AI 코딩 에이전트가 코드 작성 속도는 폭발적으로 높이지만, 인간의 이해와 팀의 개발 관행이 결여되면 유지보수 가능한 소프트웨어를 전달하기 어렵다. 테크 리드의 딜레마를 통해 단기 속도와 장기 팀 성장 사이의 균형을 설명하고, LLM을 ‘번개처럼 빠른 주니어’로 다루는 실천적 방법을 제시한다.
누군가가 “코딩”하는 모습을 보면, 키보드를 두드리는 시간보다 허공을 멍하니 응시하는 시간이 훨씬 길다는 사실을 발견할 수 있다. 아니다, (아마) 딴짓하는 게 아니다. 소프트웨어 개발은 본질적으로 문제 해결의 실천이며, 까다로운 십자말풀이를 푸는 것과 마찬가지로 대부분의 일은 머릿속에서 이루어진다.
소프트웨어 개발 생애주기에서 코딩은 십자말풀이 칸에 글자를 채워 넣는 일에 가깝다. 머리를 쥐어짜고 메모를 끄적이는 데 비하면 아주 작은 노력일 뿐이다. 실제 일은 대개 코딩과 나란히 진행된다. 개발자가 도메인을 학습하고, 요구사항을 좁히고, 관련 추상화를 설계하고, 부작용을 고려하고, 기능을 점진적으로 테스트하고, 마지막으로 이 엄격한 과정을 통과한 버그를 박멸하는 동안 말이다. 대략 이런 모습이다:
하지만 AI 주도 코딩에서는 양상이 매우 다르다.
Claude Code 같은 AI 코딩 에이전트 덕분에 맥락에서 고립된 상태로 코드를 써 내려가는 속도는 놀라울 만큼 빨라졌다. 하지만 대부분의 소프트웨어는 복잡한 시스템 안에서 살아 움직이고, LLM이 아직 애플리케이션의 전체 컨텍스트를 한 번에 메모리에 담아둘 수 없기 때문에 인간의 리뷰, 테스트, 통합은 여전히 필요하다. 그리고 그 코드를 사람이 충분히 생각하지 않은 채 먼저 작성해버렸다면, 그 이후의 작업은 훨씬 더 어려워진다. 그 결과, 복잡한 소프트웨어에서는 AI가 쓴 코드를 사후적으로 이해하는 데 많은 시간을 쓰게 된다.
이는 AI로 코드를 작성하는 속도의 패러다임 전환을 자랑하는 마케팅 카피(종종 “(10배더 빠르게)”라는 프레이밍)와, 현장에서 관찰되는 동작하는 소프트웨어를 전달할 때의 미미한 생산성 향상(보통 10%에 가까운) 사이의 간극의 뿌리다.
더 낙담스러운 점은 개발자인 우리가, 이 놀라운 재잘거리는 기계들의 출력을 다듬는 데 점점 더 많은 시간을 쓰게 된다는 사실이다. LLM은 재미있고 쉬운 일은 번개처럼 해치우지만, 우리는 감사도 받기 힘든 일들만 떠안게 된다. 기존 기능이 깨지지 않았는지 검증하는 테스트, 중복된 코드 정리, 문서 작성, 배포와 인프라 처리 등등. 개발자가 진정으로 좋아하는 일, 즉 코딩 자체에 쓰이는 시간은 아주 적다.
다행히도 해결의 실마리는 가까이에 있다. LLM이 소프트웨어 개발 방식을 뒤흔들고 있지만, 이 문제가 새삼스러운 것은 아니다. 사실 이는 오래된 문제의 선명한 사례일 뿐이다. 나는 이것을 다음과 같이 부른다:
엔지니어는 커리어를 쌓아가다 보면 언젠가 테크 리드 역할을 맡게 된다. 팀을 매니징할 수도 있고, 사람 관리는 하지 않으면서 기술 전달을 주도하는 프린시펄 엔지니어일 수도 있다. 어느 쪽이든 팀의 기술적 결과물에 책임을 진다. 또한 경력 자체나 팀의 특수 도메인, 혹은 그 둘 모두에서 팀 내 가장 숙련된 개발자인 경우가 많다.
소프트웨어 전달은 팀 스포츠이지만, 경험은 개인별 기여의 속도(velocity)에 심하게 불균형을 초래할 수 있다. 따라서 테크 리드의 주된 일이 전달을 극대화하는 것일 때, 소프트웨어를 전달하는 두 가지 방식 사이에서 내부적 갈등을 마주하게 된다.
안타깝게도 과잉보호가 장기적으로 팀 건강에 극도로 해롭다는 점을 곧 보게 되겠지만, 단기적으로는 종종 전달 속도를 높이는 매우 효과적인 방법이기도 하다. 더 높은 대역폭을 가진 테크 리드의 시간을, 가장 어려운 일을 모두 흡수하는 데 쓰는 것이 효율적일 때가 많기 때문이다.
그래서 내 커리어 전반에 걸쳐 이 패턴이 반복되는 것을 수없이 보았다. 그리고 그 대가는 늘 분명하다. 테크 리드에게 경험이 집중되면 팀은 부서지기 쉬워지고, 지원은 어려워지며, 단일 실패 지점으로서 테크 리드에게 점점 더 큰 압력이 가해진다. 그다음은 예측 가능하다. 번아웃, 퇴사, 그리고 모든 것이 어떻게 돌아가는지 정말로 아는 단 한 사람 없이 버티려 애쓰는 팀의 위기.
대개 그렇듯, 해법은 두 극端을 피하고 전달과 팀 성장을 균형 있게 맞추는 제3의 길에 있다. 이를 다음과 같이 정식화할 수 있을 것이다.
엔지니어가 재작업을 최소화하고, 효과적인 협업을 극대화하며, 개인의 성장과 학습을 촉진하는 프레임워크 안에서 동작하는 코드를 전달할 수 있도록 팀 관행을 구현하라.
내가 Datasine의 CTO였을 때, 우리는 이 태도를 간단한 기술 팀 모토에 담아 명문화했다.
배우자. 전달하자. 재미있게 하자.
좋은 테크 리드는 엔지니어 각자가 자신의 역량 한계에 닿는 일을 맡도록 하되, 전달 리스크를 최소화하면서도 팀원 각자가 기술, 지식, 도메인 전문성을 키울 수 있게 하는 프로세스와 관행을 마련한다. 이것이 바로 훌륭한 기술 리더십의 핵심이다.
이를 달성하는 방법은 다양하다. 익스트림 프로그래밍(Extreme Programming) 규칙 같은 엄격한 규범적 프레임워크부터, 우리가 넓게 “베스트 프랙티스”라 부르는 느슨한 원칙의 집합까지:
따라서 오늘날 숙련된 엔지니어에게 시급한 질문은 이것이다. 이 관행들을 AI 주도 코딩의 세계에 어떻게 옮겨올 것인가?
2025년, 많은 엔지니어가 생전 처음으로 모든 테크 리드에게 익숙한 입장에 서게 되었다. 뛰어나지만 예측 불가능한 주니어 엔지니어를 감독하는 위치 말이다. 이런 재능을 효과적인 팀 협업에 이롭게 하도록 harness하고 통제하는 것은 엔지니어링 리더십의 주요 과제 중 하나다. 하지만 AI 코딩 에이전트는 주니어 엔지니어와는 다른 방식의 관리가 필요하다. 그들의 생산성과 성장의 본질이 근본적으로 다르기 때문이다.
소프트웨어 엔지니어는 경험이 쌓일수록 여러 면에서 동시에 생산성이 향상되는 경향이 있다. 더 견고한 코드를 쓰고, 더 나은 추상화를 사용하고, 버그를 만들고 고치는 데 쓰는 시간을 줄이고, 더 복잡한 아키텍처를 이해하고, 엣지 케이스를 더 효과적으로 커버하고, 반복되는 패턴을 더 일찍 포착하는 식이다. 엔지니어링은 풍부하고 복잡한 분야로 다양한 전문화의 길이 있지만, 단순화를 위해 이 차원들을 크게 두 가지 주제로 묶어 보자.
시간이 지남에 따라 좋은 엔지니어는 두 축 모두에서 발전한다.
초기의 LLM은 코드를 빨리 쓰긴 했지만, 버그를 고치고 환각을 제거하는 데 시간이 들어가다 보니 버그 없는 코드를 완성하는 데는 느렸다. 시간이 흐르며 더 똑똑한 LLM, 더 나은 컨텍스트 엔지니어링과 도구 활용 덕분에 최신 AI 코딩 에이전트는 “원샷”으로 코드를 작성하는 능력이 훨씬 좋아졌다. 현재 상용 에이전트 세대는 어떤 미드급 엔지니어에게도 도전이 될 문제에 대해서도 동작하는 코드를 믿을 수 없을 정도로 빠르게 만들어낼 수 있다. 다만 아직 시니어 엔지니어의 전문성에는 미치지 못한다.
따라서 현재 세대의 AI 코딩 에이전트를 주니어 엔지니어에 비유할 수 있지만, 두 가지 근본적인 차이가 있다.
주니어 인재를 배치할 때 그렇듯, 초점이 장기인지 단기인지에 따라 대체로 두 가지 방식이 있다.
예상하듯, 이 두 접근 중 하나를 택했을 때의 장기 궤적은 주니어 팀에 대한 공정한 위임과 과잉보호 사이의 선택과 거의 동일한 패턴을 따른다.
이 때문에 바이브 코딩은 아주 작은 프로젝트나 일회용 프로토타입에는 훌륭하다. 충분히 단순한 애플리케이션이라면 인간의 사고가 전혀 개입되지 않아도 전달할 수 있다. 프로젝트의 복잡도를 제한하고 도구의 역량을 십분 활용하면, 엔드 투 엔드로 동작하는 소프트웨어를 순식간에 만들 수 있다.
하지만 AI 혼자서는 넘을 수 없는 복잡성의 벽을 언젠가는 마주하게 된다.
프로토타입을 만드는 일은 그 어느 때보다 쉬워졌다. 그러나 실제로 복잡하고 안전하며 제대로 동작하는 소프트웨어의 전달을 가속하고, 주변적인 효율성 향상을 넘어서는 효과를 얻고자 한다면, 인간과 LLM이 함께하는 엔지니어링 팀 간 협업을 극대화하도록 맞춤화된 새로운 엔지니어링 플레이북이 필요하다.
AI 코딩 에이전트는 눈부시게 생산적이지만, 당신의 비즈니스, 코드베이스, 로드맵에 대한 심층 지식은 없다. 그대로 놔두면 설계, 일관성, 유지보수성을 전혀 고려하지 않은 채 기꺼이 수천 줄의 코드를 양산한다. 그러므로 엔지니어의 역할은 이 뜨거운 재능들에게 테크 리드로서 구조, 표준, 프로세스를 제공해, 날것의 속도를 지속 가능한 전달로 변환하는 일이다.
우리는 효율적으로 동작하는 소프트웨어를 전달하는 새로운 플레이북이 필요하고, 그 방법은 과거에서 배울 수 있다. LLM을 번개처럼 빠른 주니어 엔지니어로 대하되, 소프트웨어 개발 생애주기의 베스트 프랙티스를 지렛대로 삼아 스케일하는 시스템을 구축하자.
테크 리드가 단지 코드를 쓰는 데 그치지 않고 팀의 관행을 정하듯, 이제 엔지니어는 AI 에이전트를 위한 관행을 정해야 한다. 이는 AI를 생애주기의 모든 단계로 끌어들이는 것을 의미한다.
명세(스펙): 기능 명세를 탐색·분석·정제해 엣지 케이스를 포괄하고 초점을 좁힌다.
문서화: 재사용 가능한 가드레일과 지속 가능한 근거를 제공하기 위해 선행 문서를 생성하고 검토한다.
모듈형 설계: 컨텍스트 범위를 제어하고 이해도를 극대화하기 위해 모듈러 아키텍처의 스캐폴딩을 마련한다.
테스트 주도 개발: 구현에 앞서 광범위한 테스트 케이스를 생성해 구현을 이끌고 회귀를 방지한다.
코딩 표준: 컨텍스트 엔지니어링을 통해 코드 생성 시 사내 스타일과 베스트 프랙티스를 적용한다.
모니터링 및 인트로스펙션: 그 어떤 인간보다 빠르게 로그를 분석하고 인사이트를 추출한다.
소프트웨어 전달이 단순한 코드 작성 그 이상임을 이해할 때, 우리는 AI 코딩 함정을 피하고, 오히려 동작하며 확장 가능한 소프트웨어를 전달하는 우리의 역량을 크게 증폭시킬 수 있다.
