서울 AI 해커톤 후기와 팀 리틀브라더 고찰

모기·2025년 10월 10일

호명되는 그 순간이 아직도 생생하다.
인지부조화가 와서,
나는 리틀브라더 팀이지만,
저기 아나운서님이 말한 대상 리틀브라더는 우리 리틀브라더가 아니야
라고 잠깐 생각했었다.

https://velog.io/@jisung719/서울-AI-해커톤-수상-후기-1위-팁
https://velog.io/@myong2404/서울-AI-해커톤-후기

팀원들이 후기를 올렸길래 부랴부랴 글을 쓰기 시작했다.
https://velog.io/@mogiyoon/Krafton-Jungle-Eighth
강남병의 유구한 역사와 전통을 지키기 위해서이다.

꼭 후기가 아니더라도 '리틀브라더' 고찰은 반드시 할 생각이었다.
우리팀의 역할은 진짜 칼같이 나뉘어져 있어서, 나는 우리 팀원이 구현한 것들을 진짜 전혀 이해하지 못한다.
Nest는 코드를 읽을 수는 있지만, FastAPI와 Yolo 및 태깅은 내가 AI에 발을 담굴거라면 알아두는게 좋을 것 같다고 생각한다.

후기는 노션의 회의록에 기반하여 정리를 했고
FastAPI와 Yolo 고찰은 아무래도 길어질 것 같다. 베일 수 있으니 조심하자.

서울 AI 해커톤

대상이다!

출처: 나무위키

서울시장상을 받는 나는 꿈에서도 상상해본 적이 없는데
나는 사실 인간인 척하는 꿈을 꾸는 모기가 아닐까

호들갑은 여기까지 떨고
여정을 돌아보려한다.

아이디어 선별

제일 중요했던 것 같다. 아무리 개발을 열심히 하더라도, 정말 뛰어난 기술을 쓴다고 하더라도, 해커톤이 요구하는 조건에 부합하는 참신한 아이디어가 아니면 떨어질 것이라 생각했다.

그래서 우린 쳐낸 아이디어가 좀 있다.
특히 뉴스에서 자주 다루는 문제들은
아마 누구나 다 아이디어로 떠올리지 않을까 생각했다.

고독사, 말동무, 관광 도우미, 행사 추천 등등
확- 와닿지 않았다.
분명히 다른 팀에서도 해당 아이디어를 떠올리고 주제로 정하지 않을까 생각했다.
또한 위 아이디어들은 확장성이 부족했다.

엥? 웬 확장성?

이게 추진 일정인데, 보면 선발 기준들이 쭉 있다.
전직 공무원으로서 무좍건 이런 기준들을 중점적으로 평가한다고, 어쩔 수 없다고 팀원을 가스라이팅했다.

1차 서면 - 주제 적합성, 혁신과 창의성, 실현 가능성
2차 서면 - 기술적 완성도, 기술의 활용성, 구체성
최종발표 - 보완성, 사업성, 기대효과

사실 1차 서면에서는 확장성이 그렇게 중요하지는 않다. 굳이 비슷한 결을 고르자면 '혁신과 창의성'일텐데, 이 평가 기준에서는 '엥 이것도 돼? 저것도 돼?' 보다는 '엥 이게 뭐야?'가 더 중요하다고 생각했다.

2차 서면에서는 말 그대로, 구현을 잘했는지를 보는 것 같았다. 거기에 플러스로 기술의 활용성인데, 이게 아마 확장성과 결이 비슷하다고 생각했다. 사실 결승 무대에 올라오는 팀들 중 완성도와 구체성이 떨어지는 팀이 어디 있겠는가? 따라서 확장성은 2차 서면에서도 키 포인트이고

최종발표에서는 확장성 하나로 사업성과 기대효과를 다 가지고 간다고 해도 말이 아니다.

그래서 확장성을 중점적으로 봤다.

팀원의 아이디어 중 'AI 민원 분석 및 정책 제안'이라는 아이디어가 있었다.
앞서 말한 포트홀, 독거노인 등을 얘 혼자 다 포함할 수 있겠다는 생각이 들었고
그럼 어떻게 분석을 할 것인가?를 떠올리다보니 컴퓨터 비전을 떠올렸고
뭔가 포켓몬 고처럼 휴대폰을 들고 다니면서 보면 이런게 가능하지 않을까?
떠올렸다.

그럼 이제 어떻게 휴대폰을 들고 다니게 하느냐?
거기서 고민을 많이 했는데, 마침 '크래프톤 정글' 동기가 다크소울을 추천해주길래
우리 모두는 거기서 영감을 얻어 출발을 했다.

메시지 남기기 기능도 중요했지만,
확장성을 키우기에는 부족한 감이 있어 VR 기능도 추가하고
마지막에는 멘토님의 도움을 받아 AI 도슨트 기능까지 추가를 하게 됐다.

테마가 AR과 VR이다보니 할 수 있는 게 무궁무진했다.

참고로 팀원들 모두 '크래프톤 정글' '8기'다.
그렇게 아이디어를 구체화하다보니 알게된 것은,
우리는 서비스를 2개를 개발하고 있구나
라는 사실이었다.

이번 기회에 느끼게 된 것은,
'이 정도로 확신이 들어야 큰 상을 받을 수 있구나'라는 점이었다.
우리는 정말 아이디어에 대해 떠올리자마자 한결같이 확확신을 했다. 확확확신을 했을지도

설계

정확하게 기억이 안난다. 하지만 아마 우린 1차 발표 전에 설계에 들어갔던 것 같다.

1차 회의

설계부터는 일반적인 팀프로젝트와 다를게 없었다.
실현할 수 있는 기술을 다 찾아보고, 비교해서 베스트를 뽑고.

물론 그게 어렵긴했다.
써본 경험이 없는 유니티를 쓸 수 밖에 없었던 이유가
1. AR을 쓸 수 있는 기술 스택에는 어떤 것이 있는지
2. 앱과 웹 중 어떤 것이 우리 상황에 더 적합한지
3. 앱이라면 앱에는 어떤 기술들이 있는지
4. 추가적으로 yolo라는 기술을 쓸 수 있는지
5. 앱의 확장성을 더 키울 수 있는 언어나 기술 스택이 무엇인지

등등

유니티라는 뻔한 대답을 듣고 본다면, 결론이 너무 쉬웠지만
아~무것도 모르는 상황에서 교집합을 찾는 것은 여간 까다로운 일이 아니었다.

정보가 너무 많았다.

만약 유니티를 선택했는데 핵심 기능을 구현하지 못하게 된다면 수포로 돌아가게 된다. 그만큼 신중해야 했다.

2차 회의

여기서 구체적 일정을 잡은 것을 보니, 아마 발표가 나고 2차 회의에 들어갔던 것 같다. 나만무 프로젝트가 끝난지 얼마되지 않은 시점이었기에, 우리들의 AWS 지식은 빠삭한 편이었다. 그래서 아키텍쳐 설계가 바로바로 되었는데,

사실 그게 독이 되었다.

생각보다 막힌 기능과 권한들이 많았고(VPN, loadbalancer 등), 액세스 키 발급이 불가하여 로컬에서 S3 접근 자체가 불가능하다. 즉 서버를 만들고 S3를 테스트 해야했다.

일단 그래서 그 문제는 나중에 생각하기로 하고,
API 명세서, Gitflow, 코드 컨벤션, ERD 설계 등을 진행했다.

우리가 만나서 코딩한 적은 딱 두 번 있었다. 두 번을 제외한 코딩은 전부 원거리로 이루어졌는데, 쉽지 않았다.

구현

구현 파트는 적을게 없다.
이건 다른 글들을 참고하면 될 것 같다.

3차 회의

3차 회의는 간단했다. 왜냐하면 다들 구현한다고 정신없었기 때문이다. 막 MVP 기능 수정하고 완성하고 했던 기간이었다.

그리고 S3는 우리 계정으로 새롭게 하나 만들어서 IAM을 썼다.
개발 속도가 엄청 빨라졌다.

4차 회의

4차 회의는 기술적으로 타협이 필요한 부분들에 대해서 공유하는 시간이었다. 시간적으로 구현 가능한 기술이 어디까지인지, 우리는 어떤 것을 포기할지 고르는 시간이었다.
yolo를 정확하게 어떻게 사용할지, 유니티에서는 VPS를 사용할지 말지, 등을 정했다.

그리고 얘기를 하다보니, 생각보다 서로 생각한 구현이 다른 점도 있어서
그 부분에 대해서 집중적으로 토론했다.

커뮤니케이션 진-짜 중요함.

5차 회의

여기서는 관리자 페이지에 대한 얘기를 했다.
팀 리틀브라더의 아키텍처를 얘기하지 않을 수가 없는데,

    S3 - FastApi - AWS bedrock
   /          \
유니티 - Nest - Postgre
      /
   리액트

이런 느낌이다.

관리자 페이지는 사실 CRUD고, 위에서 볼 수 있듯이 촘촘하게 돼 있는 저 녀석들을 먼저 구현하느라 리액트에 신경 쓸 시간도 없었다.

그리고 마침 신경 쓸 시간이 온 것이다.

이후에도 틈틈이 회의를 하며 완성해갔고
AWS 수업을 들을 때 모각코를 하거나
그리고 멘토님의 도움을 받아 새로운 기능(도슨트)도 추가하며
완성도를 높이고, 구체성을 확보했다.

버그가 왕왕 터지기도 했으나 잘 잡았다.

완성

우리 팀원들 덕분에 팀원에 대한 기준이 너무나 높아진 것 같다.
협조도 잘하고
의사소통도 잘 되고
특히 의사소통-
예를 들면, 마음에 드는 부분은 마음에 든다. 마음에 들지 않는 부분은 구체적인 근거를 들어 마음에 들지 않는 이유를 말한다. 대안도 함께 제시한다. 오케이 납득 통과.

덕분에 프로젝트를 완성할 수 있었다.