에이전시에서 품질관리하기 — 시도
비영리단체, 창업, 프리랜서를 거쳐 에이전시는 [김지민앤컴퍼니](https://www.kimjiminand.co)가 첫 회사인 내 생각에 에이전시에서 품질 관리는 정말 힘들다. 우리나라의 수많은 개발 에이전시 중에 이곳의 근무 환경은 손가락에 꼽힐 만큼 좋은 곳이라 확신하지만, 내가 알지 못하는 더 나은 환경을 가진 곳이 있을 것이다. 그러므로 지금은 에이전시가 아닌 김지민앤컴퍼니에서의 품질 관리가 힘든 이유, 그리고 그것들을 극복하기 위한 노력을 이야기해보려고 한다.
배경
우리 결과물의 품질 관리에 대한 이슈는 내가 회사에 들어오기 전부터 꾸준히 내/외부적으로 제기되고 있던 문제였다. 최근 들어 다시 한 번 클라이언트로부터 품질에 대한 이슈를 제기 받은 뒤 근본적인 처방을 위하여 개발팀에서는 품질 관리에 대한 주제로 회의를 가졌다. 개발자들 스스로 제기하는 문제의 원인 혹은 종류에 따라 개발 문화의 개선점 혹은 협업 시스템의 개선점 등 다양한 정책이 나올 것을 기대하였고, 나름 의미 있는 결과물을 시도하고 있다고 생각되어 이것을 공유해보고자 한다.
우선 품질 관리에 대한 내 개인적인 생각과 개발팀 내부적으로 제기한 문제의식을 이해하기 위해서는 현재 회사의 환경에 대한 이해가 도움이 될 것이라 생각되어 간단히 소개한다.
1. 직원 수
- 2016년 말 기준 정직원 3명이 근무하고 있었는데, 현재 정직원 14명이 근무하고 있다(회사 성장 전략 차원에서 2017년 다수 채용).
- 에이전시의 아쉬운 점으로 생각되지만, 급여 및 활용 기술 수준 등 몇 가지의 이유로 실력 있는 개발자를 마음껏 채용하기 힘들다. 전체 14명 중 대표, 기획자, 디자이너 3명을 제외하고 11명이 개발자인데, 그 가운데 이곳이 개발자로서 첫 직장인 인원이 8명이다(참고로 대표가 유일한 10년 차 이상의 개발자이다).
- 이 중 전공이나 직종을 변경하여 독학 혹은 교육 프로그램을 통해 프로그래머로서의 경력을 시작한 인원이 4명이다.
2. 프로젝트 현황
이 글을 적고 있는 2018년 3월 1일 기준으로 기획 혹은 개발 전반을 담당하고 있는 프로젝트가 10여 건 정도이며 이 중 이미 런칭하여 유지/보수 단계에 있는 프로젝트가 5~6건 정도이다.
3. 다루는 기술 스펙
품질 관리 = 테스트
품질 관리에는 자연스레 테스트라는 꼬리표가 따라붙기 마련이다. 개발팀 내부 회의에서도 역시 모든 문제의식의 중심 키워드는 테스트의 부재 혹은 어려움이었다. 그렇다면 왜 우리에게 테스트가 힘든 걸까?
1. 시간 = 매출
에이전시에게는 시간이 바로 돈이다. 무슨 당연한 말을 하느냐고 생각하겠지만 에이전시에게 시간은 돈인 이유가 두 가지 존재한다.
- 1) 같은 시간 동안 1개의 프로젝트를 하느냐 2개의 프로젝트를 진행하느냐는 회사의 매출과 곧바로 직결되는 문제이다.
- 2) 에이전시가 1개의 계약을 따내기 위하여 더 많은 시간을 요구한다면 맨먼스에 따라 더 많은 계약금을 요구할 수밖에 없으며 이는 곧 계약을 잃는 것을 의미한다.
1) 을 달성하지 못한다면 매출이 줄어들어 임금이 낮아지겠지만, 2)는 ‘달성하지 못하면’이라는 가정조차 존재할 수 없다. 즉, 계약 조건부터 품질 관리의 어려움은 시작된다.
2. 품질 관리에 유리할 수 없는 계약
이로 인해 당연히 계약 단계에서 에이전시는 최고 효율을 가정한 계약 조건을 제시할 수밖에 없다. 여기서 최고 효율이란 최소한의 인원으로 클라이언트가 원하는 제품을 만들어 내기 위한 코드 작성 시간 그리고 최소한의 QA를 의미한다. 개발팀을 겪어본 사람이라면 당연히(대부분) QA에 배정된 시간도 결국 코드 작성 시간에 쓰일 것을 알 것이다. 결국, 애초에 테스트를 위한 시간이 적거나 없을 수밖에 없다.
3. TDD의 비효율성
사후 처방인 QA 이전에 TDD(Test Driven Development, 테스트 주도 개발)를 도입하여 코드 작성 시점에 품질을 높여보면 어떨까? 그러면 최소한의 QA, 혹은 별도의 QA 기간 없이도 충분히 개발 기간을 활용해 품질을 관리 할 수 있지 않을까? 라고 나도 착각하던 때가 있었다. 결론부터 말하자면 애초에 TDD는 에이전시에서, 아니 이곳에서는 불가능하다.
TDD를 적용하면 한 번 작성한 테스트 코드가 앞으로의 장기적인 개발 기간 상당히 효율적으로 작용할 것이다. 하지만 매우 `장기적`인 경우이다. 하나의 프로젝트가 길어야 2~3달, 짧으면 2주~1달 만에 끝나는 프로젝트를 위해서 개발 초기 단계에서 제품 코드를 생산하는 대신 테스트 코드를 작성한다는 것은 거의 불가능하다. 더군다나 동시에 유지/보수를 포함하여 10가지 프로젝트가 동시에 진행되는 상황에서 한 프로젝트만을 위한 테스트 코드는 프로젝트 개수만큼 시간을 비효율적으로 잡아먹을 수밖에 없다.
4. 그 외
- 1개의 프로젝트를 1명이 맡는 경우도 꽤 존재한다. 대부분 처음 삽을 뜨는 프로젝트보다는 이미 운영 중인 프로젝트의 개선 혹은 유지/보수 작업을 맡을 때 생기는 경우이다. 내가 싼 똥을 내가 발견한다는 것은 품질을 운에 맡기는 것과 같다.
- 안타깝지만 당연하게도 처음 생산되는 코드의 품질 자체가 좋지 못하다. 아무래도 전공을 변경한 개발자를 포함하여 첫 경력을 시작하는 주니어가 대부분이기 때문에 기본적인 기능 구현 이상의 것들(콜백/Promise 처리, 방어적 프로그래밍 등)에 대해 고민의 깊이가 얕을 수밖에 없다.
그럼에도 품질 관리는 필요하다
품질 관리가 어려운 이유는 내 개인적인 생각이었지만, 품질 관리의 필요성은 팀원 모두가 똑같이 느끼고 있었다. 아래는 팀 회의에서 나온 결과물이다.
프로젝트 배정
- 1개 프로젝트에 반드시 2인 이상 담당자를 배정한다:
프로젝트별로 기획과 개발의 진행도를 파악하고 있는 담당자가 최소 2인 이상이 되도록 한다. 보통 신규 개발 프로젝트에는 2인에서 많게는 4인 정도가 참여하고, 유지/보수로 진행하는 경우 대부분 1인, 많아야 2인이 참여하는 편이다. 이때 프로젝트의 전반적인 이슈와 진행 상황을 2인 이상이 공유할 수 있도록 한다. - 팔로업 파트너:
프로젝트가 처음 런칭하는 시점에 모든 개발자는 1명의 팔로업 파트너를 갖는다. 팔로업 파트너는 동료가 진행하는 이슈에 대해 그 내용과 진행 상황을 함께 파악한다. 또 동료가 어떤 방식으로 이슈에 접근하며 해결하고 있는지 최대한 파악하려 애쓴다.
원자적 이슈 활용
- 원자적 커밋처럼 이슈 또한 원자적 이슈가 되도록 노력한다. 프로젝트가 런칭되는 시점부터 QA까지 진행되는 모든 원자적 기능 개발은 개별적으로 1개의 이슈가 등록되어 진행되도록 한다. 이로 인해 1개의 이슈는 1명의 담당자가 배정되고 [2번 이슈]에 의하여 총 2명이 팔로업을 하게 된다.
- 프로젝트 런칭 시점부터 이슈트래커를 최대한 활용하기 위하여 런칭 전 기획회의 때 모든 개발자가 참여하며 그 자리에서 바로 [1기능 1이슈] 원칙에 따라 이슈를 생성하고 필요한 경우 담당자를 배정하여 어사인한다.
프로젝트 개발 주기 확립
- 시작 단계: 기획 회의
- 프로젝트가 런칭되는 시점에 프로젝트에 참여하는 모든 인원이 참석하는 기획 회의를 연다. 기획회의에는 기획자(혹은 PM), 디자이너 외에도 모든 개발자가 참석하여 프로젝트 전체 기획에 대해 파악한다.
- 개발팀은 화면 혹은 기능 단위로 기획을 파악하면서 원자적 이슈를 생성하고 담당자를 어사인하는 것
2. 유지/보수 단계: 월1회 주기 업데이트
- 프로젝트 주기가 유지/보수로 접어든 경우 월 1회를 주기로 마이너 업데이트를 원칙으로 한다. 마이너 업데이트란 다음과 같다.
- 포함: 레거시 코드 제거, 리팩토링, 라이브러리 최신 버전 유지
- 미포함: 클라이언트 요청에 의한 기능 추가/변경
[Server]팀과 [Client]팀 간의 협업 원칙
- [Server]팀 작업이 완료/변경/제거 되는 경우 [Client]팀 이슈트래커에 새 이슈를 등록하여 [Server]팀 완료/변경/제거 사항을 공지한다.
- [Client]팀은 이슈를 확인하고 완료/변경/제거 사항이 [Client]팀 소스코드에 반영이 된 이후 이슈를 클로즈한다.
한단계 도약을 위한 기회
굳이 기술 수준을 1에서 10까지 나눈다면 작은 에이전시에서 일한다는 것은 1에서 3~4까지의 기술 수준을 수도없이 반복하는 것이라고 말할 수 있다(간혹 6~7의 기술이 필요할 때도 있지만). 그렇기 때문에 일반적인 기술 회사에서 갖는 채용 전략과는 조금 다를 수 있고, 평균적인 기술 수준이 비에이전시 계열의 기술 회사보다 상대적으로 낮을 수 있고 또 당연한 결과이다.
에이전시가 갖는 기술 수준을 바꿀 수 있는 변수가 아닌 상수라고 생각한다면 우리는 이를 더 나은 팀워크로 극복해보고자 한다. 우리가 정립하고 시도하려는 이러한 문화와 원칙, 그리고 시스템은 각 개개인이 갖는 기술 수준과 그 편차, 그리고 비기술적인 부분에서 오는 부정적인 실수들의 완충장치가 되어줄 것이라 믿는다. 더불어 그 환경 안에서 각 개개인 각자의 성장도 더 빠르고 더 올바르게 이루어 나갈 것이라 생각한다.
