PM의 AI 리터러시, 어디까지 필요한가

 

요즘 팀 안에서 가장 자주 듣는 질문이 "저도 이제 프롬프트 엔지니어링 배워야 하나요?"입니다.
신입 기획자뿐 아니라 연차가 꽤 있는 동료들도 비슷한 질문을 던져요.
저도 작년까지는 이 질문에 명확한 답이 없었는데, 몇 번의 프로젝트를 거치면서 나름의 기준이 생겼습니다.
그래서 이번엔 "기획자에게 AI 리터러시가 어디까지 필요한가"를 저 나름대로 정리해보려고 합니다.

 

AI 리터러시라는 말을 들으면 왠지 모델 구조나 파라미터 수까지 알아야 할 것 같은 부담이 듭니다.
저도 처음엔 그렇게 생각했어요.
트랜스포머 구조가 어떻게 생겼는지, 어텐션 메커니즘이 뭔지 공부하려고 온라인 강의를 두 개나 결제했습니다.
그런데 두 달쯌 지나고 나서 깨달은 건, 그 지식이 실제 기획 회의에서 거의 쓰이지 않았다는 거였어요.
회의에서 정말 필요했던 건 "이 모델이 이런 종류의 실수를 자주 한다"는 감각이었지, 수식을 이해하는 능력이 아니었습니다.
그래서 저는 리터러시의 정의를 좀 낮춰서 다시 잡았어요.
"모델을 만들 줄 아는 것"이 아니라 "모델의 한계를 예측할 줄 아는 것"으로요.
이렇게 기준을 바꾸고 나니 공부해야 할 범위도 훨씬 명확해졌습니다.

 

이것을 위해 최소한 알아이햘 세 가지 층위에 대해 정리해 보았습니다. 

 

첫째는 모델 특성입니다.

같은 질문에도 매번 답이 조금씩 달라질 수 있다는 것, 확신 있게 틀린 답을 낼 수 있다는 것 정도는 기획자도 체감하고 있어야 해요.
이걸 모르면 "이 기능은 항상 같은 결과를 보장해야 한다"는 요구사항을 아무렇지 않게 써버리게 됩니다.
저도 초반에 그런 명세를 썼다가 개발팀에서 "이건 LLM 구조상 원천적으로 불가능한 요구입니다"라는 답을 받은 적이 있어요.
그때는 좀 민망했지만, 덕분에 확실하게 배웠습니다.

 

둘째는 데이터입니다.

모델이 어떤 데이터로 학습됐는지 세세히 알 필요는 없지만, 우리 서비스가 참고할 데이터가 어떤 상태인지는 파악하고 있어야 합니다.
데이터가 정리되어 있지 않으면 아무리 좋은 모델을 붙여도 결과가 나쁘게 나온다는 걸, 저는 사내 문서 검색 프로젝트를 하면서 뼈저리게 배웠어요.
문서 절반이 2년 전 버전으로 방치되어 있었는데, 그걸 모르고 검색 기능부터 붙였다가 오래된 정책이 최신 정책처럼 노출되는 사고가 났었습니다.

 

셋째는 비용과 리스크입니다.

호출 한 번에 얼마가 드는지, 잘못된 답변이 나갔을 때 어떤 리스크가 있는지를 감으로라도 알고 있어야 의사결정을 할 수 있어요.
이 세 가지만 알아도 개발팀, 데이터팀과의 대화가 훨씬 매끄러워집니다.
저는 이 세 층위를 팀 내부 온보딩 문서에도 그대로 정리해서, 신입 기획자가 들어오면 가장 먼저 공유하고 있어요.

 

작년 여름에 진행한 프로젝트에서, 저는 응답 속도를 전혀 고려하지 않고 화면 플로우를 설계했습니다.
사용자가 질문을 입력하면 바로 답이 뜨는 걸 전제로 로딩 화면 없이 화면을 짜뒀는데, 실제로 붙여보니 평균 응답 시간이 4~5초였어요.
사용자 테스트에서 "화면이 멈춘 것 같다"는 피드백이 계속 나왔고, 결국 로딩 애니메이션과 단계별 안내 문구를 급하게 추가해야 했습니다.
그때 처음으로 "LLM 기반 기능은 응답 지연이 기본값"이라는 걸 체감했고, 그 이후로는 항상 예상 응답 시간을 먼저 물어보고 화면을 설계하는 습관이 생겼어요.

비슷한 실수를 한 번 더 했습니다.
토큰 수에 따라 비용이 달라진다는 걸 알고는 있었지만, "그래봐야 얼마나 차이 나겠어"라고 안일하게 생각했던 적이 있었어요.
사용자가 긴 텍스트를 붙여넣는 시나리오를 놓쳤다가, 실제 운영에서 예상보다 세 배 넘는 토큰이 소비되는 걸 보고서야 입력 길이 제한을 뒤늦게 추가했습니다.
이런 실수들을 겪으면서, 결국 리터러시라는 게 "이론을 아는 것"이 아니라 "어디서 사고가 나는지 미리 상상할 수 있는 것"이라는 생각이 들었어요.

 

여기서 중요한 건 경계를 긋는 겁니다.
프롬프트를 직접 튜닝하는 건 개발자나 프롬프트 엔지니어의 영역으로 남겨두는 게 맞다고 생각해요.
기획자가 거기까지 파고들면, 오히려 "무엇을 만들 것인가"를 고민할 시간이 줄어듭니다.
저는 개인적으로 이 경계를 "모델이 왜 그렇게 답했는지 설명은 못 해도, 그 답이 서비스에 어떤 영향을 주는지는 판단할 수 있어야 한다"로 잡았어요.
설명은 전문가에게 맡기고, 판단은 기획자가 하는 거죠.

이 경계를 정하고 나서부터는 오히려 공부가 더 편해졌습니다.
모든 걸 다 알아야 한다는 부담을 내려놓으니, "이 정도만 알아도 충분하다"는 마음으로 필요한 부분만 골라서 익힐 수 있게 됐어요.
개발팀 동료에게 "이 부분만 알려주면 됩니다"라고 구체적으로 요청할 수 있게 된 것도 큰 변화였습니다.

 

혼자 공부하는 것보다 팀 전체의 감각을 맞추는 게 더 어려운 일이었어요.
저희는 매주 금요일 30분씩 "이번 주에 겪은 AI 관련 삽질"을 공유하는 짧은 세션을 만들었습니다.
거창한 스터디가 아니라, 그냥 각자 겪은 실수와 배운 점을 캐주얼하게 이야기하는 자리였어요.
처음엔 몇 명만 참여했는데, 서너 달 지나니 디자이너와 마케터까지 자연스럽게 끼어서 이야기하게 됐습니다.
이 세션이 쌓이면서, 팀 전체의 "AI가 이런 실수를 한다"는 감각이 눈에 띄게 비슷해졌어요.

 

올해 기획자 채용 면접을 몇 번 봤는데, 이 과정에서 리터러시의 격차를 더 명확하게 체감했습니다.
어떤 후보는 "LLM 기반 기능은 검증 시나리오를 어떻게 짜야 하는지" 구체적인 사례를 들어 설명했고, 어떤 후보는 AI를 그냥 "마법 같은 만능 기능"처럼 이야기했어요.
후자의 경우, 실제 업무에서는 "왜 이 기능이 이렇게 자주 틀리죠?"라는 질문에 제대로 대응하지 못할 가능성이 높다는 판단이 들었습니다.
그래서 저희는 면접 질문에 "이 기능이 실패했을 때 사용자에게 어떻게 안내할 것인가"를 반드시 넣기 시작했어요.
이 질문 하나로 후보의 리터러시 수준이 꽤 선명하게 드러난다는 걸 알게 됐습니다.
흥미로운 건, 개발 경험이 전혀 없는 후보라도 이전 프로젝트에서 실패를 어떻게 다뤘는지를 구체적으로 설명할 수 있으면 오히려 더 높은 점수를 줬다는 점이에요.
결국 중요한 건 배경지식의 양이 아니라, 실패를 대하는 태도였습니다.

 

같은 업계 지인들과 이야기를 나누다 보면, 리터러시를 다루는 방식이 회사마다 꽤 다르다는 걸 알게 됩니다.
어떤 회사는 전 직원에게 필수 온라인 교육을 의무화했는데, 정작 실무에 적용하는 사람은 적었다고 하더라고요.
반대로 저희처럼 작은 세션을 자율적으로 운영하는 방식은 참여자가 자발적이어서 실무 적용률이 높았지만, 참여하지 않는 사람과의 격차가 점점 벌어지는 단점도 있었습니다.
결국 정답은 없고, 각 조직의 문화에 맞는 방식을 찾아야 한다는 결론에 도달했어요.
저희는 자율적인 세션은 유지하면서, 신규 프로젝트에 AI 기능이 들어갈 때만큼은 관련자 전원이 필수로 참여하는 하이브리드 방식으로 조정했습니다.

 

리터러시를 이야기하면서 빼놓을 수 없는 게, 제가 스스로 갖고 있던 착각들이었습니다.
저는 한동안 "모델이 최신 정보를 모른다"는 것 정도는 당연히 알고 있으니 리터러시가 충분하다고 생각했어요.
그런데 동료와 실제 프로젝트 사례를 하나씩 비교해보다가, 저는 "모델이 왜 특정 상황에서 답을 거부하는지"에 대한 감각이 훨씬 부족하다는 걸 알게 됐습니다.
안전 정책 때문에 거부하는 경우와, 단순히 맥락을 이해하지 못해서 거부하는 경우를 구분하지 못해서, 엉뚱한 곳에 시간을 쓴 적이 몇 번 있었어요.
이 경험 이후로 "나는 어디까지 알고 있다고 착각하고 있는가"를 주기적으로 점검하는 습관이 생겼습니다.
동료들과 서로의 맹점을 짚어주는 것만으로도, 혼자 공부할 때보다 훨씬 빠르게 착각을 걷어낼 수 있었어요.

 

체감으로만 리터러시를 판단하는 게 불안해서, 저희는 팀 내부에서 쓸 간단한 자체 진단 문항을 만들어봤습니다.
"이 기능이 매번 다른 답을 낼 수 있다는 걸 사용자에게 어떻게 설명할 것인가", "이 모델의 응답이 확신에 찬 것처럼 보여도 틀릴 수 있다는 걸 스스로 어떻게 검증하는가" 같은 열 개 정도의 짧은 질문이었어요.
정답을 맞히는 시험이 아니라, 이 질문에 구체적인 사례를 들어 답할 수 있는지를 보는 방식이었습니다.
처음 이 테스트를 돌렸을 때, 저조차 몇 개 문항에는 뭉뚱그린 답밖에 못 냈다는 걸 알고 조금 당황했어요.
그 이후로 이 문항들을 신입 온보딩뿐 아니라 반기에 한 번씩 팀 전체가 다시 풀어보는 걸로 정례화했는데, 매번 답이 조금씩 더 구체적으로 바뀌는 걸 보면서 팀의 리터러시가 실제로 쌓이고 있다는 걸 확인할 수 있었습니다.

 

배운 걸 그냥 흘려보내지 않으려고, 저는 프로젝트마다 겪은 리터러시 관련 실수를 짧게라도 문서로 남기는 습관을 만들었습니다.
"이런 요구사항을 썼다가 이런 이유로 반려됐다", "이런 상황에서 폴백 설계를 놓쳤다"처럼 한 문단짜리 기록이었어요.
처음엔 저 혼자 보려고 쓴 메모였는데, 어느 순간부터 신규 프로젝트를 시작하는 동료들이 먼저 찾아와서 "혹시 관련 기록 있어요?"라고 물어보는 일이 늘었습니다.
이 메모들이 쌓여서 지금은 사내 위키에 "AI 프로젝트 실수 노트"라는 이름의 페이지가 됐고, 30개가 넘는 사례가 정리되어 있어요.
신규 프로젝트를 시작하는 사람이 이 노트를 한 번만 훑어봐도, 저희가 반년 넘게 겪은 실수의 절반은 피해갈 수 있다는 게 이 기록의 가장 큰 값어치라고 생각합니다.
글을 쓰는 게 번거로울 때도 있지만, 다음 사람의 시간을 아껴준다는 걸 알고 나서는 이 습관을 놓기가 어려워졌어요.

 

기획팀 안에서는 이제 이런 대화가 어느 정도 자연스러워졌는데, 정작 어려운 건 AI를 직접 다루지 않는 다른 부서 리더들과의 대화였습니다.
영업팀이나 인사팀 리더들은 "AI 기능 하나 넣는 게 뭐가 그렇게 오래 걸리냐"고 묻는 경우가 많았어요.
이분들에게 트랜스포머나 토큰 같은 용어를 설명하는 건 의미가 없었습니다.
대신 저는 항상 비유를 써서 설명하려고 했어요.
"신입사원에게 매뉴얼 없이 상담을 시키는 것과 비슷하다"거나, "신입사원이 확신 있게 틀린 답을 할 수도 있으니 검증 과정이 필요하다"는 식으로 사람에 빗대어 설명하니 훨씬 잘 이해하셨습니다.
이 비유를 쓰기 시작한 뒤로는, 신규 AI 기능 관련 예산이나 일정 승인을 받는 회의가 눈에 띄게 빨리 끝났어요.
리터러시라는 게 결국 상대방의 언어로 설명할 수 있는 능력까지 포함하는 거라는 걸, 이런 자리를 겪으면서 새롭게 느꼈습니다.

돌아보면 AI 리터러시는 한 번 배우고 끝나는 게 아니라 프로젝트마다 조금씩 쌓이는 감각 같습니다.
매번 새로운 실수를 하면서 배우고 있는데, 적어도 작년보다는 회의에서 헛발질하는 횟수가 줄어든 것 같아 다행이라고 생각해요.
내년엔 또 어떤 새로운 개념이 나와서 저를 다시 공부하게 만들지 궁금하기도 하고, 조금은 피곤할 것 같기도 합니다.
그래도 이 흐름에서 뒤처지지 않으려면, 완벽하게 아는 것보다 계속 실수하고 고치는 태도가 더 중요하다는 걸 요즘 부쩍 느끼고 있어요.