[ je개발 회고 ] H/F 프로젝트 회고 (2) - F 프로젝트(feat. 개발)

1. 잘못된 설계

이 프로젝트 참 많이 아끼는 프로젝트지만 그래서 리팩터링으로 싹 엎고 싶은 마음이 굴뚝같다. 먼저 변명을 하자면, 그 당시에 나는 개발 공부를 처음 시작한지 8개월이었고, 이 프로젝트가 이렇게까지 커질 줄은 몰랐고, 실제 일할 때 요구사항이 어떻게 바뀌고 오는지도 몰랐다. 그냥 몰랐다. 너~~무 몰랐다. 그래서 고생을 했다.

1) 다형성과 확장성의 중요성

일단 첫 번째로 내가 설계한 컴포넌트 구조, 기능에서는 다형성과 확장성에 용이한 형태로 설계되지 못했다. 내가 이전 회고에서도 계속 울면서 외친 4분할과 Tooltip 기능은 이 부분을 간과하고 설계했기 때문에 발생한 문제였다.

4분할 화면

4분할 화면 구현에서 가장 큰 문제는 "이렇게 될 줄 몰랐지" 다. 처음에 기획했을 때는, 하나의 화면을 4개로 쪼개서 사용할 생각이 아니었다. 총 네개의 브라우저를 띄워서 위치를 맞출 생각이었다. 이 프로젝트의 화면을 띄울 곳이 4개의 모니터로 이루어진 한 화면이었기 때문에 이런 생각이 가능했다. 하지만, 이것이 결과적으로 불가능이라 결론이 내려졌고 결국 하나의 브라우저 화면에서 네 개의 화면을 쪼개기로 했다. 그래서 처음에는 4분할 계획이 없는 상태였다가 이제 다시 설계해서 만들어야 했다. 심지어 구글링을 해도 이런 기능 구현은 따로 레퍼런스가 없었기 때문에 스스로 설계를 해야했다. 그때 당시, 내가 설계했을 때의 생각은 이러했다.

1. 4분할로 쪼개지는 것과 원래의 페이지로 남는 것에는 큰 차이가 없다. Style 의 차이만 있을 뿐
2. 이미 하나의 컴포넌트에서 구현된 기능들이 있다. 4분할로 쪼갠 화면에도 똑같이 해당 기능을 구현할 것이다.
3. 그렇다면... 그냥 하나의 컴포넌트에서 4분할일 때와 4분할이 아닐 때로 나누면 되지 않을까?
4. 반응성 있게 em 을 쓰자! 그리고 좀더 디테일하게 수정해야할 부분이 있다면 props 로 해당 화면이 4분할 화면인 것을 알려주자!

위의 생각의 흐름대로 내려와서 기능을 구현했다. 나름 나쁘지 않은 생각이라고 했다. 개발 시간도 절약을 하고, 실제로 당시에 정말 문제 없이 잘 기능이 구현됐기 때문이다. 그러나... 문제는 "디자인" 이 오고 나서부터였다. 이전에도 H/F 프로젝트에서도 보면 알듯이 마감 기한은 정해져 있으나 디자인 시안이 오는 것은 마감 2달 전이었기 때문에 내가 선작업을 하고 있어야 했다. 그렇게 선작업할 때 위의 방식으로 설계를 했던 거고, 디자인이 오고나서부터 모든 것이 무너졌다.

일단, Style 이 단순히 폰트 사이즈를 em 으로 처리한다 해서 수정될 수 없었다. 두 번째로, 디자인 온 시안이 4분할을 고려하지 않은 형태라서 4분할로 쪼개면 와장창 깨졌다(font-size 10px 가 최소인 것도 한 몫을 했다). 때문에 4분할일 때와 4분할이 아닐 때의 UI 최상단이라 할 수 있는 레이아웃 스타일도 바뀌어야 했다. 이것 이외에도 참 많은 에러 사항이 있었는데, 이것을 해결할 방법은 결국 4분할인지 아닌지를 구분해주는 props 에 맞춰 많은 분기 처리해주는 것이었다. 지금 생각해보면... 그때 내가 좀 더 공부했다고 하면 이렇게 노가다를 하지 않았을텐데 라는 생각이 들었다. 지금의 나라면 아예 컴포넌트는 Style 로, 기능(script 문)은 컴포넌트와 분리시키고, 컴포넌트를 4분할일 때와 4분할이 아닐 때로 나누어서 만들었을 것 같다. 그러면 기능은 파일을 Import 해서 사용하면 면 되는 거고 style 은 각자의 컴포넌트에서 알아서 처리를 하면 될테니 유지보수하기에도 편리했을 것이다. 지금은 하나의 컴포넌트에서 엄청난 분기 처리로 코드 양이 많아진 형태다. 때문에 유지보수하기 어려운 형태다. (현재는 기능을 모두 뺀 상태로 리팩토링 완료)

Tooltip

Tooltip 기능 구현에서 가장 큰 문제도 역시 "이렇게 될 줄 몰랐지" 다. Tooltip 에도 많은 요구사항이 들어왔다. 이 프로젝트에서는 차트가 매우 중요했기 때문에 차트에 대한 요구사항이 종종 갱신되거나 수정됐다. 그 중에서도 가장 많은 요구사항을 받았던 것이 Tooltip 기능이었다. Tooltip 에 어떻게 그렇게 많은 요구사항이 들어올 수 있느냐 생각할 수 있겠지만... 진짜 많은 요구사항이 존재했다. (그러니 이렇게 될 줄 몰랐지다) 라이브러리에서 제공해주는 일반적인 기능들만으로는 구현이 불가능한 형태가 종종 있었다. 문제는, 그런 여러 요구사항이 하나로 합쳐져서 Tooltip 에 녹아져야 한다는 것이었다. 그러니까 차트에서 다섯 개의 데이터가 렌더링 됐을 때 그 중 두 개는 A 의 요구사항을, 나머지 중 두개는 B의 요구사항을, 나머지 하나는 C의 요구사항을, 그리고 그외에도 Tooltip 에 보여줘야할 데이터로 D 의 요구사항을 반영해야 한다. 즉, 하나의 Tooltip 에 4개의 요구사항을 반영해야 하는 상황인 것이다. 이건 따로 Tooltip 을 만드는 함수를 여러개 만들어서 될 것이 아니라 Tooltip 을 만드는 하나의 함수에서 여러 요구사항을 반영할 수 있는 형태가 돼야 한다는 것을 의미한다.

나는 그냥 간단하게 Tooltip 을 구현할 함수를 만들었는데, 이것이 여러 요구 사항을 수용할 수 있는 형태가 되기 시작하면서 내부 로직이 엄청 복잡해졌다. 내가 설계한 방식은 각 요구 사항 하나와 Tooltip 구현 함수에서 넘겨 받는 매개변수 하나를 1:1 매칭을 하고, 그 매개변수는 객체로 구현하여 어떤 데이터에서 해당 요구 사항을 반영한 형태로 보여줄지로 설계를 했다. 이렇게 되니, 가장 큰 문제점은 요구사항이 하나씩 늘 때마다 매개변수가 하나가 더 추가된다는 점이다. A-D 요구사항은 무시하고 E 의 요구사항만을 반영한 Tooltip 을 그리려면 makeTooltip(null, null, null, null, E인자) 이런식으오 함수 호출을 해야한다. 최악이다. 그리고 역시나 내부 로직도 수많은 조건과 분기 처리가 되어 있어서 유지보수하기에 어려운 형태가 됐다. 지금의 나였다면... Tooltip 을 만들 class 객체를 선언해서 상속을 했거나 아니면 함수형 프로그래밍으로 각각의 요구 사항은 함수로 구현해서 함수 합성하는 방식으로 만들었을 것 같다. (즉, 나중에 리팩터링은 이렇게 할 예정이라는 것)

2) 그래서 나는

이렇게 개발을 하고 나니 유지보수에 용이하고 확장성 높은 설계가 중요하다는 것을 뼈저리게 깨달았다. 앞으로 개발할 때는 먼저 이런 부분들을 고려하고 코드를 짜게 될 것 같다. 하다보니 이전에 공부했던 TDD 나 아니면 클린 코드, 리팩터링과 같은 책에서 배운 내용들이 생각난다. 다시 한 번 복습하고 공부해야할 거 같다. 물론... 우리 회사 다른 개발팀장님께서 말씀하신 거지만 "현실은 시궁창"이다. 그래도 최대한 기술 부채가 적은 코드를 작성하기 위해서 노력해서 시궁창에서 벗어나려고 노력해야겠다.

2. 그래도 어떻게든 돌아간다

그래도 의의를 두자면 동작한다. 요구사항으로 들어 온 기능들은 모두 동작하고, 만들기로 했던 것들은 모두 만들었다. 내 1년차의 경력은 거의 H/F 프로젝트로 하나로 요약할 수 있는데 그래도 이렇게 기능이 다 돌아가고 실질적으로 서비스될 수 있고 사용할 수 있는 결과물을 만들어 냈다면 그것만으로도 충분한 의미가 있다고 생각한다. 앞으로 할 일은 이제 만든 것들을 다시 리팩터링해서 더 유지보수와 확장성 높은 수준으로 끌어올리고, 이후에 들어오는 요구사항들을 다 반영하면 될 것 같다.

지금 하고 있는 일 중 하나는 H 프로젝트의 기능 하나를 고도화하는 것인데 여기서부터 함수형 프로그래밍으로 몇 가지 코드를 개선했다. 앞으로도 계속해서 내가 만든 코드를 리팩터링하고, 내가 배운 것들을 하나씩 접목해서 내가 성장하는 만큼 이 프로젝트의 품질도 더 좋게 개선하고 싶다.

3. 레퍼런스

재밌게도, F 프로젝트를 시작하고 나서부터 블로그 작성을 뚝 하고 멈췄다. (ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ)

아래의 URL에 작성된 블로깅은 맨 처음 F 프로젝트를 시작할 때의 나의 다짐 같은 것이다.

https://je-developing.tistory.com/255

[ je 개발 일지 ] 186 - 192 일차, "기획이 내려왔다. 나의 목표는?"