한결과 레지아이스

42GG, 5월 23일부터 7월 13일 사이의 기록. 본문

42GG

42GG, 5월 23일부터 7월 13일 사이의 기록.

miniwho 2022. 7. 17. 04:01

인생 첫 프로젝트, 42좋은 42서울인을 위한 탁구 생활 서비스, [42GG]를 런칭했습니다.
다행히도 첫 날 동안 버그는 없었고, 별다른 이상 없이 마칠 수 있었습니다. 이 글을 쓰는 오늘 까지도 다행히 결함으로 서버가 내려간다거나 하는 문제 없이 서비스를 원활히 제공할 수 있었고, 기쁜 마음에 첫 날부터 런칭까지 제가 개발하고 경험하고 느낀 것에 대한 글을 써보려 합니다.

개발 배경

먼저 저는 42서울이라는 교육기관에서 2년간의 교육과정을 밟고 있는 카뎃(≒학생)입니다. 제가 공부하는 곳은 클러스터라고 부르는데, 여기에는 탁구대가 딱 하나 있습니다. 탁구대는 하나, 학생들은 300명 이상… 당연하게도 탁구 한 판 치려면 기다림은 일상이었습니다.
기다림을 해소하기 위해, 그러면서 즐거움은 더하기 위해 저희 팀은 단순한 탁구대 예약을 넘어선 서비스를 만들고 싶었습니다. 그렇게 여러 논의 끝에 랭크전 형태의 매칭 서비스를 만들게 되었습니다.
42GG는 10명이 팀으로 모여 진행했습니다. FE 5명, BE 5명이 모였는데, 둘 둘은 기존에 함께 카뎃을 위한 익명 사이트(42byte.kr)를 만든 팀이었고, 이외에는 과제 이외의 개발이 처음인 카뎃들이었습니다. 저는 후자로서, 백엔드로서 참여했고, 많은 걸 배우고 느낄 수 있었던, 그리고 뿌듯하고 성공적이었던 경험이기에 기록까지 남기게 되었습니다.

첫 만남에서 기획까지

저는 기존 서비스(42byte) 백엔드 개발 설명회에 참여한 것을 계기로 백엔드 팀에 들어오게 되었습니다. 경험자 두 분(이후 리드라고 호칭)께서 해당 서비스를 스프링 부트와 mysql을 이용해 개발했기 때문에 이번에도 같은 기술로 개발을 하게 되었습니다.
저는 자바는 아주 조금 할 줄 알고, 스프링/부트는 문외한이었습니다. 그래서 인프런에서 김영한님의 강의를 기획 단계동안 최대한 많이 들으려 노력했습니다. 데이터베이스에 대해선 일단 쿼리문까지는 몰라도 스프링이 해준다는 말을 듣고 스프링에 최대한 집중했습니다.
탁구 랭크 매치를 하자! 라고 정한 뒤에 기획은 시나리오를 기반으로 진행되었는데, 열 명이나 모인지라 각자가 서비스에 대해 생각한 시나리오를 공유하고 좋은 점을 추려나가는 방식이었습니다.

▼ 시나리오 관련 자료


각각 작성한 시나리오 - https://github.com/42organization/42arcade/wiki/기획-'시나리오-작성'
기반으로 정리된 내용 - https://copper-way-3a6.notion.site/5-25-e041be6d19e84953a4a89ed503968960) — 정리해주신 nheo님께 이 자리를 빌어 감사를..


결과로 나온 것은

  • 탁구대에 시간별로 참여할 수 있는 게임 슬롯이 존재하고,
  • 해당 게임 슬롯에 수준이 맞는 유저들이 참여해 게임을 진행하고
  • 그 기록을 남기되 자신의 수준이 점수로 정해지는

서비스입니다.

우리만으론 안돼!

기획은 좋았지만 항상 그렇듯 문제가 있었습니다. 바로.. [탁구대는 우리의 것이 아니다!]라는 것이었습니다. 클러스터에서 카뎃들이 공공재로 사용하는 것을, 우리의 서비스가 점유해도 되는가? 라는 문제가 있었습니다. 탁구대는 하나고, 우리 서비스 이용은 해당 탁구대에서 이뤄지는데, 어떤 유저가 매치를 잡은 시간에 누가 이미 탁구를 치고있다면.. 이런 문제는 팀원들끼리 해결할 수 있는 게 아니었습니다.
그래서 저희는 먼저 클러스터 운영 스태프의 장을 만났습니다. 현재 이런 서비스를 기획하고 있다고 설명드렸고, 예상되는 문제는 위에 적은 것이고, 도움이 필요하다고 말씀드렸습니다. 스태프 측에서는 충분히 제공해 줄 수 있지만 카뎃들간의 합의가 필요할 것이라고 말씀 해주셨고, 저희는 서비스 수요 설문조사를 진행하게 되었습니다.


여기까지 과정이 시간이 생각보다 오래걸려 개발을 병행하고 있었는데, 결과를 보고 우리가 프로젝트를 제대로 진행해도 되겠다, 기다리는 사람이 많다! 라고 확신을 얻어 이때부터 본격적으로 개발을 진행했습니다.

고난의 백엔드

백엔드 개발기
https://island-zebra-5e0.notion.site/42GG-a2c4be0528cf498bacc9697e2b335202


백엔드 처음이고.. 스프링도 처음이고.. mysql도 처음이고…. 모르는 것들로 뒤덮인 시작이었습니다. 그나마 다행이라면 자바는 조금 안다는 것? js 프레임워크를 사용했다면 정말 아무 것도 몰랐을 터였기에, 자바라서 나았습니다.
백엔드는 기획단계에서 API 설계와 erd클라우드를 통한 db 설계를 진행했습니다.

▼ API 설계 문서와 DB 설계

API 설계 문서 - https://www.notion.so/2d439ee97ad147809a54c6c39ff2be13?v=b71bafc54f99451492b27f266a3a30ce

이해도가 부족해 FK를 선으로 잇는다거나 하는 작업을 못했다.. 몹시 아쉽고 공부를 더 해서 수정하고 싶은 부분.

초반 작업

리드 분들은 프로젝트 경험이 있고, 저와 다른 동료 둘은 없었기 때문에 처음에는 다 같이 code with me를 통해 하나의 소스를 만들었습니다. 팀원들이 설계에 맞춰 소스를 작성하면, 리드 분들이 알려주고 수정하는 방식으로 진행했고 이때 정말 많이 배웠습니다. 하지만 시간이 오래 걸리고, 한 번 무언가 놓치면 따라가기 힘들다는 단점이 있었습니다. 지금 생각하면 같이 진행도 좋지만, 작업은 각자 하되 내용을 팀원들에게 설명해주고 리뷰를 받는 식으로 진행했으면 하는 아쉬움이 남습니다.
개발은 제가 여태 경험해온, 과제로서의 개발과는 천지차이였습니다. 거의 처음부터 끝까지 그건 왜해야돼요? 라는 질문을 입에 달고 살았습니다. 테스트서버? 로컬서버가 있는데 왜필요해요?? 어드민 페이지? db 수정하면 될텐데 왜필요해요?? DTO? 그냥 인자로 여러개 넘기면 되지 그런 건 왜써요??

▼ 지금은 조금 알 것도 같은.. 프로젝트가 끝난 저의 대답

 

  • 테스트서버: 로컬 서버만 있을 때는 프론트와 협업하기가 몹시 힘들다.
  • 어드민 페이지: DB를 직접 수정하는 건 해당 부분을 작업한 개발자 이외에는 위험한 일이라고 생각된다. 데이터들이 엮여있어 하나를 수정하면 다른 것도 수정되어야 하는 게 많은데, 이걸 일일히 기억하고 DB에서 이 친구들을 다 수정하는 것도 어렵다. 그리고 운영을 꼭 개발자가 한다고 생각하면 안되기에, 어드민 페이지는 꼭 필요한 것 같다.
  • DTO: 처음에는 만드는 이유를 몰라 만들기가 귀찮았는데, 코드 수정이 반복해서 일어나면서 DTO에 감사하게 되었다.. 넘겨줄 인자가 바뀌면 DTO만 수정하면 거의 일이 끝난다! 유지보수와 협업을 위해 굉장히 필요한다고 느꼈다.

테스트는 중요하다

화룡점정은 테스트였습니다. TDD를 시도해보려 했으나.. 쉽지는 않았습니다. 개발에 미숙했기 때문에 기능이 얼추 완성되기 전까지는 어떤 테스트들이 필요할까 떠올리기 어려웠습니다. 그리고 테스트 코드 작성이 뭔가 시간 낭비라는 생각이 들었고 왜 필요한지 잘 몰랐습니다. 그리고 좋은 테스트에 대한 고민이 부족했기에 커버리지가 부족하거나 예외를 충분히 고려하지 않은, 통과를 위한 테스트를 짜기도 했습니다. 하지만 지금은 정말로… 테스트코드가 왜 중요한지 뼈저리게 느꼈습니다.

▼ 혹시나 궁금한 사람을 위한 느낀점

 

  • 빌드는 오래걸린다! 코드를 수정하고 새로 빌드를 올릴 때, 암만 로컬이라도 빌드하고 api 호출해서 테스트해보고 에러가 생기는지 확인하고 하다가는 정말 끝도 없다.
  • 매 번 코드를 수정 할때마다 1번을 계속한다..? 혹은 수정사항이 여러 개이고 기능도 추가했다..? 이런 걸 빌드해서 테스트하다보면, 다 테스트 했다고 생각하지만 결국 나중에 언젠가 터지더라..

분명 생각할 수 있었던 부분인데 놓친 예외들, 혹은 로직의 구멍들이 많이도 있었습니다. 좋은 테스트를 만들고 시작했다면, 혹은 기능을 완성한 뒤에라도 만들었다면 이런 부분을 줄일 수 있었다는 생각이 듭니다.

어드민 페이지

어드민 페이지는 후반부에 제가 혼자 작업한 부분이 많은데, thymeleaf를 이용해 만들었습니다. 결국은 제가 개발을 도맡게 되었지만 시작할 당시에는 제가 보조였고, 크게 중요하다고 생각하지 않아서 42byte의 어드민 페이지 소스를 많이 빌렸습니다. 개발을 빨리 할 수는 있었지만 중간중간 이해하지 못하고 만든 코드 때문에 작동에 문제도 있었습니다. 개발을 앞두고 제대로 동작하게 만드는데 시간을 많이 사용했고, 기술 부채가 이런데서 생기는구나 싶었습니다. thymeleaf와 ajax.. 지금도 잘 모르겠는데 제가 많이 만들게 될 줄 알았으면 공부를 한 번 하고나서 개발할걸 하는 아쉬움이 남습니다.

적극적인 멘토링

적극적이었던건 누구였을까..! 장소가 부족해 멘토룸 앞 책상에서 팀원들이 다 같이 모여 작업을 하곤 했는데, 이때마다 ⭐️이호준⭐️멘토님이 지켜보면서 직면한 문제들을 헤쳐나갈 방법들과 새로운 문제들을 쥐어주고 가셨다. 어떻게 짧게만 지켜보셔도 우리의 문제점을 귀신같이 알아내셨을까. 그리고 쥐어준 새로운 문제들은 우리가 꼭 만나게 될 문제들이었다. 특히 에러코드에 대해서 프론트와 함께 공유하고 문서화하라는 조언은 시간을 정말 많이 절약하게 도와주었다. 멘토님께서 담당하신게 아닌, 우리끼리의 사이드 프로젝트였음에도 너무 많이 도와주셔서 참 감사합니다.

생산성?

어드민 페이지를 만들 때 엄청 많은 기능을 만들고 이것 저것 추가하면서 이러면 편해지고 생산성이 늘어나겠지? 라는 생각을 했습니다. 물론 복잡한 일을 조금 더 편하게 처리할 수 있었지만, 그 기능들을 많이 쓸 일은 없었습니다. 오히려 하루 한 두 게임 42GG를 통해 탁구를 즐길 수 있던 것이 기다리는 시간도 줄이고, 원래 한 시간씩 치던 탁구를 짧고 간결하게 치게 되니 생산성이 늘어나는 경험이었습니다. 무언가 엄청나고 대단한 것만이 생산성을 증대시킬수 있다고 생각했는데, 조금은 다른 관점에서 바라보게 되었습니다.

 

KEEP PROBLEM TRY

KEEP 좋았던, 지켜나가고 싶은 것들

  • 너무 좋았던 분위기. 코딩으로 밤을 새던 날에도 다툼은 없었다. 다들 친하고 서로 위해주는 분위기가 짧지 않은 시간동안 프로젝트를 성공적으로 이끈 주역이라고 생각한다. 그런 분위기를 만들어준 리드님들께 진심감사감사.
  • 기획은 기획대로, 개발은 개발대로 단계별로 잘 이룬 것이 참 좋았다. 기획 단계를 잘 마쳐 개발할 때 로직이 많이 수정되거나 하는 혼돈이 생기지 않았다.
  • 개발 외적인 것을 잘 챙겼다. 특히 탁구대 이용과 관련해 스태프 분들과 소통하고 카뎃들 상대로 설문을 한 것을 참 잘했다고 생각한다. 애써 만든 작품을 수포로 돌아가게 하는 일을 미연에 방지했다.
  • 컨벤션을 정해놓고 시작한 것. 예를 들면 메서드명 규칙이 기억에 남는다. 코드를 여러명이 작성했음에도 규칙을 다 정해놨기 때문에 통일성 있어 보이는건 덤이고 메서드명만 봐도 어떤 메서드일지 알아챌 수 있었다.
  • 정말 많이 배웠다! 물어보기도 많이 물어보고 알려주기도 많이 알려주며 배우는게 많았다. 서로 편한 분위기 덕분이라고 생각한다. 그리고 사고쳐도 나무람 없이 수습을 도와주는 분위기 덕분에 작업이 잘 진행된 것 같다.
  • 모두가 시간을 많이 투자한 것. 50일이 조금 넘는 긴 기간동안 아침부터 밤까지, 다들 주말에도 최대한 출근하며 시간을 많이 투자했다. 참으로 감사한 부분이다.

PROBLEM 문제점, 지양해야 할 것들

  • 프론트와 백을 너무 늦게 합쳤다.. api에 대한 변동사항이 많았는데 이에 대한 소통은 부족해 처음 양 단을 붙일떄 애로사항이 많았다..
  • 처음에는 4주를 목표로 한 프로젝트여서 일정관리 툴(JIRA)를 사용하지 않았는데, 사용해봤으면 좋았을 것이라는 아쉬움이 남는다.
  • 테스트 코드를 소중히 여기고 갈고 닦고 아무튼 열심히 하자.
  • 랭킹 관리를 위해 redis가 사용되었는데, 내가 맡은 부분이 아니라고 너무 공부하지 않았던 것, 그래서 사실 redis에 대해 아무것도 모르는 것이 후회되고 아쉽다.
  • 백엔드!! 문서화가 참말로 부족했다. 특히 문제를 직면하고 해결해 나간 과정에 대해 기록이 부족한것이 너무너무 아쉽다.
  • 나는 시큐어 코딩을 못한다. 테스트는 자꾸 터지고, 테스트 서버에서도 자꾸 터지고.. 무언가 터지면 나일까 두려웠던 기억이 가득하다. 더 단단한 코딩을 지향하며 공부해야겠다.
  • 엄청 큰 프로젝트가 아니었기에, 처음부터 프론트와 백이 함께 했다면 더 많은 걸 배우지 않았을까 하는 아쉬움이 아주 조금..

TRY 다음에는 시도해 보고 싶은 것들

  • 더더더 소통하기. 프론트의 오버커뮤니케이션 따라하기. 우리 프론트에겐 배울게 많다.
  • 프론트 팀의 문서화 능력을 배우기
  • TDD에 대한 책을 읽고 실천해보기
  • JIRA & Confluence 사용하기
  • 팀원들과 코드리뷰 세션 자주 갖기
  • 회식 덜 빠지기🍻
  • 백핸드 드라이브🏓

Thanks to

프로젝트 책임자이자 백엔드를 이끌어주신 nheo님, 백엔드 리드인 donghyuk님, 함께 고생한 백엔드 똘마니들 wochae님과 jiyun님 너무 고생 많았습니다.
그리고 빛나는 결과물을 만들어준 프론트 리드 jabae님과 PM sujpark님, 그리고 jihyukim님, kipark님과 daekim님도 함께 할 수 있어서 정말 행복하고 보람찼습니다. jabae님과 jihyukim님은 디자인까지 너무 잘해주셔서 참.. 대단하세요.
10명, 적지 않은 사람들이 모여 탈 없이 무언가를 해냈다는 것도 대단한 일이지만, 결과도 뿌듯하게 나와서 제가 인복이 참 좋다는 생각을 하게 되었습니다. 제가 티는 안내지만 여러분들을 만나 정말 행운이고 행복합니다. 글은 이렇게 썼지만 아직 끝이 아니고 우리가 나아가야 할 길은 멀기에, 앞으로도 잘 부탁드립니다. 당신들이 최고야!

별첨부록

42GG Github Wiki

Comments