<div id="readability-page-1" class="page"><section itemprop="text">
 
 안녕하세요!
예전 사내 지식관리시스템에서 계정 생성 제한으로 새 동료를 못 받을 뻔했던 위기를 넘어, 
이제는 우리 팀의 든든한 AI 지식 창고가 된&nbsp;키냅스(Kynapse)&nbsp;개발 팀장 손상우입니다.

지난 포스팅에서 Outline 오픈소스 기반으로 뼈대를 세웠던 이야기를 드렸죠? 
오늘은 키냅스가 세상에 나오기 전, ‘AI 도입기’를 복기해보려 합니다.

지금은 매끄럽게 돌아가는 서비스지만, 런칭 직전까지 저희 개발팀은 AI를 길들이기 위해 정말 치열한 밤을 보냈거든요. 
“API 하나 연결하면 끝 아냐?”라고 생각했던 과거의 저에게 들려주고 싶은 그날의 기록, 지금 시작합니다.

<h2 id="smb의-생명줄-보안이라는-철창">SMB의 생명줄, ‘보안’이라는 철창</h2>

<figure>
 <img src="https://rerewww.github.io/assets/images/20260224/image1.png" alt="image1">
 <figcaption>Image generated by ChatGPT 5.2</figcaption>
</figure>

저희 타겟은 SMB(중소·중견기업)입니다. 
“우리 회사 기밀이 AI 학습에 쓰이면 어쩌지?”라는 고객의 원초적인 공포를 해결하지 못하면 런칭은 의미가 없었습니다. 
저희는 데이터 유출 걱정이 없는&nbsp;Private LLM&nbsp;환경을 최우선으로 고려했고, AWS 환경에서 서비스를 운영할 계획이었기에 자연스럽게&nbsp;AWS Bedrock을 검토하기 시작했습니다. 
25년 여름 무렵, 베드락에서 제공하는 ‘노바(Nova)’ 모델을 연동해 간단한 챗봇 테스트를 이어갔지만, 
기대보다 낮은 응답 품질이 발목을 잡았습니다.

결국 성능이 확실한 ‘클로드(Claude)’ 모델로 갈아탔는데, 결과물은 훌륭했지만 예상보다 비싼 가격이 문제였습니다. 
좋은 모델일수록 품질은 보장되지만 그만큼 비용 부담이 커지는 냉혹한 현실을 마주한 것이죠. 
이때 비로소 다른 서비스들이 왜 AI 기능을 계정당 1회만 제공하거나, 무료 토큰 소진 시 추가 결제를 요구하는지 그 이유를 뼈저리게 체감했습니다.

<figure>
 <img src="https://rerewww.github.io/assets/images/20260224/image2.png" alt="image2">
 <figcaption>Image generated by ChatGPT 5.2</figcaption>
</figure>

“하지만 저희는 ‘성장’과 ‘품질’이라는 두 마리 토끼를 잡기로 했습니다.”

아직 서비스 초기라 사용자 확보가 무엇보다 중요한 시점이고, 다행히 회사에서도 초기 비용을 감수하겠다는 통 큰 결단을 내려주셨습니다. 
덕분에 성능 좋은 고가의 모델을 사용자분들이 무료로 경험하실 수 있도록 열어두되, 안정적인 운영을 위해&nbsp;매일 계정당 10회라는 넉넉한 제한을 두는 것으로 합의를 봤습니다. 
“비싼 만큼 제값을 한다”는 원칙을 고수하며, 사용자가 처음 마주하는 응답 한 번에 멋진 경험을 제공하는 데 모든 역량을 집중하기로 한 셈입니다.

<h2 id="사내-지식의-내비게이션-rag-엔진-구축-분투기">사내 지식의 내비게이션, RAG 엔진 구축 분투기</h2>
저희에게 단순히 응답하는 AI는 필요 없었습니다. 
우리 회사의 ‘비급’ 같은 문서 속에서 정답을 콕 집어내는 시스템이 핵심이었죠. 
하지만 초기 설계는 마치 초보 운전자가 고속도로에서 급브레이크를 밟는 것과 같았습니다.

<figure>
 <img src="https://rerewww.github.io/assets/images/20260224/image3.png" alt="image3">
 <figcaption>Image generated by ChatGPT 5.2</figcaption>
</figure>

“서버가 살려달라고 비명을 지르는 소리 들어보셨나요?”

사용자가 문서를 저장할 때마다 실시간으로 임베딩(Vector 변환)을 돌렸더니, 트래픽이 조금만 몰려도 서버 CPU 점유율이 널뛰기를 하더군요. 
말 그대로 서버가 ‘뻗어버리는’ 과부하 상황이었습니다. 게다가 벡터 데이터가 쌓일수록 인프라 디스크 용량은 바닥을 드러내기 시작했죠. 
시스템 설계 관점에서 보면 ‘가용성’과&nbsp;’확장성’&nbsp;모두에 빨간불이 들어온 셈입니다.

<figure>
 <img src="https://rerewww.github.io/assets/images/20260224/image4.png" alt="image4">
 <figcaption>Image generated by ChatGPT 5.2</figcaption>
</figure>

저희는 즉시 아키텍처를 전면 수정했습니다. 
우선, 실시간 처리라는 강박을 버리고&nbsp;비동기 구조를 도입했습니다. 큐와&nbsp;스케줄러를 배치해 데이터를 한 줄로 세웠죠. 
“야, 한꺼번에 밀고 들어오지 말고 차례대로 처리해!”라고 교통정리를 한 겁니다.

벡터 DB로는 사내에서 이미 검증된 큐드란트(Qdrant)를 선택해 신뢰도를 높였고, 
디스크 부족 문제는&nbsp;AWS EBS를 유연하게 연동해 물리적인 저장 공간의 한계를 지워버렸습니다.

이 설계 변경은 런칭 후 대량의 문서가 쏟아질 때 진가를 발휘했습니다. 
서버는 평온을 되찾았고, 아무리 문서가 많아져도 시스템은 끄떡없었죠.

결과적으로 수만 권의 문서 사이에서 정답을 1초 만에 찾아내는 ‘지능형 내비게이션’이 완성되었습니다. 
시스템의 부하를 분산하고 인프라 유연성을 확보한 전략이 적중한 순간이었습니다.

<h2 id="마크다운은-왜-탈락했을까-ai의-문해력을-높인-html-정제-작전">마크다운은 왜 탈락했을까? AI의 문해력을 높인 ‘HTML 정제 작전’</h2>
개발 막바지, 다 된 밥에 재 뿌리는 격으로 예상치 못한 복병이 터졌습니다. 
문서 요약 기능이 자꾸 ‘헛소리’를 하기 시작한 거죠.

처음엔 단순하게 생각했습니다. “토큰(비용) 아껴야 하니 텍스트(PlainText)만 쏙 뽑아서 보내주자!” 
그런데 웬걸, 뼈대 없는 텍스트를 받은 AI는 문서의 제목이 뭔지, 어디까지가 표의 내용인지 도통 감을 못 잡더군요. 
데이터 계층 구조가 깨지니 요약 품질은 바닥을 쳤고, 저희의 야심작은 졸지에 ‘난독증 AI’가 될 위기에 처했습니다.

<figure>
 <img src="https://rerewww.github.io/assets/images/20260224/image5.png" alt="image5">
 <figcaption>Image generated by ChatGPT 5.2</figcaption>
</figure>

즉시 마크다운(Markdown)과&nbsp;HTML을 링 위에 올리고 끝장 테스트를 벌였습니다. 
마크다운은 가볍긴 했지만, 복잡한 표 구조나 중첩된 레이아웃을 설명하기엔 역부족이었습니다. 
반면 HTML은 구조 파악 능력이 월등했습니다. 문제는 ‘태그 지옥’이었죠. 
태그가 너무 많으면 비용이 폭발하니까요.

그래서 저희는 정공법을 택했습니다. 
‘불필요한 태그는 싹 걷어내고 의미 있는 뼈대만 남기는 정제 로직’을 구현했습니다. 
AI에게 “이건 표고, 이건 제목이야”라고 가장 친절하면서도 가볍게 알려주는 맞춤형 식단을 차려준 셈입니다.

결과는 성공이었습니다. 
아무리 복잡한 표 구조라도 AI가 척척 이해하며 고품질의 요약을 내놓기 시작했죠. 
게다가 데이터 최적화 덕분에 AI 호출 비용까지 절감할 수 있었습니다. 
데이터 전처리의 최적화를 통해 품질 향상과 운영 효율성이라는 상충하는 가치를 동시에 달성한 전략이었죠.

<h2 id="하드코딩의-늪에서-탈출하다-랭플로우langflow-에이전트로-갈아탄-이유">하드코딩의 늪에서 탈출하다: 랭플로우(Langflow) 에이전트로 갈아탄 이유</h2>
RAG 연동에 성공했을 때만 해도 다 끝난 줄 알았습니다. 
하지만 진짜 ‘지옥’은 그다음에 기다리고 있었죠. 
사용자의 수만 가지 질문 패턴을 코드로 일일이 대응하는 건 그야말로 끝이 없는 싸움이었습니다.

“프롬프트 한 줄 고치려고 서버 전체를 다시 빌드하던 시절을 상상해 보세요. 끔찍하지 않나요?”

유지보수의 한계와 재배포의 공포..&nbsp;초기에는 모든 AI 로직을 WAS에 전담했습니다. 
그러다 보니 예외 상황이 터질 때마다 프롬프트를 수정해야 했고, 그때마다 서비스 전체를 재배포해야 하는 리스크를 안고 살았습니다.

코드 베이스는 점점 복잡해졌고, 
“이러다 서비스가 산으로 가겠다”는 위기감이 엄습했습니다. 
시스템 디자인 관점에서 보면 ‘결합도(Coupling)’가 너무 높아 유연성이 완전히 실종된 상태였죠.

<figure>
 <img src="https://rerewww.github.io/assets/images/20260224/image6.png" alt="image6">
 <figcaption>Image generated by ChatGPT 5.2</figcaption>
</figure>

이 문제를 해결하기 위해&nbsp;’랭플로우(Langflow)’ 기반의 에이전트&nbsp;시스템을 도입했습니다. 
검색, RAG, DB 조회 같은 기능들을 각각의 독립된 ‘도구(Tool)’로 정의하고, 에이전트가 사용자의 의도에 따라 어떤 도구를 쓸지 스스로 판단하게 워크플로우를 짰습니다. 
즉, 복잡한 판단 로직을 코드에서 들어내어 별도의 에이전트 레이어로 분리한 것입니다.

이제 AI 로직을 수정할 때 WAS를 건드릴 필요 없이 에이전트 파드(Pod)만 살짝 갈아 끼우면 됩니다. 
유지보수 효율이 올라가고&nbsp;여기에 더해, AI가 답변을 내놓기 전 고민하는 ‘추론 단계’를 스트리밍으로 구현해 사용자에게 보여줄 수 있게 되었습니다. 
결과적으로 ‘애플리케이션 로직과 AI 추론 로직을 분리하여 시스템의 응집도를 높이고, 운영 안정성을 확보한 설계’였습니다.

<h2 id="글쓰기-도우미의-완성-검증된-에디터에-ai-한-스푼-얹기">글쓰기 도우미의 완성: 검증된 에디터에 AI 한 스푼 얹기</h2>
챗봇을 넘어 에디터 안에서 직접 문서를 생성하고 편집하는 고난도의 기능까지 구현해야 하는 과제가 남았습니다. 
모든 것을 밑바닥부터 개발하기엔 리소스가 부족했던 상황에서, 저희는 직접 개발하고 싶은 욕심을 잠시 내려놓고 20년 문서 기술이 집약된 사내 솔루션인 ‘사이냅 에디터’를 그대로 이식했습니다.

이미 검증된 강력한 에디터에 AI 인증 토큰과 API만 매끄럽게 연동한 결과, 14종의 업무용 템플릿을 자동 생성하는 ‘글쓰기 도우미’를 순식간에 완성할 수 있었습니다. 
개발 리소스를 아끼면서도 시장에 내놓아도 손색없는 편집 기능을 런칭 일정에 맞춰 선보이게 된 순간이었습니다.

<h2 id="에필로그">에필로그</h2>
사내 오픈 전날까지도 “정말 AI가 우리 의도대로 대답해줄까?”를 고민하며 모니터 앞을 지켰던 기억이 납니다. 
화려한 AI 기능 뒤에는 HTML 태그 하나와 씨름하고 토큰 한 알을 아끼려던 개발팀의 처절한 사투가 녹아있습니다. 
과연 이렇게 탄생한 키냅스는 실제 업무 현장에서 어떤 반응을 얻었을까요?

101번째 동료는 정말로 이 AI 비서의 도움을 받아 ‘일잘러’가 되었을까요? 
다음 주, 키냅스가 실제 업무 환경에 투입되어 일으킨 생생한 변화들을 들고 돌아오겠습니다!

이런 서비스, 우리 회사에도 시급하다면? 
👉 <a href="https://kynapse.ai/">kynapse.ai 더 알아보기</a>

 
 </section></div>

I Luv Console

안녕하세요!
예전 사내 지식관리시스템에서 계정 생성 제한으로 새 동료를 못 받을 뻔했던 위기를 넘어,
지난 포스팅에서 Outline 오픈소스 기반으로 뼈대를 세웠던 이야기를 드렸죠?
지금은 매끄럽게 돌아가는 서비스지만, 런칭 직전까지 저희 개발팀은 AI를 길들이기 위해 정말 치열한 밤을 보냈거든요.
SMB의 생명줄, ‘보안’이라는 철창
저희 타겟은 SMB(중소·중견기업)입니다.
결국 성능이 확실한 ‘클로드(Claude)’ 모델로 갈아탔는데, 결과물은 훌륭했지만 예상보다 비싼 가격이 문제였습니다.
“하지만 저희는 ‘성장’과 ‘품질’이라는 두 마리 토끼를 잡기로 했습니다.”
아직 서비스 초기라 사용자 확보가 무엇보다 중요한 시점이고, 다행히 회사에서도 초기 비용을 감수하겠다는 통 큰 결단을 내려주셨습니다.
사내 지식의 내비게이션, RAG 엔진 구축 분투기
저희에게 단순히 응답하는 AI는 필요 없었습니다.
“서버가 살려달라고 비명을 지르는 소리 들어보셨나요?”
사용자가 문서를 저장할 때마다 실시간으로 임베딩(Vector 변환)을 돌렸더니, 트래픽이 조금만 몰려도 서버 CPU 점유율이 널뛰기를 하더군요.
저희는 즉시 아키텍처를 전면 수정했습니다.
벡터 DB로는 사내에서 이미 검증된 큐드란트(Qdrant)를 선택해 신뢰도를 높였고,
이 설계 변경은 런칭 후 대량의 문서가 쏟아질 때 진가를 발휘했습니다.
결과적으로 수만 권의 문서 사이에서 정답을 1초 만에 찾아내는 ‘지능형 내비게이션’이 완성되었습니다.
마크다운은 왜 탈락했을까? AI의 문해력을 높인 ‘HTML 정제 작전’
개발 막바지, 다 된 밥에 재 뿌리는 격으로 예상치 못한 복병이 터졌습니다.
처음엔 단순하게 생각했습니다. “토큰(비용) 아껴야 하니 텍스트(PlainText)만 쏙 뽑아서 보내주자!”
즉시 마크다운(Markdown)과 HTML을 링 위에 올리고 끝장 테스트를 벌였습니다.
그래서 저희는 정공법을 택했습니다.
결과는 성공이었습니다.
하드코딩의 늪에서 탈출하다: 랭플로우(Langflow) 에이전트로 갈아탄 이유
RAG 연동에 성공했을 때만 해도 다 끝난 줄 알았습니다.
“프롬프트 한 줄 고치려고 서버 전체를 다시 빌드하던 시절을 상상해 보세요. 끔찍하지 않나요?”
유지보수의 한계와 재배포의 공포.. 초기에는 모든 AI 로직을 WAS에 전담했습니다.
코드 베이스는 점점 복잡해졌고,
이 문제를 해결하기 위해 ’랭플로우(Langflow)’ 기반의 에이전트 시스템을 도입했습니다.
이제 AI 로직을 수정할 때 WAS를 건드릴 필요 없이 에이전트 파드(Pod)만 살짝 갈아 끼우면 됩니다.
글쓰기 도우미의 완성: 검증된 에디터에 AI 한 스푼 얹기
챗봇을 넘어 에디터 안에서 직접 문서를 생성하고 편집하는 고난도의 기능까지 구현해야 하는 과제가 남았습니다.
이미 검증된 강력한 에디터에 AI 인증 토큰과 API만 매끄럽게 연동한 결과, 14종의 업무용 템플릿을 자동 생성하는 ‘글쓰기 도우미’를 순식간에 완성할 수 있었습니다.
에필로그
사내 오픈 전날까지도 “정말 AI가 우리 의도대로 대답해줄까?”를 고민하며 모니터 앞을 지켰던 기억이 납니다.
101번째 동료는 정말로 이 AI 비서의 도움을 받아 ‘일잘러’가 되었을까요?
이런 서비스, 우리 회사에도 시급하다면?
kynapse.ai 더 알아보기

AI를 붙이는 건 어렵지 않았다. 그 다음이 문제였다: 키냅스(kynapse) AI 도입기

댓글