AI가 코드를 더 많이 써도, 개발자의 책임은 줄지 않습니다

AI 요약

AI 에이전트는 기능 구현부터 테스트, 버그 수정, 리팩터링, 문서화, 명령 실행까지 맡습니다. 덕분에 개발자가 직접 쓰는 코드는 줄어들지만, 운영 환경에서 문제가 생겼을 때 시스템을 설명하고 책임지는 사람은 여전히 개발자입니다. 글은 AI가 만든 코드라는 이유로 책임이 가벼워지는 것은 아니라고 강조합니다. 코드를 승인하거나 병합하고 배포하면 그 코드는 팀이 소유하는 시스템의 일부가 됩니다.

테스트 통과가 요구사항 충족을 보장하지는 않습니다

AI가 요구사항을 잘못 이해한 뒤 구현과 테스트를 모두 만들면, 테스트는 통과해도 기능은 틀릴 수 있습니다. 테스트는 코드가 정해진 기대에 맞게 동작하는지 확인하지만, 그 기대 자체가 올바른지는 자동으로 증명하지 않습니다. 같은 모델이 구현과 테스트를 만들면 둘 다 같은 오해를 공유할 수 있습니다. 따라서 검토는 코드뿐 아니라 요구사항 수준에서도 이뤄져야 합니다.

코드 부채와 다른 ‘이해 부채’

글은 코드가 지저분하다는 사실을 알면서 출시하는 상황을 기술 부채로 설명합니다. AI가 만든 코드에서는 다른 문제가 생길 수 있습니다. 팀이 소유한 코드인데도 왜 그런 방식으로 동작하는지 아무도 제대로 설명하지 못하는 상태입니다. 글은 이를 ‘이해 부채(understanding debt)’라고 부릅니다. 코드가 복잡하다는 문제는 눈에 보이지만, 이해가 빠져 있다는 사실은 평소에 드러나지 않습니다. AI 작업의 맥락이 사라지고 판단 근거도 기록하지 않으면, 몇 달 뒤 장애가 생겼을 때 구현 이유를 찾기 어려워집니다.

큰 작업을 나누고 계획부터 검토합니다

“구독 시스템 전체를 만들어 달라”고 한 번에 맡기기보다, 먼저 기존 결제 구조를 분석하고 변경할 파일과 위험을 설명하게 하라고 제안합니다. 계획을 검토한 뒤 데이터 모델, 결제 서비스, 테스트처럼 작업을 나누고 각 단계에서 변경 범위를 제한합니다. 작은 작업은 diff도 작아져 사람이 이해하고 검토하기 쉽습니다. 구현 전에 AI가 현재 구조와 변경 이유, 예상 위험을 설명하게 하고 승인 전에는 코드를 수정하지 않도록 하는 방법도 소개합니다. 잘못된 계획은 초기에 바로잡는 편이, 그 계획에 따라 수백 줄이 생성된 뒤 수정하는 것보다 부담이 적습니다.

코드 리뷰도 문법과 개별 줄의 정확성에만 머물러서는 안 됩니다. 결제 처리가 왜 이 모듈에서 이뤄지는지, 테스트가 실제 요구사항을 확인하는지, 데이터와 권한, 외부 API에서 어떤 실패가 생길 수 있는지 살펴야 합니다. 네트워크 시간 초과, 중복 요청, 부분 쓰기, 예상하지 못한 입력 같은 사례도 확인 대상입니다. 작업 범위가 넓거나 보안, 동시성, 데이터 마이그레이션처럼 영향이 큰 변경이라면 사람의 이해와 검토를 더 강화해야 합니다.

AI가 중요한 설계 결정을 내렸다면 그 이유도 남겨야 합니다. 주석이나 Architecture Decision Record(ADR)에 선택의 근거를 기록하면 AI 세션이 사라진 뒤에도 다음 개발자가 맥락을 파악할 수 있습니다. 글은 AI가 반복 작업과 상용구 코드를 줄이는 데 쓰일수록, 개발자의 역할은 문제 정의, 경계 설정, 아키텍처 판단, 검증, 디버깅, 유지보수로 옮겨간다고 봅니다. 코드를 생성하는 비용은 낮아져도, 이해하고 소유하는 책임까지 자동으로 줄지는 않습니다.

dev.to 반응

• @codemaster_121482 — 맞습니다. LLM은 실제 엔지니어를 대체하기보다 일을 더 쉽게 만듭니다. 상용구를 작성하고 코드를 생성하는 일은 LLM이 맡을 수 있지만, AI가 만든 코드가 운영 환경에서 문제를 일으키지 않도록 확인하는 책임은 개발자에게 있습니다. 좋은 글입니다.
  • @robertadam987_ — 저도 정확히 그렇게 봅니다. LLM은 반복 작업을 줄이고 구현을 빠르게 하는 데 유용하지만, 아키텍처와 테스트, 예외 상황, 보안, 운영 환경의 동작을 책임지는 사람은 여전히 개발자입니다. 중요한 가치는 “AI가 엔지니어를 대체한다”가 아니라, 출시할 내용을 이해하고 검증하는 한 AI가 엔지니어의 역량을 키워준다는 점입니다. 좋은 의견 감사합니다.
• @sofaliferi — “이해 부채”라는 표현이 와닿습니다. 많은 팀이 겪으면서도 그 문제를 부를 적절한 말을 찾지 못했던 것 같습니다. 좋은 글입니다.
  • @robertadam987_ — 그 표현이 공감을 얻는 이유도 그 때문이라고 생각합니다. 코드가 작동하고 테스트도 통과하지만, 시스템이 왜 그렇게 동작하는지 설명하는 사람이 줄어드는 상황을 팀은 이미 알고 있습니다. 이해 부채라고 이름 붙이면 장애가 터진 뒤에야 발견하는 대신 의식적으로 관리할 수 있습니다. 그 부분을 좋게 봐주셔서 감사합니다.
• @aidiveyt — 가드레일도 코드만큼 꼼꼼히 검증해야 합니다. 도구 호출을 막는 훅을 만들고 제대로 차단한다고 생각했는데, 예외를 던지는 훅은 차단 장치가 아니었습니다. 제 훅은 574ms 만에 건너뛰어졌고 도구가 그대로 실행됐습니다.
• @kartik-nvjk — 계속 생각하게 되는 부분은 책임 문제입니다. 에이전트가 작성한 코드가 운영 환경에서 문제를 일으켜도 배포한 사람은 여전히 인간입니다. 저는 에이전트가 쓴 코드도 주니어 개발자가 쓴 코드처럼 다루기 시작했습니다. 꼼꼼히 검토하고 책임자를 분명히 정해야 합니다. 가장 많은 문제를 잡아내는 평가는 린터가 아니라 “사람이 썼어도 이 코드를 병합하겠는가?”라는 질문입니다. 에이전트가 실수했을 때 책임 공백을 어떻게 다루시나요?

원문: dev.to / 번역·요약: Trawling