속도는 공짜가 되었지만, 책임은 그렇지 않습니다

어느 날 제 노트북에는 에이전트가 여덟 개 돌아가고 있었고, 밤사이 도착한 PR이 다섯 개 쌓여 있었습니다. 대시보드는 쉴 새 없이 움직였고, 그날 저는 한 주 중 가장 바빴습니다. 그런데 퇴근할 무렵 main에 실제로 머지된 변경은 거의 없었습니다. 가장 생산적이라고 느낀 날과, 가장 적게 만들어 낸 날이 같은 날이었습니다.

이 역설이 어디서 오는지 알면, 요즘 에이전트 기반 개발을 둘러싼 과한 낙관과 막연한 불안 사이에서 발을 디딜 자리를 찾을 수 있습니다. 코드를 만드는 비용은 거의 0으로 떨어졌지만, 그 코드를 책임지는 비용은 한 푼도 싸지지 않았습니다.

낙관은 절반만 맞습니다

먼저 분명히 해 둘 게 있습니다. 저는 AI 도구를 매일 쓰고, 이 도구들 덕분에 예전보다 훨씬 과감하고 재미있는 일을 합니다. Addy Osmani도 같은 이야기를 합니다. 지난 1년 동안 이 도구들로 그 전 5년보다 더 많은 것을 실제로 만들었다고요. 생산성이 2배, 5배로 뛰었다는 경험담은 과장이 아닙니다. 그래서 "에이전트가 다 해준다"는 들뜬 목소리가 어디서나 들립니다.

문제는 그 목소리가 종종 한 박자를 건너뛴다는 데 있습니다. 데모는 늘 끝내줍니다. 그러다 현실이 도착합니다. 수정하거나, 확장하거나, 보안을 손보려는 순간, 아무도 이 코드가 실제로 무엇을 하는지 이해하지 못했다는 사실이 드러납니다.

1년 전 Andrej Karpathy가 만든 vibe coding 이라는 말은 원래 이 방식을 정확히 가리켰습니다. 프롬프트를 던지고, diff는 읽지 않고, 에러가 나면 다시 붙여 넣는 식으로 감에 맡기는 프로그래밍 말입니다. 주말 프로토타입이나 한 번 쓰고 버릴 스크립트라면 더없이 좋은 방식입니다. 망가지면 다시 생성하면 그만이니까요.

그런데 이 말이 어느새 결제 시스템을 만드는 일까지 전부 뭉뚱그려 부르는 단어가 되어 버렸습니다. Karpathy는 이번에 agentic engineering이라는 더 정확한 표현을 제안했고, Simon Willison을 비롯한 여러 사람이 비슷한 구분을 시도해 왔습니다. 핵심은 단어가 아니라 그 단어가 강제하는 경계입니다. vibe coding은 코드를 보지 않는 것이고, agentic engineering은 구현만 AI에게 맡기되 아키텍처와 품질, 정확성에 대한 책임은 사람이 쥐는 것입니다.

그러니 낙관 자체는 죄가 없습니다. 도구는 정말로 강력해졌고, 잘 쓰는 사람은 분명히 앞서갑니다. 위험한 건 낙관이 책임을 건너뛰는 핑계로 쓰일 때입니다. "에이전트가 했으니까"라는 말은 디버깅에도, 사고 보고서에도 아무 도움이 되지 않습니다.

리뷰어가 병목이 됩니다

낙관과 현실 사이의 간극이 가장 먼저, 가장 아프게 드러나는 자리가 코드 리뷰입니다.

코드 리뷰는 늘 병목이었습니다. 하지만 생산적이고 교육적인 병목이었습니다. PR을 읽는 행위 자체가 이해를 강제합니다. 숨은 가정이 드러나고, 반년 전 내린 설계 결정과 부딪히는 부분이 잡히고, 시스템이 실제로 무엇을 하는지에 대한 지식이 유지보수를 책임질 사람들에게 흩어집니다.

여기에 속도의 비대칭성이 끼어듭니다. AI는 사람이 코드를 평가하는 속도보다 훨씬 빠르게 코드를 생성합니다. 코드 생산이 비쌌던 시절에는, 시니어가 주니어의 작성 속도보다 빠르게 리뷰할 수 있었습니다. 이제는 주니어 한 명도 시니어가 비판적으로 검토할 수 있는 속도를 가뿐히 넘겨 코드를 쏟아냅니다. 리뷰를 의미 있게 지탱하던 속도 제약이 사라진 것입니다.

그래서 리뷰어의 책상에는 책임감이 휘발된 산출물이 끝없이 쌓입니다. 누군가 결과에 대한 부담 없이 올린 commit, PR, 기능 추가가 시니어든 주니어든 가리지 않고 검토자 한 사람에게 몰립니다. 1,800줄짜리 PR 앞에서 무슨 일이 벌어지는지는 이미 살펴본 적이 있습니다. 처음 100줄은 꼼꼼히 읽다가, 500줄을 넘으면 함수 시그니처만 훑고, 1,000줄을 넘으면 "테스트는 통과했네"로 끝내 버립니다.

Addy Osmani는 이 지점을 인지적 항복(cognitive surrender)이라고 부릅니다. 변경량이 머릿속에 담을 수 있는 임계치를 넘는 순간, 사람은 이해하기를 포기하고 통과 의례로 갈아탑니다. "Approve"는 검토의 결과가 아니라 절차의 일부가 됩니다.

이때 조직이 오랫동안 의지해 온 가정 하나가 조용히 무너집니다. "리뷰된 코드는 이해된 코드다" 라는 가정입니다. 엔지니어가 완전히 이해하지 못한 코드를 승인하면, 그 코드는 묵시적으로 "승인된 것"이 되고, 책임은 아무도 모르게 조직 전체로 흩뿌려집니다.

당신은 단일 스레드입니다

여기서 한 단계 더 들어가면, 이게 의지나 규율의 문제가 아니라 구조의 문제라는 사실이 보입니다.

파이썬에는 GIL(Global Interpreter Lock)이 있습니다. 스레드를 몇 개를 만들든, 한 순간에 실제로 파이썬 바이트코드를 실행하는 건 잠금을 쥔 단 하나의 스레드뿐입니다. 당신은 당신의 에이전트들에게 GIL과 같습니다. 에이전트는 얼마든지 동시에 돌릴 수 있지만, 아키텍처를 진짜로 이해해야 하는 판단이나 머지 충돌을 푸는 일은 결국 잠금을 잡아야만 처리됩니다. 잠금은 하나뿐이고, 그걸 쥔 사람은 당신입니다.

Amdahl의 법칙이 이 한계를 정확히 수식으로 못 박습니다. 병렬화로 얻는 속도 향상은, 끝까지 직렬로 남는 작업의 비율에 의해 상한이 정해집니다. 에이전트 개발에서 그 직렬 구간은 판단 입니다. 에이전트를 여덟 개 띄운다고 당신의 판단 시간이 8분의 1로 줄지 않습니다. 당신에게 들어오는 작업 큐만 여덟 배 깊어질 뿐입니다.

이걸 다른 각도에서 보면 이렇습니다. 코드를 생성 하는 비용은 빠르게 O(1)에 수렴하고 있습니다. 변경의 크기와 거의 무관하게, 사실상 공짜에 가까운 시간이면 됩니다. 하지만 그 코드를 이해하고 책임지는 비용은 여전히 O(n)입니다. 변경량에 비례해 사람의 주의력을 꼬박꼬박 잡아먹습니다. 생성 곡선은 바닥으로 내려앉는데 검토 곡선은 그대로이니, 둘 사이의 간극이 곧 오케스트레이션 세금(orchestration tax)입니다. 에이전트가 만들어 내는 양과 당신이 실제로 머지할 수 있는 양 사이에 구조적으로 벌어지는 격차죠.

이 비유는 한 군데에서 깨집니다. 그리고 깨지는 방향이 중요합니다. CPU의 컨텍스트 스위칭은 마이크로초 단위에, 공정하게 스케줄링되고, 상태를 완벽하게 복원합니다. 사람의 주의력은 그렇지 않습니다. 한동안 보지 않던 에이전트로 돌아갈 때마다 우리는 몇 분에 걸쳐 문맥을 다시 로딩하고, 그마저도 매번 완벽하게 복원하지 못합니다. 비유가 우리에게 유리한 쪽이 아니라 가혹한 쪽으로 깨지는 셈입니다. 사람은 GIL보다 느리고 불완전한 직렬 자원입니다.

그래서 에이전트 스무 개가 돌아가는 화면은 위험할 만큼 생산적으로 느껴집니다. 하지만 바쁜 것과 만들어 내는 것은 전혀 다릅니다. 좋은 동시성 시스템이 큐가 무한정 길어지지 않도록 생산자에게 백프레셔(backpressure)를 걸듯이, 띄우는 에이전트 수는 당신이 실제로 리뷰를 끝낼 수 있는 속도에 맞춰야 합니다. 그 숫자는 대부분의 사람에게 낮은 한 자릿수입니다. UI가 스무 개를 띄우게 해 준다는 건, 그저 UI가 그렇게 만들어졌다는 뜻일 뿐입니다.

부채는 코드가 아니라 사람과 인텐트에 쌓입니다

직렬 병목을 무시하고 갈아 넣으면, 그 대가는 사라지지 않고 부채로 적립됩니다. Margaret-Anne Storey의 3중 부채 모델은 그 부채가 쌓이는 자리를 세 군데로 깔끔하게 나눕니다.

기술 부채 는 코드에 쌓입니다. 얽힌 모듈, 마감에 쫓겨 낸 지름길처럼 나중에 시스템을 바꾸기 어렵게 만드는 선택들입니다. 수십 년 된 개념이고, 빌드가 느려지거나 테스트가 깨지는 형태로 체감됩니다.

인지 부채(이해 부채)는 사람에게 쌓입니다. 시스템에 존재하는 코드의 양과, 사람이 실제로 이해하는 양 사이에 벌어지는 간극입니다. 코드는 흠잡을 데 없이 깔끔할 수 있습니다. 그런데 아무도 그 깔끔한 코드를 이해하지 못한다면, 그건 가짜 자신감일 뿐입니다. Storey가 관찰한 어느 학생 팀은 7주 차에 벽에 부딪혔습니다. 코드가 지저분해서가 아니라, 왜 그런 설계 결정이 내려졌는지 아무도 설명하지 못해서, 간단한 변경조차 예상치 못한 문제를 일으키지 않고는 할 수 없게 된 것입니다.

인텐트 부채는 산출물에 쌓입니다. 시스템이 지금의 모습이 된 이유 — 목표, 제약, 근거 — 가 어디에도 외부화되지 않은 상태입니다. 여기서 핵심은 "외부화"입니다. 근거가 머릿속에만 있고 글로 남지 않았다면, 다음 사람에게도 다음 에이전트에게도 그 인텐트는 존재하지 않는 것과 같습니다.

이 세 부채 중 앞의 둘은 에이전트가 어느 정도 거들 수 있습니다. 엉킨 모듈은 리팩터링을 맡길 수 있고, 이해가 끊긴 부분은 "이 코드 설명해 줘"로 머릿속 모델을 다시 세울 수 있습니다. 코드가 남아 있으니까요. 하지만 인텐트는 다릅니다. 모델은 300ms라는 디바운스 값이 의도된 UX 결정이었는지, 벤치마크 결과였는지, 아니면 누군가 한 번 적고 두 번 다시 손대지 않은 숫자인지 알지 못합니다. 그저 그럴듯하고 자신감 넘치는 이유를 지어낼 뿐입니다. 모른다고 솔직하게 말하는 것보다 오히려 나쁩니다.

진짜 무서운 건 이 부채들이 맞물려 돌아가는 악순환입니다. 인지적 항복으로 이해 못 한 코드를 머지합니다. 이해 부채와 인텐트 부채가 복리로 붙습니다. 어느 날 시스템은 7주 차의 벽처럼 손대기 두려운 상태가 됩니다. 그래서 그걸 고치겠다고 다시 에이전트에게 "그냥 고쳐 줘"라고 던집니다. 같은 무책임이 한 겹 더 쌓이고, 코드베이스는 더 깊은 나락으로 내려갑니다. 코드 생성이 빨라질수록 이 사이클이 도는 속도도 함께 빨라진다는 게 핵심입니다.

하네스를 조이는 것만으로는 부족합니다

여기까지 오면 자연스럽게 떠오르는 해법이 있습니다. "그럼 하네스를 잘 설계하면 되는 것 아닌가?"

하네스(harness) 란 모델 자체를 뺀 나머지 전부입니다. 시스템 프롬프트와 CLAUDE.md, 도구와 MCP 서버, 훅, 샌드박스, 서브에이전트, 규칙과 스킬, 그리고 그 위에 얹는 외부 프레임워크와 플랫폼까지. 하네스 엔지니어링은 이걸 하나의 진짜 산출물로 취급하고, 에이전트가 한 번 미끄러질 때마다 더 조여 나가는 규율입니다.

이 규율은 분명히 강력합니다. 가장 좋은 습관은 에이전트의 실수를 영구적인 신호 로 다루는 것, 즉 래칫(ratchet)입니다. 에이전트가 주석 처리된 테스트를 포함한 PR을 올렸다면, 다음 버전의 규칙 파일에 "테스트를 주석 처리하지 말 것"이 들어가고, pre-commit 훅이 그 패턴을 걸러내고, 리뷰어 서브에이전트가 그걸 막아야 할 항목으로 표시합니다. 같은 실수를 두 번 하지 않도록 시스템을 설계하는 것. 좋은 규칙 파일의 모든 줄은 구체적인 실패의 흔적으로 거슬러 올라갈 수 있어야 합니다.

그런데 하네스를 강화하면 모든 게 해결된다는 식의 접근은 두 가지 지점에서 어긋납니다.

첫째, 하네스는 작아지지 않고 자리를 옮깁니다. 모델이 좋아지면 어떤 스캐폴딩은 쓸모없는 코드가 됩니다. 동시에 천장이 올라가면서, 예전엔 손도 못 대던 작업이 가능해지고 그 작업은 또 다른 실패 모드를 데려옵니다. 불안을 달래던 장치가 사라진 자리에, 며칠짜리 메모리 정책이나 전문 에이전트 셋을 조율하는 하네스가 들어섭니다. 그래서 "그냥 더 똑똑한 모델을 기다리면 된다"도 틀리고, "하네스만 충분히 쌓으면 끝난다"도 틀립니다. 일은 사라지지 않고 모양만 바꿉니다.

둘째, 더 쌓는 게 늘 더 나은 것도 아닙니다. 플러그인과 의존성을 무작정 붙이면 컨텍스트가 부풀고, 에이전트는 정보 과부하에 빠집니다. 행맨 게임 하나 만드는데 71번 전 세션의 메모까지 끌어안고 있으면 성능은 오히려 떨어집니다. 정말 유용한 프리미티브는 결국 파운데이션 모델이 기본 기능으로 흡수합니다. 스킬도, 메모리도, 플래닝도 그렇게 외부에서 검증된 뒤 공식 기능이 됐습니다. 그러니 최신 하네스를 좇아 매주 갈아엎는 것보다, 미니멀하게 시작해 실패를 목격할 때만 한 줄씩 조이는 편이 낫습니다.

무엇보다, 어떤 실패를 규칙으로 만들지, 결과가 받아들일 만한지, "완료"가 무엇을 뜻하는지를 정하는 일은 하네스가 대신해 주지 못합니다. 그건 판단이고, 판단은 직렬이며, 직렬 자원은 당신 하나뿐입니다. 하네스는 당신의 판단을 전달 하고 강제 하는 메커니즘이지, 판단을 대체 하는 장치가 아닙니다.

결국 책임은 사람이 집니다

그래서 모든 길은 한 곳으로 모입니다. 오늘 나와 있는 어떤 에이전트도 완벽하지 않고, 설계와 구현의 상당 부분을 넘길 수는 있어도 결과에 대한 책임은 머지 버튼을 누른 사람의 몫으로 남습니다.

이 책임을 의식적으로 지지 않으면 어떻게 될까요? 답은 의외로 익숙합니다. 에이전트 이전 시대에 무책임한 코드가 일으키던 바로 그 문제들 — 아무도 이해 못 하는 시스템, 복원되지 않는 설계 의도, 손대기 두려운 모듈 — 이 똑같이 일어납니다. 다만 코드 생성 시간이 O(1)로 수렴하는 만큼, 그 문제들이 훨씬 빠른 속도로, 훨씬 큰 규모로 들이닥칩니다. 속도가 빨라졌다는 건 좋은 결정도 나쁜 결정도 똑같이 빨라졌다는 뜻입니다. 책임의 밀도가 그대로면, 빨라진 속도는 그저 나락으로 떨어지는 속도가 됩니다.

뒤집어 말하면, 속도가 빨라질수록 사람이 쥐어야 할 것은 더 또렷해집니다. Addy Osmani는 코딩 세션을 마칠 때마다 단순한 질문을 던진다고 합니다. "오늘 나는 뭔가를 배웠는가, 아니면 그냥 티켓만 닫았는가?" Ship 과 Learn 은 서로 다른 두 지표이고, 매니저와 고객은 늘 첫 번째만 묻습니다. 두 번째를 챙기는 건 결국 당신의 책임입니다. 시스템에 대한 깊은 맥락을 쥔 사람만이, 어떤 diff가 진짜 하중을 지탱하는지 알아보고, 리팩터링이 안전한지 아니면 사용자가 의존하던 무언가를 조용히 바꾸고 있는지 구분해 낼 수 있습니다. 코드가 싸지면서, 이 능력은 값이 떨어지기는커녕 시스템 전체가 의존하는 희소 자원이 됩니다.

함께 이해하는 데서 시작합니다

그렇다고 너무 쫄 필요는 없습니다. 여기서 길을 잃지 않는 출발점은 의외로 단순합니다. 팀이 같은 지도를 들고 있는 것입니다.

지금까지 이름 붙인 것들 — 인지적 항복, 이해 부채, 인텐트 부채, 오케스트레이션 세금, 하네스 — 은 모두 예전엔 막연한 피로감이나 "왠지 불안한데"로만 존재하던 현상입니다. 이름이 생기면 팀이 그것을 두고 대화할 수 있습니다. "이 PR은 내 인지 용량을 넘었어"라거나 "이 결정은 인텐트를 남겨 두자"는 말이 통하는 팀과, 그냥 머지 수만 세는 팀은 6개월 뒤 전혀 다른 코드베이스 위에 서 있게 됩니다.

같은 지도를 공유했다면, 그다음은 길게 보고 가는 실천으로 이어집니다. 어느 것도 거창하지 않습니다. 이미 쓰고 있는 도구 안에서의 작은 자세 변경입니다.

• 인텐트를 1급 산출물로 외부화합니다. "왜"를 머릿속에서 꺼내 에이전트가 읽을 수 있는 곳에 남깁니다. 결정을 내리는 그 자리에서 가벼운 결정 로그(ADR)를 적고, CLAUDE.md나 AGENTS.md를 자동 생성된 설정 파일이 아니라 인텐트 장부 로 다룹니다. 모든 걸 적을 수는 없어도, "틀리면 비싸게 치를" 선택만큼은 근거를 남깁니다.
• 검증을 사후 단계가 아니라 구조적 제약으로 둡니다. 통과해야 할 테스트와 충족해야 할 조건을 작업 시작 전에 글로 못 박으면, 에이전트가 스텁만 만들고 "됐지?"라며 멈추는 일이 줄어듭니다. 다만 테스트는 필요조건이지 충분조건이 아닙니다. 아무도 떠올리지 못한 동작에는 테스트를 쓸 수 없으니까요.
• 자신의 주의력을 아키텍처처럼 설계합니다. 리뷰 속도에 맞춰 에이전트 수를 정하고, 판단이 본질인 복잡한 일은 병렬화하지 않으며, 리뷰는 배치로 모아 컨텍스트 스위칭 비용을 아낍니다. 기계가 스스로 증명할 수 있는 80%는 에이전트에게 맡기고, 사람의 판단이 필요한 20%에만 희소한 주의력을 씁니다.

조직 차원에서는 이걸 에이전트 개발 생애주기로 끌어올릴 수 있습니다. 빌드하고, 테스트하고, 통제된 방식으로 배포하고, 프로덕션에서 어떻게 동작하는지 모니터링하고, 거기서 얻은 학습을 다음 빌드에 되먹이는 순환입니다. 이건 무책임하게 빨리 내지른다는 뜻이 아니라, 가시성 을 갖춘 채로 빠르게 반복한다는 뜻입니다. 여기에 비용·도구 접근·발견 가능성을 다루는 거버넌스가 전체를 감싸면, 에이전트 개발은 일회성 데모에서 벗어나 유지보수 가능하고, 확장 가능하며, 안정적인 시스템으로 옮겨 갑니다. 짧은 시야로는 결코 도달할 수 없는 자리입니다.

내일, 다음 에이전트를 띄우기 전에

그러니 내일 다음 에이전트를 띄우기 전에, 딱 세 가지만 해 보면 좋겠습니다. 이번 변경에서 "틀리면 비싼" 결정 하나의 이유 를 적어 두는 것. 오늘 내가 Ship을 좇는지 Learn을 좇는지 한 번 의식하는 것. 그리고 내가 진짜로 리뷰를 끝낼 수 있는 에이전트 수가 몇 개인지 정직하게 숫자로 적어 보는 것.

미래에서 온 장난감을 손에 쥐고 진짜 일을 해 나가는 건 꽤 짜릿한 경험입니다. 그 짜릿함을 오래 누리는 방법은 속도를 포기하는 게 아닙니다. 빨라진 속도만큼 책임과 이해의 밀도를 의식적으로 설계하는 것입니다. 속도는 공짜로 받았지만, 그 속도를 어디로 끌고 갈지 정하는 일만큼은 끝까지 사람의 몫으로 남습니다.