오픈 소스

67 개의 포스트

cloudflare원문

에이전트에 힘을 더하다: Workers AI, 이제 Kimi K2.5를 시작으로 대규모 모델 실행 지원 (새 탭에서 열림)

Cloudflare는 자사의 AI 추론 플랫폼인 Workers AI에서 Moonshot AI의 **Kimi K2.5**를 시작으로 대규모 프런티어 모델 지원을 공식화했습니다. 이를 통해 개발자는 Durable Objects, Workflows 등 기존의 강력한 인프라와 고성능 LLM을 결합하여 에이전트의 전체 라이프사이클을 단일 플랫폼에서 관리할 수 있게 되었습니다. 특히 대형 모델의 추론 비용을 획기적으로 낮추고 성능을 최적화함으로써, 복잡한 추론 기능이 필요한 지능형 에이전트 구축의 진입 장벽을 제거했다는 점이 핵심입니다. ### Kimi K2.5 도입과 경제적 효용성 * **성능 사양:** 256k의 방대한 컨텍스트 윈도우를 지원하며, 멀티턴 도구 호출(Tool Calling), 비전 입력, 구조화된 출력 기능에 특화되어 복잡한 에이전트 작업에 적합합니다. * **비용 절감:** Cloudflare 내부의 보안 리뷰 에이전트에 적용한 결과, 기존 유료 독점 모델 대비 성능 저하 없이 비용을 약 77% 절감하는 효과를 거두었습니다. * **확장성:** 개인용 에이전트나 코딩 에이전트의 사용량이 급증하는 추세에서, 독점 모델의 높은 비용 문제를 해결하고 엔터프라이즈급 추론 능력을 경제적으로 제공합니다. ### 대규모 모델 추론 스택의 기술적 최적화 * **커스텀 커널 및 엔진:** 자체 추론 엔진인 'Infire'를 기반으로 Kimi K2.5에 최적화된 커스텀 커널을 적용하여 GPU 활용도와 처리 속도를 극대화했습니다. * **병렬화 및 분산 처리:** 데이터, 텐서, 전문가(Expert) 병렬화 기술뿐만 아니라, 프리필(Prefill)과 생성(Generation) 단계를 분리하는 '분산 프리필' 전략을 통해 높은 처리량을 확보했습니다. * **서버리스 편의성:** ML 엔지니어나 DevOps 전문가 없이도 API 호출만으로 이러한 고차원적인 최적화 기술이 적용된 대형 모델을 즉시 사용할 수 있습니다. ### 에이전트 워크로드를 위한 플랫폼 개선 * **프리픽스 캐싱(Prefix Caching):** 대화 맥락이나 시스템 프롬프트 등 중복되는 입력 텐서를 캐싱하여 프리필 단계의 계산을 생략함으로써, 첫 토큰 생성 시간(TTFT)을 단축하고 처리량을 높였습니다. * **세션 어피니티(Session Affinity) 헤더:** `x-session-affinity` 헤더를 도입하여 요청을 동일한 모델 인스턴스로 라우팅함으로써 캐시 히트율을 높이고 추론 비용을 추가로 절감할 수 있도록 지원합니다. * **캐시 토큰 할인:** 캐싱된 토큰 사용량을 명확히 시각화하여 제공하며, 일반 입력 토큰보다 저렴한 가격 정책을 적용하여 대규모 컨텍스트를 사용하는 에이전트의 비용 부담을 줄였습니다. 고성능 추론 능력이 필요한 복잡한 AI 에이전트를 구축하고자 한다면, Cloudflare Workers AI 플랫폼에서 Kimi K2.5와 세션 어피니티 기능을 활용해 보시기 바랍니다. 인프라 구축의 복잡성을 Cloudflare에 맡김으로써 개발자는 에이전트의 논리와 비즈니스 가치 창출에만 집중할 수 있습니다.

discord4분 읽기큐레이션 요약

ROOST가 온라인 안전을 발전시키는 방법

Discord는 온라인 안전 도구를 기업 내부의 비공개 자산으로 두기보다, ROOST를 통해 공개·공유·감사 가능한 오픈소스로 발전시키고 있다. 그 대표 사례인 Osprey는 실시간 이벤트 처리와 행동 분석을 수행하는 규칙 엔진으로, Discord의 프로덕션 환경에서 검증된 뒤 커뮤니티의 개선을 거쳐 다시 Discord에 반영됐다. ROOST는 이러한 도구를 여러 플랫폼이 함께 사용하고 발전시키는 생태계를 만들어 온라인 위협 대응의 기본 수준과 혁신 속도를 높이려 한다. ## 생성형 AI로 복잡해진 온라인 위협 - 공격자들은 생성형 AI를 활용해 정교한 피싱 캠페인, 설득력 있는 딥페이크, 대규모 협력형 공격을 더 빠르게 만들고 있다. - 기존의 신뢰·안전 대응 방식만으로는 위협의 규모와 변화 속도를 따라가기 어렵다. - 플랫폼마다 안전 도구를 처음부터 개발하면 대응 수준이 크게 달라지고, 특히 소규모 플랫폼은 충분한 보호 기능을 갖추기 어렵다. - ROOST는 이미 검증된 안전 기술을 공유해 플랫폼 간 격차를 줄이는 것을 목표로 한다. ## Osprey의 실시간 규칙 엔진 - Osprey는 로그인 시도, 콘텐츠 게시, 계정 생성 등 플랫폼에서 발생하는 모든 이벤트를 입력으로 받을 수 있다. - 플랫폼별로 필요한 사용자 지정 이벤트도 처리할 수 있으며, 규칙을 통해 이상 행동과 잠재적 위협을 실시간으로 분석한다. - 안전·보안 팀은 간단한 규칙 언어로 탐지 로직을 작성할 수 있다. - 새로운 규칙을 배포할 때 별도의 엔지니어링 작업에 의존하지 않아도 되며, 판단 결과가 안전·의심·악성으로 투명하게 제공된다. - Discord에서는 수천 개의 규칙을 수백 가지 이벤트 유형에 적용하고 있다. - 조사 플랫폼에서 발견한 이상 징후를 새로운 규칙으로 연결하는 순환 구조를 갖는다. - 탐지 결과가 규칙 개선으로 이어짐 - 규칙이 실제 집행으로 연결됨 - 집행 과정에서 새로운 위협 신호가 축적됨 ## 프로덕션 검증을 거친 오픈소스 - Osprey 공개를 위해 Discord 내부 시스템과의 결합을 분리하는 데 수개월의 엔지니어링 작업이 진행됐다. - 공개 버전은 기능을 축소한 별도 제품이 아니라 Discord의 실제 프로덕션 엔진에서 출발했다. - ROOST 커뮤니티가 기능을 발전시켰고, 개선된 버전은 다시 Discord의 시스템에 통합됐다. - 따라서 Discord가 운영 환경에서 사용하는 엔진과 외부 기업이 배포할 수 있는 엔진이 동일하다는 점이 강조된다. ## 기존 업계 협력 모델의 확장 - 온라인 안전 분야에는 이미 여러 조직이 공동으로 기술과 신호를 공유해 온 사례가 있다. - 아동 착취 이미지 대응을 위한 이미지 해시 기술 공유 - Tech Coalition의 Lantern 프로그램 - 테러 및 대규모 폭력 사건 대응을 위한 GIFCT의 플랫폼 간 협력 - Digital Trust & Safety Partnership이 주도한 ISO 표준화 - ROOST는 이러한 협력 전통을 오픈소스 개발 재단의 방식과 결합한다. - Linux Foundation, Apache Foundation, Python Foundation처럼 도구를 관리하는 데 그치지 않고 새로운 도구를 직접 만들고 유지보수한다. - Osprey와 종합 검토 도구인 Coop 등을 누구나 사용·기여할 수 있게 해 공공의 이익을 위한 개발자 커뮤니티를 구축하려 한다. ## 여러 플랫폼이 함께 만드는 안전 생태계 - 단일 도구나 단일 기업만으로는 온라인 안전 문제를 해결할 수 없다. - 오픈소스 안전 도구는 플랫폼들이 갖춰야 할 최소한의 보호 수준을 높이고, 새로운 방어 기술의 개발을 가속한다. - 소규모 플랫폼이 기본적인 보호 기능을 도입하면 위협이 특정 서비스에 집중되는 것을 줄일 수 있다. - 대형 플랫폼들이 방어 기술을 공개적으로 공동 개선하면 전체 인터넷 생태계가 혜택을 받는다. - ROOST는 도구 자체뿐 아니라 이를 배포·운영·관리해 주는 상용 서비스 생태계도 함께 성장할 것으로 기대한다. - Musubi는 Coop 기반 관리형 서비스를 제공 - Zentropi는 자체 라벨러 엔진을 Coop에 통합 ## 공개 개발과 실제 도입 성과 - ROOST는 2026년 FOSDEM에서 Osprey v1을 공개했다. - 여러 조직과 프로토콜의 엔지니어들이 함께 참여해 플랫폼 안전 문제와 대응 방법을 논의하는 계기가 됐다. - Bluesky를 비롯한 플랫폼들이 이미 ROOST 도구를 사용하고 있으며, 실제 운영 개선 사례도 공개되고 있다. - 글에서는 여러 플랫폼에 걸쳐 3억 6천만 명 이상의 사용자가 오픈소스 안전 도구의 혜택을 받는 생태계에 포함됐다고 설명한다. - Osprey 기여자와 도입 기관들은 2주마다 공개 작업 그룹 회의를 열어 기능을 논의하고 개발 계획을 조율한다. 오픈소스 안전 도구를 도입하려는 플랫폼은 Osprey 같은 실시간 규칙 엔진으로 탐지·집행 체계를 먼저 구축하고, 공개 작업 그룹과 다른 도입 기관의 사례를 활용하는 것이 효과적이다. 다만 도구만 설치하는 것보다 자체 위협 모델, 운영 인력, 규칙 검토 절차를 함께 마련해야 지속적인 안전 성과를 얻을 수 있다.

원문 읽기(새 탭에서 열림)
datadog원문

AI 에이전트가 문을 두드리자: Datadog 오픈 소스 저장소의 악성 기여를 포착하다 (새 탭에서 열림)

데이터독(Datadog)은 최근 GitHub Actions 및 LLM 기반 워크플로우를 표적으로 삼는 AI 에이전트 'hackerbot-claw'의 악성 기여 시도를 성공적으로 차단했습니다. 이 공격은 AI 기술을 활용해 오픈소스 리포지토리에 취약점을 주입하려는 시도였으나, 데이터독의 AI 기반 탐지 시스템인 'BewAIre'와 선제적인 CI/CD 보안 제어 덕분에 무력화되었습니다. 이번 사례는 공격자들이 LLM을 통해 공격 규모를 확장함에 따라, 방어자 또한 AI를 보안 체계에 적극적으로 도입해야 함을 시사합니다. **오픈소스 CI 파이프라인을 향한 주요 공격 벡터** - **변수 삽입 취약점:** PR 제목과 같이 사용자가 제어할 수 있는 변수를 워크플로우 스크립트 내에 안전하지 않게 삽입하는 경우를 악용합니다. - **I-PPE(간접 포이즌 파이프라인 실행):** 악성 의존성이나 빌드 지침을 PR에 삽입하여 빌드 과정에서 자동으로 실행되게 함으로써 CI 비밀번호(Secrets)를 탈취합니다. - **`pull_request_target` 오용:** 신뢰할 수 없는 PR에서 실행되는 워크플로우에 높은 권한을 부여하는 설정을 악용하여 시스템을 장악합니다. - **LLM 프롬프트 인젝션:** `claude-code-action`이나 `run-gemini-cli`처럼 LLM을 사용하는 GitHub 액션에 악의적인 지시를 주입하여 자동화된 트리징 시스템을 교란합니다. **AI 기반 탐지 시스템 'BewAIre'의 운영** - **실시간 코드 리뷰:** 매주 유입되는 약 10,000건의 내외부 PR을 대상으로 LLM 기반의 자동화된 보안 검사를 수행합니다. - **2단계 분석 파이프라인:** GitHub 이벤트를 통해 코드 차분(diff) 데이터를 추출 및 정규화한 뒤, 2단계 LLM 파이프라인을 거쳐 변경 사항을 '악성' 또는 '정상'으로 분류하고 그 근거를 구조화하여 제시합니다. - **SIEM 통합 및 대응:** 악성으로 판정된 결과는 즉시 Datadog Cloud SIEM으로 전송되어 보안 사고 대응 팀(SIRT)이 즉각적으로 조사하고 사고화할 수 있도록 지원합니다. **선제적인 인프라 강화 및 보안 모범 사례** - **최소 권한의 임시 자격 증명:** OIDC identity federation을 활용한 `dd-octo-sts-action`을 도입하여, 수명이 길고 권한이 과도한 개인 액세스 토큰(PAT) 대신 수명이 짧고 권한이 제한된 인증 정보를 동적으로 생성합니다. - **비밀 정보 관리:** 수천 개의 리포지토리를 전수 조사하여 사용되지 않는 GitHub Actions 비밀 정보를 대규모로 식별하고 제거했습니다. - **CI 보안 정책 강제화:** 브랜치 보호 규칙, 휴먼 및 봇의 커밋 서명 의무화, 필수 PR 승인 절차를 도입하고 `GITHUB_TOKEN` 권한을 기본적으로 최소 수준으로 설정했습니다. - **보안 골든 패스(Golden Paths):** 엔지니어들이 별도의 복잡한 설정 없이도 보안이 확보된 표준 CI 파이프라인을 사용할 수 있도록 가이드를 문서화하고 시스템화했습니다. AI 에이전트를 활용한 공격이 현실화됨에 따라 단순한 규칙 기반의 탐지는 한계에 직면해 있습니다. 조직은 BewAIre와 같은 AI 기반 탐지 모델을 구축함과 동시에, OIDC를 통한 인증 체계 개선 및 GITHUB_TOKEN 권한 최소화와 같은 근본적인 CI/CD 보안 설정을 병행하여 자동화된 공격에 대한 방어 계층을 다각화해야 합니다.

github4분 읽기큐레이션 요약

GitHub Security Lab의 오픈 소스

GitHub Security Lab은 오픈 소스 AI 프레임워크인 **Taskflow Agent**와 웹 보안 감사용 taskflow를 활용해 80건 이상의 취약점을 발견했으며, 그중 상당수는 인증 우회와 민감 정보 노출처럼 영향도가 높은 취약점이었다고 설명합니다. 이 방식은 대형 단일 프롬프트 대신 여러 단계의 작업을 YAML로 정의하고, LLM의 분석 결과를 데이터베이스로 전달해 반복적·구조적인 보안 감사를 수행합니다. 프레임워크와 taskflow는 공개되어 있어 GitHub Copilot 사용자는 자신의 저장소에서도 실행할 수 있습니다. ## 오픈 소스 AI 보안 감사의 성과 - 새로운 taskflow는 웹 애플리케이션 취약점 탐색에 특화되어 있습니다. - 지금까지 80건 이상의 취약점을 보고했으며, 작성 시점에 약 20건이 공개되었습니다. - 발견된 취약점의 상당수는 다음과 같은 고위험 유형입니다. - 인증 또는 권한 우회 - 다른 사용자로 로그인할 수 있는 문제 - 다른 사용자의 비공개 데이터에 접근하는 정보 노출 - 글에서 제시한 사례로는 다음이 언급됩니다. - 전자상거래 애플리케이션의 장바구니에서 개인식별정보(PII) 접근 - 채팅 애플리케이션에서 어떤 비밀번호를 사용해도 로그인 가능한 문제 - 연구자들은 기존에 악용 가능성이 불분명한 후보를 검증하는 데 쓰던 시간을 줄이고, 실제 결과를 수동 검증하고 보고하는 데 더 집중할 수 있게 되었다고 설명합니다. ## 자신의 저장소에서 실행하는 방법 - `GitHubSecurityLab/seclab-taskflows` 저장소에서 Codespace를 시작합니다. - 초기화가 끝난 뒤 다음 명령을 실행합니다. ```bash ./scripts/audit/run_audit.sh myorg/myrepo ``` - 중간 규모 저장소에서는 실행에 한두 시간이 걸릴 수 있습니다. - 완료되면 SQLite 뷰어가 열리고, `audit_results` 테이블에서 `has_vulnerability` 열이 체크된 행을 확인합니다. - 실행에는 GitHub Copilot 라이선스가 필요하며, 프리미엄 모델 요청 할당량을 많이 사용할 수 있습니다. - LLM 결과는 비결정적이므로 같은 코드베이스를 여러 번 검사하는 것이 권장됩니다. - 서로 다른 모델을 사용하면 결과가 달라질 수 있습니다. - 예시로 GPT 5.2와 Claude Opus 4.6을 각각 사용할 수 있습니다. - 비공개 저장소도 지원하지만, Codespace 설정을 수정해 접근 권한을 별도로 부여해야 합니다. ## Taskflow의 구조 - Taskflow는 LLM에 수행시킬 작업 목록을 YAML로 정의한 파일입니다. - `seclab-taskflow-agent`가 다음 기능을 담당합니다. - 작업을 순차적으로 실행 - 앞선 작업의 결과를 다음 작업에 전달 - 여러 구성 요소에 같은 작업을 비동기적으로 반복 실행 - 템플릿 프롬프트에 구성 요소별 정보를 삽입 - 저장소 감사는 일반적으로 다음 단계로 나뉩니다. - 저장소를 기능별 구성 요소로 분할 - 각 구성 요소의 진입점, 신뢰할 수 없는 입력, 요구 권한, 역할 등을 분석 - 분석 결과를 `repo_context.db` 같은 데이터베이스에 저장 - 저장된 컨텍스트를 사용해 취약점 후보를 생성 - 후보별로 세부 검증을 수행 - 현재는 각 구성 요소에 대해 일반적인 보안 문제를 제안하는 작업과, 제안된 문제를 정밀하게 검증하는 작업이 사용됩니다. - 특정 취약점 유형에 집중하는 별도의 taskflow도 추가할 수 있습니다. ## 하나의 거대한 프롬프트 대신 여러 작업을 사용하는 이유 - LLM의 컨텍스트 창에는 한계가 있습니다. - 복잡한 작업을 하나의 프롬프트에 모두 넣으면 일부 단계가 누락되거나 제대로 수행되지 않을 수 있습니다. - 작업을 분리하면 다음과 같은 장점이 있습니다. - 각 단계의 결과를 개별적으로 확인 가능 - 실패하거나 잘못된 단계를 디버깅하기 쉬움 - 이전 분석 결과를 후속 작업의 컨텍스트로 재사용 가능 - 여러 코드 구성 요소에 동일한 분석을 일관되게 적용 가능 - 더 큰 컨텍스트 창을 지원하는 모델에서도, 작업 흐름을 통제하고 검증하기 위해 taskflow 방식이 유용하다고 설명합니다. ## 일반 보안 코드 감사에서의 과제 - 초기에는 CodeQL 경고 분류처럼 범위와 판단 기준이 명확한 작업에 Taskflow Agent를 사용했습니다. - 이후 특정 경고에 한정하지 않고 일반적인 취약점까지 찾는 방식으로 확장했습니다. - LLM에 더 많은 자유를 주면 다음 문제가 커집니다. - 환각 - 오탐 - 검증하기 어려운 취약점 보고 - CodeQL 경고 분류가 효과적이었던 이유는 지시와 판정 기준이 엄격하고, 각 단계에서 결과가 요구사항을 충족하는지 확인할 수 있었기 때문입니다. - 따라서 목표는 LLM이 다양한 취약점을 자유롭게 탐색하게 하면서도 taskflow 설계와 프롬프트 엔지니어링으로 환각과 오탐을 통제하는 것입니다. ## 실용적인 권장 사항 실제 프로젝트에 적용할 때는 한 번의 실행 결과를 확정적인 보안 보고서로 취급하지 말고, 여러 모델과 반복 실행으로 후보를 수집한 뒤 사람이 재현 가능성과 악용 가능성을 검증하는 것이 좋습니다. 또한 저장소 전체를 한 번에 분석하기보다 기능별 구성 요소와 단계별 taskflow로 나누면 결과를 추적하고 수정하기 쉽습니다.

원문 읽기(새 탭에서 열림)
meta원문

인프라 투자: jemalloc에 (새 탭에서 열림)

메타(Meta)는 자사 소프트웨어 인프라의 핵심 토대인 고성능 메모리 할당자 'jemalloc'에 대한 기술적 지원과 커뮤니티 협업을 대폭 강화한다고 발표했습니다. 과거 단기적 이득을 우선시하며 발생했던 기술적 부채를 인정하고, 프로젝트 설립자와의 논의를 통해 오픈 소스 저장소를 다시 활성화하여 코드베이스 현대화에 착수했습니다. 이를 통해 최신 하드웨어 환경에 최적화된 성능을 제공하고 장기적인 소프트웨어 건강성을 회복하는 것을 목표로 합니다. ## 기술적 부채 청산과 커뮤니티 신뢰 회복 * 과거 핵심 엔지니어링 원칙에서 벗어나 발생했던 기술적 부채를 해결하기 위해 리팩토링을 진행하며, 모든 사용자가 쉽고 안정적으로 사용할 수 있도록 코드베이스를 정비합니다. * 프로젝트 설립자인 제이슨 에반스(Jason Evans) 및 오픈 소스 커뮤니티와의 긴밀한 소통을 통해 아카이브되었던 저장소를 다시 열고 투명한 개발 프로세스를 유지합니다. * 신뢰는 행동을 통해 얻어진다는 원칙 아래, 메타의 자원 투입이 jemalloc의 장기적인 발전으로 이어질 수 있도록 운영 방식을 개선했습니다. ## 현대적 하드웨어를 위한 성능 최적화 로드맵 * **대용량 페이지 할당자(HPA) 개선**: 투명한 대용량 페이지(THP, Transparent Huge-Pages)의 활용도를 높여 CPU 효율성을 극대화할 수 있도록 HPA 기능을 지속적으로 고도화합니다. * **메모리 효율성 극대화**: 메모리 패킹(Packing), 캐싱, 퍼징(Purging) 메커니즘을 개선하여 불필요한 메모리 낭비를 줄이고 시스템 전반의 효율을 높입니다. * **AArch64(ARM64) 플랫폼 최적화**: 최신 서버 환경인 ARM64 아키텍처에서 별도의 튜닝 없이도 즉각적으로 뛰어난 성능(Out-of-the-box performance)을 발휘할 수 있도록 지원을 강화합니다. ## 인프라 경쟁력 강화를 위한 제언 이번 jemalloc의 변화는 대규모 트래픽을 처리하는 인프라 환경에서 메모리 할당자의 성능이 시스템 전체의 비용과 효율에 직결됨을 시사합니다. 특히 ARM64 기반 서버로 전환 중이거나 대용량 페이지 관리를 통해 CPU 성능을 높이고자 하는 조직이라면, 향후 업데이트될 jemalloc의 최적화 기능을 적극적으로 검토하고 도입할 가치가 있습니다.

gitlab원문

Git 2.53.0 (새 탭에서 열림)

Git 2.53.0 버전은 대규모 저장소 관리 효율성을 높이고 데이터 무결성을 강화하는 데 초점을 맞춘 업데이트를 선보였습니다. 이번 릴리스의 핵심은 부분 클론(Partial Clone) 환경에서의 기하급수적 재패킹 지원과 히스토리 재작성 시 유효한 서명을 선별적으로 보존하는 기능의 도입입니다. 이를 통해 개발자와 운영자는 대규모 프로젝트를 관리할 때 성능 최적화와 보안 신뢰성을 동시에 확보할 수 있게 되었습니다. ## 부분 클론 환경의 기하급수적 재패킹(Geometric Repacking) 지원 * 전통적인 'all-into-one' 재패킹 방식은 모든 객체를 하나의 패크파일로 합쳐 조회 성능은 좋지만, 대규모 저장소에서는 작업 시간이 지나치게 길어지는 단점이 있습니다. * 이를 보완하는 '기하급수적 전략'은 패크파일들의 크기를 일정 비율(두 배 이상)로 유지하며 필요한 부분만 결합하지만, 그동안 부분 클론 환경의 '프로미서(promisor)' 패크파일을 제대로 처리하지 못하는 기술적 한계가 있었습니다. * Git 2.53에서는 기하급수적 재패킹 시 프로미서 패크파일을 별도로 구분하여 관리하도록 개선되었습니다. 이를 통해 부분 클론을 사용하는 저장소에서도 데이터 손상 위험 없이 효율적인 객체 관리가 가능해졌습니다. ## 유효한 커밋 서명만 보존하는 git-fast-import 개선 * 저장소 히스토리를 대량으로 재작성하는 `git-fast-import` 명령어에 `--signed-commits` 옵션의 새로운 모드인 `strip-if-invalid`가 추가되었습니다. * 기존에는 히스토리를 재작성할 때 서명을 일괄 삭제하거나 무효한 서명을 그대로 남겨둬야 했으나, 이제는 재작성으로 인해 내용이 바뀐 커밋의 서명만 골라 삭제할 수 있습니다. * 이 기능 덕분에 히스토리 재작성 과정에서 변경되지 않은 객체들의 유효한 서명은 안전하게 보존할 수 있어, 데이터의 무결성을 유지하는 데 큰 도움이 됩니다. ## 저장소 구조 분석 도구(git-repo-structure)의 데이터 수집 강화 * 저장소의 성능 특성을 파악하기 위해 도입된 `git repo structure` 명령어가 이제 도달 가능한 객체들의 상세 크기 정보를 제공합니다. * 커밋, 트리, 블롭, 태그 등 각 객체 유형별로 압축 해제 시 크기(Inflated size)와 실제 디스크 점유 크기(Disk size)를 모두 확인할 수 있습니다. * 이는 외부 도구 없이도 네이티브 명령어를 통해 대규모 저장소의 구조적 부하를 진단하고 하드웨어 자원 계획을 세우는 데 유용하게 활용됩니다. 대규모 저장소를 운영하거나 히스토리 정제 작업을 빈번하게 수행하는 팀이라면 이번 Git 2.53.0 업데이트를 적극 권장합니다. 특히 부분 클론을 활용한 CI/CD 환경에서 기하급수적 재패킹을 통해 성능을 최적화하고, 히스토리 수정 시에도 유효한 서명을 유지함으로써 보안 수준을 한 단계 높일 수 있습니다.

kakao원문

더 똑똑하고 효율적인 Kanana-2 오픈소스 공개 (새 탭에서 열림)

카카오는 사용자의 명령 맥락을 파악하고 능동적으로 동작하는 에이전틱 AI(Agentic AI) 구현에 최적화된 차세대 언어모델 'Kanana-2'를 오픈소스로 공개했습니다. 글로벌 프런티어 모델인 Qwen3-30B-A3B와 대등한 성능을 갖춘 이번 모델은 도구 호출(Tool Calling)과 지시 이행 능력을 대폭 강화하여 실무적인 활용도를 극대화했습니다. 특히 한국어 처리 효율성을 30% 이상 개선하고 추론 특화 모델을 라인업에 추가함으로써, 고도화된 논리적 사고가 필요한 서비스 개발에 강력한 토대를 제공합니다. **다양한 연구 및 서비스 요구사항을 충족하는 세 가지 모델 라인업** * **Kanana-2-30b-a3b-base**: 사전 학습 단계의 웨이트를 포함한 기본 모델로, 연구자들이 자체 데이터를 활용해 자유롭게 파인 튜닝하여 새로운 모델을 개발할 수 있는 기초가 됩니다. * **Kanana-2-30b-a3b-instruct**: 사용자의 지시를 정확히 이해하고 수행하는 능력을 극대화한 버전으로, 일반적인 대화 및 작업 수행에 최적화되어 있습니다. * **Kanana-2-30b-a3b-thinking**: 카카오가 처음으로 선보이는 추론 특화 모델로, 수학이나 코딩 등 복잡한 논리적 사고가 필요한 과제에서 뛰어난 성능을 발휘하며 높은 지시 이행 능력을 동시에 유지합니다. **에이전틱 AI 구현을 위한 도구 호출 및 지시 이행 성능 강화** * **Multi-turn Tool Calling**: 외부 도구를 자유자재로 다루는 능력을 이전 모델(Kanana-1.5) 대비 3배 이상 개선하여, 모델 컨텍스트 프로토콜(MCP) 활용성을 극대화했습니다. * **정교한 지시 이행**: 사용자의 복잡하고 단계적인 요구사항을 정확히 파악하여 결과물을 생성하며, 추론 모델에서도 이러한 성능이 저하되지 않도록 설계되었습니다. * **다국어 지원 확대**: 기존 한국어와 영어에 더해 일본어, 중국어, 태국어, 베트남어까지 총 6개 국어를 지원하여 글로벌 서비스 대응 능력을 높였습니다. **대규모 트래픽 처리를 위한 아키텍처 및 효율성 개선** * **MLA(Multi-head Latent Attention)**: 메모리 점유를 압축하여 긴 문맥(Long Context)을 효율적으로 처리할 수 있도록 설계되었습니다. * **MoE(Mixture of Experts)**: 추론 시 필요한 파라미터만 활성화하는 전문가 혼합 구조를 통해 거대 모델의 성능은 유지하면서 연산 비용과 응답 속도를 획기적으로 개선했습니다. * **한국어 최적화 토크나이저**: 새롭게 학습된 토크나이저를 통해 기존 모델 대비 한국어 토큰 효율을 30% 이상 향상시켜, 더 적은 자원으로 빠른 응답(High Throughput)이 가능합니다. **실용적인 결론 및 제안** Kanana-2는 고성능과 효율성을 동시에 잡은 모델로, 특히 한국어 기반의 복잡한 에이전트 서비스를 구축하려는 개발자에게 최적의 선택지입니다. 허깅페이스(Hugging Face)를 통해 Base 모델부터 추론 특화 모델까지 모두 공개되어 있으므로, 목적에 맞는 모델을 선택해 즉시 파인 튜닝하거나 서비스에 적용해 보실 것을 추천합니다.

naver원문

네이버 TV (새 탭에서 열림)

네이버의 서비스 운영 환경에서 효율적인 지표 수집을 위해 Telegraf를 활용하여 커스텀 Exporter를 개발한 경험과 그 노하우를 공유합니다. 다양한 오픈소스 솔루션의 벤치마크 결과를 바탕으로 Telegraf의 유연성과 확장성을 검증하였으며, 이를 통해 기존 지표 수집 시스템의 한계를 극복하고 운영 효율을 개선한 구체적인 사례를 제시합니다. 최종적으로는 커스텀 지표 수집이 필요한 엔지니어들에게 실무적인 적용 가이드와 최적화 옵션을 제안합니다. **오픈소스 기반 Exporter 도입 배경과 벤치마크** * 서비스 규모가 확장됨에 따라 표준 지표만으로는 파악하기 어려운 비즈니스 로직 및 특정 인프라 상태를 모니터링해야 하는 필요성이 증가했습니다. * 기존의 파편화된 수집 방식을 개선하기 위해 여러 오픈소스 기반 Exporter들의 성능, 유지보수 편의성, 확장성을 비교 분석하는 벤치마크 테스트를 수행했습니다. * 다양한 환경에 유연하게 대응하면서도 시스템 리소스 점유율이 낮은 최적의 솔루션을 찾는 과정이 수반되었습니다. **Telegraf의 구조와 선정 이유** * Telegraf는 플러그인 기반 아키텍처를 가진 에이전트로, 데이터 수집(Input), 처리(Processor), 집계(Aggregator), 전송(Output)의 전 과정을 설정 파일만으로 손쉽게 구성할 수 있습니다. * Go 언어로 작성되어 별도의 런타임 없이 단일 바이너리로 실행 가능하며, 메모리 사용량이 적어 사이드카(Sidecar) 형태로 배포하기에 적합합니다. * 이미 풍부한 커뮤니티 플러그인을 보유하고 있어 새로운 커스텀 지표를 추가하거나 데이터 형식을 변환할 때 개발 공수를 획기적으로 줄일 수 있습니다. **Telegraf 적용 후 개선점** * 여러 대의 서버와 서비스에서 발생하는 지표 수집 방식을 Telegraf로 표준화하여 관리 포인트가 단일화되었습니다. * 필요에 따라 지표를 가공하거나 필터링하는 기능을 활용하여 모니터링 시스템(Prometheus, InfluxDB 등)으로 전달되는 데이터의 양을 최적화했습니다. * 커스텀 Exporter 개발 시 반복되는 통신 로직이나 버퍼링 로직을 직접 구현할 필요 없이 Telegraf의 기능을 활용함으로써 개발 생산성이 향상되었습니다. **성능 최적화를 위한 주요 설정 옵션** * `flush_interval`: 지표를 수집하여 목적지로 전송하는 주기를 조절함으로써 네트워크 트래픽과 실시간성 사이의 균형을 맞춥니다. * `metric_batch_size` 및 `metric_buffer_limit`: 한 번에 전송할 지표의 양과 일시적인 장애 시 보관할 버퍼 크기를 설정하여 데이터 유실을 방지합니다. * `precision`: 지표의 타임스탬프 정밀도를 설정하여 저장소 용량을 효율적으로 관리하고 쿼리 성능을 개선합니다. 오픈소스 기반의 모니터링 환경을 구축하려는 엔지니어에게 Telegraf는 매우 강력한 도구입니다. 단순히 지표를 수집하는 것을 넘어, 전처리와 집계 과정을 표준화하고 싶다면 Telegraf의 플러그인 아키텍처를 적극 활용해 보기를 권장합니다. 특히 대규모 인프라에서 커스텀 Exporter 개발 시 발생하는 중복 코드를 줄이고 운영 안정성을 확보하는 데 큰 도움이 될 것입니다.

discord원문

ROOST, AI 시대를 위한 (새 탭에서 열림)

비영리 단체 ROOST는 AI 시대의 온라인 안전을 위해 오픈 소스 기반의 보안 도구인 'Coop'과 'Osprey'를 공개했습니다. 이 도구들은 막대한 비용이 드는 엔터프라이즈 소프트웨어나 복잡한 자체 시스템 없이도 모든 규모의 기업이 유해 콘텐츠를 탐지하고 대응할 수 있는 기술적 토대를 제공합니다. 이를 통해 안전 인프라를 공공재로 전환함으로써 디지털 생태계 전반의 보안 수준을 상향 평준화하는 것을 목표로 합니다. **전문적인 콘텐츠 검토와 규제 준수를 돕는 Coop** * 콘텐츠 리뷰를 전문가에게 라우팅하고, 검토에 필요한 관련 정보를 시각화하여 즉각적인 조치를 취할 수 있는 인터페이스를 제공합니다. * 아동 성착취물(CSAM)의 의무 신고를 위한 미국 실종학대아동센터(NCMEC) API가 내장되어 있어 관련 법규를 효율적으로 준수할 수 있습니다. * 대규모 유해 콘텐츠 처리에 특화된 기술 기업 'Cove'의 IP를 ROOST가 인수하여 오픈 소스로 전환함으로써, 검증된 기술력을 누구나 무료로 활용할 수 있게 되었습니다. **위협 조사 및 대규모 사고 대응을 위한 Osprey** * 플랫폼 내에서 발생하는 위협을 심층적으로 이해하고 대규모로 대응 조치를 실행할 수 있는 경량화된 사고 조사 도구입니다. * 사용자 친화적인 설계를 통해 소규모 커뮤니티부터 대형 플랫폼까지 인프라 부담 없이 강력한 조사 기능을 수행할 수 있도록 돕습니다. * Discord가 자사 플랫폼뿐만 아니라 인터넷 전체의 안전을 위해 개발한 기술을 ROOST에 기증한 것으로, 업계 내 안전 기술 공유의 핵심 사례로 꼽힙니다. **오픈 소스 안전 생태계의 확산과 협업** * 탈중앙화 소셜 미디어인 Bluesky는 Osprey 도입을 통해 자원 규모와 관계없이 효과적인 안전 인프라 구축이 가능함을 입증할 계획입니다. * Notion과 같은 주요 플랫폼들은 기존 Cove 기술을 통해 확보한 안전 역량을 기반으로, ROOST의 주도하에 더욱 강화된 개방형 보안 생태계 구축에 동참하고 있습니다. * 이 모델은 스타트업의 혁신, 자선 단체의 후원, 그리고 오픈 소스의 협업 정신을 결합하여 피싱 캠페인부터 아동 안전 사고까지 광범위한 위협에 맞서는 새로운 표준을 제시합니다. 온라인 위협이 정교해짐에 따라 안전 도구는 더 이상 경쟁 우위 수단이 아닌, 모든 플랫폼이 갖춰야 할 필수적인 기반 시설이 되어야 합니다. 유해 콘텐츠 대응과 플랫폼 보안 강화가 필요한 서비스 제공자라면, 향후 정식 공개될 Coop과 Osprey를 적극적으로 도입하여 비용 효율적이면서도 전문적인 신뢰 및 안전(Trust & Safety) 역량을 확보할 것을 권장합니다.

figma원문

Payload의 Figma 팀 합류를 (새 탭에서 열림)

피그마(Figma)는 오픈소스 헤드리스 CMS이자 애플리케이션 프레임워크인 페이로드(Payload) 팀을 인수하여 디자인과 개발의 경계를 허무는 행보를 가속화합니다. 이번 인수는 최근 발표된 '피그마 사이트(Figma Sites)'와 시너지를 내어 개발자들에게 더욱 강력하고 유연한 도구를 제공하는 데 목적이 있습니다. 피그마는 이를 통해 디자인뿐만 아니라 실제 제품의 빌드와 배포까지 생태계 내에서 직접 수행할 수 있는 중앙 허브로 거듭날 계획입니다. **Figma Sites와 Payload의 기술적 시너지** - Config 2025에서 발표된 '피그마 사이트'와 결합하여, 디자인에서 실제 프로덕션 웹사이트 제작까지의 과정을 비약적으로 단축합니다. - Payload가 제공하는 높은 커스터마이징 자유도와 확장성을 활용해, 개발자들이 기존의 제한적인 CMS 환경에서 벗어나 더 나은 DX(개발자 경험)를 누릴 수 있도록 지원합니다. - 포춘 100대 기업들이 이미 도입하여 신뢰성을 검증받은 Payload의 기술력을 피그마 플랫폼에 이식함으로써 엔터프라이즈급 개발 환경을 구축합니다. **오픈소스 생태계 유지와 커뮤니티 협업** - Payload는 인수 후에도 오픈소스 프로젝트로 유지되며, 기존 사용자들은 현재와 동일하게 서비스를 이용할 수 있도록 독립성을 보장합니다. - 피그마의 협업 중심 철학과 Payload의 오픈소스 커뮤니티 지향점이 결합되어, 사용자 피드백을 기반으로 한 제품 로드맵을 투명하게 공유할 예정입니다. - 피그마는 오픈소스 프로젝트에 지속적으로 투자하여 개발자들이 지식을 공유하고 기술을 발전시킬 수 있는 생태계를 확장하는 데 집중할 계획입니다. **디자인-개발 통합을 통한 제품 제작 가속화** - AI의 발전으로 코드와 콘텐츠 생성이 쉬워진 환경에 발맞추어, 배포 채널을 직접 제어하고 사용자 경험을 세밀하게 튜닝할 수 있는 제어권을 강화합니다. - 단순히 디자인 결과물을 공유하는 단계를 넘어, 피그마 생태계 내에서 직접 디지털 제품을 구축하고 배포할 수 있는 환경을 조성합니다. - 디자인과 개발 사이에 전통적으로 존재해 왔던 간극을 좁힘으로써 제품 제작 팀의 전체적인 생산성을 높이는 것을 최종 목표로 삼고 있습니다. 디자이너와 개발자가 긴밀하게 협업해야 하는 조직이라면 향후 피그마 사이트와 페이로드의 통합 기능을 주목할 필요가 있습니다. 디자인 시스템을 기반으로 실제 웹 서비스를 신속하게 배포하고 관리하려는 팀에게 이번 인수는 매우 강력한 생산성 도구의 탄생을 예고합니다.

figma2분 읽기큐레이션 요약

디자인 시스템 도입을 가로

디자인 시스템은 대기업만을 위한 복잡한 도구가 아니라, 팀 규모와 관계없이 효율성·일관성·협업을 높이는 실용적인 체계다. 최신 유행이나 Material Design을 그대로 따르기보다 조직의 목표, 브랜드, 사용자에 맞춰 설계해야 한다. 또한 처음부터 모든 것을 직접 만들 필요 없이 공개된 리소스를 활용해 현실적인 범위에서 시작할 수 있다. ## 디자인 시스템은 대기업만을 위한 것이 아니다 - 규모가 작은 팀도 디자인 시스템을 통해 반복 작업을 줄이고 결과물의 일관성을 높일 수 있다. - 디자인 시스템의 형태는 조직마다 다를 수 있지만, 핵심 목적은 공통적이다. - 업무 효율 향상 - 제품 경험의 일관성 확보 - 디자이너와 개발자 간 협업 촉진 - 사례로 소개된 Mixpanel은 디자인 시스템을 개편해 비용을 절감하고, 일관성을 개선하며, 전사적으로 데이터 분석 접근성을 높였다. ## 최신 디자인 기법을 모두 적용해야 한다는 오해 - 디자인 트렌드는 계속 변하며, 모든 조직에 통하는 유일한 정답은 없다. - 다른 팀의 사례와 업계 동향은 참고할 수 있지만 그대로 복제할 필요는 없다. - “완벽하고 최신인 시스템”을 만드는 데 집중하면 실제 해결하려던 문제와 목표를 놓칠 수 있다. - 디자인 시스템은 유행을 보여주는 전시물이 아니라 다음을 지원해야 한다. - 조직의 구체적인 목표 - 실제 사용자 요구 - 팀의 업무 방식 - 지속 가능한 운영 ## Material Design이 모든 조직에 맞는 것은 아니다 - Google의 Material Design은 널리 알려진 표준이지만, 모든 제품에 그대로 적용할 수 있는 만능 해법은 아니다. - 조직의 디자인 시스템은 다음 요소를 반영해야 한다. - 브랜드의 고유한 정체성 - 제품 사용자의 needs - 조직의 비즈니스 목표 - 현재 조직이 처한 상황과 우선순위 - 업계 표준을 참고하되, 조직에 가장 적합한 방식과 균형을 찾아야 한다. - 글에서는 Uber Base, Google Material 3, Spotify Backstage, Pipedrive, Microsoft Teams, Salesforce Lightning 등의 디자인 시스템과 UI 키트를 비교 사례로 제시한다. ## 디자인 시스템을 처음부터 직접 만들어야 한다는 오해 - 글은 디자인 시스템을 반드시 처음부터 자체 제작해야 한다는 생각에 의문을 제기한다. - 공개된 오픈소스 디자인 시스템과 UI 리소스를 활용하면 초기 구축 비용과 시간을 줄일 수 있다. - 이미 검증된 리소스를 기반으로 시작한 뒤, 조직의 브랜드와 제품 요구에 맞게 수정하는 방식이 현실적이다. - 제공된 본문은 이 신화에 대한 설명 중간에서 끝나므로, 이후 네 번째부터 여섯 번째 신화의 전체 내용은 확인할 수 없다. 작게 시작하되 팀의 반복 문제와 실제 사용자 요구를 우선 해결하는 것이 좋다. 기존 오픈소스와 업계 사례는 출발점으로 활용하고, 최종 디자인 시스템은 조직의 브랜드·제품·업무 방식에 맞게 점진적으로 발전시키는 것이 바람직하다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

디자인 시스템의 미래는 복잡

디자인 시스템은 제품과 사용자 요구가 복잡해질수록 단순한 시각 규칙 모음이 아니라, 여러 팀과 시스템을 조율하는 운영 구조가 되어야 한다. 브랜치·머지, 로컬 시스템, 오픈소스 같은 코드의 방식을 활용하면 확장성과 협업을 높일 수 있지만, 지나친 규제는 창의성과 실험을 막는다. 따라서 미래의 디자인 시스템은 구조와 유연성 사이의 균형을 지속적으로 조정해야 한다. ## 디지털 제품의 복잡성과 디자인 시스템의 변화 - 초기 디자인 시스템은 사용자가 디지털 인터페이스를 이해하도록 돕는 시각적 은유에 크게 의존했다. - Google Material Design은 종이를 쌓은 듯한 표면, 가장자리, 그림자를 사용해 조작 가능한 요소를 설명했다. - 당시에는 완전한 스큐어모피즘 없이도 사용자가 인터페이스를 직관적으로 이해하도록 만드는 것이 주요 과제였다. - 그러나 다양한 디바이스와 폼팩터가 등장하면서 단일 은유만으로는 충분하지 않게 됐다. - 접근성 기준 - 새로운 입력 방식과 상호작용 - 성능 요구사항 - 여러 화면과 플랫폼에 대응하는 반응형 경험 - Instagram처럼 하나의 핵심 기능만 제공하던 앱도 검색, 광고, 파트너십, 쇼핑 등으로 확장됐다. - 이에 따라 디자인 시스템은 더 많은 기능과 사용자 유형, 서로 연결된 제품 경험을 지원해야 한다. ## 구조로 혼란 다루기 - 디자인팀은 소프트웨어 개발에서 사용하던 프로세스와 프레임워크를 디자인 시스템에 적용하고 있다. - 대표적인 방식이 브랜치와 머지다. - 기여자가 별도의 브랜치에서 새로운 컴포넌트나 수정안을 작업한다. - 기존의 메인 시스템에 영향을 주지 않고 실험할 수 있다. - 디자인 시스템 관리자가 변경 사항을 검토한 뒤 공식 시스템에 반영한다. - 이 방식은 디자인 시스템을 중앙 팀만 관리하는 자산이 아니라, 커뮤니티와 함께 발전시키는 구조로 만든다. - Spotify의 Encore는 하위 팀이 시스템을 포크해 각자의 “로컬 시스템”을 만들도록 허용했다. - 광고 팀의 비디오 플레이어처럼 특정 도메인에 특화된 컴포넌트가 발전했다. - 이러한 결과물이 다시 전체 디자인 시스템의 방향과 적용 범위를 넓혔다. - 오픈 디자인 시스템은 외부 기여와 피드백을 받을 수 있다는 장점이 있다. - 다양한 사용자의 요구를 파악할 수 있다. - 제품과 조직의 작업 방식을 공개해 신뢰와 인지도를 높인다. - 디자인 지식을 업계와 공유할 수 있다. ## 지나치게 엄격한 시스템의 문제 - 구조를 규모 있게 적용하면 일관성은 높아지지만, 시스템이 지나치게 제한적으로 변할 수 있다. - 디자이너는 다음과 같은 문제를 경험할 수 있다. - 새로운 아이디어를 실험하기 어려움 - 제품 특성에 맞는 예외를 만들기 어려움 - 기존 컴포넌트에 억지로 맞추느라 디자인 품질이 떨어짐 - 디자인 시스템의 목적은 창의적 표현의 진입장벽을 낮추는 것이지, 창작 자체를 어렵게 만드는 것이 아니다. - 모든 상황을 사전에 정의하려는 접근은 복잡한 제품과 예상하지 못한 사용자 요구에 제대로 대응하지 못한다. ## 건축보다 정원에 가까운 운영 - Shopify의 José Torre는 디자인 시스템을 완성 후 고정하는 건축물보다 계속 돌보고 변화하는 정원에 비유한다. - 건축적 접근: - 세부 사항을 미리 결정한다. - 설계와 구축이 끝나면 결과물을 완성된 상태로 간주한다. - 정원식 접근: - 기본적인 씨앗과 구조를 심되, 최종 형태는 성장 과정에서 발견한다. - 실제 사용 중 나타나는 문제와 새로운 요구에 따라 개입한다. - 불필요한 요소는 제거하고 유용한 패턴은 발전시킨다. - 계획된 디자인 시스템 안에서도 새로운 버튼이나 메뉴 변형이 자연스럽게 등장할 수 있다. - 이런 변형을 무조건 제거하기보다, 실제 제품 요구에서 비롯된 것인지 평가하고 필요하다면 시스템에 흡수하는 유연성이 중요하다. 디자인 시스템은 엄격한 규칙집이 아니라 제품과 조직의 변화에 맞춰 계속 진화하는 기반으로 운영하는 것이 바람직하다. 공통 구조와 검토 절차는 유지하되, 브랜치·로컬 시스템·실험 공간을 허용해 팀의 자율성과 창의성을 보장해야 한다.

원문 읽기(새 탭에서 열림)
datadog원문

엔지니어링 스포트라이트: 테이 니시무라 (새 탭에서 열림)

데이터독(Datadog)의 인프라 엔지니어 테이 니시무라(Tay Nishimura)의 커리어 여정은 자신만의 사고방식에 적합한 직무를 찾는 과정의 중요성을 보여줍니다. 수학 전공자이자 시각적 사고를 선호하는 그녀는 일반적인 소프트웨어 개발 속도 경쟁에서 어려움을 겪었으나, 네트워크 시뮬레이터 'ToyNet' 개발을 통해 자신의 강점을 증명하며 SRE(Site Reliability Engineering)로 성공적으로 전향했습니다. 이 글은 전형적인 엔지니어의 틀에 갇히지 않고 자신의 고유한 특성을 기술적 자산으로 승화시킨 과정을 다룹니다. **학계와 실무 사이의 괴리와 시각적 사고** * 수학 전공자로서 증명 위주의 엄격한 사고에 익숙했던 테이는 효율과 속도를 중시하는 애자일 개발 환경에서 초기에 성능 피드백 문제로 어려움을 겪었습니다. * 코드를 바로 작성하기보다 코드를 그림으로 변환하여 논리를 검증한 뒤 다시 코드로 옮기는 '시각적 사고' 방식을 고수했는데, 이는 신중함을 더해주었지만 작업 속도를 늦추는 요인이 되기도 했습니다. * 일반적인 개발 직무에서는 속도 저하로 평가받았던 그녀의 신중함과 모든 실패 모드를 고려하는 태도가, 오히려 시스템의 안정성을 책임지는 SRE 직무에는 핵심적인 역량이 될 수 있음을 깨달았습니다. **ToyNet 개발과 SRE로의 전환** * 팬데믹 기간 중 해고를 겪었으나 이를 계기 삼아 평소 관심 있던 네트워크 기술을 공부하며, 수감자와 베테랑을 위한 교육 프로그램 'Project Reclass'를 시작했습니다. * 인터넷 사용이 제한된 교도소 환경에서도 네트워크 실습이 가능하도록 React, Flask, Mininet을 활용해 컨테이너 기반 네트워크 에뮬레이션 플랫폼인 'ToyNet'을 설계했습니다. * ToyNet은 테이의 클라우드 배포 역량과 기술적 깊이를 증명하는 강력한 포트폴리오가 되었으며, 이는 데이터독에 SRE로 합류하는 결정적인 발판이 되었습니다. **데이터독에서의 적응과 시각적 분석의 힘** * 데이터독 합류 후 Kubernetes, 카오스 엔지니어링, Go 언어 등 생소한 기술 스택을 빠르게 습득하며 인프라 엔지니어로서 전문성을 쌓았습니다. * 데이터독의 카오스 자동화 도구인 'Chaos Controller'를 오픈소스화하는 과정에서, 복잡한 코드베이스를 상자와 화살표로 시각화하여 구조를 파악하는 자신만의 분석 방식을 적극적으로 활용했습니다. * 과거에는 약점으로 치부되었던 '꼼꼼하고 신중한 속도'가 이제는 대규모 시스템의 신뢰성을 보장하고 복잡한 기술 문제를 해결하는 강력한 무기가 되었습니다. 자신이 업계의 전형적인 틀(Cookie-cutter shape)에 맞지 않는다고 느낄 때, 포기하기보다는 자신의 독특한 사고방식이 빛을 발할 수 있는 세부 분야를 찾는 것이 중요합니다. 테이 니시무라의 사례처럼 사이드 프로젝트를 통해 실질적인 기술력을 증명하고 이를 직무 전환의 교두보로 활용하는 전략은 커리어 고민을 겪는 엔지니어들에게 실질적인 영감을 줍니다.

figma3분 읽기큐레이션 요약

앞으로의 한 해: 솔

창의적 업무는 하이브리드·원격 근무의 확산으로 물리적 공간보다 디지털 환경을 중심으로 재편될 전망이다. 협업이 글로벌·비동기적으로 이루어질수록 명확한 문서화, 투명한 의사결정, 체계적인 조직 운영이 중요해진다. 장기적으로는 디자인 탐색과 피드백의 상당 부분이 AI와 같은 가상 협업자에 의해 자동화될 가능성도 제시된다. ## 하이브리드 근무와 디지털 창작 환경 - 전통적인 사무실 회의실에서 진행하던 ‘자유 발상’과 화이트보딩 세션이 FigJam 같은 디지털 협업 도구로 이동한다. - 업무 맥락과 조직의 지식이 물리적 공간이 아니라 디지털 환경에 축적된다. - 창작 도구는 디자이너만의 전문 도구가 아니라, 직군 전체가 사용하는 협업 도구로 확장된다. - 도구가 더 협력적이고 접근하기 쉬워질수록 창작 과정의 참여 장벽과 직군 간 격차가 낮아진다. ## 런던과 실리콘밸리의 생태계 차이 - 런던에서는 기술 산업이 이미 지배적인 분야인 실리콘밸리와 달리, 아직 성장하고 혁신하는 분야로 인식된다. - 기존 기술 중심 지역에서 당연하게 여겨지는 지식과 관행이 신흥 시장에서는 새롭고 혁신적인 것으로 받아들여질 수 있다. - 런던에는 초기 단계의 영국 창업자를 지원하려는 투자자들이 유입되고 있다. - 과거에는 자금 조달과 성장을 위해 실리콘밸리로 이동해야 했던 창업자들이 이제는 영국을 기반으로 글로벌 기술 기업을 만들 수 있다. - 이러한 창업자와 기업은 런던의 미래 산업 구조를 직접 형성하는 역할도 하게 된다. ## 글로벌·비동기 협업의 운영 방식 - 여러 시간대에 걸쳐 일하는 팀은 피드백과 의사결정 과정을 의도적으로 설계해야 한다. - 동료가 서로 다른 시간대에 활동하므로 실시간 회의만으로 정렬하기 어렵고, 비동기 협업이 필수적이다. - 업무 지시와 피드백은 더 명확한 글로 작성해야 하며, 영상 녹화를 활용해 방향과 맥락을 전달할 수 있다. - 사무실에서 자연스럽게 공유되던 배경지식이 줄어들기 때문에 문서화와 결정 과정의 공개가 중요해진다. - 명확한 기록, 투명한 의사결정, 정돈된 프로세스를 뜻하는 ‘조직 위생(organizational hygiene)’이 경쟁력이 된다. ## 디자인 자동화와 가상 협업자 - 디자인 탐색과 피드백 과정은 앞으로 상당 부분 자동화될 가능성이 있다. - 미래에는 사람이 아닌 소프트웨어 에이전트가 지식 노동, 피드백, 반복 작업에 참여할 수 있다. - 이러한 가상 협업자는 현재 사람이 수동으로 수행하는 업무 유형에 맞춰 조정될 수 있다. - AI 기반 협업자의 등장은 단순한 생산성 향상을 넘어 팀워크와 협업의 본질 자체를 바꿀 수 있는 변화로 평가된다. ## 실용적인 시사점 - 원격·하이브리드 팀은 회의보다 문서, 녹화 피드백, 공개된 의사결정 기록을 우선 구축하는 것이 좋다. - 모든 구성원이 참여할 수 있는 디지털 화이트보드와 협업 도구를 활용하면 직군 간 아이디어 교환을 확대할 수 있다. - 반복적인 디자인 검토와 피드백 업무는 향후 자동화할 수 있도록 프로세스를 구조화하고 데이터를 축적해야 한다. ※ 제공된 글은 Soleio 인터뷰의 중간에서 끝나 있어 Julie Zhuo와 May-Li Khoe의 답변 내용은 포함되어 있지 않습니다.

원문 읽기(새 탭에서 열림)
figma2분 읽기큐레이션 요약

Config 2021

이 글은 Config 2021에서 소개된 팀 문화 변화 사례를 통해, 협업적이고 포용적인 디자인 문화를 만들려면 취약함을 솔직하게 드러내고 서로의 경험을 존중해야 한다고 말한다. 개인의 감정과 필요를 공유하는 투명성, 누구나 참여할 수 있는 공동의 공간과 자원, 다양한 관점을 끌어들이는 협력이 신뢰와 포용성을 강화한다는 결론이다. ## 취약함을 받아들이는 팀 문화 - 업무와 개인 생활의 경계가 흐려진 상황에서는 구성원이 자신의 감정과 필요한 지원을 솔직하게 말할 수 있어야 한다. - Figma 리서치팀은 1:1 대화와 수시 확인 외에도 매일 Slack 스탠드업을 운영했다. - 당일 집중할 업무를 공유한다. - 운동, 취미, 가족과의 시간 등 업무 외에 자신에게 활력을 주는 활동도 함께 이야기한다. - 이 방식은 구성원이 일과 삶의 균형을 지키도록 돕고, 서로를 더 깊이 이해하게 만든다. - 동료를 단순히 경청하는 데서 그치지 않고, 상대의 감정·경험·생각을 표현할 공간까지 마련하는 것이 중요하다. - 항상 괜찮은 척하지 않아도 된다는 점을 인정할 때 팀의 심리적 안전감이 높아진다. ## 모두가 참여할 수 있는 공간 만들기 - Bitcoin 디자인 커뮤니티의 Johns Beharry와 Christoph Ono는 기술 전문성이 부족한 사람에게 Bitcoin 디자인이 배타적으로 느껴질 수 있다는 피드백을 받았다. - Bitcoin의 접근성 확대라는 취지와 달리, 전문 용어나 기술 중심 자료가 진입장벽이 될 수 있음을 인식했다. - 이를 해결하기 위해 여러 형태의 공동 공간과 학습 자원을 구축했다. - 초보자와 경험 많은 디자이너가 교류하는 Slack 그룹 - 작업물을 공유하고 협업하는 GitHub - 자료를 모은 리소스 허브 - 초기 작업과 어려움을 논의하는 주간 커뮤니티 콜 - 모범 사례와 학습 내용을 담은 오픈소스 Bitcoin Design Guide - 자료는 특정 문화, 지역, 언어, 지리적 배경에 한정되지 않도록 설계했다. - 목표는 전문 지식을 과시하는 공간이 아니라, 누구나 질문하고 대화에 참여할 수 있는 “친절한 공간”을 만드는 것이었다. ## 다양성을 위한 협업 - 디자인은 본질적으로 다양한 경험과 관점이 결합되는 협업 활동이다. - 더 많은 사람이 디자인 과정에 참여하면 접근성과 포용성이 높은 결과물을 만들 가능성이 커진다. - 조직이나 개인이 혼자 모든 문제를 해결할 수 없으므로, 커뮤니티와 공유 자원을 활용해야 한다. - 투명한 대화와 열린 참여 구조는 팀 내부뿐 아니라 외부 협력자에게도 신뢰를 형성한다. 팀 문화를 개선하려면 구성원이 힘든 상태를 숨기지 않아도 되는 분위기를 만들고, 정기적인 체크인과 감정 공유를 일상적인 업무 방식에 포함하는 것이 좋다. 동시에 초보자도 접근할 수 있는 공유 문서·커뮤니티·학습 공간을 마련해 다양한 배경의 사람들이 실제 의사결정과 디자인 과정에 참여하도록 해야 한다.

원문 읽기(새 탭에서 열림)