하네스 엔지니어링, 자율주행 코딩, Pencil.dev

지난주에 심포니를 보고 난 뒤, 이번 주는 내내 오케스트레이션과 하네스를 깎았다. 에이전트에게 코드를 짜게 하고 그게 잘 돌아가는지 멍때리면서 보고, 문제가 생기면 고치고, 다시 돌리는 것의 반복이다.

Anthropic 엔지니어링 블로그에 “Harness design for long-running application development” 라는 글이 하나 올라와서 살펴봤다.

클로드 팀이 한 것과 내가 한 작업들 비교도 해보고, 지난 블로그 작성 이후 했던 일들도 적어본다.

오케스트레이터와 워크플로우

이전 글에서 소개한 워크플로우(이슈 생성 -> 개발 -> 리뷰 -> QA -> 완료)를 실행하는 파이썬 오케스트레이터를 만들었다.

처음에는 에이전트에게 오케스트레이션을 맡겼으나, 클로드가 서브에이전트를 호출하는데 뎁스 리밋이 있어서 프로세스 하나가 오케스트레이션을 하게 했다.

뎁스 리밋이 있으니 코덱스를 서브에이전트로 사용할 수도 있었으나, 카톡 GPT Pro 구독이 끝나기도 했고, 아무래도 오케스트레이터도 AI로 두면 할루시네이션 이슈가 있을 것으로 생각되어 메인 오케스트레이터는 파이썬으로 짰다. 얘는 거의 그냥 파일과 프롬프트 넘겨서 커스텀 에이전트 생성하고, 끝날때까지 기다리고 다음꺼 호출하고 이런 정도다.(과거의 나)

구조는 이렇다. 워커(오케스트레이터)가 에이전트에 대한 상태 관리, 검증, 커밋을 하고, 실제 에이전트 작업은 claude -p 서브프로세스로 넘긴다.

크게 세 단계(plan, execute, review)를 반복하면서 Wave(작업 단위, 스프린트와 비슷)를 하나씩 소화한다.

plan 단계에서는 에이전트가 코드베이스를 탐색하고 재사용 가능한 코드를 파악한 뒤, 구현 스펙과 태스크를 생성한다. 이때 기존 코드를 무시하고 새로 만드는 걸 구조적으로 막기 위해 재사용 후보를 3개 이상 찾도록 강제한다. 우리의 경우는 이미 만들어진 프로덕트가 있기 때문이고 웬만한 디자인 시스템은 다 거기서 커버가 된다. 플랜 단계 잘 하기 위한 인덱싱된 문서도 읽게 한다.

execute 단계에서는 실제 구현을 한다. 에이전트가 코드를 짜고, 테스트를 돌리고, 브라우저 QA까지 한다. QA는 최대 5회까지 루프를 돌면서, 같은 시나리오가 3번 실패하면 known issue로 분류하고 넘어간다. feature-dev 스킬과 gstack 의 browser-qa 를 내부적으로 사용한다.

review 단계에서는 별도의 에이전트가 구현 결과를 채점한다. 100점 만점에 5개 하위 점수(계획 완성도, 재사용 검증, 디자인 충실도, 코드 품질, 테스트 커버리지)로 나뉘고, 75점 이상이면 통과, 60점 미만이거나 blocker가 있으면 execute를 재실행한다.

이걸 자동으로 돌려놓으면, 내가 자는 동안에도 에이전트가 계속 코드를 짠다. 일종의 방치형 게임 같은 느낌인데, 아침에 일어나서 뭔가 쌓여 있고 커밋도 쌓여있는거 보는 재미가 있다.(근데 죽어있으면 화남)

200달러 기준 5시간이면 40%정도? 사용한다. 적절히 소넷도 쓰고 최적화를 해놔서 생각보단 많이 안쓴다. 지금 2배 이벤트라서 그럴지도 모르겠다.

Anthropic 방식과 공통점

읽으면서 비슷하다고 느낀 지점들이 꽤 있었다.

우선 Anthropic 에서 소개된 작업 방식도 같은 구조다. Planner가 한 줄짜리 프롬프트를 풀 스펙으로 확장하고, Generator가 스프린트 단위로 구현하고, Evaluator가 Playwright MCP로 실제 앱을 클릭하면서 검증한다.

사실 다 비슷한 것 같다. GSD, 심포니, omc 등등 다 애초에 하네스 엔지니어링이 다 비슷비슷하다. 아무래도 현실의 개발조직을 모방하려다보니 유사해진게 아닐까? 이미 수십년간 최적화된 업무방식과 조직구조가 있으니?

1. 큰 틀이 플래닝 → 구현 → 평가로 동일하다. 나는 plan/execute/review 로 나눴고, 이쪽은 planner/generator/evaluator 로 나눔.
2. 에이전트 간 커뮤니케이션을 파일 기반으로 한다. 한 에이전트가 파일을 쓰면 다른 에이전트가 읽고 응답하는 방식. 나도 impl-spec, tasks.md, agent-log 같은 파일로 stage 간 맥락을 전달한다. 최대한 많은 로그를 남겨야 에이전트가 헛짓을 했는지 잘 했는지를 나중에 파악할 수 있기 때문.
3. 스프린트 단위로 스펙에서 기능을 하나씩 픽업하는 것, 기준 미달 시 재실행하는 것, QA를 브라우저 레벨에서 자동화하려는 시도도 다 동일하다.

겪었던 이슈들과 커스터마이징 등

필요에 의해 만든 것들이 있다. 이미 돌아가고 있는 프로덕션 수준의 앱 위에다 에이전트로 개발하려다 보니 자연스럽게 생긴 것들. 여러 삽질들도 있다.

1. 모니터링 대시보드: 에이전트가 백그라운드에서 돌아가다 보니 진행 상태를 한눈에 보는 게 중요했다. 각 wave의 진행률, QA 에이전트가 찍은 스크린샷, 현재 어떤 stage에 있는지 등을 시각화해서 보여준다. 다른 팀들에서도 비슷한 대시보드를 만들었다는 걸 봤는데, 확실히 모니터링이 눈으로 되면 편하다.

진행상황 보여주는 대시보드. 에이전트가 QA하면서 찍은 사진들도 보여준다.

[embed]

[embed]

2. 로깅과 교차검증. 에이전트의 말을 믿으면 안 된다는 걸 여러 번 겪었다. 안해놓고 했다고 하고 자기가 짠 코드는 후하게 점수를 준다(클로드 팀도 똑같이 겪었다고..) 그래서 에이전트의 실제 스킬이나 툴 호출 로그나 에이전트가 스스로 작성한 보고서를 다른 에이전트가 대조하는 교차검증 시스템을 넣었다. 원래는 코덱스를 쓰게 했지만, 코덱스 20달러짜리는 금방 다 써버려서 그냥 오푸스 두 개 띄워서 비교하라고 했다.

3. 중간 개입 시스템: 파이프라인이 돌아가는 중에 내가 끼어들 수 있어야 했다. 예를 들어 자고 일어났는데 에이전트가 이상한 방향으로 구현하고 있으면 작업 큐에 방향 지시(directive)나 코드 패치(patch)를 넣어놓는다. 그러면 다음 wave 시작 전에 우선순위를 자동으로 조정한다. 파이프라인을 멈추고 수동으로 고치게 되면 아무래도 전체 작업 로그가 깨지다보니까 이렇게 함.

4. 프로세스 관리: 생각보다 인프라 관련 버그들이 많았다. 서브프로세스가 테스트 프로세스를 실행시켰는데 죽이질 않아서 메모리가 누적되는 문제, CI에서 린트가 실패하면 파이프라인 전체가 죽는 문제, 진행 상태를 기록하는 JSON 파일을 엉뚱하게 만들어서 파이프라인이 멈추는 문제 등등. 이런걸 중간중간 관찰하며 고쳤다.

5. 작업 단위 쪼개기: 에이전트가 한 번에 개발할 수 있는 범위를 의도적으로 작게 잡았다. 모달 창 하나, 컴포넌트 두세 개 정도? 너무 크면 컨텍스트 리밋으로 망가지고, 너무 작으면 리뷰 단계에서 시간을 많이 잡아먹는다. 지금은 하나당 15~20분 정도 소요되고 있다.

6. 자라는 시드데이터: 개발이 진행될수록 QA에 필요한 데이터들이 늘어난다. 이것도 같이 발맞춰서 업데이트 해줘야 한다. 프로세스에 명시해서 QA에 활용할 수 있게 했음.

프론트엔드 디자인(Pencil dev)

클로드 블로그에서도 프론트엔드 디자인이 별도 주제로 다뤄졌는데, 나도 여기서 비슷한 고민을 하고 다른 방식으로 해결을 했다.

에이전트한테 구현을 시키면 기능적으로는 작동하는데, 생긴 게 못생긴 경우가 많다. 캡쳐해서 레퍼런스 이미지를 넣으면 훨씬 잘 만드는데, 맨땅에서 만들면 이상하게 나온다. 디자이너가 있었으면 초안을 받아서 작업을 시켰을 텐데 없으니까 그 역할을 할 AI를 찾아야 했다.

클로드 팀은 이걸 채점 기준(디자인 품질, 독창성, 기술적 완성도, 기능성)을 만들고 Generator-Evaluator 루프를 돌려서 해결했다. Playwright MCP로 실제 페이지를 보면서 채점하고, 점수가 안 나오면 아예 다른 디자인으로 전환하게 했다.

나는 pencil.dev 라는 AI 디자인 도구로 이 과정을 대신했다. 처음에는 구글 Stitch가 새롭게 나왔다길래 써봤는데 그지같았고 pencil.dev를 써보고 나서는 여기에 정착했다. 레퍼런스를 넣었을 때 반영하는 능력이 좋았고, 편집도 편했다(내가 하는건 아니지만 특정 컴포넌트들 선택 후 바로바로 명령 가능).

클로드 팀도, 나도 “taste를 어떻게 다룰 것인가” 라는게 공통으로 겪은 문제. 이쪽은 오케스트레이션으로 풀었고, 나는 별도의 디자인 도구로 풀었다. 결국 사람의 테이스트를 어딘가에서 주입해야 한다는 건 동일함.

참고로 내가 만드는 앱도 디자인할 화면이 굉장히 많다 보니, 이 디자인 작업 자체에도 일종의 워크플로우를 만들었다. 도메인 영역을 쪼개고, 각 영역별로 디자인을 생성하고, 시나리오 중심 리뷰와 화면별 리뷰를 따로 돌리는 식이다.(대신 pencil.dev 가 토큰을 무지막지하게 먹음)

하네스 엔지니어링은 사라질까?

프롬프트 엔지니어링이라는 게 한 2년 전에 되게 많이 쓰였는데, 지금은 거의 못본 것 같다. 많이 추상화되기도 했고, 스킬 같은 컨셉 덕분에 다른 사람이 만든걸 그냥 그대로 갖다 쓰기 쉬워지기도 하고, 이런거 없이도 잘 작동하는 부분도 있다.

옛날에 n8n 같은거로 해야 하던 일들도 모델이 발전하면서 상당 부분 사라졌다. 대표적인게 글쓰기? 컨텍스트 윈도우가 대폭 늘어나니 간단한 글은 굳이 리서쳐 목차 등등을 나누지 않아도 혼자 잘 쓴다. 알아서 에이전트도 잘 호출하기도 하고.

이런 맥락에서 하네스 엔지니어링도 언젠가 클로드나 코덱스에서 그냥 제품으로 내장시켜 버리거나 그냥 이 컨셉 자체가 없어질 수도 있겠다 싶었다. 이미 자기들 블로그에 쓰고 있는걸 보면 제품으로 나오는게 얼마 안남은 것 같기도 하다.

근데 또 보면 블로그에서 “From this work, my conviction is that the space of interesting harness combinations doesn’t shrink as models improve. Instead, it moves, and the interesting work for AI engineers is to keep finding the next novel combination.”. 라고 한다.

컨텍스트 엔지니어링을 봐도, 프롬프트를 잘 넣는 것의 중요성 자체는 변하지 않았고, 단지 이름이 바뀌고 범위가 확장됐을 뿐이다. 하네스 엔지니어링도 추상화될 순 있겠지만, AI가 일을 잘 할 수 있도록 구조를 짜는 건 본질적으로 중요한 것이고 사라지지 않을 것.

다만 개인의 입장에서는 이걸 내가 제품 만들면서 달리면서 하냐, 아니면 좀 기다리다 이들이 내는걸 쓰냐 이 차이? 하네스를 깎다 보면 동시에 현실적인 기회비용 계산도 하게 된다. 하네스를 깎아서 AI가 일 시키게 하는데쓴 시간에 그냥 내가 직접 개발했으면 더 빨랐을 수도 있기 때문이다. 스킬만 봐도 내가 열심히 만들기보다 좀 기다리면 gstack 이나 omc 같은 오픈소스 개발자분들이 만든게 우후죽순 나오니까..

에이전트 워크플로우 자동화를 국내외 많은 회사들이 하고있고 오픈소스들도 많이 나오는걸 보면, 잠깐의 트렌드는 아닌 것 같다. 다만 내가 바퀴를 만들면서 가냐, 아니면 안만들고 할거 하다가 나오는거 보고 쓰냐의 차이?

물론 이번에 GSD나 OMC같은게 이미 있음에도 내가 직접 깎은건 이미 우리 레포에 맞게 최적화된 커맨드나 스킬, 프로세스가 있었기 때문. 지난 글에서 소개했듯 이미 잘 쓰던 스킬이 있었기에 조합만 잘 하면 됐었다.

내가 자고 있는 동안에도 작업이 쌓인다는게 뭔가 방치형 게임 하는 재미가 있다 ㅋㅋ.. 엉망으로 쌓이면 화만 나겠지만, 스크린샷으로 QA 잘 시키니까 꽤 잘짠다.

그리고 클로드 200불짜리 토큰을 많이 쓰기가 쉽지 않은데, 이거로 녹이고 있으면 뭔가 뽕 뽑은 것 같아서 좋다.

References

[embed]Harness design for long-running application development Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI…www.anthropic.com

[embed]Effective harnesses for long-running agents Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI…www.anthropic.com

[embed]Pencil - Design on canvas. Land in code. Pencil fundamentally increases your engineering speed by bringing designing directly into your preferred IDE.pencil.dev