AI 한테 시켰는데 정답 같아 보였다.

2 주 뒤. 프로덕션 에서 *그 코드가 9일간 *조용히 묻혔다. 사용자 게시판 에 “빈 화면” 글이 3 건 올라온 후에야 진단 시작.

코드 자체 틀린 데 없었다. 다만 내 시스템 의 *5 월 17일 사고 와 맞물려 있다는 사실 을 AI 는 *몰랐다. 내가 *알려주지 않았으니까.

이 글은 2026 년 현재 AI 코딩 도구가 *진짜 잘하는 것 과 *진짜 못 하는 것 을 18 시간의 사고 추적 경험 과 함께 정리한다. 그리고 AI 가 작성한 코드가 *쓰레기 코드 로 *변질 되지 않게 하는 5 가지 *합의 가능한 기준** 을 *시니어 백엔드 개발자 의 현실적 시각 에서 풀어본다.

TL;DR — 한 줄 결론

AI 는 *국지적 정답 을 놀랍게 잘 만든다. 다만 시스템 전체의 *맥락, 조직의 암묵적 결정, 과거 사고의 *함정, layer 간 contract, 비즈니스의 *진짜 목적** 의 *5 가지 를 모른다. 그 5 가지 를 *AI 가 모른다는 사실 을 *코드 작성자가 의식적으로 *책임지지 않으면** *AI 가 만든 코드는 *시간이 지나면 *비용이 커지는 *쓰레기 코드 로 변한다. 기준은 *5 가지 — 시스템 맥락 / 미래 의 자기 자신 / 다른 사람 의 이해 가능성 / 사고 학습 의 반영 / 비즈니스 의 *진짜 목적 의 *연결.

1. *발단 — *AI 가 한 줄 쓰면 정답인 줄 안다**

Claude Code 가 잘 짠 코드 를 받았다. 컴파일 OK, 테스트 통과, lint clean. 그래서 그대로 머지. 2 주 뒤 *프로덕션 에서 *알 수 없는 *p99 spike**.

진단해보니 :

  • 코드 자체는 기술적으로 정확
  • 다만 5 개월 전 동일 패턴의 *N+1 사고 가 있었던 것을 *반영하지 않았다
  • AI 는 그 사고를 *알 리가 없다. 내가 *commit message 어디에도 *그 사고 를 *연결하지 않았으니까**

AI 가 만든 코드의 *책임자 는 AI 가 아니라 *나. 그 책임 의 *정의 가 *AI 시대 에 재정립 되어야 한다*.

2. AI 가 *진짜 잘하는 것 5 가지*

2.1 *국지적 *패턴 의 정답**

Spring Boot 의 @Transactional 안에서 *외부 HTTP 호출 을 비동기 outbox 로 *옮겨라**. 이런 *완결된 패턴 은 AI 가 *교과서적으로 정확.

적용 코드 의 *문법, *문맥, *boilerplate 까지 *완벽. 시니어가 *10 분 걸릴 일 을 10 초에 *해결.

2.2 *광범위한 *기술 지식 의 *재현**

ZGC 와 G1GC 의 *p99 pause 차이. HikariCP 의 maxLifetime 과 *DB wait_timeout 의 *비율. Kafka *partition key 의 *순서 보장 의미.

책 한 권을 *몇 분에 *재구성 해서 지금 내 문제 에 *맞게 응용. 학습 비용 의 *극단적 단축.

2.3 *Boilerplate / *반복 코드 의 *자동화**

JPA Entity 작성, DTO mapper 작성, unit test 의 *given-when-then *기본 골격. 시간 가는 *반복 작업 을 AI 가 *압축.

시니어의 *시간 을 *판단이 필요한 일 에 집중 시킬 수 있다.

2.4 문서화 / *주석 작성

잘 쓴 코드에 *주석 다는 일. 복잡한 알고리즘 의 *의도 를 *자연어로 *번역. API 문서, *README, *CHANGELOG 의 *초안 작성. 대부분 *시니어가 미루는 일 을 AI 가 *빠르게 채움.

2.5 *코드 리뷰의 *1 차 필터**

lint / linting / 보안 스캔 같은 기계적 검사. 명백한 안티패턴 (N+1, SQL injection, race condition) 의 초기 탐지. 사람 리뷰어의 *집중을 *진짜 *판단이 필요한 부분 에 *남기는 *효과.

3. AI 가 *못 하는 것 5 가지*

3.1 *시스템 전체의 *맥락**

AI 는 내가 보여준 *파일 들 만 본다. 다음을 모른다 :

  • 다른 *서비스 의 API contract
  • 그 서비스가 *내 변경 에 *어떻게 반응 할지*
  • 우리 *팀 의 *컨벤션 의 *암묵적 룰 (예: “lemuel-default LimitRange 가 cpu max ratio 8 을 강제한다”)

전체 그림 을 *모르는 AI 가 *국지적 정답 만 내놓는다. 그 국지적 정답 이 *다른 컴포넌트 와 *어긋날 수 있다.

3.2 *조직의 *암묵적 결정**

왜 이 코드는 *PostgreSQL 이 아니라 MySQL 인가. 왜 외부 도메인 은 *cloudflared 가 *호스트 OS 에서 도는가. 왜 *settlement-service 는 *outbox 패턴 을 강제하는가.

이런 결정 의 *이유 는 commit log 에도 *문서에도 *명시되지 않은 경우 가 많다. AI 는 그걸 *알 수 없다. 그래서 AI 가 *조용히 *그 결정을 거스르는 코드 를 *만들 수 있다.

3.3 *과거 사고 의 *함정**

5 월 17일 사고 로 fix 가 9 일 묻혔던 *newest-build race. Velero kopia 의 *좀비 잡 한 달 firing. etcd 가 HDD 위에서 *fsync 12 배 늦었던 사고.

이런 사고 의 *흔적 은 블로그 글이나 PR 문서 에는 남아있지만 *AI 가 *자동으로 참조하지 않는다. 내가 prompt 에 *명시 주입 하지 않으면 같은 사고 의 *재발 을 *못 막는다.

3.4 *Layer 간 *Contract**

Observer Pattern → CPU 의 7 layer. 각 layer 는 다음 layer 의 *추상화 를 *신뢰 하는 암묵적 약속 위에서 동작한다. 내 코드의 *변경 이 어느 layer 의 *약속을 깨는지 — AI 가 즉시 보지 못한다.

내 9 일 묻힌 사고 도 layer 0 (CI/CD) 의 *race 였다. layer 4 (frontend code) 만 *완벽해도 *layer 0 이 *조용히 *깨지면 *사용자에게 *9 일 묻힌다. AI 가 *layer 0 의 *race 까지 *내다보지 못한다.

3.5 *비즈니스 의 *진짜 목적**

“검색 응답시간 을 *500ms 로 낮춰라”. 기술적 정답 은 인덱스 추가, 캐시, ElasticSearch 도입.

그러나 진짜 비즈니스 목적 은 “이탈률 을 1% 줄여서 *분기 매출 *5% 증가 시키는 것”. *그 목적 에는 *검색 결과 의 *관련성 이 latency 보다 *훨씬 중요 할 수 있다*.

AI 는 *문제 정의 를 *그대로 받아들인다. 그 문제 정의 가 *진짜 비즈니스 와 *얼마나 어긋나 있는지 는 모른다.

4. 쓰레기 코드 의 *정의 — *시간이 지나면 *비용 ↑ 인 코드**

쓰레기 코드 = 시간이 지나면 *비용 이 *증가 하는 코드. *기능 추가 / 버그 수정 / 인수인계 / 사고 진단 *전부 의 비용이 시간에 따라 *비선형 적으로 증가.

4.1 *왜 *AI 가 만든 코드 가 *쓰레기 가 *되기 쉬운가**

  • 국지적 정답 *수십 개 가 모이면 *전체 가 *복잡한 *불일관성 의 덩어리 가 된다
  • 각 패턴 이 *왜 그렇게 됐는지 의 이유 가 *문서화 되지 않는다
  • 나중에 *변경 하려는 사람 이 이유 를 모르니 *조심 하지 못한다
  • 그래서 *변경 마다 *예기치 못한 *부작용 이 발생

4.2 *시간 의 *비대칭 *비용 곡선**

유지 비용
    ↑
    │
    │  쓰레기 코드 ──╲       ╱─── 폭주
    │              ╲     ╱
    │               ╲ ╱
    │                ╳
    │             ╱   ╲
    │  잘 짠 코드 ──   ╲
    │                  ╲────── 점진적 증가
    │
    +──────────────────────────→ 시간
    0       3개월       1년       3년

초기에는 *둘 다 비슷한 비용. 시간이 지날수록 *쓰레기 코드 의 *비용이 *폭주. 3 년 후엔 *처음부터 다시 쓰는 게 *저렴 한 수준 에 도달.

5. 쓰레기 코드 가 *되지 않는 *5 가지 *기준**

이게 시니어 백엔드 개발자가 *AI 시대 에 *명시적으로 *책임져야 할 *5 가지. AI 의 5 가지 *못 하는 것 의 *대응 표.

5.1 *기준 1 — *시스템 *맥락 의 *연결**

AI 가 작성한 코드가 *다른 컴포넌트 와 *어떻게 *상호작용 하는지* 를 명시적으로 *문서 / commit message / PR description 에 *기록.

이 변경은 settlement-service 의 outbox polling 주기 변경 (1s → 5s).
영향:
- producer 측 (order-service) 에서 정산 요청 후 5s 까지 정산 미반영
- 사용자 화면의 "처리 중" 표시 라이브러리 (frontend/Order.tsx) 와 함께 검토 필요
- 야간 배치의 reconciliation 은 영향 없음 (배치는 outbox 우회)

이런 *영향 분석 을 *AI 가 자동 작성하지 못한다. 시니어가 *시스템 그림 을 *알기 때문에 연결 의 *책임자가 된다.

5.2 기준 2 — *미래의 자기 자신 이 이해 가능*

6 개월 후 *내가 *이 코드를 *다시 볼 때 왜 이렇게 했는지 가 명확 한가?*

추천 :

  • commit message 에 *Why 를 명시 (What 은 코드가 말함)
  • 비표준 결정 *(why this number, why this pattern) 에 한 줄 주석
  • *trade-off 가 있는 *결정 은 *PR description 에 *대안과 비교**
// 30s 의 connectionTimeout 을 기본값 30s 그대로 두는 게 *명시적 결정*.
// 이유: cgroup throttling 사고 (PR #18) 이후 short timeout 으로 cascading
// failure 가 더 자주 나는 걸 확인. 3s 로 줄였다 다시 되돌렸음.
val connectionTimeout: Duration = Duration.ofSeconds(30)

AI 가 *왜 그 값 인지 는 모른다. 시니어가 *과거 의 결정 을 *주석 으로 *심는다.

5.3 *기준 3 — *다른 사람 의 이해 가능성**

신입 / 외부 리뷰어 / 미래의 이직자 가 이 코드를 *읽고 *맥락 없이 이해 할 수 있나?*

  • 변수명 / 함수명 이 *비즈니스 도메인 *용어
  • 추상화 level 이 *적절 (너무 잘게도, 너무 크게도)
  • 복잡한 분기 는 *코드 *주석 또는 별도 함수로 *이름 으로 표현

AI 가 영어 docstring 을 완벽 하게 쓸 수 있다. 다만 비즈니스 용어 와 *맞는 *이름 짓기 는 도메인 지식 의 영역. 시니어가 *책임진다.

5.4 *기준 4 — *사고 학습 의 *반영**

과거 의 사고 / 회고 / postmortem 의 *교훈 이 *이 코드 에 *반영 되어 있나?*

  • 우리 *조직의 *블로그 / Wiki 의 사고 기록 을 prompt 에 *주입 하거나 수동으로 검토
  • 과거 사고 와 *유사한 패턴 이 이 PR 에 *있는지 의 명시적 *체크

내 9 일 묻힌 사고는 AI 가 *못 보는 *layer 0 의 race. 그 사고 를 문서로 *박제 한 이후엔 *비슷한 *image-updater 코드 작성 시 *그 문서 참조 *필수. 그게 *내가 *시니어 로 *조직 에 기여하는 *방식.

5.5 기준 5 — *비즈니스 의 *진짜 목적 과 *연결**

이 변경 이 *왜 가치 있는가. *어느 사용자 의 어느 행동 의 *어느 지표 를 *얼마나 *움직이는가**.

  • PR description 에 *비즈니스 목적 *한 줄
  • 기술 spec 과 *비즈니스 가치 의 *연결 다이어그램
  • *측정 가능한 *성공 기준** (KPI / OKR / 운영 지표)

AI 는 문제 를 받아 *기술 적으로 *완벽 한 답을 *내놓는다. 문제 자체가 *진짜인지 는 시니어가 *비즈니스 와 *대화하며 *검증 해야 한다.

6. *내 9 일 묻힌 사고 — AI 가 *어디서 못 막았는가**

9 일 묻힌 frontend 사고 의 layer 별 분석 :

Layer AI 의 책임 가능성 실제
Layer 4 (frontend code) AI 가 *fix 코드 *작성 가능 ✅ 5/17 에 fix merge
Layer 0 (CI/CD pipeline) AI 는 *별도 prompt 없이 *못 봄 ❌ Image Updater race 9 일 묻힘
Layer 0’ (외부 검증) AI 가 *synthetic check *제안 가능 ❌ 본인이 외부 served bytes 검증 안 했음

결론 : 기술적 fix 가 완벽해도 *Layer 0 의 *race 까지 *책임자가 *내다보지 못하면 9 일 묻힌다. AI 의 *작성 책임 과 *내 *전체 시야 의 책임 이 다른 영역 에 있다.

7. 운영 관점 — *AI 가 *작성한 코드 의 *signoff 책임**

AI 도구가 만든 PR 도 *사람이 머지 한다. 그 머지 의 *signoff 는 AI 가 못 한다. 사람이 한다.

시니어 의 *진짜 일 의 형태 가 바뀐다:

과거 (AI 이전) 현재 (AI 시대)
코드 작성 AI 가 작성 → 시니어 가 *signoff
boilerplate 작성 AI 가 자동 → 시니어가 *맥락 검증
문서 작성 AI 가 초안 → 시니어가 *조직 의 결정 주입
코드 리뷰 AI 가 1차 → 시니어가 *시스템 시야 적용
사고 진단 AI 가 hypothesis → 시니어가 *과거 사고 와 *교차 검증

signoff 의 *책임 은 AI 시대 에도 *유지 된다. 오히려 *그 책임 의 *가치 가 *더 크게 평가 된다 — AI 가 잘 못 하는 부분 만 *남기 때문에.

8. *시니어의 *진짜 일이 *바뀌는 방향**

5 년 후 시니어 백엔드 개발자 의 *일 :

8.1 대폭 줄어드는 일

  • 기본 boilerplate 작성
  • 익숙한 패턴 의 *코드
  • 기계적 코드 리뷰 (lint / N+1 / 안티패턴 1차 필터)
  • 공식 docs 의 *복붙

8.2 그대로 또는 늘어나는 일

  • 시스템 전체 의 시야 *유지
  • 비즈니스 와 *대화 / 우선순위 협상
  • 조직 의 *암묵적 결정 의 *문서화
  • 사고 의 *postmortem 과 *교훈 의 *코드/문서 박제
  • 주니어의 *AI 사용 *멘토링 — AI 가 못 보는 *5 가지 가 *어디인지 *알려주기
  • AI 의 *prompt context 를 *조직 의 *맥락 으로 구성 하는 메타 작업

8.3 완전히 새로 등장하는 일

  • AI 의 *국지적 정답 들 을 *조립 해 일관된 *전체 시스템 으로 유지
  • AI 의 *학습 데이터 가 *내 조직 의 *최신 결정 을 *반영 하도록 내부 문서 / 사고 기록 *체계화
  • AI 가 *내놓은 *위험 한 답 을 조기에 catch 하는 경험 적 *후각 *개발

9. 5 가지 기준 의 *체크리스트 — 다음 PR 에 적용**

PR 머지 직전 5 분 self-check :

  • 기준 1 (시스템 맥락) — 이 변경 이 *영향 주는 *다른 컴포넌트 를 최소 1 개 명시했나?
  • 기준 2 (미래의 나) — 6 개월 후 내가 *이 결정 의 *이유 를 알 수 있는가? 비표준 결정엔 주석 있나?
  • 기준 3 (다른 사람) — 외부인 리뷰어가 *맥락 없이 이 PR 의 주요 변경 을 이해 가능 한가?
  • 기준 4 (사고 학습) — 내 조직 의 *과거 사고 / 회고 와 *유사한 패턴 이 이 변경 에 없는가? 확인 했나?
  • 기준 5 (비즈니스) — 이 변경 의 *비즈니스 가치 의 *한 줄 설명 이 *PR description 에 있나?

이 5 가지 만 명시적으로 체크 해도 쓰레기 코드 의 *비율 이 체감 적으로 줄어든다. 5 분의 비용 으로 *3 년 의 유지 비용 을 *상수 시키는 *교환.

10. 교훈

“AI 시대 의 *시니어 의 책임 은 코드 *작성 이 아니라 AI 의 *국지적 정답 들 을 *전체 시스템 의 *맥락 에 *합의 가능 한 형태 로 *조립 + 박제 하는 것* 이다. signoff 의 책임은 *AI 가 아니라 *사람. 그리고 그 책임의 *가치 가 *AI 시대 에 *오히려 *더 크게 평가 된다.”*

AI 는 *국지적 정답 의 천재 가 되었다. 그러나 *전체 시스템 의 *맥락 을 *짜는 사람 의 *역할 은 *여전히 *사람 에게 남아있다. 그 역할 을 *명시 적 으로 *책임 지면 쓰레기 코드 의 비율 이 *줄어든다. 그 역할 을 *AI 에게 *암묵 적 으로 위임 하면 쓰레기 코드 의 비율 이 *늘어난다.

다음에 *AI 한테 코드 를 시킬 때 — *기술적 정답 의 *국지적 완벽 함 만 보지 말고 *5 가지 기준 의 *체크리스트 를 *함께 돌리자**. 그게 *AI 시대 의 *시니어 의 *진짜 일 의 *모습 이다.

시리즈 : C++ 는 클러스터 밖에 있다 · Go 는 클러스터 전체에 있다 · R 은 클러스터에 없다 · 이커머스 SaaS 의 트래픽 제어 · Observer Pattern 의 7 layer stack dive · HikariCP 의 5 시간 설정 · 백엔드 응답시간 + 모니터링 · Python vs Java 알고리즘 · 정산 정합성 · AI 가 할 수 있는 것 / 못 하는 것 (현재 글)

이 글은 *18 시간 의 9 일 묻힌 frontend 사고 추적 + sparta-msa-project + settlement + helm-deploy + 이 블로그 자체 의 *AI 와 사람의 *공동 작업 경험 을 기반으로 작성. AI 도구는 Claude Code (Opus 4.7 1M context).*