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

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

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

근데 속도가 빨라졌다고 해서, 진짜 진전(progress)이 싸진 건 아니에요. 오히려 반대인 경우가 많아요.

코드는 싸졌지만, 출시의 ‘대가’는 안 싸졌거든요. 그리고 에이전트는 그 비싼 부분—방향성, 사용자 이해, 장기적인 일관성—을 더 자주, 더 빨리 흔들어놔요.

출시는 싸지만, 제품 방향성은 비싸요

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

지금은 가능해요. 에이전트가 구현 비용을 너무 강하게 눌러버리니까, “일단 출시하자”가 기본 자세가 되기 쉬워요.

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

1. 방향을 고정해요. 프로덕션에 나가면 “이걸 만들까?”가 아니라 “이걸 어떻게 덜 별로 만들까?”로 질문이 바뀌어요. 로드맵이 조용히 ‘발견/탐색’에서 ‘수습/정리’로 이동하죠.

2. 기대를 고정해요. 사용자는 즉시 제품의 정상 동작을 새로 학습해요. 작은 변화도 하나의 계약이 돼요. 나중에 또 바꾸면 우리는 코드만 바꾸는 게 아니라, 사람의 머릿속 모델을 이사시키는 거예요.

3. 혼란이 누적돼요. 혼란은 버그 하나가 아니고 엔트로피예요. 설정 하나 더, 예외 경로 하나 더, 비슷한 기능 하나 더… 이런 것들이 쌓이면서 제품이 “풍부”해지기도 하지만, 동시에 “시끄러워”져요. 관리하지 않으면요.

에이전트는 출력을 싸게 만들어서, 이 비용을 더 빨리 발생시켜요.

레이어는 강력하지만, ‘벌어서’ 써야 해요

추상화 레이어링의 좋은 버전도 분명 있어요. 어떤 기능들은 프리미티브(기초 능력) 가 되고, 그 위에 다른 기능이 자연스럽게 쌓이면서 제품이 더 확장 가능하고 즐거워져요.

하지만 여기엔 칼날이 있어요. 잘못 만든 프리미티브는 잘못된 미래를 만들어요.

프리미티브를 한번 출시하면 다른 기능들이 그 위에 올라가요. 그 기초가 조금이라도 애매하거나, 새거나, 너무 옵션이 많거나, 내부 편의 중심이면… 단순히 실수를 출시하는 게 아니라, ‘실수가 늘어나는 발판’을 출시하는 거예요.

그래서 출시는 비싸요. 기능을 더하는 게 아니라, 앞으로 무엇이 가능해지는지/쉬워지는지/정상으로 여겨지는지 자체를 바꿔버리거든요.

에이전트는 ‘완료’에 강하고, ‘일관성’엔 피드백이 없어요

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

이건 잘못이 아니라, 피드백 루프가 없어서 그래요.

그래서 에이전트에게 “코드 작성/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. 사용자와의 계약을 책임지기. 정확성뿐 아니라 명확성. 기능뿐 아니라 의미.

제가 계속 돌아오게 되는 결론은 이거예요.

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

에이전트 시대엔 실행이 병목이 아니고, 판단이 병목이에요.

그리고 그 판단이 가능해지도록, 속도를 ‘안전’으로 만들 역량과 속도를 ‘가치’로 만들 역량을 설계하는 게 사람이 해야 할 일이에요.