「AI로 개발은 할 수 있게 되었다. 하지만 주니어는 경험을 쌓지 못한 채 계속 견학만 하고 있게 된다…」

이런 과제를 느끼고 있는 분들이 어쩌면 많지 않을까요?

시니어는 AI를 한 손에 들고 폭속으로 구현을 끝내버리고, 주니어에게는 코드를 작성할 차례나 리뷰할 차례가 좀처럼 돌아오지 않습니다.

정신을 차려보면 시니어만 손을 움직이고 주니어는 계속 견학만 하고 있는 듯한 상황입니다.

이것이 계속되면 주니어는 언제까지나 주니어로 남게 되고, 시니어도 다음 시니어를 키워낼 수 없는 악순환에 빠지게 됩니다.

이를 해결하기 위해 AWS가 제창하는 「AIDLC (AI-Driven Development Life Cycle) 개발 플로우에 『주니어가 코드를 작성하는 틀』을 심어둔다」는 메커니즘입니다.

본 기사에서는 그 사고 과정 등의 내용에 대해 써보았습니다.

• AI 주도 개발로 인해 「주니어가 코드를 작성하지 않음 · 리뷰도 할 수 없음」이라는 육성 과제가 조용히 진행되고 있다
• 해결책으로서 AIDLC에 주니어가 코드를 작성하는 20% 할당량을 포함시켜 본다
  • 단순한 양으로 따지는 20/80은 제대로 작동하지 않으므로, 「어떤 20%를 맡길 것인가」를 학습 가치로 결정하는 규칙으로 한다
  • AIDLC의 extensions/에 opt-in 확장으로서 구현하여, Code Generation 계획의 각 단계에 [AI]가 작성할지 [Junior]가 작성할지의 라벨을 붙이는 형태로 운용한다

AI에게 사양(Specification)을 전달하면 구현이 나오는 시대가 되어 생산성은 뛰어올랐을지도 모릅니다. 이것 자체는 물론 좋은 변화입니다. 다만 동시에 주니어에게는 꽤나 아픈 변화이기도 합니다.

• 주니어에게 태스크가 돌아오지 않음 (시니어가 AI로 즉시 끝내버림)
• 「AI에게 통과시켰다는 전제」로 리뷰가 진행되므로, 주니어가 리뷰에 참여할 기회도 줄어듦
• 모르는 것을 선배에게 묻기 전에 AI에게 먼저 물어보게 되어, 동기적인 토론의 장이 사라짐

이대로라면 주니어가 「코드를 작성한다」, 「리뷰한다」, 「토론한다」는 장(場) 자체가 줄어들게 됩니다. 긴 안목으로 보면 조직으로서 누가 다음 시니어를 키울 것인가라는 문제로 이어집니다.

AIDLC는 요구사항 → 사양 → 구현 → 리뷰 → 배포의 각 페이즈에서 AI를 활용하는 개발 스타일로, 이것 자체는 매우 좋은 메커니즘입니다. 다만 기본 구조로는 「인간이 직접 손을 움직이는 장면」이 극단적으로 적어지기 쉬워, 주니어의 육성 포인트가 구조적으로 들어오지 않습니다.

코드 생성 중 20%는 주니어가 작성한다. 나머지 80%는 시니어 또는 AI가 담당한다.

다만 이 경우 단순한 20%만으로는 몇 가지 과제도 있습니다.

• 애초에 「20%」를 무엇으로 측정할 것인가 (행 수? 태스크 수?)
• 「쉬운 20%」를 선택하면 주니어는 계속 쉬운 일만 할 수밖에 없다
• 「어려운 20%」를 선택하면 개발 속도가 너무 떨어진다

즉 양의 문제에 국한되어 있는 한, 제대로 작동하게 만드는 것은 어렵다는 뜻입니다.

20%라는 숫자보다 그 20%의 내용과, 그 전 단계의 사양 공유가 훨씬 더 중요하다는 것입니다.

사양을 시니어와 주니어 모두가 논의하여 공통 이해를 마친 뒤, 주니어에게 코드를 작성하게 한다.

이렇게 하면,

• 작성하지 못했다 = 사양 이해도가 부족했다는 것을 조기에 파악할 수 있다
• 사양 인식이 일치하므로, 시니어의 리뷰에서 수정 사항(Return)이 적다
• 결과적으로 육성과 개발 속도의 양립이 현실적이 된다

「주니어에게 코드를 작성하게 하는 것」을 육성 할당량이 아니라, 사양 공유의 피드백 루프로 자리매김하는 것이 포인트입니다.

핵심인 선택 방법입니다만, 여기서는 학습 가치가 높은 부분을 의도적으로 할당하는 방침으로 합니다.

• 도메인의 핵심 로직: 프로덕트를 지탱하는 본질적인 부분. 주니어가 이곳을 다루면 제품 이해가 단번에 진전된다
• 과거에 버그가 다발했던 영역: 왜 버그가 나오기 쉬운지를 생각하는 훈련이 된다
• 리뷰 관점이 많은 부분: 시니어의 암묵지 (Tacit Knowledge)를 끌어내기 쉽다
• 테스트 설계가 요구되는 부분: 사양의 경계(Boundary)를 생각하는 훈련이 된다

반대로 기계적이거나 완전히 독립된 작은 모듈은 의도적으로 제외합니다. 배움이 적을 뿐만 아니라 팀과의 접점도 생기기 어렵기 때문입니다.

여기까지의 방침을 AWS의 AIDLC에 opt-in 확장으로서 구현합니다. AIDLC의 extensions/

디렉토리에 opt-in 형식으로 확장 규칙을 추가합니다. 보안 베이스라인 (Security Baseline)이나 속성 기반 테스트 (Property-Based Testing) 도 같은 위치에서 제공됩니다.

.aidlc-rule-details/extensions/
├── security/baseline/
├── testing/property-based/
...

워크플로 시작 직후, 요구사항 분석 (Requirements Analysis) 타이밍에 다음과 같은 질문을 던지는 형태입니다.

## Question: Junior Allocation Extension
Should the Junior Allocation rules be enforced for this project?
A) Yes — enforce all JR rules as blocking constraints
...

이와 함께, aidlc-state.md에 설정 파라미터를 갖게 합니다.

규칙 본체는 6개로 압축했습니다. 너무 많으면 현장에서 소화할 수 없으므로, 이 부분은 의식적으로 덜어냅니다.

JR-03의 **"easy를 이유로 주니어 태스크를 선택하는 것을 금지한다"**라는 제약은, 코드 생성 계획 파일에 Why-Junior: easy라고 적는 순간 차단 (Blocking) 처리됩니다. 이것이 없으면 현장에서는 결국 "편해 보이는 일을 주니어에게 넘겨두자"가 되기 쉬우므로, 규칙으로 막는 형태를 취합니다. 또 다른 포인트는 JR-06의 이해도 회고입니다. 주니어가 구현 중 막혔던 사양의 모호함을 다음 이터레이션 (Iteration)의 요구사항 (Requirements)으로 되돌리기 위한 입구가 됩니다. 이것은 주니어를 평가하기 위한 것이 아니라 "사양 공유가 정말로 전달되었는가"를 체크하기 위해 사용합니다. 구현에서 막힌 부분은 대개 사양의 모호함의 반증이므로, 이 부분을 포착하면 다음 이터레이션의 논의 질이 올라갈 것입니다.

AIDLC와 상호작용하는 과정에서의 간단한 이미지도를 붙여둡니다.

주니어용 코드 생성 규칙을 적용할 것인가.

규칙을 적용할 경우, 어떤 단계로 적용할지 상세 내용을 확정한다.

[AI]가 작성할지, [Junior]가 작성할지 등 코드 생성 플랜을 세운다.

[Junior]는 스펙 표를 바탕으로 학습하며 코드를 생성한다.

솔직히 이것으로 모든 것이 해결된다고 생각하지는 않습니다. 실제 운용에서 나타날 법한 과제도 몇 가지 있습니다.

• 시니어의 리뷰 부하가 증가한다: AI 생성 80% + 주니어 구현 20%를 모두 보게 된다. JR-05의 "주니어가 1차 리뷰"를 통해 다소 분산할 수는 있지만, 제로가 되지는 않는다.
• 속도는 다소 떨어진다: 주니어가 작성하는 부분은 AI보다 느리다. 사양 공유를 통해 되돌아오는 과정(Back-and-forth)이 줄어듦으로써 어디까지 흡수할 수 있을지는 실제 운용을 통해 지켜봐야 한다.
• "이번에는 급하니까 주니어 할당 없음"이 계속되면 형식화된다: 스프린트 (Sprint) 단위로 할당량을 보장하는 등, 운용 규칙도 함께 필요하다.

특히 세 번째는 꽤 무서운 부분인데, 규칙으로 묶어두었다고는 해도 인간의 의사결정으로 예외를 계속 만들다 보면 결국 할당량 자체가 사라지게 됩니다. 이 부분은 도구의 문제라기보다 팀 문화의 문제라는 생각이 듭니다.

• AI 시대의 육성 과제에 대해, AIDLC에 "주니어 구현 할당량 20%"를 포함하는 안을 생각하고, 실제로 확장(Extension)으로서 구현해 보는 것을 고려한다.
• 양보다, **사양 공유 + 학습 가치로 선택하는 20%**가 핵심 - AIDLC의 extensions/

는, 이러한 "팀의 육성 방침"과 같은 것까지 워크플로우에 직접 포함시킬 수 있을 것 같다.

아직 가설 단계이며, 장기적으로 운용했을 때 어떠할지는 미지수입니다. 개발 속도를 높이는 것도 필요하다고 생각하지만, 젊은 인재들이 앞으로를 만들어가는 과정에서 미래를 생각하는 계기가 되기를 바랍니다.