AI가 코드를 다 짜주는 시대, 경쟁력은 어디서 갈리나

요즘 우리 팀에 AI 토큰을 안 태우는 개발자가 없다. 나도 매일 태운다. 그런데 이상한 장면을 본다. 같은 도구를 똑같이 쥐여줬는데, 어떤 사람은 일이 확 빨라지고 어떤 사람은 오히려 더 느려진다.

처음엔 내 착각인 줄 알았다. 바깥 데이터도 비슷했다. 어떤 조사는 AI 도입으로 생산성이 25%에서 39%까지 올랐다고 했다. 다른 연구에서는 숙련 개발자가 AI 결과를 확인하고 고치는 시간까지 합쳤더니 오히려 19% 느려졌다고 했다. 같은 기술인데 결론이 정반대다.

AI는 그 자체로 개발을 빠르게 만들지 않는다.

명세와 컨텍스트와 검증 구조가 준비된 조직에서만 효과가 커진다. 같은 모델이 어떤 손에 쥐이느냐에 따라 가속 페달이 되기도 하고, 브레이크가 되기도 한다.

차이는 모델이 아니라 하네스에서 났다

에이전트는 똑똑한 LLM 하나가 아니다. 지침과 규칙 파일, 도구와 MCP 서버, 샌드박스, 서브 에이전트 오케스트레이션, 가드레일과 훅, 그리고 테스트와 평가와 관측까지 한데 묶인 실행 구조다. 모델은 그 구조 안에 박힌 하나의 부품일 뿐이다.

그래서 같은 모델을 써도 프롬프트, 도구, 미들웨어, 실행 구조만 바꾸면 결과가 크게 달라진다. 누군가는 이걸 모델 10%, 하네스 90%라고 표현한다. 숫자야 보는 사람마다 다르게 잡겠지만, 방향은 맞다고 본다. 더 좋은 모델을 붙이는 것보다, 그 모델을 어떻게 둘러싸느냐가 결과를 더 크게 움직인다.

모든 걸 항상 집어넣지는 않는다

하네스를 만들다 보면 컨텍스트를 어떻게 다루느냐가 성능과 비용을 동시에 가른다. 에이전트가 쓰는 컨텍스트는 지침, 지식, 메모리, 예시, 도구, 가드레일로 나뉜다. 이걸 전부 매번 밀어 넣으면 안 된다.

AGENTS.md, 시스템 지침, 핵심 규칙은 안정적이지만 매 호출마다 토큰을 먹는다. 반면 Skill이나 RAG 문서, 도구 결과는 필요한 순간에만 불러오면 된다. 핵심 규칙은 정적 컨텍스트로 고정하고, 업무별 지식은 동적으로 로딩한다. 그리고 이 구분 자체를 코드처럼 버전 관리하고 리뷰한다. 무엇을 항상 켜둘지, 무엇을 그때그때 부를지가 곧 설계다.

바이브 코딩과 엔지니어링을 가르는 건 검증이다

같은 AI 코딩 도구를 써도, 결과를 대충 실행해 보고 끝내면 바이브 코딩이다. 명세와 테스트와 평가, CI 게이트를 통과시키면 에이전틱 엔지니어링이 된다. 도구가 같아도 둘은 전혀 다른 일이다.

검증은 두 가지로 나뉜다. 하나는 최종 결과가 맞는지 보는 것이다. 다른 하나는 올바른 도구와 절차를 거쳐 그 결과를 만들었는지 보는 것이다. 앞을 결과 검증, 뒤를 절차 검증이라 부른다. 겉으로는 정답처럼 보여도, 꼭 필요한 보안 검사나 데이터 검증을 건너뛴 결과라면 그건 빠른 게 아니라 위험한 것이다.

품질 수준은 데모가 아니라 평가 기준에서 정해진다.

병목은 구현에서 명세와 검증으로 옮겨갔다

AI는 구현 시간을 몇 주에서 몇 시간 수준으로 압축한다. 그런데 요구사항을 정의하고, 아키텍처를 판단하고, 결과를 검증하는 일은 여전히 사람의 몫이 크다. 빨라진 쪽과 그대로인 쪽이 갈리니, 병목이 옮겨간다.

개발자의 일도 바뀐다. 코드를 직접 쓰는 일에서, AI가 만든 코드를 검토하는 일로 무게가 넘어간다. 테스트와 평가는 개발의 마지막 단계가 아니라 구현 한가운데로 들어온다. 에이전트는 기능의 첫 80%는 빠르게 만들지만, 시스템 사이의 연결부와 예외 상황 같은 마지막 20%는 여전히 많은 맥락을 요구한다. 결국 구현 속도보다 명세의 품질이 새로운 병목이 된다.

싸게 시작해서 비싸게 끝나는 길

바이브 코딩은 설계 없이 바로 시작할 수 있어 초기 비용이 낮다. 대신 시간이 지나면 비용이 다른 곳에서 쌓인다. 반복되는 프롬프트와 토큰, 임시방편 코드의 유지보수, 뒤늦게 정리하는 보안 취약점, 무너진 코드 맥락, 기능을 고칠 때마다 다시 읽어야 하는 기존 코드.

에이전틱 엔지니어링은 반대다. 초기에 스키마와 테스트와 규칙, 구조화된 컨텍스트를 만드는 비용이 먼저 든다. 그 대신 이후 기능당 한계비용은 낮아진다. 바이브 코딩이 기능당 몇 배 더 비싸다는 식의 수치도 보이는데, 실측 상수라기보다 이 비용 구조를 설명하기 위한 예시에 가깝다. 중요한 건 정확한 배수가 아니라, 비용이 미뤄질 뿐 사라지지는 않는다는 사실이다.

그래서 무엇을 쥐여줄 것인가

그래서 요즘 내가 회사에서 가장 공들이는 건 더 좋은 모델을 들이는 일이 아니다. 우리가 일하는 방식, 인프라 기준, 보안 규칙, 검증 절차를 에이전트가 늘 지키도록 만드는 일이다. 좋은 도구는 누구나 똑같이 산다. 차이는 그 도구에 무엇을 쥐여주느냐에서 난다.

나에게 다음 숙제는 분명하다. Skill을 몇 개 더 만드는 게 아니라, 각 Skill에 테스트와 평가 기준을 연결해 에이전트가 결과뿐 아니라 올바른 절차를 거쳤는지까지 확인하는 체계를 붙이는 것이다. 그게 바이브 코딩을 조직 차원의 에이전틱 엔지니어링으로 바꾸는 조건이라고 본다.

질문은 하나로 남는다. 우리는 에이전트의 결과만 보고 있나, 그 결과가 올바른 절차를 거쳤는지까지 보고 있나.