주니어 개발자의 AI 활용 워크플로우 — 먼저 짜고, 비교하고, 성장하기

목차

• AI가 다 짜주는데, 왜 나는 실력이 안 붙을까?
• 5단계 워크플로우: 먼저 짜고, 비교하고, 성장하기
  • 1단계: 직접 짠다 (30분~1시간 제한)
  • 2단계: 막혔을 때 분기한다
  • 3단계: 동작하는 코드를 완성한다
  • 4단계: AI에게 내 코드를 리뷰시킨다
  • 5단계: 내 코드와 AI 제안의 차이를 분석한다
• 왜 이 순서여야 하는가: 각 단계의 학습 효과
• 워크플로우의 약점과 보완: 자기 검증
  • 작업 유형별 워크플로우 분기표
• 생산성 격차 문제: 느린데 괜찮은 건가?
• 절대 하지 말아야 할 3가지
• 실전 적용 체크리스트
• FAQ
• 결론: 10분의 차이가 6개월의 실력을 가른다

AI가 다 짜주는데, 왜 나는 실력이 안 붙을까?

"옆자리 동료는 Cursor로 한 시간 만에 끝내는 작업을 나는 하루 종일 붙잡고 있다. 나도 AI에게 맡겨버릴까?"

주니어 개발자라면 하루에도 몇 번씩 이 유혹이 찾아온다. AI에게 맡기면 빠르다. 당장의 산출물은 나온다. 하지만 한 달이 지나도 빈 에디터 앞에서 손이 멈추는 건 여전하다. 반대로 AI를 완전히 배제하면 생산성에서 뒤처진다. 팀에 민폐가 된다.

문제는 AI를 쓰느냐 안 쓰느냐가 아니다. 어떤 순서로, 어떤 역할로 쓰느냐의 문제다. 이 글에서는 AI를 활용하면서도 실력을 확실하게 키울 수 있는 5단계 워크플로우를 제시한다. 읽고 나면 오늘 작업부터 바로 적용할 수 있다.

팀에서 AI 코딩 전략을 수립하고 있다면, 이 워크플로우를 주니어 개발자 온보딩 가이드에 포함하는 것을 고려해 보라. 성장과 생산성을 동시에 잡는 기준이 될 수 있다.

5단계 워크플로우: 먼저 짜고, 비교하고, 성장하기

이 워크플로우의 핵심은 단순하다. 내 코드가 먼저 존재해야 비교할 기준이 생긴다. 비교할 기준이 있어야 학습이 일어난다. 전체 흐름은 다음과 같다.

1. 직접 짠다 (30분~1시간 제한)
   ↓
2. 막혔을 때 분기:
   ├─ 개념적 막힘 → AI에게 "개념"을 묻는다 (코드 말고)
   └─ 설정/문법 막힘 → AI로 즉시 해결한다
   ↓
3. 동작하는 코드를 완성한다
   ↓
4. AI에게 내 코드를 리뷰시킨다
   ↓
5. 내 코드와 AI 제안의 차이를 분석한다
   → 이 단계가 학습 효율이 가장 높은 구간

각 단계를 구체적으로 살펴보자.

1단계: 직접 짠다 (30분~1시간 제한)

첫 번째 원칙은 명확하다. AI보다 내가 먼저 코드를 짠다. 시간 제한은 30분에서 1시간이다. 이 제한이 중요한 이유가 있다. 제한 없이 "끝까지 혼자 하겠다"고 버티면 비효율적인 삽질에 빠진다. 반대로 5분 만에 포기하면 능동적 생성의 기회를 놓친다.

완벽한 코드를 짤 필요는 없다. 에러가 나도 괜찮다. 핵심은 "내가 먼저 생각하고 시도했다"는 사실 자체다. 이 과정에서 뇌에 문제 구조가 각인된다. 이후 AI의 코드를 볼 때 비교 기준이 생긴다.

2단계: 막혔을 때 분기한다

30분에서 1시간이 지났는데 막혔다면, 막힌 지점의 성격을 먼저 판단한다. 이 판단이 워크플로우의 핵심 분기점이다.

분기 A: 개념적으로 막혔을 때

"이 개념 자체를 모르겠다", "이 패턴이 왜 이렇게 동작하는지 모르겠다"는 상황이다. 이때는 AI에게 개념을 묻는다. 코드를 짜달라고 하는 것이 아니다.

• 좋은 질문: "GenServer에서 call과 cast의 차이가 뭐야?"
• 좋은 질문: "React에서 useEffect의 cleanup 함수가 언제 실행되는지 설명해줘"
• 나쁜 질문: "이 기능 코드 짜줘"

AI를 선생님으로 활용하는 구간이다. 개념을 이해한 후 다시 직접 구현으로 돌아온다.

분기 B: 설정이나 문법에서 막혔을 때

"config 파일에서 에러가 나는데 뭐가 잘못인지 모르겠다", "이 라이브러리의 import 경로가 맞는지 모르겠다"는 상황이다. 이런 문제는 학습 가치가 낮다. AI로 즉시 해결한다.

• 적합한 질문: "이 Webpack config 에러 뭐 때문이야?"
• 적합한 질문: "TypeScript에서 이 타입 에러 어떻게 해결해?"

설정과 오타 문제에 1시간을 쓰는 것은 성장이 아니라 시간 낭비다. 이 판단을 빠르게 내리는 것도 실력이다.

Pro Tip: 막혔을 때 "이게 개념 문제인가, 설정 문제인가?"를 스스로 판단하는 연습을 하라. 이 판단 자체가 문제 분류 능력을 키운다. 처음에는 어렵지만, 2주만 의식적으로 하면 자동화된다.

3단계: 동작하는 코드를 완성한다

2단계를 거쳐 개념을 보충하거나 설정 문제를 해결한 후, 동작하는 코드를 완성한다. 완벽하지 않아도 된다. 깔끔하지 않아도 된다. 핵심은 "내 코드"가 존재하는 것이다.

왜 완성이 중요한가? 다음 단계인 리뷰와 비교를 하려면 비교 대상이 필요하기 때문이다. "반쯤 짜다가 포기하고 AI한테 맡겼다"면 비교할 기준이 없다. 내 코드가 있어야 AI의 제안과 나란히 놓고 차이를 볼 수 있다.

4단계: AI에게 내 코드를 리뷰시킨다

동작하는 코드가 완성되었으면, AI에게 리뷰를 요청한다. 이 단계가 잘못된 패턴의 체화를 방지하는 핵심 구간이다.

구체적인 프롬프트 예시는 다음과 같다.

• "이 코드의 문제점이 뭐야? 더 나은 방법이 있어?"
• "이 함수의 성능을 개선할 수 있는 부분이 있을까?"
• "이 설계에서 놓치고 있는 엣지 케이스가 있어?"

혼자만 코드를 짜면 자기 사고 범위에 갇힌다. 잘못된 패턴을 반복해도 알아차리지 못한다. AI 리뷰는 이 맹점을 저비용으로 커버한다. 시니어 개발자에게 매번 리뷰를 요청하기 어려운 상황에서, AI는 24시간 대기하는 리뷰어 역할을 해준다.

5단계: 내 코드와 AI 제안의 차이를 분석한다

이 단계가 학습 효율이 가장 높은 구간이다. AI가 리뷰에서 제안한 개선 코드와 내 코드를 나란히 놓고 비교한다.

이때 확인해야 할 것은 세 가지다.

1. 무엇이 다른가? — 변수명, 구조, 패턴, 알고리즘 중 어디가 다른지 식별한다.
2. 왜 다른가? — AI의 방식이 더 나은 이유를 이해한다. 납득이 안 되면 추가 질문한다.
3. 내가 왜 그렇게 짰는가? — 내 사고 과정의 어느 지점에서 갈렸는지 추적한다.

이 분석이 강력한 이유가 있다. 좋은 코드 읽기와 내 약점 인식이 동시에 발생하기 때문이다. 단순히 좋은 코드를 읽는 것보다, 내 코드와 비교하면서 읽는 것이 체화 속도가 빠르다. "아, 나는 여기서 이렇게 생각했는데, 이 방식이 더 나은 이유는 이거구나"라는 인식이 만들어진다.

왜 이 순서여야 하는가: 각 단계의 학습 효과

각 단계가 생략 불가능한 이유를 정리하면 다음과 같다.

특히 주목할 것은 4단계와 5단계의 결합 효과다. 4단계 없이 혼자만 짜면 잘못된 패턴을 반복하게 된다. 5단계 없이 리뷰만 받으면 "아 그렇구나" 하고 넘어가기 쉽다. 두 단계가 합쳐져야 "발견 → 이해 → 체화"의 학습 루프가 완성된다.

워크플로우의 약점과 보완: 자기 검증

어떤 워크플로우든 모든 상황에 완벽하게 적용되지는 않는다. 이 워크플로우의 약점을 먼저 인식하고, 보완 방법을 함께 제시한다.

약점 1: 모든 코딩 작업에 동일한 방식을 적용할 수 없다.

로직 구현, 아키텍처 설계, 프레임워크 학습은 성격이 다르다. 같은 "직접 짜기"라도 영역마다 효율이 달라진다.

약점 2: "완성한 후 리뷰"는 완성을 전제로 한다.

완전히 막혀서 동작하는 코드를 완성하지 못하는 경우도 있다. 이때 워크플로우가 멈춰버린다.

약점 3: AI 리뷰가 주니어에게 항상 소화 가능하지 않다.

AI가 고급 패턴이나 복잡한 리팩토링을 제안했을 때, 주니어가 그것을 이해하지 못할 수 있다.

보완: 작업 유형별 분기

이 약점들을 보완하려면, 작업 유형에 따라 워크플로우 자체를 분기시켜야 한다.

로직/비즈니스 규칙 → 기본 워크플로우 그대로 적용

조건 분기, 데이터 변환, 유효성 검증 등은 직접 짜는 것의 학습 가치가 가장 높다. 5단계 워크플로우를 그대로 따른다.

설계/아키텍처 → 읽기 먼저, 그 다음 짜기

좋은 설계 예제를 먼저 학습한다. 그 다음 자기 상황에 맞게 변형하여 구현한다. 마지막으로 AI에게 리뷰를 받는다. "직접 짜기"가 아닌 "읽기 → 짜기 → 리뷰" 순서다.

프레임워크 학습 → 공식 문서 → 따라 짜기 → 변형

프레임워크는 설계자의 의도를 이해하는 것이 먼저다. 공식 문서를 읽고, 가이드를 따라 짜보고, 그 다음 자신만의 변형을 시도한다.

작업 유형별 워크플로우 분기표

Pro Tip: "완성을 못 했을 때"의 대안은 이렇다. 완성하지 못한 코드라도 AI에게 보여줘라. "여기까지 짰는데 막혔어. 내 접근 방식의 문제가 뭐야?"라고 물으면 된다. 완성된 코드 vs AI 제안이 아니라, "내 시도 vs AI의 진단"으로 비교 축을 바꾸면 학습은 여전히 일어난다.

코드 리뷰 워크플로우를 팀 차원에서 도입하고 싶다면, 이 분기표를 기준으로 팀 내 가이드라인을 만들어 보라. 작업 유형별로 AI 활용 범위를 명확히 하면 팀 전체의 코드 품질과 성장 속도를 동시에 관리할 수 있다.

생산성 격차 문제: 느린데 괜찮은 건가?

이 워크플로우를 따르면 당연한 질문이 생긴다. "AI에게 다 맡기는 동료보다 내가 느린데, 괜찮은 건가?"

솔직하게 말하자. 느린 것은 사실이다. AI에게 전부 맡기는 사람은 1시간 안에 끝낼 작업을, 이 워크플로우를 따르면 2~3시간이 걸릴 수 있다. 단기적으로 산출물 양에서 밀릴 수밖에 없다.

하지만 숫자를 냉정하게 따져보자.

4단계(리뷰)와 5단계(차이 분석)에 걸리는 시간은 10분이면 충분하다. 코드를 완성한 후 AI에게 리뷰를 요청하고, 차이를 분석하는 데 10분이다. 기존에 "직접 짜고 끝"이던 방식에서 10분만 추가하면 핵심 맹점 3개를 커버할 수 있다.

• 잘못된 패턴의 체화 방지
• 더 나은 접근법 인식
• 내 약점의 구체적 파악

동료와의 당장의 속도 격차는 이 워크플로우로 좁혀지지 않는다. 하지만 이 격차가 "의미 있는 투자 기간"인지, "그냥 뒤처지고 있는 것"인지는 워크플로우를 쓰고 있느냐로 갈린다. 10분의 투자를 하고 있는 사람과 아닌 사람은 반년 후에 완전히 다른 위치에 서 있다.

절대 하지 말아야 할 3가지

워크플로우를 올바르게 실행하는 것만큼, 하지 말아야 할 것을 아는 것도 중요하다. 다음 세 가지는 성장을 가장 효과적으로 방해하는 안티패턴이다.

1. AI가 먼저 짠 코드를 읽으면서 "공부한다"고 착각하는 것

AI가 생성한 코드를 읽으면 이해가 된다. "아, 이렇게 하면 되는구나." 그래서 공부가 된 것 같다. 하지만 이것은 이해의 착각이다.

읽고 이해하는 것과 직접 생성하는 것은 전혀 다른 인지 과정이다. 수학 풀이를 읽으면 납득이 되지만, 책을 덮으면 풀지 못하는 것과 같은 구조다. AI 코드를 먼저 보는 순간, 능동적 생성의 기회는 사라진다.

2. 설정/타이포 문제에서 1시간 이상 삽질하는 것

Webpack config 오류, import 경로 문제, 환경 변수 오타. 이런 문제에 1시간 이상 매달리는 것은 학습이 아니라 시간 낭비다.

이 유형의 문제에서 얻는 교훈은 "다음에는 오타를 조심하자" 정도다. 개념적 성장과 무관하다. 15분 이상 걸리면 즉시 AI에게 물어보라. 절약한 시간을 학습 가치가 높은 곳에 투자하라.

3. 직접 짠 후 리뷰 없이 넘어가는 것

"돌아가니까 됐다"는 위험한 판단이다. 동작하는 코드가 곧 좋은 코드인 것은 아니다. 리뷰 없이 넘어가면 잘못된 패턴이 습관으로 굳어진다.

한 번 체화된 안티패턴은 나중에 교정하는 데 배의 비용이 든다. 10분이면 끝나는 리뷰 과정을 건너뛰는 것은, 10분을 아끼고 나중에 10시간을 잃는 선택이다.

실전 적용 체크리스트

오늘 작업부터 이 워크플로우를 적용하기 위한 체크리스트다.

작업 시작 전

• 이 작업의 유형을 식별했다 (로직 / 설계 / 프레임워크)
• 작업 유형에 맞는 워크플로우 분기를 선택했다
• 타이머를 30분~1시간으로 설정했다

작업 중

• AI보다 내가 먼저 코드를 짜기 시작했다
• 막혔을 때 "개념 문제인가, 설정 문제인가"를 판단했다
• 개념 질문은 코드 요청이 아닌 개념 설명으로 요청했다
• 설정/문법 문제는 15분 이내에 AI로 해결했다

작업 완료 후

• 동작하는 코드를 완성했다 (완벽하지 않아도 됨)
• AI에게 코드 리뷰를 요청했다
• 내 코드와 AI 제안의 차이를 분석했다
• 분석에서 발견한 것을 한 줄이라도 기록했다

9개 이상 체크하고 있다면 이 워크플로우를 제대로 실행하고 있는 것이다. 7개 이하라면 빠지고 있는 단계를 점검하라.

FAQ

Q1. 이 워크플로우를 모든 작업에 적용해야 하나요? 급한 버그 핫픽스에도?

아니다. 프로덕션 긴급 대응이나 단순 반복 작업까지 이 워크플로우를 적용할 필요는 없다. "학습이 필요한 작업"과 "실행만 하면 되는 작업"을 구분하라. 이미 충분히 이해하고 있는 영역의 반복 작업이라면 AI에게 바로 맡겨도 된다. 이 워크플로우는 "아직 체화되지 않은 영역"에서 성장하기 위한 전략이다. 급한 핫픽스를 처리한 후, 사후에 코드를 분석하며 학습하는 방식으로 보완할 수 있다.

Q2. 4~5단계를 했는데, AI의 리뷰가 너무 어려워서 이해가 안 됩니다. 어떻게 하면 좋을까요?

AI의 제안이 이해되지 않는 것은 자연스러운 상황이다. 이때는 AI에게 추가 질문을 하라. "이 패턴을 더 쉽게 설명해줘", "이게 왜 더 나은지 비유로 설명해줘", "단계별로 하나씩 바꿔보면 어떻게 되는지 보여줘"라고 요청하면 된다. 한 번에 모든 제안을 소화할 필요는 없다. 제안 중 하나라도 이해하고 적용했다면 그것으로 충분하다. 나머지는 실력이 오르면 자연스럽게 소화할 수 있게 된다.

Q3. 이 워크플로우를 팀 차원에서 도입하고 싶은데, 어떻게 시작하면 좋을까요?

가장 현실적인 시작점은 코드 리뷰 프로세스에 5단계를 연결하는 것이다. PR을 올리기 전에 "AI 리뷰를 먼저 받고, 차이점을 PR 설명에 기록하라"는 가이드라인만 추가해도 효과가 크다. 팀 전체에 한꺼번에 적용하기보다, 한두 명이 2주간 실행해보고 효과를 공유하는 방식이 저항감 없이 도입하기에 좋다.

결론: 10분의 차이가 6개월의 실력을 가른다

이 글에서 제시한 5단계 워크플로우의 핵심을 다시 정리하면 이렇다.

1. 내가 먼저 짠다. 능동적 생성이 학습의 출발점이다.
2. 막히면 분기한다. 개념은 묻고, 설정은 바로 해결한다.
3. 동작하는 코드를 완성한다. 비교 기준을 확보한다.
4. AI에게 리뷰시킨다. 안티패턴 체화를 방지한다.
5. 차이를 분석한다. 좋은 코드 읽기와 약점 인식이 동시에 일어난다.

AI 코딩 전략의 본질은 "AI를 쓰느냐 안 쓰느냐"가 아니다. 어떤 순서로, 어떤 역할로 쓰느냐다. 이 워크플로우에서 4단계와 5단계에 투자하는 시간은 10분이다. 기존 작업 방식에서 10분만 추가하면 된다.

AI에게 전부 맡기는 동료보다 당장은 느릴 수 있다. 하지만 그 10분의 투자를 매일 반복하는 사람과 그렇지 않은 사람은, 6개월 후 전혀 다른 개발자가 되어 있을 것이다.

지금 진행 중인 작업 하나를 골라라. 오늘부터 5단계 워크플로우를 적용해 보라. AI에게 코드를 요청하기 전에, 먼저 에디터를 열고 직접 짜기 시작하라. 그 30분이 시작점이다.