(8주차 ~ 11주차)

실전 프로젝트는 실전이다

실전 프로젝트를 진행하며 느낀 점은 그동안의 프로젝트는 프로젝트라는 이름을 달아줄 수준도 아니었구나 하는 것이었다. 물론 지금 우리의 결과물도 실제 현업에서 다루게 될 프로젝트들의 규모에 비하면 장난같은 수준이겠지만 :)

8주) 팀빌딩에서 MVP 개발까지

주제 그리고 회의, 회의, 회의

클론 코딩이 성공적으로 마무리되고 곧 바로 팀 빌딩이 이루어졌다. 그 과정에서 우여곡절이 있었지만, 무사히 팀 빌딩이 이루어졌고 우리 팀의 주제는 음식 배달을 공유하는 커뮤니티 사이트로 정해졌다. 주제 선정이 끝나도 아이디어를 빌드업하는 과정이 순탄하지 않았다.

처음 만난 난제 - 스페이스를 나눠야 할까?

첫 생각은 슬랙이나 게더처럼 회사, 공유오피스 사람만 사용할 수 있도록 스페이스를 나누어주고 인증키를 주는 것이었는데 그 방법에 관한 접근법이나 기술적으로 알맞은 해결법을 찾기가 어려웠다. 이 문제를 어떻게 비지니스적으로도 사용성 측면에서도 어색하지 않고 자연스럽게 풀어갈 수 있을지 회의를 정말 많이했던 기억이 난다. 그래서 다음과 같이 차근차근 우리의 현 상황과 목적을 분명하게 하는 방법을 취해서 곁가지를 쳐내기로 했다.

• 스페이스를 나누려는 목적 :
  낯선 사람과 배달비를 나누거나 배달 받은 음식을 나눠가지기 위해 이루어지는 상황과 행동들 중 위험한 요소들이 존재 할 수 있다. 따라서 어느정도의 안전성을 보장 할 수 있는 범위로 사용자 범위를 좁히는 것이 필요하다. 그 범위로 회사, 공유 오피스인 이유는 신원 파악이 가능하고 관리 되는 명단이라고 판단 할 수 있기 때문이다.

• 스페이스를 나눌때의 문제점 :
  타겟이 되는 사용자의 풀이 좁아지고 기술적으로 매끄럽게 해결 되지 않는 한계가 존재한다. 가령 특정 링크로 초대받은 사용자가 다시 인증키를 복사해와서 다시 입력하고 다시 로그인하고 (다시.. 다시.. 다시... 후...) 우리가 생각해 낼 수 있는 스페이스를 나누는 방법이 서버단에서도 프론트단에서도 그리 만족스럽지 못했다.

  1. 링크를 받고 초대 받은 사람을 어디로 보내야하는가?
  2. 어떤 정보를 요구해야 스페이스를 나눌 수 있는가?
  3. 초대받지 않고 우연히 방문한 사용자는 어디로 보내야하는가?
  4. 스페이스를 최초로 만들 사람은 어떻게 관리해야하는가?
  5. 이 과정들이 사용자 유입에 장애가 되지는 않는가?
  6. 이런 과정이 있어야만 위험을 줄일 수 있는 것인가?

• 스페이스를 나누는 방법 외 해결 방법 :
  스페이스를 나누는 목적에도 부합하면서 스페이스를 나눌때의 문제점을 자연스럽게 해결해줄 방안을 모색하던 중 위치기반으로 사용자 및 모집글을 모으고 트롤 유저에 관한 방책으로 채팅방 방장에게 강퇴 권한을 부여하는 구성을 생각하게 되었다.

• 새 방안의 장점:

  1. 특정 회사, 공유 오피스로 특정 되지 않기때문에 사용자의 범위가 넓어진다.
  2. 복잡한 절차가 사라지면서 서비스 진입장벽을 낮출 수 있다.
  3. 모임을 진행할 구성원을 방장이 관리할 수 있기 때문에 트롤 유저에 관한 관리를 할 수 있다.
  4. 위치 기반으로 모임을 구성하기 때문에 스페이스를 구분하지 않아도 그와 유사한 효과를 기대할 수 있다.

두번째 난제 - 결제와 관련 트롤 유저 관리를 어떻게 하지?

• 결제 시스템의 부재가 낳는 문제점 :
  낯선 사람과 우리 서비스를 이용하게 된다는 가정 아래, 가장 큰 문제는 먹튀였다. 방장이 일방적으로 결제 후 그 사람이 나타나지 않거나 비용을 함께 부담하지 않는다면 결제 기능이 없는 우리 서비스에는 너무도 치명적인 결점이 될 것이라 판단 했다.
• 해결 과정 : 이 문제를 해결할 방안은 두가지 정도로 생각 되었다. 더치페이 기능을 넣거나, 이용자들이 배달 및 결제 전에 직접 만나서 결제와 관련된 행동을 하도록 하는 것이었다. 당근 마켓을 생각해보면 불가능한 일은 아닐 것이라는 생각이 들었고, 공유 오피스와 같은 환경에서는 충분히 가능하지 않을까 라는 쪽으로 의견이 모여 대학가와 공유오피스를 주요 타겟으로 설정 한 뒤 개인 프로필에 성별, 연령 및 상대방을 알 수있는 정보를 최대한 제공하는 것으로 결론을 내고 회의를 마무리 지을 수 있었다.

9주) sockJS를 활용한 채팅기능 개발

8주차 오랜 시간 회의 끝에 앞으로 가야하는 방향에 관한 설정이 끝난 이후 소셜 로그인과 기본 CRUD를 완성 후 배포하는 일에 정신 없이 시간을 보냈다. 클론 코딩때만 해도 기본 리액트와 리덕스를 사용하여 CRUD를 완성하는 것이 어렵기도 하고 시간이 참 오래걸렸었는데, 어느 순간 필요한 액션을 구상하거나 서버에 필요한 정보를 요청하기도 하고 프론트에서 대신 작업해 줄 수 있는 영역도 구분 짓는 등 항해를 처음 시작하던 때와는 사뭇 달라진 나의 모습이 보였다. 그렇게 한 주를 보내고 2주차에 접어들어 채팅이라는 큰 산을 만나게 되었다.

웹 소켓이 뭐지?

지금까지 서버와 클라이언트의 통신은 단방향이었다. 프론트가 일방적으로 요청을 보내면 서버로부터 응답을 받는 구조였다. 이제 겨우 그 관계에 익숙해진 상태였고, 사실 그것만이 내 세상.. 이었다. 그러던 중 우리 서비스의 핵심 기능이라고 할 수 있을 채팅 파트를 맡게 되니 처음에는 긴장이 되기도 했었다. 그래도 새로운 기능이자 중요한 기능을 내가 구현해볼 기회가 생겼다는 것이 굉장히 기뻤고 뿌듯했다. 곧 바로 서버분들과 회의를 진행했고 다행히 그 동안 알지 못했던 개념들을 잘 설명해 주셔서 금방 공부해야할 방향을 잡을 수 있었다.

• 프로토콜
  정보를 주고 받는 양식과 규칙의 체계를 의미한다. 즉 데이터의 교환 방식을 정의하는 규칙 체계이다.
• TCP
  전송계층에 속하는 중요 연결 지향 프로토콜이다. 3way handshaking으로 클라이언트와 서버가 연결된 상태에서 양방향으로 테이터를 주고받는 형식이다. 신속성이 높은 UDP와 달리 정확성을 추구하며 1:1 통신만 가능하다.
• WebSocket
  TCP 소켓과 달리 HTTP 레이어에서 작동하는 소켓으로, 웹을 통해 클라이언트와 서버 간의 양방향 통신을 위한 프로토콜이다. 웹 소켓 연결을 위해 클라이언트와 서버간 특정 HTTP 기반 헨드쉐이크가 교환되고 연결 성공 이후 TCP 연결을 사용하여 양방향 데이터 교환이 가능해진다.

sockJS, socket.io, stomp ?

기본 용어 공부 이후 그래서 어떻게 리액트에 적용해서 사용하는 건데? 그래서 어떻게 코드를 짜야 동작을 하는 건데? 라는 문제에 부딪혔다. 일단 sockJS, socket.io 가 뭔지 stomp는 또 뭔지 코드는 어떻게 동작을 하는 건지 공부하는 데에 시간을 많이 쏟았던 것 같다.

• sockJS VS socket.io
  일단 sockJS와 socket.io 모두 WebSocket emulation( 하나의 시스템이 다른 시스템을 흉내 내도록 하는 것 )으로 웹소켓이 미지원되는 브라우저에 대응하여 웹소켓 이전 http에서 양방향 통신을 흉내내던 http 기반 방식으로 기술을 전환하여 연결 지원해주는 서비스이다. 여기서 sockJS는 spring기반이며, socket.io는 node.js 기반이라는 차이가 존재한다. 따라서 이번 프로젝트에서는 sockJS를 사용하였다.
• stomp
  stomp는 간단한 문자 기반 메세지 프로토콜이다. 텍스트 송 수신을 위한 규칙으로 여러 플랫폼간 메세지 상호 운영이 가능하다. stomp가 다른 메세지 전송 프로토콜과 차별화 되는 점은 binary(2진법) 기반이 아닌 텍스트 지향 프로토콜로 개발에 용이하다. 즉, stomp는 tcp, websocket과 같은 양방향 프로토콜 상에서 동작하는 프로토콜로 클라이언트와 서버가 전송할 메세지의 유형, 형식, 내용 등을 결정하게 한다.

그래서 어떻게 채팅을 구현할 수 있을까?

세 번째 난제 - 어디에 코드를 작성해야 연결이 되는거야?

개념도 이해를 했다고 생각했고 구글링과 git hub 코드 참고로 어느정도 스톰프 메서드를 사용하는 법에 관한 느낌은 잡았다고 생각을 했다. 다른 프로젝트와 비교하며 우리 프로젝트에 적용할 방안도 고민해보았는데 될 거라고 생각하고 작성했던 코드에서 문제가 많이 발생했다.

• 문제 현상 : 채팅방에 들어가면 websocket is opening 이라는 내용만 찍히면서 실제 커넥과 섭이 이루어지지 않았다. 오히려 채팅방을 나가거나 주소이동이 되는 순간 서버로 커넥, 섭, 디스커넥이 산발적으로 발생하는 것을 확인할 수 있었다.

• 문제 원인 : 그 이유를 찾기 위해 구글링을 하던 중 한 줄기 빛과 같은 문장을 보게 되었다. 소켓 연결을 선언하는 위치는 해당 컴포넌트와 동등한 위치에서 선언되어야한다는 것이었다. 이전까지 스톰프 함수들을 여러 컴포넌트에서 사용할 수 있을 것이라는 생각으로 모듈을 만들어 임포트하는 형식으로 코드를 작성했었는데 그것이 아주 큰 실수였다.

• 해결 과정 : 초기 우리 서비스에서 채팅방으로 입장이 가능한 경우는 메인 포스트 채팅버튼과 개인 채팅 리스트 탭이었다. 그래서 초반 소켓을 선언하는 위치에 관련한 이슈에서도 혼란이 있었다고 생각한다. 그래서 소켓 연결 위치에 관련된 이슈를 접한 뒤 실제 채팅이 일어나는 컴포넌트에 해당 코드를 작성하였고 room id 가 없는 경우의 예외처리를 추가하였다. 또한 초반 채팅으로 접근할 수 있는 경로가 메인과 채팅 리스트 탭이었는데, 이것을 채팅 리스트 탭으로 통합하여 관리하고, 메인에서는 방장에게 채팅 신청을 넣는 기능으로만 제한하여 로직을 정리하였다.

연결 그 이후

소켓 연결 이후에도 엄청나게 많은 디버깅과 기능 추가와 코드 수정이 있었다. 단순히 연결만 시켰다고 끝나는 것이 아니라 내가 보낸 채팅과 다른 사람이 작성한 채팅을 구분해서 뷰를 만들어야 했다. 사이드바에서는 채팅에 참여 중인 유저를 관리하였고, 계속해서 생겨나는 채팅과 관련 된 기능들을 구현하느라 새벽 4시, 5시가 기본 취침시간이 되었다...

2주간 얻은 것

• 의사소통
  많은 회의를 거치며 자유롭게 의견을 말하는 문화가 얼마나 중요한지 느꼈다. 에자일 방법론을 적용해보려는 팀 분위기도 좋았다. 또한 의견을 낼 기회가 많이 주어지니 스스로도 더욱 타당한 주장과 뒷받침 의견을 제시하여 발전적인 결론을 도출하려는 시도를 하게 되었다. 덕분에 논리적으로 사고하는 연습을 많이 할 수 있었다. 같은 말도 듣기 좋게, 분명하게, 상대를 배려하는 자세로, 무언가 요구하기전 내가 해야하는 부분은 책임지고 마무리한 뒤, 협업이 가능한 상태를 만드는 것이 참 중요했다.

• 기본 CRUD
  실전 프로젝트 전 과정들을 통해 기본적인 CRUD와 api 요청은 어느정도 익숙해진 상태긴 했지만, 이번 프로젝트를 진행하면서 리덕스와 그 데이터들에 관한 관계를 확실히 몸에 새기게 되었다.

• 컴포넌트 간 데이터 이동 및 관리
  항상 상위 컴포넌트에서 하위로 데이터를 이동시키곤 했는데, 컴포넌트의 구조가 복잡해질 수록 간혹 하위의 데이터를 상위로 가져와야하는 경우가 생겼었다. 이런 데이터들을 처리하는 법을 조금이라도 다뤄볼 수 있었고 필요한 데이터들을 만들어 내거나 관리하는 법을 익혀가는 것 같다.

• 낯선 기능을 구현해보는 힘
  채팅을 처음 구현해보는 것도 매우 큰 경험이었지만, 그 외 라이브러리를 사용해보는 것도 나에게는 새로운 경험이었다. 온통 영어로 되어있는 라이브러리를 설치한 뒤 문서를 읽어보며 사용법을 익히고 라이브러리 코드를 뜯어보며 커스텀을 하거나 구글링을 하며 문제를 해결해 나가는 경험들이 의미있었다. 비록 그것이 best practice는 아니었을지라도 새로운 기술, 기능을 적용해 보는 재미가 쏠쏠했다.