비전공자 프론트엔드 부트캠프 생존기: 하루 8시간, 6개월을 버티는 학습법

부트캠프 커뮤니티에서 반복적으로 올라오는 고민이 있다. "JavaScript 변수 선언 세 가지가 뭔지는 아는데, 왜 세 가지인지 모르겠어요. let이랑 const 차이를 강사님이 설명할 때는 알겠는데, 혼자 코드를 치면 머리가 하얘져요." 비전공자 부트캠프 수강생 대부분이 겪는 상황이다. 문법을 외웠는데 코드를 못 짜고, 수업을 따라갔는데 혼자서는 한 줄도 못 쓴다. 강의실에서는 고개를 끄덕이다가 회고 시간에 키보드 앞에 앉으면 막막해진다.

이 글에서는 비전공자가 6개월 프론트엔드 부트캠프를 수료하고, 취업까지 이어지는 학습법을 다룬다. 하루 6시간 교육, 2시간 회고라는 구조 안에서 시간을 어떻게 쓰는지, 8시간이 끝난 뒤에는 무엇을 하는지, 그리고 AI 코딩 도구가 쏟아지는 2026년에 비전공자가 어떤 전략으로 공부해야 하는지를 구체적으로 짚는다.

한 가지 먼저 말해두고 싶다. 비전공자라서 불리하다는 생각은 반은 맞고 반은 틀리다. 컴퓨터공학과 출신은 자료구조와 알고리즘을 4년간 배우면서 프로그래밍적 사고를 체득한다. 그 기반이 없는 비전공자가 6개월 만에 같은 수준에 도달하기는 어렵다. 하지만 프론트엔드라는 분야는 시각적 결과물이 즉시 나오고, 사용자 경험이라는 관점에서 비전공 배경이 오히려 강점이 되기도 한다. 디자인을 했던 사람, 마케팅을 했던 사람, 글을 쓰던 사람이 프론트엔드에서 빛을 발하는 경우를 여러 번 봤다.

문제는 학습법이다. 같은 6개월을 보내도 어떻게 공부하느냐에 따라 결과가 완전히 달라진다.

6시간 교육 시간, "듣기"가 아니라 "따라 치기"다

부트캠프 교육 시간에 가장 흔한 실수가 있다. 강사의 설명을 필기하면서 듣는 것이다. 대학 수업처럼 노트에 적거나, 강의 슬라이드를 캡처하거나, 코드를 그대로 타이핑해서 옮기는 행위다. 왜 문제인지는 학습 연구에서 이미 밝혀져 있다.

Karpicke & Roediger(2008) 연구에 따르면, 수동적으로 읽고 듣는 것보다 스스로 떠올리는 연습이 장기 기억에 2~3배 효과적이다. Ali Abdaal의 학습법 가이드에서도 같은 결론을 내린다. 강의를 듣고 필기하는 행위는 "수동적 입력"에 해당한다. 정보가 눈과 손을 스쳐 지나갈 뿐, 뇌에는 제대로 새겨지지 않는다.

그러면 교육 시간에 무엇을 해야 하는가.

첫째, 강사가 코드를 칠 때 화면을 보면서 따라 치되, 강사보다 한 발 앞서 예측하면서 친다. "여기서 map을 쓰겠지", "이 다음에 return이 나오겠지"라고 머릿속으로 먼저 생각한 뒤에 키보드를 누른다. 맞으면 이해하고 있는 것이고, 틀리면 바로 그 지점이 학습 포인트다.

둘째, 강사가 설명하는 "왜"를 주석으로 남긴다. 코드 자체를 필기하지 말고, 코드 위에 왜 이 코드가 필요한지를 한 줄 주석으로 적는다.

// 배열의 각 요소를 순회하면서 새로운 배열을 만들어야 하니까 map을 쓴다
// forEach는 undefined를 반환하니까 여기서는 안 된다
const doubled = numbers.map(num => num * 2);

이 주석이 나중에 복습할 때 가장 쓸모 있는 단서가 된다. 코드만 남아 있으면 "이걸 왜 이렇게 했지?"부터 다시 시작해야 한다. "왜"가 적혀 있으면 맥락이 바로 복원된다.

셋째, 이해가 안 되는 순간을 표시한다. 그냥 넘어가면 안 된다. 이해 안 되는 부분을 코드 옆에 // ???로 표시하거나, 메모장에 "클로저 개념이 헷갈림 - 함수가 외부 변수를 기억한다는 게 구체적으로 뭔지"처럼 질문 형태로 적어둔다. 이 질문 목록이 회고 시간과 방과 후 학습의 핵심 재료가 된다.

현업 개발자에게 들어보니, 부트캠프 시절 가장 후회하는 것이 "수업 시간에 100% 이해하려고 했던 것"이라고 한다. 교육 시간에 모든 것을 이해하려고 하면 오히려 전체 흐름을 놓친다. 70% 이해하고, 30%는 "이건 나중에 잡는다"라고 표시해두는 게 현실적인 전략이다.

교육 시간 실전 루틴

6시간 교육을 최대한 활용하려면 시간대별로 접근 방식을 달리해야 한다.

오전(3시간)은 보통 새로운 개념이 등장하는 시간이다. 이때는 코드를 따라 치면서 "왜"를 주석으로 남기고, 모르는 부분을 표시하는 데 집중한다. 점심 직후 20분은 오전에 배운 핵심 개념 3가지를 메모장에 자기 말로 적어본다. 이것만 해도 오전에 배운 것이 머리에 훨씬 잘 남는다.

오후(3시간)는 실습 위주로 돌아가는 경우가 많다. 실습 시간에는 "동작하는 코드"를 만드는 것에 집착하지 않는다. 에러가 나면 에러 메시지를 읽고, 왜 이 에러가 나는지를 파악하는 데 시간을 쓴다. 현업에서 개발자가 하는 일의 절반은 에러를 읽고 원인을 추적하는 것이다. 에러를 피하지 않고 들여다보는 습관, 부트캠프에서 반드시 길러야 할 능력이다.

// 이런 에러가 나면 당황하지 말고 읽어보자
// TypeError: Cannot read properties of undefined (reading 'map')

// 이 에러가 말하는 것:
// 1. 어떤 값이 undefined인데
// 2. 그 undefined에 .map()을 호출하려고 했다
// 3. 그러면 .map() 앞에 있는 변수가 뭔지 확인하면 된다

// 흔한 원인: API 응답이 아직 안 왔는데 렌더링하려고 할 때
const UserList = ({ users }) => {
  // users가 undefined일 수 있으니 방어 코드를 넣는다
  if (!users) return <p>로딩 중...</p>;

  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
};

이런 에러 하나를 직접 만나서 해결한 경험이 강의 10시간보다 기억에 오래 남는다.

2시간 회고, 하루 학습의 승패를 가르는 시간

많은 수강생이 회고 시간을 "자습 시간"으로 취급한다. 오늘 못 다 한 실습을 마저 하거나, 이해 안 되는 부분을 인터넷으로 검색하거나, 다음 날 내용을 미리 보는 식이다. 이것이 틀렸다고 말하기는 어렵지만, 훨씬 나은 방법이 있다.

인지과학에서 반복 검증된 학습법이 두 가지 있다. "능동적 회상"과 "간격 반복"이다. 버밍엄시티대학교에서 정리한 2357 방법이 이를 잘 보여준다. 수업 직후에 한 번, 다음 날에 한 번, 3일 뒤에 한 번, 7일 뒤에 한 번 복습하면 장기 기억 전환율이 크게 올라간다. 회고 시간이 바로 이 "수업 직후 첫 번째 복습"에 해당한다.

회고 2시간 분배법

이 2시간을 30분 단위로 나눠서 쓰는 것을 권한다.

다음 그림은 회고 2시간을 30분 단위로 나눠서 활용하는 방법을 보여준다.

회고 2시간 활용법 타임라인

빈 종이 테스트로 기억을 끄집어내고, 코드를 보지 않고 다시 짜보고, 동료와 질문을 주고받고, 다음 날 학습을 미리 훑어보는 흐름이다. 이 순서를 매일 반복하면 장기 기억 전환율이 크게 올라간다.

첫 30분은 "빈 종이 테스트"다. 오늘 배운 핵심 개념 3가지를 에디터를 열고, 아무것도 보지 않고 자기 말로 설명을 적어본다. 예를 들어 오늘 JavaScript의 배열 메서드를 배웠다면 이렇게 적는다.

[오늘 배운 것 - 빈 종이 테스트]

1. map: 배열의 각 요소를 변환해서 새 배열을 만든다.
   원래 배열은 안 바뀐다. forEach랑 다른 점은 반환값이 있다는 것.
   예시: [1,2,3].map(x => x * 2) -> [2,4,6]

2. filter: 조건에 맞는 요소만 골라서 새 배열을 만든다.
   콜백 함수가 true를 반환하는 요소만 남긴다.
   예시: [1,2,3,4].filter(x => x > 2) -> [3,4]

3. reduce: 배열을 하나의 값으로 줄인다.
   누적값(acc)이랑 현재값(cur)을 받는다.
   초기값 안 넣으면 첫 번째 요소가 초기값이 된다.
   예시: [1,2,3].reduce((acc, cur) => acc + cur, 0) -> 6

적다가 막히는 부분이 바로 이해가 부족한 부분이다. reduce의 초기값이 왜 필요한지 설명이 안 된다면, 그것이 오늘의 학습 포인트다. freeCodeCamp에서 소개한 파인만 기법도 같은 원리다. 남에게 설명하듯 써보고, 막히는 지점을 파고든다.

두 번째 30분은 "코드 재현"이다. 수업 시간에 작성한 코드를 닫고, 같은 결과물을 처음부터 다시 만들어본다. 그대로 복제하는 것이 아니라 "이 기능을 만들어야 한다"는 목표만 가지고 새로 짜본다. 여기서 막히면 수업 코드를 잠깐 보고, 다시 닫고, 다시 짜본다.

이 과정이 고통스럽다. 분명 수업 때 이해했는데 왜 한 줄도 못 짜지? 하는 좌절감이 든다. 하지만 이 좌절감이야말로 학습이 일어나고 있다는 증거다. 뇌가 정보를 끄집어내려고 애쓰는 과정에서 기억이 더 단단해진다. 쉽게 떠올려지는 것은 이미 아는 것이고, 힘들게 끄집어내야 하는 것이 지금 배우고 있는 것이다.

// 수업 때 만든 것: 할 일 목록의 완료 기능
// 회고 시간에 코드를 보지 않고 다시 만들어본다

// 1차 시도 - 막혀서 10분 고민
const toggleTodo = (todos, id) => {
  return todos.map(todo => {
    if (todo.id === id) {
      return { ...todo, completed: !todo.completed };
    }
    return todo;
  });
};

// 여기서 스프레드 연산자를 왜 쓰는지 설명할 수 있어야 한다
// -> 원본 객체를 직접 수정하면 안 되니까 (불변성)
// -> React에서 상태 변경을 감지하려면 새 객체를 만들어야 하니까

세 번째 30분은 "질문 정리와 동료 토론"이다. 수업 중 // ???로 표시해둔 부분을 꺼내서 정리한다. 질문을 구체적으로 만드는 것이 핵심이다. "클로저가 뭔지 모르겠어요"는 나쁜 질문이다. "함수 안에서 외부 변수를 참조할 때, 그 변수가 사라지지 않는 이유가 뭔가요?"가 좋은 질문이다. 질문을 구체적으로 만드는 과정 자체가 이해를 돕는다.

주변에 동료가 있다면 서로 개념을 설명해준다. "나 오늘 배운 map이랑 forEach 차이를 설명해줄게, 들어봐"라고 하면 된다. 이것이 러버덕 디버깅의 변형이다. 원래는 고무 오리 인형에게 코드를 설명하면서 버그를 찾는 기법인데, 개념 학습에도 같은 원리가 적용된다. 누군가에게 설명하려고 하면 자기가 모르는 부분이 드러난다.

마지막 30분은 "내일 예습"이다. 다음 날 학습할 내용의 키워드를 훑어본다. 깊이 이해하려고 하지 않는다. "내일은 DOM 조작을 배우는구나. DOM이 뭔지 대략 이런 거구나" 정도만 파악한다. 이렇게 하면 다음 날 수업을 들을 때 완전히 새로운 개념이 아니라 "어제 살짝 본 것"이 되어서 이해 속도가 빨라진다. 인지과학에서는 이걸 "선행 조직자" 효과라고 부른다.

8시간 후, 방과 후에 무엇을 할 것인가

하루 8시간 교육이 끝나면 많은 수강생이 두 부류로 나뉜다. 지쳐서 아무것도 안 하는 부류와, 새벽까지 코딩하는 부류다. 둘 다 위험하다.

코스리포트의 부트캠프 가이드에 따르면, 풀타임 부트캠프 수강생은 주 60시간 이상의 학습 시간이 권장된다. 계산을 해보면 이렇다.

주간 학습 시간 계산:
- 교육(6시간) + 회고(2시간) = 하루 8시간 × 5일 = 40시간
- 방과 후 자습: 하루 3시간 × 5일 = 15시간
- 주말 복습: 1일 × 5시간 = 5시간
- 합계: 약 60시간
- 주말 1일은 완전 휴식

하루 교육 8시간에 방과 후 3시간을 더하면 하루 11시간이다. 여기에 주말 하루 복습을 합치면 주 60시간이 된다. 나머지 주말 하루는 반드시 쉬어야 한다.

하지만 12시간을 컴퓨터 앞에 앉아 있다고 12시간을 공부한 것은 아니다. 집중 못 하고 화면만 보는 시간은 빼야 한다. 집중한 2시간이 흐릿한 5시간보다 낫다.

방과 후 3시간 루틴

부트캠프를 거쳐 취업한 개발자들을 보면, 방과 후 3시간을 대체로 이런 식으로 쓴다.

첫 30분은 완전한 전환 시간이다. 산책을 하든, 밥을 먹든, 운동을 하든 코딩과 완전히 관련 없는 활동을 한다. Built In에서 정리한 부트캠프 번아웃 방지 전략에서도 이 전환 시간이 꼭 필요하다고 말한다. 테크 종사자의 57%가 번아웃을 겪었다는 조사도 있다. 6개월 부트캠프는 마라톤이지 단거리 달리기가 아니다. 중간에 쓰러지면 완주할 수 없다.

다음 1시간 30분은 "변형 실습"이다. 오늘 배운 코드를 그대로 치는 것이 아니라, 변형해서 다른 것을 만든다. 오늘 할 일 목록을 만들었다면, 같은 원리로 장보기 목록을 만들어본다. 핵심 로직은 같은데 데이터 구조가 살짝 다른 것을 만들면, 같은 패턴이 다른 상황에서도 먹힌다는 감각이 생긴다.

// 수업에서 만든 것: 할 일 목록
const [todos, setTodos] = useState([]);
const addTodo = (text) => {
  setTodos([...todos, { id: Date.now(), text, completed: false }]);
};

// 변형 실습: 장보기 목록 (수량, 카테고리, 가격 추가)
const [items, setItems] = useState([]);
const addItem = (name, quantity, category, price) => {
  setItems([...items, {
    id: Date.now(),
    name,
    quantity,
    category,
    price,
    purchased: false
  }]);
};

// 카테고리별 필터링 기능 추가 (filter 연습)
const getItemsByCategory = (category) => {
  return items.filter(item => item.category === category);
};

// 총 예상 비용 계산 (reduce 연습)
const getTotalCost = () => {
  return items.reduce((total, item) => total + (item.price * item.quantity), 0);
};

이런 식으로 배운 개념을 다른 맥락에 적용하면 "map은 배열 메서드"라는 추상적 지식이 "map으로 이런 것도 저런 것도 만들 수 있다"는 실전 감각으로 바뀐다.

마지막 1시간은 "공식 문서 읽기"다. 오늘 배운 메서드나 개념의 MDN 문서를 읽는다. 부트캠프 강의만으로는 각 API의 세부 동작이나 엣지 케이스를 다 다루지 못한다. MDN은 프론트엔드 개발자의 성경 같은 존재다. 처음에는 영어라서, 또는 설명이 딱딱해서 읽기 힘들다. 하지만 MDN 문서를 읽는 습관은 부트캠프 이후에도 평생 써먹는 능력이다.

MDN 문서를 읽을 때 팁이 있다. 처음부터 끝까지 읽으려고 하지 않는다. 구조가 항상 같다. "구문(Syntax)" 부분에서 매개변수가 뭔지 확인하고, "예제(Examples)" 부분에서 코드를 직접 쳐보고, "명세(Specifications)" 부분은 건너뛴다.

MDN 문서 읽기 순서:
1. 맨 위 한 줄 설명 읽기
2. 구문(Syntax) 확인 - 매개변수와 반환값
3. 예제(Examples) 따라 치기
4. "이 API를 쓰면 안 되는 상황"이 적혀 있으면 꼭 읽기
5. 브라우저 호환성은 Can I Use로 확인

주말 활용법

주말 중 하나는 주간 복습에 할당한다. 한 주 동안 배운 내용을 빈 종이 테스트로 쭉 훑는다. 월요일에 배운 것이 금요일에 얼마나 남아 있는지 확인하면, 자기 기억력의 패턴을 파악할 수 있다.

나머지 하루는 완전히 쉬거나, 개인 사이드 프로젝트를 한다. 사이드 프로젝트는 거창할 필요 없다. "내가 실제로 쓸 수 있는 것"을 만드는 게 핵심이다. 매일 마시는 커피 기록 앱, 독서 목록 관리 페이지, 동네 맛집 지도 같은 것이다. 작은 프로젝트라도 기획부터 배포까지 혼자 해보면, 부트캠프 과제와는 질이 다른 경험이 된다.

AI 시대, 비전공자의 학습 전략이 바뀌어야 한다

2026년 2월 현재, GitHub Copilot 사용자는 2천만 명을 넘었다. Cursor 에디터는 월 20달러로 AI 코딩 보조를 제공하고, Fortune 100 기업의 90%가 AI 코딩 도구를 사용한다. Java Code Geeks의 분석에 따르면, AI 코딩 도구가 개발자 생산성을 20~30% 끌어올린다고 본다.

그러면 비전공자 부트캠프 수강생도 AI 도구를 적극 활용해야 할까? 앤드류 응 교수가 2026년 1월 세계경제포럼에서 이런 말을 했다. "기초 없이 AI 프로젝트에 바로 뛰어들면 오히려 아무것도 배우지 못한다."

비전공자 부트캠프에도 그대로 적용되는 말이다. AI 도구에 너무 일찍 의존하면 문제가 생긴다.

첫째, 코드가 동작하는 이유를 모른 채 넘어간다. GitHub Copilot이 자동완성한 코드가 돌아가면 "됐다"하고 넘어가는데, 왜 그렇게 작성해야 하는지 이해하지 못한 상태로 다음 단계에 가면 결국 벽에 부딪힌다.

둘째, 에러 해결 능력이 자라지 않는다. AI에게 에러 메시지를 던져주고 해결책을 받는 습관이 들면, 에러를 읽고 추론하는 능력이 발달하지 않는다. 현업에서는 AI가 해결 못 하는 버그가 수두룩하다. 자기 서비스의 비즈니스 로직과 얽힌 버그는 AI가 맥락을 알 수 없기 때문이다.

셋째, 면접에서 걸러진다. 코딩 테스트나 라이브 코딩 면접에서 AI 도구를 쓸 수 없다. 기초가 없으면 면접장에서 한 줄도 못 짠다.

AI 도구의 올바른 활용 타이밍

그렇다고 AI를 완전히 배제하라는 말은 아니다. 시점이 중요하다.

다음 그림은 6개월 부트캠프 기간 동안 AI 도구를 언제, 어떻게 활용해야 하는지 보여준다.

AI 도구 활용 6개월 로드맵

1~2개월차에는 AI를 완전히 끄고 손으로 기초를 다진다. 3~4개월차에는 직접 짠 코드를 AI에게 리뷰받는 학습 보조 도구로 쓴다. 5~6개월차에 비로소 페어 프로그래밍 파트너로 활용하되, 면접에서 설명할 수 없는 코드는 쓰지 않는다는 원칙을 지킨다.

1~2개월차(기초 단계)에는 AI 코딩 도구를 끈다. 자동완성도 끄고, Copilot도 끈다. 모든 코드를 한 글자씩 직접 친다. 이 시기에 손가락이 문법을 기억하게 해야 한다. function 키워드를 수백 번 치다 보면 몸이 기억한다. 이것을 "근육 기억"이라고 한다.

// 1~2개월차: 이런 기초 코드를 반복해서 직접 친다
// AI 자동완성 없이, 한 글자씩

function greet(name) {
  return "안녕하세요, " + name + "님!";
}

// 화살표 함수로도 써본다
const greet = (name) => {
  return `안녕하세요, ${name}님!`;
};

// 더 줄여본다
const greet = (name) => `안녕하세요, ${name}님!`;

3~4개월차(응용 단계)에는 AI를 "학습 보조"로 활용한다. 코드를 직접 짠 뒤에 AI에게 리뷰를 요청한다. "이 코드를 더 개선할 수 있는 부분이 있을까?"라고 물으면 AI가 대안을 제시한다. 이때 AI가 제시한 코드를 복사 붙여넣기하지 않고, 왜 그렇게 바꾸면 나은지를 이해한 뒤에 직접 다시 작성한다.

// 내가 짠 코드
function getAdultUsers(users) {
  const adults = [];
  for (let i = 0; i < users.length; i++) {
    if (users[i].age >= 18) {
      adults.push(users[i]);
    }
  }
  return adults;
}

// AI에게 리뷰를 요청하면 이렇게 제안할 수 있다
const getAdultUsers = (users) => users.filter(user => user.age >= 18);

// 중요한 것: 왜 filter가 나은지 이해하기
// 1. 선언적 코드: "무엇을 하는지"가 코드에 드러난다
// 2. 불변성: 원본 배열을 건드리지 않는다
// 3. 간결함: 의도가 명확하게 전달된다
// 4. 하지만 for문을 모르면 filter를 제대로 쓸 수 없다

5~6개월차(프로젝트 단계)에는 AI를 "페어 프로그래밍 파트너"로 활용한다. 이 시기에는 팀 프로젝트를 하면서 마감에 쫓기게 된다. AI 도구를 활용해서 생산성을 높이되, 생성된 코드를 반드시 이해하고 넘어간다. AI가 제안한 코드를 쓸 때마다 스스로에게 묻는다. "이 코드를 면접관 앞에서 한 줄씩 설명할 수 있는가?" 설명할 수 없으면 쓰지 않는다.

AI 시대에 비전공자가 갖춰야 할 역량

CIO 매거진 기사에 따르면, 생성형 AI 확산으로 개발자의 역할이 재정의되고 있다. 코딩의 희소성은 줄어들지만, 문제 정의 능력, 맥락 파악 능력, 전략적 사고는 오히려 더 중요해지고 있다. ZDNet Korea는 "코딩은 AI가, 전략은 사람이"라는 제목으로 이 변화를 다뤘다.

이 변화가 비전공자에게는 오히려 기회다. 비전공자는 다른 분야의 도메인 지식을 가지고 있다. 금융에서 온 사람은 금융 서비스의 사용자 경험을 잘 안다. 교육에서 온 사람은 학습 플랫폼이 어떻게 작동해야 하는지 직감적으로 안다. 이 도메인 지식이 곧 "문제 정의 능력"이다. AI가 코드를 만들어주는 세상에서, "뭘 만들어야 하는지"를 정의하는 사람이 더 가치 있어진다.

6개월 부트캠프, 결국 포트폴리오가 말한다

코드트리의 2025년 개발자 취업 현실 분석에 따르면, 대기업 공채는 줄어들고 상시 채용이 주류가 되고 있다. 신입 개발자에게 더 높은 실무 역량을 요구하는 추세다. 프론트엔드 신입 개발자의 평균 연봉은 3,000~3,500만 원 수준으로, 비전공자가 부트캠프 6개월 만에 이 시장에 들어가려면 포트폴리오가 거의 전부다.

코드스테이츠 블로그에서 강조하는 프론트엔드 포트폴리오의 핵심은 "트러블 슈팅 과정"이다. 완성된 결과물의 화려함이 아니라, 문제를 어떻게 발견하고 어떤 시도를 거쳐 해결했는지를 보여주는 것이다.

인프런 멘토링에서 비전공자로 5개월 만에 500:1 경쟁률을 돌파한 사례가 공유된 바 있다. 이 사례의 핵심도 결국 "문제 해결 과정을 잘 기록한 포트폴리오"였다. 실제 비전공자 출신 프론트엔드 개발자의 포트폴리오가 궁금하다면, GitHub에서 "bootcamp portfolio frontend"나 "비전공 프론트엔드 포트폴리오"로 검색하면 여러 사례를 볼 수 있다. 특히 README에 트러블 슈팅 섹션이 있는 저장소를 찾아서 구조를 참고하면 도움이 된다.

부트캠프 기간 동안 포트폴리오를 준비하려면, 1개월차부터 시작해야 한다. 1개월차에 만든 투두앱이 초라해 보여도, 그 과정에서 겪은 에러와 해결 과정을 GitHub에 기록해두면 나중에 좋은 포트폴리오 재료가 된다.

# 포트폴리오 README 예시 구조

## 프로젝트 소개
- 무엇을 만들었는가
- 왜 만들었는가 (실제 문제에서 출발)

## 기술 스택
- 사용한 기술과 "왜 이 기술을 선택했는지"

## 주요 기능
- 기능별 구현 방식 설명

## 트러블 슈팅
### 1. API 호출 시 CORS 에러
- 상황: fetch로 외부 API를 호출했을 때 CORS 에러 발생
- 원인: 브라우저의 동일 출처 정책으로 인해 다른 도메인 요청 차단
- 시도한 방법: 프록시 서버 설정, CORS 미들웨어 추가
- 최종 해결: Vite 개발 서버의 proxy 설정 활용
- 배운 점: 브라우저 보안 정책의 작동 원리

### 2. 상태 업데이트 후 화면이 갱신되지 않는 문제
- 상황: 배열 상태를 push로 업데이트했는데 리렌더링이 안 됨
- 원인: React는 참조값이 같으면 상태 변경으로 인식하지 않음
- 시도한 방법: 불변성을 유지하는 다양한 패턴 비교
- 최종 해결: 스프레드 연산자로 새 배열 생성
- 배운 점: React의 불변성 원칙과 참조 비교

## 성장 기록
- 프로젝트 시작 시점과 완료 시점의 역량 변화

이런 구조의 README가 3~4개 프로젝트에 걸쳐 쌓이면, 면접관은 이 지원자가 "문제를 만나면 도망가지 않고 파고드는 사람"이라는 인상을 받는다.

포트폴리오 프로젝트 선택 기준

투두앱이나 날씨앱처럼 모든 부트캠프 수료생이 만드는 프로젝트는 차별화가 안 된다. 대신 자기 이전 경력이나 관심사와 연결된 프로젝트를 만든다. 간호사 출신이라면 환자 투약 스케줄 관리 앱을, 교사 출신이라면 학습 진도 추적 대시보드를, 요리사 출신이라면 레시피 원가 계산기를 만드는 식이다. 이런 프로젝트는 도메인 지식이 녹아 있어서 "이 사람만이 만들 수 있는 것"이 된다.

번아웃을 이기는 법, 6개월을 완주하는 기술

부트캠프 수료율을 공개하는 기관은 많지 않다. 하지만 커뮤니티에서 들리는 이야기를 종합하면, 중도 포기율이 결코 낮지 않다. 3개월차, JavaScript 기초를 지나 React에 진입하면서 난이도가 확 올라가는 시점에 그만두는 사례가 많다.

번아웃 방지는 "좀 쉬어라"로 해결되지 않는다. 장치가 필요하다. 이때 나타나는 전형적인 증상이 있다. 코드를 보면 눈이 글자를 따라가지만 머리에 아무것도 들어오지 않는다. 수업 시간에 멍하니 앉아 있다가 회고 시간에 "오늘 뭘 배웠지?" 하게 된다. 이런 증상이 3일 이상 이어지면 번아웃 초기 신호다.

학습 시간에 상한선을 둔다. 밤 10시 이후에는 코딩을 하지 않겠다는 원칙을 세운다. 밤늦게까지 코딩하면 다음 날 교육 시간에 집중력이 떨어지고, 그러면 이해도가 낮아지고, 그러면 방과 후에 더 많은 시간을 써야 하고, 그러면 다시 늦게까지 코딩하는 악순환에 빠진다. 에러가 30분 넘게 안 풀리면 현재 상태를 그대로 커밋해놓고, 자리에서 일어나는 규칙을 만든다. "WIP: 에러 미해결 - useState 리렌더링 안 됨"이라고 커밋 메시지를 남기고, 산책을 다녀온 뒤에 다시 보면 의외로 원인이 보이는 경우가 많다.

일주일에 하루는 온전히 쉰다. 코딩도, 기술 영상도, 기술 블로그도 보지 않는다. 뇌가 배운 정보를 정리하려면 입력이 멈추는 시간이 필요하다. 수면 중에 기억이 장기 저장소로 옮겨가는 것처럼, 휴식 중에 학습 내용이 무의식적으로 정리된다.

비교를 멈추는 방법이 있다. 옆자리 수강생이 나보다 빨리 이해하는 것처럼 보여도, 그 사람의 속사정은 모른다. 혼자서 3개월 독학한 뒤에 부트캠프에 온 사람일 수도 있고, 컴퓨터공학 비관련 학과지만 프로그래밍 수업을 들은 적이 있는 사람일 수도 있다. 비교를 멈추려면 "비교 대상을 바꾸는" 장치가 필요하다. 매일 자기 전에 "오늘 새로 할 수 있게 된 것 1가지"를 적는다.

[성장 기록 예시]
- 2월 3일: map과 filter를 체이닝해서 쓸 수 있게 됐다
- 2월 4일: 컴포넌트에 props를 전달하는 법을 이해했다
- 2월 5일: TypeError 에러 메시지를 보고 원인을 혼자 찾았다
- 2월 6일: 스프레드 연산자로 불변성을 유지하는 코드를 직접 짰다

이 기록이 쌓이면 3개월 뒤에 돌아보면서 자기가 얼마나 성장했는지 확인할 수 있다. 부트캠프의 가장 큰 적은 "나는 아무것도 못 한다"는 착각이다. 기록은 이 착각을 깨뜨린다. 주 1회 동기 수강생과 식사하면서 코딩 이야기는 하지 않는 시간을 만드는 것도 좋다. 같은 상황에 있는 사람과 코딩 외의 대화를 나누면, 서로가 "기계가 아니라 사람"이라는 걸 다시 느끼게 된다.

마무리: 6개월 뒤의 당신에게

IT 강사로 오랜 시간 수강생들을 만나면서 깨달은 것이 있다. 완주한 사람과 포기한 사람의 차이는 재능이 아니었다. 학습법이었다. 같은 교육을 받아도 회고 시간을 어떻게 쓰는지, 방과 후에 무엇을 하는지, 에러를 만났을 때 도망가는지 파고드는지에 따라 6개월 뒤의 결과가 완전히 갈렸다.

비전공자라는 꼬리표가 떨어지는 건 첫 취업이 아니라, 첫 번째 프로덕션 버그를 혼자 힘으로 잡았을 때다. 그리고 그 순간은 부트캠프에서 에러 메시지를 끝까지 읽고, 콘솔 로그를 하나하나 찍어보면서 문제를 추적했던 경험에서 온다.

AI 도구가 코드를 대신 써주는 시대에 개발자를 하겠다는 것은 무모한 선택이 아니다. 앤드류 응 교수의 말처럼, 코딩은 AI 시대 생산성을 정의하는 핵심 기술이다. AI가 코드를 만들어줘도, 그 코드가 맞는지 판단하고, 수정하고, 서비스에 맞게 조합하는 일은 사람의 몫이다. 그 "사람"이 되려면, 기초를 직접 손으로 쌓아야 한다.

6개월은 짧다. 하지만 제대로 집중하면 충분하다. 빈 종이 테스트를 하고, 코드를 보지 않고 다시 짜보고, 에러 메시지를 끝까지 읽고, 매일 작은 성취를 기록하는 사람이 결국 살아남는다.

오늘부터 회고 시간 첫 30분을 빈 종이 테스트에 쓰는 것부터 시작해보면 어떨까.

참고 자료

Karpicke, J.D. & Roediger, H.L. (2008), "The Critical Importance of Retrieval Practice to Learning", Science, 319(5865), 966-968
Ali Abdaal, "How To Study: Active Recall", https://aliabdaal.com/studying/how-to-study-active-recall-the-high-utility-technique-you-should-be-using/
Birmingham City University, "Spaced repetition and the 2357 method", https://www.bcu.ac.uk/exams-and-revision/best-ways-to-revise/spaced-repetition
freeCodeCamp, "How to Understand Complex Coding Concepts Using the Feynman Technique", https://www.freecodecamp.org/news/how-to-understand-complex-coding-concepts-better-using-the-feynman-technique/
Course Report, "Coding Bootcamps in 2026: Your Complete Guide", https://www.coursereport.com/coding-bootcamp-ultimate-guide
Built In, "8 Ways to Avoid Burnout While in Coding Bootcamp", https://builtin.com/career-development/bootcamp-self-care
Java Code Geeks, "AI-Assisted Coding in 2026", https://www.javacodegeeks.com/2025/12/ai-assisted-coding-in-2026-how-github-copilot-cursor-and-amazon-q-are-reshaping-developer-workflows.html
Final Round AI, "Andrew Ng's 3 AI Tips to Land Jobs in 2026", https://www.finalroundai.com/blog/andrew-ng-ai-tips-2026
CIO, "생성형 AI 확산 속 개발자 역량 재정의", https://www.cio.com/article/4136337/
ZDNet Korea, "코딩은 AI가, 전략은 사람이", https://zdnet.co.kr/view/?no=20250609103900
OpenMaru, "AI 시대 개발자 생존 전략", https://www.openmaru.io/ai-era-developer-survival-strategy-andrew-ng
코드트리, "2025년 개발자 취업 현실과 연봉, 전망, 준비", https://www.codetree.ai/blog/2025%EB%85%84-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%B7%A8%EC%97%85-%ED%98%84%EC%8B%A4%EA%B3%BC-%EC%97%B0%EB%B4%89-%EC%A0%84%EB%A7%9D-%EC%A4%80%EB%B9%84/
코드스테이츠, "프론트엔드 개발자 취업", https://www.codestates.com/blog/content/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%B7%A8%EC%97%85
snappify, "Rubber Duck Debugging Method", https://snappify.com/blog/rubber-duck-debugging

비전공자 프론트엔드 부트캠프 생존기: 하루 8시간, 6개월을 버티는 학습법

6시간 교육 시간, "듣기"가 아니라 "따라 치기"다

교육 시간 실전 루틴

2시간 회고, 하루 학습의 승패를 가르는 시간

회고 2시간 분배법

8시간 후, 방과 후에 무엇을 할 것인가

방과 후 3시간 루틴

주말 활용법

AI 시대, 비전공자의 학습 전략이 바뀌어야 한다

AI 도구의 올바른 활용 타이밍

AI 시대에 비전공자가 갖춰야 할 역량

6개월 부트캠프, 결국 포트폴리오가 말한다

포트폴리오 프로젝트 선택 기준

번아웃을 이기는 법, 6개월을 완주하는 기술

마무리: 6개월 뒤의 당신에게

참고 자료

부트캠프

댓글

김성박의 다른 글

MCP로 완성하기 - Claude가 회사 지식을 쓰게 만들기

검색, 평가, 그리고 신뢰할 수 있는 시스템

데이터가 전부입니다 - 문서를 지식으로 바꾸는 파이프라인

왜 당신의 RAG는 실패하는가 - 온톨로지, 지식 그래프, 그리고 제대로 된 아키텍처의 조건

CLAUDE.md, 쓰는 게 맞습니까 - 논문이 뒤집은 상식과 실전 가이드