90분 코딩 랩: 혼란을 다음 단계로 바꾸는 작은 실험들

코드로 먹고 살든(혹은 재미로 코딩하든) 이 느낌, 분명 알 것이다.

에디터를 연다.

머릿속에 한 번에 다 담기기엔 너무 크거나, 흐릿하고, 절반만 정의된 문제와 마주한다.

몇 시간을 이리저리 건드려 본다. 문서를 읽는다. 뭔가 시도해 본다. 반쯤 된다. 딴짓을 한다. 정신 차려 보니 오후 5시, 뭘 배운 건지조차 모르겠다.

문제는 코드만이 아니다.

문제는 구조 없는 학습이다.

간단한 해결책이 있다. 코딩 시간을 작은 실험들로 쪼개는 것이다. 한 번에 하나의 명확한 질문에 답하기 위해 설계된, 90분짜리 "코딩 랩" 세션.

이 마인드셋은 애자일의 "스파이크(spike)"와 좋은 디버깅 습관에서 그대로 가져온 것이다. 코드베이스를 무작정 헤매며 번뜩임을 기다리는 것보다, 집중된 가설을 검증할 때 더 빠르게, 더 많이 배운다.

코딩 “스파이크”란 무엇인가 (그리고 왜 중요한가)

애자일 개발에서 스파이크(spike) 는, 본격 구현에 들어가기 전에 어떤 아이디어, 기술, 리스크를 짧게 탐색해 보는 시간 제한 실험이다.

팀은 스파이크를 이런 데 쓴다:

새로운 프레임워크나 라이브러리 탐색
모호한 요구사항 구체화
아키텍처 옵션 비교·검토
큰 에픽(epic)의 가장 어려운 부분을 먼저 실험해 리스크 줄이기

핵심은, 스파이크는 프로덕션급 코드를 만드는 작업이 아니라는 점이다. 스파이크의 목적은 학습이다.

스파이크는 완성도 대신 명확성을 택한다. 우리는 기능을 만드는 게 아니라, 정보를 사들이고 있는 것이다.

이 개념은 개인 작업이나 디버깅에도 똑같이 잘 들어맞는다. "전체 문제를 한 번에 해결"하려 하기보다, 작고 부담 없는 실험을 설계해 아주 좁은 질문 하나에 답한다.

막연한 혼란에서 구체적인 질문으로

코딩할 때의 혼란은 대개 이렇게 나타난다:

"이 시스템이 어떻게 맞물려 돌아가는지 잘 모르겠다."
"왜 이 버그가 생기는지 모르겠다."
"이 접근법이 스케일할지 확신이 없다."
"이 기능은 너무 커서, 어디서 시작해야 할지 모르겠다."

이건 질문이 아니라 감정이다. 감정에는 실험을 할 수 없다.

첫 단계는, 이 안개 같은 느낌을 구체적인 질문 하나로 바꾸는 것이다.

"이 새로운 API에 최소한의 요청을 보내서 성공 응답을 받을 수 있을까?"
"성능 문제는 DB 쿼리에 있는가, 네트워크 레이어에 있는가?"
"이 UI 라이브러리의 가상 스크롤(virtualization)로 1,000개 아이템을 부드럽게 렌더링할 수 있을까?"
"버그를 이 함수로 국한할 수 있을까, 아니면 호출하는 함수 쪽 문제일까?"

좋은 실험은 한 번의 90분 세션 안에서 현실적으로 진전시킬 수 있는, 구체적인 질문 하나에서 시작한다.

왜 90분인가? 몰입과 피드백의 스위트 스폿

그렇다면 왜 포모도로처럼 25분도 아니고, 반나절도 아닐까?

90분 코딩 랩은 이런 균형을 잘 맞춘다:

깊은 작업에 충분히 길다: 복잡한 시스템을 머릿속에 로드하고, 살펴보고, 의미 있는 스파이크를 만들 수 있다.
번아웃을 막기엔 충분히 짧다: 하드 스톱이 있어서, 초점을 잃은 채 4–5시간을 갈려 나가지 않게 해 준다.
자연스러운 타임박스: 모든 걸 할 수 없다는 전제가 생기므로, 우선순위를 정하고 단순화하게 된다. 지금 당장 중요한 게 무엇인지 고르게 된다.
내장된 피드백 사이클: 각 세션 끝에는 "이번에 뭘 배웠는지, 다음 실험은 무엇일지"를 되돌아보는 작은 회고가 따라온다.

하루 전체가 하나의 크고 흐릿한 "작업 시간"이 되는 대신, 구조화된 학습 사이클들의 집합이 된다.

90분 코딩 랩 템플릿

바로 써먹을 수 있는 구조를 소개한다.

1. 질문 정의하기 (5–10분)

노트 앱, 마크다운 파일, 이슈 트래커 어디든 좋으니 눈에 보이는 곳에 적어라.

질문(Question): 이번 세션에서 구체적으로 무엇을 배우거나 결정하려 하는가?
범위(Scope): 이번 세션에서 하지 않을 일은 무엇인가?

예시:

질문: "이 버그를 최소한의 테스트 케이스로 재현할 수 있을까?"
- 범위: 지금은 버그를 고치지 않고, 안정적으로 재현하는 데만 집중.
질문: "라이브러리 X가 우리 인증(auth) 흐름을 처리할 수 있을까?"
- 범위: 전체 앱에 통합하지 않고, 로그인 + 토큰 리프레시 POC만 만든다.

이 단계만으로도 불안이 많이 줄어든다. "이건 엉망진창이야"라는 막연함이 "나는 이 질문 하나에 답하고 있다"로 바뀌기 때문이다.

2. 가설 세우기 (5분)

효과적인 디버깅과 탐색은 좋은 가설에 달려 있다. 지금까지 가진 증거를 바탕으로 한, 명확하고 검증 가능한 추측이다.

가설은 이런 형태여야 한다:

만약 X를 하면 Y가 일어날 것이다. 왜냐하면 Z라고 예상하기 때문이다.

예시:

만약 의존성을 v3.2에서 v3.1로 내리면 에러가 사라질 것이다. 왜냐하면 스택 트레이스에 v3.2에서 새로 추가된 메서드가 언급되기 때문이다.
만약 페이지네이션을 페이지당 50개로 제한하면, 프레임 당 16ms 이하로 스크롤 성능이 유지될 것이다. 왜냐하면 UI 라이브러리 문서에서 그 정도를 안전한 한계라고 제안하고 있기 때문이다.

가설이 있으면, 세션 전체에 더 선명한 렌즈가 생긴다. 그냥 "이것저것 해 보는" 게 아니라, 특정 아이디어를 검증하고 있는 것이다.

3. 성공 기준 정하기 (5분)

성공 기준은 전체 프로젝트가 아니라, 실험 자체의 성공을 정의해야 한다.

성공(Success): 어떤 결과가 나오면 이 방향이 유망하다고 볼 수 있는가?
실패(Failure): 어떤 결과가 나오면 다른 접근법을 시도해야 한다는 신호인가?

예시:

성공: "50줄 미만의 유닛 테스트로 버그를 재현할 수 있다."
실패: "90분이 지나도 독립적인 재현 케이스를 못 만들었다면, 더 많은 런타임 데이터를 수집해야 한다."

이 기준이 있어야 스스로에게 솔직해질 수 있다. 좋아하는 아이디어를 합리화하는 게 아니라, 현실을 테스트하는 것이다.

4. 실험 실행하기 (60–70분)

이제 코드를 짜되, 가드레일을 두고 진행한다.

가이드라인:

범위 안에 머물기: 옆길로 새고 싶은 아이디어가 떠오르면, 따로 적어두고 지금은 쫓아가지 않는다.
미니멀 예제를 선호하기: 표면적이 작을수록 학습 속도가 빠르다. 가설을 검증하는 데 필요 없는 건 과감히 걷어낸다.
시도한 것들을 기록하기: 간단한 불릿 포인트면 충분하다.
- 시도: 캐시 설정 변경 → 변화 없음
- 시도: 기능 플래그 X 비활성화 → 버그 사라짐

이 기록은 빵가루 트레일을 만든다. 같은 막다른 길을 반복하지 않게 해 주고, 세션을 요약하거나 도움을 요청할 때 큰 도움이 된다.

5. 정리 및 다음 단계 결정 (10–15분)

타이머가 울리면 멈춘다. 실험을 닫고, 정리한다.

다음 내용을 적어 둔다:

무엇을 배웠는가? ("이건 안 된다"도 중요한 배움이다.)
가설이 지지되었는가, 반박되었는가?
새로 떠오른 질문은 무엇인가?
다음 실험은 무엇인가?

예시:

배운 점: 성능 문제는 DB 쿼리에 있지 않다(쿼리 시간 < 20ms). 대신 UI 리스트를 렌더링할 때 발생한다(보이는 아이템이 200개를 넘으면 프레임 드랍).

다음 실험: 가상 스크롤(virtualization) ON/OFF 상태에서 렌더링 시간을 비교 측정.

각 90분 랩은 **"내일도 대충 계속 해 보자"**로 끝나는 게 아니라, **"다음에 할 명확한 한 걸음"**으로 끝난다.

디버깅을 마이크로 실험들의 연속으로 보기

디버깅에서 이 접근법은 특히 빛난다.

나쁜 디버깅의 모습:

코드를 무작위로 바꿔 본다.
코드 블록을 덩어리째 주석 처리했다가, "대충 되는 것 같다" 싶으면 멈춘다.
서비스들을 재시작하면서, 잘 되기만을 바란다.

좋은 디버깅은 가설 중심이다.

증거 수집 (로그, 스택 트레이스, 재현 스텝 등)
가설 수립: "캐시가 오래되어, 폴백(fallback) 로직이 동작할 때 버그가 나타난다."
작은 실험 설계: "캐시 미스를 강제로 발생시키고, 폴백 경로를 로깅한 뒤 동작을 비교한다."
실행, 관찰, 가설 수정.

한 번의 거대한 "디버깅 세션" 대신, 더 좁은 질문에 답하는 세네 번의 90분 랩으로 나눠 보자.

랩 1: 최소한의, 안정적인 재현 케이스를 만들 수 있는가?
랩 2: 버그가 데이터 형태, 타이밍, 설정 중 무엇과 연관이 있는가?
랩 3: 컴포넌트 X를 바꿨을 때 증상이 사라지는가, 혹은 다른 곳으로 옮겨 가는가?

이렇게 하면 루트 원인으로 이어지는 증거의 사슬이 쌓인다.

측정 가능하고, 반복 가능한 진전 만들기

90분 코딩 랩 마인드셋의 진짜 힘은, 지저분한 일을 반복 가능한 프로세스로 바꾼다는 데 있다.

각 세션은 다음과 같다:

자급자족(Self-contained): 한 개의 질문, 한 개의 가설, 한 묶음의 관찰.
기록됨(Documented): 미래의 나(와 팀원들)는 무엇을 시도했고, 무엇이 먹혔고, 무엇이 실패했는지 한눈에 볼 수 있다.
비교 가능(Comparable): 일주일을 돌아봤을 때, 그냥 "그 버그를 며칠 동안 붙잡고 있었다"는 흐릿한 기억이 아니라, 실험과 학습의 타임라인을 확인할 수 있다.

이런 측정 가능성은 실무에서 큰 이점을 준다.

상태 공유가 쉬워진다: "스파이크 세 개를 돌렸고, 지금은 X, Y, Z를 알게 됐으며, 위험한 접근법 두 개를 버렸다."
온보딩이 빨라진다: 새 팀원은 처음부터 다시 헤매는 대신, 그간의 실험 기록을 따라가면 된다.
의사결정이 좋아진다: 감(直感)이 아니라, 구체적인 실험 결과를 바탕으로 트레이드오프를 비교할 수 있다.

내일부터 90분 랩 시작하는 방법

거창한 프로세스 개편이 필요 없다. 아주 작게 시작하자.

막혀 있는 골치 아픈 작업 하나를 고른다.
캘린더에 90분을 블록으로 잡고, 제목을 "코딩 랩: [짧은 질문]"처럼 적는다.
이 템플릿을 사용한다:
- Question (질문)
- Hypothesis (가설)
- Success criteria (성공 기준)
- Experiment notes (실험 노트)
- Debrief + next step (정리 + 다음 단계)
타임박스를 존중한다. 90분이 끝나면, 아이디어가 한창일 때라도 멈춘다. 떠오른 아이디어는 다음 랩의 씨앗으로 기록해 둔다.

몇 번만 해 봐도 이런 변화를 느낄 것이다.

모호한 일을 마주할 때의 두려움 감소
더 또렷하고 집중된 코딩 세션
기술적 의사결정에 대한 자신감 증가

결론: 드라마 대신 데이터

코딩할 때 느끼는 혼란은 개인 능력의 문제가 아니다. 지금 가진 머릿속 모델보다 문제의 크기나 모호함이 더 크다는 신호다.

더 많은 의지력이나 더 긴 노동 시간이 필요한 게 아니다.

필요한 건, 더 작고, 더 날카로운 실험들이다.

각 90분을 명확한 질문, 근거 있는 가설, 분명한 성공 기준을 가진 작은 랩으로 다루면, 불확실성을 구조화된 학습 과정으로 바꿀 수 있다. 리스크는 줄이고, 디버깅은 더 효과적으로, 진전은 꾸준히 내면서도 번아웃을 피할 수 있다.

다음에 막힌 느낌이 들면, "계속 붙잡고 있으면 되겠지"라고 말하지 말자.

"지금부터 90분짜리 실험 하나를 돌려 보자"라고 말하자.

그리고 실험을 설계하고, 시간 상자를 씌우고, 무엇을 배웠는지 확인하라.