본고는 회고록을 작성하지 않았던 2021년도부터 2022년도까지의 나의 개발 생활과 바탕해 회고한 내용들을 적는다.
그 중에서도 본고에서는 아하팀에서 내가 진행해왔던 업무와 이를 통해 얻은 것들을 바탕으로 진행한다.
아하팀에서 근무 하면서 여러 좋은 장점들이 많았습니다.
타당하다면 이를 근거로 주도적인 업무를 지향할 수 있었고, 만일에 업무를 진행함에 있어 사고가 발생한다 하더라도, 그 누구도 비난하거나 책임을 지게 하지 않았습니다.
그 과정에서 원인을 분석하고 다음번에는 성공할 수 있도록 재차 도전할 뿐이었습니다.
실패에 대한 두려움이 사라지니 포기하지않고 또다시 반복하며 도전을 마다하지 않는 정신을 가질 수 있게 되었습니다.
아하팀에서는 비즈니스에 있어 원샷원킬은 존재하지 않는다는 전제하에, 이러한 정신을 존중하였기 때문에 스타트업으로서의 개발자의 마음가짐을 재차 정돈할 수 있는 시간이 되었습니다.
아하팀에서 업무를 진행하며 2021.11 부터 앱 개발을 진행하게 되었다.
단순한 목적은 모바일 트래픽 대응과 매번 발송되는 카카오 채널 톡송신 비용을 줄이기 위함이었다.
당시 회원수가 80만에 육박했던 상황을 고려해보면 카카오톡 송신 비용이 어마어마했다는 것을 알 수 있었다.
그 당시에는 앱 개발이 나의 프론트엔드 커리어에 영향을 주지 않을까 걱정하였는데, 지금와서 돌이켜보면 내 커리어를 빛내줄 성과라고 생각된다.
처음하는 앱개발이었기 때문에 많은 어려움이 있었다.
리액트 네이티브와 플루터 중 당시 회사 상황에 맞는 프레임워크를 선정하기 위해 개발 팀 전 인원이 조사를 진행하였고, 회사에 리액트 개발자가 있었다는 점, 자바스크립트 기반으로 다트 언어에 비해 러닝커브가 높지 않다는 점을 사유로 들어 본격적인 리액트 네이티브 개발의 착수가 시작되었다.
물론 개발을 진행하면서도 생각 했었던 것 보다 여러 문제점들이 있었다.
1. 생각보다 너무 느렸다.
너무 느렸다. 안드로이드의 경우에는 더더욱 그랬다.
브라우저 환경에서 개발을 진행하던 프론트엔드 개발자 서 너명이 초기에 환경 세팅을 시작하고 나니, 리렌더링 요소를 최대한 줄일 수 있는 아키텍쳐를 초기에 구상해놓지 못했다.
질문 상세의 좋아요 버튼을 클릭하면, 클릭되었다는 피드백이 1초 후에 왔으며 이 것은 누가봐도 유저 경험에 최악인 것 같아 보였다.
나는 해당 문제를 맞닥드리고 리액트 컴포넌트의 아키텍쳐 구조를 전면 개편하기로 마음 먹었다.
먼저 UI 이벤트가 발생하는 액션 노드들을 별도로 분리했다.
리액트는 컴포넌트 단위로 리렌더링이 발생하기 때문에, 이벤트가 발생할 수 있는 노드들을 따로 분리해 해당 노드 내의 라이프사이클에서만 UI 변경이 이루어지도록 하였다.
이렇게 아키텍쳐를 변경하고나니, 자연스럽게 이러한 아키텍쳐들이 객체지향의 SOLID 원칙과 연관이 깊다는 것을 알게되었다.
리액트는 참조 타입에 대한 비교 수행에 있어 얕은 비교를 수행하기에 인터페이스를 최대한 분리하여 각 컴포넌트가 자신이 가지는 UI에 대한 상태값을 전달받고 즉시 처리할 수 있도록 역하과 책임을 가중하였다.2. 모니터링 시스템의 부재가 현실적으로 다가왔다.
어플리케이션이 실행되는 기기의 환경이 천차만별이다보니, 어떤 기기에서는 발생하던 오류가 어떤 기기에서는 발생하지 않고, 개발자 입장에서 이슈 트래킹이 원활하지 못하는 상황이 여렷 발생하게 되었다.
물론 대책이 없었던 것은 아니었다.
sentry를 도입해 발생하는 에러 로그는 전부 수집을 하고 있어 어느정도 파악은 할 수 있었으나, 문제는 해당 오류가 어떠한 케이스에 의해 일어나는지는 알 겨를이 없었다.
아하팀은 이를 해결하기 위해 사용자의 모든 인터렉션을 수집하기로 했다.
외부 모니터링 서비스를 사용하고 해당 서비스에 모든 인터렉션 이벤트를 넘겨, 에러가 발생한 사용자가 그 이전까지 어떠한 인터렉션을 앱에 가하였는지 수집하도록 했다.
해당 기능을 도입하고나니, 더이상 유저 이슈 대응이 무섭지만은 않았다.물론 얻은 것도 많았다.
1. 디자인 패턴의 중요성을 깨닫게 되었다.
디자인 패턴이 가지는 범용성에 대해 다시한번 생각해보게 되었다.
물론 자바스크립트가 객체 지향 언어인 것은 맞지만 그렇다고 해서 완전한 객체 지향 언어는 아니기에 객체 지향 방식의 SOLID 디자인 패턴에 대해 중요치 않게 생각하고 있었는데, 해당 디자인 패턴이 가지는 코드의 구성 방법, 크게는 아키텍쳐의 조정과 유지보수의 용이성 제공까지. 내가 놓치고 있었던 것이 많다고 다시한번 느끼게 되었다.
2. 테스트 코드의 중요성을 깨달았다.
웹 사이트를 개발함에 있어 기존에는 JSDOM을 통해 Node 상에서 브라우저를 렌더링하고 이를 expect하는 처리를 강구했었다.
다만 이 처리에도 문제가 있었는데, 브라우저에 실제로 렌더링하는 것이 아니기 때문에 분명히 원했던 스타일 그대로 매칭이 안될 수 있다는 단점이 있었고, 직접 확인을 할 수 없으니 동기부여가 잘 되지 않았다.
그러던 중 TDD의 다른 설계버전인 SDD를 보았는데, 스토리북과 컴포넌트를 먼저 작성하고 이를 매 테스트마다 UI를 대조하여 문제점을 확인할 수 있으니 개발자로서 동기부여가 잘 될 것 같았다.
2021.09에는 아하 커넥츠의 서비스 채팅 기능을 개발했는데, 결제를 통해 이루어지는 유료 채팅이다보니 매우 코어한 기능이었다.
당시 아하 커넥츠의 채팅 기능은 샌드버드를 통해 이루어지고 있었는데, 당시 파트너사인 샌드버드가 만들어놓은 번들 파일을 자바스크립트로 포팅하여 기능을 제공하고 있으니 발생할 수 있는 문제가 하나 둘이 아니었다.
1. 늘어나는 고객 수, 멈춰있는 기능 개발
파트너사를 통해 제공받은 기능을 그대로 사용하다보니 번들 코드를 직접 수정하기에 공수가 너무 부담되어 선뜻 기능 개편을 할 수 없었다.
.. 다 갈아 엎었다.
번들되어 난잡했던 코드 번들 파일은 다 제거해버리고 SendBird에서 제공해는 api를 사용해 직접 구현했다.
SendBird의 경우 Socket.io를 통해 채팅 서비스를 제공하고 있었기 때문에 과거에 Socket.io을 통해 카카오톡을 구현해보았던 경험이 크게 작용했던 것 같다.
아하팀?
아하팀에서 개발을 하며 최근에 들었던 생각이다.
다양한 사람들과 다양한 스터디를 하며 기술부채를 직접적으로 맞닥드릴 수 있는 환경에서 일해보고 싶다.
지금 회사는 스터디 환경이 이루어져있고 기술부채에 대한 해결 의지가 낮다.
