현재 회사에 풀스택 개발자로 입사 후 3년이 지나 올해로 4년 차가 되었고, 그 사이에 팀장이라는 직책도 임명받았고 얼마 전에는 연봉협상도 진행되었다. 언제나 그렇듯 연봉협상을 하면 회사 분위기가 뒤숭숭하다. 아무래도 경기가 안 좋은 요즘 같은 상황엔 누구나 만족할만한 연봉 인상률이 나오긴 힘드니, 열심히 달려왔던 동료들의 동기부여가 줄어든 모습이 많이 보인다.
이번 인사평가때는 처음으로 누군가를 평가하고, 그 평가가 누군가의 연봉 인상률에 영향을 미치는 경험을 하게 되었다.
나는 입사 후 지금까지 매년 해가 넘어가는 이 시즌에는 모든 업무프로젝트들과 내 활동에 대한 회고를 정리하곤 했고, 그 회고는 겸사겸사 평가를 위한 자료로도 쓰이곤 했다. 그래서 이번에도 팀원들에게 본인이 본인을 회고하는 시간을 가져보길 권장했다. 내가 그랬던 것처럼 말이다.
나는 항상 회고를 쓸때마다 '진짜 회사생활에 몰두해서 살기는 했다.'라는 생각으로 가득 차있었다. 그리고 자연스럽게 내가 생각했던 좋았던 점과 아쉬웠던 점을 써 내려가는 동안에도 '아쉬웠던 건 많지만 내년에 보완하지 뭐!' 라든가, '이 정도면 열심히 살았으니 나쁘지 않은 1년이네!'라는 식의 마냥 긍정으로 가득 찬자기 위안을 자주 했던 것 같다. 사실 나에겐 하고 있는 일 그 자체를 위해 내가 보내는 시간의 가치, 혼자가 아닌 팀이 만들어내는 결과, 그 결과인 서비스가 고객에게 주는 가치 등 본질적인 부분에서 오는 동기부여가 더 크게 작용한다. (물론 그 가치와 금전적인 부분은 양의 상관관계에 있을 거라 생각하는 것도 사실이다.) 그렇기 때문에 자연스럽게 평가라는건 남들이 주는 평가보단 사실 본인이 본인을 돌아봤을 때 스스로에게 내리는 평가가 훨씬 중요하다고 생각해 왔던 것 같고, 본인이 만족할만한 결과를 냈고 그 결과가 가치 있다고 평가했다면 그것으로 족하다고 생각했다.
하지만 다른 사람의 회고를 보고 평가해야할 때가 오니 그렇지 않았다. 특히 내가 리드를 해야 하는 우리 팀의 회고를 볼 때는 더더욱 그렇지가 않았다. 내가 어찌어찌 뛰어다니고 헤쳐나가며 닦아 나가고 있는 길을 뒤따라 묵묵히 따라오고 있는 팀원들의 고생을 보고서 '길이 꽤 꼬불꼬불했지만 결국 열심히 따라 걸어왔으니 잘 했어요! 내년에도 파이팅!'이라고 관전하며 결과만 보고 응원하는 리더는 되기 싫으니 말이다. 적어도 어떤 길에 들어설지에 대한 결정권을 갖고 있는 나로서는 이 길을 함께 더 잘 걸어 나가기 위한 방법도 모색하고, 더 나은 신발과 도구와 탈 것과 하다못해 물이라도 마련할 의무가 있다고 생각한다. 그리고 잘 따라오지 못한다면 따라오기 위해서 어떻게 해야 하는지에 대한 팁도 전수할 의무가 있을 것이다. 그래야 더 멀리 갈 수 있을 거라고 생각한다.
그래서 이 글이 탄생했다.
'어쩌다 보니 열심히 지냈고 이만큼이나 해냈으니, 내일도 열심히!' 라는 낙관적이고 두리뭉실한 피드백과 가이드를 팀원들에게 주고 싶진 않았다. 그리고 어찌 보면 그 '팀원'에는 나도 포함이다. 나도 이제는 알고는 있었고 지키려고도 노력했지만 진짜 지키고 있는지, 나를 바라보는 더 객관적인 시야가 필요하다고 느끼기도 했다. 이 글을 쓰기 위해 내 상급자이신 부장님과 CTO 님과도 면담하며 이 길을 더 오래 걸은 분들은 어떻게 하면 좋은 길을 걸을 수 있다고 생각하는지에 대한 인사이트를 얻어내려고 평가면담의 탈을 쓴 물음표 살인마가 되어 수많은 질문을 던졌다. 감사하게도 정말 많은 인사이트를 얻어 내 생각을 정리할 수 있게 되었다. 이 내용이 내년에는 바뀔지도 모르겠지만, 적어도 올 해를 가이드하는 나침판이 되어줄 수는 있을 것 같다.
✔️ 5가지 유형별 방향성
우리 팀은 풀스택으로 일하고 있고, 운영과 개발에 대한 롤이 나누어져 있지 않다보니 한 사람이 하는 1년의 업무를 모아보면 정말 다양하고 다채롭다. 그만큼 넓은 범위의 업무를 맡고 있는 팀의 특성상 각 프로젝트에 맞는 방향성이 다를 수 있다는 생각이 들었다. 일단 각 프로젝트들은 어떻게 분류되고, 어떤 목적을 가지고 있는지부터 정의하는 일이 필요했다. 그렇게 5가지의 유형으로 분류해 보았다.
1. 오류해결
말 그대로 오류 해결이다. 보통은 QA 과정이라고 하는데, 우리 조직의 경우엔 계속해서 유관부서를 통해 오류가 등록되는 시스템이기 때문에 정기배포를 통해 오류를 해결하고 수정하여 주기적으로 반영하는 업무를 병행하게 된다.
✅ 근본적인 해결과 즉시적인 해결 양쪽 모두에 대한 고려가 되었는지
✅ 도메인 지식으로 인한 누락이 있는지 동료와의 크로스체크( 코드 리뷰 요청 👬 )
✅ 사이드 이팩트 확인
오류 해결을 계속해서 하다보면 '근본적인 해결'과 '즉시적인 해결'에 대한 고민을 하게 되는데, 이럴 땐 상황의 위급성과 해당 도메인의 확장성 등을 모두 고려해서 개발자 스스로 판단을 해야 한다고 생각한다. 대신 그 도메인에 대한 지식이 조금 더 풍부한 동료라던지, 다른 시각을 가지고 있는 동료로부터의 피드백과 크로스 체킹이 따라오면 더 좋은 것 같다. 또한 본인이 작업한 코드가 쓰이고 있는 다른 영역에서도 사이드이펙트를 일으키지는 않는지 확인이 필수적이다.
2. 운영업무
운영업무라는 단어로 표현될 수 있는 업무는 정말 많다. SaaS 데스크탑용 PC앱 업데이트, 서버배포, 엔터프라이즈 및 글로벌 서비스 업데이트 지원, 기업 문의, 커스텀 요건 개발 가능여부 검토, 현상 확인 및 해결 요청, 원격 지원, 담당 도메인 관련 개발자 문의 등 대부분은 루틴한 배포와 업데이트 혹은 타인의 불편과 궁금증을 해소하기 위한 대응 업무를 포함한다.
✅ OS 와 버전, 고객사 보안특이사항, 브라우저 환경 등 환경적 케이스에 대한 이해와 처리
✅ 100%의 오류해결이 어려운 경우, 문제를 해결하기 위한 제시
✅ 이슈케이스 공유 ( 환경으로 인한 이슈 케이스는 히스토리 적재가 필수 )
✅ 수정 및 테스트, 배포 일정 관리
루틴한 배포와 업데이트더라도, 기업용 SaaS 서비스를 운영하다 보니 다양한 기업의 보안정책과 환경에 따라 문제가 발생하는 경우가 많다. 그럴 때는 내부에서 현상이 파악되지 않기 때문에 어떤 환경에서 우리 서비스에 영향이 있는지, 그 문제를 해결하려면 어떤 조치를 취해야 하는지 개발자가 직접 나서야 하는 경우도 많다. 특히 우리 팀의 경우엔 웹과 서버뿐만 아니라 일렉트론을 활용한 PC 앱 개발과 업데이트에 대한 롤까지 맡고 있기 때문에 운영체제에 대한 이해도 필요하다. 그리고 그러한 환경에 대한 이슈케이스는 또 다른 팀원의 시간이 낭비되지 않도록 공유하는 일도 중요하다. 그리고 최종적으로 수정 내용이 반영되는 날짜도 보통은 개발자가 먼저 제안을 하고 배포를 진행하기 때문에 일정 관리도 필요하다.
3. 기능개발
우리 서비스의 경우 고객사의 커스텀 요구도 매번 감사하게도(?) 많으면서도 다채롭고, 해외 진출을 위해 서비스도 계속해서 성장시켜 나가고 있다보니 신규 기능 프로젝트, 기능개선 건 프로젝트가 매번 쉴 틈 없이 빠른 속도로 진행되곤 한다. 그리고 보통은 1개의 프로젝트에 2명 이상의 개발자가 배정될 확률은 희박하다. 그렇게 되면 앞서 설명한 1번, 2번과 뒤이어 나올 4번, 5번에서 업무 누락이 발생하거나 팀에 오버플로우가 발생할 수 있기 때문이다. 따라서 기능개발 프로젝트를 맡은 개발자는 신입이라 할지라도 A부터 Z까지 책임지고 이끌어가는 능력이 요구된다.
✅ 작업 전 정책상 / 개발 구조상 불가능하거나 누락이 있는지에 대한 크로스체크 & 기획팀과의 조율
✅ 작업 전 설계 중 누락이 있는지에 대한 개발팀 내 크로스체크 ( 설계 리뷰 요청 👬 )
✅ 유지보수성을 고려한 설계 및 작업 ( 모듈화, 재사용성 등 )
✅ 서버 부하테스트
✅ 기본적인 정책 및 요건 충족
✅ DB cost 고려 (인덱스처리)
✅ 예외 처리 & 다국어 처리
✅ 기능 테스트 및 사이드이펙트 체크
✅ 일정 조율 및 관리
풀스택 답게.. 기획 검토에서부터 설계, 쿼리, cost 비교, 인텍스 처리, 서버작업, 부하테스트, 프론트엔드 백엔드, 예외처리, 다국어 처리, 마지막 병합 및 배포까지 모든 걸 본인이 진행해야 한다. 당연하게도 혼자서 이 모든 일을 신입개발자가 판단해서 진행할 수는 없기 때문에 주위에서 도와주고 검토해 주며 진행하고 있는 분위기이다. 그리고 연차가 쌓이더라도 이 모든 부분을 혼자서 잘하기 쉽진 않아서, 조금이라도 특정 부분에 더 경험이 있는 사람들에게 조언을 구해가며 성공적인 결과를 내기 위해 스스로의 작업을 리딩해나가는 책임감이 굉장히 중요하다.
4. 장애대응
SaaS 서비스의 프론트/서버/DB/인프라에 걸친 모든 긴급 이슈, 엔터/글로벌 앱 관련 이슈는 SaaS개발부의 모든 개발자가 신경 써야 하는 부분이다. 누가 언제 만든 기능인지 파악해 가며 요청하기에는 정말 긴급한 경우가 많기 때문이다.
✅ 빠른 선조치 자세한 후분석
✅ 장애보고서 작성
✅ 근본적 해결을 위한 자세한 연구
✅ 원인과 해결 방법에 대한 공유 및 전파
보통은 2번 운영을 담당하는 사람이 이 장애 대응에도 더 많은 시간을 쓰게되고 선조치를 하게 된다. 하지만 보통은 장애의 원인이 타인인 경우가 많아서, 분석은 원인 제공자와 함께 하면서 근본적인 해결을 고민한다. 이 과정에서 빠르게 선조치를 하는 건 어떻게 보면 경험이 쌓여야 하는 부분이기도 하다. 하지만 근본적인 해결을 위한 연구나 제시, 그 방법에 대한 공유와 전파는 개발자라면 그 누구라도 시간을 써서 할 수 있는 부분이라고 생각한다.
5. 고도화 / 성능개선 / 기술개선
✅ 비효율적이던 방식을 얼마나 효율적이게 했는가✅ 기존의 어떤 문제를 왜 얼만큼 해결했는지 측정
✅ 고객 혹은 개발팀에게 어떤 가치가 있는가
말 그대로 고도화나 자동화, 프로세스 개선, 성능개선, 테스트툴 도입 등의 목적은 '상황의 개선'에 그 목적이 있다. 그렇기 때문에 비효율적이던 방식을 얼마나 효율적으로 개선했는가, 얼마만큼 해결했고 어떤 가치가 있었는가에 대한 측정이 필요하다. 이러한 과제는 보통 누군가가 주어준다기보다는 '아 이런 건 좀 불편한데?', '이 부분은 자동화가 가능하겠는데?' 라던지, '이렇게 하면 개발 생산성이 높아지겠는데?' 라는 개인의 불편함과 팀의 불편함에서부터 시작되는 경우가 많다. 어찌 보면 가장 난이도가 높고 현실적으로 실행되기 어려운 부분이지만, 회사차원에서 꼭 필요하다고 생각할만한 영역이라고 생각한다.
✔️ 모든 프로젝트에 공통적으로 적용해 볼 수 있는 3가지
지금까지는 프로젝트의 유형별로의 목적과 체크할 부분을 봤다면, 모든 프로젝트 과제에 공통적으로 적용할 수 있다고 생각하는 3가지에 대해서 작성해보았다. 어찌보면 '필수적'이지는 않으나, 내가 조금만 더 신경 쓰면 '더 나은 프로젝트가 되게 할 수 있는것들' 에 가깝다고 볼 수 있겠다.
1. 리뷰 & 보고 & 회고
🚀 사전에 팀원, 팀, 협업 부서 등에게 리뷰를 요청하여 더 나은 설계하기
🚀 진행중에 상급자에게 상황을 잘 보고 하기
🚀 완료후엔 누락된 부분이나 고려해야 할 부분이 있는지 점검하고 회고하고 보완하기
위에서도 언급했지만, 사실 내가 하는 것 같아 보이는 일 중에 나 혼자 완성되는 일은 하나도 없는 것 같다. 사전에 누군가의 리뷰를 통해 더 나은 설계가 탄생하고, 진행 중엔 상황을 잘 보고함으로써 프로젝트의 진행상황이 유관부서와도 잘 소통되고 관리되게 할 수 있고, 완료 후에도 출시된 기능을 보며 로그를 분석한다던지, 맹점을 파악한다던지, 데이터 통계를 내본다던지 등의 회고를 통해 더 완벽한 결과로 재탄생하기도 한다. 어찌 보면 이러한 점이 개인 프로젝트와 회사 프로젝트에서 배울 수 있는 점의 가장 큰 차이가 아닌가 싶고 팀의 존재 이유라고 생각한다. 숱하게 말하는 '회사와 나의 동반 성장'이라는 이상적인 것 같은 단어는 이런 디테일한 행동과 습관을 통해 현실이 되는 것 같다.
2. 정리 및 전파
🚀 내가 쓴 글은 남이 읽어도 도움을 받을만한 글인가? 고민하기.
🚀 내가 쓴 글을 언제든지 남들이 쉽게 읽을 수 있게 공유하기.
개발 문서가 '잘 정리되었다' 는 것은 단순히 개발 경험을 일기처럼 작성한 것이 아니라, 내 작업을 이어갈 다른 사람이 코드를 살펴보기 전에 정리된 내용을 확인함으로써 전체적인 흐름과 중요한 정보를 빠르게 파악하고 이해할 수 있도록 가공하는 것을 의미하는 것 같다. 그리고 그 글이 공유되고 전파되지 않으면, 그 경험은 그저 한 사람의 경험일 뿐이다. 남을 위한 글을 쓰는 연습을 통해 더 영향력 있는 사람이 되어보자.
3. 진행이 주체적이었는가?
개발자가 된 이후에 대기업을 경험해본 적은 없지만, 스타트업~중소기업 그 어디쯤에 있는 나의 상황에서 비교적으로 좋다고 생각하는 점은 주니어 개발자인데도 작고 큼직한 프로젝트를 모두 주체적으로 이끌 수 있다는 점이다. 정해진 기획이라고 해서 무조건 따라야 한다는 법은 없고, 더 나은 방향과 의견을 언제든지 제안하고 실행시킬 수 있다. 배포의 시기도 오픈의 방법도 모두 마음만 먹으면 나의 의견이 개입된다. 하지만 그 주체성을 잃는 순간, 누군가의 의견에 수동적으로 끌려다니기 쉽다는 단점도 있다. 내 시간이 단순히 '채워졌다'가 아닌 '채웠다'로 남겨지길 바란다면 모든 프로젝트에 주체적으로 참여하려는 자세가 필요한 것 같다.
사실 개인적으로 나를 돌아보면 아직 아는 것보다 모르는게 비교도 못하게 더 많다고 생각하는 주니어 개발자이자 신임팀장인데, 이런 개인의 의견을 토대로 한 글을 벌써 써서 공유해도 되나 고민도 했었다.
하지만 서두에서 언급했듯이 부족한 나를 이미 따라오고 있는 사람들도 있고, 짧고 별거 없는 길이더라도 그 길을 더 잘 걸어왔으면 하는 바람에 써보았다. 그리고 이왕 쓴 김에 우리 팀원들뿐만 아니라, 수많은 서비스를 위한 프로젝트에 허덕이며 내가 대체 뭘 하다가 n년차가 된 거지.. 싶은 주니어 개발자분들도 이 글을 보면 공감도 하고 도움도 받고, 반대로 내 글에 대한 피드백도 받을 수 있지 않을까 싶어서 용기 내어 올려본다! 🙏🏻
'Moment' 카테고리의 다른 글
| 4년차 개발자 회고록 (혹은 작업기록) (2) | 2025.01.05 |
|---|---|
| 3년차 개발자 회고록 (+ 2023년 하반기 회고) (2) | 2024.01.07 |
| 3년차 개발자 회고록 (상반기) (0) | 2023.07.16 |
| 2년차 개발자 회고록 (0) | 2023.02.12 |
| (기고문) 함께 일하기 위한 도구, 협업툴 개발자의 질문 (1) | 2023.01.27 |
