잡다한기술블로그

서비스 배포과정

• QA까지 정상적으로 마쳤다면 이제 사용자들이 사용하는 실제 환경에 적용하는 배포과정만 남음
• 일반적으로 개발자가 코드를 짜서 프로젝트에 코드를 합치는 작업들은 전부 개발환경에서 진행됨
  • 개인 컴퓨터를 통해서 프로그램을 실행시키고 코드를 작성하므로 실제 사용자들에게 영향 x
• 개발환경에서 짠 코드들이 실제 사용자들이 사용하는 운영환경에 업데이트가 되어야 하는데 이를 배포라 함
  • 운영환경: 웹 서버, API 서버, 앱 스토어 등 실제 사용자들이 사용하게 되는 환경(서버)
  • 배포: 개발환경의 코드를 운영환경에 프로그램을 실행시키는 일련의 작업

Example

• 프론트엔드 개발자가 웹을 개발한 후 웹 서버에 배포하는 작업 필요
• 백엔드 개발자가 API 서버를 개발한 후 API 서버에 배포하는 작업 필요
• 모바일 개발자는 모바일 앱을 개발한 후 앱 스토어에 배포(+심사)하는 작업 필요

CD (Continuous Deployment)

• 과거에 서비스를 배포하기 위한 프로세스는 다음과 같음

1. 원격으로 운영환경(서버)에 접속
2. 운영환경에서 실행되고 있는 서버 프로그램을 종료시킴
3. 원격 코드 저장소에서 프로젝트를 다운받음
4. 프로젝트를 빌드해서 서버를 실행시킴

• 위 방식은 수동적인 방식으로 운영환경의 컴퓨터들이 많다면 일일이 하나씩 접근해야 하며, 문제가 생기면 일일히 들어가서 수정해야 함
• 이를 해결하기 위해 배포 과정을 자동화하는 방식이 많이 나옴

• CD(Continous Deployment): 서비스를 자동화 및 연속적으로 배포 할 수 있게 해주는 것
  • CD툴 사용시 개발자들이 소스코드를 원격 저장소(github 등)에 올려놓기만 하면 자동으로 운영 환경에 배포까지 진행해줌
  • 보통 CI를 통해 코드가 정상적으로 원격 저장소에 합쳐지고, CD를 통해 원격저장소에 있는 소스코드를 운영환경 컴퓨터에 최종적으로 실행시키는 일련의 과정으로 CI/CD 라고 부름

배포 주기

• 보통 배포는 코드가 원격저장소에 합쳐질 때마다 하지 않음
• 회사마다 정해놓은 주기, 정책에 따라 배포함
  • 일반적으로 하루에 한번씩 배포
  • 에러가 생기면 빠르게 수정해서 바로 배포 -> 핫픽스(HotFix)

배포 후

• 프로덕트가 최종적으로 개발되고 배포된 다음 개발자들이 심어 놓은 로그 코드를 통해서 로그들이 쌓임
  • 로그 데이터를 바탕으로 마케팅, 데이터 분석, 버그 수정 및 디벨롭 등을 진행

 DevOps

• DevOps: 코드 작성, 통합, 배포하는 프로세스를 자동화하고 클라우드 환경에서 문제가 없도록 관리 해주는 직군
  • 실제로 위의 전체적인 프로세스를 자동화하기 위해선 개발 환경을 구축해줘야 하고 꽤 많은 리소스들이 듬
  • 개발자들이 더 좋은 환경에서 개발할 수 있도록 코드 작성 외에 전반적인 프로세스 자동화 및 클라우드 관리 작업을 DevOps가 도와줌

Reference

https://www.inflearn.com/course/it-%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D#

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304

개발 코드 통합하기

• 개발자들이 제품 개발을 위해 코드를 다 작성한 후, 프로젝트에 코드를 통합하는 과정 필요
  • 웹, 앱, 서버 등 특정 목적을 수행하는 프로그램을 위한 소스코드들이 모여있는 공간을 프로젝트라고 하며 여러명의 개발자들이 하나의 프로젝트를 바라보고 코딩을 하게 됨
  • 최종적으로 코드가 합쳐져야 프로젝트에 제대로 개발자들이 짠 코드가 반영됐다고 할 수 있음

• 소스코드 빌드 & 테스트 실행, 코드 리뷰를 안(못)하는 기업들도 많음 -> 코드를 합치려면 코드 충돌만 해결해도 가능

프로젝트 빌드 & 테스트 실행

• 개발자가 짠 코드가 최종적으로 원격 프로젝트 저장소에 저장되기 전에 프로젝트 빌드와 테스트 실행이 먼저 실행됨
• 프로젝트 빌드: 개발자들이 짠 코드를 바탕으로 실행가능한 프로그램을 만드는 것을 의미
  • 개발자가 개발한 프로젝트는 사용자들이 이용하는 서버(웹, API 등)에서 제대로 실행되어야 함
  • 만약 프로젝트에 문제가 생기면 사용자들은 해당 서버를 이용할 수 없게 되어 큰 타격을 입을 수 있음
  • 따라서 업데이트된 프로젝트가 실제 유저가 이용하는 서버(운영환경)에 배포되기 전에 미리 가상 컴퓨터 공간에서 프로젝트를 빌드해서 실행시켜 보는 것이 중요
  • 이렇게 되면 문제가 생길 경우 미리 개발자들이 문제를 해결할 수 있게 되어 실제 서비스에 영향을 미치는 사태를 방지할 수 있음

• 프로젝트 빌드가 진행되면서 동시에 개발자들이 짜놨던 테스트 코드가 실행
  • 테스트 코드를 실행해서 통과되지 못한 테스트가 있다면 개발자들이 미리 확인해서 코드를 수정할 수 있음

CI (Continuous Integration)

• CI 툴: 프로젝트를 가상 환경에서 빌드(실행)해주고 테스트 코드도 실행시켜주는 자동화 툴
  • CI 툴은 내부 컴퓨터 환경에서 프로젝트 소스코드를 통해 프로그램을 실행시켜주는 프로젝트 빌드를 알아서 해줌
  • 프로젝트 빌드와 함께 테스트 코드 동작을 시켜 보며 문제가 없는지를 같이 확인해줌
  • 대표적인 CI 툴로 CircleCI, Travis CI 등이 있음
• CI 아래의 프로세스를 가짐
  • 코드를 짜고
  • 프로젝트를 빌드하고 테스트를 실행한 후
  • 프로젝트 저장소에 코드를 합침

코드 리뷰하기

• 보통 개발자들은 본인의 코드를 최종적으로 프로젝트에 반영하기 전에 코드리뷰를 거침
• 코드리뷰: 다른 개발자들이 직접 본인의 코드를 확인하는 과정
  • 코드를 보면서 에러가 날 수 있는 부분들, 회사의 코딩 컨벤션을 잘 지켰는지 등을 확인하고 리뷰를 남김
  • 리뷰 후 해당 리뷰를 코드에 적용하고 다시 리뷰를 요청하는 방식으로 진행
  • 보통 코드리뷰는 github이나 bitbucket 같이 소스코드를 저장하고 관리해주는 서비스에서 진행
• 개발자가 혼자거나 초기 스타트업은 코드리뷰를 하지 않고 빠르게 코드를 병합하기도 함

코드 충돌 해결하기

• 코드 충돌은 두 명 이상의 작업자가 동일한 파일을 작업했을 때 주로 발생
  • 하나의 프로젝트를 여러명의 개발자들이 개발하다 보면 같은 파일을 동시에 수정하는 경우가 많음
  • 보통 Git에서는 동일한 파일을 수정하더라도 알아서 코드를 병합해줌
  • 그러나 특정한 상황에서는 병합 과정에서 코드 충돌이 발생함
  • 그 때는 개발자가 직접 수정을 해서 코드를 병합해야 함
• 코드 충돌이 해결되면 업로드 후 코드 빌드, 테스트, 리뷰를 다시 거쳐 코드 충돌이 없는지 확인 후 코드 통합

QA

• QA: 최종적으로 개발자들이 열심히 짠 코드가 프로젝트에 적용되면 해당 제품이 잘 동작하는지 확인하는 작업
  • 보통 큰 기업에서는 QA 엔지니어 가 QA를 체계적으로 진행
  • 반면 규모가 작은 스타트업에서는 제품 팀에서 직접 사용해보며 문제를 찾음
  • QA를 하면서 기존 디자인에 맞게 잘 만들어졌는지, 버튼이나 API가 잘 동작하는지 등 개발된 제품을 전반적으로 확인
• 개발자들이 테스트 코드를 작성하는 것도 일종의 QA이긴 하지만 테스트 코드만으로 제품의 완성도를 평가하기는 어렵기 때문에 사람이 보통 추가로 QA 작업을 진행함
• 요새는 HBSmith 같이 QA를 자동으로 해주는 서비스들도 나오고 있음
• QA 작업을 해서 문제가 있는지 없는지를 확인하고 문제가 생기면 다시 코드를 고쳐 코드 통합 과정을 반복함

Reference

https://www.inflearn.com/course/it-%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D#

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304

제품 개발하기

• IT 제품은 IT 서비스를 제공하기 위해서 만들어야 하는 웹, 앱, 서버 등 폭넓은 의미로 사용되므로 IT 회사에서는 서비스를 개발할 때 제품을 개발한다고 이야기 함

제품팀은 어떻게 구성될까

• 일반적으로 제품팀은 PM 혹은 PO, 기획자, 디자이너, 개발자가 한 팀이 되어 활동함

• PM은 Project Manager로 제품을 개발할 때 전반적으로 일정, 역할, 태스크 관리 등을 주도
• 기획자는 서비스 기획을 담당
  • 예를 들어 친구초대 이벤트를 진행하기로 했다면 기획자는 간단한 화면 구성(프로토타입)을 그려보는 동시에 친구 초대의 정책도 같이 기획함
• 디자이너는 UI/UX를 담당
  • 우리가 사용하는 모든 웹, 앱은 디자이너가 디자인한 화면을 개발자가 구현해놓은 결과물
• 개발자는 제품팀에서 나온 기획과 디자인을 바탕으로 실제 제품을 구현

• 요새 스타트업에서는 기획자 대신 PO, 디자이너, 개발자로 팀을 구성해 기획에 제품팀 모두가 참여하면서 각자의 역할을 주체적으로 부여하는 애자일 방식으로 진행
• 보통 기획자, 디자이너는 개발자와 커뮤니케이션을 잘 하기 위해서는 개발용어를 아는 것 뿐만 아니라 배경지식들을 잘 이해하고 있어야 함

비즈니스 로직 개발하기

• 기획자가 친구초대 정책을 기획하고, 디자이너가 그에 맞춰 디자인을 작업

개발자가 개발하는 과정 1

• 기획과 디자인이 어느정도 윤곽이 나오면 개발자도 코딩을 시작

• 프론트엔드 개발자는 프로토타입을 보면서 화면의 전체적인 구성을 미리 설계
  • 프로토타입에서 "A페이지, B페이지 추가" 등의 정보들이 들어있으면 프론트엔드 개발자는 디자인이 나오기 전에 화면 구성, 간단한 기능들 구현을 먼저 진행
• 백엔드 개발자는 기획을 토대로 데이터베이스와 API 서버를 개발
  • 친구 초대의 기능의 경우 회원가입한 유저는 어떤 친구를 통해 초대되었는지 데이터를 가지고 있어야 하므로 데이터베이스를 수정해야 함
  • 초대받은 친구가 가입했을 때 보상을 줘야 하므로 회원가입 관련 API 코드에 친구 초대관련 코드가 추가되야 함

• 프로토타입은 실제로 디자인 결과물이 나오기 전에 미리 전체적인 그림을 그려주는 역할
• 위 사진처럼 실제 페이지 구성이 어떻게 되는지, 버튼을 누르면 어떻게 가는지 등 프로세스를 담고 있음

개발자가 개발하는 과정 2

• 프론트엔드 개발자는 최종 디자인을 받아 구체적인 화면 구성 진행
  • 버튼, 텍스트, 이미지 등의 배치와 크기를 정하는 작업을 하고 백엔드 개발자가 개발한 API 정보를 받아서 사용
• 백엔드 개발자는 개발한 API를 직접 사용하면서 문제가 없나 직접 테스트
  • 기획과 다른 방향으로 API 코드가 동작하는지 등을 확인
• 실제로 회사마다 제품을 개발하는 프로세스가 조금씩 다를 수 있음

로그 수집

• 보통 IT 제품에서 로그를 수집
  • 로그를 통해 이번 제품 개발이 성과가 있는지 측정할 수 있음
• 프론트엔드 개발자는 '친구 초대 링크에 얼마 들어왔는지', '버튼을 얼마나 클릭했는지' 등의 유저 로그 수집
  • 유저 로그를 이용하여 유저들의 행동을 분석해서 더 나은 제품을 개발할 수 있음
• 백엔드 개발자는 서버 관련 로그 수집 
  • 서버 로그를 이용하여 모니터링 할 수 있음

데이터 트래킹

• 데이터 트래킹은 데이터를 추적하는 것을 의미
  • 사용자의 행동 데이터를 수치로 나타내기 위해서 구글 애널리틱스를 이용해 데이터를 수집하여 데이터베이스에 저장하는 것 
  • 일반적으로 유저들이 웹, 앱에서 행동하는 것을 로그 데이터 형태로 수집한 후 로그를 다루는 서버로 전송
  • 그래서 보통 제품 개발을 진행한 후 버튼 클릭, 페이지 진입 등 유저가 사용하는 특정 행동 리스트에 유저 로그를 수집할 수 있는 코드를 추가함

테스트 코드 작성

• 테스트 코드 작성 이유
  • 이 버튼이 눌렸을 때 API 호출을 잘 하는지, API 서버에서는 제대로 동작을 하는지 등 사람이 직접 사용하면서 문제점을 찾음
  • 이런 과정을 코드로 짜서 자동화 해놓으면 사람의 테스트 시간도 아낄 수 있고, 동시에 휴먼 에러(사람이 낼 수 있는 실수)도 줄일 수 있으므로 개발자들이 테스트 코드를 작성
  • 위 예시와 같이 친구 초대의 경우 "초대 링크로 가입을 했을 때 초대자가 무사히 포인트를 발급받았는지" 를 테스트 코드로 작성함
  • 테스트를 통과하면 친구 초대의 기능이 잘 동작한다는 것이고, 실패한다면 문제가 있다는 것이니 코드를 수정해야 함
• 테스트 코드 종류
  • 기능 테스트 or E2E 테스트: 위와 같이 사용자의 관점에서 기능이 잘 작동하는지 확인하는 테스트
  • 단위 테스트: 개발자들이 짜놓은 코드의 작은 부분들(함수, 클래스 등)을 테스트하는 것
  • 테스트 커버리지: 테스트 코드가 얼마나 적용되어 있는지를 이야기하는 것

TDD

• 테스트를 최우선으로 하는 개발 프로세스로 테스트를 먼저 작성해서 테스트를 통과하는 코드 위주로 개발하는 방법
  • 테스트가 있으므로 코드가 안정성이 있지만 개발하는 기간이 그만큼 길어지는 단점 존재

Reference

https://www.inflearn.com/course/it-%EA%B0%9C%EB%B0%9C%EC%A7%80%EC%8B%9D#

https://www.grabbing.me/IT-A-to-Z-By-1e1fbc981b7c4c03ac44943085ac8304