현업에서는 이렇게 AI를 운영한다 - 구름 커밋 후기

AI 서비스를 직접 만들고 운영하는 세 명의 실무자가 나눈 대화를 들었다. 이론서에 없는 현장 이야기가 많아서 메모하면서 계속 끄덕였다. 인상 깊었던 것들을 적어본다.

---

틀린 이유를 쪼개야 고칠 수 있다

AI 응답이 틀렸을 때 그냥 "틀렸다"고 넘기면 막막하다. 패널들이 오류를 네 가지로 쪼개서 분석한다는 이야기를 듣고, 이건 실무적으로 당장 써먹겠다 싶었다.

문맥 파악 실패면 프롬프트를 고치고, 데이터 검색 실패면 RAG 파이프라인을 고치고, 데이터 조합 실패면 청킹이나 검색 로직을 점검하고, 최종 생성 실패면 모델이나 파인튜닝을 의심한다. 각각 해결책이 다르니까 원인을 먼저 분리하는 게 시작이라는 생각이 들었다.

재현성 이야기도 나왔다. 100번 같은 질문했는데 99번은 같고 1번 다르게 나온다면, 이게 AI의 본질이라고 한다. 무결성이 중요한 도메인에서는 휴먼 에러 발생 가능성을 2% 이하로 잡고 거기에 맞춰간다고. LangFuse, LangSmith 같은 도구로 지속적인 평가를 자동화한다는 이야기도 들었는데 당장 찾아봐야겠다.

---

어제 된 게 오늘 안 된다

이 부분이 제일 와닿았다. 모델도 고정하고 시스템 프롬프트도 고정해도 DB는 항상 바뀔 수 있고, 벤더 정책 변경이 언제든 영향을 준다.

2,000명이 온라인 시험을 보고 있었는데 갑자기 특정 유저 요청에서 에러가 터진 사례가 있었다. 원인은 Azure 콘텐츠 정책. 환경 파괴 관련 수학 문제가 프롬프트에 포함되어 있었는데, 이게 Azure 금지 조항에 걸린 것. 시험 중에 이런 일이 터지면 진짜 난감하다.

"벤더가 끼는 경우에는 정말 예측을 할 수가 없습니다. 가장 중요한 건 모니터링할 수 있는 수단을 만들어두는 겁니다."

이 말이 계속 머릿속에 남았다. 결국 트레이싱, 폴백 전략, 휴먼 인 더루프 설계가 다 기본기다.

개체 인식 태스크에서 LLM과 파인튜닝 모델을 비교한 경험도 나왔다. LLM은 정확도 50% 미만, 파인튜닝 모델은 80% 이상. 비용도 느리고 비싸고. "이 정도 태스크에 LLM이 필요한 건지 명확히 하는 게 중요합니다"라는 말에 고개가 끄덕여졌다.

---

토큰 비용, 보이지 않는 폭탄

한 은행에서 2만 명 임직원용 AI 어시스턴트를 만들고 싶다고 했다. Notion AI가 이미 있는데도. 계산해보니 Notion AI 2만 명 × 월 1만 원 = 월 2억, 연 24억. "그러니 차라리 만드는 게 낫지 않겠나?"인데, 실제로 개발하면 24억으로도 부족할 수 있다고. 인프라, 유지보수 인력, 운영 비용까지 합치면 공짜 SaaS를 쓰는 게 나을 수도 있다.

"살 수 있으면 사서 쓰세요. 만들면 버그입니다."

비용 관리 팁도 몇 개 들었다. 시스템 프롬프트 3,000자가 매 요청마다 누적되면 토큰이 기하급수적으로 증가하니까 캐싱이 필수. 파인튜닝으로 시스템 프롬프트를 줄이는 것도 방법인데, 200개 데이터만으로도 파인튜닝이 가능하다고. 그리고 자율형 에이전트(Cursor, Windsurf)의 토큰 소모는 진짜 무섭다. "실험 하나 돌렸는데 몇 달러가 날아갔습니다"라는 경험담이 나왔다.

---

정확도, 속도, 비용 중 하나는 포기해야 한다

증권사 사례가 재밌었다. 정확도 KPI 다 맞춰놨는데 회장님이 "느리다"고 해서 낮은(빠른) 모델로 바꿨다. 정확도가 떨어졌지만 실제로는 큰 문제가 안 됐다고 한다. 속도가 체감 품질에 더 큰 영향을 줬던 셈.

B2C 서비스도 비슷했다. 초기에 정확도를 포기하고 속도를 선택했다고. 일반 사용자들은 AI가 틀려도 "내가 질문을 잘못했나 보다"라고 생각하는데, 속도가 느리면 바로 컴플레인이 온다. AI 역량 평가 서비스다 보니 정답을 직접 주면 안 돼서 검증 모델을 여러 단계로 꽂아놨는데, 한 번 요청에 최대 5배의 LLM 호출이 발생했다고.

같은 서비스 안에서도 영역마다 다르게 갔다. UX 어시스턴트는 속도 우선으로 빠른 모델, 채점 시스템은 정확도 우선으로 느려도 정확한 모델. "시기에 따라, 서비스 성숙도에 따라 중요도를 다르게 가져갔습니다"라는 말이 실감났다.

---

보이지 않던 페인포인트가 가장 큰 가치

시험 감독 AI 사례는 좀 충격이었다. 기존에 60~100명 감독관이 2시간 동안 모니터를 보며 스크린샷을 찍었는데, AI 도입 후 2명이 처리하게 됐다. L사 사례도 비슷. 연간 6,000~7,000명 시험에 20명당 감독관 1명이 필요했는데, AI 도입 후 감독관 인력 대폭 축소, 비용 약 50% 절감, 휴먼 에러율 감소. 최종 검증은 여전히 사람이 하지만 AI가 스냅샷을 떠서 전달하니까 고객 만족도가 높았다고.

그런데 제일 기억에 남는 건 "보이지 않던 페인포인트" 이야기. 데이터 분석 도구를 제공하면서 발견한 건데, 사람들이 차트와 숫자를 해석하는 것 자체가 큰 부담이었다. AI가 해석만 해줘도 사용자들이 크게 감동했다고.

"우리는 그냥 보여주면 끝이라고 생각했는데, 사실 해석을 해야 하는 부하가 있었습니다. 그것을 줄여주는 것만으로도 정말 많이들 좋아하시더라고요."

듣고 나서, 사용자가 당연하다고 생각하는 부담이 사실 가장 큰 기회일 수 있겠다는 생각이 들었다.

---

바이브 코딩, 생산성은 올랐는데 블랙박스도 커졌다

미국 기준 개발자의 약 60%가 바이브 코딩(에이전트 코딩)으로 코드를 생산하고 있다고 한다. Cursor, Windsurf가 보편화되면서 "코드에 손을 대는 일이 없어졌다"는 반응이 많다고.

한 4년차 개발자의 고백이 인상적이었다.

"바이브 코딩으로 생산 속도가 너무 빨라지다 보니, 원래 하던 단위 테스트, 블랙박스 테스트를 훨씬 더 빡세게 해야 하는데... 코드 단위로 리뷰하면 문제가 없어 보이는데, 설계 단위로 합쳤을 때 정말 원활하게 돌아가는지 검증하기가 점점 어려워집니다."

솔직히 나도 이 고민이 있다. AI가 빠르게 코드를 써주니까 리뷰가 뒤로 밀리고, 합쳤을 때 터지는 문제는 점점 더 잡기 어려워진다.

패널들이 제안한 대응도 공감됐다. TDD가 더 중요해진 시대라는 거. 테스트 코드도 AI가 짜줄 수 있으니 테스트를 소홀히 할 이유가 없다. 수천 개 테스트 중 정말 호흡이 맞아야 하는 10~20개만 뽑아서 집중 관리하고, 코드 리뷰뿐 아니라 DB 설계, 도메인 간 관계 등 설계 단위 리뷰도 필수.

"생산 속도가 빨라진 만큼, 퀄리티 컨트롤은 더 체계적으로 해야 합니다."

 

---

모델이 바뀌면 다시 한다

GPT 모델이 바뀔 때마다 시스템 프롬프트, 청킹 전략, 임베딩 등을 다시 설정해야 한다. 한 프리랜서 플랫폼은 매칭 자동화를 구축해놨는데 모델이 바뀔 때마다 처음부터 다시 세팅해야 했다고.

Bedrock/Azure를 쓰면 버전이 픽스되어 있어서 안정성은 확보된다. 하지만 언젠가는 업그레이드해야 하니까, 새 모델이 나올 때마다 패스/페일 기준으로 검증하고 버전별로 시스템 프롬프트를 따로 관리해야 한다.

시스템 프롬프트를 3,000자로 관리하면 매 요청마다 누적되어 토큰 폭발. 파인튜닝으로 시스템 프롬프트를 줄이면 토큰 사용량이 급감하지만 성능 저하 각오. 결국 모델 의존도가 낮을수록 유지보수 비용이 줄어든다.

OpenAI API 호출 시 같은 질문인데도 어떤 때는 빠르고 어떤 때는 느리다. 원인은 리전 선택과 트래픽 집중. 한국 리전에 트래픽이 몰리면 유럽 리전으로 우회하는 식의 대응이 필요하다고 한다.

---

현장에서 직접 부딪히는 분들의 이야기를 들으니, 이론으로 알던 것들이 확실히 다르게 들렸다. 특히 "어제 된 게 오늘 안 되는 게 정상"이라는 말과, 사용자가 당연하다고 생각하는 해석 부담을 줄여주는 것만으로도 큰 가치가 된다는 이야기는 앞으로 서비스 설계할 때 계속 떠오를 것 같다.

---