AI 통합 시 과도한 엔지니어링을 멈추세요 (아직은)

벡터 데이터베이스 (Vector Database)가 필요하지 않습니다. LangChain도 필요 없습니다. RAG (Retrieval-Augmented Generation) 인프라를 구축하기 위해 2주를 보낼 필요도 없습니다.

진심입니다. 여러분 대부분은 아직 존재하지도 않는 문제를 해결하려 하고 있습니다.

진짜 문제

저는 팀들이 기본적인 프롬프트 엔지니어링 (Prompt Engineering)과 API 호출을 사용하여 하루 만에 유용한 것을 출시할 수 있었음에도 불구하고, 정교한 AI 시스템을 구축하는 데 문자 그대로 몇 달을 소비하는 것을 보아왔습니다. 실제로 일어나는 일은 다음과 같습니다:

당신은 앱에 AI 기능을 추가하고 싶어 합니다. 그래서

• 문서가 컨텍스트 (Context)에 담기에는 너무 큽니다 — Claude의 컨텍스트 윈도우 (Context window)는 200K 토큰입니다. 이는 대략 15만 단어에 해당합니다. 실제로 이 용량을 초과하는 문서를 얼마나 가지고 계십니까?
• 수천 개의 문서가 있어 시맨틱 검색 (Semantic search)이 필요합니다 — "언젠가 생길지도 모를 상황"이 아니라, "지금 당장 문서가 수천 개이고 검색 기능이 실제로 작동하지 않는 상황"이어야 합니다.
• 지연 시간 (Latency)이 매우 중요합니다 — 문서를 동적으로 검색하면 밀리초 (ms) 단위의 시간이 추가됩니다. 때로는 이것이 중요할 수 있지만, 대부분의 경우에는 그렇지 않습니다.
• 비용이 걸림돌입니다 — 매 요청마다 전체 지식 베이스 (Knowledge base)를 전송하면 비용이 누적됩니다. 하지만 먼저 수학적으로 계산해 보세요. 생각보다 놀라운 결과가 나올 수도 있습니다.

실제로 효과가 있는 방법

팀들이 성공을 거둔 로드맵은 다음과 같습니다:

1주 차: 단순한 프롬프팅 (Prompting). API를 작동시키고 토큰 비용을 파악합니다. 이 방식이 귀하의 유스케이스 (Use case)에 실행 가능한지 빠르게 알 수 있을 것입니다.

2~3주 차: 프롬프트 최적화. 컨텍스트 (Context) 추가. 아마도 기본적인 캐싱 (Caching) 구현. 많은 문제들이 이 단계에서 해결됩니다.

4주 차 이상: 실제로 무언가 작동하지 않을 때만, 이를 해결하기 위한 인프라 (Infrastructure)를 구축합니다.

어려움을 겪는 팀들은 4주 차부터 시작하는 팀들입니다.

저는 한 콘텐츠 큐레이션 도구에 AI를 통합하는 것을 도운 적이 있습니다. 그들의 초기 본능은 무엇이었을까요? 기사를 저장하고, 임베딩 (Embedding)하고, 시맨틱 검색을 수행하는 RAG (Retrieval-Augmented Generation) 시스템을 구축하는 것이었습니다.

대신 저는 이렇게 말했습니다: "그냥 단순한 프롬프트와 함께 기사 텍스트를 Claude에게 직접 보내세요."

그것은 작동했습니다. 비용은 기사당 0.002달러였습니다. 처리 시간은 2초였습니다.

6개월 후, 그들이 수천 개의 기사를 보유하게 되었고 더 나은 필터링이 필요해졌을 때, 그때 벡터 데이터베이스 (Vector database)를 추가했습니다. 하지만 그때쯤 그들은 자신들에게 실제로 무엇이 필요한지에 대한 진짜 데이터를 가지고 있었습니다.

숨겨진 이점

단순하게 시작하면 실제로 무슨 일이 일어나고 있는지 이해할 수 있습니다. 디버깅 (Debugging)할 수 있고, 팀원들에게 설명할 수 있으며, 빠르게 반복 (Iterate)할 수 있습니다.

첫날부터 RAG 인프라를 구축하면, 제품을 개선하는 대신 LangChain 에러를 디버깅하게 될 것입니다.

결론

데모에서 보았기 때문이 아니라, 그것이 필요하다는 증거가 있을 때 복잡성을 추가하세요.

여러분의 첫 번째 AI 기능은 지루해야 합니다. 두 번째 기능부터 화려하게 만들 수 있습니다.

먼저 출시하세요. 과도한 생각은 나중에 해도 됩니다.