coding-agents

6 개의 포스트

figma3분 읽기큐레이션 요약

더 나은 코드, 더 적은 토큰: MCP에서 Code Connect의 이점 | Figma 블로그

코딩 에이전트가 디자인을 코드로 변환할 때 Code Connect를 사용하면 실제 프로덕션 컴포넌트와 디자인 시스템을 더 정확히 활용할 수 있다. Figma MCP와 Code Connect를 함께 사용한 실험에서 작업 시간은 19.6%, 토큰 사용량은 29.5% 감소했고, 코드 품질은 1~4점 척도에서 1점 향상됐다. 즉, 시각적으로 비슷한 코드를 새로 만드는 대신 기존 컴포넌트를 직접 연결하면 더 빠르고 일관된 결과를 얻을 수 있다. ## 코딩 에이전트가 디자인 시스템을 잘못 구현하는 이유 - Figma MCP의 `get_design_context`는 캔버스의 디자인을 React 코드 형태로 설명한다. - Code Connect가 없으면 에이전트는 다음과 같은 문제를 겪을 수 있다. - 기존 컴포넌트 대신 새로운 컴포넌트를 직접 생성한다. - 디자인 시스템에서 잘못된 컴포넌트를 선택한다. - 올바른 컴포넌트를 찾더라도 검색과 수정에 불필요한 토큰과 시간을 사용한다. - 결과물은 시각적으로는 맞아 보여도 프로젝트의 실제 코드 구조나 디자인 시스템 규칙과 어긋날 수 있다. ## Code Connect가 MCP 응답을 보강하는 방식 - Code Connect는 Figma 컴포넌트와 코드베이스의 실제 컴포넌트를 연결한다. - 설정이 완료되면 MCP 응답에 일반적인 React 표현 대신 프로덕션 코드에 가까운 코드 스니펫이 포함된다. - 에이전트는 다음 정보를 직접 전달받는다. - 사용해야 할 컴포넌트의 import 경로 - 컴포넌트에 전달할 정확한 속성값 - 디자인 요소와 코드 컴포넌트 간의 대응 관계 - 예를 들어 Code Connect가 없으면 탭 UI를 여러 `<button>` 요소와 CSS 클래스로 재구성할 수 있다. - Code Connect를 사용하면 다음처럼 기존 디자인 시스템 컴포넌트를 바로 사용한다. ```tsx <SegmentedControl value="design" options={["Design", "Code"]} /> ``` ## Coinbase 사례 - Coinbase Design Systems 팀은 일관된 UI를 위해 핵심 컴포넌트, 디자인 토큰, 인프라를 관리한다. - 에이전트 기반 개발을 도입하면서 Code Connect를 적용해 에이전트가 CDS 컴포넌트를 재사용하도록 했다. - Code Connect가 없을 때는 에이전트가 스테퍼를 프로그레스 바 조합으로 임의 구현하는 등 컴포넌트를 잘못 추측할 수 있었다. - Code Connect를 사용하면 정확한 코드 표현과 실제 CDS 컴포넌트의 import 문을 확인할 수 있어 코드 품질이 향상되고 토큰도 절약됐다. ## Code Connect의 효과를 측정한 실험 - 동일한 디자인, 프롬프트, 모델을 사용해 Code Connect 적용 여부만 달리한 디자인-투-코드 작업을 비교했다. - 총 27개 테스트 케이스에서 다음 항목을 측정했다. - 코드 품질 - 토큰 사용량 - 작업 소요 시간 - React 기반 디자인 시스템 두 가지를 대상으로 했다. - Figma의 예제 디자인 시스템인 Simple Design System(SDS) - 더 규모가 크고 복잡한 내부 시스템인 Figma Pattern Library(FPL) - Code Connect 적용 결과: - 작업 시간 중앙값 19.6% 감소 - 토큰 사용량 중앙값 29.5% 감소 - 코드 품질 1~4점 Likert 척도에서 1점 향상 ## 실용적인 적용 방향 - 디자인 시스템의 핵심 컴포넌트에 Code Connect 템플릿을 우선 설정하는 것이 효과적이다. - 에이전트가 직접 HTML과 스타일을 조합하게 하기보다 실제 컴포넌트와 import 정보를 제공해야 한다. - 디자인 시스템을 사용하는 팀이라면 Code Connect를 단순한 인간 개발자용 문서화 도구가 아니라 에이전트의 코드 생성 품질과 비용을 개선하는 컨텍스트 계층으로 활용할 수 있다.

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

거대한 AI 생성 풀 리퀘스트 하나를 검토 가능한 스택으로 바꾸기

AI 코딩 에이전트는 짧은 시간에 대규모 기능을 구현하지만, 모든 변경을 하나의 거대한 PR에 담는 방식은 리뷰 품질과 병합 속도를 떨어뜨린다. 이 글은 기능을 데이터·API·애플리케이션 연결·UI처럼 논리적 계층으로 나누고, 각 계층을 작은 PR로 쌓는 “스택드 풀 리퀘스트(stacked pull requests)”를 대안으로 제시한다. 이를 통해 에이전트의 생산성은 유지하면서도 각 변경을 독립적으로 검토하고 관리할 수 있다. ## AI가 만든 대규모 PR의 문제 - 쇼핑 어시스턴트에 상품 검색 기능을 추가하면 다음 변경이 한 PR에 함께 들어가기 쉽다. - 새 데이터 모델과 시드 데이터 - API 라우트와 입력 검증 - 클라이언트 연결 - UI 및 빈 상태·오류 상태·대체 상태 - 결과적으로 1,000~1,700줄 이상의 큰 diff가 만들어질 수 있다. - 리뷰어는 변경 내용을 한 번에 이해하기 어렵고, PR 설명이 길지만 구체적이지 않으면 검토를 뒤로 미루게 된다. - 리뷰가 늦어지면서 문맥이 사라지고 피드백 품질이 낮아지며, 충돌과 수동 동기화가 늘어난다. - 결국 기능이 충분히 검토되지 않은 채 병합될 위험이 커진다. ## 스택드 풀 리퀘스트의 기본 원리 - 하나의 대형 PR 대신 기능을 논리적으로 분해해 여러 개의 작은 PR로 만든다. - 각 PR은 하나의 관심사만 다루며, 리뷰어가 한 번에 이해할 수 있는 크기로 제한한다. - PR은 의존성 순서에 따라 연결된다. - 하위 계층이 먼저 구현되고, 상위 계층은 그 변경을 기반으로 작업한다. - 이전 계층에서 얻은 문맥은 다음 계층으로 자연스럽게 이어지므로, 전체 기능을 매번 처음부터 읽을 필요가 없다. - 데이터 담당자, 백엔드 담당자, UI 담당자처럼 변경 영역에 맞는 리뷰어를 배정할 수 있다. ## 상품 검색 기능의 스택 구조 | 계층 | 브랜치 | 작업 내용 | 의존 대상 | |---|---|---|---| | L1 | `feat/catalog-data` | 타입이 지정된 카탈로그, 시드 데이터, 검증, 데이터 접근 모듈 | `main` | | L2 | `feat/search-api` | 검증을 포함한 `/api/products/search` 엔드포인트 | L1 | | L3 | `feat/chat-grounding` | 채팅이 API를 호출하고 실제 상품 데이터에 기반해 응답 | L2 | | L4 | `feat/grounded-ui` | 상품 인용 카드와 UI 상태 처리 | L3 | - 데이터, API, 애플리케이션 연결, UX가 각각 독립된 작업 단위가 된다. - 각 계층은 자체적으로 리뷰할 수 있지만, 전체 기능은 계층 간 의존성을 통해 완성된다. - 가장 기반이 되는 작업을 스택의 아래쪽에 배치하고, 그 위에 이를 사용하는 작업을 쌓는다. ## GitHub 도구와 초기 설정 - GitHub는 PR 화면뿐 아니라 터미널에서도 스택드 PR을 관리할 수 있다. - `gh-stack` CLI 확장 설치: ```bash gh extension install github/gh-stack ``` - 코딩 에이전트가 스택 구조를 이해하고 생성·관리하도록 관련 스킬을 설치할 수 있다. ```bash gh skill install github/gh-stack ``` 또는: ```bash npx skills add github/gh-stack ``` - 스택을 시작하기 전에 스택의 기준 브랜치(stack base)를 정해야 한다. - 일반적으로 `main`이 기준이 된다. - CI 검사와 병합 규칙이 전체 스택에서 이 기준을 바탕으로 평가된다. - 모든 계층에 CI가 존재하는지 확인해야 한다. - 각 PR 계층마다 CI 검사가 실행된다. - 따라서 작은 PR이라도 테스트와 규칙 검증을 통과해야 한다. ## 에이전트별 작업 분담 - 에이전트에게 전체 기능을 한 번에 맡기기보다, 계층별로 역할과 범위를 지정한다. - 예시 구성: - L1: 데이터 모델러 에이전트 - L2: 백엔드 에이전트 - L3: 프론트엔드 에이전트 - L4: 프론트엔드 에이전트 - 각 에이전트는 하나의 작업 스트림과 엄격한 범위를 따르도록 구성한다. - 이런 방식은 에이전트가 자동화 루프에서 작업하더라도 결과물이 지나치게 커지는 것을 방지한다. - 작업 순서는 데이터 기반을 먼저 만들고, API, 채팅 연결, UI 순으로 진행한다. ## 실용적인 적용 방법 - 기능을 시작할 때 먼저 데이터·도메인 모델·API·애플리케이션 연결·UI로 나눈다. - 각 PR이 단일 관심사만 포함하는지 확인한다. - 기반 브랜치를 먼저 만들고, 각 후속 브랜치를 바로 이전 계층에서 파생한다. - 계층별로 적절한 리뷰어를 배정하고, 각 PR에 해당 계층의 목적과 검증 방법을 명확히 작성한다. - AI 에이전트에는 “전체 기능 구현”이 아니라 특정 스택 계층과 변경 범위를 명시하는 것이 좋다. - 스택드 PR은 리뷰 부담을 줄이는 대신 브랜치 의존성을 관리해야 하므로, CLI와 자동화 도구를 함께 사용하는 것이 효과적이다.

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

AI 시대의 개발 능력은 검증력으로 결정된다, Flava API Gateway 개발 중 배운 빠른 검증과 로컬 환경 구성 전략

코딩 에이전트는 빠르게 코드를 생성하지만, 설계 불명확성·출력 비결정성·검증 지연 때문에 신뢰할 수 없는 결과를 만들 수 있다. LY Corporation의 Flava API Gateway 팀은 이를 해결하기 위해 **스펙 주도 개발, 검증 자동화, 빠르고 독립적인 로컬 환경**을 구축했다. 결론적으로 AI의 생산성을 활용하려면 개발자의 전문성과 테스트·린터·사전 설계를 오히려 더 강화해야 한다. ## 코딩 에이전트가 만드는 개발 병목 - 에이전트의 코드 생성 속도에 비해 CI 대기, 환경 프로비저닝, 원격 테스트 같은 단계는 느리다. - 에이전트는 다음과 같은 오류를 반복적으로 만들 수 있다. - 컴파일되지 않는 코드 - 존재하지 않는 API 참조 - 명시되지 않은 설계 결정을 임의로 선택 - 동일한 프롬프트라도 실행마다 결과가 달라질 수 있어 출력의 일관성과 역량을 일반화하기 어렵다. - AI가 개발자의 리뷰 속도보다 빠르게 코드를 생성하면, 검토되지 않은 코드가 누적될 위험이 있다. - 따라서 AI 활용의 핵심은 단순한 생성 속도가 아니라, 잘못된 결과를 빠르게 발견하고 수정하는 개발 시스템이다. ## Flava API Gateway와 세 가지 대응책 - Flava API Gateway는 LY Corporation의 사내 프라이빗 클라우드 Flava에서 API를 생성·배포·모니터링하는 제품이다. - Kong이 데이터 플레인을 담당하고, 컨트롤 플레인은 각 팀이 독립적으로 API를 관리할 수 있는 다중 테넌트 REST API를 제공한다. - 팀은 다음 세 가지 원칙을 채택했다. - 코드 작성 전 설계와 요구사항을 확정하는 **스펙 주도 개발** - 테스트와 린터로 에이전트가 스스로 오류를 찾도록 하는 **검증 자동화** - CI를 기다리지 않고 전체 검증 루프를 돌리는 **빠른 로컬 환경** ## 스펙 주도 개발로 구현 방향 고정 - 에이전트가 설계가 정해지기 전에 구현을 시작하면, 에이전트가 임의로 설계 결정을 내리면서 비결정성이 커진다. - Flava 팀은 먼저 OpenAPI 스펙으로 컨트롤 플레인의 전체 설계를 정의했다. - OpenAPI 스펙은 다음 역할을 한다. - 에이전트가 따라야 할 명시적 기준 - 구현 결과가 설계에서 벗어났는지 판단하는 검증 기준 - API 동작 계약의 문서화 - 이후 기능을 작은 단위로 나누고 OpenSpec을 사용해 각 기능을 구현했다. ## Nickel을 활용한 OpenAPI 관리 - 원본 OpenAPI YAML은 반복적이고 장황해 수작업 유지보수가 어렵다. - 스펙과 실제 구현이 어긋나면 에이전트를 통제하는 기준으로서의 가치가 떨어진다. - 팀은 Nickel을 사용해 API 리소스를 선언적으로 정의하고, 이를 전체 CRUD 엔드포인트 스펙으로 변환했다. - 예를 들어 리소스 정의만으로 다음 요소를 일관되게 생성할 수 있다. - 목록·생성·조회·삭제 엔드포인트 - 페이지네이션과 정렬 - 정확히 일치하는 필터와 부분 문자열 필터 - ETag 기반 낙관적 잠금 - 공통 오류 응답 - 이 방식은 반복적인 YAML 작성량을 줄이고, API 설계 규칙을 생성기에 집중시킨다. ## OpenSpec 기반의 협업 워크플로 OpenSpec은 에이전트가 구현 전에 행동 계약에 합의하도록 다음 네 가지 산출물을 요구한다. - **제안(Proposal)**: 무엇을, 왜 변경하는지 설명 - **설계(Design)**: 기술적 결정과 트레이드오프 정리 - **델타 스펙(Delta Specs)**: 변경되는 요구사항을 Given-When-Then 시나리오로 정의 - **작업 목록(Task List)**: 구현 단계를 체크리스트로 분해 워크플로는 다음 순서로 진행된다. - 개발자와 에이전트가 기능, 세부사항, 에지 케이스를 함께 검토한다. - 에이전트가 네 가지 산출물을 작성한다. - 에이전트가 작업 목록을 단계적으로 실행하며 구현한다. - 완료 후 변경 사항을 아카이브하고 델타 스펙을 메인 스펙에 병합한다. - 축적된 델타 스펙은 시간이 지나면서 시스템 전체의 “살아 있는 스펙”이 된다. ## 검증 자동화로 에이전트의 오류 수정 유도 - 프롬프트에 주의사항을 계속 추가하는 방식은 효과가 제한적이며, 제약이 많아질수록 출력 품질이 낮아질 가능성도 있다. - 대신 테스트와 린터가 오류를 구체적으로 드러내도록 구성했다. - 에이전트는 다음과 같은 반복 루프를 수행한다. - 코드를 작성한다. - 테스트·린터·포매터를 실행한다. - 실패 원인을 확인한다. - 코드를 수정한다. - 다시 검증하고 다음 오류로 넘어간다. - 모든 요구사항을 처음부터 프롬프트에 주입하는 대신, 필요한 제약을 실패 시점에 점진적으로 제공하는 방식이다. - 프로젝트별 스킬에 테스트, 린터, 포매터를 묶고 `AGENTS.md`를 통해 언제 해당 스킬을 사용할지 안내했다. - 검사 지침을 매 턴마다 전달하지 않고 필요할 때만 로드해 에이전트의 불필요한 컨텍스트 부담도 줄였다. ## 세 계층 테스트와 완전한 로컬 검증 전체 테스트 모음은 2,754개이며 다음 세 계층으로 구성된다. - **단위 테스트** - 비즈니스 로직을 분리해 검증 - **통합 테스트** - 실제 PostgreSQL 사용 - 제약 조건, 트리거, 소프트 삭제 연쇄, 트랜잭션 검증 - 전체 인프로세스 HTTP 스택 검증 - 모든 응답의 OpenAPI 준수 여부 확인 - **E2E 테스트** - 실제 Athenz 인증 - Kong 데이터 플레인 - API 키 적용 - 멀티 테넌트 격리 - 전체 시스템 동작 검증 ## CI 의존성을 줄인 빠른 개발 환경 - 개발자가 직접 작성할 때는 CI 왕복을 줄이기 위해 어느 정도 완성된 코드를 먼저 제출할 수 있지만, 에이전트는 짧은 간격으로 수많은 시도를 반복한다. - 모든 시도를 원격 CI로 보내면 다음 문제가 생긴다. - 긴 대기 시간 - 반복 과정에서 에이전트가 컨텍스트를 잃을 가능성 - 원격 환경의 로그와 상태를 조사하기 어려움 - 완전한 로컬 환경을 구축하면 에이전트가 즉각적인 피드백을 받고 현재 작업 흐름을 유지할 수 있다. - 로컬 의존성의 로그와 상태를 직접 확인할 수 있어 실패 원인 분석도 쉬워진다. - 전체 테스트는 개발자 기기에서 약 15초 안에 실행되도록 최적화했다. - 이를 위해 테스트를 병렬화하고 테스트 간 격리를 강화했다. 공유 테이블을 매번 삭제하는 방식보다 각 테스트 패키지가 독립적으로 생성한 데이터를 사용해 실행 간 충돌을 줄이는 방향을 택했다. ## 실용적인 적용 권장사항 AI 코딩 에이전트를 도입할 때는 프롬프트를 복잡하게 만드는 것보다 먼저 API·행동 스펙을 문서화하고, 테스트·린터·포매터를 자동 실행하며, 핵심 검증을 로컬에서 빠르게 끝낼 수 있게 만드는 것이 효과적이다. 에이전트의 성능을 높이는 가장 현실적인 방법은 더 많은 일을 맡기는 것이 아니라, 실패를 즉시 알려 주고 스스로 수정할 수 있는 짧은 피드백 루프를 구축하는 것이다.

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

Skill 품질 관리를 위한 Rubric 설계와 시스템 구현

Skill은 코딩 에이전트가 개발 과정에서 호출해 사용하는 문서형 도구이므로, 내용이 좋아도 호출되지 않으면 아무런 가치가 없다. 글은 Skill 품질을 6개 섹션 30개 항목으로 평가하고, 형식처럼 결정적으로 검증할 수 있는 항목은 규칙 기반으로, 호출 적합성처럼 의미 판단이 필요한 항목은 LLM 기반으로 분리해야 한다고 주장한다. 특히 BLOCKER가 하나라도 있으면 F 등급으로 처리해 Merge 차단 여부를 단순하게 판단하는 것이 핵심이다. ## Skill 평가가 어려운 이유 - Skill은 컴파일이나 테스트처럼 명확한 통과·실패 기준이 없다. - 결함이 있어도 호출되지 않거나, 호출돼도 효과가 없는 상태로 조용히 남을 수 있다. - 대표적인 문제는 다음 두 가지다. - **트리거 실패**: 호출 조건을 본문에 작성하고 `description`에는 적지 않아 에이전트가 Skill을 호출하지 못하는 문제 - **형식 위반**: `name`이 kebab-case가 아니거나, `name`과 폴더명이 달라 Skill 자체가 인식되지 않는 문제 ## 규칙 기반 검사와 모델 기반 검사의 분리 - 형식·구조처럼 결과가 명확한 항목은 정규식, 카운트, AST 파싱 등 결정적 도구로 검사한다. - 트리거의 의미나 설명의 충분성처럼 문맥 판단이 필요한 항목은 LLM이 평가한다. - 30개 평가 항목은 다음처럼 나뉜다. - 규칙 검사 17개 - 모델 검사 13개 - 역할을 섞으면 문제가 발생한다. - 결정적 결함을 LLM에 맡기면 애매한 상태를 통과시키는 False Negative가 생긴다. - 의미적 판단을 정규식으로 처리하면 표현의 다양성을 놓쳐 False Positive가 늘어난다. - 규칙 검사는 비용이 거의 없어 모든 PR에서 실행할 수 있고, LLM 검사는 규칙 검사를 통과한 Skill에만 적용해 비용을 줄인다. ## 6개 섹션 30개 항목의 평가 구조 - 각 항목은 `BLOCKER`, `MAJOR`, `MINOR` 심각도를 가진다. - 결과는 S부터 F까지 5단계 등급으로 표시한다. - `BLOCKER`가 하나라도 있으면 무조건 F다. - 세부 등급은 작성자에게 상태를 알려주는 신호로 사용하고, 실제 Merge 차단은 F 여부만으로 결정한다. - 이 방식은 등급의 미세한 차이를 두고 불필요하게 논쟁하는 일을 줄인다. ## 타당성: Skill이 정말 필요한가 - Skill을 만들 만한 가치가 있는지 평가한다. - 핵심 질문은 다음과 같다. - 반복적으로 발생하는 작업인가? - 코딩 에이전트가 일반적인 지시만으로 처리하기 어려운가? - Skill로 만들어 제공할 때 지속적인 이점이 있는가? - 일회성 작업이나 에이전트에게 그대로 시켜도 되는 작업은 Skill로 만들 필요가 없다. - 다른 섹션이 이미 만들어진 Skill의 품질을 점검한다면, 타당성 섹션은 애초에 만들지 말았어야 할 Skill을 걸러내는 역할을 한다. - 이 섹션에는 3개 항목이 있으며 모두 MAJOR 수준이다. ## 구조: 형식 오류를 결정적으로 차단 - 구조 섹션은 8개 항목으로 구성되며, 그중 5개가 BLOCKER다. - 예시로 다음을 검사한다. - frontmatter 존재 여부와 YAML 파싱 가능 여부 - `name`의 kebab-case 준수 여부 - `name`과 폴더명 일치 여부 - `description` 길이가 1~1024자 범위인지 여부 - 본문에 허용되지 않은 XML 태그가 포함됐는지 여부 - 구조 검사는 전부 규칙 기반으로 처리하며 LLM을 사용하지 않는다. - frontmatter 자체가 파싱되지 않는 경우에는 즉시 반환하지만, 그 외 오류는 가능한 한 끝까지 검사한다. - 여러 오류를 한 번에 반환해 PR 작성자가 한 번의 피드백으로 모두 수정할 수 있도록 설계했다. - 형식 검사는 정교함보다 매번 동일한 결과를 내고 누락 없이 동작하는 것이 중요하므로, 단순한 구현을 유지한다. ## 트리거: Description에 WHAT과 WHEN을 함께 작성 - 에이전트는 Skill을 호출할지 결정할 때 이름과 `description`만 본다. - Skill 본문은 호출이 결정된 뒤에 읽힌다. - 따라서 본문에만 다음과 같은 조건을 작성하면 호출되지 않는다. - “언제 사용하는가” - “어떤 상황에서 호출하는가” - `Use when ...` - `description`에는 Skill이 무엇인지뿐 아니라 언제 사용해야 하는지도 포함해야 한다. - 트리거 섹션은 6개 항목으로 구성되며, 본문에만 트리거 조건이 있는 경우 BLOCKER로 처리한다. - 처음에는 `when`, `use when`, “할 때”, “사용 시” 같은 표현을 정규식으로 검사했지만 한계가 있었다. - 한국어 표현을 놓치면 잘못된 BLOCKER가 발생한다. - 이모지, 완곡한 표현, 다양한 문장 구조를 모두 규칙으로 포괄하기 어렵다. - 최종적으로는 “Description이 본문의 트리거 조건을 의미적으로 충분히 포함하는가?”를 LLM이 판단하도록 전환했다. ## 운영 방식과 설계 원칙 - BLOCKER 구조 오류는 LLM 평가 전에 차단해 불필요한 모델 호출을 줄인다. - 구조 검사 결과를 오류 목록으로 한 번에 제공해 수정 비용을 낮춘다. - 복잡한 전략 패턴 같은 확장 설계보다 현재 요구사항에 맞는 단순한 검사 코드를 우선한다. - 규칙 기반과 모델 기반의 책임 영역을 명확히 나누는 것이 Rubric 전체의 핵심 원칙이다. 실무에서는 먼저 frontmatter, 이름 규칙, 폴더 구조 같은 형식 검사를 자동화하고, 이를 통과한 Skill에 대해서만 트리거 적합성과 내용 품질을 LLM으로 평가하는 방식을 권장한다. 특히 `description`에는 Skill의 기능(WHAT)과 사용 시점(WHEN)을 모두 명시해야 하며, BLOCKER 하나만으로도 배포나 Merge를 막도록 운영하면 호출되지 않는 Skill을 조기에 줄일 수 있다.

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

Nova: 코딩 에이전트를 위한 사내 플랫폼을 소개합니다

코딩 에이전트는 코드 작성뿐 아니라 CI 장애 대응, 마이그레이션, 테스트 개선 등 소프트웨어 개발 전반의 반복 업무를 지원할 수 있다. Dropbox는 대규모 모노레포와 Bazel, 사내 인프라에 맞는 실행·검증 환경을 제공하기 위해 개별 도구 대신 클라우드 기반 플랫폼인 Nova를 구축했다. Nova는 대화형 세션과 비동기 자동화 작업을 하나의 인터페이스로 통합하고, 실제 빌드·테스트 결과를 바탕으로 에이전트가 반복적으로 수정하도록 설계됐다. ## 분산된 개발 업무를 통합하는 플랫폼 - 개발 과정에는 디버깅, 의존성 업데이트, 테스트 커버리지 개선, flaky test 수정처럼 반복적이지만 중요한 작업이 많다. - 작업에 따라 상호작용 방식이 다르다. - 개발자가 직접 대화하며 진행하는 대화형 세션 - 에이전트가 백그라운드에서 실행되고 의미 있는 결과만 전달하는 비동기 작업 - Dropbox의 대규모 모노레포는 Bazel의 캐시와 원격 실행, 온프레미스 인프라에 의존한다. - 일반적인 외부 코딩 에이전트는 로컬 개발에는 적합하지만 Dropbox의 저장소 구조와 빌드·검증 경로를 자연스럽게 지원하지 못한다. - 따라서 워크플로마다 별도 AI 도구를 만드는 대신, 실행·검증·컨텍스트 처리를 공통화한 플랫폼을 선택했다. ## Nova의 실행 및 검증 방식 - 각 Nova 세션은 특정 커밋 시점의 Dropbox 코드베이스 스냅샷을 기반으로 격리된 환경에서 실행된다. - 호출자는 다음 정보를 전달할 수 있다. - 기준 커밋 - 수행할 작업 - 작업 후 실행할 검증 명령 - 검증 실패 시 계속 진행할지 여부 - 최대 반복 횟수 - 결과를 게시할 브랜치 - 기본 흐름은 다음과 같다. - 에이전트가 변경 사항 제안 - Bazel 빌드·테스트 등 실제 검증 수행 - 실패 결과를 에이전트에 전달 - 에이전트가 원인을 분석하고 수정 - 정해진 반복 횟수까지 재검증 - 단순히 그럴듯한 패치를 생성하는 데 그치지 않고, 실제 Dropbox 개발 환경에서 변경 사항이 유효한지 확인한다. - 세션은 하나의 브랜치만 사용하고 코드 게시 작업은 에이전트 외부에서 처리한다. - 활성 브랜치와 게시 상태를 예측하기 쉽다. - 테스트 실행, 리베이스 등 후속 자동화를 단순하게 유지할 수 있다. - 여러 브랜치를 에이전트가 직접 관리할 때 발생하는 기준 브랜치 선택 문제를 피할 수 있다. ## 다양한 개발 인터페이스와 확장 기능 - Nova는 여러 코딩 에이전트를 동일한 인터페이스 뒤에서 사용할 수 있도록 확장됐다. - 제공 방식은 다음과 같다. - 웹 UI 기반 대화형 세션 - CLI - API - 로컬 에이전트, 스크립트, 사내 서비스에서 병렬 작업 실행 - 장기 실행 워크플로에 AI 단계를 추가할 수 있는 헬퍼를 제공한다. - 프롬프트 평가, 관측성, 피드백 수집 기능으로 에이전트 성능을 측정하고 개선할 수 있다. - 파일 수정 외에도 로그 수집, 장애 조사, 여러 단계에 걸친 컨텍스트 유지가 필요하므로 다음 확장 기능을 포함한다. - Skills - Plugins - MCP 통합 - 관측성 시스템 접근 ## CI 장애 대응에서 시작한 적용 - Nova는 CI 실패에 대한 수정 제안을 자동화하는 문제에서 출발했다. - 예시 요청은 특정 커밋에서 CI 실패를 조사하고, 관련 Bazel 테스트를 실행하며, 실패 시 최대 5회까지 수정·재검증하는 형태다. - 검증 명령을 호출자가 명시하므로 에이전트가 변경한 코드에 필요한 컴파일·테스트 범위를 구체적으로 지정할 수 있다. - 이 방식은 “변경 제안 → 실제 검증 → 실패 원인 반영”이라는 안정적인 자동화 패턴을 만든다. ## 개발자 주도 세션 - 엔지니어는 Nova 웹 UI에서 로컬 개발을 중단하지 않고 빠른 수정이나 프로토타입을 진행할 수 있다. - Bazel 선택성 도구와 검증 명령을 결합해 변경된 코드와 관련된 컴파일·테스트 대상만 검증할 수 있다. - Slack 대화에서 바로 Nova 세션을 시작하고 해당 스레드의 논의 내용을 컨텍스트로 전달할 수 있다. - 이를 통해 문제 설명이나 팀 내 논의를 에이전트 프롬프트에 수동으로 다시 작성하는 비용을 줄인다. ## Flaky test 자동 수정 - Nova의 대표적인 운영 자동화 사례는 flaky test remediation이다. - Dropbox의 flaky 테스트 탐지 시스템인 Athena와 내부 도구 Deflaker를 결합했다. - Deflaker의 흐름은 다음과 같다. - 테스트가 성공한 사례와 실패한 사례를 수집 - 관련 로그를 Nova에 컨텍스트로 전달 - 에이전트가 가능한 근본 원인을 분석 - 수정안을 제안 - 이는 단순 코드 생성보다 로그 분석, 증거 비교, 원인 추론이 중요한 장기 실행형 워크플로에 해당한다. ## 실용적인 시사점 코딩 에이전트를 도입할 때는 에디터 플러그인 하나를 추가하는 것보다 저장소, 빌드 시스템, 테스트 인프라, 로그와 컨텍스트를 연결하는 플랫폼 설계가 중요하다. 특히 에이전트의 결과를 실제 검증 명령으로 확인하고, 실패 결과를 다시 에이전트에 제공하는 반복 루프와 예측 가능한 브랜치·게시 정책을 갖추는 것이 안정적인 자동화의 핵심이다.

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

연구 파트너로서의 AI (새 탭에서 열림)

Google DeepMind는 LLM 기반 코딩 에이전트인 AlphaEvolve를 활용해 복잡도 이론(Complexity Theory)의 난제를 해결하고 새로운 수학적 구조를 발견하는 성과를 거두었습니다. 이 연구는 AI가 단순히 문제를 푸는 수준을 넘어, '리프팅(Lifting)' 기법을 통해 유한한 구조를 최적화함으로써 보편적인 수학적 정리를 증명하는 강력한 연구 파트너가 될 수 있음을 보여줍니다. 결과적으로 MAX-4-CUT 문제의 근사 난이도와 무작위 그래프 특성 인증 분야에서 기존 기록을 경신하며 이론 전산학의 지평을 넓혔습니다. ### AlphaEvolve의 반복적 진화 메커니즘 * AlphaEvolve는 Gemini와 같은 LLM을 기반으로 코드를 반복적으로 진화시키는 피드백 루프 시스템입니다. * 초기 코드 조각(Population)에서 시작하여 생성된 구조의 성능을 평가하고, 가장 우수한 코드를 LLM이 변형(Morph)하여 더 나은 솔루션을 찾아가는 과정을 반복합니다. * 수학 및 이론 전산학에서 요구되는 절대적인 정확성을 보장하기 위해, AI가 생성한 모든 수학적 구조는 인간의 개입 없이 컴퓨터 프로그램에 의해 자동으로 검증되도록 설계되었습니다. ### '리프팅(Lifting)'을 통한 유한 구조의 보편적 증명 확장 * AI는 특정 사례(유한한 구조)를 찾는 데 능숙하지만, 전산학 정리는 모든 문제 크기($\forall n$)에 대해 성립해야 한다는 간극이 존재합니다. * 연구진은 전체 증명 프레임워크 내에서 특정 부분(유한한 구조)만 AI로 최적화하고, 이를 다시 전체 증명에 결합하여 보편적인 결과로 확장하는 '리프팅' 기법을 도입했습니다. * 특히 기존에 연구자들이 수작업으로 설계하던 복잡한 '가젯 리덕션(Gadget reduction)'을 AlphaEvolve가 수행하게 함으로써, 인간이 발견하기 어려운 정교하고 효율적인 구조를 도출해냈습니다. ### 복잡도 이론에서의 주요 성과 * **MAX-4-CUT 문제의 한계 돌파:** 그래프의 노드를 4개의 집합으로 분할할 때 가로지르는 엣지를 최대화하는 문제에서, 기존 기록을 경신하는 새로운 근사 불가능성(Inapproximability) 하한선을 제시했습니다. * **무작위 그래프(Random Graphs) 인증:** 무작위 그래프의 특정 성질을 인증하는 데 필요한 '평균 사례 난이도(Average-case hardness)'의 경계를 더욱 정밀하게 좁히는 데 성공했습니다. * 이러한 성과들은 AI가 발견한 유한한 구조를 기존의 견고한 수학적 증명 체계에 성공적으로 통합할 수 있음을 입증합니다. 이 연구는 AI가 정교한 증명 요소를 생성하고 이를 시스템이 검증하는 협업 모델이 이론적 난제 해결에 실질적인 돌파구를 마련할 수 있음을 보여줍니다. 이론 전산학 연구자들은 앞으로 AI를 단순한 보조 도구가 아닌, 인간의 직관을 넘어서는 복잡한 증명 구조를 설계하고 최적화하는 핵심 연구 파트너로 활용할 수 있을 것입니다.