첫 서버 개발 도전기(1) - 실시간 브레인스토밍 협업 툴, STORM

본 포스트는 서비스 소개부터 DB 설계까지의 이야기를 담고 있습니다.

"컴공인데 이걸 왜 하세요?"

2년 간 여러 활동을 하면서 내가 가장 많이 들었던 질문이다. 융합콘텐츠학과를 복수전공하기 시작했을 때도, 영삼성 리포터즈로 활동했을 때도, 언제나 이 질문을 받았다. 아마도 이 질문은 "컴공인데 (왜 개발은 안 하시고) 이런 활동을 하세요?" 였을 것이다. 답은 간단했다. 의미 있는 서비스를 생각해내고, 눈에 보이도록 그려내고, 사람들이 그 서비스를 정말 즐겨 쓰는지 확인하는 일을 나는 너무나도 좋아했기 때문이다. 그렇게 주전공은 뒤로 넘겨둔 채 UX/UI에만 집중했던 오만한 컴공생은 곧 이 문제와 부딪혔다.

'이거.. 개발이 되나?'

내가 생각하기에 아무리 신박한 서비스면 어쩌나. 개발이 가능한지 알 수가 없었다. 주변에서는 "컴공이시죠?"하며 눈을 빛내며 바라보는데 나는 그저 웃을 뿐 아무 말도 할 수 없었다. 아, 재미 없다고 피하기만 했던 개발을 마주해야만 할 때가 드디어 와버린 것이다. 그래서 울며 겨자먹기로 학교에서 했던 프로젝트를 긁어모아 대학생연합 IT 벤처 창업동아리 SOPT에 지원했다. 지금 생각해보면 동아리에 합격한 것이 참 놀라운게, 서버 파트에 지원해놓고 서버가 뭔지도 모르고 있었다. (밈으로 널리 알려져있는 Java와 javascript가 형제지간인줄 알았던 게 바로 나였다.) 아무튼 무엇이든 다 배워버리고 말겠다는 내 열정을 알아봐준 동아리 덕분에 드디어 본격적인 개발에 첫 발을 들이게 되었다.

---

⚡팀빌딩⚡

SOPT에서는 3주간의 해커톤인 APP JAM(이하 앱잼)을 진행한다. 전체적인 진행 과정은 먼저 PM의 기획 경선으로 앱잼에 참가할 아이템이 최종 선정되고, 기획자와 디자이너가 우선적으로 팀을 꾸려 2주간 서비스를 디벨롭한다. 이후 개발자 팀빌딩을 통해 클라이언트 개발자와 서버 개발자가 합류하여 서비스를 3주간 개발한 후, 데모데이에서 이를 발표하는 것으로 마무리된다. 해커톤 참여가 처음이었던 나는 어떤 팀을 선택해야 할지 고민이 많았다. 그때 나름대로 세웠던 기준은 다음과 같다.

첫째로, 새로운 서비스를 개발하고 싶었다.
동일한 분야에서 이미 이름을 날리고 있는 비슷한 서비스가 없으며, 사용자들이 신선하다고 느낄만한 새로운 서비스를 만들어보고 싶었다. 이때까지는 내 개발 활동의 목적이 의미 있는 서비스 제작에 참여하는 것이었기 때문이었다. 이미 풍부한 기능이 탑재되어 있고, 사용자들에게 대표적인 서비스로 각인되어 있는 타 서비스가 존재할 경우 이 목표에 다가가기 힘들다고 생각했다.

둘째로, 재밌는 서비스를 개발하고 싶었다.
첫 번째 이유와 비슷한 맥락이지만 조금 다르다. 사용자들이 사용할 때 재밌다고 느끼는 서비스를 개발해야 개발하는 나도 재밌다고 느낄 수 있을 거라고 생각했다. (지금 생각해보면 이 당시의 내가 생각하던 '재미'는 게임적인 요소였던 것 같다.) 이왕 하는 거 개발이 정말 재밌는지 직접 느껴보고 싶었다.

마지막으로, 서로를 격려하는 팀에 가고 싶었다.
첫 개발이었고 첫 해커톤이었기 때문에 무엇보다도 즐거운 기억을 남기고 싶었다. 게다가 동일한 시드의 다른 선배 개발자들에 비해 개발 경험이 전혀 없는 나로써는 서툴러도 함께 응원하며 나아갈 수 있는 팀원들이 필요했다. 그때의 나는 본인이 전혀 긴장하지 않았다고 생각했는데, 이렇게 다시 돌아보면 엄청 긴장했던 것이 틀림 없다.

생각은 이렇게 했지만, 실제로는 내가 팀을 '선택'하는 것이 아니라 경험 없는 개발자를 '선택해주는' 팀을 찾아가야만 했다. 그래도 나름의 핵심 가치를 미리 생각해두고 팀빌딩에 참여한 덕분에 개발하고자 하는 서비스에 대한 애정을 가지고 어필할 수 있었고, STORM이라는 좋은 팀을 만날 수 있지 않았나 생각한다.

---

⚡STORM⚡

결론부터 이야기하자면 놀랍게도 STORM은 내가 생각했던 세 가지 기준을 모두 충족하는 팀이었다. 새롭고 재밌는 서비스를 좋은 팀원들과 함께 만들다보니 개발 자체에도 흥미를 가지게 되었고, 프로젝트 이후 서버 개발자의 길을 걷고자 결심하게 되었다. STORM이 도대체 어떤 서비스이길래 진로를 개발자로 변경했을 정도로 새롭고 재밌다고 느꼈는지 아래에서 간략하게 소개하고자 한다.

.

데모데이 발표에 사용되었던 STORM 프로모션 영상. 음향부터 모션까지 아주 근사하다.

영상을 보면 알 수 있듯이, STORM은 브레인스토밍 기법을 활용해 더 효율적으로 아이디어를 생각해내고, 팀원들과 쉽게 공유하도록 함으로써 협업을 돕는 툴이다.(데모데이 이후 회의를 통해 플랫폼에서 툴로 변경되었다.) 마치 게임처럼 프로젝트를 생성하여 팀원들의 접속 여부를 확인하고, 라운드마다 팀원들의 카드를 훑어보며 아이디에이션을 할 수 있다는 것이 새롭고 재밌는 STORM만의 포인트다. 협업이라는 키워드를 딱딱하지 않고 색다르게 풀어냈다는 것이 내가 가장 매력을 느낀 부분이었다.

---

앱잼에서 서버의 역할은 아래와 같다.

1. 서비스의 핵심 기능과 워크플로우를 확인한 후, DB를 설계한다.
2. 클라이언트 개발자가 참고할 수 있도록 API 명세서를 빠르게 작성한다.
3. 작성한 API 명세서대로 API를 개발한다.
4. 개발한 API를 배포하여 클라이언트에서 접근이 가능하도록 관리한다.
5. 이후 클라이언트 개발자와의 소통 및 기획 수정 사항에 맞춰 API를 수정한다.

(수정은 언제나 발생한다. 수정 요청을 무조건적으로 거절하거나 승인하는 것은 이후 더 큰 오류를 발생시키는 원인이 된다. 수정을 요청할 때는 적절한 근거를 함께 준비해야 하며, 수정 요청을 받았을 때 그 근거가 타당하면 수정을 미뤄서는 안된다.)

위의 개발 순서에 따라 먼저 진행했던 DB 설계 과정에 대해 이야기하고자 한다.

---

⚡DB 설계⚡

새로운 서비스의 DB를 처음부터 구상하는 것은 어렵고도 즐거운 일이었다. 서버가 처음인 두 명이 머리를 맞대고 어떻게든 DB를 구성해보자며 뷰를 하나 하나 뜯어보던 기억이 아직도 생생하다.

1단계) 뷰를 참고하여 필요한 데이터 목록을 뽑아내기

당시 최신 버전의 뷰와 워크플로우를 펼쳐놓고 STORM 내에서 사용되는 모든 데이터를 체크했다.

"사용자가 라운드를 만들면 어떤 정보가 필요하지?"
➡ "어떤 프로젝트인지 프로젝트 정보가 필요하고, 라운드 목표도 보여줘야되고, 몇 라운드인지도 체크해야 돼!"
➡ "그럼 프로젝트 하나당 라운드가 여러개니까 1:N 관계고, 라운드 테이블은 프로젝트 정보를 참조해야겠다."
➡ "그럼 라운드 하나에 참여자가 여러 명이니까 참가자 테이블은 라운드 정보를 담는 테이블이랑 분리해서 만들어야겠네."

위와 같은 흐름으로 각각의 뷰를 뜯어보며 필요한 데이터들을 쭉 적어내려갔다. 게임처럼 라운드를 계속 생성해야 하는 서비스 특성상 데이터가 꼬리에 꼬리를 물고 연결되는 특징이 있어서(ex - 라운드 참여자 테이블에는 사용자 정보가 담기며, 각각의 라운드 참여자 정보에는 어떤 라운드에 참여하고 있는지를 나타내야 하기 때문에 해당 라운드 정보를 참조하고, 해당 라운드 정보는 어떤 프로젝트의 라운드인지를 나타내야하기 때문에 해당 프로젝트 정보를 참조하고...와 같은 식이었다.) 다른 데이터를 참조를 하거나 참조되는 부분이 많았기 때문에 모든 테이블에 idx column을 가장 먼저 적어넣었다.

2단계) 워크 플로우를 따라가며 나열한 데이터들의 관계를 정리하기 (정규화 작업)

1단계에서 정리한 정보들을 가지고 워크플로우대로 사용자가 하나의 서비스 사이클을 도는 과정을 시뮬레이션했다. 빠트린 정보는 없는지, 정보간의 관계를 잘못 정의한 부분은 없는지 여러 번 체크를 했는데, 이 과정에서 각 테이블간의 관계를 꼼꼼하게 정리하고, 기본키와 외래키를 설정하고, 부분적 종속을 삭제함으로써 테이블을 한층 깔끔하게 정규화할 수 있었다.

이렇게 시뮬레이션을 하며 데이터를 체크해가며 검토하다가, 한 카드에 여러 사용자가 각자의 메모를 남길 수 있기 때문에 메모의 경우 카드 테이블의 column으로 두는 것이 아니라, 별도의 테이블로 빼야 한다는 것을 발견할 수 있었다. 이 경험을 통해 DB를 설계할 때는 꼼꼼한 검토가 정말 중요하다는 것을 느낄 수 있었다. 카드 테이블에 넣어둔 채로 개발을 시작했으면 엄청난 후폭풍을 겪을 뻔했다.

왼쪽은 직접 손으로 그린 ERD. 이후 AQueryTool을 발견해 웹으로 옮겼다. 과거의 내가 ERD를 손으로 그릴 생각을 했다는게 아직도 너무 웃기다.

3단계) DB의 효율성을 고민하기 (필요시 역정규화 작업 진행)

테이블을 정리하고 나니 카드 테이블이 우리를 괴롭혔다. 원칙대로라면 라운드 테이블에서 프로젝트 정보(project_idx)를 가지고 있기 때문에 round_idx만을 참조하는 것이 맞지만, 카드를 출력하는 모든 뷰에서 프로젝트 이름을 출력해야했기 때문에 이렇게 DB를 구성하게 될 경우 계속해서 join을 써서 정보를 출력해야 할 것이 눈에 선했다.

project_idx를 카드 테이블에도 추가하여 중복되는 데이터가 공간을 조금 더 차지하더라도 빠른 정보 검색이 가능하도록 설계하는 것이 나을지, 아니면 검색 속도 차이가 그리 크진 않을테니 테이블을 이대로 두고 join을 사용할지 고민했다. 서버 개발자 둘이서 열심히 고민한 결과, 결론은 project_idx를 카드 테이블에 추가하는 것으로 결정했다. project_idx 자체가 공간을 많이 차지하는 데이터도 아닐 뿐더러, STORM은 카드를 생성하는 것이 전부인 서비스이기 때문에 공간이 부족할 정도로 많은 데이터가 쌓일 것 같지 않다는 예상을 했기 때문이었다. 생각보다 사용자들이 한 라운드에서 많은 카드를 사용하지 않는다는 것을 알게 된 지금으로써는 참 귀여운 고민을 했었다는 생각이 든다. 결과적으로 API를 개발할 때 join을 확실히 덜 쓸 수 있어서 깔끔한 코드를 작성할 수 있었기 때문에 효율적인 선택이었다고 생각한다.

우여곡절 끝에 완성된 ERD! 이후로도 호스트 테이블을 따로 분리하는 등, 꽤 많은 수정을 거쳤다.

처음 DB를 설계하는 것 치고는 꽤 많은 사항들을 고려하며 신중하게 설계한 것 같아서 돌이켜보니 새삼 뿌듯하다. 데이터 타입을 신중하게 결정하라는 서버 파트장님의 조언을 참고하여 다양한 상황에서의 데이터 흐름을 고민하고, 여러 번 꼼꼼하게 시뮬레이션하는 과정을 통해 탄생한 위의 ERD를 슬랙에 바로 자랑했었던 기억이 난다. 손으로 그린 ERD를 보고도 멋지다는 이모지를 찍어준 STORM 멤버들이 참 좋은 팀원이었음을.. 새삼 느낀다.


첫 앱잼에 대한 생각까지 녹여내다보니 첫 글이 생각보다 매우 길어졌다! 다음 포스팅은 본격적인 API 개발기에 대해 적을 예정이다 :)