[Bookgroo] 코드보다 먼저, 문서로 시작한 Bookgroo 프로젝트
⚠️ 안내: 이 글은 학습 기록용입니다. 오류나 보완 의견은 댓글로 알려주세요.
💡 다른 팀들과는 다른 출발점
Bookgroo 프로젝트는 부트캠프에서 2주 동안 진행한 중간 프로젝트로, Django REST Framework와 LangChain을 기반하는 서비스를 만들어보는 것으로 저희는 맞춤형 도서 추천 챗봇 개발하기로 했습니다.
저희 팀이 다른 팀들보다 뛰어나거나 엄청 뛰어난 결과를 낸 것은 아니였지만, 다른 팀들과의 차별점은 명확했습니다. 다른 팀들은 프로젝트 시작 후 회의 문서작업에 쓰는 시간이 많이 않았지만, 저희 팀은 2주간 프로젝트의 기간에서 1주의 시간을 오롯이 문서 작업 및 회의에 시간을 쏟았습니다.
당시에는 “너무 느린 거 아닐까?” 하는 불안감도 있었지만, 프로젝트를 마친 뒤 돌이켜보니 결과물을 정리하기도 훨씬 수월했고, 다른 팀들과 비교해도 프로젝트의 완성도가 떨어지지 않았기 때문에 결과적으로 좋은 선택이었다고 생각합니다.
🧭 코딩보다 먼저, 설계와 정의부터
저희가 처음 한 일은 코딩이 아니라 설계와 정의였습니다. 어떤 주제를 선택할지, 서비스의 흐름은 어떻게 구성할지, 사용 기술과 그 선택의 이유를 논의하며, 데이터베이스 구조와 챗봇의 대화 로직은 어떻게 연결하지까지 세밀하게 정리했습니다. 이 내용을 문서와 다이어그램으로 시각화하면서 팀원 모두가 동일한 그림을 공유할 수 있었고, 그 덕분에 이후의 개발 기간에는 추가적읜 회의 없이 개발에만 집중할 수 있었습니다.
⚙️ 문제 - 챗봇 로직 설계의 어려움
프로젝트의 결과물을 내는 것도 중요하지만, 지금 가장 해봐야하는 것이며 집중해야하는 것은 ‘챗봇 로직 다이어그램’을 제대로 그리는 것이라고 생각했습니다. 저는 이 다이어그램에 정말 많은 시간과 노력을 들였습니다. 가뜩이나 프로세스 플로우라는 것도 처음 만들어보는데, 내 생각이 제대로 담기고 그것이 다른 개발자들한테도 받아들여질 수 있을까에 대한 고민이 가장 많았던 것 같습니다.
가장 처음 만들었던 프로세스 플로우는 위의 이미지와 같았습니다. 나름 잘 만들었다고 생각했지만, 이 다이어그램을 가지고 “저희의 챗봇은 이러한 로직으로 동작합니다.” 라고 설명했는데, 튜터님들께서는 “로직이 잘 이해되지 않는다”. “병렬처리가 뭘 의미하는지 전혀 모르겠다”고 하셨습니다.
🔁 해결 - 분기와 병렬의 구분
왜 그렇게 느끼셨을까 곰곰이 생각해보니. 문제의 원인은 ‘분기 처리’와 ‘병렬 처리’를 구분하지 않았기 때문이었습니다. 두 개념은 한꺼번에 “병렬 처리”로 뭉뚱그려 표현하면서 의미가 모호해졌던 것이었습니다. 그래서 저는 해당 부분을 다시 설계하였습니다.
위의 이미지처럼
- 사용자가 책과 무관한 아예 뜬금없는 내용을 물어보는 경우,
- 상황이나 추천에 필요한 정보를 정확히 주면서 물어보는 경우,
- 맥락은 전혀 없지만 책을 추천해달라는 경우
이 세 가지를 명확히 ‘분기 처리’ 로 나누고, 책 추천 단계에서는 LLM이 기존 데이터에서 추천을, RAG로 신간 데이터를 가져오는 것을 동시에 ‘병렬적으로’ 수행하도록 표현했습니다. 튜터님께서도 “이제야 무슨 말을 하는지 알겠다”라고 하셨을 때, 제가 생각한 로직이 명확하게 전달되었다는 점이 정말 기뻤습니다.
🧩 마무리 – 문서의 힘을 실감하다
이번 프로젝트에서는 Django, Django REST framework(DRF), LangChain을 잘 이용하며 구현하는 것도 중요했지만, 문서 작업 및 사전 작업에 굉장히 중요하고 많은 비중을 가져도 된다라는 것을 배울 수 있었습니다.
