JSON, Git, Github, 그리고 QA 1탄 | 코드스테이츠 PMB 17기 W7D4
오늘은 IT프로덕트에서 JSON의 역할과 Git으로 개발 코드를 관리해야 하는 이유,
그리고 QA를 PM의 주도로 진행해야 하는 이유에 대해서 공부해보자!
.
.
JSON 이해하기
API가 제대로 작동하려면 요청과 응답 안에 '데이터'를 넣어 전달해야 하는데, 이때 데이터를 담는 일정한 형식이 필요하다. JSON은 데이터를 주고 받는 가장 대표적인 방식이다. PM의 경우, JSON 파일을 열어 찾고자 하는 키 값에 대응하는 밸류를 읽을 줄 알면 된다고 한다.
JSON의 형식:
{ 키1(Key): 값1(Value), 키2(Key): 값2(Value), }
데이터는 크게 중괄호로 묶고, 이름과 값의 쌍으로 구성된다. 안에 콜론(:)을 중심으로 왼쪽에는 데이터의 이름, 키(key)를, 오른쪽에는 그에 대응하는 값, 밸류를 적는다.
XML:
JSON과 유사한 목적으로 사용되는 또 다른 구조화된 데이터 형식으로 XML도 있다. XML은 웹 프론트엔드 언어인 HTML과 호환성이 높다는 장점이 있다. 하지만 용량이 무겁다는 단점이 있다. 요즘은 가볍고 명확한 JSON을 더 많이 사용한다고 한다.
개발 관리와 Git
제품 개발 절차는 이전에도 언급했지만, 다시 정리해보자면 다음과 같다:
요구사항 정의서 >> 설계 >> 개발/디버깅 >> 코드 업로드 >> 코드 리뷰 >> 테스트 배포 >> 테스트 >> 배포
앞에 두 단계는 PM의 영역이고, 이후부터는 개발팀의 영역이라고 할 수 있다. 그럼 각 단게 별로 어떤 일을 하게 되는지 간략하게 살펴보자.
3) 개발, 디버깅(로컬)
프로그램 개발 및 개발 단계에서 생긴 버그를 해결하는 단계이다. 이 단계에서는 코드를 개인 컴퓨터에서 작업하고 저장한다. 개발팀이 개발을 진행하는 동안, 이 단계에서 PM은 테크 리드와 함께 개발 과정에서 필요한 리소스 관리, 협업을 진행해야 한다. 개발에 필요한 와이어프레임, 디자인 파일, 이미지 파일 등을 관리하고 제공해야 하는 것이다.
4) 원격 업로드(Git)
개발팀은 다수의 개발자가 하나의 애플리케이션을 개발하게 되는 경우가 많다. 따라서 코드 간의 충돌과 여러 코드 버전이 동시에 생성되어 유지보수가 어려워질 수 있다. 이런 문제의 발생을 줄이기 위해 로컬(개발자의 컴퓨터)에서 개발이 완료된 코드는 버전 관리를 위해 원격 공간인 Git에 업로드한다.
Git은 소스 코드의 버전을 관리하는 시스템이다. 분산 버전 제어를 통해 프로젝트에 참여하는 여러 개발자가 효율적으로 코드를 개발하도록 지원한다. 프로그램 개발을 위해 보통 프로젝트 파일이 하나 생성된다. 개발자들은 하나의 프로젝트를 기준으로 코드를 받아 로컬 환경에서 작업하고, 개발 및 디버깅이 완료되면 다시 프로젝트 파일에 만든 commit을 원격 저장소에 업로드 한다. 원격 저장소로 파일을 업로드 하는 행위를 Git에서는 push라고 한다. push를 실행하면 원격 저장소에 개발자 A의 변경 이력인 commit이 올라가게 되고, 원격 저장소에 commit에 기반한 새로운 버전이 쌓이게 된다. 다른 개발자는 pull 기능을 활용하여, 마지막 commit을 기준으로 자기 로컬 저장소로 프로젝트의 모든 코드를 받아온다.
*commit: 코드와 파일 및 폴더의 변경, 추가사항을 저장소에 기록하려면 'commit' 기능을 활용한다. 아직 공유하지 않은 변경 사항을 나타낸다. 개인 로컬 저장소에서 관리한다.
Git의 장점:
1) 소스 코드를 주고받을 필요 없이, 같은 파일을 여러 명이 동시에 작업하는 병렬 개발이 가능하다.
2) 분산 버전 관리이기 때문에 인터넷이 연결되지 않은 곳에서도 개발을 진행할 수 있고, 중앙 저장소가 날아가도 원상복구 할 수 있다.
3) 팀 프로젝트가 아닌, 개인 프로젝트일지라도 Git을 통해 버전 관리를 하면 체계적인 개발이 가능해지고, 프로그램이나 패치를 배포하는 과정도 간단해진다.
원격 코드 저장소로는 Github가 대표적이다. Git시스템에 올린 코드를 저장하고 관리하는 공간이다. 단순히 기업에서 일하기 위해 사용되는 것뿐만 아니라, 개인의 프로젝트도 Github를 통해 관리하곤 한다. 기업, 공공기관, 프로젝트팀이 제공하는 오픈소스 역시 Github를 통해 공유된다.
5) 코드 리뷰
코드 리뷰란 디버깅이 완료가 된 코드를 개발자 간에 서로 크로스체크하는 과정이다. 개발팀 특유의 상호 소통 방식 중 하나이며 아래와 같은 장점과 효과를 만들어 낸다:
- 개발자 서로의 개발 스타일을 이해할 수 있다.
- 일관된 아키텍처를 유지할 수 있도록 돕는다.
- 서로의 기술 정보를 공유 및 습득한다.
- 잠재적인 오류의 발생 가능성을 낮춘다.
코드 리뷰는 코드와 개발팀의 수준을 높이 끌어 올리는 효과가 있다. 일정에 따라 코드 리뷰를 진행하거나 하지 않는 경우도 있다.
6) 테스트
다음과 같은 이유로 디버깅을 마친 이후에도 반드시 테스트 서버를 두고 테스트 과정을 거쳐야 한다. 테스트 서버를 통해 실제 배포 시에 생길 수 있는 문제를 사전에 검토해야 한다. 특히 서버 없이 로컬에서 구현되는 프론트엔드와 실제 클라이언트와 연동 없이 개발되는 백엔드의 경우 테스트 서버에 배포해 연동 테스트를 진행해야 한다. PM도 검토 과정에 참여하여, 기획의도에 맞게 개발이 되었는지 확인해야 한다.
7) 프로덕션 배포
배포 작업은 고객에게 제품이 전달되는 과정으로서 배포 환경이 제대로 설정되어 성공적으로 배포를 진행할 수 있는지 점검해야 한다. 배포 실패는 곧 서비스 중지를 의미하기 때문에, PM도 반드시 배포 절차에 대해 직접 관여해야 한다.
Git과 Github 관련하여 알아두면 좋은 용어:
1) Repositories
Git에서 개발하는 코드를 저장하는 단위이다. 크게 로컬저장소, 원격저장소로 나뉘고, 로컬저장소는 자신의 컴퓨터에 저장하는 저장소이며 원격저장소는 서버, 네트워크에 있는 저장소로 GitHub가 해당된다. 코드를 업로드하면, 자동으로 버전의 히스토리가 남게 된다.
2) Clone
원격저장소에 있는 파일을 그대로 복사해 로컬저장소에 저장하도록 돕는 기능이다. Git에 올라온 코드 가운데 원하는 부분을 전체 그대로 복사해 로컬에 저장해준다. pull과의 차이점은 clone은 현재 작업 중인 코드만 고려한다는 것이고, pull은 현재 작업 중인 내용을 유지하면서 최신 코드만 업데이트 한다. 따라서 처음 작업 환경을 셋팅 할 때는 clone을, 작업 중간에 최신 코드를 받을 때는 pull을 사용하는 것이 일반적이다.
3) Branch
주요 코드에서 곁가지를 뻗어 작업하는 환경을 의미한다. 다른 기능에 기반을 두고 있지만, 연관성이 떨어지는 기능을 새로 개발하고 관리하고 싶을 때 Branch 를 활용한다. 브랜치에서 작업 한 내용은 기존 메인 프로젝트에 영향을 주지 않으며, 작업이 모두 끝난 뒤에는 병합하는 과정을 거쳐야 한다. 그래서 작업할 때는 우선 메인 브랜치를 복사해서 새 브랜치를 만들고, 그 위에 commit을 쌓아 작업을 완료한다. 그리고 해당 브랜치를 메인 브랜치와 병합해서 프로덕트를 완성한다고 보면 된다.
4) Pull Requests
Pull Request는 내가 수정한 내용들을 원본 Repository에 pull해달라고 요청하는 작업이다. 이 과정을 수행할 때 코드 간의 충돌 문제가 있는지 확인하고, 작성한 코드에 문제가 없는지 코드 리뷰 작업을 거친 뒤 병합을 진행하게 된다.
QA
QA(Quality Assurance)는 단순한 테스트를 넘어, 제품의 품질을 안정화하고, 유지보수, 개선과 관련된 모든 업무를 아우르는 상위 개념이다. QA업무를 수행하는 직무 그 자체를 QA라고 부르기도 한다. QA를 시작할 때는 우선 프로덕트의 변경 포인트와 요구사항을 분석 및 검토한다. 이를 기반으로 리스크 및 테스트 컨디션을 파악해 시험 계획을 수립한다. 테스트 시에는 단순 변경 사항 확인을 넘어 잠재적인 문제를 발견한다. 따라서 문제 발견을 위한 테스트 케이스를 수립해야 한다. 고객에게서 들어온 문제점을 파악해 개발팀에 전달하며, 문제 이력을 관리해 다시 발생하지 않도록 해야한다. 그리고 이를 기반으로 유관 부서들과 커뮤니케이션하는 것까지 업무에 포함된다. QA자체가 제품 퀄리티 전반에 걸친 책임을 가진다고 볼 수 있다.
QA 과정에서 진행되는 업무:
1) 기획 문서 리뷰 :
QA 담당자가 작성된 기획서를 리뷰하면서, 기획의 문제점이나 버그 발생의 요소는 없는지 등을 검토하여, 최대한 버그 발생 가능 요인을 점검하고 예방한다. PM은 보통 QA 담당자와 일정을 잡아 논의한다.
2) 테스트 케이스 작성 :
QA 담당자는 기획서를 기반으로 테스트 케이스를 정리하는 단계이다. 해당 과정은 제품이 개발되기 전이나 개발 중에 작성이 시작되며, 필요에 따라 테스트 케이스 작성 중 기획이 고려하지 못한 문제가 발견되면, 기획 자체를 수정하기도 한다. 특히 이런 부분은 예외 처리 관련된 내용이 많다. 인터넷 연결이 끊겼을 때 화면이 없다든지 등과 같은 것들이 있다.
3) 내부 리뷰 :
PM, 개발자, QA 등 프로덕트 팀이 테스트 케이스를 점검하며 문제가 없는지 확인하는 단계이다. 테스트 케이스 작성 과정과 내부 리뷰 과정은 개발과정과 병렬로 진행하게 된다. 개발에 고려가 될 것이 있다면, 개발 중에 반영하기도 하지만, 테스트를 수행하면서 반영하기도 한다.
4) 테스트 케이스 수행 :
테스트 케이스 기반으로 QA 담당자들이 수행하며, Pass/Fail로 여부를 확인한다. Fail이 된 케이스에 대해서는 PM과 개발자들이 확인하여 문제를 해결하고, 이를 다시 QA 담당자들에게 안내하여 문제가 해결되었음을 다시 확인받는다.
학습 회고...
오늘은 개념적인 내용이 많았고, 이전 학습 내용과 연관이 되어있어, 이해하는데 큰 어려움은 없었던 것 같다. 다만 아쉬운 점은..과연 내가 할 수 있을 것인지에 대한 생각과 함께, 너무 얕게 공부한 것은 아닌지에 대한 생각이 들어..음 썩 만족스럽진 못했던 것 같다. 시간이 나면 자료도 많이 찾아보고 해야겠다..!