에이전시에서 품질관리하기 — 시도

출처: http://www.transperfect.com/blog/translation-quality-assurance-vs-quality-control

배경

우리 결과물의 품질 관리에 대한 이슈는 내가 회사에 들어오기 전부터 꾸준히 내/외부적으로 제기되고 있던 문제였다. 최근 들어 다시 한 번 클라이언트로부터 품질에 대한 이슈를 제기 받은 뒤 근본적인 처방을 위하여 개발팀에서는 품질 관리에 대한 주제로 회의를 가졌다. 개발자들 스스로 제기하는 문제의 원인 혹은 종류에 따라 개발 문화의 개선점 혹은 협업 시스템의 개선점 등 다양한 정책이 나올 것을 기대하였고, 나름 의미 있는 결과물을 시도하고 있다고 생각되어 이것을 공유해보고자 한다.

  • 2016년 말 기준 정직원 3명이 근무하고 있었는데, 현재 정직원 14명이 근무하고 있다(회사 성장 전략 차원에서 2017년 다수 채용).
  • 에이전시의 아쉬운 점으로 생각되지만, 급여 및 활용 기술 수준 등 몇 가지의 이유로 실력 있는 개발자를 마음껏 채용하기 힘들다. 전체 14명 중 대표, 기획자, 디자이너 3명을 제외하고 11명이 개발자인데, 그 가운데 이곳이 개발자로서 첫 직장인 인원이 8명이다(참고로 대표가 유일한 10년 차 이상의 개발자이다).
  • 이 중 전공이나 직종을 변경하여 독학 혹은 교육 프로그램을 통해 프로그래머로서의 경력을 시작한 인원이 4명이다.

품질 관리 = 테스트

품질 관리에는 자연스레 테스트라는 꼬리표가 따라붙기 마련이다. 개발팀 내부 회의에서도 역시 모든 문제의식의 중심 키워드는 테스트의 부재 혹은 어려움이었다. 그렇다면 왜 우리에게 테스트가 힘든 걸까?

  • 1) 같은 시간 동안 1개의 프로젝트를 하느냐 2개의 프로젝트를 진행하느냐는 회사의 매출과 곧바로 직결되는 문제이다.
  • 2) 에이전시가 1개의 계약을 따내기 위하여 더 많은 시간을 요구한다면 맨먼스에 따라 더 많은 계약금을 요구할 수밖에 없으며 이는 곧 계약을 잃는 것을 의미한다.
출처: https://pacroy.blogspot.kr/2017/01/a-few-exercises-for-you-to-practice.html
  • 1개의 프로젝트를 1명이 맡는 경우도 꽤 존재한다. 대부분 처음 삽을 뜨는 프로젝트보다는 이미 운영 중인 프로젝트의 개선 혹은 유지/보수 작업을 맡을 때 생기는 경우이다. 내가 싼 똥을 내가 발견한다는 것은 품질을 운에 맡기는 것과 같다.
  • 안타깝지만 당연하게도 처음 생산되는 코드의 품질 자체가 좋지 못하다. 아무래도 전공을 변경한 개발자를 포함하여 첫 경력을 시작하는 주니어가 대부분이기 때문에 기본적인 기능 구현 이상의 것들(콜백/Promise 처리, 방어적 프로그래밍 등)에 대해 고민의 깊이가 얕을 수밖에 없다.

그럼에도 품질 관리는 필요하다

품질 관리가 어려운 이유는 내 개인적인 생각이었지만, 품질 관리의 필요성은 팀원 모두가 똑같이 느끼고 있었다. 아래는 팀 회의에서 나온 결과물이다.

프로젝트 배정

  • 1개 프로젝트에 반드시 2인 이상 담당자를 배정한다:
    프로젝트별로 기획과 개발의 진행도를 파악하고 있는 담당자가 최소 2인 이상이 되도록 한다. 보통 신규 개발 프로젝트에는 2인에서 많게는 4인 정도가 참여하고, 유지/보수로 진행하는 경우 대부분 1인, 많아야 2인이 참여하는 편이다. 이때 프로젝트의 전반적인 이슈와 진행 상황을 2인 이상이 공유할 수 있도록 한다.
  • 팔로업 파트너:
    프로젝트가 처음 런칭하는 시점에 모든 개발자는 1명의 팔로업 파트너를 갖는다. 팔로업 파트너는 동료가 진행하는 이슈에 대해 그 내용과 진행 상황을 함께 파악한다. 또 동료가 어떤 방식으로 이슈에 접근하며 해결하고 있는지 최대한 파악하려 애쓴다.

원자적 이슈 활용

  • 원자적 커밋처럼 이슈 또한 원자적 이슈가 되도록 노력한다. 프로젝트가 런칭되는 시점부터 QA까지 진행되는 모든 원자적 기능 개발은 개별적으로 1개의 이슈가 등록되어 진행되도록 한다. 이로 인해 1개의 이슈는 1명의 담당자가 배정되고 [2번 이슈]에 의하여 총 2명이 팔로업을 하게 된다.
  • 프로젝트 런칭 시점부터 이슈트래커를 최대한 활용하기 위하여 런칭 전 기획회의 때 모든 개발자가 참여하며 그 자리에서 바로 [1기능 1이슈] 원칙에 따라 이슈를 생성하고 필요한 경우 담당자를 배정하여 어사인한다.

프로젝트 개발 주기 확립

  1. 시작 단계: 기획 회의
  • 프로젝트가 런칭되는 시점에 프로젝트에 참여하는 모든 인원이 참석하는 기획 회의를 연다. 기획회의에는 기획자(혹은 PM), 디자이너 외에도 모든 개발자가 참석하여 프로젝트 전체 기획에 대해 파악한다.
  • 개발팀은 화면 혹은 기능 단위로 기획을 파악하면서 원자적 이슈를 생성하고 담당자를 어사인하는 것
  • 프로젝트 주기가 유지/보수로 접어든 경우 월 1회를 주기로 마이너 업데이트를 원칙으로 한다. 마이너 업데이트란 다음과 같다.
  • 포함: 레거시 코드 제거, 리팩토링, 라이브러리 최신 버전 유지
  • 미포함: 클라이언트 요청에 의한 기능 추가/변경

[Server]팀과 [Client]팀 간의 협업 원칙

  • [Server]팀 작업이 완료/변경/제거 되는 경우 [Client]팀 이슈트래커에 새 이슈를 등록하여 [Server]팀 완료/변경/제거 사항을 공지한다.
  • [Client]팀은 이슈를 확인하고 완료/변경/제거 사항이 [Client]팀 소스코드에 반영이 된 이후 이슈를 클로즈한다.

한단계 도약을 위한 기회

굳이 기술 수준을 1에서 10까지 나눈다면 작은 에이전시에서 일한다는 것은 1에서 3~4까지의 기술 수준을 수도없이 반복하는 것이라고 말할 수 있다(간혹 6~7의 기술이 필요할 때도 있지만). 그렇기 때문에 일반적인 기술 회사에서 갖는 채용 전략과는 조금 다를 수 있고, 평균적인 기술 수준이 비에이전시 계열의 기술 회사보다 상대적으로 낮을 수 있고 또 당연한 결과이다.

출처: 이미테이션게임

--

--

Hacker, Yoga, Feminist https://hoony.land

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store