본문 바로가기

카테고리 없음

게으름의 경고

개발자로 일을 하다보면, 해결해야할 문제를 실제보다 작게 판단하게 되는 경우가 없어야 함에도 불구하고, 업무를 만만하게 보는 오류에서 완전히 자유롭지 못하다.

최근 이직한 회사에서 처음 접한 언어/프레임워크를 쓰며 도메인 지식이 부족한 것과는 별개로, 업무를 하면서 놓치는 부분이 많다는 것을 느끼고 있다. 왜 놓치는 걸까? 아마 사람의 본능이 게으르기 때문일거다. 한 번 더 확인하고, 테스트를 몇번 더 해보기만 해도 이런 류의 실수는 많이 줄일 수 있을텐데 그 게으름 때문에 결국 문제를 일으키고야 만다. 자기 자신을 믿지 않는 것도 문제겠지만. 자기 자신을 잘못 믿는 것만큼 위험한 것이 이 세상에 더 있을까?

최근 몸의 아픈 신호를 핑계로 나의 슬럼프가 찾아오지 않기를 바라며 나의 잘못을 숨기고 싶었던 걸지도 모르겠다. 그러나 진정한 프로가 되려면, 내가 있는 그대로의 나 자신을 대해야 함이 중요하겠지. 현재의 문제점을 파악하고, 개선을 하기 위해 지속적인 성찰이 필요하다.

그리고 또 중요한 것은 내가 일하고 있는 시스템이 이런 류의 실수를 만들기 쉽도록 구축이 되어있기 때문일 수도 있다는 것이다. 어찌보면 개인의 잘못을 남탓으로 돌리는 것으로 비춰질 수도 있지만, 한 사람의 실수를 세상에 내보내기 전에 시스템적으로 미리 발견하여 예방할 수 있도록 개선할 수 있는 포인트를 찾아 실제로 개선이 되도록 할 수 있기 때문이다. 그게 테스트 코드가 될 수도 있고, 코드 리뷰, 꼼꼼한 QA 등이 될 수도 있다.

그렇지만 가장 큰 원인은 실수를 한 나 자신임을, 시스템적인 문제를 해결해야할 사람도 나 자신임을 잊어서는 안 되겠다. 실수도 3번이면 실력인데...

—-

해야할 업무를 파악할 때, 머리로만 생각해서 추측하지 말고 실제로 통합 환경에서 현재 어떻게 돌아가고 있는지를 확인하는 것이 중요하다. 내가 가끔 유난히 게으른 시기가 찾아올 때 많이 놓치는 부분이다.

기획은 완벽하지 않을 수 있다. 기획에서 고려하지 못한 것을 작업 전에 발견해야할 1차 책임자는 개발자다. 기획이 잘못됐다고 말할 수 있는 시기는, 배포되고 나서 버그가 발견됐을 때가 아니라 기획리뷰 또는 코딩을 시작하기 전이라는 것. 코딩을 하다가 발견된 부분은 즉시 이슈 레이징을 해야한다.

작업을 하면서 production 환경에 특별히 적용해야하는 설정값이나 DDL 등이 있다면 놓치지 않도록 나만의 루틴을 만들어야 한다. 난 요즘 github PR 의 description 에 넣어서 merge 하기 전에 그것이 미리 선행되도록 하려고 하고 있다.

TDD 로 개발하고 있다고 해도 놓치는 부분이 있을 수 있다. 개발자가 한가지에 집중하다보면 생각하고 있던 컨텍스트에 사상이 매몰되어 눈 먼 상태가 될 때가 있는데, 나만 있나?, 통합환경에서 테스트를 꼭 해야 한다. 그게 힘들면 QA 의 리소스를 빌리자. 통합환경에서의 테스트도 하지 않고 작은 기능이라며 QA 프로세스도 무시해버리면 80% 이상으로 버그가 발생하는 것 같다. (근거없는 개인의 기억에 의한 통계) 배포를 늦추더라도 이 과정은 생략해서는 안 되는 과정인 것 같다.

하.. 정신차리자.