내가 개발자로서 회사에서 한 실수들

Namu CHO
5 min readApr 1, 2024
출처: https://www.inc.com/john-discala/4-ways-to-bounce-back-after-making-a-mistake-at-work.html, 게티이미지

1. 모든 질문에 답변하고 코드 조언에 따른 것

오늘 dynamoDB 테이블에 있는 데이터를 업데이트 하는 과정에서 원하는 결과가 나오지 않았습니다. 하필 제 주위에 매니저 및 다른 동료들이 많이 있었어서 자연스럽게 다들 저의 에러에 관심을 가지게 되고, 다들 관련해서 도움을 주고자 많은 질문과 ‘이렇게 코드를 작성해보라’는 조언을 남겼습니다.

이 때 제가 많은 이들을 응대하면서 했던 말을 다시 반복하는 과정에서 지치면서 스트레스 받는 감정을 그대로 드러내버렸습니다.

하지만 집에와서 차분히코딩을 해본 결과 5분이면 해결되는 문제였습니다.

다음에 같은 상황이 생긴다면 모든 동료의 물음과 코딩 조언에 응대하지 않고 ‘차분히 제가 한 번 해보고 필요 시 도움을 요청하겠습니다. ’라고 대답할 것입니다.

2. 기본적인 지식을 모른 것

혹은 알지만 귀찮아 한 것

위 1번의 상황은 사실 배열을 순회하면서 배열 안의 정보를 기반으로 연속적으로 Promise를 통한 API call을 하는 작업이었습니다.

저는 이 상황에서 Promise.all 혹은 Promise.allSettled를 사용해야함을 알고 있었지만 ‘Promise.all을 사용하지 않고 update 작업을 수행해도 되지 않을까?’ 하는 검증되지 않고 틀린 생각으로 코드를 짜고 수행한 뒤 그 결과를 바로 다른 팀원들에게 공유해서 발생한 일이었습니다.

사실 제가 Promise에 대해 제대로 알고 있었다면 이런 바보같은 코드를 애초에 작성하지 않았을 것입니다. 저는 Promise에 대해 알고있다고 생각했지만 사실은 모르는 것입니다.

또한 머릿속에 Promise.all이라는 정답을 알면서 지금 당장 간단한 코드로 짜서 테스트하고자 하는 귀찮음 또한 저의 잘못이었습니다.

3. 테스트를 하지 않은 것

아주 간단한 파싱을 하는 코드를 수정하고 테스트하는 것을 잊었습니다.

아마 아주 간단한 코드 수정이라고 생각해서 테스트해봐야겠다고 생각하지 못 했던 것 같습니다.

이런 안일한 생각과 간단한 코드 실수로 인해 약 2주간의 데이터를 잃게 되었습니다. (다행히 개발용 테스트 데이터입니다.)

앞으로는 코드 수정 후 반드시 테스트하는 것을 잊지 않고 더 나아가 테스트 환경을 구축할 것입니다.

4. 확실하지 않은 것을 확실한 것처럼 말한 것

1번의 상황의 연장선입니다.

저는 1번의 상황에서 질문에 답할 때 ‘dynamoDB에서 이미 string으로 value가 설정된 key는 다시 그 value로 Number(value)를 해도 타입이 number로 바뀌지 않는다.’라는 잘못된 정보를 확신하듯이 말했습니다.

그 근거는 AWS console에서 데이터를 수정해도 데이터의 형이 number로 바뀌지 않았다는 것과, 제가 작성한 코드가 원하는 대로 동작하지 않았다는 것입니다.

하지만 AWS console은 GUI로서 데이터 manipulation의 한계가 있었던 것이었을 뿐이고, 제 코드는 제 코드의 로직 문제가 있었던 것이기에 (Promise.all을 쓰지 않은 것) 원하는 대로 동작하지 않았던 것일 뿐인데 저 두 근거로 너무 확신에 차서 잘못된 정보를 전달했습니다.

앞으로는 ‘~~한 상황을 근거로 보았을 때 ㅁㅁ해보이지만 좀 더 확인해보겠다.’와 같이 커뮤니케이션을 진행할 것입니다.

5. 다른 이들이 내가 만든 에러를 짚어낼 수 없는 환경을 구축한

1번 상황의 연장선입니다.

현재 새로운 POC 프로젝트를 진행하고 있습니다.

POC이기 때문에 스피드를 생명으로 가능한지의 여부를 먼저 보기 위해 저의 개인 AWS instance에 코드 및 서비스를 올려두고 개발을 진행하고 있었습니다.

저는 코드는 깃랩으로 관리하며 프로젝트 관련자들을 모두 member로 코드에 접근할 수 있게 해두었고

간단한 코드 리뷰를 요청해두었기 때문에 충분히 함께 협업하는 환경이 구축되었다고 생각했습니다.

하지만 제가 저의 개인 AWS instance에 접근 권한을 주지 않았기 때문에 아무도 데이터가 제대로 계속 들어오고 있는지, CloudWatch에 에러 로그가 찍히지 않는지 등을 모니터할 수 없는 상황이었습니다.

앞으로는 다른 프로젝트 멤버들이 필요한 리소스에 접근하는데 문제가 없도록 잘 살필 것입니다.

6. 스트레스 가득한 상황에서 동료의 도움요청을 응대한 것

스트레스 받는 상황에서 그 스트레스를 조절하기가 어렵다면, 그 장소를 빠져나와서 숨을 고르고 그 다음 도움이 필요한 동료에게 대화를 요청하거나

아니면 온라인으로 응대하는 것이 더 저에게 적합한 방법일 것으로 보입니다.

사실 작성해놓고 보니 미래의 면접을 보게 될 회사가 보면 저를 탈락시킬 것 같아서 걱정일 정도로 개발자로서 별로인 모습이지만

스스로의 발전을 위해서 이 실수들을 블로그 글로 남겨 앞으로 같은 실수를 반복하지 않도록 하겠습니다.

글을 작성하면서 스스로를 방어하기 위한 여러 사족을 붙이고 싶은 욕구가 많이 들었지만 작성하지 않고 최대한 스스로의 잘못만을 객관적으로 기재하고자 노력했습니다.

저의 부족한 면을 다들 너그러이 봐주시고 혹시 관련하여 피드백해주고 싶으신 부분이 있다면 쓴 피드백도 달게 받겠습니다. 마음 편히 피드백 남겨주세요.

마지막으로 저의 실수와 부족함을 비난하지 않고

함께 도와주려고 하는 현재 팀에게 늘 감사합니다.

--

--