AI 도입, 프롬프트를 고쳐도 안 되는 이유 | 볼 곳 6가지

📰 2026년 8월 26일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.

“프롬프트를 열 번쯤 고쳤는데 아직도 엉뚱한 답을 내요.”

AI 기능을 붙여본 회사에서 자주 나오는 말이에요. 그러면 프롬프트를 또 고치게 되고, 모델을 비싼 걸로 바꿔보고, 그래도 안 되면 도입 자체를 접어요.

8월 25일 CIO에 실린 기고문 하나가 이 상황을 정면으로 다뤘어요. 제목이 「기업용 AI 경쟁은 플랫폼 팀이 이끈다, 프롬프트 엔지니어가 아니다」예요. 요지는 간단해요. AI가 틀리는 이유는 대개 모델이 아니라 그 뒤에 있다는 거예요.

1. 어떤 이야기였나요

기고자는 플랫폼을 만들어온 경험에서 출발해요. 기업 AI 이야기는 결국 프롬프트로 수렴하는데, 프롬프트를 잘 쓰면 결과가 바로 눈에 보이니까 그렇다는 거예요. 빠르고 뚜렷한 성과라 거기에 시선이 몰려요.

그런데 데모와 매일 돌아가는 업무는 다른 물건이에요. 한 번 잘 나온 답을 계속 잘 나오게 만들려면 반복 가능한 전달과 검증, 맥락, 통제가 필요해요. 기고자의 결론은 이렇게 정리돼요.

“AI 경쟁에서 이기는 조직은 프롬프트를 가장 잘 쓰는 곳이 아니라, 가장 튼튼한 사내 플랫폼을 만든 곳이 될 거예요.”

2. AI가 틀릴 때 대개 모델 잘못이 아니에요

기고문이 짚은 실패 원인이 흥미로워요. AI 답변이 어긋날 때 뿌리를 따라가 보면 네 가지 중 하나인 경우가 많다고 해요.

• 데이터가 오래됐어요
• 불러야 할 API가 응답하지 않아요
• 권한이 시스템마다 제각각이에요
• 연동을 담당하는 서비스가 불안정해요

넷 다 모델 밖의 문제예요. 프롬프트를 아무리 정교하게 써도 어제 자 재고를 보고 답하면 답이 어긋나요. 저희도 AI 기능을 붙이는 프로젝트에서 첫 두 주를 대개 여기에 써요. 모델을 고르는 시간보다 “이 데이터가 지금 어디에 어떤 모양으로 있나”를 확인하는 시간이 길어요.

3. AI 하나가 실제로 건드리는 것들

기고문에 나온 예가 구체적이에요. 쓸모 있는 업무 하나를 AI에게 맡긴다고 해볼게요. 고객 문의에 답하는 일이에요.

이 한 번의 응답을 위해 AI는 CRM에서 고객 정보를 가져오고, ERP에서 재고를 확인하고, 결재 흐름을 시작하고, 상담 티켓을 갱신하고, 협업 도구에 알림을 보내요. 사용자 눈에는 대화창 하나지만 뒤에서는 사내 시스템 여러 개가 순서대로 움직여요.

여기서 필요한 건 프롬프트 기술이 아니에요. 믿을 수 있는 API와 사건이 생기면 알아서 다음으로 넘어가는 구조예요. 이게 없으면 다섯 번 중 한 번은 중간에서 끊겨요.

용어 하나만 풀어둘게요. API는 시스템끼리 정해진 방식으로 말을 주고받는 창구예요. 창구가 없으면 사람이 엑셀로 옮겨 붙이는 수밖에 없어요. 실무에서는 “그 시스템 API 열려 있어요?”라고 물어보는데, 이 질문의 답이 ‘no’면 AI 프로젝트 일정이 대개 몇 주 늘어나요.

4. 플랫폼 팀이 만든다는 게 뭘까요

말이 추상적이라 기고문이 나열한 항목을 발주자 말로 옮겨봤어요.

기고문 표현	발주자 말로 옮기면
표준 API와 재사용 서비스	시스템마다 다르게 만든 연결을 한 방식으로 정리하는 일
신원 관리와 접근 통제	누가 어디까지 볼 수 있는지를 한 곳에서 정하는 일
데이터 거버넌스	어떤 자료를 AI에 보내도 되는지 정해두는 일
배포 자동화	고친 걸 사람이 손으로 올리지 않게 만드는 일
관측과 로깅	무슨 요청이 오갔고 얼마가 나갔는지 남기는 일
AI 게이트웨이·모델 오케스트레이션	여러 모델을 상황에 맞게 갈아 끼우는 통로
벡터 DB와 검색	우리 문서에서 근거를 찾아오는 부분
정책 집행	하면 안 되는 요청을 자동으로 막는 규칙

여덟 개를 다 갖춘 회사는 드물어요. 그래도 목록으로 보면 왜 프롬프트만 고쳐서는 안 되는지가 보여요. 프롬프트는 이 여덟 개 위에 얹는 마지막 한 겹이에요.

기고문은 NIST의 AI 위험관리 프레임워크를 인용하면서 한 가지를 덧붙여요. 신원 확인과 감사 기록, 규정 준수는 배포 직전에 통과시키는 관문이 아니라 바닥에 깔아두는 것이라는 이야기예요. 나중에 붙이면 이미 쌓인 데이터를 되짚어야 해서 값이 훨씬 커져요.

5. 개발자 역할도 같이 바뀌고 있어요

같은 시기에 GitHub 블로그에도 비슷한 결의 글이 올라왔어요. 제목은 「코더에서 오케스트레이터로」예요.

프롬프트 한 번으로 그럴듯한 데모를 만드는 건 쉬워졌는데, 안정적이고 안전하게 코드를 만들어내는 체계를 세우는 건 다른 일이라는 이야기예요. 개발자가 코드를 쓰는 동시에 코드가 어떻게 제안되고 검증되고 리뷰되고 배포될지를 설계하는 쪽으로 옮겨가고 있다고 봤어요.

OpenAI 코덱스 같은 코딩 에이전트를 붙여본 팀이라면 이 감각을 알 거예요. 만들어내는 양은 늘어나는데 확인해야 할 양이 같이 늘어요. 그래서 병목이 작성에서 검증으로 옮겨가요.

발주자 입장에서 이게 왜 중요하냐면, 견적서에 “AI로 개발 기간을 단축합니다”라고만 적혀 있을 때 무엇을 되물어야 할지가 여기서 나오기 때문이에요. 줄어드는 건 작성 시간이고, 늘어나는 건 검토 시간이에요. 두 개를 함께 적어둔 견적서가 정직한 견적서예요.

6. 그래서 견적서에서 볼 6가지

AI 기능을 외주로 맡길 때 위 이야기를 그대로 확인 항목으로 바꾸면 이렇게 돼요.

1. 데이터 출처와 최신성 — 어떤 시스템에서 가져오고 얼마나 자주 갱신되나요
2. 연동 대상 목록 — 붙일 시스템이 몇 개이고 API가 열려 있나요
3. 권한 설계 — 사용자 등급별로 AI가 볼 수 있는 범위가 나뉘나요
4. 기록 — 요청과 응답, 비용이 어디에 어떤 단위로 남나요
5. 실패 처리 — 중간 단계가 응답하지 않을 때 무엇을 하나요
6. 모델 교체 여지 — 다른 모델로 바꿀 때 무엇을 다시 만들어야 하나요

여섯 개 중 3번과 4번이 특히 자주 빠져요. 화면에 안 보이는 항목이라 견적을 줄일 때 먼저 사라지는데, 없으면 오픈 뒤에 제일 아쉬운 자리이기도 해요.

7. 처음부터 다 만들 필요는 없어요

여덟 가지 목록을 보면 부담스러워요. 그런데 한 번에 다 만드는 회사는 없어요.

저희가 권하는 순서는 이래요. 먼저 업무 하나를 고르고, 그 업무가 건드리는 시스템만 정리해요. 대개 두세 개예요. 그 두세 개에 대해서만 접근 방식을 표준으로 맞추고 기록을 남기게 해요. 여기까지가 첫 단계예요.

두 번째 업무를 붙일 때 첫 단계에서 만든 걸 그대로 재사용할 수 있으면 방향이 맞은 거예요. 매번 처음부터 다시 연결하고 있다면 그때가 구조를 정리할 시점이에요.

자체 SaaS 4종을 직접 운영하면서 배운 게 하나 있어요. 초기 기능보다 운영 구조가 비용을 더 자주 바꿔요. AI 기능도 다르지 않아요. 붙이는 데 드는 값보다 붙이고 나서 매달 나가는 값이 판단을 좌우해요.

8. 자주 묻는 질문 (FAQ)

AI 에이전트 도입을 검토 중인데, 사람부터 뽑아야 할까요 시스템부터 손봐야 할까요?

순서로는 시스템 쪽이 먼저예요. 프롬프트를 잘 쓰는 사람이 붙으면 데모는 빨리 나오지만, 그게 매일 돌아가는 업무가 되려면 데이터를 어디서 가져올지, 누구 권한으로 접근할지, 실패하면 어디에 남을지가 정해져 있어야 해요. 사람을 나중에 뽑으라는 뜻이 아니라, 들어와서 만질 바닥이 있어야 한다는 뜻이에요.

AI 자체 도입과 외주 개발 중 어떤 선택이 맞나요?

이미 표준화된 API와 권한 체계가 있으면 자체 도입이 빨라요. 사내 데이터가 엑셀과 메일함, 오래된 관리자 화면에 흩어져 있다면 그 연결 작업이 프로젝트의 몸통이 되는데, 이건 해본 사람이 붙는 편이 시간을 아껴요. 기준을 하나만 꼽자면 지난 1년 안에 시스템끼리 데이터를 주고받는 연동을 직접 만들어본 적이 있는지예요.

AI 기능 견적서에서 가장 자주 빠지는 항목은 뭔가요?

관측과 기록이에요. 화면과 모델 연동은 대개 적혀 있는데, 어떤 요청이 어떤 결과를 냈고 비용이 얼마 나갔는지 남기는 부분이 빠져요. 이게 없으면 두 달 뒤에 “어느 기능이 돈을 쓰는지 모르겠다”는 상태가 돼요.

9. 마무리

프롬프트를 고치는 건 값싸고 빨라요. 그래서 먼저 손이 가요. 그런데 열 번 고쳐도 같은 자리에서 어긋난다면, 그건 문장 문제가 아니라 그 문장이 참고하는 자료와 통로 문제일 가능성이 커요.

저희는 AI 프로젝트를 볼 때 모델 이름보다 연동할 시스템 개수를 먼저 세요. 10년 넘게 50개가 넘는 프로젝트를 진행하고 자체 SaaS 4종을 운영해오면서, 값이 갈리는 자리가 대개 거기였거든요. 롯데·캐논 같은 곳과도 함께해 왔고요.

AI를 어디에 먼저 붙일지 아직 정하지 못하셨어도 괜찮아요. 업무 목록만 들고 오시면 어느 것부터가 현실적인지 같이 골라볼 수 있어요 →

함께 보면 좋은 글이에요.

• AI 도입 비용, 얼마부터 시작하고 어디에 돈이 들까요
• AI 에이전트에 권한을 줄 때 정할 4가지
• AI 프로젝트, 외주와 자체 개발 중 무엇이 맞을까요