회사 동료와 이야기를 나누던 중 코드리뷰에 대한 주제가 나왔다. 나는 부트캠프 시절 회사에 빨리 취업하고 싶었다. 그 이유는 회사에서 코드를 다루는 법을 알고 싶었으며 시니어들의 리뷰를 받아보고 싶었다. 하지만 이런 희망사항은 회사 개발 문화가 잘 자리잡힌 조직에만 해당된다는 것을 입사 후에 알아버렸다. 그래서 항상 코드리뷰와 프론트엔드 시니어 개발자의 조언에 대한 목마름이 있었다. 그런데 회사 동료가 Next Step 강의에서 코드리뷰를 받을 수 있다고 알려주었고 사이트에서 강의 정보를 살펴보았다. 가격은 생각했던 것보다 매우 비쌌지만 살면서 이런 리뷰를 언제 받아보겠나 싶어서 신청하였다.
7월 19일 부터 9월 13일까지 일주일에 1회 줌을 통해 수업을 진행하고 미션을 진행하였다. 점심시간과 퇴근 후 과제를 진행하고 PR을 요청했다. 리뷰를 받고 수정하며 코드를 보완해 나갔다. 정말 남는시간에 과제만 한 것 같다. 여름기간 동안 정말 열심히 달렸던 것 같다. 남들보다 뒤쳐지기 싫어서 더 열심히 했던 것 같다. 수업을 들으며 여러 수강생들의 코드와 생각을 볼 수 있었는데 정말 많은 도움이 된 것 같다.
강의를 들으며 새로 알게 된 점, 느낀점, 배운것을 적용한 사례등을 두서없이 간단하게 작성해 보려고 한다. 지식적인 내용도 있지만 개발과 업무에 대한 느낀점이 더 많을 것 같다.
TDD란 무엇인가?
부트캠프에서 협력사 설명회 후 식사자리에서 TDD라는 용어를 처음 들었다. 다른 동기 형이 코치님에게 TDD에 대해서 어떻게 생각하시는지 질문하였다. 코치님은 TDD는 구글, 페이스북등 빅테크 기업 안에서도 제대로 할 수 있는 개발자는 몇 없다고 하셨다. 대한민국의 개발 환경상 제대로 TDD를 적용하는 것은 매우 어렵다고 하셨다. 그래서 그 당시에는 큰 관심을 가지지 않았다.
하지만 취업준비를 하면서 여러 모집요강을 보다보면 TDD에 대한 내용이 꽤 많았다. 그리고 다른 부트캠프 동기들에게서 TDD에 대한 이야기를 들을 수 있었다. 물론 백엔드 개발자였고, 다른 프론트엔드 개발자 동기들 중에서는 TDD를 적용한 사례는 보지 못했다. 그래서 해당 강의에 대해 관심이 생겼던것 같다.
강의를 듣기 전에는 테스트를 위한 코드를 작성하고 환경을 작성하는 것이 TDD라고 생각했다. 하지만 TDD는 내가 생각했던 것과 많이 달랐다. 강의에서 들은 TDD의 핵심은 피드백을 빨리 더 자주, 더 빨리 였다. 내가 작성한 코드에 대해 피드백을 계속 받으며 작은 것 부터 빠르게 구현해 나가는 것이었다.
TDD를 통해 얻을 수 있는 장점은 처음부터 모든 기능을 구현하지 않고 동작가능한 최소단위부터 구현하기 때문에 초기 개발이 빠르다. 그리고 테스트 코드를 통해 기능 검사를 하고 필수 기능을 알 수 있기 때문에 유지 보수에도 도움이 된다. 또한 코드 리팩터링에 큰 도움이 된다. 리팩터링은 코드만 달라지고 기능은 동일해야 한다. 그러므로 테스트 코드는 내가 진행하고 있는 리팩터링에 피드백을 바로 제공한다. 실제로 나도 2주간 코드 전체를 리팩터링한 경험이 있는데 리팩터링을 하면서도 기존 기능이 제대로 동작하는지 모두 확인할 수가 없어서 다시 QA를 진행했었다.
이렇듯 TDD는 개발 스킬이라기 보다 방법론에 가까웠다. 나에게 주어진 문제를 분석하고 최소 기능을 구분하는 능력이 제일 큰 것 같았다. 그래서 부트캠프 코치님이 TDD가 어렵다고 말씀하신 것 같다. 복잡한 서비스일 수록 테스트 케이스를 만드는 것이 어려울 것 같기는하다. 하지만 나의 생각에는 우리는 TDD적 사고방식에 꽤 익숙하다 생각한다. 기능을 구현할때 기능에 대해 정의하고 코드를 작성한뒤 내가 정의한 기능이 제대로 동작하는지 테스트 해본다. 그리고 QA과정도 거친다. 이러한 과정의 순서와 테스트 범위만 다르다 생각한다. 그리고 코딩 이외의 업무에도 적용해 보면 좋을 것 같다는 생각도 들었다. 예를 들면 와이어 프레임이나 기획서를 보며 최소 기능에 대해 생각하고 빠진 것이 없는지 생각해보기도 하고 일정 산정시 기능들의 우선순위를 나누고 이를 반영하기도 하였다.
테스트 코드를 작성하는 것 보다 무엇을 어떻게 테스트 할지. 그리고 테스트 코드를 어떻게 작성을 해야 테스트 코드를 재사용할 수 있는지 고민하는 것이 더 어려웠다. 서비스의 모습은 변하기 마련이고 기능에 따라 테스트 코드가 영향을 받는다면 해당 테스트 코드를 사용할 수 없다. 하지만 서비스의 핵심은 잘 변하지 않고 핵심을 테스트 한다면 테스트 코드의 재사용성도 좋아질 것이다.
같은 코드라도 사람마다 의견이 다르다.
미션을 여러개 진행하며 여러 리뷰어에게 리뷰를 받았다. 신기한 점은 리뷰어마다 의견이 다른점이 생각보다 많다는 것을 알았다. 그것이 코딩의 매력이기도 하지만 회사 업무적으로 볼때는 혼란을 가져올 수도 있는것 같다. 또한 모든 코드를 일정한 패턴으로 구현할 수도 없을 것이다. 그렇다면 이런 상황에서 필요한 것이 무엇인지 생각해보았다. 결론은 다른 시각을 받아들이는 자세와 나의 구현 방식에 대한 이해가 필요한 것 같다. 나의 구현 방식에 대한 이해는 내가 선택한 방식에 대한 분명한 이유가 있어야 한다는 것이다. 왜 이렇게 했냐는 질문에 "그냥요.."라는 답변을 하지 않기 위해서이다.
새로운 것들에 대한 자세
나는 이전까지 자바스크립트를 통해 클래스를 활용해 본적이 거의 없다. 그리고 디자인 패턴 개념을 전혀 몰랐다. 그런데 다른 수강생들이 MVC 패턴과 클래스를 사용하며 객체지향적으로 코드를 작성하는 것을 보았다. 그래서 학습겸 나도 사용해보기 시작했다. 새로운 것이 나의 문제를 해결하는데 도움을 주기도 했지만 도리어 생각의 폭을 좁히기도 하였다. 예를 들면 클래스를 만들었는데 메소드의 재사용성이 없거나 객체로서의 역할이 없는 경우도 있었다. 함수로 구현하는것이 더 나은 경우였지만 클래스로 만들어야한다는 생각에 사로잡힌 것이었다. 그리고 MVC 패턴으로 구현할 경우 어느 레이어에 속해야할지 애매한 경우도 있었으며 M,V,C로는 부족한 경우도 있었다. 실제로 강의 내용중 디자인 패턴에 갇혀서 시야가 좁아지는 경우가 많아서 주의해야한다는 내용도 있었다.
나는 왜 이런 경우가 발생하는지 고민해 보았다. 내가 생각하는 이유는 새로운 것을 왜 사용하는지에 대한 이유가 명확하지 않기 때문인 것 같다. MVC를 미션에 적용하는 이유가 무엇인지, 클래스를 활용한 이유가 무엇인지, 이 함수를 만든 이유는 무엇인지 등등. 이전에는 일단 돌아가게끔 구현하느라 이런 질문을 나에게 던지지 않았던것 같다. 그래도 요즘은 무언가 잘 풀리지 않을때 내가 왜 이것을 하고 있는지 물어가면서 문제를 해결하곤 한다.
클린코드
나도 몰랐던 코딩 습관들을 볼 수 있었다. 예를 들면 변수명이나 상수관리를 아무 생각없이 회사에서 하듯이 하고 있었다. 예를 들면 상수를 constants.ts같은 한개의 파일에 모두 관리하였다. 이전에는 왜 그렇게 했는지 크게 생각하지 않았다. 정말 습관처럼 하고 있었는데 리뷰를 통해 이것이 좋지 않은 방법이라는 것을 알아서 회사 코드에서도 개선시키고 있다. 그리고 정규 표현식 같은 경우 rName 처럼 변수명을 지었다. 이유는 딱히 모른다. 그런데 리뷰를 통해 해당 변수명이 알기 힘들다는 것을 깨달았다.
이 외에도 변수명을 정하는 방식같은 컨벤션은 조직내에서 방향을 정해야 한다고 느낀 경험도 있다. 나는 변수명을 영어 문법 순서로 정하곤 했다. 예를들어 이름 유효성 검사 결과의 경우 "isNameValid"라고 변수명을 지었는데 리뷰어께서 "isValidName"이 더 좋지 않냐는 의견을 주셨다. 한글 어순이면 리뷰어의 의견이 더 맞는것 같았다. 그래서 클린코드도 조직마다 다르겠다는 생각을 하게 되었다.
API 추상화 하기
프론트엔드에서 api 통신에는 흔히 axios를 사용한다. 나는 주로 api 한개당 함수를 만들어서 axios로 api를 호출해서 data 객체를 return하였다. 하지만 만약 axios가 서비스 종료하거나 다른 라이브러리로 전환할 경우 모든 함수를 수정해야했다. 그래서 미션에서는 ApiWrapper를 만들어서 추상화 하였다. axios가 아니더라도 다른 라이브러리를 사용한다면 ApiWrapper만 수정하면 모든 코드에 적용되도록 하였다.
그리고 외부 api를 사용하는 경우 내가 원하는 데이터로 변환하는 레이어를 추가하여 추상화 하였다. 예를 들어 영화 정보를 조회할때 넷플릭스 api를 사용하다가 쿠팡플레이 api로 전환할 경우 추상화가 되어있지 않다면 코드의 상당부분을 수정해야한다.
이런 경우가 회사 프로젝트에도 있었다. 회사 제품소개 페이지에서 블로그 글을 webflow를 통해 관리하였다. 그래서 webflow api에 맞게 모든 컴포넌트가 구현되어있었다. 나는 강의를 들으며 블로그 글이 떠오르며 개선이 필요하다고 생각했다. 그래서 webflow api 응답결과를 블로그 데이터로 전환하는 함수를 추가하여 webflow를 사용하지 않더라도 유지보수에 용이하도록 구조를 개선하였다.
총평
강의를 들으며 그동안 생각하지 못했던 부분들을 많이 발견하였다. 그리고 TDD에 대해 제대로 알게 되었다. 하지만 내가 하는만큼 얻을 수 있는 강의인것 같다. 과제를 성실히 해서 피드백을 최대한 많이 받아야 의미가 있다. 비록 지금 회사에서는 테스트 코드를 작성하지는 않지만 미래를 위해서 투자할 가치가 있다고 생각한다.
