Today I Learned

[TIL] 나만무 6/18 ~ 6/22

eezy 2025. 6. 23. 02:14

6/18(수) : 팀 발표

화요일에 나만무 팀이 발표된 이후, 첫 회의를 진행했다.

첫 회의인 만큼 앞으로 어떤 방식으로 프로젝트를 진행할지, 그리고 팀장이 제출한 기획안을 중심으로 논의했다.

우선 우리 팀의 기본 룰은 아침 10:30까지 강의실에 출근하고, 정규 교육 시간(오후 11시)까지는 강의실에 계속 있는 것으로 협의하였다. 일부 팀원이 새벽까지 깨어 있는 것을 힘들어하기 때문에, 아침 시간을 활용하여 매일 회의를 진행하기로 했다. 일요일은 자율 시간으로 남겨두었지만, 앞으로 진도율에 따라 유동적으로 시간 분배를 하려 한다.

이후에는 팀장의 기획안을 바탕으로 논의하는 시간을 가졌다. 기존에 코치님께서 주신 피드백을 고려하여 기획안을 어떻게 더 구체화할 수 있을지 함께 고민했고, 추가로 나머지 팀원들의 아이디어가 있다면 내일 회의 때 논의해보기로 했다.

6/19(목) : Brain Storming

음악 플랫폼을 만들자는 기존 회의 기반의 내용으로 이 아이디어를 조금 더 구체화 해보았다. 뮬이라는 웹사이트 UI의 불편함 그리고 거래 시 나의 번호가 그대로 노출되는 보안의 취약점에 대하여 문제 인식을 가지고, 새로운 음악인을 위한 플랫폼을 만들기로 했다. 주요 기능을 난이도 순으로 정리해보았다.

< 구현 난이도: 하 >

  • 중고 악기 구매 / 판매
  • 합주 및 공연 인원 모집
  • 합주실 예약
  • 음악 및 공연 추천

< 구현 난이도 : 중 >

  • 공연 예매

< 구현 난이도 : 상 >

  • 음악 스트리밍
  • 메트로톰
  • 악보 자동 넘기기
  • 숏폼 영상 업로드 및 편집

우선 내일 1차 기획 발표가 있기 때문에, 기존 팀장의 아이디어와 내가 제안한 아이디어를 기반으로 PPT 자료를 만들기로 했다.

추가로 나의 아이디어도 사이드 기능으로 일부 포함되긴 했으나...

사실 이야기를 나누다 보니, 내 아이디어는 팀 프로젝트로 확장하기에는 기능적 한계가 있다는 생각이 들었다. 단순히 CRUD 및 외부 API 활용만으로도 충분히 구현이 가능한 수준이라, 전체 프로젝트 스코프에서 보았을 때 다소 작게 느껴졌다.

이번 논의를 통해 느낀 점은, 기획을 할 때 단순히 아이디어 자체만 보는 것이 아니라, 그 아이디어를 통해 얼마나 확장 가능한지, 그리고 내가 어떤 기술적 챌린지를 해볼 수 있는지까지 고려하는 것이 중요하겠다는 점이었다.

6/20(금) : 기획 1차 발표

우리 팀이 제출한 두 아이디어 모두 예상 외로 긍정적인 피드백을 받아서 놀랐다! 코치님은 기술적 챌린지가 적절하지만, 두 아이디어 모두 조금 더 구현의 난이도를 높여보는 방향을 생각해보라는 피드백을 받았다. 아래 피드백을 바탕으로 어떤 아이디어로 갈지, 그리고 어떻게 구현 난이도를 높여 볼지 추가적으로 생각해보는 시간을 갖기로 했다. 결과적으로는 음악 아이디어로 굳혀졌다.

5팀 코치 피드백

발표자 : 팀장

 

1. 여행 기록 및 공유 서비스

  • 사용자의 평판 등에 대한 정보가 단순한 프로필로는 부족하다. 당근의 매너온도 처럼, 서로가 서로를 평가할 수 있는 시스템이 필요하다. 그래야 신뢰성을 기반으로 한 온라인을 넘어선 오프라인 만남이 가능하다.
    • 간단하게는 친구 맺기, 차단 기능 등의 구현이 필요하다
    • 만남이 1:1 뿐만 아니라 다수인 경우, 단체 채팅방 구현과 모임 장소를 정하는 파이프라인 등에 대해 고민해라
    • 여러 명의 위치를 기반으로, 만남을 하기 가장 최적한 장소 (스패닝 트리 등)
  • 지도에서 보여지는 컨텐츠만 보여주는 것으로는 부족하다
    • 그 곳까지의 경로 등, 앱을 이탈하지 않을 방안. 단순히 위치를 보여주는 것을 넘어선 지도 UI에 대한 필요성이 느껴지도록 아이디어 디벨롭이 필요하다

2. 올인원 음악 플랫폼

  • 합주를 구현하기에는 기술적으로 어렵다. 영상과 사운드를 같이 구현하며, 이를 실시간으로 편집하는 것은 단순히 컴퓨터 사이언스 기술을 넘어서 음악에 대한 이해가 필요하다
  • 제공하는 기능이 많아, 기한 내 완성도 높은 서비스를 뽑아낼 수 있는지 현실적인 고민이 필요하다.

전체 피드백 : 1) 만남에 대한 구체화. 2) 합주에 대한 기술적 구현 방향성

2차 피드백

  1. 김정민 서브 코치
    • 음악 플랫폼에서 릴스가 메인이 되었으면 좋겠다.
    • 공감대가 없는 사람에 입장에서는 중고 장터가 뜬금없어 보이나, 스토리상 잘 엮을 수 있다면 좋음
    • 기술적 챌린지가 적당히 있어서 좋다
  2. 유윤선 코치
    • 아이디어 자체는 둘 다 좋다. 그 이유는 기술적으로 보여줄만한 내용이 충분하다
    • 다만 릴스 부분에서, 기술적으로 더 보여줄 수 있는게 있으면 좋겠다
    • 단순히 기존 라이브러리를 가져다 사용하는 것으로는 부족할 수 있다
    • 라이브러리를 사용하되, 기술적으로 어필할 수 있는 부분을 더 생각해보라

6/21(토) : 기획 구체화

음악 아이디어에서 구체적인 기획에 대해 각자 알아보고 논의해보기로 했다.

메인 주제는 프론트, 백, DB의 아키텍처 선정, 각종 협업 도구를 어떻게 활용할지, 그리고 음원에 대한 저작권 이슈 등으로, 각자 분야를 맡아서 조사하기로 했다.

나는 프론트와 저작권 관련하여 조사를 진행했다.

프론트는 React & React-Native를 혼합하여 사용하는 방향으로 논의했다.

그 이유는 일부 영상 편집 기능은 앱에서만 진행하는 것이 프로젝트의 스코프와, 우리가 사용하려는 JS 기반 언어와 잘 맞기 때문이다. 알아본 바로는 웹에서는 영상 편집 같은 CPU 집약적인 기능은 구현이 어렵다고 하며, 아직까지는 WebAssembly 기반으로 코드를 컴파일하는 방식이 주로 사용된다고 한다.

백엔드는 Node.js로 거의 고정되었다.

그 이유는 실시간 채팅 등의 기능을 구현하기 위해서는 Node의 비동기 I/O 방식이 가장 잘 어울린다고 판단되었고, Spring은 각자의 러닝 커브에 따라 개발 속도가 지연될 수 있기 때문이었다. 추가로 이미지 ML의 경우는 Python 서버를 별도로 운영한다.

DB 또한 이미지나 영상은 NoSQL 기반의 Redis 서버를, 나머지 CRUD 기능은 SQL DB를 운용하려 한다.

이 과정에서 PostgreSQL과 MySQL 사이에서 고민했으나, 추가 확장성을 고려하여 PostgreSQL로 결정했다. 이외에도 개발을 위한 도커 환경 및 AWS 환경 구축에 대해 알아보기로 했다.

나머지 시간은, 우리가 논의한 기능을 기반으로 Wireframe을 Figma를 활용해 구상하였다. 그 중 나는 채팅 서비스와 공연 홍보 게시판을 메인으로 구현했다.

6/22(일) : 쉬어가는 타임

일요일은 쉬어가는 타임으로 잠깐만 회의했다.

우선 내일 발표를 앞두고, 먼저 발표 리뷰를 진행했다.

추가적으로 이미지 ML에 대하여, 기타 쉐입으로 인식에 문제가 없을지에 대해 기타 카테고리를 분류한 내용을 기반으로 논의했다. 예를 들어 스트랫 일렉기타는 왼쪽이 조금 더 뾰족한 쉐입인데, 이를 기반으로 이미지를 처리하고, 그다음 헤드를 보고 브랜드를 인식하는 등 단계적으로 나누어 연산 처리하는 방법이 있다고 한다. 사실 이건 뭐... 잘 모르겠다!

추가로 React를 사용할 때 전역 상태 관리를 위해 Redux를 공부하기로 했다.

나머지 시간은 기존에 Week14에서 못 풀었던 알고리즘을 다시 풀어보고 있다. 확실히 처음 알고리즘을 접했을 때보다는 내 생각을 코드로 옮기는 시간이 조금은 더 빨라졌지만, 여전히 문제를 어떻게 접근할지에 대해서는 고민을 많이 해봐야 할 것 같다. 답은 맞았지만, 내 코드를 보면 어디선가 불필요한 연산을 계속 하고 있었고, 그런 부분 때문에 메모리 부족을 자주 경험했다.

특히 문자열(string)을 다루는 방법은 아직도 조금 헷갈린다. LeetCode의 Fraction to Recurring Decimal 문제를 푸는데, 소수점 밑의 나머지와 자릿수를 어떻게 저장해서 괄호를 씌울지가 고민이었는데, 결국 dictionary를 이용하면 된다는 해답을 보고 풀었다. 다양한 자료구조의 활용이 이렇게 쓰이는구나 하고 다시 한번 느끼게 되었다.