첫 회사에서 한 5가지 실수

아직도 이불킥을 찬다.

첫 회사에서 저지른 5가지 실수

1. 테스트 없이 프로덕션 배포를 했다.
2. 사고를 쳐놓고 인정하지 않았다.
3. 요구사항을 제대로 확인하지 않고 개발을 진행했다.
4. 배포를 남한테 떠넘겼다.
5. 코드 리뷰를 싸가지 없게 했다.

1. 테스트 없이 프로덕션 배포를 했다.

간단한 코드를 수정하고 바로 프로덕션 배포를 한 적이 있다.

머릿속으로 실행을 해봤을 땐, 완벽하게 작동했기 때문에 따로 테스트는 하지 않았다.

그리곤 운영팀에서 난리가 났다. 😱

사용자 불만 문의가 유입되고, 불편을 겪은 사용자에게 사과 메일도 보냈다.

원인은 입력 폼 검증 로직에 삼항 연산자를 썼는데, 연산자 우선순위를 제대로 고려하지 않아서 모든 사용자의 폼 제출이 막혔다.

그 이후론 코드 수정 후, 잘 돌아가는 것을 반드시 눈으로 확인해보고 PR을 올리고, 배포한다.

또한, 버그를 발견하기 위해 더욱 공격적으로 코드 리뷰를 하게 됐다.

남의 코드를 보고 찜찜한 부분이 있으면, 귀찮아도 직접 실행해서 테스트하곤 한다.

개인적 해결책

• 배포 전에 꼭 테스트한다. 5분 귀찮다고 테스트 안 하면 5일 동안 정신 나간다.
• 모든 일은 생각보다 급하지 않다. 차분하게 해도 큰일이 나지 않는다.

팀차원 해결책

• 코드 리뷰를 통해 다른 팀원이 코드 레벨에서 문제를 미리 파악한다.
• 스테이징, CBT 환경에서 반드시 테스트해보고 배포한다.

2. 사고를 쳐놓고 인정하지 않았다.

+ 비즈니스 로직을 모두 파악하지 못했다.

내가 모로고 있던 유저 플로가 있었는데,

그 플로를 실행하면, 한 사용자의 데이터를 다른 사용자의 데이터로 덮어져서 기존의 데이터가 소실되는 사고가 발생했다.

긴급회의로 팀원들이 소집됐을 때, 분명히 내 잘못인데도,

유저 플로를 전혀 몰라서 대응할 수 없던 터라 “나도 당했다”라는 느낌 때문에 팀원들에게 제대로 사과하지 못했다.

문제가 발생했으니 상황 파악을 하고 해결책을 제시했어야 했는데, 멘붕 상태라 얼빠진 행동을 했다.

다음엔, 큰 사고를 치면 멘탈을 제대로 부여잡고 빠르게 해결부터 한 뒤에 사과하겠다고 다짐하고 있다.

그리고 문제가 재발하지 않기 위해 포스트모르템을 작성하고, 개인 차원을 넘어 조직 차원에서 문제를 예방을 방법을 생각하려고 한다.

온보딩 때, 누가 비즈니스 로직을 1:1로 가르쳐주거나, 잘 정리된 문서만 있었어도 지금까지 이불킥 찰 일은 없었을 텐디…

개인적 해결책

• 실수를 빨리 인정하고 해결한다.
• 실수했으면 사과한다.
• 실수를 예방할 대책을 세운다.

팀차원 해결책

• 신입사원이 놓치는 비즈니스 로직이 없도록 온보딩 때 교육을 하거나 문서를 잘 정리한다.
• 사고를 쳐서 당황한 팀원이 멘탈을 붙잡을 수 있도록, 지금 당장 해야 할 행동을 인지시킨다. (문제 파악, 해결)

3. 요구사항을 제대로 확인하지 않고 개발을 진행했다.

요구사항을 착각해서 설정만 수정해서 5분이면 끝날 일을, 잘못된 기능을 개발하느라 3일을 날렸다.

또한, 잘못 구현한 기능이 다른 모듈에 영향을 끼쳐서 그것대로 민폐였다.

1분이라도 들여서 요구사항을 제대로 확인했으면 이런 일이 일어나지 않았을 것이다.

개인적 해결책

• 요구사항을 제대로 확인하고 또 확인한다.
  • 프로젝트를 동시에 많이 진행하다 보면 어떤 프로젝트의 어떤 기능을 구현해야 하는지 정말 헷갈린다.
  • 그럴수록, 정신 똑바로 차리고 내가 하고 있는 게 맞는지 확인해야 한다.

팀차원 해결책

• 구현할 요구사항을 리뷰한다.
  • 현 회사에서는 팀원이 돌아가면서 피쳐리스트를 작성하고 모든 팀원이 검토를 한다.
  • 기획에서 요구한 사항을 충족하는지와 문제가 발생할 부분은 없는지 확인할 수 있다.

4. 배포를 남한테 떠넘겼다.

배포 담당자가 있었지만, 내가 배포를 직접할 수 있었다면 고객의 요구사항에 유연하게 대체할 수 있었을 것이다.

당시엔 급하게 배포해야 할 게 있을 때마다, 담당자에게 부탁을 했어야 했다.

그게 귀찮아서 당장 배포해도 괜찮을 것도 정기 배포 때 같이 태워서 배포했다.

그렇게 어려운 게 아니라, 그냥 내가 하면 됐는데 왜 안 했을까?

개인적 해결책

• 배포를 직접 해본다.

팀차원 해결책

• 배포를 쉽게 할 수 있는 환경을 만든다.

5. 코드 리뷰를 싸가지 없게 했다.

코드 리뷰에 재미가 붙기 시작한 때였다.

코드 속에 숨어 있는 버그와 요구사항을 충족하지 못한 부분을 잡아내서 리뷰를 남기곤 했는데,

다른 회사에 가서 코드 리뷰를 남기기만 하던 입장에서 받아 보는 입장이 되니, 잘못을 지적받는 게 정신적으로 힘든 일임을 알게 됐다.

리뷰에 말이 이쁘게 적혀 있더라도, 코드에 부족한 부분을 들키게 되면 머쓱할 때도, 맘이 덜컹할 때도 많은 거 같다.

코드 리뷰가 다른 개발자들의 마음에 비수를 난사하는 행위가 되지 않도록 조심해야겠다.

그리고 나쁜 것만 지적하지 않고 잘한 점도 발견해서 칭찬해야 하는데,, 쉽지는 않지만 노력해야 한다.

개인적 해결책

• 🌸🌷🌹말 좀 이쁘게 하자🌻🌺💐
• 칭찬 좀 하자
• 구글의 지혜: 겸손하게 다른 팀원의 지적 창조물을 존중하고 신뢰한다. (Humble, Respect, Trust)

팀차원 해결책

• 좋은 리뷰를 선정해서 공유한다.

마무리

남의 실수를 봐도 별 감흥이 없었지만, 직접 실수를 해보니 큰 깨달음을 얻을 수 있었다.

실수 했을 당시엔 지옥 같았지만, 지금은 미리 실수해서 다행이라고 생각한다.

앞으로도 많은 실수를 하겠지만, 전에 저지른 실수 덕분에 전보다 더 잘 대처할 자신감이 생겼다.