그래도 나는 여전히 이것을 사용하고 있다

내가 다음 조직에서 실제로 AI 코딩 도구를 배포할 곳과 그 이유.

내 지난 포스트를 읽었다면, 내가 무조건적인 신봉자가 아니라는 것을 알 것이다. 컨텍스트 부패 (Context rot)는 실재한다. 신뢰도와 정확도 사이의 격차 (confidence-to-accuracy gap)도 실재한다. 아무도 요청하지 않은 자율적 의사결정 (autonomous decision-making) 또한 실재한다. 나는 이를 증명할 수 있는 디버깅 시간들을 겪어왔다.

그렇다면 왜 나는 첫날부터 Claude Code를 배포하겠다는 계획을 가지고 다음 조직으로 향하는 것일까?

"엔지니어링 팀을 대체할 준비가 되지 않았다"는 말과 "특정하고 제한된 방식으로 진정으로 유용하다"는 말은 서로 배타적인 것이 아니기 때문이다. 내가 사람들이 저지르는 실수라고 보는 것은 이것을 이분법적으로 다루는 것이다. 즉, AI가 모든 것을 10배로 만들거나, 아니면 과장된 쓰레기이거나 둘 중 하나라고 생각하는 것이다. 내가 발견한 것은 그렇지 않다. 내가 발견한 것은 실제 한계치 (ceiling)가 존재하지만, 그 한계치가 많은 가치 있는 작업의 최소 기준선 (floor)보다는 높은 도구라는 점이다. 질문해야 할 가치가 있는 것은 "이것이 좋은가?"가 아니라, "이것이 실제로 무엇을 잘하며, 어떻게 하면 나머지 부분을 망치지 않게 할 것인가?"이다.

내가 내린 결론은 다음과 같다.

새로운 코드베이스 (codebase) 파악하기

새로운 조직에 합류할 때마다, 나는 처음 몇 주 동안 한 번도 본 적 없는 코드베이스를 파악하는 데 시간을 보낸다. 어떤 것은 읽는 것이고, 어떤 것은 질문하는 것이다. 역사적으로 이는 내가 거의 알지 못하는, 자신의 업무를 수행 중이며 해당 코드베이스의 특정 부분이 어떻게 작동하는지 기억할 수도 있고 못할 수도 있는 새로운 팀원을 방해하는 것을 의미했다.

Claude Code는 그 방정식을 바꾼다. 평이한 언어로 질문할 수 있는 능력: "이 기능이 실제로 어디에 있나요?", "이 모듈을 건드리는 것이 무엇인가요?", "이것이 왜 존재하나요?"와 같은 질문들 말이다. 요구에 따라 상당히 정확한 답변을 돌려받는 것은 진정으로 가치 있는 일이다. 그것이 항상 옳기 때문이 아니라, 항상 사용 가능하며 당신이 검증할 수 있는 시작점을 제공하기 때문이다.

분명히 하고 싶습니다. 이것은 코드베이스 안에서 2년 동안 살아온 엔지니어들에게는 그다지 가치 있는 것이 아닙니다. 그들은 이미 머릿속에 지도를 가지고 있습니다. 하지만 완전히 새로운 사람에게는, 필요할 때 에이전트를 통해 질문에 답을 얻을 수 있다는 점 자체가 진정한 촉진제(accelerant)이며, 그렇지 않았다면 답변을 제공해야 했을 사람들에게서 반복적으로 발생하는 세금(tax)을 제거해 줍니다.

또한 제가 신규 채용자에게 첫날부터 맡길 수 있는 작업의 복잡성 자체를 변화시킵니다. 이전에는 누군가를 적응시키기 위해 단순하고 위험 부담이 낮은 과제에 의존했습니다. 이제는 신입 직원에게 의미 있게 복잡한 무언가를 맡기고, Claude에게 어디서 시작할지 물어보라고 지시하며, 그들이 더 일찍 실제 업무에 참여하도록 할 수 있습니다. 이는 신규 채용자에게도 좋고 팀에게도 좋습니다.

코드 리뷰를 요청하되 비판적으로 하도록 요청하기

Claude는 정말 효과적인 코드 리뷰어입니다. 하지만 만성적으로 간과되는 한 가지 주의점이 있습니다. 바로 명시적으로 비판적이 되도록 요청해야 한다는 것입니다.

스스로 두면, 그것은 응원하는 쪽으로 기본 설정됩니다. 무언가를 승인하고 싶어 합니다.

주의해야 할 실패 모드(failure mode)는 다음과 같습니다. 리뷰 에이전트(review agent)가 코딩 에이전트(coding agent)와 동일한 컨텍스트 부패(context rot)를 물려받을 수 있다는 점입니다. 저는 프로세스 초기 단계에 린팅(linting) 규칙을 설정해 두었던 상황이 있었습니다. 그런데 코딩 에이전트가 PR을 생성하기 전에 린터를 실행하는 것을 중단했습니다. 리뷰 에이전트 역시 이를 잡아내지 못했습니다. 저는 이것이 CI 파이프라인(CI pipeline)에 도달하여 실패했을 때에야 알게 되었습니다. 저는 두 에이전트 모두를 꾸짖어야 했습니다.

이를 최종 관문(final gate)이 아닌, 1차 검토(first pass) 용도로 사용하십시오. 엔지니어들이 코드를 인간 리뷰어(human reviewer)에게 보내기 전에 Claude의 리뷰를 먼저 실행하게 하십시오. 이는 의미 있는 비율의 문제들을 잡아낼 것입니다. 이것이 인간 리뷰어를 대체하는 것은 아니며, 그렇게 포지셔닝해서도 안 됩니다.

진단 도구로서의 테스트 생성 (Test generation as a diagnostic tool)

이 부분은 충분한 주목을 받지 못하고 있습니다.

엔지니어들은 만성적으로 테스트에 대한 투자를 소홀히 합니다. 이는 테스트를 가치 있게 여기지 않아서가 아니라, 지루하고 제품 출시(shipping)와 경쟁 관계에 있기 때문입니다. 그 결과, 커버리지(coverage)가 불충분한 코드베이스가 만들어지며, 이는 다른 모든 작업을 더 어렵게 만듭니다.

Claude는 테스트 생성(test generation)에 능숙하지만, 가장 유용한 점은 Claude가 생성하는 테스트 그 자체가 아닙니다. Claude가 어려움을 겪을 때 발생하는 현상입니다. 테스트하기 어려운 코드는 거의 항상 증상입니다. 즉, 갓 클래스(god class), 한 곳에 너무 많은 책임(responsibilities)이 집중됨, 숨겨진 의존성(hidden dependencies) 등이 그 증상입니다. Claude에게 무언가에 대한 테스트를 작성하도록 요청했을 때 깔끔하게 수행하지 못한다면, 그것은 하나의 정보입니다. 그 고전(struggle)은 이미 존재하던 설계 문제(design problems)를 표면 위로 드러냅니다.

저는 엔지니어들이 이를 2단계 워크플로우(workflow)로 사용하기를 권장합니다. 방금 구축한 것에 대해 Claude에게 테스트를 작성하도록 요청하십시오. 만약 Claude가 이를 깔끔하게 수행하지 못한다면, 코드가 출시되기 전에 재검토가 필요하다는 신호로 간주하십시오. 여러분은 단순히 테스트를 생성하는 것이 아닙니다. 테스트 생성 프로세스를 가벼운 설계 리뷰(design review)로 활용하고 있는 것입니다.

내부 도구 (Internal tooling)

모든 엔지니어링 조직에는 고객을 직접 상대하지 않고, 로드맵에도 없으며, "언젠가 누군가 해야 할 일"이라는 단계에 머물러 아무도 만들지 않은 내부 도구(internal tools)들의 무덤이 있습니다. 보고를 자동화하기 위한 스크립트, 운영 가시성(operational visibility)을 위한 대시보드, 만약 존재한다면 매주 몇 시간씩을 아껴줄 수 있는 작은 유틸리티들 같은 것들 말입니다.

제가 지난 포스트에서 설명한 메트릭 대시보드(metrics dashboard)가 바로 이것이었습니다. 매주 30분씩 걸리던 수동 작업을 8시간 만에 자동화한 것이었죠. 고객을 직접 상대하는 것도 아니었고, 실제 이해관계자들이 기다리고 있는 프로젝트에서 엔지니어를 빼내어 이 일을 할 만큼 정당화할 수도 없는 일이었습니다. 하지만 실질적인 가치가 전달되었습니다.

이 지점이야말로 현재의 한계가 가장 덜 중요한 부분입니다. 내부 도구(Internal tooling)는 투박함을 견딜 수 있습니다. 사용자들이 기술적이며, 런타임 에러(runtime error)의 위험 부담도 낮습니다. 만약 에이전트(agent)가 내부적으로 세 명만이 사용하는 스크립트에 대해 이상한 자율적 결정을 내린다면, 그것을 발견하고 수정하고 넘어가면 그만입니다.

내부 도구를 시험장(proving ground)으로 활용하십시오. 엔지니어들이 이러한 도구들과 어떻게 협업할지에 대한 직관을 기를 수 있도록 하십시오. 어디를 신뢰하고, 어디를 검증하며, 어떻게 효과적으로 프롬프트(prompt)를 작성할지를 말입니다. 틀렸을 때의 비용이 낮은 작업에서 먼저 실행해 본 뒤, 비용이 높은 작업으로 넘어가십시오.

적절한 유형의 문제를 위한 프로덕션 코드 (Production code)

이 대목에서 대화는 보통 양방향으로 엇나갑니다. 사람들은

제3자 통합 (Third-party integrations)이 가장 명확한 예시입니다. 외부 서비스와 통합할 때, 여러분은 다른 누군가가 작성한 명세 (specification)에 맞춰 코딩하게 됩니다. 입출력은 정의되어 있고, 예외 케이스 (edge cases)는 문서화되어 있습니다. API 계약 (API contract)의 범위 내에서 머문다면, 숨겨진 성능 함정이나 보안 지뢰가 많지 않습니다. 이는 시니어 엔지니어의 시간을 소모하지만, 진정한 시니어의 판단력을 요구하지는 않는 작업입니다. 이것이 바로 여러분이 외주를 주고 싶은(offload) 바로 그 작업입니다.

의존성 업그레이드 (Dependency upgrades) 또한 마찬가지입니다. 누군가는 해야 하지만 아무도 하고 싶어 하지 않는 기계적인 작업입니다. 잘 이해된 예상 가능한 동작이며, 테스트 스위트 (test suite)가 성공 여부를 알려줍니다. 저는 가드레일 (guardrails)을 갖춘 상태에서 Claude가 이러한 작업을 처리하도록 맡길 것입니다. 저의 경험칙은 이렇습니다. 만약 의존성을 업데이트하는 과정에서 버전 변경 자체 외에 3개 이상의 파일을 수정해야 한다면, 즉시 중단하십시오. 무언가 더 복잡한 일이 일어나고 있으며, 인간의 결정이 필요하다는 신호입니다.

여기서 기회비용 (opportunity cost) 논리가 중요합니다. 시니어 엔지니어가 통합 명세나 의존성 업그레이드에 소비하는 매 시간은, 진정으로 새로운 문제들, 즉 아키텍처 결정, 까다로운 버그, 그리고 실제 경험과 판단력이 요구되는 성능 조사 등에 쓰지 못하는 시간입니다. 잘 정의된 작업을 외주 주는 것은 게으름이 아닙니다. 그것은 자원 배분 (resource allocation)입니다.

타협할 수 없는 원칙은 적절한 모니터링 (monitoring), 어떤 것이 프로덕션 (production)에 반영되기 전의 면밀한 검토, 그리고 언제 에스컬레이션 (escalate)할지에 대한 명확한 기준입니다. AI가 생성한 프로덕션 코드가 본질적으로 무모한 것은 아닙니다. 검토되지 않고 모니터링되지 않는 AI 생성 프로덕션 코드가 무모한 것입니다.

내가 실제로 기대하는 것

제가 이 일을 확신이 아닌 계획을 가지고 임하고 있다는 사실을 솔직하게 말씀드리고 싶습니다. 제가 설명한 모든 것은 조직 전체에 대규모로 배포한 결과가 아니라, 제 개인 프로젝트에서 실행한 실험에 기반한 것입니다. 어떤 것은 제가 기대한 대로 작동할 것이고, 어떤 것은 그렇지 않을 것입니다. 아마도 아직 접해보지 못한 새로운 실패 모드 (failure modes)를 발견하게 될지도 모릅니다.

제가 하지 않을 일은 도구를 사용하는 프레임워크 (framework) 없이 팀원들에게 도구를 던져주는 것도, 혹은 도구가 불완전하다는 이유로 그것들을 가둬두는 것도 아닙니다. 제가 함께 일하게 될 엔지니어들은 저의 가이드 (guidance) 유무와 상관없이 이 도구들을 사용할 것입니다. 저의 역할은 그들에게 "그냥 이것저것 해보고 어떻게 되는지 보자"라는 방식보다 더 스마트한 방식으로 도구와 상호작용할 수 있는 방법을 제공하는 것입니다.

만약 실제로 대규모 (scale)로 운영해 본 후에 이에 대한 제 생각이 바뀐다면, 그 내용에 대해서도 글을 쓰겠습니다.