글의 제목은 저에게 하는 말이구요. 커리어리에 처음 글을 쓰는 만큼 저를 모르실 텐데요. 저는 현재 카카오엔터프라이즈 검색플랫폼 팀에서 일하고 있는 주니어 개발자입니다. 앞으로 주로 쓸 글은

글의 제목은 저에게 하는 말이구요. 커리어리에 처음 글을 쓰는 만큼 저를 모르실 텐데요. 저는 현재 카카오엔터프라이즈 검색플랫폼 팀에서 일하고 있는 주니어 개발자입니다. 앞으로 주로 쓸 글은 시니어가 되기 위한 성장 과정들을 다룰 것 같아요. 현재 가장 관심 있는 목표가 시니어 개발자가 되는 것이거든요. 오늘은 최근 회사에서 저에게 가장 화가 많이 났던 사건을 다룰 거에요. 이걸 통해 깨달은 게 있거든요. 최근 제가 개발한 플랫폼에서 이슈가 생겼는데, 이 문제의 원인을 프로젝트를 같이하는 다른 팀원이 알려주셨어요. 제가 배포한 이후에 발생한 이슈라서 배포 후 모니터링을 했더라면 제가 진작에 발견할 수 있었겠죠. 기본을 지켰더라면 팀원분의 시간을 빼앗지 않았을 텐데 그러지 않았던 저에게 일차적으로 화가 났구요. 문제가 발생한 부분이 제가 배포하고 난 후 실제 테스트를 했었더라면 진작에 발견할 수 있었던 부분이었던 점에서 또 화가 났습니다. 저는 기능을 위해 같이 개발했던 테스트 코드가 잘 돌아가길래 당연히 정상적으로 작동할 줄 알았거든요. 즉 실제로 배포하고 난 후 돌려보지 않았다는 뜻이죠. 그리고 만약 많은 범위를 커버하는 테스트 코드를 짰더라면 테스트 코드에서도 당연히 검출되었을 거에요. 어떤 테스트 코드를 넣을까? 에서도 저는 잘못된 선택을 한 거죠. 기본을 지키지 않은 행동들을 해서 다른 분들에게 피해를 준 것에 대해서 미안했습니다. 이로 인해 팀원분들의 신뢰도 잃을 수 있었겠다는 생각이 드니까 한심하게 느껴졌었어요. 이미 잃었다면 잃은 거고 앞으로 어떻게 할지가 중요한 거겠죠. 제가 생각한 피드백은 이렇습니다. - 테스트 코드가 어디까지 커버하는지를 한 번 더 고민해보기. (회귀 방지에 대해서 고민해보기.) - 실제로 배포 후에 기능이 정상적으로 작동하는지 확인을 위한 스크립트 준비하기. (여러 가지 시나리오를 다루고 있는 스크립트를 준비하자.) - 매일 출근할 때 시스템의 에러가 없었는지 확인할 수 있는 자동화 시스템을 구축해놓기. 제가 할 수 있는 건 발전된 모습을 보여주는 것뿐이라 생각해서 이거라도 잘해야겠습니다.