brunch

라이킷 39 댓글 4

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Kiyoung Lee Feb 27. 2017

스타트업에서 개발 문화 만들기 (아직 진행중..)

Git 어떻게 사용하세요?

들어가기에 앞서

이 포스팅은 글쓴이가 재직 중인 스타트업에서 진행되고 있는 개발 문화 만들기에 관한 글이며, 현재 진행 중인 부분에 대해 공유하고 올바른 방향을 찾아가고자 함을 목적으로 하는 글입니다. 특정 개발 방법론이나 기술 소개가 아님을 말씀드립니다.

이직하기 전부터 하고 싶었던 일중에 하나가 자동화 테스트, 빌드 및 배포 그리고 코드리뷰 문화를 만들어 보고 싶었다. 혹자는 "개발할 시간도 없는데 그런 걸 뭐하러 해?"라고 말을 하곤 한다. 아직 많은 경험을 해보지 않았고, 완벽하게 적용하여 사용 중이라고도 할 수 없지만 상식적으로는 그렇다.

1류 IT업체에서 빠르면 1주일 또는 1달 주기로 제품의 배포 주기가 짧아지고 있다고 한다. 1달 만에 솔루션을 만들어 납품한다고(?) 심지어 버그도 미세하게 존재하며 고객들이 제품을 사용하기에 거의 문제가 없을 정도의 품질로 짧은 주기에 출시된다. 수많은 기술과 노하우가 있겠지만 가장 중요한 키워드는 '자동화'라고 생각한다.

이전까지는 올바른 개발 문화에 대해 제대로 배운 적이 없었고, 이직 기간에는 국내에서 내가 원하던 개발 문화가 정착되어있는 팀을 찾기는 어려웠다.

특히나 하루하루 시간이 소중한 스타트업에서는 어떻게 보면 개발자들 모두가 몸에 배어있지 않고 문화가 형성되지 않는 이상 매우 힘든 개발환경인 것 같다. 다행히도 현재 개발팀에 조인했을 때 개발 팀분들에게 내가 하고 싶은 개발 문화의 청사진을 공유하고 단계별로 진행해볼 수 있게 되었다.

자동화에 대한 경험이 없기에 참고자료를 먼저 읽어보는 것이 첫 번째 일이었다. 그중 오픈소스 프로젝트에 관한 이야기로 2~3년 전부터 오픈소스가 대중화되면서 전 세계에 있는 수많은 개발자들이 git이라는 형상관리 툴 아래 하나의 프로젝트를 만들어가고 심지어 최근에는 대기업들조차 오픈소스 프로젝트로 제품을 구성하는 단계인 것 같다.

얼굴도 한 번안 봤을지도 모르는 개발자들이 개발한 소스들을 어떻게 정리하고 빌딩 시켜나가는지는 github 서비스가 많은 역할을 해주고 있다. 물론 github 이 자동화를 도와주는 툴은 아니지만 프로젝트 협업에 있어 매우 대중화된 서비스이고, 현재 사내에서는 gitlab이라는 서비스를 이용하여 협업을 진행하고 있다.

글쓴이가 생각한 프로젝트에서 git을 사용한다면, 개발자가 할 수 있어야 하는 요구사항

이전 버전으로 언제든지 복구할 수 있는 환경

배포(master) 브랜치와는 별개로 진행되는 개발

같은 프로젝트 안에 여러 개발자가 공동작업을 진행 시 개발자 간의 코드 충돌 최소화 및 개발 의존성 x
(이거 고쳐도 돼요?, 허락받고 작업하기 등..)

버그를 수정하고 바로 배포(master) 브랜치에 적용할 수 있는 환경

다른 기능 및 차기 버전을 개발 중인 상황에서 언제든지 긴급 업데이트 가능한 환경

GitLab 등 코드 호스팅 서비스를 사용할 때 요구사항

코드리뷰

Issue 및 Wiki 사용

모든 문제를 이슈화 하는 것

회고록

테스트 케이스

Release note

Bug count check

Git

현재 개발팀은 git 적응 중에 있다.

내가 처음 조인했을 때 GitLab을 도입한 지 채 1달이 안되었으며 팀원 전체가 전에는 git이라는 형상관리에 대해서 사용해본 적도 없는 상태였다. 그래서 글쓴이도 부족하지만 전 직장에서 git을 사용했던 경험을 살려(?) git을 본격적으로 사용하기 시작했다. 마침 전 직장에서도 git을 가장 먼저 도입한 프로젝트 팀에 있었기 때문에 git에 대해서 여러 케이스들을 먼저 접할 수 있게 되었고 사용에 있어서 거부감은 없던 상태였다.

git을 쓰면서 가장 유용하게 사용하고 있는 기능이 언제든지 커밋된 프로젝트에 대해 자유롭게 롤백(rollback)하고 원하는 커밋으로 돌아갈 수 있는 환경. 돌아가고자 하는 커밋을 알고 있다면 언제든지 돌아갈 수 있는 형상관리의 기본 기능 중에 하나다.

Git을 처음에 명령어 기반으로 접했다면 거부감이 컸을 것이다.

굉장히 유연한 시스템인데 반해 커맨드 라인에서 보이는 작업의 히스토리는 글쓴이 같은 초보 개발자에게 어려워 보일 수 있다. 명령어들이 생소하기 때문에 동작 방식이 잘 이해가 안 갈 수도 있고, 처음 실무에 바로 적용하기에는 두려웠던 것이 사실이다. 기존 .NET 의 TFS GUI 환경에 익숙해 있던 나는 SourceTree라는 GUI 툴을 이용하여 git에 입문했다.(강추!)

언급했던 기능의 명령어는 git reset이라는 명령어이다. 3가지 옵션을 제안하지만 필자는 Hard 옵션을 가장 많이 쓴다. 뒤돌아볼 것 없이 모든 내용을 선택한 커밋으로 롤백(rollback) 하려고 할 때 매우 유용하게 쓰고 있다. 또는 이전 커밋에서 작성했던 모듈이나 함수의 코드가 궁금할 때 돌아가서 보곤 한다.

또는 IDE에서 제공하는 커밋 비교를 활용하기도 한다. 기존에 형상관리를 적용하지 않았다면 이 기능만으로도 git의 편리함을 느낄 수 있다. 추가로 cherrypick, revert, rebase, merge, squash, stash 등 다양한 명령어들이 있고, 명령어의 동장 방식과 개념을 이해하며 다양한 상황별로 입맛에 맞게 사용하는 재미가 있다.

Branch 전략

조금 더 나아가서 배포(master) 브랜치에서 혼자 작업 시에는 별로 상관이 없지만 해당 프로젝트에 대해 2인 이상 작업하게 되면 같은 부분에 대해 동시에 코드 수정이 들어가며 변경사항에 대해 충돌이 발생하게 된다. 때로는 버그가 있는 변경사항을 잘못 병합(merge) 한 채 배포(master) 브랜치에 푸시하여 현재 돌아가고 있는 서비스에 장애가 발생한다던가 롤백(rollback)을 해야 하는 끔찍한 상황이 발생하기도 한다.

이때 git에서 제공하는 브랜치에 대해 운영 전략을 생각하게 된다. 현재 사내에서는 배포(master)와 개발(develop) 브랜치 그리고 개발자별 이슈(daily) 브랜치로 구성을 시작했다. 이는 배포된 버전과의 의존성을 분리하고 더 깊게는 개발(develop) 브랜치 내부에서도 개발자 간의 작업에 있어서 상호 작업에 의존성이 생기지 않게 하기 위한 방법이다.

각 회사별로 브랜치 전략이 다를 수 있겠지만 위에 설명한 4 가지 배포(master)/개발(develop)/개발자이슈(daily) 브랜치는 코드 리뷰 및 상호 의존성을 정리하는데 좋은 전략인 것 같다. 각 개발자는 작업을 시작하기 전 자신의 이름_날짜로 구성된 브랜치를 개발(develop) 브랜치로부터 생성한다는 규칙을 가지고 있다. 개발자 이슈(daily)에서 작업한 브랜치에 대해 마지막 커밋/푸시를 완료한 후 개발(develop) 브랜치에 병합(merge)한다.

Git에서 가장 골치 아픈 것 중에 하나가 충돌 해결이다.

충돌이 나면 git에서는 로컬에서 해당 브랜치에 있는 소스와 서버에 올라가 있는 소스 차이에 대해 주석처럼 표기를 해준다. 하지만 커맨드 기반의 개발에 익숙하지 않은 개발자들은 자신의 멀쩡한 코드에 이상한 주석 등이 들어가 있는 것을 보고 당황할 수밖에 없다.

처음부터 커맨드 기반의 개발을 했으면 낯설지 않았을 수도 있을 거라는 생각을 했다. 오히려 윈도우 개발자라 더 당황스러웠던 것 같다. 하지만 소스트리 같은 GUI 환경에서는 충돌 난 소스를 직접 열어 병합(merge)할 수도 있지만 윈도우 환경에서는 외부 병합(merge) 툴을 연결해놓으면 편리하게 나의 브랜치의 소스와 서버에 올라가 있는 소스를 편리하게 병합(merge) 할 수 있다.

코드리뷰 - Pull Request(Merge Request)

여기까지 사용법에 팀원들이 익숙해졌을 때, 자 그럼 이제 코드리뷰를 하고 싶은데 어떻게 하는 것이 좋을까? 각자의 작업내용을 가지고 회의실에 모여서 리뷰를 할까? 글쓴이를 포함한 대부분이 주니어 포지션인 우리에게 자신이 다루는 플랫폼이나 언어를 제외하고 타 개발자의 언어를 보기란 부담스럽고 이해가 안 되는 부분이 있는 것이 사실이었다. 오히려 리뷰를 해주는 역할이 아닌 리뷰를 요청한 개발자에게 코드에 대해 설명을 듣고 있는 상황이 발생했다. 처음 코드 리뷰 당시 한 명의 코드를 리뷰하는데 2시간이 흘렀고 아무리 코드 리뷰라고 하지만 비효율의 끝을 달렸다.

하지만 '코드리뷰' 오픈소스 개발에서는 필수적이다. 아무런 정보도 없이 개발자인지 아닌지도 모르는 사람이 특정 오픈소스에 코드 변경을 가하려고 시도했을 때 프로젝트 담당자는 변경을 제한하고 github에서는 'pull request(이하 PR)'라는 방식으로 프로젝트 주인에게 코드를 리뷰받고 올리는 프로세스가 적용되어있다.

같은 맥락으로 사내에서도 각각의 개발자가 작업한 커밋을 배포(master) 브랜치 또는 개발(develop) 브랜치에 병합하려고 할 때 적용시켜 보았다. 물론 개발팀 내부적으로 아무런 룰이 없다면 해당 개발자가 스스로 병합하여 푸시할 수 있다. 만약 이렇게만 사용한다면 git 이 제공하는 수많은 기능 중에 버전 관리에 해당하는 부분만 사용하는 단순한 방법인 것 같다.

나도 마찬가지로 git을 처음 접했을 때 커밋하는 것이 왜 이렇게 두려운지 커밋 후 마스터 브랜치에 병합(merge)할때 충돌이 안 나기를 간절히 바라며 충돌 없이 병합(merge) 되었을 때 안도의 한숨을 내쉬었던 적이 있다. 하지만 단순 버전 관리의 용도 또는 소스를 하드에 백업해두기 불안해서 git서버에 올린다는 개념으로만 git을 사용하고 싶지는 않았고, 다른 기업들의 코드리뷰 적용기 등 을 보며 한 단계씩 시도해나갔다.

타사의 코드리뷰 포스팅들을 보니 대부분 비슷한 시행착오와 고민들을 하고 있었고, 코드리뷰 방법 중 선정한 것이 github의 PR기능을 통한 코드리뷰 방법이었다.

PR은 'Pull Request'란 뜻 그대로 내가 작업한 내용물이 있으니 내 브랜치를 당겨(검토 후 병합해) 주세요.라는 개념으로 이해하고 시작하면 가장 쉽다.

위에서도 언급했듯이 병합(merge)에 있어 개발자이슈(daily) 브랜치에서 작업하고 PR을 올렸을 때 어떻게 병합할 것인지 개념이 헷갈리기 마련이다. Git에서는 병합(merge)의 방법을 기본적으로 3가지나 제공해주고 있기 때문이다. rebase/merge/pull로 병합을 (요청하는 or 하고자)하는 브랜치의 관점에 따라 다른 동작이 일어나는데 처음에는 매우 혼란스럽다.

그래서 룰을 정한 것이 위 개념을 적용하여, 병합하고자 하는 브랜치(기준 브랜치! 보통은 배포(master) 브랜치)에서 PR 요청이 온 브랜치를 pull 하는 것으로 병합(merge)을 실시한다. 이렇게 룰을 정해놓으면 PR의 의미가 좀 더 명확해지고 병합에 대한 명령어에서 혼란을 줄일 수 있다. 이 방법이 익숙해졌을 때 추후에 병합의 기능들에 대해서 시험해보고 알맞게 사용하는 것이 좋은 것 같다.

PR의 가장 큰 장점은 서로 바쁜 개발자들끼리 굳이 회의실을 잡지 않아도 굳이 시간을 맞추지 않아도 서로가 편한 시간에, 원하는 시간에 코드리뷰를 요청하고 코드리뷰를 할 수 있었다. 심지어 웹상에서, 본인 자리에서 할 수 있고 코멘트 기능, 거절(reject) 또는 점수 매기기 등 다양한 커뮤니케이션을 할 수 있는 기능들이 적용되어 있었다.

Git Lab 에서 진행중인 Merge Request.

하지만 위에 적었던 바와 같이 우리는 모든 플랫폼에 대해 코드리뷰를 할 수 있는 역량이 아니었다. 따라서 코드리뷰도 리뷰지만 일단 pull request를 작성하는 것에 익숙해져야 했고, 내부적 룰은 이랬다. 같은 플랫폼에서 작업하는 개발자들끼리는 무조건 리뷰 후에 PR을 통한 병합 작업을 진행하지만 플랫폼의 1명의 개발자만 포진한 경우에는 PR을 올리고 다른 개발자들도 리뷰는 같이 한다.

하지만 시간이 안 맞거나 나의 플랫폼이 아니기 때문에 관심도가 떨어져 리뷰가 잘 안될 수도 있기 마련이다. 이럴 때는 리뷰가 안된다고 여기저기 리뷰 요청을 하면 서로 스트레스가 된다. 나의 플랫폼이 아니기 때문에 코드가 맞는지도 모르겠고, 요청하는 사람은 바쁜 개발자들한테 가서 리뷰해달라고 PR 요청할 때마다 해야 하고 스트레스가 여간 생기는 게 아니기에 단독 플랫폼을 진행하는 개발자는 PR을 올리되 하루 안에 별다른 리뷰가 달리지 않으면 스스로 병합(merge)하는 룰을 일단 만들었다. 하지만 이방식에 대한 문제점은 아직 어떻게 풀어야 할지 숙제로 남아있다.

이 방법은 PR작성과 코드리뷰를 도입함에 있어 꼭 리뷰를 하기보다 과도기적인 단계로 내가 작업한 코드를 무작정 병합(merge) 하는 것이 아닌 PR을 올리는 과정을 통해 남에게 나의 코드가 보인다는 생각을 가지고 코드에 신경을 쓰게 되고, PR을 작성하면서 내가 작업한 커밋에 대한 내용 정리도 한 번 같이 할 수 있기 때문에 혹여나 리뷰가 안되더라도 작업물의 PR화를 채득 하기 위해 시행하고 있다.

독립 플랫폼에 대해서는 어떻게 해야 할지 여전히 문제가 존재하지만 공동작업을 하는 플랫폼에서는 리뷰를 함으로써 바로 다음 배포에서 효과가 나오기 시작했다. 이전에 사내에서도 코딩 규칙 등 세미나 형식으로 공유하고 강조해봤지만 리뷰를 하기 전까지는 세미나를 하고도 전혀 고쳐지지 않았던 사례가 있다.

하지만 리뷰 과정이 들어가면서 잘못된 코드에 코멘트가 달리고 지적받은 개발자는 다음에도 동일 실수를 하지 않기 위해 다음 작업에서는 알아서 실수를 수정하는 효과가 바로 나타나고 있었다. 줄 간격 / 탭 스타일등 작은 부분이었지만 변화가 시작되는 것이 중요한 포인트다.

코드리뷰 과정 - 작은곳 부터 시작해보면 어렵지 않아요.

Issue & Wiki

PR이 익숙해질 때쯤 이슈와 위키 탭이 눈에 들어오기 시작했다. 사실 개발 이슈 같은 경우는 사내 메신저로 실시간으로 주고받지만, 실시간으로 주고받는 것 외에 기록이 남지 않아 추후에 해당 내용에 대해 문제가 생겼을 때 메신저의 대화 내용을 찾아보기란 여간 까다로운 일이 아니다. 그리고 메시지에는 모든 내용이 디테일하게 들어가 있는 것이 아니고 당시의 요약본이다 보니 그때 이 작업을 왜 하려 했는 제 무엇이 문제의 본질이었는지, 문득 '아 이 작업하기로 했었지(?)'라고 소파에 낀 500원을 발견하듯 발견하지만 이미 이번 스프린트 일정에는 고려가 안된 개발 항목이기 때문에 일정에 차질이 생기기 마련이다.

이런 문제점은 개발팀의 고질적인 문제였고 이슈관리와 문서관리가 전혀 안돼서 이슈관리시스템(JIRA)을 도입하려고 검토 및 교육을 다니던 상태였고, JIRA를 적용시키기 전까지 그럼 이 문제를 방치하고 있을 수는 없었다. JIRA를 설치하고 나서도 사용법 및 운영방법이 익숙지 않아 개발자들 모두가 적응기간이 최소 2~3달은 걸릴 것이 분명했기 때문이다. 이에 간단하게 게시판 형태로 쓸 수 있는 이슈부터 작성해 나가기 시작했다. 이슈에 제일 먼저 작성했던 것은 테스트 케이스이다. 테스트 케이스와 더불어 구현 항목 명세라고도 할 수 있겠다.

아직 단위 테스트 코드를 도입하지 않았기 때문에 임시방편으로 작성한 것이기도 하고 기존에 개발팀의 개발방식은 디자이너 분께서 레이아웃 가이드 문서를 주시면 구현 항목에 대한 리스트업 없이 일단 레이아웃 잡기에 먼저 들어가는 개발팀이었다. 따라서 디자인 가이드 레이아웃을 받고 먼저 내가 구현해야 할 항목과 개발이 완료되었을 때 어떤 기능에 대해서 충족해야 함을 명세하는 시트를 작성하기 시작했다.

추후 이 시트는 단위 테스트 함수가 될 것임을 기약하며 작성했다. 이슈에 굳이 작성한 이유는 이슈는 열고 닫을 수 있는 기능이 있기 때문에 더 유용했다. 해당 테스트 케이스에 대해 좀 더 견고한 케이스를 작성해 나가기 위함이었다. 개발 당시 작성한 테스트 케이스가 완벽할 것이라는 보장이 없기 때문이다. 작성한 대로 개발하다 보면 추가되는 항목도 있을 것이고, 개발 후에 배포가 된 후에도 해당 모듈에서 버그가 나올 수도 있는 가능성이 있다.

이때 다시 이슈를 오픈시켜 테스트 케이스에 누락 항목을 추가하고 커버리지를 좀 더 좁혀나가는 것을 목표로 했다. 화장실 청소를 할 때도 청소 리스트를 시트에 적고 체크하는 시대에 개발 항목에 있어 문서(?) 하나 없이 개발을 진행하는 것은 너무 불안한 프로세스다. 현재는 아래와 같이 시트를 작성하고 해당 항목을 기준으로 구현, 그리고 배포전에 점검을 한번 더 하고 제품을 배포하게 된다.

Release Note 그리고 회고.

배포가 완료되면 다음날 개발팀에서는 회고와 ReleaseNote 작성을 진행한다. 먼저 회고에서는 여느 멋진 팀과 같이 포스트잇을 사용하거나 카드게임, 점수를 적는 등 디테일한 회고는 아니다. 다만 이번 개발에서 서로가 좋았던 점, 잘했던 점, 그리고 아쉬웠던 점, 바라는 점, 추후에 고쳐졌으면 하는 점, 요약 정도로 이번 개발 사이클에 대해서 서로가 실수한 점 (ex테스트 케이스는 작성했지만 마지막에 귀찮아서 테스트 안 하고 배포하였더니 버그 났다.. 등) 하지만 비난하지 않는 것이 원칙이다.

사람이니까 그 순간 귀찮을 수 있고 실수할 수 있다는 전제가 깔린 상태에서 모든 개발자들이 회고에 임한다. 물론 테스트를 안 하고 제품이 나갔을 때 버그가 발생하는 것은 케이스에 따라 매우 크리티컬 한 문제가 될 수도 있다. 문제의 심각도가 어찌 됐던 이미 나가버린 제품에 대해 시간을 되돌릴 수는 없는 일이다. 이에 만약 문제의 발생 당사자가 있다면 스스로가 가장 반성할 것이고, 이번 잘못을 통해 다음번에는 귀찮더라도 한 번 더 꼼꼼히 하는 개발자로 한 단계씩 성장해 나가는 것을 목표로 하고 있다.

회고록 예시

처음에는 위키에 무엇을 적을까 망설이다가. 일단은 회고록, ReleaseNote로 위키를 채워나가기로 했다. 이렇게 회고가 끝나면 ReleaseNote 작성에 들어간다. 각자 맡은 플랫폼에 대한 업데이트 사항 등을 명시하고 날짜 및 버전을 기입한다. 노트의 맨 마지막에는 현재는 모바일 개발자들만 시행하고 있지만 fabric에서 배포하기 직전 버전에 대한 Crash 율 통계치를 올리곤 한다.

이를 보고 있자면 마치 헬스장에서 InBody를 하는 느낌이랄까. 버전마다 기록되는 bug와 crash율을 보면서 묘한 성취감을 느끼곤 한다. 추가로 위키의 다른 페이지에는 지금까지 이슈에서 적었던 Test Case에 대해 대시보드(?) 형태로 나열하여 해당 테스트 케이스별 배포 날짜를 명시해놓는다.

이는 해당 모듈에 대한 테스트가 끝났음을 반증하며, 해당 모듈에 대해서는 테스트가 보장되어 배포된 것이니 버그가 발생하거나, 코드 리팩토링을 하지 않는 한 해당 모듈에 대한 테스트는 다음 버전에서 고려되지 않아도 됨을 반증하는 페이지이다. 물론 중간에 버그가 나면 명시했던 날짜를 지우고 해당 케이스들의 플래그를 리셋시킨다.

Release Note, 버그수는 민망하므로 모자이크 :)

빌드 및 배포 자동화

Git을 도입하고 얼마 되지 않았을 때, 나는 단위 테스트 및 테스트 자동화는 고사하고 하루빨리 배포 자동화를 완성시켜야겠다는 마음이 간절했다. 개발 사이클에 있어 자동화된 곳은 없었고 모든 것은 수작업으로 진행되고 있었다.

심지어 서버 배포 또한 Git의 배포(master) 브랜치에 있는 파일로 전체 동기화를 시키는 것도 아닌 FTP로 접속하여 수정사항이 일어난 파일만 교체한다던가, 서버에 직접 붙어서 서버 내부 파일을 실시간으로 수정하는 일들이 빈번했다. 선 서버 수정 후 git 커밋 등의 사이클이 개발자들의 입맛에 맞게 진행되고 있었다. 오히려 git을 쓰기 전보다 더 관리 포인트가 늘어난 기분이었다.

어떤 방식으로 진행되든 기능 동작 잘하고 관리가 잘되면 누구 하나 뭐라 할 사람이 없지만 개발자는 사람이고 실수가 나오기 마련이다. 시간이 지날수록 변경이 일어난 부분에 커밋을 했는지, 서버와 코드 동기화는 맞춰 저 있는지, 어제 됐던 기능이 새로운 개발자가 조인하면서 커밋하고 배포했더니 잘되던 기능이 안된다던지 해당 시기에 주어지는 본 개발 업무보다 흩어진 코드 조각을 그때그때 상황에 맞춰 동기화하는데 더 많은 리소스가 들어가고 있었다.

서비스가 커질수록 자동화를 했다면 단 몇 분 안에 해결될 내용들의 작업범위가 점점 커지면서 일의 효율은 점점 더 비효율적이 되어가고 있었다. 이에 Jenkins를 통하여 Mobile 플랫폼은 지속적 빌드를, Web과 서버 배포는 스크립트를 통하여 각각 develop 브랜치는 테스트 서버로, master 브랜치는 각 Release 서버로 배포하도록 자동화를 진행하였고, jenkins에서 제공하는 모니터링 에드온을 통해 사내에 모니터링 컴퓨터 한편에 배치해두고 모니터링을 진행하고 있다.

사실 Jenkins 같은 CI 도구는 테스트 자동화 및 코드 커버리지 확인이 들어가야 진국이 되어 개발 산출물의 퀄리티가 향상되겠지만 위에도 적었듯이 진행 중인 사항이며, 추후 진행할 Step 에 단위 테스트에 대한 항목을 염두에 두고 있다.

마무리하며..

우선 가장 먼저 개발팀 팀원분들의 적극적인 협업으로 짧은 기간 안에 개발 사이클을 변화시킬 수 있어서 너무 감사하다는 마음을 전하고 싶다. 정보 공유와 시시콜콜한 개발 이슈에 대한 지속적 대화는 개발자에게 매우 귀찮은 일이지만 커뮤니케이션의 재미에 대해 그리고 진행 사항을 명확히 서로 정의하고 진행하는 것에 있어 의견 차이 없이 하나의 스프린트가 완성되었을 때 느끼는 성취감은 생각대로 바로 코딩했는데 빌드, 테스트, 실행이 오류 없이 한 번에 되는 것만큼 기쁜 일인 것 같다. 다음번엔 단위 테스트 적용기와 테스트 자동화에 관련된 주제로 포스팅을 해보고싶다. 변화할 수 있는 개발팀이어서 좋다!