DesigningInTheRun
주니어 개발자들을 위한 패턴 언어 - 소스 코드 밖, 프로그램이 살아 움직이는 현장에서 직접 설계를 결정하는 법
Contents
The Story 1: The Editor Resident vs. The Runtime Explorer (Programming)
두 명의 개발자, 민수와 하나가 복잡한 UI 레이아웃과 데이터 처리 로직을 수정하고 있다.
민수의 방식 (The Editor Resident): 민수는 오직 에디터(VS Code)만 본다. 그는 상상력을 동원하여 HTML과 CSS를 수정한다. "여기에 마진을 20px 주면 예쁘겠지?" 수정 후 저장하고, 빌드를 기다리고, 브라우저를 확인한다. 마음에 들지 않는다. 다시 에디터로 돌아간다. 민수는 소스 코드와 실행 결과 사이의 긴 강을 수십 번 왕복하며 진을 뺀다. 지도가 실제 땅과 어떻게 다른지 매번 뒤늦게 깨닫기 때문이다.
하나의 방식 (The Runtime Explorer): 하나는 실행 중인 브라우저 안으로 직접 들어간다. (Chrome DevTools)
현장 편집: 인스펙터를 열어 HTML 요소를 실시간으로 수정하고 CSS 값을 드래그하며 최적의 수치를 찾는다. 화면이 바뀌는 것을 즉시 확인하며 설계를 확정 짓는다.
로직 탐색: 복잡한 데이터 변환이 필요할 때는 REPL(django shell 등)을 띄워 실제 데이터를 넣어본다.
하나는 소스 코드를 고치기 전에 이미 작동하는 진실을 알고 있다. 그녀는 현장에서 결정된 내용을 소스 코드에 마지막으로 '기록'할 뿐이다.
The Story 2: The Tape on the Floor (Ordinary Life)
민수와 하나는 비어있는 새 사무실에 가구를 배치하려 한다.
민수의 배치 (The Blueprint Only): 민수는 평면도 도면을 출력해왔다. 책상 크기를 자로 재고 도면 위에 연필로 배치도를 그렸다. "여기 책상을 두면 딱 맞겠어." 하지만 실제로 책상이 배달되었을 때, 도면에서는 보이지 않았던 기둥과 콘센트 위치 때문에 책상을 놓을 수 없음을 깨달았다. 민수는 무거운 책상을 다시 옮기느라 진땀을 흘렸다.
하나의 배치 (The On-site Marking): 하나는 사무실 바닥에 마스킹 테이프를 들고 갔다. 그녀는 도면을 보는 대신, 실제 바닥에 테이프를 붙여 책상 크기만큼 표시해 보았다. "아, 여기 테이프를 붙여보니 통로가 너무 좁네. 책상을 10cm만 왼쪽으로 옮기자." 하나는 가구가 들어오기 전에 이미 현장에서 최적의 배치를 확정했다. 실제 공간의 부피와 질감을 몸으로 느끼며 내린 결정은 틀릴 리가 없었다. 진정한 설계는 머릿속이 아니라 발을 딛고 있는 대지 위에서 일어남을 하나는 알고 있었다.
Context
TightLoop를 유지하며 기능을 개발하고 있다. CSS 수치나 복잡한 데이터 가공 로직처럼, 소스 코드 단계에서 결과를 완벽히 예측하기 어려운 작업을 수행 중이다.
일상적인 상황:
- CSS 값을 1px씩 바꿔가며 저장과 새로고침을 반복하느라 시간이 다 간다.
- 복잡한 정규표현식이나 데이터 필터링 로직이 한 번에 맞기를 기도하며 코드를 짠다.
- "에디터에서 볼 때는 맞는데 왜 실행하면 다르지?"라고 의아해하며 추측으로 코드를 고친다.
- 시스템을 재시작하는 시간이 아까워 확인을 미루다가 나중에 큰 버그를 발견한다.
당신은 지금 완성된 지도를 그리려 애쓰고 있지만, 실제 영토를 밟아볼 생각은 하지 않고 있다.
Problem
에디터 안에서의 상상만으로 설계를 결정하려 하면, 피드백 주기가 길어지고 실행 환경의 수많은 변수를 놓치게 된다.
시각적 피드백의 지연: UI의 미세한 조정은 실시간 확인 없이는 불가능에 가깝습니다. 상상력만으로 픽셀 단위의 조화를 맞추는 것은 뇌에 엄청난 피로를 줍니다.
가설 검증의 높은 비용: 로직을 확인하기 위해 매번 전체 시스템을 빌드하고 재시작하는 것은 전진하는 리듬을 끊어버립니다.
현실과의 괴리: 런타임 환경(브라우저 엔진, DB 상태 등)은 에디터가 보여주지 않는 수많은 제약 조건을 가지고 있습니다. 이를 무시한 설계는 결국 실패합니다.
Solution
소스 코드를 고치기 전에 브라우저 인스펙터, 디버거, REPL 등 "실행 중인 환경"에서 먼저 결과를 결정하라.
Christopher Alexander가 대지 위에서 말뚝을 박으며 집의 위치를 정했듯, 개발자도 프로그램이 돌아가는 현장에서 설계를 확정해야 합니다.
Principle 1: Live UI Tweaking (실시간 UI 조정)
브라우저의 개발자 도구를 에디터보다 더 사랑하십시오.
- 요소의 위치, 색상, 크기를 인라인으로 직접 편집하며 "살아있는지" 느껴보십시오.
- 완벽한 수치와 구조를 발견했을 때, 그 결과를 소스 코드에 역으로 반영하십시오.
Principle 2: REPL-Driven Development (REPL 기반 개발)
데이터 가공 로직은 REPL(Read-Eval-Print Loop)에서 먼저 검증하십시오.
- Django shell, Node.js REPL 등에서 실제 객체를 만져보며 함수의 입출력을 확정하십시오.
TinyExperiment를 수행하기에 REPL보다 좋은 장소는 없습니다.
Principle 3: Debugger as an Exploration Tool (탐색 도구로서의 디버거)
디버거를 단순히 버그를 잡는 '사후 처방' 용도로만 쓰지 마십시오.
- 중단점(Breakpoint)을 걸고 시스템이 멈춘 상태에서 변수 값을 강제로 바꿔보거나 함수를 실행해보며, 시스템이 가진 잠재적 가능성을 탐색하십시오.
Principle 4: Real-time Feedback Loop (현장 피드백)
내가 고친 것이 즉시 현실이 되게 하십시오. DesigningInTheRun은 TightLoop를 물리적으로 실천하는 가장 구체적인 방법입니다.
Real Examples
Example 1: Determining HTML Structure
민수는 에디터에서 <div> 구조를 쪼개며 고민하지만, 하나는 크롬 인스펙터에서 Edit as HTML을 눌러 구조를 즉석에서 바꿔봅니다. 레이아웃이 무너지지 않는 것을 확인한 후에야 비로소 에디터에 코드를 옮겨 적습니다.
Example 2: Complex Query in Shell
복잡한 데이터 필터링 로직을 짜야 할 때, 하나는 서버를 띄우는 대신 shell을 열어 한 줄씩 명령어를 쳐봅니다. 데이터가 정확히 걸러지는 것을 눈으로 확인한 뒤 서비스 로직에 반영합니다.
Common Pitfalls
"I forgot to save!" (저장하는 걸 깜빡했어요)
현장에서 신나게 고쳤는데 새로고침을 하거나 창을 닫아버리는 것. 현장에서 얻은 영감은 즉시 메모하거나 에디터에 반영하는 습관을 들여야 합니다.
Temporary Fix vs. Permanent Code (임시 방편의 함정)
인스펙터에서 대충 맞춘 코드를 그대로 가져왔을 때 전체적인 아키텍처가 나빠지는 경우. 현장에서는 '결과'를 결정하고, 에디터에서는 그 결과를 '우아한 구조'로 정착시켜야 합니다.
Connection to Other Patterns
TightLoop - DesigningInTheRun은 피드백 루프를 물리적 한계까지 좁히는 기술입니다. 심화
PresentMoment - 실행 중인 상태야말로 우리가 마주해야 할 가장 정직한 현재입니다. 기반
WorkingFirst - 현장에서 일단 돌아가게 만드는 것이 모든 설계의 시작입니다. 우선순위
RoughWholeFirst - 엉성한 전체를 화면에 띄워놓고 인스펙터로 세분화해 나갑니다. 방법
Signs of Success
- 에디터보다 브라우저나 터미널 창을 더 자주, 더 깊게 들여다본다.
- 코드를 한 번에 작성하고 실행했을 때 단번에 작동할 확률이 높아진다.
- "어? 이게 왜 이렇게 나오지?"라는 당혹감이 사라진다. 이미 실행 결과를 알고 있기 때문이다.
- UI나 로직의 세부 수치를 결정하는 속도가 비약적으로 빨라진다.
The Ultimate Insight
진정한 설계는 종이 위가 아니라, 발을 딛고 있는 대지 위에서 완성된다.
컴퓨터는 당신의 머릿속이 아니라 현실의 런타임에서 숨을 쉽니다. 그 숨결을 직접 느끼며 코드를 만지십시오. 실행 중인 현장이 당신의 실험실이자 작업실이 될 때, 당신의 코드는 비로소 생명력을 얻게 될 것입니다.
CategoryPatternLanguage CategoryProgramming CategoryDesign CategoryDebugging CategoryAgile