[Start up] 스타트업 개발자의 허심탄회한 이야기 (첫 회의)

8. 프론트 개발자 첫 회의

우선 배경을 이야기하자면 프릭스 헬스케어는 나와 포비를 제외한 모든 개발자가 비전공자 대학생들이었다. 모든 비전공자 개발자들이 그렇다고 할 순 없겠지만, 그 때 개발자들은 타입에 대한 이해도가 높지 않았다. 그걸 기반으로 회의가 진행됐고, 일단 리팩토링이 너무 절실했기 때문에 몇 가지 안건에 대해 회의를 했다.

1. 타입스크립트를 사용하는 이유

첫 회의 안건은 타입스크립트를 사용하는 이유였다. react-native와 typescript로 프로젝트를 만들었지만 모든 타입은 any였다. 그 때 생각을 하면 머리가 어질어질하다. 모두가 타입스크립트가 좋다고 하니까 사용했다는 답변을 듣고 타입이 필요한 이유에 대해 설명하기 시작했다.

타입 언어는 비타입 언어에 비해 코드 생산성, 코드 리뷰 및 협업에서 매우 강한 강점을 가질 수 있다. js의 특성상 object를 사용하는 경우가 매우 많은 데 만약 남이 짠 코드에서 object의 타입이 적혀있지 않다면... 상상도 하기 싫다. 그 코드를 쭉 따라가서 어떤 오브젝트가 있는 지 일일이 확인해야한다. 비타입언어는 그 나름의 매력이 있다고 생각하지만 개인적으로 비타입언어는 협업에 있어 너무 많은 단점이 존재한다고 생각한다.

나는 특정 기능 부분을 올바른 타입스크립트 형식으로 리팩토링한 후 예시를 들어가며 설명을 해줬고, 팀원들과 해당 형식으로 리팩토링을 하기로 결정했다.

2. MobX를 사용하는 이유

두 번째 안건은 redux, redux-toolkit, context api 등 다른 상태관리 툴이 아닌 mobx를 사용하기로 결정한 이유였다. 이 때의 답변은 러닝커브가 낮아서였다.

답변을 듣고 나는 별다른 말을 할 수가 없었다. 적어도 기능 비교 정도는 해봤을 줄 알고 이야기를 시작한 것이었는 데, 그저 쉬워서라는 답변이 말문을 막히게 했다.

그래서 일단 MobX로 계속 사용해보고 다른 문제점이 생기면 변경하기로 했다. (UI 측면에서도 리팩토링을 전부 다 진행했어야 했기 때문에... 상태관리 툴 까지 한 번에 변경하면 더 정신없을 것 같기도 했다.)

3. Atomic Design의 기준

전체적인 코드를 지켜본 결과 일관성이란 게 거의 존재하지 않았다. 물론, 앱을 무에서 유로 창조한다는 것은 쉬운 일이 아니라는 것 정도는 알고 있지만 Atomic Design을 사용한 이유가 전혀 보이지 않았다. 폴더 구성 자체도 이게 Atomic Design이 맞나 싶었는 데, 사용하게 된 계기를 물어보니 이 것도 어떤 블로그를 읽었는 데 좋아 보여서 썼다고 한다.

대부분의 답변이 어디서 봤는 데 혹은 어디서 들었는 데 좋아보여서였다. 나로써는 이해가 잘 안 가지만 그런 사람도 있을 수 있다는 생각으로 내가 조사해온 Atomic Design의 정의부터 설명을 했다. 대부분 이미 알고있다는 분위기여서 폴더 구성을 이렇게 한 이유가 있냐고 물어보니 답변이 딱히 없었고, 새로운 폴더 구조를 제안했고, 그에 따르기로 했다. 또한, 어떤 형식이 어떤 폴더에 들어갈지 Atom, Molecule, Organism, Template 구조에 대해 정리했다.

4. 리팩토링 업무 분담

이 때 회의에 참여한 개발자는 나(플래시), 이누, 코난, 패트 총 4명이었다. 이 중 맨 처음부터 개발을 시작한 건 이누였고, 이누가 프론트 개발자가 너무 부족하다고 해서 들어온 게 코난이라고 한다. 패트는 백엔드 개발자인 미륵의 친구여서 들어오게 됐는 데, 개발에 대해 아무것도 모르는 상태로 인턴으로 들어왔다.

내가 느끼기에는 지금부터 패트를 개발에 투입시키기에는 더 큰 혼란을 야기할 것 같았고, 우선 이누, 코난, 나 이렇게 셋이서 부분을 나눠 리팩토링 작업을 진행하기로 했다.

9. 리팩토링 vs 기능 개발 (뭐가 먼저일까?)

리팩토링은 생각보다 많은 시간을 요하는 작업이다. 특히, 초기 설계부터 잘못되어 있거나 타입이 정해져있지 않은 경우에는 더더욱 오래 걸린다. 회사에 리팩토링에 대한 시간을 별도로 요청했지만, 기능 개발을 계속 뒤로 미룰 수도 없는 노릇이었다.

리팩토링은 정말 짬짬이 해야하는 작업이다. 모든 개발자라면 과거에 자신이 짠 코드를 다시 보고 '엥? 이게 내가 짠 코드라고? 진짜 너무 못 짰다...' 이런 생각을 한 경험이 있을 것이다. 물론, 너무 잘 짜서 나중에 봐도 멋진 코드인 경우도 있을 수 있지만, 나의 경우에는 그렇지 않은 경우가 더 많았다. 만약, 이런 생각이 들었을 때 바로 코드를 고치지 않는다면 상황은 걷잡을 수 없이 커질 수 있다. 이 문제가 쌓이고 쌓여서 거대한 더 큰 문제를 만들 것이기 때문이다. (마구마구 엉켜버린 실타래처러 말이다.)

리팩토링은 왜 해야할까?

리팩토링이란 작업을 비개발자가 본다면 기능 개발을 위해 사용한 시간을 또 사용하는 것처럼 느낄 수도 있다. 기능1을 개발하기 위해 시간을 썼는 데, 기능1을 리팩토링하기 위해 또 시간을 쓴다고 느껴질 수 있기 때문이다. 물론, 여기서 드는 시간은 리팩토링하는 시간이 더 적겠지만 아무래도 그렇게 느껴지기 마련이다.

혹자들은 여기서 절대적인 시간이 더 많이 든다면 리팩토링을 안 하는 게 낫지 않냐고 말할 수 있다. 하지만 리팩토링을 하면서 재사용성을 늘린 코드들은 후에 개발될 많은 부분에서 훨씬 시간을 줄일 수 있다. 또한, 코드 가독성을 늘려서 본인이 짠 코드를 추후에 다시 볼 때나 팀원들이 코드를 봤을 때 코드를 빠르게 이해하고 기능을 추가하거나 수정하는 작업을 더 빠르게 진행할 수 있다.

개발자들이 어느 정도 설계를 하고 개발을 시작하지만, 전에 개발했던 기능1과 이번에 개발하게 될 기능2에서 중복적인 기능이 존재한다면 해당 부분을 한 번 더 코드로 작성하는 게 아니라 리팩토링을 통해 재사용하는 게 훨씬 효율적이다.

많은 스타트업의 비개발자 인원들이 이 부분에 대해서 어느 정도 인지하고 리팩토링에 대한 관대함을 가져줬으면 한다. 우리 회사는 개발자들의 의견을 잘 수렴해주는 편이어서 리팩토링을 열심히 하고 있다.

그렇다고 개발자들이 무작정 리팩토링에 대한 기간을 달라고 하는 것도 문제가 될 수 있다. 아까도 말했듯이 리팩토링은 짬짬이 해야하는 작업이다. 이 때의 경우 전체적인 대공사로 리팩토링을 진행해야 했지만, 일반적인 경우 기능을 개발하면서 리팩토링을 동시에 진행하는 게 가장 효율적이다.

예를 들어, 1커밋 후 1리팩토링 같은 형식으로 자신이 정해놓은 틀에 맞게 리팩토링을 진행한다면 훨씬 퀄리티 있는 코드를 작성할 수 있을 것이다.

리팩토링 + 기능개발

우리는 기능 개발을 하면서 리팩토링을 진행하게 됐다. 나는 리팩토링 하기로 한 형식에 익숙해져 있었기 때문에 기능 개발을 하면서 리팩토링을 하는 데 무리가 없었지만, 다른 인원들은 리팩토링 하기로 한 형식을 익히는 게 중요하다고 생각했다. 따라서, 내가 기능 개발을 전담하고 다른 인원들은 리팩토링에 전념하기로 했다. 사실 기능 개발이라고 해봤자, 페이스북 SDK 연동, firebase 연동 등이 대부분이었다.

다음 이야기

무엇을 먼저 개발해야 할까요? 라는 질문으로 이어가보도록 하자.