기술보다 문제 정의가 성패를 가른다
소프트웨어를 만드는 도구들이 너무 강력해져서 이제 만드는 행위 자체가 더 이상 어려운 부분이 아니다. Cursor가 코드를 쓴다. Bolt가 앱의 뼈대를 잡는다. Lovable이 UI를 생성한다. Claude Opus 4.6이 아키텍처를 추론한다. 원하는 것을 설명하면 — 종종 몇 분 안에 — 작동하는 무언가가 나타난다.
기술보다 문제 정의가 성패를 가른다
"AI로 만들기" 시리즈 5편
지난 2년 사이 놀라운 일이 일어났다.
소프트웨어를 만드는 도구들이 너무 강력해져서 이제 만드는 행위 자체가 더 이상 어려운 부분이 아니다. Cursor가 코드를 쓴다. Bolt가 앱의 뼈대를 잡는다. Lovable이 UI를 생성한다. Claude Opus 4.6이 아키텍처를 추론한다. 원하는 것을 설명하면 — 종종 몇 분 안에 — 작동하는 무언가가 나타난다.
이건 해방감을 줘야 한다. 많은 사람에게 실제로 그렇다.
하지만 이 진보 안에 숨어 있는 문제가 있다. 만드는 비용이 거의 0에 가까워지면서 다른 무언가가 병목이 됐다 — 항상 거기 있었지만, 만드는 것이 어려울 때는 무시하기 쉬웠던 것.
이제 병목은 이것이다: 무엇을 만들고 싶은지 명확하게 정의할 수 있는가?
기술적으로가 아니다. 코드로가 아니다. 평범한 언어로. 강력한 도구가 — 혹은 팀에 막 합류한 똑똑한 사람이 — 스무 개의 명확화 질문을 하지 않고도 실행할 수 있을 만큼 충분히 정밀하게.
그 능력은 들리는 것보다 어렵다. 그리고 AI에서 놀라운 결과를 얻는 사람과 계속 답답한 결과를 얻는 사람을 가르는 것이 바로 이것이다.
왜 모호한 입력이 모호한 출력을 만드는가
문제 정의의 정밀도와 AI가 만들어주는 것의 품질 사이에는 직접적인 관계가 있다.
이건 AI에만 국한된 게 아니다. 모든 창의적이거나 기술적인 협업에서 사실이다. 디자이너를 고용하고 "멋있게 만들어줘"라고 하면 당신의 멋있음이 아닌 그들의 해석을 받게 된다. 개발자에게 "주문을 처리하는 걸 만들어줘"라고 브리핑하면 예상치 못한 방식으로 주문을 처리하고 — 당신이 당연하다고 생각한 방식으로는 처리하지 않는 시스템을 받게 된다.
AI는 이 역학을 증폭시킨다. 언어 모델은 공백을 채우는 데 탁월하다 — 하지만 채우는 공백은 당신의 특정 맥락, 당신의 사용자, 당신의 제약, 당신의 성공 정의가 아닌 학습된 모든 것의 패턴 매칭을 기반으로 한다.
모호한 문제를 AI에게 주면, AI는 당신이 실제로 가진 문제와는 약간 다른 문제에 대한 자신감 있고 잘 구조화된 답을 준다.
그리고 여기에 함정이 있다. 맞아 보인다. 맞게 들린다. 표면 검사를 통과한다. 그 위에 구축하기 시작한다 — 그리고 세 단계 후에 기반이 어긋났다는 걸 깨닫는다.
잘 정의된 문제가 실제로 어떻게 생겼는가
대부분의 사람들은 문제를 정의하는 것이 더 긴 설명을 쓰는 것을 의미한다고 생각한다. 그렇지 않다. 길이는 정밀도가 아니다.
잘 정의된 문제에는 네 가지 구성 요소가 있다:
구체적인 상황 — "영업 프로세스를 자동화하고 싶어"가 아니라 "잠재 고객이 응답하지 않았을 경우 영업 통화 48시간 후 우리가 논의한 내용을 기반으로 개인화된 후속 이메일을 자동으로 보내고 싶어."
구체적인 사용자 — "고객들"이 아니라 "지난 30일 이내에 가입했고 아직 첫 번째 데이터 소스를 연결하지 않은 소규모 사업주들."
구체적인 제약 — 경계는 무엇인가? 할 수 없는 것은? 항상 해야 하는 것은? "주당 한 번 이상 후속 발송을 해서는 안 된다"는 제약이다. "자동화된 것처럼 느껴지지 않고 개인적으로 느껴져야 한다"는 제약이다.
구체적인 성공 조건 — 어떻게 작동했다는 걸 알 수 있는가? "후속 이메일의 응답률이 높아진다"는 성공 조건이다. "주당 두 시간을 절약해준다"는 성공 조건이다. "우리를 당황스럽게 만들지 않는다"도 성공 조건이다.
네 가지 없이는 방향은 있지만 정의는 없다. 그리고 방향은 구축하기에 충분하지 않다.
전과 후: 같은 목표, 다른 결과
실제 예시로 구체적으로 만들어보자.
모호한 버전: "팀이 고객 불만을 관리하는 데 도움이 되는 도구를 만들어줘."
무언가를 만들어낼 것이다. 인상적으로 보일 수도 있다. 하지만 "고객 불만 관리"가 티켓 시스템, AI 자동 응답기, 분류 도구, 대시보드, 에스컬레이션 워크플로우, 또는 스무 가지 다른 것을 의미할 수 있기 때문에 거의 확실히 진짜 문제를 놓칠 것이다.
정밀한 버전: "우리는 매주 이메일로 약 50건의 고객 불만을 받는다. 현재 팀이 각각을 수동으로 읽고 인간 응답이 필요한지 단순 확인만 필요한지 결정하고 적절한 담당자에게 배정한다. 이게 하루에 약 3시간이 걸린다. 수신 불만 이메일을 읽고 긴급도(긴급 / 표준 / 참고)로 분류하고 인간 검토를 위한 첫 번째 응답 이메일 초안을 작성하고 카테고리에 따라 적절한 팀원에게 라우팅하는 도구가 필요하다. 자동으로 아무것도 보내서는 안 된다 — 모든 것이 발송 전 인간 승인을 거쳐야 한다."
같은 목표. 완전히 다른 브리핑. 두 번째는 개발자, AI 에이전트, Bolt나 n8n을 가진 비기술 빌더 누구에게나 건네도 실제로 문제를 해결하는 무언가를 만들어낼 것이다.
차이는 기술 능력이 아니다. 사고 능력이다.
왜 이게 어렵고 (왜 대부분의 사람이 건너뛰는가)
문제를 정밀하게 정의하는 것은 불편한 작업이다. 모든 답을 알기 전에 결정을 내리도록 강요한다. 만들고 있다고 깨닫지 못했던 가정들을 표면화한다. 자신이 가졌다고 생각한 문제가 실제 문제가 아닐 수 있다는 걸 드러낸다.
대부분의 사람이 건너뛰는 이유:
만드는 것은 진전처럼 느껴진다. 정의하는 것은 지연처럼 느껴진다. Cursor나 Lovable을 열고 원하는 것을 설명하는 순간, 무언가가 일어나고 있다. 화면이 채워진다. 생산적으로 느껴진다. 어떤 도구도 건드리기 전에 30분을 문제 정의 작성에 쓰는 것은 낭비된 시간처럼 느껴진다 — 특히 도구들이 이렇게 빠를 때.
이건 정확히 반대다. 10분의 명확한 문제 정의가 잘못된 것에 대한 수시간의 반복을 절약한다. 도구는 빠르게 만든다; 비용은 만든 것을 맞닥뜨리고, 정확하지 않다는 것을 깨닫고, 다시 만드는 것이다.
모호함이 더 안전하게 느껴지기도 한다. 모호한 브리핑은 결과가 너그럽게 해석될 여지를 남긴다. 구체적이지 않으면 구체적으로 틀릴 수 없다. 정밀도는 헌신을 요구한다 — 그리고 헌신은 실제로 원하는 것에 대한 자신감을 요구한다.
그리고 진짜 문제는 종종 불편하다. 문제를 정밀하게 정의하는 과정이 진짜 문제가 생각했던 것이 아님을 드러낼 때가 있다. "더 나은 불만 관리 도구가 필요해"는 때때로 "지원 인력이 너무 부족해"를 의미한다. "보고를 자동화해야 해"는 때때로 "우리가 실제로 무엇을 측정하려는지 모른다"를 의미한다. 정밀한 문제 정의는 기술적 문제보다 직면하기 더 불편한 조직적 진실을 표면화할 수 있다.
문제 정의 프레임워크
어떤 AI 도구도 열기 전에 이 다섯 가지 질문에 답하라. 답을 적어라 — 머릿속에만 두지 마라.
1. 현재 상황은 무엇인가? 지금 일어나고 있는 것을 구체적이고 명확한 용어로 설명하라. 가능한 곳에서 숫자로. 누가 무엇을, 얼마나 자주, 얼마나 오래 하는가?
2. 고통은 무엇인가? 구체적으로 무엇이 잘못되고, 너무 오래 걸리고, 너무 많은 비용이 들거나, 일어나야 하는데 일어나지 않는가? "비효율적이야"가 아니라 — 구체적인 비효율성은 무엇인가?
3. 누가 이것을 경험하는가? 구체적인 역할, 구체적인 맥락. "사용자들"이 아니라 — 어떤 사용자들이, 무엇을 하면서, 언제?
4. 이상적인 결과는 어떻게 생겼는가? 이게 완벽하게 해결된다면 구체적인 시나리오를 설명하라. 단계별로 걸어가라. 지금은 일어나지 않는 무엇이 일어나는가?
5. 하드 제약은 무엇인가? 변할 수 없는 것은? 솔루션이 항상 하거나 절대 하지 말아야 하는 것은? 기술적으로 맞는 솔루션도 여전히 받아들일 수 없게 만드는 것은?
다섯 가지 모두 명확하게 답할 수 있을 때 문제 정의가 있다. 그 정의가 브리핑이다. Claude Opus 4.6, Cursor, Bolt에 넣어라 — 돌아오는 것의 품질이 얼마나 극적으로 달라지는지 봐라.
도구는 전략이 아니다
Cursor, Claude, Bolt, Lovable이 설명할 수 있는 거의 모든 것을 만들 수 있는 시대에 경쟁 우위는 완전히 설명 품질로 이동했다. 사고 품질으로. 해결하는 문제에 대한 이해의 정밀도로.
이것은 2026년 가장 중요한 AI 기술이 프롬프트 엔지니어링이 아니라는 것을 의미한다. 어떤 모델을 쓸지 아는 것이 아니다. API나 자동화 도구를 이해하는 것이 아니다.
도구를 집기 전에 문제에 대해 명확하게 생각하는 능력이다.
그 능력은 항상 중요했다. 모든 훌륭한 제품, 모든 성공적인 자동화, 모든 유용한 도구는 해결하려 하기 전에 문제를 깊이 이해한 누군가로부터 시작됐다.
변한 것은 증폭이다. 만드는 것이 느리고 비쌀 때, 다소 모호한 문제 정의도 여전히 유용한 무언가를 만들었다 — 빌드 프로세스의 마찰이 길을 따라 명확화를 강요했기 때문에. 이제 도구는 즉시 만든다. 모호함이 끝까지 유지된다. 잘못된 질문에 대한 빠르고 잘 실행된 답을 받게 된다.
이기는 빌더는 처음에 속도를 늦추는 사람들이다 — 정밀하게 정의하기 위해 — 그래서 빌드 내내 자신감 있게 빠르게 움직일 수 있다.
연습: 한 단락 브리핑
AI로 만들거나 자동화하고 싶었던 것을 하나 골라라. 진짜인 것 — 가상의 것이 아니라.
위 프레임워크의 다섯 가지 질문 모두에 답하는 한 단락을 써라. 구체적으로. 숫자를 사용해라. 실제 사용자를 명명하라. 실제 제약을 명명하라.
그리고 다시 읽어라. 스스로에게 물어라: 나를 만난 적 없고, 내 사업을 본 적 없는 사람이 이 설명만으로 내가 필요한 것을 정확히 만들 수 있는가?
답이 아니라면 — 계속 다듬어라. 작업은 다듬는 데 있다.
답이 예라면 — 도구를 열어라. 준비됐다.
더 깊이 배우고 싶다면
이 글은 문제 정의 레이어를 다뤘다. 송재희의 AI Development Guide는 더 깊이 들어간다 — 날카로운 문제 정의를 효과적인 프롬프트, 워크플로우, 완전한 AI 솔루션으로 변환하는 방법을 다양한 도메인과 사용 사례에 걸친 실제 예시와 함께 담고 있다.
📱 Apple Books ▶️ Google Play Books 🌐 전 플랫폼 구매 (Books2Read)
다음 편: "프롬프팅은 프로그래밍이다" — 날카로운 문제 정의가 생기면 원하는 결과를 일관되게 얻는 프롬프트로 변환하는 방법을 다룹니다.