[나만무 WEEK5] 나만무 프로젝트 후기

munsik22 2025. 7. 29. 22:59

길고 길었던 5주간의 크래프톤 정글 나만의 무기 만들기 프로젝트가 끝났다. 오늘(이라기에는 3일이나 지났지만) 포스터 세션까지 모두 마친 시점에서, 프로젝트를 진행하며 겪었던 문제들과, 그 문제를 해결하기 위한 기술적 고민의 과정이 새삼 떠올라 기록해 본다.

🛫 KlickLab은 처음부터 KlickLab이 아니었다

사실 처음 우리가 이 프로젝트를 시작했을 때는, 지금의 KlickLab과는 전혀 다른 주제였다. 5주 간의 프로젝트 기간 중에서 가장 힘들었던 시간은 쉴 틈 없이 바쁘던 MVP 개발 기간도, 폴리싱와 데이터 작업을 하느라 밤을 꼬박 샌 최종 발표 리허설 전도 아니라 바로 기획 단계였던 것 같다.

가장 첫 번째 아이디어는 애플 워치와 연동되는 수영 기록 앱이었다. 물 속에서도 동작을 인식해 스트로크별로 구분하고, 실시간 칼로리 소모량까지 보여주자는 야심 찬기획이었는데… iOS 앱 개발 진입장벽이 생각보다 너무 높았다. 개발 환경도 복잡하고, iOS 마켓에 등록하는 절차도 힘들고, 결정적으로 팀원 중 맥북을 가진 사람이 2명 밖에 없었다. 결국 “이건 나중에 진짜 앱 만들 기회가 생기면 다시 해보자”는 말과 함께 기각되었다.

그 다음으로 나왔던 주제가 냉장고 재고 관리 + 사용자 맞춤형 식단 추천 앱, 이름하여 Eatventory. 팀원들도 다들 공감할 만한 실생활 문제고, OCR을 사용해 직접 입력하는 번거로움을 줄일 수 있다면 기존 앱과 비교해도 경쟁력이 있을 것이라는 말이 꽤 설득력 있었다. 사실 최선의 선택은 아니었는데, 다른 팀원들이 모두 마음에 드는 차선책이 없어서 울며 겨자먹기 식으로 Eatventory를 선택한 감도 없지 않다.

갈팡질팡 하고 있던 그 때 담임 코치님이 해주셨던 말이 있었다.

“혹시 ‘클릭스트림’이라는 기술 들어봤어요? 그런 걸 응용해 보면 어떨까?”

그 한 마디로 우리는 다시 방향을 틀었다. (너무 팔랑귀인가? 😅) 냉장고 재고 관리를 하되, 사용자 맞춤 추천을 위해 클릭 데이터 기반의 식단 행동 분석을 붙여보자. 타겟층을 명확히 하기 위해 비건 식단 관리 앱이라는 테마로 틀었다. Leafridge라는 이름으로 최종 기획 발표까지 진행했었다. 하지만 지금 그때 발표 자료를 보면 어이가 없어서 웃음이 절로 난다.

기술 스택에 대한 고민 없이 트렌디한 용어만 잔뜩 넣어 놓은 발표였다. 심지어 우리는 아직 Kafka 설치도 안 해봤을 때였다...😅 물론 지금에서야 Kafka를 사용하는 이유가 초 당 1만건의 요청이 들어와도 손실/지연없이 처리하기 위해서라는 당위성이 존재하지만, 저 당시에는 그냥 "클릭스트림? Kafka랑 Flink 쓴다는데?" 라고 해서 넣은 거였다.

첫 멘토링 시간, 멘토님은 발표를 다 보시고 나서 조용히 말씀하셨다.

“냉장고랑 클릭스트림을 아예 따로 분리해서 생각해보는 게 더 좋을 것 같아요.”

그 말에 우리는 정말 과감하게 냉장고를 버렸다. 클릭스트림 기반 데이터 분석이라는 기술 자체에 집중하고, GA, Appsflyer 같은 실전 서비스 구조를 직접 구현해보는 플랫폼을 만들자고 방향을 완전히 바꿨다. 그렇게 해서 탄생한 것이 지금의 KlickLab이다.

후일담으로 들은 얘긴데, 당시 코치님들이 “냉장고... 저거 괜찮을까...” 하면서 우리 팀을 꽤 걱정하셨다고 한다😓 오죽했으면 MVP 발표에서 주제가 KlickLab으로 바뀐 걸 보시곤 다들 “와 진짜 너무 잘 바꿨다”, “주제 바꿔서 정말 다행이다” 라고들 하셨을까...😂

📌 문제와 해결의 여정

① 원본 테이블 조회 지연

처음에는 모든 데이터를 ClickHouse의 단일 events 테이블에 저장했다. 그러나 데이터가 쌓이자 조회 성능이 급격히 떨어졌다.

초기 상태:
- events 테이블 단일 조회 → 응답시간 매우 느림
1차 시도:
- 20여 개의 집계 테이블을 추가 생성하여 데이터를 미리 집계해 두는 방식 도입
최종 선택:
- 중복되고 불필요한 테이블을 정리하고 최적화하여, 최종적으로 8개의 Materialized View와 7개의 집계 테이블만 유지
- 결과적으로 실시간 분석 속도가 대폭 향상 (응답 시간 99.43% 단축)

② 이벤트 수집 신뢰성 & 순서 보장

초기에 이벤트 수집 구조가 매우 단순했다. 하지만 실제 운영 환경에서의 신뢰성과 순서 보장 문제를 경험했다.

초기 구조:
- API Gateway → AWS SQS → AWS Lambda
- 문제점: 이벤트 양이 많아질 경우 순서 보장과 확장성에 한계를 느낌
2차 시도:
- Network Load Balancer(NLB) + c6in.xlarge 17대로 API 서버를 구축
- 이벤트는 AWS MSK(Kafka 관리형) → AWS Lambda가 처리
- 문제점: 비용이 지나치게 높았고, 생각보다 CPU 자원을 충분히 활용하지 못함
최종 선택:
- NLB + t2.small 인스턴스 74대로 수평 확장 → 비용 절감 및 효율적인 리소스 활용
- AWS MSK로 Kafka 기반 메시징 안정성 확보
- AWS Lambda로 자동 스케일링 및 안정적인 이벤트 처리 확보

③ Node.js GC로 인한 RPS 급락

Node.js 환경에서는 가비지 컬렉션(GC) 발생 시 처리량(RPS)이 급격히 하락하는 현상이 반복적으로 관찰되었다.

초기 상태:
- c6in.xlarge 인스턴스 17대로 운영
- GC pause가 빈번하고 길어짐 → RPS 주기적 급락 현상 발생
최종 선택:
- 보다 작은 인스턴스(t2.small) 74대로 전환하여 GC pause 빈도를 크게 낮춤
- GC 부담 분산 효과로 평균 RPS가 3,900에서 10,600으로 증가하고 안정화됨

④ DB 선정 과정 (mongoDB → PostgreSQL → ClickHouse)

초기 설계 당시에는 빠르게 프로토타입을 만들기 위해 MongoDB를 사용했다.

초기 상태:
- mongoDB 사용 (유연한 스키마와 빠른 개발 속도 장점)
- 문제점: 복잡한 집계 분석 성능에 한계를 느끼고, 속도가 현저히 떨어짐
2차 시도:
- PostgreSQL로 마이그레이션 시도 (집계 쿼리 작성의 편리성 및 범용성)
- 문제점: 데이터가 수백만 건 이상 쌓이자 집계 성능이 급격히 저하
최종 선택:
- 대용량 데이터 집계에 특화된 ClickHouse로 최종 결정
- MV(Materialized View)를 활용해 빠른 조회 성능과 실시간성 확보

📌 피드백에서 피드백으로, KlickLab 발표의 여정

📍 MVP 발표 – 피드백 폭격의 시작

MVP 발표 때는 일단 기능 중심으로 설명하자는 생각이 컸다. 그래서 우리가 구현한 SDK, 데이터 흐름, 대시보드 구성 등 기술 요소 중심으로 데모를 보여줬는데…

“시나리오가 너무 부족해요.”

라는 피드백을 받았다. 기술적으로 뭘 했는지는 알겠지만, 이 서비스가 어떤 맥락에서 쓰이는지 감이 안 잡힌다는 것이었다. 당시엔 우리가 직접 만든 데모 페이지도 미완성이라, 사용자 입장에서 본 흐름을 충분히 보여주지 못했던 것도 있다.

🎭 폴리싱 발표 – 롤플레잉의 반전

그 다음 발표에선 피드백을 반영해 역할극 형식의 데모를 시도했다. 한 명은 1인 쇼핑몰 사장님, 한 명은 KlickLab 매니저 역할을 맡아 데모 흐름에 몰입감을 주려고 했다. 예전 기수 발표 영상에서도 몇몇 팀들이 시나리오 기반 롤플레잉 발표를 하는 걸 봤기 때문에,
“이거 괜찮겠다” 싶었는데...

“이제는 확실하게 말씀드릴게요. 롤플레잉은 하지 마세요. 학예회 같고, 전문적으로 보이지 않습니다.”

...😭
심지어 시나리오 자체도 여전히 약하다는 피드백까지 받았다.

🛠 시나리오 재정비 – 최가영 대표의 탄생

그래서 이번엔 아예 데모용 쇼핑몰 페이지와 클릭랩 대시보드 페이지를 전제로 시나리오를 ‘스크립트 수준’으로 다시 짰다. 사용자 페르소나로 1인 쇼핑몰 창업자 ‘최가영 대표’를 설정하고, 최 대표의 시선으로 어떤 데이터를 보고 어떤 의사결정을 할 수 있는지 서사를 구성했다. 이후 최종 발표 1차 리허설 때 처음으로 긍정적인 피드백을 받았다.

“대시보드 구현이 잘 되었고, 시나리오도 잘 구성해서 영리하게 잘 발표하셨습니다.”

우리가 처음 발표이기도 해서, 처음엔 “이제 그냥 좋은 말만 해주기로 하셨나?” 의심했는데 다음 팀 발표부터는 다시 피드백 폭격이 돌아가서, 전날 밤을 새며 시나리오 다듬고 더미 데이터 넣은 게 효과가 있었구나 싶었다.

물론 우리 팀의 발표자 분의 뛰어난 딕션과 발표 진행력이 제일 영향이 크지 않았나 생각이 든다. 만장일치로 그 분이 발표자로 선정된 것도 평소 주간 공유 때마다 딕션 좋고 논리 정연한 발표를 해오셨기 때문이 아니었을까. 이후로도 코치님들한테 좋은 피드백을 받은 것이 좋은 발표자님 덕분이라고 생각한다👍

🎙 대망의 최종 발표

드디어 발표 당일. 자리에 앉아 있는데도 괜히 긴장이 됐고, 발표자분은 얼마나 떨렸을까 싶었다. 그런데 실제 발표는 정말 흔들림 없이 침착하게, 평소 리허설 때 했던 대로 진행되었다. (※ 발표 중간에 ‘최가영 대표’를 살짝 패러디해 ‘김창한 대표님’으로 바꿔서 넣었지만... 아무도 안 웃었다...😂)

하지만 정말 매끄러운, 아니 최고의 발표였다. 객관적으로 봐도, 우리 팀 발표자 님이 제일 발표를 잘 했다! 실제로 포스트 세션에서 8기 동기분들, 9기, 10기 분들 등 많은 분들이 우리 팀 발표자 님을 찾아왔다.

“발표 너무 잘 들었어요. 발음 완전 최고에요.”
“발표자 님의 발표가 진짜 제일 좋았어요.”
“클릭랩 발표 듣고 나서 포스터 세션도 꼭 와보고 싶었어요.”

내가 발표를 하거나 발표에 지대한 공을 세운 건 아니었지만, 그 자리에 함께했던 팀원으로서 괜히 뿌듯하고 자랑스러운 순간이었다. 그리고 개인적인 의견이지만 발표 PPT와 포스터 디자인도 우리 팀이 제일 멋진 듯?😎

📌 포스터 세션에서 느낀 점

포스터 세션 당일, 생각보다 많은 분들이 우리 부스에 와주셔서 솔직히 좀 놀랐다. 내심 "누가 우리 프로젝트에 관심이나 있겠어?" 라는 의구심이 있었는데, 진짜로 우리 팀 부스에만 계속해서 사람들이 질문을 하려 몰려드는 느낌이어서 좀 무서울 정도였다. 농담이고, 그만큼 감사하게도 협력사 관계자분들, 시니어 개발자, 9기,10기 분들까지 다양한 분들이 와서 우리 프로젝트에 관심을 갖고 질문을 던져주셨다.

🔊 가장 기억에 남는 평들

🏅 제일 기분 좋았던 평가

"이 팀에 마케팅 담당자 있었어요? 없다고요? 근데 어떻게 이런 주제를 생각해내고, 이렇게까지 설계할 수 있었죠?"

우리 팀은 모두 개발자였지, 실제 마케팅 도메인 경험자는 한 명도 없었다. 그런데도 실제 전환 흐름, 유입 분석, 사용자 세분화를 전제로 설계한 시스템이라는 점이 좋게 봐주신 듯하다. 정말 뿌듯했던 순간이었다.

🧊 제일 현실적인 평가

"결과물의 완성도는 좋아요. 서비스 플로우도 현실적이고, 구조도 탄탄하네요. 하지만 포트폴리오로서 보면 ‘그래서 이게 어떤 기술 문제를 해결했느냐’는 질문에는 답하지 못합니다. GA나 Amplitude가 이미 존재하는 상황에서, 이 서비스가 그들과 달리 어떤 문제를 해결했는지가 명확하지 않은것 같습니다."

뼈 때리는 말이었지만, 아주 정확한 지적이었다. 우리의 MVP는 GA의 개선판이 아니라, 클릭스트림 분석 기술을 직접 구현해보는 경험(= GA의 리버스 엔지니어링)에 가까웠기 때문에 그 자체가 차별화된 문제 해결은 아니었다😥

💬 질문이 가장 많았던 부분들

SDK와 트래픽 생성기 구조
DB 구조에서 읽기/쓰기 분리 방식
그리고 의외로, "ClickHouse가 뭐예요?"라는 질문도 꽤 많았다😅

그 중에서도 가장 공격(?)이 많았던 파트는 단연 SDK였다.

⚔️ SDK에 대한 질문 폭격

가장 많이 들은 질문들은 이런 것들이었다:

"이 SDK는 모든 이벤트를 수집하니까 필터링이 안 되는 거 아닌가요?"
"성별/연령은 로컬 스토리지에서만 가져오면, 없는 경우 수집 불가한 거 아닌가요?"

사실 하나같이 다 맞는 말이었다. 후자의 경우에는 MVP 개발 당시엔 “뭐~ 되겠지 뭐~” 라며 흐린 눈으로 넘어간 부분도 있었다. 물론 폴리싱 단계에서는 이런 질문이 올 걸 예상하고 성별/연령 정보를 수집하는 대안도 찾아보기도 하고 고민해봤다. 하지만 법적인 이유로 대부분 막혔고, 현실적인 해결책이라면

고객사로부터 제3자 정보이용 동의를 받고
고객사 내부 DB에서 user_id 기준으로 JOIN하는 방식 정도가 유일했다.

즉, 우리가 SDK에 담으려고 했던 기능이, 실제 서비스 환경에서는 쉽게 쓸 수 없는 것이었다는 점도 깨달았다. 하지만 그 자체로도 좋은 학습이었다.

🎤 포스트 세션을 마치고

포스터 세션은 발표보다 훨씬 냉정한 현실과 마주하게 해주는 자리였다. 그 자리에서 들었던 말들, 맞받아쳐야 했던 질문들, 부족했던 논리들이 결국 우리가 만들었던 KlickLab이라는 서비스의 “한계”이자 동시에 “의미”였다.

우리가 스스로에게 던졌던 질문이기도 하다: “진짜 기술로 문제를 해결했는가?”

📌 마무리하며

KlickLab은 우리가 처음부터 잘했던 프로젝트가 아니다. 기획부터 삐걱거렸고, 기술 스택도 여러 번 바뀌었고, 발표는 한 번씩 혹평을 받았으며, 포스터 세션에서는 뼈 때리는 현실적인 피드백을 받았다.

하지만 그 과정 하나하나가 우리 팀을 만들었다고 생각한다. 처음엔 “이런 서비스를 만들면 좋지 않을까?”라는 아이디어로 시작했지만, 결국 우리가 하게 된 건 문제를 정의하고, 그걸 기술적으로 풀 수 있는 구조를 만드는 일이었다. 아무도 안 써본 기술은 아니었지만, 그걸 처음부터 설계하고 하나씩 구현해보는 건 우리한테 처음이었다. 성과도 있었지만, 그보다 더 기억에 남는 건 우리가 왜 이 구조를 선택했는지, 그걸 어떻게 설명할 수 있게 됐는지다.

결국 프로젝트는 끝났지만, 이제는 누군가 우리에게 “왜 그렇게 만들었어?”라고 물었을 때,자신 있게 대답할 수 있게 됐다는 게 가장 큰 수확이었다. 가장 먼저 5주 동안 함께 정말정말 고생했던 팀원들에게 감사하고, 끝까지 애정과 피드백을 아끼지 않았던 모든 코치님들, 멘토님께도 감사의 인사를 전한다.