|
Size: 7602
Comment:
|
← Revision 3 as of 2025-12-30 08:50:47 ⇥
Size: 8352
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 8: | Line 8: |
| == The Story: The Sketch vs. The Jigsaw Puzzle == | == The Story 1: The Dashboard Sketch (Programming) == |
| Line 13: | Line 13: |
| 민수는 완벽주의자다. 그는 왼쪽 상단의 '사용자 프로필' 컴포넌트부터 완벽하게 만들기 시작했다. "로그인한 사용자의 아바타를 가져오고, 등급에 따라 테두리 색을 바꾸고..." 그는 이 작은 조각을 완성하는 데만 이틀을 썼다. 하지만 정작 대시보드 전체를 조립했을 때, 프로필 컴포넌트가 너무 커서 다른 차트들이 들어갈 자리가 없음을 깨달았다. 민수는 정성껏 만든 조각을 다시 깎아내야 했다. |
민수는 완벽주의자다. 그는 왼쪽 상단의 '사용자 프로필' 컴포넌트부터 완벽하게 만들기 시작했다. 아바타 이미지의 그림자 값, 테두리 두께 등을 이틀 내내 공들여 다듬었다. 하지만 정작 대시보드 전체를 조립했을 때, 프로필 컴포넌트가 너무 커서 다른 차트들이 들어갈 자리가 없음을 깨달았다. 민수는 정성껏 만든 조각을 다시 깎아내야 했다. |
| Line 18: | Line 16: |
| 하나는 화가처럼 시작했다. 1. '''엉성한 전체:''' 처음 10분 만에 화면 전체를 텅 빈 박스 4개로 채웠다. (전체 레이아웃 확정) 2. '''점진적 분화:''' 첫 번째 박스에 '프로필'이라는 글자를 적었다. 두 번째 박스에는 가짜 차트 이미지를 넣었다. 3. '''세분화:''' 전체 구도가 잡히자, 그때부터 하나씩 진짜 코드로 교체해 나갔다. 하나는 단 한 번도 조각을 깎아낼 필요가 없었다. 시스템은 처음부터 '전체'로서 존재했고, 시간이 흐름에 따라 더 정교하게 '''분화(Differentiation)'''되었을 뿐이다. |
하나는 화가처럼 시작했다. 먼저 화면 전체를 텅 빈 박스 4개로 채워 전체 구도를 잡았다. 그 안의 여백과 배치가 조화로운지 먼저 확인한 후, 하나씩 진짜 코드로 교체해 나갔다. 하나는 단 한 번도 조각을 깎아낼 필요가 없었다. 시스템은 처음부터 '전체'로서 존재했고, 시간이 흐름에 따라 더 정교하게 '''분화(Differentiation)'''되었을 뿐이다. == The Story 2: The IKEA Table (Ordinary Life) == 민수와 하나는 집에서 사용할 식탁을 함께 조립하고 있다. '''민수의 조립 (The Tight Bolt):''' 민수는 매뉴얼대로 단단히 고정하고 싶어 한다. 그는 첫 번째 다리를 프레임에 끼우고 나사를 끝까지 꽉 조였다. "흔들리지 않게 해야지." 하지만 네 번째 다리까지 조립하고 상판을 덮으려 하자, 구멍이 미세하게 어긋나 있었다. 나사를 너무 일찍 꽉 조여버린 탓에 프레임이 유연하게 움직이지 않았고, 민수는 상판을 끼우기 위해 모든 나사를 다시 풀어야 했다. '''하나의 조립 (The Soft Fastening):''' 하나는 다르게 행동했다. 나사를 손으로만 살짝 돌려 '느슨하게' 걸어두었다. 다리들은 조금씩 흔들거렸지만 덕분에 여유 공간(Buffer)이 생겼다. 상판을 얹자 느슨한 다리들이 조금씩 움직이며 상판 구멍에 완벽하게 들어맞았다. 모든 조각이 제 자리를 잡은 것을 확인한 후에야 하나는 모든 나사를 단단히 조였다. 기예는 '느슨한 전체'에서 시작해 '단단한 부분'으로 나아가는 것임을 하나는 알고 있었다. |
| Line 27: | Line 32: |
| [[OrganicGrowth]]를 실천하며 시스템을 구축하고 있다. [[StrongCenter]]를 잡았지만, 그 중심에서 어떻게 확장을 시작해야 할지 고민 중이다. | [[OrganicGrowth]]를 실천하며 시스템을 구축하고 있다. [[StrongCenter]]를 잡았지만, 그 중심에서 어떻게 확장을 시작해야 할지 고민 중이다. 코딩뿐만 아니라 가구를 조립하거나 글을 쓰는 등 무언가 구조를 만드는 모든 상황에 해당한다. |
| Line 35: | Line 40: |
| 당신은 지금 '''퍼즐 조각'''을 맞추고 있는가, 아니면 '''그림'''을 그리고 있는가? |
|
| Line 40: | Line 43: |
| '''부분을 먼저 완성하고 조립하려 하면, 전체적인 조화(Wholeness)를 잃고 재작업의 비용이 커진다.''' | '''부분을 너무 일찍 완벽하게(Hardened) 만들면, 전체적인 조화(Wholeness)를 맞추기 위한 유연성이 사라진다.''' |
| Line 42: | Line 45: |
| * '''전체성의 상실:''' 조각들은 각자 훌륭할지 모르나, 그것들이 모였을 때 시스템의 본질적인 가치를 드러내지 못할 수 있다. * '''유연성 부족:''' 조각이 너무 일찍 완벽해지면(Hardened), 나중에 전체 구조에 맞춰 수정하기가 매우 힘들어진다. |
* '''유연성 부족:''' 조각이 너무 일찍 굳어지면, 나중에 전체 구조에 맞춰 수정하기가 매우 힘들어진다. * '''재작업의 비용:''' IKEA 테이블처럼, 나중에 전체가 안 맞으면 처음부터 다 풀어야 한다. |
| Line 48: | Line 51: |
| '''완벽한 부분보다 엉성하더라도 "전체 구조"를 먼저 만들고, 그 안에서 세부 사항을 점진적으로 분화시켜라.''' | '''완벽한 부분보다 엉성하더라도 "전체 구조"를 먼저 만들고, 나사를 느슨하게 조인 상태(Soft Fastening)로 세부 사항을 점진적으로 분화시켜라.''' |
| Line 52: | Line 55: |
| === Principle 1: Embryonic Growth (배아적 성장) === 시스템은 처음부터 '전체'여야 한다. * 아주 단순하고 기능이 거의 없더라도, 입력부터 출력까지 연결된 '''전체 흐름(Walking Skeleton)'''을 가장 먼저 확보하라. * 이 엉성한 전체가 시스템의 '배아'가 되어, 앞으로의 모든 성장을 가이드한다. |
=== Principle 1: Meta-Planning with TODO.md (메타플래닝) === 코딩을 시작하기 전, 반드시 '''TODO.md''' 파일을 만들어 작업의 전체 지도를 그리십시오. 해야 할 일들을 나열하고 우선순위를 정하는 행위 자체가 시스템의 전체성을 파악하는 첫 번째 분화 과정입니다. |
| Line 57: | Line 58: |
| === Principle 2: Defer Detailed Implementation (세부 구현 미루기) === 구조를 잡는 동안 세부 로직은 가짜(Mock, Hardcoding)로 채워라. * "로그인 로직"을 완벽히 짜기보다, "로그인 성공이라고 가정함"이라는 텍스트 한 줄을 띄우는 것이 먼저다. * 전체적인 흐름과 배치가 확정될 때까지 세부 사항을 '굳히지' 마라. |
=== Principle 2: Soft Fastening (나사를 느슨하게 유지하기) === 처음부터 코드를 '확정' 짓지 마라. * 인터페이스는 만들되 내부 구현은 가짜(Mock)로 채워라. * 클래스 사이의 관계를 확정하기 전까지는 결합을 느슨하게 유지하라. * "나중에 바뀔 수 있다"는 여백을 남겨두어야 전체적인 균형을 맞출 수 있다. |
| Line 62: | Line 64: |
| === Principle 3: Differentiation over Assembly (조립이 아닌 분화) === 바깥에서 조각을 가져와 붙이지 말고, 안에서 나누어라. * 거대한 클래스를 먼저 만들고, 그 내부가 복잡해지면 그때 클래스를 쪼개라. * 큰 화면 레이아웃을 먼저 잡고, 그 안의 공간을 나누어 컴포넌트를 배치하라. |
=== Principle 3: Embryonic Growth (배아적 성장) === 시스템은 처음부터 '전체'여야 한다. 아주 단순하고 기능이 거의 없더라도, 입력부터 출력까지 연결된 '''전체 흐름(Walking Skeleton)'''을 가장 먼저 확보하라. |
| Line 67: | Line 67: |
| === Principle 4: Continuous Wholeness (지속적인 전체성) === 개발의 모든 순간에 시스템은 "작동하는 전체"여야 한다. * [[BabySteps]]를 밟을 때마다 시스템이 파편화되지 않고 항상 하나의 온전한 상태를 유지하는지 확인하라. |
=== Principle 4: Differentiation over Assembly (조립이 아닌 분화) === 바깥에서 조각을 가져와 붙이지 말고, 안에서 나누어라. 거대한 클래스를 먼저 만들고, 그 내부가 복잡해지면 그때 클래스를 쪼개라. 이것이 조립(Assembly)과 분화(Differentiation)의 차이다. |
| Line 74: | Line 73: |
| === Example 1: Web Development === '''Assembly Way:''' 버튼 컴포넌트 완성 -> 입력 폼 완성 -> 서버 API 완성 -> 합체 시도. '''Rough Whole Way:''' 빈 페이지에 "주문하기" 버튼 하나만 만듦 -> 누르면 서버에 로그 찍힘 -> 확인 후 버튼 예쁘게 다듬기 -> 입력 폼 하나씩 추가. |
=== Example 1: IKEA Furniture Assembly === 나사를 한 번에 꽉 조이지 않고 모든 부품을 일단 걸어두는 것. 전체 수평과 구멍이 맞는지 확인한 후에 마지막으로 단단히 조이는 행위는 공학의 기본이다. |
| Line 78: | Line 76: |
| === Example 2: Complex Algorithm === 복잡한 추천 알고리즘을 만든다면, 먼저 "무조건 1번 상품 추천"이라는 엉성한 로직으로 전체 추천 엔진의 파이프라인을 구축한다. 그 파이프라인이 안정화되면 실제 알고리즘을 세분화하여 구현한다. |
=== Example 2: Web Dashboard === 민수는 왼쪽 상단 프로필 사진의 그림자 값부터 결정하려 하지만, 하나는 화면 전체에 텅 빈 박스 4개를 먼저 배치한다. 전체 레이아웃이 확정된 후에야 하나씩 진짜 컴포넌트로 채워 나간다. |
| Line 84: | Line 82: |
| === "Premature Hardening" (조기 경화) === 너무 일찍 라이브러리를 확정하거나, DB 스키마를 고정해버리는 것. * 엉성한 전체가 충분히 검증될 때까지는 '유연한 나사' 상태를 유지하라. |
|
| Line 85: | Line 87: |
| 엉성한 상태를 동료나 고객에게 보여주는 것에 대한 두려움. | 엉성한 상태를 보여주는 것에 대한 두려움. |
| Line 87: | Line 89: |
=== Losing Focus (방향 상실) === 전체만 잡다가 아무것도 완성하지 못하는 것. * 엉성한 전체를 잡은 후에는 반드시 [[StrongCenter]]부터 하나씩 세분화(Differentiate)해 나가야 한다. |
|
| Line 98: | Line 96: |
| * '''[[DirectPath]]''' - 전체 구조를 먼저 보면 불필요한 우회로를 더 쉽게 발견할 수 있습니다. ''설계적 측면'' | * '''[[DesigningInTheRun]]''' - 느슨한 나사 상태에서 현장을 보며 세부 수치를 조정합니다. ''실천'' |
| Line 102: | Line 100: |
| * 프로젝트 시작 직후부터 시스템의 전체적인 흐름을 누구나 확인할 수 있다. * 세부 사항이 바뀌어도 전체 구조가 흔들리지 않는다. * "조립" 단계에서 발생하는 예상치 못한 버그가 획기적으로 줄어든다. * 시스템이 자라나는 과정이 마치 안개가 걷히며 풍경이 선명해지는 것처럼 느껴진다. |
* 프로젝트 초기에 전체적인 레이아웃과 데이터 흐름이 이미 잡혀 있다. * 세부 사항이 바뀌어도 "아, 그럼 그 박스 내용만 바꾸면 되겠네"라고 가볍게 대응한다. * "조립" 단계에서 발생하는 "안 맞네"라는 당혹감이 사라진다. * 코딩 과정이 가구 조립처럼 리드미컬하고 즐거워진다. |
| Line 109: | Line 107: |
| '''생명은 조각들의 합이 아니라, 전체가 스스로를 나누며 피어나는 과정이다.''' | '''패턴과 원칙은 코드에만 갇혀 있지 않다. 그것은 사물이 만들어지는 보편적인 원리다.''' |
| Line 111: | Line 109: |
| 퍼즐 조각을 맞추는 개발자가 되지 말고, 나무를 키우는 정원사가 되라. 엉성한 씨앗 속에 이미 거대한 숲의 지도가 들어 있다. 전체를 먼저 세우고 그 안에서 디테일을 꽃피워라. 그것이 복잡함 속에서도 우아함을 잃지 않는 비결이다. | IKEA 가구를 조립할 때나, 대규모 시스템을 설계할 때나 진리는 같습니다. 전체를 먼저 살피고, 나사를 느슨하게 유지하며, 모든 것이 조화로울 때 비로소 단단히 매듭지으십시오. 장인의 손길은 언제나 전체에서 부분을 향합니다. |
RoughWholeFirst
주니어 개발자들을 위한 패턴 언어 - 완벽한 조각을 맞추기보다 엉성한 전체에서 시작하여 세분화하는 법
Contents
The Story 1: The Dashboard Sketch (Programming)
두 명의 개발자, 민수와 하나가 '대시보드 화면'을 개발하고 있다.
민수의 방식 (The Jigsaw Puzzle): 민수는 완벽주의자다. 그는 왼쪽 상단의 '사용자 프로필' 컴포넌트부터 완벽하게 만들기 시작했다. 아바타 이미지의 그림자 값, 테두리 두께 등을 이틀 내내 공들여 다듬었다. 하지만 정작 대시보드 전체를 조립했을 때, 프로필 컴포넌트가 너무 커서 다른 차트들이 들어갈 자리가 없음을 깨달았다. 민수는 정성껏 만든 조각을 다시 깎아내야 했다.
하나의 방식 (The Sketch): 하나는 화가처럼 시작했다. 먼저 화면 전체를 텅 빈 박스 4개로 채워 전체 구도를 잡았다. 그 안의 여백과 배치가 조화로운지 먼저 확인한 후, 하나씩 진짜 코드로 교체해 나갔다. 하나는 단 한 번도 조각을 깎아낼 필요가 없었다. 시스템은 처음부터 '전체'로서 존재했고, 시간이 흐름에 따라 더 정교하게 분화(Differentiation)되었을 뿐이다.
The Story 2: The IKEA Table (Ordinary Life)
민수와 하나는 집에서 사용할 식탁을 함께 조립하고 있다.
민수의 조립 (The Tight Bolt): 민수는 매뉴얼대로 단단히 고정하고 싶어 한다. 그는 첫 번째 다리를 프레임에 끼우고 나사를 끝까지 꽉 조였다. "흔들리지 않게 해야지." 하지만 네 번째 다리까지 조립하고 상판을 덮으려 하자, 구멍이 미세하게 어긋나 있었다. 나사를 너무 일찍 꽉 조여버린 탓에 프레임이 유연하게 움직이지 않았고, 민수는 상판을 끼우기 위해 모든 나사를 다시 풀어야 했다.
하나의 조립 (The Soft Fastening): 하나는 다르게 행동했다. 나사를 손으로만 살짝 돌려 '느슨하게' 걸어두었다. 다리들은 조금씩 흔들거렸지만 덕분에 여유 공간(Buffer)이 생겼다. 상판을 얹자 느슨한 다리들이 조금씩 움직이며 상판 구멍에 완벽하게 들어맞았다. 모든 조각이 제 자리를 잡은 것을 확인한 후에야 하나는 모든 나사를 단단히 조였다. 기예는 '느슨한 전체'에서 시작해 '단단한 부분'으로 나아가는 것임을 하나는 알고 있었다.
Context
OrganicGrowth를 실천하며 시스템을 구축하고 있다. StrongCenter를 잡았지만, 그 중심에서 어떻게 확장을 시작해야 할지 고민 중이다. 코딩뿐만 아니라 가구를 조립하거나 글을 쓰는 등 무언가 구조를 만드는 모든 상황에 해당한다.
일상적인 상황:
- 작은 기능 하나는 완벽한데, 전체를 합치면 어색하거나 아키텍처가 꼬인다.
- "일단 이것부터 제대로 만들고 다음으로 넘어가자"는 유혹을 느낀다.
- 프로젝트 초반에 세부 사항(UI 픽셀, 특정 알고리즘 최적화)에 너무 많은 시간을 쓴다.
- 전체 그림을 보지 못해 나중에 큰 구조적 변경을 해야 하는 상황이 발생한다.
Problem
부분을 너무 일찍 완벽하게(Hardened) 만들면, 전체적인 조화(Wholeness)를 맞추기 위한 유연성이 사라진다.
유연성 부족: 조각이 너무 일찍 굳어지면, 나중에 전체 구조에 맞춰 수정하기가 매우 힘들어진다.
재작업의 비용: IKEA 테이블처럼, 나중에 전체가 안 맞으면 처음부터 다 풀어야 한다.
피드백 지연: "진짜 전체 모습"을 프로젝트 후반부에나 볼 수 있게 되어, 치명적인 구조적 결함을 너무 늦게 발견한다.
Solution
완벽한 부분보다 엉성하더라도 "전체 구조"를 먼저 만들고, 나사를 느슨하게 조인 상태(Soft Fastening)로 세부 사항을 점진적으로 분화시켜라.
Christopher Alexander는 생명체의 발달이 세포들을 조립하는 것이 아니라, 배아라는 전체가 점점 나누어지며(Differentiation) 장기를 만드는 과정임을 강조했다.
Principle 1: Meta-Planning with TODO.md (메타플래닝)
코딩을 시작하기 전, 반드시 TODO.md 파일을 만들어 작업의 전체 지도를 그리십시오. 해야 할 일들을 나열하고 우선순위를 정하는 행위 자체가 시스템의 전체성을 파악하는 첫 번째 분화 과정입니다.
Principle 2: Soft Fastening (나사를 느슨하게 유지하기)
처음부터 코드를 '확정' 짓지 마라.
- 인터페이스는 만들되 내부 구현은 가짜(Mock)로 채워라.
- 클래스 사이의 관계를 확정하기 전까지는 결합을 느슨하게 유지하라.
- "나중에 바뀔 수 있다"는 여백을 남겨두어야 전체적인 균형을 맞출 수 있다.
Principle 3: Embryonic Growth (배아적 성장)
시스템은 처음부터 '전체'여야 한다. 아주 단순하고 기능이 거의 없더라도, 입력부터 출력까지 연결된 전체 흐름(Walking Skeleton)을 가장 먼저 확보하라.
Principle 4: Differentiation over Assembly (조립이 아닌 분화)
바깥에서 조각을 가져와 붙이지 말고, 안에서 나누어라. 거대한 클래스를 먼저 만들고, 그 내부가 복잡해지면 그때 클래스를 쪼개라. 이것이 조립(Assembly)과 분화(Differentiation)의 차이다.
Real Examples
Example 1: IKEA Furniture Assembly
나사를 한 번에 꽉 조이지 않고 모든 부품을 일단 걸어두는 것. 전체 수평과 구멍이 맞는지 확인한 후에 마지막으로 단단히 조이는 행위는 공학의 기본이다.
Example 2: Web Dashboard
민수는 왼쪽 상단 프로필 사진의 그림자 값부터 결정하려 하지만, 하나는 화면 전체에 텅 빈 박스 4개를 먼저 배치한다. 전체 레이아웃이 확정된 후에야 하나씩 진짜 컴포넌트로 채워 나간다.
Common Pitfalls
"Premature Hardening" (조기 경화)
너무 일찍 라이브러리를 확정하거나, DB 스키마를 고정해버리는 것.
- 엉성한 전체가 충분히 검증될 때까지는 '유연한 나사' 상태를 유지하라.
"It looks unprofessional" (너무 허술해 보여요)
엉성한 상태를 보여주는 것에 대한 두려움.
- "이것은 미완성 조각이 아니라, 자라나고 있는 살아있는 전체"임을 설명하라.
Connection to Other Patterns
OrganicGrowth - RoughWholeFirst는 유기적 성장이 일어나는 구체적인 방식(분화)을 설명합니다. 메커니즘
StrongCenter - 엉성한 전체 안에서 가장 먼저 세분화해야 할 지점이 바로 강한 중심입니다. 우선순위
WorkingFirst - 엉성하더라도 작동해야 진정한 전체라고 할 수 있습니다. 전제 조건
DesigningInTheRun - 느슨한 나사 상태에서 현장을 보며 세부 수치를 조정합니다. 실천
Signs of Success
- 프로젝트 초기에 전체적인 레이아웃과 데이터 흐름이 이미 잡혀 있다.
- 세부 사항이 바뀌어도 "아, 그럼 그 박스 내용만 바꾸면 되겠네"라고 가볍게 대응한다.
- "조립" 단계에서 발생하는 "안 맞네"라는 당혹감이 사라진다.
- 코딩 과정이 가구 조립처럼 리드미컬하고 즐거워진다.
The Ultimate Insight
패턴과 원칙은 코드에만 갇혀 있지 않다. 그것은 사물이 만들어지는 보편적인 원리다.
IKEA 가구를 조립할 때나, 대규모 시스템을 설계할 때나 진리는 같습니다. 전체를 먼저 살피고, 나사를 느슨하게 유지하며, 모든 것이 조화로울 때 비로소 단단히 매듭지으십시오. 장인의 손길은 언제나 전체에서 부분을 향합니다.
CategoryPatternLanguage CategoryProgramming CategoryDesign CategoryAgile CategoryArchitecture