항해99 실전 프로젝트 기획 검토

실전 프로젝트를 진행함에 있어서 팀 내부적으로 혼란스러웠던 부분을 짚고 넘어가기로 하였다. 따라서, 우리가 이 프로젝트를 통해 무엇을 얻을 것이며, 어떤 기술을 중점적으로 연마해 나갈 것인지 등의 내용을 정리해보려고 한다.

1. 프로젝트 주제

팀에서 정한 프로젝트의 주제는 전문 분야의 다양한 사람들과 식사를 하면서 편안하게 고민을 상담하거나, 지식을 얻을 수 있도록 도와주는 서비스이다. 이 주제를 평가하는 기준으로는 크게 기획, 기술로 구분된다. 먼저, 아이디어 자체는 굉장히 마음에 들었다. 그 이유는 직장생활을 하면서 처음 프로그래밍을 접하게 되었을 때, 이러한 서비스가 있었으면 좋겠다고 생각한 적이 있기 때문이다. 이어서, 기술면적으로 보자면 또 다시 두 가지로 나눌 수 있을 것 같다. 첫 번째로는 스파르타 측에서 설명한 기술적 챌린지 기준이다.

• socket.io를 사용한 실시간 채팅 기능 구현 : 80%
• 실제로 사용할만한 서비스 : 60%
• 참신한 주제 : 80%
• 호기심 유발 가능성 : 50%

다음은 안정적인 프로덕트 관점에서 바라본 기술적 챌린지 기준이다.

• 서버 안정성 : 80%
• 비교적 복잡한 DB 테이블 관계 형성 : 80%
• 쿼리문 튜닝 : 70%
• AWS 아키텍처 구조 : 100%
• 코드 리팩토링 : 100%

즉, 나는 이 프로젝트의 백엔드 개발자로서 서버 안정성, DB 테이블 관계 형성, 쿼리문 튜닝, AWS 아키텍처 구조, 코드 리팩토링 등 여러 구성요소를 기술적 챌린지로 활용할 수 있을 것으로 생각하였다. 뿐만 아니라, 개인 프로젝트의 규모라고 한들, 혼자서 마음대로 프로젝트를 진행하는 것과 팀원들과 함께 진행하는 것 자체가 기술적 챌린지 요소로 추가해도 된다고 생각한다. 따라서, 이 주제로 프로젝트를 진행한다면 내가 실제로 사용해본 경험이 없는 기술을 사용할 수 있을 것으로 보였고, 추가적으로 캐싱 등의 또 다른 기술까지 접목시킬 수 있다고 생각하였다.

2. 주요 기능 선정

2.1. 매칭

이 프로젝트의 주된 기능은 바로 매칭이다. 매칭의 방식으로는 크게 자의적, 타의적으로 구분할 수 있다. 즉, 참여자가 직접 해당 그룹에 참여하거나, 랜덤으로 그룹이 형성되어 매칭되는 방식을 말한다. 이 중에서 우리는 자의적 매칭 방식을 적용하기로 하였다. 그 이유는 해당 서비스에 참여하는 참여자의 현재 위치에 따라 실제 만남이 성사되어야 의미가 있기 때문인데, 랜덤 방식으로 진행하게 된다면 실제 만남이 성사되기 매우 어려울 수 있기 때문이다. 물론, 현재 접속자의 위치에 따라 인접한 사람들을 랜덤으로 매칭시켜줘도 되나, 메뉴라는 또 다른 변수가 있기 때문에 이마저도 어려울 것으로 보였다. 조금 더 자세히 말하자면, 특정 메뉴에 알러지 반응이 있는 사람들인 경우 실제로 어떠한 그룹에 참여했을 때 음식을 먹지 못하는 상황이 발생할 수도 있다. 뿐만 아니라, 랜덤으로 매칭하게 된다면 서비스 자체 본질이 흐려질 수 있다고 생각하였다. 즉, 랜덤으로 아무나 매칭시켜주고, 현재 그룹원의 정보를 공개하는 순간 불순한 이유로 인해 해당 그룹이 폭파될 수 있기 때문이다. 따라서, 자신이 직접 만나서 조언을 듣거나, 고민 상담이 필요한 분야의 사람을 직접 찾아 나서거나, 해당 사람들이 생성한 그룹에 직접 참여함으로써 참여자 스스로의 선택에 대한 책임감을 갖고 모임에 참여하도록 하였다.

2.2. 실시간 채팅

해당 그룹에 참여한 이후에는 그룹 채팅방을 통해 간단한 인사와 서로의 연락처를 주고 받는 공간을 마련하고자 한다. 실시간 채팅 기능을 구현하는 것은 크게 어렵지 않다. 다만 , 실시간 채팅 기능을 구현하면 과연 사람들이 많이 이용할 것인가? 해당 기능이 우리 서비스에 필요한 기능인가?에 대해서는 다시 한 번 검토해 볼 필요가 있다고 생각한다. 뒤에서 언급하겠지만, 우리 프로젝트의 주된 서비스는 주로 Kakao API에 의존하고 있다. 그렇다면 실시간 채팅을 구현하면서 또 다른 EC2 인스턴스와 자원을 낭비하는 것보다는 카카오톡 알림 기능 API를 사용하는 편이 더 낫지 않을까?라는 생각이 들곤 한다. 물론, 직접 구현한 이후에 사용자들이 실시간 채팅을 많이 이용해주면 서버의 부하를 늘릴 수 있다는 장점이자 단점이 있다. 나는 서버 개발자로써 서버의 부하가 증가하면 포트폴리오에 기록할 내용이 많아져서 장점이 될 수 있으나, 만약 구현해 놓았는데도 불구하고 이용자가 많지 않다면 결국 인력과 시간만 낭비하는 셈이 된다(만약 내가 서비스 이용자라면, 그룹원들의 연락처를 얻기 위해 1~2마디 정도 대화한 후 다른 매체를 통해 소통할 것 같다). 따라서, 실시간 채팅 기능을 사용하도록 유도하는 별도의 시스템(장치 또는 체제)을 마련하거나, 카카오톡 알림 API를 사용하여 시간 낭비를 절약하는 것이 최선이라고 생각된다.

2.3. Kakao API

2.3.1. Kakao Login API

처음 설계할 당시에만 하더라도 서비스 자체 회원가입/로그인 방식을 구현하기로 결정하였다. 그러나, 프로젝트의 MVP가 실제 모임이기 때문에 적어도 사용자들의 신원 정보가 확인되어야 한다고 생각하였다. 이를 위해 국내에서 가장 많이 사용하는 메신저 애플리케이션인 카카오톡을 기반으로 기본적인 신원인증을 구현하는 것이 적합하다고 생각하였다. 물론, 문자메시지, 이메일, 신분증 OCR을 통한 인증 또한 가능하겠지만 이를 사용하면 추가적인 비용 발생, OCR 사용 시 서비스의 주된 기능 개발 시간 감소 등의 문제점이 있다고 생각하여 카카오 API에 의존하는 편이 더 낫다고 판단하였다.

2.3.2. Kakao Map API

모임의 장소를 나타내는 데에 가장 효율적인 수단을 뽑자면, 그것은 단연코 지도일 것이다. 따라서, 프로젝트에서도 사용자로 하여금 지도를 통해 직관적으로 해당 장소를 파악할 수 있도록 하였다. 이때, 지도는 카카오 Map API를 사용하여 구현하기로 하였는데, 그 이유는 매우 단순하다. 먼저, 환경변수를 줄이기 위해서이다. Kakao Map API나 Naver Map API를 사용하기 위해서는 해당 API를 사용하기 위한 Secret Key를 별도로 보관하여야 한다. 그런데, 로그인은 Kakao API를 사용하고, Map만 Naver API로 사용한다면 관리해야 하는 API Secret Key만 늘어나게 된다. 따라서, Kakao API만을 사용하여 Secret Key의 통일성을 확보하고자 하였다. 이렇게만 보면, 프로젝트의 서비스는 대부분 카카오에 의존하는게 아닌가?라는 의문이 생길 수 있는데, 이에 대한 나의 대답은 의존하는 거 맞다라고 할 수 있다. 배달의 민족 CEO 김범준 대표는 이와 같은 말은 한 적이 있다.

• 프로그래머가 1만줄의 코드를 작성했다고 해서 반드시 좋은 프로그래머라고는 할 수 없다.
• 당신의 코드로 만들어진 비즈니스 가치가 중요한 것이지, 코딩 자체로 인정받는 것은 아니다.
• 때로는 어떠한 문제를 해결하는 가장 좋은 방법이 정책을 바꾸고 프로그래밍을 하지 않는 것일 수도 있다.
• 따라서, 개발자는 코딩도 물론 중요하지만, 더 중요한 것은 문제해결력인 것 같다.

즉, 이 프로젝트를 통해 제공하고자 하는 주된 서비스는 신원 인증이나 지도를 보여주는 것이 아니며, 프로젝트 기간이 약 2주 정도로 짧기 때문에 주된 서비스 기능을 구현하는데 더욱 집중하는 편이 낫다고 생각하였다(물론, JWT 인증 방식이 어떠한 로직으로 동작하는지와 같은 기본적인 개념을 알고 있어야 한다). 또한, 나는 서버 개발자로서 로그인/로그아웃 기능을 구현하는 것보다는 서비스를 운영하면서 발생하는 서버 이슈, 운영 이슈 등을 처리하는 것이 더욱 높은 수준의 학습이 될 수 있다고 생각하였다.

3. 예상되는 문제

이 서비스를 개발하는 과정 또는 실제로 시범 운영하면서 예상되는 문제점에 대해서 기획 관점으로 기록해보았다.

3.1. 신고 & 블랙리스트 vs 모임 인증 & 리뷰

이와 같은 플랫폼 서비스를 이용하다보면 누구나 한 번쯤은 신고 게시판을 보았을 것이다. 이는 사람의 문제를 기계가 해결할 수 없기 때문에 별도로 관리자를 두어 해당 계정을 블랙리스트에 추가하는 등의 조치가 필요하기 때문이다. 마찬가지로 프로젝트를 개발한 후에는 이를 관리하기 위한 별도의 신고, 블랙리스트 관리 시스템이 도입되어야 할 것으로 예상된다. 그러나, 현재까지는 서비스를 장기간 운영할 목적이 아직까지 없으므로 해당 기능의 구현 여부를 결정하는데 있어서 문제가 예상된다. 예를 들어, 해당 기능을 구현하기 위한 별도의 테이블을 구성하기 위해 테이블 간 관계를 맺어주는 과정에서의 이슈, 잘못된 신고로 인한 억울한 유저의 블랙리스트 해제 등 다양한 인적 예외 처리 사항이 발생할 수 있을 것으로 예상된다. 따라서, 이 문제를 고민하기보다는 차라리 모임 인증 & 리뷰 게시판을 구현하여, 건전한 모임을 형성하는데 도모하고 해당 기능을 통해 작은 이벤트를 운영하여 트래픽을 유도하는 방향이 더욱 바람직할 것 같다는 생각이 든다.

3.2. 테스트 및 서버 안정성 확보

갑작스럽게 트래픽이 증가한다면 서버의 안정성은 어떻게 확보할 것인가? 이론적으로는 설명할 수 있으나, 이와 관련된 문제를 실제로는 접해본 경험이 없기 때문에 명확한 해결 방법이 떠오르지 않는다. 따라서, 실제 서비스를 배포하기 전에 테스트를 진행하고자 한다. 테스트 방법에는 크게 단위 테스트, 통합 테스트, 성능 테스트로 구분되는데, 트래픽에 관련해서는 성능 테스트가 적합하다. 그러나, 예기치 않은 연산 처리(우리는 이를 버그라고 칭한다)까지 테스트하면, 내가 작성한 코드에 대한 신뢰성을 확보할 수 있으므로 이번 프로젝트에서는 반드시 테스트 코드를 작성해보려고 한다. 아직까지는 제대로 된 테스트 코드를 작성해본 경험이 없기 때문에, 이 과정 자체가 내게는 기술적 도전이 아닐까라는 생각이 든다. 또한, 실제로 서비스를 운영하고, 이벤트와 같은 요소로 가급적 많은 사용자들이 참여할 수 있도록 트래픽을 유도하면서, 그로인해 발생되는 서버 이슈에 관해서도 직접 해결하고, 이를 기록으로 남겨놓고자 한다.

3.3. 그 밖의 사항들에 대하여

위에서 언급한 내용 이외에도 여러 문제와 마주칠 것이라고 예상하고 있다. 가령, 현재 접속자 위치에 따른 그룹 목록 조회 API, 무한 스크롤을 구현할 때 현재 접속자 위치에 따른 제한된 수량의 데이터를 조회하는 API 등을 구현할 때 해당 문제를 어떻게 해결할 것인지 고민해보아야 할 것으로 보인다. 뿐만 아니라, 해당 문제들을 해결한 이후에는 어떻게 더 효율적으로 동작시킬 수 있는지에 대해 많은 고민이 필요할 것으로 예상된다.

4. 마치며

기록하고 싶은 내용이 차고 넘치지만, 9시에 회의가 있기 때문에 일단은 여기서 마치겠다. 마지막으로 다음 글을 나의 중심으로 삼고 프로젝트를 진행하려고 한다.

“우리가 지금 겪고 있는 모든 현상들은, 되돌아보면 부족하게 느낄지는 몰라도 그게 어제의 최선이었다.”

즉, 기획단계부터 모든 문제를 예측하고, 완벽하게 수행하는 것은 신의 영역이지 나약한 인간의 영역은 아니라고 생각한다. 다만, 나는 이것밖에 안 돼라는 마음가짐보다는 어제보다 더 나은 최선의 상황을 만들기 위해 끊임없이 공부하고 도전해보는 자세로 프로젝트에 임하려고 한다.