기획을 위한 최소한의 개발 지식 (9)
개발팀 협업 방법
목차
✅ 컴퓨터의 구성 요소와 운영체제
✅ 프로그래밍 언어
✅ 네트워크, 클라이언트, 서버
✅ 스크래핑, API, JSON
✅ App 과 Web
✅ 네이티브, 리액티브, 웹앱, 하이브리드
✅ 데이터베이스
✅ 프레임워크, 라이브러리
✅ 개발팀 협업 방법 ⬅︎
✅ 클라우드
'커밋한다', '빌드를 만다' 는 얘기를 처음 들었을 때 '엥? 뭔소리야?' 했던 기억이 있다. 몇 번 물어보고 설명을 들어 봐도 이해가 되지 않아서 상당히 난처했다. 그걸 이해해 보겠다고 개발을 직접 해 볼수도 없는 노릇이니 말이다.
S/W 회사의 채용 공고를 보면 풀스택 개발자, BE(백엔드) 개발자, FE(프론트엔드) 개발자, DevOps 개발자 등 다양한 역할이 있다. 같은 역할이어도 혼자서 개발하지 않고 여러 명이 협업하며 개발하는 경우가 많다. Flow Chart 나 User Story 처럼 기획 문서는 서비스가 일단 론칭 되고 나면 서비스를 직접 써 보면서 어느 정도는 복구 혹은 추측을 할 수도 있지만 소스코드를 날려 버리면 복구가 어려우니 체계적으로 정리해서 잘 저장하는 것도 중요하다.
☑️ Git : 개발자의 협업 도구이다. (원격 저장소라고 생각하면 된다.)
☑️ Commit 하다 : 각 개발자가 한 작업을 Git에 업로드하는 일. 각 개발자의 코딩 작업물은 각자의 컴퓨터에 저장되어 있고 그걸 커밋해야 협업이 가능한 상태가 된다.
☑️ Branch : 기존 작업에 영향을 주지 않고, 기존 작업과 결이 다른 작업을 추가하는 일이다.
☑️ Merge : 개발자들이 각자 작업한 코드를 합치는 것이다.
☑️ 빌드를 말다 : 보통 QA(테스트)를 할 때 개발 환경에서 테스트를 한 후 사용자 환경에서 최종적으로 확인을 하는데, 열심히 개발한 결과물을 테스트 가능한 상태로 업로드하는 걸 '빌드를 만다' 라고 한다. 보통 '컴파일 - 빌드 - 배포'의 과정을 거친다. 이걸 아는 기획자는 배포를 한 후에 코드를 수정하려면 저 과정을 다시 반복해야 한다는 걸 알기 때문에, 배포 이후에 수정이 필요한 기능들을 모아서 요청하는 쪽으로 개발팀을 배려할 수 있다.
Jira 라는 프로젝트 관리 툴을 쓰면 담당 개발자 할당 후 Git에 연동해서 작업 상태를 볼 수 있는데 스타트업에서 다양한 협업툴을 경험하면서 이제 이런 소프트웨어 없는 협업은 상상하기 어렵다는 생각이 들었다. 최근에는 코딩 작업 후 테스트 작업까지의 과정을 자동화 해주는 툴도 많이 사용하고 있다고 하고, 코딩이 상당 부분 쉬워지거나 low-code, no-code 를 활용한 서비스까지 등장을 하고 있다. App과 Web 서비스가 일정 부분 정형화 되면서 협업이 쉬워지는 부분도 생기는 것 같다.
시중은행 에서 처럼 이런 툴이 없이 내부 시스템 만으로 협업을 할 경우에는 이런 부분에 대해서 분업이 잘 되어 있어 기획자로서 챙길 부분이 적었던 것 같다. 그래서 처음 스타트업으로 이직을 했을 때 기획이 챙겨야 할 범위가 갑자기 훅 늘어났다는 느낌을 받았었다. 앞으로 어떤 회사에서 어떤 툴을 이용해서 협업을 하게 될 지 모르겠지만, 기본적인 협업 방식을 알고 좀더 함께 일하는 개발자분을 배려하는 기획자가 되고 싶다.
참고 자료
<비전공자를 위한 이해할 수 있는 IT 지식>, 최원영, 2021.02.01., T.W.I.G.
<[QA] 컴파일? 빌드? 배포? 개념과 차이는 무엇일까?>, HaejoonLee, 2019.5.28., https://itholic.github.io/qa-compile-build-deploy/
