AI 코딩 에이전트가 코드를 쓴다고 해서 개발자의 일이 사라지는 것은 아니다. 정확히는, 개발자의 일이 코드 바깥으로 밀려난다.

예전에는 개발자의 실력을 구현 속도에서 먼저 확인했다. 요구사항을 읽고, 설계를 세우고, 코드를 쓰고, 테스트를 통과시키는 속도 말이다. 지금은 에이전트가 여러 파일을 읽고, 변경하고, 테스트와 린트를 실행한 뒤 PR까지 만들 수 있다. 구현만 놓고 보면 사람의 손이 병목이 아니게 되는 순간이 분명히 늘고 있다.

그렇다고 개발이 자동화되는 것은 아니다. 오히려 구현이 빨라진 만큼, 이전에는 코드 작성 과정에 흩어져 있던 판단이 더 선명한 병목으로 드러난다. 무엇을 만들지, 어디까지 바꿔도 되는지, 무엇을 성공으로 볼지, 어떤 실패는 절대 허용할 수 없는지. 에이전트는 이 질문에 대한 답을 스스로 갖고 있지 않다.

그래서 AI 코딩 에이전트 시대의 개발자는 코더라기보다 에이전트가 일할 수 있는 시스템을 설계하는 사람에 가까워진다.

코드를 시키는 일보다, 일을 정의하는 일이 어려워진다#

에이전트에게 “로그인 화면을 개선해 줘”라고 말하면 그럴듯한 결과는 금방 나온다. 하지만 그 안에는 아직 결정되지 않은 질문이 너무 많다.

  • 기존 인증 흐름은 유지해야 하는가?
  • 실패 메시지는 어떤 상황에서, 누구에게 보여야 하는가?
  • 모바일 접근성과 키보드 탐색은 성공 조건에 포함되는가?
  • 새 UI는 어떤 지표를 개선해야 하는가?
  • 장애가 발생했을 때 되돌릴 수 있는가?

사람이 코드를 직접 쓸 때도 이 질문들은 존재했다. 다만 구현하면서 머릿속에서 함께 풀었다. 에이전트에게 작업을 넘기면 이 암묵지가 사라진다. 에이전트가 볼 수 없는 맥락은, 사실상 존재하지 않는 맥락이 된다.

그래서 좋은 프롬프트는 장황한 요청문이 아니다. 좋은 프롬프트는 이미 정리된 제품 의도와 기술적 제약의 압축본이다. 수용 기준, 관련 문서, 변경 가능 범위, 검증 명령, 금지해야 할 선택지가 저장소와 작업 지시에 드러나 있어야 한다.

개발자의 첫 번째 역할은 에이전트에게 답을 대신 주는 것이 아니라, 좋은 답을 만들 수 있는 문제의 경계를 만드는 일이다.

테스트가 있어도, 판단은 끝나지 않는다#

에이전트는 테스트를 실행하고 실패를 고친다. 이 능력은 중요하다. 실행 결과라는 현실의 피드백을 보고 다음 행동을 바꿀 수 있기 때문이다.

하지만 테스트 통과는 머지 승인과 같은 말이 아니다.

테스트는 대부분 “작성된 기대”를 검증한다. 반면 실제 운영에서 중요한 문제는 종종 기대 바깥에 있다. 이미 있는 컴포넌트를 또 만들지는 않았는지, 에러를 조용히 삼키지는 않았는지, 도메인 규칙을 UI에 흩뜨리지는 않았는지, 지금의 편한 구현이 다음 변경을 어렵게 만들지는 않았는지 같은 문제다.

AI가 만든 코드는 특히 그럴듯해서 위험하다. 타입도 맞고, 테스트도 통과하고, 이름도 자연스럽다. 하지만 코드베이스의 오래된 약속을 깨거나, 제품이 감당할 수 없는 트레이드오프를 선택할 수 있다.

그러므로 리뷰의 역할은 “AI가 실수했는지 잡아내는 마지막 관문”에 그치면 안 된다. 리뷰에서 반복해서 발견되는 문제는 다음번에도 사람이 다시 찾지 않도록 바꿔야 한다.

  • 누락되는 입력 검증은 타입·스키마·경계 검사로.
  • 반복되는 스타일 논쟁은 formatter·lint rule로.
  • 계층 침범은 구조 테스트로.
  • 배포 후에야 드러나는 성능 문제는 SLO와 관측성으로.
  • 도메인 해석의 흔들림은 ADR과 예시로.

좋은 리뷰는 코멘트를 남기는 일이 아니라, 다음 리뷰에서 같은 코멘트가 필요 없게 만드는 일이다.

에이전트가 강할수록 저장소의 품질이 중요해진다#

AI 코딩 에이전트는 좋은 코드베이스에서 더 잘 일한다. 이는 놀랍지 않다. 새로 온 동료도 비슷하기 때문이다.

어디서 시작해야 하는지 알려 주는 짧은 지도, 도메인별로 분리된 문서, 실제로 실행되는 테스트 명령, 의도를 설명하는 ADR, 변경 이력, 재현 가능한 개발 환경. 이런 것들이 있으면 에이전트는 추측 대신 탐색할 수 있다.

반대로 문서가 낡아 있고, 규칙이 사람의 머릿속이나 메신저에만 있고, 테스트가 불안정하며, 로컬 환경이 재현되지 않는다면 에이전트는 빈칸을 그럴듯한 추측으로 채운다. 그 결과는 빠르게 만들어진 코드가 아니라 빠르게 쌓이는 불확실성이다.

여기서 문서는 지식 저장소 이상의 의미를 갖는다. 에이전트가 저장소를 이해하기 위한 인터페이스다. AGENTS.md 하나에 모든 규칙을 몰아넣는 것보다, 짧은 시작점에서 필요한 문서·규칙·검증 도구로 찾아갈 수 있게 만드는 편이 낫다.

사람이 읽기 좋은 문서 구조와 에이전트가 탐색하기 좋은 문서 구조는 크게 다르지 않다. 둘 다 최신이어야 하고, 서로 연결되어야 하며, 실행 가능한 사실을 담아야 한다.

개발자의 산출물은 코드에서 harness로 넓어진다#

이제 개발자가 남기는 산출물은 애플리케이션 코드만이 아니다.

  • 에이전트가 실패하지 않도록 하는 제약
  • 에이전트가 성공을 확인할 수 있는 테스트
  • 에이전트가 맥락을 찾을 수 있는 문서 지도
  • 에이전트가 실행 중 이상을 발견할 수 있는 로그·메트릭·트레이스
  • 에이전트가 넘지 말아야 할 권한과 배포 경계
  • 사람이 최종적으로 승인할 수 있게 만드는 작고 검증 가능한 변경 단위

이 묶음을 흔히 harness라고 부른다. 중요한 것은 에이전트를 세게 통제하는 것이 아니다. 에이전트가 좋은 방향으로 빠르게 움직이고, 잘못된 방향으로 갈 때는 스스로 또는 조기에 멈출 수 있게 만드는 것이다.

이 관점에서는 에이전트가 낸 결과가 기대에 못 미쳤을 때 “프롬프트를 더 잘 써야겠다”로 끝나지 않는다. 먼저 묻는다. 이 실패를 다음에도 반복하지 않으려면 무엇을 저장소에 추가해야 하는가? 테스트인가, 규칙인가, 도메인 예시인가, 도구 권한인가, 관측성인가?

이 질문에 답하는 과정에서 개발자의 판단은 일회성 지시가 아니라 팀과 에이전트가 함께 쓰는 시스템의 일부가 된다.

결론: 좋은 개발자는 더 적게 타이핑할 수 있다#

AI 코딩 에이전트가 늘수록 개발자는 더 적게 타이핑할 수 있다. 하지만 더 적게 생각해도 되는 것은 아니다.

오히려 좋은 개발자는 구현을 넘기는 대신 더 어려운 일을 맡는다. 문제를 작고 검증 가능하게 정의하고, 제품·도메인·아키텍처의 맥락을 기록하고, 품질 기준을 기계가 확인할 수 있는 형태로 바꾸고, 최종 결과가 사용자와 시스템에 미칠 영향을 책임진다.

AI가 코드를 만드는 시대에 개발자의 경쟁력은 얼마나 많은 코드를 작성했는지가 아니라, 얼마나 좋은 판단을 반복 가능한 시스템으로 남겼는가에 달려 있다.

참고 자료#