2시간 제약: 실제 프로젝트에 살아남는 초소형 코딩 실험 설계법

소프트웨어 개발에서 말하는 “빠른 실험”은 보통 둘 중 하나로 끝납니다.

• 잊힌 브랜치 속에 조용히 사라지거나
• 어느새 의도치 않은 프로덕션 시스템으로 자라납니다.

둘 다 나쁜 결과입니다.

• 잊힌 실험은 시간을 태웠지만 실제 의사결정에는 아무 영향도 주지 못합니다.
• 우연히 프로덕션이 된 실험은 모두가 건드리기 무서운, 취약한 기반이 됩니다.

더 나은 패턴이 있습니다. **명확한 목적을 가진, 엄격히 시간 제한된 ‘2시간짜리 코딩 실험’**입니다. 이 실험은 오직 한 가지 유용한 질문에 답하고, 실제 프로젝트 작업으로 이어지기 위해서만 존재합니다.

이걸 **초미니 애자일 스파이크(micro Agile spike)**라고 생각하면 됩니다. 짧고 의도적인 탐색으로, 불확실성을 줄이고 중요한 결정을 디리스킹(de‑risk)하기 위한 것—하지만 또 하나의 미완성 사이드 프로젝트로 변질되지는 않게 설계된 것 말이죠.

이 글에서는 이런 초소형 실험을 어떻게 설계해야 빠르고, 집중되어 있으며, 무엇보다 인사이트가 실제 코드베이스와 계획에 살아남게 할 수 있는지를 단계별로 살펴봅니다.

왜 ‘2시간’인가? 강한 제약이 주는 힘

3시간이나 90분을 택해도 되지만, 2시간은 여러모로 균형이 좋습니다.

• 레포를 클론하고, 라이브러리를 한 번 써 보고, 최소한의 테스트를 붙이고, 메모를 남기기에 충분히 길고
• 오버엔지니어링을 막고, 잔혹할 정도로 집중하도록 만들 만큼 충분히 짧으며
• 바쁜 하루에도 하나의 독립된 블록으로 끼워 넣기 쉽습니다.

이 2시간이라는 엄격한 제한은 건강한 압박을 만듭니다.

• 깔끔한 프로토타입을 만들 생각 자체를 안 하게 됩니다.
• 문제 전체를 한 번에 다 해결하려는, 이른바 “바다를 끓이는” 시도를 할 수 없습니다.
• 이렇게 질문하게 됩니다. “유의미한 걸 배우기 위해 내가 할 수 있는 가장 작은 일은 무엇인가?”

제약이 없으면 “실험”은 슬그머니 미니 프로젝트로 변합니다. 반대로 제약이 있으면, 실험은 본래 목적대로 값싸고, 폐기 가능한 학습 도구로 남습니다.

실험을 애자일 스파이크처럼 다루기

애자일에서 **스파이크(spike)**란, 불확실성을 줄이기 위한 시간 제한 탐색 작업을 말합니다. 보통 큰 스토리에 들어가기 전에 하는 작은 기술 조사죠.

2시간 실험은 사실상 **마이크로 스파이크(micro-spike)**입니다. 그래서 이런 특징을 가져야 합니다.

• 목적이 명확해야 합니다. 특정 리스크나 모르는 지점을 탐색합니다.
• 의도적으로 작아야 합니다. 결정을 내리는 데 충분한 정도만 작업합니다.
• 결론으로 끝나야 합니다. 예를 들어 “이 접근은 ○○ 조건이라면 쓸 만하다” 혹은 “성능 요구사항을 못 맞춘다” 같은 짧은 문장으로요.

여기서 중요한 건 관점의 전환입니다.

우리는 기능을 만드는 게 아니다. 정보를 사는 것이다.

실험을 “정보 구매”로 바라보면, 평가 기준이 코드의 완성도나 우아함이 아니라 배운 것의 가치가 됩니다.

한 가지 구체적인 질문 또는 리스크에서 시작하기

2시간 블록을 가장 쉽게 날리는 방법은, 질문 없이 코딩을 시작하는 것입니다. 그러면 여기저기 헤매다가, 결과라고 해봐야 “감상” 수준에 머물고, 액션으로 이어질 만한 인사이트는 남지 않습니다.

코드를 한 줄이라도 쓰기 전, 다음 중 하나를 반드시 정리해야 합니다.

• 딱 한 개의 질문, 또는
• 딱 한 개의 리스크

아래처럼 최대한 구체적으로 적습니다.

• “라이브러리 X를 사용해서 단일 노드에서 초당 1만 메시지를 처리할 수 있는가?”
• “Provider Y의 OAuth 플로우를 현재 인증 모델에 붙이는 난이도가 어느 정도인가?”
• “GraphQL 게이트웨이가 큰 구조 변경 없이 스트리밍 업데이트를 처리할 수 있는가?”

그리고 이에 대한 성공 기준을 정의합니다.

• “내 로컬 환경에서 초당 1만 메시지를 달성하는 벤치마크를 돌릴 수 있으면 성공이다.”
• “가짜 사용자로 로컬 환경에서 end‑to‑end OAuth 로그인을 완주할 수 있으면 성공이다.”

이렇게 하면 분명한 결승선이 생깁니다. 그 선을 넘는 순간, 멈춰도 된다는 신호가 됩니다. 아니, 멈추는 게 장려됩니다.

이 질문과 성공 기준은 짤막한 실험 티켓이나 공유 문서에 적어두면 좋습니다. 이 작은 구조화 작업 하나가, “뭐 좀 만져봤어요” 수준과 “우리는 X를 배웠고, 그래서 Y를 하기로 결정했다” 수준을 가르는 경계가 되곤 합니다.

완성도 대신 빠른 피드백에 최적화하기

2시간짜리 실험이 흔적도 없이 사라지는 가장 큰 이유 중 하나는, 처음부터 욕심이 너무 많을 때입니다. 전체 플로우, 완벽한 에러 처리, 예쁜 UI까지 다 해보려는 식이죠.

대신 빠르고, 집중된 피드백에 최적화해야 합니다.

• 가정(assumption)을 검증하는 데 필요한 크리티컬 패스만 구현합니다.
• 설정 시스템을 다 짤 생각 말고, 값을 하드코딩해도 됩니다.
• 지금은 적합성(feasibility)만 보는 단계이므로, 통합 어댑터를 정교하게 만들기보다 간단한 스텁으로 때웁니다.
• 코드가 좀 투박하고 절차적이어도, 그게 의식과 ceremony를 줄여 학습 속도를 높여 준다면 그대로 두어도 괜찮습니다.

스스로에게 계속 물어보세요.

“유의미한 걸 하나 배우기 위해, 진짜로 필요한 최소한은 무엇인가?”

예시를 들어보면:

• 테스트 프레임워크 오버헤드를 보고 싶은가? 그럼 행복 경로(happy path) 하나만 검증하는 단일 테스트 파일이면 충분합니다.
• 새 큐 시스템을 평가하고 싶은가? 마이크로서비스 구조부터 짜지 말고, 단일 프로세스 안에서 수천 개 메시지를 푸시/컨슘하고 로그만 찍어도 됩니다.
• 새 UI 위젯 라이브러리를 살펴보는가? 실제 화면 전체를 옮기려 하지 말고, 관심 있는 두 개 컴포넌트만 있는 로컬 페이지 하나면 충분합니다.

폴더 구조, 네이밍 규칙, DI 컨테이너 같은 생각이 슬슬 떠오른다면, 실험에서 아키텍처 설계 모드로 기어를 바꾸고 있다는 신호입니다. 그때는 한 번 물러나서 방향을 다시 잡아야 합니다.

가벼운 툴과 자동화 사용하기

불편한 툴링과 싸우다 보면 2시간은 순식간에 사라집니다. 실험 환경은 최대한 마찰이 없어야 합니다.

실용적인 가이드라인을 몇 가지 정리하면:

• 풀 서비스보다는 간단한 스크립트를 선호합니다.
• API를 만져보려면, 정식 클라이언트를 먼저 만들기보다 curl, HTTPie, jq 같은 커맨드라인 도구로 바로 두드려 봅니다.
• 의존성은 최소화합니다. 라이브러리 하나 보려고 굳이 대형 모노레포를 새로 깔 필요는 없습니다.
• 작은 테스트 리그로 충분합니다. 단일 스크립트나 Jupyter 노트북 하나로도 웬만한 건 실험할 수 있습니다.
• 이미 사용하는 로컬 인프라(Docker, 로컬 DB, 모킹 도구 등)를 최대한 재활용하고, 새로운 스택을 가능한 한 만들지 않습니다.

팀 차원에서 작은 **“실험 스타터 킷”**을 만들어두는 것도 좋습니다.

• 기본 빌드, 테스트, 로깅이 설정된 템플릿 레포
• run.sh, bench.sh, demo.sh 같은 심플한 스크립트 몇 개
• 샘플 설정 파일이나 .env.example

목표는 단순합니다. 2시간 중 대부분의 시간을 기술/문제와 직접 씨름하는 데 쓰고, 파이프라인이나 설정 싸움에는 최소한만 쓰는 것입니다.

결과가 사라지지 않게: 즉시 기록하고 공유하기

가장 안타까운 실험은, 중요한 질문에 이미 답을 냈는데… 누군가의 Downloads 폴더에서 그대로 잊혀지는 경우입니다.

이걸 막기 위해, 처음부터 마지막 단계를 프로세스에 포함시켜야 합니다. 바로, 기록과 공유입니다.

2시간 블록 안에서 마지막 10–15분은 꼭 아래 작업에 씁니다.

1. 짧은 요약 작성하기 (5–10줄이면 충분합니다)

   • 어떤 질문을 탐색했는가?
   • 높은 수준에서 무엇을 했는가?
   • 무엇을 배웠는가?
   • 다음 단계로 무엇을 추천하는가?

2. 코드와 산출물 저장하기

   • 실험 브랜치를 공유 레포에 푸시합니다. 예: /experiments 폴더나 전용 레포.
   • 최소한의 사용법을 적은 README.md를 남깁니다. 3–5줄짜리 “how to run”이면 충분합니다.
   • 의미 있는 로그, 스크린샷, 벤치마크 결과 파일이 있다면 함께 저장합니다.

3. 결과 공유하기

   • 팀 채널(슬랙 등)에 짧은 메시지를 남기고, 코드와 요약 링크를 함께 올립니다.
   • 관련 티켓이나 아키텍처 결정 기록(ADR 등)이 있다면, 거기에 링크를 추가합니다.

여기서 목표는 완벽한 문서를 만드는 게 아닙니다. 지금까지 한 일이 증발하지 않도록 최소한의 흔적을 남기는 것입니다. 몇 문단과 한두 개의 링크만 있어도, 2시간짜리 실험이 이후 아키텍처/기술 결정에 쓰일 수 있는 “공식 근거”가 됩니다.

진짜 어려운 부분: 2시간에서 냉정하게 멈추기

시간이 다 되어 갈 때쯤 이런 생각이 들 겁니다.

• “거의 다 됐는데… 좀만 더 하면 완전하게 돌아갈 것 같은데…”
• “한 시간만 더 쓰면, 재사용 가능한 형태로 깔끔하게 만들 수 있는데…”

하지만 참아야 합니다.

2시간 제약이라는 규율이 있어야, 실험이 언제나 싸고, 지속 가능한 방식으로 돌아갈 수 있습니다.

시간이 끝나면 일단 멈추고, 나서 다음 중 하나를 의식적으로 선택합니다.

1. 폐기(Discard)

   • 결과가 명확하다면(“이건 우리에겐 안 맞는다”), 브랜치를 아카이빙하고 관련 티켓이나 설계 문서를 업데이트합니다.
   • 이건 실패가 아니라 성공입니다. 몇 주를 쏟아부어야 알 수 있는 결론을, 2시간 만에 얻은 겁니다.

2. 반복(Iterate)

   • 일부만 답을 얻었고 추가 학습이 합당하다면, 새로운 2시간 실험을 명시적으로 잡습니다.
   • “조금만 더…”를 허용하면 시간이 끝없이 새어 나갑니다. 늘 새 스파이크로 잘라내, 다시 의도적으로 시작해야 합니다.

3. 제품화(Productize) (드물어야 하고, 의도를 명확히 해야 합니다)

   • 실험 결과가 실제 시스템의 일부가 될 만큼 유망하다면, 제대로 된 엔지니어링 작업을 계획합니다.
     • 테스트, 리팩터링, 성능, 보안 등을 위한 티켓을 만듭니다.
     • 평소 코드 리뷰 · 배포 프로세스 안으로 이 코드를 편입시킬 경로를 설계합니다.
   • “일단 되니까”라는 이유로 실험 코드를 그대로 머지하는 일은 피합니다.

이런 명시적인 선택 지점 덕분에, 두 가지 극단 모두를 피할 수 있습니다.

• 의미 있는 인사이트가 묻히는 것
• 실험 코드가 슬금슬금 프로덕션에 스며드는 것

팀 차원에서 2시간 실험을 습관으로 만들기

이런 마이크로 스파이크는 팀 차원에서 보이고, 당연하게 여겨질 때 가장 큰 힘을 발휘합니다.

• 작업 관리 도구(Jira, Linear, GitHub Projects 등)에 **“실험(Experiment)”**이라는 활동 유형을 1급 시민으로 넣습니다.
• 개발자가 불확실성 때문에 막혔을 때, 추측으로 때우기보다 2시간 실험을 제안하도록 장려합니다.
• 회고(retro)나 스탠드업에서 “무엇을 배웠는가”라는 관점의 결과를 함께 공유합니다.
• 과거 실험들을 모아두고 검색할 수 있는 작은 실험 카탈로그를 만듭니다.

시간이 지나면 이런 변화를 느낄 수 있습니다.

• 아키텍처 논쟁이 짧아집니다. 말싸움 대신 실제 데이터가 있기 때문입니다.
• 위험한 결정은 더 잘게 쪼개지고, 더 많은 정보를 바탕으로 이뤄집니다.
• 왜 이런 결정을 했는지 아무도 모르는, **“미스터리 결정”**이 줄어듭니다.

정리: 작게, 빠르게, 그리고 의도적으로

2시간짜리 코딩 실험은 단순하지만, 효과가 큰 실천 방법입니다.

• 강한 타임박스 덕분에 오버엔지니어링과 잠행 프로젝트로의 변질을 막을 수 있습니다.
• 이를 애자일 스파이크로 대하는 순간, 목적이 명료해집니다. 불확실성을 줄이고, 중요한 결정을 디리스킹하는 것.
• 명확한 질문과 성공 기준 덕분에, 실험 결과가 실제 액션으로 이어질 수 있습니다.
• 완성도보다 빠른 피드백을 중시하면, 값싸고 빠르게 배울 수 있습니다.
• 가벼운 툴링은 세팅보다는 인사이트에 시간을 쓰게 해 줍니다.
• 결과를 기록하고 공유하면, 실험에서 나온 발견이 사라지지 않고 실제 작업을 형성합니다.
• 2시간에서 냉정하게 멈추는 습관은 이 모든 것을 지속 가능하게 만들고, 실험 코드가 실수로 프로덕션에 스며드는 것을 막아 줍니다.

팀이 선택지를 두고 끝없이 말싸움만 하거나, 몇 주짜리 “PoC(Proof of Concept)” 속으로 사라지는 경우가 잦다면, 2시간 제약을 한번 도입해 보세요.

딱 한 가지 질문, 하나의 실험, 2시간짜리 블록 하나로 시작하면 됩니다.

그다음부터는, 학습이 복리로 쌓이도록 두면 됩니다.