코딩 에이전트에게 “주문 취소 API 만들어 줘” 라고 하면 몇 분 만에 컨트롤러, 서비스, 리포지토리, 테스트까지 나온다. 컴파일도 되고 테스트도 초록이다. 그런데 정작 중요한 질문에는 답이 없다.

  • 부분 취소는 되는가?
  • 이미 정산된 주문은?
  • 포인트로 결제한 몫은 어디로 돌아가는가?
  • 동시에 두 번 누르면?

코드를 만드는 비용은 빠르게 0 에 가까워지고 있다. 대신 “무엇을, 왜, 어디까지 만들 것인가” 를 정하는 능력, 즉 기획 능력의 값이 올라가고 있다. 이 글은 그 기획 능력이 자바 개발자에게 구체적으로 무엇인지, 그리고 주니어부터 리드까지 각자의 위치에서 어떻게 달라지는지를 정리한다.

1. 먼저 숫자 — AI 는 빠르게 해 주지만, 방향은 고쳐 주지 않는다

AI 가 개발을 어떻게 바꾸는지에 대한 1차 자료 세 개를 보자.

① 체감과 실측은 다르다. METR 의 2025년 무작위 대조 연구는 숙련된 오픈소스 개발자 16명이 실제 이슈 246개를 처리하는 과정을 관찰했다.

  • AI 를 허용했을 때 완료 시간이 “19% longer”, 즉 오히려 19% 늘었다.
  • 그런데 개발자들은 시작 전에 24% 빨라질 거라고 예상했다.
  • 끝난 뒤에도 “they still believed AI had sped them up by 20%”. 느려진 걸 겪고도 20% 빨라졌다고 믿었다.

(논문) 이 결과는 2025년 초 도구 기준이다. METR 페이지에도 지금은 낡은 결과라는 안내가 붙어 있다. 그래서 “AI 는 느리다” 로 읽으면 안 된다. “빨라졌다는 느낌을 믿으면 안 된다” 로 읽어야 한다.

② AI 는 증폭기다. 구글 DORA 의 2025 보고서 결론은 한 문장이다. “AI’s primary role is as an amplifier, magnifying an organization’s existing strengths and weaknesses.” 같은 발표(Google Cloud 블로그)에서 응답자 약 5,000명 중 90% 가 업무에 AI 를 쓴다고 답했다. 동시에 30% 는 AI 가 만든 코드를 거의 또는 전혀 신뢰하지 않는다고 답했다.

③ 쓰지만 믿지는 않는다. Stack Overflow 2025 개발자 설문에서 84% 가 AI 도구를 쓰거나 쓸 계획이다. 반면 정확도를 불신하는 사람(46%)이 신뢰하는 사람(33%)보다 많다.

세 자료를 합치면 이렇게 읽힌다. AI 는 이미 모두가 쓰는 엔진이다. 그 엔진이 증폭하는 것은 우리가 넣어 준 방향이다. 방향이 흐릿하면 흐릿한 코드가 빠르게, 대량으로 나온다. 그리고 우리는 그걸 생산성이라고 착각하기 쉽다.

2. 개발자의 기획 능력이란 무엇인가

여기서 말하는 기획은 PM 의 기획서가 아니다. 코드를 쓰기 전에 개발자가 머릿속에서 끝내야 하는 일이다. 자바·스프링 백엔드 개발자 기준으로 다섯 가지로 나눌 수 있다.

기획 능력 질문 AI 에게 맡기면 생기는 일
문제 정의 이게 진짜 풀어야 할 문제인가? 성공은 무엇으로 아는가? 요청 문장을 그대로 구현한다. 문제가 틀렸으면 틀린 답이 완벽하게 나온다
도메인 경계와 불변식 무엇이 절대 깨지면 안 되는가? (예: 정산 금액 = 결제 − 수수료) 행복 경로만 구현된다. 불변식은 누가 말해 주지 않으면 코드에 없다
수용 기준 “됐다” 는 정확히 어떤 상태인가? 에이전트가 스스로 “완료” 를 선언한다. 기준이 없으면 반박할 근거도 없다
비기능 요구 동시성, 트랜잭션 경계, 멱등성, 성능, 장애 시 동작은? 단일 요청에서는 완벽하게 돌고, 동시 요청 두 개에 깨진다
분해와 순서 어떤 단위로 나누고, 무엇부터 검증하는가? 거대한 변경 하나가 한 번에 나온다. 리뷰도, 되돌리기도 어렵다

자바 개발자에게 이 다섯 가지는 낯설지 않다. 트랜잭션 경계를 어디에 둘지, 엔티티와 값 객체를 어떻게 나눌지, 어떤 예외를 체크 예외로 둘지 같은 고민이 원래 기획의 일부였다. AI 시대에 바뀐 건 이 고민의 위치다. 예전에는 코드를 짜면서 자연스럽게 마주쳤다. 이제는 코드를 짜기 전에, 글로 먼저 끝내야 한다. 코드를 짜는 사람이 내가 아니라 에이전트이기 때문이다.

기획을 “검증 가능한 문장” 으로 쓰는 법

요구사항을 기계가 확인할 수 있는 형태로 쓰는 오래된 방법이 있다. 롤스로이스에서 개발해 2009년 처음 발표된 EARS(Easy Approach to Requirements Syntax) 형식이다.

WHEN 이미 정산 확정된 주문에 대해 환불 요청이 들어오면
THE SYSTEM SHALL 정산을 수정하지 않고 지급 후 회수 채권을 생성한다

이렇게 쓰면 이 한 줄이 그대로 테스트 케이스가 되고, 에이전트에게 주는 수용 기준이 되고, 리뷰어가 대조할 체크리스트가 된다. 기획 문장과 테스트와 리뷰가 하나로 연결된다. 이 블로그의 계획 루프 글에서 다룬 “계획 → 테스트 → 구현” 루프의 첫 칸이 바로 이 문장이다.

3. 각자의 위치에서

기획 능력은 직급에 따라 범위가 달라진다. 필요 없는 사람은 없다.

주니어 — “요청을 질문으로 되돌려 주는 능력”

주니어에게 기획은 거창하지 않다. 받은 요청을 바로 에이전트에 넘기지 않고, 질문 세 개로 되돌려 주는 것이다.

  • “취소 가능한 상태는 어디까지인가요?”
  • “이미 정산된 건은요?”
  • “동시에 두 번 요청이 오면요?”

AI 시대의 주니어가 가장 경계해야 할 것은 “돌아가는 코드를 빨리 내는 사람” 이 되는 것이다. 그 일은 에이전트가 더 잘한다. 반대로 질문으로 구멍을 찾는 사람은 팀이 대체할 수 없다.

연습법: 에이전트가 만든 코드를 받으면, 고치기 전에 “이 코드가 가정한 것 세 가지” 를 먼저 적어 본다. 대부분 그 가정 중 하나가 틀려 있다.

미드레벨 — “작업을 에이전트가 끝낼 수 있는 크기로 쪼개는 능력”

3~7년 차의 기획은 분해다. 기능 하나를 에이전트가 한 번에 검증 가능하게 끝낼 수 있는 단위로 나눈다. 그리고 각 단위에 수용 기준과 순서를 붙인다.

  • 스프링 기준으로는 “도메인 규칙 → 유스케이스 → 어댑터(웹·영속성)” 순서로 나누면 각 단계가 독립적으로 테스트된다. 헥사고날 구조가 AI 시대에 다시 주목받는 이유다. 경계가 분명하면 에이전트에게 맡길 단위도 분명해진다.
  • 이 단계의 함정은 1절의 METR 결과 그대로다. 에이전트와 함께 일하면 빨라졌다고 느끼기 쉽다. 미드레벨은 그 느낌 대신 리뷰 시간, 되돌린 횟수, 운영 장애로 실제 속도를 재야 한다.

시니어·테크 리드 — “팀의 ‘완료’ 를 정의하는 능력”

리드의 기획은 기준을 만드는 일이다. 개별 기능이 아니라 팀 전체가 쓰는 정의를 만든다.

  • 무엇이 “완료” 인가: 테스트 통과만인가, 불변식 테스트까지인가, 운영 지표 확인까지인가?
  • 에이전트에게 무엇을 맡기지 않는가: 결제·정산·권한 같은 영역은 사람이 설계하고 에이전트는 구현만 한다. 이런 경계를 정한다.
  • 아키텍처 결정 기록(ADR): “왜 이렇게 했는가” 를 남긴다. 에이전트는 코드를 고칠 때 이유를 모른다. 이유가 문서에 있어야 다음 에이전트도, 다음 사람도 같은 실수를 안 한다.

DORA 의 “증폭기” 결론이 가장 직접 닿는 자리가 여기다. 리드가 만든 기준이 탄탄하면 AI 가 그 기준을 증폭한다. 기준이 없으면 혼란이 증폭된다.

1인 개발자·스타트업 — “만들지 않을 것을 정하는 능력”

혼자 일하거나 작은 팀이라면 AI 덕분에 만들 수 있는 양이 폭발한다. 그래서 오히려 기획의 핵심은 빼기가 된다.

  • 에이전트가 하루 만에 대출, 보험, 게시판, 교육 모듈까지 붙여 주는 시대다. “만들 수 있다” 와 “만들어야 한다” 사이의 거리가 커졌다.
  • 고객 한 명의 문제를 끝까지 푸는 좁고 깊은 제품이, 열 가지를 얕게 하는 제품보다 낫다. 에이전트가 얕은 확장을 너무 쉽게 만들어 주기 때문에, 이 판단을 하는 사람이 필요하다.

SI·에이전시 개발자 — “요구사항을 계약 언어로 바꾸는 능력”

납품형 프로젝트에서 기획 능력은 곧 리스크 관리다. 모호한 요구사항은 나중에 추가 공수와 분쟁이 된다. EARS 같은 형식으로 요구사항을 검증 가능한 문장으로 바꿔 고객과 합의해 두면, 에이전트에게 줄 수용 기준과 인수 테스트 기준이 한 번에 생긴다. AI 로 구현이 빨라질수록 “무엇을 납품하기로 했는가” 가 분명한 쪽이 이긴다.

4. 자바 개발자에게 특히 유리한 지점

자바·스프링 생태계는 이 변화에 생각보다 잘 맞는다.

  • 타입과 계층이 기획을 강제한다. 인터페이스, 도메인 객체, 명시적 예외는 그 자체로 기획 문서의 성격을 가진다. 에이전트에게 “이 포트 인터페이스를 구현하라” 고 주면 범위가 저절로 제한된다.
  • 테스트 문화가 성숙해 있다. JUnit, ArchUnit, Testcontainers 같은 도구로 기획 문장을 실행 가능한 검증으로 바꾸기 쉽다. ArchUnit 으로 “도메인은 인프라를 모른다” 를 강제하면, 에이전트가 경계를 넘는 코드를 쓰는 순간 빌드가 막힌다.
  • AI 기능도 같은 생태계 안에서 만든다. 스프링에는 Spring AI(“an application framework for AI engineering”)가 있어서, LLM 을 쓰는 기능도 익숙한 방식으로 설계할 수 있다. 다만 여기서도 똑같다. 프롬프트와 모델 호출은 쉽다. 실패했을 때 무엇을 할지, 결과를 어떻게 검증할지가 기획이다.

5. 오늘부터 할 수 있는 것

  1. 에이전트에 요청하기 전에 세 줄을 쓴다. 문제 한 줄, 완료 기준 한 줄, 절대 깨지면 안 되는 것 한 줄. 이 세 줄을 못 쓰면 아직 요청할 때가 아니다.
  2. 수용 기준은 EARS 형식으로 쓴다. WHEN … THE SYSTEM SHALL …. 그대로 테스트가 된다.
  3. 불변식 테스트를 먼저 만든다. 금액 합계, 상태 전이, 멱등성처럼 깨지면 안 되는 것부터 테스트로 박아 두고 에이전트에게 구현을 맡긴다.
  4. “빨라졌다” 는 느낌 대신 숫자를 본다. 리뷰 시간, 되돌린 커밋 수, 운영 장애 수.
  5. 결정의 이유를 남긴다. ADR 한 장이 다음 에이전트의 실수를 막는다.

맺으며

AI 시대에 사라지는 것은 개발자가 아니라 “말한 대로 코드를 쓰는 일” 이다. 남는 일, 그리고 값이 오르는 일은 무엇을 말할지 정하는 일이다. 주니어는 질문으로, 미드레벨은 분해로, 리드는 기준으로, 1인 개발자는 빼기로, SI 개발자는 계약 언어로. 각자의 위치에서 기획의 모양은 다르지만 본질은 같다.

코드를 쓰기 전에 “무엇이 맞는가” 를 글로 말할 수 있는가.

AI 는 그 문장을 증폭한다. 문장이 없으면 증폭할 것도 없다.

References