PH pullh
입문 블로그 / 튜토리얼을 끝내도 코드가 안 써질 때
첫걸음 5분 Beginner

튜토리얼을 끝내도 코드가 안 써질 때

따라 칠 때는 이해한 것 같았는데, 혼자 하려면 아무것도 안 나오는 순간이 있다. 그 답답함을 넘는 연습법을 정리했다.

튜토리얼 피로 커버 이미지

튜토리얼은 길을 열어 주지만, 동시에 배우는 사람을 수동적인 상태에 묶어 두기도 합니다. 다음 줄을 계속 말해 주기 때문에, 내가 스스로 문제를 고르는 경험이 뒤로 밀립니다.

그래서 어느 시점부터는 "잘 따라 하는 사람"에서 "혼자 조금이라도 써 보는 사람"으로 연습 방식을 바꿔야 합니다. 문제는 그 전환이 불편하다는 것이고, 이 글은 그 불편한 구간을 건너는 구체적인 방법을 다룹니다.

막히는 이유가 이해 부족만은 아닙니다

많은 경우, 개념을 몰라서가 아니라 문제를 스스로 쪼개는 연습이 없어서 막힙니다. 튜토리얼은 이미 잘게 나뉜 단계를 제공하지만, 현실에서는 그 단계를 내가 정해야 합니다. "할 일 목록을 만들자"라는 한 문장을 어떻게 다섯 개의 작업으로 나눌지가 실제 난이도의 대부분입니다.

그래서 튜토리얼 이후의 첫 연습은 완전히 새로운 프로젝트가 아니라, 이미 본 예제를 내 식으로 바꾸는 것이 좋습니다. 도메인을 아는 상태에서 분해 연습만 따로 하는 셈이라 실패해도 원인이 분명합니다.

편집되어 사라진 것들

튜토리얼이 어느 시점부터 도움이 되지 않는 데에는 구조적인 이유가 있습니다. 만든 사람이 잘못해서가 아니라, 좋은 튜토리얼일수록 그렇게 됩니다.

첫째, 튜토리얼은 이미 답이 정해진 길입니다. 저자는 완성된 결과에서 거꾸로 걸어 나와 순서를 만듭니다. 그래서 화면에 보이는 모든 선택이 "당연히 그렇게 하는 것"처럼 보입니다. 실제로 만들 때는 그 자리에서 서너 가지 방법이 동시에 떠오르고, 어느 것도 명백히 옳지 않습니다.

둘째, 실패 경로가 지워져 있습니다. 저자가 중간에 두 시간 헤맨 부분, 라이브러리를 바꾼 이력, 처음 설계를 갈아엎은 과정은 편집 단계에서 잘려 나갑니다. 남는 것은 매끈한 한 줄기 길이고, 따라 하는 사람은 자기만 자꾸 막힌다고 느낍니다.

셋째, 그런데 막히는 지점 자체가 학습의 내용입니다. 에러 메시지를 읽고, 무엇이 틀렸는지 가설을 세우고, 하나씩 확인해 좁히는 과정이 실제로 늘려야 할 능력인데, 튜토리얼에서는 그 부분이 정확히 제거되어 있습니다. 완주해도 그 근육만 안 자라는 이유입니다.

넷째, 설계 선택이 보이지 않습니다. 데이터를 어떤 모양으로 저장할지, 어디까지를 한 함수로 묶을지 같은 결정은 이미 내려진 채로 등장합니다. 결정의 이유를 못 봤으니 요구사항이 조금만 달라져도 응용이 안 됩니다.

이 네 가지를 합치면 결론은 단순합니다. 튜토리얼은 "무엇이 가능한지"를 보여주는 데는 좋고, "어떻게 결정하는지"를 가르치는 데는 원래 약합니다. 그 부분은 따로 연습해야 합니다.

요구사항을 하나만 바꿔 다시 만들기

가장 저렴한 연습은 방금 끝낸 튜토리얼의 예제에 요구사항을 하나씩 얹는 것입니다. 아래는 흔한 할 일 목록 앱을 끝냈다고 가정한 과제 목록입니다. 위에서부터 순서대로 하나씩만 합니다.

CHANGE ONE REQUIREMENT

[1] 완료된 항목만 보이는 필터를 추가한다.
    - 전체 / 진행중 / 완료 세 가지 보기
    - 필터를 바꿔도 원본 목록은 그대로 유지될 것

[2] 새로고침해도 목록이 남게 한다.
    - 저장 위치는 직접 고를 것 (파일 / localStorage / DB)
    - 저장 시점이 언제인지 한 줄로 설명할 수 있을 것

[3] 항목에 마감일을 추가한다.
    - 지난 항목은 다르게 표시
    - 마감일이 없는 기존 항목이 깨지지 않을 것

[4] 항목 수정 기능을 넣는다.
    - 빈 문자열로 저장하면 어떻게 되는지 먼저 정할 것

[5] 목록이 500개일 때도 느려지지 않는지 확인한다.
    - 임의 데이터 500개를 넣어 직접 눌러 볼 것

각 항목은 30분에서 두 시간 사이로 끝나야 합니다. 그보다 커지면 더 쪼갭니다.

이 방식이 효과가 있는 이유는, 도메인은 이미 아는 상태에서 "결정"만 새로 하기 때문입니다. 2번 하나만 해도 데이터를 어떤 모양으로 저장할지, 언제 저장할지, 저장된 게 없을 때 무엇을 보여줄지를 스스로 정해야 합니다. 튜토리얼이 지워 버린 부분이 정확히 그 자리에서 돌아옵니다.

중요한 것은 한 번에 하나만 하는 것입니다. 다섯 개를 동시에 시작하면 어디서 깨졌는지 알 수 없고, 결국 예제를 다시 다운로드하게 됩니다.

과제를 다 끝냈다면 마지막으로 한 가지를 더 합니다. 튜토리얼 창을 닫고 빈 폴더에서 같은 앱을 처음부터 다시 만들어 보는 것입니다. 이때 막히는 지점의 목록이 곧 아직 안 익은 것들의 목록입니다. 검색을 몇 번 하든 상관없지만, 원래 예제 코드를 열어 보는 것만 참으면 됩니다.

시작 전에 적어 두는 열 줄

튜토리얼 없이 혼자 만들 때는 첫 30분에 코드를 쓰지 말고 메모를 씁니다. 형식은 아래 정도면 충분합니다.

DESIGN NOTE

# 가계부 v0

입력
  - 날짜, 금액, 분류(식비/교통/기타), 메모 한 줄

저장할 데이터 모양
  - 항목: {id, date, amount, category, memo}
  - 전체: 항목 리스트 하나, JSON 파일로 저장

화면
  - 목록 화면: 이번 달 항목 + 합계
  - 입력 화면: 위 네 개 필드 + 저장 버튼

안 할 것 (v0에서는 절대 안 함)
  - 로그인, 여러 사용자
  - 통계 그래프
  - 예산 알림
  - 모바일 앱

끝났다고 말할 조건
  - 항목을 넣고 앱을 껐다 켜도 남아 있으면 끝

"안 할 것"과 "끝났다고 말할 조건"이 이 메모에서 가장 중요한 두 칸입니다.

이 메모의 핵심은 범위를 좁히는 데 있습니다. 만들다 보면 아이디어가 계속 떠오르고, 그걸 다 넣으면 끝나지 않습니다. 처음에 "안 할 것"을 적어 두면 나중에 떠오른 기능을 그 목록 아래에 추가하는 것만으로 마음이 정리됩니다. 완성 가능한 크기로 첫 프로젝트를 자르는 방법은 끝낼 수 있는 첫 프로젝트 고르기에서 더 다룹니다.

막혔을 때의 순서

메모를 다 썼으면 그중 가장 작은 조각 하나부터 코드로 옮깁니다. 화면부터 만들지 말고, 데이터를 만들고 저장하고 다시 읽어 오는 것까지를 먼저 확인하는 편이 대체로 빠릅니다. 눈에 보이는 부분을 먼저 만들면 예뻐 보이지만, 정작 데이터 모양이 틀렸다는 사실은 한참 뒤에 드러납니다.

혼자 만들면 반드시 막힙니다. 막히는 것 자체는 문제가 아니고, 막혔을 때 무작정 검색창으로 가는 것이 문제입니다. 순서를 정해 두면 같은 시간에 훨씬 멀리 갑니다.

  1. 에러 메시지를 끝까지 읽습니다. 맨 아랫줄의 예외 이름과 설명, 그리고 내 파일 이름이 나오는 가장 마지막 줄을 봅니다. 대부분의 답은 여기 있습니다.
  2. 공식 문서에서 그 함수 하나를 찾습니다. 블로그 글보다 먼저 봅니다. 인자 이름과 반환값, 예외 조건이 정확한 곳은 공식 문서뿐입니다.
  3. 최소 재현 코드를 만듭니다. 문제가 나는 부분만 열 줄 이하로 떼어 새 파일에 옮깁니다. 이 과정에서 절반은 스스로 원인을 찾습니다.
  4. 그래도 안 되면 그 최소 코드를 들고 질문합니다. "안 돼요" 대신 기대한 결과, 실제 결과, 재현 코드를 함께 냅니다.

이 순서는 몇 번 반복하면 습관이 되고, 그때부터 튜토리얼 없이 만드는 속도가 눈에 띄게 붙습니다. 첫 주에 무엇을 어떤 순서로 해 볼지는 Hello World 다음 7일에 정리되어 있습니다.

아직 끊을 때가 아닌 경우

"튜토리얼을 끊어라"를 너무 빨리 받아들이면 반대 방향으로 손해를 봅니다.

언어 문법 자체가 아직 낯설다면 계속 따라 하는 편이 빠릅니다. 반복문과 조건문을 쓸 때마다 문법을 검색하고 있다면, 지금 부족한 것은 설계 경험이 아니라 손에 익은 패턴입니다. 이 단계에서 혼자 만들기로 넘어가면 문법 오류를 고치느라 시간을 다 쓰고 설계는 시작도 못 합니다.

완전히 새로운 도메인에 처음 들어갈 때도 마찬가지입니다. 그래픽, 임베디드, 오디오 처리처럼 용어와 관례가 통째로 다른 영역에서는 "무엇이 가능한지"조차 모르는 상태입니다. 이때는 잘 만든 튜토리얼 두세 개를 그대로 따라 해 보는 것이 지도를 얻는 가장 빠른 방법입니다. 경력이 오래된 사람도 새 분야에서는 똑같이 합니다.

그리고 "튜토리얼 지옥"이라는 말에 겁먹어 기초 반복을 건너뛰는 것도 역효과입니다. 같은 것을 여러 번 써 보는 일은 낭비가 아니라 자동화입니다. 문제는 반복 자체가 아니라, 매번 새 강의를 켜면서 한 번도 스스로 결정하지 않는 패턴입니다. 같은 예제를 세 번 다시 쓰는 것은 건강한 반복이고, 다른 강의 세 개를 한 번씩 따라 하는 것은 그렇지 않습니다.

구분하는 기준은 하나면 됩니다. 지금 화면을 끄고 빈 파일에서 시작했을 때, 첫 줄을 쓸 수 있는지. 쓸 수 있으면 끊을 때가 된 것이고, 아예 손이 안 움직이면 조금 더 따라 해도 됩니다.

알아두면 좋은 점

따라 하는 중에도 능동적으로 만드는 방법이 있습니다. 저자가 다음에 무엇을 할지 말하기 전에 잠깐 멈추고 스스로 예측해 보는 것입니다. 맞으면 그 부분은 이미 아는 것이고, 틀리면 그 지점이 정확히 배울 곳입니다. 재생 속도를 올리는 것보다 이쪽이 남습니다.

자주 하는 실수

막혔을 때 코드를 통째로 지우고 처음부터 다시 씁니다. 잠깐 시원하지만 같은 자리에서 다시 막히고, 원인은 여전히 모릅니다. 지우기 전에 최소 재현 코드부터 만듭니다. 그리고 되던 시점으로 돌아갈 수 있게 커밋을 자주 남깁니다.

다음 일주일의 연습 목록

  • 새 강의를 켜지 않습니다. 가장 최근에 끝낸 예제를 엽니다.
  • 요구사항 하나를 골라 종이에 적습니다. 두 개는 안 됩니다.
  • 위의 설계 메모 형식으로 열 줄을 먼저 씁니다. "안 할 것"을 반드시 채웁니다.
  • 막히면 에러 메시지 → 공식 문서 → 최소 재현 순서를 지킵니다.
  • 끝나면 튜토리얼을 닫고 빈 파일에서 같은 것을 다시 만들어 봅니다.

다음에 무엇을 볼지 고르기 어렵다면 심층 가이드 목록에서 지금 쓰고 있는 언어의 주제 하나를 골라 예제만 확인하는 것도 방법입니다.

혼자 30분 동안 버벅이며 다시 쓰는 시간이, 깔끔하게 정리된 강의를 세 시간 더 따라 보는 시간보다 많이 남는 경우가 많습니다.

첫걸음

Next Read

좋은 프로그래밍 질문은 어떻게 만들까

막혔을 때 질문을 잘하면 배우는 속도가 훨씬 빨라진다. 답을 빨리 받기 위한 형식이 아니라, 스스로 정리하기 위한 질문법을 다룬다.