올해 GitHub에서 AI가 생성한 코드가 처음으로 인간이 직접 쓴 코드를 넘어섰다. 개발자들의 코딩 활동량은 180% 폭증했다. 그런데 실제로 세상에 출시된 소프트웨어는 고작 30% 늘어나는 데 그쳤다. 180%와 30% 사이의 150%포인트는 어디로 증발한 걸까?
이 질문에 대한 답을 따라가다 보면, 우리가 AI 코딩 도구를 '더 많이' 쓰는 것이 아니라 '더 똑똑하게' 써야 하는 이유가 보인다.
깔때기의 교훈: 180% 입력이 30% 출력이 되는 구조
파로스 AI의 2025년 리포트는 이 격차의 실체를 보여준다. PR(Pull Request) 머지 건수는 98% 늘었지만, 사람이 그 코드를 리뷰하는 시간은 91% 길어졌다. 버그도 9% 증가했다. AI가 부품을 3배 속도로 찍어내는데, 조립·검수 라인은 옛날 속도 그대로인 공장과 같다.
학계는 이 현상을 생산성-신뢰성 역설(PRP)이라 부른다. 개인의 코딩 속도는 빨라졌지만 검증 병목이 그대로여서 시스템 전체의 신뢰성이 오히려 떨어진다.
앤트로픽과 스탠포드 대학의 실험 결과는 더 충격적이다. AI를 사용해 새 라이브러리를 학습한 그룹은 AI 없이 학습한 그룹보다 코드 이해도와 디버깅 능력이 17% 낮았다. AI에 전적으로 의존한 그룹은 나중 유지보수 테스트에서 77%가 실패했다. 카네기멜론의 표현을 빌리면, 이는 '인식론적 부채' — AI에게 인지 부하를 외주 주면서 학습 과정 자체를 포기하는 현상이다.
GPS만 따라가다 화면이 꺼지면 바로 미아가 되는 것과 같다. 당신은 어디 있는지 모른다.
시니어 개발자들은 지금 코드 대신 '하네스'를 만든다
여기서 흥미로운 대목이 나온다. 이 병목을 돌파한 시니어 개발자들은 코드를 타이핑하는 대신 하네스(Harness)를 만들고 있다. 에이전트는 모델 + 데이터 + 하네스라는 공식이 통용되며, 하네스는 5개 레이어로 구성된다:
- Memory — 시스템 아키텍처를 주입하는 컨텍스트. 프로젝트 규칙, 과거 결정 사항, 실수 패턴을 에이전트가 매번 다시 묻지 않도록 미리 주입한다.
- Tools — 사용 가능한 기능을 제한하는 도구 경계. 에이전트가 함부로 시스템을 건드리지 못하게 행동 반경을 명확히 긋는다.
- Permissions — 위험한 행동을 막는 권한 통제. 데이터베이스 직접 수정, 실서버 배포 같은 치명적 작업은 사람 승인 없이 실행할 수 없게 막는다.
- Hooks — 오류 발생 시 자체 수정을 강제하는 피드백 루프. 테스트 실패 시 자동 재시도, 코드 리뷰 병목 감지 시 알림 등이 여기에 해당한다.
- Observability — 모든 과정을 투명하게 기록하는 감시 체계. 에이전트가 어떤 결정을 내렸는지, 왜 그 결정을 내렸는지 추적할 수 있어야 한다.
오픈AI 코덱스 팀은 단 3명의 엔지니어로 1,500개의 PR(Pull Request)을 처리했다고 알려졌다. 슈드 AI의 분석에 따르면, 뛰어난 시니어 한 명이 반나절 만든 하네스가 10명의 주니어가 매일 시스템 맥락 파악하느라 하는 삽질을 완전히 대체한다.
5레이어 하네스, 실제로 이렇게 돌아간다
이 5레이어가 실제 프로젝트에서 어떻게 작동하는지 구체적인 예로 살펴보자. 필자가 직접 운영 중인 에이전트 시스템을 기준으로 설명한다.
① Memory — "설정 파일은 CLI로만 수정한다", "이 프로젝트는 Python 3.12를 사용한다" 같은 규칙을 세션 시작 시점에 자동 주입한다. 에이전트가 매번 "어떤 버전 쓸까요?"라고 묻지 않는다. 사람이 매일 아침 팀원에게 브리핑하지 않아도 되는 것과 같다.
② Tools — 읽기 전용 명령어와 쓰기 가능 명령어를 분리한다. 파일 읽기는 자유롭지만, 내용 수정은 승인된 도구로만. 단순한 취향이 아니라, 에이전트의 행동 반경을 명시적으로 제한하는 통제 장치다.
③ Permissions — 블로그 글 발행, 자동화 스케줄 변경, 파일 삭제는 반드시 사람 승인을 요구한다. 자동화 모드에서는 더 엄격해져서, 실서버 접근 자체가 차단된다. 에이전트가 아무 일이나 저지르지 못하게 하는 안전장치다.
④ Hooks — 자동화된 품질 검사 파이프라인이 대표적이다. 글을 발행하기 전에 금지어 체크, 길이 검사, 톤 일관성 검사를 통과해야만 최종 승인 단계로 넘어간다. 불합격하면 자동으로 보강 루프가 돌아 최대 3회까지 재시도한다. 사람 손 없이도 품질 기준이 무너지지 않는다.
⑤ Observability — 모든 세션을 기록·인덱싱한다. "지난주에 그 설정 왜 바꿨지?"라는 질문에 5초면 답이 나온다. 에이전트와 수천 번 대화를 나눠도, 결정의 맥락이 사라지지 않는다.
엔지니어에서 빌더로: 역할의 재정의
"엔지니어는 2025년에 끝났다. 이제 모두가 빌더다." 샌프란시스코 스탠더드의 이 헤드라인은 과장이 아니다.
Boris Cherny(Claude Code 개발자)는 AI 시대의 역할을 세 가지로 재정의했다:
- 프로토타이퍼: AI로 빠르게 실험하고 가능성을 타진하는 역할
- 빌더: 프로토타입을 실제 서비스로 만드는 역할
- 그루퍼: 시스템을 지속적으로 개선하는 역할
시니어로 갈수록 이 세 역할을 동시에 오간다는 점이 핵심이다. 예를 들어, 아침에는 AI에게 "이 API 써볼 만한지 PoC 만들어줘"라고 던지고(프로토타이퍼), 오후에는 그 PoC를 제품 파이프라인에 연결하는 규칙을 설계하며(빌더), 저녁에는 오늘 발생한 예외 케이스를 분석해 하네스의 권한 규칙을 조정한다(그루퍼).
중요한 건 이 세 역할이 등급이 아니라 동시에 존재하는 레이어라는 점이다. AI 시대에 살아남는 개발자는 이 셋 중 하나만 하는 사람이 아니라, 셋을 필요에 따라 오가는 사람이다.
자동화가 아니라 증강: 아이언맨 수트의 철학
가장 중요한 구분은 '자동화(Automation)'와 '증강(Augmentation)'의 차이다.
자동화는 인간을 공장 컨베이어 벨트에서 쫓아내는 것이다. 증강은 아이언맨 수트처럼 인간이 입어서 능력을 증폭시키는 것이다. 좋은 에이전트 시스템은 후자를 추구한다. 사람의 판단을 대체하는 게 아니라, 사람이 진짜 중요한 결정에 집중할 시간을 벌어주는 게 목표다.
이 철학을 관통하는 3대 원칙:
- 튼튼한 기초 위에 쌓아라 — 코드는 최소한으로. "쓰지 않은 코드가 최고의 코드다." 하네스도 마찬가지다. 과잉 설계하지 말고, 진짜 필요한 제약만 걸어라.
- 인지적 주권을 유지하라 — 최종 판단은 항상 사람이 한다. 에이전트는 "이렇게 하자"까지 제안하지만, 실행 버튼은 사람의 손에 있다. AI에게 결정권을 넘기지 마라.
- 끊임없이 의심하고 검증하는 루프를 설계하라 — 코드 리뷰, 품질 게이트, 자동 회귀 테스트. 생성은 AI에게 맡겨도, 검증은 시스템이 강제해야 한다.
당신의 하네스는 무엇인가?
세 가지 질문으로 마무리한다.
당신은 지금 AI로 더 많이 배우고 있는가? 아니면 인식론적 부채를 쌓고 있는가? ChatGPT의 답변을 그대로 복사·붙여넣기만 하고 있다면, 당신은 학습을 AI에 외주 주고 있는 것이다. 좋은 하네스는 에이전트가 틀렸을 때 "여기 의심스럽다"고 말해준다. "동반자는 아첨꾼이 아니다"라는 원칙을 시스템에 심는 것이다.
AI의 출력을 스스로 검증할 수 있는가? 깔때기의 병목이 보여주듯, 생성은 쉬워졌지만 검증은 여전히 인간의 몫이다. 검증 능력은 경험과 기본기에서 나온다. '속 빈 빌더' — 겉은 그럴듯하지만 기본기가 없는 사람 — 이 가장 먼저 대체될 것이다.
당신만의 하네스를 만들고 있는가? 단순히 AI 도구를 쓰는 것을 넘어, 그 도구를 통제하는 시스템을 설계하고 있는가? 오픈AI 코덱스 팀의 사례처럼, 단 3명이 1,500건의 PR을 처리한 비결은 더 좋은 모델이 아니라 더 정교한 하네스였다.
1997년 딥블루와 가리 카스파로프의 체스 대결 이후, 인간과 AI의 조합(켄타우루스 체스)이 최강이었다. 코딩도 마찬가지일 것이다. AI는 당신을 대체하지 않는다. 당신을 대체하는 건 AI를 더 잘 활용하는 다른 인간일 뿐이다.
그리고 무엇보다 중요한 질문이 남는다. "코드를 처음부터 직접 쳐보며 밤새 삽질할 기회가 사라진 다음 세대 개발자들은, 그 기초와 직관을 어디서 어떻게 배워야 할까?"
이 질문에 대한 답을 찾는 게, 하네스 엔지니어링의 다음 과제일지도 모르겠다.