AI는 왜 매번 제대로 못 할까? 멍청해서가 아니라, 당신이 제대로 말하지 않아서다

먼저 당신도 십중팔구 겪어봤을 장면부터.

AI에게 뭔가를 만들어달라고 시키고, 기대에 부풀어 결과를 기다린다. 그런데 나온 물건이 당신이 생각했던 것과는 하늘과 땅 차이다. 당신이 한 마디 고치면 그게 한 군데 틀리고, 몇 번을 오가다 결국 짜증이 나서 속으로 한 마디 내뱉는다. “이 AI도 별거 없네.”

이 몇 달 나는 거의 매일 AI로 일을 하는데, 매일 이 함정에 빠졌다. 그런데 빠지고 또 빠지다 보니 생각이 바뀌었다. 좀 뼈아픈 규칙 하나를 발견했기 때문이다. 같은 요구사항인데, 말을 한 번 바꿔주니 한 번에 제대로 해냈다.

한두 번은 우연이지만, 여덟아홉 번이면 우연이 아니다. 나는 서서히 이 사실을 인정할 수밖에 없었다. AI가 틀리는 건, 거의 대부분 멍청해서가 아니라 내가 제대로 말하지 않아서다.

이건 신비주의가 아니라, 그 뒤에 아주 소박한 이치가 있다. 소박해서 좀 잔인할 정도의:

AI는 마음을 읽지 못한다. 당신이 ‘말한’ 대로 할 뿐, 당신이 ‘생각한’ 대로 하지 않는다.

당신 머릿속의 그 요구사항은 입체적이다—배경도 있고, 스스로도 의식하지 못한 기본 전제도 있고, ‘이건 당연한 거 아니야?’ 하는 상식 한 세트가 통째로 딸려 있다. 그런데 당신이 대화창에 쳐 넣은 그 한 문장은, 흔히 얇디얇은 한 겹 껍데기만 남는다. AI가 받은 건 그 껍데기고, 나머지는 스스로 추측하는 수밖에 없다. 맞게 추측하면 당신이 운이 좋은 거고, 틀리게 추측하면 당신은 오히려 멍청하다고 나무란다.

이걸 깨닫고 나서, 나는 더 이상 ‘어떤 AI가 더 똑똑한가’를 따지지 않게 됐다. 대신 훨씬 값진 걸 연마하기 시작했다. 머릿속의 그 입체적인 요구사항을, 온전하게 대화창으로 옮기는 법. 이 글은 그 방법의 전부다. 전부 그대로 베껴 쓸 수 있고, 재능이 필요한 비결 같은 건 한 줄도 없다.

그리고 이 얘긴 꼭 해야겠다. 이건 프로덕트 매니저에게 엄청난 희소식이다. 요구사항을 기술하는 것, 원래 PM의 밥벌이 실력이다. 예전엔 요구사항을 개발자에게 말했고, 지금은 AI에게 말한다—차이라면, 개발자는 경험으로 당신이 안 한 말을 채워주고 되물어까지 오지만, AI는 더 말을 잘 듣고 더 ‘고지식’해서, 당신이 말한 만큼만 한다는 것뿐이다. 그러니 AI를 상대할 땐, 개발자에게 할 때보다 딱 한 뼘만큼 더 명확하게 말해야 한다. 그 딱 한 뼘이, 문턱이자 분수령이다.

AI가 한 번에 제대로 해내는 요구사항에는, 다섯 개의 부품이 있다

내가 ‘제대로 말했던’ 요구사항들을 뜯어보니, 늘 다섯 가지가 갖춰져 있었다. 어느 하나가 빠지면, AI는 바로 그 자리에서 나 대신 결정을 내려버렸다.

매번 다섯 가지를 다 쓰고 팔고문처럼 만들 필요는 없다. 하지만 마음속엔 이 다섯 개의 칸이 있어야 한다—보내기 전에 한 번 훑어서, 어느 칸이 비었는지 보라. 비어 있는 그 자리에서 AI가 제멋대로 결정한다.

부품 하나: 무엇을 원하는가—먼저 명사를 정확히 말하라

가장 기본이고, 가장 얼렁뚱땅 넘어가기 쉽다.

“사용자 관리하는 거 하나 만들어줘”라고 말하면, 이 ‘거’가 뭘까? 페이지 하나? 표 하나? 백오피스 한 세트 통째로? AI는 그중 하나를 골라 추측하는 수밖에 없다.

이렇게 바꿔보자. “사용자 목록 페이지 하나, 표 하나, 프로필 사진·이름·이메일·가입 시각·상태를 표시.” — 그러면 어디서부터 손댈지 바로 안다.

비결은 한 마디다. ‘거’ ‘기능’ ‘모듈’ 같은 뜬 말을, 구체적인 명사로 바꿔라. 페이지, 표, 버튼, 폼, 차트, 팝업. 그게 대체 ‘뭔지’를 말할 수 있어야, AI가 받아낸다.

부품 둘: 누구에게, 왜—이 고리가 가장 빠뜨리기 쉽고, 가장 값지다

이 고리는, 기술 출신인 사람이 오히려 자주 빠뜨린다. 그런데 이건 바로 PM의 주 무대다—당신은 태생적으로 ‘누가 쓰는가, 왜 쓰는가’를 신경 써야 하는 사람이다.

비교해보자. “데이터 대시보드 하나 만들어, 온갖 데이터를 다 올려줘”라고 하면, 당신이 아예 안 볼지도 모르는 차트를 한 화면 가득 쌓아준다.

이렇게 바꿔보자. “데이터 대시보드 하나 만들어줘. 매장 점장이 매일 아침에 보는 거야. 그가 가장 관심 있는 건 어제 얼마나 팔렸는지, 그저께보다 올랐는지 내렸는지, 어느 품목이 가장 잘 팔리는지야. 이 셋을 가장 눈에 띄게, 나머지는 부차적으로.”

차이가 보이는가? ‘누가 쓰는가 + 그가 가장 관심 있는 게 무엇인가’를 더하니, AI는 무엇을 부각하고 무엇을 죽여야 할지 알게 된다—AI에게 ‘중점’이 생기기 시작한 거다. 모든 정보를 바닥에 평평하게 깔아놓는 대신에.

나는 이제 거의 습관이 됐다. 요구사항 하나하나 뒤에, ‘이건 누구에게 쓰는 거고, 그가 무슨 문제를 풀려는가’를 한 마디 덧붙이는 것. 이 한 마디는, 앞의 모든 기술을 다 합친 것보다 값질 때가 많다.

부품 셋: 구체적 형태—‘어떻게 생겼는지’를 말로 하라

머릿속에선 생각에 그림이 있는데, 당신은 추상적인 단어 하나만 툭 던진다.

“필터 기능 하나 만들어줘” — AI는 당신이 뭘, 어떻게 거르려는지 모른다.

“표 위쪽에 필터 한 줄 추가: 날짜 범위 선택기 하나, ‘상태’ 드롭다운 하나(전체／정상／사용 중지), 검색창 하나(이름 또는 이메일로 검색). 필터는 즉시 반영, 고르는 즉시 새로고침, 확인 누를 필요 없이.” — 이러면 일대일로 그대로 복원해낸다.

당신이 디자인을 할 줄 알 필요는 없다. 그저 마음속 그 그림을 쉬운 말로 그려내기만 하면 된다. 어떤 블록들이 있고, 각 블록이 뭐고, 어디에 놓고, 어떻게 쓰는지. 그려낼 수 있으면 복원해내고, 그려내지 못하면 당신 자신도 아직 정리가 안 됐다는 뜻이다—그게 딱 좋다. 그건 하나의 신호다. 뒤에서 이걸 거꾸로 활용해 당신 생각을 정리하게 돕는 법을 얘기하겠다.

부품 넷: 경계—‘돌아가는 것처럼 보임’과 ‘진짜 쓸 만함’의 분수령

이 고리는 두 마디 더 하겠다. 이게 초보와 PM의 진짜 차이이기 때문이다.

초보는 요구사항을 기술할 때 ‘정상 상황’만 기술한다. 사용자가 얌전히 입력하고, 데이터는 다 정상이고, 네트워크는 계속 연결돼 있다. 하지만 현실 세계에선 사용자가 아무렇게나 입력하고, 데이터가 비어 있고, 네트워크가 끊기고, 입력이 지나치게 길다. 이런 걸 ‘경계 상황’이라 하는데, PM이 가장 신경 써야 하고, AI에게 가장 명확히 말해줘야 하는 부분이다.

“피드백 제출 폼 하나 만들어줘. 이름·이메일·내용, 제출 버튼 하나”라고 하면, AI는 정상 경로 하나만 만들고 임무 완수로 친다.

이렇게 말한다면:

”……이 몇 가지 상황을 신경 써줘. 이메일 형식이 틀리면 입력창 아래 빨간 글씨로 알려주고 제출은 막아줘. 피드백 내용이 비면 제출 버튼이 안 눌리게. 제출 성공하면 폼을 비우고 ‘피드백 감사합니다’를 표시. 제출 실패(예: 네트워크 끊김) 시엔 사용자가 이미 입력한 내용을 비우지 말고, ‘제출 실패, 다시 시도해주세요’라고 알려줘.”

여기 늘어난 이 몇 줄이, 바로 PM의 전문성이다. AI는 이런 걸 처리할 능력이 충분한데, 당신이 말하지 않으면 기본값으로 ‘정상 경로’만 만든다. 당신이 경계를 나열해주면, 한 번에 다 만들어준다.

덧붙이자면, ‘무엇이 다 됐다는 건가’와 ‘무엇을 안 할 건가’도 경계에 속하고, 마찬가지로 말해야 한다. “이번 버전은 목록과 필터만, 추가·삭제·수정은 아직 안 함”이라는 한 마디가, 이번 판에 당신이 애초에 원하지도 않은 온갖 것들을 막아준다.

부품 다섯: 참조—AI에게 자 하나를 쥐여줘라

스타일, 배색, 경험 같은 ‘감각’의 일은, 글로 명확히 말하기가 가장 어렵다. 가장 손쉬운 방법은 참조를 주는 것이다.

“색 좀 예쁘게, 전문적으로 해줘” — ‘예쁨’ ‘전문적’은 백 명이면 백 가지로 이해한다.

“메인 컬러는 브랜드 블루 #3B82F6, 전체 배색과 여백은 Stripe 공식 사이트 같은 깔끔하고 절제된 스타일을 참고.” — AI에게 자가 생겼으니, 당신 마음속의 ‘예쁨’을 헛짚을 필요가 없어진다.

참조는 색값 하나일 수도, 당신이 좋다고 여기는 제품(‘Notion처럼’)일 수도, 하나의 기준일 수도 있다. 참조를 주면, AI는 당신의 안목에 도박을 걸 필요가 없어진다.

가장 흔한 다섯 가지 ‘말 못 함’, 그리고 그 고치는 법

위는 정면에서 뜯어본 것이다. 아래는 내가 가장 많이 봤고, 나 자신도 가장 많이 저지른 다섯 가지 함정이다. 하나씩 대조하며 자가 점검해보자.

함정 하나, 너무 뭉뚱그림. “예쁜 페이지 하나 만들어줘” — AI는 평범한 물건을 주고, 당신은 어디가 잘못됐는지 말도 못 한다. 고치는 법: 구체적인 쪽으로 한 겹 밀어붙여, 형용사를 명사와 세부로 바꿔라.

함정 둘, 명령만 내리고 맥락은 안 줌. “내보내기 기능 추가해줘” — 뭘 내보내? 어디로? 무슨 형식? 어디에 붙여? 고치는 법: ‘어디에 + 뭘 내보내 + 무슨 형식’을 채워라. 예를 들어 “리포트 페이지 오른쪽 위에 ‘내보내기’ 버튼 추가, 클릭하면 현재 필터 조건의 표를 CSV로 내보내 다운로드”.

함정 셋, 한 번에 잔뜩 던짐. 메시지 하나에 요구사항 열다섯 개를 쑤셔 넣으면, 나온 게 뒤죽박죽이라 어디부터 고쳐야 할지도 모른다. 고치는 법: 작게, 빠르게. 한 번에 하나만. 먼저 뼈대를 세워 돌려보고 결과를 눈으로 확인한 뒤, 하나씩 하나씩 올려라. 이 항목이 모든 것 중 가장 중요하다. 예외 없이.

함정 넷, 참조를 안 주고 안목을 전부 AI에게 추측시킴. 고치는 법은 부품 다섯을 보라. 색값을 주고, 참조 대상을 주고, 기준을 줘라.

함정 다섯, 정상만 말하고 이상은 안 말함. 데모 시연은 아주 매끄럽다가, 실제로 사용자에게 쥐여주면 온갖 데서 터진다. 고치는 법: 요구사항을 보내기 전에 스스로 세 마디를 물어라—데이터가 비면 어떻게 되지? 사용자가 아무렇게나 입력하면 어떻게 되지? 네트워크가 끊기면 어떻게 되지? 답을 요구사항에 써넣어라.

세 가지 기술: AI를 ‘손’에서 ‘머리’로 바꾸는 법

위를 능숙하게 익히면, 당신은 이미 대다수를 앞선다. 아래 세 가지는, 내가 AI를 ‘말 잘 듣는 한 쌍의 손’에서 ‘나 대신 생각해주는 하나의 머리’로 바꾸는 데 쓰는 기술이다.

첫째, AI가 먼저 되묻게 하라. 급하게 시키지 말고. 이건 내가 가장 많이 쓰고, 가장 직관에 반하는 기술이다. 중요한 요구사항일수록, 시작하자마자 만들라고 하지 말고, 먼저 나에게 묻게 하라.

“생각 하나 있어. 고객 피드백 수집·분석 도구 하나를 만들려고 해. 아직 손대지 말고—먼저 가장 핵심적인 질문 다섯 개를 나한테 물어봐. 타깃 사용자, 핵심 용도, 반드시 있어야 할 기능, 경계를 다 명확히 묻는 걸로.”

AI가 던진 질문은, 십중팔구 바로 당신 자신이 아직 정리하지 못한 지점이다. 당신이 답하는 과정이 곧, 요구사항을 ‘한 덩어리 모호함’에서 ‘한 줄 명확함’으로 밀어붙이는 과정이다. 다 답하고 나면 AI 손엔 이미 완전한 요구사항이 있고, 만든 결과가 맞는 건 당연하다. 이 기술의 본질은, AI로 하여금 당신을 대신 만들게 하는 게 아니라, 당신 생각을 정리하게 돕는 것이다—정리되면, 제대로 만드는 건 덤이다.

둘째, 정례와 반례를 줘라. 글로 명확히 안 될 땐, 예를 드는 게 가장 빠르다. 특히 ‘난 이런 게 좋고, 저런 건 싫다’일 때.

“이 버튼 클릭 후 안내 문구를 써줘. 이런 식으로: 짧게, 구어체로, 안심시키는—‘저장됐어요, 걱정 마세요’. 이런 식은 말고: 관료적이고, 장황한—‘귀하의 작업이 서버에 성공적으로 제출되어 영속 저장이 완료되었습니다’.”

정례 하나에 반례 하나가, 당신이 형용사 세 줄 쓰는 것보다 잘 먹힌다.

셋째, 복창해 확인하게 한 뒤 손대게 하라. 요구사항이 복잡할 땐, AI가 먼저 자기 이해를 한 번 복창하게 하고, 당신이 확인하면 그때 만들게 하라.

“방금 내가 말한 요구사항, 아직 만들지 마. 세 문장으로 나한테 확인해줘: 뭘 만들 건지, 몇 개 블록으로 나눌 건지, 아리송한 데는 없는지. 내가 확인하면 그때 시작해.”

이 단계에 30초를 쓰면, 반나절 재작업을 아낀다. AI가 복창할 때, 당신은 종종 그 자리에서 발견한다. “어, 여기 내가 말한 거랑 내가 생각한 게 다르네”—AI가 아직 손대기 전에, 얼른 고쳐라.

한 번 끝까지 걸어보기: 모호한 한 마디에서, 한 번에 제대로 해내기까지

위를 한 줄로 꿰어, 실제 과정을 한 번 훑어보자. 내 머릿속엔 모호한 한 마디밖에 없다고 하자. “뭔가 하나 있으면 좋겠어. 사용자 피드백을 볼 수 있는.”

첫 단계, 나는 급하게 만들라고 하지 않고, 먼저 생각을 정리하게 돕는다(첫째 기술). AI가 나에게 다섯 개의 핵심 질문을 하게 한다. AI는 이렇게 묻는다. 누가 쓰나(운영 동료)? 피드백은 어디서 오나(CSV 파일 하나)? 거기서 가장 얻고 싶은 게 뭔가(다들 어디에 가장 몰려서 불평하는지 빠르게 아는 것)? 심각도순으로 정렬할까(그렇게)? 이번 버전에 필터 넣을까(아직은 됐다)?

둘째 단계, 답을 모아 완전한 요구사항 하나로 만든다. 다섯 부품이 딱 갖춰진다. 운영이 볼 것, 목적은 사용자가 가장 몰려서 불평하는 게 뭔지 빠르게 보는 것(누구에게, 왜). 위쪽에 CSV를 올리는 업로드 영역 하나, 아래쪽에 피드백의 주제 분류, 분류별 몇 건인지, 비율이 얼마인지를 자동 표시하고 건수순 정렬(무엇을, 형태). CSV가 비었거나 형식이 틀리면 ‘읽기 실패, 형식을 확인해주세요’라고 안내, 이번 버전은 필터·검색 안 함(경계). 깔끔하고 절제되게, 메인 컬러 #3B82F6, Notion의 레이아웃 참고(참조). 우선 가짜 데이터로 만들어, 로컬 서버를 띄워 미리 볼 수 있게.

셋째 단계, 돌려서 결과를 눈으로 본 뒤, 작게 더한다(함정 셋의 고치는 법). 한 번에 하나씩—“각 주제 뒤에 진행 바를 붙여 비율 표시” “어떤 주제를 클릭하면 그 분류의 원본 피드백 세 건을 펼쳐 표시” “주제를 심각도로 색칠, 빨강은 고빈도, 노랑은 중간, 회색은 저빈도”.

넷째 단계, AI가 스스로 문제를 찾게 한다. “클릭할 수 있는 곳을 전부 눌러보고, 에러·멈춤·예상과 다른 것을 찾아 목록으로 만들어줘.”

전 과정에서 나는 코드 한 줄 안 썼지만, 매 단계를 또렷또렷하게 말했다. 이게 지금의 일상이다—당신은 명확히 생각하고 명확히 말하는 걸 맡고, AI는 만드는 걸 맡는다.

마지막으로

엔터를 치기 전에, 나는 보통 10초를 들여 마음속으로 이 칸들을 한 번 훑는다. 무엇을 원하는가(구체적 명사인가), 누구에게 왜, 어떤 모양, 경계(빈 데이터·아무렇게나 입력·실패·안 할 것을 다 말했나), 참조, 그리고—이번엔 요구사항을 하나만 냈나. 여섯 개 중 넷다섯 개를 통과하면, AI는 대체로 한 번에 제대로 해낸다.

AI를 쓸 줄 아는 사람은 점점 늘지만, 요구사항을 제대로 말할 줄 아는 사람은 늘 소수다. 앞의 일은 문턱이라 누구나 넘을 수 있고, 뒤의 일은 분수령이라 사람을 두 부류로 가른다.

그리고 당신은 프로덕트 매니저로서, 원래 사용자를 가장 잘 알고, 중점을 가장 잘 알고, 아무도 대신 신경 써주지 않는 그 경계를 가장 잘 안다. 당신에게 모자랐던 건 이런 게 아니라, 그것들을 말로 내놓는 습관이었다. 한 달만 연마해보라. AI가 똑똑해진 게 아니라, 당신이 드디어 배운 것임을 알게 된다—마음속 그 요구사항을, 온전하게 건네는 법을.