TL;DR
- 저는 디테일을 잘 못챙깁니다.
- 디테일을 챙기는 개발자가 어떤 사람인지 정리합니다.
- 디테일을 챙기는 개발자가 되기 위해 남은 과정을 정리합니다.
- 정리한 과정이 올바른지 퇴고 합니다.
저는 디테일을 잘 못챙깁니다.
항상 제가 받는 피드백이 있습니다.
| ‘크리스피님, 여기 이 입력에서는 이렇게 되어 확인 요청드립니다.’
지금까지는 받아오면서 아무생각 없이 이슈에 대응만 하였습니다. 그러다 문득 깨달아 버렸습니다.
‘이게 맞나?’
항상 하는 실수인데, 예방하는 수는 없었을까? 한번 더 확인 하는게 불충분 하다면 다른 방법을 찾는게 좋지 않았을까? 왜 나는 그냥 대응만 하고 있지? 내가 개발자랑 안맞는 건가? 그만 둘까? 자질이 없나?
꼬리에 꼬리를 무는 자기 비하를 하다 보니 결국 한가지 결론에 도달했습니다.
지금 디테일을 챙기지 못하고 있고, 개발자를 할 거라면 디테일을 챙기자.
개발자를 더 이상 안할 것이라면 상관없지만 계속 할 것이라면 챙겨야 겠다고 말입니다.
디테일을 챙기는 개발자는 이런 사람입니다.
수정의 범위를 예측하고 대비합니다.
시스템에 대한 전반적인 큰그림을 사전에 정리하고 있어야 합니다. 그 큰그림을 기준으로 자신이 변경하고자 하는 것의 영향 범위 및 작업의 완료 여부를 확인합니다. 범위를 기준으로 테스트의 필요성 등을 판단합니다.
자신의 선택과 그 근거를 기록합니다.
개발자로서 하는 여러가지 선택의 근거는 항상 처한 상황에 따라 다릅니다. 디테일을 챙기는 개발자는 자신의 선택과 그 근거를 기록해놓아 자신의 결정에 대한 일관성을 유지합니다. 혹은 자신의 결정에 아쉬움을 회고하기도 합니다. 이를 통해 추후 비슷한 상황에서 더 많은 요소들을 고려한 결정을 내립니다.
정리하면
- 시스템에 대한 큰그림을 가지고 판단에 활용하는 사람
- 자신의 결정을 기록하고, 회고하는 사람
디테일을 챙기는 개발자 되기까지
뭐 하나라도 잘했으면 스스로에 대한 실망감도 덜었을 것 같습니다. 저로서는 가야할 길이 막막해 보입니다. 어쨌거나 되고 싶은 사람이니 어떻게 하면 좋을지 행위 중심으로 정리해 봅니다.
시스템에 대한 큰 그림을 가지기
- 일단 현재 회사 서비스에 대한 큰그림을 그려보기
- 알고리즘 문제를 손대기 전에 구상까지 끝내기
자신의 결정을 기록하고, 회고하는 사람
- 일지 쓰기
- 주간/월간 회고록 작성하기
자신의 작업이 미치는 영향을 예측하고, 계획하는 사람
- 작업 시작 전 상황의 정리와 가정 쓰고 작업 시작하기
정리한 과정이 올바른지 퇴고합니다.
행위 중심으로 되어 있는가?
그렇습니다. 일단 오늘 업무 부터 시작해 보면 좋을 것 같네요.
모호한 표현이 없는가?
큰그림등 모호한 표현을 사용했습니다. 이는 무지에서 비롯된 표현으로, 추후 같은 주제로 다른 글을 쓰게 된다면 큰그림이 무엇을 의미하는지 자세히 정리하면 좋겠다는 생각입니다.
행위를 통해 원하는 바를 성취할 수 있는가?
그렇다고 봅니다. 이것 자체를 실험처럼 해도 괜찮을 것 같다는 아이디어가 떠올랐습니다. 다음 글로 회고문을 작성할 수 있으면 좋겠다는 생각이 듭니다.
혹시 같은 고민을 가지셨던, 가지고 계신 분이 이 글을 읽으셨다면 함께 해보지 않겠습니까? ㅎ
이상 디테일 챙길 개발자 크리스피였습니다.