한 줄 요약: 긴 작업에서 에이전트의 성능을 결정하는 것은 모델 크기만이 아니라, 작업을 나누고 상태를 넘기고 평가를 분리하는 하네스 설계다.1
핵심 문제의식
장시간 실행되는 애플리케이션 개발은 단일 프롬프트와 단일 에이전트로 밀어붙이기 어려운 문제다. 초반에는 그럴듯하게 출발해도, 시간이 길어질수록 작업 초점이 흐려지고, 맥락이 뒤엉키고, 스스로 만든 결과를 지나치게 후하게 평가하는 문제가 겹친다.1
이 글이 중요한 이유는, 장시간 코딩을 단순히 "더 오래 생각하게 만들면 되는 문제"로 보지 않기 때문이다. 오히려 긴 작업을 다룰 수 있게 만드는 핵심은 모델 내부가 아니라 바깥의 운영 구조, 즉 어떤 단위로 나누고 어떤 상태를 남기며 어떤 기준으로 다시 평가하게 하느냐에 있다는 점을 분명히 보여준다.1
제품 개발 관점에서 보면 이건 더 큰 의미가 있다. 실제 서비스 개발은 정답이 뚜렷한 부분과, 취향과 품질 판단이 필요한 부분이 섞여 있다. 그래서 단순 생성 능력만으로는 부족하고, 생성과 검토를 분리한 체계가 필요하다.1
왜 순진한 에이전트 구현은 실패하는가
기존의 단순한 방식은 대체로 initializer가 작업을 나누고, coding agent가 하나씩 구현하는 구조다. 글에서 설명한 바에 따르면 이런 방식만으로도 기본 성능은 꽤 올라가지만, 복잡한 작업에서는 시간이 지날수록 에이전트가 일탈하는 문제가 남는다.1
첫 번째 문제는 긴 작업에서의 문맥 붕괴다. 컨텍스트 창이 차오르면 모델은 앞선 결정과 현재 작업의 연결을 느슨하게 유지하기 시작한다. 여기에 일부 모델은 스스로 한계에 가까워졌다고 느끼면 일을 마무리하려는 쪽으로 행동하는데, 글에서는 이를 context anxiety라고 부른다.1
이때 compaction과 context reset은 비슷해 보여도 다르다. compaction은 같은 세션을 유지한 채 이전 대화를 요약해 압축한다. 연속성은 남지만, 에이전트가 이미 느끼고 있는 압박감까지 지워주지는 못할 수 있다. 반면 context reset은 아예 새 세션으로 다시 시작한다. 깨끗한 출발점이라는 장점이 있지만, 이전 상태를 다음 에이전트가 이어받을 수 있도록 handoff를 정교하게 설계해야 한다.1
즉 compaction은 연속성을 사고, reset은 명료성을 산다. 문제는 reset이 공짜가 아니라는 점이다. orchestration 복잡도, 토큰 비용, 지연이 모두 늘어난다. 그래서 어떤 방식을 택할지는 모델 특성과 작업 길이에 따라 달라진다.1
두 번째 문제는 자기평가의 한계다. 에이전트는 자신이 만든 결과를 평가할 때 대체로 관대하다. 특히 디자인처럼 주관적 판단이 개입되는 과업에서는 이 문제가 더 두드러진다. 테스트가 통과했는지처럼 이진적으로 확인할 수 없는 영역에서는, "괜찮아 보인다"는 자기합리화가 쉽게 들어온다.1
그래서 generator와 evaluator를 분리하는 발상이 중요해진다. 글의 핵심은 평가자를 분리한다고 해서 자동으로 엄격해지는 것은 아니지만, 생성기가 스스로를 비판하게 만드는 것보다 별도 evaluator를 회의적으로 튜닝하는 편이 훨씬 현실적이라는 점이다. 실무적으로도 이는 구현과 리뷰를 같은 사람에게 맡기지 않는 이유와 닮아 있다.1
제안된 아키텍처 정리
프론트엔드 디자인에서는 generator-evaluator 루프가 중심이다. 생성기는 사용자 프롬프트를 바탕으로 UI를 만들고, 평가기는 실제 페이지를 살펴본 뒤 기준별 점수와 비평을 남긴다. 그 피드백이 다시 생성기로 들어가 다음 반복을 이끈다.1
여기서 흥미로운 점은 평가 기준이 단순 채점표가 아니라는 것이다. "좋은 취향"처럼 애매한 개념을, 설계 원칙으로 번역해 gradable한 대상으로 바꾼다. 결국 이 구조의 본질은 미적 판단을 완전히 수치화하는 데 있지 않고, 적어도 반복 개선이 가능한 형태로 바꾸는 데 있다.1
장시간 코딩으로 확장하면 구조는 planner-generator-evaluator의 3에이전트로 정리된다. planner는 짧은 사용자 프롬프트를 더 풍부한 product spec으로 확장한다. 이 역할은 단순 문서 정리가 아니라, 모호한 요구를 실행 가능한 제품 맥락으로 바꾸는 일에 가깝다. 생성기가 바로 코드부터 쓰기 시작하면 초반 방향 설정이 빈약해지기 쉬운데, planner는 그 빈칸을 메운다.1
generator는 실제 구현을 담당한다. 하지만 중요한 것은 혼자 일하지 않는다는 점이다. evaluator가 외부의 비판적 시선을 제공하고, planner가 상위 맥락을 제공하면서 generator를 중간층의 실행자로 위치시킨다. 이 구조는 사람 조직에서 제품 기획, 구현, 리뷰가 나뉘는 방식과도 자연스럽게 닮아 있다.1
structured artifact와 handoff는 이 전체 구조를 붙들어 주는 장치다. 긴 작업에서는 모든 것을 대화 히스토리에만 의존할 수 없다. 현재 상태, 다음 할 일, 의사결정 이유, 남은 리스크를 구조화해 넘겨야 세션이 바뀌거나 반복이 길어져도 작업이 이어진다. 결국 좋은 하네스는 "기억력 좋은 에이전트"를 기대하기보다, "잊어도 다시 복구 가능한 작업 체계"를 만든다.1
글에서 제시한 디자인 평가 기준 요약
글에서는 프론트엔드 디자인 평가를 네 가지 기준으로 정리한다. design quality는 화면이 조각난 결과물이 아니라 하나의 일관된 분위기와 정체성을 갖는지를 본다. originality는 템플릿이나 라이브러리 기본값을 벗어나 실제 선택과 해석이 들어갔는지를 본다. craft는 타이포그래피, 간격, 대비, 색 조화 같은 기본기를 본다. functionality는 미감과 별개로 사용자가 목적을 이해하고 행동을 완료할 수 있는지를 본다.1
가중치는 design quality와 originality에 더 실렸다. 이유도 분명하다. 글에서 설명한 바에 따르면 모델은 기본적으로 craft와 functionality에서는 이미 일정 수준을 내는 편이었다. 반면 결과물이 지나치게 무난하고, 어딘가 익숙한 "AI스러운 평균값"으로 수렴하는 것이 더 큰 문제였다. 그래서 좋은 결과를 얻으려면 안정성보다 개성과 완성도 쪽에 압력을 더 걸어야 했다.1
이 대목은 실무적으로 시사점이 크다. 평가 기준은 단지 측정 도구가 아니라, 시스템이 어디로 수렴할지를 결정하는 조향 장치다. 무엇을 강하게 벌점 주고 무엇을 크게 보상하느냐에 따라 산출물의 성격이 바뀐다.1
실무 적용 관점의 인사이트
장시간 실행 작업에서는 '더 큰 모델'보다 '더 나은 하네스'가 더 중요할 수 있다. 물론 모델 성능 차이는 크다. 하지만 글이 보여주는 변화는, 성능 향상의 상당 부분이 역할 분리, 반복 루프, 상태 전달, 평가 기준 설계 같은 바깥 구조에서 나왔다는 점이다.1
평가자 분리는 코드리뷰와 QA 자동화의 연장선으로 이해할 수 있다. 생성기는 빠르게 전진하는 데 강하고, 평가기는 멈춰 세워 문제를 드러내는 데 강하다. 둘을 같은 루프 안에 넣으면 단순 생성보다 훨씬 안정적인 개선 사이클이 생긴다.1
작업을 작은 단위로 쪼개고 상태를 명시적으로 넘기는 설계도 중요하다. 긴 세션에서 문제는 단순히 토큰 부족이 아니라, 의사결정의 맥락이 묻히는 것이다. 무엇을 왜 했는지, 다음에 무엇을 해야 하는지, 어떤 위험이 남아 있는지를 구조화해 남겨야 한다. 이는 사람 간 handoff 문서와도 같은 역할을 한다.1
주관적 품질도 평가 기준을 잘 만들면 개선 가능하다는 점도 실무에 유효하다. 디자인, 문서, 사용자 경험처럼 정답이 없는 영역은 자동화가 어렵다고 여겨지기 쉽다. 하지만 기준을 명확히 정의하고 evaluator를 그 기준에 맞춰 튜닝하면, 적어도 더 나은 방향으로 반복시키는 것은 가능하다.1
반복은 대체로 결과를 끌어올리지만, 항상 단조롭게 좋아지지는 않는다. 중간 결과가 최종 결과보다 나을 수도 있다. 이는 자동 반복을 설계할 때 "마지막 산출물이 최고"라고 가정하면 안 된다는 뜻이다. 중간 산출물 보존, 후보 비교, 사람의 선택 개입 지점이 여전히 필요하다.1
또 하나 주목할 점은 context reset의 필요성이 모델과 설정에 따라 달라진다는 점이다. 글에서는 일부 모델에서 reset이 핵심이었지만, 더 강한 모델과 설정에서는 연속 세션과 자동 compaction만으로도 가능성이 생겼다고 설명한다. 결국 하네스는 한 번 정하면 끝나는 정답이 아니라, 모델 특성에 맞춰 다시 조정해야 하는 운영 계층이다.1
내가 얻은 시사점
긴 작업일수록 프롬프트보다 운영 구조를 먼저 설계해야 한다.
생성과 평가는 분리할수록 개선 루프가 선명해진다.
컨텍스트는 많이 넣는 것보다, 필요한 상태를 구조화해 넘기는 편이 낫다.
주관적 품질도 좋은 평가 기준이 있으면 충분히 다룰 수 있다.
반복 횟수보다 각 반복에서 무엇을 학습해 다음 라운드에 반영하는지가 중요하다.
에이전트 시스템은 "한 번에 잘하기"보다 "틀려도 다시 바로잡기"에 최적화해야 한다.
결론
이 글은 장시간 실행 에이전트의 한계를 모델 자체의 지능 부족으로만 보지 않는다. 오히려 실패의 많은 부분이 문맥 관리, 역할 분리, 평가 체계 부재 같은 하네스 문제에서 나온다고 본다.1
그래서 실무에서 필요한 것은 만능 에이전트 한 명이 아니다. 일을 잘게 나누고, 상태를 분명히 남기고, 다른 시선으로 다시 검토하게 만드는 구조다. 긴 작업에서는 똑똑한 생성기보다, 흔들리지 않는 운영 체계가 더 큰 차이를 만든다.1
실무 체크리스트
장시간 작업을 한 세션에 몰아넣지 말고, 단계별 산출물과 handoff 포맷을 먼저 정의한다.
generator와 evaluator를 분리하고, evaluator는 의도적으로 더 비판적으로 튜닝한다.
compaction과 context reset을 모두 실험하되, 모델별로 어떤 방식이 더 안정적인지 검증한다.
planner를 두어 짧은 요구사항을 제품 스펙 수준으로 확장하게 만든다.
평가 기준은 기능성뿐 아니라 완성도와 독창성처럼 실제 품질 차이를 만드는 항목까지 포함한다.
마지막 결과만 저장하지 말고, 중간 반복 산출물도 비교 가능하게 보존한다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.