Skip to main content

Command Palette

Search for a command to run...

"고객 인터뷰는 해봤어?" — RAG 프로젝트 회고

Updated
3 min read

AI가 나에게 물었다. "고객 인터뷰는 해봤어?" 이 질문 하나로 개발 프로세스가 바뀌었다.

프로젝트 개요

이 프로젝트는 상담 추천 시스템(콘텐츠 기반 필터링)을 만들기 위해 벡터 DB를 설계하고 POC를 해보는 과정에서 파생됐다. 2026년 3월부터 1주 단위 스프린트 4번으로 4주 동안 기획·디자인·FE·BE·AI 개발을 1인으로 진행했다. 원래는 유사한 상담을 벡터 검색으로 추천해주는 모듈을 개발 중이었다. 여기서 아이디어를 확장하여 새로운 상담이 들어왔을 때 벡터 검색으로 유사 상담을 찾고, 그 내용을 기반으로 LLM이 답변 초안을 작성해주는 RAG 시스템을 개발했다.

상담 초안 AI 프로젝트 진행 과정 — 4주 스프린트 사이클과 피드백 수집 방식 3단계 진화

일단 MVP로 부딪혀 보기

초기 요구사항을 모아 벡터 DB 인프라를 세팅하고 MVP를 배포했다. 이후 일주일 단위로 피드백 → 개발 → 결과 발표 사이클로 스프린트를 구성했다.

고객은 AI와 일을 해본 적이 없기 때문에, 워터폴 방식으로 명확한 요구사항과 기획을 받아낼 수 없었다. 그래서 일단 초기 요구사항을 반영해 MVP를 만들고, 계속 부딪혀 보면서 개발했다.

피드백이 휘발되는 문제

이 스프린트에서 가장 중요했던 파트는 고객 피드백이었다. 피드백을 제대로 받아야 고객이 필요로 하는 방향으로 개발이 진행될 수 있었다. 처음에는 두 가지 방식으로 피드백을 수집했다. 하나는 스프린트 결과 발표 자리에서 받는 구두 피드백, 다른 하나는 초안을 참고한 뒤 '적용' 버튼을 누를 때 뜨는 설문 폼(긍정·부정 버튼 + 텍스트 입력)이었다.

그런데 이 두 방식 모두 상담 작성 중간 과정이 아닌 결과 시점에 받는 피드백이었다. 고객이 상담 답변 중 언제 반복 작업이 일어나는지, 병목이 되는지 등— 이런 중요한 맥락이 제출 버튼 앞에서 휘발되고 있었다.

AI가 던진 질문, "고객 인터뷰는 해봤어?"

피드백을 어떻게 하면 잘 받을 수 있을까를 고민하면서, 브레인스토밍을 위해 gstack 하네스로 AI와 질문을 주고받고 있었다. 그 중 AI가 "너 고객 인터뷰는 해봤냐"고 물었다. 그동안 내가 수집하던 건 "결과"뿐이었고 "전체 과정"은 놓치고 있었음을 깨닫고, 바로 쉐도잉 세션을 조율했다.

현장에서 본 광경은 예상 밖이었다. 상담 과정에서 AI 초안은 고객의 작업 흐름 어디에도 자연스럽게 끼어들지 못하고 있었다. 그동안 스프린트에서는 "AI 파이프라인의 정확도"를 계속 올리려 했지만, 쉐도잉을 통해 더 중요한 이슈를 파악할 수 있었다. 초안이 아무리 정확해도, 작성 흐름에 들어갈 자리가 없으면 쓰이지 않는다. 정확도보다 먼저 확보해야 하는 건 사용성이었다. AI 초안이 고객의 루틴에 자연스럽게 끼어들 수 있게 UX부터 개선했다. 그 결과 초안 활용도가 올라갔고, 그제서야 피드백 루프가 의미 있게 돌기 시작했다.

결과물

4주 끝에 완성된 시스템은 다음과 같다.

  • 5개 이상의 LLM 파이프라인으로 구성된 RAG 상담 초안 작성 엔진 (파이프라인별 모델·비용 최적화)

  • 벡터 DB 기반 유사 상담 검색 모듈 — 초안 작성의 근거로 활용

  • 위키형 각주 인용 UI — 초안의 각 문장에 근거가 된 상담을 링크로 제공, 고객이 참고 논문처럼 원문을 즉시 확인 가능

인사이트

이전까지 나에게 AI는 내가 쓸 코드를 더 빨리 쓰게 해주는 도구였다. 이미 아는 방향으로 가속시켜주는 역할. 바퀴를 더 나은 바퀴로 만드는 건 가능해도, 바퀴를 뛰어넘는 무언가를 새로 제안하는 건 아직 어렵다고 생각했다.

이번 스프린트를 계기로 그 생각이 바뀌었다. AI는 내가 고민하던 틀 밖의 새로운 방향을 제시했고, 그게 프로젝트에 주요하게 작용했다. 적절한 하네스 환경과 충분한 맥락이 주어지면, AI도 아이디어 파트너가 될 수 있다.

4주 내내 사고가 계속 확장되는 경험이었다. 벡터 DB POC를 해보려다가 RAG로 넓어지고, AI와 브레인스토밍하다가 AI에게 사용자 인터뷰를 제안받고, 일하다 보니 "어, 요즘 많이 언급되는 FDE(Forward Deployed Engineer)처럼 일하고 있었네" 하고 또 깨닫고 — 하다 보니 "이게 이거였구나" 싶은 순간이 연달아 찾아왔다. 덕분에 즐겁게 인사이트를 얻으며 일할 수 있었다. AI와의 협업이 없었더라면 이 기간 내로 만드는 것은 도저히 불가능했을 것이다.


프로젝트 정보

  • 기간: 2026.03 — 2026.04 (4주, 1주 단위 스프린트 4회)

  • 스택: RAG - 벡터 DB(Faiss), LLM 파이프라인, NestJS, TypeScript

  • 역할: 1인 풀스택 (기획·디자인·FE·BE·AI, PO 디자이너 동료 분들 도움 한 꼬집씩 😂)

17 views

More from this blog

『인스파이어드』를 읽고 — 엔지니어의 시선으로

책에 대하여 『인스파이어드』는 IT 제품(앱, 웹, 일반 프로그램 등)을 어떻게 하면 더 잘 만들 수 있을지 가이드를 주는 책이다. 특히 IT 제품팀과 제품 관리자의 관점에서 중요한 내용이 많이 수록되어 있다. 나는 엔지니어로서 더 나은 제품팀을 만드는 데 어떻게 기여할 수 있을지, 그리고 엔지니어링 기술력을 어떻게 효율적으로 활용할 수 있을지에 대한 관점으로 읽어나갔다. 엔지니어의 역할에 주목하며 대부분의 내용은 제품팀과 제품 관리자, 그리고...

Jul 30, 20242 min read10

API 응답 속도가 얼마나 빨라야될까? (페이지 로딩시간, API TPS, latency)

안녕하세요. 팀에서 최근 들어 API 최적화에 대한 논의가 이루어지면서, API의 응답 속도에 대한 기준과 논리가 필요하여 몇 가지 찾아 정리해보았습니다. ## 왜 API 응답 속도가 빨라야 할까요? 사용자가 서비스를 기다리는 페이지 로드 시간이 곧 비용이기 때문입니다. 긴 페이지 로딩 시간은 서비스 트래픽과 전환율에 악영향을 줍니다. (자료가 과장됐거나 정확하지 않을 수는 있겠지만, 일관된 언급이 신뢰성을 준다고 생각합니다.) 기존에 페이지...

Jan 5, 20231 min read8

typeORM에서 timezone 올바르게 적용하기

글로벌 서비스를 대비하여, typeORM 사용시 DB 타임존을 어떻게 적용할지 정리하였습니다. typeORM 사용시 다음 절차를 통해, 타임존을 올바르게 설정해 사용할 수 있습니다. DB 타임존 확인하기 typeORM의 타임존 설정 설정된 타임존 확인하기 DB 타임존 확인하기 DB의 타임존은 다음 쿼리로 확인할 수 있습니다. 현재 저는 AWS RDS mySQL을 사용하고 있어서, 파라미터 그룹 변경을 통해 타임존을 설정할 수 있어요. 참고자...

Dec 29, 20221 min read

4년차 초보 개발자의 성장 방법

개발자로써 밥을 먹은 지 4년차가 되었다. 일하면서 배울수록 모르는 것, 배울 것이 많이 보이고, 업무 범위와 책임이 커졌다. 특히 팀장으로써의 직무를 수행하면서 나, 개인에 대한 성장 뿐만아니라 팀의 성장, 회사의 성장을 고민하게 되었다. 동료 개발자들과 일하면서 “4년 동안 어떻게 실력을 키울 수 있었느냐”에 대한 질문을 많이 받았다. 이에 대해서 명확하게 말로 설명할 수 없었던, 정리되지 않은 것들이 있었고, 지금까지 개발하면서 성장하는데...

Sep 7, 20223 min read2
D

dev-marco-song

42 posts

Hi there 👋 백엔드 개발자 마르코입니다.

A natural-born problem solver. I can do this all day :)