AI 가 코드 를 대신 써 준다. 그럼 개발자 의 가치 는 어디 로 가는가?

“어떻게 만드나(how)” 에서 “무엇 을·왜 만드나(what·why)” 로 옮겨 간다. 구현 이 싸지면, 희소해지는 건 문제 를 정확히 규정 하는 능력 이다. 이 글 은 AX(AI Transformation) 시대 에 왜 문제정의(problem definition) 가 핵심 역량 이 되는지 — 그리고 백엔드 개발자 가 왜 여기서 유리 한지 를 정리한다.

1. AI 는 답 을 잘 하지, 질문 을 대신 하지 않는다

LLM 에게 “쇼핑몰 결제 만들어 줘” 라고 하면 뭔가 나온다. 그럴듯 하다. 그런데 프로덕션 에 올리는 순간 터진다 — 중복 결제, 부분 실패, 환불 정합성 을 아무도 규정 하지 않았으니까.

AI 는 주어진 문제 는 빠르게 푼다. 하지만 “진짜 문제 가 무엇 인지” 는 스스로 좁히지 못한다. 모호한 입력 → 모호한 출력. 이건 AI 든 주니어 든 똑같다.

핵심: AI 가 강해질수록, “무엇 을 풀지” 를 규정 하는 사람 이 병목 이자 레버리지 가 된다. 구현 은 무한 복제 되지만, 좋은 문제정의 는 여전히 사람 몫 이다.

2. 문제정의 = 좋은 프롬프트 = 좋은 스펙 — 셋 은 같은 것

전에 AI 사용법 글 에서 좋은 프롬프트 = 역할·입력·제약·형식 이라 했다. 그런데 이건 새로운 게 아니다 — 좋은 스펙(요구사항 정의) 과 완전히 같은 구조 다.

좋은 프롬프트 좋은 스펙 공통
제약(분량·형식) 비기능 요구(성능·정합성) 경계 를 못 박음
예시(few-shot) 유스케이스·엣지케이스 구체 로 좁힘
역할 도메인 컨텍스트 맥락 을 줌

즉 프롬프트 를 잘 쓰는 능력 = 문제 를 잘 정의 하는 능력 이다. AX 시대 에 “프롬프트 엔지니어링” 이 뜨는 이유 는, 그게 사실 요구사항 을 정확히 규정 하는 오래된 엔지니어링 역량 이기 때문.

3. 백엔드 개발자 는 원래 문제정의 훈련 을 받아 왔다

여기서 백엔드 의 강점 이 드러난다. 백엔드 일 의 본질 은 모호한 요구 를 엄밀한 제약 으로 번역 하는 것 이다.

  • “주문 되게 해줘” → 트랜잭션 경계 는? 동시성 은? 재고 부족 시엔? 결제 실패 롤백 은?
  • “빠르게 해줘” → p95 몇 ms? 어느 쿼리? 캐시 무효화 는 언제?
  • “안 틀리게 해줘” → 어떤 unique 제약? at-least-once 면 idempotent 수신 은?

이 번역 이 곧 문제정의 다. 백엔드 개발자 는 매일 스키마·API 계약·실패 모드·트랜잭션 경계 로 세계 를 엄밀 하게 규정 한다. AX 시대 가 요구 하는 능력 을, 백엔드 는 이미 직업 적 으로 연습 해 왔다.

4. 실전 — “중복 결제 막아 줘” 의 두 얼굴

같은 요구 도 정의 의 해상도 에 따라 결과 가 갈린다.

모호한 정의 → AI 에게 던지면 헛발질:

“결제 중복 안 되게 해줘” → AI: if (exists) return; 같은 순진한 체크. 동시성·재시도·분산 환경 에서 다 뚫림.

정의 된 문제 → AI 든 사람 이든 정확히 구현:

“분산 메시징 은 at-least-once 라 이벤트 가 중복 된다. 이걸 3 겹 으로 막는다 — L1 outbox event_id UNIQUE(발행), L2 processed_events PK(수신), L3 DB 자연키 UNIQUE(저장). 어느 한 층 이 뚫려도 다음 층 이 막는다.”

두 번째 는 정산 시스템 글 에서 실제 쓴 Triple Idempotency 다. 차이 는 코드 실력 이 아니라 문제 를 얼마나 정확히 규정 했는가 다. AI 시대 엔 이 해상도 가 곧 결과물 의 질 이 된다.

5. 좋은 문제정의 의 5 요소 (백엔드 체크리스트)

문제 를 AI(또는 팀) 에게 넘기기 전, 이 다섯 을 규정 했는지 본다:

  1. 제약(constraints) — 성능·정합성·보안 의 비기능 요구. “빠르게” 말고 “p95 200ms”.
  2. 엣지케이스 — 빈 값, 동시 요청, 부분 실패, 중복. 정상 경로 는 AI 도 짠다. 경계 가 진짜 문제.
  3. 실패 모드 — 뭐가 어떻게 깨지고, 깨지면 어떻게 복구 하나. (외부 API 죽으면? 메시지 유실 되면?)
  4. 성공 기준(측정 가능) — “잘 된다” 가 아니라 숫자. 중복 처리 0 건, 유실률 0.
  5. 트레이드오프 — 무엇 을 포기 하고 무엇 을 얻나. (HNSW 처럼 정확도 조금 내주고 속도 얻기)

이 다섯 이 채워지면, 구현 은 AI 가 해도 된다. 비어 있으면, AI 가 빨리 짤수록 빨리 틀린다.

6. 그래서 AX 시대 에 살아남는 백엔드 는

  • 코드 타이핑 속도 로 경쟁 하지 않는다. 그건 이미 AI 가 이겼다.
  • 대신 문제 를 정의 하는 해상도 로 경쟁 한다 — 무엇 이 진짜 문제 이고, 어떤 제약·실패·성공기준 이 걸려 있는지 를 남 보다 선명 하게 보는 것.
  • AI 를 구현 도구 로 부리되, 무엇 을 구현 할지 는 자기 가 규정 한다. AI 답 을 검증 하는 것 도 결국 “내가 문제 를 정확히 알아야” 가능 하다.

구현 이 공짜 에 가까워질수록, 문제정의 는 비싸진다. AX 시대 의 백엔드 개발자 는 “어떻게” 를 잘 아는 사람 에서 “무엇 을·왜” 를 정확히 규정 하는 사람 으로 진화 한다.

질문 을 잘 하는 사람 이, 답 을 잘 하는 기계 를 이긴다.

관련: 실무 AI 사용법 8 원칙 · 정산 시스템 을 KPI 로