코드 자동완성이 에이전트 코딩으로, 다시 에이전트를 관리하는 '하네스(harness)'로 넘어오는 데 채 18개월이 걸리지 않았다. 이 글의 저자는 그 흐름 위에서 한 가지 결론에 도달한다. 모델 자체는 빠르게 상품화(commodity)되고 있으며, 이제 일과 지렛대는 스킬·확장·스크립트로 조작 가능한 앱을 묶은 하네스에 있다는 것이다. 특정 모델의 '마법 같은 비결'을 좇는 대신, 모델이 무엇으로 바뀌든 흔들리지 않는 자기만의 작업 구조를 갖추는 쪽이 생산성의 축이 된다는 관점이다.
저자의 작업 환경은 Cursor, Claude, 그리고 Pi 세 개의 TUI로 구성되지만, 이들은 모두 동일한 스킬 세트와 AGENTS.md를 공유한다. 인터페이스는 셋이어도 경험은 하나로 통합돼 있어, 이달 말 Cursor에서 Codex로 갈아타는 전환에도 별다른 불안이 없다고 말한다. 도구가 바뀌어도 하네스가 그대로 남기 때문에 모델은 그에게 이미 '교체 가능한 부품'이 된 셈이다.
계획·실행·비평을 분리하는 워크플로
하네스의 핵심에는 역할 분리가 있다. 하나의 프롬프트가 계획하고 실행하고 스스로를 비평하게 하면 목표가 뒤엉키기 때문에, 저자는 planner·worker·critic을 각각 격리한다. 여기에 Can Bölük의 'prewalk' 기법을 결합했다. 계획 단계와 첫 작업만 프런티어 모델로 처리해 패턴을 잡은 뒤, 나머지는 더 저렴한 모델에 넘기는 방식이다. 탐색은 명시적인 DAG(방향성 비순환 그래프) 작업 목록으로 정형화되고, worker가 노드를 하나씩 구현한다. 이어 critic이 결과를 단순화하고 되묻는데, 이 단계에서 반발이 충분히 크면 worker 단계로 되돌아간다. 만족스러워지면 critic은 promoter로 넘어간다. 만들고 나서 바로 다음으로 넘어가려는 습관을 보완하기 위해, '완성은 남에게 제대로 알려야 끝난다'는 리마인더를 절차에 박아 넣은 것이다.
효과는 수치로 나타난다. 가장 강도 높은 작업에서도 프런티어 모델 의존도가 75% 줄었고, 20달러짜리 구독 두 개에 필요할 때만 Pi를 얹는 구성으로 클라이언트 업무와 개인 프로젝트를 동시에 굴린다고 한다. 유지보수와 단순 작업은 저렴한 모델에 맡기고, 움직이는 부품이 많은 대형 리팩터링이나 진지한 기능 탐색에서만 프런티어를 꺼내는 식이다.
앱을 하네스에 연결한다는 것
저자의 제품은 사진 한 장을 값 레이어와 도형으로 단순화해 벡터 그래픽으로 바꿔주는 카메라 앱이다. 해상도를 낮추고 디테일을 걷어내되 맥락은 남겨, 인쇄해 위에 그리거나 Procreate로 불러와 레이어 안에서 그릴 수 있게 한다. 흥미로운 지점은 poster-driver라는 도구로 이 라이브 사이트를 헤드리스 크롬에서 구동한다는 것이다. 웹페이지를 여는 것만큼 쉽게 앱을 스크립트로 조작할 수 있게 되면서, 예전엔 어설픈 우회책밖에 없던 고급 활용이 실제로 가능해졌다. LLM이 작성해준 스크립트를 하네스에 보관해 두면 토큰을 태우지 않고 반복 실행할 수 있다. 앱이 하네스에 '도달 가능'해지자 도구 자체가 더 강력해진 것이다.
감사가능성(auditability)도 설계의 중심에 있다. TUI들은 결과물을 artifacts/ 디렉터리 안에 두도록 지시받고, Cursor가 .gitignore로 파일을 관리하는 방식 때문에 루트는 git이 없는 상태로 유지된다. 스킬·확장·AGENTS.md는 루트의 1급 시민으로 언제든 수정·확장되며, TUI는 그 규칙에 맞춰 움직여야 한다. 저자는 nvim 설정까지 작업 디렉터리에 매핑해, LLM이 지금 열려 있는 파일을 알고 함께 편집하도록 만들었다. 그는 이를 '지그(jig)로서의 하네스'라 부른다.
한계와 실무적 함의
이 글은 검증된 벤치마크가 아니라 한 개발자의 개인 경험담이라는 점을 감안해야 한다. 등장하는 모델명이나 정부의 'Fable' 금지 조치, 그로 인해 개발자들이 중국산 모델과 Pi로 다변화했다는 서술은 저자의 관점과 특정 시점의 상황일 뿐, 일반화된 사실로 받아들이기는 어렵다. 저자 스스로도 초기에는 스킬을 지나치게 세세하게 규정하다 토큰을 낭비했고, 앞으로는 변화의 효과를 경험적으로 확인하는 접근이 필요하다고 인정한다.
그럼에도 한국 실무자에게 남는 시사점은 분명하다. 특정 벤더나 모델에 종속되지 않으려면, 값어치는 프롬프트 한 줄이 아니라 재사용 가능한 스킬·워크플로·연결 스크립트라는 자산에 쌓아야 한다. 역할을 분리하고, 비싼 모델은 계획과 첫 수립에만 쓰며, 결과물을 감사 가능한 구조 안에 가두는 방식은 팀 규모와 무관하게 검토해볼 만한 설계 원칙이다. 모델이 흔해질수록, 그것을 어떻게 엮어 쓰느냐가 실력의 차이를 만든다.