개발팀의 근황을 아주 간단히 말씀드리자면.. 서비스 개발과 외주를 열심히 진행하고 있습니다.
개발팀의 지향점과 현실에 대해 얘기해보려고 합니다.
개발팀 구성원들은 다행인지 아닌지(?) 이곳 저곳에서 좋은 개발 팀의 경험과 좋지 않은 경험을 직간접적으로 많이 경험했습니다.
그러다보니 개발팀의 지향점이나 문화에 대해 의논할 때면 다행히도 의견이 많습니다.
어쩌면 잘 알려진 테크기업이나 좋은 개발 문화를 직간접적으로 많이 접한 사람들에겐 당연한 얘기일 수 있지만
LAH 개발팀에겐 작지만 큰 목표이자 지향점이 되었습니다.
첫 번째로는 내부 문서화의 활성화입니다.
회사의 기술적 자산이라고 하면 인력이라고 생각해왔지만, 사실 회사로서 자산이라고 한다면 결국 문서화인 것 같습니다.
회사라는 주체가 회사의 구성원이 바뀌는 상황을 대처할 수 없다면 문제가 있다고 생각하는데, 이런 면에서 가장 중요한 것은
역시 문서화입니다.
사실 우리 모두는 문서화가 중요한 것은 알고 있습니다.
개발팀의 문서화는 중요한 규칙이 있습니다.
바로 단순히 명령어/동작에 따른 화면 덤프 문서화를 지양하자는 것입니다.
이 부분은 현 개발팀 구성원들이 겪었던 문제 덕분에 생긴 것인데 단순한 규칙이지만 많은 도움이 됩니다.
단순히 “덤프를 하지말자” 처럼 보이지만, 결국 덤프를 하지 않는다면 문서의 구성을 고민하게 됩니다. 이런 부분은 당연하게도 문서의 질에 도움이 되고 있죠.
두 번째로는 CI/CD의 중요성입니다.
이제는 너무 당연하고 대부분이 사용중인 CI/CD에 대한 중요성입니다.
개발팀 규모가 작을 때에는 구성원들이 많은 일을 해내야하기 때문에 CI/CD 구성 자체가 부담되는 경우가 많은데,
현재 개발팀은 CI/CD 구축에 대한 필요성이나 중요성이 매우 강하게 자리잡혀있습니다.
당연히 이와 더불어서 테스트 범위에 대한 고민도 많이 하게 됩니다. MR 생성시 테스트 범위와 데일리 테스트의 범위라던가..
세 번째로는 상호간의, 코드에 대한 존중입니다.
그럴듯하게 존중이라고 썼지만, 쉽게 설명하자면 서로의 코드를 리뷰할 때 수직관계가 아닌 수평관계가 중요하다는 얘기입니다.
코드를 리뷰하다보면 분명 프로그래밍을 잘하는 사람과 그보다 덜한사람이 있다고 생각합니다.
하지만 프로그래밍을 잘하는 사람의 코드가 늘 정답은 아니겠죠.
단적인 예로 프로그래밍을 잘하는 1명이 모든 코드를 작성하면 코드의 효율은 굉장히 좋아질 수 있지만,
다른 프로그래머는 해당 코드를 이해조차 하지 못해서 결국 팀의 효율은 떨어지고, 심지어 관계가 틀어질 수도 있습니다.
이 외에도 지향점은 굉장히 많지만 현재 개발팀은 크게 이러한 지향점을 가지고 서비스를 개발하고 있습니다.
하지만, 현실은..
불릿만 난무하는 문서도 있고, CI/CD는 커녕 테스트 코드만 겨우 작성하고 있기도 합니다.
코드에 대한 존중 이전에 어떤 팀원은 외주만 하느라 서비스 코드를 작성도 못하고.. 어떤 팀원은 서비스 코드만 열심히 작성하고 있는데
리뷰를 못받고 있기도 합니다.
이러한 지향점과 현실간의 차이가 분명 스트레스가 되고 불편한 맘이 들게 하지만
결국 더 나은 개발문화와 팀을 만들 것 같습니다.