TightLoop
주니어 개발자들을 위한 패턴 언어 - 변경과 피드백 사이의 간격을 최소화하여 몰입을 유지하는 법
Contents
The Story 1: The Long Wait vs. The Instant Response (Programming)
두 명의 개발자, 민수와 하나가 CSS 스타일을 수정하고 로직을 점검하고 있다.
민수의 하루 (The Distracted Loop): 민수는 코드 한 줄을 고쳤다. 그리고 결과를 보기 위해 서버를 중지하고, 다시 빌드하고(30초), 서버가 뜰 때까지 기다린 뒤(20초), 브라우저를 새로고침하고 로그인해서 해당 페이지까지 클릭해 들어간다(30초). 합계 1분 20초. 그 사이 민수는 지루함을 참지 못하고 스마트폰을 확인하거나 메신저를 본다. 다시 코드로 돌아왔을 때, 그는 방금 무엇을 고치려 했는지 잊어버렸다.
하나의 하루 (The Flow Loop): 하나는 환경 설정에 공을 들였다. 코드를 저장하자마자 Hot Reload가 작동하여 0.5초 만에 브라우저에 반영된다. 로직이 궁금할 때는 해당 부분만 검증하는 유닛 테스트를 실행한다(1초 이내). 하나는 자리에 앉아 2시간 동안 한 번도 흐름이 끊기지 않았다. 그녀의 뇌는 코드와 실시간으로 대화하는 것 같은 상태(Flow)에 빠졌다.
The Story 2: The Tennis Coach (Ordinary Life)
민수와 하나는 테니스를 배우기 시작했다.
민수의 레슨 (The Delayed Feedback): 민수는 독학을 선호한다. 그는 자신의 스윙 모습을 동영상으로 촬영한 뒤, 집에 돌아와서 영상을 확인한다. "아, 라켓 각도가 너무 누웠구나." 민수는 집에 와서야 자신의 실수를 깨달았지만, 이미 몸의 감각은 사라진 뒤였다. 다음 날 테니스장에 갔을 때 민수는 어제와 똑같은 실수를 반복했다.
하나의 레슨 (The Tight Loop): 하나는 전문 코치에게 레슨을 받는다. 하나가 공을 치는 순간, 코치가 옆에서 즉시 외친다. "라켓 끝을 더 세우세요!" 하나는 방금 친 공의 느낌이 손에 남아있는 상태에서 즉시 동작을 수정한다. 0.1초 만에 돌아오는 피드백 덕분에 하나의 몸은 올바른 자세를 빠르게 기억했다. 피드백 루프가 촘촘할수록 학습 속도는 기하급수적으로 빨라짐을 하나는 몸소 체험했다.
Context
당신은 코드를 작성하고 있다. 한 줄을 고칠 때마다 그것이 제대로 작동하는지 확인해야 한다.
일상적인 상황:
- 코드를 고치고 결과를 확인하기까지 과정이 너무 번거롭다.
- 빌드나 배포 시간이 길어서 그 사이에 딴짓을 하게 된다.
- "한꺼번에 고쳐서 한 번에 확인해야지"라고 생각하며 큰 덩어리로 작업한다.
- 피드백이 늦게 오니 실수를 발견했을 때 이미 너무 멀리 와버렸다.
당신은 지금 코드와 느리고 답답한 대화를 나누고 있다.
Problem
피드백 루프가 길어지면, 개발자는 몰입(Flow)을 잃고 인지 부하가 급증한다.
인간의 단기 기억은 짧다. 변경 사항이 시스템에 반영되기까지 10초 이상 걸리면:
맥락 상실: 기다리는 동안 뇌는 다른 생각을 하기 시작한다. 다시 집중하려면 에너지가 든다.
추측의 증가: 확인하기 귀찮으니 "아마 되겠지"라고 추측하며 코드를 더 많이 작성한다. 결과적으로 버그가 더 복잡하게 얽힌다.
지루함과 피로: 지루한 대기 시간은 개발을 고통스럽게 만든다.
반대로 피드백이 빠르면 개발은 게임처럼 즐거워진다. 내가 한 행동의 결과가 즉시 보이기 때문이다.
Solution
변경을 만들고 그 효과를 확인하는 사이의 시간(Feedback Loop)을 1초 이내로 줄여라.
TightLoop는 도구의 설정과 작업 방식의 혁신을 요구한다.
Principle 1: Optimize the Environment (도구에 투자하라)
기다리는 시간은 공짜가 아니다. 피드백을 빠르게 해주는 도구에 시간을 투자하는 것은 가장 수익률이 높은 투자다.
Hot Reload / Live Reload: 저장 즉시 반영되게 하라.
Fast Tests: 전체 테스트가 아니라, 지금 고치는 부분의 테스트만 0.1초 만에 실행되게 하라.
REPL / Notebook: 전체 앱을 띄우지 않고도 로직을 실험할 수 있는 환경을 갖춰라.
Principle 2: Work in Smallest Units (가장 작은 단위로 확인하라)
전체 시스템을 다 실행해서 확인하려 하지 마라.
- 특정 함수만 떼어내어 실행할 수 있는가?
- 특정 UI 컴포넌트만 따로 볼 수 있는가(Storybook 등)?
- 데이터베이스 없이 메모리에서 로직만 검증할 수 있는가?
Principle 3: Automate the Path (경로를 자동화하라)
확인하기 위해 매번 로그인하고 5번 클릭해야 한다면, 그 경로를 코드로 자동화하라.
- 특정 상태로 앱이 시작되게 하는 URL 파라미터를 만들거나, 테스트 코드를 활용하라.
Principle 4: Stop and Fix the Loop (루프가 느려지면 멈춰라)
빌드 시간이 1분을 넘어가기 시작하면, 기능 개발을 멈추고 빌드 시간을 줄이는 작업을 먼저 하라. 이것이 BabySteps를 가능하게 하는 기반이다.
Real Examples
Example 1: UI Development
CSS를 고칠 때마다 브라우저를 새로고침하고 있다면:
BrowserSync나 Vite 같은 도구를 설정하여 저장 시 즉시 반영되게 한다.
- 레이아웃이 깨졌을 때 0.5초 만에 여러 시도를 해볼 수 있다. 결과적으로 훨씬 아름다운 UI를 더 빨리 만든다.
Example 2: Backend Logic
복잡한 정산 로직을 고치고 있다면:
- 매번 전체 정산 프로세스를 실행(3분 소요)하지 않는다.
- 문제가 되는 계산 함수만 추출하여 유닛 테스트를 만든다.
watch 모드로 테스트를 띄워놓고, 코드를 고칠 때마다 0.2초 만에 통과 여부를 확인한다.
Common Pitfalls
"I don't have time to set up tools" (설정할 시간이 없어요)
가장 흔한 핑계다. 하루에 1분짜리 대기를 50번 한다면, 당신은 매일 50분을 버리고 있다. 1시간을 투자해 도구를 설정하면 다음 날부터 매일 50분을 버는 것이다.
"My project is too big" (프로젝트가 너무 커서 느려요)
프로젝트가 클수록 격리(Isolation)가 중요하다. 전체를 빌드하지 않고 부분만 빌드하거나 테스트할 수 있는 구조를 만들어야 한다. 이것은 설계의 문제이기도 하다(DesignThroughTest).
Relying on Manual QA (수동 확인에 의존하기)
사람이 직접 눈으로 확인하는 것은 가장 느린 루프다. 가능한 한 기계가 확인하게(Automated Test) 하라.
Connection to Other Patterns
GreenRefuge - 루프가 빠르면 내가 언제 길을 잃었는지 즉시 알 수 있고, 즉시 돌아갈 수 있습니다. 안전망
DesignThroughTest - 테스트하기 쉬운 설계는 TightLoop를 가능하게 합니다. 설계적 측면
CognitiveMicroscope - 빠른 피드백은 내 사고의 해상도를 높여줍니다. 인지적 효과
Signs of Success
- 코드를 저장하는 행위와 결과를 확인하는 행위가 거의 동시에 일어난다.
- 개발 중에 메신저나 웹 서핑을 하고 싶은 유혹이 들지 않는다(몰입 상태).
- 하루에 수백 번 이상의 작은 확인을 거치며 전진한다.
- "어? 이게 왜 이래?"라는 당혹감이 거의 없다. 모든 변화를 즉시 확인하기 때문이다.
The Ultimate Insight
개발의 속도는 타이핑 속도가 아니라, 피드백 루프의 회전 속도에 결정된다.
루프가 촘촘해질수록 당신의 뇌는 코드와 하나가 됩니다. 기다리지 마십시오. 시스템이 당신에게 즉시 대답하게 하십시오. 그것이 전문가의 작업 방식입니다.
CategoryPatternLanguage CategoryProgramming CategoryAgile CategoryTDD