AI가 코드를 만드는 시대, 개발자는 무엇을 검증해야 할까

게시 2026/06/25

By woolam

조회 30 분읽는 시간

오늘 생각을 정리하게 된 계기

AI 시대에 전문성이 어떻게 변하는지 다룬 발표를 보고 나서, 한동안 머릿속을 맴도는 문장이 하나 있었다.

AI 시대의 전문성은 “직접 만드는 능력”에서 “AI가 만든 결과를 검증하고, 방향을 정하고, 책임지는 능력”으로 이동한다.

처음엔 당연한 얘기 아닌가 싶었다. 그런데 최근 프로젝트에서 AI로 코드를 만들고, PR을 올리고, 리뷰하는 과정을 직접 겪으면서 이 문장이 점점 구체적으로 와닿기 시작했다.

코딩 속도가 빨라지는 것은 사실이다. 그런데 속도가 빨라진다고 시스템이 좋아지는 건 아니다. 오히려 빠르게 만들어진 코드가 검증 없이 머지되면, 그 비용은 나중에 더 크게 돌아온다.

이번 TIL은 단순히 “AI가 좋다, 나쁘다”를 따지는 글이 아니다. 백엔드 개발자로서, AI가 만든 결과물을 어떻게 검증하고 어떤 구조 안에서 다뤄야 하는지 정리한 글이다.

AI 도입이 바로 생산성 향상으로 이어지지 않는 이유

회사에서 ChatGPT나 Claude 같은 AI 도구를 도입하고 교육을 진행해도, 바로 업무 생산성이 좋아지는 경우는 드물다. 나도 처음엔 “이제 금방 만들겠지”라고 생각했지만, 실제로는 그렇게 단순하지 않았다.

AI를 업무에 연결하기 어려운 이유는 크게 두 가지다.

Input 문제: AI는 회사의 세부 맥락을 모른다. 우리 프로젝트의 도메인 정책, 코드 컨벤션, 아키텍처 규칙 같은 것들은 프롬프트에 일일이 설명해야 한다.
Output 문제: AI가 만든 결과물을 다시 기존 업무 도구에 복사·붙여넣기해야 한다. Jira에 이슈를 옮기고, GitHub에 커밋하고, Notion에 문서를 정리하는 과정은 여전히 수작업이다.

MCP, Slack, Notion, Jira, GitHub 같은 사내 시스템과 연동이 갖춰지면 AI가 실제 업무 흐름 안으로 들어올 수 있다. 하지만 이때도 단순 사용량이나 토큰 소비량이 아니라, 실제 산출물과 성과를 기준으로 효과를 평가해야 한다. “AI를 많이 썼다”는 것과 “일이 잘 됐다”는 것은 다른 이야기다.

AI J Curve Trap

AI를 도입하면 바로 생산성이 올라가는 것이 아니라, 적응 과정에서 오히려 일시적으로 생산성이 떨어지거나 혼란이 생길 수 있다. 이때 발생하는 비용은 세 가지로 나뉜다.

Learning Curve: AI 도구를 익히고, 프롬프트를 작성하고, 결과를 해석하는 데 드는 학습 비용
Verification Tax: AI 결과물이 맞는지 확인하고 수정하는 데 드는 검증 비용
Pipeline Adaptation: 기존 개발 파이프라인과 워크플로우를 AI에 맞게 재구성하는 비용

이 중에서 특히 Verification Tax가 과소평가되기 쉽다.

AI가 코드를 만들고 문서를 만들 수는 있다. 하지만 그 결과가 맞는지 검증하고, 틀렸을 때 책임지는 일은 여전히 사람에게 남는다. 백엔드에서는 이게 더 뼈아프다. AI가 API 하나를 만들어줬는데, 그 API가 기존 도메인 경계를 침범하고 있거나, 트랜잭션 범위가 잘못 잡혀 있거나, 예외 처리가 빠져 있다면, 결국 사람이 한 줄씩 검증해야 한다. 코드를 만드는 시간은 줄었는데, 검증하는 시간은 오히려 늘어날 수 있다.

AI 시대에 커지는 세 가지 부채

기술부채: 국소최적화, 전역무지

AI가 만든 코드는 작은 단위에서는 잘 동작한다. 함수 하나, 클래스 하나 단위에서 보면 깔끔하고 논리적이다. 하지만 전체 시스템 구조, 운영 환경, 장기 유지보수성을 고려하지 못하는 경우가 많다.

이 현상을 한마디로 표현하면 “국소최적화, 전역무지”다.

백엔드 개발에서 이런 문제는 익숙한 모습으로 드러난다.

도메인 경계가 흐려지는 코드: 주문 서비스 안에 결제 로직이 섞이거나, 알림 발송 코드가 비즈니스 서비스에 직접 들어간다.
임시 구현이 그대로 운영 코드가 되는 문제: Stub이나 Fake로 먼저 처리한 부분이 교체 시점을 놓치고 프로덕션에 남는다.
테스트 없이 빠르게 추가된 기능: AI가 빠르게 만들어준 기능이 검증 없이 머지되면, 나중에 변경할 때 어디가 깨질지 예측할 수 없다.
중복된 DTO나 책임이 섞인 서비스: AI가 매번 새로운 DTO를 만들어주는 바람에, 동일한 데이터를 표현하는 클래스가 여러 개 생긴다.

이런 부채는 눈에 바로 보이지 않는다. 기능은 돌아가고 테스트도 통과하는데, 시스템이 점점 복잡해지고 변경 비용이 올라간다.

인지부채: 인지적 항복의 위험

AI가 만든 코드와 문서를 사람이 충분히 이해하지 못한 채 받아들이면, 팀이 시스템을 함께 이해하지 못하게 된다.

이 상태가 반복되면 “인지적 항복”이 발생한다. AI 결과물이 그럴듯하다는 이유만으로 충분히 검토하지 않고 받아들이는 상태다. “AI가 만들었으니까 맞겠지”라는 무의식적 신뢰가 쌓이면, 팀 전체의 시스템 이해도가 천천히 무너진다.

이게 가장 위험해지는 순간은 장애가 발생했을 때다.

시스템 맥락을 이해하지 못하는 상태에서 AI에게 “이 장애 원인 분석해줘”라고 물으면, AI는 여러 가지 가능성을 제시한다. 그런데 그중 무엇이 실제 원인인지 판단하려면, 결국 시스템이 왜 이런 구조로 만들어졌는지, 어떤 트레이드오프가 있었는지 알아야 한다. 맥락 없이는 AI의 제안조차 평가할 수 없다.

의도부채: 왜 이렇게 만들었는지 사라지는 문제

의도부채는 왜 그렇게 만들었는지, 어떤 제약과 트레이드오프가 있었는지가 사라지는 문제다.

예를 들어 다음 질문에 아무도 답하지 못하는 상태를 생각해보자.

왜 이 API는 v1과 v2로 나눴는가?
왜 이 기능은 Stub/Fake로 먼저 처리했는가?
왜 이 정책은 요구사항 문서가 아니라 별도 정책 문서에 남겼는가?
왜 특정 상태값이나 예외 흐름을 명시적으로 분리했는가?

AI와 여러 에이전트를 사용하면, 많은 결정이 프롬프트 안에서만 오가고 사라질 수 있다. 대화가 끝나면 맥락도 함께 사라진다. 결국 남는 것은 최종 코드뿐이고, 그 코드가 왜 이런 형태인지는 아무도 설명하지 못한다.

그래서 최종 코드뿐 아니라 결정의 이유와 트레이드오프를 문서에 남겨야 한다. PR 설명, 이슈 코멘트, 위키 문서 어디든 좋다. 중요한 것은 “무엇을 만들었는가”가 아니라 “왜 이렇게 만들었는가”를 기록하는 것이다.

생산보다 검증이 중요해진다

이 발표에서 가장 인상 깊었던 메시지는 이것이다.

AI 시대에 사람의 메인 작업은 생산에서 검증으로 이동한다.

과거에는 사람이 생산하고 사람이 검증했다. 이제는 AI가 생산한 결과를 사람이 검증 가능한 구조 안에 넣어야 한다.

검증 레이어는 크게 세 가지로 나눌 수 있다.

검증 유형	설명
Binary Checks	테스트 케이스처럼 통과/실패가 명확한 검증. 맞거나 틀리거나, 둘 중 하나다.
Quantitative Metrics	처리량, 지연시간, 성능 지표처럼 숫자로 측정되는 검증. 기준값이 있고, 넘으면 문제다.
Qualitative Rubrics	아키텍처 품질, UX 직관성, 코드 일관성처럼 정성 평가가 필요한 검증. 사람의 판단이 필요하다.

백엔드 개발 관점에서 이 세 가지 검증을 실제로 구현하는 수단들을 나열하면 다음과 같다.

테스트 코드: 단위 테스트, 통합 테스트, 인수 테스트
정적 분석: 코드 품질, 보안 취약점, 코드 스타일 검사
코드 리뷰 기준: PR 체크리스트, 리뷰 가이드라인
아키텍처 규칙: 패키지 의존성 방향, 레이어 경계, 도메인 분리 규칙
API 명세: 요청/응답 스키마, 에러 코드, 버전 호환성
GitHub Issue 기준: 이슈 작성 템플릿, 완료 조건 정의
PR 체크리스트: 머지 전 확인 항목, 테스트 통과 여부
운영 모니터링: 에러율, 응답 시간, 리소스 사용률
장애 대응 시나리오: 롤백 절차, 비상 연락 체계, 장애 등급 기준
LLM as Judge 기반 정성 평가: AI가 만든 결과물을 다른 AI가 평가하는 구조

핵심은 AI가 만든 모든 중간 과정을 사람이 전부 읽는 것이 아니다. 최종 산출물이 통과해야 할 검증 기준을 명확히 만드는 것이다.

AI가 코드를 100줄 만들었을 때, 그 100줄을 한 줄씩 다 읽는 것보다, “이 코드가 통과해야 할 테스트는 무엇인가”, “이 API가 만족해야 할 스펙은 무엇인가”, “이 변경이 기존 아키텍처 규칙을 위반하지 않는가”를 기준으로 검증하는 것이 더 효과적이다.

AI-native하게 일한다는 것

AI-native 회사는 단순히 AI 도구를 많이 쓰는 회사가 아니다. 다음 세 가지 조건을 갖춰야 한다.

1. Queryable

회사의 문서, 회의록, 결정 사항, 정책이 AI가 검색하고 참조할 수 있는 형태여야 한다. 머릿속에만 있거나 슬랙 대화에 묻혀 있으면, AI는 그 맥락을 활용할 수 없다.

2. Closed Loop

이전 시도의 결과가 다음 시도의 입력으로 이어져야 한다. AI에게 같은 질문을 매번 처음부터 설명하는 상태라면, 루프가 아직 닫히지 않았다.

3. Self-improving

반복적으로 더 나은 시도를 할 수 있어야 한다. 지난번 장애에서 배운 점이 다음 설계에 반영되고, 리뷰에서 지적된 패턴이 컨벤션 문서에 추가되는 흐름이 있어야 한다.

이 세 가지를 가능하게 만드는 핵심은 SSOT(Single Source of Truth)다. 하나의 결정에 대해 하나의 출처만 존재해야, AI든 사람이든 같은 근거를 바탕으로 판단할 수 있다.

하지만 현실에서는 요구사항, 정책, 스펙, GitHub Issue, Wiki, PR 내용이 쉽게 파편화된다. 같은 결정인데 위키에는 A라고 적혀 있고, 이슈에는 B라고 적혀 있고, 코드에는 C로 구현되어 있는 상황이 생긴다.

현재 진행 중인 프로젝트에서도 이 문제를 의식하면서 문서화 방식을 정리하고 있다.

GitHub Wiki: 전체 아키텍처, 도메인 설계, 기술 결정 기록
요구사항 문서: 기능별 요구사항과 수용 기준
정책 문서: 비즈니스 정책, 검증 규칙, 예외 처리 기준
API 스펙: 엔드포인트, 요청/응답 스키마, 에러 코드
Issue: 작업 단위 정의, 완료 조건
PR: 변경 내용, 변경 이유, 리뷰 포인트
코드 컨벤션: 네이밍, 패키지 구조, 레이어 규칙
AI Workflow 문서: AI 에이전트가 참조할 수 있는 프로젝트 맥락

중요한 것은 문서를 많이 만드는 것이 아니다. 문서들이 서로 같은 결정을 바라보게 만드는 것이다. 위키에서 정한 도메인 경계가 API 스펙에도 반영되고, 그 기준이 코드 리뷰에서도 검증되는 구조가 되어야 한다.

암묵지를 포착하는 방법

AI에게 좋은 결과를 얻으려면 명시적인 요구사항뿐 아니라, 팀과 개인이 지닌 암묵지도 필요하다. 문제는 암묵지가 내가 알고 있지만, 내가 안다는 사실조차 모르는 지식인 경우가 많다는 것이다.

“왜 이 서비스는 비동기로 처리하지 않았어요?”라는 질문을 받으면, “아, 그건 초기에 트래픽이 적어서 동기로 충분했고, 비동기로 전환하면 메시지 큐 운영 비용이 생기니까…“라고 답한다. 이 답변 자체가 암묵지다. 코드 어디에도 적혀 있지 않지만, 설계에 영향을 준 결정이다.

이런 암묵지를 끌어내는 데 AI를 활용할 수 있다. AI를 단순 답변자가 아니라 적극적으로 질문하는 역할로 쓴다.

AI가 계획을 두고 집요하게 질문한다. “이 API는 왜 POST인가요?”, “이 검증은 서비스 레이어에서 하는 이유가 있나요?”
사용자는 의도와 제약을 답한다.
그 과정에서 암묵지가 자연스럽게 문서화된다.
다음 AI 세션이나 다른 에이전트도 그 문서를 재활용할 수 있다.

이 방식은 GitHub Wiki, Issue, 정책, 스펙을 정리할 때도 적용할 수 있다. 단순히 “프롬프트를 잘 쓰는 것”보다, “결정의 이유와 제약을 남기는 것”이 더 중요하다.

AI 시대에 필요한 개발자의 능력

발표를 보면서 정리한, AI 시대에 개발자에게 필요한 능력은 다음과 같다.

큰 문제를 작은 작업 단위로 쪼개는 능력. AI는 한 번에 큰 문제를 풀지 못한다. “주문 시스템을 만들어줘”보다 “주문 생성 API의 요청 검증 로직을 만들어줘”가 훨씬 좋은 결과를 낸다. 문제를 적절한 크기로 분해하는 능력이 AI 활용의 출발점이다.

AI 결과의 실패를 빠르게 판별하는 능력. AI가 만든 코드가 컴파일되고 테스트를 통과해도, 도메인 로직이 틀릴 수 있다. “이건 아닌데”를 빠르게 감지하려면 도메인 지식과 시스템 이해가 필요하다.

여러 도구와 에이전트가 실제로 일이 되게 만드는 구조를 설계하는 능력. AI 도구를 하나 쓰는 것과, 여러 AI 에이전트가 협력해서 하나의 워크플로우를 완성하게 만드는 것은 차원이 다르다. 이건 결국 시스템 설계 능력이다.

짧은 시간 안에 많은 맥락을 파악하는 능력. AI가 코드를 빠르게 만들수록, 리뷰어는 더 많은 양의 코드를 더 빠르게 파악해야 한다. 핵심을 빨리 찾는 능력이 중요해진다.

무엇을 만들지 않을지 결정하는 취향과 판단력. AI 덕분에 만드는 비용이 줄어들면, “만들 수 있으니까 만들자”는 유혹이 커진다. 하지만 기능을 많이 추가하는 것이 좋은 제품을 만드는 것은 아니다. 제품의 방향성과 시스템의 일관성에 맞는 선택을 하는 능력, 즉 무엇을 하지 않을지 결정하는 판단력이 오히려 더 필요해진다.

전문성은 사라지지 않는다

AI가 많은 일을 대신해도 전문성은 사라지지 않는다. 오히려 더 중요해진다.

그 이유는 세 가지다.

AI가 만든 그럴듯한 가짜를 걸러내야 한다. AI의 결과물은 형식적으로 완벽해 보일 수 있다. 하지만 도메인 정책에 맞지 않거나, 엣지 케이스를 놓치고 있을 수 있다. 이걸 걸러내려면 해당 도메인에 대한 깊은 이해가 필요하다.
어려운 결정은 여전히 사람에게 올라온다. “이 API를 하위 호환을 깨고 v2로 전환할 것인가, 아니면 v1을 유지하면서 점진적으로 마이그레이션할 것인가?” 같은 결정은 AI가 대신 내려줄 수 없다.
실패했을 때 책임지고 수습할 수 있는 주체는 사람이다. 장애가 나면 롤백을 결정하고, 원인을 분석하고, 재발 방지 대책을 세우는 건 결국 사람이다.

개발자 관점에서 더 구체적으로 정리하면 이렇다.

AI가 코드를 만들 수는 있지만, 그 코드가 도메인 정책에 맞는지는 사람이 판단해야 한다.
AI가 API를 만들 수는 있지만, 버저닝과 호환성 책임은 사람이 져야 한다.
AI가 테스트를 만들 수는 있지만, 무엇을 검증해야 하는지는 사람이 정해야 한다.
AI가 문서를 만들 수는 있지만, 결정의 의도와 맥락은 사람이 남겨야 한다.

내가 프로젝트에서 적용해볼 점

이번 발표를 보고, 현재 진행 중인 프로젝트에서 다음 네 가지를 더 의식적으로 챙기려고 한다.

1. GitHub Wiki, Issue, Spec, Policy, PR 흐름을 더 명확히 연결하기. 위키에 정한 도메인 경계가 이슈의 작업 범위에 반영되고, 그 이슈가 PR의 변경 범위와 일치하는지 확인하는 흐름을 만들겠다. 문서가 따로 놀지 않도록.

2. Stub/Fake를 사용할 때 왜 임시 구현인지 기록하기. 인터페이스 기반 개발에서 Stub이나 Fake를 먼저 만드는 건 좋은 방식이다. 하지만 왜 임시인지, 언제 실제 구현으로 교체할 것인지, 어떤 제약이 있는지를 코드 주석이나 이슈에 남겨야 한다. 안 그러면 임시 코드가 영원히 남는다.

3. API 버저닝이나 정책 결정의 이유를 남기기. “v1에서 v2로 나눈 이유”, “이 검증을 서비스 레이어에서 하는 이유” 같은 결정의 배경을 PR 설명이나 위키에 기록하겠다. 나중에 이 코드를 만진 사람이 “왜?”를 알 수 있도록.

4. AI가 만든 결과를 그대로 믿지 않고 테스트와 리뷰 기준으로 검증하기. AI가 만든 코드라도 PR 체크리스트를 통과해야 하고, 테스트를 작성해야 하고, 아키텍처 규칙을 지켜야 한다. AI가 만들었다고 검증 기준이 낮아지면 안 된다.

오늘 배운 점

AI 시대의 전문성은 사라지는 것이 아니라 이동한다. 직접 모든 것을 만드는 능력에서, AI가 일할 수 있는 구조를 만들고 결과를 검증하며 책임지는 능력으로.
AI 도입은 바로 생산성 향상으로 이어지지 않는다. Verification Tax를 과소평가하면 안 된다.
기술부채, 인지부채, 의도부채는 AI 시대에 더 빠르게 쌓일 수 있다. 특히 인지적 항복을 경계해야 한다.
좋은 개발자는 코드를 많이 직접 작성하는 사람을 넘어, AI가 코드를 작성해도 시스템이 망가지지 않도록 검증 구조와 아키텍처 경계를 설계하는 사람이 되어야 한다.
프롬프트를 잘 쓰는 것보다, 결정의 이유와 제약을 남기는 것이 더 중요하다.

AI, Backend