[토스 Frontend Accelerator 1기] 1주차 후기 (feat. 관심사 분리)

1주차 과제 후기

토스 과제 풀이는 문제 풀이만으로도 배울 게 많아서, 이직 생각이 없어도 채용 공고 뜨면 문제 풀러 지원한다는 얘기를 많이 들었는데, 멘토링 지원해서 문제 풀었을 때도 그렇고, 이번 과제를 풀면서도 역시나 너무 유익하다는 생각이 들었다.

토스 채용의 과제 테스트보다 난이도는 쉽지만 유형은 비슷한 특정 기능에 대한 구현 과제였다. UI는 이미 만들어져있고, 기능만 구현해서 test 를 통과하면 되었다.

1. UI가 이미 만들어져 있으니 토스 개발자는 UI 컴포넌트를 이런식으로 만드는 구나 하는 걸 볼 수 있어서 재밌었다.

2. 채용 과제 테스트에서는 제한 시간이 있다는 압박감에 조금이라도 실수해서 시간을 허비하면 머리가 하얘졌는데, 이번 과제를 하면서는 그래도 며칠의 시간이 충분히 있어서 코드를 짜다가 에러가 발생해도 될때까지 디버깅해보고, 다 완성 후에도 리팩토링도 계속 해볼 수 있어서 재밌었다.
   (하지만 며칠의 시간에도 불구하고, 결국 원하는 구현을 다 해보진 못해서 다음 주 TODO 로 남겨 뒀다. 속도와 퀄리티를 다 챙길 수 있는 킹왕짱대박천재 개발자가 되고 싶다...🥹)

3. 이번 주차 주제인 관심사 분리 라는 주제를 생각하며, 처음부터 구조를 잘 짜고, 의존성을 최대한 덜어내서 분리된 컴포넌트, 함수를 잘 만들려면 어떻게 해야할 지를 더 고민해보게 됐다.

1주차 멘토링 후기

슈퍼 I 내향인이어서, 회사 사람들 외 개발자분들을 만날 일이 거의 없었는데, 이번 멘토링에서 멘토님 뿐만 아니라 다른 좋은 똑똑한 멘티 2분과도 알게되고, 비슷한 연차 개발자들의 고민과 생각을 듣게 돼서 너무 좋았다.

멘토링 시작에 앞서, 1. 과제 경험과 2. 이번 멘토링에서 얻어가고 싶은 것을 물어봐주셨는데, 다른 분들의 고민과 답변을 들었을 때 엄청 공감이 됐다.

1. 토스 채용 과제 테스트랑 유형은 비슷한데, 채용 과제 풀 때 있던 시간 압박이 없어서 며칠에 걸쳐 작업해도 되어서 좀 더 마음 편하게 작업 했던 것

2. 속도와 퀄리티를 둘 다 챙기고 싶은 것

   • 본업 마치고 퇴근 후 과제를 하면서, 내가 더 빨리 더 잘 코드를 짤 수 있었으면 원하는 기능 구현부터 리팩토링을 다 해볼 수 있었을텐데하는 아쉬움이 남았어서 공감됐다.

3. 잘 하고 있는 건지 내 코드에 대한 확신이 없다.

   • 입사 후 0개월 ~ 6개월차 까지는 내가 아직 실력이 부족하니까 10시, 12시까지 야근하는게 당연히 필요한 과정이라고 생각했는데, 곧 1년이 되어가는 지금까지도 늦게까지 일을 붙잡고 있는게 과연 잘 하고 있는 걸까? 하는 고민을 하고 있었어서 공감이 됐다.
   • 야근을 하는 게 싫은 건 아닌데,(야근 안하는 날에도 무거운 노트북 들고 다니기 싫어서 사무실에서 공부하고 10시 이후에 집 감) 정규 업무 시간 내에 일을 다 해내지 못하는 것 같은 나 자신이 너무 싫다는 고민을 요즘 하고 있었다.
     진짜로 내 속도가 느린 문제인 건지, 애초에 업무가 정규 시간 내에 못할 양인 건지 객관적인 판단이 잘 안선다.
     
     (그래도 다행인건 야근해서 해낼 수 있는 양과 난이도 라는 거... 늦게까지 해도 결국 못해낼 정도로 실력이 부족하면 너무 슬플 것 같다😭 하하,,)

4. 커리큘럼을 보면서 퍼널이라는 새로운 디자인 패턴을 알게 된 것처럼, 더 좋은 코드와 구조를 위한 인사이트를 많이 얻어 가고 싶다.

1주차 주제 : 관심사 분리

관심사 분리에 대해서 통짜 모듈 방식(?) 이라는 '관심사' 를 하나의 모듈 안에서 전부 관리하는 새로운 방식을 들어서 신선했다.
처음에는 몇 천자가 넘는 코드가 한 모듈에 들어 있는 외양에 의문이 들었는데, 설명을 들어보니 또 이 방식의 장점이 납득이 되었다

통짜 모듈 방식	vs	기존에 해왔던 분리 방식
한 페이지(기능)에 관련된 모든 로직을 하나의 모듈(파일)에서 관리, 최대한 다른 페이지와 로직을 공유하지 않음	방법	여러 페이지에서 공통 사용되는 로직을 hooks, util 디렉토리로 분리하여 imprt, export 하여 사용
하나의 모듈에서 읽어야 하는 코드 길이가 길다	가독성	하나의 모듈에서 읽어야 하는 코드 길이가 상대적으로 짧다
비슷한 기능에 대해 여러 모듈에서 중복해서 정의하는 코드가 많아질 수 있다.	중복성	중복되는 코드는 분리해서 공유해서 사용하므로 코드 중복이 적다
각 모듈간 공유하고 있는 로직이 적어 서로 얽혀있지 않고 독립적으로 분리되어 있다	결합도	로직을 공유해서 사용하는 모듈이 많을수록, 모듈 간 결합도가 높아질 수 있다
각 모듈이 독립되어 있으므로, 특정 부분의 수정사항이 생기면 해당 모듈에 맞춰 유지보수하기가 쉽다. 반면에 공통된 로직도 한 번에 수정하기 어렵고 모든 모듈을 찾아서 수정해야하는 단점도 있다	유지보수	여러 모듈에 걸쳐서 사용되고 있으므로 특정 모듈에서만 수정이 필요한 경우 맞춰 수정하기가 쉽지 않고, 아예 분리해버리기도 한다
이 방식에 대해 심도 있는 논의가 이루어지기 전까지 팀원들의 반발이 심할 것 같다.	범용성	일반적으로 많이 사용되던 방식으로 큰 설득이 필요없을 것 같다

관심사 분리 라는 주제를 보고 멘토링을 받기 전 했던 생각 및 코드에 반영했던 내용은
1. UI / 로직 을 분리
2. 1을 위해 컴포넌트 내부에 로직을 넣지 않고 커스텀 hook 으로 분리해서 여러 컴포넌트에 걸쳐서 재사용성을 높이자
였다.

그래서 카드 발행 전단계에 걸친 페이지들을 퍼널로 만들고
각 단계(=페이지) 이동을 useFunnel 이라는 훅으로 만들어서 onNext, onPrev, step 으로 분리한 정도로도 나름 관심사 분리를 챙겼다고 할 수 있지않을까? 생각했다
(ㅎㅎ 하지만 이런 방심하는 생각은 역시나 사망 플래그..! ☠️🏴‍☠️ )

서막은 관심사 분리에 대한 한 멘티분이 작성해주신 내용을 공유하는 것에서 부터 시작됐다.

무엇을 어떠한 관점으로 볼 지에 대한 차이

그리고 한 모듈에서 사용되는 로직을 해당 모듈 안에 모두 두는 것과, util, hook 등으로 분리해서 다른 모듈에서 공유해서 사용하는 것에 대한 질문이 이어졌는데,
로직을 다른 파일로 분리하는 것이 복잡도를 낮추는 것이 아닌 숨기는 것이라고 생각한다고 하셨다.

그동안 당연하게 중복된 코드를 작성하지 않도록 공통로직은 util, hook 등으로 묶어서 분리해서 재사용해야한다고 배웠고 의문없이 그렇게 코드를 작성해왔었는데 프레임이 깨진 느낌이었다.
(이에 대해 이전부터 고민해보고, 본인만의 생각과 논리가 쌓여있는 멘티분이 너무 신기하고 존경스러웠다.)

개발자는 필연적으로 수많은 기획 변경과 마주하는데,
이때 각 모듈이 공유하고 있는 로직이 많을수록 수정이 어려워진다는 아래 예시 설명을 듣고 통짜모듈에 대한 설명이 이해가 됐다.

예를 들어
1. 날짜를 yyyy.mm.dd 형식으로 표현하도록 하는 formatDate() 를 util 에 정의하고, 날짜를 사용하는 모든 모듈에서 import 해서 사용하고 있었다.

const formatDate = (date: Date) => {
    // 형식 변환 어쩌구 로직
	return 'yyyy.mm.dd';
}

2. 그런데 my profile 페이지에서는 yyyy-mm-dd 로 표현해달라는 수정 요청이 들어왔다.
   1) formatDate 내부에서 페이지에 따라 다른 형식을 보여주는 로직을 추가하거나
   2) my profile 페이지에서만 사용하는 myProfileFormatDate() 함수를 따로 만들 수도 있다.

const formatDate = (date: Date, page: string) => {
    if(page === 'myProfile'){
      return 'yyyy-mm-dd' 
    }
	return 'yyyy.mm.dd';
}

이렇게 서로 다른 모듈에서 공유하고 있는 로직이
유지보수를 하며 점점 더 덕지덕지 더러워지게 될 수 있다는 문제가 있다.

또 다른 개발자가 이미 만들어 둔 util 이 있는지 찾는데 드는 비용, 공통되는 로직이라고 생각해서 합쳤다가 다른 부분을 찾아서 다시 분리하는 비용 등이 있을 것 같다.

처음부터 이 모듈에서 사용될 것은 이 모듈 내에서 정의한다고 생각하고 개발을 하면 위 비용들이 들지 않는다는 장점이 있다.

그래서 적용 가능할까?

멘토님이 이 방식을 설명해주시면서, 하지만 이 방식에 대해 본인도 많은 다른 개발자들의 반발에 부딪힌다고 하셨다

아니나다를까, 회사에서 다른 개발자분들에게 제안을 해보았는데,
1. 한 파일에 몇 천줄짜리 코드가 있는 것에 대한 거부감
2. 불필요하게 이미 만들어진 로직을 각각의 모듈에서 각자 다시 만드는 데에 대한 반대
3. 같은 코드가 중복해서 쌓이면서 용량이 늘어나는 것에 대한 반대
등의 이유로 4명 중 4명에게 반대를 들었다. 😂

그래도 한 번쯤...

이 방식을 지금 회사에서 바로 적용하기에는 당연히 무리가 있지만,
의견이 맞는 개발자들을 모아서 장기적인 토이 프로젝트에서 한 번 사용해보고 싶다는 생각이 들었다.
ver.1 을 개발할 때까지는 장점을 느끼기 어려워도,
ver.2, ver.3 등 여러 수정사항을 마주하는 프로젝트에서는 이 방식의 장점이 십분 이해될 것 같다.