TwoWorlds

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

TwoWorlds.pdf

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

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

The Premature Solution

문제를 듣자마자 해결책이 떠오른다. 이것은 경험의 표시처럼 느껴진다. "나는 이걸 어떻게 만들지 알아!" 하지만 이것은 함정이다. Gerald Weinberg는 "Are Your Lights On?"에서 말한다: 문제가 무엇인지 정의하지 않고는, 문제를 해결할 수 없다. 하지만 우리는 정의하기 전에 해결하려 한다.

The Cost of Wrong Problems

잘못된 문제를 해결하는 것은 자원의 엄청난 낭비다. 2주간 개발한 기능이 무용지물이 되는 것은 단순히 시간의 손실을 넘어 팀의 사기와 신뢰에 타격을 줍니다.

Two Worlds Confused

* 문제 공간 (Problem Space): 무엇을 해결할 것인가? (사용자가 진짜 원하는 것, 목표, 사용 상황) * 해결 공간 (Solution Space): 어떻게 구현할 것인가? (데이터 구조, 알고리즘, 라이브러리, 성능 최적화) 이 두 세계는 다른 사고 방식을 요구한다. 하지만 우리는 이것들을 너무 쉽게 섞어버린다.

Solution

문제 공간을 충분히 탐색하라. 그다음에 해결 공간으로 이동하라. 두 세계를 의식적으로 분리하면, 더 나은 해결책을 찾고, 종종 훨씬 더 간단한 해결책을 찾게 됩니다.

Principle 1: Stay in Problem Space Longer

해결책을 제안하고 싶은 충동을 억제하십시오. 문제 공간에 머물면서 깊이 탐색하십시오. * 문제를 다른 말로 표현해 보십시오. * 핵심 요소와 제약 사항이 무엇인지 파악하십시오. * George Polya의 접근처럼, 모르는 것이 무엇인지 명확히 하십시오.

Principle 2: Define Before Solving

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

도요타의 기법: 문제의 근본 원인을 찾기 위해 "왜?"를 5번 물으십시오.

Pattern 2: Problem Statement Template

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

Pattern 3: Solution Space Exploration

문제를 이해한 후, 해결 공간에서 여러 옵션을 탐색하고 트레이드오프를 비교하십시오.

Common Pitfalls

"But I Know the Solution!"

경험이 많아질수록 패턴을 빨리 인식하지만, 이것이 함정이 될 수 있습니다. 5분만 더 투자해서 문제를 확인하십시오.

"We Need to Move Fast!"

잘못된 것을 빨리 만드는 것은 결국 더 느린 길입니다. 올바른 방향으로 천천히 가는 것이 더 빠릅니다.

Connection to Other Patterns

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

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

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

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

• TinyExperiment - 문제가 불명확하면 작은 실험으로 문제를 명확히 하십시오. 탐색

Signs of Success

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

For Teachers and Mentors

주니어가 바로 구현을 시작하려 할 때 "잠깐, 코딩 전에 이 문제를 설명해 줄 수 있어?"라고 멈추게 하십시오. "왜 사용자가 이것을 원할까?", "다른 방식으로 같은 목표를 달성할 수 있을까?"를 질문하여 두 세계를 구분하게 하십시오.

The Ultimate Insight

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

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

CategoryPatternLanguage CategoryProgramming CategoryProblemSolving CategoryDesign