AI 개발

소프트웨어는 오랫동안 같은 입력에 같은 출력을 내는 물건이었습니다. 저장 버튼을 누르면 저장되고 안 되면 버그입니다. 재현 절차를 적어 넘기면 다른 사람 화면에서도 같은 증상이 나왔고, 고친 뒤에는 고쳐졌는지 기계가 대신 확인해 줬습니다. 맞고 틀림이 분명했다는 뜻입니다.

언어 모델이 제품 안에 들어오면서 이 전제가 깨졌습니다. 페이지덱이 회의록에 문서 요약 기능을 붙였을 때가 그랬습니다. 태오의 화면에서 열 번 돌려 열 번 다 괜찮은 요약이 나왔고 그대로 내보냈는데, 사흘 뒤 고객이 "요약에 우리가 하지도 않은 결정이 적혀 있다" 고 알려 왔습니다. 태오가 같은 문서를 다시 넣어 보니 이번에는 멀쩡한 요약이 나왔습니다. 재현이 안 되니 버그 리포트를 쓸 수가 없고, 무엇을 고쳐야 할지도 정할 수 없었습니다.

문제는 하나 더 있었습니다. 요약 문장을 손보면 그 문서에서는 나아지는데 다른 문서 쉰 건에서 어떻게 되는지를 아무도 몰랐습니다. 좋아졌다는 말과 나빠졌다는 말이 둘 다 근거 없이 오갔고, 회의는 각자 본 사례를 꺼내 놓는 자리가 됐습니다.

머신러닝이 이미 있었지만 일의 모양이 달랐습니다. 데이터로 규칙을 학습시켜 예측하게 만드는 그 일은 회사가 자기 데이터를 모으고 모델을 직접 학습시켜야 했고, 그래서 전담 인력과 몇 달이 필요했습니다. 지금은 남이 만들어 둔 모델을 인터넷 너머로 불러다 씁니다. 모델을 만드는 일이 아니라 남의 모델을 제품에 끼워 넣고 통제하는 일이 남았고, 그 남은 일에 붙은 이름이 AI 개발입니다. 만드는 쪽의 어려움이 사라진 자리에 판정하고 가두는 쪽의 어려움이 들어왔습니다. 그래서 이 갈래는 엔지니어링의 다른 갈래들과 성질이 하나 다릅니다. 나머지는 기능이 되는지 안 되는지를 먼저 확인하고 그다음에 얼마나 빠른지를 따지지만, 여기서는 되는지 안 되는지를 재는 방법부터 팀이 직접 만들어야 합니다.

AI 개발 아래 묶인 용어들은 기능 하나를 만들며 부딪히는 순서대로 놓여 있습니다. 무엇으로 만드는가가 기반이고, 어떻게 쓰는가가 활용이고, 무엇에 걸리는가가 제약이고, 무엇이 잘못되는가가 위험이고, 잘됐는지 어떻게 아는가가 품질입니다. 다섯 갈래입니다.

기반은 재료를 다루는 갈래입니다. 대규모 언어 모델은 아주 많은 텍스트를 미리 읽어 두고 앞의 말에 이어질 말을 골라 내놓는 프로그램입니다. 사실을 찾아 답하는 것이 아니라 그럴듯한 다음 말을 고르는 방식이라, 이 한 줄이 뒤에 나오는 위험 갈래의 이유가 됩니다. 이 분야에서 쓰는 모델은 대개 직접 만들지 않고 만든 회사의 창구를 통해 빌려 씁니다.

활용은 그 모델에게 일을 시키는 방법을 가르는 갈래입니다. 여섯 가지가 있고 뒤로 갈수록 손이 많이 갑니다.

1. 프롬프트 엔지니어링 — 모델에게 주는 지시문을 설계하는 일입니다. "요약해 줘" 와 "결정된 사항만 세 줄로 뽑고 결정되지 않은 것은 적지 마" 는 같은 모델에서 전혀 다른 결과를 냅니다. 비용이 가장 적게 드는 수단이라 대개 여기서 시작합니다.
2. RAG — 모델은 회사 내부 문서를 모릅니다. 그래서 질문이 들어오면 사내 자료에서 관련 대목을 먼저 찾아 지시문에 붙여 주고, 모델은 그 대목만 보고 답하게 만듭니다. 사내 검색이나 고객 문의 답변처럼 우리 자료가 있어야 답이 되는 기능이 전부 이 방식입니다.
3. 임베딩 — 문장의 의미를 숫자 목록으로 바꾼 표현입니다. 글자가 겹치지 않아도 뜻이 가까우면 숫자가 가깝게 나와서, "환불 언제 돼요" 와 "결제 취소 처리 기간" 을 같은 자리로 모아 줍니다. 앞의 방식에서 관련 대목을 찾아내는 일이 이 숫자 비교로 이뤄집니다.
4. 파인튜닝 — 특정 용도에 맞게 모델을 추가로 학습시키는 일입니다. 말투를 고정하거나 우리 회사에서만 쓰는 분류 체계를 익히게 할 때 씁니다. 자료를 수백 건 이상 모아야 하고 모델을 바꿀 때마다 다시 해야 해서, 앞의 세 가지로 안 될 때 마지막에 꺼냅니다.
5. 에이전트 — 한 번 답하고 끝내는 대신 도구를 써 가며 여러 단계를 스스로 밟게 만든 구성입니다. 문서를 검색하고, 일정을 확인하고, 초안을 쓰고, 결과를 보고 다시 검색하는 식입니다. 단계가 늘어날수록 중간에 한 번 틀린 판단이 뒤를 전부 오염시킵니다.
6. MCP — 모델에 외부 도구와 데이터를 연결하는 개방 규격입니다. 도구마다 연결 방식을 따로 짜던 것을 한 규격으로 맞춰, 문서 저장소든 일정표든 같은 방법으로 붙입니다.

제약은 시킬 수 있는 일의 크기를 정하는 갈래입니다. 토큰은 모델이 글을 쪼개 다루는 최소 단위로, 한국어에서는 대체로 한두 글자가 한 토큰입니다. 컨텍스트 윈도는 모델이 한 번에 볼 수 있는 토큰의 최대 개수입니다. 이 둘이 곧 돈이자 한계입니다. 요금이 토큰 수로 매겨지고, 창을 넘는 문서는 통째로 넣을 수 없어 잘라 넣어야 하며, 자르는 순간 모델은 잘려 나간 부분을 없는 것으로 칩니다. 200쪽짜리 계약서를 넣고 "위약금 조항 알려 줘" 라고 물었을 때 없다고 답하는 사고가 여기서 납니다.

위험은 이 분야에만 있는 고장을 다루는 갈래입니다. 환각은 모델이 사실이 아닌 내용을 그럴듯한 문장으로 내놓는 현상입니다. 앞의 요약 사고가 그것입니다. 모르면 모른다고 하는 대신 가장 그럴듯한 말을 채워 넣기 때문에, 틀린 답이 맞는 답과 똑같이 자신 있게 생겼습니다. 가드레일은 그 출력이 넘으면 안 되는 선을 코드로 걸어 두는 장치입니다. 회사 정책에 어긋나는 답을 걸러 내거나, 정해진 형식을 벗어나면 다시 시키거나, 근거 문서에 없는 문장이 섞이면 내보내지 않는 식입니다.

품질은 나아졌는지를 판정하는 갈래입니다. 평가셋은 입력과 기대하는 답을 미리 짝지어 모아 둔 묶음으로, 지시문이나 모델을 바꿀 때마다 같은 묶음을 다시 돌려 점수를 비교합니다. 앞의 네 갈래를 아무리 잘 다뤄도 이것이 없으면 좋아졌다는 말을 증명할 수 없어서, 이 갈래가 없는 팀은 사례 몇 건으로 다투다 끝납니다.

다섯 갈래는 나란히 놓인 목록이 아니라 서로를 먹입니다. 컨텍스트 윈도가 좁으면 자료를 통째로 못 넣어 검색해 붙이는 방식이 필요해지고, 그렇게 붙인 자료가 엉뚱하면 환각이 늘고, 환각이 늘면 가드레일이 두꺼워지고, 그 모든 변경이 실제로 효과가 있었는지는 평가셋만 답합니다.

"이건 AI 개발 쪽에서 봐야 해요. 서버가 죽은 게 아니라 모델이 엉뚱한 답을 낸 거라서요."

같은 장애처럼 보여도 원인의 성격이 달라서 담당과 대응 절차가 다르다는 구분입니다.

"이번 분기 AI 개발 과제는 새 기능이 아니라 평가셋입니다. 지금은 답이 좋아졌는지 나빠졌는지 아무도 모릅니다."

기능을 더 붙이는 대신 품질을 재는 장치부터 만들겠다는 선언입니다.

"AI 개발 비용이 지난달 대비 두 배 나왔어요. 붙이는 자료를 줄이든 모델을 바꾸든 결정해야 합니다."

쓴 만큼 요금이 나가는 구조라 사용자가 늘면 비용도 같이 늘고, 그래서 기능 하나가 계속 관리해야 하는 변동비로 잡힌다는 뜻입니다.

페이지덱에서 이 일은 태오가 맡았습니다. 요약 사고 뒤에 태오가 가장 먼저 한 일은 요약을 고치는 것이 아니라, 실제 회의록 마흔 건을 골라 각각에 사람이 쓴 정답 요약을 붙여 두는 것이었습니다. 그 뒤로 지시문을 바꿀 때마다 마흔 건을 전부 다시 돌려 몇 건이 정답과 어긋나는지를 셉니다. 32건에서 36건으로 올라가면 반영하고, 그대로거나 내려가면 되돌립니다.

이 마흔 건이 하는 일은 하나 더 있습니다. 고객 불만이 새로 들어오면 그 사례를 묶음에 더해 두어서, 한 번 겪은 고장이 다음 변경에서 조용히 되살아나지 않게 막습니다.

지현은 이 숫자를 기능 출시 기준으로 씁니다. 새 AI 기능은 40건 중 몇 건을 넘겨야 나갈 수 있는지를 미리 정해 두고, 못 넘기면 날짜가 됐어도 내보내지 않습니다. 규원이 분기 회의에서 묻는 것은 두 가지입니다. 이번 달 모델 요금이 얼마인지, 그리고 그 돈으로 산 기능이 유료 전환에 실제로 도움이 됐는지입니다.

AI 개발을 프롬프트를 잘 쓰는 일과 같은 말로 여기는 오해가 가장 흔합니다. 데모가 지시문 한 줄로 만들어지니 그렇게 보일 만합니다. 실제로 제품에 나가는 기능에서 지시문이 차지하는 비중은 일부이고, 나머지는 어떤 자료를 찾아 붙일지 정하고, 길이를 한도 안에 맞추고, 틀린 답을 걸러 내고, 요금과 응답 시간을 재고, 바꾼 것이 나아졌는지 확인하는 배관입니다. 이 오해를 그대로 두면 팀은 몇 달 동안 지시문만 고치게 됩니다. 매번 어제보다 나아진 것 같다고 말하지만 증명할 방법이 없고, 반년 뒤에도 같은 고객 불만이 같은 빈도로 들어옵니다. 지시문을 고치는 일 자체가 문제가 아니라, 고친 결과를 재는 눈금이 없는 채로 고치는 일이 문제입니다.

모델이 좋아지면 이 일이 없어진다고 보는 것도 자주 나옵니다. 해마다 모델이 눈에 띄게 나아지니 자연스러운 기대입니다. 하지만 모델이 아무리 좋아져도 우리 회사의 문서와 고객 기록은 여전히 모델 바깥에 있고, 무엇을 보여 줘도 되는 사람인지 가리는 일도, 요금과 응답 시간을 감당 가능한 선에 두는 일도, 답이 틀렸을 때 책임 소재를 남기는 일도 제품 쪽에 남습니다. 이 기대를 붙들고 있으면 팀은 다음 모델을 기다리며 아무 배관도 만들지 않고, 정작 더 좋은 모델이 나온 날에도 그것을 제품에 붙일 준비가 안 되어 있습니다.