Boot-Up : 개발 전 시동 걸기

Kernel360

최근까지 AI 대학원에 가야할지, 취업을 선택해야할지 많은 고민이 있었습니다. 이유는 1년 반이 넘도록 학부 연구를 하고 있어서 대학원에 가지 않기에는 시간과 노력이 아깝지만, 반면에 대학원에서 또 2년 동안의 연구를 진행하는 것에 대한 자신감이 없었습니다.

학부 연구를 하면서 학교 서버 성능의 한계로 인해 모델의 batch size를 크게 잡을 수 없거나 실험 자동화가 어렵다는 어려움을 겪었습니다. 물론, 이러한 문제들을 해결하기 위해 쉘 스크립트를 작성하는 등 노력을 기울였지만, 실제 기업에서 사용되는 인공지능 모델은 어떻게 훈련을 주기적으로 실행하는지 궁금했습니다.

또한, 모델의 성능을 높이는 연구를 하더라도 실제로 모델이 상용화되지는 않기에, 연구에 대한 회의감을 가지기도 했습니다. 이런 이유로, 더 실용적인 일을 하고 싶었고, 그동안의 나의 연구 활동과 나름(?) 관련 있는 MLOps 분야에 관심을 갖게 되었습니다.

개발은 대학교 2학년 2학기에 창업 준비팀에서 앱 프론트엔드 개발을 한 뒤로 거의 없었는데, 그 때만큼 몰입했던 순간이 없었습니다. 그래서 다시 한번 개발 공부 해야겠다 결심했고, Kernel360을 알게 되어 수많은(?) 선발 과정 끝에 크루로 합류하게 되었습니다. (압도적 감사)

---

Boot-Up 프로젝트란?

협업에 대한 이해를 강화하고, 현실적 협업에 대해 경험하는 것을 목표로 합니다.
공유하는 프로젝트로 구현보다는 기능 설계와 문서화에 집중하며 하나의 프로젝트를 만들 때 어떤 과정으로 어떻게 협업을 해야 하는지 배웁니다.

프로젝트는 총 3일 진행되었고 1, 2일차는 어떤 주제의 프로젝트를 진행할지 논의한 후 시스템 아키텍처, API 명세, UX/UI, DB ERD 등을 작성 및 설계를 진행합니다. 이 후, 마지막 3일차에는 팀장을 제외한 팀이 바뀌어서 기존의 아이디어를 업데이트 하고 Github 문서화를 진행했습니다.

---

Flavor Match (1,2일차)

먼저 팀원들이 랜덤으로 구성되었고, 팀원들끼리 주제 가이드에 맞게 프로젝트 주제를 선정했습니다.

• 주제 가이드
  1. 전세계에 배포하는 서비스 : 다양한 문화, 시차, 언어, 제도, 인프라를 고려한다.
  2. 사람마다 관점이 다양한 주제 : 다양한 의견이 나올 수 있는 주제를 선정한다.
  3. 많은 기능이 있어야 하는 주제 : 일부러 기능을 많이 포함할 수 있도록 한다.

위와 같은 가이드를 가지고 고민을 하다보니 Flavor Match 라는 프로젝트가 구상 되었습니다.

(같은 가이드를 두고 여러 팀이 고민하다보니 결국은 다들 음식 관련한 프로젝트가 나오게 되었,,,)

프로젝트 소개

• 배경: 세계의 많은 사람들의 문화, 종교, 신념, 취향 등이 서로 다르고 더욱 세분화되고 있으나 이런 개개인의 요구를 수용할 수 있는 식당을 찾는 서비스가 없다.
• 목표: 다양한 사용자의 요구를 수용할 수 있는 음식점 추천 어플 구현하기
• 사용한 협업 툴
  • Git, Notion : 노션을 기본으로 하고, 팀원 모두 Git에 익숙해지도록 노력했습니다.
• Git 링크 : https://github.com/Kernel360/boot-up1-flavor-match

밑의 내용부터는 제가 참여한 부분에 대한 내용들 입니다!

(기술 스택, 기능 명세서 작성, 화면 설계, DB ERD 작성)

그리고,,, 센스있는 ‘Flavor Match’ 프로젝트명 작명은 제가 했습니다 ㅋ

(기획만 한) 기술 스택

• FrontEnd
  • language: javascript
  • framework: react native
• BackEnd
  • language: java
  • framework: spring boot, hadoop
  • ORM: JPA
• Database
  • MySQL, cassandra
• External library, API
  • library: moneta, i18n
  • API: Java Exchange Rate API, Google places API

기능 명세서에 맞게 어떤 기술을 사용해야 하는지 정했습니다. 제가 가지고 있는 지식을 짧았지만 다른 팀원분들 덕분에 어떤 기술이 어떤 기능 때문에 필요한지에 대해 알 수 있었고, 이 후 실제 개발하는 프로젝트에 있어서는 오버 엔지니어링 없이 기술의 장단점을 토대로 프로젝트 목적에 맞는 기술을 채택해야겠다고 생각했습니다.

기능 명세서

필요하다고 생각되는 기능들을 모조리 적어보았습니다. 기능 명세서를 먼저 작성해야 이 후 DB ERD, api 명세서, 화면 설계 등이 나오기 때문에 기능 명세서부터 시작했습니다 !

화면 설계

대학도 공대라 논문 리뷰하려고 ppt 만들면 교수님께서 그냥 흰 배경에 실험 결과표, 검정 글씨만 넣으라고 하셨기 때문에 디자인에 대해 정말 고민해본 적이 없었던 지난 날들…

팀원 분들 중 (당연하게도) 디자이너는 없기 때문에 ppt로 간단하게 화면 설계를 했습니다. 잠깐 동안의 경험이지만 디자이너의 소중함에 대해 생각해볼 수 있었습니다. (ㅠㅠ)

그리고 디렉터님께서 화면 설계부터 하면 기능 명세, 시스템 아키텍처 작성 등이 더 쉬워진다는 팁을 주셨습니다 ! (너무 늦게 알았습니다 ㅠ.ㅠ )

DB ERD

기능 명세서를 토대로 DB ERD를 작성했습니다.

dbdiagram.io를 통해 작성했는데 바뀐 팀에서 draw.io를 사용하며 dbdiagram.io의 편리함을 뼈져리게 느꼈습니다. (한참 고생하다 dbdiagram.io로 바꿈)

---

Samsik (3일차)

슬슬 팀에 적응하려는 찰나, 랜덤으로 팀이 바뀌었습니다.

먹을 것에 진심인 제게 딱 맞게도 ‘또’ 음식을 주제로 한 팀으로 오게 되었습니다.

프로젝트 소개

• 목표: 해외에 나가서도 원하는 음식점을 찾을 수 있는 서비스 만들기
• 사용한 협업 툴
  • Git, Notion : 노션을 기본으로 하고, 팀원 모두 Git에 익숙해지도록 노력했습니다.
• Git 링크 : https://github.com/Kernel360/boot-up1-samsik

제가 팀에 와서 참여한 내용들입니다.

Git 협업

• Project 기능

깃허브의 Project를 사용하여 구현해야할 기능들에 대한 이슈를 생성했습니다.

• PR 리뷰

팀원들을 리뷰어로 지정하고, 팀원 중 2명 이상이 approve 해야 merge할 수 있도록 했습니다.

깃허브가 단순히 버전 관리만 하는 것이 아니라 협업을 위한 다양한 기능들이 있다는 것을 알았고 계속 사용해 나가면서 배워야겠습니다! (깃허브 어려워요)

API 명세서 작성

처음 팀에 이어서 API 명세서를 또 작성했습니다. 전의 팀과 다르게, 네이밍 컨벤션을 정해서 API 명세서를 작성했더니 통일되게 작성할 수 있었습니다.

• 네이밍 컨벤션
  • 생성 : create
  • 조회 : search, 복수 건 조회 시 뒤에 s 붙이기
  • 수정 : modify
  • 삭제 : delete
  • 가게관련 api는 /owner가 prefix
  • 일반 유저 api는 /

---

회고

당시에는 실제 개발을 하지 않았기 때문에 기획한 것이 어떤 식으로 동작이 되는지 감을 못 잡았습니다. 하지만 현재 글을 쓰는 시점(Boot-Up 프로젝트 2주 후)에 다른 개발 프로젝트를 진행 중인데, 개발 전에 꼼꼼하게 api와 DB ERD를 작성해야 하는 이유, 프로젝트에 맞는 기술 선택의 중요성 등에 대해 몸소 체험하고 있습니다. Boot-Up 프로젝트를 통해 개발 전의 필요한 과정들에 대해 배울 수 있었습니다.