TwoWorlds

주니어 개발자들을 위한 패턴 언어 - 문제 공간과 해결 공간을 분리하여 올바른 문제를 해결하는 방법

The Story 1: The Wrong Search Engine (Programming)

두 명의 개발자, 민수와 하나가 '주문 내역 조회' 기능을 개발하고 있다.

민수의 접근 (The Premature Solution): 민수는 요구사항을 듣자마자 구현을 시작했다. "주문 내역을 쉽게 찾아야 하니까 강력한 검색 엔진이 필요해." 그는 2주 동안 엘라스틱서치(Elasticsearch)를 연동하고 10개가 넘는 복잡한 필터링 옵션을 구현했다. 하지만 데모 날, 사용자의 피드백은 예상 밖이었다. "우리는 복잡한 검색을 원한 게 아니라, 그냥 '지난번 샀던 거 다시 주문하기' 버튼 하나가 필요했어요." 민수는 해결 공간에 너무 빨리 뛰어든 나머지, 잘못된 문제를 해결하고 말았다.

하나의 접근 (The Problem Explorer): 하나는 코딩 전에 사용자에게 물었다. "왜 주문 내역을 찾고 싶어 하시나요?" (문제 공간 탐색) "대부분 지난번에 샀던 비품을 다시 주문하려는데, 품목 이름을 잊어버려서 그래요." 하나는 진짜 문제를 발견했다. 그녀는 복잡한 검색 기능을 만드는 대신, '최근 주문 목록'과 '재주문 버튼'을 만들었다. 하나는 단 하루 만에 사용자를 만족시켰다. 문제 공간을 충분히 이해하는 것이 가장 빠른 해결책임을 하나는 알고 있었다.

The Story 2: The Travel Plan (Ordinary Life)

민수와 하나는 이번 여름 휴가 계획을 세우고 있다.

민수의 계획 (The How First): 민수는 비행기 티켓 예매 사이트부터 열었다. "지금 삿포로행 비행기가 제일 싸네! 일단 이거부터 예약하자." 민수는 '어떻게(How)' 이동할지에 매몰되어 티켓을 끊었다. 하지만 나중에 보니 하나는 이번 휴가 때 따뜻한 바다에서 서핑을 하고 싶어 했다. 민수가 예약한 삿포로는 하나가 원하던 '무엇(What)'과 전혀 맞지 않았고, 결국 수수료를 내고 티켓을 취소해야 했다.

하나의 계획 (The What First): 하나는 민수에게 먼저 물었다. "이번 휴가 때 우리가 진짜 하고 싶은 게 뭐야? 휴식이야, 아니면 액티비티야?" 두 사람은 충분한 대화 끝에 '따뜻한 나라에서 스쿠버다이빙 하기'라는 목적지를 정했다. 목적(Problem Space)이 명확해지자, 비행기 노선과 숙소(Solution Space)는 자연스럽게 결정되었다. 무엇을 원하는지 결정하는 세계와 어떻게 달성할지 결정하는 세계는 분리되어야 함을 하나는 알고 있었다.

Context

당신은 새로운 기능을 개발하고 있다. 요구사항을 받았고, 머릿속에 이미 구현 방법이 떠오른다. 코드를 어떻게 짜야 할지, 어떤 라이브러리를 쓸지, 어떤 알고리즘을 적용할지...

일상적인 상황:

• 요구사항 문서를 받자마자 코딩을 시작한다.
• "이건 간단해, 그냥 X를 추가하면 돼"라고 생각한다.
• 구현하다가 요구사항이 애매해서 추측으로 진행한다.
• 완성 후 "이게 아니었는데..."라는 피드백을 받는다.

Problem

많은 프로그래밍 오류는 사고 과정에서 "문제 공간"과 "해결 공간"을 너무 일찍 섞는 데서 비롯된다.

• Premature Solution: 문제를 이해하기 전에 해결책부터 생각하면, 경험의 함정에 빠져 진짜 목표를 놓치게 됩니다.

• 잘못된 문제 해결의 비용: 2주간 개발한 기능이 무용지물이 되는 것은 엄청난 자원 낭비입니다.

• 혼란스러운 대화: "왜(Why)"를 묻는 사람과 "어떻게(How)"를 말하는 사람이 섞이면 의사소통이 불가능해집니다.

Solution

문제 공간을 충분히 탐색하라. 그다음에 해결 공간으로 이동하라.

두 세계를 의식적으로 분리하면 더 간단하고 올바른 해결책을 찾을 수 있습니다.

Principle 1: Stay in Problem Space Longer

해결책을 제안하고 싶은 충동을 억제하십시오.

• 문제를 다른 말로 표현해 보십시오.
• "왜 이것이 필요한가?"를 5번 물어보십시오.
• 진짜 목표(Goal)가 무엇인지 정의될 때까지 키보드에서 손을 떼십시오.

Principle 2: Define Before Solving

Gerald Weinberg의 조훈: "문제가 무엇인지 정의하지 않고는 문제를 해결할 수 없다."

• 현재 상태(Current)와 원하는 상태(Desired) 사이의 간격(Gap)을 명확히 문장으로 적어보십시오.

Principle 3: Separate Thinking Modes

의식적으로 두 모드 사이를 전환하십시오.

• 문제 모드 (Why & What): 가치와 목표에 집중합니다.

• 해결 모드 (How): 기술과 구현에 집중합니다.

한 번에 하나의 모드만 사용하십시오. 섞지 마십시오.

Principle 4: Maximize Work Not Done

Agile 원칙: "하지 않아도 되는 일을 최대화하라." 문제 공간을 깊이 탐색하면, 종종 구현할 필요가 없는 기능이나 훨씬 간단한 대안을 발견하게 됩니다.

Practical Patterns

Pattern 1: The Five Whys

근본 원인을 찾기 위해 "왜?"를 반복합니다.

Pattern 2: Problem Statement Template

"[누가]의 [어떤 상황]에서 [현재 문제]가 발생하여 [어떤 영향]을 미친다. 우리는 [원하는 결과]를 달성하고 싶다."

Connection to Other Patterns

• WorkingFirst - 문제를 이해한 후, 가장 간단한 작동하는 해결책부터 시작하십시오. 순서

• StrongCenter - 문제의 핵심을 파악하는 것은 시스템의 강한 중심을 찾는 것과 같습니다. 본질

• DataAsFoundation - 문제 공간을 탐색하면 종종 올바른 데이터 구조가 보입니다. 발전

• DetectiveWork - 버그 조사도 문제 공간을 탐색하는 과정입니다. 사고방식

Signs of Success

• 코딩 전에 질문이 많아진다.
• 결과적으로 만들어지는 코드가 이전보다 훨씬 단순해진다.
• 팀원들과 문제 정의에 대해 빠르게 합의에 도달한다.
• 재작업(Rework) 비율이 현저히 줄어든다.

The Ultimate Insight

문제 공간에서 시간을 쓰는 것은 투자이며, 해결 공간에서 잘못된 것을 만드는 것은 낭비입니다.

두 세계를 분리하십시오. 문제를 충분히 탐색하고, 그 다음에 해결책을 만드십시오. 그것이 단순히 시간을 아끼는 것을 넘어, '올바른 것'을 만드는 유일한 길입니다.

CategoryPatternLanguage CategoryProgramming CategoryProblemSolving CategoryDesign