AppJam: 2주간 장기간 해커톤 후기

fluff logo

 

팀이 이름을 남기는 시대

먼저 이 키워드로 포스팅을 시작하고 싶다. 개인이 이름을 남기는 시대가 지나가고, 이제 대부분의 프로젝트가 팀 단위로 이루어지게 됨에 따라 '얼마만큼 팀에 기여할 수 있는가'에 관한 역량이 중시되는 시대가 찾아왔다. 이번 해커톤에서 만들어낸 fluff 프로젝트는 Plan, Design, Android, iOS, Server 총 5개의 파트와 그를 구성하고 있는 13명의 팀원들이 이루어낸 우리의 이야기가 담긴 프로젝트이다. 그렇기에 다른 포스팅과는 조금 성격이 다르게 이 글에서는 우리가 팀이었기에 해낼 수 있었던 것들에 관하여 나누어 볼까한다.

Fluff-Project/Fluff_Server

 

 

One and Only, person & clothe

Fluff(보풀)이라는 뜻을 가진 우리의 프로젝트는 이름에서도 알 수 있듯 옷이 가진 과거의 스토리를 기억하고 이어가려는 의지가 담긴 빈티지 쇼핑몰 플랫폼이다. 옷을 사고 버리기보다는 옷이 거쳐간 시간과 이야기, 옷이 가지는 가치를 재창출해내는 것을 core value로 잡고 기존의 쇼핑몰과는 다른 관점으로 빈티지 옷에 초점을 맞추었다.

fluff 팀은 존중과 솔직함, 그리고 함께하는 성장에 관한 믿음을 가지고 출발했다. 논쟁이 장려되었고, 그 안에서 다양한 아이디어와 의견들이 오고 갔다. 그리고 그 밑바탕에는 서로에 대한 존중이 기초가 되었다. 거침없이 자기 생각을 말할 수 있는 분위기는 2주간의 짧은 기간이었음에도 최대의 퍼포먼스를 발휘할 수 있도록  팀을 역동적으로 이끌어갔다. 그렇게 시작된 우리의 프로젝트는 2주의 시간이 지났을 때 우리의 기대치를 이미 넘어있었다.

 

 

Server 파트가 일하는 방식

해커톤 특성상 주어진 시간 안에 완성을 하는 것은 가장 중요한 문제 중 하나였다. 하지만, 그렇다고 해서 주먹구구식의 하드코딩으로 코드의 품질을 떨어뜨리고 싶지 않았던 우리는 semver version을 도입했다. 가장 기본적이고 가장 쉬운 방식, 즉 동작하기만 하는 방법으로 모든 기능 구현을 마치는 것에 1차적인 목표를 두고, 남는 기간 동안 조금씩 성능이나 정확도에 관한 부분을 다루는 방식으로 프로젝트를 진행했다. (예를 들면 1.0.1 버전에서는 유저의 키워드와 일치하는 모든 상품을 랜덤으로 추천해주는 방식으로 초기 추천 알고리즘을 구현했다면, 1.1.1 버전에서는 content-based-filtering 딥러닝 추천 알고리즘을 적용하여서 좀 더 추천 정확률을 높이는 방식을 사용하였다.) 이런 식으로 프로젝트를 진행하게 되면, 기능 구현에 관한 압박감을 다소 덜 수 있었고, 서버의 변화 과정을 서버 파트원들이 피부로 느낄 수 있는 장점이 있었다. 다만 그러기 위해서 필수적으로 요구되는 것이 있었는데, 바로 섬세한 객체지향적인 설계였다. 해당 기능을 부품처럼 뺐다가 끼울 수 있도록 확장성을 고려해서 모듈화를 적극적으로 장려했다. 그 결과 프로젝트 초기에는 진행상황이 느렸지만, 어느 정도 자리가 잡힌 이후에는 확장성을 고려한 프로젝트 설계로 인해 유연하게 다양한 상황에 대처할 수 있었고, 개발 속도 또한 급격히 빨라졌다. 이러한 방식의 work flow는 서버 개발의 기능 구현이 끝났다고 하여서 클라이언트와의 통신을 넋 놓고 기다리는 것이 아니라, 해커톤이 끝날 때까지 우리는 우리만의 싸움을 계속 이어 갈 수 있었다.

 

 

Server 개발에 대한 개인적인 회고

1. Filing에 관한 고민

이번에 서버에서 사용한 기술 스택은 Node.js였다. 좀 더 세분화된 비즈니스 로직 분리를 위하여 routes와 controller를 분리시키게 되었다.(spring으로 치면 controller와 service관계) 다만 개발 초기 당시 두 가지 방식의 고민이 있었는데, 하나는 routes와 controller를 다른 디렉터리를 분리하는 방식의 fordering이었고, 다른 하나는 routes 디렉터리 안에 router와 controller를 분리하는 filing이었다. 우리 팀은 전자의 방식을 택해, controller를 분리시켰지만 시간이 흐를수록 Node.js에는 후자의 방식이 좀 더 어울리지 않았나 하는 생각이 들었다.

 

(좌) 전자 방식, (우) 후자 방식

이유는 단순했는데, 일단 Node.js를 기술 스택으로 선정한 프로젝트의 볼륨 특성상 controller 디렉터리를 따로 빼서 얻을 수 있는 파일링에 관한 손익분기점이 프로젝트 진행 중에 넘기기 힘들다는 판단이 생겼다. 또한 VScode는 intelliJ나 eclipse만큼 파일의 path를 섬세하게 잡아주지 않아 오히려 path 설정에 관한 에러율이 올라갈 수 있다는 생각이 들었다. ('그럼 intelliJ로 Node.js 개발을 하면 되지 않느냐' 고 하면 할 말은 없지만, 대부분의 Node개발자들이 그러하듯 필자 역시 Node.js 개발로는 VSCode가 좋다:D )

 

 

2. 트랜잭션 (Transaction)

이번 프로젝트에서 채택한 데이터베이스는 NoSQL의 대표주자인 MongoDB였다. 이는 2주간의 해커톤 중 기획이나 클라이언트 개발의 싱크가 변경될 경우에 유연한 대처를 하기 위한 선택이었다. 물론 이 선택은 옳은 선택이었다. 예상대로 기획과 디자인, 클라이언트, 서버 개발의 싱크가 조금씩 변경되었고, NoSQL을 선택하지 않았다면  '마감기한까지 프로젝트를 완성하지 못했을지도 모른다'라는 생각이 들었다. 하지만 개발을 진행하면서 계속해서 트랜잭션 처리에 관한 아쉬움이 남았다. 물론 NoSQL을 사용해서도 비즈니스 로직상에서 트랜잭션과 같은 기능들을 구현할 수 있지만, 코드가 지저분해지고 성능면에서도 결코 RDB에 비해 나아 보이지 않았다.

 

※ 위 내용은 RDB와 NoSQL에 관한 비교가 아닌, 우리 프로젝트에 어울리는 Database에 관한 비교입니다.

 

 

3. 아키텍처(Architecture)

API Gateway

이번 프로젝트는 도커 네트워크를 이용한 멀티 컨테이너 배포를 하였다. 각 컨테이너들은 내부 통신과 외부 통신을 구분하여 통신하였고, 그러다 보니 entry point가 여러 개가 생기는 문제점이 발생했다. 물론 이 정도 볼륨의 프로젝트에서는 그러한 고민이 크게 이슈를 발생시키지 않았지만, 향후 디벨럽 될 확장성을 생각한다면 API Gateway를 두어 entry point를 통일성있게 구성시킬 필요해 보였다.

 

HA(high Availability)

프로젝트 진행 단계 중 클라이언트와 테스트 통신 단계에서 aws에 새로운 버전을 배포할 때마다 클라이언트와의 통신이 단절됨으로 인한 불편함이 존재했다. 불편함 정도의 문제라면 몇 분정도의 불편함을 감수하면 되지 않겠냐고 할 수 있겠지만, 문제는 다른 곳에서 발생했다. 컨퍼런스 당일 몇가지 에러에 대한 패치를 위한 배포를 하고 있을 때였다. IT 컨퍼런스 특성상 상당히 많은 네트워크 트래픽이 한 공간안에서 발생했는데, 그로 인해 배포 중간에 한순간 네트워크가 끊어지는 문제가 발생했다. 단순히 카카오톡과 같은 메신저를 보낼 때의 일시적인 네트워크 단절은 재전송과 같은 방법으로 넘어갈 수 있겠지만, 서버 배포중 발생한 일시적인 네트워크 단절은 인스턴스 안에 구동중인 마이크로 서비스들의 네트워크를 꼬아버리는 심각한 문제를 발생시켰다. 만약 컨퍼런스 당일이 아닌 개발 도중이었다면 시간을 두고 해결했겠지만, 이제 불가 수십 여분 뒤에 시현을 해야 하는 입장에서는 이러한 이슈는 굉장한 부담감으로 다가왔다. 어찌 됐든 해당 에러를 해결하여 성공적으로 기능 시현을 할 수는 있었지만, 만약 에러를 잡지 못하였거나, 실제 서비스 런칭 환경에서는 굉장히 위험성 있는 이슈였다. 때문에 HA(High Availability)와 같은 고가용성 아키텍처 구성으로 무중단 서비스에 대한 필요성을 느끼게 되었고, 이러한 배포와 관리 그리고 인프라에 관한 지식에 더욱 관심을 가지게 되었다.

 

 

후기

나는 대부분의 프로젝트를 solo로 활동했었다. 팀원에게 의지하기보다는 혼자서 문제를 해결하는 것이 마음이 편했고, 그것이 좀 더 나은 성과를 이끌어 낸다고 믿었다. 하지만 이번 프로젝트를 통해 협업은 서로의 스타일을 맞추는 데에 시간이 필요하지만, 그것은 좀 더 빠르고 멀리뛰기 위한 전초 과정이고, 협업으로 인한 시너지 효과는 혼자 작업하는 것과는 비교할 수 없는 퍼포먼스를 발휘한다는 것을 깨달았다. 비단 퍼포먼스적인 관점뿐만 아니라 서로가 서로를 의지하며 프로젝트를 진행한다는 것은 더 나은 관계를 형성하고 예상치 못한 문제가 발생했을 때 정신적으로 흔들리지 않고 안정감을 유지할 수 있다는 것에 굉장히 큰 만족감을 얻을 수 있었다.

 

우리 팀은 일 중독들로 가득한 팀이었다. 대부분의 팀원들이 2주일 동안 하루에 4시간 이상 수면을 취하지 않았고 프로젝트에 100% 몰입해있었다. 특히 마지막 4일은 극심한 피로도가 쌓여있었음에도 오히려 퍼포먼스가 올라갈 정도로 지속적으로 집중력을 유지할 수 있었다. 이러한 협업 분위기는 지쳐있는 체력과 날카로운 신경을 서로가 서로를 배려하고 캐어하는 것으로부터 시작되었다고 생각한다.

 

앞서 이야기했듯 나는 협업에 익숙하지 않다. 때문에 프로젝트를 진행해온 2주간 온전히 무결하다고 한다면 거짓말일 것이다. 나 역시 순간순간 머릿속 필터를 거치지 않은 자잘한 말실수를 거듭했고, 계속된 수면 부족으로 곤두선 신경에 다른 사람을 배려하지 못한 모습을 보였을지 모른다. 그렇지만 이러한 나의 부족한 면을 뒷받침해줄 수 있는 팀을 만난 것에 대단히 감사하고, 이 팀의 구성원 중 한 명으로써 프로젝트에 사소한 긍정적인 영향을 끼칠 수 있었다는 것에 만족감 또한 느끼고 있다.

 

크리스마스에 누군가의 오글거리는 건배사로 인해 우리의 팀의 대표 슬로건이 된 말이 있는데, 그 문장을 마지막으로 이만 글을 줄이도록 하겠다ㅎㅎ.

 

.

.

 

 Fluff Forever!