[구름톤 트레이닝 풀스택 1기] 20주차 회고 - 실시간 동시 편집이 가능한 Web IDE 구현 완료, 발표 역량 향상

실시간 동시 편집이 가능한 Web IDE

2023년 9월 6일 ~ 2023년 10월 11일, 약 4주 간의 프로젝트가 끝났고 발표까지 마무리 됐다.

코드 편집 페이지 부분을 전반적으로 담당했는데
실시간 동시 편집이 가능하도록 CRDT 기술이 있는 Yorkie 라이브러리를 적용하느라 꽤 애먹었고
호환성을 위해서 이전에 코드 에디터 라이브러리인 Monaco 에서
CodeMirror 로 바꿨는데 이 두 라이브러리의 러닝 커브가 상당했다.

우리 팀은 단순히 주어진 과제를 수행하는 것이 아니라
실제 웹 서비스를 개발한다는 하에 보다 매리트있고 차별성 있는 Web IDE 를 만들고자 했다.

그래서 CRDT 기술을 적용해서 실시간 동시 편집이 가능한 Web IDE 를 만들기로 했다.

비슷한 제품으로 구름 IDE가 있는데
구름 IDE 에는 음성 채팅 기능이 없어서
Zoom, 디스코드 등 다른 플랫폼을 추가적으로 사용해야한다는 불편함이 있다.

이러한 불편함을 해소하고자 음성 채팅 기술을 추가했다.

프로젝트 구조

프로젝트 구조는 저번 기획 발표 때 언급했던 구조에서
음성 채팅을 구현하기 위해서 connectlive-web-sdk 가 추가되었다.

프론트엔드는 S3, 백엔드는 EC2를 사용해서 배포를 진행했으며
github actions CI/CD를 구축했다.

프로젝트 팀 구성 및 역할

우리 팀은 총 7명의 구성으로 프론트엔드 4명, 백엔드 3명이다.

담당 항목은 관여한 페이지 항목이 들어가 있고
담당 별 세부 업무 항목에는 같은 페이지별로 개발한 기능이 들어있다

빨간색 부분이 내 역할과 담당, 그리고 세부 업무이다.

수행 절차

API 문서

기능 개발을 위해서,
프론트엔드, 백엔드 협업을 통해 미리 사전에 정의했던 API 문서이다.

Method, Path, 간단한 설명, 담당자를 지정해서 작성했다.

get 요청인 컨테이너 정보 가져오기 이다.
Request Path에 key 값과 간단한 설명을 작성했고
Response로 더미 데이터를 만들어서 작성하여 프론트엔드와 백엔드 간의 협업을 진행했다.

개발 프로세스

위 API 문서를 기반으로 기능 개발을 진행했는데 하나의 기능을 개발하기 위한 팀 프로세스이다.

1. JIRA 에 어떠한 기능을 개발할지 등록을 한다.
2. 사전 정의한 Branch 전략에 따라 따라 Branch 를 생성한다.
3. 만든 Branch에서 기능 개발을 진행한다.
4. 사전 정의한 컨벤션 전략에 따라 커밋과 푸시를 진행한다.
5. Pull Request
6. 코드 리뷰를 진행하고 본인을 제외한 2명 이상의 리뷰어가 Approve 하도록 한다.
7. default 브랜치인 develop에 Branch Rebase Merge 를 한다.
8. Github Actions 를 통한 자동 배포
9. 버그테스트를 진행 -> 만약 버그가 발견되면 발생조건을 노션에 작성

프로젝트 결과물 만이 아니라 협업을 통해서 나온 문서들도 결과라고 한다.
일부 예시들에 대해서 순차적으로 작성 해보고자 한다.

JIRA

하나의 기능을 개발하기 위해 프론트엔드와 백엔드에서 할 일이 다르기 때문에
제목 작성 시 FE, BE 태그를 달아줬다.

설명에는 이 기능을 개발하기 위해서 할 일을 작성한다.
이후 세부 정보에는 우선순위, 레이블, 스프린트를 지정하고 등록했다.

Github 과 연동을 해둔 상태이기 때문에 발급된 키를 커밋 메세지에 첨부하여 푸시하면
자동적으로 진행 사항이 개발 항목에 표기가 된다.

이런 식으로 작성을 해나가면서 프로젝트 진행 상황을 모든 팀원들이 공유할 수 있도록 했다.

Pull Request

기획 및 개발기간이 약 1달로 많지 않은 시간이기에
PR 작성에 대해서는 별도의 규칙을 만들진 않았다.

단 코드 리뷰에 도움이 될 수 있도록 작업한 목록을 작성하고
프론트엔드의 경우 변경사항을 파악하기 쉽도록 가능하다면 이미지를 첨부했다.

코드 리뷰

백엔드 팀원이 작성해준 PR 이다.
작업한 목록을 작성해주셨고 추가적으로 이후에 할 작업들을 작성해주셨다.

리뷰어 들은 코드를 읽고 잘못된 부분,
혹은 개선해야할 부분이 있는 지확인하고 댓글을 남겼다.

이러한 부분들을 리뷰하는 것 뿐만 아니라 문제상황을 발견했을 때
어떻게 해결해나가야할 지 토론하는 공간으로 사용하기도 했다.

버그 테스트 후 에러 제보

배포된 서비스에서 기능 테스트를 하면서 발견된 버그들을 제보하는 페이지이다.
간단하게 에러 사항을 적고 어디서 발생했는지 그리고 처리 유무,
제보자와 담당자를 기록해놓음으로써 기능의 안정성을 쌓아 나갔다.

Quality Assurance

총 두 번의 QA 를 진행했다.
페이지를 담당해서 개발한 사람이 체크리스트를 작성하고
그 페이지에 관여하지 않은 사람이 테스트를 해주는 방식으로 진행했다.

코드 편집 페이지는 내가 담당했기에 위 체크리스트는
내가 구현한 세부 기능 목록들이다.

두 번의 QA를 진행해서 안정적인 서비스를 구축할 수 있었다.

핵심 기능

회원 가입 - SSE

이메일에 담긴 인증 버튼을 클릭했을 때 회원가입 페이지에서 인증이 완료되는 기능이다.
HTTP 프로토콜로는 불가능 해서 SseEmitter 를 사용했다.

SseEmitter는 사용자의 고유값을 기준으로 통신을 하는,
서버에서 클라이언트로의 단방향 연결성 통신이다.

서버는 해당 클라이언트에게 하나에 요청에 대해,
연결이 끊기기 전까지 지속적으로 응답을 반환할 수 있다.

사용자가 이메일 인증 버튼을 클릭하면 SSE 연결을 위해
이메일 주소와 사용자의 UUID가 백엔드 서버로 전송된다.
이후 서버는 해당 이메일 주소로 인증을 위한 토큰을 포함한 메일을 발송힌다.
동시에 SseEmitter 연결을 통해 해당 사용자와 서버 간의 지속적인 연결을 유지한다.

사용자가 메일로 받은 인증 버튼을 클릭하면 토큰이 서버로 전송된다.
서버는 Filter를 통해 토큰의 유효성을 검증하고,
유효하면 "인증 완료" 메시지를 반환하며 SseEmitter 연결을 종료한다.

로그인 - Refresh Token & Access Token

이메일과 비밀번호를 입력하고 로그인 버튼을 클릭하면 로그인 요청이 서버로 전송된다.
요청을 받은 서버는 해당 정보가 올바른 정보이면 Refresh 토큰과 Access토큰을 발급한다.

Refresh 토큰은 쿠키에, 엑세스 토큰은 헤더에 담아서 응답값을 보내게 된다.
응답값을 받게되면 엑세스 토큰을 로컬스토리지에 저장하고 메인페이지로 이동하게 된다.

메인 페이지 - 모든 컨테이너, 유저 정보 출력

메인페이지로 이동하게 되면 좌측에 띄워줄 사용자 정보와
메인 컴포넌트에 띄워줄 컨테이너 정보들을 서버에 요청하고 응답받는다.
이 과정은 보통의 get 요청과 동일한 방식으로 동작한다.

사용자 정보의 경우 리코일에 저장해서 다른 페이지에서 활용한다.
메인 페이지의 우측 상단에 있는 컨테이너 추가 버튼을 클릭하면
컨테이너 생성 페이지로 이동한다.

컨테이너 생성

컨테이너 이름을 입력할때마다 0.5초 디바운싱으로 존재하는 컨테이너 이름인지 확인하는 요청을 보내다.

중복되지 않은 이름이면 다음과 같이 초록색 텍스트가 나온다.
이후 옵션을 선택하고 컨테이너 생성 버튼을 클릭하면 생성 요청이 날아가게 된다.
요청을 받은 서버는 DB에 컨테이너 정보를 추가하고 S3 에 컨테이너 이름의 루트 폴더를 생성한다.

모든 처리가 끝나면 클라이언트로 응답을 보내게 되고 응답을 받으면 다시 메인 페이지로 이동한다.

❗️ 코드 편집 페이지 - 파일 추가 및 CRDT 바인딩

담당한 페이지 기능 중 일부이다.

먼저 파일트리에서 폴더 우클릭을 하면 폴더 컨텍스트 메뉴가 출력된다.
파일 추가를 클릭해서 파일명을 입력하고 확인 버튼을 누르면 파일 추가 요청이 보내진다.

요청을 받은 서버는 컨테이너 생성 시 때 처럼 마찬가지로
DB 작업을 마치고 컨테이너에 존재하는 해당 폴더 내부에 파일을 만든다.

처리 완료 응답을 받은 클라이언트는 파일 트리를 관리하는 TreeDataRecoilState를 업데이트하고
FileDataRecoilState도 업데이트한다.

이 것은 파일경로를 키 값으로,
Yorkie 데이터베이스에 접근하기 위한 키를 value로 가지는 map 객체이다.
새 탭을 생성했기 때문에 탭 상태를 관리하는 TabDataRecoilState를 업데이트한다.

모든 리코일 상태를 업데이트 한 후 탭이 가지고 있는
파일 경로 변수를 통해 FileDataRecoilState에 있는 엑세스 키에 접근하여
Yorkie와 바인딩 하고 실시간 처리를 시작한다.

채팅 - SockJS, Stomp

사용자가 컨테이너에 접속하면,
해당 컨테이너 내부의 채팅방과 웹소켓 연결을 초기화하는 과정을 시작한다.

이때 핸드셰이크 과정을 거쳐 연결이 성립되며,
그 다음 단계로 사용자는 서버에 자신이 해당 컨테이너를 구독하고자 함을 알린다.

구독 요청 처리가 완료되면, 서버는 새로운 유저의 입장 정보를 저장하고,
이미 구독 중인 다른 유저들에게 입장 메시지를 전달한다.
이 메시지는 채팅방에 있는 모든 사용자들에게 전달된다.

그 후에는 연결된 웹소켓을 통해서 사용자들은 채팅방에서 실시간으로 메시지를 주고 받을 수 있다.

사용자의 개인 정보와 관련된 데이터 요청은 HTTP 프로토콜 기반의 API를 통해 처리된다.
예를 들어, 현재 채팅에 접속 중인 사용자 정보를 조회하려면 해당 API 요청을 보내면 된다.
이때 서버는 컨테이너 구독 시 저장한 데이터를 조회하여 요청한 사용자 정보를 반환해준다.

음성 채팅 - connective-web-sdk

음성 채팅 아이콘을 클릭하면 음성 채팅 서버에 연결되고
음성 채팅 아이콘이 활성화된다.

음성 채팅 도중 다시 음성 채팅 아이콘을 클릭하면 음성 채팅 서버에서 나오게되고
음성 채팅 아이콘이 비활성화된다.

자체 평가 의견

모든 팀원들의 의견을 종합해서 나온 4가지 의견이다.

우리 팀, 나날이 발전해나가고 있는 것 같다.

발표 평가

최고 점수: 92점
최저 점수: 73점
평균 점수: 80점

내 발표 점수: 92점

[구름톤 트레이닝 풀스택 1기] 17주차 회고 - Web IDE 기획과 발표 역량 부족 중 일부.

지난 기획 발표 평가 점수로 평균 점수 대의 점수를 받아서 아쉬웠었다.

기획 평가 발표 피드백 회고를 통해서 느꼈던 점과 보완해야할 점을 고민하고 적용한 결과
최고점을 받을 수 있었다.

결과 발표에 대한 멘토링을 받지 못해서 걱정이 많았는데 다행이다..
아래는 항목별 피드백 및 점수이다.

기획력(차별성, 접근 방식)

음성 채팅 아이디어 좋았습니다.
기본 기능 구현도 부담일 수 있는 계획에,
추가적인 아이디어까지 논의하고 진행한 점 좋았습니다.

점수: 18/20

기술성(기술적 타당성)

리뷰어와의 소통을 통해서, 좀 더 나은 결과물에 대한 토론과
Github, Notion 등을 어떻게 잘 활용해 협업했는가가 드러나는 점 좋았습니다.

점수: 26/30

완성도(완성도, 기여도)

음성 채팅까지 완료하셔서 놀랐습니다.
시연 연상에서 다양한 예외처리도 확인할 수 있는 점도 좋았습니다.

점수: 29/30

발표(장표 구성, 시간 활용, 전달 방식)

시퀀스 다이어그램이 아주 상세해서 좋았습니다
또한 발표도 매끄럽고, 내용 설명도 잘 전달되었습니다.

점수: 19/20

피드백 회고

상세 가 답이었던 것 같다.

지난번 회고에서 얻어낸 것을 반영해서 숲보단 나무에 집중해서 발표 준비를 했다.
그래서 대본이 길어졌고 그 이유로 말을 너무 빨리해서 걱정을 했는데
생각보다 좋은 평가를 받았다.

하지만 여기서 안주하진 않기에
감점 이유에 대해서 분석을 해봤다.

지난번 분석때는 내 점수보다 더 높은 점수를 받은 팀의 피드백을 보고 비교를 했었는데
기술성 부문을 제외하고 나머지 부문에서는 모두 최고점이다.

기술성 부문에서 보완해야한다고 생각이 들었던 것은 Why 였다.
기술 스택에 대한 발표 시 왜 이 기술을 선택했는지에 대한 것을 언급하지 않았던 것 같다.

다음 발표에서 이 부분을 반드시 추가할 예정이다.

글을 마치며

익숙하지 않은 도메인을 개발하느라 새로운 기술들을 찾아 사용하게 되는 계기가 되었던 것 같다.

CRDT의 경우, 직접 구현했었으면 좋았을 것 같은데 기간이 짧아서
알고리즘을 파악하고 분석할 시간이 없어서 아쉬웠던 것 같다.
부트 캠프를 마치고 CRDT 알고리즘에 대해서 공부하려고 한다.

기획 기간을 제외하면 총 개발 기간은 3주 였는데
3주 안에 기획했던 모든 기능들을 개발했다는 점에서 매우 놀랍다..

구름톤 트레이닝 풀스택 부트캠프를 듣기 전의 역량으로는 절대 불가능하지 않았을까 한다.

부트캠프 주최사가 구름이라
구름톤 트레이닝 부트캠프에서 Web IDE 를 만들기 위한 일부 기술들을
커리큘럼 혹은 세미나에서 제공 받을 줄 알았는데 전혀 없어서 아쉬웠지만

직접 찾아서 구현하는 과정을 통해 성장할 수 있었던 것 같다.