AI 기획자 기술 지식 : 어디까지 알아야 하나요

AI 기획자에게 먼저 필요한 것은 모델 내부를 만드는 지식이 아니라 서비스에서 모델이 언제 바뀌고 어디가 깨지는지 확인하는 지식입니다. 2026년 8월 아이엠 AI PM 과정 1회차에서 34회차까지 모델 내부의 계산 방식은 다루지 않았습니다. 대신 챗봇 실습을 하면서 연결, 모델, 답변 길이, 대화 기록 중 어디에서 문제가 생겼는지 개발자, 기획자, 사용자에게 설명할 수 있는 수준까지 익혔습니다.

모델 내부를 알아야 AI 기획을 할 수 있나요

모델 내부보다 챗봇을 불러 쓰고 문제가 생긴 자리를 확인하는 지식부터 익혔습니다. 처음에는 AI 기획을 하려면 모델 안에서 문장이 만들어지는 원리부터 알아야 한다고 생각했습니다. 하지만 챗봇 실습에서 먼저 필요했던 것은 입력한 내용과 나온 답을 비교하고, 어느 자리에서 문제가 생겼는지 가르는 일이었습니다.

서비스에서는 LLM을 직접 열어 고치기보다 API로 불러 씁니다. LLM은 많은 글을 읽고 다음에 올 말을 고르는 큰 언어 모델입니다. API는 남이 만든 기능을 주소로 불러 쓰는 창구입니다. 집 안을 열어보는 대신 문으로 무엇을 넣었고 무엇이 나왔는지 확인하는 셈입니다.

처음에는 기술 용어를 많이 알아야 한다고 봤습니다. 다시 보니 AI 기획자에게 먼저 필요한 것은 서비스가 안 될 때 확인 순서를 설명하고 직접 시험하는 능력이었습니다.

챗봇에서 404 오류가 나면 무엇을 확인해야 하나요

AI 기획자는 챗봇에서 오류가 났을 때 API 키, 연결, 모델 가운데 어디에서 문제가 생겼는지 범위를 좁힐 수 있어야 합니다. 2026년 8월 아이엠 AI PM 과정의 챗봇 실습에서 HTTP Error 404가 났습니다. 처음에는 코드나 API 키가 잘못됐다고 생각했습니다.

먼저 오류 본문을 읽었습니다. 사용하던 모델을 신규 사용자가 더는 쓸 수 없으니 다른 모델로 바꾸라는 내용이었습니다. 바로 모델명을 바꾸기보다 API 키와 연결이 정상인지 확인하기 위해 현재 사용할 수 있는 모델 목록부터 조회했습니다. 목록에서 37개가 정상으로 돌아왔습니다. API 키나 연결이 끊겼다면 목록도 받아올 수 없기 때문에, 연결은 살아 있고 호출한 모델에 문제가 있다고 범위를 좁혔습니다.

문제의 원인을 찾은 뒤에는 옛 모델명이 남은 자리도 확인했습니다. 코드 기본값과 설정 파일 등 여섯 단계에 네 곳씩 모두 24곳이었습니다. 한 곳에라도 옛 모델명이 남아 있으면 같은 오류가 다시 생길 수 있어 빠짐없이 점검했습니다.

이 실습을 통해 AI 기획자가 모델을 직접 만들 필요는 없지만, 오류 문구를 읽고 확인 순서를 정할 수는 있어야 한다고 배웠습니다. API 키와 연결이 정상인지 확인하고, 모델 문제로 범위를 좁힌 뒤, 같은 값이 남은 자리까지 점검하는 수준의 기술 지식이 필요했습니다.

챗봇의 답이 중간에서 잘리면 무엇을 확인해야 하나요

AI 기획자는 챗봇의 답이 중간에서 끊겼을 때 답변에 허용된 길이가 충분한지 확인할 수 있어야 합니다. 모델명을 바꾼 뒤 답이 한식조리기능사 필기 응시에서 끊겼습니다. 답의 내용이 잘못된 것인지, 답변을 끝까지 쓸 공간이 부족한 것인지 확인해야 했습니다.

실습에서는 출력 길이의 한도를 1024에서 2048로 올린 뒤 같은 질문으로 다시 확인했습니다. 그러자 끊겼던 답이 이어졌습니다. 이를 통해 답의 내용이 잘못된 것이 아니라 답변에 허용된 길이가 부족했다는 것을 확인했습니다.

이 문제를 이해하려면 토큰의 뜻을 알아야 합니다. 모델은 글의 길이를 글자 수가 아니라 토큰이라는 단위로 셉니다. 토큰은 대략 한글 한두 글자나 영어 서너 글자에 해당하는 작은 글 조각입니다. 사용자가 입력한 내용과 모델이 출력한 답에 토큰이 쓰이며, 요즘 모델은 답을 만들기 위해 생각하는 과정에도 토큰을 사용할 수 있습니다. 생각하는 데 많은 토큰을 쓰면 실제 답변에 사용할 수 있는 분량이 줄어들 수 있습니다.

이 실습을 통해 답이 잘렸을 때 출력 숫자만 무작정 키우기보다 입력, 생각 과정, 실제 답변에 토큰이 어떻게 쓰이는지 살펴봐야 함을 배웠습니다. 즉, AI 기획자는 토큰의 계산 방식을 직접 만들 필요는 없지만, 답변 한도를 바꾼 뒤 실제 답이 끝까지 나오는지 다시 확인할 수는 있어야 합니다.

챗봇이 앞선 내용을 잊는다면 무엇을 확인해야 하나요

비개발자 AI 기획자는 챗봇이 앞선 내용을 잊었을 때 대화 기록을 얼마나 보내고 있는지, 꼭 기억해야 할 값은 따로 저장했는지 확인할 수 있어야 합니다. 챗봇은 사람처럼 대화를 스스로 기억하지 않습니다. 답변할 때 다시 전달받은 기록만 참고하므로, 기획자가 어떤 내용을 계속 보여 줄지 정해야 합니다.

실습의 목표는 대화가 이어져도 챗봇이 첫 번째 빈칸에 입력된 값을 놓치지 않게 만드는 것이었습니다. 처음에는 이전 대화를 많이 보내면 해결될 것으로 생각했습니다. 하지만 모델이 한 번에 참고할 수 있는 전체 분량인 컨텍스트에는 한도가 있습니다. 기록을 계속 늘리면 비용이 커지고, 앞부분이 빠지거나 오래된 내용이 섞여 답이 어긋날 수 있었습니다.

먼저 챗봇에 실제로 몇 개의 기록이 전달되는지 확인했습니다. 화면에는 15개라고 표시돼 처음에는 기능이 고장 난 줄 알았습니다. 알고 보니 턴과 전달 항목을 다르게 센 결과였습니다. 턴은 사용자의 말과 챗봇의 답을 합친 한 번의 주고받기이므로 1턴은 말풍선 2개입니다. 이처럼 AI 기획자는 코드를 직접 만들지 않더라도 화면의 숫자가 무엇을 뜻하는지 확인하고, 기능 오류인지 설정을 잘못 이해한 것인지 구분할 수 있어야 합니다.

그다음에는 모든 대화를 보내는 대신 전달할 기록을 1턴으로 줄였습니다. 대화를 줄인 이유는 불필요한 기록을 덜어내면서도 답변에 꼭 필요한 값은 유지하기 위해서였습니다. 첫 번째 빈칸 값은 저장소의 값으로 다시 계산해 챗봇에 전달했습니다. 필요한 값만 담은 분량을 비교하니 1턴은 639자, 5턴은 680자였고 20턴에서도 700자 안팎이었습니다. 이 실습을 통해 대화 기록을 무조건 늘리기보다 필요한 값을 따로 저장하고 답변할 때 다시 건네는 방식을 설계해야 함을 배웠습니다.

아직 몰라도 되는 것과 알아야 하는 것의 경계는 어디인가요

2026년 8월 아이엠 AI PM 과정의 챗봇 실습에서는 모델 목록을 조회해 연결 문제와 모델 문제를 갈랐습니다. 모델명이 남은 24곳을 찾았고, 답이 끊겼을 때 출력 길이를 1024에서 2048로 바꿨습니다. 대화 기록이 많아졌을 때는 턴을 늘리는 대신 필요한 값을 저장소에서 다시 꺼냈습니다.

이 경험에서 잡은 경계는 개발자처럼 모델을 만드는가가 아니었습니다. AI 기획자는 API 키, 연결, 모델, 출력 한도, 대화 기록 가운데 어디를 먼저 확인할지 정할 수 있어야 했습니다. 또 바꾼 뒤에는 챗봇의 실제 답을 다시 확인해야 했습니다. 직접 재지 않은 비용과 사용량은 좋아졌다고 말하지 않는 것까지가 제가 익힌 기술 지식의 범위였습니다.