DesigningInTheRun

주니어 개발자들을 위한 패턴 언어 - 소스 코드 밖, 프로그램이 살아 움직이는 현장에서 직접 설계를 결정하는 법

The Story: The Editor Resident vs. The Runtime Explorer

두 명의 개발자, 민수와 하나가 복잡한 UI 레이아웃과 데이터 처리 로직을 수정하고 있다.

민수의 방식 (The Editor Resident): 민수는 오직 에디터(VS Code)만 본다. 그는 상상력을 동원하여 HTML과 CSS를 수정한다. "여기에 마진을 20px 주면 예쁘겠지?" 수정 후 저장하고, 빌드를 기다리고, 브라우저를 확인한다. 마음에 들지 않는다. 다시 에디터로 돌아간다. 민수는 소스 코드와 실행 결과 사이의 긴 강을 수십 번 왕복하며 진을 뺀다.

하나의 방식 (The Runtime Explorer): 하나는 실행 중인 브라우저 안으로 직접 들어간다. (Chrome DevTools)

1. 현장 편집: 인스펙터를 열어 HTML 요소를 실시간으로 수정하고 CSS 값을 드래그하며 최적의 수치를 찾는다. 화면이 바뀌는 것을 즉시 확인하며 설계를 확정 짓는다.

2. 로직 탐색: 복잡한 데이터 변환이 필요할 때는 REPL(django shell 등)을 띄워 실제 데이터를 넣어본다.

하나는 소스 코드를 고치기 전에 이미 작동하는 진실을 알고 있다. 그녀는 현장에서 결정된 내용을 소스 코드에 마지막으로 '기록'할 뿐이다.

Context

TightLoop를 유지하며 기능을 개발하고 있다. CSS 수치나 복잡한 데이터 가공 로직처럼, 소스 코드 단계에서 결과를 완벽히 예측하기 어려운 작업을 수행 중이다.

일상적인 상황:

• CSS 값을 1px씩 바꿔가며 저장과 새로고침을 반복한다.
• 복잡한 정규표현식이나 데이터 필터링 로직이 한 번에 맞기를 기도하며 코드를 짠다.
• "에디터에서 볼 때는 맞는데 왜 실행하면 다르지?"라고 의아해한다.

당신은 지금 완성된 지도를 그리려 애쓰고 있지만, 실제 영토를 밟아볼 생각은 하지 않고 있다.

Problem

에디터 안에서의 상상만으로 설계를 결정하려 하면, 피드백 주기가 길어지고 실행 환경의 변수를 놓치게 된다.

• 시각적 피드백의 지연: UI의 미세한 조정은 실시간 확인 없이는 불가능에 가깝다.

• 가설 검증의 비용: 로직을 확인하기 위해 매번 전체 시스템을 재시작하는 것은 엄청난 에너지 낭비다.

• 정신적 에너지 소모: 머릿속으로 실행 결과를 시뮬레이션하느라 뇌가 금방 지친다.

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: Shorten the Distance to Reality (현실과의 거리 좁히기)

내가 고친 것이 즉시 현실이 되게 하라.

• DesigningInTheRun은 TightLoop를 물리적으로 실천하는 가장 구체적인 방법이다.

Real Examples

Example 1: Determining HTML Structure

민수는 에디터에서 <div>를 쪼개며 고민하지만, 하나는 크롬 인스펙터에서 Edit as HTML을 눌러 구조를 바꿔본다. 화면이 무너지지 않는 것을 확인한 후에야 에디터에 코드를 옮긴다.

Example 2: API Logic in Shell

복잡한 Queryset 필터링을 짜야 할 때, 하나는 서버를 띄우는 대신 python manage.py 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