개발자의 끄적거림

[Docker] Docker 완벽 정리

끄적잉 — Tue, 10 Feb 2026 22:55:46 +0900

내 컴퓨터에선 됐는데 왜 서버에선 안 될까? (도커 입문 가이드)

안녕하세요! 오늘은 개발자라면 누구나 한 번쯤 겪어봤을, 아니 어쩌면 지금 이 순간에도 여러분의 뒷목을 잡게 만들고 있을 그 주제에 대해 이야기해보려 합니다. 바로 **도커(Docker)**입니다.

우리가 개발을 하다 보면 가장 많이 하는 거짓말(?) 중 하나가 뭔지 아세요? 바로 이겁니다.

"어? 내 컴퓨터에선 분명히 잘 됐는데요?"

분명 내 로컬 환경(맥북, 윈도우)에서는 쌩쌩 돌아가던 코드가, 배포 서버에만 올라가면 에러를 뿜어냅니다. 자바 버전이 다르다느니, 환경 변수가 안 잡혔다느니, 리눅스 패키지 뭐가 없다느니... 이런 '환경 지옥'에서 우리를 구원해 줄 고래 한 마리, 지금부터 제대로 파헤쳐 보겠습니다.

1. 도커는 왜 태어났을까? (환경 지옥의 종말)

우리가 흔히 겪는 문제를 떠올려봅시다. 새로 합류한 팀원에게 개발 환경을 세팅해줘야 할 때, 우리는 보통 이런 가이드를 줍니다.

"자바 17 깔으시고요."
"환경 변수 JAVA_HOME 잡으세요."
"아, 아나콘다 쓰시나요? 그럼 가상환경부터 만드시고..."
"DB는 포스트그레스(Postgres) 13버전인데, 설정 파일은 제가 카톡으로 보내드릴게요."

이 과정에서 꼭 한두 명은 "저 에러 나는데요?"라고 말하죠. 운영체제마다 파일 경로가 다르고, 이미 설치된 다른 소프트웨어와 충돌이 나기 때문입니다.

도커는 여기서 **"그냥 내가 돌아가는 환경을 통째로 박스에 담아서 줄게!"**라는 기발한 생각을 합니다. 이 박스 안에는 코드뿐만 아니라 운영체제 핵심 기능, 라이브러리, 설정값까지 싹 다 들어있습니다. 이 박스만 있으면 윈도우든 리눅스든 맥이든, 어디서든 똑같이 실행됩니다. 이게 바로 도커의 본질입니다.

2. 가상 머신(VM)과 도커, 뭐가 다른데?

보통 도커를 처음 배우면 "어, 그럼 VMware나 VirtualBox 같은 가상 머신이랑 똑같은 거 아니야?"라고 묻습니다. 결론부터 말씀드리면 **"비슷하지만 훨씬 가볍고 빠르다"**입니다.

이해를 돕기 위해 아파트와 고시원 비유를 들어볼게요.

가상 머신 (Virtual Machine): 아파트를 한 채 통째로 짓는 것입니다. 집마다 전용 현관문, 부엌, 화장실, 배관이 다 따로 있죠. 안전하고 독립적이지만, 짓는 데 오래 걸리고 자원(땅)을 많이 차지합니다. OS 위에 또 OS를 올리는 격이라 굉장히 무겁습니다.
도커 컨테이너 (Docker Container): 이미 지어진 건물에 방만 빌리는 방식입니다. 수도나 전기는 같이 쓰되(OS 커널 공유), 내 방 안에서는 내가 뭘 하든 간섭받지 않습니다. 방만 꾸미면 되니까 만드는 속도가 엄청나게 빠르고, 아파트 한 채 지을 자원에 방 수십 개를 만들 수 있습니다.

실제로 VM은 부팅하는 데 몇 분씩 걸리지만, 도커 컨테이너는 실행 명령을 내리는 즉시 1초 만에 뜹니다. 개발자에게 이 '속도'는 엄청난 축복이죠.

3. 도커의 핵심 삼인방: Dockerfile, Image, Container

도커를 공부하다 보면 이 세 단어가 계속 나올 텐데요. 요리 과정에 비유하면 뇌에 박제할 수 있습니다.

① Dockerfile (레시피)

"라면을 끓이려면 물 500ml를 넣고, 스프를 먼저 넣고, 면을 넣어라"라고 적힌 텍스트 파일입니다.

FROM python:3.9 (파이썬 3.9 환경에서 시작해!)
COPY . /app (내 소스 코드를 복사해 넣어!)
CMD ["python", "main.py"] (이걸 실행해!) 이렇게 명령어를 적어두는 설계도입니다.

② Image (밀키트)

설계도(레시피)를 바탕으로 실제 요리 재료들을 다 모아서 얼려놓은 밀키트입니다. 이 밀키트는 변하지 않습니다(Immutable). 누가 사 가든, 어디서 뜯든 그 안의 재료는 항상 똑같죠. 이미지는 실행되기 전의 '상태'를 의미합니다.

③ Container (완성된 요리)

밀키트를 뜯어서 냄비에 끓인 상태입니다. 실제로 서비스가 돌아가고 있는 실체죠. 우리는 하나의 밀키트(이미지)로 수십 개의 요리(컨테이너)를 동시에 만들어낼 수 있습니다. 배달 주문이 밀리면(트래픽이 늘어나면) 냄비 수만 늘리면 되는 거죠.

4. 개발자가 도커를 쓰면 얻는 개이득(Advantage) 3가지

첫째, "Clean & Clear" 내 컴퓨터가 깨끗해집니다.

예전에는 새로운 프로젝트를 할 때마다 온갖 DB와 라이브러리를 내 컴퓨터에 직접 깔았습니다. 프로젝트가 끝나도 지우기 귀찮아서 방치하다 보면 어느새 내 맥북은 쓰레기장이 되죠. 도커를 쓰면? 컨테이너만 지우면 끝입니다. 내 컴퓨터 본체는 언제나 쾌적합니다.

둘째, 협업 효율의 극대화

"저기, 제 컴퓨터에선 되는데..."라는 말을 원천 봉쇄합니다. 모든 팀원이 동일한 이미지를 내려받아 실행하기 때문에, "환경 설정 때문에 하루 버렸어요"라는 핑계가 사라집니다. (이건 좀 슬픈 일일 수도 있겠네요...)

셋째, 배포의 혁명

로컬에서 테스트 완료한 이미지를 그대로 서버에 올리기만 하면 됩니다. "서버 가니까 라이브러리 버전이 다르네?" 같은 공포스러운 상황에서 해방됩니다. CI/CD 파이프라인의 핵심이 바로 이 도커입니다.

5. 마치며: 고래 등에 올라타는 것을 두려워하지 마세요

처음엔 터미널에 명령어를 치는 게 낯설고, 네트워크 설정이나 볼륨 마운트 같은 개념이 어렵게 느껴질 수 있습니다. 하지만 한 번 익숙해지고 나면, 도커 없는 개발 인생으로는 절대 돌아갈 수 없을 겁니다.

마치 피처폰을 쓰다가 스마트폰을 처음 썼을 때의 충격 같달까요? 여러분의 소중한 코드가 어떤 환경에서도 당당하게 돌아갈 수 있도록, 오늘 당장 docker run 한 번 쳐보시는 건 어떨까요?

외부망없이 드라이버 설치 방법 총정리

끄적잉 — Wed, 27 Aug 2025 20:57:17 +0900

✅ 외부망 없이 노트북 드라이버 설치하는 방법

1. 설치가 필요한 드라이버 파악

먼저 어떤 드라이버가 필요한지 확인해야 합니다.

필요한 드라이버 예시:
- 그래픽 카드 드라이버
- 사운드 드라이버
- LAN/Wi-Fi 드라이버
- 칩셋 드라이버
- 터치패드/기타 장치 드라이버
방법:
1. 노트북을 켜고 장치 관리자를 실행 (Win + X → 장치 관리자)
2. 노란 느낌표가 있는 장치를 확인
3. 장치 이름을 메모하거나, 하드웨어 ID로 검색

2. 드라이버 설치 파일 준비 (인터넷 연결 가능한 다른 PC에서)

인터넷이 되는 다른 PC나 노트북에서 해당 드라이버 설치 파일을 다운로드합니다.

✅ 방법 A: 제조사 공식 홈페이지 이용

다른 PC에서 노트북 제조사 홈페이지 접속
제품 모델명을 입력하여 검색
드라이버 및 유틸리티 다운로드 항목에서 필요한 드라이버들을 다운로드

예시:

Lenovo: https://support.lenovo.com

HP: https://support.hp.com

Dell: https://www.dell.com/support

ASUS: https://www.asus.com/support

✅ 방법 B: 드라이버 백업 (이미 설치된 동일 모델 노트북이 있을 때)

Double Driver 또는 DriverBackup! 같은 프로그램을 이용해, 동일 모델 노트북에서 드라이버를 백업해 복사할 수 있습니다.

3. 설치 파일을 오프라인 노트북으로 복사

복사 방법:

USB 메모리
외장 하드
SD 카드 등

⚠️ 바이러스가 없도록 사전에 USB를 검사하세요.

4. 노트북에 드라이버 설치

USB 또는 저장장치를 오프라인 노트북에 연결
복사한 드라이버 설치 파일 실행 (.exe 파일이면 직접 실행, .inf 파일이면 오른쪽 클릭 → 설치)
필요한 경우 재부팅

5. 자동 드라이버 설치 프로그램 사용 (선택사항)

오프라인에서도 사용 가능한 드라이버 패키지를 준비할 수 있습니다.

✅ 추천 오프라인 드라이버 패키지:

Snappy Driver Installer Origin (SDIO):
- 공식 사이트: https://www.snappy-driver-installer.org/
- “Full” 버전을 다른 PC에서 받아 USB에 넣으면 오프라인으로 설치 가능

장점: 모든 드라이버를 한 번에 검색 및 설치 가능

Map, HashMap, TreeMap 완벽 정리

끄적잉 — Tue, 5 Aug 2025 14:17:39 +0900

1. Map (인터페이스)

가장 먼저 이해해야 할 것은 Map이 인터페이스(Interface)라는 점입니다. 자바 컬렉션 프레임워크에서 Map은 **키(key)**와 **값(value)**을 한 쌍으로 묶어 저장하는 데이터 구조의 규약(청사진)을 정의합니다. Map 자체는 객체로 생성할 수 없으며, 이 인터페이스를 구현하는 구체적인 클래스들(예: HashMap, TreeMap, LinkedHashMap)을 통해 기능을 사용할 수 있습니다.

핵심 특징:

키(Key)의 고유성: 모든 키는 유일해야 합니다. 동일한 키로 값을 추가하면 기존의 값은 새로운 값으로 덮어쓰여집니다.
키-값 쌍: 키를 통해 값에 빠르게 접근할 수 있습니다. 마치 사전에서 단어를 찾아 그 의미를 확인하는 것과 같습니다.
순서 없음: Map 인터페이스 자체는 요소의 순서를 보장하지 않습니다. (TreeMap은 예외적으로 정렬된 순서를 가집니다.)
null 허용: 대부분의 구현체는 키나 값에 null을 허용합니다. (단, TreeMap은 키에 null을 허용하지 않습니다.)

Map 인터페이스가 제공하는 주요 메서드는 다음과 같습니다.

put(key, value): 키와 값을 저장합니다.
get(key): 주어진 키에 해당하는 값을 반환합니다.
remove(key): 키에 해당하는 키-값 쌍을 삭제합니다.
containsKey(key): 해당 키가 존재하는지 확인합니다.
keySet(): Map에 있는 모든 키들을 Set 형태로 반환합니다.
entrySet(): Map에 있는 모든 키-값 쌍(Entry)을 Set 형태로 반환합니다.

Map은 키를 사용하여 데이터를 조회하는 작업이 빈번할 때 매우 효율적입니다.

2. HashMap (빠른 비정렬 맵)

HashMap은 Map 인터페이스의 가장 대표적인 구현체입니다. 키를 기반으로 데이터를 빠르게 탐색해야 할 때 사용되며, 내부적으로 해시 테이블(Hash Table) 자료구조를 사용합니다.

내부 동작 원리:

HashMap은 키에 대해 **해시 함수(Hash Function)**를 적용하여 해시 코드를 생성하고, 이 해시 코드를 통해 배열의 인덱스(버킷)를 결정합니다.

키-값 저장 시: put(key, value)를 호출하면, 먼저 키의 hashCode() 메서드를 호출하여 해시 코드를 얻습니다. 이 해시 코드를 배열의 크기에 맞게 가공하여 인덱스를 계산하고, 해당 인덱스에 키-값 쌍을 저장합니다.
충돌(Collision) 처리: 여러 개의 키가 동일한 인덱스로 매핑되는 해시 충돌이 발생할 수 있습니다. HashMap은 이를 해결하기 위해 각 배열 인덱스에 연결 리스트(Linked List)나 트리(Tree)를 사용하여 충돌을 처리합니다.
키-값 조회 시: get(key)를 호출하면, 저장할 때와 마찬가지로 키의 hashCode()를 통해 인덱스를 찾습니다. 해당 인덱스에 저장된 요소들 중에서 equals() 메서드를 이용해 찾는 키와 동일한 요소를 찾아 반환합니다.

주요 특징:

성능: 평균적으로 put, get, remove 연산의 시간 복잡도는 O(1) 입니다. 해시 함수가 키를 고르게 분산시킬 경우 매우 빠릅니다. 최악의 경우(모든 키가 동일한 해시 코드를 가질 경우)는 O(n)까지 느려질 수 있지만, 일반적으로는 발생하지 않습니다.
순서 없음: HashMap은 저장된 순서를 보장하지 않으며, 정렬되어 있지도 않습니다.
null 허용: 하나의 null 키와 여러 개의 null 값을 가질 수 있습니다.
동기화: 스레드에 안전하지 않습니다(Non-Synchronized). 멀티스레드 환경에서 사용하려면 Collections.synchronizedMap()을 사용하거나, ConcurrentHashMap을 사용해야 합니다.

HashMap은 데이터의 삽입, 삭제, 조회가 가장 빠른 맵으로, 일반적인 용도에서 가장 많이 사용됩니다.

3. TreeMap (정렬된 맵)

TreeMap은 Map 인터페이스를 구현하며, 데이터를 키를 기준으로 정렬하여 저장합니다. 내부적으로는 **레드-블랙 트리(Red-Black Tree)**라는 균형 이진 탐색 트리를 사용합니다.

내부 동작 원리:

TreeMap은 키-값 쌍을 트리에 저장하며, 새로운 요소가 추가될 때마다 트리의 균형을 유지하고 정렬된 상태를 만듭니다.

정렬 기준: 키의 자연적 순서(Natural Ordering) 또는 생성 시 제공된 **Comparator**에 따라 정렬됩니다. Integer, String 같은 기본 클래스는 자연적 순서가 정의되어 있습니다.
탐색: 트리의 루트 노드에서 시작하여 키를 비교하며 내려가기 때문에, 삽입, 삭제, 검색에 일정한 성능을 보장합니다.

주요 특징:

성능: put, get, remove 연산의 시간 복잡도는 항상 O(log n) 입니다. HashMap의 평균적인 성능(O(1))보다는 느리지만, HashMap의 최악의 경우(O(n))보다는 빠르고 안정적입니다.
순서 보장: 키를 기준으로 오름차순으로 정렬된 상태를 항상 유지합니다.
null 키 불가능: 키를 비교해야 하므로 null 키는 허용하지 않습니다. null 값은 허용합니다.
동기화: HashMap과 마찬가지로 스레드에 안전하지 않습니다(Non-Synchronized).

TreeMap은 키의 순서

가 중요하거나, 정렬된 데이터를 반복적으로 조회해야 할 때 유용합니다. 예를 들어, 특정 범위 내의 키-값 쌍을 찾거나(subMap), 최소/최대 키를 찾는 등의 작업에 적합합니다.

4. 핵심 비교 및 요약

구분	HashMap	TreeMap
내부 자료구조	해시 테이블(Hash Table)	레드-블랙 트리(Red-Black Tree)
성능 (시간 복잡도)	삽입, 삭제, 검색 평균 O(1)	삽입, 삭제, 검색 O(log n)
데이터 순서	보장하지 않음 (무작위)	키를 기준으로 오름차순 정렬
null 키 허용	허용 (단, 1개만)	허용하지 않음
주요 활용 사례	- 순서가 중요하지 않은 일반적인 맵 <br> - 빠른 조회/삽입/삭제가 필요한 경우	- 키의 순서가 중요한 경우 <br> - 정렬된 데이터를 반복적으로 조회해야 할 때 <br> - 범위 검색(range search)이 필요한 경우
장점	- 가장 빠른 성능 <br> - 범용적으로 사용 가능	- 항상 정렬된 상태 유지 <br> - 예측 가능한 안정적인 성능
단점	- 순서가 없어 순차 접근 시 비효율적 <br> - 해시 충돌 시 성능 저하 가능성	- HashMap보다 느림 <br> - 메모리 사용량이 상대적으로 많음

5. 결론: 언제 무엇을 사용해야 하는가?

HashMap을 사용하세요: 대부분의 경우 HashMap이 가장 좋은 선택입니다. 데이터의 순서가 중요하지 않고, 가장 빠른 데이터 접근 및 조작 성능이 필요할 때 사용합니다.
TreeMap을 사용하세요: 키를 기준으로 정렬된 상태로 데이터를 유지해야 할 필요가 있거나, 키를 기준으로 범위 검색(예: "100~200번 키에 해당하는 데이터")을 해야 할 때 사용합니다.

.xfdl 파일이란? (넥사크로 파일이란?)

끄적잉 — Wed, 30 Jul 2025 15:09:09 +0900

.xfdl 파일은 주로 **넥사크로플랫폼(nexacro platform)**에서 사용되는 UI(사용자 인터페이스) 정의 파일입니다. 넥사크로플랫폼은 투비소프트(TOBESOFT)에서 개발한 RIA(Rich Internet Application) 개발 도구이자 프레임워크입니다.

.xfdl 파일의 특징 및 역할

UI/UX 화면 정의:
- .xfdl 파일은 넥사크로플랫폼에서 사용자에게 보여지는 화면의 레이아웃, 컴포넌트(버튼, 그리드, 텍스트박스, 콤보박스 등), 그리고 이 컴포넌트들의 속성(크기, 위치, 색상, 글꼴 등)을 정의하는 XML 기반의 파일입니다.
- 비주얼 스튜디오(Visual Studio)나 이클립스(Eclipse) 같은 IDE에서 GUI(Graphical User Interface) 기반의 넥사크로 스튜디오(nexacro studio)를 사용하여 화면을 디자인하면, 그 결과물이 .xfdl 파일로 저장됩니다.
XML 기반 구조:
- 파일 내용은 XML(eXtensible Markup Language) 형식으로 작성되어 있습니다. 따라서 텍스트 편집기로도 열어볼 수 있지만, 사람이 직접 편집하기보다는 넥사크로 스튜디오를 통해 시각적으로 편집하는 것이 일반적입니다.
- XML 태그와 속성을 통해 각 컴포넌트의 종류, 이름, 위치, 크기, 이벤트 핸들러 연결 등을 명시합니다.
데이터 바인딩 및 이벤트 처리 정의:
- .xfdl 파일 내에서는 화면 컴포넌트와 데이터셋(Dataset) 간의 데이터 바인딩 정보도 정의할 수 있습니다. 예를 들어, 그리드 컴포넌트가 어떤 데이터셋의 데이터를 표시할지, 특정 입력 필드가 어떤 데이터셋의 특정 컬럼과 연결될지 등을 설정합니다.
- 버튼 클릭 시, 데이터 변경 시 등과 같은 **이벤트 처리 로직(스크립트)**도 .xfdl 파일 내에 또는 별도의 .js 파일로 연결하여 정의됩니다. (주로 JavaScript를 사용)
클라이언트 런타임 환경:
- 넥사크로플랫폼으로 개발된 애플리케이션은 웹(HTML5), 데스크톱(넥사크로 런타임), 모바일(앱) 등 다양한 환경에서 실행될 수 있습니다. .xfdl 파일은 이 런타임 환경에서 화면을 구성하고 동작을 제어하는 데 사용되는 핵심 자원입니다.
- 사용자가 넥사크로 애플리케이션에 접속하면 서버로부터 .xfdl 파일을 다운로드하여 클라이언트 런타임 엔진이 이를 해석하고 화면을 구성하게 됩니다.
다국어 지원 및 확장성:
- .xfdl 파일은 다국어 처리를 위한 리소스 관리 기능도 포함할 수 있으며, 개발자가 직접 정의한 사용자 정의 컴포넌트나 라이브러리를 포함하여 확장성을 가집니다.

넥사크로플랫폼과 .xfdl 파일의 역할

넥사크로플랫폼은 "One Source Multi Use"를 지향하며, 하나의 소스 코드(여기서 .xfdl 파일 및 관련 스크립트)로 웹, 모바일, 데스크톱 환경에 대응하는 애플리케이션을 개발할 수 있도록 합니다. .xfdl 파일은 이러한 유연한 아키텍처의 중심에 있습니다.

간단히 요약하면:

무엇인가? 넥사크로플랫폼에서 사용하는 XML 기반의 UI 화면 정의 파일.
어떤 내용을 담고 있는가? 화면 레이아웃, 컴포넌트 정보, 데이터 바인딩, 이벤트 스크립트 등.
왜 사용하는가? 넥사크로 스튜디오를 통해 시각적으로 빠르게 UI를 디자인하고, One Source Multi Use 환경에서 다양한 플랫폼에 대응하는 애플리케이션을 구축하기 위함.

만약 넥사크로플랫폼 개발 환경에 계신다면, 이 .xfdl 파일을 통해 화면을 구현하고 백엔드와 연동하는 작업을 하실 것입니다.

리덕스란? (Redux 완벽 정리)

끄적잉 — Wed, 30 Jul 2025 09:54:46 +0900

리덕스란!???

웹 개발의 세계는 끊임없이 진화하고 있으며, 특히 사용자 인터랙션이 많아지고 데이터 흐름이 복잡해지는 현대 웹 애플리케이션에서는 '상태 관리(State Management)' 가 개발의 성패를 좌우하는 핵심 요소가 되었습니다. 오늘 이 블로그 포스팅에서는 React와 같은 프런트엔드 라이브러리/프레임워크와 환상의 궁합을 자랑하며, 전역 상태 관리에 있어 독보적인 위치를 차지하고 있는 라이브러리, Redux에 대해 깊이 있게 알아보겠습니다.

단순히 사용법을 나열하는 것을 넘어, Redux가 왜 필요하고 어떤 철학을 가지고 있으며, 여러분의 애플리케이션에 어떻게 강력한 힘을 실어줄 수 있는지 자세히 파헤쳐 보겠습니다. 이 글을 통해 Redux의 본질을 이해하고, 여러분의 다음 프로젝트에 자신 있게 적용할 수 있기를 바랍니다.

1. Redux, 왜 필요한가요? - 상태 관리의 복잡성

모던 웹 애플리케이션은 사용자 로그인 상태, 장바구니 품목, UI 테마, 데이터 로딩 상태 등 다양한 종류의 '상태'를 가집니다. 애플리케이션의 규모가 커지고 컴포넌트 간의 관계가 복잡해질수록 다음과 같은 문제가 발생합니다.

컴포넌트 간의 상태 공유 어려움 (Prop Drilling): 상위 컴포넌트에서 하위 컴포넌트로 상태를 전달하기 위해 여러 단계를 거쳐 Props를 '드릴'처럼 뚫고 내려가야 합니다. 이는 코드를 읽기 어렵게 만들고 유지보수를 힘들게 합니다.
예측 불가능한 상태 변화: 여러 컴포넌트에서 동일한 상태를 변경할 수 있게 되면, 어떤 컴포넌트가 언제 어떻게 상태를 변경했는지 추적하기 어려워집니다. 이는 버그 발생의 주원인이 됩니다.
디버깅의 어려움: 상태가 여기저기 흩어져 있거나 비동기적으로 복잡하게 변경되면, 버그 발생 시 문제의 원인을 찾아내기가 매우 어려워집니다.

Redux는 이러한 문제들을 해결하기 위해 탄생했습니다. 애플리케이션의 모든 상태를 예측 가능하고 일관된 방식으로 관리하는 단일 저장소(Store)를 제공하는 것이 핵심입니다.

2. Redux의 세 가지 핵심 원칙 (Principles)

Redux는 세 가지 매우 중요한 원칙을 기반으로 합니다. 이 원칙들을 이해하는 것이 Redux를 제대로 활용하는 첫걸음입니다.

단일 진실 공급원 (Single Source of Truth):
- 애플리케이션의 모든 상태는 하나의 커다란 자바스크립트 객체 트리 형태로 하나의 Store 안에 저장됩니다.
- 마치 은행에 하나의 중앙 데이터베이스가 모든 고객의 잔액 정보를 관리하듯이, Redux는 애플리케이션의 모든 데이터를 한 곳에서 관리합니다. 이는 상태의 일관성과 예측 가능성을 극대화합니다.
상태는 읽기 전용이다 (State is Read-Only):
- 상태를 직접 변경할 수 없습니다. 상태를 변경하고 싶다면, 반드시 액션(Action) 이라는 일반 자바스크립트 객체를 통해 변경 의도를 표현해야 합니다.
- 마치 법률 시스템에서 모든 변경 요청이 공식적인 서류(액션)를 통해 이루어지는 것처럼, Redux의 상태 변경은 투명하고 기록 가능합니다. 이는 어떤 변경이 왜 일어났는지 추적하기 쉽게 만듭니다.
변화는 리듀서에 의해 이루어져야 한다 (Changes are Made with Pure Functions / Reducers):
- 액션에 의해 상태가 어떻게 변경될지는 리듀서(Reducer) 라는 순수 함수(Pure Function) 에 의해 정의됩니다.
- 순수 함수란:
  - 동일한 입력(State와 Action)에는 항상 동일한 출력(새로운 State)을 반환합니다.
  - 함수 외부의 어떤 것도 변경하지 않습니다 (Side Effect 없음).
- 리듀서는 현재 상태와 액션을 받아서, 새로운 상태를 반환합니다. 이 과정에서 기존 상태를 직접 변경(Mutation)하지 않고, 항상 새로운 상태 객체를 생성하여 반환해야 합니다.
- 이는 예측 가능한 상태 변화를 보장하고, 디버깅을 용이하게 하며, 시간 여행 디버깅(Time-Travel Debugging)과 같은 강력한 도구를 가능하게 합니다.

3. Redux의 주요 구성 요소 (Core Components)

Redux는 몇 가지 핵심적인 구성 요소들이 유기적으로 연결되어 동작합니다.

Store (스토어):
- Redux의 핵심이자 모든 상태를 담고 있는 단 하나의 객체입니다.
- 상태를 저장하고, 상태를 업데이트하며, 상태 변경을 구독(Subscribe)할 수 있는 메서드를 제공합니다.
Action (액션):
- 상태 변경을 위한 "무엇이 일어났는지"를 설명하는 객체입니다.
- 필수적으로 type 속성을 가져야 하며, 이 type은 어떤 종류의 액션인지 문자열로 정의합니다. (예: { type: 'ADD_TODO', text: 'Learn Redux' })
- 액션은 상태를 직접 변경하지 않고, 단지 변경 "의도"만을 전달합니다.
Reducer (리듀서):
- 액션을 받아서 "상태를 어떻게 변경할지"를 정의하는 순수 함수입니다.
- (previousState, action) => newState 형태를 가집니다.
- 이전 상태와 액션을 인자로 받아 새로운 상태를 반환합니다. 절대 이전 상태를 직접 변경해서는 안 됩니다.
Dispatcher (디스패처 - Store의 메서드):
- store.dispatch(action) 메서드를 통해 액션을 Redux Store로 보내는(전달하는) 역할을 합니다.
- 이 메서드가 호출되면, Redux는 해당 액션을 모든 리듀서에게 전달하여 상태를 업데이트합니다.
Selector (셀렉터):
- Store의 상태(State)에서 원하는 데이터를 추출하는 함수입니다.
- UI 컴포넌트가 Store에서 필요한 데이터만 효율적으로 가져올 수 있도록 돕습니다.

4. Redux의 동작 흐름 (Flow)

Redux의 데이터 흐름은 단방향(Unidirectional Data Flow)입니다. 이 일관된 흐름은 상태 변화를 예측 가능하게 만듭니다.

사용자 인터랙션 발생: UI(React 컴포넌트)에서 사용자의 클릭, 입력 등 어떤 이벤트가 발생합니다.
Action Dispatch: 이벤트 핸들러는 store.dispatch(action) 메서드를 호출하여 상태 변경을 위한 Action 객체를 Store로 보냅니다.
Reducer 호출: Store는 전달받은 Action을 모든 Reducer 함수에게 전달합니다. (실제로는 Root Reducer에게 전달되고, Root Reducer가 하위 Reducer들에게 전달합니다.)
State 변경: Reducer는 현재 상태와 Action을 기반으로 새로운 상태 객체를 생성하여 반환합니다. (기존 상태는 변경하지 않음)
Store 업데이트: Store는 Reducer가 반환한 새로운 상태로 자신의 상태를 업데이트합니다.
UI 렌더링: Store의 상태가 변경되면, Store를 구독(Subscribe)하고 있던 UI 컴포넌트들이 변경된 상태를 감지하고, 필요한 경우 새로운 데이터로 다시 렌더링됩니다.

이 흐름은 항상 동일하게 반복되며, 어떤 상태 변화든 이 흐름을 따라가기 때문에 디버깅이 매우 용이합니다.

5. Redux의 장점 (Advantages)

예측 가능한 상태 관리: 단일 진실 공급원, 읽기 전용 상태, 순수 리듀서라는 원칙 덕분에 상태 변화가 매우 예측 가능하며 일관적입니다.
쉬운 디버깅: 모든 상태 변화가 액션이라는 기록으로 남아 있기 때문에, Redux DevTools를 사용하면 상태 변화의 과정을 시간 여행하듯이 추적하고 재현할 수 있습니다. 이는 버그를 찾는 데 엄청난 도움이 됩니다.
중앙 집중식 상태: 모든 상태가 한 곳에 모여 있어 컴포넌트 간의 상태 공유가 매우 효율적입니다. Props Drilling 문제를 해결할 수 있습니다.
유지보수 용이성: 상태 변화 로직이 리듀서에 명확히 분리되어 있어, 코드의 가독성이 높아지고 유지보수가 용이해집니다.
서버 사이드 렌더링(SSR) 지원: 서버와 클라이언트 간의 상태 동기화를 쉽게 할 수 있어 SSR에 유리합니다.
강력한 미들웨어 생태계: 비동기 작업(API 호출 등)을 처리하기 위한 Redux Thunk, Redux Saga와 같은 미들웨어와, 로깅, 크래시 리포팅 등을 위한 다양한 미들웨어를 활용할 수 있습니다.

6. Redux의 단점 및 고려 사항 (Disadvantages & Considerations)

Redux는 만능이 아니며, 모든 프로젝트에 필수적인 것은 아닙니다.

보일러플레이트 코드 (Boilerplate Code): 특히 초기 설정 시 액션 타입, 액션 생성자, 리듀서 등 작성해야 할 코드가 많아 복잡하게 느껴질 수 있습니다. 이는 Redux Toolkit의 등장으로 많이 해소되었습니다.
학습 곡선: 초보 개발자에게는 Redux의 개념(액션, 리듀서, 미들웨어 등)과 단방향 데이터 흐름을 이해하는 데 시간이 필요할 수 있습니다.
과도한 사용: 작은 규모의 애플리케이션에서는 Redux를 도입하는 것이 오히려 복잡성을 증가시킬 수 있습니다. 컴포넌트 내부 상태(Local State)나 React Context API만으로도 충분한 경우가 많습니다.
성능 최적화: 상태가 변경될 때마다 관련 컴포넌트가 다시 렌더링될 수 있으므로, React.memo, useCallback, useMemo 등을 활용한 렌더링 최적화에 신경 써야 합니다. (물론 React 자체의 문제입니다.)

7. Redux Toolkit: Redux 개발을 더 쉽고 효율적으로!

Redux의 보일러플레이트와 복잡성 문제를 해결하기 위해 공식적으로 권장되는 도구 모음이 바로 Redux Toolkit (RTK) 입니다. RTK는 다음과 같은 주요 기능들을 제공하여 Redux 개발 경험을 획기적으로 개선합니다.

configureStore: Redux Store를 쉽게 설정할 수 있으며, Redux Thunk와 Redux DevTools Extension이 기본으로 포함됩니다.
createSlice: 액션 타입, 액션 생성자, 리듀서를 한 번에 정의할 수 있게 해주는 함수입니다. 이를 통해 보일러플레이트 코드를 대폭 줄일 수 있습니다. (상태를 '슬라이스' 단위로 관리)
createAsyncThunk: 비동기 로직(API 호출 등)을 쉽게 처리할 수 있는 액션 생성자를 생성합니다.
createEntityAdapter: 정규화된 상태를 관리할 때 유용합니다.

Redux를 새로 시작하거나 기존 프로젝트에 도입한다면, 반드시 Redux Toolkit을 사용하는 것을 강력히 권장합니다.

마무리하며

Redux는 복잡한 웹 애플리케이션의 상태 관리를 위한 매우 강력하고 성숙한 라이브러리입니다. 그 예측 가능한 단방향 데이터 흐름과 단일 진실 공급원이라는 철학은 대규모 프로젝트에서 빛을 발하며, 효율적인 디버깅과 유지보수를 가능하게 합니다.

물론, Redux가 모든 프로젝트의 만병통치약은 아니며, 작은 규모의 애플리케이션에서는 과도한 오버헤드일 수 있습니다. 하지만 여러분의 애플리케이션이 성장하고 상태 관리가 점점 더 복잡해진다면, Redux는 여러분에게 질서와 통제력을 제공하는 든든한 아군이 될 것입니다.

FIDO 인증이란? (FIDO 완벽 정리)

끄적잉 — Mon, 28 Jul 2025 17:25:27 +0900

## FIDO 인증에 대한 심층 분석: 비밀번호 없는 강력하고 편리한 인증의 미래

### 1. 서론: FIDO의 등장 배경과 미션

오늘날 디지털 세상에서 우리는 수많은 온라인 서비스에 접근하기 위해 비밀번호를 사용하고 있습니다. 그러나 비밀번호는 **피싱(Phishing), 자격 증명 스터핑(Credential Stuffing), 무작위 대입 공격(Brute-force Attacks), 재사용(Reuse) 및 대규모 데이터 유출(Data Breaches)** 등 다양한 보안 위협에 끊임없이 노출되어 있습니다. 사용자들은 너무 많은 비밀번호를 기억해야 하는 부담과 함께, 복잡한 비밀번호를 만들어야 하는 스트레스, 그리고 주기적인 비밀번호 변경 요구에 시달리고 있습니다.

이러한 문제들을 해결하기 위해 **FIDO (Fast IDentity Online) Alliance**라는 글로벌 산업 협회가 등장했습니다. FIDO의 핵심 미션은 **비밀번호 없는(passwordless)**, 더 **강력하고(stronger)**, 더 **간단한(simpler)** 인증 방식을 제공하여 온라인 보안과 사용자 경험을 혁신하는 것입니다. FIDO 인증은 전통적인 비밀번호 기반의 인증 모델을 공개키 암호 방식(Public-key Cryptography) 기반의 혁신적인 프로토콜로 대체합니다.

### 2. FIDO Alliance와 그 목표

FIDO Alliance는 2013년에 설립된 비영리 산업 협회로, 전 세계 수백 개의 기술, 금융, 보안, 통신 기업들이 참여하고 있습니다. 이들은 공통의 오픈 표준을 개발하고 전파하여 강력한 인증을 위한 상호 운용 가능한 기술 스택을 구축하는 것을 목표로 합니다.

FIDO Alliance의 주요 목표는 다음과 같습니다:
* **강력한 인증:** 피싱, 중간자 공격(Man-in-the-Middle), 재전송 공격에 매우 강한 인증 방식을 제공합니다.
* **간단한 사용자 경험:** 비밀번호 없이 빠르고 직관적인 인증 절차를 제공합니다.
* **프라이버시 보호:** 사용자 생체 정보가 기기 외부로 유출되거나 서버에 저장되지 않도록 보장합니다.
* **상호 운용성:** 다양한 기기, 플랫폼, 서비스 간에 인증 기술이 호환되도록 표준화합니다.

### 3. FIDO 인증의 핵심 원리 및 철학

FIDO 인증은 기존 비밀번호 인증과 근본적으로 다른 원리를 가집니다.

* **비밀번호 없는 인증 (Passwordless):** FIDO는 사용자가 비밀번호를 입력하는 대신, 기기 내에서 사용자의 신원을 로컬로 확인(예: 지문, 얼굴 인식, PIN 입력)하고, 이를 바탕으로 암호화된 인증 정보를 생성하여 서버에 보냅니다. 서버는 비밀번호를 저장하거나 검증할 필요가 없습니다.
* **공개키 암호 방식 (Public-key Cryptography):** FIDO 인증의 핵심은 공개키 암호 방식입니다. 각 사용자 계정마다 고유한 암호화 키 쌍(개인키/공개키)이 생성됩니다. 개인키는 사용자 기기에 안전하게 보관되고, 공개키만 서버에 등록됩니다.
* **로컬 인증 (Local Authentication):** 사용자는 자신의 기기(스마트폰, PC)에 내장된 생체 인식 센서(지문 인식기, 얼굴 인식 카메라)나 PIN/패턴 입력과 같은 익숙한 방식으로 본인임을 인증합니다. 이 인증은 기기 내부에서만 이루어지며, 사용자의 생체 정보는 절대 기기 외부로 전송되거나 서버에 저장되지 않습니다.
* **피싱 저항성 (Phishing Resistance):** FIDO는 인증 정보를 특정 웹사이트의 도메인(Origin)에 묶어둡니다. 즉, A 사이트용으로 생성된 인증 정보는 B 사이트에서는 사용할 수 없습니다. 이로 인해 사용자가 피싱 사이트에 속아 인증 정보를 입력하더라도, 해커는 그 정보를 진짜 사이트에서 사용할 수 없어 피싱 공격이 원천적으로 차단됩니다.
* **개인정보 보호:** 사용자의 생체 정보는 기기 내의 보안 영역(Secure Enclave, TEE/Trusted Execution Environment)에서만 처리되고, 기기를 떠나지 않습니다. 서버는 생체 정보를 알 수 없으며, 단지 사용자가 올바르게 인증했음을 증명하는 암호화된 서명만을 받게 됩니다.

### 4. 주요 FIDO 표준 (프로토콜)

FIDO Alliance는 여러 가지 오픈 표준 프로토콜을 개발했습니다.

* **FIDO UAF (Universal Authentication Framework):**
    * 앱 내에서 비밀번호 없이 인증하기 위해 설계된 초기 FIDO 표준입니다. 사용자의 생체 인식이나 PIN 등으로 인증하고, 기기 내에서 생성된 키를 사용해 서버에 인증합니다.
    * 초기 모바일 앱 중심의 무비밀번호 인증에 주로 사용되었습니다.

* **FIDO U2F (Universal 2nd Factor):**
    * 두 번째 인증 요소(2FA)로 사용하기 위해 개발되었습니다. 주로 USB 보안 키와 같은 하드웨어 토큰을 통해 간단하고 강력한 2단계 인증을 제공합니다. (예: Google 계정 로그인 시 YubiKey 사용)
    * 웹 브라우저에서 주로 사용되었으며, WebAuthn의 기반이 되었습니다.

* **FIDO2 (WebAuthn + CTAP):**
    * 현재 가장 중요하고 널리 확산되는 FIDO 표준입니다. 웹 브라우저와 운영체제에서 비밀번호 없는 강력한 인증을 지원하도록 설계되었습니다.
    * **WebAuthn (Web Authentication API):** W3C(World Wide Web Consortium) 표준으로, 웹 브라우저와 운영체제가 FIDO 인증자(Authenticator)와 통신하는 표준 API를 정의합니다. 웹사이트가 사용자 기기의 생체 인식 기능이나 보안 키를 통해 사용자를 인증할 수 있도록 해줍니다.
    * **CTAP (Client to Authenticator Protocol):** 인증자(Authenticator, 예: USB 보안 키, 휴대폰)가 클라이언트(웹 브라우저, OS)와 통신하는 방법을 정의하는 프로토콜입니다.

### 5. FIDO (WebAuthn/CTAP) 인증의 상세 작동 방식

FIDO2 기반의 인증 흐름은 크게 '등록(Registration)'과 '인증(Authentication)' 두 단계로 나뉩니다.

**5.1. 등록 (Registration): 사용자의 키 쌍 생성 및 등록**

1.  **사용자 의도:** 사용자가 서비스(웹사이트/앱)에서 "FIDO 인증 등록"을 선택합니다.
2.  **서비스 요청:** 서비스(서버)는 사용자 기기(클라이언트)에 FIDO 인증자(Authenticator)를 등록하라는 요청(챌린지 포함)을 보냅니다.
3.  **사용자 확인:** 기기(운영체제)는 사용자에게 지문, 얼굴, PIN 등 익숙한 방식으로 본인임을 확인해 달라고 요청합니다.
4.  **키 쌍 생성:** 사용자의 확인이 성공하면, 기기 내부의 보안 영역(예: Secure Enclave)에서 해당 서비스에만 연결된 새로운 **공개키/개인키 쌍**이 생성됩니다.
5.  **공개키 전송:** 기기는 생성된 공개키와 함께 'Attestation'(선택 사항: 기기가 진짜임을 증명하는 서명)을 서비스(서버)로 전송합니다.
6.  **서버 저장:** 서비스(서버)는 받은 공개키를 사용자 계정과 연결하여 안전하게 저장합니다. **개인키는 절대 서버로 전송되지 않습니다.**

**5.2. 인증 (Authentication): 사용자의 신원 확인**

1.  **사용자 의도:** 사용자가 서비스에 로그인하려 합니다 (예: 로그인 화면에서 "FIDO 로그인" 버튼 클릭).
2.  **서비스 요청:** 서비스(서버)는 기기(클라이언트)에 사용자에게 인증을 요청하는 '챌린지(Challenge)'를 보냅니다.
3.  **사용자 확인:** 기기는 사용자에게 지문, 얼굴, PIN 등으로 본인임을 확인해 달라고 요청합니다.
4.  **서명 생성:** 사용자의 확인이 성공하면, 기기는 저장된 **개인키를 사용하여 서버가 보낸 '챌린지'에 암호학적으로 서명(Sign)**합니다.
5.  **서명 전송:** 기기는 생성된 서명된 응답을 서비스(서버)로 전송합니다.
6.  **서버 검증:** 서비스(서버)는 자신이 저장하고 있는 사용자의 **공개키를 사용하여 받은 서명 응답이 유효한지 검증**합니다.
7.  **인증 성공:** 서명 검증이 성공하면, 서비스는 사용자가 올바르게 인증되었음을 확인하고 로그인을 허용합니다.

### 6. FIDO 에코시스템의 구성 요소

* **Relying Party (RP, 서비스 제공자):** 웹사이트, 웹 애플리케이션, 모바일 앱 등 FIDO 인증을 통해 사용자를 인증하려는 서비스입니다. (예: Google, Apple, 금융 앱 서버)
* **Client (클라이언트):** 사용자 기기(스마트폰, PC)의 운영체제 및 웹 브라우저입니다. FIDO 인증자와 통신하고 사용자 인터페이스를 제공합니다. (예: Chrome, Safari, Windows, Android, iOS)
* **Authenticator (인증자):** 사용자의 개인키를 안전하게 저장하고 생체 인증/PIN을 통해 인증 서명을 생성하는 하드웨어 또는 소프트웨어 모듈입니다.
    * **플랫폼 인증자 (Platform Authenticator):** 기기에 내장된 인증자 (예: 스마트폰의 지문 센서, Face ID 모듈).
    * **로밍 인증자 (Roaming Authenticator):** 기기 외부에 있는 인증자 (예: USB YubiKey, Bluetooth 보안 키).

### 7. FIDO 인증의 주요 이점 (종합)

* **강력한 보안:**
    * **피싱 저항성:** 가장 큰 장점입니다. 인증 정보가 특정 도메인에 묶여 있어 피싱 사이트에서 탈취될 수 없습니다.
    * **자격 증명 유출 방지:** 서버에 비밀번호가 저장되지 않으므로, 서버 해킹으로 인한 비밀번호 유출 위험이 없습니다.
    * **중간자 공격, 재전송 공격 방지:** 강력한 암호학적 프로토콜로 이러한 공격을 차단합니다.
* **탁월한 사용자 경험:**
    * **비밀번호 없는 편리함:** 비밀번호를 기억하거나 입력할 필요 없이 생체 인식이나 PIN으로 빠르게 로그인합니다.
    * **간편하고 직관적:** 기기 잠금 해제와 동일한 방식으로 익숙하게 인증할 수 있습니다.
* **강화된 프라이버시:**
    * 사용자의 생체 정보는 기기를 떠나지 않고 로컬에서만 처리됩니다. 서버는 생체 정보에 대해 알 수 없습니다.
* **광범위한 상호 운용성:**
    * 오픈 표준이므로, 다양한 제조사의 기기, 운영체제, 브라우저, 서비스에서 FIDO 인증이 호환되어 작동합니다.
* **운영 비용 절감:**
    * 사용자의 비밀번호 분실/재설정 관련 헬프데스크 호출 감소.
    * 데이터 유출로 인한 피해 및 복구 비용 감소.

### 8. FIDO와 패스키(Passkeys)의 관계

앞서 언급했듯이, **패스키(Passkeys)**는 FIDO 표준, 특히 WebAuthn의 사용자 친화적인 이름이자 구현체입니다. 패스키의 목표는 여러 기기 간에 FIDO 인증 정보를 동기화하여, 마치 비밀번호처럼 편리하게 사용할 수 있으면서도 훨씬 강력한 보안을 제공하는 것입니다. 사용자는 하나의 패스키를 생성하면 iCloud 키체인이나 Google 비밀번호 관리자와 같은 클라우드 동기화 서비스를 통해 자신의 다른 기기에서도 해당 패스키를 사용할 수 있습니다.

### 9. 도입 및 확산

FIDO 인증은 이미 Google, Apple, Microsoft, Amazon, Meta(Facebook) 등 전 세계 주요 IT 기업에서 자사의 서비스에 활발하게 적용하고 있습니다. 웹 브라우저(Chrome, Firefox, Safari, Edge)와 모바일 운영체제(Android, iOS)에 기본 기능으로 내장되어 있으며, 금융, 통신, 공공 서비스 등 다양한 산업 분야로 확산되고 있습니다.

### 10. 고려사항

* **기존 시스템 통합:** 레거시 시스템에 FIDO 인증을 통합하는 것은 추가적인 개발 및 연동 작업이 필요할 수 있습니다.
* **사용자 교육:** 새로운 인증 방식에 대한 사용자 교육이 필요할 수 있습니다.
* **기기 분실/손상 시 복구:** 인증 수단인 기기를 분실하거나 손상했을 때 안전하고 편리하게 계정을 복구하는 메커니즘이 중요합니다.

IT 프로젝트 포지션 완벽 정리(feat. PM PL AA DA 등)

끄적잉 — Fri, 18 Jul 2025 11:26:54 +0900

## 1. **PM (Project Manager) – 프로젝트 관리자**

### ▶️ 역할:

* 프로젝트 전반의 **관리 책임자**로, 일정, 예산, 자원, 품질, 범위 등을 조율
* 고객과의 커뮤니케이션 창구 역할
* 프로젝트의 리스크를 식별하고 관리
* 팀원 간의 업무 조율 및 일정 계획

### ▶️ 주요 업무:

* 프로젝트 계획 수립 (WBS, 일정표, 자원계획)
* 고객 요구사항 수집 및 관리
* 프로젝트 예산 산정 및 통제
* 프로젝트 진행 현황 보고
* QA 및 테스트 결과 보고 관리

### ▶️ 요구 역량:

* 커뮤니케이션 능력, 리더십, 일정관리 능력
* 다양한 개발 방법론 (Waterfall, Agile 등)에 대한 이해
* 이슈 및 리스크 관리 능력

---

## ‍ 2. **PL (Project Leader) – 기술 리더/팀 리더**

### ▶️ 역할:

* 기술적인 관점에서 프로젝트를 리딩하는 사람
* 팀원들의 작업을 분배하고 기술 방향을 제시
* PM의 보조 역할을 하면서 개발자 간 기술 중재자 역할 수행

### ▶️ 주요 업무:

* 개발 일정에 따른 업무 분장 및 진척도 관리
* 기술 이슈 해결 및 기술 스택 선정
* 코드 리뷰 및 품질 관리
* 개발 표준 정의 및 문서화

### ▶️ 요구 역량:

* 풍부한 개발 경험
* 아키텍처 설계 능력
* 팀 관리 및 기술 멘토링 능력

---

## 3. **AA (Application Architect) – 응용 아키텍트**

### ▶️ 역할:

* 시스템의 전반적인 **기능 설계와 구조 설계**를 담당
* 비즈니스 요구사항을 토대로 시스템의 모듈화와 구조를 정의

### ▶️ 주요 업무:

* 어플리케이션 구조 설계 (MVC, MSA 등)
* 공통 모듈 및 재사용 가능한 컴포넌트 설계
* 성능, 보안, 유지보수성을 고려한 설계
* PL 및 개발자들과 협업하여 구현 지시

### ▶️ 요구 역량:

* 설계 패턴, 소프트웨어 아키텍처에 대한 깊은 이해
* 다양한 플랫폼/프레임워크 경험
* 대규모 시스템 구축 경험

---

## 4. **DA (Data Architect) – 데이터 아키텍트**

### ▶️ 역할:

* 시스템에서 사용하는 **데이터 구조를 설계**하는 전문가
* 데이터베이스의 논리적, 물리적 모델을 정의

### ▶️ 주요 업무:

* ERD 작성 (Entity Relationship Diagram)
* 데이터 표준 정의 및 메타데이터 관리
* 성능을 고려한 테이블 구조 및 인덱스 설계
* 데이터 보안 및 무결성 확보

### ▶️ 요구 역량:

* RDBMS, NoSQL 등 다양한 DBMS에 대한 이해
* 데이터 모델링 툴 (ERwin, PowerDesigner 등) 사용 능력
* 데이터 흐름 및 ETL 설계 경험

---

## 그 외에도 존재하는 관련 포지션들

| 포지션                                      | 설명                          |
| ---------------------------------------- | --------------------------- |
| **BA (Business Analyst)**                | 고객의 비즈니스 요구사항을 정의하고 분석하는 역할 |
| **QA (Quality Assurance)**               | 테스트 전략 수립 및 품질 보증 업무 담당     |
| **FE/BE (Frontend / Backend Developer)** | 사용자 인터페이스 / 서버 사이드 로직 개발자   |
| **UX/UI 디자이너**                           | 사용자 경험 및 인터페이스 설계           |
| **DevOps 엔지니어**                          | 개발-운영 환경 자동화 및 인프라 구축       |
| **Tester**                               | 실제 테스트 시나리오 작성 및 기능 확인 수행   |

---

## 정리: 각 포지션의 관계도

```
고객 ────── BA ──────── PM ────── PL ───── 개발자들
                  │            │            │
                 AA           DA          QA
```

* **BA → PM/AA**: 비즈니스 요구를 기술요건으로 변환
* **PM ↔ PL**: 프로젝트 일정·품질 관리를 위한 협업
* **AA ↔ DA**: 구조와 데이터 설계를 함께 조율
* **PL ↔ 개발자**: 개발 방향, 코드 품질 지도
* **QA ↔ 전체**: 품질 확보를 위한 협업

---

## ✅ 마무리 요약

| 역할     | 주요 책임                   |
| ------ | ----------------------- |
| **PM** | 프로젝트 전반 관리 (일정, 비용, 품질) |
| **PL** | 기술 리딩, 개발팀 관리           |
| **AA** | 애플리케이션 구조 설계            |
| **DA** | 데이터베이스 설계 및 데이터 구조 정의   |

각 포지션은 유기적으로 연결되어 있으며, **소프트웨어 프로젝트의 성공을 위해 상호 협력**해야 합니다. 프로젝트 규모가 클수록 포지션 간의 역할 분담이 더 명확해지며, 작은 프로젝트에서는 한 사람이 여러 역할을 수행하기도 합니다.

[React] 하단 메뉴바 생성하는 방법

끄적잉 — Tue, 15 Jul 2025 16:10:57 +0900

하기와 같이 하단 메뉴바 생성하는 방법 시작합니다.

일단 해당 부분 인스톨 하고

npm install @react-navigation/bottom-tabs

Tabs메뉴

import { createBottomTabNavigator } from '@react-navigation/bottom-tabs';

const MyTabs = createBottomTabNavigator({
  screens: {
    Home: HomeScreen,
    Profile: ProfileScreen,
  },
});

API 설명

backBehavior

이는 goBack내비게이터에서 가 호출될 때 발생하는 동작을 제어합니다. 여기에는 기기의 뒤로 가기 버튼이나 Android의 뒤로 가기 제스처가 포함됩니다.

다음 값을 지원합니다.

firstRoute- 탐색기에서 정의된 첫 번째 화면으로 돌아갑니다(기본값)
initialRoute- prop에 전달된 초기 화면으로 돌아가고 initialRouteName, 전달되지 않으면 첫 번째 화면으로 기본 설정됩니다.
order- 포커스된 화면 이전에 정의된 화면으로 돌아갑니다.
history- 탐색기에서 마지막으로 방문한 화면으로 돌아갑니다. 동일한 화면을 여러 번 방문한 경우 이전 항목은 기록에서 삭제됩니다.
fullHistory- 탐색기에서 마지막으로 방문한 화면으로 돌아갑니다. history- 이 동작은 웹 페이지가 작동하는 방식과 일치하도록 하는 데 유용합니다.
none- 뒤로가기 버튼을 처리하지 마세요

detachInactiveScreens

메모리 절약을 위해 비활성 화면을 뷰 계층 구조에서 분리할지 여부를 나타내는 부울 값입니다. 이를 통해 react-native-screens 와 통합할 수 있습니다 . 기본값은 .입니다 true.

tabBar

탭 표시줄에 표시할 React 요소를 반환하는 함수입니다.

이 함수는 다음 속성을 포함하는 객체를 인수로 받습니다.

state- 탭 탐색기의 상태 개체입니다.
descriptors- 탭 탐색기에 대한 옵션을 포함하는 설명자 개체입니다.
navigation- 탭 탐색기의 탐색 개체입니다.

배열 state.routes에는 탐색기에 정의된 모든 경로가 포함됩니다. 각 경로의 옵션은 descriptors[route.key].options.

import { View, Platform } from 'react-native';
import { useLinkBuilder, useTheme } from '@react-navigation/native';
import { Text, PlatformPressable } from '@react-navigation/elements';
import { createBottomTabNavigator } from '@react-navigation/bottom-tabs';

function MyTabBar({ state, descriptors, navigation }) {
  const { colors } = useTheme();
  const { buildHref } = useLinkBuilder();

  return (
    <View style={{ flexDirection: 'row' }}>
      {state.routes.map((route, index) => {
        const { options } = descriptors[route.key];
        const label =
          options.tabBarLabel !== undefined
            ? options.tabBarLabel
            : options.title !== undefined
              ? options.title
              : route.name;

        const isFocused = state.index === index;

        const onPress = () => {
          const event = navigation.emit({
            type: 'tabPress',
            target: route.key,
            canPreventDefault: true,
          });

          if (!isFocused && !event.defaultPrevented) {
            navigation.navigate(route.name, route.params);
          }
        };

        const onLongPress = () => {
          navigation.emit({
            type: 'tabLongPress',
            target: route.key,
          });
        };

        return (
          <PlatformPressable
            href={buildHref(route.name, route.params)}
            accessibilityState={isFocused ? { selected: true } : {}}
            accessibilityLabel={options.tabBarAccessibilityLabel}
            testID={options.tabBarButtonTestID}
            onPress={onPress}
            onLongPress={onLongPress}
            style={{ flex: 1 }}
          >
            <Text style={{ color: isFocused ? colors.primary : colors.text }}>
              {label}
            </Text>
          </PlatformPressable>
        );
      })}
    </View>
  );
}

const MyTabs = createBottomTabNavigator({
  tabBar: (props) => <MyTabBar {...props} />,
  screens: {
    Home: HomeScreen,
    Profile: ProfileScreen,
  },
});

다음 옵션을 사용하여 네비게이터 화면을 구성할 수 있습니다. 이러한 옵션은 screenOptionsprop of Tab.navigator또는 optionsprop of 에서 지정할 수 있습니다 Tab.Screen.

title

headerTitle및 tabBarLabel. 의 대체 제목으로 사용할 수 있는 일반적인 제목입니다 .

tabBarLabel

{ focused: boolean, color: string }탭 막대에 표시되는 탭의 제목 문자열 또는 React.Node를 반환하는 함수입니다 . 탭 막대에 표시할 탭의 제목 문자열입니다. 정의되지 않은 경우 scene이 title사용됩니다. 숨기려면 .을 참조하세요 tabBarShowLabel.

tabBarShowLabel

탭 레이블을 표시할지 여부입니다. 기본값은 .입니다 true.

tabBarLabelPosition

라벨이 아이콘 아래에 표시되는지, 아니면 아이콘 옆에 표시되는지.

기본적으로 위치는 장치 너비에 따라 자동으로 선택됩니다.

below-icon: 라벨은 아이콘 아래에 표시됩니다(iPhone의 경우 일반적임)

[React] 네비게이션 메뉴 useState? useSelector?

끄적잉 — Tue, 15 Jul 2025 15:56:06 +0900

네비게이션 메뉴에 서 쓰일 정보들은 useState useSelector 어디서 관리하는게 좋을까?

무조건 리덕스(Redux)와 같은 전역 상태 관리 라이브러리를 사용하는 것이 훨씬 효율적이고 useState로도 구현은 가능하지만, 앱의 구조가 복잡해지고 유지보수가 매우 어려워집니다.

## 왜 리덕스가 더 효율적인가?

모바일 앱에서 하단 메뉴바(네비게이션 바)는 어떤 페이지에 있든지 항상 화면에 유지되는 최상위 컴포넌트 중 하나입니다. 사용자가 메뉴를 커스텀하는 화면은 보통 '설정'이나 '메뉴 편집' 같은 특정 페이지에 있습니다.

이 상황을 정리하면 다음과 같습니다.

메뉴를 변경하는 곳: '메뉴 편집' 페이지 (하위 컴포넌트)
변경된 메뉴가 표시되는 곳: 하단 메뉴바 (최상위 컴포넌트)

이처럼 서로 다른 위치에 있는 컴포넌트들이 동일한 데이터(사용자가 선택한 메뉴 목록)를 공유해야 할 때, 전역 상태 관리가 빛을 발합니다.

구분	리덕스 (useSelector)	useState
데이터 흐름	간단하고 명확 메뉴 편집 페이지 → 리덕스 스토어 → 하단 메뉴바	복잡하고 비효율적 (Props Drilling) 메뉴 편집 페이지 → 부모 → 부모 ... → 최상위 App → 하단 메뉴바
구조	어떤 컴포넌트에서든 스토어에 직접 접근 가능	상태를 공유하려면 수많은 부모 컴포넌트를 거쳐 props를 전달해야 함
유지보수	쉬움. 상태 변경 로직이 한 곳(리듀서)에 모여있어 관리 용이	어려움. 앱 구조가 조금만 바뀌어도 props 전달 코드를 전부 수정해야 함
추천 상황	바로 이 경우처럼 앱 전반에 걸쳐 공유되는 상태를 다룰 때	한두 개의 컴포넌트 내에서만 사용하는 간단한 상태를 다룰 때

## 구현 시나리오 (리덕스 사용)

로그인: 사용자가 로그인하면, 서버로부터 해당 유저가 설정해놓은 메뉴 목록 데이터를 가져옵니다. (['홈', '환경설정'])
리덕스 스토어 저장: 가져온 메뉴 목록을 리덕스 스토어에 저장합니다.
하단 메뉴바 렌더링: 하단 메뉴바 컴포넌트는 useSelector를 사용해 리덕스 스토어에 있는 메뉴 목록을 가져와 화면에 그립니다.
메뉴 변경: 사용자가 '메뉴 편집' 페이지에서 메뉴를 추가하거나 삭제합니다. (예: '마이페이지' 추가)
리덕스 스토어 업데이트: '메뉴 편집' 페이지는 변경된 새 메뉴 목록(['홈', '환경설정', '마이페이지'])으로 리덕스 스토어의 상태를 업데이트하는 액션을 발생시킵니다.
자동 리렌더링: 리덕스 스토어의 상태가 변경되었으므로, 해당 데이터를 구독하고 있던 하단 메뉴바 컴포넌트는 자동으로 리렌더링되어 즉시 변경 사항을 화면에 반영합니다.

이처럼 리덕스를 사용하면 데이터 흐름이 매우 깔끔하고 효율적으로 관리됩니다. 따라서 고민할 필요 없이 리덕스(또는 Zustand, Recoil 같은 다른 전역 상태 관리 도구)를 선택하시는 것이 정답입니다.

[리액트] React.js 생명주기 마운트, 언마운트란?

끄적잉 — Sat, 5 Jul 2025 23:27:04 +0900

React 생명주기(Lifecycle): 마운트(Mount)와 언마운트(Unmount)의 개념과 이해

1. 생명주기(Lifecycle)란?

React에서 **생명주기(lifecycle)**란 컴포넌트가 생성되고, 화면에 렌더링되며, 업데이트되고, 제거될 때까지의 일련의 과정을 의미합니다. React 컴포넌트는 이 생명주기 동안 특정 시점에 자동으로 호출되는 메서드나 함수들을 통해 상태 관리, 데이터 처리, 부수 효과(side effects) 등을 제어할 수 있습니다.

컴포넌트 생명주기는 크게 다음과 같은 단계로 구분됩니다:

Mounting (마운트): 컴포넌트가 생성되어 DOM에 삽입되는 단계
Updating (업데이트): 컴포넌트의 props나 state가 변경되어 재렌더링되는 단계
Unmounting (언마운트): 컴포넌트가 DOM에서 제거되는 단계

이 중, 본 설명에서는 **마운트(Mount)**와 **언마운트(Unmount)**에 집중하여 설명하겠습니다.

2. 마운트(Mount)란?

2.1 정의

**마운트(Mount)**는 컴포넌트가 초기 생성되어 DOM에 추가되는 과정을 의미합니다. 즉, 화면에 처음으로 나타나는 시점입니다. 이 과정에서 컴포넌트는 다음과 같은 일을 합니다:

props를 전달받음
state 초기화 (클래스형: constructor, 함수형: useState)
DOM 트리에 컴포넌트가 삽입됨
렌더링 수행
외부 API 호출, 이벤트 등록 등 부수 효과 실행

2.2 클래스형 컴포넌트의 마운트 생명주기 메서드

class MyComponent extends React.Component {
  constructor(props) {
    super(props); // 초기 props 설정
    this.state = { count: 0 }; // 초기 state 설정
    console.log('constructor');
  }

  componentDidMount() {
    console.log('componentDidMount');
    // API 호출, 이벤트 등록 등
  }

  render() {
    console.log('render');
    return <h1>Hello, world!</h1>;
  }
}

호출 순서:

constructor(): 컴포넌트 초기화, state 설정
render(): JSX 반환
componentDidMount(): 컴포넌트가 DOM에 삽입된 직후 호출됨

componentDidMount()는 특히 다음과 같은 작업에 적합합니다:

API 데이터를 불러와 state에 저장
타이머 설정
외부 라이브러리 연동
이벤트 리스너 등록

2.3 함수형 컴포넌트에서의 마운트

React Hooks를 사용하는 함수형 컴포넌트에서는 useEffect()를 활용하여 마운트 타이밍을 처리합니다.

import React, { useEffect, useState } from 'react';

function MyComponent() {
  const [data, setData] = useState(null);

  useEffect(() => {
    console.log('컴포넌트 마운트됨');

    fetch('/api/data')
      .then(res => res.json())
      .then(result => setData(result));
  }, []); // 빈 배열을 전달하면 마운트 시 1회 실행

  return <div>{data ? data.name : 'Loading...'}</div>;
}

useEffect(() => { ... }, []): 마운트 시점에 한 번만 실행됨
이 안에서 fetch, WebSocket 연결, 구독 등의 작업 수행

3. 언마운트(Unmount)란?

3.1 정의

**언마운트(Unmount)**는 컴포넌트가 DOM에서 제거되는 시점을 의미합니다. 페이지 이동, 조건부 렌더링 해제 등으로 인해 컴포넌트가 사라질 때 발생합니다.

언마운트 시에는 다음과 같은 작업이 필요할 수 있습니다:

타이머 제거 (clearInterval, clearTimeout)
이벤트 리스너 제거 (removeEventListener)
WebSocket 종료, 구독 해제
메모리 누수 방지

3.2 클래스형 컴포넌트의 언마운트 메서드

class MyComponent extends React.Component {
  componentWillUnmount() {
    console.log('componentWillUnmount');
    // 타이머 제거, 이벤트 제거 등
  }

  render() {
    return <h1>Goodbye!</h1>;
  }
}

componentWillUnmount()는 컴포넌트가 제거되기 직전에 호출됩니다.
이 메서드는 주로 정리(clean-up) 작업에 사용됩니다.

3.3 함수형 컴포넌트에서의 언마운트 처리

useEffect() 내부에서 return 함수로 정리 작업을 할 수 있습니다. 이 return 함수는 컴포넌트가 언마운트될 때 실행됩니다.

import React, { useEffect } from 'react';

function TimerComponent() {
  useEffect(() => {
    const timer = setInterval(() => {
      console.log('타이머 실행');
    }, 1000);

    return () => {
      clearInterval(timer); // 컴포넌트 언마운트 시 타이머 제거
      console.log('컴포넌트 언마운트됨');
    };
  }, []);

  return <div>1초마다 로그 출력 중</div>;
}

이렇게 return 함수를 통해 컴포넌트가 사라지기 직전에 해야 할 정리 작업을 명확히 관리할 수 있습니다.

4. 마운트 & 언마운트의 실전 예시

function ChatRoom({ roomId }) {
  useEffect(() => {
    const connect = () => console.log(`방 ${roomId}에 연결`);
    const disconnect = () => console.log(`방 ${roomId} 연결 해제`);

    connect();

    return () => {
      disconnect(); // 언마운트 시 정리
    };
  }, [roomId]);

  return <h1>{roomId}번 채팅방</h1>;
}

roomId가 바뀔 때마다 이전 연결을 해제하고 새로 연결
이 방식은 실시간 통신, 소켓 연결 등에서 매우 중요

5. 요약 정리

구분 마운트(Mount) 언마운트(Unmount)

정의	컴포넌트가 DOM에 삽입되는 과정	컴포넌트가 DOM에서 제거되는 과정
클래스형 메서드	constructor, componentDidMount	componentWillUnmount
함수형 Hook	useEffect(() => {...}, [])	useEffect(() => {...}; return () => {...}, [])
주요 작업	API 호출, 초기화, 구독 시작	타이머 제거, 구독 해제, 메모리 정리
사용 예	초기 데이터 로딩, 이벤트 등록	자원 정리, 소켓 연결 종료

6. 결론

React의 마운트와 언마운트는 컴포넌트의 시작과 종료를 제어하는 중요한 개념입니다. 이를 제대로 이해하면 부수 효과를 안전하게 관리할 수 있으며, 메모리 누수나 성능 저하 문제를 사전에 방지할 수 있습니다. 함수형 컴포넌트에서는 useEffect()를 중심으로 이러한 생명주기를 통제하며, 클래스형에서는 각 메서드를 통해 세밀하게 생애주기를 관리할 수 있습니다.