Skip to main content

에이전트 코딩, 혼자 해야 할 일이지만 여럿이 해야 한다면...

· 9 min read
summerz
summerz

요즘은 코드를 직접 치는 시간보다 에이전트에게 시키고 결과를 보는 시간이 더 길죠. 혼자 할 때는 그럭저럭 굴러가는데, 사람이 여럿 붙으면 이야기가 달라지죠. 누가 뭘 승인하고, 어디까지 사람이 읽고, 어긋난 건 어떻게 잡을 것인가. 차라리 혼자 하는 게 더 빠른데, 여럿이 해야 하는 일이 있기도 하고... 남들은 어떻게 했는지 과거 자료를 좀 뒤져봤습니다. 즉, 처음 팀 작업을 한다고 생각하고, 그럴 때 발생하는 고민들과 해결점을 찾아본 거죠.

모아놓고 보니 제일 오래된 게 작년 3월 글이고, 제일 최근 게 한 달 전입니다. 1년 반이면 모든 게 뒤바뀌는 분야인지라, 여기 나오는 걸 지금의 최신 방법론이라고 부르긴 어렵고 이름 변경은 고사하고 아예 폐기되다 싶은 것들도 있고요. 그래도 사람들이 어디쯤에서 넘어졌는지는 그대로 남아 있어서, 저는 그 부분을 보려고 읽었습니다.

읽다 보니 공통점이 하나 있더군요. 잘 굴러간다는 팀들이 손본 건 프롬프트 쪽이 아니었습니다. 일의 순서하고 검증 방법을 바꾼 거죠.

사람의 일이 옮겨간다​

가장 극단적인 사례는 올해 2월에 OpenAI 내부 팀이 공개한 Harness engineering입니다. 어떤 베타 제품을 5개월간 만들면서 사람이 손으로 쓴 코드가 0줄이었고, 앱 코드, 테스트, CI, 문서, 리뷰 응답까지 전부 에이전트가 썼고 PR을 열고 병합하는 것까지 시켰다고 합니다.

그럼 사람은 뭘 했느냐. 우선순위를 정하고, 사용자 피드백을 수용 기준(acceptance criteria)으로 바꿔내고, 결과를 판정했습니다. 그리고 하나 더. 실패했을 때 그 원인을 도구/가드레일/문서가 부족한 것으로 판단하고 그걸 되돌려 고쳤습니다. 저는 이 마지막 항목이 핵심이라고 보긴 했어요. 에이전트가 틀렸을 때 "다시 해줘"로 때우면 다음 주에 같은 자리에서 또 틀리거든요. 하지만, 이건 토큰을 마음껏 쓸 수 있는 곳에서나 할 수 있는 작업이 아닌가 싶기도 하고...

여기에 딴지를 거는 쪽도 있는데 이것도 일리가 있습니다. Simon Willison은 코딩 에이전트에겐 숙련된 개인이 필요하다고 썼어요. 명확한 과제를 낼 만큼 도메인과 도구를 아는 사람, 결과가 마음에 안 들 때 어디를 어떻게 다시 시킬지 아는 사람이 있어야 한다는 겁니다. 작년 6월 글이니 그 사이 모델은 몇 세대 지났는데, 지적은 아직 안 낡은 것 같고요.

두 이야기가 충돌하는 것 같은데, 같이 놓고 보면 낮아진 건 만드는 쪽 문턱뿐입니다. 다 된 게 맞는지 판정하는 사람의 역량은 여전히 대체가 안 되는 것 같아요.

코드보다 계획을 먼저 본다​

여기저기서 반복해서 나오는 패턴은 역시 스펙 주도 개발 (spec-driven development). 작년 9월에 나온 GitHub의 Spec Kit은 specify → plan → tasks → implement → verify 순서를 단계별 체크포인트로 두자고 합니다. 사람은 사용자 여정과 성공 조건, 스택과 제약을 넣고 에이전트가 명세/계획/작업 분해/코드를 만드는 식이죠. 여기서 명세는 개발 끝나고 쓰는 문서가 아니라 검증의 기준점입니다. 뭐 요즘은 많이들 하는 방식이긴 하죠.

Kiro는 요구사항/설계/작업을 아예 따로 떼어서 각각 승인 가능한 산출물로 만듭니다. 이것도 작년 7월 제품 소개라 효과 주장을 그대로 믿을 건 아니지만, 발상 자체는 가져올 만합니다.

실제로 써본 관찰도 있습니다. Thoughtworks의 Technology Radar Vol.34에서 여러 팀이 Spec Kit을 주로 기존 시스템(brownfield)에 시험했는데, 구현 전에 숨은 가정과 제약이 드러나더라는 겁니다. 코드 리뷰에서 발견하면 이미 늦은 것들이죠.

기존 코드를 고치는 경우라면 명세에 이 세 칸만 있어도 될 것 같습니다.

  • 바꿀 동작
  • 절대 바꾸지 않을 동작
  • 검증 명령

두 번째 칸이 제일 중요해 보여요. 바꿀 것만 적어두면, 그 주변을 어디까지 건드려도 되는지는 에이전트가 알아서 판단하게 되니까요.

그런데, 이게 규칙을 강화할수록 생산성은 낮아지고 토큰과 시간은 무지막지하게 소비되는, 그런 트레이드오프가 있긴 하죠.

긴 지시문은 생각보다 힘이 없다​

이 대목이 제일 뜨끔했습니다. 저도 CLAUDE.md를 적다 보면 금방 길어지거든요.

OpenAI 팀은 문서만으로는 에이전트가 만든 코드베이스의 일관성을 유지할 수 없다고 결론 내렸습니다. 한동안은 금요일마다 손으로 AI가 어질러 놓은 걸 치웠는데, 그게 주당 20%였다고 해요. 나흘 일하고 하루 치우는 셈이죠.

그래서 한 게 문서의 지시를 실행 규칙으로 승격시키는 거였습니다. 도메인을 고정된 레이어로 나누고 허용된 의존 방향을 커스텀 lint와 구조 테스트로 강제했어요. 로깅 방식, 스키마/타입 명명, 파일 크기 같은 것도 lint로 검사합니다. 재미있는 디테일 하나는 lint 오류 메시지 안에 에이전트가 읽을 수정 지시를 넣었다는 겁니다. 문서에 적어두고 읽어주길 바라는 대신, 틀린 순간에 손에 쥐여주는 거죠.

Thoughtworks 쪽에서도 같은 맥락의 관찰이 나옵니다. 지시문이 비대해지면(instruction bloat) 오히려 맥락이 썩는다(context rot)고요. 한 팀은 재사용 지침을 skill로 빼서 기본 지시문을 얇게 유지했답니다.

그러니 CLAUDE.md나 AGENTS.md에는 탐색 지도, 금지 사항, 검증 명령 정도만 남기고 긴 절차는 필요할 때 불러오는 쪽이 낫겠네요. 그리고 같은 지적이 두 번 나온 규칙만 CI 실패 조건으로 올리는 걸로. 한 번은 그냥 넘어가고요.

첫 달에 CI 실패 조건을 세 개쯤으로 시작하는 게 적당해 보입니다. 레이어 역방향 import 금지, 공개 API 테스트, 포맷/타입 검사. 사람 리뷰에서 반복된 지적만 하나씩 늘려가면 되겠죠.

아마 이게 팀원이 많을수록 효과가 크지 않을까 추측해봅니다. 힘이 없는 문서를 읽는 횟수가 많아지면 사람들은 점점 효과가 있으리라 생각하고, 에이전트는 그 기대를 무시할테니 괴리가 더욱 크게 보일 것 같아요.

그럼 사람은 코드를 안 읽어도 되나​

여기서 제일 과감한 사례가 하나 나옵니다. 71만 줄짜리 TypeScript 시스템에서 189개 파일을 리팩터링한 케이스 스터디인데요. 명세를 14번 다듬어 동결한 뒤 구현하고, 그 고정 명세에 대해 17번 검증하고, 31번의 감사에서 201개 결함을 고쳤습니다. 두 번 연속으로 지적 사항이 0이 나오면 끝난 걸로 쳤고요. 사람은 생성된 코드를 읽지 않았습니다. 3일간 2,430달러를 썼다고 합니다.

그나마 이게 이 글에서는 제일 최근 자료인데(한 달 전), 단일 저자의 자기 보고에 사전공개본이라 그대로 믿고 정책을 세울 근거는 아닙니다. 다만 짚어둘 건, 사람이 코드를 안 읽는 쪽으로 간 사례들은 하나같이 그 대가로 어마어마한 자동 검증을 깔았다는 점이에요. (그리고 그만큼 비용도...) OpenAI 팀도 PR 수명을 짧게 가져가고 병합 게이트를 최소화했지만, 그 전제는 상시 자동 테스트와 저장소 자체의 지식화였다고 하죠.

그러니 "사람이 코드를 안 읽는 것"을 목표로 삼는 건 순서가 거꾸로인 것 같습니다. 저라면 기본값은 사람이 PR을 읽는 걸로 두겠어요. 저위험이고, CI 통과했고, 테스트가 붙었고, 데모까지 있는 PR. 이 네 개를 다 만족할 때만 자동 병합 후보로 좁히고요. 대신 구현 전에 계획 리뷰를 15분 넣어서 API/데이터 변경, 실패와 롤백, 테스트 시나리오 정도만 보는 게 남는 장사일 것 같습니다.

아니면 최소한 에이전트가 코드를 마구 고쳐댈 때 눈에 힘을 빡 주고 모니터를 바라보는 겁니다. 뭘 고치고 있는지, 내 생각과 방향이 다르면 바로 esc 키를 눌러서 불러 세우는 거죠. 코드를 다 안 읽더라도 이 정도만 해도 효과가 아주 큰데, 결국 이것도 인간의 판단력이 병목이라...

주니어는 뭘 배워야 하나​

Addy Osmani가 이 글에서 주니어에게 필요한 기초 역량으로 시스템 설계, 엣지 케이스, 테스트, 디버깅을 꼽습니다. 프롬프트를 잘 쓰는 능력이 아니라요. AI가 만든 코드를 이해하고 개선하고, 엄격한 테스트로 신뢰를 쌓는 쪽으로 가야 한다는 거죠. 작년 3월 글이라 오래된 글이라 그런 건 안 중요하다고 하는 사람들도 많을 것 같기도 합니다.

Kent Beck의 구분도 유용했습니다. augmented coding은 빠른 탐색을 할 수 있고 좋은 설계를 발견할 수 있게 한다는 겁니다. 가설을 빨리 던져보는 단계 말이죠. 반대로 예측 가능성과 정확성이 중요한 단계는 여전히 사람 판단이 필요하고요.

그래서 주니어에게는 프로토타입을 실컷 만들게 하되, 만들면서 왜 이렇게 코딩(명령)했는지, 작성한 코드가 깨지는 경우를 찾을 수 있는지, 작성한 테스트에서 누락된 위험을 찾을 수 있는지를 훈련하면 어떨까 싶더라고요.

돈 이야기​

이건 짧게. Anthropic 문서의 비용 관리 쪽을 보면 작게 시작해서 기준선을 만든 뒤 늘리라고 합니다. 공개된 엔터프라이즈 평균이 활성 개발자당 하루 13달러, 월 150~250달러쯤 된다는데(90%는 하루 30달러 미만), 코드베이스와 모델과 동시에 돌리는 인스턴스 수에 따라 크게 달라져서 작은 팀의 견적으로 쓸 숫자는 아닙니다. 가격 정책 자체도 자주 바뀌고요.

좌석 가격 하나로 예산을 잡으면 안 된다는 게 요지예요. 동시 에이전트 수, 컨텍스트 크기, 백그라운드 작업, 모델 선택이 다 비용입니다. 2주쯤 사람별/작업 유형별로 비용과 성공률을 기록해 보고, 탐색/구현/자동화 정도로 태그를 나눠 보면 다음 달 결정이 쉬워지겠죠.

적고 보니, 공통적인 특징이 보입니다. 에이전트 성능이 좋아질수록 사람이 할 일은 전처리 쪽으로 가는 것 같아요. 코드를 쓰던 자리에서 무엇이 완료인지 정하는 자리로 옮겨가고, 틀린 걸 지적하던 자리에서 애초에 틀릴 수 없게 만드는 자리로 옮겨갑니다.

경험이 없는 작은 팀이라면 이 순서로 시작하면 될 것 같습니다.

  1. 기능마다 한 장짜리 명세. 바꿀 동작, 안 바꿀 동작, 검증 명령.
  2. 구현 전 15분 계획 승인.
  3. CI 실패 조건 세 개로 시작해서, 반복되는 지적만 규칙으로 승격.
  4. 저위험 PR만 자동 병합 후보. 나머지는 사람이 읽고 판단.
  5. 2주간 비용 기록 후 팀 상한 정하기.

읽으면서 계속 든 생각은, 이게 다 새로운 이야기가 아니라는 겁니다. 명세를 먼저 쓰고, 규칙을 자동화하고, 검증을 CI에 넣는 건 원래 하면 좋다고들 하던 것들이죠. 안 해도 그럭저럭 굴러갔으니까 미뤘던 거고요. 에이전트가 생산 속도를 올려놓으니까 미뤄둔 청구서가 한꺼번에 날아온 느낌입니다.

그리고 이 글들이 쓰인 뒤로도 도구는 계속 바뀌었으니, 지금은 더 나은 방법이 나와 있을 겁니다. 다만 막상 개발 능력과 분야가 다른 사람들이 각자 에이전트 하나씩 끼고 모여 앉아 하나의 프로젝트를 완성하려고 들려고 하니, 방법론들을 다시 살펴봤습니다.

참고한 글들입니다.