어느덧 입사 11개월차

입사 3개월, 6개월차 회고는 저멀리 지나가고 어느새 만 1년을 바라보는 시기가 되었다. 6월부터 새로운 프로젝트를 준비하고 있다. 입사 후 두번째 프로젝트다. 첫번째 프로젝트와 마찬가지로 바닥부터 시작하는 그린필드 프로젝트지만 첫번째 프로젝트와 같은 카테고리의 솔루션이기 때문에 노하우(랄게 있다면..🥲)들을 이식해와야 한다. 
 
그래서 첫 프로젝트에서 해결하지 못한 기술적 과제들을 정리해 보았다. 이 과제들을 해결하지 못한다면 새 프로젝트도 고스란히 부채를 안고 시작해야 하기 때문에 어떻게든 기존보다 더 나은 방향으로 진행해 보고 싶다. 
 
 
1. contentEditable 이슈 
보통 생각하는 에디터 기능까지는 아니지만 서비스에서 사용자가 텍스트 편집과 조회를 하는 게 필수 기능이다. React 프로젝트에서 contentEditable을 사용하는 게 쉽지 않아서 리액트의 상태로 UI를 그리는 일반적인 방식이 아닌 innerHTML을 직접 조작하고 있다. 
 
react-contenteditable 라이브러리를 분석해서 라이브러리에서 지원하지 않는 available props를 추가 구현을 해보려고 한다. react-contenteidtable 라이브러리는 사실상 핵심 동작은 컴포넌트 파일 하나에서 돌아가는 굉장히 간단한 라이브러리다. 작년에도 라이브러리를 조금 뒤적여 봤는데 일단 클래스형 컴포넌트라는 형식이 낯설었고, 간단하다고는 하지만 라이브러리의 동작 원리를 전부 다 이해하기가 어려워서 이 라이브러리로는 우리 요구사항을 충족할 수 없구나 까지만 확인하고 접었다. 
 
이번에 다시 라이브러리 코드를 들여다보니 작년보다 아주 조금은 더 알 것도 같아서 나 좀 늘었나봐? 하는 오만방자한 생각을 잠깐 했다. 후후후.. 아직 들춰만 본 수준이어서 그렇고 막상 코드 가져와서 주물럭주물럭 해보면 금세 생각이 바뀔 것 같긴 하다. 
 
 
2. 사용자의 역할과 권한에 대한 설계 
첫 프로젝트는 만들어가는 도중에 요구사항이 계속 변경되는 상황이었다. 이게 꼭 나쁘다기보다.. 우리 회사 상황상 요구사항이 구체적으로 나올 수 없는 상태였고 만들어가면서 요구사항을 구체화 해나갈 수 밖에 없었다. 그러다보니 사용자의 역할과 권한에 대한 부분이 첫 설계에 부족했고, 추가 기능이 하나 생길 때마다 대응해나가는 식으로 구현해서 지금 코드가 아주 짬뽕 그 자체.. 나는 처음부터 히스토리를 다 아니까 그래도 추가 기능 붙이거나 변경 사항이 생겼을 때 대응해 나가고는 있는데 코드 처음 접하는 사람이 보면 기절할 노릇일 테다. 
 
최근 Role-Based Access Control(역할 기반 접근 제어)라는 키워드를 알게 되었는데 새로 들어가는 프로젝트는 이 키워드를 중심으로 역할과 권한을 설계해 보고 싶다. 그리고 가능하다면 기존 프로젝트도 이를 바탕으로 리팩토링하고 싶다.
 
 
3. 테스트 코드의 부재 
TDD라는 개념은 부트캠프 시절부터 접하긴 했지만 유틸 함수 등을 대상으로 간단한 유닛 테스트를 작성하는 것 말고 프론트엔드의 E2E 테스트는 어떻게 해야하는건지 감이 잘 오지 않았다. 그런데 이게 프로젝트 덩치가 일정 수준 이상을 넘어가기 시작하니까 테스트 코드가 없다는 게 얼마나 위태위태한 코드인지 실감하고 있다. 
 
가령 지금 프로젝트에서 디렉토리 구조를 보다 인체공학적으로 개편하고 싶은데, 이게 나름 대공사다보니 개편 이후에도 기존에 하던 동작을 전부 다 할지 확신할 수가 없다. 나혼자 하고 있는 프로젝트고 지금 새로운 프로젝트 구상 중이라 기존 프로젝트는 얼마든지 리팩토링을 할 수 있는 기간인데도 테스트 코드가 없으니 공사를 시작할 엄두가 안 나는 상황이다. 
 
잠깐 옆길로 새자면 최근 여러가지 고민 중 하나가 일정 산출에 대한 부분이다. 이를 위해서 사용자 시나리오를 구체적으로 작성하고, 해당 시나리오에 대한 기능 구현 예상 소요 시간을 적고 작업에 착수한 다음 실제 소요 시간과 비교하며 어디에서 왜 차이가 나는지를 회고해보려고 하고 있다. 이 방법을 도입하니 자연스럽게 부수 효과로 사용자 시나리오를 바탕으로 테스트 시나리오를 작성하면 되서 편해진 부분이 있다. 테스트 시나리오와 마찬가지로 사용자 시나리오를 테스트 코드로 옮기면 이게 바로 TDD가 아닐까 하는 생각을 하고 있다. 
 
부트캠프 때 구현 과제들이 항상 테스트 코드를 통과했는지 검증하는 방식이었는데 그 테스트 코드들을 다시 들여다보려고 한다. 새 프로젝트는 위의 방법과 합을 맞춰나가며 테스트 코드를 작성한다면 Cypress나 Playwright 같은 E2E 방식은 아니더라도 테스트 코드를 도입해볼 수 있지 않을까 하는 생각을 하고 있다. 
 
 
4. 실행취소/재실행 기능 
위에서 텍스트 편집 기능이 필수 기능이라고 했는데 편집 외에도 다양한 액션(세그먼트 병합/분리, 세그먼트 순서 이동 등)에 따른 실행취소와 재실행 기능도 기존 프로젝트의 요구사항 중 하나였다. 실행취소/재실행 기능 구현을 위한 대표적인 디자인 패턴은 메멘토 패턴과 커맨드 패턴이 있는데, 이를 100% 적용하지 못해 현재 부분적으로만 동작하고 있다. 사실 디자인 패턴보다도 이 기능을 완전히 붙이기 위해서는 contentEditable 이슈를 먼저 해결해야 한다. 편집 상태를 온전히 통제하고 있지 못하니 실행취소/재실행을 통제할 수가 없다. 

그리고 다음 프로젝트에서는 백엔드 인터페이스를 조금 더 추상화하는 방식도 제안해 보고 싶다. 지금은 사용자 액션마다 엔드포인트가 만들어져 있는데, 백엔드에서 중요한 건 결국 데이터의 삽입/변경/삭제 액션으로 일어나는 순서 보장일 뿐이라서 클라이언트에서 사용자의 액션이 뭔지는 사실 알 필요 없다. 
 
 
5. 코드 컨벤션
처음에는 둘이 시작하던 프로젝트에 나 혼자 남게 되었는데, 그럼에도 코드 컨벤션을 제대로 만들어두지 못했다. 프로젝트 중반부터는 나 혼자 하게 되어서 내가 작성한 파트는 어느 정도 통일성 있게 작성한다고 하고 있지만.. 부족한 점이 많다. 컨벤션 문서를 작성하는 것도 중요하겠고, 린터와 포맷터에 최대한 위임을 하는 것도 중요한 것 같다. 
 
지엽적으로는 tailwind CSS를 사용하면서 동적 스타일링에 대한 대응을 현재 인라인 스타일로 때우고 있는데, 다음 프로젝트에서는 clsx를 같이 사용해 조건부 className을 구성하고 싶다. 
 
 
이밖에도 최근 <객체지향의 사실과 오해>를 읽고 있는데 새 프로젝트 설계에 책에서 얻게 된 액션 아이템들을 적용해 보고 싶다. 시스템에 필요한 협력과 역할, 책임의 관점에서 유연하고 재사용 가능한 설계를 한다는 건 어떤 것일지 궁금하다. 
 
기술 외적으로는 입사할 때부터 알고 들어왔지만 프론트엔드 사수가 없고, 개발팀 자체가 처음 만들어진 곳이어서 모든 것을 새로 만들어나가야 하는 환경이 항상 도전 과제일 수 밖에 없었다. 이런 환경의 장점으로는 내가 하지 않으면 아무 것도 되지 않으니까 어설프게나마 처음부터 끝까지 모든 것에 관심을 둘 수 밖에 없어서 강제로 배움을 추구하게 된다는 것이고, 단점은 매일매일 이게 맞나...? 의 연속이라는 것, 불확실성과의 싸움이다. 김창준 님의 <함께 자라기>를 시작으로 좋은 책이 좋은 사수가 되어줄 수 있다는 걸 알게 되었다. 그리고 지난 8년 여의 프리랜서 생활을 돌이켜보며 불확실성을 다스리는 것은 내 특기이자 장기라고 생각하고, 내가 있는 곳에서 나의 최선을 다하려고 하고 있다. 마틴 파울러 선생님의 다음과 같은 말씀을 붙잡고, '회사를 바꾸기 전에 회사를 바꾸고 싶다'고 생각하며 나아가는 중이다. 
 

"You can ChangeYourOrganization or ChangeYourOrganization.” 
That is... "You can ChangeYourOrganization (change how the work is done at your current employer) or ChangeYourOrganization." (find a new employer)