Skip to content
Published on

문제를 정의하는 능력 — 잘못된 문제를 완벽히 푸는 실패를 피하는 법

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드✨Start Quiz
공유하기
Authors

완벽한 답이 쓸모없어지는 자리

구성한 예시입니다. 검색이 느리니 캐시를 넣어 달라는 요청이 팀에 들어옵니다. 두 주 뒤 캐시가 붙고 응답 시간 중앙값이 절반으로 줄고 지표는 초록이 됩니다. 그런데 불만은 그대로입니다. 느리다고 말한 사람들이 겪은 것은 평균적인 조회가 아니라 필터를 세 개 겹쳤을 때만 나오는 12초짜리 질의였고, 하필 그 구간은 캐시 적중률이 거의 0이었습니다.

여기서 잘못된 것은 실력이 아닙니다. 캐시는 잘 붙었습니다. 잘못된 것은 무엇을 고칠지였습니다. 그리고 이런 종류의 실패에는 고약한 성질이 하나 있습니다. 어설픈 답은 부족하다는 신호를 주지만 완벽한 답은 끝났다는 신호를 줍니다. 그래서 잘못 잡은 문제를 잘 풀수록 잘못은 더 오래 숨습니다.

이 능력이 비싼 쪽에 남는 이유

1편에서 검증을 비싸게 만드는 요인 네 가지를 정리했습니다. 암묵적 맥락, 지연된 결과, 판정 기준의 부재, 책임 귀속입니다. 문제 정의에 대 보면 네 개가 전부 걸립니다. 무엇이 맞는 문제인지 알려 주는 정답표는 없고, 잘못 잡았다는 사실은 대개 출시 뒤에 도착하고, 판단에 필요한 정보는 코드가 아니라 사람들에게 흩어져 있고, 결국 누군가 이름을 걸고 정해야 합니다.

Fred Brooks는 1986년 "No Silver Bullet"에서 이것을 더 세게 적었습니다. 소프트웨어 시스템을 만드는 일에서 가장 어려운 단일 부분은 무엇을 만들지 정확히 정하는 것이며, 잘못했을 때 결과물을 이만큼 망가뜨리는 부분도 없고 나중에 바로잡기 이만큼 어려운 부분도 없다는 것입니다.

40년 전 문장인데 생성이 싸진 지금 오히려 더 날이 섭니다. 만드는 속도가 빨라지면 잘못 잡은 문제에 도달하는 속도도 같이 빨라지기 때문입니다. 빠른 구현은 틀린 방향을 교정해 주지 않고, 틀린 방향으로 더 멀리 데려다줍니다.

요구는 대개 해결책의 모습으로 도착합니다

캐시를 넣어 달라는 말은 요구가 아니라 해결책입니다. 요청자는 자기가 겪은 불편을 이미 한 번 번역해서 가져옵니다. 그 번역은 선의로 이뤄지고, 요청자가 아는 범위 안에서만 이뤄집니다.

번역을 되돌리는 데는 질문 세 개면 대체로 충분합니다.

  • 이게 없으면 지금 무슨 일이 일어나나요. 이 질문이 증상을 꺼냅니다.
  • 언제부터 문제가 됐나요. 이 질문이 무엇이 변했는지를 꺼냅니다.
  • 이게 해결되면 무엇을 다르게 하시겠어요. 이 질문이 성공 판정을 꺼냅니다.

세 번째가 가장 많이 걸러냅니다. 답이 안 나오면 그 요청은 아직 문제가 아니라 바람입니다. 답이 나오면 그 답이 그대로 완료 조건이 됩니다.

주의할 것은 태도입니다. 이 질문들은 요청을 거절하려고 던지는 것이 아니라 정확히 받으려고 던지는 것이고, 그 차이는 말투가 아니라 그다음 행동에서 드러납니다. 되묻고 나서 아무것도 안 하면 다음부터는 아무도 답해 주지 않습니다.

만들지 않을 것을 먼저 적기

범위를 정하는 일은 대개 할 것의 목록으로 표현되고, 그 목록은 저절로 늘어납니다. 반대 방향이 훨씬 강합니다. 이번에 하지 않을 것을 적는 쪽입니다.

비목표를 적으면 세 가지가 생깁니다. 첫째, 논쟁이 앞으로 당겨집니다. 하지 않기로 한 항목을 보여 주면 반대가 지금 나오고, 지금 나온 반대는 싸게 처리됩니다. 개발이 끝난 뒤에 나오는 같은 반대는 비쌉니다. 둘째, 나중에 들어오는 요청을 판정할 기준이 생깁니다. 셋째, 자기 자신에게 브레이크가 됩니다.

규칙은 하나입니다. 비목표에는 이유를 붙입니다. 다국어는 안 한다고만 적지 말고, 첫 고객 두 곳이 모두 국내이고 문자열 분리는 나중에 해도 비용이 선형으로만 늘기 때문이라고 적습니다. 이유 없는 비목표는 다음 회의에서 뒤집힙니다.

문제 진술서 여섯 줄

문제 정의를 문서로 만들면 대개 길어지고, 길어지면 안 읽힙니다. 여섯 줄이면 충분합니다.

예시 — 문제 진술서 여섯 줄

증상:      필터 3개 이상 조합 시 검색 응답이 10초를 넘김. 하루 약 40건
영향:      해당 사용자가 검색을 포기하고 담당자에게 전화로 문의
성공 판정: 같은 조합의 95퍼센트 지점 응답이 3초 이하. 전화 문의 감소로 확인
비목표:    전체 검색 속도 개선. 지금 문제는 꼬리 구간이며 중앙값은 이미 충분
제약:      색인 스키마 변경은 다음 분기까지 불가
모르는 것: 이 조합을 쓰는 사용자가 몇 명인지, 언제부터 늘었는지

가장 자주 비는 칸은 마지막 줄입니다. 모르는 것이 비어 있는 문제 진술서는 대체로 조사가 덜 된 것입니다. 아는 것만 적힌 문서는 자신 있어 보이지만, 일정을 실제로 흔드는 항목은 언제나 그 문서에 없던 쪽입니다.

범위를 줄이는 것과 문제를 바꾸는 것

여기서 정직해야 할 부분이 있습니다. 문제를 다시 정의하는 능력은 오용하기 쉽습니다. 어려운 요구를 만났을 때 진짜 문제는 사실 다른 것이라고 선언하면서 풀기 쉬운 쪽으로 갈아타는 일이 실제로 자주 일어나고, 그건 문제 정의가 아니라 회피입니다.

구별하는 방법은 하나뿐입니다. 원래 요청자가 그 재정의에 동의하는지 확인하는 것입니다. 범위를 줄이는 것은 같은 문제를 작게 자르는 일이고, 자른 조각이 여전히 요청자의 증상을 건드립니다. 문제를 바꾸는 것은 다른 증상을 겨냥하는 일이고, 요청자는 결과물을 받고도 처음 겪던 일을 계속 겪습니다. 그래서 재정의는 반드시 요청자에게 되돌려 확인해야 하고, 그 확인이 빠지면 취향으로 방향을 튼 것입니다.

직접 해보기

이번 주에 지금 하고 있는 작업 하나를 골라 위 여섯 줄을 채워 보세요. 30분이면 됩니다. 채우다 막히는 줄이 나오면 그 줄이 물어봐야 할 사람과 질문을 알려 줍니다. 특히 성공 판정이 안 써지면, 그 작업은 지금 완료 조건 없이 진행되고 있는 것입니다.

  • 사고력 훈련소 — 문제를 내 말로 다시 쓰기와 시키지 않은 가정 지우기가 아홉 개의 수 안에 들어 있습니다. 진술서의 첫 줄과 비목표 줄이 하는 일과 같습니다.
  • 협업 RPG — 요청을 되묻는 선택이 관계에 어떤 값을 치르는지 몇 장면 뒤에 도착합니다. 되묻기는 공짜가 아니고, 이 도구는 그 비용을 시간차로 보여 줍니다.

안 통하는 경우도 적어 둡니다. 요청자가 자기 문제를 이미 정확히 아는 경우가 있습니다. 규제 대응, 계약서에 적힌 항목, 상위 시스템이 강제하는 인터페이스처럼 정의가 밖에서 확정된 일입니다. 여기에 문제 진술서를 붙이면 시간만 씁니다. 되묻기의 값어치는 요청자와 실행자 사이에 정보 격차가 있을 때 생깁니다.

이어서 읽기

비싸게 남는 기술 시리즈

참고 자료

  • No Silver Bullet: Essence and Accidents of Software Engineering — Fred Brooks, 1986 (전문) — 무엇을 만들지 정하는 일이 가장 어려운 단일 부분이고, 잘못했을 때 결과물을 가장 크게 망가뜨리며, 나중에 바로잡기가 가장 어렵다는 문장은 "Requirements refinement and rapid prototyping" 절에 있습니다. 2026-08-15 확인.
  • 되묻는 질문 세 개, 이유를 붙인 비목표, 문제 진술서 여섯 줄은 위 자료에 나오는 것이 아니라 이 글에서 정리한 절차입니다.
Discuss on Twitter • View on GitHub