https://tobetirdev.tistory.com/168
[나만무] 10기 4조 팀장의 후기
** 개인의 의견이 다수 포함되어 있음 **** 프로젝트에 대한 포스팅은 나중에 진행 ** 대략 2달만의 포스팅...ㅋㅋㅋ핀토스가 어떻게 끝났는지 복기할 여유도 없이 바로 나만무 프로젝트가 시작되
tobetirdev.tistory.com
**위 포스팅에 이어지는 내용입니다. 팀장의 시선보다는 팀의 진행 상황에 대한 포스팅입니다**
** 기술적 고민보다는 프로젝트 진행 회고이며, 기술 관련 포스팅은 다음에 이어서 진행합니다 **
우리 프로젝트는 정말 기획이 힘들었던 프로젝트였다.
이전 글에서 언급했듯이, 도메인 지식이 없는 채로 프로젝트를 시작했기 때문이다.
그렇다면 왜, 도메인 지식이 없는 프로젝트를 시작했을까??
1. 기획 주차
나만무 프로젝트는 본인이 원하는 프로젝트를 함으로써 실무 경험을 쌓고 성장하는 프로젝트이다.
이론상으로는 그렇다......
코치님의 피드백
우리 팀은 초기에 깃허브 관리, 그 중에서도 시각화를 컨셉으로 하는 서비스를 기획했다.
레포지토리에서 PR시에 코드변경점을 시각화하여, AI 시대에 올라간 코드 생산성을 뒷받침하기 위해
한번에 만들어지는 다량의 코드의 구조와 흐름을 쉽게 파악할 수 있도록 하는 것이 핵심 가치였다.
그러나 거부당했다.
우선 구식 기술이라는 것이다.
또한 함수의 의존성을 하나하나 다 따지기에는 복잡하며, 그렇다고 폴더 단위로 시각화하기엔 너무 간단하다라는 피드백이 있었고,
우리는 당연히(?) 반발했다.
사실 반발까지는 아니고 우리 서비스의 가치를 어떻게든 증명하여 코치님을 설득하려고 했지만, 한계는 명확해보였다.
어찌보면 당연한 결과일 수도 있다.
서비스에 대한 좁은 시야
우리는 아직 유저가 사용할만한 서비스를, 상용 가능한 서비스를 만들어 본 적이 없다.
그말인 즉, 서비스에 대한 시야 자체가 좁다는 소리다.
회의를 거듭했지만 모두가 만족할 만한 기획은 나오지 않았다.
결국 코치님의 도움을 받았다.
시각화를 해볼거면, 요즘 뜨고 있는 AI 쪽은 어떻습니까?
요즘 랭체인으로 AI 서비스를 구축하려는 시도가 늘고 있지만, 이를 시각화 툴로 제공하는 서비스는 잘 없는 것 같다 하시며
이 주제를 추천해주셨다.
'그럼 AI 관련 기능들을 유저가 접근하기 쉽게, 예쁘게 정리해서 웹으로 제공하면 되는건가?'
우리는 AI에 대해 몰랐다.
정말 아무것도 몰랐다. 랭체인이 뭔디...
AI에 대해 아는 것이라곤 Chat GPT, Claude, Gemini 정도?
거기에 MCP를 이용해 생산성을 높이는 코딩이 가능하다... 였다.
그래서 AI Agent인지 뭔지 모르겠고, 일단 가장 간단한 챗봇을 어떻게 만드는지부터 알아야 했다.
챗봇은 그냥 gpt 아닌가...?
그런데 공용 LLM이니까 새로운 지식을 학습하지 못하는구나
그럼 새로 문서를 가지고 어떤 과정을 거쳐 그걸 LLM이 알아듣는거지?
이렇게 RAG에 대해 알아보고, 임베딩이 뭔지 학습해 나갔다.
팀적으로 싱크를 맞추기 힘들었던 부분이다.
RAG, VectorDB, Prompt, Parameter, Embedding, Query ....
점점 모르는 단어가 늘어갔고, 각 용어의 개념을 찾아보며 동작 원리를 알아보았다.
그럼 프롬프트가 쿼리야?
유저 쿼리가 사용자의 입력을 말하는건가?
그럼 시스템 프롬프트는 뭐지?
임베딩이 어떻게 동작하지? 컨텍스트는 뭐고 청크는 또 뭐야....
팀이 기본적인 지식 도메인은 전부 함께 알아야 한다라고 생각했기에,
새벽까지 함께 공부하면서 RAG 동작 원리에 대한 싱크를 맞추었다.
그 다음으로는 와이어 프레임을 구상했다.
원래 시각화라는 키워드가, 유저가 쉽게 서비스를 이용하기 위해 넣었던 내용이라
우리는 최대한 코딩을 모르는 유저도 사용할 수 있도록 서비스를 만들기를 원했다.
이 생각은 나중에 큰 혼란을 가져오게 된다....
아무튼 그 결과, 그동안 학습한 RAG 기반 서비스를 Form 형식으로 제공하는 초안이 나왔다.
고안한 기능은 RAG 기반의 챗봇, 이후의 Prompt 테스트, 성능 평가 그리고 비용 통계를 제공하는 서비스였다.
돌이켜 생각해보니 이 정도도 굉장히 복잡하지 않나? 라고 생각했던 것 같다.
(실제로도 복잡하긴 하다)
아무튼 이런 과정들을 거치며 조금씩 도메인 지식을 갖추었다.
다만 도메인을 공부하느라 시간이 부족했고, PPT도 제작하지 못한 채 대강의 UI만 excalidraw로 그려가서
"이딴 식으로 할거면 하지 마세요" 라는 피드백을 들었다.
그치만 도메인 모르면 아무것도 못하는 걸...
생소한 도메인이었기 때문에 당연한 결과라고 생각했다.
(후에 코치님은 이렇게까지 AI 지식이 없으리라곤 생각을 미처 못했다고 하셨다.... 저흰 정말 맨땅에 헤딩이었습니다ㅎㅎ)
2. MVP 개발 1주차
2주차는 MVP 기능을 개발하는 시간이다.
이때부터는 기존 래퍼런스 서비스들을 많이 살펴보았다.
Dify, Botpress, NotebookLM...
그런데 어떤 형태로 툴을 제공할지 제대로 결정하지 못했다.
우리는 우선 Dify의 방식대로 챗봇을 한번 만들어보기로 했다.
또한 유저 입장에서 가장 접근이 쉬운 Form 형식으로 노드를 생성할 수 있도록 했다.
예를 들어 챗봇의 이름을 입력하고 목적을 정한뒤, 임베딩할 문서를 업로드하면 워크플로우 화면으로 이동하는 형식이다.
코치님들의 피드백
우선 잘했고, 기능도 잘 동작하기는 하는데.....
노드를 유저가 직접 만들어야지 왜 Form 형식으로 받아 생성하는 거죠? 유저가 자유롭게 쓸 수 있게 해야죠.
이 서비스가 과연 유저가 이걸 사용하기 쉬울까요?
문서는 DB에서도 가져오는 건가요? 보안 위험은요?
피드백 중 1,2번을 보면 뭔가 의아할 것이다. 조금 엇갈리는 피드백이라 할 수 있다.
유저에게 자율성을 보장해야 한다 VS 애초에 코드를 잘 모르는 사람이 이걸 쓴다고?
이렇게 피드백이 갈린 이유에 대해 우선 회의를 해보았다.
결론은 다음과 같았다.
우리 서비스의 의도를 명확히 전달하지 못했다.
그럼 이 의도가 명확하지 않았던 이유는 무엇일까?
1. 타겟 유저층이 명확하지 않았다.
2. 최종적인 시나리오를 제시하지 못했다.
우리는 서비스 이용 대상을 초보 개발자, 혹은 아예 비개발자로 잡았다.
그러다 보니 노드를 직접 생성하는 것보다는 폼 형식으로 전부 생성한 뒤,
나중에 동작을 확인할때만 노드의 흐름을 볼 수 있게 하면 될 것이라 생각했다.
그러나 이렇게 폼 형식으로 받는 것은, 에이전트가 필요로 하는 기능이나 설정이 많아지면 많아질수록
오히려 가독성이 떨어지고 UI가 구려질 것 같은 생각이 들었다.
또한 결국 챗봇에 머무르는 서비스가 아니라 우리 서비스가 최종적으로 유저에게 어떠한 가치를 제공할지에 대한
정리가 제대로 되지 않아서, 성공적인 발표를 하지 못했던 것 같다.
3. MVP 2주차
우리는 조금 더 완성도 있는 서비스를 만들기 위해, 래퍼런스를 하나씩 분석하기로 했다.
각자 하나씩....
각자 하나씩....
내가 후회하는 부분 중 하나이다. 많은 래퍼런스를 한번에 이해하고자 하였는데,
누구 하나 제대로 래퍼런스를 동작원리까지 이해하지 못했고, 결국 서비스에 대한 방향을 하나로 모으는데
소통 비용이 너무 많이 들었다.
시간을 아껴야 하는 나만무이지만 함께 싱크를 맞춰야 할 때는 모두가 같은 작업에 참여할 필요도 있다는 걸 느꼈다.
(물론 온프레미스 환경에서 도커 컴포즈로 컨테이너 다 때려박은거 확장하고 Bedrock 추가하느라 시간이 없었기도 했지만...)
아무튼
상당한 소통비용을 지불하며 우리는 3주차 발표를 완벽히 실패했다.
노드는 거의 그대로였으며, 이 서비스를 어떤 형태로 유저한테 제공할건지 겨우 결정했기 때문이다.
또한 버전 관리나 비용 조회에 대한 기능도 화면만 존재하고 동작하지는 않았다.
거의 1주일동안 뭐한거에요?
이번에도 날 선 피드백이 들어왔다.
한편으론 이런 생각도 들었다.
이번엔 진짜 거의 다 결정되었는데, 하루 이틀만 더 있었으면 진짜 제대로 구현할 수 있는데...
왜 매주 발표(그것도 PPT까지)에 이상한 일정 잡아서 구현할 시간 뺏어가는거야!
하지만 이내 잘못된 생각이라는 걸 깨달았다.
매주 발표는 10기 교육생의 중간 점검, 피드백이란 것도 있겠지만
조금 더 실무에 가까운 일정을 경험하게 하려는 취지였던 것 같다.
많은 인원이 투입되는 프로젝트에서 특정 인원만 시간을 더 주는 것도 아니고...
데드라인은 무슨 일이 있어도 맞춰야지 음음...
결국 코치님이 교육장에 직접 오셔서 서비스의 컨셉에 대해 대화를 나눴고,
우리도 이제는 피드백을 정말 제대로 반영할 준비가 되어있어서
진짜진짜진짜진짜진짜 구현만 남았다.
4. 폴리싱 1주차
구현의 연속이었다. IF/ELSE 노드, 대화변수 설정 및 할당기, 뉴스 검색 노드 등을 구현했고,
이를 바탕으로 다음과 같은 시나리오를 구상했다.
워크플로우 실행 -> 유저 입력 -> 입력에 따른 뉴스 검색 및 LLM으로 정리 -> 유저 피드백(마음에 드는지)
마음에 드는 경우 -> 자동으로 SNS 스타일로 변환
마음에 들지 않는 경우 -> 자동으로 다른 뉴스 검색 결과를 찾아 LLM으로 정리한뒤 다시 유저 피드백 요구
또한 인프라를 확장하고 워크플로우 버전관리 / 웹 앱 및 임베딩 코드 배포관리를 구현하였다.
마지막으로 마켓플레이스 게시 기능과 워크플로우 Import/Export를 구현해서 에이전트끼리 연결할 수 있도록 하였다.
Agent를 마음껏 만들고 테스트 및 버전 관리할 수 있는 시각 워크플로우 런타임
그렇게 4주차에 와서야 드디어 서비스의 최종 컨셉이 완성되었다.
코치님 피드백
기능도 많이 들어갔고, 에이전트 연결도 좋은거 같습니다. 조금 더 다듬어보죠
휴
이제는 최종발표에서 사용할 시연용 시나리오를 확정해야 했다.
심지어 이때까지 방치한 버그 및 기타 문제를 해결해야 했다.
5. 폴리싱 2주차 및 발표
사실 이 기간에는 더 이상 코드를 짜선 안된다. 서버를 확장하고 기능을 추가할 게 아니라,
테스트를 지속하고 QA를 통해 완성도를 높여야했다.
대본도 쓰고 포스터도 준비해야 했지만 그전에 마지막으로 해야할 것이 있었다.
최종 시나리오
우리 팀은 좋은 발표를 위해 정말 많이 노력했다.
대본에 들어갈 시나리오를 정말 많이 고쳤다.
그러다 보니 의견충돌이 발생했다.
이 의견 충돌과 해결 과정에 대해선 이전 포스팅을 참고하길 바란다!
마지막까지 치열하게 준비한 끝에 발표와 포스터 세션을 잘 끝낼 수 있었다.
마치며
사실 의사결정 과정이라 썼지만, 팀의 갈등 해소 과정이 정확한 표현인 것 같다.
근데 정말 신기하게 첫 주차에는 쓸 내용이 많았는데, 마지막 주차로 가면서 쓸 내용이 없다는 걸 느꼈다.
시간이 갈수록 팀합이 잘 맞았다는 증거이지 않을까 싶다.
다만 진짜 1주일만 더 있었어도, DB 접근이든 도커 이미지화든 정말 더 상용가능한 서비스를 만들 수 있었을거 같은데......
그게 너무 아쉽다!
다음 포스팅은 기술적 접근에 대한 내용을 다룰 예정!
'크래프톤정글10기 > 나만무' 카테고리의 다른 글
| [나만무] SnapAgent의 기술적 접근 (1) | 2025.12.15 |
|---|---|
| [나만무] 10기 4조 팀장의 후기 (1) | 2025.12.04 |
