노트

문제 공간과 해결 공간

Problem Space and Solution Space

설계#architecture · 연결된 개념 5개

쉽게 말하면

문제 공간과 해결 공간은 병원에서 진단과 처방을 나누는 것과 같아요. 어디가 왜 아픈지 먼저 제대로 알아내야 엉뚱한 약을 지어 주는 일이 없어요.

비유가 깨지는 곳 진료와 달리 개발에선 '이 프레임워크로 하죠' 같은 처방이 먼저 튀어나오기 쉬워요. 문제 공간 단계에서는 기술 스택을 아예 꺼내지 않아야 문제를 잘못 풀거나 과잉 설계하는 일을 막아요.

문제 공간은 "무엇을 왜 풀어야 하는가"를, 해결 공간은 "어떻게 풀 것인가"를 다루는 영역이다. 둘을 나눠 생각하고, 문제를 충분히 이해한 뒤에 해결책으로 넘어가라는 것이 요점이다.

문제 공간

  • 사용자의 진짜 문제, 그 문제가 중요한 이유, 불편을 느끼는 상황, 업무 요구와 제약(시간·비용·정책)
  • 예: "회원가입 중간에 이탈한다", "모바일에서 버튼이 잘 안 눌린다"
  • 이 단계에서는 기술 스택이나 구현 방법을 이야기하지 않는다

해결 공간

  • UI 설계, 아키텍처, 기술 선택, API와 상태 관리 방식
  • 예: "가입을 단계별로 나눈다", "터치 영역을 44px 이상으로 키운다"(피츠의 법칙)

흔한 함정

문제 정의 없이 "일단 이 프레임워크로 만들죠"부터 시작하면 문제를 잘못 풀거나 과잉 설계가 된다. 문제는 그대로인데 코드만 늘어나는 상황이다.

  • 디버깅에서도 같다. 증상을 고치기 전에 문제를 정확히 정의한다(디버깅 문제 정의 5단계)
  • 도메인 주도 설계 (DDD)는 문제 공간의 언어와 구조를 해결 공간에 그대로 옮기려는 시도다
  • 필요하지 않은 해결책을 미리 만들지 않는다는 점에서 YAGNI와 통한다

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

  • 알고리즘 문제 풀이 접근법

    낯선 문제를 만났을 때 바로 코드를 쓰기보다 따르는 다섯 단계. 수학자 폴리아(George Pólya)의 『어떻게 문제를 풀 것인가』(*How to Solve It*)에서 이어지는 흐름이다.

  • 디자인 패턴

    반복해서 나타나는 설계 문제에 대한 검증된 해결 구조와 그 이름. 복사해 쓰는 완성 코드가 아니라 객체들이 협력하는 방식을 설명하는 어휘다. 1994년 이른바 GoF(Gang of Four, 네 명의 저자)의 책 『Design Patterns: Elements of Reusable Object-Oriented Software』가 23개 패턴을 정리하며 널리 퍼졌다.

  • 몰입 영역과 난이도 조절

    과제가 너무 쉬우면 지루하고 너무 어려우면 불안하다. 그 사이의 몰입 영역에서 실력이 가장 잘 는다.

  • 소프트웨어 공학의 법칙들

    소프트웨어 시스템과 팀, 의사결정에 반복해서 나타나는 경험칙들을 모아 부르는 말. 법칙이라고 부르지만 대부분 증명된 정리가 아니라 관찰과 격언이다. 판단할 때 떠올릴 이름표로 쓴다. 따로 노트를 둔 것은 링크로, 나머지는 한 줄로 적었다.

  • 러버덕 디버깅

    문제를 남에게(혹은 고무 오리에게) 말로 설명하다 보면 스스로 답을 찾게 되는 디버깅 방법.

보기 옵션