혼자 생각해 본 개발 문화
여러 개발팀의 문화를 보면서 항상 좋은 문화와 방법에 대해 생각해왔다.
어떤 좋은 방법이 있더라도 결국 팀 안에서 상황에 맞춰서 바꿔 적용하는 게 정답일 거 같다는 생각이 든다.
내가 생각했을 때 개발팀에 있으면 좋겠다고 생각하는 문화, 방법들을 정리해 보려고 한다.
코드 리뷰
코드 리뷰를 했을 때 얻을 수 있는 이점은 문제가 생길만한 부분의 코드를 먼저 발견, 코드 스타일 ( Convention ) 준수, 중복 코드를 방지 등이 있다.
개발하다 보면 본인이 발견하지 못한 실수를 다른 사람이 먼저 발견하여 고칠 수 있으며, 정해진 코드 스타일을 지킴으로써 일관된 스타일의 코드를 작성할 수 있다.
코드 리뷰가 좋다는 말은 항상 들어서 알고는 있었으나 구체적으로 어떤 부분이 좋은지 모르고 있었는데, 실제로 코드 리뷰를 해보니 상당한 효과를 많이 봤다.
최근에 직접 겪었던 사례로 기존 서비스에서 "A 기능"을 조금 수정하고 코드 리뷰 요청을 했는데 리뷰 중 전혀 상관없어 보였던 "B 기능"에 문제가 생길 수 있지 않냐는 코멘트를 듣고 확인해보니 실제로 영향을 받고 있었다.
내부 로직이 복잡해서 정확하게 확인하지 못했던 부분인데, 리뷰를 통해서 문제가 있을 수 있다는 것을 알게 되고 다시 수정해서 문제없이 배포할 수 있었다.
코드 리뷰는 할 수 있다면 하는게 좋다.
IaC ( Infrastructure as Code )
클라우드 환경에서 리소스를 생성하고 삭제하는 건 너무나 간단하다. 클릭 한번, CLI 명령어 한 번에 리소스가 생성되고 삭제되기 때문이다.
리소스의 생성/삭제가 간편하기 때문에 수동으로 리소스를 필요할 때 마다 바로바로 만들어서 사용했다.
이렇게 인프라를 관리해도 1~2명의 인원이 관리할 때 어려움이 없었다.
하지만 인원이 늘어나고 서비스 규모가 커짐에 따라 불필요한 리소스가 생성되기도 하고, 필요한 리소스를 삭제하는 실수가 발생하기도 했다.
더 큰 문제는 시간이 지나면서 어떤 목적과 의도로 만들었는지에 대한 히스토리가 전달되지 않았고, 이로 인해 인프라 관리가 정말 어려워졌다.
이런 문제점들을 해결하기 위해 IAC ( Infrastructure as Code ) 가 등장했다.
유연성이 떨어지는 스크립트가 사람이 직접 리소스를 생성하는 대신, 코드를 이용해 시스템을 자동으로 구축, 관리, 프로비저닝을 하게 되었다.
코드로 관리하기 시작하면서 빠르고 정확하게 관리할 수 있으며, 동일한 환경을 구성할 때도 정말 간단해진다.
대표적으로는 Terraform, AWS CDK 등이 있다.
IaC 는 더이상 선택이 아니라 필수다.
문서화
개발하다 보면 무언가 정리하기 위해 문서화의 필요성을 느낄 때가 있다. 특히 개발자끼리 의사소통을 할 때 문서화의 필요성을 많이 느낀다.
문서화는 코드로만 표현하기 어려운 정보들을 보충하는 것이다. 코드는 텍스트로만 표현하기 때문에 이해가 쉽게 안 될 경우가 많다.
이런 경우 UML, flowchart 등의 시각적 자료들은 코드의 이해를 돕는 게 매우 효과적이다.
최근에 많이 적용되고 있는 MSA 에서 여러 서비스를 통신해서 기능을 만드는 경우에도 문서화를 잘해두면 이해하기가 훨씬 수월하다.
문서는 상부에 보고를 위해 만드는 게 아니라 의사소통을 위해 만드는 게 더 맞지 않냐는 생각이 든다.
가장 중요한 건 문서를 만들었으면 지속해서 관리를 해줘야 한다는 점이다.
오히려 만들어놓고 관리 안된 문서는 없는것보다 못하다.
문서화 작업도 업무의 일환으로 생각하고 일정 잡을 때 충분히 고려되어야 한다.
회고
스프린트 회고, 스쿼드 회고, TF 회고 등 여러 회고를 참석해보면서 느낀 점은 회고를 통해 내 생각을 정리하고 공유할 수 있는 시간이 만들어진다는 것이다.
회고라는 시간을 갖지 않고도 더 자주 공유하고 더 자주 대화를 하는 게 가장 좋은 방법이겠지만, 현실에서는 쉽지는 않다고 생각한다.
아쉬운 점, 잘한 점, 개선할만한 내용을 찾아내고 Action Plan을 도출해서 앞으로 더욱 팀이 성장할 수 있는 방향을 찾는 게 팀의 성장에도 굉장히 도움이 된다고 생각한다.
신규 입사자 적응 기간
개발자가 팀에 적응하는데 까지는 짧게 1달 ~ 길게는 6달 정도의 시간이 필요하다고 한다.
이 시간을 최소화하고, 빠른 업무 적응을 위해서는 신규 입사자가 기존 구성원들과 함께 제품, 시스템에 대해 이해도를 쌓아가는 시간이 필요하다. ( e.g. 스포카의 부트캠프 )
서비스를 사용하면서 문제점, 버그를 찾아 이슈로 만들고 스스로 해결해나가는 과정에서 서비스에 대한 이해도를 높일 수 있을 뿐만 아니라 코드를 직접 수정하다보니 자연스럽게 업무에 대해 적응이 된다.
신규 입사자 적응 기간은 개인의 적응 뿐만 아니라 더 나아가 팀의 성장을 위한 투자라고 생각한다.
프로페셔널
•
각 분야의 전문가로서, 당연하다고 생각한것 들은 타협하지 말고 말할 수 있어야 한다.
•
(*) 업무에 대한 시간을 측정하고, 그 시간 안에 끝내야 한다.
•
내 일이 아니더라도, 주변 동료들이 어려움을 겪는다면 적극적으로 도와준다.
•
우리 모두가 프로라는 생각을 하는 것도 중요하다.