저는 지극히 평범한 개발자입니다

켄트 백의 테스트 주도 개발(Test Driven Development)을 읽어보면 뜻밖에도 켄트 백 본인은 너무도 평범한 개발이기 때문에 테스트를 중요시한다는 내용이 나온다. 그 구절을 보고 개발자로서는 안도하지 않을 수 없다. 나 역시 수 많은 평범한 개발자 중 하나이고, 평범한 개발자라면 언제라도 실수와 의도하지 않은 Side Effect로 인한 문제를 겪을 수 있기에 다양한 안전장치를 두는 것이 마땅하다는 의미이기 때문이다. 켄트 백이 보증한다.

 

지금의 팀에 합류하고나서 팀에 세가지가 비어있다는 생각을 했다.

 

1. 문서화

2. 테스트 코드

3. APM Tool

 

우리가 평범한 개발자이기 때문에 당연히 갖추고 있어야할 이 세 가지 필수적인 요소들이 현재 팀에는 부족했다. 우선 내가 갑자기 굴러들어온 돌이고 리더도 아닌 입장에서 팀에 부족한 점을 언급하는 것이 예민하게 받아들여질 수 있고, 실제 그런 문제때문에 현재도 진행형이지만 기회가 될때마다 어필을 해왔기 때문에 이제는 공감대가 형성된 것 같다.

 

 

시스템에 대한 문서화

도메인 지식과 시스템 메뉴얼 등 전반적으로 시스템을 설명하는 문서가 부족했다. 어떤 개발자분은 나에게 "코드를 잘짜면 문서가 불필요하지 않나요?"라고 말한적도 있다. 어떤 맥락에서 하신 말씀인지 대충은 알겠지만 시스템을 구조화한 그림을 머릿속에 각인하는 것과 코드를 읽고 이해하는 것은 상당히 다르다고 생각한다. 우리팀에 개발자만 있는 것도 아니다.

 

또 장애 히스토리와 시스템 설계 문서, 의사결정 과정을 기록한 문서 등이 쌓이게 되면 팀에 귀중한 자산이 될 것이고 경험적으로는 실제로 그랬다. 아무튼 문서화의 중요성에 대해 끊임없이 언급했고 실제 내가 (문서화에 미친사람처럼) 압도적인 위키 Contribute를 보여주며 지금은 전반적으로 문서화 문화가 잡혀가고 있는 것 같다.

 

테스트 코드

매우 중요한 비즈니스 로직이어도 테스트 폴더가 말끔하게 비어있는 경우가 많았다. 당연하게도 수정에 대해 사이드 이펙트를 검증하기 어려웠고 E2E 테스트에만 의존하고 있었기 때문에 코드 한줄을 수정해도 전체 프로세스를 돌려보는 비효율적인 개발이 지속되고 있었다.

 

이 역시 내가 주도적으로 테스트 코드를 많이 짜면서 코드 리뷰에서 공유했다. 동시에 테스트 코드의 중요성에 대해 직접적이지 않게, 강하지 않게, 하지만 반복적으로(가랑비로 옷 적시기 전략) 언급했다. 결과적으로 최근에 테스트 코드 관련 팀내 정책을 논의하는 단계까지 나아갔다.

 

APM(Application Performance Management) Tool

시스템의 리소스 사용 현황을 알 수 없었고, 실시간 Request Log를 모니터링할 수 있는 환경도 없었다. Exception이 발생했을 때 오는 슬랙 Fail Message에만 의존해야 하는 상황이었다. (다행히도 Error Log는 모니터링할 수 있다). '깜깜이 배포'라는 다소 원색적인(?) 표현을 써가며 APM 환경 구성에 대한 필요성을 어필한 끝에(그 덕분인지는 확실치 않지만) 시스템의 개선점에 대해 논의하는 정기 미팅이 만들어졌다. 하지만 아직 진행중이다.