좋은 개발문화를 만든다는것

08 Apr 2020

애자일, 스크럼, 코드리뷰, CI/CD, Git-flow, 테스트코드, 기술공유, 스타일가이드, 사내 스터디… 너무나도 친숙한 이것들은 ‘개발 문화’를 만들기 위해 많은 회사들에서 시행하고있는 내용들입니다. 그렇다면 ‘개발 문화’란 무엇일까요. 앞서 나열한 다양한 방법 및 기술들은 ‘개발 문화’를 만들기위한 수단이지 ‘개발 문화’ 자체는 아닙니다.

우리팀은 스크럼을 도입해 업무를 세분화하여 스프린트에 할당한 업무만 진행해
우리팀은 무조건 모든 팀원의 코드리뷰 승인을 받아야해
우리팀은 모든 코드에대한 테스트 코드를 작성해서 테스트 커버리지가 100%야

이러한 의견들을 들으면 과연 ‘좋은 개발 문화’인가? 라는 의문이 드실 겁니다. 이렇게 말씀을 드리는 것은 위의 방법들이 좋지 않은 것들이라는 것이 아닌, 개발 문화를 만들기 위한 좋은 수단들이 말 그대로의 문화가 될때 그것이 좋은 개발 문화라 말 할수 있을 것 입니다.

스크럼 방법론을 일례로 들어보자면, 스크럼 자체가 지속적인 변화에 대응하기위한 애자일을 실천하기 위한 방법인데 스크럼을 도입하여 사용하면서도, ‘이미 개발된 사항이라 변경할수 없다’라거나 ‘해당 태스크는 우선순위가 후순위라 작업할수 없다’ 등의 이야기가 나온다면 단순히 스크럼을 업무 프로세스 과정으로 여기는 것이지, 개발 문화로 만든것은 아니라고 생각이 듭니다.

아직도 많이 부족하고 다른팀보다 뛰어나다고는 할 수 없지만, 좋은 개발문화를 만들어 나가기위해서 계속해서 노력하고 있는 저희 팀에서 사용중 몇가지의 개발 문화들의 목적과 도입효과에 대해서 공유 하고자 합니다.

Scrum

목적

위에서도 언급했다시피 스크럼 방법론은 애자일을 위한 방법론중의 하나입니다.
애자일은 과거의 폭포수 모델의 '변경하기 어려운 SW 개발방식'에서 '변화 무쌍한 SW 개발방식'을 대응하기 위한 개발방법론입니다.

애자일에서 가장 중요하게 생각하는것 2가지는 협력과 피드백 으로서, 개발을 해나가는 중간중간마다 함께만들어나가는 팀(개발팀 뿐만아닌 기획, 디자인 등등 모든 참여자)들이 함께 확인하고 개선해나감으로써 개발 초기 과정에서 변화에 빠르게 대응 할 수 있습니다.

애자일 이면의 원칙

우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.

비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

작동하는 소프트웨어를 자주 전달하라. 2주 ~ 2개월 정도의 간격으로 하되 더 짧은 기간을 선호하라.

비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.

동기가 부여된 사람들을 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.

개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.

작동하는 소프트웨어가 진척의 주된 척도이다.

애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.

기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.

단순성이 – 안 하는 일의 양을 최대화하는 기술이 – 필수적이다.

최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.

팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

도입 효과

스크럼 도입으로, 프로젝트 전체 개발플랜을 미리 세워두고 작업하는게 아닌 스프린트 단위로 정해진 주기 (2-3주)마다 개발플랜을 세우고 있습니다.

스프린트 단위 안에서 개발플랜을 계획을 하지만, 요구사항은 언제든 변경 될 수 있다는 애자일 원칙에 따라 계획은 언제나 변경 될 수 있다는 마인드로 작업을 진행하며, 작업의 진행상황에 따라서 언제든지 팀원들과 소통을 하며 마무리가 되지 않은 작업을 다음 스프린트로 넘기던가, 백로그의 작업을 미리 가져와서 진행하는 등 유동적으로 작업을 진행 할 수 있습니다.

특히 코로나 바이러스로인해 재택근무를 하고 있는 시점에서 우리팀은, 작업 목표가 루즈해지는것을 방지하기 위해 대비하여 스프린트의 주기를 일주일로 잡아 매주 개발 플랜을 세움으로써 재택기간내 프로젝트를 잘 마무리 지을 수 있었다고 생각합니다.

아직 스크럼을 아주 잘 활용하고 있다고는 하지 못하겠지만 정답이 없는 방법론 이기때문에, 계속해서 우리팀에게 도움이 되는 활용법을 찾아서 개선을 해 나가고 있습니다.

Git-flow

목적

개발팀에게 있어서 소스 버전관리는 따로 설명을 드리지 않아도 굉장히 중요함을 개발자라면 모두가 알고 계실겁니다.

우리팀은 git-flow를 활용해 브랜치를 관리하고 있는데, 일반적으로 알려진 git-flow 방식과는 다른 우리팀만의 git-flow 모델 (해당 git flow 소개 링크 : https://taes-k.github.io/2020/01/07/clean-git-flow/) 을 사용하고 있습니다.

사실 Git-flow는 단순히 git을 잘 사용하기 위한 전략일 뿐입니다. 다양한 상황에서 공통된 행동으로써 git 히스토리를 관리해나가는 것인데, 이 전략을 도입한 목적은 어떤 누가 와도 git 네트워크를 한눈에 파악하고 쉽게 사용 할수 있게하기 위함입니다.

도입 효과

(위 사진은 저희 팀에서 실제로 작업중인 프로젝트의 깃 네트워크 캡쳐 사진입니다.)

우리팀의 깃 플로우의 가장 큰 특징인 배포 브랜치인 develop, test, master 과는 별개로 work라는 메인 브랜치를 통해 항상 동작가능한 코드를 관리하는것을 위 사진을 통해서 확인하실수 있으실 겁니다.

동료들간의 간단한 브랜치 규칙을 세움으로써 언제든,누구나 깃 네트워크를 보아도 현재 프로젝트 상태를 확인 할 수 있으며 손쉽게 브랜치 생성 할 수 있고, 배포 할 수 있습니다.

이러한 git-flow 사용으로 팀내의 모든 개발자들이 간편하고 손쉽게 코드개발, 형상관리, 배포를 진행하고 있습니다.

코드리뷰

목적

우리팀은 다음과같은 목적을 위해 코드리뷰를 진행 하고 있습니다.

코드리뷰를 통해 팀 컨벤션을 맞춘다.

코드리뷰를 통해 팀내의 모든 프로젝트를 함께 참여한다.

좋은 코드를 작성하기위해 함께 노력한다.

모든 코드들에 유대감을 갖는다.

코드리뷰의 목적은 절대로 경력자가 주니어들을 상대로하는 코드검사가 아닙니다.

코드리뷰는 우리팀의 코드를 함께 개선시켜 나가기위한 수단이며 늘 오류없이 실행가능한 코드 상태를 유지 시키기위해 함께 만드는 보루 입니다.

도입 효과

(위 사진은 코드리뷰 예시를 위한 AWS 에서 제공하는 CodeGuru 서비스 캡쳐 화면입니다.)

선행하여 먼저 소개해드렸던 우리팀의 Git-flow를 통해서 모든 개발 내용은 work 브랜치로 PR(Pull Request)를 통해 merge 하도록 설정 되어있습니다.

work 브랜치의 PR들은 모두 Default Reviewer (현재는 3/8)의 approve를 받아야지만 merge를 할 수 있게끔 설정을 해 두어 경력에 상관 없이 모든 팀원들이 PR이 올라오면 코드를 보고 질문 할 수도 있고, 오류를 찾아줄 수도 있으며, 개선사항을 제시해 줄 수도 있습니다.

또한 코드리뷰를 통해 팀에서 정의한 코드컨벤션을 맞추는 과정을 통해서 어떤 팀원이 작성한 코드들이 합쳐지더라도, ‘마치 한사람이 짠 코드’처럼 코드를 유지시켜 모든 팀원들이 모든 코드를 쉽게 파익하고 수정 할 수 있습니다.

코드리뷰를 통해서 좋은 코드를 유지시키는 목적도 있지만 프로젝트의 모든 코드에 디같이 참여 함으로써 직접 개발한 코드만이 ‘내 코드’가 아니라, 전체 프로젝트가 모든 팀원들이 함께 만들어 나간 결과물이라는 마음가짐을 가질수 있게 된 것 같습니다.

테스트코드

목적

테스트 코드를 작성하는 목적은 다양하지만, 크게 정리하자면 다음과 같이 정리 할 수 있을것 같습니다.

리팩토링

품질보장

여기서 리팩토링이라 함은 또 여러 의미가 있을수 있는데,

첫째, 테스트 코드를 작성하는 과정에서 테스트를 잘 할수있는 코드로 리팩토링 하면서 더 좋은 코드를 만들어 낼수 있다.

둘째, 테스트 코드가 잘 작성되어 있다면, 메인 코드를 리팩토링 하면서 다양한 사이드 이펙트에 대해서 검증 할 수 있다.

품질보장 또한 두가지의 의미를 줄 수 있습니다.

첫째, 적어도 테스트 케이스에 한해서는 서비스 품질이 보장 할 수 있습니다.

둘째, 코드추가/변경 건에 대해서 개발자의 품질에대한 불확실성을 줄여 줄 수 있습니다.

위와같이 테스트 코드를 작성함으로써 좋은 결과를 낼 수 있지만 실무에서 테스트 코드에 입문하려면 여간 불편한 점이 많은것이 사실입니다. 따라서 형식적인 테스트코드 작성이 되지 않도록, 팀에서 테스트 전략을 세우는것이 중요 할 것 같습니다.

도입효과

(위 사진은 저희 팀에서 실제로 작업중인 프로젝트의 테스트 캡쳐 사진입니다.)

우리팀은 실용적인 테스트 코드 작성을 위해 팀 테스트 전략을 세웠습니다.
그중 주요 전략 몇가지만 소개드리자면 다음과 같습니다.

테스트 공통

테스트를 위한 코드를 만들지 않는다.

코드 커버리지는 중요하지 않다.

하나의 테스트케이스에서는 하나의 로직을 검증한다.

테스트 이름을 잘 지어 누가보아도 어떤 로직에대한 검증을 진행하는지 알 수 있게 한다.

통합 테스트

모든 api는 실제 데이터 기반으로 적어도 하나의 성공하는 통합 테스트를 작성한다.

가능하다면 mock 사용 없이 데이터단 까지 검증을 진행한다.

호출에 필요한 파라미터 > 결과값에 대한 정의 및 검증을 위한 테스트를 진행한다.

단위 테스트

서비스 로직 (서비스 메서드)를 기준으로 유닛테스트를 진행한다.

유닛테스트 과정중에서는 실제데이터에 대한 검증을 진행하지 않아도 좋다.

(해당 테스트 전략 소개 링크 : https://taes-k.github.io/2019/09/27/spring-junit-testing-strategy/)

위와같은 전략을 따라 테스트 코드를 작성함으로써 성공하는 통합 테스트코드만을 작성하는것을 시작으로, 로직상 검증이 필요한 부분에대해서 테스트코드를 계속해서 작성해 나가고 있습니다.

프로젝트의 규모가 커질수록 추가/변경 사항이 있을때 서비스에 대한 검증이 손쉽게 진행 될 수 있고 무엇보다도 작업자가 직접 작업한 부분이 아니더라도 믿을수있는 검증 로직이 있다는 점에서 더 마음놓고 개발을 진행 할 수 있다는 점이 테스트 코드 작성의 큰 장점임을 느끼고 있습니다.

정적분석

목적

위의 테스트코드 작성이, 서비스 품질을 보장하기 위함이었다면, 정적분석은 좋은 코드의 품질을 보장하기 위해서 사용합니다. 작업자가 좋은 코드를 작성했다고 하더라도 정적분석 툴은 언제나 더 좋은 코드를 만들 수 있다는 생각을 가질수 있게 해주고 더 좋은 코드를 작성하기 위해 노력하게끔 해 줍니다.

도입효과

(위 사진은 저희 팀에서 실제로 작업중인 프로젝트의 정적분석 툴 캡쳐 사진입니다.)

현재 우리팀은 SonarQube, SonarLint를 통한 정적분석을 진행하고 있습니다.

모든 코드는 테스트코드, 코드리뷰의 과정을 거치지만 그럼에도 불구하고 미처 발견 못한 누락사항들을 상호보완적으로 정적분석툴이 잘 캐치 해주고 있습니다.
이러다 보니 정적분석툴에서 잡아주는 code smell 을 통해서 잘못된 코딩습관을 개선해주기도 하며 코딩 -> 분석 -> 개선 이라는 일반적인 순서와는 오히려 반대로, 스스로 개선된 코딩을 하기위해 한번더 생각하게끔 만들어주는 긍정적인 역할을 해 주고 있습니다.

좋은 개발 문화

단순히 기획된 내용을 ‘개발’만 하는것이 아닌 주도적으로 품질(서비스 품질, 코드품질)을 개선해 나가고 개발자 개개인의 실력을 향상이 소프트웨어 품질상향을 가지고 온다고 믿는것 에서 진짜 개발 문화가 시작된다고 말 할수 있을것 같습니다.

위에서 우리팀에서 개발문화를 만들기 위해 적용중인 수단들에 대해서 설명을 드렸는데요, 좋은 개발문화를 만든다는것은 단순히 이런 수단들을 팀, 회사의 프로세스로 강제 적용 시킨다고 되는것이 아니라, 그 수단들의 목적과 도입의의를 모든 구성원들이 이해하고 자발적으로 지켜나가려고 할 때, 즉 프로세스가 아닌 문화가 될때 좋은 개발 문화를 만들 수 있다고 말씀 드리고 싶습니다.

위의 다양한 수단과 방법들은 동료들과 함께 더 좋은 개발을 해 나갈수록 있도록 만들어주는 촉진제일뿐 함께 좋은 개발, 서비스를 위해 고민할때 좋은 개발 문화가 시작된다는것을 믿습니다.

물론 이 시작부터 난관인 팀이나 회사들이 있을수 있습니다. 우리팀, 우리회사의 좋은 개발 문화는 지금 이 글을 보고계신 독자분 으로부터 충분히 시작 될 수 있습니다.

좋은 기사 하나를 공유드립니다 (https://www.venturesquare.net/2471)