자신이 원하는 것이 무엇인지 모르는 사람들

 AI에 대한 흔한 오해가 하나 있는 것 같다. AI는 맥락을 못 읽는다는 것이다.

 요즘 매일 LLM을 쓰면서 느끼는 건 아주 반대의 경우다. 나는 요즘 AI는 맥락을 꽤 잘 읽는다고 생각한다. (글을 쓰는 지금으로부터 2주 전에 GPT-6 Astra 모델이 배포되었다) 긴 문서를 던져줘도 흐름을 이해하고, 앞에서 나눈 대화를 기억하고, 상황에 맞는 톤으로 대답한다. 맥락을 잘 파악하는가? 는 더 이상 AI의 약점이 아닌 듯하다. 그러나 AI가 아무리 맥락을 잘 읽어도 해결되지 않는 것은, 바로 사용자 스스로가 뭘 원하는지 모를 때라고 생각한다.

 

 

 

수천 개의 요구사항

 요즘 서비스 기획 일을 하면서 클라이언트에게 요구사항을 받으면, 엑셀 시트로 오는 경우가 많다. 내가 투입되는 프로젝트는 수백 개, 많으면 수천 개의 행이 빼곡하게 채워져 있다. 아마도 AI에게 요청해서 뽑아냈을 문장들이다.

 

 형식은 아주 완벽하다. 그런데 내용을 읽어보면 참 뜬구름 잡는 이야기들이 거의 대부분이다. 그건 현장의 맥락이 포함되어 있지 않기 때문이라고 생각하는데, 현업에서 무엇을 하는지의 구체적인 정보가 담겨있지 않다. 주관 없이 나열된 말들이라는 느낌이 든다.

 

 AI에게는 클라이언트가 입력한 말만 전달됐기 때문이라고 생각한다. 프롬프트로 작성한 문장 뒤에 있는 배경, 실제 업무가 어떻게 돌아가는지, 누가 어떤 상황에서 불편함을 느끼는지. AI는 그걸 알 수가 없다. 클라이언트가 말해주지 않았기 때문이다. 더 근본적인 문제는, 클라이언트 본인도 자신이 무엇을 원하는지 모르는 경우가 많다는 것이다.

 

 

 

자기 업무를 모르는 사람들

 B2B 제품을 만드는 프로젝트를 하다 보면 이런 상황을 자주 만난다. 가령, 현행 업무의 불편함을 개선하고 싶으며, 비효율적인 부분을 없애고 싶다고 하신다. 그런데 조금만 들어가보면 정작 본인들의 현행 업무 프로세스가 제대로 정립되어 있지 않은 경우가 많다. 누가 어떤 일을 어떤 순서로 하는지, 어디서 시간이 오래 걸리는지, 왜 그렇게 하고 있는지가 문서로도 머릿속으로도 정리되어 있지 않은 상태이다.

 

 그러니 당연하게도 무엇이 불편한지를 스스로 알기 어려운 것 같다. 불편하다는 감각은 있는데, 그게 정확히 어디서 오는지는 모르시는 듯하다. 개선해야 한다는 건 아는데, 무엇을 어떻게 개선해야 하는지는 모르는 상태랄까?

 

 이 상태에서 제3자의 개입 없이 AI에게 요구사항을 정리해달라고 하면 어떻게 될까? AI는 일반적인 B2B 솔루션의 요구사항을 그럴듯하게 만들어준다. 그런데 그건 그 조직의 이야기가 아니며, 어디에나 있을 법한 이야기에 가깝다. 그래서 기획 단계에서는 현행 업무에 대한 컨설팅도 함께 진행하는 것이 바람직하다고 생각한다.

 

 

 

인수인계를 한다고 생각해 주세요

 이럴 때 나는 인터뷰를 한다. 여기서 주의할 점은, '요구사항' 을 정리해 달라거나 '페인포인트를 말해주세요' 라고 이야기하지 않는다. 그러면 정리 과정에서 담당자의 사고가 개입되어 오히려 역효과를 낳는다. 있는 그대로의, 날것의 정보가 필요하다. 그래서 이렇게 요청드린다.

 

'저에게 하루 일과를 어떻게 보내시는지 알려주세요. 신입사원한테 가르쳐준다고 생각하시고, 하나하나 다 설명해주세요.'

 

 요구사항을 물으면 이미 정리된 대답이 나온다. 그런데 그 대답은 대개 추상적이다. '업무 효율을 높이고 싶다' 거나 '의사결정에 도움이 되는 솔루션을 만들고 싶어요' 같은 말들이다. 반면 하루 일과를 묻기 시작하면 구체적인 이야기가 나오기 시작한다.

 

 예를 들면 어느 회사의 영업팀인데, 이 팀은 메일과 전화로 업무가 돌아가는 조직이다. 더 자세하게는, 회사에서 판매하는 제품을 이미 구매한 고객의 추가 발주나 유지보수를 최전방에서 대응하는 업무를 하는 곳이었다. 이 팀에서는 이러한 업무 절차를 시스템화하고 싶었고, 나는 이런 질문들을 드렸다.

 

 메일은 보통 어떻게 보내세요? 받는 사람은 누구인가요? 답이 안 오면 어떻게 하세요? 전화는 주로 누가 받나요? 담당자가 자리에 없으면 어떻게 되나요? 협업팀의 회신이 늦어질 때는요? 급한 건인지 아닌지는 어떻게 판단하세요?

 

 이런 아날로그적인 질문들을 계속 던진다. 그러다 보면 어느 순간 병목이 드러난다. 담당자가 자리를 비우면 아무도 그 업무를 이어받지 못한다든지, 메일 내용이 제각각이라 나중에 찾기 어렵다든지, 급한 건과 안 급한 건이 섞여서 우선순위가 엉킨다든지, 이런 건 요구사항 시트에는 절대 적혀있지 않다. 본인도 그게 문제인지 인식하지 못하고 계시니까. 그런데 대화를 통해 하나하나 되짚다 보면 스스로 알아차리신다.

 

 '아, 얘기하다 보니 생각났는데, 그게 제일 불편하네요.'

 

 

 

듣는다는 것, 그리고 기다린다는 것

 이 과정에서 가장 중요한 건 듣는 일이라고 생각한다. 기다리는 일이다.

 

 인터뷰를 하다 보면 상대방이 말을 멈추는 순간이 온다. 생각을 정리하고 계신 것이다. 이때 침묵을 견디지 못하고 다음 질문을 던지면, 그 사람이 막 떠올리려던 중요한 이야기가 사라져버린다.

 

 그래서 나는 일부러 기다리는 편이다. 어색한 침묵이 흐르더라도 그냥 둔다. 그러면 대부분 스스로 말을 이어가신다. 그리고 그때 나오는 이야기가 가장 중요한 경우가 많은 것 같다. 정리된 대답이 아니라, 방금 막 떠오른 진짜 이야기니까.

 

 적절한 타이밍에 적절한 질문을 던지는 것도 중요하다고 본다. 그게 빠를 수도 있고 늦을 수도 있다. 상대방이 흐름을 타고 있을 때는 끼어들지 않는다. 막혀 있을 때는 방향을 살짝 틀어주는 질문을 드린다. 이 리듬을 읽는 건 경험으로 쌓이는 감각인 것 같다.

 

 AI에게 고민을 털어놓는 것과 사람에게 털어놓는 건 다르다고 생각한다. AI는 즉시 답한다. 정리된 답을 준다. 그런데 사람은 다르다. 듣고, 기다리고, 상대방이 스스로 답에 도달할 때까지 옆에 있어준다. 그 과정에서 나온 답은 상대방의 것이 된다.

 

 

 

컨셉을 먼저 던지는 이유

 인터뷰를 충분히 하고 나면 나는 사용 시나리오를 쓴다. 그리고 화면 설계 초안을 잡는다. 그걸 클라이언트에게 보여드리며 이건 컨셉이라고 말씀드린다. 당연히 처음엔 신뢰하지 않으신다. 자기 업무를 완전히 이해하지도 못한 사람이 초안을 만들어왔다고 생각하시니까. 그 반응은 당연하다고 본다. 그래서 나는 이렇게 설명드린다.

 

 '이건 일반적인 소프트웨어 기획 방법론에 따라 작성한 메타데이터입니다. 여기에 도메인 지식이 반드시 반영되어야 하는데, 그건 클라이언트님만이 하실 수 있는 작업입니다. 다만 아무것도 없는 상태에서 시작하시는 것보다는, 이 초안을 놓고 여기서부터 무엇을 어떻게 수정해나갈지 접근하시는 게 훨씬 편하실 거에요.'

 

 이 방식이 효과적인 이유가 있는 것 같다. 사람은 무에서 유를 만드는 것보다, 있는 것을 고치는 걸 훨씬 잘하는 듯하다. '원하는 게 뭐예요?'라고 물으면 대답하지 못하시던 분도, 구체적인 화면을 보여드리면 '이건 아니에요, 저희는 이렇게 안 해요'라고 말씀하신다. 그 순간부터 진짜 요구사항이 나오기 시작한다.

 

 AI는 이걸 해줄 수 없다고 생각한다. 정확히는, AI도 초안을 만들 수는 있다. 그런데 그 초안을 놓고 상대방이 자기 생각을 꺼낼 수 있도록 대화를 이끄는 건 사람이 해야 하는 일인 것 같다.

 

 

 

원하는 걸 아는 것부터가 능력이다

 AI는 무엇이든 만들어준다. 요구사항 시트도, 기획서도, 화면 설계안도. 형식은 완벽하다

 

 문제는 내가 뭘 원하는지 모를 때다. 그럴 때 AI는 그럴듯한 평균값을 만들어준다. 어디에나 있을 법한 결과물이다. 그걸 그냥 사용하게 되면, 정작 우리 조직에 필요한 건 만들어지지 않는다. 그래서 여전히 사람이 해야 하는 일이 남아있다고 생각한다.

 

 듣는 일, 기다리는 일, 적절한 타이밍에 적절한 질문을 던지는 일. 그리고 상대방이 자기가 뭘 원하는지 스스로 알아차리도록 돕는 일.

 

이건 능력이라기보다 태도에 가까운 것 같다. 그리고 아직까지는, 사람만이 할 수 있는 일이라고 생각한다.