Life and IT

동적 프로그래밍[Dynamic Programming]

프티 — Sun, 13 Jul 2025 00:44:05 +0900

Concept
1. 문제를 더 작은 조각으로 나눈다.
2. 앞에 위치한 조각을 기억한다.
3. 기억하고 있는 조각을 통해서 작업의 양을 줄인다.

언제 이것을 사용할 수 있을까?

다음 2가지를 통해서 DP 알고리즘 사용 여부를 알 수 있다.

- 최적화를 할 수 있는 부분 구조의 존재여부 [Optimal Substructure]

- 반복되는 하위 로직의 존재여부 [Overlapping subproblems]

최적화를 할 수 있는 부분 구조의 존재여부 [Optimal Substructure]

체크포인트

- 하위 문제의 최적 해답으로 상위 문제의 최적 해답을 구할 수 있는지?

A -> ... -> Z로 가는 최적 경로를 구하는 알고리즘과 같은 경우에, 위 사항을 체크해보아야 한다.

A부터 Z까지 도달하는 데에 경로는 무수히 많을 수 있기 때문에 각 단계별로의 최적 경로를 찾아 합할 수 있는지가 중요하다.

사실 체감은 잘 안되기는 한다..

반복되는 하위 로직의 존재여부 [Overlapping subproblems]

체크포인트

- 작은 문제로 나뉠 수 있는지?

- 재활용 될 수 있는지?

작은 문제로 나뉠 수 있고, 재활용될 수 있다면?

-> 재활용 가능한 함수 형태로 작은 문제들을 구하고, 그 값을 기억하여 다음 연산에 사용한다.

예시

피보나치 수열을 예로 들어보자.

피보나치수열은 앞의 2개 숫자를 더한 값이 그다음 숫자로 나오는 수의 나열이다.

1, 1, 2, 3, 5, 8, 13, ....와 같은 방식으로!

이러한 방식은 단순 합의 나열 뿐만 아니라, 함수로의 나열 형태 또한 나타날 수 있다.

즉 앞의 2개의 함수의 연산값이 그 다음 함수의 연산값인 것으로 생각해 볼 수 있다.

함수 트리로 표현해보면,

피보나치수열 예시
fn(5)
fn(4) + fn(3)
fn(3) + fn(2) fn(2) + fn(1)
fn(2) + fn(1)

위와 같이 fn(3), fn(2), fn(1)의 연산값이 반복되어 나타나고 있다.

값을 저장하는 방식

위 2가지 조건 모두, 하위 문제에 대한 연산값을 기억해야 최적화하고 재활용할 수 있다는 공통점이 있다.

값을 재활용하기 위해서는 계산한 값을 저장해야 한다.

피보나치 예시를 활용하여 아래와 같은 코드로 작성해 볼 수 있다.

function fn(n, memo = []) {
  if (memo[n] !== undefined) return memo[n]
  const res = fn(n-1, memo) + fn(n-2, memo)
  memo[n] = res
  return res
}

위와 같이 값을 저장하게 되면, 시간 복잡도는 O(2^n)에서 O(n) 수준으로 급격하게 빨라진다.

거의 수직으로 올라가는 O(2^n)에서 완만한 O(n)으로..

위에서 설명한 저장 방식은 위에서 아래로 내려오는 Top-Down 방식이었다.

아래로 내려가면서 하나씩 값을 구하고, 위에서 전부 더해주는 방식이 이전 방식이다.

하지만 Bottom-Up 방식도 존재한다. 그것이 바로 타뷸레이션이다.

동적 프로그래밍은 결국 2가지 방식으로 나뉜다.
- 하향식 (Top-Down)
- 타뷸레이션 (Bottom-Up)

타불레이션(Tabulation)

타뷸레이션은 보통 루프와 같이 순환을 통해 작업한다.

순환 방식만 있는 것은 아니지만, 공간 복잡도가 더 낮기 때문에 주로 순환 방식을 사용한다고 한다.

아래 코드를 통해 방식을 확인해 보겠다.

function fn(n) {
  if (n <= 2) return 1
  const nums = [0, 1, 1] // 피보나치에서 0번째 - 0 / 1번째 - 1 / 2번째 - 1
  for (let i = 3; i <= n; i++) {
  	nums[i] = nums[i - 1] + nums[i - 2]
  }
  
  return nums[n]
}

하향식과 타뷸레이션 방식의 차이

하향식은 재귀 방식이기 때문에, 콜스택에 하위 함수들이 대기하고 있다.

하지만 타뷸레이션은 함수를 한번만 호출하기 때문에 하위 함수들이 없다.

따라서 n이 증가할수록 하향식은 콜스택 초과 에러가 발생할 수 있는 반면에, 타뷸레이션은 에러가 발생하지 않는다.

벡터 테이블 만들기 삽질과정

프티 — Wed, 2 Apr 2025 00:40:32 +0900

SQL 연습할 겸 한국 주소에 대한 테이블을 만들고 가공하는 중이다.

SQL 문법이나 서버 개발이 아직 손에 익지 않아서 고군분투 중..

테스트 겸 검색값에 대한 테이블 조회를 단순히 LIKE 문을 사용하여 구현하였다.

데이터가 한국 지도뿐이라서 속도가 느리지는 않으나 모든 데이터를 순회하며 비교를 하기 때문에,
로컬 실행이고 전 세계 주소 데이터를 가지고 있었다면 매우 느린 속도를 보일 것이라고 판단하였다.

ILIKE 검색 속도

이에 따라 벡터 테이블을 만들어 유사성 비교로 속도를 높이고자 하였다.

저렴한 구현을 추구하기 때문에 무료 벡터 모델을 찾아보았다.

오픈소스로 무료로 사용할 수 있는 Sentence-Transformers 모델 중 하나가 적합합니다.
예를 들어, paraphrase-multilingual-MiniLM-L12-v2 모델은 384차원의 임베딩을 생성하며, 50개 이상의 언어를 지원합니다. 이 모델은 다음과 같은 장점이 있습니다.
멀티링구얼 지원: 전세계 다양한 언어의 주소 데이터를 효과적으로 임베딩할 수 있습니다. 효율적 차원: 384차원으로 비교적 낮은 차원이기 때문에, 저장 및 검색 시 리소스 부담이 적습니다. 비용 효율성: 무료로 사용할 수 있으며, 별도의 클라우드 API 호출 비용이 들지 않아 개인 프로젝트에 적합합니다.

또한 최신 PostgreSQL에는 pgvector가 내장되어 있다.

이에 따라 내가 생각한 벡터 데이터 가공 플로우는 아래와 같다!

id, name, address를 조합하여 벡터값 계산 -> paraphrase-multilingual-MiniLM-L12-v2의 384차원으로 벡터값을 저장!

먼저 vectorize 익스텐션 설치를 시도하였는데...

pgxn install vectorize 에러 (ssl)
- python3 install certifi
- sudo SSL_CERT_FILE=$(python3 -m certifi) pgxn install vectorize
해결 -> cargo install cargo-pgxr 에러 (let dependency = cargo_edit::get_latest_dependency not found in `cargo_edit`)
시도 -> cargo --version && cargo install cargo-pgrx --version "0.13.1" --locked
0: $PGRX_HOME does not exist 에러
- mkdir -p $HOME/.pgrx
- export PGRX_HOME=$HOME/.pgrx
- export SSL_CERT_FILE=$(python3 -m certifi)
- sudo -E pgxn install vectorize
0: /Users/유저네임/.pgrx/config.toml not found. Have you run `cargo pgrx init` yet? 에러
해결 -> cargo pgrx init

무수히 많은 에러를 거쳐 설치완료.. 하지만 익스텐션 만으로는 인코딩 자체가 안된다는 사실을 뒤늦게 알았다..

또한 에러 해결도 왜 되는지 부끄러운 사실이지만 정확히 모.르.겠.다..

설상가상으로 에러 해결을 위해 무지성으로 설치한 패키지들로 인해, PostgreSQL이 brew와 application 버전 2가지로 설치되어 있었고, 이로 인해 서버를 실행할 때마다 실행 실패를 해결하느라 내가 나의 발목을 잡는 상황이 계속해서 발생하였다..

결국 PostgreSQL 전부 삭제하고, brew에 무지성 설치한 패키지들을 제거한 뒤, PostgreSQL 설치부터 다시 진행하였다..

익스텐션만으로는 인코딩이 안되기 때문에 벡터 인코딩 방법에 대해 리서치 중에, sentence_transformers라는 파이썬 라이브러리가 있었다. 이것을 통해 벡터로 인코딩해서 벡터를 포함한 주소 테이블을 새로 생성하고자 했다.

이에 따라 sentence_transformers를 활용한 벡터 인코딩 함수를 만들어서 실행해 보았는데, sentence_transformers 모듈을 찾을 수 없다는 에러가 발생하였다.

이를 해결하기 위해, 무지성 패키지 설치보다는 문서를 먼저 보았고, PostgreSQL 17 버전과 호환되는 python 버전이 컴퓨터에 설치되어 있는지부터 확인하였다.

또한 현재 PostgreSQL을 Application 형식으로 사용 중인데, 해당 앱이 설치한 파이썬과 연결되어 있는지 확인도 필요하였다.

# 연결되어 있는 파이썬 정보 확인 함수
CREATE OR REPLACE FUNCTION python_env()
RETURNS text AS $$
import sys
return f"
  Python: {sys.version}\n
  Prefix: {sys.prefix}\n
  Executable: {sys.executable}
"
$$ LANGUAGE plpython3u;

# Python: 3.13.2 (v3.13.2:4f8bb3947cf, Feb  4 2025, 11:51:10) [Clang 15.0.0 (clang-1500.3.9.4)]
# Prefix: /Library/Frameworks/Python.framework/Versions/3.13                                   
# Executable: /Applications/Postgres.app/Contents/Versions/17/bin/postgres

# 파이썬 경로 정보 확인 함수
CREATE OR REPLACE FUNCTION get_sys_path()
RETURNS text AS $$
import sys
return "\n".join(sys.path)
$$ LANGUAGE plpython3u;

# /usr/local/opt/python@3.13/lib/python3.13/site-packages                        
# /Library/Frameworks/Python.framework/Versions/3.13/lib/python313.zip           
# /Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13              
# /Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/lib-dynload  
# /Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages

이후에 연결되어 있는 파이썬에 sentence-transformers와 의존성 라이브러리인 torch를 설치하고자 하였으나, 무한 의존성 루프에 빠지며 죽어도 설치가 안 되는 상황이 되었다.. 리서치를 해보니 아래와 같이 상황 정리되었다..

- postgreSQL 17 버전에서의 PL/Python은 파이썬 3.13 이상만을 지원

- sentence_transformers의 의존성 라이브러리는 torch(PyTorch)

- 현재 torch의 python에 대한 공식 휠는 3.12까지 지원함

-> 따라서 PostgreSQL 17 버전에서는 sentence_transformers 사용 불가함..

따라서 PostgreSQL 버전을 다운그레이드할 예정이다.

뒷목이 뻐근한 순간이다..

AWS) Web Hosting

프티 — Sun, 9 Mar 2025 00:49:49 +0900

Web Hosting?

웹 사이트를 구성하는 여러 파일을 다양한 디바이스에서 엑세스할 수 있도록 하는 서비스

웹사이트에 엑세스하는 과정과 원리

웹사이트를 본다 === IP 주소를 통해 서버에 페이지를 요청한다

하지만 우리는 보통 IP 주소를 입력하여 웹사이트에 접근하지 않는다.

1. 유저가 브라우저 URL 주소를 입력한다.

URL의 2가지 형태

도메인 (ex. naver.com)
IP 주소 (ex. 172.0.0.1) </aside>

거의 대부분의 서비스들은 URL 주소로 IP를 직접 노출시키지 않는다.

사용자의 편의성을 위하여, 인식하기 쉬운 naver.com과 같은 도메인을 사용한다.

도메인으로 웹사이트에 접근하는 원리

도메인은 IP 주소와 매칭되어있다.
DNS 서버를 통해 해당 도메인과 매칭되는 IP 주소를 찾을 수 있다.

DNS(도메인 네임 시스템)

DNS 쿼리가 캐시되어 있지 않다면, IP 탐색은 Root 영역으로부터 시작된다.

Root 영역에서부터 차례로 내려가며, 최종적으로 해당 도메인과 매칭되는 IP 주소를 찾는다.

찾은 IP 주소는 최종적으로 클라이언트에게 반환되며, 반환된 IP 주소로 웹 사이트를 요청한다.

가비아, 고대디와 같이 도메인 거래 서비스 업체에서 특정 도메인 이름을 구매할 수 있다.

DNS 설정

DNS는 등록된 레코드 정보를 바탕으로 IP를 탐색한다.

참고 - 레코드 종류별 정보

A 레코드 - 도메인의 IP 주소를 갖고 있는 레코드. A 레코드에 대해 자세히 알아보세요.
AAAA 레코드 - 도메인의 IPv6 주소를 포함하는 레코드(IPv4 주소를 나열하는 A 레코드와 반대).AAAA 레코드에 대해 자세히 알아보세요.
CNAME 레코드 - 하나의 도메인이나 하위 도메인을 다른 도메인으로 전달하며, IP 주소를 제공하지는 않습니다. CNAME 레코드에 대해 자세히 알아보세요.
MX 레코드 - 이메일을 이메일 서버로 전송합니다. MX 레코드에 대해 자세히 알아보세요.
TXT 레코드 - 관리자가 레코드에 텍스트 메모를 저장할 수 있습니다.이 레코드는 종종 이메일 보안에 사용됩니다.TXT 레코드에 대해 자세히 알아보세요.
NS 레코드 - DNS 항목의 이름 서버를 저장합니다. NS 레코드에 대해 자세히 알아보세요.
SOA 레코드 - 도메인에 대한 관리자 정보를 저장합니다. SOA 레코드에 대해 자세히 알아보세요.
SRV 레코드 - 특정 서비스에 대한 포트를 지정합니다. SRV 레코드에 대해 자세히 알아보세요.
PTR 레코드 - 리버스 조회에서 도메인 이름을 제공합니다. PTR 레코드에 대해 자세히 알아보세요.

NS / A 레코드를 통한 IP 탐색 흐름

1 NS 레코드 → 네임서버 정보 요청

2	도메인에 대한 DNS 요청권한을 가진 네임서버 정보 획득
3	네임서버 정보 → A 레코드 정보 요청
4	A 레코드에 대한 IP 주소 획득

CNAME의 역할

하위 도메인의 이름과 매칭되는 정보

CNAME을 통해 페이지를 요청한다면, 연결된 도메인을 먼저 탐색한 후에 NS / A 레코드를 통한 IP 탐색을 시작한다.

2. URL 주소와 연결되어 있는 서버에 페이지를 요청한다.

서버의 종류

자체적으로 관리하는 내부서버
클라우드를 통해 임대하는 외부서버

클라우드 서버의 장점

서버의 물리적인 유지보수를 할 필요가 없음
대규모 트래픽에 대하여 안정적이고 일관성 있는 대응이 가능함

클라우드 서버를 사용하면 적은 리소스로 안정적이고 신뢰성있는 서비스 제공이 가능하다.

참고) 위펄슨에서 사용하는 클라우드GCP: Cloud Functions, Authentication
AWS: 웹 호스팅, S3 버킷

AWS로 웹 호스팅하기

S3 Bucket 생성

클라이언트에게 웹 사이트를 보여주려면,

서버가 클라이언트에게 보낼 웹 사이트 구성 파일을 가지고 있어야 한다.

S3 > 버킷 만들기

버킷 정보 입력

버킷 이름 : CloudFront, Route53에서 생성할 이름과 동일하게 지정
ACL 활성화 버킷 소유자 : 버킷을 소유한 계정에게 버킷에 있는 모든 객체(파일들)에 대한 모든 권한이 있음 : 버킷 소유자가 아닌 사람이 해당 버킷에 객체 업로드를 하는 경우, 버킷 소유자에게 모든 권한을 이전하는 추가 설정이 필요함 (--acl bucket-owner-full-control) 객체 라이터 : 버킷에 업로드한 객체의 권한은, 해당 객체를 업로드한 사람에게 있음
퍼블릭 엑세스 차단 설정 : 버킷의 객체에 접근할 수 있는 엑세스 권한 설정 : CloudFront를 통해서만 S3 버킷에 접근하는 경우, 엑세스 차단을 풀어줌

정적 웹 사이트 호스팅

버킷 > 버킷 이름 > 속성 > 정적 웹 사이트 호스팅 > 편집

정적 웹 사이트 호스팅을 활성화

→ 지정한 인덱스 문서에 대한 원본 주소를 얻을 수 있음

CloudFront 배포하기 ( + 기존 캐시된 파일 무효화 )

CloudFront > 배포 생성

원본 Origin Domain : S3 Bucket의 주소
원본 엑세스 Legacy access Identities : 원본 엑세스 ID를 사용하여 Bucket에 접근 : 새 OAI 생성으로 ID 등록
기본 캐시 동작 뷰어 > 프로토콜 정책 > Redirect HTTP to HTTPS : weperson에서는 사용자 편의성을 위해 리다이렉트 옵션 사용중 뷰어 > 허용된 HTTP 방법 > GET, HEAD : weperson은 SPA 서비스이기 때문에, 최소 허용 옵션 사용중
설정 Custom SSL certificate - optional : HTTPS 보안 세팅을 위한 SSL 파일 등록

생성 후

aws cli를 통해 빌드한 파일을 업로드 / 캐시 무효화 할 수 있다.

// 빌드
yarn build

// 기존 dist/spa 제거 후 새롭게 빌드된 dist/spa 파일 업로드
aws s3 sync --acl public-read --delete dist/spa s3://서브도메인.com

// 존재하는 CDN 캐시파일 무효화
aws cloudfront create-invalidation --distribution-id ${{ secrets.AWS_PROD_CLOUDFRONT_ID }} --paths "/*"

캐시 무효화 직접 해보기

CloudFront > 배포 > 배포ID > 무효화 생성

경로 패턴을 통해 하위 파일들을 타겟팅하여 무효화 생성 → 캐시 무효화

Route53 연결

Route53 > 호스팅 영역 > 레코드 생성

레코드 이름 : 유저가 입력할 도메인 이름 레코드 유형

CloudFront 연결을 할 때 → CloudFront의 도메인 이름 또는 IP 주소
정적 웹 호스팅을 할 때 → S3 Bucket의 인덱스 문서의 주소

Expo) Sentry 소스맵 업로드

프티 — Sun, 9 Mar 2025 00:19:56 +0900

1. Sentry의 역할

빌드 파일은 기존 코드를 난독화하고, 압축하기 때문에 정확한 에러 지점을 파악하기 어렵다.
Sentry에 소스맵을 업로드하면, 에러가 발생한 코드에 대한 원본 코드 위치를 소스맵을 통해 알 수 있다.
또한 에러 발생 즉시 리포트가 이루어지기 때문에 즉각적인 대응이 가능하다.

2. 소스맵 업로드

각 버전별로 소스맵을 Sentry에 업로드할 수 있다.
다만, 아래 2가지 상황별로 소스맵 업로드 방식이 다르게 존재한다.

2-1 EAS Cloud 빌드

자동으로 Sentry에 소스맵이 업로드 된다.
별도의 소스맵 업로드 처리가 필요하지 않다.

2-2 EAS Update

EAS Update 명령 실행 시 소스맵이 생성된다. (위치: root/dist/bundles)
bundle 폴더에 생성된 소스맵 파일은 Android / IOS 각각 .hbc와 .map 파일로 구성된다.

3. 배포 절차

아래는 소스맵 수동 업로드가 필요한 EAS Update에 대한 배포 방법이다.

3.1. EAS Update 실행

터미널에서 아래 명령어를 실행한다.

npx eas update

실행 결과로 Group ID, Android ID, iOS ID 총 3개의 업데이트 ID가 출력된다.
Group ID는 iOS와 Android를 일괄 업데이트하는 데 사용할 수 없다. 따라서 각 플랫폼별 업데이트 ID를 각각 사용해야 한다.
root/dist/bundles 경로에 생성된 파일 이름을 통해 각 OS 별로 다른 ID를 가진 것을 확인할 수 있다.

3.2. Sentry CLI를 이용한 소스맵 업로드

3.2.1. 소스맵 업로드

업데이트 ID를 활용해 소스맵을 업로드한다. 명령어 형식은 아래와 같다.

npx sentry-cli releases files <앱_패키지_name>@<패키지_version>+<버전_code> \\
    upload-sourcemaps --dist <업데이트_ID> --rewrite \\
    <번들_파일_경로> <소스맵_파일_경로>

플랫폼 별 위 변수에 들어갈 값 정리

IOS Android

앱_패키지_name	<패키지.이름>	<패키지.이름>
패키지_version	(package.json).version	(package.json).version
버전_code	App Store 버전 코드	Play Store 버전 코드
업데이트_ID	eas update 시 IOS ID	eas update 시 Android ID
번들_파일_경로	…/main.jsbundle	…/index.android.bundle
소스맵_파일_경로	…/ios-업데이트_ID.map	…/android-업데이트_ID.map

Android

npx sentry-cli releases files <패키지.이름>@1.0.0+100 \\
    upload-sourcemaps --dist <android_update_id> --rewrite \\
    dist/bundles/index.android.bundle dist/bundles/android-<android_update_id>.map
    
?) 번들파일 생성시 index.android.bundle의 실제 이름: <android_update_id>.hbc
?) **<android_update_id>.hbc -> index.android.bundle로 이름 변경**

iOS

npx sentry-cli releases files <패키지.이름>@1.0.0+100 \\
    upload-sourcemaps --dist <ios_update_id> --rewrite \\
    dist/bundles/main.jsbundle dist/bundles/ios-<ios_update_id>.map
    
?) 번들파일 생성시 main.jsbundle의 실제 이름: <ios_update_id>.hbc
?) **<ios_update_id>.hbc -> main.jsbundle로 이름 변경**

Sentry에서는 번들파일인 index.android.bundle과 main.jsbundle을 <update_id>.hbc 형식으로 생성한다.

3.2.2. Sentry 릴리즈 최종화

소스맵 업로드가 완료되면, 릴리즈를 최종화한다.

npx sentry-cli releases finalize "<패키지.이름>@<패키지_version>+<버전_code>"

사용 예시

npx sentry-cli releases finalize "<패키지.이름>@2.0.5+62"

3.2.3. 배포 등록

최종화된 릴리즈를 배포 환경(dev 또는 prod)에 등록한다.

npx sentry-cli releases deploys new -r "<패키지.이름>@<패키지_version>+<버전_code>" -e <sentry_등록한_환경변수명>

사용예시

// sentry 환경변수로 prod가 있다고 가정
npx sentry-cli releases deploys new -r "<패키지.이름>@2.0.5+62" -e prod

// sentry 환경변수로 dev가 있다고 가정
npx sentry-cli releases deploys new -r "<패키지.이름>@2.0.5+62" -e dev

4. 토큰 및 환경변수

환경변수는 Sentry에서 발급한 토큰과 설정한 프로젝트, organization이 필요하다.
EAS Update 시에는 로컬에서 작업이 수행되기 때문에, 로컬 환경변수에 export한다.
EAS Build 시에는 EAS 클라우드에서 빌드되기 때문에, EAS 환경변수에 등록한다.

export SENTRY_AUTH_TOKEN=<SENTRY_AUTH_TOKEN>
export SENTRY_PROJECT=<SENTRY_PROJECT>
export SENTRY_ORG=<SENTRY_ORG>

Expo) 카카오 로그인 구현하기 - 라이브러리 설치 및 빌드

프티 — Wed, 17 Apr 2024 02:31:25 +0900

expo에서 카카오 로그인을 구현하고자 했다.

로그인 구현 방식은 웹뷰/앱 내부로 크게 두 가지로 구현이 가능하다.

웹뷰로 로그인을 구현하게 되면 카카오 앱으로 넘어가기 때문에 웹뷰가 아닌 앱 내부에서 로그인을 처리하고 싶었다. (참고링크)

서치한 결과 @react-native-seoul/kakao-login을 사용하면 expo에서도 앱 내부에서 카카오 로그인이 구현 가능하다는 것을 알게 되었다.

yarn add @react-native-seoul/kakao-login

이후에 로컬 빌드를 하였으나 아래의 에러를 마주하게 되었다.

* What went wrong:
Could not determine the dependencies of task ':app:processDebugResources'.
> Could not resolve all task dependencies for configuration ':app:debugRuntimeClasspath'.
   > Could not find com.kakao.sdk:v2-user:2.11.2.
     Searched in the following locations:
       - https://oss.sonatype.org/content/repositories/snapshots/com/kakao/sdk/v2-user/2.11.2/v2-user-2.11.2.pom
       - https://repo.maven.apache.org/maven2/com/kakao/sdk/v2-user/2.11.2/v2-user-2.11.2.pom
       - file:/Users/user/projects/myapp/node_modules/jsc-android/dist/com/kakao/sdk/v2-user/2.11.2/v2-user-2.11.2.pom
       - https://dl.google.com/dl/android/maven2/com/kakao/sdk/v2-user/2.11.2/v2-user-2.11.2.pom
       - https://www.jitpack.io/com/kakao/sdk/v2-user/2.11.2/v2-user-2.11.2.pom
       - file:/Users/user/projects/myapp/node_modules/react-native/android/com/kakao/sdk/v2-user/2.11.2/v2-user-2.11.2.pom
     Required by:
         project :app > project :react-native-seoul_kakao-login
   > Could not find com.kakao.sdk:v2-talk:2.11.2.
     Searched in the following locations:
       - https://oss.sonatype.org/content/repositories/snapshots/com/kakao/sdk/v2-talk/2.11.2/v2-talk-2.11.2.pom
       - https://repo.maven.apache.org/maven2/com/kakao/sdk/v2-talk/2.11.2/v2-talk-2.11.2.pom
       - file:/Users/user/projects/myapp/node_modules/jsc-android/dist/com/kakao/sdk/v2-talk/2.11.2/v2-talk-2.11.2.pom
       - https://dl.google.com/dl/android/maven2/com/kakao/sdk/v2-talk/2.11.2/v2-talk-2.11.2.pom
       - https://www.jitpack.io/com/kakao/sdk/v2-talk/2.11.2/v2-talk-2.11.2.pom
       - file:/Users/user/projects/myapp/node_modules/react-native/android/com/kakao/sdk/v2-talk/2.11.2/v2-talk-2.11.2.pom
     Required by:
         project :app > project :react-native-seoul_kakao-login
   > Could not find com.kakao.sdk:v2-story:2.11.2.
     Searched in the following locations:
       - https://oss.sonatype.org/content/repositories/snapshots/com/kakao/sdk/v2-story/2.11.2/v2-story-2.11.2.pom
       - https://repo.maven.apache.org/maven2/com/kakao/sdk/v2-story/2.11.2/v2-story-2.11.2.pom
       - file:/Users/user/projects/myapp/node_modules/jsc-android/dist/com/kakao/sdk/v2-story/2.11.2/v2-story-2.11.2.pom
       - https://dl.google.com/dl/android/maven2/com/kakao/sdk/v2-story/2.11.2/v2-story-2.11.2.pom
       - https://www.jitpack.io/com/kakao/sdk/v2-story/2.11.2/v2-story-2.11.2.pom
       - file:/Users/user/projects/myapp/node_modules/react-native/android/com/kakao/sdk/v2-story/2.11.2/v2-story-2.11.2.pom
     Required by:
         project :app > project :react-native-seoul_kakao-login
...

해당 라이브러리 문서에 나온대로 아래 설정을 해주고 리서치를 진행했으나, 빌드시 kakao android sdk를 찾지 못하는 원인에 대한 해결책을 찾을 수 없었다..

그러다 해당 이슈에 대한 원인을 친절히 알려주시는 코멘트를 발견하였다!

따봉 100만개 주고싶다

Maven은 안드로이드의 라이브러리들을 관리해주는 도구인데, kakao sdk를 찾지 못하니 app.json / app.config.ts에서 해당 라이브러리에 대한 레포를 추가해줌으로서 해결할 수 있다는 가이드였다.

이에 따라 아래와 같이 설정해주었다.

plugins: [
    [
      'expo-build-properties',
      {
        android: {
          "extraMavenRepos": ["https://devrepo.kakao.com/nexus/content/groups/public/"]
        }
      }
    ],
    [
      '@react-native-seoul/kakao-login', {
        kakaoAppKey: '카카오 앱 키',
      }
    ]
  ]

하지만.. 또 다시 에러를 마주하고 말았다.

expo에 세팅된 kotlin gradle version은 1.5.10인데, 플러그인 호환 버전이 최소 1.5.20 이상인 것을 알게 되었다.

따라서, @react-native-seoul/kakao-login 플러그인 세팅에서 코틀린 버전을 1.5.20으로 설정하였다.

plugins: [
    [
      'expo-build-properties',
      {
        android: {
          "extraMavenRepos": ["https://devrepo.kakao.com/nexus/content/groups/public/"]
        }
      }
    ],
    [
      '@react-native-seoul/kakao-login', {
        kakaoAppKey: '카카오 앱 키',
        kotlinVersion: '1.5.20'
      }
    ]
  ]

드디어 빌드 성공.. 역시 지식 공유의 힘은 크다

별거 없지만 해당 이슈에 대한 PR에 코틀린 버전 명시가 제거되어 있길래 먼지톨보다도 작은 제안을 하며 이번 이슈를 마무리하였다..

해당 제안에 피드백이 오면 추가 공유 예정!

eslint, husky, lint-staged, commitlint 설정

프티 — Thu, 11 Jan 2024 22:35:47 +0900

회사에서 리액트 네이티브 프로젝트를 시작하면서 eslint, husky, lint-staged, commitlint를 적용해보았다.

eslint

프로젝트 할 때마다 설정하는건데 항상 찾아보는 것 같다..

우리는 타입스크립트를 사용하기 때문에 타입스크립트 관련 eslint 패키지도 함께 설치해준다.

yarn add -D eslint eslint-plugin-react-hooks eslint-plugin-react eslint-plugin-react-hooks @typescript-eslint/eslint-plugin @typescript-eslint/parser

eslint를 설정하기 위해 .eslintrc.js를 구성한다.

.eslintrc.js에 모든 설정을 몰아넣게되면 관리하기가 어려우므로, 먼저 주제에 따라 rule을 분리하고자 한다.

// rules 디렉토리 구조
eslint-config/index.js
/rules/es6.js
/import.js
/react.js
/typescript.js

rules의 디렉토리 구조는 위와 같다.

// eslint-config/rules/typescript.js
module.exports = {
  extends: [
    'plugin:@typescript-eslint/eslint-recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:@typescript-eslint/recommended-requiring-type-checking'
  ],
  rules: {
    // typescript 룰 적용
  }
}

위와같이 각 rule에 맞는 규칙과 세부 설정을 해준다.

// index.js
module.exports = {
  extends: ['./rules/es6', './rules/import', './rules/react', './rules/typescript'].map(require.resolve),
}

이렇게 구성된 rules 파일을 index에 extends한다.

// .eslintrc.js
module.exports = {
  env: {
    es6: true,
    node: true
  },
  extends: ['./eslint-config', 'eslint:recommended'],
  parser: '@typescript-eslint/parser',
  parserOptions: {
    project: ['./tsconfig.json']
  },
  plugins: ['@typescript-eslint'],
  settings: {
    react: {
      version: 'detect'
    },
    'import/ignore': ['react-native']
  }
}

최종으로 .eslintrc.js에서 eslint-config를 extends 시켜주면 깔끔하게 관리할 수 있어 유지보수에 용이하다.

husky 설정

git hook이란?
git 이벤트가 있을때 특정 스크립트를 실행하게 하는 것 실수로 origin에 push되어 배포가 되는 일을 방지할 수 있다.

husky란?
git hook을 쉽게 사용할 수 있도록 도와주는 라이브러리

git hook의 분류별 실행 단계

npx husky-init

커밋시 린트 검사를 하기위해 아래와 같이 설정한다.

// 터미널
npx husky add .husky/pre-commit 'yarn lint-staged'

lint-staged 설정

git의 stage 상태의 파일들을 대상으로 특정 명령어를 실행할 수 있도록 해주는 툴이다.

yarn -D lint-staged

// package.json
...
"script": {
	...
	"lint-staged": "lint-staged",
	"type-lint": "tsc --pretty --noEmit && eslint . --ext .js,.jsx,.ts,.tsx"
},
"lint-staged": {
	"**/*.{js,jsx,ts,tsx}": ["yarn type-lint"]
}

기존에 만들어진 type, lint 검사 스크립트를 활용하여 lint-staged시에 해당 스크립트를 실행할 수 있도록 한다. 특정 파일들을 대상으로하기 위해, "**/*.{js,jsx,ts,tsx}"와 같은 경로 및 확장자를 지정할 수 있다.

// .husky/pre-commit

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

yarn lint-staged

husky의 커밋 워크플로 훅의 하나인 pre-commit 에서 stage 파일들이 커밋되기 전에 lint-staged 스크립트가 실행될 수 있도록 한다.

commitlint 설정

yarn add -D @commitlint/cli @commitlint/config-conventional

commitlint-cli(@commitlint/cli)와 컨벤션 기반의 규칙을 제공하는 commitlint 플러그인(@commitlint/config-conventional)을 설치한다.

// .husky/commit-msg
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npx --no-install commitlint --edit $1

git commit -m “XXX: message…” 사용자 입력
husky → commit-msg 파일 실행( npx --no-install commitlint --edit $1 )
컨벤션 위반시 0이 아닌 에러코드와 위반된 규칙 메세지 반환
터미널에 에러 코드와 메세지 출력

루트에 commitlint.config.js 를 추가하여 구성하면 커스텀 커밋 컨벤션을 구성할 수 있다.

커스텀 컨벤션을 구성하지 않는 경우, 기본적으로 허용하는 컨벤션이 적용된다.

type과 body은 : 로 구성된다.
body의 맨앞에는 ``빈칸으로 구성한다.
등등..

참고

https://deku.posstree.com/en/react-native/eslint-prettier-husky-lint-staged/

https://deku.posstree.com/ko/react-native/eslint-prettier-husky-lint-staged/#google_vignette

https://velog.io/@kay_/Husky#3-sample-pre-commit-hook-추가하기

https://github.com/conventional-changelog/commitlint/blob/master/docs/reference-rules.md

루트 컴포넌트 렌더링 방식

프티 — Fri, 19 Aug 2022 09:27:42 +0900

Vue는 React와 마찬가지로 하나의 div 안에서 동작한다.

그리고 해당 div에 연결하는 방식은 조금 다르지만 비슷한 원리를 가지고 있다.

1) index.js(React) → main.js(Vue)

2) 부가 기능 없이 연결했을 때

// React
ReactDOM.render(
	<App />,
	document.getElementById("root"),
);

// Vue
createApp(App).mount("#root");

3) store 또는 router 연결했을 때

// React
ReactDOM.render(
	<Provider store={store}>
		<Router>
			<App />
		</Router>
	</Provider>,

	document.getElementById("root"),
);

// Vue
createApp(App).use(store).use(router).mount("#root");

React는 render 메서드에 컴포넌트와 이를 바인딩할 div를 인자로 넘겨준다.

이에 반해 Vue는 createApp 메서드를 사용하고, 체이닝을 통해 다양한 메서드를 연결시킬 수 있다.

코드를 보면 알 수 있듯이, React는 컴포넌트로 루트 컴포넌트를 감싸고 있는 방식이지만 Vue는 메서드 체이닝을 사용하기 때문에 다른 형태를 가지고 있다.

Getter와 Setter

프티 — Fri, 1 Jul 2022 16:25:15 +0900

객체의 프로퍼티에는 두 종류로 나뉜다.

1. 데이터 프로퍼티

2. 접근자 프로퍼티

우리가 지금까지 사용했던 프로퍼티는 데이터 프로퍼티이다.

접근자 프로퍼티는 본질이 함수이며, 값을 획득(getter)하고 설정(setter)하는 역할을 한다.

객체 리터럴 안에서 getter와 setter는 각각 get과 set으로 나타낼 수 있다.

let user = {
  name: "John",
  surname: "Smith",

  get fullName() {
    return `${this.name} ${this.surname}`;
  }
};

alert(user.fullName); // John Smith

위 코드를 보면 get 프로퍼티를 일반 프로퍼티처럼 호출하여 사용할 수 있다.

그 뒤의 로직은 getter 메서드가 처리하기 때문이다.

let user = {
  name: "John",
  surname: "Smith",

  get fullName() {
    return `${this.name} ${this.surname}`;
  },

  set fullName(value) {
    [this.name, this.surname] = value.split(" ");
  }
};

// 주어진 값을 사용해 set fullName이 실행됩니다.
user.fullName = "Alice Cooper";

alert(user.name); // Alice
alert(user.surname); // Cooper

위와 같이 setter 메서드를 구현하면 해당 프로퍼티에 새로운 값을 할당할 수 있다.

이렇게 getter와 setter 메서드를 구현하면 객체엔 fullName이라는 가상의 프로퍼티가 생긴다.

가상의 프로퍼티는 읽고 쓸 수 있지만 실제로 존재하지는 않는다.

Javascript는 왜 싱글 스레드일까?

프티 — Wed, 1 Jun 2022 00:13:13 +0900

자바스크립트는 싱글 스레드라는 것은 개념을 외우듯이 알고 있었다.

하지만 자바스크립트 언어를 만든 브렌던 아이크 선생님은 왜 싱글 스레드를 선택했을까?

우선 그전에 프로세스와 스레드의 개념을 알고 가야 할 것 같다.

프로세스와 스레드

프로세스는 운영 체제로부터 할당받은 작업의 단위이다.

프로세스 내부에는 Code, Data, Stack, Heap이라는 네 가지 리소스가 존재한다.

프로그램을 실행했을 때 보조 기억장치(ex. 하드 디스크)에서 프로그램의 코드를 컴파일하여 주 기억장치인 메모리에 옮겨가면, 그것을 프로세스라고 한다.

스레드는 프로세스가 할당받은 자원을 사용하는 작업의 흐름 단위이다.

스레드는 Stack을 가지며 나머지 Code, Data, Heap 리소스를 사용하며 작업을 처리한다.

이때 프로세스 내부에 스레드가 하나라면 싱글 스레드, 여러 개라면 멀티 스레드이다.

멀티 스레드는 여러 스레드가 리소스를 공유하며 작업을 처리하기 때문에, 여러 작업을 동시에 처리할 수 있다.

동시에 처리한다고 말했지만, 스레드를 돌아가며 순차적으로 처리하는 방식이 매우 빠르기 때문에 거의 동시에 처리되는 것처럼 느껴진다.

어떤 스레드에서 또 다른 스레드로 넘어가는 과정을 스레드 컨텍스트 스위칭이라고 한다.

스레드 컨텍스트 스위칭은 스레드 하나의 작업을 진행하기 위해 해당 스레드의 Context를 읽어오고, 다시 다른 스레드로 작업을 변경할 때, 이전 스레드의 Context를 저장하고 작업을 진행할 스레드의 Context를 읽어오는 작업을 말한다.
여기서 Context는 정보를 나타내는데 레지스터, 커널 스택, 사용자 스택 등의 여러 정보를 말하지만, 이에 대해서는 아직 잘 모르기에 추후에 다루도록 하겠다.

만약 스레드 컨텍스트 스위칭의 시간이 오래 걸리는 경우, 프로그램의 성능 저하가 일어나 프로그램이 멈추는 사용자 경험을 할 수 있다.

또한 멀티 스레드는 동시성에 대응해야 한다는 어려움이 있다.

동시성이란, 싱글 코어에서 멀티 스레드를 동작시켜 동시에 실행되는 것 같이 보이는 것이다.

동시성은 병렬성과 비교해서 보아야 한다.

동시성은 싱글 코어에서 멀티 스레드 환경을 구성하여 스레드 컨텍스트 스위칭을 통해 여러 개의 스레드가 번갈아가면서 실행되는 성질이다.

반면 병렬성은 멀티 코어에서 멀티 스레드를 동작시키는 방식이다. 따라서 실제로 동시에 여러 작업이 처리된다고 볼 수 있다.

위에서 이야기했듯이, 멀티 스레드는 여러 개의 스레드가 프로세스가 할당받은 리소스들을 공유하며 작업을 처리하기 때문에, 같은 자원을 두고 교착상태(deadlock)가 발생할 수 있다. 따라서 교착상태를 해결하기 위해 스레드 안정성(thread safe)을 가지며 코드를 작성해야 한다. 스레드 안정성을 확보하기 위한 방법들은 추후에 자세히 다루도록 하고, 방법들만 간단하게 나열해보겠다.

암시적 Lock (synchronuized)
명시적 Lock
thread safe 한 객체 사용
불변 객체 사용

자바스크립트는 왜 싱글 스레드일까?

자바스크립트가 싱글 스레드를 선택한 이유는 자바스크립트가 탄생한 역사를 보면 알 수 있다.

자바스크립트는 웹 페이지의 보조적인 기능을 수행하기 위해 브라우저에서 동작하는 경량 프로그래밍 언어를 도입하기로 결정하고 만들어진 언어이다.
웹 사이트를 구현하던 개발자들에게 자바라는 언어는 다소 무겁고 어려운 언어였다.
자바는 멀티 스레드 모델을 지원하는 언어이다.
멀티 스레드로 구현되는 서비스에서는 동시성 문제를 불가피하게 신경 써야만 한다.

이러한 역사 그리고 동시성으로 인한 복잡도 증가와 같은 이유들로 인해 자바스크립트는 싱글 스레드로 탄생한 것이다!

그럼에도 우리는 자바스크립트를 멀티 스레드처럼 사용하고 있다. 이것이 어떻게 가능하게 되었을까?

비동기 vs 동기

자바스크립트는 싱글 스레드 방식으로 실행된다.

따라서 하나의 실행 컨텍스트 스택을 갖는다. 하나의 스레드로는 동시에 2개 이상의 함수를 실행시킬 수 없다.

따라서 동기적인 처리 방식을 사용한다.

하지만 Web api, Eventloop, Taskque와 같은 자바스크립트가 아닌 브라우저에 내장되어 있는 기능들을 사용함으로써, 자바스크립트는 비동기 처리를 할 수 있다.

따라서 우리는 DOM Element의 이벤트 핸들러, 타이머, 서버에 자원을 요청 또는 응답할 수 있는 것이다.

브라우저의 구조 및 자세한 과정은 추후에 다루도록 하겠다.

정리하자면 다음과 같다.

자바스크립트 언어의 초기 개발 목적은 웹 페이지의 보조적인 기능을 수행하기 위한 경량적 언어였다.
따라서 자바스크립트는 멀티 스레드의 동시성과 같은 무겁고 대응하기 복잡한 부분들을 피하기 위해 싱글 스레드 방식으로 구현되었다.
하지만 브라우저의 내장 기능들(Web api, Eventloop, Taskque)을 활용하여 비동기 처리가 가능하게 함으로써 멀티 스레드처럼 동작시킬 수 있다.

참고

https://miracleground.tistory.com/entry/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EB%8A%94-%EC%99%9C-%EC%8B%B1%EA%B8%80-%EC%8A%A4%EB%A0%88%EB%93%9C%EB%A5%BC-%EC%84%A0%ED%83%9D%ED%96%88%EC%9D%84%EA%B9%8C-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EC%8A%A4%EB%A0%88%EB%93%9C-%EB%B9%84%EB%8F%99%EA%B8%B0-%EB%8F%99%EA%B8%B0-%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%EC%97%94%EC%A7%84-%EC%9D%B4%EB%B2%A4%ED%8A%B8%EB%A3%A8%ED%94%84

자바스크립트는 왜 싱글 스레드를 선택했을까? 프로세스, 스레드, 비동기, 동기, 자바스크립트

목차 프로세스와 스레드 프로세스 싱글 스레드와 멀티 스레드 자바스크립트는 왜 싱글 스레드를 선택했을까 동기 vs 비동기 동기 비동기 자바스크립트로 비동기 처리하는 방법 자바스크립트 엔

miracleground.tistory.com

https://hojak99.tistory.com/307

[Thread] 스레드 컨텍스트 스위칭

스레드 컨텍스트 스위칭이란 무엇일까? 우선 우리는 컨텍스트 스위칭이란 것부터 알아야 한다. 그래야 스레드에서의 컨텍스트 스위칭을 더 쉽게 이해할 수 있을 것 같은 내 생각 때문이다. 이

hojak99.tistory.com

https://velog.io/@dyllis/%EB%8F%99%EC%8B%9C%EC%84%B1%EC%9D%B4-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

동시성이 무엇일까

소개 이 글을 작성하게 된 이유는 사전면접이나 기술면접에서 항상 등장하는 프로세스와 스레드 차이, 동시성에 대해서 설명해주세요라고 했을 때 제대로 설명하지 못하는 나의 모습을 보고 정

velog.io

https://ganzicoder.tistory.com/98

스레드와 동시성

스레드 스레드는 어떠한 프로그램 안에서 , 프로세스 안에서 실행되는 흐름의 단위! 통상 한 프로그램은 하나의 스레드를 갖고있지만 프로그램 환경에따라 둘 이상의 스레드를 동시에 실행가능

ganzicoder.tistory.com

https://velog.io/@mooh2jj/%EB%A9%80%ED%8B%B0-%EC%8A%A4%EB%A0%88%EB%93%9C%EC%9D%98-%EB%8F%99%EC%8B%9C%EC%84%B1-%EC%9D%B4%EC%8A%88

멀티 스레드의 동시성 이슈 그리고 해결방법

스레드는 작업의 한단위이다. 여기서 멀티스레드 방식은 멀티태스킹을 하는 방식 중, 한 코어에서 여러 스레드를 이용해서 작업을 처리하는 방식이다.멀티 스레드를 이용하면 공유하는 장원이

velog.io

Status Code

프티 — Tue, 31 May 2022 17:42:32 +0900

Status Code, 즉 상태 코드는 http 요청 시에 request가 아닌 response에서 요청의 처리 상태를 알려주는 기능이다.

100 ~ 5xx번 대의 상태 코드가 존재하며 숫자 맨 앞자리의 번호에 따라 처리 상태의 종류가 달라진다.

1xx (informational): 요청이 수신되어 처리 중

요청을 받았으며 작업을 계속한다는 의미를 가지고 있다.

HTTP/1.0 이래로 1xx 상태 코드들은 정의되지 않았다고 하니, 실험적인 상태를 제외하고 HTTP/1.0 클라이언트로 보내면 안 된다.

2xx (Successful): 요청 정상 처리

클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.

200(성공): 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.
201(작성됨): 성공적으로 요청되었으며 서버가 새 리소스를 작성했다. (POST, PUT에 의한 수정, 추가 성공 시)
202(허용됨): 서버가 요청을 접수했지만 아직 처리하지 않았다.
203(신뢰할 수 없는 정보): 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공하고 있다.
204(콘텐츠 없음): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다.
205(콘텐츠 재설정): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다. 204 응답과 달리 이 응답은 요청자가 문서 보기를 재설정할 것을 요구한다(예: 새 입력을 위한 양식 비우기).
206(일부 콘텐츠): 서버가 GET 요청의 일부만 성공적으로 처리했다.
207(다중 상태, RFC 4918)
208(이미 보고됨, RFC 5842)
226 IM Used (RFC 3229)

3xx (Redirection): 요청을 완료하려면 추가 행동이 필요

클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.

300(여러 선택항목): 서버가 요청에 따라 여러 조치를 선택할 수 있다. 서버가 사용자 에이전트에 따라 수행할 작업을 선택하거나, 요청자가 선택할 수 있는 작업 목록을 제공한다.
301(영구 이동): 요청한 페이지를 새 위치로 영구적으로 이동했다. GET 또는 HEAD 요청에 대한 응답으로 이 응답을 표시하면 요청자가 자동으로 새 위치로 전달된다.
302(임시 이동): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.
303(기타 위치 보기): 요청자가 다른 위치에 별도의 GET 요청을 하여 응답을 검색할 경우 서버는 이 코드를 표시한다. HEAD 요청 이외의 모든 요청을 다른 위치로 자동으로 전달한다.
304(수정되지 않음): 마지막 요청 이후 요청한 페이지는 수정되지 않았다. 서버가 이 응답을 표시하면 페이지의 콘텐츠를 표시하지 않는다. 요청자가 마지막으로 페이지를 요청한 후 페이지가 변경되지 않으면 이 응답(If-Modified-Since HTTP 헤더라고 함)을 표시하도록 서버를 구성해야 한다.
305(프록시 사용): 요청자는 프록시를 사용하여 요청한 페이지만 액세스할 수 있다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 하다.
307(임시 리다이렉션): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.
308(영구 리다이렉션, RFC에서 실험적으로 승인됨)

4xx (Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음

클라이언트에 오류가 있음을 나타낸다.

400(잘못된 요청): 서버가 요청의 구문을 인식하지 못했다.
401(권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다. 상태 코드 이름이 권한 없음(Unauthorized)으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다.
402(결제 필요): 이 요청은 결제가 필요합니다.
403(Forbidden, 금지됨): 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을 갖고 있지 않다. (401은 인증 실패, 403은 인가 실패라고 볼 수 있음)
404(Not Found, 찾을 수 없음): 서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.
405(허용되지 않는 메소드): 요청에 지정된 방법을 사용할 수 없다. 예를 들어 POST 방식으로 요청을 받는 서버에 GET 요청을 보내는 경우, 또는 읽기 전용 리소스에 PUT 요청을 보내는 경우에 이 코드를 제공한다.
406(허용되지 않음): 요청한 페이지가 요청한 콘텐츠 특성으로 응답할 수 없다.
407(프록시 인증 필요): 이 상태 코드는 401(권한 없음)과 비슷하지만 요청자가 프록시를 사용하여 인증해야 한다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 한다.
408(요청 시간초과): 서버의 요청 대기가 시간을 초과하였다.
409(충돌): 서버가 요청을 수행하는 중에 충돌이 발생했다. 서버는 응답할 때 충돌에 대한 정보를 포함해야 한다. 서버는 PUT 요청과 충돌하는 PUT 요청에 대한 응답으로 이 코드를 요청 간 차이점 목록과 함께 표시해야 한다.
410(사라짐): 서버는 요청한 리소스가 영구적으로 삭제되었을 때 이 응답을 표시한다. 404(찾을 수 없음) 코드와 비슷하며 이전에 있었지만 더 이상 존재하지 않는 리소스에 대해 404 대신 사용하기도 한다. 리소스가 영구적으로 이동된 경우 301을 사용하여 리소스의 새 위치를 지정해야 한다.
411(길이 필요): 서버는 유효한 콘텐츠 길이 헤더 입력란 없이는 요청을 수락하지 않는다.
412(사전 조건 실패): 서버가 요청자가 요청 시 부과한 사전 조건을 만족하지 않는다.
413(요청 속성이 너무 큼): 요청이 너무 커서 서버가 처리할 수 없다.
414(요청 URI가 너무 긺): 요청 URI(일반적으로 URL)가 너무 길어 서버가 처리할 수 없다.
415(지원되지 않는 미디어 유형): 요청이 요청한 페이지에서 지원하지 않는 형식으로 되어 있다.
416(처리할 수 없는 요청 범위): 요청이 페이지에서 처리할 수 없는 범위에 해당되는 경우 서버는 이 상태 코드를 표시한다.
417(예상 실패): 서버는 Expect 요청 헤더 입력란의 요구사항을 만족할 수 없다.
418(I'm a teapot, RFC 2324 ,https://google.com/teapot)
420(Enhance Your Calm, 트위터)
422(처리할 수 없는 엔티티, WebDAV; RFC 4918)
423(잠김, WebDAV;RFC 4918): 접근하려는 리소스가 잠겨 있다.
424(실패된 의존성, WebDAV; RFC 4918)
424(메쏘드 실패, WebDAV)
425(정렬되지 않은 컬렉션, 인터넷 초안)
426(업그레이드 필요, RFC 2817): 클라이언트는 업그레이드 헤더 필드에 주어진 프로토콜로 요청을 보내야 한다.
428(전제조건 필요, RFC 6585)
429(너무 많은 요청, RFC 6585): 사용자가 일정 시간 동안 너무 많은 요청을 보냈다.
431(요청 헤더 필드가 너무 큼, RFC 6585)
444(응답 없음, Nginx)
449(다시 시도, 마이크로소프트)
450(윈도 자녀 보호에 의해 차단됨, 마이크로소프트)
451(법적인 이유로 이용 불가, 인터넷 초안)
451(리다이렉션, 마이크로소프트)
494(요청 헤더가 너무 큼, Nginx)
495(Cert 오류, Nginx)
496(Cert 없음, Nginx)
497(HTTP to HTTPS, Nginx)
499(클라이언트가 요청을 닫음, Nginx)

5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.

500(내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다.
501(구현되지 않음): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다.
502 (Bad Gateway, 불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다.
503(서비스를 사용할 수 없음): 서버가 오버 로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없다. 이는 대개 일시적인 상태이다.
504(게이트웨이 시간 초과): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을 받지 못했다.
505(HTTP 버전이 지원되지 않음): 서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않는다.
506(Variant Also Negotiates, RFC 2295)
507(용량 부족, WebDAV; RFC 4918)
508(루프 감지됨, WebDAV; RFC 5842)
509(대역폭 제한 초과, Apache bw/limited extension)
510(확장되지 않음, RFC 2774)
511(네트워크 인증 필요, RFC 6585)
520(Unknown Error, 알 수 없음)
598(네트워크 읽기 시간초과 오류, 알 수 없음)
599(네트워크 연결 시간초과 오류, 알 수 없음)