[네이버 부스트캠프] 네이버 부스트캠프 웹・모바일 8기 그룹 프로젝트 2주차 회고

2주차가 끝났다.

 

그룹 프로젝트의 1/3을 진행했다.

 

우리 팀은 빠른 개발 속도를 앞세워 다양한 기능을 구현하고 있다.

 

WebRTC와 관련된 부분은 어느정도 안정되었고 이제 남은 기능은 공동편집, 채팅 기능이 있다.

 

우선 기능을 만들고 개선하는 작업이 필요할 것 같다.

 

잘한 점

UX적인 측면을 개선해볼 수 있는 도전을 했다.

 

팀원과 얘기하는 과정에서 코드 에디터에 하이라이팅이 들어가면 UX적으로 더 좋을 것 같다는 생각을 갖게 되었다.

 

하지만, 내가 만들었던 textarea에는 부분적으로 색을 입히는 등의 커스텀을 할 수 없었다.

 

또한, python을 기본으로 지원하는 에디터를 만들었지만 python의 키워드들을 파싱해서 색을 입히는 작업에 들어가는 시간도 만만치 않을 것 같았다.

 

따라서, 세부적인 내용을 건너뛰고자 highlight.js를 사용하기로 했다.

 

highlight.js는 테마를 입히거나 언어를 지정하는 등 다양한 커스텀 기능을 제공했다.

 

highlight의 경우 키워드 또는 특정 자료형에 해당하는 경우 span 태그로 감싸고 클래스를 부여하는 방식으로 하이라이팅을 수행한다.

 

이렇게 되는 경우 생기는 문제점은 사용자가 입력하는 부분과 보여지는 부분에 물리적인 차이가 있으며 사용자는 자신이 입력하는 곳과 출력되는 부분에 이질감을 느낄 수 밖에 없다.

 

이를 해결하기 위해 textarea와 하이라이팅 된 코드의 출력 부분의 크기를 같게 한 뒤 두 태그를 겹치도록 구성했다.

 

두 태그를 겹치게 하되 textarea의 z-index를 더 높게 줘 사용자가 클릭하는 부분과 입력하는 부분이 textarea가 되도록 구성했다.

 

마지막으로 두 태그의 자간과 행간을 동일하게 설정하고 textarea의 배경색과 글자색을 투명하게 만들었다.

 

최종적으로 사용자는 textarea에 입력하고 있지만 하이라이팅 된 코드 (pre 태그 안에 있는)를 작성하고 있는 것 처럼 보이게 되었다.

 

이를 통해 textarea를 사용하면서 코드 하이라이팅 기능을 제공할 수 있게 되었다.

 

물론 두 태그가 겹쳐지면서 스크롤바가 따로 노는 등의 기술적 문제도 있었다.

 

이는 스크롤바의 위치에 대한 ref를 설정하고 두 ref의 비율을 맞추는 것으로 해결할 수 있었다.

 

기존 에디터에서는 사용자는 자신이 어떤 언어를 작성하고 있는지 시각적으로 확인할 수 없었다.

 

물론 상단에 조그맣게 Solution.py라는 것을 통해 파이썬임을 알 수 있지만 작게 작성되어 있어 쉽게 알아차리기 어려웠다.

 

비록 모듈을 사용하긴 했지만 시각적으로 키워드, 변수 등에 대해 시각적으로 제공하는 과정을 통해 조금 더 나은 UX에 다가갈 수 있었던 것 같다.

 

사실 highlight도 구현할 수 있을 것 같다.

 

정규식 등을 이용해서 색을 바꾸는 등의 작업을 한다면 할 수 있을 것 같다.

 

하지만, 모듈을 사용함으로써 단순 반복, 단순 구현 등에 걸리는 시간을 단축할 수 있고 이는 더 깊고 넓은 기술적 도전을 가능하게 해준다 생각한다.

 

단, 그러한 모듈을 사용할 때는 각 모듈이 왜 필요한지 판단하고 기능을 직접 구현함으로써 얻는 것과 모듈을 사용할 때의 장점을 잘 비교하여 적절한 선택을 해야 한다고 생각한다.

 

아쉬운 점

이번 주에 한 분야에 매몰되었다.

 

CRDT라는 공동 편집 기술에 도전했다가 결국 완성하지 못했다.

 

우선 라이브러리를 사용하고 개선하는 작업을 하려 했지만 라이브러리 부터 막히게 되었다.

 

예상 했던 시간은 6시간 이었지만 거의 이틀 정도 소모한 것 같다.

 

실패에 대한 원인은 조금만 더 하면 할 수 있을 것 같다는 미련을 못버린 것이다.

 

라이브러리의 공식 문서와 다양한 데모들을 살펴봤지만 현재 우리의 상황(WebRTC를 이용한 P2P 채널이 구축되어 있으며 데이터 채널을 활용하여 문서를 공유)과 맞는 부분을 찾을 수 없었다.

 

이에 따라 기본적인 사용방법을 확인하고 이를 다양한 방법으로 적용해보게 되었지만 실패하게 되었다.

 

저번 주를 돌아보며 6시간이라 최초 정해두었다면 예상 시간의 150%를 초과하지 않도록 해야 겠다는 아쉬움이 남는다.

 

위의 경우 6시간이라 예상 했으니 6시간 안에 완료했어야 했고 길어도 9시간 안에 성공이던 포기던 해야 했다고 생각한다.

 

더 많은 시간을 투자한다고 반드시 성공할 것이랑 보장도 없는 가운데 너무 많은 시간을 소모한 것 같아 아쉬움이 남는다.

 

앞으로 스스로 가능하다고 판단한 시간의 150%를 초과하지 않는 선에서 마무리 할 수 있도록 노력해야 겠다.

 

또한, 이번 주도 마찬가지로 문서화가 미흡했다.

 

이 또한, 다음 주 부터는 하루의 마무리를 문서화와 함께 할 수 있도록 해야 겠다는 생각이 든다.

 

기술적 도전에 따른 생각의 흐름, 시도, 결과 등을 기록함으로써 어떤 과정을 통해 문제를 해결했는지, 결국 실패했더라도 어떤 생각을 갖고 어떤 시도를 했는지 기억할 수 있어야 한다고 생각한다.

 

앞으로

다음 주는 CRDT를 내려두고 남은 기능들 중 우선순위가 높은 기능부터 구현할 것이다.

 

우선 나머지 기능부터 빠르게 끝내야 남은 시간동안 CRDT를 직접 구현하던 라이브러리를 사용하던 할 수 있을 것 같다.

 

또한, 다양한 문제점에 대해 어떤 고민과 시도를 했는지 문서화를 해야겠다.

 

이를 통해 나중에 깃허브나 노션만 보더라도 어떤 고민을 했는지 알 수 있도록 하고 싶다.