입사한지 한달이 되어 느낀점들

시간이 정말 빠르게 갔다. 하루하루 코드보면서 머리 싸매고 있으면 금방 일주일이 지나갔다. 개발이란 직종이 만만치 않다는 것을 새삼 느끼게 되었다. 나는 기본적으로 머리쓰는 걸 별로 좋아하지 않는다. 계획세우는 것도 싫어해서 생활을 거의 즉흥적으로 하는 편이다. 그런데 입사하고 하루종일 머리를 써야했다. 코드를 이해해야하고, 새로운 기술을 배워야했다.

기술

사내코드는 js + react(v16), react-native + redux + graphQL 등으로 이루어져 있다. react를 hook기반의 함수형 컴포넌트로만 써본 내게 클래스기반 컴포넌트는 낯설었다. 초반에 구조를 파악하는데 시간이 좀 걸렸다. redux는 redux-toolkit을 써봤기에 어느정도 개념을 알고 있었다. 하지만 redux-saga의 경우 예전엔 비동기처리를 swr, react-query로 했어서 좀 어려웠다. react-native도 기본 컴포넌트들에 대한 학습이 좀 필요했다. 앱 환경에서 ios, android 디버깅, 테스트하는 것에 익숙해지는데도 시간이 많이 들었다.

그래도 모르는건 사수에게 물어보고, 개념적인 건 Docs보면서 코드만 하루종일 보다보니 점점 익숙해졌다. 기본적인 플로우는 react나 react-native나 동일했다. saga는 데이터 비동기처리들을 담당하는 부분이고 익숙해지니 어렵게 느껴지지 않았다. 정리하면 다음과 같다.

컴포넌트에서 action 생성함수를 실행 -> action -> (saga) -> reducer -> state update -> ui update.

데이터 관련된 부분도 문제였다. db가 엄청 많고 db의 column들이 많았다. 프론트도 db구조만 데이터구조에 대해 잘 알아야 했다. 정말 백엔드 지식이 다다익선이라는 말이 괜히 있는 것이 아니었다. 예전에 PM님한테 sql문 강의 들으면서 리마인드 했던게 도움이 되었다. N:M 매핑 개념도 익혔다. product, category가 있을 때 productCategory라는 데이터셋을 만들어 관리를 하는 이유를 알수 있었다.

db의 개념과 더불어 실무적으로도 어떤 테이블들이 있고, 테이블들의 역할은 무엇인지, 컬럼이 무엇을 의미하는지도 지속적으로 사수를 괴롭히면서 배우고 있다. 하나하나 알아갈때마다 수수께끼를 풀기위한 퍼즐이 하나하나 맞춰지는 느낌이다.

태도

어떤 개발자로써의 마음가짐이랄까 태도같은 것도 다시 생각을 하게 되었다. 이전에는 보통 혼자 개발을 했다. 여럿이서 개발을 해도 그렇게 오래 개발한 적이 없었다. 한 서비스를 개발할때, 몇 년 갈 서비스를 개발하는 것이 아니라 코드를 기능개발에 맞춰 유지보수를 생각하지 않고 작성하는 경우가 많았다. 협업에 있어서도 다른 사람들이 잘 알아볼 수 있는 변수명을 짓는다던가, 선언형으로 코드를 짜서 가독성을 높인다던가 하는 부분들이 부족했다.

회사 서비스는 이미 3년이 되었고, 앞으로도 유지보수되어야한다. 그러면서 자연스럽게 협업과 유지보수들에 대해 고민하게 되었다. 변수명이나 효율적이고 가독성있는 코드작성에 있어서 사수와 CTO의 코드리뷰가 도움이 많이 되고 있다. 클린코드에 대해 관심을 가지게 되었다.

개발방식도 예전에는 먼저 코드를 치면서 개발을 시작했다. 하지만 이제는 설계를 하고 그것에 맞춰서 개발하는 식으로 배우고 있다. 첫 주에 CTO, 사수가 태스크를 어떻게 해야하는지 설명해주었다. 현재 다음과 같은 플로우로 태스크가 진행이 되고 있다.

1. 문제파악
2. 문제와 관련된 데이터 파악
3. 현 코드의 로직 파악
4. 현 코드의 문제점 파악
5. 변경 로직 설계
6. 코드 변경
7. 사이드이펙트 여부 테스트 및 기존 데이터 테스트
8. 코드 리뷰
9. 코드 반영

한달의 시간이 지났지만 코드를 작성한 시간은 적다. 코드를 읽는데 대부분의 시간을 썼다. 한 주 동안 기존 코드보고 로직 파악하는데만 시간을 쓴 적도 있었다. 태스크에 따라 1~4번의 과정조차 어렵다. 5번도 어렵다. 변경로직이 올바른 방향인지도 지속적으로 질문해야 했다. 사실 모든 과정에서 되도록 질문을 하고 진행과정을 보고하는 것이 맞다고 느끼는 중이다. 사수가 질문을 많이 하라고 했던 부분이 이런 부분이 아니었을까 한다.

나는 대충대충하는 성향이 강한 편이라 정말 조심하면서 코드를 쓰고 있다. 코드 실수해서 UI오류가 나면 직접적으로 고객에게 피해가 가기 때문에 더 조심하게 되는 것 같다. 개발팀은 팀적으로도 개인적으로도 신중하게 작업을 해야한다는 것을 잘 느끼고 있다.

배포 및 테스트

코드 외적으로도 배우는 점들이 있다. 우리 회사는 앱을 한 주에 한번정도로 업데이트를 하는데, 이 배포주기에 맞춰 태스크를 진행한다. 배포 전 테스트, 배포 후 cs 반영 등 소프트웨어 개발의 사이클을 경험하고 있다. 예전에 LoL할때, release노트라고 하면서 패치노트 나오고 버그 생기면 바로 핫픽스하던게 생각났다. 그 과정을 새삼 경험하면서 아... 쉽지 않구나 라고 느끼는 중이다.

cs를 반영해서 개선된 앱을 배포한다. 배포 이전으로 테스트를 아주 꼼꼼하게 진행하고 버그 수정을 한다. 치명적인 버그가 있지 않은 한 배포를 미루는 법은 없기 때문에 개발자들이 신경을 많이 쓰게 된다. 배포 이후에도 운영팀에서 새로운 cs가 들어오면 그것을 고쳐야한다. 새로운 기능 개발 + 기능 테스트 + 테스트 리스트 작성 + 버그 수정 등 개발자들이 하는 일이 많다.

앱의 테스트량도 만만치 않지만 버그의 발견도 쉽지 않다. 버그를 수정한다고 해서 사이드이펙트가 없을 거라는 100%보장도 되지 않는다. 버그 자체에 대한 적확한 리포팅(재현)도 쉽지 않은 경우가 있다. 완벽한 배포라는 것은 있을 수가 없다. 개발자들은 완벽을 추구하면서도 그 불완전함에 익숙져야하는 듯 하다.

앞으로

새로운 태스크를 받을때마다 하나의 도전을 하는 느낌이다. 복잡한 로직 설계를 하다가도 데이터 쪽 변경을 해야할때가 있고, 새로운 기능을 추가해야하는 경우가 있다. 최근 블루투스 영수증 프린터 기기에 js로 영수증 내용을 인코딩해서 통신하는 부분을 코드로 보게 되었다. 나는 사실, 블루투스도 잘 모르고 LAN이나 wifi도 잘 모른다. 영수증 프린터의 하드웨어적인 부분도 잘 모른다.

api를 이용해서 js로 영수증 프린터와 블루투스 통신을 하는 점이 신기했다. 그리고 태스크를 완료하고 프린트에 내가 원한 내용을 출력하게 했을때 재미를 느꼈다. 조금씩 새로운 것을 배워나가는 것은 힘들지만 재밌다. 그런 점이 적성에 맞는 것 같다. 뿐만 아니라 버그를 수정하고 사용자의 불편사항을 하나 해결했다는 생각이 들때 뭔가 뿌듯하면서 보람이 생겼다.

앞서 말했다시피 커다란 수수께끼를 푸는 기분이다. 하나하나 풀어갈 때마다 성취감이 있고 그 과정이 즐겁다. 언젠가 이 수수께끼에 익숙해진다면 직접 큰 소프트웨어를 설계하고 개발해보고 싶다.

회사갔다오면 개인공부할 여력이 없다… 정말 체력이 중요하다.