목차9개 항목
출처와 참고
「개발 배우기가 정말 어려운 이유」(Thinkful 블로그 「Why Learning to Code is So Damn Hard」 번역, 2020.01), 「비전공 개발자가 전공자보다 정말 불리할까?」(2019.09), 「마흔살 기획자 프로그래머 되다」, 「당신의 클론 코딩은 왜 실패하는가?」(2019.12), 「제로 스펙에 가까웠던 듣보잡 개발자의 유명 IT기업 도전기」를 바탕으로 재구성한 노트다.
왜 개발 입문은 유독 힘든가
개발을 배우는 사람의 자신감과 실제 실력은 같이 움직이지 않는다. 자료가 넘치는 초반에는 자신감이 실력보다 앞서고, 자료가 사라지는 중반에 자신감이 바닥을 친다. 이 하락은 재능 부족이 아니라 학습 구조에서 오는 현상이다. 단계를 알면 지금의 막막함이 정상이라는 걸 알 수 있다.
자신감
▲ ① ④ ↗
│ ╱ ╲ ↗
│ ╱ ╲ ③ ↗
│╱ ② ╲___╱
└──────────────────▶ 실력
① 강의 단계 ② 혼란의 절벽 ③ 절망의 사막 ④ 상승기네 단계
| 단계 | 특징 | 넘는 법 |
|---|---|---|
| ① 강의 단계 (Hand-Holding Honeymoon) | 친절한 강의와 즉각적인 성취로 자신감이 빠르게 오른다 | 여러 자료를 가볍게 맛본 뒤 하나를 골라 끝까지 완주한다 |
| ② 혼란의 절벽 (Cliff of Confusion) | 힌트와 예제가 사라지고 빈 에디터에서 직접 짜야 한다. 디버깅이 끝없이 이어진다 | 튜토리얼을 벗어나 작은 프로젝트를 직접 만든다. 디버깅을 연습 대상으로 삼는다. 페어 작업, 남의 코드 읽기 |
| ③ 절망의 사막 (Desert of Despair) | 배울 범위가 갑자기 넓어지는데 좋은 자료는 줄어든다. 무엇을 모르는지도 모른다. 「몇 주 만에 개발자」 같은 약속에 흔들린다 | 분명한 목표를 세우고, 목표와 상관없는 유행과 속성 과정을 걸러 한 길에 집중한다 |
| ④ 상승기 (Upswing of Awesome) | 앱을 만들 수 있게 되지만 실무 코드·모범 사례와의 격차 때문에 불안하다 | 모범 사례를 따라 하며 빈틈을 찾고, 피하기 쉬운 테스트·배포·데이터 모델링을 공부한다. 실무자에게 꾸준히 피드백을 받는다 |
혼자 익히는 방법
완독 먼저, 이해는 두 번째에
처음 읽을 때 이해 안 되는 곳은 넘기고 끝까지 읽어 전체 지도를 얻는다. 다시 읽을 때 이해가 넓어진다. 영상으로 감을 잡고 책으로 체계를 보는 식으로 섞으면 초반의 막막함이 줄어든다.
따라 치지 말고 백지에서 다시 만든다
| 실패하는 클론 코딩 | 남는 클론 코딩 |
|---|---|
| 강의 코드를 생각 없이 따라 치거나 복사한다 | 의문이 생기면 검색하고, 안 풀리면 커뮤니티에 묻는다 |
| 한 번 듣고 끝, 정리 없음 | 강의를 반복해 듣고, 배운 것을 문서로 정리한다 |
| 결과물이 강의와 똑같고 다시 보지 않는다 | 강의 없이 백지에서 다시 만들고, 스택·디자인을 바꾸고, 사이드 프로젝트로 키운다 |
단순한 과제부터 점점 복잡한 과제로 가고, 같은 과제를 처음부터 다시 구현하며 코드를 다듬는다. 이 반복이 실력을 가장 크게 올린다.
환경을 설계한다
- 퇴로를 막는다. 주변에 공언하거나 약속을 걸어 두면 의지가 약해져도 돌아오기 쉽다.
- 마감을 둔 집중 과제. 짧은 기한 안에 결과물을 내면 평소 어렵던 기능을 단기간에 익히는 도약이 생긴다.
- 나보다 잘하는 코드와 사람 가까이. 숙련자의 코드를 읽고 질문하면 혼자서는 떠오르지 않던 궁금증이 생긴다.
비전공자가 보완할 것
전공자와의 차이는 학위가 아니라 컴퓨터가 동작하는 원리에 대한 구조적 이해에서 난다. 기초가 없으면 원리 대신 사용법을 외우게 되고, 새 기술이 나올 때마다 처음부터 다시 외운다.
| 보완할 것 | 이유 |
|---|---|
| 자료구조·알고리즘 | 코드의 시간 복잡도를 스스로 계산하고 더 나은 방법을 고민하는 습관의 바탕 |
| 네트워크 | 웹 개발의 거의 모든 문제가 결국 네트워크 위에서 일어난다 |
| 설계 패턴·아키텍처(MVC·MVVM, 상태 관리) | 단기 과정에서 깊이 다루지 않는 경우가 많다 |
| 새 기술 밑의 기반 기술 | 새 기술 대부분은 기존 기술의 발전형이다. 밑바탕을 알면 빨리 익힌다 |
이전 전공·경력은 약점이 아니라 무기가 될 수 있다. 다른 분야의 도메인 지식과 개발을 결합하면 틈새 경쟁력이 생긴다.
학력 대신 실력을 증명하는 법
| 방법 | 핵심 |
|---|---|
| 만들어서 보여 준다 | 「관심 있다」는 말 대신 그 기술로 토이 프로젝트를 만들고 가능하면 실제로 배포한다 |
| 공개하고 리뷰받는다 | 코드를 올리고 실력 있는 개발자에게 리뷰를 청한다. 무엇을 왜 고쳤는지 설명을 붙여 구체적으로 요청한다 |
| 꾸준한 기록 | 블로그로 배운 것을 정리하고, 깃허브에 꾸준히 커밋하고, 오픈소스에 기여한다 |
| 비공식 경험도 정리한다 | 정식 경력이 짧아도 실제로 개발에 참여한 경험은 면접관이 궁금해한다 |
| 설명할 수 있는 것만 쓴다 | 이력서에는 직접 한 일과 근거를 들어 설명할 수 있는 기술만 적는다. 과장은 면접에서 신뢰를 잃는다 |
| 지원 회사에 맞춘다 | 요구 기술을 파악하고, 서비스를 직접 써 보며 개발자 관점의 개선 의견을 준비한다 |
정리
- 입문 중반의 자신감 하락은 구조적 현상이다. 재능 탓이 아니다.
- 단계마다 처방이 다르다: 완주 → 직접 만들기 → 목표로 거르기 → 피드백 받기.
- 따라 친 코드는 남지 않는다. 백지에서 다시 만들어야 내 것이 된다.
- 비전공자는 CS 기초를 의식적으로 메우고, 학력 대신 공개된 결과물로 실력을 보여 준다.
관련 노트: 초보 웹 개발자의 공부 방향과 차별화, 개발자의 지속 가능한 학습 루프, 컴퓨팅 사고와 개발 실력 늘리는 법, 오픈소스 기여 시작하기, 개발자 기술 블로그