함께 일하고 싶은 개발자로 성장하기

재직 중 가장 많이 고민했던 부분 중 하나입니다. 일하면서 나름의 기준이 생겨 글로 정리하게 되었습니다.

1. 본업에 충실하기

가장 먼저 본업에 충실해야 합니다. 자신이 맡은 1인분을 온전히 해내지 못하면 다른 누군가가 그 비용을 감당해야 하고, 팀 전체의 효율이 떨어질 수 있기 때문에 협업 시에는 늘 본업에 충실해야 한다고 생각합니다. 만 1년 차인 제가 백엔드 개발자로서 1인분을 잘해내는 것은 다음과 같이 정의했습니다.

1. 정해진 기한 내에 맡은 업무 완료하기

2. 담당한 기능 끝까지 책임지기 (충분한 테스트 진행하기, 이슈 발생 가능성 사전에 공유하기, 모니터링)

3. 업무 진행 상황 자주 공유하기

4. 내가 아닌 다른 동료가 이 일을 맡게 되더라도 업무 진행에 지장이 없도록 문서화하기

네 가지 조건에는 기술적인 부분도 내포하고 있습니다. 자신이 만든 기능에서 발생한 오류를 직접 해결하거나, 문제가 생기기 전에 방지하려면 그만큼의 기술적 이해가 필요하기 때문입니다. 또한 비슷한 맥락에서 코드와 테스트코드도 하나의 문서 역할을 하고, 작성한 코드를 좋은 문서로 만들기 위해서는 가독성 좋은 코드를 위한 고민과 학습이 필수라고 생각합니다. 이해하기 쉽고 테스트가 잘 갖춰진 코드는 예상치 못한 이슈를 줄여주고, 다음 작업자의 개발 비용까지 줄여주기 때문입니다.

결국 본업에 충실한다는 것은 누군가가 안심하고 업무를 맡길 수 있는 신뢰를 주는 일이고, 이러한 신뢰는 자신이 만든 기능을 끝까지 책임지려는 태도에서 비롯된다고 생각합니다.

2. 텍스트로 소통하기 편한 사람 되기

입사 후 가장 신경 썼던 부분입니다. 업무 히스토리를 남기기 위해 메신저를 잘 활용하는 것이 중요했고, 팀 내에서도 슬랙 소통을 권장했습니다. 회사에는 도메인 전문가이자 DBA분이 계셨는데, 레거시 개선 작업을 하면서 이분과 소통할 일이 많았습니다. 직무가 다르고 자리가 멀어 거의 90%의 소통을 메신저로 했지만, 이분이 설명해주신 내용은 거의 단번에 이해가 되었습니다. 설명이 항상 군더더기 없이 명료했기 때문입니다. 이분의 스레드를 보면서 소통 방식을 배우려 했고, 다음 부분들을 신경 쓰면서 저도 소통 비용을 줄일 수 있었습니다.

정보는 상대방의 맥락을 고려하여 한 번에 전달하기

상대방의 맥락을 고려한다는 것은 상대방의 직무나 직급 등을 고려해서 전달한다는 의미입니다. 예를 들어 기획자와 소통할 때는 개발 용어를 비개발자도 이해할 수 있는 언어로 바꾸거나, 개발 용어를 꼭 써야 하는지 생각했습니다. 만약 개발 서버에서 발생한 에러의 원인이 개발 DB에 신규 컬럼이 아직 추가되지 않았기 때문이더라도, 기획자에게는 '백엔드 환경 설정 문제'라고 전달하면 충분합니다. 상대방에게 어떤 내용을 전달하고 싶은지, 혹은 어떤 답변을 듣고 싶은지 등 글을 쓰는 목적을 생각하며 글을 쓰려 노력했습니다.

마찬가지로 자신의 업무 맥락과 상대방의 맥락은 다를 수 있다는 점을 인지해야 합니다. 다른 맥락에 있을 상대방을 배려해 "API 작업 완료되었습니다."보다 "A 프로젝트의 XX API 작업 완료되었습니다."라고 전달하는 편이 불필요한 소통 비용을 줄일 수 있습니다. 상대방에게 필요한 내용을 간결하면서도 자세히 전달하고자 했습니다.

적절한 독자 선별하기

일을 하다 보면 많은 메신저 알림을 받게 됩니다. 저는 슬랙 알림을 확인하는 대로 읽으려 노력하는 편이고, 빠른 답장도 중요하게 생각합니다. 그러다 보니 알림이 와도 쌓아두지 않고 바로 확인하는데요. 백엔드 작업과 크게 관련 없는 디자인 논의 스레드에 태그될 때마다 알림이 오면, 제게 정말 필요한 정보를 식별하는 데 비용이 든다는 점을 인지했습니다. 이후부터는 글을 작성할 때 이 글이 필요한 대상인지 한 번 더 생각하고 태그했습니다. 웬만하면 @here 같은 태그보다는 답변을 줄 수 있는 분을 직접 태그했습니다. 또, 여러 일을 병렬적으로 진행하는 분을 태그할 때는 태그 옆에 맥락을 설명하는 간단한 코멘트를 붙이기도 했습니다. 업무 참조 cc.도 적극 활용해, 팀장님처럼 진행 상황 공유를 위해 태그가 필요한 경우에는 cc.를 자주 사용했습니다. 앞에 cc.만 붙어도 중요도를 파악할 수 있는 힌트가 된다고 생각했기 때문입니다.

퇴사 전날 이사님께서 디엠을 주셔서 커피챗을 하게 되었습니다. 이사님과 업무적으로 직접적인 교류는 한 번도 없어서 저에 대해 잘 모르실 거라 생각했는데, 이사님께서는 슬랙에 글 쓰는 걸 보고 말을 잘해서 눈에 띄었다는 칭찬을 해주셨습니다. 회사 생활은 처음이라 여러 방법을 시도해봤는데, 그 방식이 정말 효과가 있는지 확신이 없던 저에게 좋은 피드백이 되었습니다.

3. 실수를 반복하지 않도록 나만의 시스템 만들고 공유하기

입사 초기, DBA 분께 운영 DB 쿼리 검토를 받는 과정에서 제 쿼리가 잘못되어 같은 쿼리를 두 번 확인받아야 했던 적이 있습니다. 이후 같은 실수를 반복하고 싶지 않아 저만의 시스템을 만들었습니다. 거창하게 시스템이라 표현했지만, 실수를 방지하기 위한 나만의 매뉴얼을 만든 것입니다. 단계별로 진행해야 하는 작업은 다음 사진처럼 매뉴얼로 만들어두었습니다.

매뉴얼에는 작업 순서와 주의사항을 작성하고, 완전히 체화될 때까지 그대로 따라했습니다. 실수를 줄이기 위해 검토 과정만 늘리면 시간이 불필요하게 소요되고, 그렇다고 검토 과정을 생략하자니 실수를 반복할 수 있다고 생각했습니다. 따라서 이러한 매뉴얼을 따라하면서 작업 절차와 검증 과정이 익숙해지고 자동화하여 속도와 정확도를 모두 잡고자 했습니다. 이 방법으로 놓칠 수 있는 부분을 실수하기 전에 미리 확인할 수 있었습니다. 시스템적으로 자동화 가능한 부분이 있다면 자동화하는 게 베스트지만, 그런 환경이 안 될 때 사용하기 좋은 방법이라고 생각합니다.

이렇게 작성한 매뉴얼은 팀의 자산이 된다는 것도 배웠습니다. 신규 입사자분과 둘만 회사에 남은 적이 있었는데, 그분은 당장 배포를 해야 했고, 배포에 익숙하지 않아 배포 프로세스 설명을 부탁하셨습니다. 저도 당시 급하게 처리할 일이 있었지만, 작성해둔 매뉴얼을 공유해 빠르게 해결할 수 있었습니다. 실수를 줄이기 위해 작성한 글이 누군가에게 가이드 문서가 될 수 있다는 생각에 작업 내용을 컨플루언스에도 문서화하기 시작했습니다. CS 이슈에 히스토리를 남기거나, 해결 가이드를 작성하거나, 몇 줄 안 되는 PR이라도 반드시 히스토리와 작업 설명을 적었습니다.

처음에는 단순히 실수를 줄이고자 시작했지만, 실수를 줄이는 것 뿐만 아니라 하나의 매뉴얼로 문서화 된다는 점과 업무의 히스토리가 된다는 점 등의 여러 이점이 있었습니다.

또 앞으로도 팀과 상황에 맞춰 유연하게 기준을 조정하며 좋은 동료로서 기여할 수 있다면 좋겠습니다.

번외) 퇴사 전 제가 정말 애정하던 동료분들이 좋은 말씀을 많이 해주셨습니다. 누군가 어떤 개발자가 되고 싶은지 물었을 때 항상 같이 일하고 싶은 개발자가 되고 싶다고 생각했었는데, 조금은 그 목표에 가까워진 것 같아 회사 생활을 행복하게 마무리할 수 있었습니다.