[코드스테이츠 PMB 9기] JSON

W7D4 학습목표
- JSON의 형식과 특징에 맞게 프로그램 기능을 정의할 수 있다.
- Github을 통해 프로그램 개발이 관리되는 과정을 분석할 수 있다.

개념 정리
- JSON
- Git, Github

이후 답변 가능한 질문
- IT 서비스에서 JSON의 역할은 무엇인가?
- Git으로 개발 코드를 관리해야 하는 이유는 무엇인가?

---

 

JSON 이해하기

JSON이란

정보를 주고받는 방법 뿐 아니라 주고받는 정보의 형식 역시 API와 같이 일정한 규칙을 정해 사용하는 것도 필요하다. 이런 목적으로 사용되는 형식 중 대표적인 방식이 JSON 이다.

JSON의 형태

{ 키1(Key): 값1(Value), 키2(Key): 값2(Value), }

JSON vs XML

JSON과 유사한 목적으로 사용되는 또 다른 구조화된 데이터 형식으로 XML이라는 것도 존재한다. 용도와 목적에 따라 어떤 형식을 선택해 사용할지 고려하여 결정하는 것이 필요하다.

PM은 JSON 파일을 어디까지 다뤄야 할까?

개발 관리 과정에서 정보의 형식을 직접 확인하거나 테스트 데이터를 만드는 등의 작업을 할 때 직접 JSON형식을 다루는 경우가 있을 수 있다. 이런 경우를 대비해 형식을 보고 어떻게 데이터가 구성되어 있는지를 파악하는 능력은 필요하다.

Git & Github

Git : 소스코드의 버전을 관리하는 툴. Github : Git이 적용된 원격 코드 저장소.

Git의 장점

1. 소스 코드를 주고 받을 필요 없이, 같은 파일을 여러 명이 동시에 작업하는 병렬 개발이 가능합니다. (브랜치를 통해 개발한 뒤, 본 프로그램에서 합치는 방식(Merge)으로 개발을 진행할 수 있습니다.)
2. 분산 버전 관리이기 때문에 인터넷이 연결되지 않은 곳에서도 개발을 진행할 수 있고,중앙 저장소가 날라가 버려도 원상복구할 수 있습니다.
3. 팀 프로젝트가 아닌, 개인 프로젝트일지라도 Git을 통해 버전 관리를 하면 체계적인 개발이 가능해지고, 프로그램이나 패치를 배포하는 과정도 간단해집니다.

Git 용어

1	Repositories	Git에서 개발하는 코드를 저장하는 단위이며 로컬저장소, 원격저장소로 나뉩니다 로컬저장소는 자신의 컴퓨터에 저장하는 저장소이며 원격저장소는 서버, 네트워크에 위치한 저장소로 GitHub가 여기에 해당합니다. 기본적으로 로컬저장소에서 작업을 수행하고, 그 결과를 이후에 원격 저장소에 저장(커밋)하는 방식으로 개발이 진행됩니다.
2	Clone	Clone은 원격저장소에 있던 순수파일들과 프로젝트의 커밋되었던 히스토리 정보까지 모두 다운로드가 되어있는 로컬저장소(Local Repository)를 만들어 주는 역할입니다.
3	Branch	전체 프로젝트에서 일부만 수정사항이 있는 경우에 메인 프로젝트에서 일부를 가지처럼 나누어 별개의 프로젝트로 나눈 것을 브랜치라고 합니다. 브랜치에서 작업을 한 내용은 기존 메인 프로젝트에 영향을 주지 않으며, 작업이 모두 끝난 뒤에는 병합하는 과정을 거쳐야 합니다.
4	Pull Requests	Pull Request는 내가 수정한 내용들을 원본 Repository에 반영(Pull)해줄 것을 요청(Request)하는 작업입니다. 이 과정을 수행할 때 코드간의 충돌문제가 있는지 확인하고, 작성한 코드에 문제가 없는지 코드 리뷰 작업을 거친 뒤 병합을 진행하게 됩니다.

 

개발 절차

1	개발, 디버깅(로컬)	개발팀이 개발을 진행하는 동안 PM은 테크 리드와 함께 개발 과정에서 필요한 리소스 관리, 협업을 진행해야 합니다. 또한 개발에 필요한 개발 외의 자료, 리소스에 대한 제공 책임을 갖습니다. 와이어프레임, 디자인 파일, 이미지 파일 등 개발에 직접적으로 사용되는 비 개발 리소스에 대해서 관리하는 역할이 필요합니다.
2	원격 업로드(Git)	개발팀은 다수의 개발자들이 하나의 어플리케이션을 개발하게 되는 경우가 많습니다. 이때 생길 수 있는 가장 큰 문제가 코드간의 충돌과 여러 코드 버전이 동시에 생성되 유지보수가 어려워 지는 것 입니다. 이런 문제의 발생을 줄이기 위해 로컬(개발자의 컴퓨터)에서 개발이 완료된 코드는 버전 관리를 위해 원격 공간인 Git에 업로드 됩니다.
3	코드 리뷰	코드리뷰란 디버깅이 완료가 된 코드를 개발자들간에 서로 크로스 체킹을 하는 과정입니다. 개발팀 특유의 상호 소통 방식중 하나이며 아래와 같은 장점과 효과를 만들어 냅니다. 서로의 개발 스타일을 이해할 수 있습니다. 일관된 아키텍쳐를 유지할 수 있도록 합니다. 서로의 기술 정보를 공유 및 습득합니다. 잠재적인 오류의 발생 가능성을 낮춥니다. 기획단계에서의 잦은 요구사항 및 기한 변경을 하게 되면, 실제 개발작업이 이뤄지지 않는 코드 리뷰와 같은 작업이 생략되게 되어 코드 전반의 품질을 떨어트리는 요인이 될 수 있습니다.
4	테스트	다음과 같은 이유로 디버깅을 마친 이후에도 반드시 테스트 서버를 두고 테스트 과정을 거쳐야 합니다. 로컬에서 문제 없다고 실제로 문제가 없는 것은 아닐 수 있습니다. 개발은 항상 완벽할 수 없다는 가정을 하는 것이 중요합니다. 로컬 - 서비스에 영향을 주지 않고 안전하게 개발할 필요가 있습니다. 테스트 서버를 둠으로서 실제 배포시에 생길 수 있는 문제를 사전에 검토해야 합니다. 특히 서버 없이 로컬에서 구현되는 프런트엔드와 실제 프런트와 연동 없이 개발되는 백엔드의 경우 테스트 서버에 배포해 연동 테스트를 진행해야 합니다.
5	프로덕션 배포	배포 작업은 고객에게 제품이 전달되는 과정으로서 배포 환경이 제대로 설정되 성공적으로 배포를 진행할 수 있는지 점검해야 합니다. 배포 실패는 곧 서비스 중지를 의미하기 때문에 제품 책임자인 PM으로서 반드시 배포 절차에 대해 직접 관여해야만 합니다.

 

 

PM이 테스트 절차를 직접 관리해야 하는 이유는 무엇일까?

개발팀에서 기능 검토가 끝난 제품이라 할 지라도 기획 의도에 맞게 고객의 니즈를 명확하게 반영한 기능을 만들었는지는 제품팀에서 검토를 해야 할 필요가 있습니다. 테스트 과정에서 PM과 제품팀의 원래 의도대로 기능이 구현되었는지, 해당 기능이 고객의 문제를 해결하는지에 대해 직접 점검할 필요가 있습니다. 어떤 테스트를 진행해야 하는지에 대해 PM이 직접 테스트 케이스를 정의해 테스트를 진행하는 것이 중요합니다.

 

 

 

---

 

 

W6D1 데일리 과제 회고하기
지난 2주동안 (W6, W7) 강의를 바탕으로 본인이 선택한 프로덕트에서 유저가 할 수 있는 행동에 대한 Flow Chart를 간단하게 만들어 봅시다. (Technical Flow Chart 검색 시 다양한 플로우차트 작성 방법이 나옵니다)지난 2주동안 (W6, W7) 강의를 바탕으로 본인이 선택한 프로덕트의 UI, 클라이언트, 서버, DB가 각각 어떻게 보이고 작동할지 예상하여 적어 봅시다.

1) 당근마켓 로그인, 전화 번호 등록

2) 동네 선택

3) 동네 판매자들 물건 둘러보기

4) 검색하기 or 둘러보기 하면서 물건 탐색 후 원하는 물건 찾음

5) 원하는 물건 판매자에게 채팅

 

 

 

- 회원 정보

아이디, 개인정보, 비밀번호 등

- 위치 기반 DB

사용자 위치기반

- 커뮤니티 정보

게시판, 동네 생활