AI가 코드를 쓴다. 그럼 사람은 뭘 하나?
지금 대부분의 팀이 겪는 긴장감은 단순하다. AI가 코드를 생성하는 속도는 올라갔는데, 그 코드를 누가 얼마나 이해해야 하는지에 대한 기준이 없다. 속도를 포기하자니 아깝고, 이해를 포기하자니 불안하다. 이 둘 사이에서 팀은 지금 실질적인 역할 설계를 요구받고 있다.
두 진영, 둘 다 틀렸다
dev.to에 올라온 'Proof of Understanding' 글은 이 긴장을 두 진영으로 정리한다. 첫 번째는 '실용적 급진주의자'들이다. 이들의 주장은 명쾌하다: 사람이 루프 안에 있으면 AI의 속도가 상쇄된다. 가드레일, 테스트, 품질 게이트만 잘 설계하면 된다. 코드 내부를 사람이 이해할 필요는 없다.
두 번째는 '서명자들'이다. AI가 코드를 생성하더라도 개발자가 그 로직을 이해하고, 그 이해를 문서로 증명하고, 팀 앞에서 방어한 뒤에만 머지를 허용해야 한다는 입장이다. '이해의 증명(Proof of Understanding)'이라는 개념 자체는 설득력 있다.
문제는 둘 다 현실에서 실패한다는 것이다. 첫 번째 진영은 테스트와 가드레일이 '이미 누군가가 생각한 실패'만 잡는다는 사실을 외면한다. 어떤 실패가 존재하는지를 상상하는 능력 자체를 AI에 아웃소싱할 수는 없다. 두 번째 진영은 이상적이지만 비현실적이다. 10년 된 핀테크 시스템을 완전히 이해하는 사람은 없다. 모든 PR에 이해 증명을 요구하면, 결국 AI가 코드와 함께 설명 문서까지 생성하고, 사람은 서명만 하는 형식으로 전락한다.
이해는 예산이다 — 어디에 쓸지 결정하라
세 번째 길은 이 질문에서 시작한다: 이해의 비용을 어디에 집중할 것인가?
'Proof of Understanding' 글이 제안하는 개념이 바로 폴트라인(fault lines), 즉 시스템의 하중을 지탱하는 이음새다. 국소적 변경이 비국소적 결과를 낳는 지점들이다. 구체적으로는 이런 곳들이다:
- 팬아웃이 높은 함수: 40군데에서 호출되는 함수에서의 잘못된 결정은 전체로 전파된다.
- 신뢰 경계: 인증 체크, 입력 유효성 검증, 권한 게이트.
- 상태 전이: DB 쓰기, 큐 발행, 금융 트랜잭션, 부작용 있는 외부 API 호출.
- 불변식 선언: 항상 참이라고 주장하는 지점, 그리고 그 가정 위에 돌아가는 다운스트림 코드.
- 동시성과 공유 상태: 락, 트랜잭션, 멱등성 키, 재시도 로직.
- 계약 정의: API 스키마, DB 마이그레이션, 퍼블릭 함수 시그니처.
반대로 이 목록에서 빠지는 것들이 있다. 대부분의 CRUD 핸들러, 직렬화, 설정 와이어링, UI 렌더링, 1:1 데이터 변환. 일반적인 코드베이스의 70~85%가 여기에 해당한다. 이 영역은 AI가 알아서 처리하면 된다.
결론은 이렇다: 기계는 모든 코드를 작성하고, 사람은 이음새를 이해한다.
시니어의 역할은 '짓는 것'에서 '고르는 것'으로
같은 맥락에서 dev.to의 또 다른 글('Taste is the new 10x')은 시니어 개발자의 역할 변화를 직설적으로 짚는다. AI는 이제 주니어 수준의 코드를 거의 무료로 생성한다. 하루가 걸리던 기능을 몇 분 만에 뽑아낸다. 그런데 '작동하는 코드'와 '출시할 수 있는 코드'는 다르다.
그 간격을 메우는 것이 '테이스트(taste)', 즉 판단력이다. 이건 감이 아니다. 수년간 시스템이 성공하고 실패하는 과정을 보면서 축적된 패턴 인식이다. 200줄짜리 추상화가 지금은 편하지만 6개월 후에 어떤 부채를 만들지 아는 것, AI 출력이 해피 패스만 커버하고 실제 사용자가 맞닥뜨릴 엣지 케이스를 전부 빠뜨렸다는 걸 느끼는 것, API 표면에서 마찰을 버그 리포트 전에 감지하는 것.
이 글이 지적하는 불편한 진실이 있다. 일부 시니어 엔지니어들은 여기서 어려움을 겪을 것이다. 지식이 부족해서가 아니라, 편집자적 감각을 한 번도 훈련하지 않았기 때문이다. 그들은 만드는 사람이었지, 고르는 사람이 아니었다. 그리고 업계는 20년간 만드는 것에 보상해왔다.
2025년의 10x 엔지니어는 코드를 10배 더 많이 쓰는 사람이 아니다. 나쁜 코드가 10배 더 적게 출시되도록 막는 사람이다.
자율 에이전트가 실패하는 진짜 이유
6개월간 자율 코딩 에이전트를 직접 구축한 개발자의 분석('Why Autonomous Coding Agents Keep Failing')은 왜 사람의 개입 지점 설계가 필요한지를 아키텍처 레벨에서 보여준다. 에이전트 실패의 원인은 모델 성능이 아니라 구조 문제다. 다섯 가지 클러스터로 정리된다.
- 리페어 루프 부재: 단일 패스(프롬프트 → 코드 → 완료) 구조는 데모일 뿐이다. 실제 코드는 첫 번째 시도에서 작동하지 않는다. 실패를 분류하고 타깃화된 수정 프롬프트를 구성하는 구조화된 루프가 없으면 에이전트는 도구가 아니다.
- 취약한 테스트: 에이전트가 생성한 테스트가 잘못된 구현을 통과시킨다. 변이 테스트 없이는 테스트가 있어도 없는 것과 같다.
- 워크스페이스 인식 부재: 프로젝트 구조, 모듈명, 올바른 테스트 커맨드를 모르는 에이전트는 추측하거나 계속 묻는다. 둘 다 용납하기 어렵다.
- 롤백 없음: 파일을 수정하다 실패하면 워크스페이스가 망가진 채로 남는다.
git stash를 활용한 스냅샷-복구 메커니즘은 선택이 아니라 필수다. - LLM 프로바이더 불안정성: 단일 프로바이더에 의존하면 레이트 리밋 하나로 전체 태스크가 멈춘다. 카스케이드 구조와 일시적 제한/일별 소진 구분이 필요하다.
여기서 가장 주목할 포인트는 결정론(determinism)이다. 같은 태스크를 두 번 실행해서 같은 결과가 나오지 않는 에이전트는 CI/CD 파이프라인에 넣을 수 없다. 디버깅도 불가능하다. 신뢰도 쌓이지 않는다. 성공한 LLM 인터랙션을 레코드-리플레이하는 방식은 이 문제를 동시에 해결하면서 감사 가능한 이력까지 제공한다.
팀 설계로 가져오면
세 글이 가리키는 방향은 하나로 수렴한다: AI 코드 시대에 사람의 역할은 양을 줄이는 게 아니라 위치를 바꾸는 것이다.
실무적으로 지금 당장 팀에 적용할 수 있는 프레임은 이렇다.
- 폴트라인 목록을 팀 문서로 만들어라. 인증, DB 스키마, 외부 API 계약, 동시성 처리 — 이 지점에 닿는 PR은 사람의 실질적 이해와 검토가 필수다. 나머지는 AI 리뷰와 빠른 휴먼 글랜스로 충분하다.
- 테이스트는 훈련 가능하다. 코드를 쓰는 것보다 더 많은 코드를 리뷰하게 하라. 1년 이상 프로덕션에서 살아남은 코드를 분석하게 하라. AI 출력을 그냥 수용하지 말고 심문하게 하라: "이걸 왜 바꾸고 싶은가? 이 판단을 한 문장으로 설명할 수 있는가?"
- 에이전트 루프를 설계할 때 사람의 개입 지점을 명시하라. 리페어 루프의 최대 시도 횟수, 롤백 트리거, 폴트라인에 닿는 변경의 자동 플래그 — 이것들은 에이전트 아키텍처가 아니라 팀의 역할 설계다.
AI와 협업 모드로 일한다는 것
'Proof of Understanding' 글은 마지막에 중요한 구분을 한다. 자율 모드(autopilot) vs. 협업 모드(collaboration). 자율 모드는 AI에게 목표를 주고 결과를 받는다. 사람은 경계에 있을 뿐 루프 안에 없다. 협업 모드는 AI를 테이블에 앉은 새 동료로 본다. 유능하지만, 도전받고 방향을 교정해줄 유능한 사람이 맞은편에 있어야 최선의 결과를 낸다.
향후 5~10년은 협업 모드다. 그리고 협업 모드에서 AI와 인간 동료 사이의 핵심 차이는 이해관계(stake)다. 사람 동료의 반론은 그것을 꺼내는 데 비용이 들었기 때문에 신호가 된다. AI의 동의도, 반론도, 비용이 없다. 그래서 AI가 틀렸을 때를 감지하고, 프레임을 바꾸고, 확신 있게 잘못된 방향을 되돌리는 능력 — 이것이 앞으로 팀에서 가장 비싼 역량이 된다.
속도는 이미 올려줬다. 이제 팀이 설계해야 하는 건 그 속도 안에서 사람이 설 자리다.