새해의 1월 하고도 12일이나 지났다. 회사에서 한 달 전부터 준비해온 22년 첫 업데이트를 무사히 끝내고 퇴근한 지금에서야 겨우 '아, 회고록!' 하고 마음을 다잡으며 키보드를 두드리게 된 나를 보니, 개발자로서의 이번 1년은 "눈코 뜰새 없었다."라는 표현이 참 어울린다. 이 글을 쓰고 있는 순간에도 '다음 개발건 쿼리 쪽 어떻게 개선하지? 일정 산출은 어느 정도로 하지?' 등의 수많은 물음표가 머리를 채우고 있으나, 최대한 걱정은 비우고 지난 1년을 차분히 되돌아보려고 한다.
시작하며
올해에는 정말 많은 일이 있었다. (1월이 되어버렸지만 몰입을 위해 올해라고 하자.) 정말 정말 많이 배웠고 많이 성장했다. 하지만 그보다 아직 아쉬운 점, 부끄러운 점이 너무나도 많다. 이렇게 스스로 부족함을 느끼는 내가 회고록을 블로그에 남겨 기록한다는건 부끄럽다고 생각했었고 개인 노션에만 적어놓고 일기처럼 덮어놓을 생각이었다. 그럼에도 불구하고 이렇게 남기게 된 이유는 개발자들의 회고록을 모아놓은 깃헙을 보다가 서두에 쓰인 글을 본 이후 생각이 조금 바뀌었기 때문이다.
아무것도 남기지 않으면 아무것도 남지 않을 것입니다.
회고는 자신 또는 팀을 위한 것이지만 나눌 때 그 가치가 더욱 커집니다.
특히 앞서서 길을 걷고 있는 개발자의 회고는 비슷한 길을 따르고 있지만 아직 경험이 적은 개발자들에게 수확 없는 삽질을 줄여주고, 존재조차 몰랐던 이정표를 제시해줄 것입니다.
내가 개발을 처음 시작할 때만 생각해보아도, 불안함 반 걱정 반으로 앞선 길을 걷고 있는 개발자들의 글을 많이 읽었던 것 같다. 하지만 얼마전 팀내 주니어 개발자들중에 가장 눈에 띄는 성과와 열정을 보여주고 있는 것 같다는 피드백을 받았고, 1년전과 비교했을때 조금이나마 성장했다는 생각이 들었다.
그래서 지금의 배움과 성장과 아쉬움과 부끄러움을 모두 기록해보고자 한다. 그리고 미래에 누군가 나와 같은 처지에 있는 이가 이 글을 시작으로 내 흔적들을 읽을 때 '아, 나만 이런 생각을 한 게 아니었구나.' '나도 이 사람의 길을 걸어보면 어떨까?' '이런 경험을 하는 사람도 있구나.'라는 생각을 했으면 좋겠다. 내가 하는 지금의 생각들과 내가 겪은 경험을 적어놓은 이 글이 위로와 용기와 간접경험과 공감 중 어느 하나라도 내어줄 수 있는 글이었으면 좋겠고, 나 스스로에게도 나중에 돌아봤을때 성장의 동력이 되길 바라며 회고를 시작해보겠다.
개발자로서의 첫 회사생활 요약
들어온 지 얼마 되지 않아 감사하게도 바로 개선/신규 개발 건들을 맡게 되었고, 리뉴얼 프로젝트에 바로 투입되어 서비스 전체 리뉴얼을 진행하며 서비스 전반을 파악할 수 있는 기회를 얻었다. 게다가 1년이 지난 지금은 회사가 급성장한 덕에 개발 인원이 배로 늘어났고, 일부 영역에 있어서는 주도해서 진행할 수 있는 기회도 주어졌다.
"눈코 뜰새 없었다."라는 표현으로 이 포스팅을 시작했으나 사실은 모두 감사한 기회를 얻은 덕분에 "꽉 채워졌다."라고 표현하는 게 더 어울리는 표현인 것 같다.
회사생활 - 업무
1. 어드민 사용자 조회 기능 개발 (11월)
입사 후 처음으로 약 3주 만에 만든 기능이다. 선배 개발자분이 필요하지만 일정에 의해 만들어지지 못한 기능들을 리스트업 해놓으셨고, 입사 동기 개발자들과 하나씩 나눠서 개발을 진행하게 되었다.
- 배경 : 기획-디자인-퍼블의 모든 과정이 생략되어있는 '있으면 좋을 것 같은 기능'만 적혀 있는 과제였다.
- 행동 & 배운 점 : 처음에는 막막했으나 앞 작업이 안되어있던 게 오히려 좋았다. 왜 우리 서비스의 어드민에서 이러한 기능이 필요한 지부터, 그럼 어떻게 표현해야 사용성이 높아질까, 유저 정보를 가지고 있는 테이블은 어떤 것들이 있고 어떠한 구조인가, 전체적인 프론트/백 로직은 어떻게 구성되어있는가 등의 서비스 및 개발의 전반적인 부분에 대해 고민해보고 파악할 수 있는 기회였다. 특히 사용자 관련 기능을 맡았다보니 서비스의 시작이라고 볼 수 있는 유저 정보의 암호화 방식이나 DB 테이블 구조를 파악하기에 좋은 기회였다. 처음에는 유저의 기본 정보만 조회 가능한 기능으로 개발을 시작했으나, 몇 번의 피드백과 첨언을 통해 해당 유저가 어떤 기기로 언제 로그인을 했었는지, 서비스 내에서 관리자인지 일반 사용자인지 등의 상세 정보까지 모두 조회할 수 있는 기능으로 디벨롭하였다.
- 결과 : 1년이 지난 지금 그 기능은 실제 내부 cx팀에서 고객 오류가 접수되면 바로 응대하기 위해 검색하는 데에 유용히 쓰고 있다고 한다. 이때 이후로 어드민보단 실제 유저들이 사용하는 서비스 개발만 작업하느라 유지보수는 신경 쓰지 못했다. 다음에 기회가 되면 불편한 점은 없었는지 내부적으로 물어보고 조금씩이라도 디벨롭해야겠다.
2. 채팅 로직 개선 (12월)
입사 2개월차에 채팅 로직 개선 업무를 받았을 때, 기존에 회사에 계시던 개발자분들이 모두 '벌써 그쪽을 봐? 어려울 텐데..'라는 반응을 보였다. 그도 그럴 것이 고질적인 문제로 항상 언급되던 '채팅 읽음 처리'를 개선하는 업무였기 때문이다. 사실 주위에서 아무리 그렇게 이야기해도 당시의 나는 '어떤 업무를 받는다 한들 어차피 나한텐 새롭고 낯설고 어려운 건 마찬가지겠지..'라고 생각해서 겁도 없이 해보겠다고 덤볐? 던 것 같다. 그리고 채팅 쪽을 담당하시는 사수님을 만나 받게 된 첫 업무이니, 잘 해내서 짐을 나누고 싶은 마음뿐이었다.
- 배경 : 채팅 메시지 옆 읽음 카운트가 실제 읽은 사람의 수와 맞지 않는 이슈, 나중에 읽은 채팅보다 먼저 읽은 채팅의 '읽지 않음' 수가 더 높은 오차현상 등이 일어나지만 정확한 원인 파악이 되지 않는 상태였다.
- 행동 : 일단 우리 채팅서비스를 사용하며 일어날 수 있는 모든 케이스를 리스트화 했다. 그러다 보니 기존 로직의 허점이 조금씩 보이기 시작했다. 예를 들면 채팅창을 켜놓긴 했지만 설정창이나 검색창 등 내부의 팝업을 켰기 때문에 읽고 있는 것으로 간주하면 안 되는 경우. 너무 오랫동안 읽지 않아 몇십 개가 쌓여있는 톡방에 들어갔을 때 화면에 그려져 있는 것만 읽음 처리하게 되는 경우. db에서 순차적으로 읽음 처리가 끝나지 않았는데 카운팅 조회 후 클라이언트에서 그려버리는 경우. 실시간 처리일 때와 아닐 때 다른 로직을 타는 경우 등등이 있었다.
- 배운점 : 그 모든 케이스를 고려하여 완전한 처리를 구현해낸다는 게 사실 입사 2개월 차에 업무파악도 못하던 병아리 신입에겐 정말 혼돈 그 자체 었다. 기존 코드를 개선하는 게 새로 만드는 것보다 훨씬 어렵다는 말을 왜 하는지 너무나 이해가 가는 기간이었다. 하나를 생각하면 두 개를 더 생각해야 하고 두 개를 생각하다 보면 네 개를 더 생각해야 하는 업무의 무한루프를 경험했다. 하지만 어렵게 느껴졌었던 소켓통신도 이때 적응하게 되었고, 실시간 처리에서 발생할 수 있는 순차처리라던지 유실 등에 대해 더 고려해볼 수 있는 기회였다.
- 결과 : 적어도 사용자 입장에서 느낄 수 있는 케이스에 대한 대응은 어떻게든 해냈다. '내가 못해서 더 어렵게 느껴지는 거겠지'라고 나의 부족함을 탓하며 더 매달려서 했던 것 같다. 하지만 여전히 그 부분은 매우 아쉽다. 어떻게든 개선했으니 물론 이전보단 나아진 상태인 것은 맞다. 그러나 그때 당시에 작업했던 것들은 근본적인 원인 해결이 아닌 방어 로직도 많고, 코드 자체가 마치 소설처럼 절차 지향적으로 구성되어있어 다른 개발자분들이 유지보수를 시도한다면 내가 투자한 만큼 (2~3주)의 분석기간이 필요하다. 물론 첫 작업이니 기존 개발자분들의 로직에 손을 크게 대지 않고 싶은 마음도 있긴 했으나, 이왕 손대는 김에 또 다른 개발자들에게도 보기 쉬운 코드로 리팩토링했다면 좋았을 것 같아 올해 안에 보수가 매우 필요하다.
3. 데스크탑 설치형 네트워크 연결 오류 개선 (1~2월)
우리 서비스는 데스크탑에 설치하여 사용하는 설치형도 운영 중이다. 대부분 회사에서 사용하기 때문에 재부팅 시 자동 실행이 가능한 설치형을 사용하는 경우가 많다. 하지만 웹에서의 서비스 과는 다르게 사용자의 운영체제나 pc설정 환경, 보안에 따라서 영향을 많이 받는다. 그중 하나가 설치 시 아무런 동작 없이 '흰 화면'이 뜬다는 이슈였다.
- 배경 : 내부에서는 재현이 되지 않으나, 일부 사용자들에게만 서비스가 '흰 화면'으로 보인다는 이슈가 지속적으로 발생했다. 간단하게 로딩을 하지 못하는 경우라고 생각하고 업무를 받았으나 재현이 되지 않아 꽤나 골치 아픈 업무였다.
- 행동 : 일단 증상 원인파악을 위해 고객 원격 지원을 밥먹듯이 했다. 사실 타사에서는 개발자가 직접 원격지원을 하는 경우가 얼마나 많을지는 모르겠으나, 나의 경우엔 재현되지 않는 오류의 경우 증상과 log파일과 pc설정값, 다른 보안 프로그램이 깔려있는 건 아닌지 등을 직접 확인하고 싶어서 원격지원을 바로바로 요청하는 편이다.
직접 확인해보니 내부망을 사용하여 외부 서비스가 막혀있는 기업도 있었고, 설치형 vpn을 사용하는 기업들, 웹 vpn을 사용하는 기업들, 네트워크가 연결되지 않았을 때 앱이 먼저 켜지는 경우, 로그인 페이지에서 사용되는 sns api의 권한이 해당 기업에서 막히는 경우 등의 다양한 케이스를 발견해낼 수 있었다.
결과적으로는 모두 네트워크 이슈였기 때문에, 각 네트워크 이슈 발생 시 고객에게 케이스별로 확실한 noti를 표현하는 방식에 대해 기획팀에 건의하여 원하던 방식으로 개발을 진행했다. 에러 여부를 ERR_INTERNET_DISCONNECTED로만 체크했던 로직도 네트워크 관련 에러가 상세하게 포함되도록 추가하고 관련 문구가 노출되도록 추가하였다. 또한 기존에는 navigator.onLine 만 사용하여 서버 응답이 가능한 상태가 아니어도 online상태로 로직을 시도해서 오류가 발생하였다. online을 체크하는 방식을 2단계로 늘렸고, 로딩에 실패할 경우 새로 기획된 팝업과 2차 체크 로직을 연결시켜 5회 재시도를 클릭하면 수동으로 사용자가 연결을 재시도할 수 있도록 구현하였다.
- 배운 점 : 입사한 지 몇 달 안된 신입 개발자가 기획팀장님께 기능 정책을 요청하고 세부요건을 요청하는 게 괜히 오지랖이 될 수 있다는 생각에 그냥 '고객님 회사 보안 때문입니다.' 답변만 주고 넘길까 고민도 했었던 것 같다. 하지만 '반복되는 오류접수가 있고, 그 오류를 줄일 수 있는 방법도 있을 것 같다.'라는 것을 기능 정책에 대해 고려하는 팀에게 공유하고 해결하고 싶은 마음이 더 컸다.
디테일이 S급을 만든다 라는 말도 있지 않은가! 다행히 파트장님도 진행될 수 있게 도와주셨고 기획팀 팀장님께서도 긍정적으로 진행해주셨다. 주위에 의욕적인 동료들이 있다는 건 감사한 일이라고 느꼈다.
- 결과 : '흰 화면 몰살!'이라는 목표는 90% 달성했다. 하지만 느낀 건 확실히 아직 나는 네트워크 지식이 부족하다는 것이다. 누군가 '비전공 개발자는 업무 퍼포먼스는 좋을 수 있으나 시간이 지나면 네트워크나 운영체제 관련 지식이 부족한 게 드러나게 된다.'라고 말하는 것을 들은 적이 있다. '뭐래.. 개발 잘하면 된 거지..'하고 무시할 수도 있겠지만, 나는 운이 좋게도 신입으로 입사하자마자 데스크톱 설치형 업무를 받은 덕에, 서비스 로직도 물론 중요하지만 네트워크와 운영체제 전반에 대한 지식이 탄탄해야 된다는 것을 일찍 깨닫게 된 것 같다.
노력은 하고 있으나 아직 그에 비해 지식은 아주 미비하고 스스로 만족스럽지 않기에 갈길이 정말 멀다.
4. 대규모 업데이트. 리뉴얼 프로젝트 투입! (3~9월)
그리고 입사 5개월이 되던 시기... 리뉴얼 프로젝트가 시작되었다. 서비스가 만들어진지 5년 만에 처음으로 전체 리뉴얼을 하는 작업이었다. 이전에 진행했던 채팅/데스크톱 앱 관련한 영역을 리팩터링 하는 역할로 프로젝트에 투입되었다. 이후 거의 5~6개월간 이 프로젝트에만 매달렸다.
- 배경 : 리디자인 -> 리팩터링 -> 프런트 구조변경까지 점점 업무의 단위가 커졌다. 쇠뿔도 단김에 빼자는 의도로 프로젝트를 리드하고 계시는 선배 개발자분이 리디자인/리팩터링을 하는 김에 새로운 아키텍처로 만들어 나가는 것을 추진했다.
- 행동 : 주어진 일정은 매우 제한적이었고 혼자서 채팅과 데스크톱 앱 내에 구현되어있는 수십 개의 (어쩌면 수백 개일 수도..) 기능들을 한층 더 디벨롭하여 구현해나가야 한다는 것 때문에 압박감을 굉장히 많이 받았다. 이때 당시에 매일같이 오후 11시가 넘어 퇴근했고 하루 12시간 근무는 기본이었다. 경주마처럼 달리긴 했으나 돌이켜보면 체력적으로 정신적으로 매우 지치고 힘들었던 것 같다.
- 배운 점 : 사실상 기존의 api를 활용하여 서비스를 새로 만드는 것과 다름이 없었다. 물론 백엔드 작업에 비해 프런트 작업의 비중이 굉장히 높았으나, 6개월 동안 자바스크립트에 대한 이해도나 활용도가 쌓인 것 같다. 물론 완전하게 마스터했냐라고 한다면 부끄러울 수준이지만, 적어도 프론트작업에 관한 새로운 지식을 습득하는 데에 있어 주저하지 않게 되었다고는 확신할 수 있을 것 같다. 이건 내가 나중에 프론트 / 백 어떤 길을 택하더라도 개발자 1년 차로써 할 수 있는 값진 경험과 배움이 아닐 수 없다고 생각한다.
또한 5명의 개발자가 영혼을 갈아 진행하다 보니 초반에는 git 충돌이 어마어마했다. 작업한 게 날아가는 일은 익숙해질 정도였다. 하지만 작업량이 점점 많아지다 보니 한번 충돌에 의해 잘못 머지된 작업들을 되돌리는 일은 안그래도 바쁜데 매우매우매우 비효율적인 일이었다. 이때 git 활용법인 rebase, patch 등에 대해 깊이 있게 공부하게 된 것 같다.
- 결과 : 결과적으로는 잘 리드해주신 선배 개발자 분과 열정적인 동료들 덕에 '훨씬 빨라져서 더 이상 이전 버전은 못쓰겠다!'라고 평가받고 있는 지금의 리뉴얼된 서비스를 만들어냈다. 나 또한 이전 버전에 비해 굉장히 만족하는 애용자가 되었다. ㅋㅋ 그리고 채팅과 데스크톱에 있어서는 도맡아 작업을 진행했던 덕에, 현재 두 영역에서 발생하는 이슈나 개선 건들에 관련해서 책임지게 되었다. 굉장히 이른 시기에 무거운 역할이긴 하나, 그만큼 책임감을 가지고 해 나갈 예정이다. 아쉬운 점이 있다면 당시 너무 급하게 개발한 탓에 깊게 고민하지 못하고 구현에만 목적을 두고 만들었던 부분도 있다. 그런 부분들이 현재 유지보수를 해나가며 나 스스로의 발목을 잡고 있는데, 올 해에는 그 부분들 리팩토링을 진행할 예정이다.
5. 데스크탑 설치형 업데이트(8~10월)
데스크톱의 경우 앱을 구성하고 빌드하고 배포하기 위해 일렉트론이라는 기술을 사용한다. 현재는 웹뷰 형식으로 일렉트론에서 url을 불러와 BrowserWindow에서 감싸는 형태로 사용하고 있기 때문에 모바일 앱처럼 로직 자체를 독립적으로 개발을 진행할 필요는 없다. 하지만 윈도우와 맥 각각의 운영체제에 맞게 알림/트레이 메뉴/설치 팝업/업데이트 등을 진행시키기 위해서 개별적으로 개발해줘야 하는 부분도 많다. 그래서 리뉴얼을 하는 김에 혼자 틈틈이 일렉트론 내부의 기능들도 리팩토링 및 개선을 병행했다.
- 배경 : 새로운 버전의 앱으로 전체 업데이트를 해야 하기 때문에, 재설치가 안 되는 불상사가 일어나서는 절대 안되는 일이었다. 특히 과거 5년간 사용자들이 설치했던 파일 중 설치 과정에 문제가 있으면 자동 업데이트가 안되는데, 그러한 경우에도 이번 리뉴얼에선 무조건 새로운 버전으로 업데이트가 되도록 하기 위해 잘못된 레지스트리를 삭제하고 앱 데이터를 초기화하는 로직을 installer.nsh에 넣는 작업도 필요했다.
또한 이왕 업데이트가 되었는데 내부만 바뀌고 껍데기(?)라고 볼 수 있는 일렉트론 자체 기능들이 개선되지 않는다면 그 또한 만든사람 쓰는 사람 둘 다 만족하지 못하게 될 것이라고 생각해 서비스 로직의 개선 작업도 필요하다고 생각했다.
- 행동 : 이 작업들을 혼자 틈틈이 병행할 수밖에 없던 이유는 일렉트론을 담당하는 개발자가 내 사수님과 나 둘 뿐이었지만 다른 업무로 매우 바쁘셨고, 나도 리뉴얼 소스 작업을 함께 진행하며 설치 업데이트 준비까지 혼자 진행해야 했기 때문이다. 처음에는 어디서부터 어떻게 건드려야 할지 감도 안 왔다. 일렉트론이라는 기술 자체가 생소했고, 회사 내에서 이 부분을 알고 있는 사람이 단 1명뿐이었기 때문이다. 그래서 구글에 있는 일렉트론 관련 글이란 글은 다 찾아보고 온갖 커뮤니티에 참여하여 질문하고 다니기도 했다. 특히 국내에는 커뮤니티가 많지 않아서, 대학시절 1년도 안 되는 기간 동안 교환학생을 다녀왔던 짧은 영어실력을 끄집어내서 해외 커뮤니티를 잘 활용했다.
- 배운 점 : 일단 윈도우와 맥의 운영체제 환경, 개발자가 다뤄야 하는 범위, 그리고 다룰 수 있는 범위도 다르다. 그 모든 걸 고려해야 하는 게 데스크톱 앱 개발자의 숙명인 것 같다. 특히 윈도우의 경우 electron-builder 가 사용하는 NSIS(Nullsoft Scriptable Install System)라는 일반적인 웹 프런트/백엔드 개발자라면 생소한 스트립트를 이용하여 설치에 필요한 앱아이콘/프로그램파일/앱데이터 등을 삭제하고 재설치하는 과정들을 직접 지정해줘야 한다. 또한 pc 재부팅 시 자동으로 재시작하도록 설정하는 부분, 작업표시줄 아이콘, 트레이 메뉴, 상단 메뉴, 내비게이션 바 등등 네이티브적인 모든 걸 윈도와 맥 모두 고려해야 한다. 개발이 마무리될 때쯤엔 빌드를 하루에도 수십 번씩 반복하며 여러 사람의 pc에 부탁해서 설치해보고, 심지어 대학교 친구들과 가족 pc에도 다 설치해보며 고쳐나갔다. (물론 uninstaller.exe 도 같이 전달해줬다..ㅎㅎ)
- 결과 : 약 3만명의 데스크톱 앱 사용자들을 버전 기준으로 3번에 나눠 정상적으로 업데이트시켰다. 이 과정에서 구버전 앱이 정상적으로 설치되지 않아 업데이트가 안 되는 경우도 몇 있었으나 결론적으론 잘 해결되었다. 그리고 회사에서 '미니맘'이라는 별명이 생겼다. 데스크탑앱은 사내에서 '미니'라는 이름으로 불리기도 하는데, 내 새끼 키우듯이 공들여 만들다보니 생긴 별명이다...! 보통 개발자들은 크롬 웹을 쓰기 때문에 설치형을 오히려 쓰지 않아, 실질적인 사용자의 후기나 오류 여부를 알기 위해서는 실 사용자인 타 부서나 고객들의 건의사항을 많이 참고했고 그 과정에서 자연스럽게 애착이 생겼다. 지금은 '데스크톱 앱 = 나'라는 인식이 자리 잡은 것 같아 뿌듯하기도 하고 일이나 각종 부서의 문의가 많아져서 힘들기도 하다.ㅎ.. 그리고 아직까진 자랑스럽지만 부족한 게 많은 내 새끼다. 일렉트론 버전 업데이트도 해줘야 하고 deprecated 예정인 모듈들은 새로 나온 친구들로 바꿔줘야 한다. 22년에 더 이쁘게 키워줄게...
6. 채팅 기능 고도화(10~11월)
리뉴얼 웹과 데탑이 모두 업데이트되고 2주 정도 여유를 가질까 말까 하던 찰나에 또 다른 프로젝트가 시작되었다. 바로 채팅 기능 고도화이다.
- 배경 : 위에서 언급한 채팅 로직 개선, 채팅 리뉴얼 작업을 진행하며 아무래도 익숙해져 있고, 기능 고도화 작업을 하며 좀 더 디벨롭하고 싶은 부분도 있어서 이 업무가 기획되었을 때 내가 진행하고 싶다고 팀원들과 파트장님들께 말씀드려 진행하게 되었다. 답장하기와 이미지 묶어 보내기 두 가지 기능이 추가되었는데, 나는 그중에서 답장하기 기능을 맡았다.
- 행동 : 답장 메시지라는 게 아예 없었기 때문에 db부터 프런트까지 한큐에 진행했다. 답장 메시지라는 개념을 따로 생각한다기 보단 메시지의 종류의 일부라고 생각해서 메시지 구분 값에 답장 여부와 답장이라면 상위 메시지 pk를 함께 저장하는 방식으로 작업했다. 채팅은 db에서 조회하여 보여주는 경우도 있고 소켓통신으로 노출되는 경우도 있기 때문에 두 경우 모두 동일한 동작이 이뤄질 수 있도록 모두 공통 함수를 이용하는 로직으로 구현했다. 그리고 답장이라는 기능이 생김으로써 한 채팅방에서 스크롤만 가능하던 예전과는 달리 과거와 현재의 시점을 왔다 갔다 하며 보여줘야 하기 때문에 프런트의 페이징 작업도 신경 써야 했고, 답장의 대상이 일반/이모티콘/이미지/파일/링크 등의 경우가 될 수 있기 때문에 테스트도 충분히 필요했다.
- 배운 점 : 확실히 채팅의 경우 이미 알고 있던 로직이라서 그런지 한결 개발하는데 어려움이 덜했고 속도도 붙었다는 느낌을 받았다. 깊이 있게 고민을 하더라도 구현하는 속도 자체가 빨라지니 더 세세한 부분까지 신경 쓸 수 있었고, 다 구현한 뒤 테스트까지 자체적으로 두세 번 진행한 다음 PM에게 개발 완료 통보를 할 수 있는 여유가 생겼다. 그러나 내가 신경 쓰지 못한 부분은 모바일이었다. 나는 api 작업과 웹클라작업과 소켓 작업을 스스로 진행하니 내가 서버에서 넘긴 값이 클라에서 받아질 거라는 걸 알고 진행해서 수월했다. 하지만 이후 작업하는 모바일 개발자들의 입장에선 대체 어떤 값이 넘어오고 활용을 어떻게 해야 하는지 내가 가이드를 명확하게 해주지 않으면 어려움을 겪을 수밖에 없었다. 망치로 머리를 맞은 것 같았다. 이렇게 또 자만할뻔했구나 생각하며 전문 명세서를 그제야 꼼꼼히 점검해서 모바일개발팀에 전달했다.
- 결과 : 고객 요청 1위였던 기능인만큼 채팅 답장 기능이 오픈하고 나서 1월인 지금까지 db조회를 해보니 사용자는 꽤 되는 것 같다. 하지만 오류건은 단 한건도 들어오지 않았고 그만큼 나 스스로 만족하는 결과물이기도 하다. 드디어 안 아픈 손가락이 생긴 기분이랄까..?
7. 기타 21년에 진행한 신규/개선 개발
그 외에도 다 기록할 수는 없으나 생각해보면 오류 수정 건을 제외한 신규/개선 업무들을 진행했다. 하나하나 고군분투하며 만들어서 그런지 머리로 낳은 내 자식들 같다.... (아픈 손가락이 몇 개 있긴 하지만ㅠ)
- [2월] 스티비 API 연동 메일 발신 개발
- [3월] 일렉트론 윈도 창 위치 및 모니터 감지 개선
- [8월] 설치형 사용자 온라인/오프라인/자리비움 상태 표시 개선
- [9월] 채팅 소켓 수신 시 참여자 필터 오류 개선
- [10월] 모바일앱 푸시 발송 개선 (채팅방/프로젝트 방 기준 알림 묶어보기)
- [12월] AD연동 기업 자동 로그인 기능 개발
8. 기타 21년에 진행한 오류 수정
우리 회사는 우리가 만든 서비스로 직접 업무를 진행하기 때문에 회사 구성원들이 진행한 모든 업무가 기록으로 남는다. 얼마 전 같은 팀 개발자분이 프로젝트별 처리업무를 한눈에 볼 수 있는 워킹 보드를 만드셔서 확인해보니 나는 무려 1년간 1044개의 업무를 완료 처리했다.... 세상에... 열심히 살았던 게 대견하기도 하지만 '그게 최선이었니?' 묻고 싶은 어리숙한 작업들도 사실 많다. 어떻게 첫술에 배부르겠냐만은 갈길이 너무 멀고 할 일은 태산이고 할 공부도 태산인데 욕심은 많으니 몇 년간은 하루를 48시간으로 사는 방법밖엔 없는 것 같다.ㅠ
아쉬운 점이라면 이곳은 급박하게 모든 일이 진행되고 업무량이 상당한 편이다. 이건 아마 여기까지 이 글을 읽었다면 공감할 것이다. 그러다 보니 나 스스로도 죄를 짓는 기분으로 충분한 고민이 부족한 채로 코드를 써 내려가게 되는 경우도 있다. 하지만 나중에 시니어 개발자가 되었을 때 흔히들 말하는 '실무는 모르면서 뜬구름 잡는' 그런 개발자가 되지 않으려면, 내실 있는 단단한 경험을 쌓기 위해 넘어볼 만한 산이자 감사한 기회라고 생각한다. 빠르게 작업하면서도 충분한 고민을 할 수 있도록 성장하면 되는 일이고, 일복도 복이라고 했으니 긍정적으로 생각하자!
회사생활 - 기타
이렇게 쓰다 보니 정말 일밖에 안 하고 산 것 같지만 회사에서 좋은 경험도 많이 했고 좋은 습관도 생겼다. 몇 가지 적어보자.
1. 작업일지
나는 개발 작업을 하며 일지를 꼬박꼬박 써왔다. 처음에는 사수님이 기록을 남기는 것이 나중에 나에게도 동료에게도 좋으니 써보라고 권해주셔서 쓰기 시작했고 초반에는 배운 걸 복습하면서 공부하듯이 꼼꼼히 쓰던 작업기록이 이제 하루 동안의 내 작업을 마무리하는 의미의 행동이 된 것 같다.
이제 딱히 강제로 시키는 사람도 없고 쓴다고 이익이 있는 것도, 안 쓴다고 불이익이 있는 것도 아니다. 평소에 글에 내 감정을 잘 담는 편은 아니라 일기는 잘 쓰지 못했는데, 신기하게도 이 작업일지는 팩트에 기반한 기록과 감정이 아닌 생각을 기록하는 일이라 그런지 매일매일 술술 잘만 써지고 쓰고 나면 유종의 미가 느껴져서 매우 뿌듯했다. 여기서도 mbti가 나오는 건가...?
결론은 작업일지 덕분에 이 회고록도 잘 채워졌던 것 같다. '기억보단 기록을'이라는 유명한 분의 블로그 이름처럼 기억이 나지 않을 뻔했던 업무들도 기록을 통해 되살렸다. 정말 좋은 습관이 생겼다고 생각해서 추천해주신 분께도 감사하고, 이 글을 읽는 당신에게도 매우 추천한다!
2. 사내 인터뷰
마드라스체크 장소이 책임, 웹서버개발팀 인터뷰 - 업무용 올인원 협업툴 플로우(flow)
안녕하세요, 저는 웹서버개발팀 공통 2파트의 장소이라고 합니다.저희 공통 파트는 플로우의 클라우드 서비스를 안정적으로 운영하면서, 동시에 사용자들이 원하는 기능들을 새롭게 보완해 나
post.flow.team
사내에서 인터뷰를 진행하여 공식 블로그에 게시되었다. 7~8월쯤 인터뷰를 진행했던 것 같은데 한참 리뉴얼 작업에 허덕이고 있을 때다. 이전 회사에선 개발자가 아니었기 때문에, 개발자로서 블로그에 게시된 내 모습과 내 생각을 보면 사실 아직도 신기하다. 내가 얼마 전에 쓴 내 생각을 읽는 게 신기하고 새로울 정도로 나에게는 이 1년 차 개발자로서의 일상이 바쁘고 힘들지만 아직까진 뿌듯하고 재미있게 느껴지는 것 같다.
3. 사내 동호회 3개 가입
동호회를 3개나 가입했다.. 일부러 많이 하려고 의도한 건 아니었는데 사람도 좋고 운동도 좋고 힐링도 좋으니 자연스럽게 가입하게 되었다.
1. 힐링 동호회, 2. 클라이밍 동호회, 3. 미라클 모닝 동호회이다.
그중에서 요즘 가장 나의 생활에 영향을 많이 미치는 동호회는 미라클 모닝이다. 사실 원래 모각 코 동호회였는데, 활동을 자주 못해서 기울어져 간다는 동기의 말을 듣고 아쉬워서 가입하여 미라클 모닝으로 탈바꿈하는 것을 제안해서 유지하고 있는 동호회다. 아침마다 기상을 인증하고 개인적인 공부나 자기 계발의 목표를 공유하고 이뤄나가는 방식으로 진행한다. 덕분에 아침이 매우 길어졌다.
4. 좋은 동료
인생에서 오래오래 생각날 좋은 동료들을 많이 만났다. 얼마 전에 한 직원이 이런 이야기를 하는 것을 들었다. '우리 회사는 너무 주니어만 모여있어서 배울 게 없어. 다들 열심히만 해.'
나는 개인적으로 시각을 중요하게 생각한다. 사람이나 상황이나 물건이나 환경 모든 것은 좋은 점이 있고 나쁜 점이 있다. 그중에서 어떤 면을 바라보느냐는 바라보는 사람의 몫이라고 생각한다. 내가 가진 시각으로만 대상을 바라보게 되면 그 이면은 절대 보이지 않고 놓치는건 늘어난다.
적어도 내 시선엔 부서를 막론하고 주위를 둘러보면 온통 존경스럽고 열정적인 사람들이다. 본인의 업무에 책임감을 갖고 개인 시간까지 줄여가며 몰입하는 모습, 주도적으로 성장하는 모습을 보면 항상 나를 뒤돌아보게 된다. 좋은 동료들이 항상 주위에 있음을 감사하고 나도 그들에게 더 좋은 영향력을 주는 동료가 되기 위해 노력할 것이다.
그래서 개발자로서의 1년 만족도는?
1. 70%! 정말 알차게 채워서 몰입하는 1년을 보냈기 때문에 아쉬움을 가지지 않으려고 하다가도 개인적인 공부를 못했던 시기가 있어서 계획했던 것만큼 많이 하지 못했다는 아쉬움이 든다. 분명 그렇게 바쁘고 11시에 퇴근하더라도 공부는 꾸준히 할 수 있지 않았을까? (사실 못했을 것 같다. 그래도 아쉽다.)
2. 그리고 이제 2년 차가 되었기 때문에, 지금처럼 전문분야 없이 풀 스택으로 개발을 하는 게 과연 맞는가에 대한 의문도 든다. 다들 주위에선 이때쯤엔 프론트를 할지 백엔드를 할지 결정하라고 한다. 나는 그냥 개발이 좋은데 ㅠ... 너무 어려운 일이고 아직도 결정하지 못했으나 아직 나에게 1년만 더 주고싶다. 대신 그동안은 더 깊이있게 고민하고 파고들어보고, 후회하지 않을 선택을 했으면 좋겠다. 오히려 둘다 해봤더니 풀스택이 맞는거 같더라! 라고 생각할 수도 있다.
3. 체력적으로는 계속 앉아만 있으니 체력이 많이 떨어졌다. 그래서 요즘은 운동도 꾸준히 하고 취미생활도 활동적인 것으로 꾸준히 하고 있다. 이제 나이가 들어가니 건강관리를 잘해야겠다.
끝내며
생각보다 글이 길어졌다. 분명 시작은 예비 개발자를 위해 1년차인 내 경험과 생각을 공유하는 것으로 시작했는데, 그냥 한명의 일에 찌든 개발 회고록이 된 것 같다.... 만약 이 글을 읽는 사람이 '내가 취업해서 잘할 수 있을까?'라는 생각으로 글을 읽고 있는 개발 취준생이라면 '아, 이런사람도 있구나. 심지어 비전공자였지만 결국 그냥 일 좋아하고 개발 좋아하는 개발자가 되는구나.' 라고 생각만 하고 당장 공부하러 갔으면 좋겠다. 불안함은 자기개발서, 선생님, 멘토들이 없애주는게 아니라, 자기 자신이 치열한 시간으로 쌓아가는 것이라는 글을 본 적이있다.
글을 읽는 모든 사람들에게 감히 응원을 하자면 정말 다양한 일을 하다가 개발의 길에 들어섰을텐데, 첫번째로는 축하한다는 말을 하고 싶고 두번째로는 용기를 내어 시작한 만큼 더 치열하게 살아가고 있을 당신을 존경한다. 스스로에 대한 믿음을 잃지 않았으면 좋겠고 내 성장에는 끝이 없다!라는 생각을 잃지 말기를!! (to me..)
'Moment' 카테고리의 다른 글
| 3년차 개발자 회고록 (+ 2023년 하반기 회고) (2) | 2024.01.07 |
|---|---|
| 3년차 개발자 회고록 (상반기) (0) | 2023.07.16 |
| 2년차 개발자 회고록 (0) | 2023.02.12 |
| (기고문) 함께 일하기 위한 도구, 협업툴 개발자의 질문 (2) | 2023.01.27 |
| 퇴사 후 회고록 (1) | 2021.01.02 |
