원문: https://blog.passionoil.co/how-the-dev-team-gets-things-done/
2020년 12월 9일 작성된 글입니다.
IT 조직 경험이 없는 내부 팀원들에게 공유하기 위해 작성된 글 입니다.

개발팀이 일을 매듭 짓는 방법 by 새발

---

프로젝트 시작 후 기획과 디자인/개발이 끝나면 QA, 배포 단계를 거쳐 유저에게 전달됩니다.
1년 넘게 같이 협업하면서 QA, 배포에 대해 대략적으로 얘기만 했지 제대로 알려드린 적이 없는 것 같아요.

최근 디자이너 심옹과 마케터 이든이 합류하고, 팀 전체 구조가 바뀌면서 개발팀의 업무 형태도 많이 달라졌습니다.

몇달 전만 해도 “퀄리티 보다는 속도” 중점으로 1주일 단위 업무 계획과 실행(스프린트), 그리고 커뮤니케이션을 최소화한 상태에서 기능을 빠르게 올린 후 터져나오는 문제를 실시간으로 해결을 하는 방식이었습니다.

지금은 적극적인 커뮤니케이션, 예측 가능한 계획과 실행, 위험 관리 등 속도를 조금 포기하고 디테일과 안전성을 확보하려 노력하고 있습니다.

때문에 QA와 배포 대한 중요도가 높아졌어요. 각각에 대해 한번씩 짚어보겠습니다. 여기에 더해 개발팀에서 요새 자주 얘기하는 “코드 퀄리티”에 대해서도 얘기해 보겠습니다.

QA

개발팀에서 “배포 전 QA를 해야 서비스가 터질 확률이 줄어든다”라는 말을 많이 했었습니다. 하지만 빠른 배포 일정으로 QA가 없거나 간단한 테스트만 거치고 출시하는 일이 잦았어요. 더불어 서비스가 터지고 버그가 발생하는 일이 많았습니다.

QA는 “Quality assurance”의 약자로, “품질 보증”을 의미합니다. 즉 개발한 기능과 제품이 우리가 정의한 수준 이상의 품질을 보증할 수 있도록 배포 이전에 각종 테스트와 검수 작업을 하는 겁니다.

좀 더 구체적으로 말하자면 기능 테스트와 더불어 기획한대로 결과물이 나왔는지, 기획 상 빈틈은 없는지, 디자인 상 이슈는 없는지, 개발팀에서 놓친 빈틈은 없는지 등 품질 보증을 위해 전반적인 검수를 하는 작업입니다.

QA 진행에도 시간이 들어가고, 수정 사항이 나오면 이를 수정하는데도 시간이 들어갑니다. 때문에 배포 일정이 늦춰지고, 팀 간 불화도 생겨 나죠. 개발팀에선 QA 일정을 개발 일정에 포함 시켜 일정 미루기와 불화를 최대한 피하려고 합니다.

QA는 업무 진행을 평가할 수 있는 최소한의 기준이다.

열기 팀에서 개발팀과 업무를 진행할 때, 기획/디자인/개발 이 세 파트가 서로 맞물려 진행됩니다. 각자 다른 파트의, 각자 다른 사람이 모여 하나의 그림을 그려 나갑니다. 업무에 참여한 팀원들 모두 같은 그림을 같이 그리고 있다면, QA 상 문제가 발생할 확률이 현저히 떨어지게 됩니다. 팀원들이 예측한 범위 내의 결과물이 나오니까요. 개발팀에서 기능 테스트만 잘 진행하면 됩니다.

만약 팀원들이 각자 생각하는 그림을 각자 그리고 있다면 예측치를 벗어난 결과물이 나옵니다. 기획과 다른 방향으로 구현된 기능에, 디자인도 잘 반영되어 있지 않고 심지어 너덜너덜 거리는 결과물이 말이죠. 당연히 QA 상 문제가 많이 튀어 나오고, 일정이 밀리게 되겠죠.

QA는 업무 초반 기획 단계에서부터 많은 영향을 받습니다. 그리는 그림이 팀원들에게 충분히 얼라인 되고, 깊게 생각해 디자인/개발 작업 이전에 빈틈을 찾고, 일정에 차질이 없다면 QA 단계에서 문제가 발생할 확률이 적습니다. 때문에 QA는 디자인/개발팀만의 전유물이 아니며, 참여하는 팀원들 모두가 QA에 영향을 주게 됩니다.

결국 “QA가 예측한 범위 내에서 문제 없이 잘 진행되었다”는 “프로젝트가 시작부터 끝까지 별탈 없이 잘 진행되었다”라는 최소한의 업무 평가 기준을 제시하게 됩니다.

QA를 디자인/개발팀에서 자체적으로 진행하고 있어 피부로 와 닿지 않겠지만, 참여한 모든 팀원의 영향을 받으니 꼭 신경써주시면 감사하겠습니다. 🤤🤤🤤🤤

현재 어떻게 QA를 진행하고 있나요?

몇 주 전까지는 러프하게 필요할 경우에만 QA를 간단하게 진행했지만, 지금은 새로 추가된, 수정된 모든 기능들에 대해 QA를 진행합니다.

현재(2020-12) 시점에서 디자인/개발팀과 협업하는 프로세스는 다음과 같고,

1. 기획 및 아이디에이션
2. 상세 일감 및 일정 산정
3. 디자인 및 개발
4. QA
5. 배포

3번째 단계(디자인 및 개발) 완료 시 디자인/개발팀 내에서 자체적으로 진행하고 있습니다.

기획 단계에서 나온 유저 스토리보다 좀 더 기능에 포커스를 맞춘 유저 스토리를 재작성하고, 이를 노션에 테이블로 만들어 테스트 합니다. (심옹이 많이 도움을 주셨어요)
테스트 후 수정 사항을 반영하고 배포 단계로 넘어가게 됩니다.

배포

배포는 추가/수정한 기능을 앱/웹/서버에 반영하는 작업입니다.

우리가 만든 것들이 실제 유저에게 적용되는 시점이며, 개발 할때는 언제나 예측하지 못한 위험이 도사리고 있기 때문에 위험도가 높은 작업입니다.

앱

크클 앱(ios/android) 배포는 항상 심사 / 업로드 시간이 걸립니다.

애플 앱스토어는 애플에서 우리 앱을 심사합니다. 심사에 통과해야만 앱을 배포할 수 있습니다. 배포 후 앱스토어에 반영되는 시간이 어느정도 있고, 반영되면 유저가 업데이트해야 우리가 추가/수정한 기능이 반영됩니다.

구글 플레이 스토어는 앱을 심사하지 않지만, 스토어에 반영되는 시간이 꽤 있고, 유저마다 이 반영 시간이 다릅니다. 대략 1시간 내지 많게는 2일 정도 까지라고 느껴지네요. 이 또한 유저가 앱을 업데이트 해야 우리가 추가한/수정한 기능이 반영됩니다.

앱 배포 시 최종적으로 스토어 반영까지 시간이 들기 때문에 배포 후 문제가 터질 경우 다시 반영하는데까지 시간이 소요됩니다. 때문에 앱 배포 시에는 QA가 정말 중요합니다.

앱 배포는 해달이 자동화하여 개발자의 번거로움을 줄여주셨습니다. 원래는 손으로 업로드 해야하거든요. (자동화 배포를 CD, Continuous deployment라 부릅니다.)

ios는 코드 반영 시마다 앱 심사 전 단계로 앱스토어에 업로드 합니다.
android는 코드 반영 시마다 테스트 단계로 구글 플레이 스토어에 업로드 합니다.

웹

리뉴얼 하고 있는 웹사이트 기준으로 말씀드리겠습니다. – https://gathering.creatorclub.kr , https://creatorclub.kr

앱 배포와는 다르게, 수정 시 바로 바로 배포 가능합니다. 개발팀에서 우리 웹 서버에 코드를 반영하는 시간만 있을 뿐 입니다.

웹 배포 또한 오월이 자동화해주셨습니다.
코드 반영 시 선택적으로 자동 배포됩니다. 평균 반영 시간은 5분 내외입니다.

서버

웹과 마찬가지로 수정 시 바로 배포 가능합니다.
서버 배포도 오월과 새발(나)이 자동화 해주셨습니다.
코드 반영 시 선택적으로 자동으로 배포됩니다. 평균 반영 시간은 10분 내외입니다.

개발팀에서는 배포를 왜 두려워할까요?

“배포 시 문제가 터질 수도 있다”라는 것 때문에 개발팀에서 배포를 두려워 합니다. QA를 충분히 거치더라도 빈틈이 있을 수 있습니다. 심지어는 추가/수정한 기능이 건드리지 않은 기능에 영향을 주기도 해요.

그리고 문제가 터질 경우 기존 작업 계획에 영향을 주기 때문에 위험 부담을 최대한 줄이려는 노력을 하고 있습니다.

왜 점심에 배포하려고 하던게 다음 날로 밀리죠?

주로 타이트한 일정을 잡았을 때 많이 발생하고, 배포 직전에 문제점이나 빈틈을 발견해서 최대한 고친 후 배포를 하기 때문입니다.

코드 퀄리티

제가 아마 코드 퀄리티라는 말을 자주 했었을 겁니다. 코드 퀄리티는 말 그대로 코드의 퀄리티, 품질을 의미합니다.

우리가 만드는 서비스는 모두 “코드”로 이루어져 있습니다. 개발자가 하는 일은 코드를 추가하거나 수정해 기능을 구현해내는 것 입니다.

문제는 코드를 추가하고 수정하는 작업은 단순 타자를 쳐서 뭔가를 적는 게 아닌, 꽤 복잡한 작업이라는 겁니다. 코드는 다른 코드와 서로 얽혀 있기 때문에, 코드를 추가하거나 수정할 때마다 얽힌 코드에 문제가 없는지, 더 나아가 서비스를 구성하고 있는 데이터나 연동된 서비스에 문제가 없는지 지속적으로 체크를 해야합니다.

때문에 코드 퀄리티가 중요해집니다. 작성해 놓은 코드를 개발자들이 지속적으로 읽고 수정하기 때문에, 코드가 정리되어 있지 않으면 그만큼 작업 시간도 오래 걸리고, 버그 발생 확률도 높아집니다.

코드 퀄리티가 떨어지는 잘 정리되어 있지 않은 코드 비유:

코드 퀄리티가 높은 잘 정리되어 있는 코드 비유:

코드 퀄리티는 개발팀 말고는 아무도 모른다.

코드 퀄리티 관리 없이 기능 개발을 치고 나가면 어느 순간 개발팀 생산성이 저하되고 버그가 자주 발생합니다. 이때가 되면 개발팀은 코드나 기능을 리뉴얼 하거나 소위 “리팩터링”이라고 부르는 코드 정리 작업을 진행해야 합니다. 기능 개발과는 별개로 말이죠.

때문에 개발팀은 팀 전체의 우선순위와 긴급도, 요구사항 스펙을 보고 이번 기능 개발 때 코드 퀄리티를 챙길지 말지 생각해 상세 일감과 일정을 짜게 됩니다.

2개월 전쯤에 백조에게 “개발팀이 서비스 개발 일정 권한을 많이 가져가고 싶다”라고 했고, 허락을 받았습니다. 개발팀에서 앞서 언급된 QA, 배포, 코드 퀄리티까지 적당히 생각해서 일감과 일정을 가이드 드리고 있습니다. 혹여 정말 일정이 급한 경우에는 꼭 어필해주세요. 같이 얘기를 해봅시다. 🤤

현재 개발팀에서는 이렇게 코드 퀄리티를 관리하고 있어요.

코드 퀄리티 관리는 QA와 비슷하게 프로젝트 시작 단계에서 부터 시작합니다. 개발자 스스로가 기획, 아이디에이션 단계에 적극 임하지 않으면 요구 사항을 정확히 파악하지 못하며 이는 일감/일정 산정에 악영향을 주게 됩니다. 일정 막바지가 되면 이런 저런 문제가 터져나오고 결국 낮은 퀄리티의 코드로 일정을 최대한 맞추려고 하겠죠.

비슷한 얘기지만 일정 산정에 있어서도 관리가 필요합니다. 우선순위와 긴급도에 따라 달라지겠지만, 타이트한 일정은 낮은 코드 퀄리티를 유지할 수 밖에 없습니다. 일정이 타이트한 만큼 개발자가 설계하고 생각하는 시간이 적어지기 때문입니다.

개발팀 내부에서 서로의 코드를 리뷰해주려 노력하고 있습니다. 급할 땐 못하고 넘어가지만요🌝. 이와 함께 코드 작성에 대한 규칙, 앱/웹/서버 파트 별로 잡힌 아키텍쳐와 철학을 개발팀 내에 지속적으로 얼라인 하고 있습니다.

많은 도구와 방법들이 있지만 제일 효과적인 방법은 코드 퀄리티, 구조, 개발 철학에 대해 팀 내에서 많이 얘기하는 게 가장 좋은 방법인 듯 합니다. 저랑 해달만 있었을 땐 기능 개발만 하다가 코드에 대해서 주관이 뚜렷한 오월 합류 이후로 코드 자체에 대해서 얘기를 많이 하고 있거든요. 대화로 심어진 작은 씨앗이 몇 주 내 반영 되기도 합니다.

결론

QA, 배포, 코드 퀄리티에 대한 지식이 있다면 개발팀과 커뮤니케이션 하는데 많은 도움이 되실 겁니다. 최대한 쉽게 썼지만 어려운 부분이 있다면 언제든지 말씀해주시면 감사하겠습니다.