콘텐츠로 이동

AWS CEO가 '주니어 대체는 바보짓'이라 한 이유와, 주니어가 AI와 함께 연습할 세 가지

"AI가 코드를 다 짜 주는데 신입을 왜 뽑나요?"라는 질문에 AWS CEO 매트 가먼(Matt Garman)은 2025년 8월 한 인터뷰에서 그 생각을 "들어 본 것 중 가장 어리석은 생각 가운데 하나"라고 답했습니다. 이 말은 주니어를 위로하는 말로 많이 퍼졌습니다. 그런데 발언을 끝까지 읽어 보면 위로보다 숙제에 가깝습니다. 그는 회사가 신입에게 "문제를 쪼개고 생각하는 법"을 가르쳐야 한다고 했고, 그 말은 거꾸로 주니어가 무엇을 연습해야 하는지를 알려 줍니다. 이 글은 발언을 원문 보도로 확인한 뒤, Java/Spring 강의에서 쓰는 실습 과제로 그 숙제를 어떻게 연습하는지 정리합니다.

이 글의 기준

2025년 12월에 올린 같은 주제의 글은 유튜브 영상 한 편을 요약한 것이었습니다. 2026-10-24에 발언을 원 인터뷰와 보도로 다시 확인하고, 제 개인 위키에 공개한 Java/Spring 실습 교재를 근거로 전면 다시 썼습니다. 인용은 보도마다 표현이 조금씩 달라 확인한 매체를 함께 적었습니다. 채용 시장 통계는 주니어 소멸의 시대 글에서 따로 다룹니다.

1. 발언을 원문으로 확인하기

발언이 나온 곳은 매튜 버먼(Matthew Berman)의 유튜브 채널 인터뷰 「White Collar Jobs, Hyperscalers, AI Coding, Open vs Closed, Agents, and more! (Matt Garman)」입니다. 2025년 8월 19~20일에 여러 매체가 이 인터뷰를 보도했습니다. 보도에서 확인되는 내용을 나누면 다음과 같습니다.

주장 보도된 표현 확인한 매체
주니어를 AI로 대체하는 생각은 어리석다 "one of the dumbest things I've ever heard" The Stack (TechRadar는 제목에 "The dumbest thing I've ever heard"로 씀)
이유 ① 비용 젊은 직원은 대체로 인건비가 가장 낮은 직원이다 GIGAZINE
이유 ② AI 친숙도 젊은 직원이 AI 도구를 가장 적극적으로 쓴다 GIGAZINE
이유 ③ 10년 뒤 직원 모두가 아무것도 배우지 못했다면 10년 뒤에는 어떻게 할 것인가 GIGAZINE
회사가 할 일 "keep hiring kids out of college and teach them the right ways to build software and decompose problems and think about it" The Stack
개발자 수요 "we're going to need more software developers, not fewer" The Stack

같은 인터뷰에서 그는 "AI가 만든 코드 줄 수"를 내세우는 지표를 "silly metric"이라고도 했습니다. 코드의 양보다 코드가 맞는지가 중요하다는 뜻으로 읽힙니다.

교훈: 이 발언의 핵심 동사는 "뽑는다"보다 "가르친다"입니다. 가르칠 내용으로 꼽은 것은 소프트웨어를 제대로 만드는 법, 문제를 쪼개는 법, 생각하는 법입니다. 주니어가 혼자서도 연습할 수 있는 목록이기도 합니다.

2. 연습 ① — AI에게 맡기기 전에 규칙 표를 먼저 쓴다

"문제를 쪼갠다"는 말은 막연하게 들립니다. 강의에서는 이것을 규칙 표를 먼저 쓰는 일로 바꿔 연습합니다. 위키의 Spring 실습 과제인 도서 대여 REST API는 기능 설명보다 규칙 표가 먼저 나옵니다. 일부를 옮기면 이렇습니다.

번호 규칙 위반 시 응답
R3 이미 대출 중인 도서는 다시 대출할 수 없다 409 BOOK_ALREADY_LOANED
R4 반납 기한이 지난 대출이 있는 회원은 새로 대출할 수 없다 409 OVERDUE_MEMBER
R5 한 회원이 동시에 빌릴 수 있는 책은 최대 3권이다 409 LOAN_LIMIT_EXCEEDED
R6 반납 기한은 대출일 + 14일이다 —

AI에게 "도서 대여 API 만들어 줘"라고 하면 그럴듯한 CRUD가 나옵니다. 그 안에 연체 회원을 막는 규칙이 있는지, 위반하면 어떤 상태 코드가 나가는지는 요청한 사람이 정하지 않았으니 AI가 추측해서 채웁니다. 규칙 표를 먼저 쓰면 요청이 "R4를 서비스 계층에 구현하고, 위반하면 409와 OVERDUE_MEMBER를 돌려줘"로 바뀝니다. 요청 단위가 작아지고, 결과를 판정할 기준이 생깁니다.

교훈: 규칙에 번호를 붙일 수 있으면 문제를 쪼갠 것입니다. 번호를 붙이지 못하면 아직 AI에게 맡길 단계가 아닙니다.

3. 연습 ② — 판정은 테스트가 한다

2025년 Stack Overflow 개발자 설문에서 응답자의 66%가 AI 도구를 쓰며 겪는 가장 큰 불만으로 "거의 맞지만 완전히 맞지는 않은 답"을 꼽았습니다. 거의 맞는 코드는 눈으로 읽어서는 잘 걸러지지 않습니다. 그래서 과제는 규칙마다 테스트를 요구합니다. 아래는 위키 과제의 모범 답안에 실린 R4 판정 테스트입니다.

@Test
void 반납_기한이_지난_대출이_있으면_연체로_판단한다() {
    Member member = em.persist(new Member("김자바", "java@library.test"));
    Book book = em.persist(new Book("9788966262281", "이펙티브 자바", "조슈아 블로크"));
    LocalDate today = LocalDate.now();
    em.persist(new Loan(member, book, today.minusDays(20)));   // 기한 = 6일 전

    boolean overdue = loanRepository.existsByMemberIdAndStatusAndDueDateBefore(
            member.getId(), LoanStatus.LOANED, today);

    assertThat(overdue).isTrue();
}

순서가 중요합니다. 이 테스트는 AI에게 구현을 맡기기 전에 사람이 씁니다. 그러면 AI가 내놓은 리포지토리 메서드를 한 줄씩 의심하며 읽는 대신 ./mvnw test로 판정할 수 있습니다. 실패하면 실패 메시지를 그대로 AI에게 돌려줍니다. 구현 전에 테스트가 먼저 실패하는 것을 확인하는 습관은 TDD 3법칙의 첫 번째 법칙과 같습니다.

교훈: AI가 "구현했습니다"라고 말하는 것과 테스트가 통과하는 것은 다른 사건입니다. 주니어가 먼저 익힐 것은 두 번째 사건을 만드는 능력입니다.

4. 연습 ③ — "컴파일되지만 틀린" 함정을 목록으로 갖는다

테스트를 쓰려면 무엇이 틀릴 수 있는지 알아야 합니다. Spring에는 컴파일도 되고 실행도 되는데 결과가 틀리는 기본값 함정이 있습니다. 위키에 정리해 둔 것 가운데 실습 과제에서 실제로 마주치는 것을 골랐습니다.

함정 겉으로 보이는 증상 잡아내는 확인
@Enumerated 기본값이 ORDINAL 상태가 DB에 0, 1로 저장되고, enum 순서를 바꾸면 기존 데이터의 의미가 바뀜 H2 콘솔에서 STATUS 컬럼에 문자열(LOANED)이 있는지 확인
@Transactional은 체크 예외에서 롤백하지 않음 IOException이 났는데 주문은 DB에 남음 예외를 던진 뒤 저장 여부를 검사하는 테스트
open-in-view: false에서 컨트롤러가 지연 로딩 대출 응답에서 LazyInitializationException API 테스트로 응답 본문까지 확인
Boot 3.x 자료의 테스트 import를 Boot 4에서 사용 테스트 컴파일 실패 (package ... does not exist) 프로젝트 버전과 자료의 버전을 먼저 대조

네 번째 줄은 AI와 일할 때 특히 자주 떠올리게 됩니다. 참고한 자료가 만들어진 시점과 지금 쓰는 버전이 다르면, 사람이 쓴 블로그든 AI의 답이든 옛 경로를 자신 있게 내놓을 수 있습니다. 이 목록을 아는 사람은 AI의 답에서 어디를 먼저 의심해야 하는지 압니다.

교훈: 검증 능력은 막연한 감각이 아니라 이름 붙은 함정 목록입니다. 함정 하나를 알 때마다 테스트를 하나 더 쓸 수 있습니다.

5. 리뷰 어휘로 AI 코드에 코멘트한다

마지막 연습은 말로 지적하는 일입니다. 위키의 코드 작성·점검 가이드는 신입 교육용으로 세 가지 습관을 권합니다. PR을 올리기 전에 작성 체크리스트를 확인하고, 리뷰할 때는 클린 코드 17장의 휴리스틱 이름으로 코멘트하고, 한 달 뒤 자기 PR을 돌아보며 어떤 항목을 어겼는지 확인합니다.

AI가 쓴 코드도 같은 방식으로 읽습니다. "뭔가 이상하다" 대신 "컨트롤러에 업무 규칙을 검사하는 if가 있다", "엔티티를 응답으로 그대로 반환한다"처럼 과제 채점 기준의 문장으로 지적합니다. 기준 문장이 있으면 AI에게 돌려줄 수정 요청도 정확해집니다.

과제의 도전 과제 5번은 이 연습의 마지막 단계입니다. 두 요청이 동시에 같은 책을 빌리면 둘 다 성공할 수 있는 상황(검사 후 실행 경쟁 조건)을 직접 재현하고, @Version 낙관적 락이나 DB 제약으로 막습니다. 문제를 재현하는 테스트부터 만들어야 하므로, 무엇을 증명할지 정하는 일은 AI에게 넘길 수 없습니다.

교훈: 이름을 붙여 지적할 수 있어야 고치게 할 수 있습니다. 리뷰 어휘는 사람 동료에게도, AI에게도 똑같이 통합니다.

가먼이 말한 세 가지를 이 글의 연습과 짝지으면 다음과 같습니다.

가먼이 말한 것 이 글의 연습 연습 결과물
문제를 쪼개는 법 규칙 표를 먼저 쓴다 번호 붙은 규칙 R1~R7
소프트웨어를 제대로 만드는 법 규칙마다 테스트를 먼저 쓴다 실패에서 통과로 바뀌는 테스트
생각하는 법 함정 목록과 리뷰 어휘로 AI 코드를 읽는다 이름 붙은 코멘트와 재현 테스트

💡 원스의 인사이트: AI가 대신 못 하는 일은 판정 기준을 만드는 일입니다

강의 교재를 만들 때 저는 규칙 표와 채점 기준을 구현 설명보다 앞에 둡니다. 코드 작성은 AI가 꽤 잘 도와주지만, 무엇이 맞는 결과인지 정하는 일은 요청하는 사람의 몫으로 남기 때문입니다.

가먼이 "10년 뒤"를 걱정한 것도 같은 지점이라고 봅니다. 신입 시절에 판정 기준을 직접 만들어 본 사람이 나중에 시니어가 됩니다. AI를 쓰지 말자는 이야기가 아닙니다. 맡기기 전에 규칙을 쓰고, 맡긴 뒤에는 테스트로 판정하는 순서를 손에 익히자는 이야기입니다.

체크리스트 — AI와 함께 과제를 할 때

  • [ ] 구현을 맡기기 전에 업무 규칙을 번호 붙은 표로 썼다
  • [ ] 규칙마다 실패하는 테스트를 먼저 만들었다
  • [ ] AI의 "완료" 보고가 아니라 ./mvnw test 결과로 끝을 판단했다
  • [ ] 사용하는 Spring Boot 버전과 참고 자료·AI 답의 버전을 대조했다
  • [ ] AI 코드에 남긴 코멘트를 채점 기준이나 휴리스틱 이름으로 표현했다

참고 자료 및 출처