블레이버스 MVP 개발 해커톤 시즌4(2026) `대상` 후기 겸 회고

이번 해커톤은 제가 속한 개발 동아리에서 우연히 이야기를 접하며 시작되었습니다. 다른 대회와 달리, 기업의 MVP 프로토타입을 구현하고 이를 통해 비즈니스 가치를 설득하는 과정에 집중할 수 있다는 점이 매력적이었습니다. 기술적인 근거와 비즈니스 가치의 설득하는 과정에는 자신 있다는 생각으로 도전하게 되었습니다.

이번 해커톤은 총 309명의 인원이 참여했고, 2월 1일부터 2월 10일까지 10일 정도의 기간 동안 진행되었습니다.

저희 팀은 3D Viewer 기반의 학습 어시스턴트라는 다소 난이도 높은 주제를 선택했는데, 이 과정에서 기술적인 성장뿐만 아니라 소프트 스킬 측면에서도 많은 것을 배울 수 있었습니다. 이번 회고 겸 후기에서는 기술적인 구현 내용보다는, 팀이 하나의 목표를 향해 달려가는 과정에서 느낀 점과 배운 점을 중점적으로 기록하였습니다.

1. 팀빌딩 과정

저는 프론트엔드와 백엔드를 모두 경험하며 다양한 트레이드 오프를 경험해보았습니다. 그 경험을 통해서 깨달은 것은 해커톤 같은 단기 프로젝트에서는 단순히 다양한 기술을 알고 적용할 수 있는 팀원보다는 우리 프로젝트의 서사를 잘 풀어내고 설득할 수 있는 팀원이 더 중요하다는 사실이었습니다.

그래서 저는 다음과 같은 기준으로 팀을 구성하고자 하였습니다.

1. 근거를 기반으로 논리적인 설득이 가능하신분
2. 비판을 공격이 아닌 성장의 기회로 받아들이는 수용적인 태도를 가진 분

결과적으로 PM(1), FE(2), BE(3), 디자이너(1)으로 팀이 구성되었습니다. 저는 BE파트의 리드를 맡아 프로젝트를 수행했습니다.

2. MVP가 나오기전: 구현 가능성 탐색하기

본격적인 개발에 앞서, MVP의 핵심인 ‘3D 애니메이션 뷰어’ 기능을 어디까지 커스터마이징 할 수 있는지 판단하는 것이 급선무였습니다.

우리에게 주어진 시간은 세부 요구사항이 나오기 전, 단 하루 남짓이었습니다.

저는 문제를 다각도로 분석하고 러프한 구현 방향성을 빠르게 수립하여 팀원들에게 공유했습니다. 팀원 개개인의 기술적 컨텍스트를 일치시키기 위한 노력이었습니다.

제한된 시간 내에 구현 가능성을 검증하는 데 집중하다 보니, 돌이켜보면 아쉬운 점들도 눈에 띕니다.

당시에는 속도가 최우선이라 판단하여 제가 주도적으로 조사를 진행했지만, 팀원 각자에게 조사 태스크를 분배하고 공유하는 과정을 거쳤다면 어땠을까 합니다.

그랬다면 분석의 다양성을 확보하고, 팀 전체가 프로젝트에 대해 더 깊은 이해도를 가진 상태로 단단하게 시작할 수 있었을 것이라는 배움을 얻었습니다.

3. 설계: 모두가 바라보는 방향을 일치시키기 위한 요구사항 분석 과정

제가 백엔드 파트의 리드로서 개발 직군의 다른 분들과 소통할 때 가장 중요하게 생각했던 부분은 요구사항 분석 과정이었습니다.

MVP에 대한 대략적인 요구사항이 나왔을 때 모호한 내용들을 사전에 제거해야 불필요한 병목을 제거할 수 있고, 기획 측면에서도 요구사항 이면에 숨어있는 본질을 찾을 수 있다고 판단했기 때문입니다.

이 과정에서 저희가 당연하게 이 기능은 ~방식으로 동작하겠지라고 지레짐작했던 내용들을 구체화하므로써 모호한 점들을 제거하고 구현 단계에서 발생할 수 있는 병목을 사전 예방할 수 있었습니다.

4. 설계: 구체화하기

데이터모델링

데이터모델링은 함께 했던 백엔드 팀원 두 분이 모두 직장인이셨기에 작업의 유휴시간을 줄이기 위해 저 혼자 작성을 한 다음, 초안을 공유하는 방식으로 이루어졌습니다.

제가 맡은 기능은 3d viewer의 핵심 컴포넌트를 서버 단에서 조립하여 완성된 하나의 asset을 API로 내려주는 파트였으며 기능에 맞추어 데이터모델링을 진행하였습니다.

Table 정의는 기술적인 내용이므로 현재 포스트에서는 생략합니다

이 과정에서 제 파트를 이해하고 싶어했던 팀원에게 gltf 구조에 대한 완전한 이해를 하도록 돕지 못했다는 것이 아쉬웠습니다.

당시에는 기술적인 설명에만 치중하여 해당 팀원이 생소한 도메인 지식을 받아들이는 어려움을 헤아리지 못했습니다.

돌이켜보면, 복잡한 개념을 직관적인 개념으로 치환하여 설명하고 팀 내에서 공통적으로 사용하는 용어 사전을 먼저 정의했다면 어땠을까 라는 생각이 듭니다.

다음 협업 때에는 기술적인 깊이보다 우리가 집중해야하는 부분은 무엇인지 정의하고 이를 해결하기 위한 용어들을 직관적으로 정의하고 소통을 진행해야겠습니다.

API 설계

데이터모델링을 마무리할 때쯤 디자이너분과 PM분이 만드신 디자인이 포함된 화면 정의서가 나왔습니다!

결국 백엔드의 고객은 프론트이기 때문에 API 설계를 할 때 선제적으로 화면에서 필요한 정보, 인터랙션 과정에서 필요한 부가적인 필드들을 식별하는데 집중했습니다.

개발 기간이 짧았던 만큼 기획과 실제 구현 결과가 불일치할 경우 결과물의 완성도가 현저히 떨어질 수 있었기 때문에 의도를 계속 여쭤보며 개발을 진행하였습니다.

확실히 이렇게 지속적으로 의도를 여쭙고 보완하며 팀원들간의 컨텍스트를 지속적으로 일치시킨것이 저희 프로젝트의 주요 성공 원인 중 하나였던 것 같습니다. 이렇게 계속 의도를 파악하고 누락된 요구사항들을 보완하면서 API 명세서까지 완성할 수 있었습니다.

5. 구현: 이상과는 다른 현실

설계를 엄격하게 했다고 자부했지만 현실의 벽은 높았습니다. 구현 과정에서 예상치 못한 허점들이 발견됐습니다

그럼에도 불구하고 팀원 간의 신뢰와 명확한 소통 문화 덕분에 당황하지 않고 문제를 하나씩 해결했습니다.

결국 해냈습니다! 🥳🥳🥳

구현은 기술적인 내용이 많아, 추후 다른 포스트로 분리할 예정입니다.

6. 발표 및 결과 발표

파이널 데이에 합류하게 된 저희 팀… 부푼 기대를 안고 PT진행을 참관했습니다..!

하은 PM님께서 너무 기획 의도와 구현 기술과의 연계들을 너무 잘 설명하셔서 내심 수상했다…! 라는 생각을 가지고 있었습니다.

하지만 최우수상까지 저희 팀 이름이 불리지 않아서 내심 아… 그래도 부족했구나.. 생각을 하고 있었습니다.

마지막 대상 부문에서 저희 팀 이름이 불릴 때 날아가듯 기뻤습니다!.. 다른 팀원들도 정말 행복해하는 모습이 보여서 뿌듯하고 기분 좋게 마무리 할 수 있었습니다.

수상 직후에 역삼역으로 다 같이 모여서 가는 길에 심사를 하셨던 분들을 우연히 마주쳐서 저희 팀의 어떠한 점들이 인상깊었냐고 여쭤봤습니다

디자인, 기술적 완성도, 기획 의도가 다른 팀들에 비해 우수했다라는 말씀을 해주셨습니다.

이 경험을 통해서 제가 다시 한 번 깨닫는 점은 결국 소프트웨어의 본질은 현실 세계의 어려움을 해결하기 위한 것이라는 것이었습니다. 오버엔지니어링을 피하기 위해서 저희는 본질을 제외한 부수적인 것들을 덜어내는 전략을 취했었는데 이 부분이 저희의 수상에 가장 결정적인 요인이었던 것 같습니다.

무엇보다도 개인적으로도 배운점이 많았던 대회였습니다! 좋은 코드는 혼자서도 작성할 수 있지만 좋은 프로덕트는 서로 소통하며 본질을 고민하는 과정에서 탄생한다는 것을 몸소 깨달았습니다.

대상이라는 결과보다 더 값진 것은 서로 다른 생각과 의견을 가진 개인이 하나의 팀이 되어가는 과정이었습니다. 함께 고생해 준 우리 팀원들에게 감사의 마음을 전합니다..👏👏👏