VHAL_

[HTTP] 3. http 기초

VHAL_ — Thu, 19 Dec 2024 00:06:50 +0900

HTTP란 무엇인가

HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜입니다.
HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 합니다.
클라이언트-서버 프로토콜이란 (보통 웹브라우저인) 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미합니다.

1. HTTP의 핵심 개념

클라이언트-서버 구조: 클라이언트가 요청(Request)을 보내면 서버가 응답(Response)을 반환합니다.
- 클라이언트와 서버들은 (데이터 스트림과 대조적으로) 개별적인 메시지 교환에 의해 통신합니다. 보통 브라우저인 클라이언트에 의해 전송되는 메시지를 요청(requests)이라고 부르며, 그에 대해 서버에서 응답으로 전송되는 메시지를 응답(responses)이라고 부릅니다.
무상태 프로토콜(Stateless): 각 요청은 독립적으로 처리되며, 서버는 클라이언트 상태를 기억하지 않습니다.
- 상태 유지인 Stateful은 항상 같은 서버로 유지되어야 하고, stateless는 중간에 서버가 장애나도 아무 서버나 호출해도 되는 중 스케일아웃-수평확장에 유리합니다.
비연결성(Connectionless): 요청-응답 후 연결을 종료하여 서버 자원을 효율적으로 관리합니다.
- TCP/IP 연결을 새로 맺어야 한다는 한계가 있습니다. (3 way handshake 시간 추가)
- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 등 수 많은 자원이 함께 다운로드됩니다.
- 현재에는 HTTP 지속 연결(Persistent Connections)로 문제 해결하였습니다.

2. HTTP 요청 메시지

HTTP 요청 메시지는 클라이언트가 서버로 데이터를 요청할 때 사용하는 메시지 형식으로, 다음과 같은 구조를 가지고 있습니다.

Start Line (시작 라인): 요청의 기본 정보를 나타냄.
Header (헤더): 요청 관련 부가 정보를 포함.
Message Body (본문): 실제 데이터를 전송(선택적).

✔️ 시작 라인 (Start Line)

요청 메시지의 첫 번째 라인으로, 세 가지 구성 요소로 나뉩니다

HTTP 메서드:
- 클라이언트가 서버에서 수행할 동작을 지정.
- 주요 메서드:
  - GET: 데이터 조회 요청.
  - POST: 데이터 생성/처리 요청.
  - PUT: 데이터 전체 수정.
  - DELETE: 데이터 삭제.
요청 대상(Request Target):
- 요청할 리소스의 경로를 지정.
- 예: /search?q=hello&hl=ko (절대 경로와 쿼리 파라미터 포함).
HTTP 버전:
- 요청에 사용된 HTTP 프로토콜의 버전.
- 예: HTTP/1.1.

✔️ 헤더 (Header)

각 요청에 필요한 추가 정보를 전달하는 부분.
- 예: Host: www.google.com

주요 헤더:
- Host: 요청을 보낼 서버의 도메인
- Content-Type: 본문 데이터의 형식 지정 (예: JSON, HTML)
- User-Agent: 클라이언트 정보 (브라우저, 앱 등)
- Authorization: 인증 정보

✔️ 메시지 바디 (Message Body)

요청과 함께 전송되는 데이터로, POST, PUT 등의 메서드에서 주로 사용.
- 실제 전송할 데이터
- HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능

3. HTTP 응답 메시지

HTTP 응답 메시지는 서버가 클라이언트의 요청에 대한 결과를 전달하는 메시지로, 다음과 같은 구조를 가지고 있습니 다.

Start Line (시작 라인): 응답 상태와 관련된 정보를 나타냄
Header (헤더): 응답의 부가 정보
Message Body (본문): 실제 응답 데이터(선택적)

✔️ 시작 라인 (Start Line)

HTTP 상태 코드 : 요청 성공, 실패를 나타냄
- 200 : 성공
- 400 : 클라이언트 요청 오류
- 500 : 서버 내부 오류
이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글

✔️ 헤더 (Header)

HTTP 전송에 필요한 모든 부가정보
예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보...
주요 헤더:
- Content-Type: 응답 본문의 데이터 형식 지정 (예: JSON, HTML).
- Content-Length: 응답 본문의 크기(바이트 단위).
- Cache-Control: 클라이언트의 캐시 동작을 제어.
- Set-Cookie: 클라이언트에 쿠키 저장 요청.
- Server: 서버 정보.

✔️ 메시지 바디 (Message Body)

실제 전송할 데이터
HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능

[HTTP] 2. URI Web Browser

VHAL_ — Wed, 20 Nov 2024 11:54:54 +0900

URI란?

URI란 통합 자원 식별자(Uniform Resource Identifier)는 인터넷에 있는 자원을 어디에 있는지 자원 자체를 식별하는 방법입니다. URI의 하위개념으로는 URL, URN이 있습니다.

URL은 Locator를 의미하며 리소스가 있는 위치를 지정합니다. 반면에 URN은 Name을 의미하며 리소스에 이름을 부여하비다. 위치는 변할 수 있지만, 이름은 변하지 않습니다. 따라서 URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화되지 않았습니다.

☁️ URL은?

URL은 네트워크 상에서 자원이 어디 있는지 위치를 알려주기 위한 규약입니다.
즉, 컴퓨터 네트워크와 검색 메커니즘에서의 위치를 지정하는, 웹 리소스에 대한 참조라고 할 수 있습니다.

흔히 우리는 URL을 웹 사이트 주소로만 알고 있지만, URL은 웹 사이트 주소뿐만 아니라 컴퓨터 네트워크상의 자원을 모두 나타내는 표기법이며 해당 주소에 접속하려면 URL에 맞는 프로토콜(http, sftp, smp ..등)을 알아야 하고, 그와 동일한 프로토콜로 접속해야 합니다

URL의 문법

• scheme://[userinfo@]host[:port][/path][?query][#fragment]
• https://www.google.com:443/search?q=hello&hl=ko

프로토콜 (http)
- 의미: 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙 (ex. http, https 등)
- http는 80포트, https는 443포트를 주로 사용
호스트명(www.google.com)
- 호스트명을 의미
- 도메인명 또는 IP 주소를 직접 사용 가능
포트 번호(443)
- 접속한 포트를 의미
- 일반적으로 생략함
path(/search)
- 리소스 경로를 의미하며 계층적 구조로 이루어짐
- ex. /home/file1.jpg
쿼리 파라미터(q=hello&hl=ko)
- key=value 형태
- ?로 시작, &로 추가 가능 ?keyA=valueA&keyB=valueB
- query parameter, query string 등으로 불림, 웹서버에 제공하는 파라미터, 문자 형태

웹 브라우저 요청 흐름

URL 입력:
사용자가 브라우저에 URL을 입력합니다.
DNS 조회:
- 브라우저는 도메인 이름(www.google.com)을 DNS 서버에 질의합니다.
- DNS 서버는 해당 도메인의 **IP 주소(200.200.200.2)**를 반환합니다.
HTTPS 포트 생성:
- 브라우저는 IP 주소와 함께 **443번 포트(HTTPS용)**를 사용하여 구글 서버와 연결을 시도합니다.
HTTP 요청 메시지 생성:
- 브라우저는 사용자의 요청(/search?q=hello&hl=ko)을 HTTP 요청 메시지로 생성하여 서버에 전송합니다.
- 이 과정에서 HTTPS를 사용하면 데이터가 암호화되어 전송됩니다.
서버 응답:
- 서버(200.200.200.2)는 요청을 처리한 후 결과를 브라우저로 반환합니다.
결과 표시:
- 브라우저는 서버에서 받은 응답 데이터를 사용자에게 표시합니다(예: 구글 검색 결과 페이지).

[HTTP] 1. Internet Network

VHAL_ — Tue, 19 Nov 2024 14:10:11 +0900

** 해당 포스팅은 '[인프런] 김영한의 HTTP 웹 기본 지식' 강의 내용을 기록용으로 정리한 글입니다. HTTP의 매우 얕고 넓은 개념을 기록한 점 참고 부탁드리며, 구체적인 내용은 추후 다른 포스팅에서 작성할 예정입니다.

IP란?

IP(Internet Protocol) 란 인터넷에 연결되어 있는 모든 장치들(컴퓨터, 서버 장비, 스마트폰 등)을 식별할 수 있도록 각각의 장비에게 부여되는 고유 주소입니다.

IP의 주요 역할은?

지정한 IP 주소 (IP Address)에 데이터 전달
패킷 (Packet)이라는 통신 단위로 데이터 전달

IP 프로토콜의 한계는?

비연결성
- 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
비신뢰성
- 중간에 패킷이 사라지면?
- 패킷이 순서대로 안오면?
프로그램 구분
- 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?

TCP/IP란?

TCP/IP를 알아보기 이전, 인터넷 프로토콜에 관련하여 간단하게 알아보겠습니다.

인터넷 프로토콜
인터넷에서 컴퓨터들이 서로 정보를 주고 받는데 쓰이는 통신규약.
여러가지 종류의 인터넷 프로토콜이 있으나 그 중 TCP/IP가 가장 많이 쓰이기 때문에 TCP/IP 프로토콜이라고 함께 부르는 경우가 많다.

인터넷 프로토콜은 다음과 같이 4계층으로 이루어져 있습니다.
각 계층은 인터넷 통신에서 특정 역할을 담당하며, 데이터를 전송하고 수신하는 데 필요한 기능을 분리하여 정의합니다.

프로토콜 계층에서 데이터는 어떻게 전달될까요?

데이터가 애플리케이션에서 생성되어 인터넷을 통해 전송되고, 서버에 도달하기까지의 과정을 간단하게 시각적으로 보여드리겠습니다.

TCP/IP 정의

TCP/IP는 하나의 프로토콜이 아니라 TCP와 IP를 합쳐 부르는 말입니다. TCP/IP를 사용한다는 것은 IP 주소 체계를 따라 목적지에 데이터를 전달하고, IP 라우팅을 통해 데이터가 올바른 경로로 도달하도록 한다는 의미입니다. 또한, TCP의 특징을 활용해 송신자와 수신자 간의 논리적 연결을 생성하고 데이터 전송의 신뢰성을 유지할 수 있도록 보장합니다.
즉, TCP/IP를 말한다는 것은 송신자가 수신자에게 IP 주소를 사용해 데이터를 전달하고, 데이터가 제대로 전달되었는지, 너무 빠르거나 느리지 않은지, 정상적으로 수신되었는지에 대해 이야기하는 것을 의미합니다.

☁️ TCP 특징

TCP는 전송 제어 프로토콜 (Transmission Control Protocol)이며 현재는 대부분 TCP를 사용합니다.

연결지향 - TCP 3 way handshake (가상 연결)
- 의미 : TCP/IP 프로토콜을 이용해서 통신을 하는 응용 프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 상대방 컴와 사전에 세션을 수립하는 과정
- SYN(접속 요청), ACK(요청 수락)을 사용
데이터 전달 보증
- 전송한 데이터를 잘 받았는지 확인
순서 보장
- 전송한 순서대로 도착
신뢰할 수 있는 프로토콜

☁️ UDP 특징

UDP는 사용자 데이터그램 프로토콜(User Datagram Protocol)입니다.

연결지향 X - TCP 3 way handshake X
데이터 전달 보증 X
순서 보장 X
데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름

추상적으로 정리하자면, IP와 거의 유사하지만, port와 체크섬 정도가 추가된 것입니다. 따라서 애플리케이션에서 추가 작업이 필요합니다.

Port 란?

포트(port)는 '논리적인 접속장소'이며, 특히 인터넷 프로토콜인 TCP/IP를 사용할 때에는 클라이언트 프로그램이 네트워크 상의 특정 서버 프로그램을 지정하는 방법으로 사용됩니다.

네트워크 상에서 통신을 할 때 IP를 토대로 해당 서버가 있는 컴퓨터에 접근하게 됩니다. 하지만 대부분의 경우 하나의 컴퓨터에는 여러 개의 서버가 실행될 수 있습니다. 이렇게 컴퓨터에 여러 개의 서버가 실행되고 있다면, 어느 서버에 접속해야 하는지 컴퓨터에게 알려주어야 합니다. 이때 사용되는 것이 바로 포트 번호입니다 !

포트 번호의 범위는 ?

포트 번호는 0~65535번까지의 범위를 가집니다. 이 중 일부는 특정 용도로 예약되어 있습니다.

0~1023 (Well-Known Ports): 표준화된 서비스와 프로토콜에 할당된 포트.
예:
- 80번: HTTP (웹 서버)
- 443번: HTTPS (보안 웹 서버)
- 25번: SMTP (메일 전송)
1024~49151 (Registered Ports): 특정 응용 프로그램에 등록된 포트.
예: 3306번 (MySQL), 5432번 (PostgreSQL).
49152~65535 (Dynamic/Private Ports): 임시 포트로, 클라이언트가 서버와 연결할 때 동적으로 사용됩니다.

DNS란?

DNS(Domain Name System)는 도메인 이름과 IP 주소를 매핑하는 시스템입니다. 인터넷 상의 모든 장치는 고유한 IP 주소를 통해 통신합니다. 그러나 IP 주소는 숫자로 이루어져 있어 사용자가 기억하기 어렵기 때문에, 사람이 이해하기 쉬운 도메인 이름(예: www.google.com)을 사용할 수 있도록 DNS가 만들어졌습니다.

✔️ DNS의 주요 역할

IP는 기억하기 어려우며, 변경될 수 있습니다. DNS는 변경된 IP 주소를 도메인 이름에 자동으로 매핑하여, 사용자는 IP 주소 변경을 신경 쓰지 않고 도메인 이름만으로 서비스를 이용할 수 있습니다. 즉, 사용자에게는 도메인 이름만 제공되므로, IP 주소가 변경되어도 동일한 도메인 이름으로 서비스를 이용할 수 있습니다.

도메인 이름 → IP 주소 변환
- 사용자가 www.google.com과 같은 도메인 이름을 입력하면, DNS 서버가 이를 IP 주소(예: 142.250.190.78)로 변환하여 해당 웹사이트에 접근할 수 있도록 합니다.
사용자 친화적인 인터넷 환경 제공
- IP 주소 대신 도메인 이름을 사용하므로 기억하기 쉽고, 직관적인 인터넷 사용이 가능합니다.
인터넷의 전화번호부 역할
- DNS는 도메인 이름과 IP 주소를 저장하고 관리하며, 인터넷 사용자가 원하는 웹사이트에 쉽게 연결될 수 있도록 돕습니다.

[Git] 02. Git Branch 전략

VHAL_ — Mon, 18 Nov 2024 13:57:26 +0900

Git Branch란?

Git Branch는 Git에서 코드를 분기하여 관리하는 개념입니다.
Git에서는 기본적으로 master라는 하나의 브랜치를 가지고 있으며, 이 master 브랜치에서 새로운 브랜치를 만들어 작업을 진행합니다.

☁️ Git Branch 전략이란

Git 브랜치 전략은 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow
입니다. 개발 프로젝트를 효율적으로 관리하고, 코드 품질을 유지하며, 협업을 원활하게 하기 위해 브랜치를 사용하는 체계적인 방법이며 프로젝트의 규모와 팀의 협업 방식에 따라 다양한 전략을 사용할 수 있습니다.

git branch 전략이 중요한 이유는?

만일 브랜치 전략이 없는 팀이라면, 어떤 상황이 발생할까요?

~~저는 깃을 잘 모르고, 무작정 깃허브를 활용하여 협업 팀 프로젝트를 진행하였을 때 많은 문제점을 경험했었습니다 ..~~

어떤 브랜치가 최신 브랜치인지 알기 어려웠고, 팀원 사이에 소통이 부족했을 때 어디에 push를 해야 하고 어떤 브랜치를 끌어와야 하는지 혼란스러웠습니다. 또, 버그 수정을 할 때 어떤 브랜치를 기준으로 수정해야 할지 알기 어려웠습니다.

이러한 문제점들을 다 겪으니 브랜치 전략 도입의 중요성을 꺠달을 수 있었습니다 ..

장점은 각 전략마다 조금씩 차이가 있으며, 이 외에도 다양하지만 일부 요약하여 작성하였습니다.

동시 작업이 편하다
- 여러 사람이 독립적으로 작업하고, 커밋을 할 때, 자신의 브랜치에서 변경 사항을 커밋하게 됩니다.
- 브랜치가 병합될 때만 충돌을 해결하면 되니, 아무 규칙이 없는 것보다 충돌 시점이 명확해지기에 생산성을 높일 수 있습니다.
목적이 명확한 브랜치
- 애플리케이션의 상태에 몇 가지가 있는데, 안정된 프로덕션, 테스트 환경, 기능 추가 환경... 등이 있습니다. 여러 기능별 브랜치(안정된 버전의 코드만이 관리되는 브랜치, 테스트 환경을 위한 브랜치, 기능 추가를 위한 브랜치)를 네이밍을 통해 구분하면 각각의 브랜치에 대해서 추가적인 설명을 할 필요 없이 명확하게 관리할 수 있습니다.
배포 파이프라인 관리가 편함
- 브랜치가 네이밍으로 명확하게 구분이 되어있다면, 조건을 설정하기 쉽습니다.
- 특정 타입의 브랜치에 push 되었을 때, pull request를 만들었을 때 같은 조건에 따른 스크립트를 만들어둔다면 CI/CD를 구축하기 쉽습니다.
버전 관리가 편리하다
- 서버에 문제가 생겼을 때, 어떤 브랜치로 돌아가서 롤백을 해야 하는지에 대한 것들이 명확합니다.
- 안정된 브랜치가 어떤 것인지 명확하기에, 롤백 과정에 대한 의사결정을 줄일 수 있습니다.

☁️ Git Branch 전략의 종류는?

그렇다면 브랜치 전략의 종류는 어떻게 될까요?

Git Flow, Github Flow, GitLab Flow 등 이 외에도 다양하지만 주로 널리 사용디는 Git Flow와 Github Flow를 기준으로 설명드리겠습니다.

Git Flow 전략

기본적인 브랜치 이름은 feature, develop, release, hotfix, master 5가지로 구분됩니다.

master, develop 2가지 브랜치는 '항시 유지되는 메인 브랜치'이며 feature, release, hotfiix 3가지 브랜치는 'merge되면 사라지는 보조 브랜치'입니다.

Git Flow 브랜치 구조

Master: 라이브 서버에 제품으로 출시되는 브랜치
Develop : 다음 출시 버전을 대비하여 개발하는 브랜치
Feature : 추가 기능 개발 브랜치. Develop 브랜치에 들어감.
Release : 다음 버전 출시를 준비하는 브랜치. Develop 브랜치를 Release 브랜치로 옮긴 후, QA와 테스트를 진행하고 Master 브랜치로 합친다.
Hotfix : Master 브랜치에서 발생한 버그를 수정하는 브랜치

✔️ 메인 브랜치

메인 브랜치는 master 브랜치와 develop 브랜치 두 종류를 말한다.

master 브랜치는 배포 가능한 상태만을 관리하는 브랜치를 말하며,

develop브랜치는 다음에 배포할 것을 개발하는 브랜치이다.

즉 develop 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행합니다.

✔️ 보조 브랜치

보조 브랜치는 feature branch를 말한다

가지가 뻗어나오는 곳 : develop
뻗어나갔던 가지가 다시 합쳐지는 곳 : develop
이름 설정 : master, develop, release-*, hotfix-*를 제외하기만 하면 자유롭게 이름 설정이 가능하다.
새로운 기능을 추가할 때 주로 사용하는 가지이다.

master 브랜치에서 develop 브랜치를 만들었고,

develop 브랜치에서 다시 feature 브랜치를 나눠 작업을 하고 있는 것을 그림을 통해 알 수 있다.

develop 브랜치에는 기존에 잘 작동하는 개발코드가 담겨있으며, 보조 브랜치는 새로 변경될 개발코드를 분리하고 각각 보존하는 역할을 한다. 즉, 보조 브랜치는 기능을 다 완성할 때까지 유지하고, 다 완성되면 develop 브랜치로 merge 하고 결과가 좋지 못하면 버리는 방향을 취한다. 보조 브랜치는 보통 개발자 저장소에만 있는 브랜치고, origin에는 push하지 않는다.

✔️ 릴리즈 브랜치(release branch)

릴리즈 브랜치는 배포를 위한 최종적인 버그 수정 등의 개발을 수행하는 브랜치를 말한다.

가지가 뻗어나오는 곳 : develop
뻗어나갔던 가지가 다시 합쳐지는 곳 : develop, master
이름 설정 : release-*
새로운 제품을 배포하고자 할 때 사용하는 가지이다.

develop 브랜치에 버전에 포함되는 기능이 merge 되었다면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성한다. 배포 가능한 상태가 되면 master 브랜치로 병합시키고, 출시된 master 브랜치에 버전 태그(ex, v1.0, v0.2)를 추가한다. release 브랜치에서 기능을 점검하며 발견한 버그 수정 사항은 develop 브랜치에도 적용해줘야 한다. 그러므로 배포 완료 후 develop 브랜치에 대해서도 merge 작업을 수행해야 한다.

✔️ 핫픽스 브랜치(hotfix branch)

핫픽스 브랜치는 배포한 버전에서 긴급하게 수정할 필요가 있을 때 master 브랜치에서 분리하는 브랜치를 말한다.

가지가 뻗어나오는 곳 : master
뻗어나갔던 가지가 다시 합쳐지는 곳 : develop, master
이름 설정 : hotfix-*
제품에서 버그가 발생했을 경우에는 처리를 위해 이 가지로 해당 정보들을 모아준다. 버그에 대한 수정이 완료된 후에는 develop, master에 곧장 반영해주며 tag를 통해 관련 정보를 기록해둔다.

버그를 잡는 사람이 일하는 동안에도 다른 사람들은 develop 브랜치에서 하던 일을 계속할 수 있다.

이 때 만든 hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge 하여 문제가 되는 부분을 처리해줘야 한다.

release 가지가 생성되어 관리되고 있는 상태라면 해당 가지에 hotfix정보를 병합시켜 다음번 배포 시 반영이 정상적으로 이루어질 수 있도록 해준다. Hotfix는 보통 다급하게 버그를 고치기 위해 생성되는 가지이기 때문에 버그를 해결하면 보통 제거하는 일회성 가지다.

Git flow 흐름

앞에서 적었던 기본 구조 5개 중 가장 많이 사용되는 가지는 master와 develop가 되며 정상적인 프로젝트를 진행하기 위해서는 둘 모두를 운용해야 한다.
나머지 feature, release, hotfix branch는 사용하지 않는다면 지우더라도 오류가 발생하지 않기 때문에 깔끔한 프로젝트 진행을 원한다면 지워뒀다가 해당 가지를 활용해야 할 상황이 왔을 때 만들어줘도 괜찮다.
대부분의 작업은 develop에서 취합한다 생각하면 되며 테스트를 통해 정말 확실하게 더 이상 변동사항이 없다 싶을 때 master로의 병합을 진행하게 된다.
master가 아닌 가지들은 master의 변동사항을 꾸준히 주시해야 한다.

1. 신규 기능 개발

개발자는 develop 브랜치로부터 본인이 신규 개발할 기능을 위한 feature 브랜치를 생성한다.
feature 브랜치에서 기능을 완성하면 develop 브랜치에 merge를 진행하게 된다.

2. 라이브 서버로 배포

feature 브랜치들이 모두 develop 브랜치에 merge 되었다면 QA를 위해 release 브랜치를 생성한다.
release 브랜치를 통해 오류가 확인된다면 release 브랜치 내에서 수정을 진행한다.
QA와 테스트를 모두 통과했다면, 배포를 위해 release 브랜치를 master 브랜치 쪽으로 merge하며,
만일 release 브랜치 내부에서 오류 수정이 진행되었을 경우 동기화를 위해 develop 브랜치 쪽에도 merge를 진행한다.

3. 배포 후 관리

만일 배포된 라이브 서버(master)에서 버그가 발생된다면, hotfix 브랜치를 생성하여 버그 픽스를 진행한다.
그리고 종료된 버그 픽스를 master와 develop 양 쪽에 merge하여 동기화 시킨다.

Github Flow 전략

GitHub Flow는 간단하고 직관적인 브랜치 전략으로, 빠르게 변화하는 프로젝트나 소규모 팀에서 주로 사용됩니다.

기본적으로 master 브랜치에 대한 규칙만 정확하게 정립되어 있다면 나머지 가지들에 대해서는 특별한 관여를 하지 않으며 PR(Pull Request)기능을 사용하도록 권장합니다.

GitHub-Flow 특징

release branch가 명확하게 구분되지 않은 시스템에서의 사용이 유용하다.
GitHub 자체의 서비스 특성상 배포의 개념이 없는 시스템으로 되어있기 때문에 이 flow가 유용하다.
웹 서비스들에 배포의 개념이 없어지고 있는 추세이기 때문에 앞으로도 Git flow에 비해 사용하기에 더 수월할 것이다.
hotfix와 가장 작은 기능을 구분하지 않는다. 모든 구분사항들도 결국 개발자가 전부 수정하는 일들 중 하나이기 때문이다. 이 대신 구분하는 것은 우선 순위가 어떤 것이 더 높은지에 대한 것이다.

Github-Flow 흐름

1. 브랜치 생성

Github-flow 전략은 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성하는 것으로 시작된다.

단, 이때 체계적인 분류 없이 브랜치 하나에 의존하게 되기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 매우 중요하다.

master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치다. 이 브랜치에 대해서는 엄격한 role과 함께 사용한다
새로운 브랜치는 항상 master 브랜치에서 만든다
Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않는다.
그렇지만, 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자

2. 개발 & 커밋 & 푸쉬

개발을 진행하면서 커밋을 남긴다.
이때도 브랜치와 같이 커밋 메세지에 의존해야 하기 때문에, 커밋 메세지를 최대한 상세하게 적어주는 것이 중요하다.

커밋메시지를 명확하게 작성하자
원격지 브랜치로 수시로 push 하자
Git-flow와 상반되는 방식
항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다
이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다

3. PR(Pull Request) 생성

피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성한다

pull request는 코드 리뷰를 도와주는 시스템
이것을 이용해 자신의 코드를 공유하고, 리뷰받는다.
merge 준비가 완료되었다면 master 브랜치로 반영을 요구한다.

4. 리뷰 & 토의

Pull-Request가 master 브랜치 쪽에 합쳐진다면 곧장 라이브 서버에 배포되는 것과 다름 없으므로, 상세한 리뷰와 토의가 이루어져야 한다.

5. 테스트

리뷰와 토의가 끝났다면 해당 내용을 라이브 서버(혹은 테스트 환경)에 배포해본다.

배포시 문제가 발생한다면 곧장 master 브랜치의 내용을 다시 배포하여 초기화 시킨다.

6. 최종 Merge

라이브 서버(혹은 테스트 환경)에 배포했음에도 문제가 발견되지 않았다면 그대로 master 브랜치에 푸시를 하고, 즉시 배포를 진행한다.

대부분의 Github-flow 에선 master 브랜치를 최신 브랜치라고 가정하기 때문에 배포 자동화 도구를 이용해서 Merge 즉시 배포를 시킨다.

master로 merge되고 push 되었을 때는, 즉시 배포되어야한다

GitHub-flow의 핵심
master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓는다. (CI / CD)

☁️ Git Flow vs Github Flow 비교하기

결론적으로, 1개월 이상의 긴 호흡으로 개발하여 주기적으로 배포, QA 및 테스트, hotfix 등 수행할 수 있는 여력이 있는 팀이라면 git-flow가 적합하다. 하지만 수시로 릴리즈 되어야 할 필요가 있는 서비스를 지속적으로 테스트하고 배포하는 팀이라면 github-flow와 같은 간단한 work-flow가 적합하다.

[Git] 01. Git의 기본 개념

VHAL_ — Mon, 18 Nov 2024 12:40:42 +0900

Git이란 무엇인가

Git은 분산 버전 관리 시스템으로, 파일의 변경 이력을 기록하고 협업을 가능하게 하는 도구입니다.

Git을 사용하면 코드와 파일의 변화를 시간순으로 기록하고, 이전 상태로 되돌리거나 여러 사람이 동시에 같은 프로젝트에서 작업할 수 있습니다.

☁️ 기본 개념

1. Repository와 Commit

Repository(저장소)
Git에서 파일의 변경 이력을 관리하는 공간으로, 프로젝트의 전체 상태와 이력을 저장합니다. 저장소는 로컬(Local) 저장소와 원격(Remote) 저장소로 나뉩니다.
- 로컬 저장소: 사용자 컴퓨터에 저장된 Git 저장소.
- 원격 저장소: GitHub, GitLab 같은 서버에 저장된 Git 저장소.
Commit(커밋)
변경된 파일의 상태를 기록한 스냅샷입니다. Git은 커밋 단위로 변경 사항을 추적하며, 각 커밋은 고유한 해시값을 가집니다.

2. Branch와 Merge

Branch(브랜치)
브랜치는 저장소의 독립적인 작업 공간으로, 프로젝트의 기본 흐름(main)에서 분기하여 새로운 작업을 할 수 있습니다.
Merge(병합)
브랜치에서 작업한 변경 사항을 다른 브랜치(main 등)와 통합하는 작업입니다.

3. Staging Area와 Working Directory

Working Directory (작업 디렉터리): 현재 사용자가 작업 중인 파일들이 있는 공간입니다.
Staging Area (스테이징 영역): 커밋 전에 변경 사항을 임시로 저장하는 공간으로, 커밋할 파일들을 준비하는 단계입니다.
Repository (저장소): 커밋된 파일들이 영구적으로 저장되는 공간입니다.

☁️ File Status Lifecycle

Git에서 파일은 다음 4가지 상태 중 하나에 속합니다:

Untracked (추적되지 않음)
- Git이 추적하지 않는 새로운 파일입니다.
- git add 명령어로 파일을 스테이징 영역에 추가하면 Staged 상태로 전환됩니다.
Unmodified (변경되지 않음)
- Git이 추적하고 있으며, 마지막 커밋 이후 변경되지 않은 파일입니다.
- 이 상태의 파일은 커밋 내용과 동일하므로 아무 작업도 필요하지 않습니다.
Modified (수정됨)
- Git이 추적 중인 파일이 변경되었지만, 아직 스테이징 영역에 추가되지 않은 상태입니다.
- git add 명령어로 변경된 내용을 스테이징 영역에 추가할 수 있습니다.
Staged (스테이징됨)
- 변경된 파일이 스테이징 영역에 추가되어 커밋 준비가 된 상태입니다.
- git commit 명령어로 변경 사항을 저장소에 커밋할 수 있습니다.

[CI/CD] Github Action으로 CI/CD 구축하기

VHAL_ — Sun, 17 Nov 2024 11:50:34 +0900

Github Action이란?

Github Action 공식 문서 : Link

GitHub Actions은 GitHub 플랫폼에서 제공하는 자동화 및 지속적 통합/지속적 배포(CI/CD) 서비스입니다. 소프트웨어 개발 라이프사이클 안에서 Pull Request, Push 등의 이벤트 발생에 따라 자동화된 작업을 진행할 수 있게 해주며 코드의 통합과 배포 프로세스를 자동화하여 개발 생산성을 향상시킬 수 있습니다.

** 하단의 글들을 모두 타블로그의 글을 참고한 추후 수정 목적의 개인 공부용 글입니다. **

시작하기

✔️ 템플릿 이용하기

공식문서의 Quick Start에도 설명이 잘 되어 있듯이, 이미 기본적인 프로젝트에 대한 CI/CD 템플릿을 어느정도 지원하고 있습니다. 간단한 프로젝트라면 이미 구축되어 있는 템플릿을 활용하는 것도 빠른 CI/CD를 구축하는데 도움이 될 것 같습니다.

CI/CD를 구축하고 싶은 Repository로 이동하여 Actions 탭을 누르면 다음과 같은 화면이 보입니다. 여기서 원하는 템플릿을 가져다 쓰면 됩니다!

하지만 이번 포스팅에서는 워크플로우를 직접 구성하여 클라우드 서비스와 연동하는 과정까지 직접 작성한 내용에 대해 다루어보도록 하겠습니다.

✔️ .github/workflows/cicd.yml

처음 접하는 yaml 문법이라면, 속도가 당연히 더딜 수는 있어도 프로젝트 환경에 맞는 배포 워크플로우를 커스터마이징 할 수 있다는 장점이 있습니다.

다만, 워크플로우를 작성할 때는 yaml 파일이 프로젝트 폴더의 .github/workflows/ 디렉토리에 위치해있는지 확인하면 됩니다.

  .github
  ├── workflows
  │   └── cicd-file-name.yml
  src
  app.ts
  package.json
  │
  ...

yaml이란?
yaml이란 데이터 표현 양식의 한 종류이며 기본적으로 들여쓰기(indent)를 원칙으로 하며 데이터는 Map(key-value)형식으로 작성되어야 합니다.

구성요소

Workflow

Workflow란 레포지토리에 추가할 수 있는 일련의 자동화된 커맨드 집합입니다.

하나 이상의 Job으로 구성되어 있으며, Push나 PR과 같은 이벤트에 의해 실행될 수도 있고 특정 시간대에 실행될 수도 있습니다. 빌드, 테스트, 배포 등 각각의 역할에 맞는 Workflow를 추가할 수 있고, .github/workflows 디렉토리에 YAML 형태로 저장합니다.

Event

Event란 Workflow를 실행시키는 Push, Pull Request, Commit 등의 특정 행동을 의미합니다.

그리고 위의 특정 행동이 아닌, Repository Dispatch Webhook을 사용하면 Github 외부에서 발생한 이벤트에 의해서도 Workflow를 실행시킬 수 있습니다. Event 종류에 대해 더 알고 싶다면 Github Actions 공식 문서를 확인해주세요.

Jobs

Job이란 동일한 Runner에서 실행되는 여러 Step의 집합을 의미합니다.
워크플로우에서 특정 이벤트에 따라 처리하는 프로세스를 구분하고 정의할 수 있습니다.프로세스는 각각의 step으로 나뉘고 이 step은 shell에서 동작하는 CLI와 동일하게 실행이 됩니다.각각의 step들 정의한 순서대로 실행되며, step 별로 동일한 환경변수를 지정할 수 있어 데이터를 공유할 수 있습니다. 기본적으로 하나의 Workflow 내의 여러 Job은 독립적으로 실행되지만, 필요에 따라 의존 관계를 설정하여 순서를 지정해줄 수 있습니다.

Actions

Action이란 Job을 만들기 위해 Step을 결합한 독립적인 커맨드로, 재사용이 가능한 Workflow의 가장 작은 단위의 블럭입니다. 반복되는 코드를 모듈이나 함수로 관리하는 것처럼 복잡하고 자주 사용되는 작업을 정의할 수 있습니다.워크플로우 내에서 자주 반복되는 스크립트를 미리 정의하여 좀 더 효율적으로 관리할 수 있습니다.이미 많은 사용자들이 불편함을 느껴 GitHub 마켓플레이스에 퍼블릭하게 배포해 놓은 action들이 많이 있으니, 참고하여 각자 개발 프로세스에 맞는 CI/CD를 구축할 수 있겠네요!

env

환경변수가 반드시 필요한 구성요소는 아니지만, 노출되어서는 안되는 민감한 정보를 환경변수로 설정하여 사용할 수 있습니다. Repository별로 환경변수를 독립적으로 설정할 수 있고, Organization을 사용한다면, 모든 Repository에 적용되는 환경변수를 관리할 수 있습니다.

Step

Step이란 커맨드를 실행할 수 있는 각각의 Task를 의미하는데, Shell 커맨드가 될 수도 있고, 하나의 Action이 될 수도 있습니다.
하나의 Job 내에서 각각의 Step은 다양한 Task로 인해 생성된 데이터를 공유할 수 있습니다.

Runner

Runner란 Github Actions Workflow 내에 있는 Job을 실행시키기 위한 애플리케이션입니다.
Runner Application은 Github에서 호스팅하는 가상 환경 또는 직접 호스팅하는 가상 환경에서 실행 가능하며, Github에서 호스팅하는 가상 인스턴스의 경우에는 메모리 및 용량 제한이 존재합니다.

아래 화면과 같이 Settings -> Secrets and variables (Actions) -> New Repository secret 순으로 이동합니다.
이후 아래와 같이 환경변수로 사용할 변수명과 실제 값을 기입해줍니다.
사용방법은 다음과 같습니다:

- name: Environment Setup
  run: ${{ secrets.등록한_환경변수_이름 }}

출력값:

# in Linux Terminal
실제_등록한_환경변수_값이 출력됩니다.

with AWS

✔️ AWS Certification

Github Action이 실행되는 repository에 환경변수를 직접 추가해주었기 때문에, 이제 환경변수에 손쉽게 접근할 수 있습니다. 노출에 민감한 값을 적용할 때 권장되는 방법입니다. 환경변수를 워크플로우 내부에서 지정하여 사용하는 방법에 대해서는 Slack API 단락을 확인해주세요.

환경변수 사용 예시 아래 예시 코드는 AWS credential 인증을 위한 action 코드입니다. 이 때 필요한 값은 access-key-id와 secret-access-key 값입니다. 하지만 외부 제 3자가 이 두가지 값을 안다면, 내부 리소스에 접근할 수 있기 때문에 환경변수로 관리해야합니다. repository에 등록한 환경변수에는 {{ secrets.Name }} 과 같은 방식으로 접근할 수 있습니다.
Name에는 직접 입력한 환경변수의 Key 값을 입력하여 사용할 수 있습니다.
```
- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v1
  with:
      aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
      aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      aws-region: ap-northeast-2
```

✔️ Frontend Deployment (S3)

Deploy to S3

S3 버킷에 build 파일을 업로드 하여 Frontend 코드를 배포하고 해당 S3 스토리지에 저장된 파일을 CloudFront에서 전달하는 배포 프로세스를 따르고 있습니다. 우리는 build 파일을 S3에 업로드만 하면 되기 때문에 해당 워크플로우를 들여다보겠습니다.

마찬가지로 name은 원하는 워크플로우 이름을 지정해줍시다.
어떤 폴더를 빌드 폴더로 지정할 지 정해줍니다. 여기서는 build 폴더로 지정하겠습니다.
S3에 접근할 때 사용되는 Action인 lbertenasco/s3-deploy@v1을 사용해줍니다.
bucket의 실제 이름과 cloudfront의 dist-id 값을 repository 환경변수에 등록을 해주고, 필요한 필드에 값을 치환해주면 됩니다.
배포가 될 때마다 새로운 컨텐츠를 제공할 수 있도록 invalidation 설정을 해줍니다. 캐시 무효화 작업을 통해 배포가 되면 캐싱 데이터를 전달하지 않고 새로운 데이터를 전달합니다.

- name: Deploy
    uses: lbertenasco/s3-deploy@v1
    with:
      folder: build
      bucket: ${{ secrets.S3_BUCKET }}
      dist-id: ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }}
      invalidation: / *

✔️ Backend Deployment (EC2)

Inbound Control IP4V

EC2 인스턴스에 소스 코드를 내려 받고 pm2를 활용하여 서버를 배포하고 있습니다.

마찬가지로 step 별로 뜯어보겠습니다.

Github Action IP 주소 받기 haythem/public-ip@v1.2 액션을 통해 ip 값을 id에 지정해줍니다.
이 값은 이후 스텝에서 사용됩니다.
```
- name: Get GitHub Actions IP
  id: ip
  uses: haythem/public-ip@v1.2
```
인바운드 규칙에 IP주소 화이트리스트 등록하기 SSH에 직접 접근하는 방식으로 배포를 하고 있습니다.
만약 외부에서 SSH 접속을 통해 API 내부에 침투한다면 굉장히 위험하기 때문에 인바운드 규칙에서 접속 가능한 IP 리스트를 제한하고 있습니다.
로컬 뿐만이 아니라, Github Action에서 SSH 접속을 허용해야 하기 때문에 아래와 같은 스크립트를 작성할 수 있습니다.
- 보안그룹 ID 값이 필요합니다. --group-id 플래그에 대한 값에 지정해줍니다.
- tcp port는 SSH접속 목적이기 때문에 22port로 지정해줍니다.
- cidr은 Github Action의 IPv4 대역을 받아옵니다. 1번에서 id에 ip 값을 할당하고 있는데 그 값을 사용할 수 있습니다. steps.ip.output.ipv4 라는 값을 사용할 수 있습니다.
- name: Add Github Actions IP to Security group
  run: |
  aws ec2 authorize-security-group-ingress \
  --group-id ${{ secrets.PROD_AWS_SG_ID }} \
  --protocol tcp --port 22 \
  --cidr ${{ steps.ip.outputs.ipv4 }}/32

Deploy to EC2

Github Action의 CIDR이 인바운드 규칙에 등록이 되었다면, CI/CD가 실행되는 네트워크에서 우리 서버 EC2로 접속할 수 있게 됩니다.

EC2에 접속하기 위해 appleboy/ssh-action@master 액션을 사용하며, 필요한 값은 다음과 같습니다:

AW_SSH_KEY: *.pem 값을 환경변수로 지정해줍니다.
AWS_HOST: 호스트는 EC2의 인스턴스의 퍼블릭 CIDR을 가리킵니다.

실제로 Github Action이 실행되는 터미널을 확인해보면, 로컬에서 접속하는 것과 동일하게 EC2 인스턴스에 접속해있는 것을 확인할 수 있습니다. 이제 EC2 인스턴스 내부에서 리눅스 명령어를 사용하여 Backend 소스 코드를 받아오고 pm2 매니저를 활용하여 서비스를 중단하지 않고 배포를 해보겠습니다.

git pull origin “branch”
Install Dependencies (mecab-ko 설치 필요!)
pm2 reload

- name: EC2 Production Server Deploy
    uses: appleboy/ssh-action@master
    with:
      key: ${{ secrets.PROD_AWS_SSH_KEY }}
      host: ${{ secrets.PROD_AWS_HOST }}
      username: ubuntu
      script: |
        export NVM_DIR=~/.nvm
        source ~/.nvm/nvm.sh
        pm2 stop 0
        pm2 stop 1
        pm2 save
        cd 2minutes
        git checkout main
        git pull origin main
        npm ci && node_modules/mecab-ya/bin/install-mecab ko
        pm2 start 0
        pm2 start 1
        pm2 save

with Cache node_modules

✔️ GitHub Action은 cache를 제공한다

mecab-ko-dic을 OS에 설치하는 방법이 반드시 필요하다!

GitHub Actiond에서는 특정 파일을 해시값으로 바꾸어 해당 파일을 캐싱할 수 있습니다.
아래 소스 코드를 살펴보겠습니다.

 - name: Cache Dependencies
     id: dependency-cache
     uses: actions/cache@v3
     with:
   		# 캐시 대상이 되는 파일입니다.
        # node_module 디렉토리의 하위 내용을 모두 캐시하겠다는 의미입니다.
        path: "**/node_modules"
    	
        # 캐시를 식별할 때 사용하느 옵션입니다.
    	# npm-package 대신 저장하고 싶은 캐시 키 값을 사용할 수 있습니다.
    	# ${{ hashFiles('**/package-lock.json') }}은 package-lock.json 파일 내용을 해시값으로 저장합니다.
    	# 여기서 해싱이 되어 저장된 package-lock.json 파일과 새로운 commit 코드의 package-lock.json 파일이 일치하는지 확인합니다.
    	key: npm-package-${{ hashFiles('**/package-lock.json') }}
    
    	# 캐싱이 되어있는 해시 파일을 찾습니다.
    	# 해시 파일을 찾는 기준은 restore-keys에 등록된 순으로 찾습니다.
    	# 예를 들어, Caches에 npm-package-1, npm-package-2, npm-package-3 이라는 파일이 있다고 가정해봅시다.
    	# 이 때 package-lock.json의 해싱 파일이 npm-package-1로 되어 있다면, npm-package-1을 기준 캐시 데이터로 지정합니다.
    	# 지정된 캐시 파일은 commit의 package-lock.json 파일을 비교하는 작업을 하게됩니다.
    	#  *** PR이 달라도 기존 캐시 파일을 찾기 때문에 local-build & test 속도를 향상시킬 수 있습니다. ***
    	retore-keys: |
      	  npm-package-${{ hashFiles('**/package-lock.json') }}
          npm-package-

만약 새로 개발한 작업에서 써드파티 라이브러리를 사용하는 경우 새로운 디펜던시가 추가가 될 것입니다.
그럼 새로운 작업 소스 코드의 package-lock.json 파일과 캐싱된 파일을 비교하여, 변동 사항이 없다면 굳이 디펜던시를 다시 설치하여 사용할 필요가 없다고 판단하게 됩니다.

with Slack Message

✔️ Slack 수신웹후크 (Incoming Webhook)

Github Action에서 Slack 메시지를 보내는 방법은 이 포스팅에서 소개하는 방식 외에도 다양한 방법이 이습니다. 그 중 Slack API의 수신웹후크를 사용하여 CI/CD의 결과를 Slack 메시지로 보내는 방법에 대해 소개해보겠습니다.

앱 생성 방식이 아닌 앱 추가 방식을 우선 소개합니다.
만약 회사 공용 slack 계정으로 추가할 경우 앱 추가 방식이 문제가 되진 않지만,
팀을 떠날 가능성이 있다면 개인 계정을 사용할 경우 앱 생성 방식을 권장합니다.

앱 추가 절차

앱 관리 > Incoming Webhook 검색 > 원하는 채널에 추가
구성 편집의 웹훅 URL 정보 확인. (Github Repository의 환경변수로 지정해줍니다.)

✔️ Github Action에서 슬랙 메시지 전송하기

슬랙메시지 전송 job 구성하기 local 테스트 및 staging & production에 코드를 배포하는 job이 종료가 되면, CI/CD의 결과를 슬랙 메시지로 전송하기 위한 job을 추가해보겠습니다. 슬랙 메시지는 결과가 어떻든 항상 보내져야 하는 작업이기 때문에 조건을 추가해줍니다. always()함수를 통해 위에서 실행된 CI/CD의 결과가 어떻든 해당 job은 항상 실행이 되도록 지정할 수 있습니다. 선행 결과를 고려하지는 않아도 반드시 필요한 선행 결과를 지정해주어야 그 결과를 슬랙 채널에 전달할 수 있기 때문에 needs 옵션을 사용하여 반드시 선행되어야 하는 job의 이름을 지정해줍니다.
```
jobs:
  slack_notification:
	  if: ${{ always() }}
    needs: [ 로컬, 스테이징, 프로덕션 ]
    runs-on: ubuntu-latest
```

슬랙메시지 커스터마이즈 로컬테스트, staging & production 서버 배포의 결과에 따라 상태메시지 (STATUS)와 슬랙에서 사용될 이모지 (IMOJI)를 커스터마이즈 할 수 있습니다. run 옵션에 아래와 같은 리눅스 명령어를 작성해줍니다. if … then … elif … then fi 구문은 조건절을 나타냅니다. 조건절은 항상 fi 를 작성하여 구문을 종료합니다. 우선, github.ref라는 변수에 접근하여 Github Action이 실행될 때 저장되는 branch의 이름을 받아올 수 있습니다. 해당 값에 따라 슬랙 메시지에 보여질 BUILD_NAME 변수에 값을 동적으로 지정해줄 수 있습니다.
```
... slack_notification jobs ...

steps:
  - name: CUSTOM_STATUS SET UP
    run: |
      if [ "${{ github.ref }}" = "refs/heads/develop" ];
      then
        BUILD_NAME="Staging Deploy"
      elif [ "${{ github.ref }}" = "refs/heads/main" ];
      then
        BUILD_NAME="Production Deploy"
      else
        BUILD_NAME="Local Build & Test"
      fi
```
다음으로 needs 옵션에 추가했던 선행 job들의 결과에 따라 슬랙메시지에 보여질 상태메시지와 이모지를 지정해주는 스크립트입니다. needs.지정한_job_이름.result 을 통해 해당 job의 실행결과를 받아올 수 있습니다.
실행 결과 값은 아래와 같습니다:
- success: 성공
- failure: 테스트 또는 빌드 실패, 내부 네트워크 에러 등
- cancelled: 의도적 중단 혹은 내부 네트워크 에러 등해당 job에서 사용될 환경변수를 GITHUB_ENV에 추가하여 실제로 그 값을 호출하고 사용할 수 있도록 지정해줍니다.
```
... slack_notification jobs ...

steps:
  - name: CUSTOM_STATUS SET UP
    run: |
      ... BUILD_NAME Set up...
      ... STATUS & IMOJI Set up...
      echo "CUSTOM_STATUS=${CUSTOM_STATUS}" >> $GITHUB_ENV
      echo "BUILD_NAME=${BUILD_NAME}" >> $GITHUB_ENV
      echo "SLACK_EMOJI=${SLACK_EMOJI}" >> $GITHUB_ENV
```
- echo "key: value" >> 환경변수_등록_파일 을 통해 환경변수를 지정해줄 수 있습니다:
- ... slack_notification jobs ... steps: - name: CUSTOM_STATUS SET UP run: | ... BUILD_NAME Set up... if [ "${{ needs.local_build_test.result }}" = "failure" ] || \ [ "${{ needs.deploy_staging.result }}" = "failure" ] || \ [ "${{ needs.deploy_production.result }}" = "failure" ]; then CUSTOM_STATUS="Failure" SLACK_EMOJI=":boom:" elif [ "${{ needs.local_build_test.result }}" = "cancelled" ] || \ [ "${{ needs.deploy_staging.result }}" = "cancelled" ] || \ [ "${{ needs.deploy_production.result }}" = "cancelled" ]; then CUSTOM_STATUS="Aborted" SLACK_EMOJI=":exclamation:" else CUSTOM_STATUS="Success" SLACK_EMOJI=":rocket:" fi

✔️ Webhook을 이용하여 슬랙메시지 보내기

슬랙 메시지 전송 옵션은 아래와 같습니다.

사용 Action uses
- rtCamp/action-slack-notify@v2
슬랙 메시지에 전달 되는 변수 env
- SLACK_WEBHOOK
  첫번째 단계에서 Github Repository에 지정한 환경변수를 불러옵니다.
- MSG_MINIMAL
  웹훅에서 기본값으로 보내주는 값들입니다. 불필요한 값은 해당 필드에 추가하여 제거해주고 더욱 깔끔한 슬랙 메시지로 커스터마이즈 할 수 있습니다.
- SLACK_CHNNEL
  슬랙 메시지가 전송 될 채널을 지정해줍니다.
- SLACK_COLOR
  job의 실행 결과의 색을 따르도록 지정합니다. 커스터마이즈 가능합니다.
- SLACK_ICON
  슬랙메시지가 보내질 때 프로필 사진을 지정할 수 있습니다. 커스터마이즈 가능합니다.
- SLACK_USERNAME
  슬랙메시지가 보내질 때 이름을 지정할 수 있습니다. 커스터마이즈 가능합니다.
- SLACK_TITLE
  ${{ env.GITHUBENV에등록한_환경변수_key }} 구문을 활용하여 슬랙메시지가 보내질 때 타이틀을 지정할 수 있습니다.
코드 예시

# cicd.yml
- name: Send Slack Message
  uses: rtCamp/action-slack-notify@v2
  env:
    SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}
    MSG_MINIMAL: ref,commit,actions url
    SLACK_CHANNEL: dev
    SLACK_COLOR: ${{ job.status }}
    SLACK_ICON: https://github.com/github.png
    SLACK_USERNAME: GitHub CI/CD
    SLACK_TITLE: '${{ env.SLACK_EMOJI }} ${{ env.BUILD_NAME }}: ${{ env.CUSTOM_STATUS }} ${{ env.SLACK_EMOJI }}'

[CI/CD] 01. CI/CD란 무엇인가

VHAL_ — Fri, 15 Nov 2024 20:26:34 +0900

CICD란?

CI/CD(Continuous Integration/Continuous Deployment or Delivery)는 코드 통합, 테스트, 빌드, 배포 과정을 자동화하여 개발 효율성을 높이고 품질을 유지하기 위한 소프트웨어 개발 방법론

1. CICD의 주요 개념

일반적인 앱의 개발 및 유지보수 단계는 아래와 같습니다. 여기서 지속적 통합 및 지속적 전달을 단계별로 자동화할 수 있습니다.

CI (Continuous Integration) ' 지속적인 통합 '

개발자를 위한 자동화 프로세스라고 볼 수 있으며, Code - Build - Test 단계를 자동화할 수 있습니다.

Code : 개발자가 코드를 원격 코드 저장소 (Ex. github repository)에 push하는 단계
Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계
Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정

애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있습니다.

이전에는 각자 개발자가 작성한 코드를 합치고 난 후, 모두 모여서 빌드를 시작하고 나서야 문제점을 파악할 수 있었습니다. 지속적 통합이 적용된 개발팀은 코드를 머지하기 전, 이미 빌드 오류나 테스트 오류를 확인하여 훨씬 더 효율적인 개발을 할 수 있게 됩니다.

개발자가 작성한 코드를 자주(하루에도 여러 번) 저장소에 통합하는 프로세스.
코드가 통합될 때마다 자동으로 테스트와 빌드를 실행

CD (Continuous Delivery & Deployment) ' 지속적인 제공 & 배포 '

Release - Deploy - Operate 단계를 자동화할 수 있습니다. 지속적으로 통합된 코드를 자동으로 프로덕션 환경에 배포하는 프로세스이며 즉, 개발자가 원클릭으로 수작업 없이 빌드, 테스트, 배포까지의 자동화를 할 수 있습니다.

코드 변경 사항이 테스트 및 승인을 거쳐 자동으로 프로덕션 환경에 배포 (merge to main) 되고, 새로운 기능과 버그 수정 사항이 실제 사용자에게 빠르게 제공됩니다.

Release : 배포 가능한 소프트웨어 패키지를 작성
Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출 > 실질적인 배포
Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지

Continuous Delivery: CI에서 생성된 빌드 결과물을 수동 승인 후 프로덕션 환경에 배포.
Continuous Deployment: CI에서 생성된 결과물을 자동으로 프로덕션 환경에 배포.

2. CI/CD 파이프라인의 주요 구성

개발자가 배포할 때마다 일일히 빌드하고 배포하는 과정을 진행하는 것은 한두 번이면 충분하겠지만, 이러한 과정이 수없이 진행된다면 일일히 이 과정을 수행하는 것이 번잡스럽고 지루할 것이다. 그래서 이 수없이 진행되는 배포 과정을 자동화시키는 방법을 구축하게 되는데, 그것을 CI/CD 파이프라인이라고 한다.

2.1 소스 코드 관리 (Source)

GitHub, GitLab, Bitbucket과 같은 플랫폼에서 소스 코드를 관리
브랜치 전략(예: Git Flow, Trunk-Based)을 활용하여 작업 분리

2.2 빌드 (Build)

코드를 컴파일하고 의존성을 설치하여 실행 가능한 상태로 만드는 단계
ex )
- FE : npm run build
- BE (Java): mvn clean package

2.3 테스트 (Test)

단위 테스트: 기능별 코드가 올바르게 동작하는지 확인
통합 테스트: 여러 컴포넌트 간 상호작용 테스트
E2E 테스트: 실제 사용자 환경에서의 테스트

2.4 배포 (Deploy)

스테이징 환경: 실제 배포 전에 테스트를 위한 환경
프로덕션 환경: 사용자에게 제공되는 환경
배포 도구: Kubernetes, AWS ECS, Docker Swarm 등

3. CI/CD의 주요 도구

3.1 CI/CD 플랫폼

GitHub Actions: GitHub 기반 CI/CD 워크플로우
GitLab CI/CD: GitLab 내장 CI/CD 기능
Jenkins: 오픈소스 CI/CD 서버
CircleCI: 클라우드 기반 CI/CD 서비스
Travis CI: 간단한 설정으로 CI/CD 제공

3.2 빌드 및 테스트 도구

FE : Jest, Mocha, Cypress (테스트), Webpack (빌드)
BE (Java) : JUnit (테스트), Maven/Gradle (빌드)

3.3 배포 도구

Docker: 컨테이너 기반 애플리케이션 배포
Kubernetes : 컨테이너 오케스트레이션 도구
AWS ECS/EKS : AWS의 컨테이너 관리 서비스
Google Cloud Build : Google Cloud의 CI/CD 서비스

[API] 01. Restful API란?

VHAL_ — Thu, 14 Nov 2024 14:41:16 +0900

Restful API란?

REST API란 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스이며 REST를 기반으로 만들어진 API를 의미합니다.

REST API를 알기 위해 REST와 API에 대하여 먼저 알아보겠습니다.

API란?

API는 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘이며 Application Programming Interface(애플리케이션 프로그램 인터페이스)의 줄임말입니다.

다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의하며 웹 API는 클라이언트와 웹 리소스 사이의 게이트웨이라고 생각할 수 있습니다.

REST란?

REST는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처이며 Representational State Transfer(REST)의 줄임말입니다.

REST 아키텍처 스타일 원칙

Uniform Interface (균일한 인터페이스) : 클라이언트와 서버가 동일한 인터페이스를 통해 소통할 수 있도록 하며, 주로 HTTP 프로토콜을 사용합니다.
Stateless (무상태성) : 각 요청이 독립적으로 처리되며, 서버는 클라이언트의 상태를 저장하지 않습니다.
Layered System (계층화 시스템) : 요청과 응답은 여러 계층을 거쳐 전달되며, 이를 통해 보안과 확장성을 강화합니다.
Cacheable (캐시 가능성) : 클라이언트는 응답을 캐싱할 수 있습니다. 이를 통해 성능을 개선할 수 있습니다.
Code on Demand (온디맨드 코드) : 서버는 필요에 따라 클라이언트에 코드를 전송해 동적으로 기능을 확장할 수 있습니다 (선택적 원칙).
Client-Server Architecture (클라이언트-서버 구조): 클라이언트와 서버의 책임을 분리하여 각각 독립적으로 발전할 수 있도록 합니다.

즉, Rest란

HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고
HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.

CRUD Operation이란
CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인
Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말

Create : 데이터 생성(POST)
Read : 데이터 조회(GET)
Update : 데이터 수정(PUT, PATCH)
Delete : 데이터 삭제(DELETE)

REST 구성 요소

자원(Resource) : HTTP URI
자원에 대한 행위(Verb) : HTTP Method
자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load

REST의 장단점

장점
- HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
- HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
- Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
- REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
- 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
- 서버와 클라이언트의 역할을 명확하게 분리한다.

단점
- 표준이 자체가 존재하지 않아 정의가 필요하다.
- HTTP Method 형태가 제한적이다.
- 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.
- 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(익스폴로어)

그럼 다시 돌아와서, RESFUL API란?

RESPT API란 REST의 원리를 따르는 API를 의미합니다.

하지만 REST API를 올바르게 설계하기 위해서는 지켜야 하는 몇가지 규칙이 있으며 HTTP 메서드와 함께 해당 규칙을 알아 보겠습니다.

HTTP 메서드

RESTful API에서 사용하는 주요 HTTP 메서드와 역할을 설명합니다.

GET: 자원의 조회에 사용됩니다. 리소스를 가져올 때 주로 사용하며, 데이터 변경을 일으키지 않습니다.
POST: 자원의 생성에 사용됩니다. 클라이언트에서 서버로 데이터를 전송해 새 리소스를 만듭니다.
PUT: 자원의 전체 수정을 위해 사용됩니다. 기존 리소스를 업데이트합니다.
PATCH: 자원의 부분 수정을 위해 사용됩니다. 일부분만 변경할 때 사용됩니다.
DELETE: 자원의 삭제에 사용됩니다. 클라이언트가 특정 자원을 삭제할 때 사용합니다.

RESTful API 설계 예시

명사형 URI 사용
- RESTful API는 동사 대신 명사를 사용하여 리소스를 표현합니다.
- 예시:
  - 올바른 사용: /users, /products, /orders
  - 잘못된 사용: /getUsers, /createProduct, /deleteOrder
- 리소스의 상태나 액션은 HTTP 메서드로 전달하고, URI에는 리소스만 표시합니다.
소문자 URI와 일관성 유지
- URI에서는 대문자보다는 소문자를 사용하며, 일관성 있는 표기를 유지합니다.
- 예시:
  - 올바른 사용: /users, /products, /orders
  - 잘못된 사용: /Users, /PRODUCTS
마지막에 슬래시 (/) 포함하지 않기
- URI 끝에 슬래시를 추가하지 않는 것이 REST 설계 규칙입니다. 대부분의 RESTful API에서는 URI 마지막에 슬래시가 없는 것을 표준으로 권장합니다.
- 예시:
  - 올바른 사용: /products/123
  - 잘못된 사용: /products/123/
언더바(_) 대신 하이픈(-) 사용
- URI에서 여러 단어를 조합할 때는 **하이픈(-)**을 사용하여 단어를 구분합니다. 언더바는 가독성이 떨어지기 때문에 REST 설계에서는 하이픈을 권장합니다.
- 예시:
  - 올바른 사용: /user-accounts, /order-details
  - 잘못된 사용: /user_accounts, /order_details
파일 확장자를 포함하지 않기
- RESTful API에서는 자원 형식을 나타내기 위해 파일 확장자를 사용하지 않습니다. 대신 클라이언트가 요청 시 Accept 헤더를 사용하여 원하는 응답 형식을 지정합니다.
- 예시:
  - 올바른 사용: /products
  - 잘못된 사용: /products.json, /products.xml
행위를 URI에 포함하지 않기
- URI는 자원만 나타내며, 동작은 HTTP 메서드로 전달합니다. 예를 들어, 조회, 생성, 수정, 삭제 등의 행위는 각각 GET, POST, PUT, DELETE와 같은 메서드로 표현됩니다.
- 예시:
  - 올바른 사용:
    - GET /users (사용자 목록 조회)
    - POST /users (사용자 생성)
    - PUT /users/{id} (특정 사용자 정보 수정)
    - DELETE /users/{id} (특정 사용자 삭제)
  - 잘못된 사용:
    - /getAllUsers, /deleteUser/{id}, /updateUser/{id}
HTTP 상태 코드 사용
- RESTful API는 클라이언트에게 응답 시, 요청의 결과를 HTTP 상태 코드로 전달합니다. 각 상태 코드는 요청 성공, 실패, 잘못된 입력 등의 상황을 나타내며 클라이언트가 적절한 후속 조치를 취할 수 있게 도와줍니다.
  - 200 OK: 요청이 성공적으로 처리되었습니다.
  - 201 Created: 리소스가 성공적으로 생성되었습니다 (주로 POST 요청 후 사용).
  - 204 No Content: 요청이 성공적으로 처리되었으나 반환할 내용이 없습니다 (DELETE 요청 후 주로 사용).
  - 400 Bad Request: 잘못된 요청이 전달되었습니다.
  - 404 Not Found: 요청한 리소스를 찾을 수 없습니다.
  - 500 Internal Server Error: 서버에서 요청을 처리하는 중에 오류가 발생했습니다.
- 예시:
  - GET /users/123 요청이 성공하면 200 OK와 사용자 데이터를 반환
  - POST /users 요청으로 사용자 생성 시 201 Created와 새 사용자 정보를 반환
  - DELETE /users/123 요청이 성공하면 204 No Content 응답

RESTFUL이란 REST의 원리를 따르는 시스템을 의미합니다. 하지만 REST를 사용했다 하여 모두가 RESTful 한 것은 아닙니다. REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있습니다.

[Image Processing] 3. Intensity Transformations and Spatial Filtering

VHAL_ — Thu, 14 Nov 2024 12:47:50 +0900

** 해당 시리즈는 타블로그의 글을 참고하여 공부용으로 기록해놓은 글입니다 **

Basics

1. Intensity Trasnform (밝기값 변환)

원본 이미지f의 밝기를 변환하여 출력 이미지g를 내보내는 함수T

◾ Intensity Trasnform funtion T

(aka. grey-level function, mapping function)

기존 이미지의 픽셀값r을 s로 변환하는 함수T
(T의 종류는 여러가지)

2. Spatial domain Operator (공간 영역 연산)

한 픽셀을 계산할 때 주변(neighbor, window)을 고려하는 것
neighbor pixels의 평균으로 출력 이미지g를 얻음

1. 4-neighbor Averaging

자신 포함 4이웃의 픽셀 값 평균으로 자신의 새로운 픽셀 값 얻음

2. 8-neighbor Averaging

자신 포함 8이웃의 픽셀 값 평균으로 자신의 새로운 픽셀 값 얻음

3. Filtering

Spatial domain operator를 filtering이라고 함
위의 Averaging을 한 값들의 집합

Intensity Transformation Functions 종류

1. Image Negatives

원본 이미지의 범위 [0, L-1]

2. Log Transformation

원본이미지가 0일 때 0이 나옴
상수 c
0은 0이고, 조금이라도 밝으면 밝게 나타남
어두운 부분의 디테일을 살리지만 밝은 부분의 디테일은 감소

3. Pow-Law (Gamma) Transformation

Log Transformaion보다 자주 사용

γ=1 -> 입력값 = 출력값

γ<1 -> 어두운 부분의 디테일 살아남

γ>1 -> 밝은 부분의 디테일 살아남

기울기가 클수록 디테일이 크게 살아남 (input이 작아도 대비(변화)가 높아진다)

γ가 점점 감소하는 경우와 / 점점 증가하는 경우

❗감마가 낮아질 때 / 높아질 때의 기울기, 계수 등 그래프와의 관계 생각해보기

◾ Monitor response

모니터에서 가장 밝은 값은 대략 L = c^2.2

보통 실제 이미지들은 감마 연산을 거쳐서 저장된다.

Linearization

4. Piecewise-Linear Transformation (부분선형변환함수)

좀 더 복잡한 변환 기능을 형성하기 위해 임의로 함수를 정의할 수 있음

a - 기울기, 기울기가 가파를수록 대비가 높아져 어두움과 밝음의 구분이 쉬워짐 -> Contrast

b - b가 양수면 전체 이미지가 밝아지고, 음수면 어두워짐 -> Brightness

ex) Intensity Slicing

특정한 밝기 범위만 밝게하고 나머지는 억제

Histogram Processing

1. Image Intensity Histogram

각 밝기마다 해당하는 픽셀 수를 나타낸 그래프 (특정한 픽셀 값을이 존재할 확률)
어두울 수록 왼쪽에 몰려있고, 밝으면 오른쪽에 몰려있다.
낮은 대비를 가지면 가운데 몰려있고, 대비가 높으면 고르게 잘 퍼져있다.
고르게 잘 퍼진 히스토그램을 만드는 것이 목표 (평탄화)

2. Probability distribution function (PDF, 확률분포)

r의 밝기일 확률 = 특정 r의 밝기를 가진 픽셀의 수 / 전체
누적분포 = 0~r 까지의 확률의 합
평탄화(좋은 대비를 가지는 이미지)가 되려면 모든 히스토그램의 값이 상수면 좋겠다.

3. Histogram Equalization (히스토그램 평탄화)

평탄화되는 intensity transformation 함수
x커지면 y도 커지는 단조함수(monotonically increasing)

◾ Implementation

r의 밝기일 확률의 누적분포와 s의 밝기일 확률의 누적분포가 같다

◾ Result

어둡든 밝든 거의 일정한 값(밝기)을 가진다 라는 특징을 가진다.
사람이 보기 좋다에 초점을 맞춘 것은 X

4. Local(adaptive) histogram equalization (AHE)

global 정규화는 local 대비를 조절할 수 없기 때문에 window에서의 정규화를 해서 local의 대비를 조절한다.
구역마다 정규화 시 경계부분이 어색할 수 있기 때문에 옆 부분과 자연스럽게 섞어준다.

Spatial Filtering Fundamentals

1. Spatial Filtering (공간 필터링)

이미지를 공간적으로 필터링
미리 정의된 Operationw (kernel, mask, ...)
Outputg는 고정, Inputf는 유동적

◾ Similar concept

Correlation(상관관계)

두 개의 독립적인 것들이 어떤 관계를 가지는가
Spatial filtering과 같다.

Convolution

두 함수를 서로 곱해 합친다.

2. Padding

모서리 픽셀을 필터링하면 neighborhood가 존재하지 않는 부분도 생김.
그래서 네 모서리에 임의로 픽셀을 추가한다
(실제로 이미지를 키우는 것은 아니고, 필요한 위치에서 픽셀을 참조해서 해당하는 값을 전달)
Constant padding의 경우, 보통 0으로 채운다. (zero padding)

Smoothing Spatial Filters

위의 Spatial Filtering의 Operation w함수의 역할 중 하나
이미지를 부드럽게 만들기 위해 노이즈를 제거
해상도가 낮아짐

노이즈 제거를 위해 주변에서 좀 튀는 픽셀을 주변과 비슷하게 바꿔줌
neighborhood의 평균

2. Weighted Averaging Filter (Gaussian)

위의 이미지처럼 averaging filtering을 많이 하면 보이는 경계를 보완하기 위한 방법
가까운 이웃의 비중을 살려서 평균을 구함
더 정교한 box(kernel)은 Gaussian

◾ Guassian

가우스 분포는 정규분포로 평균이 0, 표준편차가 σ이다.

σ가 크면 납작하고, σ가 작으면 뾰족한 정규분포이다.

3. Separable Filter (linear)

kernel이 큰 Operation은 시간이 오래걸린다. mxn
몇몇 Operator은 Separable한데, 이것은 가로 세로 커널로 분해 가능한 것을 의미한다.
separable하면 시간은 m+n으로 줄어든다.
세로/가로 필터링을 따로 했을 때와, 전체 필터링 했을 때 결과가 같으면 Separable
ex) box filter, Guassian filter는 Separable

4. Order-Statistic(median) Filters (Non-linear)

이웃 픽셀들을 정렬하여 찾은 중앙값으로 filtering
중심에서 멀리 벗어난 outlier를 삭제할 수 있다. (원본 이미지와 상관없이 noise가 큰 이미지) -> Gaussian과의 차이점

Sharpening Spatial Filters

1. Derivatives (미분)

이미지도 함수니까 미분이 가능하고, Finite difference라는 방식으로 이미지를 미분한다.

◾ Finite difference (Discretized version)

바로 옆 픽셀과의 차이f(x-1)-f(x)가 미분값
오른쪽, 왼쪽 둘 다 가능하다.
미분을 한번 더 하는 경우는, 옆 픽셀과의 한번 미분한 값의 차이이다.

◾Edge (밝기가 변하는 부분)

Ramp: 이미지 밝기가 서서히 변하는 edge

Step: 이미지 밝기가 급격히 변하는 계단 형태의 edge

◾1번 미분

접선의 기울기 (이미지의 밝기 변화 정도)
0이면 일정한 밝기
0이 아니면 Edge
(절댓값이 작은 부분은 Ramp, 큰 부분은 Step Edge)
극대점(미분값이 큰 부분)으로 Edge 검출

◾ 2번 미분

접선의 기울기의 증감 (이미지가 천천히 또는 빠르게 밝기 변화하는 정도)
0이면 일정한 정도로 밝기 변화
0이 아니면 갑자기 꺾어지는 Intensity trnasition 부분
zero crossing가 발생하는 지점으로 명확한 Edge 검출

❗ 실제 영상에서는 Ramp Edge가 많기 때문에 1차로는 정확한 Edge 검출이 어려워서 2번 미분으로 명확한 Edge를 검출하는 것이다.

2. Laplacian

2차 미분의 zero crossing으로 엣지를 검출할 때 사용하는 연산
이미지 방향에 독립적이다. (Isotropic)
밝기의 불연속성을 강조하고, 느리게 변화하는 부분은 강조X
음수가 나올 수 있지만 0 이하는 전부 검정이다. 음수 부분을 확인하기 위해 Laplacian에 전체 상수를 더하면(곱하면?) 색 바뀌는 부분을 더 잘 확인할 수 있다.

3. Image Sharpening with Laplacian (샤프닝1)

상수c를 더한(곱한?) Laplacian 이미지를 원본에 더해 선명하게 만든다.

4. Unsharp Masking and Highboost Filtering (샤프닝2)

box filter 또는 Gausian을 활용해 블러한 이미지f-를 원본 이미지f에서 빼서 세부 디테일 값Unsharp mask만 얻는다.
그 값을 원본에 더해 선명하게 만들어 최종 이미지g를 얻는다.

◾ 상수 k

k=1 : Unsharp masking

k>1 : Highboost filtering (더 선명하게)

k<1 : Unsharp masking의 강조 감소 (선명해지긴 함)

k<0 : blur와 비슷

5. Gradient

기울기, 증감, 변화도 와 같은 변화하는 정도를 나타냄
변화하는 정도가 가장 큰 부분은 일반적으로 edge와 모서리 부분이며, 이를 찾기 위해 gradient를 활용한다.
이미지(x, y)에서의 Gradient의 벡터값(방향, 크기)을 통해 해당 픽셀에서 edge까지 얼마나 가까운지, 방향이 어디인지 알 수 있다.

◾ 방향(gradient)

f(x, y)에서의 최대 변화율의 방향 (이미지가 가장 밝아지는 방향)

◾ 크기(magnitude)

벡터 방향으로 얼마나 밝아지는지의 정도 (이미지가 밝아지는 픽셀까지의 거리)
linear하지 않다.

6. Gradient & Sobel Operator

◾ Basic gradient

중심 대칭이 아님

◾ Symmetric gradient

중심 대칭 (basic말고 이렇게 쓸 수도 있다~)

◾ Sobel Operator (3x3 version)

noise의 영향을 줄이기 위해 주변 픽셀값도 섞어서 미분
중심이랑 가까운 부분z8,z2,z6,z4은 비중을 더 주기위해 더 많이 섞음
오른쪽 표에 있는 수의 합이 0이다.
왼쪽 식의 뜻 - 오른쪽 표에 있는 수를 각 픽셀에 곱하고 다 더한 값이 미분값이다.
Laplacian은 2차 미분의 zero crossing으로 edge를 찾았고,
Sobel(Gradient)은 x, y 방향의 1차 미분의 극대값으로 edge를 찾는다.
분류를 어케해야하는지 잘 머르겟다....................

Combining Spatial Enhancement

결국 지금까지 배운 공간 필터링을 조합해보면,, 이런 이미지를 만들어낼 수 있다. 잘 조합해서 쓰면 된다..?

[Image Processing] 2. Digital Image

VHAL_ — Fri, 8 Nov 2024 12:06:53 +0900

** 해당 시리즈는 타블로그의 글을 참고하여 공부용으로 기록해놓은 글입니다 **

Human Vision

Image Formation in the Eye

Lights

1. Human Vision

Light Source (광원)
오브젝트로 향하는 광원 (Decay - 광원에서 멀어질수록 어두워짐)
오브젝트에 도착한 빛
- Absorption (흡수)
- Reflection(표면에서 반사) / Scarttering(내부로 흡수했다가 나옴)
오브젝트에서 눈으로 가는 빛 (No decay - 공기 저항 무시, 각 시세포가 받는 E는 일정)
눈에 도착한 빛 (Sensing Energy)

2. Light

특정 유형의 전자파인 Visible Spectrum(가시광선)만 사람 눈에 감지된다.

◾Color

다양한 wavelength(파장)의 light wave(광파) 혼합된 것이며 그 혼합물에 대한 사람의 반응, 느낌

◾ Achromatic light (무채색)

파장을 무시하는 빛으로 색은 없고 intensity(밝기)만 존재
(aka. monochromatic, gray level, Luminace(휘도), birightness)

Image Acquisition

1. Sensor Element

빛 E가 들어오면 전류가 흐른다. (빛 신호 -> 전기 신호)

1-1. Single Element Sensing

sensor 하나가 좌우로 이동하고, 필름은 회전한다.
센서를 천천히 움직이면 해상도가 올라간다. (픽셀 개수가 정해지지 않음)
ex) 잉크프린터, 필름 고해상도 현상

1-2. Sensor Strip Sensing

Sensor strip (여러개의 sensor)
Sensor strip이 좌우로 이동한다.
Sensor strip의 센서 개수가 해상도를 결정한다. (움직이는 방향의 해상도는 속도로 조절 가능)
ex) 스캐너

1-3. Sensor Ring Sensing

동그란 모양의 Sensor Ring 사이로 3D오브젝트가 통과되며 이미지를 인식한다.
속도가 빠르다.
ex) X-ray, CT

1-4. 2D Image Array Sensing

2D Sensor Array(센서가 이차원 배열로 존재)
렌즈(카메라) 필요
한 순간의 데이터를 저장할 수 있다. (snapshot)
ex) CCD array

2. Image Formation Model

이미지가 디지털로 바뀌는 방법
Image의 밝기: f(x, y)
(밝기의 범위는 한계가 없다. 0 < f(x, y) < ∞)
Formation model
- Illumination (광원에서 나온 빛) : i(x, y)
- Reflectance (반사율) : r(x, y)
- 반사율 예시
광원에서 나온 빛과 반사율을 곱해 이미지의 밝기를 구한다.

3. Intensity Range (밝기의 범위)

한 픽셀의 값
이론에 따르면 밝기의 범위는 한계가 없어 0 < f(x, y) < ∞ 이지만, 센서가 받아낼 수 있는 최소, 최대가 정해져있다.
그래서 Intensity Range(Gray scale)는 보통 0에서 L-1까지의 값을 가진다.

Sampling and Quantization

1. Digitization

이미지를 디지털(정수 형태)로 바꾸는 과정

◾Sampling

연속적의 데이터를 다 알 수 없어서 이미지의 특정 공간만 Sampling해서 전체를 알기

x, y방향으로 이미지를 작은 픽셀로 쪼개기

픽셀값으로 이미지를 나타냄 (각 픽셀마다 색, 밝기 등)

◾ Quantization (양자화)

Sampling 값을 디지털화(정수화) 한다.

이미지의 경우 0-255 범위에 픽셀 정도가 저장된다. (사람이 구분할 수 있는 정도의 기준)

❗ Sampling과 Quantization 둘 다 무조건 많이 하는게 좋지만, 시간과 같은 자원의 한계가 있다.

2. Sampling

정수의 값을 갖는 몇개의 점xi yi에 대한 함수값
이차원 배열 / 행렬 형태

3. Quantization (양자화)

[0~최대 밝기]의 범위를 정수로 쪼갬
b와 k는 비례
수준이 높아질수록 자원이 많이 들고, 낮아지면 밝기 구분이 어려워짐

4. Saturation (색의 포화도)

RGB가 전부 255를 넘은 Saturation 상태에서 다시 밝기를 낮추면 색이 복구되지 않고 회색이 나온다.

◾Clipping

모니터마다 가장 밝은 부분255의 밝기가 다 다르다.
카메라에서 밝기가 전체적으로 어두워지는 것은 기존의 255 밝기보다 낮은 밝기를 255로 Quantization하기 때문

5. Resolution (해상도)

1. spatial resolution (공간해상도)

이미지 구성에 사용되는 픽셀 수 (구별가능한 최소 단위)
Dots per inch (DPI): 기준 크기에 단위(픽셀)가 몇개 들어가는지

2. Intensity resolution

Intensity LevelL의 구별 가능한 최소 변화
각 픽셀이 가질 수 있는 값의 개수
8비트(가장 많이 사용), 12비트, 16비트 등
Intensity level에 따른 이미지

◾Isopreference Curves

ResolutionN이 높으면 Intensity Levelk이 낮아도 괜찮고, Resolution이 낮으면 Intensity Level이 높아지는 것이 좋다.
얼굴 이미지는 낮은 디테일, 군중 이미지는 높은 디테일을 가진다.

6. Image Interpolation

◾Interpolation

알고 있는 데이터로 모르는 부분을 추정한다. (ex-내적)

픽셀 사이의 값을 추정하여 더 높은 해상도를 만든다.

1. Nearest neighbor Interpolation

근처에 알고 있는 픽셀값으로 보간
경계선이 깨지며 해상도 낮아짐

2. Bilinear Interpolation

근처에 알고 있는 4개의 픽셀값을 적당히 섞은 새로운 값으로 보간

3. Bicubic Interpolation

근처의 16개의 픽셀값으로 3차 곡선을 만들어서 새로운 값으로 보간

✔️ 왼쪽부터 Nearest neighbor, Bilinear, Bicubic

Basic Relationship between Pixels

1. Neighborhood

(x, y) 좌표를 가지는 픽셀p의 이웃

1. 4-neighborhood

2. 4 diagonal neighborhood

3. 8-neighborhood

2. Adjacency

픽셀 간 인접관계를 나타내기위한 Intensity valuse V

1. 4-adjacency

픽셀 q가 p의 4이웃이고, 두 픽셀 모두 V의 값을 가짐

2. 8-adjacency

픽셀 q가 p의 8이웃이고, 두 픽셀 모두 V의 값을 가짐

3. M-adjacency

두 픽셀 모두 V의 값을 가지는데,
- 픽셀 q가 p의 4이웃 이거나
- 픽셀 q가 p의 D이웃 이고 p의 4이웃과 qD이웃의 교집합에 V값을 가지는 픽셀이 없는 경우

3. Path (or Curve)

adjacency한 애들 따라가서 다른 픽셀로 가는 길 (n - path의 길이)
closed path - 시작해서 제자리로 돌아오는 path
두 픽셀사이 path가 있다 -> 두 픽셀이 connected

4. Region

Path로 연결된 픽셀 덩어리 (connected set)

5. Boundary

Region의 한 픽셀의 이웃 중, Region에 포함되지 않는 픽셀들
(Region 픽셀 이웃의 여집합complement에 포함되는 픽셀)

6. Distance Measure (두 픽셀 사이 거리)

◾ Metric

거리를 재는 방법이 Metric하다는 것은
1. 거리가 양수
2. p -> q, q -> p 거리가 동일
3. p -> q + q -> p ≥ p -> z

1. 직선거리

2. x축의 거리차 + y축의 거리차

4neighbor을 통해서만 측정하는 거리

3. x축 차이, y축 차이의 최대값

8neighbor을 통해서만 측정하는 거리

Mathematical Tools Basic

1. Array Operation

이미지끼리 곱할 때에는 아래 방법을 주로 사용 (기존의 행렬 곱셈이 아님)

2. Linear vs Nonlinear Operation

◾Operation

f이미지를 넣어서 g이미지가 나오는 영상처리 함수H

1. Linear Operation

H함수를 한 번에 적용한 것과 두 번에 나눠서 적용한 것의 결과값이 같으면 Linear
1번 적용한 것이 더 효율적