Skip to content

태그: 개발

총 113개의 글이 있습니다.

아키텍처-및-방법론

DRY(Don't Repeat Yourself)는 "같은 지식을 코드 여러 곳에 중복해서 두지 말라"는 원칙이다. 하나의 사실이 여러 곳에 흩어져 있으면, 바뀔 때 전부 찾아 고쳐야 하고 그중 하나라도 빠뜨리면 버그가 된다. 여기서 말하는 중복은 코드 모양이 같은 것이 아니라 지식이 같은 것을 뜻한다. 우연히 비슷하게 생겼을 뿐 서로 다른 이유로 존재하는 코드를 억지로 합치면, 한쪽 요구사항이 바뀔 때 함께 묶인 다른 쪽까지 영향을 받아 오히려 더 나빠진다. 그래서 DRY를 성급하게 적용하는 것은 위험하다. 아직 중복이라 확신할 수 없을 때는 YAGNI를 따라 그냥 두고, 실제로 같은 지식이 반복해서 나타난 뒤에 묶는 편이 정확하다. --- 참고

아키텍처-및-방법론

KISS(Keep It Simple, Stupid)는 "가능한 한 단순하게 만들라"는 원칙이다. 복잡한 설계는 그 자체로 이해·수정·디버깅 비용을 늘리기 때문에, 문제를 푸는 데 꼭 필요한 만큼만 복잡해야 한다는 것이다. 단순함은 코드가 짧다는 뜻이 아니라, 읽는 사람이 동작을 예측하기 쉽다는 뜻이다. 과한 추상화, 불필요한 계층, 영리하지만 이해하기 어려운 표현은 모두 복잡성을 키운다. 똑같이 동작하는 두 방법이 있다면 더 단순한 쪽을 고른다. 지금 필요하지 않은 것을 미리 만들지 않는 YAGNI와 방향이 같다. YAGNI가 시간축에서의 단순함이라면, KISS는 구조 자체의 단순함에 가깝다. --- 참고

아키텍처-및-방법론

YAGNI(You Aren't Gonna Need It)는 "지금 당장 필요하지 않은 기능은 미리 만들지 말라"는 원칙이다. 익스트림 프로그래밍(XP)에서 나온 말로, 나중에 쓸 것 같다는 추측만으로 코드를 미리 작성하는 것을 경계한다. 미래에 필요할 것 같다는 판단은 대부분 빗나간다. 막상 그 시점이 오면 요구사항이 달라져 있거나, 애초에 그 기능이 필요 없어지는 경우가 많다. 그런데 추측으로 만들어둔 코드는 그때까지 계속 유지보수 대상으로 남는다. --- 참고

아키텍처-및-방법론

3의 법칙(Rule of Three)은 "같은 코드가 세 번째로 나타났을 때 비로소 공통 컴포넌트로 추출하라"는 재사용 경험칙이다. 두 번까지는 중복을 참고, 세 번째에 묶으라는 것이다. 성급하게 재사용 가능한 추상화를 만들면 잘못된 추상화가 되기 쉽다. 사례가 하나나 둘밖에 없으면 그 코드들이 정말 같은 이유로 존재하는지, 앞으로 어떻게 달라질지 판단할 근거가 부족하다. 이 상태에서 억지로 공통화하면 우연히 닮았을 뿐인 코드를 하나로 묶게 되고, 나중에 한쪽 요구사항이 갈라질 때 잘못 만든 추상화를 다시 뜯어내야 한다. 세 번째 사례가 등장하면 변형의 축이 드러나서, 무엇이 진짜 공통이고 무엇이 달라지는 부분인지 훨씬 정확하게 가려낼 수 있다. --- 참고

Worse is Better

아키텍처-및-방법론

"더 나쁜 게 더 낫다(Worse is Better)"는 리처드 가브리엘이 말한 내용이다. 가브리엘은 Lisp 프로그래머였고, 이 글이 실린 원 발표의 제목은 "Lisp: Good News, Bad News, How to Win Big"였다. 기술적으로 명백히 앞서 있다고 믿었던 Lisp와 Lisp 머신이 왜 C와 Unix에 밀려나는에 대해 적은 자기반성에 가까운 내용이다. 구체적인 이야기는 아래와 같다. MIT AI 랩과 스탠퍼드를 중심으로 한 Lisp 문화에는 "올바른 것(the Right Thing)"을 추구하는 태도가 있었다. 시스템은 완전하고 일관되고 정확해야 하며, 그렇게 만들기 위해 구현이 아무리 복잡해져도 감수한다는 것이다. 사용자가 마주하는 인터페이스에서 지저분함을 걷어낼 수 있다면

디미터의 법칙

아키텍처-및-방법론

디미터의 법칙(Law of Demeter)은 "한 객체는 자신이 직접 아는 대상에게만 말을 걸어야 한다"는 원칙이다. 최소 지식 원칙(Principle of Least Knowledge)이라고도 한다. 어떤 컴포넌트가 다른 컴포넌트의 내부 구현을 속속들이 알고 그 안까지 파고들어 조작하면, 두 컴포넌트가 강하게 결합되어 한쪽 변경이 다른 쪽을 깨뜨리기 때문이다. 구체적으로 한 메서드는 자기 자신, 자신의 필드, 인자로 받은 객체, 자신이 만든 객체 정도에게만 메시지를 보내야 한다. 남에게 받은 객체가 또 물고 있는 내부 객체까지 꺼내 쓰지 말라는 것이다. `a.getB().getC().doSomething()`처럼 점(.)이 길게 이어지는 호출이 전형적인 위반 신호다. 이런 코드는 a가 B의 구조를, 다시

콘웨이의 법칙

아키텍처-및-방법론

콘웨이의 법칙(Conway's Law)은 "시스템의 구조는 그것을 만든 조직의 의사소통 구조를 닮는다"는 관찰이다. 1967년 멜빈 콘웨이가 제시했으며, 조직이 시스템을 설계할 때 그 설계는 조직 내부의 소통 경로를 그대로 복제하게 된다는 것이다. 이유는 단순하다. 두 모듈이 서로 맞물려 동작하려면 그 모듈을 만드는 사람들이 계속 협의해야 한다. 자주 대화하는 팀끼리 만든 부분은 자연스럽게 긴밀하게 엮이고, 소통이 드문 팀 사이에는 명확한 인터페이스가 생긴다. 그래서 세 팀이 컴파일러를 만들면 3-패스 컴파일러가 나오기 쉽다는 식의 이야기가 따라붙는다. 이 법칙의 실질적 함의는 두 가지다. 하나는 여러 팀이 함께 손대야만 바뀌는 컴포넌트를 만들지 말라는 것이다. 그런 컴포넌트는 팀 경계와 어긋나 있어 변

파레토의 법칙

아키텍처-및-방법론

파레토의 법칙(Pareto principle)은 "결과의 대부분은 원인의 일부에서 나온다"는 경험칙이다. 흔히 80:20 법칙이라 부르며, 전체 효과의 80%가 원인의 20%에서 비롯된다고 본다. 이탈리아 경제학자 빌프레도 파레토가 "이탈리아 땅의 80%를 인구의 20%가 소유한다"고 관찰한 데서 이름이 붙었다. 이후 여러 분야에서 비슷한 편중이 반복해서 나타나는 것이 확인되면서 일반적인 경향으로 자리 잡았다. 정확히 80과 20이라는 숫자가 중요한 게 아니라, 기여도가 균등하지 않고 소수에 쏠려 있다는 점이 핵심이다. 소프트웨어에서도 자주 인용된다. 성능 최적화에서 실행 시간의 대부분은 코드의 일부 구간에서 소비되므로, 전체를 고르게 손보기보다 병목이 되는 소수 지점을 먼저 측정해 개선하는 편이 효율적

ERP(Enterprise Resource Planning)는 회사의 회계, 인사, 구매, 재고, 생산, 영업 등의 업무를 하나의 시스템으로 통합 관리하는 소프트웨어이다. 부서마다 따로 쓰던 시스템을 하나의 DB로 묶어서 데이터가 실시간으로 공유되게 한 것이다. MRP에서 ERP까지 ERP는 제조업의 자재 관리에서 출발했다. MRP (1960년대): Material Requirements Planning. Orlicky 교수가 고안했다. "무엇이, 얼마나, 언제 필요한가"를 계산해서 자재 조달 계획을 세우는 시스템이다. BOM(자재 명세서)과 생산 일정을 기반으로 필요한 자재 수량과 시기를 산출한다. MRP II (1980년대): Manufacturing Resource Planning

Git LFS(Large File Storage)는 대용량 파일을 Git 저장소에서 효율적으로 관리하기 위한 Git 확장 도구이다. Git은 모든 파일의 전체 히스토리를 로컬에 저장하는 분산 버전 관리 시스템이다. 그런데 바이너리 파일이나 대용량 미디어 파일처럼 크기가 큰 파일이 저장소에 포함되면, clone이나 fetch 시 모든 버전을 다운로드해야 하므로 저장소 크기가 급격히 커지고 속도가 느려진다. Git LFS는 이 문제를 해결한다. Git LFS는 대용량 파일의 실제 콘텐츠를 별도의 원격 스토리지에 저장하고, Git 저장소에는 해당 파일을 가리키는 작은 포인터 파일만 커밋하는 것이다. 예시 version oi

Adaptive Bitrate Streaming

ABR(Adaptive Bitrate Streaming)은 네트워크 상태에 따라 동영상의 비트레이트(화질)를 실시간으로 조절하는 스트리밍 기술이다. 플레이어는 동영상을 하나의 연속된 파일로 받는 것이 아니라, 짧은 세그먼트 단위로 나눠서 받는다. 매 세그먼트마다 "지금 네트워크 상태에서 어떤 화질을 받아야 끊김 없이 최고 화질을 유지할 수 있는가"를 판단하는 것이 ABR의 핵심이다. 기본 구조 ABR 시스템은 서버 측 준비와 클라이언트 측 결정으로 나뉜다. 서버는 하나의 영상을 여러 비트레이트(예: 400kbps, 800kbps, 1.5Mbps, 3Mbps, 6Mbps)로 인코딩하고, 각 버전을 짧은 세그먼트(보통 2~6초)로 분할해 둔다. 그리고 이 정보를 매니페스트 파일로 제공한다. HLS

가변 프레임레이트 (VFR)

영상의 프레임레이트는 크게 두 가지로 나뉜다. CFR (Constant Frame Rate) 고정 프레임레이트 모든 프레임이 균일한 간격으로 배치된다. 30fps라면 각 프레임 간격은 정확히 1/30초(33.33ms)이다. VFR (Variable Frame Rate) 가변 프레임레이트 프레임 간격이 일정하지 않다. 화면 변화가 많으면 프레임을 자주 찍고, 변화가 없으면 프레임을 생략한다. 스마트폰 카메라가 대표적인 VFR 소스이다. MOV/MP4에서 프레임 타이밍이 저장되는 방식 stts box (Sample-to-Time) 각 프레임의 duration(지속 시간)을 저장한다. CFR이면 모든 프레임의 duration이 같으므로 entry가 1개지만, VFR이면 dura

MOV/MP4 컨테이너에는 `elst`(Edit List)라는 box가 있다. 이 box는 원본 미디어 데이터를 직접 수정하지 않고, "어느 구간을 어떤 순서로 재생할지"를 지정하는 일종의 재생 지시서다. 예를 들어 10분짜리 원본 영상에서 앞뒤 1분씩 잘라내고 싶을 때, 실제 미디어 데이터는 10분 그대로 두고 edit list에 "1분~9분만 재생"이라고 적는 것이다. 재인코딩이 필요 없어서 빠르고, iOS 사진 앱이나 QuickTime의 "다듬기" 기능이 이 방식을 사용한다. 구조 `elst` box는 `edts`(Edit Box) 안에 들어있고, 트랙(trak)마다 하나씩 존재할 수 있다. moov └─ trak (비디오 트랙) └─ edts └─ elst

비디오 컨테이너에는 각 프레임(샘플)마다 두 종류의 타임스탬프가 붙어 있다. PTS (Presentation Time Stamp): 이 프레임을 화면에 표시해야 하는 시점 DTS (Decoding Time Stamp): 이 프레임을 디코딩해야 하는 시점 타임스탬프가 두 개 필요한 이유는 B-frame(양방향 예측 프레임)에 있다. B-frame은 앞뒤 프레임을 모두 참조하기 때문에, 화면에 보여주는 순서와 디코더가 처리하는 순서가 달라질 수밖에 없다. 참조 대상이 되는 뒤쪽 P-frame을 먼저 디코딩해놓아야 그 사이의 B-frame을 복원할 수 있기 때문이다. 예를 들어 PTS 순서가 `I B B P B B P`인 영상이 있다면, 디코딩 순서는 `I P B B P B B`가 된다. ti

Shaka Player Polyfill

Shaka Player는 Google에서 개발한 오픈소스 미디어 플레이어 라이브러리이다. 다양한 브라우저 환경에서 일관된 미디어 재생 경험을 제공하기 위해 여러 polyfill을 내장하고 있으며, `shaka.polyfill.installAll()`을 호출하면 등록된 모든 polyfill이 설치된다. 이 문서에서는 Shaka Player가 제공하는 각 polyfill의 역할과 등록 순서를 살펴보고, 그 중 가장 복잡한 EncryptionScheme polyfill의 동작 원리를 상세히 알아본다. Polyfill 등록 메커니즘 `shaka.polyfill.register(callback, priority)` `priority`가 높을수록 먼저 실행된다 기본값은 `0` 같은 priority 내

FID(Fréchet Inception Distance)는 생성 모델이 만든 이미지의 품질과 다양성을 평가하는 지표이다. GAN, Diffusion 모델 평가의 사실상 표준으로 사용된다. 원리 Inception v3 네트워크의 마지막 풀링 레이어에서 feature를 추출하고, 실제 이미지와 생성 이미지의 feature 분포를 비교한다. 두 분포를 다변량 가우시안으로 모델링하여 Fréchet distance를 계산한다. FID = ||μr μg||² + Tr(Σr + Σg 2(ΣrΣg)^(1/2)) μr, μg: 실제/생성 이미지 feature의 평균 Σr, Σg: 실제/생성 이미지 feature의 공분산 행렬 특징 낮을수록 좋음: 0에 가까울수록 실제 이미지 분포와 유사

VMAF(Video Multi-Method Assessment Fusion)는 Netflix가 개발한 비디오 품질 평가 지표이다. 세 가지 기본 지표를 추출하고 SVM(Support Vector Machine)으로 함친다. VIF (Visual Information Fidelity): 자연 이미지 통계 기반 품질 측정 DLM (Detail Loss Metric): 세부 정보 손실 측정 Motion: 프레임 간 움직임 정보 이 지표들을 인간의 주관적 평가 데이터로 학습된 모델에 입력하여 최종 점수를 산출한다. (100에 가까울수록 원본과 동일) bash ffmpeg로 VMAF 계산 ffmpeg -i distorted.mp4 -i reference.mp4 \ -lavfi

이미지 품질 지표

이미지 품질을 평가하는 대표적인 지표로 PSNR, SSIM, LPIPS가 있다. PSNR PSNR(Peak Signal-to-Noise Ratio)은 원본과 비교 이미지 간의 픽셀 차이를 dB 단위로 표현하는 가장 기본적인 지표이다. MSE = (1/N) × Σ(xi yi)² PSNR = 10 × log₁₀(MAX² / MSE) N: 전체 픽셀 수 xi, yi: 원본과 비교 이미지의 i번째 픽셀 값 MAX: 픽셀 최대값 (8비트 이미지의 경우 255) 값이 높을수록 품질이 좋다. 일반적으로 40dB 이상이면 원본과 거의 동일, 30~40dB이면 좋음, 20~30dB이면 보통으로 본다. python from skimage.metrics import peak_signal_nois

lerna: 각 패키지들을 배포하고 버전 관리하는 역할 yarn: 각 패키지간의 의존성 관리 하는 역할 여기서 yarn workspaces 만으로 구성하지 않는 이유는, 여러 개의 패키지를 용이하게 관리 할 수 있는 CLI 명령어 (publish, version 등)는 Lerna에서 많이 제공 되고 있기 때문입니다. 반면에 패키지 관리는 yarn으로 하는 이유는 다음과 같습니다. npm은 모노레포를 지원하지 않음 yarn 은 yarn workspaces 를 추가적인 라이브러리 설치 없이 쉬운 방법으로 제공 yarn workspaces 가 불필요하게 lerna bootstrap 등의 명령을 실행하지 않으면서 더 안전하고 깔끔하게 패키지를 관리 --- front는 tu

uv tool install harlequin uv tool install 'harlequin[postgres]'

ffmpeg 오디오 정규화

Limiter, Compressor bash ffmpeg -y -i input.wav \ -af "alimiter=limit=0.3:attack=1:release=20,acompressor=threshold=-20dB:ratio=8:attack=2:release=30" \ output.m4a 리미터(alimiter)는 일정 크기 이상의 소리를 물리적으로 잘라낸다. `limit=0.3`: 피크를 약 -10dB 수준으로 제한. 낮을수록 더 강하게 자른다. `attack=1`: 어택 1ms. 피크를 얼마나 빠르게 감지할지. `release=20`: 릴리즈 20ms. 피크가 지나간 후 원래대로 돌아오는 시간. 컴프레서(acompressor)는 리미터보다 부드럽게 동작한다. 임계값 이상의 소

자막 파일 포맷

자막 파일은 영상 콘텐츠에 텍스트 정보를 동기화하여 표시하는 파일 형식이다. SRT, SBV, VTT, SMI 네 가지 주요 포맷이 널리 사용되며, 각각의 특성과 용도가 다르다. SRT (SubRip Text) 가장 범용적으로 사용되는 자막 포맷이다. 텍스트 기반의 단순한 구조로 거의 모든 미디어 플레이어에서 지원한다. 구조: 자막 번호, 타임코드, 텍스트, 빈 줄로 구성된다 시간 형식: `HH:MM:SS,mmm --HH:MM:SS,mmm` 자막 번호를 통해 순서 관리가 명확하다 1 00:00:01,000 --00:00:04,000 안녕하세요, 여러분. 2 00:00:04,500 --00:00:06,500 오늘은 자막 파일 형식에 대해 설명한다.

The Go language comes with a built-in template language, but not very many template functions. Sprig is a library that provides more than 100 commonly used template functions. argowf에서 sprig 예시

[Hammerspoon]( macOS용 데스크톱 자동화 및 시스템 컨트롤 도구로, Lua로 사용하여 macOS의 다양한 기능을 제어할 수 있게 해준다. 설치 및 설정 기본 설치 bash brew install --cask hammerspoon Spoon 설치 시스템 Spoon은 Hammerspoon의 모듈 시스템으로, 재사용 가능한 기능들을 패키지화한 것 [SpoonInstall]( Spoon 관리를 위한 기본 도구 예시 lua hs.spoons.use("SpoonI

hls, dash와 cmaf

HLS (HTTP Live Streaming) 애플(Apple)이 개발한 스트리밍 프로토콜 전체 온라인 스트리밍 시장의 약 70%를 차지 iOS/macOS 기기에서 필수적으로 사용하는 `FairPlay Streaming` DRM은 HLS를 통해서만 적용 가능 기술 구성 컨테이너: `m3u8` 플레이리스트 + MPEG2-TS 청크 (fMP4도 지원됨) 코덱: H.264 (AVC), H.265 (HEVC) DRM 호환성: FairPlay Streaming (기본) Widevine (추가 지원) 암호화 방식: AES-CBC 모드 (SAMPLE-AES 포함) --- MPEG-DASH (Dynamic Adaptive Streaming

해상도(Resolution)는 영상의 가로 픽셀 수와 세로 픽셀 수를 의미한다. 예를 들어, 854x480은 가로 854픽셀, 세로 480픽셀로 구성된 화면이다. 해상도는 물리적으로 존재하는 픽셀 수만을 나타내며, 화면 비율(Aspect Ratio)과는 직접적으로 일치하지 않을 수 있다. SAR (Sample Aspect Ratio) 각 픽셀 하나의 가로 대 세로 비율을 뜻한다. SAR이 1:1이면, 하나의 픽셀은 정사각형이다. SAR이 1:1이 아닐 경우, 픽셀은 직사각형 모양이 되어 화면 전체에 왜곡을 발생시킨다. SAR은 인코딩 시점에 설정되며, 영상의 해석 방식에 영향을 준다. SAR을 조정함으로써, 같은 해상도를 유지하면서도 영상의 논리적 비율(DAR)을 수정할 수 있다. • 일부 문

Box Plot(상자 그림)에서 그 부분들은 각각 다른 통계적 의미를 가짐: 1. 상자(Box) 부분: ▪ 박스의 아랫부분(Q1, 1사분위수): 데이터의 25%가 이 값 아래에 있음 ▪ 박스의 윗부분(Q3, 3사분위수): 데이터의 75%가 이 값 아래에 있음 ▪ 박스 내부의 가로선(중앙선): 중앙값(데이터의 50%) 2. 수염(Whiskers, ––| 부분): ▪ 상단 수염: Q3 + 1.5 *IQR(사분위 범위) 까지의 데이터 ▪ 하단 수염: Q1 1.5* IQR 까지의 데이터 3. 개별 점들: ▪ 수염을 벗어나는 점들: 이상치(Outlier) 시각적으로 데이터의 분포, 대칭성, 이상치를 한 눈에 볼 수 있게 해줌.

Mise는 개발 환경을 손쉽게 관리할 수 있도록 도와주는 도구로, 다양한 프로그래밍 언어와 툴을 한 번에 관리할 수 있다. `asdf`, `fnm`, `nvm` 등의 버전 관리 도구와 유사하지만, 실행 속도가 더 빠르다. 기능 멀티 런타임 관리 `mise`는 하나의 도구로 여러 언어와 런타임을 관리할 수 있다. 예를 들어, Node.js, Python, Ruby 등의 버전을 동시에 설치하고 관리할 수 있다. sh mise use node@18 [email protected] 위 명령어를 실행하면 현재 프로젝트에서 Node.js 18 버전과 Python 3.10 버전을 사용할 수 있다. `.tool-versions` 파일을 통한 버전 고정 프로젝트별로 특정 버전을 고정하려면 `.to

Native messaging

브라우저 Native Messaging은 확장 프로그램(Extension)이 외부 네이티브 애플리케이션과 직접 통신할 수 있도록 하는 기술이다. 보통 웹 브라우저 내에서 실행되는 확장 프로그램은 보안상의 이유로 로컬 파일이나 시스템 리소스에 직접 접근할 수 없다. 하지만, Native Messaging을 사용하면 브라우저 확장이 특정한 네이티브 애플리케이션을 실행하고 JSON 메시지를 주고받을 수 있다. Native messaging을 사용하면 브라우저 확장 플러그인에 아래 같은 기능을 추가할 수 있다. 파일 시스템 접근: 확장 프로그램에서 로컬 파일을 읽거나 쓰는 작업 수행 네이티브 애플리케이션 제어: 특정 데스크톱 애플리케이션을 실행하고 상태를 확인 보안 관련 작업

상단 탭 목록 없애기 1. 아래 명령어 실행 ls ~/Library/Application\ Support/Firefox/Profiles/ 2. `.default-release`로 끝나는 경로 들어가서 mkdir chrome && vi chrome/userChrome.css 3. `userChrome.css` 파일에 아래 내용 삽입 css @namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); tabbrowser-tabs { visibility: collapse ! } nav-bar {

rebase 쉽게 하는법

rebase via merge Let me share one possible way to resolve rebase conflicts. I call it rebase via merge. It can help if you want to rebase a branch with many commits and many conflicts are expected. First, let's create a temp branch and force all conflicts to show up with a regular merge git checkout -b temp git merge origin/master Resolve all the conflicts the regular way and finish

git rerere는 비교적 장기간 유지되는 토픽 브랜치를 사용하는 워크플로우에서 동일한 충돌을 반복적으로 해결해야 하는 문제를 해결하기 위한 도구이다. 토픽 브랜치가 "release" 브랜치에 병합되거나 업스트림에 전송되어 승인될 때까지, 개발자는 종종 같은 충돌을 여러 번 해결해야 한다. 이 명령어는 최초 수동 병합 시 충돌이 발생한 자동 병합 결과와 그에 대응하는 수동 해결 결과를 기록하고, 이후 동일한 충돌이 발생했을 때 이전에 기록된 해결 방법을 자동으로 적용한다. 주의: 이 명령어를 사용하려면 `rerere.enabled` 설정 변수를 활성화해야 한다. --- 명령어 일반적으로 `git rerere`는 인자 없이 또는 사용자 개입 없이 실행된다. 하지만 작업 상태와 상호작용할 수

비트레이트

프레임 레이트 frame rate 프레임 레이트 단위는 fps(frame per second)이다. 30fps라면, 1초에 30장의 프레임이 재생된다. 초당 재생되는 이미지 수가 많아지면 동영상이 더 부드럽게 재생된다. 비트 레이트 bit rate 비트 레이트 단위는 bps(bits per second)이고, 초당 처리하는 데이터 크기를 의미한다. 동영상에서 화질은 해상도와 함께 비트레이트 크기가 중요한 역할을 한다. 해상도가 아무리 높아도 비트레이트가 낮으면 화면이 뭉개진다. 그렇다고 비트레이트를 무턱대고 높인다고 화질이 무조건 좋아지는 것도 아니라 해상도에 맞는 적당한 비트레이트를 선택해야 한다. 물론 비트레이트를 높이면 해상도에 따른 화질이 보장되기는 하는데, 비트레이트가 너무 높으면 쓸

ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}... 파일 정보 확인 ffmpeg로 입력 파일 정보 확인 `ffmpeg -i input.mp4` `-hide_banner` 옵션을 사용하면, FFmpeg의 로고와 불필요한 버전 정보 없이 파일 정보만을 출력한다. ffprobe ffprobe는 FFmpeg 패키지의 일부로, 미디어 파일의 스트림 정보를 보다 상세하게 분석할 수 있다. 해상도 확인 `ffprobe -v error -select_streams v:0 -show_entries stream=width,height -of csv=s=x:p=0 input.mp4` 너비, 높

컨테이너와 코덱

컨테이너 포맷(Container Format) 앞서 말한 것처럼 동영상 확장자는 오디오, 비디오 데이터인 스트림(Stream)을 하나 이상 가지고 있는 보관함 역할을 하며 이를 컨테이너 포맷(Container Format) 혹은 래퍼 포맷(Rapper Format)이라 부른다. 스트림(Stream)은 데이터, 패킷, 비트 등 일련의 연속성을 갖는 흐름/데이터를 의미하는데 간단히 컨테이너가 가지고 있는 비디오, 오디오 데이터라 생각할 수 있다. 컨테이너가 가지고 있는 비디오, 오디오 스트림(Stream)들은 코덱(Codec)을 통해 가공된 데이터들이다. 왜 코덱을 통해 가공을 했을까? 코덱(Codec) 코덱은 코더(Coder)와 디코더(Decoder)의 앞글자를 딴 합성어로 용량이 큰 영상을 다른

EME(Encrypted Media Extension)의 약자로, DRM이 걸려있는 영상 컨텐츠를 사용자가 단말기에서 보안 프로그램 설치 없이 사용할 수 있게 해주는 기술이다. EME를 적용하기 위해선 아래 네 가지가 필요하다. 1. 암호화된 영상이 저장되어있는 스토리지 서버 콘텐츠를 암호화된 형태로 저장하고, 재생시 영상을 반환한다. [Shaka Packager]( 같은 도구를 사용해 암호화할 수 있다. 2. 복호화 키가 들어있는 라이센스 서버 콘텐츠 재생에 필요한 암호화 키를 안전하게 발급한다. 3. 인증서 영상을 복호화할 때, 복호화키와 인증서를 같이 가져와 인증해야한다.

Nightly build 매일 발생하는 소프트웨어에 대한 수정사항을 포함하고 있는 소프트웨어 배포버전이다. 소프트웨어는 테스트가 되어 있지 않을 수 있기 때문에 매우 불안정한 상태이다.

map, noremap map, noremap 둘다 특정키를 매핑하는 역할을 한다. 둘의 차이는 recursive vs non-recursive 이다. 에를 들어 :map j gg :map Q j 를 하면 j를 누르면 gg를 누른 것과 동일한 효과를 얻게 된다. 만약 대문자 Q를 누른다면 j로 매핑한다음 다시 j가 gg를 가리키므로 결과적으로 Q는 gg를 수행하게 된다. 그래서 map을 ‘recursive’하다라고 얘기한다. 매핑되는 키의 또다른 매핑되는 키를 찾아가게 된다. 하지만 noremap은 non-recursive map이다. :map j gg :noremap Q j Q를 누르면 j를 누르는 효과이다. map command에 대한 mode별 버전들이 있

압축 알고리즘

BZIP2: Burrows-Wheeler 알고리즘을 사용하는 형식이다. DEFLATE: [LZSS]( 및 [Huffman 코딩]( 기반으로 한 압축 알고리즘이다. [Deflate]( Avro 파일 형식에만 해당된다. GZIP: Deflate를 기반으로 한 압축 알고리즘이다. Athena 엔진 버전 2 및 3의 Hive 테이블과 Athena 엔진 버전 2의 Iceberg 테이블의 경우 GZIP은 Parqu

`sitemap.xml` 사이트맵은 사이트의 페이지, 동영상, 기타 파일들의 관계에 대한 정보를 제공하는 파일이다. 검색엔진 크롤러는 자동으로 홈페이지에서 시작하는 링크를 따라가 페이지를 탐색하는데, 홈페이지에서 모든 페이지를 접근할 수 없거나 페이지 갯수가 많은 경우(약 500개 이상) `sitemap.xml` 파일을 설정해놓으면 크롤러가 사이트를 더 효율적으로 크롤링할 수 있다. 사이트에 리치 미디어 콘텐츠(동영상, 이미지)가 많거나 Google 뉴스에 표시되어야 하는 경우 sitemap 파일로 추가 정보를 제공하는 것이 좋다. 크롤러에서 인식할 수 있는 사이트맵 형식은 여러가지가 있다. | 사이트맵 형식 | 장점 | 단점 | |--------------|------|------|

웹 바이탈(Web Vitals)은 웹페이지 유저들의 사용 경험을 측정하는 구글의 표준화된 웹 성능 측정 기준이다. 사이트의 전반적인 로딩 속도, 상호작용, 웹페이지의 시각적 안정성, 보안 문제 등 여러 요소를 포함하고 있으며, 웹 사이트가 검색 엔진 결과에 표시되는 위치에 영향을 미친다. 검색 엔진에서 최적화하고 전체적으로 유저에게 좋은 환경을 제공하려면 코어 웹 바이탈을 개선해야한다. 성능 지표 중 주요항목으로는 6가지가 있다. FCP (First Contentful Paint) : 첫번째 텍스트 또는 이미지가 표시되는 시간 TTI (Time to Interactive) : 사용자 인터렉션이 가능해질 때까지 걸리는 시간 SI (Speed Index) : 페이지 속도. 얼마나

설정파일 위치: `~/.config/tridactyl/tridactylrc` vimR 연동 vimR을 연동하면 브라우저 입력창에서 vim 입력기를 열어 편집할 수 있다. [editor]( 옵션으로 vimR이 아닌 다른 도구를 설정할 수도 있다. brew install --cask vimr 설정파일에 아래 내용을 추가한다. set editorcmd /opt/homebrew/bin/vimr --wait --- 참고

git branch를 실수로 reset하여 복구하고 싶을 때가 있다. 그런 경우 `git reflog`를 사용해 특정 명령어 실행 전의 코드로 돌아갈 수 있다. (`git log -g --abbrev-commit --pretty=oneline`도 사용할 수 있다.) $ git reflog a1b2c3d (HEAD -wip/goofy, origin/develop, origin/HEAD) HEAD@{0}: checkout: moving from wip/goofy to develop a1b2c3d (HEAD -wip/goofy, origin/develop, origin/HEAD) HEAD@{1}: reset: moving to a1b2c3d7aa62eaab5fdc1dfa83993d9b9e78bde5 c

truborepo remote cache `.turbo/cache`가 캐시 경로임 그걸 업로드해서 remote 공유해서 쓸 수 있게 하는 게 remote cache

New Architecture

JIS 맨 처음엔 RN에서 js 엔진으로 JSC(Apple에서 만든, safari에서 쓰이는 엔진)가 사용되었는데, 브릿지의 책임이 커지고 서로 강결합된다는 문제가 발생했다. 이러한 문제를 해결하기 위해 엔진 인터페이스(JSI)가 만들어졌다. JIS는 Native와 JS 코드가 직접 상호작용할 수 있도록 한다. 즉 JSI라는 인터페이스를 통해서 자바스크립트가 호스트 쪽 객체의 레퍼런스를 직접 가질 수 있도록, 그리고 호스트 쪽 메소드도 직접 호출할 수 있도록 한다. 데이터 전달 과정 네이티브 모듈 인프라로 전달 js runtime이 c++로 전해주고, 네이티브 모듈 인프라로 전해서 처리 뷰도 같은 식으로 전달해서 UI Manager로 전해서 처리 (메모리 업데이트 되면 JS에 반영이 되어서 표

리액트 네이티브는 iOS와 안드로이드에서 동작하는 네이티브 모바일 앱을 만들기 위한 자바스크립트 프레임워크이다. 리액트 네이티브의 동작 원리는 리액트의 가상(virtual) DOM과 관련되어 있습니다. DOM 수정은 매우 값비싼 동작이기 때문에 리액트는 페이지의 변화를 바로 렌더링 하는 대신 메모리의 가상 DOM을 이용해 변화가 필요한 곳을 계산하고 최소한의 변경사항만 렌더링한다. 리액트 네이티브는 같은 원리를 이용해 브라우저의 DOM이 아닌 오브젝티브-C API를 호출하여 iOS 컴포넌트를 렌더링하고, 자바 API를 호출하여 안드로이드 컴포넌트를 렌더링한다. 이는 브릿지가 대상 플랫폼의 네이티브 UI 요소에 접근하는 인터페이스를 제공하기 때문에 가능하다. 스레딩 모델 리액트 네이티브는 다음의

소프트웨어 공학

소프트웨어 공학 수업 기말고사 대비 정리입니다. --- 소프트웨어 공학 공학에는 정해진 기간과 주어진 비용이라는 제한이 있기에, 문제 해결을 위한 기술과 공학적 원리를 활용해야 한다. 그리고 이를 실무에 적용해 문제 해결의 절차를 만들고 반복적인 절차를 개선해 표준을 만들어낸다. 소프트웨어 개발의 어려움을 해결하기 위해 공학을 적용하는 것이 소프트웨어 공학이다. 비용 산정 기법 하향식 전문가 판단 기법 델파이 기법: 전문가의 편견에 영향받지 않도록 조정자를 둠 상향식 코드 라인 수(Line Of Code): 코드 라인 수를 구하고 노력 산정 개발 단계별 노력 기법: 각 단계의 노력 투여를 맨먼스(M/M)로 구함 수학적 COCOMO: 라인 수를 추정하고, 이

테스팅 용어

테스팅의 기초 테스팅: 소프트웨어 제품과 관련 작업 산출물이 특정 요구명세를 만족하는지 결정하고, 목적에 부합하는지 입증하고 결함을 찾아내기 위해 해당 산출물을 계획, 준비, 평가하는 정적/동적인 모든 수명주기 활동으로 구성된 프로세스 커버리지: 특정한 커버리지 항목이 테스트 스위트에 의해 이행되는 백분율 정도 디버깅: 소프트웨어에서 장애의 원인을 발견하고, 분석하여 제거하는 절차 테스트 오라클: 테스트 대상 소프트웨어의 실제 결과와 비교할 목적으로 예상 결과를 결정하는 근거 밸리데이션: 요구사항이 컴포넌트나 시스템을 특정하게 의도적으로 사용 또는 활용하는 것을 충족시키는지 조사에 의해서나 객관적인 증거 제공으로 확인하는 것. 베리피케이션: 명세된 요

Apache Airflow는 초기 에어비엔비(Airfbnb) 엔지니어링 팀에서 개발한 워크플로우 오픈 소스 플랫폼이다. 워크플로우란 의존성으로 연결된 작업(Task)들의 집합을 말한다. 예를 들어 ETL의 경우 Extractaction Transformation Loading 의 작업의 흐름을 가지는 워크플로우이다. Airflow를 사용하면 프로그래밍 방식으로 워크플로우를 작성, 예약 및 모니터링할 수 있다. Key Concept DAG (Directed Acyclic Graph) 단어 뜻 그대로 순환하지 않는 그래프, DAG(대그)라고 부름 반복이나 순환을 허용하지 않음 순차적으로 작업(task)이 이루어지며, 순환 실행을 방지하기 때문에 매우 중요함 → 논리적 오류는 교착상태(deadlo

Vim 이동 기본 이동 -`h`, `j`, `k`, `l` : 좌, 하, 상, 우 커서 이동 `-` : 줄의 처음 위치로 커서 이동 `gg` : 맨 위로 커서 이동 `shift + g` : 맨 아래로 커서 이동 단어 단위로 이동 `w` : 단어의 시작 위치로 커서 이동 (오른쪽 방향) `b` : 단어의 시작 위치로 커서 이동 (왼쪽 방향) `e` : 단어의 마지막 위치로 커서 이동 (오른쪽 방향) `ge` : 단어의 마지막 위치로 커서 이동 (왼쪽 방향) 한 문장 내에서 이동 `0 (숫자)` : 라인 맨 앞으로 커서 이동 `^` : 문장 맨 앞으로 커서 이동 `$` : 문장 맨 뒤로 커서 이동 현재 페이지에서의 이동 `shift + h` : 현재 보이는 페이지에서 커서를 맨 위로 이

커서 이동 행 `k` : 커서를 한 행 위로 이동 `j` : 커서를 한 행 아래로 이동 `-` : 커서를 앞 행의 처음으로 이동 `+` : 커서를 다음 행의 처음으로 이동 `^` 또는 `0` : 커서를 현재 행의 맨 처음으로 이동 `$` : 커서를 현재 행의 마지막으로 이동 글자 `l` : 커서를 한 글자 오른쪽으로 이동 `h` : 커서를 한 글자 왼쪽으로 이동 단어 `w` : 커서를 다음 단어의 첫 글자로 이동 `b` : 커서를 앞 단어의 첫 글자로 이동 화면 이동하기 반 화면 `Ctrl + u` : 반 화면 위로 이동 `Ctrl + d` : 반 화면 아래로 이동 한 화면 `Ctrl + b` : 한 화면 위로 이동 `

Git Flow 는 2010년 Vincent Driessen 이 작성한 블로그 글을 통해 유명해지기 시작한 Git Branching Model중 하나로, Git의 사용 방법론이다. GitFlow는 프로젝트를 런칭한 이후에도 코드를 관리하기 용이하게 하고, 프로젝트에서 발생하는 다영한 워크플로우의 구현이 가능하기 떄문에 많은 개발자들이 사용하는 방법론으로 자리잡게 되었다. 에디터와 IDE에서 플러그인으로 지원하는 경우도 많다. 브랜치의 종류가 많아 복잡하고, release와 master의 구분이 모호하기도 하지만 프로젝트의 규모가 커지면 커질수록 소스코드를 관리하기에 용이하다는 장점이 있다. --- GitFlow의 브랜치 Git Flow는 크게 5개의 branch 를 사용한다. 그중 가장 중심이

GitFlow의 브랜치 전략의 복잡한 부분을 생략하여 간략화한 브랜치 전략이다. github flow는 master 브랜치 하나만을 가지고 진행하는 방식이다. GitHub Flow는 `master`와 `feature`, 두개의 브랜치로 나뉜다. Github Flow의 개발 과정은 다음과 같다. 1. master 브랜치에서 개발이 시작된다. 2. 기능이나 버그에 대해 issue를 작성한다. 3. 팀원들이 issue 해결을 위해 master 브랜치에서 생성한 `feature/{구현기능}` 브랜치에서 개발을 진행하고 커밋한다. 4. 개발한 코드를 master 브랜치에 병합할 수 있도록 요청을 보낸다. 즉, pull request를 날린다. 5. pull request를 통해 팀원들간에

Gitlab은 Git의 원격 저장소와 코드 리뷰, 이슈 트래커 기능등을 제공하는 소프트웨어로, 설치형 Github라는 컨셉으로 시작된 프로젝트이기 때문에 Github와 비슷한 면이 많다. 1. 패키지 종류 GitLab 패키지는 3가지로 구분된다. GitLab CE : Community Edition으로 설치형이고 아무런 제한 없이 무료 GitLab EE : Enterprise Edition으로 설치형이고 매월 유저당 과금 [(참고)]( GitLab.com : 클라우드형이고 개인이 가입해서 사용하면 무료 2. 기능 Git 저장소 및 관리 프로젝트 생성하면 자동으로 git 저장소가 생성됨 그룹 및 팀원 그룹을 만들고 팀원을 지정

githook을 위한 perl command

perl option Perl은 심플한 프로그래밍 언어 중 하나이다. CLI에서 `perl` 명령어를 통해 짧은 스크립트를 실행할 수 있다. 아래와 같이 텍스트 대치 등 간단한 처리 스크립트를 작성하는 데 사용하기 좋다. bash perl -p0e 's/__PROJECT_TREE__/`cat`/se' "$readme_template" "$readme" 1. 실행 제어 -e : 스크립트로서 실행할 스트링을 지정하여 Command Line에서 수행 -M : 펄 모듈을 로드하는 옵션이며, Default Import 하지 않을 경우 -m 옵션을 사용 -l : 표준 장소 앞에서 모듈을 검색하기 위한 디렉토리 지정 -c : 펄 프로그램을 컴파일(실행전

Git에서는 어떤 이벤트가 생겼을 때 자동으로 특정 스크립트를 실행하도록 할 수 있다. 이 훅은 클라이언트 훅과 서버 훅으로 나눌 수 있는데, 클라이언트 훅은 커밋이나 Merge 할 때 실행되고 서버 훅은 Push 할 때 서버에서 실행된다. 프로젝트의 `.git/hooks` 폴더에 들어가서 해당 훅의 이름을 파일명으로 쉘스크립트를 작성하면, 해당 훅이 특정 상황에 자동으로 실행된다. 분류에 따른 훅은 아래 표와 같다. Commit workflow hook |훅|설명| |-|-| |pre-commit|commit 을 실행하기 전에 실행| |prepare-commit-msg|commit 메시지를 생성하고 편집기를 실행하기 전에 실행| |commit-msg|commit 메시지를 완성한 후 com

파일트리 자동생성

레포지토리 폴더에 `.git/hook/pre-commit` 파일을 생성하여 아래 스크립트를 넣으면 커밋시에 README.md 파일에 트리가 자동으로 생성된다. (mac 기준) bash !/bin/bash export LANG=UTF-8 function generate_project_tree() { tree /Users/rlaisqls/Documents/github/TIL -tf --noreport -I '~' --charset ascii $1 | gsed -e 's/[|]-\+/╊━/g' | gsed -e 's/[|]/┃/g' | gsed -e 's/[`]/┗━/g' | gsed -e 's/[-]/━/g' | gsed -e 's:\(━ \)\(\(.*/\)

Selfhosted Runner

Self-hosted Runner란 Github Actions에서 사용자가 지정하는 로컬 컴퓨팅 자원으로 빌드를 수행하도록 설정하는 기능이다. 주로 배포작업이 많아 배포가 지체되거나 서버 비용이 부담되는 경우 사용한다. 설정 방법 Github Actions을 사용하고자 하는 저장소에서 Settings Actions Runners로 이동한다. 설정하고자 하는 로컬 머신에 해당되는 OS를 선택하면 OS 별로 설정하는 방법이 Download와 Configure란에 설명되어 있다. Linux 기준으로는 다음과 같다. Download bash Create a folder $ mkdir actions-runner && cd actions-runner Download the latest runne

기존 TIL Repository는 파일을 추가하거나 수정한 뒤 수동으로 커밋하는 방식으로 운영했다. 하지만 혼자 작성하다보니 버전 관리에 대한 이점도 크게 없고, 생성이나 수정에 대한 커밋을 각각 나눠서 하는게 번거로워서 그냥 하루에 한 번씩 local crontab을 돌려 자동으로 커밋하도록 하는 쉘 스크립트를 작성하였다. 크게 복잡한 내용은 없고 그냥 `git . add` 한 뒤 커밋하는 것이 전부이다. 단, 작성중이어서 커밋하면 안되는 파일은 접두사에 `+`를 붙여서 표기하고 gitignore에 커밋되지 않도록 설정해줬다. `+`로 정한 이유는 명령어상 다른 특별한 의미가 없으면서 파일명 앞에 들어갈 일이 없을 것 같은 기호였기 때문이다. `+autocommit.sh`를 정의한다. bas

GTM은 ‘코드추적을 용이하게 해주는 도구이자 태그 관리 툴’이다. 기존에는 Google Analytics(GA), 페이스북 픽셀 등과 같은 트래킹 툴을 각각 설정해야 했다. 하지만 GTM은 트래킹을 위한 코드의 삽입, 수정, 삭제 모두를 효율적으로 관리할 수 있게 해준다. GTM 코드만 삽입하면, 새로운 마케팅 툴을 여러 개 추가하더라도 추가적인 코드작업 없이 손쉽게 설치 할 수 있다. 핵심 용어 태그 데이터를 어디로 전달할 지를 정의한다. 데이터를 추적해 활용하는 트레이싱 툴을 등록하면 된다. 트리거 어떤 경우에 실행할 지를 정의한다. 트리거 조건을 충족했을 경우 데이터가 전송된다. 트리거 유형은 사용자의 창 로드, 클릭, 스크롤 등이 될 수 있다. 변수

Intellij Profiling tools

IntelliJ IDEA Ultimate를 사용하고 있다면 Profiling tools을 사용하여 애플리케이션에 대한 부가적인 분석 정보를 얻을 수 있다. 세부 기능으로는 애플리케이션의 실행 방식과 메모리, CPU 리소스가 할당되는 방식에 대한 분석을 제공하는 Async Profiler, 애플리케이션이 실행되는 동안 JVM에서 발생한 이벤트에 대한 정보를 수집하는 모니터링 도구인 Java Flight Recorder 등이 있다. 또한 애플리케이션의 특정 시점의 스냅샷으로 메모리를 분석하거나(Analyze memory snapshots) 애플리케이션이 실행되는 도중에도 CPU와 메모리 현황을 실시간으로 확인할 수 있는 기능(CPU and memory live charts)들이 있다. 기능 Pr

Makefiles are a simple way to organize code compilation. This tutorial does not even scratch the surface of what is possible using _make_, but is intended as a starters guide so that you can quickly and easily create your own makefiles for small to medium-sized projects. A Simple Example Let's start off with the following three files, hellomake.c, hellofunc.c, and hellomake.h, which would repre

mermaid로 그릴 수 있는 다이어그램은 아래와 같은 것들이 있다. 플로우 차트 (Flowchart) 시퀀스 다이어그램 (Sequence Diagram) 간트 차트 (Gantt Chart) 클래스 다이어그램 (Class Diagram) User Journey Diagram Git graph Entity Relationship Diagram 플로우 차트(Flowcharts) 모든 플로우 차트는 각 상태를 나타내는 Node와 Node를 이어주는 간선(Edge)으로 구성된다. 우리는 mermaid를 통해 다양한 화살표, 간선 타입, 서브 그래프로 플로우차트를 간단하게 그려낼 수 있다. java flowchart LR A[구매] --B; B[유저, 파라미터, \n 어뷰징 검증] --C

Apache Spark는 빅 데이터 워크로드에 주로 사용되는 오픈 소스 분산 처리 시스템이다. Apache Spark는 빠른 성능을 위해 인 메모리 캐싱과 최적화된 실행을 사용하며, 일반 배치 처리, 스트리밍 분석, 기계 학습, 그래프 데이터베이스 및 임시 쿼리를 지원한다. 장점 빠른 성능: Apache Spark는 방향성 비순환 그래프(DAG) 실행 엔진을 사용함으로써 데이터 변환에 대한 효율적인 쿼리 계획을 생성할 수 있다. 또한, Apache Spark는 입력, 출력 및 중간 데이터를 인 메모리에 RDD(Resilient Distributed Dataset)로 저장하므로, I/O 비용 없이 반복 또는 대화형 워크로드를 빠르게 처리하고 성능을 높일 수 있다. 애플리케이션을 신속하게

정보 보안에는 인증(Authentication, authn)와 인가(Authorization, authz)라는 개념이 있다. 간단히 말하자면 authn은 정체성 또는 그 유저가 누구인지와 관련있는 반면, authz는 권한 또는 누군가가 할 수 있는 것을 다룬다. 둘은 연관되어있지만 서로 다른 개념이고, 유저를 식별하고 접근을 관리하는(IAM)에서 중요한 요소이다. --- Authentication(authn)이란? authn은 사용자의 신원을 검증하는 행위로서 보안 프로세스에서 첫 번째 단계이며, 사용자 또는 장치가 누구인지(또는 무엇인지)를 확인하는 것을 의미한다. 신분을 확인함으로써 사용자가 합법적인지 확인하고자 하는 것이며, 잘못된 사람에게 정보가 노출되지 않도록 보장한다. 일

FineGrained와 CoarseGrained

Fine-grained는 사전적으로 "결이 고운", "미세한"이라는 의미를 가지고, Coarse-grained는 "결이 거친", "조잡한"의 의미를 가진다. Grain은 곡식 혹은 낱알을 뜻하는데, 알갱이가 거칠고 큼직큼직헌지, 곱고 세밀한지에 따라서 Coarse와 Fine으로 나누어 표현한다고 이해할 수 있다. Fine-Grained 하나의 작업을 작은 단위의 프로세스로 나눈 뒤, 다수의 호출을 통해, 작업 결과를 생성해내는 방식 예를 들어, `Do`라는 동작이 있다면 해당 함수를 `First_Do()`, `Second_Do()`로 나누어 작업 결과를 생성해냄 다양한 "Flexible System" 상에서 유용하게 쓰일 수 있음 Coarse-Grained 하나의 작업을 큰 단위의 프로

api-아키텍처

GraphQL은 정확하게 데이터를 요청하는 방법을 설명하는 구문이다. 서로를 참조하는 복잡한 엔티티를 사용하는 애플리케이션의 데이터 모델을 사용하고, 그것을 다양한 방식으로 조회해야 할때 유용하게 사용된다. 최근 GraphQL 생태계는 Apollo, GraphiQL, GraphQL Explorer와 같은 강력한 도구와 라이브러리로 확장되고 있다. GraphQL 동작방식 GraphQL은 GraphQL API에서 만들 수 있는 모든 쿼리와 반환하는 모든 타입에 대해 설명하는 스키마를 정의하는 것으로 시작한다. 스키마 정의 언어(SDL)에서는 엄격한 타입 정의를 사용하기 때문에 스키마 정의가 쉽지 않다. 쿼리 전에 스키마를 통해 쿼리에 대한 유효성 검사를 한 뒤 본 요청이 백엔드 애플리케이션에 도달하면,

api-아키텍처

REST는 설계적 제약 조건으로 API 스스로에 대한 설명이 가능하여 수 많은 API 소비자에게 채택될 수 있도록 정의된 API 아키텍처 스타일이다. 오늘날 가장 대중적인 REST API 아키텍처 스타일은 2000년 Roy Fielding의 박사 학위 논문에 처음 소개되었다. REST API는 서버 측에서 JSON 및 XML과 같은 간단한 형식의 데이터로 표현 가능하게 한다. REST 동작 방식 REST는 SOAP만큼 엄격하게 정의되어 있지 않다. RESTful한 아키텍처는 6개의 설계 제약 조건을 준수해야 한다. 일관성 있는 인터페이스 : 장비 또는 애플리케이션 타입과 무관하게 목표 서버와 통신하도록 일관성 있는 통신 방법을 허용한다. 무상태 : 요청 자체가 요청을 처리하는 데 필요

api-아키텍처

RPC란 원격 프로시저 호출이라는 뜻으로, 다른 컨텍스트에서 함수의 원격 실행을 허용하는 사양이다. RPC는 로컬 프로시저 호출 개념을 확장한 것이지만, HTTP API 컨텍스트에 포함되는 개념이다. 초기 XML-RPC는 XML 페이로드 데이터의 타입을 보장하기 어렵다는 문제를 가지고 있었다. 그래서 차후의 RPC API는 보다 정형화된 JSON-RPC를 사용하여 SOAP보다 단순한 구조를 지닌 SOAP의 대안으로 인식되었다. 그중 gRPC는 2015년 Google에서 개발한 최신 버전의 RPC이며, 로드밸런싱, 추적, 상태 확인, 그리고 인증을 위한 플러그인을 지원하기 때문에 마이크로 서비스 연결에 매우 적합하다. RPC 동작방식 클라이언트는 원격 프로시저를 호출하고 매개 변수와 추가 정

api-아키텍처

SOAP는 XML 형식의 고도로 표준화된 웹 통신 프로토콜이다. XML-RPC 출시 1년 후에 SOAP가 출시되었기 때문에 SOAP는 XML-RPC로부터 상당 부분을 물려받았다. 이후 REST가 출시되었을 때, SOAP와 REST는 같이 사용되었지만, 곧 REST만 사용하는 추세가 시작되었다. SOAP의 동작 방식 SOAP 메시지는 다음과 같이 구성된다. 메시지의 시작과 끝을 표시하는 envelop tag 요청 또는 응답 body 메시지가 특정 사항이나 추가 요구 사항을 결정해야되는지에 대한 정보를 나타내는 헤더 요청을 처리하는 도중 발생할 수 있는 오류에 대한 안내 SOAP API 로직은 웹 서비스 기술 언어(WSDL)로 작성된다. 이 API 기술 언어는 endpoint를 정의하고 실행

아키텍처-및-방법론

CQRS는 Command Query Responsibility Segregation 의 약자로, 단어 그대로 해석하면 "명령 조회 책임 분리"를 뜻한다. 즉, 우리가 보통 이야기하는 CRUD(Create, Read, Update, Delete)에서 CUD(Command)와 R(Query)의 책임을 분리하는 것이다. CQRS가 필요한 이유 Application의 Business 정책이나 제약은 데이터 변경(CUD)에서 처리되고, 데이터 조회(R) 작업은 단순 데이터 조회를 처리하는데, 두가지 작업 모두를 동일 Domain Model로 처리하면 필요하지 않은 Domain 속성들이 생겨 복잡도가 증가한다. 도메인의 여러 속성들이 얽히면 유지보수의 비용이 증가하고 Domain model은 설계의 방향과 다르

DDD는 Domain Driven Design, 즉 도메인 주도 설계이다. 도메인을 중심으로 애플리케이션을 설계, 구성하는 방법이다. 도메인(Domain) 도메인이란 '소프트웨어로 해결하고자 하는 문제 영역'을 의미한다. 한 도메인은 다시 하위 도메인으로 나눌 수 있고, 도메인들은 서로 연동하여 완전한 기능을 제공한다. 이 `도메인`은 소프트웨어의 요구사항을 이해하는데 중요한 요소이다. 서비스를 통해 어떤 문제를 해결할 것인지, 어떤 도메인을 다룰 것인지, 도메인끼리의 관계가 어떠한지 확실하게 알아야 요구사항을 제대로 이해하고 개발을 효율적으로 진행할 수 있다. 도메인은 사용자가 누구인가, 어떻게 사용하냐에 따라 같은요소라고 할지라도 계속 바뀔 수 있고, 형태가 고정되어있지 않은

DDD의 아키텍처

도메인 주도 설계에서는 도메인을 중심으로하여 애플리케이션을 설계, 구성한다. 애플리케이션은 도메인 외에도 표현, 응용, 인프라스트럭처 등의 영억으로 나뉘어있고 각각의 역할을 수행한다. application전체를 구성하는 아키텍처 요소에 대해 알아보자. 대표적으로 DDD에서는 위와 같은 구조의 Layered Architecture를 가진다. 계층별 설명 1. Presentation Layer (표현 계층) 사용자 요청을 해석하고 응답하는 일을 책임지는 계층이다. 사용자에게 UI를 제공하거나 클라이언트에 응답을 보내는 모든 클래스가 포함된다. Client로부터 request를 받아 response를 보내는 API를 정의한다. 2. Application Layer (응용 계층) 사용

도메인영역

도메인 영역의 주요 구성요소는 아래 다섯가지가 있다. | 요소 | 설명 | | --| --| | 엔티티(Entity) | 고유의 식별자를 갖는 객체이다.도메인 모델의 데이터를 포함하며, 해당 데이터와 관련된 기능을 함께 제공한다. | | 밸류(Value) | 고유의 식별자를 갖지 않는 객체로, 주로 개념적으로 하나인 도메인 객체의 속성을 표현할 때 사용된다. (ex. 주소, 배송상태)엔티티의 속성뿐만 아니라 다른 밸류 타입의 속성으로도 사용될 수 있다. | | 애그리거트(Aggregate) | 애그리거트는 관련된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것이다.도메인 관계 복잡도를 낮추기 위해 여러 하위 도메인을 독립된 객체군으로 나눈다. | | 리포지터리(Repository) | 도메인 모델의 영속성

이벤트 스토밍

이벤트 스토밍이란 도메인에 관련된 모든 이해 관계자가 모여서 화이트 보드와 포스트잇을 활용하여 이벤트를 중심으로 업무들 간의 상호 연관성을 찾기 위해 진행하는 워크숍 방법론이다. 도메인 전문가와 개발자를 학습 과정에 참여시키기 위해 설계되었고, 모든 사람들이 시각적으로 도메인에 시각적으로 접근할 수 있게 해준다. 이벤트 스토밍을 하는 이유? 이벤트 스토밍의 가장 큰 목적은 도메인지식을 공유함으로써 전체 비스니스가 어떻게 돌아가는지 한눈에 볼 수 있는 지도(타임라인)를 만드는 것이다. 각 도메인 전문가들의 도메인 지식은 모두 분산되어 있기 때문에 한번에 전체 지도를 그리기 힘든데, 이벤트 스토밍은 그 지식을 모아 정리할 수 있도록 한다. 이벤트 스토밍 하는 법 이벤트 스토밍을

바운디드 컨텍스트의 모델은 서로 독립적이지만 바운디드 컨텍스트 자체는 독립적이지 않다. 컨텍스트는 각자 독립적으로 발전할 수 있지만 컨텍스트끼리는 서로 상호작용해야 하기 때문에, 그 사이에는 항상 접점이 생기는데 이를 컨트랙트(Contract) 라고 부른다. 바운디드 컨텍스트 간의 연동, 즉 컨트랙트에 대한 고민은 솔루션 설계에서 평가되고 다뤄져야 한다. ![image]( 바운디드 컨텍스트간의 연관관계를 나타낸 컨텍스트 맵의 예시이다. 바운디드 컨텍스트 간의 관계는 두 컨텍스트를 작업하는 팀 간의 협력적 특성이나

HexagonalArchitecture

아키텍처-및-방법론

The Hexagonal Architecture is a very powerful pattern. It helps you create more sustainable and better testable software by decoupling the business logic from the technical code. 만약 비즈니스 로직(Domain)이 특정 라이브러리에 의존성을 가지고 있다면 기술 스택을 업그레이드하고 바꿔야 할떄, 모든 비즈니스 로직과 infrastructure를 갈아 엎어야 할 것이다! 육각형 아키텍처(Hexagonal Architecture)는 그러한 문제를 해결하기 위해 기술과 비지니스 로직 사이를 분리하여 비지니스 로직이 기술에 구애받지 않고 동작할 수 있도록 하는 아

MSA의 장단점

마이크로서비스 아키텍처의 장점 크고 복잡한 애플리케이션을 지속적으로 전달/배포할 수 있다. (CI/CD) MSA를 구축하면 크고 복잡한 애플리케이션을 지속적 전달/배포할 수 있다. MSA는 다음과 같은 세가지 방법으로 지속적 전달/배포를 실현한다. 테스트성: 지속적 전달/배포를 하려면 자동화 테스트가 꼭 필요하다. MSA는 상대적으로 크기가 작아서 자동화 테스트를 작성하기 쉽고 더 빨리 실행되며, 애플리케이션 버그도 적은 편이다. 배포성: MSA는 독립적으로 배포할 수 있기 때문에 개발자가 자신이 담당한 서비스 변경분을 배포할때 다른 개발자와 복잡한 협의 과정을 거칠 필요가 없다. 그래서 프로덕션에 변경분을 반영하기가 훨씬 수월하다. 자율성, 느슨한 결합: 작은 팀이 여러개 결

메시지 브로커

브로커리스 메시징 브로커리스 아키텍처의 서비스는 메세지를 서로 직접 교환한다. 장점 송신자가 보낸 메시지가 브로커를 거쳐 수신자로 이동하는 것이 아닐, 송신자에서 수신자로 직접 전달되므로 네트워크 트래픽이 가볍고 지연 시간이 짧다. 메시지 브로커가 성능 병목점이나 SPOF(단일 정야좀)가 될 일이 없다. 메시지 브로커를 설정/관리할 필요가 없으므로 운영 복잡도가 낮다. 단점 서비스가 서로의 위치를 알고 있어야 하므로 서비스 디스커버리 메커니즘을 사용해야한다. 메시지 교환시 송신자/수신자 모두 실행중이어야 하므로 강ㅇ성이 떨어진다. 전달 보장같은 메커니즘을 구현하기가 어렵다. 브로커 기반 메시징 메시지 브로커는 모든 메시지가 지나가는 중간 지점이다. 송신자가 메시지 브로커에 메시

사가는 MSA에서 분산 트랜잭션 없이 데이터 일관성을 유지하는 메커니즘이다. 사가는 일종의 로컬 트랜잭션인데, 각 로컬 트핸잭션은 ACID 트랜잭션 프레임워크/라이브러리를 이용하여 서비스별 데이터를 업데이트한다. 주문 서비스의 createOrder() 작업은 6개의 로컬 트랜잭션을 가진 주문 생성 사가로 구현된다. Txn:1 주문 서비스: 주문을 APPROVAL_PENDING 상태로 생성한다. Txn:2 소비자 서비스: 주문 가능한 소비자인지 확인한다. Txn:3 주방 서비스: 주문 내역을 확인하고 티켓을 CREATE_PENDING 상태로 생성한다. Txn:4 회계 서비스: 소비자 신용카드를 승인한다. Txn:5 주방 서비스: 티켓 상태를 AWATING_A

사가는 단계를 편성하는 로직으로 구성된다. 시스템 커맨드가 사가를 시작할 때 해당 편성 로직은 첫 번째 사가 참여자를 정하여 로컬 트랜잭션 실행을 지시하고, 트랜잭션이 완료되면 모든 단계를 실행 될때까지 계속 그다음 사가 참여자를 호출한다. 로컬 트랜잭션이 도중에 하나라도 실패한다면 사가는 보상 트랜잭션을 역순으로 실행한다. 이와 같은 사가를 편성하는 로직은 두 가지 종류가 있다. |종류|설명| |-|-| |코레오그래피(choreography)|의사 결정과 순서화를 사가 참여자에게 맡긴다. 사가 참여자는 주로 이벤트 교환 방식으로 통신한다.| |오케스트레이션(orchestration)|사가 편성 로직을 사가 오케스트레이터에 중앙화한다. 사가 오케스트레이터는 사가 참여자에게 커맨드 메시지를 보내 수행할 작업

시맨틱 버저닝

마이크로서비스 애플리케이션은 클라이언트를 다른 서비스 팀이 이비 개발한 경우가 대부분이기 때문에 서비스 API를 변경하기가 어렵다. 서비스를 클라리언트를 모두 찾아 강제로 업그레이드시키기도 쉽지 않다. 또 요즘은 유지보수시 서버를 내리지 않기 때문에 규칙적인 단계로 서비스를 업그레이드하여 신구버전을 동시에 실행해야한다. [시맨틱 버저닝]( 명세는 API 버저닝에 관한 유용한 지침서이다. 여기에ㅔ는 버전 번호를 사용하고 증가시키는 규칙들이 면시되어있다. 시맨틱 버저닝은 원래 소프트웨어 패키지의 버저닝 용도로 쓰였지만, 분산 시스템의 API 버저닝에도 사용할 수 있다. ![image](

MSA에서는 각 서버가 서로 통신함으로써 여러 도메인이 엮인 요청을 처리할 수 있도록 한다. 이때 서버간 통신을 위해 일반적인 IPC인 REST를 사용할 수 있지만, REST는 동기 프로토콜이기 때문에 호출한 서비스가 응답할 때까지 클라이이언트가 대기해야한다는 단점이 있다. 따라서 서비스가 동기 프로토콜로 통신하면 그만큼 애플리케이션 가용성은 저하될 수밖에 없다. 서비스가 모두 HTTP 통신을 사용한다면, 어느 하나의 서버가 내려갔을때 제대로 동작할 수 없다. 동기 상호 작용 제거 이를 해결하기 위해 비동기 만 있는 서비스를 정의해서 해결할 수도 있지만, 어쩔 수 없이 서비스에 동기 API를 포함시켜야 할 경우가 많다. 이런 경우에는 동작을 조금 우회한 비동기 처리 기법을 사용할 수 있다. 비동기

트랜잭션 격리

사가를 사용하는 경우, 여러 서버와 도메인에 걸친 트랜잭션을 보장해줄 수 있지만 트랜잭션의 완전한 격리를 완벽히 보장할 순 없다. 따라서 dirty read나 nonrepeatable read 등의 문제들이 생길 수 있는데, 이런 문제들을 해결하기 위해선 사가의 격리를 위한 전략을 사용해줘야한다. 이를 위한 전략으로는 아래와 같은 것들이 있다. 시맨틱 락(Semantic Lock) 보상 가능 트랜잭션이 생성/수정하는 레코드에 무조건 플래그를 세팅하는 대책이다. 레코드가 아직 커밋 전이라서 변경될지 모르니, 다른 트랜잭션이 레코드에 접근하지 못하도록 락을 걸어놓는 것이다. 그 플래그는 재시도 가

트랜잭션 로그 테일링 패턴

메시지 브로커는 보통 메시지를 적어도 한 번 이상 전달한다. 클라이언트나 네트워크, 혹은 브로커 자신에 이상이 있는 경우 같은 메시지를 여러번 전달할 수도 있다. 하지만 이때 메시지를 여러번 전달함으로 인해 중복 메세지가 발생하여 멱등하지 않은 시스템에 지장을 주거나, 메시지 순서가 꼬여 잘못 처리될 수도 있다. 이를 해결하기 위해 ID를 기록하여 검사하거나 DB 폴링 방식을 사용하기도 한다. 이때 사용할 수 있는 정교하고 성능이 꽤 좋은 방식중 하나로는, 트랜잭션 로그 테일링 패턴이 있다. 말 그대로 메시지 릴레이를 통해 DB 트랜잭션 로그(커밋 로그)를 tailing하는 방법이다. 애플리케이션에서 커밋된 업데이트를 각 DB의 트랜잭션 로그 항목(log entry)으로 남긴다. 그리고 그 후에 트

1. 단일 책임 원칙 (Single Responsibility Principle, SRP) 하나의 모듈는 하나의 책임만 가져야 한다. SRP를 적용하면 메소드의 책임 영역이 확실해지기 때문에 한 기능이 수정되었을 때 다른 연쇄작용을 일으키지 않는다. 또, 책임을 적절히 분배함으로써 코드의 가독성이 향상되고 유지보수가 용이해진다. 2. 개방 폐쇄 원칙 (Open-Closed Principle, OCP) 소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀 있어야 한다. 코드를 수정하거나 기능을 추가할 일이 생겨도 기존 구성 요소는 바뀌지 말아야한다. 추상화와 다형성으로 구현할 수 있다. 3. 리스코프 치환의 원칙 (Liskov Substitutiong Principle, LSP) 서브 타

응집도와 결합도

응집도와 결합도는 코드의 관심사와 연결관계가 어느정도로 구분되어있고, 얽혀있는지를 나타내는 정도이며, 모듈의 독립성을 판단하는 두 가지 지표이다. 응집도는 모듈 내부의 기능적인 집중 정도, 결합도는 모듈과 모듈간의 상호 의존 정도라고 할 수 있다. 높은 응집도와 낮은 결합도를 가진 코드가 객체지향적으로 좋은 코드로 여겨지며, 객체지향 원칙 중 개방 폐쇄 원칙(Open-Closed Principle, OCP)과 연관있는 개념이다. 응집도(Cohesion) 응집도는 모듈에 포함된 내부 요소들이 하나의 책임/ 목적을 위해 연결되어있는 연관된 정도이다. 응집도가 높다는 것은, 하나의 모듈또는 쿨래스가 하나의 책임 또는 관심사에만 집중되어있다는 것을 뜻한다. 응집도가 높으면 그 모듈이 처리할 수

빌더 패턴은 복합 객체의 생성 과정과 표현 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴이다. 빌더 패턴을 사용하면 객체를 생성할 떄 필요한 값만 넣을 수 있다. 그리고 파라미터룰 사용한 생성자가 아니라 변수명을 명시하여 생성하는 것이기 때문에 변수 순서가 바뀌거나 새로 추가될때 유연하게 대처할 수 있고 매개변수가 많아져도 가독성을 높일 수 있다. 구현하는 것이 복잡하기 때문에 직접 구현하면 코드 구조가 읽기 어려워진다는 단점이 있다. Lombok에서 제공해주는 @Builder 어노테이션을 사용하면 Lombok이 자동으로 빌더를 만들어준다. --- 예시 코드 java @Getter @Setter public class Pizza { String

싱글톤 패턴

싱글톤 패턴은 애플리케이션이 시작될 때, 어떤 클래스가 최초 한 번만 메모리를 할당(static)하고 인스턴스를 생성하여 사용하는 패턴이다. 똑같은 인스턴스를 여러개 생성하지 않고, 어디에서 접근하든 기존에 만들었던 인스턴스를 이용하도록 한다. --- 예시 코드 java public class LazyInitSingleton { private static LazyInitSingleton instance; private LazyInitSingleton() {} public static LazyInitSingleton getInstance() { if (instance == null) { instance = new LazyInitS

추상팩토리 패턴

서로 관련있는 여러 객체를 만들어주는 인터페이스를 만들어 구체적으로 어떤 클래스의 인스턴스를(concrete product)를 사용하는지 감추는 패턴이다. 구체적인 객체 생성 과정을 추상화한 인터페이스를 제공한다는 점에서 팩토리 메소드 패턴과 비슷하지만 팩토리 메소드 패턴은 구체적인 객체 생성 과정을 하위 또는 구체적인 클래스로 옮기는 것이 목적이고, 추상 팩토리 패턴은 관련있는 여러 객체를 구체적인 클래스에 의존하지 않고 만들 수 있게 해주는 것이 목적이라는 점에서 다르다. --- 예시 코드 java @Getter @Setter @AllArgsConstructor public abstract class Pizza { private String name; private Sau

팩토리메소드 패턴

팩토리 메소드 패턴은 부모(상위) 클래스 코드에 구체 클래스 이름을 감추고, 자식(하위) 클래스가 어떤 객체를 생성할지를 결정하도록 하는 패턴이다. 구체적인 객체 생성 과정을 추상화한 인터페이스를 제공한다는 점에서 추상 팩토리 패턴과 비슷하지만 추상 팩토리 패턴은 관련있는 여러 객체를 구체적인 클래스에 의존하지 않고 만들 수 있게 해주는 것이 목적이고, 팩토리 메소드 패턴은 구체적인 객체 생성 과정을 하위 또는 구체적인 클래스로 옮기는 것이 목적이라는 점에서 다르다. '확장에 대해 열려있고 수정에 대해 닫혀있어야 한다'는 개방-폐쇄 원칙(OCP)을 만족하는 객체 생성 방법이다. --- 예시 코드 java @Getter @Setter @NoArgsConstructor public abstrac

프로토타입 패턴

기존 인스턴스를 프로토타입으로 사용해 새 인스턴스를 만드는 패턴이다. 비슷한 객체를 여러개 만드는 경우 인스턴스를 생성하는 복잡한 과정을 거칠 필요 없이 새 인스턴스를 만들 수 있다는 장점이 있다. --- 예시 코드 java의 Cloneable 인터페이스와 Object의 clone() 메서드를 사용하면 프로토타입 패턴을 간단하게 사용할 수 있다. java @Getter @AllArgsConstructor public class Pizza implements Cloneable{ String name; String topping; String sauce; @Override public Pizza clone() { try {

데코레이터 패턴

데코레이터 패턴은 주어진 상황 및 용도에 따라 객체에 책임을 덧붙이는 패턴이다. 기본 기능에 추가할 수 있는 기능의 종류가 많은 경우에 각 추가 기능을 Decorator 클래스로 정의 한 후 필요한 Decorator 객체를 합함으로써 추가 기능의 조합을 설계 하는 방식이다. 데코레이터 패턴은 객체의 결합 을 통해 기능을 동적으로 유연하게 확장 할 수 있게 해준다. --- 예시 코드 java public interface CommentService { void addComment(String comment); } public class DefaultCommentService implements CommentService{ @Override public void addCom

브릿지 패턴

브릿지 패턴은 구현부에서 추상층을 분리하여 각자 독립적으로 변형할 수 있도록 하는 패턴이다. 즉, 기능과 구현에 대해 별도의 클래스로 구현하여 서로의 코드에 간섭하지 않고 변형, 확장할 수 있도록 하는 것이다. --- 예시 코드 java @AllArgsConstructor public abstract class Pizza { private String name; private Recipe recipe; public String result(){ return recipe.getName() + " " + name; } } public class CheesePizza extends Pizza { public CheesePizza(Recipe

어댑터 패턴

어댑터 패턴은 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴이다. 기존 코드를 변경하지 않고 원하는 인터페이스 구현체를 만들어 사용하는 것이기 때문에 기존 코드가 하던 일과 특정 인터페이스 구현체로 변환하는 작업을 각기 다른 클래스로 분리하여 관리할 수 있다는 장점이 있다. --- 예시 코드 java public interface UserDetails { String getUsername(); String getPassword(); } public interface UserDetailsService { UserDetails loadUser(String username); } public class LoginHandler { priv

컴포짓 패턴

컴포짓 패턴이란 객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴으로, 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 한다. 복합 객체와 단일 객체의 처리 방법이 다르지 않을 경우, 그 관계를 전체-부분 관계로 정의할 수 있는데, 이 전체-부분 관계를 효율적으로 처리하기 위한 디자인 패턴이 컴포짓 패턴이다. --- 예시 코드 대표적인 컴포짓 패턴의 예시는 파일 디렉토리 구조이다. 내가 있는 폴더가 다른 폴더의 자식 폴더인지, root 폴더인지에 상관없이 똑같이 다룰 수 있다. 컴포짓 패턴을 사용하면 재귀적인 트리 구조를 구현할 수 있다. java public interface Composite { String getName(); String g

퍼사드 패턴

퍼사드 패턴은 클라이언트가 사용해야 하는 복잡한 서브 시스템 의존성을 간단한 인터페이스로 추상화 하는 디자인 패턴이다. Client는 서브시스템의 존재를 모르는 상태로, 오직 facade클래스에만 접근할 수 있도록 하는것이 특징이다. --- 예시 코드 java public class PizzaFacade { private final Chef chef = new Chef(); private final Oven oven = new Oven(); public Pizza makingPizza() { Pizza pizza = chef.makingDough(); pizza = chef.addToppings(pizza); retu

프록시 패턴

프록시 패턴은 인터페이스를 사용하고 실행시킬 클래스에 대해 객체가 들어갈 자리에 대리자 객체를 대신 투입하여, 클라이언트는 실제 실행시킬 클래스에 대한 메소드를 호출하여 반환값을 받는지 대리 객체의 메소드를 호출해서 반환값을 받는지 모르도록 하는것을 말한다. 프록시 패턴을 사용하면 실제 메소드가 호출되기 이전에 필요한 기능(전처리등의)을 구현객체 변경없이 추가할 수 있고, 구현클래스에 직접 접근하지않고 Proxy를 통해 한번 우회하여 접근하도록 되어있기 때문에 흐름제어를 할 수 있다는 장점이 있다. --- 예시 코드 java public interface HelloService { String run(); } public class HelloServiceImpl implements

플라이웨이트 패턴

플라이 웨이트 패턴은 동일하거나 유사한 객체들 사이에 가능한 많은 데이터를 서로 공유하여 사용하도록 하여 메모리 사용량을 최소화하는 패턴이다. 플라이웨이트 패턴에서는 일부 오브젝트의 상태 정보를 외부 자료 구조에 저장하여 플라이웨이트 오브젝트가 잠깐 동안 사용할 수 있도록 전달한다. --- 예시 코드 java @Getter @Setter public class Pizza { private String name; private int price; private Dough dough; private Sauce sauce; } 피자가 있다. 이제부터 피자를 아주 많이 만들어서 배송할건데, 만들 때 마다 새 인스턴스로 생성해서 배송하기엔 메모리가 너무 아깝다.

메멘토 패턴

메멘토 패턴은 객체를 이전 상태로 되돌릴 수 있는 기능을 제공하는 소프트웨어 디자인 패턴이다. 현재(원본) 상태를 저장하는 객체인 Originator에서 특정 상태를 저장하는 Memento 객체로 변환하여 CareTaker에 저장하는 구조이며, 핵심 객체의 데이터를 계속해서 캡슐화된 상태로 유지하는 것이 특징이다. --- 예시 코드 java @Getter @Setter public class Originator { private String state; public Memento saveStateToMemento() { return new Memento(state); } public void getStateFromMemento(Memento

방문자 패턴

방문자 패턴은 알고리즘을 객체 구조에서 분리시키는 디자인 패턴이다. 기존 클래스 필드 정보를 유지하면서 새로운 연산을 추가하는 방식 중 하나이다. 비슷한 동작을 수행하는 로직을 Visitor 객체에 모을 수 있기 때문에 코드를 유지보수하기 좋지만, Element와 Visitor 간의 결합도가 상승한다는 단점이 있다. --- 예시 코드 java public interface Element { void visit(Visitor visitor); } public class ElementA implements Element{ @Override public void visit(Visitor visitor) { visitor.visit(this); } }

상태 패턴은 상태 패턴 인터페이스의 파생 클래스로서 각각의 상태를 구현함으로써, 상태를 객체화시키고 상태전이 메서드를 구현할 필요 없이 상태객체가 슈퍼클래스에 의해 정의한 메소드를 호출하여 사용하도록 하는 패턴이다. 상태 전이를 위한 조건 로직이 복잡한 경우 이를 해소하기 위해 사용될 수 있다. --- 예시 코드 java public interface State { State feelingBetter(); State feelingBad(); void printCurrentEmotion(); } java public class Happy implements State{ @Override public State feelingBetter() {

옵저버 패턴

옵서버 패턴은 객체의 상태 변화를 관찰하는 관찰자들을 생성하여, 즉 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하도록 하는 패턴이다. 옵저버 패턴을 활용하면 다른 객체의 상태 변화를 별도의 함수 호출 없이 즉각적으로 알 수 있기 때문에, 이벤트를 자주 처리해야하는 프로그램에서 적합하다. --- 예시 코드 java public interface Publisher { void add(Observer observer); void delete(Observer observer); void notifyObserver(V message); } public class NewsPublisher implements

이터레이터 패턴

이터레이터 패턴은 컬렉션 구현 방법을 노출시키지 않으면서 집합체 안에 들어있는 모든 항목에 접근할 수 있도록 하는 패턴이다. java의 stream이 대표적인 이터레이터 패턴의 예시이다. --- 예시 코드 java @RequiredArgsConstructor public class ArrIterator implements Iterator { private final Integer[] list; private int position = 0; @Override public boolean hasNext() { return position { private final List list; private int position = 0;

인터프리터 패턴

인터프리터 패턴은 자주 등장하는 문제를 간단한 언어로 정의하고 재사용하는 패턴이다. 인터프리터 패턴을 사용하면 반복되는 문제 패턴을 언어 또는 문법으로 정의하고 확장할 수 있다. 쉽게 말하면, 일정한 형식을 갖춘 텍스트(String)를 해석해서 규칙에 맞는 로직을 실행할 수 있도록 하는 것이다. 어떤 용도로, 어떤 언어를 구현하는지에 따라 정말 다양한 코드가 나올 수 있지만, 보통 명령을 입력받아 해석하는 Parser와 그것을 바탕으로 로직을 실행하는 Expression으로 나뉜다. --- 예시 코드 항이 2개인 간단한 덧셈, 뺄셈 식 계산을 인터프리터 패턴으로 구현했다. java public interface Expression { Integer interpret(String co

전략 패턴은 프로그램이 진행되면서 캡슐화된 로직을 선택할 수 있게 하는 디자인 패턴이다. 로직 실행은 인터페이스에 의존을 시키고 인터페이스를 구현한 로직들을 전달해줌으로써 분기처리 없이 유연성을 갖출 수 있다. 객체지향 원칙중 개방-폐쇄 원칙(Open-Closed Principle)을 지키기 위한 디자인 패턴이다. --- 예시 코드 java @Setter @AllArgsConstructor public class Coupon { private DiscountStrategy discountStrategy; public int discount(int price) { return discountStrategy.execute(price); } } public

중재자 패턴

중재자 패턴은 객체간 커뮤니케이션을 하는 경우 중재자를 생성하여 객체끼리의 결합을 약화하는 디자인 패턴이다. 중재자 패턴을 사용하면 N:M개의 객체, 또는 N:1개의 객체간의 데이터 전달도 구현할 수 있다. 객체의 통신을 다룬다는 점에서 옵저버 패턴과 비슷하지만, 옵저버패턴은 한 객체에서 일방적으로 데이터를 송신하는데 반해 중재자패턴은 양방향으로 데이터를 전달할 수 있다는 것이 차이점이다. --- 예시 코드 java @Getter @Setter public abstract class Colleague { protected String name; private Mediator mediator; private String message; public Collea

책임연쇄 패턴

책임 연쇄 패턴은 객체를 연결리스트와 같은 사슬 방식으로 연결한 후에 요청을 수행하지 못하는 객체인 경우 책임을 다음 객체에 넘기며 책임을 넘기는 형태의 패턴을 말한다. 각각의 체인은 자신이 해야하는 일만 담당하기 때문에 집합 내의 처리 순서를 변경하거나 처리객체를 유연하게 추가 또는 삭제할 수 있다. --- 예시 코드 java @AllArgsConstructor public class RequestHandler { private RequestHandler nextHandler; public void handle(Request request) { if (nextHandler != null){ nextHandler.handle(request

커맨드 패턴

커맨드 패턴은 요청을 객체의 형태로 캡슐화하여 사용자가 보낸 요청을 나중에 이용할 수 있도록 매서드 이름, 매개변수 등 요청에 필요한 정보를 저장 또는 로깅, 취소할 수 있게 하는 패턴이다. 어떤 로직에 대한 요청을 객체화 시킴으로써, 코드를 수정하거나 교체하기 쉽게 하고, 유지보수성을 높인다. --- 예시 코드 java @Setter @AllArgsConstructor public class Lamp { private boolean power; public boolean isOn(){ return power; } } @Setter @AllArgsConstructor public class AirConditioner { private boole

템플릿메소드 패턴

템플릿 메소드 패턴은 동작 상의 알고리즘의 프로그램 뼈대를 정의하는 행위 디자인 패턴이다. 템플릿 메소드 패턴은 여러 작업들이 동일한 구조를 갖지만, 일부 동작은 각각 다르게 구현해야할 때 사용된다. 템플릿 메소드 패턴은 전체 실행과정을 구현한 상위 클래스(추상 클래스)와 실행 과정의 일부 단계를 구현한 하위 클래스(구체클래스)로 나뉘며, 추상 메서드를 재정의함으로써 알고리즘의 구조를 변경하지 않고 알고리즘의 특정 단계들을 다시 정의할 수 있게 해준다 --- 예시 코드 java public abstract class Human { abstract void Introducing(); void eating() { System.out.println("밥먹기"

디자인패턴

디자인패턴

디자인 패턴이란 프로그래밍을 할 때에 공통적으로 생기는 문제를 해결하고자 설계한 일정한 코드의 패턴이다. 애플리케이션이나 시스템을 디자인하는 과정에서 자주 발생하는 문제를 해결하는데에 쓰이는 형식화 된 관행이자, 재사용 가능한 해결책이기도 하다. GoF 디자인 패턴 종류 디자인 패턴에 대해 다루는 유명한 책 중 하나인 'GoF의 디자인 패턴'에서 다룬 디자인 패턴의 종류는 다음과 같다. 1. 생성 패턴 (Credential Patterns) 객체 생성과 관련된 패턴이다. 객체의 생성과 조합을 캠슐화하여 특정 객체가 생성되거나 변경되어도 프로그램 구조에 크게 영향을 받지 않도록 유연하게 설계하는 것이 목적이다. 싱글톤(Singleton) 패턴 클래스의 인스턴스를 오직 한개만 생성하여 제공

위임 패턴(Delegate Pattern)

디자인패턴

소프트웨어 엔지니어링에서 delegate pattern(위임 패턴)은 객체 합성이 상속과 동일하게 코드 재사용을 할 수 있도록 하는 객체 지향 디자인 패턴이다. 상속(inheritance) vs 합성(composition) 객체지향 시스템에서 기능의 재사용을 위해 구사하는 가장 대표적인 기법은 클래스 상속, 그리고 객체 합성(object composition)이다. 클래스 상속 서브클래싱, 즉 다른 부모 클래스에서 상속받아 한 클래스의 구현을 정의하는 것. 서브클래싱에 의한 재사용을 화이트박스 재사용(white-box reuse)이라고 한다. '화이트박스’는 내부를 볼 수 있다는 의미에서 나온 말로, 상속을 받으면 부모 클래스의 내부가 서브클래스에 공개되기 때문에 화이트박스인 셈이다. 상속의 장