Skip to content
dev-marco-song
Go back

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

Edit page

최근 4주 동안 RAG 기반의 LLM 파이프라인 프로젝트를 풀스택으로 맡아 진행했다. 1주 단위 스프린트 4회를 진행하며 기획·디자인·FE·BE·AI를 혼자 커버했고, 그 과정에서 AI를 단순히 코드를 빨리 쓰게 해주는 도구가 아니라 아이디어 파트너로 써본 경험이 남았다. 이번 글은 그 경험에서 얻은 몇 가지 인사이트를 정리한다.


가속 페달 vs 아이디어 파트너

지금까지는 주로 AI를 아는 방향을 더 빨리 가게 해주는 가속 페달처럼 활용했다. 바퀴를 더 나은 바퀴로 만드는 건 가능해도, 바퀴 너머의 새로운 무언가를 제안하는 건 아직 어렵다고 생각했다.

이번 프로젝트를 진행하면서 그 생각이 바뀌었다.

한 번은 프로젝트 피드백 수집 방식을 고민하다가 브레인스토밍하려고 AI와 대화를 주고받고 있었다. 그때 나는 기존의 피드백 방식 — 스프린트 리뷰에서 받는 구두 피드백, 결과 화면에 뜨는 설문 폼 — 을 어떻게 개선할지만 고민하고 있었다.

그때 AI가 되물었다.

그런데 너 사용자 인터뷰는 해봤어?

이 질문 한 줄이 머리를 정돈해줬다. 그동안 내가 수집하던 건 모두 “결과 시점”의 피드백이었지 “과정”의 피드백이 아니었다. 작업 흐름 어디에서 막히는지, 언제 반복 작업이 생기는지 — 이런 맥락은 결과 화면 앞에서 휘발되고 있었다.

AI가 내가 놓치고 있던 부분을 명확히 지적해줬다. 이후 바로 사용자 옆에서 실제 작업을 관찰하는 쉐도잉 세션을 잡았고, 그 한 번의 세션이 프로젝트 방향을 크게 변화시켰다.


AI 정확도보다 사용성이 먼저

쉐도잉에서 얻은 인사이트는 기술적인 것이 아니었다. 아무리 정확한 출력을 내놓아도, 사용자의 작업 흐름에 자연스럽게 끼어들지 못하면 쓰이지 않는다는 당연한 사실이었다.

이전까지 스프린트에서는 “파이프라인의 AI 정확도를 어떻게 올릴까”에 집중하고 있었다. 대부분의 LLM 프로젝트가 그렇듯이 개선해야 할 지표는 무한히 많고, 하나씩 파고들다 보면 끝이 없다. 그런데 정작 필요한 건 정확도 n% 향상이 아니라, 사용자가 이 기능을 꺼내 쓰고 싶게 만드는, 안 쓰고는 못 배기게 하는 진입 경로였다.

이후로는 정확도 개선의 우선순위를 뒤로 미루고 UX부터 정리했다. 그러자 피드백 루프가 비로소 돌기 시작했다 — 쓰이지 않으면 피드백도 없다는, 어쩌면 제품 개발의 근본 원리를 프로젝트 한가운데서 다시 체감했다.


AI가 질문하게 하라

AI가 저런 질문을 던질 수 있었던 건 우연이 아니라, 충분한 맥락을 주고받을 수 있는 세팅 때문이었다고 생각한다.

“피드백 어떻게 받을까?”라고만 물었다면 답은 “설문 UI를 개선해보세요” 수준에서 멈췄을 거다. 내가 프로젝트의 현재 상태, 고민하는 지점, 지금까지 시도한 방식, 각 방식의 한계를 충분히 풀어놓은 뒤에야 “인터뷰는 해봤냐”는 질문이 돌아왔다.

AI와의 협업에서 “좋은 답을 받는 것”만큼 중요한 게 “좋은 질문이 돌아올 수 있는 맥락을 만드는 것”이라는 걸 이번에 크게 체감했다. 짧은 프롬프트로 답을 긁어내는 대신, 내가 처한 상황 전체를 공유하고 대화를 이어가는 방식이 훨씬 잘 먹힌다. 브레인스토밍이나 질문 기능을 내장한 하네스(gstack, superpowers, omc) 안에서 작업했을 때 이 방식의 효과가 특히 컸다.


하다보니 FDE처럼 했네?

프로젝트 중반쯤, 요즘 업계에서 자주 언급되는 FDE(Forward Deployed Engineer) 개념을 뒤늦게 접했다. 아직 다양한 형태가 있지만 개인적으로 정리한 바로는 엔지니어가 사용자 옆에서 일하면서 요구사항 정의 → 구현 → 개선을 통해 제품을 만들어가는 업무 방식이다.

돌아보면 이번 4주는 의도하지 않았는데 정확히 그 방식으로 일한 기간이었다. 사용자 옆에 가서 관찰하고, 관찰한 걸 바로 코드로 옮기고, 다음 스프린트에서 반응을 보고, 다시 조정하고 — 직군의 경계를 세게 긋지 않은 채로 맥락을 놓치지 않고 일하는 흐름이었다.

이 방식이 항상 효율적인 건 아니지만, 사용자가 무엇을 하는지 내가 이해하지 못한 상태에서 만드는 LLM 제품은 거의 쓰이지 않는다는 걸 배웠다. 도메인 이해와 코드 구현 사이의 거리가 짧을수록 LLM 제품은 좋은 피드백 루프가 돌면서 효과적으로 개선된다.


마치며

4주 내내 사고가 계속 확장되는 시간이었다. 초기 기술 리서치를 하다가 제품 제안으로 넘어가고, AI와 브레인스토밍하다가 AI에게 사용자 리서치 제안을 받고, 일하다 보니 “어, 이게 FDE구나” 하고 뒤늦게 이름을 붙이고 — “아, 이게 이거였구나” 싶은 순간이 연달아 찾아왔다.

적절한 하네스와 충분한 맥락이 주어지면, AI도 내가 생각하지 못한 방향을 제안하는 아이디어 파트너가 될 수 있다. 가속기 이상의 무언가로 쓸 수 있다는 가능성을 발견한 게 이번 프로젝트의 가장 큰 수확이었다.


Edit page
Share this post on:

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