사수없는 스타트업에서 프론트엔드 개발자로 살아남기

공통된 코드 컨벤션 갖기, 코드 리팩토링

Namu CHO
4 min readSep 14, 2021

사실 사수는 있습니다.

하지만 사수를 사수라 부르지 못하는… Nameun CHO…

현 회사에는 개발자들이 대략 몇 십명이 있다.

그 중 프론트엔드 개발자로 입사한 사람은 나와 사수 단 둘.

사수는 나보다 2~3달 먼저 이 회사에 입사했다.

하지만 앞서 말했듯 나는 사수를 사수라 부르지 못하는데…

(누가 사수라 부르지 말라고 한거 아님…)

그 이유는 그가 내 사수인듯 사수아닌 사수같은 사수이기 때문이다.

무슨 말이냐하면, 사수는 분명 프론트엔드 개발자로 입사하였으나

그가 하고 있는 일은 단지 자바스크립트를 쓸뿐 일반적?으로 생각하는 프론트엔드 업무를 하고 있지 않기 때문이다.

그래서 업무가 전혀 겹치지도 않을 뿐더러

너무나도 바쁜탓에 말을 걸기도 어렵고,

사수도 리액트가 강점이 아니기 때문에 리액트와 관련한 인사이트를 얻기가 어려워보였다.

이러쿵저러쿵하였지만

결론은 혼자 프론트엔드 개발자인 것과 진배없는 삶을 살고 있다는 말을 하고 싶었다.

혼자 ㅇㅇㅇ 개발자일 때 겪는 어려운 점

‘혼자서 ㅇㅇㅇ개발자’였을 때 문제점은 여럿 있겠으나,

그 중 내가 겪고 있는 문제는

  1. 성장의 속도가 느린 것 같다고 느껴지는 것
  2. 피드백을 받기가 어렵다는 것
  3. 2번의 이유로 코드를 헤이하게 짜게 될 수도 있다는 것이다.

이 글에서는 3번 문제점에 대해 말해보고자 한다.

바쁘다, 급했다 등등 이런저런 핑계로 프로젝트를 마무리하고 보니

나에게는 아주 흉물스러운 리액트 코드가 남아있었다(‘내 코드 냄새나!’).

내 코드의 문제점들은 간추리자면 아래와 같았다.

  1. api요청 코드와 UI코드가 한 곳에 있음
  2. 어떤 api요청은 fetch를 쓰고 어떤건 axios를 씀(기준 없음-사수도 초반에 아주 잠깐 이 프로젝트에 참여하여 코드를 짰었는데, 서로 합의 없이 사수는 axios를 썼고 본인은 fetch를 써서 이런 문제가 발생했다.-)
  3. 어떤 컴포넌트 파일은 대문자로 시작하고 어떤건 소문자로 시작함(기준 없음)

심지어 1번 문제를 해결하고자 인터넷 강의를 찾아보니

dependency injection 형태로 클래스타입의 api통신 코드를 프롭스로 넘겨주는 식으로 작성하는 것이 좋다고 하여

상당수의 api통신 코드를 클래스형으로 짜고 리팩토링을 진행했는데…

결과적으로는 이게 현 프로젝트와 맞는 형태의 코드가 아니라는 판단이 났다(그 이유는 추후 더 자세히 설명하겠다.)

심지어 api코드를 클래스형으로 만들어 분리하는 이 작업을 모든 api코드에 한 것이 아니라서 더더더 ‘니 코드 냄새나!’단계에 이르른 꼴이 되었다.

그래서 최근 내가 한 작업은

  1. fetch를 모두 axios로 바꾼다.
  2. axios 통신 시 자주 사용되어지는 코드를 커스텀 훅으로 짠다(로딩상태 관리 및 리턴, 성공 시 서버에서 보내준 리턴 값 파싱하여 필요한 값만 리턴, 실패 시 alert띄우는 작업 등 반복적인 작업을 하는 코드를 작성하였다).
  3. api코드를 UI코드에서 분리하여 따로 관리한다.
  4. 2번에서 작성한 코드를 이용하여 서버 통신 코드를 리팩토링한다(그러면 중복되는 코드를 대폭 줄일 수 있다)
  5. 3번의 코드는 커스텀 훅 형태로 짠다.
  6. 위의 작업들을 진행하면서 소문자로 시작하는 컴포넌트 파일명들은 모두 대문자로 시작하도록 파일명을 변경한다.

등의 작업을 진행했다.

물론 보기 흉한 코드를 짜는 것 자체가 스스로에게 부끄러운 일이기에 리팩토링한 것도 있지만,

후에 나 말고 다른 이가 이 프로젝트를 맡게 되었을 때 유지 보수 및 관리가 쉽도록 하는 것 또한 나의 업무라고 생각했다.

그래서 프로젝트 전체에서 통하는 코드 컨벤션을 가지고 있어야 하겠다는 생각이 들어 코드 리팩토링을 진행하게 되었다.

어려웠던 점

코드 리팩토링을 하는 것 자체는 어려운 일이 아니었으나,

왜 fetch대신 axios를 써야할까?

폴더 구조를 어떻게 가지고 가야 할까?

등의 생각과 그에 대한 나만의 답을 찾아가는 과정이 힘들었으며,

‘현재 잘 돌아가는 코드 괜히 건들였다가 오히려 문제만 생기는 거 아니야? 심지어 이 코드로 해야하는 이벤트가 곧 다시 열리는데 괜히 긁어 부스럼 만들지 말자, 지난 코드 동작 잘 했잖아!’하는 내 걱정+안일한 마음과 싸우는 것이 힘들었다.

--

--

Namu CHO
Namu CHO

Written by Namu CHO

외노자 개발자 나무 🇸🇬

Responses (1)