출시는 싸요. 방향성은 비싸요.

코딩 에이전트는 ‘출시’를 엄청 싸게 느끼게 만들었습니다.

기능을 한두 단락으로 설명하면 PR이 나오고 커피가 식기 전에 머지까지 갑니다. 엔드투엔드로 제품을 만드는 프로덕트 엔지니어 입장에서는 솔직히 짜릿합니다.

그런데 속도가 빨라졌다고 해서 진짜 진전(progress)까지 싸진 건 아닙니다. 오히려 반대인 경우가 많습니다.

코드는 싸졌지만 출시가 치러야 할 대가는 싸지지 않았습니다. 방향성, 사용자 이해, 장기적인 일관성처럼 원래 비쌌던 부분을 에이전트가 더 자주, 더 빨리 흔들어놓기 때문입니다.

출시는 싸지만 제품 방향성은 비쌉니다

예전에는 출시가 엔지니어링 시간에 묶여 있었습니다. 설정 몇 개를 ‘그냥’ 추가하거나, UI 카피를 크게 바꾸거나, 워크플로우를 매일 리팩토링하는 건 현실적으로 쉽지 않았습니다.

지금은 가능합니다. 에이전트가 구현 비용을 워낙 강하게 눌러버려서 “일단 출시하자”가 기본 자세가 되기 쉽습니다.

하지만 출시는 중립적인 행동이 아닙니다. 한 번 출시할 때마다 최소한 세 가지 비싼 일이 벌어집니다.

  1. 방향을 고정합니다. 프로덕션에 나가면 “이걸 만들까?”가 아니라 “이걸 어떻게 덜 별로 만들까?”로 질문이 바뀝니다. 로드맵도 조용히 ‘발견과 탐색’에서 ‘수습과 정리’로 넘어갑니다.

  2. 기대를 고정합니다. 사용자는 제품의 정상 동작을 즉시 새로 익히기 때문에 작은 변화도 하나의 계약이 됩니다. 나중에 또 바꾸면 우리는 코드만 바꾸는 게 아니라 사람들 머릿속의 모델까지 옮겨놓게 됩니다.

  3. 혼란이 누적됩니다. 혼란은 버그 하나가 아니고 엔트로피입니다. 설정 하나 더, 예외 경로 하나 더, 비슷한 기능 하나 더… 이런 것들이 쌓이면 제품은 기능적으로 풍부해질지 몰라도, 의식적으로 통제하지 않는 한 그만큼 시끄러워집니다.

에이전트가 출력을 싸게 만든 만큼 우리는 이 비용을 더 빨리 치르게 됩니다.

레이어는 강력하지만 ‘벌어서’ 써야 합니다

추상화 레이어링에는 분명 좋은 버전도 있습니다. 어떤 기능들은 기초 역량(primitives)이 되고 그 위에 다른 기능이 자연스럽게 쌓이면서 제품이 더 확장 가능하고 즐거워집니다.

하지만 조심할 지점이 하나 있습니다. 잘못 만든 프리미티브는 잘못된 미래를 만듭니다.

프리미티브를 한 번 출시하면 다른 기능들이 그 위에 올라갑니다. 그 기초가 조금이라도 애매하거나, 새거나, 너무 옵션이 많거나, 내부 편의 중심이면 실수 하나를 출시하는 데서 끝나지 않습니다. 실수가 늘어나는 발판 자체를 출시하는 셈입니다.

그래서 출시는 비쌉니다. 기능을 더하는 게 아니라, 앞으로 무엇이 가능해지고 쉬워지고 정상으로 여겨지는지 그 기준 자체를 바꿔버리기 때문입니다.

에이전트는 ‘완료’에 강하고 ‘일관성’엔 피드백이 없습니다

코딩 에이전트는 컴파일되는 코드, 그럴듯한 테스트, 프로페셔널해 보이는 문구까지 그럴듯한 결과물을 정말 잘 만듭니다. 다만 그 결과물이 제품 전체에서 일관된 경험인지, 사용자 혼란을 줄이는지 가늠하는 감각은 기본적으로 없습니다.

이건 잘못이 아니라, 피드백 루프가 없어서 생기는 일입니다.

그래서 에이전트에게 “코드 작성/PR 생성” 같은 출력(Output)만 주면, 속도는 오르는데 제품의 응집력은 조용히 무너질 위험이 있습니다.

이게 에이전트 시대의 함정입니다. 처리량은 높은데 숙고는 낮은 상태.

테스트가 ‘출시’를 가치 있게 만듭니다

여기서 말하는 테스트는 유닛 테스트를 더 쓰자는 얘기가 아닙니다. 유닛 테스트는 물론 필요하지만 그것만으로는 충분하지 않습니다.

핵심은 출력을 ‘학습’으로 바꾸는 시스템입니다.

이걸 역량의 사다리로 보면 이해하기 쉽습니다.

  • Tier 0: Output. 에이전트가 구현하고 출시할 수 있습니다. 출시는 싸지만 위험합니다.
  • Tier 1: Verification. 제품을 직접 실행해서 엔드투엔드로 동작을 확인할 수 있습니다. 회귀가 줄어듭니다.
  • Tier 2: Validation. 이 변화가 가치가 있었는지(채택, 완료, 오류 감소, 혼란 감소)를 신호로 확인할 수 있습니다. 출시는 비로소 학습이 됩니다.
  • Tier 3: Steering. 신호를 기반으로 개선안을 제안할 수 있지만 방향과 의미는 사람이 결정합니다.

대부분은 Tier 0이 즉각적인 힘처럼 보여서 그쪽으로 먼저 달려갑니다.

하지만 진짜 이점은 Tier 1과 2에서 시작합니다. 여기서부터 출시는 그냥 움직임에 그치지 않고 ‘진전’이 됩니다.

거창한 에이전트 하네스까지 갈 필요도 없습니다. 아주 단순한 로컬 루프만 있어도 달라집니다. 에이전트가 앱을 띄워 실제 브라우저(예: CDP)에서 플로우를 돌려보고 깨진 부분이 없는지 확인한 뒤, 무엇을 검증했는지 요약하게 만드는 식입니다.

CDP가 마법이라서가 아니라, 비로소 현실을 확인하는 감각이 생기기 때문입니다.

사람의 역할: 코더가 아니라 ‘역량 설계자’

그럼 에이전트가 구현을 해주는 시대에 사람은 뭘 해야 할까요?

에이전트와 실행 속도로 경쟁하면 집니다. 그보다는 실행이 가치로 누적되게 만드는 희소한 역량에 집중해야 합니다.

  1. ‘좋은 변화’의 정의를 내리기. 성공 기준, 가드레일, 절대 깨지면 안 되는 계약. 이게 없으면 아무리 빨리 출시해도 소용이 없습니다.

  2. 제품 일관성을 설계하기. 인지 부하를 줄이는 추상화, 의도를 담은 기본값, 기능 더미 대신 ‘하나의 제품’처럼 느껴지게 하는 서사.

  3. 피드백 루프를 만들기. 검증(작동하는가?)과 가치 검증(도움이 되었는가?). 이게 방향성 드리프트를 막습니다.

  4. 사용자와의 계약을 책임지기. 단순한 정확성보다 명확함, 기능 더미보다 의미.

저는 계속 이 결론으로 돌아옵니다.

출시는 쌉니다. 방향성은 비쌉니다.

에이전트 시대에는 실행이 병목이 아니고 판단이 병목입니다.

그리고 그 판단이 가능해지도록, 속도를 안전하게 만들고 그 속도를 가치로 바꿀 피드백 루프를 설계하는 것이 바로 사람이 해야 할 일입니다.