노트

문제 공간과 해결 공간

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개 패턴을 정리하며 널리 퍼졌다.

  • 몰입 영역과 난이도 조절

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

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

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

  • 러버덕 디버깅

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

보기 옵션