만병통치약 Agile이 왔습니다!!
Agile Process 의 거짓말
스푼 라디오 서비스 플랫폼 팀의 메시징 파트에서 채팅 서버 개발을 맡고 있는 Elliott입니다. 개발 프로세스의 정립과 개선에 대해서 개인적으로 생각하는 것들을 공유드립니다.
Agile을 시작하면서…
Agile하게 일하자!! 우리도 Agile 프로세스를 도입하자!!
우리는 개발 조직 또는 IT 회사에서 일을 하다 보면 Agile을 직.간접적으로 경험하게 된다.
하지만 그들은 우리를 속였고 편해지지도 업무속도가 빨라지지도 않았다.
Agile의 핵심 내용
Agile이 무엇인지 찾아보면 여러 가지 정보를 확인할 수 있는데 결국 Agile 프로세스라는 것은 기존 폭포수 모델과 같은 오래되고 변화하기 어려운 프로세스를 벗어나서 고객의 변화하는 요구 사항에 빠르게 대처하기 위해서 제품을 출시하기 위한 사이클을 짧고 더 빠르게 가져가는 일 하는 방식을 의미한다.
Agile은 만능 도구일까?
위의 사진은 개인적으로 좋아하는 사진 중에 하나인데 Waterfall 모델과 IT업계에서 찬양하는 Agile를 비교한 사진이다. 이 그림에서 어떤 차이를 찾아볼 수 있을까? 화살표 일부(사이클)을 제외하곤 제품을 출시하는 과정에서의 스텝은 다를 게 전혀 없다.
그럼에도 왜 Agile에 대해서 이렇게 찬양하는 사람이 많을까??
그동안 다녔던 회사들에서 Jira 관리와 프로세스에 대하여 개인적으로 고민을 오랫동안 해본 결과로는 다들 현재 업무에 너무 많이 지쳐있는 것이 가장 큰 이유라고 생각된다. 그래서 개발 조직의 인원들은 어떤 프로세스가 우리를 이 업무의 늪에서 구해줄 수 있을 것이라고 “희망”하게 되는데 그로 인해서 새로운 것처럼 보이는 무언가를 사용하여 일하는 방식이 일종의
“도깨비 방망이”쯤으로 여겨지는 것이다.
그럼 일의 절차가 필요 없을까요?
그렇지는 않다고 생각한다. 우리는 다양한 유관부서와 협업을 통하여 어떤 서비스 또는 제품을 출시하는데 이 과정에서 커뮤니케이션에 필요한 또는
“일반적”인 상황에서 어떻게 할 것인가에 대한 약속은 필요하다.
문제는 구성원들이 고려해야 할 예외 상황과 경우의 수가 프로젝트 중에 너무 많다는 것이다. 기본적으로 사람이라면 한 번에 받아들이고 빠르게 판단할 수 있는 인지적인 한계가 반드시 존재하는데…(본인이 폰 노이만이 아니라면..) 이런 다양한 경우의 수에 대한 결과 도출 프로 세스를 전부 정립하더라도 구성원들이 이를 빠르게 따라올 수 없다는 것이 문제다.
그럼 우리가 약속해야할 것들은 무엇일까?
우리가 제품을 개발하면서 어떠한 것들을 지키도록 정의해야 할까?
- 유관부서와 공유할 문서의 규격화
- 회의에서는 최대한 해당 회의에서 이야기될 주제에 대해서만 논하고 빠르게 끝낸다.
- 회사 또는 프로젝트의 목표는 반드시 관련인원들에게 공유된다.
- 결정권자는 반드시 회의에 참여한다.
위의 정리한 내용들을 보면 알 수 있듯이 특정 상황에 대한 루틴이 아니라 큰 틀에서의 단순한 규칙만을 가지고 있는데 위에서 얘기한 것처럼 프로세스를 만들겠다며 이런저런 복잡한 Rule 들을 추가하다 보면 불필요한 의사소통을 하는데 너무 많은 시간이 소요될 뿐만 아니라 프로젝트 관리자는 구성원들에게 어떻게 일해야 할지에 대한 질문을 엄청나게 받을 것이다…
(규칙이 많아지면 관리자도 어떻게 해야할지는 잘 모른다.. 그저 그 상황에 따라서 판단할 뿐이다.)
진짜 “도깨비 방망이”?
프로세스가 업무효율 상승에 큰 효과가 없다면 우리는 어떻게 대처해야할까?
진짜 우리를 늪에서 구해줄 용사님은 계실까?
필자도 개발자로써 일을 하면서 운영 업무를 하거나 협업을 하면서 다양한 상황에 부딪혀왔는데 어떤 프로세스가 팀과 나를 구원해 준 적은 단 한 번도 없었다.
그저 어떤 방식으로든 현재 상황에 대한 문제점을 다른 무언가를 탓하기 위한 것이라고 많이 느끼게 됐는데 단 한 번 일을 하기가 너무 편하고 제품을 개선하기 위한 다양한 생각을 할 수 있었던 때가 있었는데 그것은 TDD 를 제대로 사용하던 시기였다.
TDD(Test-Driven Development)
테스트 주도 개발이라고 얘기하는 것으로 우리가 개발한 제품의 모든 Business Logic(ex: 회원가입)을 검증하는 방법으로 테스트 코드를 작성하거나 Business Logic을 설계하기 위한 방법으로 테스트 코드로 스펙을 정의한 후에 테스트 코드가 정상적으로 돌아가는 프로그램을 작성하는 것을 말한다.
필자가 얘기하고자 하는 것은 테스트 코드를 통해서 설계 방식을 바꾸자는 것도 아니고 TDD는 설계 방식으로 사용하는 것도 맞지 않다고 생각한다.
테스트 코드를 잘 짜면 뭐가 좋은가?
보통 API에 대한 테스트 코드를 작성한다면 데이터베이스와 더미 파일을 지정하거나 더미 데이터를 고정된 위치에 만드는 방식으로 작성하는데 이건 정말 잘못된 방법이라고 생각한다.
기존에 존재하는 무언가를 타겟으로 검증 절차를 가진다는 것 자체만으로도 종속성이 생기기 때문에 환경이나 솔루션이 바뀌게 되면 그 검증 절차는 사용할 수 없게 된다.
테스트 코드는 기능 테스트와는 다르다. 우리의 비즈니스 로직을 검증하기 위한 단위로 그 사이에 다른 무언가에 의해 종속성이 생기면 안 된다.
그러기 위하여 데이터베이스는 인 메모리를 사용하고 필요한 이미지 리소스 등은 최소한의 양으로 해당 프로젝트 안에 더미 파일 형태로 존재해야 한다.
경험에 의하면 API의 경우 테스트 코드 coverage 70%만 넘어도 대부분의 비즈니스 로직을 검증한 상황이라고 판단할 수 있다.
자세한 테스트 코드 작성 요령은 아래의 주소를 참고 바란다.
프로세스 얘기를 하다가 왜 갑자기 TDD 얘기를 하는 것이냐면 개발 프로세스에서 시간을 가장 많이 잡아먹는 요인 중 하나가 운영 업무 또는 버그에 의한 이슈 대응이 크게 작용하기 때문인데 이 시간 소요를 없애려면 반드시 올바른 테스트 코드가 선행되어야 한다. 적어도 우리 앱의 비즈니스 로직을 종속성없이 검증할 수 있다면 배포를 할 때 받는 스트레스는 줄어들고 서비스의 안정성은 증가할 것이다. 비즈니스 로직을 검증했다면 개발자는 버그 상황에 대해서 검토해야할 부분이 아주 혁신적으로 감소할 수 있다.
언제까지 DaP(Deploy and Pray) 할 수는 없는 것이다.
나만의 작은 개발 환경??!
Docker는 더 응용해서 써야 할 필요가 있다.
많은 IT 기업들에서 제품을 Dockerize 해서 사용하지만 보통 라이브 서버 환경 구성으로만 사용한다.
docker-compose를 사용해서 로컬 개발 환경에서 다른 앱과의 상호작용이 필요한 경우에 클라이언트, 서버 개발자 상관없이 로컬에서 기능적인 테스트가 가능하게 해야 한다.
개인적으로는 개발 서버는 반드시 필요하다고 생각하지는 않는데 예외적인 상황으로 서비스가 엄청나게 방대한 상황이라 로컬에서 모든 컨테이너를 띄우기 어려운 경우가 아니라면 말이다.
로컬에 docker-compose로 서비스 환경을 구성해서 사용하면 개발자가 즉시 자신이 변경한 사항을 다른 서비스들과 연동하는 테스트를 빠르게 진행할 수 있기 때문에 많은 시간 절약이 가능하다.
데이터베이스 컨테이너의 경우 볼륨(로컬 저장소)을 지정하면 데이터 또한 그대로 유지할 수 있고 없앨 수도 있기 때문에 다른 애플리케이션들과 연동되는 기능 테스트는 로컬에서도 충분히 진행할 수 있다.
모든 개발자들이 원하는 버전과 개발환경을 중앙화된 서버에서 컨트롤할 수는 없다.
자동화
자동화라고 부를 수 있는 내용들은 여러 가지가 있지만 개발자로써 필수적인 자동화라고 생각하는 부분들은 아래와 같다.
- CI(Continuous Integration) 영역으로 툴을 이용한 테스트 코드 자동 실행 및 정적 분석
- CD(Continuous Delivery) 영역에 해당하는 특정 환경에 앱 배포 및 롤백
- Jira 자동화
보통 IT 회사라면 CI/CD 환경은 다들 구성하는데 문제는 위에 얘기한 종속성을 제거한 테스트 코드를 수반하지 않는 경우가 많기 때문에 제대로된 CI를 하기가 어렵다… 하지만 이 글을 본 사람들은 멋진 테스트 코드를 작성했다고 생각해보자.
배포 자동화도 너무 완벽하게 구성했다!!
하지만 우리에겐 한 가지 더 중요한 것이 남아있다.
우리는 코드 통합 및 배포만 자동으로 할 수 있는 게 아니다.
Jira 자동화
많은 기업에서 사용 중인 Jira도 자동화할 수 있는데 Jira를 자동화해야 하는 이유와 어떻게 응용할 수 있는지를 얘기해보려고 한다.
일반적으로 기업에서는 애자일 프로세스를 도입하게 되면서 Jira를 많이 사용하게 되는데 Agile에서 얘기하는 스프린트, 스크럼 등의 내용이 Jira에 녹아 있기 때문이다.
하지만 제대로 사용하는 경우를 거의 보기가 힘든데 그 이유는 Jira의 가장 중요한 장점이자 단점인 “다량의 정보 생산”이다.
많은 인원들이 Jira를 사용할수록 정보의 양은 기하급수적으로 늘어나는데 이런 정보를 올바르게 관리하기가 어렵다는 것이다.
필요한 내용만 확인하고 업무에 대한 내용을 수치적으로 산출하기 위한 정보는 자동으로 처리가 되어야 하는데 보통 너무 많은 값들을 이슈 하나에 저장하기 때문에 귀찮아서 또는 잘 몰라서 안 하게 되는 경우가 다반사다.
Jira를 제대로 쓰지 않겠다면 그냥 Trello를 쓰는게 훨씬 나은 방법이다…
업무가 어떻게 진행되고 얼마나 시간을 할애했는지 등에 대한 내용을 기록하고 알려면 이러한 정보를 일일이 이슈 하나하나에 기록해야 하는데 어떤 시간 많은 한량이 이걸 다 하면서 업무를 진행할 수 있을지는 모르겠다.
우리는 편하려고 툴을 도입했는데 오히려 일이 늘어나는 상황인 것이다. 우리는 업무를 위한 업무를 하고 싶은 게 아니라 일을 줄이고 싶은 것이다.
Jira Workflow
프로젝트에서 우리가 추적해야 할 다양한 정보 중에 가장 중요하다고 생각되는 것은 실제로 얼마나 이슈를 해결하기 위하여 일을 했는가를 측정하는 것인데 이 내용을 위해서 Jira에 자동화 기능을 몇 가지 추가해보았다.
우선적으로 필요한 것은 이슈들이 어떤 상태를 가질 수 있는지 정의하는 것인데 Workflow를 통하여 설정이 가능한다. 필자의 경우 아래처럼 설정하였다.
- To Do: 백로그에 이슈가 최초로 생성된 상태
- In Progress: 실무자가 이슈를 처리하기 위해 실제로 처리중인 상태
- In Review: 실무자가 완료로 판단하여 리뷰를 받기 위한 상태
- Rejected: 리뷰가 거절되어 일종의 백로그 상태로 돌아간 상태
- Reopened: 완전히 완료된 이후에 다시 이슈 라이징된 상태
- Paused: 업무 시간 외 및 작업 중 다른 업무를 진행하는 등의 이유에 의해서 중지된 상태
- Done: 최종 완료된 상태
일반적인 개발팀에서는 위와 같은 정도의 이슈 사이클을 관리하면 충분하다고 생각한다. 여기서 중요한 부분은 작업 전의 상태가 여러 가지가 존재하고 해당 영역에서는 “실제로 실무자가 작업 중”인 상태는 아니라고 판단한다.
Jira Automation 설정하기
실제로 업무에 얼마나 시간을 소요했는지를 판단하기 위해서 간단한 Automation 규칙을 추가해 봤다.
- SetTrackingStartDate: 이 규칙은 위의 Workflow에서 TO DO, REOPENED, REJECTED 상태에서 In Progress 로 넘어가는 상황에서 실행되는 규칙으로 WorkLog: StartDate 라는 커스텀 필드를 현재 시간으로 업데이트한다.
- Add TimeTracking: In Progress -> In Review 상황에서 실행되는 규칙으로 위에서 업데이트된 WorkLog: StartDate 필드의 시간과 현재 시간의 차이를 계산해 TimeTracking의 시간값에 “누적”한다.
이와 같이 팀 또는 그룹 차원에서 어떤 수치들을 기록하고 참고할 것인지 이슈 타입에 따라 어떤 내용을 작성할 것인지(template automation)를 미리 정의하여 이를 자동화 시키면 실무자의 입장에서는 단 한 가지에만 포커스를 할 수 있게 되는데 그것은 이슈의 상태 전환이다.
실제로 업무 중인 이슈에 대해서만 상태를 In Progress로 잠시 멈추거나 퇴근할 때는 Paused 상태로 전환을 하는 실제 작업 중인 이슈 한 가지만 In Progress로 유지하는 행위를 교육하고 습관화되면 정리되지 않은 이슈를 줄이고 실제로 이슈에서 어떤 업무를 얼마큼 진행했는지 판단하는데 큰 도움이 된다.
몇 년 전에 Scrum, Agile 관련 페이퍼를 작성하기 위해서 업계에 있는 사람들에게 다양한 피드백과 설문조사를 받은 적이 있는데 회사에서 제대로 Agile이 동작하지 않는다고 생각하는 이유 1위가 구성원이 Agile이 뭔지 모른다였다. 들어는 봤지만 실제로 어떻게 일해야 하고 회의 시에는 어떤 규칙이 있는지를 모른다는 것이다. 그렇게 행동하지도 않고 회의를 중재하는 중재자도 없다. 우리가 프로세스를 만들기 위해서 다양한 우리만의 규칙을 추가할 때마다 일을 하기 위해 거쳐야 하는 허들만 더 생긴다는 것을 잊지 말자.
허들이 생길 때마다 우리는 Agile 해지지 않고 더 느려질 뿐이다.
마치면서…
위에서 다양한 방식으로 개발 업무 효율을 개선하는 내용을 작성했는데 필자가 얘기하고 싶은 핵심은 아래와 같다.
- 프로세스를 바꾸고 루틴 한 규칙을 추가하는 게 개발 업무 효율에 도움이 되는 것보단 오히려 역효과가 날 수 있다.
- 업무 관리를 위해서 좋은 툴을 사용하는 것도 좋지만 그 툴을 더 잘 사용하기 위해서 최대한 자동화할 수 있는 것은 자동화하고 실무자에 대한 교육도 게을리해서는 안된다.
- 업무 규칙은 간단하게 하고 서비스를 검증하고 신뢰성을 올리기 위한 많은 자동화 작업을 해두면 개발자들로 하여금 서비스에 대한 심도 있는 고민과 새로운 기술을 연구하고 빠르게 서비스에 녹일 수 있는 여유가 생길 수 있다.
- 서비스를 구성하는 애플리케이션들의 비즈니스 로직을 검증하는 테스트 코드를 다량 작성하여 안정적으로 운영하기 위해서는 개발자들 스스로의 마인드 셋도 중요하지만 회사의 기조 또한 중요하다.
최대한 자동화할 수 있는 것들은 조금 느리더라도 자동화하고 가자는 문화가 정착된다면 더 안정적으로 서비스를 운영하고 다른 기능이나 서비스를 추가할 때 들어가는 비용도 오히려 더 감소할 수 있을 것이다.
개발자라는 사람들은 뼛속부터 게으른 사람들이어야 한다.
너무 게을러서 업무에 비효율적으로 들어가는 것들은 전부 컴퓨터에게 맡기고 우리는 배부르고 등 따뜻하게 다양한 생각을 더 할 수 있는 상황을 만들어야 한다.
이 뉴스의 교훈은 놀고 먹어도 일은 아무 이상없이 잘 돌아갔다는 것…
