참을 수 없는 코드의 가벼움(3년차 개발자 회고)

이 글의 제목인 참을 수 없는 코드의 가벼움은 환경과 다른 코드에 영향을 받아 쉽게 흔들리는 불안한 코드를 표현한 것이다.

취업해서 개발자로서 일을 시작한 지 2년이 넘었다. 나에게 코드는 굉장히 흥미로운 도구이지만, 매일 씨름하는 스트레스의 주범이기도 하다. 코드를 작성하는 개발자는 종종 "이게 왜 안되지?", "엥, 왜 돌아가지?"라고 생각하곤 한다. 하지만 사실 코드는 아주 정직하게 동작한다. 코드는 앞에서 그렇게 생각한 개발자를 "아, 내가 바보네"라고 생각을 고쳐먹게 한다. 코드가 제대로 동작하는지는 개발자의 손에 달린 것이다.

애증 덩어리인 코드를 작성하면서 좋은 코드에 대해 늘 고민했다. 좋은 코드에 대해 정의하는 많은 책과 아티클이 있고, 또 이것은 개발자 커뮤니티에서도 자주 접할 수 있는 주제다. 이 글에서는 주니어 개발자로 일하면서 좋은 코드에 대해 고민했던 것들을 다시 돌아보려 한다.

기능과 도메인에 대한 이해

제 코드를 믿으세요...? 저 신입인데요.

처음 개발자로 입사를 하고서는 제대로 동작하는 코드를 작성하려고 고민했었다. 회사 개발팀의 문화가 여느 빅 IT 기업처럼 좋은 문화는 아니었다. 테스트 코드도 없었고, 코드 작성 컨벤션도 없었다. 기능만 제대로 동작한다면 내 코드를 아무도 들여다보지 않았다. 모든 것이 기능 위주의 개발이었다. 이렇게 개발을 하고 나면 서비스가 배포된 후에 사용자가 버그를 발견하는 경우가 많았고, 이것에 대해 보완할 수 있는 장치는 없었다. 코드를 작성한 내가 열심히 수동 E2E 테스트를 할 뿐이었다. 사실 가끔은 "소프트웨어는 완벽할 수 없고, 버그는 고치면 된다"라는 선임자의 태도가 나를 위로하기도 했다. 하지만 그것으로 내 코드에 대한 불안을 떨쳐낼 순 없었다.

iPad Safari에서는 안 되는데요?

취업하기 전에 만들었던 토이 프로젝트와 다르게 비즈니스 레벨의 프로젝트에서는 고려해야 할 것들이 더 많다. 웹에서는 크로스 브라우징 이슈나 웹 표준에 대한 부분을 따져보아야 한다. 또한 모바일과 태블릿에서의 호환성도 챙겨야 하고, 사용자 데이터가 많아짐에 따라 성능 하락이 생기지 않는지 신경 써야 한다. 이런 부분에서 꽤 많은 버그가 발생했었다. 데스크탑 + Windows + Chrome + 넉넉한 CPU와 메모리의 환경에서 잘 동작하던 것이 다른 OS나 브라우저에서는 다르게 동작하거나, 너무 느리거나 하는 버그가 있었다. 같은 기능이라도 환경마다 어떻게 다르게 동작하는지 알아야 하기 때문에 코드 이외에도 신경써야 할 부분들이 꽤 있었다.

사용자가 원하는 것이 진짜 좋은 서비스일까?

특히 기억에 남는 이슈가 있다. iPad에서는 웹 페이지 viewport 설정을 user-scalable=no으로 지정해도 Pinch to Zoom 기능을 제한할 수 없다. 애플이 웹 페이지 정책보다 사용자의 UX(눈이 너무 나쁘거나 시각장애인일 경우)가 우선된다고 생각하기 때문이다. 나는 애플의 정책에 동의하지만, 우리 서비스의 기획자와 사용자는 아니었다. 결국 웹킷 엔진에서는 터치 이벤트를 분석해 Pinch to Zoom을 제한하는 기능을 따로 구현했다.

웹 표준이나 OS 정책, 보편적인 사용성을 지키는 것이 좋지만 늘 그렇지는 않다. 서비스와 도메인에 따라서는 앞서 말했던 것과는 다르게 동작하도록 처리할 부분들이 있다. 어쩌면 특정 팀원의 고집으로 내가 생각하기에 일반적이지 않은 방향으로 개발해야 할 수도 있다. FACEBOOK의 추천 알고리즘이 정치적 편향을 만든다는 논란처럼 특정 기능이 미치는 영향에 대해 전부 알기 어렵지만, 좋은 서비스를 만드는 것이 무엇인지 생각해보게 되는 계기가 되었다.

기술에 대한 이해

Mobx를 쓰다 보니 Redux가 보인다.

입사하기 전에 프론트엔드 관련 기술 중 Vue를 주로 사용했던 터라 React에 대해서 잘 알지 못했다. 입사하면서 React를 사용하게 되었고 팀이 사용하는 상태 관리 도구인 Mobx를 사용했다. 1년 정도 리액트 + Mobx로 개발하면서 자연스럽게 더 깊이 알게 되었다. 리액트 상태 관리 도구로 잘 알려진 Redux에 대해 많이 들었지만 Mobx와 비교해 보진 않았었다. Mobx를 더 깊이 알아갈수록 Redux에 대한 궁금증이 생겼다. Mobx는 이렇게 동작하는데 Redux는 뭐가 다를까?

이런 종류의 궁금증과 기술에 대한 이해가 커지는 시기는 입사 후 6개월부터 2년 정도까지였던 것 같다. 회사에서 React를 쓰면서 자연스럽게 React와 비교하며 Vue에 대해서도 더 공부하게 되었다. 또 Postgres를 사용하면서 Mysql과는 다른 데이터 타입은 무엇이 있는지, Datetime에 대한 처리는 어떻게 다른지 자연스럽게 알게 되었다. 하나의 기술을 깊이 알수록 이것과 비교하며 같은 목적의 기술을 더 쉽게 이해할 수 있는 것 같다.

이렇게 짜면 느릴 것 같은데...

실사용 서비스를 계속해서 개발-배포하는 반복되는 과정에서 코드는 언젠가 복잡해지고 속도의 문제를 마주친다. 개발 초기 단계에서 이미 존재했지만 몰랐던 문제일 수도 있다. SSR에서의 서버 처리 시간이 길어지거나, React 컴포넌트의 비효율적인 렌더링 등과 같은 문제가 이제 보이기 시작하는 것이다. 서비스의 속도가 느려지는 것뿐만 아니라 빌드/배포 시간도 길어진다. 개발자의 사고 방식 중 하나는 "이게 지금 1개일 때 이 정도인데, 100개/1000개/10000개가 되면 어떨까?" 하는 식의 무한대를 생각해 보는 것이다. 문제가 생겼을 때 빨리 해결하지 않으면 그것이 스노우볼이 되어 돌아올 것을 개발자는 직감한다.

또한 치명적인 성능 이슈가 아니더라도 기술에 대한 이해가 생기면 내가 작성하는 코드가 성능에 어떤 영향을 미치게 될지 어느 정도 예상하게 된다. React의 Memoization을 적용한다거나, Mobx의 Reaction을 활용하는 것처럼 더 좋은 패턴을 사용하여 코드를 작성하는 고민을 하게 되는 것이다. 코드가 믿음직하지 못하더라도 동작하는 것에 만족했던 신입 때와 다르게 내가 작성하는 코드가 섹시하게 동작하는 것을 위해 신경 쓰게 되는 것이다.

설계에 대한 이해

코드는 언제든지 변경될 수 있다. 내 예상과는 늘 다르게.

관심사의 분리

컴포넌트 패턴 중에 Container Presenter 패턴이 있다. 컴포넌트의 비즈니스 처리 로직과 렌더링 뷰 부분을 구분하는 패턴인데, 컴포넌트를 반복적으로 개발하고 사용하다 보면 이러한 관심사의 분리를 위한 연구를 하게 된다. 코드가 동작하는 컨텍스트의 목적에 따라 코드를 분리하는 것이다. 또한 다른 뷰이지만 같은 비즈니스 처리 로직이나 상태를 가지거나, 같은 상태를 가지지만 다른 뷰를 가지는 경우와 같이 코드를 재사용할 때에도 효과적으로 이용할 수 있다.

이것은 컴포넌트에만 적용되는 개념이 아니다. 서비스 레이어의 클래스를 작성하거나 심지어 아주 단순한 함수 하나를 작성하더라도 같은 원리를 적용할 수 있다. 코드 컨텍스트에 여러 목적을 위한 코드가 섞여 있으면 코드를 이해하기도 어렵고, 테스트하기도 어렵다. 작성하는 클래스의 역할이 무엇인지, 함수를 어느 정도 수준으로 쪼갤 것인지 고민하면서 코드가 적절한 자리에 있도록 설계해야 한다.

유연한 인터페이스 사용

코드의 변경을 예측하는 것은 쉽지 않다. 물론 도메인에 따라 어떻게 확장될 것인지 예상할 수 있는 부분도 있지만, 요구사항과 기능이 변하면서 코드가 변경되는 일을 미리 알기는 어렵다. 예측하지 못한 변경보다 더 나를 힘들게 하는 것은 하나의 코드를 수정하기 위해서 다른 코드를 수정해야 하는 일이었다. 이러한 문제들을 마주하면 SOLID 원칙, Strategy 패턴, 의존성 역전, 헥사고날 패턴 등 여러 가지 설계 이론들이 얼마나 필요한지 깨닫게 된다. 또한 이것들을 적용하는 것은 매우 즐거운 일이다. 클래스나 함수를 직접 참조하지 않고 인터페이스를 정의하여 사용하는 것이 얼마나 안정감이 있는지 느끼게 된다.

마치며

코드를 작성할 줄만 알고 깊이 이해하지 못했던 입사 초기와는 다르게 이제 코드의 가벼움이 주는 영향을 많이 체감한다. 사실 충분한 시간이 없는 경우에는 아직도 가벼운 코드를 급하게 작성하기도 한다. 이것은 정말 참기 힘든 부분이다. 내 스스로 기술 부채를 남기는 경험은 모든 개발자가 질색할 것이다. 빠르게 변화하는 소프트웨어의 생명주기에서 경제적이고 가볍지 않은 코드를 작성하는 것이 이 시대 속 모든 개발자의 숙명이 아닐까.

2년 반이 넘는 시간 동안 코드에 대한 시각이 많이 변했다. 이제는 묵직한 코드를 작성하고 싶다. 검증된 코드를 작성하기 위해서는 아직 많은 경험이 필요할 것이다. 다행히 몇몇 빅 IT 기업들과 개인 개발자들이 양질의 기술 정보를 공유하는 시대에 살고 있다. 많은 개발자들이 지식을 공유해준 덕분에 계속해서 성장할 수 있을 것이다. 이런 문화는 개발자라는 직업의 매력 중 하나인 것 같다. 이제 앞으로 3년 후에는 내가 어떻게 코드를 바라보고 어떤 코드를 작성하고 있을지 기대하며 글을 마친다.