1. 시작하며
블로그에 "3년 차 개발자 회고록"이라는 타이틀로 글을 시작하는 날이 오다니 새삼 신기하다.
신입 때 나의 상상 속 3년 차 개발자는 분명 어나더클래스의 실력을 갖춘 미친 퍼포먼스를 내는 사람일 거라고 생각했었다. 하지만 현실은 비교적 능숙하게 힘을 덜 들이며 효율적으로 쳇바퀴를 타는 방법을 터득했다..?라고 느끼는 것 말고는 아직도 배울 것이 더 많은 부족한 사람이다. 물론 능숙하게 쳇바퀴를 타기 위해 2년 넘게 꽤나 치열하게 노력해 왔으니 지금의 상황이 만족스럽기도 하다. 평범함 속에 숨겨진 성실함이 비범한 인생의 조건이라는 말도 있으니까 말이다.
작년과 재작년에 12개월치 회고를 하는 게 밀린 일기를 쓰는 기분이었어서, 올 해는 1~6월까지의 상반기 회고록을 나눠서 써보려고 한다.
2. 업무 회고
- R&D 40% ( 반기 전 대비 10% ⬆️ )
- 신규기능개발 및 기능개선 35% ( 반기 전 대비 5% ⬇️ )
- 팀문화 20% ( 반기 전 대비 5% ⬆️ )
- 반복업무 5% ( 반기 전 대비 10% ⬇️ )
작년에 개발 2년 차로 22년을 마무리하며 365일 동안 쓴 시간에 대해 스스로 평가해 본 적이 있다. 그때와 지금을 비교해 보면 확실히 업무를 함께 할 파트가 꾸려져서인지 팀문화와 R&D에 쓰는 시간이 늘었고, 신규기능개발과 반복업무에 쓰는 시간이 줄어들었다.
1~2년 차까지는 서비스에 필요한 개발자가 되면서도 다양한 경험을 하며 성장하는 게 목표였어서 주어진 시간에 주어진 업무를 완벽하게 해내는 데에만 급급했고, 그 시간 동안 최고의 효율을 내며 성장하고 싶은 마음에 에너지를 쏟아부었다. 그리고 다시 생각해도 그렇게 시간을 보내온 것에 대해 전혀 후회하지 않는다. 그 시기를 보냈기 때문에 서론에 언급한 쳇바퀴를 잘 타는 3년 차가 된 것 같다는 생각이 들기 때문이다.
하지만 올 해에는 나와 함께하는 파트원들도 생겼고, 2년과 3년이 주는 숫자에서의 중압감 차이도 있었다. 그래서 스스로 과제를 바라볼 때 기능적 완성도와 체계적인 진행은 지금까지 꾸준히 추구했던 바이기 때문에 어느정도 익숙해져 디폴트로 했고, 유지보수를 고려한 설계, 기술적인 전파, 프로세스 정리, 더 나은 개발 문화 등에 대한 생각까지 넓게 생각하려고 노력했던 것 같다.
1) Electron Repo 프로세스 만들기 ( feat. 혼자서 하던 일을 셋이 하려면? )
작년 말부터 나 포함 총 3명의 파트원이 Electron (데스크톱 애플리케이션을 구축하기 위한 프레임워크)을 활용한 개발을 함께하게 되었다. 지금까지는 각 팀의 담당자 1명이 맡아서 해 오던 일이었다면, 내가 리드하는 파트에서 담당하게 된 것이다. 혼자서 하던 일을 셋이 하게 되었을 때 가장 먼저 해야 하는 것은 프로세스를 잡는 일이라고 생각했다. 회사 차원에서도 혼자 하던 일을 셋이서 하게 해 준 데에는 당연히 앞으로 이 분야의 일이 몰아닥칠 것을 예고했기 때문일 것이다.
제일 먼저, 존재하긴 했으나 관리되지는 않았던 git branch 를 정리하고 다시 브랜치 전략을 짰다. 가장 보편적으로 널리 쓰이는 방법과, 우리 서비스의 업데이트 프로세스를 적절히 조합하여 파트원들과의 논의 끝에 탄생했다. 위 git flow는 글을 쓰고 있는 현재와는 조금 다르다. 현재는 젠킨스라는 빌드자동화 툴을 활용한 빌드 방식으로 5~6월간 개선하여 변경되었지만, 12~1월에 처음 추진했던 위 흐름과 크게 다르지 않다. 위 흐름으로 merge 하는 과정 속에 codecommit을 활용한 풀리퀘스트도 시도해 보았으나, 대면 리뷰만큼의 효과는 없는 듯하여 현재는 진행하지 않고 있다.
그 외에도 상반기 동안 노드 환경변수를 관리하기 위해 dotenv를 도입하고, 빌드 자동화를 추진하고, 업데이트 프로세스를 변경하는 등의 작업들을 진행하며 프로세스를 잡아왔다. 프로세스를 잡는다는건 다양한 사람들의 의견이 반영되어야 하고 여러 번의 수정 과정도 필요하지만, 결과적으로 현재는 6개월 전에 비하면 각자 다른 개발건을 진행하면서도 체계에 따라 pc앱 업무를 병행할 수 있는 체계적이고 효율적인 구조가 만들어 진 것 같다.
2) 대시보드 프로버전 고도화 ( feat. 구현에만 만족하지 않기 )
3월부터 시작했던 대시보드 고도화 작업이 4개월을 지나 얼마 전 마무리되어 최종 오픈되었다.
시작 당시 프로젝트의 목표는 기존에 타 팀에서 고객사 커스텀 요건으로 만들었던 기존 소스를 리팩토링하고, SSR 처리, 정책 변경건 적용을 최우선 순위로 두고 빠르게 리뉴얼을 마무리한 뒤, 성능적인 고도화까지 진행하고 오픈하는 것이었다. 하지만 중간에 신규 기능을 더 적용했으면 좋겠다는 기획 요건이 추가되어 프로젝트 방향이 변경되었고, 작업 기간이 길어지게 되면서 꽤나 확장성 있는 기능이 될 것 같다는 생각을 하게 되어 구조적인 개선까지 추진하여 장기 프로젝트로 진행되었다.
내가 세운 구조 개선의 주된 목표는 실시간 갱신이었다.
지금까지 우리 서비스에서는 채팅을 제외한 기능에 실시간 갱신을 적용한 적이 없었는데, 앞으로 대시보드라는 기능을 서비스의 얼굴인 첫 메인 페이지에 적용할 것이고, 대시보드 안에 많은 위젯을 추가하며 더 확장시킬 것이라면 지금 실시간으로 수정사항을 반영할 수 있는 구조를 만들어놓아야겠다고 생각했다. 그리고 그 갱신으로부터 부하가 오지 않게 하기 위한 캐싱 구조를 짜고 테스트를 마무리하는 것 까지가 이번 대시보드 고도화의 내 최종 목표였다.
구현 내용을 짧게 요약해보자면 결론적으로는 확장성을 고려하여 위젯 상속 구조와 옵저버 패턴을 적용하여 뼈대를 만들어 놓고, 내부에서는 indexedDB를 통해 프론트 데이터를 관리하도록 만들었다. 그 덕에 추천과 같은 통계성 위젯이나 시시각각 데이터가 변경되는 메모장 위젯 등도 API 호출빈도를 낮추면서도 자연스럽게 보이도록 구현해 낼 수 있었다.
그리고 실시간 처리를 위해 사용한 소켓 서버에 무리가 오지 않도록 실제 서비스 사용 데이터를 토대로 socket io 공식문서에서 추천하는 artillery 를 사용하여 시나리오를 작성하여 부하테스트를 진행했다. 이때 부하 테스트를 진행하기 위해 공부를 하면서 일정하게 유저가 유입하는 환경, 램프업(비율이 점점 늘어나는) 되는 환경, 커넥션만 유지하는 환경 등 다양한 상황을 가정하고 진행하는 방법에 대해 새롭게 알게 된 것 같다.
이번 작업은 실시간작업, 소켓 부하테스트, 베타테스트, 통계 위젯, IndexedDB활용 등 과거에 서비스에서 진행하거나 활용한 적이 없는 새로운 것들의 집합체인 프로젝트여서 쉽지 않았다.. 모두 스스로 제안하고 벌린 일이라 결과 또한 내가 완벽히 내야 한다는 생각에 부담감도 컸던 것 같다. 그리고 지금까지 해왔던 모든 개발건 중에 인프라팀과의 본격적인 협업이 가장 많았던 것 같다. 내가 고려하는 것과 인프라팀이 고려하는 관점이 많이 다른 점도 있어 그 관점을 맞춰나가고 의견을 조율하는 과정에서 배운 점이 많다. 서비스를 개발하는 사람으로서 고려해야 하는 수많은 것들 중 하나이기 때문에 값진 경험이 아니었나 싶다. 결론적으로는 운영상에 큰 이슈 없이 마무리되어 많은 사람이 안정적으로 사용 중인 첫 페이지가 되어 보람 있다.
3) 채팅 통합 검색 ( feat. 원칙을 세우고 개발하기 )
사실 대시보드 작업 시 '구현에만 만족하지 않겠다'라고 마음먹을 만큼 구현 자체에 어려움이 없게 만들어 준 데에는 대시보드 이전 1월에 작업했던 '채팅 통합 검색'이라는 기능의 프론트 구현시 얻은 것이 많았기 때문이다. 더 정확히는 삽질의 삽질을 계속했던 작년 12월의 '업무 리팩토링' 의 도움이 컸다. 물론 그 삽질의 결과는 처참했기 때문에 내 로컬 브랜치 속에 잠자고 있지만 말이다... 내가 그때 삽질을 통해 얻은 수많은 원칙들을 처음 적용해 본 기능이 '채팅 통합 검색' 이라는 기능이었다.
이전까지는 구현 결과 자체에만 신경을 썼는데, 우리 회사의 경우 프론트 프레임워크를 사용하고 있지 않기 때문에 개발 원칙이 꼭 필요하겠다는 생각이 들어 각 기능 개발 전 원칙을 세워서 개발하는 습관을 들이고 있다. 결과적으로는 아직 부족한 점은 많지만 개인의 성장과 서비스의 성장에 둘 다 도움이 되는 시도인 것 같아 올해 동안에는 계속해나갈 것 같다.
4) 담당자 팝업 개선
2월에 엄청난 집중력으로 약 1주일 만에 만들어낸 담당자 팝업 기능이다.. 체크박스로 제어하고 리스트를 확인할 수 있도록 개선된 기능인데, 사실 나도 회고록을 쓰기 전까지는 개선했다는 사실을 잊고 있을 만큼 빠르게 진행하고 배포되었다. 당시 기획자 분이 굉장히 꼼꼼하신 분이었어서 명세서도 명확했고, 나 스스로 예상하고 계획했던 대로 개발이 진행되어 딱히 개발에 어려움도 없어 물 흐르듯 개선한 업무였다. 그래서 쓸까 말까 고민했지만 내 회고록에도 남지 않으면 어디에도 남지 않을 것 같다는 생각에 짤막히... 흔적이라도 남긴다.
5) 업무 리스트 순서 통일 작업 ( feat. DB 맞추기 )
이미 꼬인 DB 데이터의 순서를 바꾸는 로직을 작성하는 상상을 해본 적이 있을까? 언젠가 할 것 같았던 그 상상이 2월에 현실로 일어났다. 문제가 발생한 원인은 정책 자체가 조회하는 화면마다 달랐기 때문에 가 가장 컸고, 그 사이에 개발 및 QA를 진행하는 과정에서 더 꼬인 것도 컸다.
한 번에 업데이트 시 db 부하가 갈 수도 있고, 정확하지 않은 업데이트가 이뤄질 경우 자칫 큰 문제로 이어질 수 있기 때문에 단건으로 사용자가 특정 시점에 진입하는 순간 맞춰주는 로직을 넣어놓는 방법을 택했다. 이후 새로운 수정값들은 하나의테이블만 바라보도록 수정했다. 물리적으로 칼럼값이 블록에 넓게 산재되어 있으면 디스크 I/O가 많이 일어나 조회성능이 나빠지기 때문에 사용하지 않게 된 컬럼은 테이블에서 아예 삭제하는 것이 맞지만, 아직까지는 트리거가 발생하지 않아 맞춰지지 않은 데이터가 남아있기 때문에 진행하지 않고 있다.
6) 그 외
그 외에도 업무 모두 접기/펼치기 기능, 글로벌 서비스 앱 출시 및 업데이트, 네트워크 연결 지연 이슈, 메모리 및 프로세스 연구, 로그 기록 연구 등 다양한 업무를 진행했으나... 모두 쓰기에는 한계가 있으니 이만 줄여야겠다.
3. 업무 외 회고
1) 우당탕탕 리더 되기
나는 개발자라는 직업을 갖기 전 HRD(Human Resource Development)라는 업무를 약 2년 정도 수행했었다. 인적자원개발은 네이버 지식백과의 어휘력을 빌려 설명하자면 "조직의 지속적인 성장과 경쟁 우위를 확보하기 위한 전략적 대안이며, 개인, 집단, 조직의 효율향상을 위한 훈련·개발(조직개발)과 경력개발을 통합한 것으로 계획적이며 조직적인 학습활동"을 의미한다.
과거 직업의 영향인지, 나에게는 '리더'라는 역할이 굉장히 중요하게 인식되어 있다. 누군가는 그저 리더와 팔로워의 관계가 일을 주고 그 일을 도와주는 사람으로 생각할 수도 있고, 선배와 후배 정도 관계의 동료라고 생각할 수도 있고, 프로젝트를 같이 하는 팀원 정도로 생각할 수도 있겠다. 하지만 나에게는 리더는 한 팀의 역량을 결정짓는 존재라고 인식되어 있다. 리더는 누군가의 역량을 폭발적으로 이끌어 낼 수도 있고, 역량을 못 표출하게 억누를 수도 있고, 심지어는 생각의 틀 안에 갇히게 할 수도 있다. 행여 그런 의도를 갖고 있지 않아도, 리더의 말과 행동과 표정과 글에는 그 정도의 영향력이 있다는걸 느낀적이 많다.
진지하게 글이 길어진 게 무색하게 사실 나한테 그렇게까지 막중한 리더의 역할이 맡겨진 것은 아니다. 아마 회사에서 나에게 기대하는 파트리더의 역할은 '주도적 실무자' 로서의 선배의 역할이었을 것이다. 하지만 누군가에게 영향력을 줄 수 있는 역할이 주어진 이상 시간과 에너지를 들여 고민하고 행동해야 하는 것은 당연한 일이라고 생각이 들어 상반기에는 팀빌딩에 많은 시간을 썼다.
리더라는 권한이 주어지게 되었을 때 이 파트를 어떻게 이끌어 가야 하고, 어떤 파트로 만들어야 하는지 굉장히 고민을 많이 했다. 올해 업무에 80%의 시간을 쓰고 20%를 팀 문화에 썼다고 한 데에는 직책의 변화가 그 이유이다.
올해 초에는 연간 파트 계획을 세웠다. 지금까지 우리 회사는 쉴 틈 없이 업무가 휘몰아쳐서 개발자들은 쳐내기에 급급한 문화가 없지 않아 있었고, 그런 상황 속에서 신입 개발자가 본인이 생각하는 개발적 목표나 방향성에 대해 시간을 갖는다는 것이 쉽지 않다고 느껴왔다. 그래서 아무리 업무폭탄이 내려오는 상황에서도, 그 안에서 얻어야 하는 것들과 그 이후에 우리가 해 나가야 하는 것들에 대해 함께 인지하는 과정이 필요하다는 생각에 연간 계획이라는 소재를 활용한 것 같다. 그리고 당장은 힘들고 고되다고 생각되는 업무를 맡게 되더라도 그 업무가 단지 아무나 해도 되는 루틴한 업무가 아닌, 사업적으로나 서비스 전체적으로 얼마나 중요한 일인지, 앞으로는 어떤 방향으로 개선해나가면 좋은 업무인지 등에 대해 알고 있으면 더 주체적으로 할 수 있지 않을까 싶어 이야기하는 자리를 마련했다.
그리고 얼마 전 6월 말에는 상반기에 작성한 목표를 토대로 얼마나 달성했는지 각자 회고하고 공유하는 시간도 가질 수 있었다. '측정할 수 없다면 관리할 수 없고, 관리할 수 없으면 개선시킬 수도 없다.'라는 대학교 1학년 교양수업에서 배운 진부한 말이 이렇게나 실용적인 말인지 처음 알았다.
나는 사실 실무적으로도 인간적으로도 매우 서툰 리더이다.
이것도 해보고 저것도 해보고 싶은 욕심에 일 벌이기 일쑤고, 가끔은 업무적으로 일이 잘 진행되지 않는다고 느낄 땐 감정적인 모습을 보일 때도 있다. 파트원분들은 항상 최고다 행운이다 감사하다 좋은 말은 전부 모아 모아 끌어서 해주시지만, 오히려 그렇게 말해주고 묵묵히 따라와 주면서도 내가 잘못된 선택을 하지 않게 항상 의견을 교류하는 데에 서슴지 않는 흔쾌한 동료들을 만난 나야말로 행운이고 감사하고 과분하다는 생각이 든다. 앞으로 더 좋은 동료이자 리더가 될 수 있도록 노력을 많이 해야 할 것 같다.
2) 사내 코드리뷰 문화 만들기
이전부터 꾸준히 코드 리뷰 문화를 만들고 싶다는 생각을 해왔는데, 드디어 추진했다. 무언가 문화를 만들기 위해서는 왜 필요한지부터 설득이 필요했다.
- 본인이 발견하지 못한 실수를 다른 사람이 발견하여 코드의 Side effect와 오류를 조기에 대응합니다.
- 팀 내 정해진 컨벤션 규칙을 공유/유지하고 기술 부채를 줄일 수 있습니다.
- 여러 명의 개발자가 참여함으로써 문제 해결을 위한 기술 구현 방법론에 대해 공유하기도 합니다.
- 생각하지 못했던 히스토리나 도메인 지식을 전달받을 수 있습니다.
그라운드룰을 만들고 따로 프로젝트를 만들어 공지 후 팀원들을 초대하고 진행했는데, 열심히 참여하시는 분들도 있는 반면, 본인이 먼저 나서서 리뷰를 해달라고 요청하는 것에 아직까진 망설임이 있는 분들도 있다. 하반기에는 체계를 좀 바꿔서 좀 더 접근성 좋게 진행해 봐야겠다.
3) 웹서버개발부 CA (Culture Agency) 선발
조직의 소통과 문화를 리딩하는 역할로 주어지는 CA라는 제도가 새로 생기면서, 내가 웹서버 개발부의 CA로 선정되었다. 우리 개발부의 경우 인원이 많아 2명이 선정되었는데, 실명으로 진행하면 '장소이'라는 사람과 소통하는 기분이 들지는 않을까 싶어 '플로끼'라는 가상의 캐릭터를 만들었다.
상반기에는 개발적인 문화를 바로 진행하기보다는, 일단 개발자들 간 소통이 활발해졌으면 좋겠다는 생각에 '문화의 날', '성장하길 바라' 두 가지를 추진했는데, 꽤 반응이 좋고 친해졌다고 느껴지고 피드백도 참여율도 모두 다행히 긍정적이었다. 하반기에는 리뷰나 세미나 문화를 확대하는 방향으로 진행해 나가면 더 좋겠다는 생각이 든다.
4) 사내 스터디 기획&운영
사내 스터디 문화를 본격적으로 활성화 시켜야 겠다는 생각이 들었다. 플로끼 아이디로 모집을 시작했고 사내 스터디가 총 4개가 개설되었다.
5) '친해지길바래' 문화의날 운영
워낙 조직의 변화도 많고 업무도 바쁜터라 개발자들간의 소통이 많지 않다고 느껴왔다. CA 활동으로 ‘친해지길바래’라는 문화의 날을 만들어 소통의 기회를 늘려주려 노력했다.
6) 개발자 글쓰기 모임 글또 (글쓰는 또라이가 세상을 바꾼다) 8기 활동
1월부터 개발자 글쓰기 모임인 글또 활동을 시작했다. 글을 쓰고 싶은 마음은 굴뚝같지만 항상 미루고 미루는 습관을 고치기 위해 시작했다. 한 번도 패스를 안 쓰고 채워나가는 게 목표였고, 일렉트론을 활용하는 방법에 대한 주제로 글을 쓰고 싶었지만 막상 실무에서 알게 된 내용이가 업무에서 활용하기 위해 공부한 내용들, 혹은 신입분들을 교육하기 위해 만든 자료 등으로 제출을 채워왔던 것 같아 아쉬움이 크다.
스스로 글에 대해 아쉬웠던 것과는 별개로, 글또에서 만났던 커피드백 멤버들은 너무 좋았고, 인사이트도 많이 얻었다. 어느새 만난 지 몇 번 되지도 않았지만 서로를 응원하게 되는 것 같다. (나만 그럴 수도 있다..) 심지어 나는 만나지는 못했어도 열심히 커뮤니티를 이끌어 나가시는 분들을 진심으로 응원하게 되었다. 이전에 나도 단체 커뮤니티를 이끌어 본 경험이 있는데, 그때의 내 모습과는 비교도 안될 정도로 프로페셔널하시고 책임감도 강하시다.
6개월이 벌써 지나서 이번 기수 활동은 끝나지만, 기회가 된다면 다음 기수 활동도 이어서 하고 싶고 더 적극적으로 참여하고 싶다.
7) 스터디 참여
사내 스터디를 꾸준히 참여하려고 노력중이다.
1. 프론트엔드 성능 최적화 가이드 => 완료!
2. 리액트를 다루는 기술 => 진행 중
4. 마치며
개인적으로 인생의 엄청난 경사를 하반기에 앞두고 있어서, 상반기에는 업무와 병행하며 준비하느라 하루하루가 소중하고 빽빽했다. 주위에서는 어떻게 그렇게 맨날 야근하면서 준비를 하느냐고 신기하다고 했지만 개인적으로는 '월~금'의 나와 '토~일'의 내가 완벽히 분리되는 느낌도 들어 오히려 좋았다.
항상 바쁘게 지내는 와중에도 응원해 주는 가족들과 주위 사람들 모두 너무너무 소중하다. 하반기에는 일 뿐만 아니라 주위를 더 챙기는 습관을 들여야 할 것 같다.
올해 하반기도 감동 없는 하루보단 몰입의 하루들로 행복하게 야무지게 채워보자!
'Moment' 카테고리의 다른 글
| 업무의 미로에서 방향 찾기 (3) | 2024.03.03 |
|---|---|
| 3년차 개발자 회고록 (+ 2023년 하반기 회고) (2) | 2024.01.07 |
| 2년차 개발자 회고록 (0) | 2023.02.12 |
| (기고문) 함께 일하기 위한 도구, 협업툴 개발자의 질문 (2) | 2023.01.27 |
| 1년차 개발자 회고록 (2) | 2022.01.12 |
