devNote

AI 시대에 시간관리 앱이 필요할까?

sddev — Tue, 17 Mar 2026 12:49:36 +0900

최근 몇 년 사이 AI 기술이 빠르게 발전했습니다.

ChatGPT, Claude, Copilot 같은 AI 도구들은

글을 써주고
코드를 작성하고
업무를 자동화하고
정보를 정리해 줍니다.

그래서 어떤 사람들은 이렇게 말합니다.

“AI 시대에 시간관리 앱이 필요할까?”

AI가 대부분의 일을 대신해 주는 시대라면
시간관리는 더 이상 중요하지 않을까요?

하지만 실제로는 정반대입니다.

AI 시대일수록
시간 관리와 할일 관리의 중요성은 더 커지고 있습니다.

AI는 일을 대신하지만, 삶을 대신하지는 않는다

AI는 많은 일을 대신할 수 있습니다.

예를 들어

보고서 작성
코드 생성
자료 조사
콘텐츠 작성

하지만 AI가 대신할 수 없는 것이 있습니다.

바로

✔ 무엇을 해야 하는지 결정하는 것
✔ 어떤 일을 먼저 할지 선택하는 것
✔ 인생의 방향을 정하는 것

입니다.

AI는 도구(tool) 입니다.
하지만 인생의 방향은 사람이 결정해야 합니다.

그래서 여전히 시간관리와 할일 관리 시스템이 필요합니다.

AI 시대의 문제는 "시간 부족"이 아니다

예전에는 많은 사람들이 이렇게 말했습니다.

“시간이 부족하다.”

하지만 AI 시대의 문제는 조금 다릅니다.

이제는

“무엇을 해야 할지 너무 많다.”

해야 할 일이 많고
정보가 넘쳐나고
선택해야 할 것들이 많습니다.

이런 상황에서는

단순한 일정관리보다
할일 관리(Task Management) 가 더 중요해집니다.

AI 시대에는 Task 중심 관리가 중요하다

기존의 시간관리 방식은

시간(Time) 중심

이었습니다.

예를 들어

9시 업무
11시 회의
14시 작업

하지만 AI 시대의 업무는 훨씬 더 유동적입니다.

AI를 활용하면

작업 속도가 빨라지기도 하고
예상보다 오래 걸리기도 하고
새로운 아이디어가 생기기도 합니다.

그래서 중요한 것은

시간보다 Task입니다.

✔ 지금 해야 할 일
✔ 중요한 일
✔ 완료해야 할 일

이것을 중심으로 관리해야 합니다.

AI 시대의 생산성은 "속도 + 방향"

AI는 속도를 높여 줍니다.

하지만 방향을 정하지 않으면
속도는 의미가 없습니다.

예를 들어

AI를 활용해서 하루에 10개의 일을 처리할 수 있다고 해도
그 일이 정말 중요한 일인지는 또 다른 문제입니다.

그래서 AI 시대의 생산성은

Speed + Direction

즉

✔ 빠르게 실행하고
✔ 올바른 일을 하는 것

입니다.

결국 중요한 것은 작은 실행

많은 생산성 시스템이 복잡합니다.

하지만 실제로 중요한 것은

✔ 해야 할 일을 기록하고
✔ 하나씩 실행하고
✔ 완료를 체크하는 것

입니다.

이 작은 실행이 쌓이면
하루가 달라지고
삶의 방향이 달라집니다.

마무리

AI는 우리의 능력을 확장해 줍니다.

하지만

무엇을 할지 결정하는 것
삶의 균형을 유지하는 것
중요한 일을 실행하는 것

은 여전히 사람의 몫입니다.

그래서 AI 시대에도
아니 AI 시대일수록

좋은 시간관리와 할일 관리 시스템이 필요합니다.

Task 기반 Life Management Tool
Speedetail

Android
https://play.google.com/store/apps/details?id=com.speedetail.speedetailapp&pcampaignid=web_share

iOS
https://apps.apple.com/kr/app/speedetail/id6502599511

공식 사이트
https://www.speedetail.com

시간관리 안되는 사람 특징 5가지 - SPEEDETAIL 앱추천

sddev — Tue, 17 Mar 2026 12:45:01 +0900

(대부분 사람들이 모르는 시간관리 방법)

많은 사람들이 시간관리 방법을 찾습니다.

하지만 대부분의 사람들은
시간관리 방법을 배우기 전에
먼저 알아야 할 것이 있습니다.

바로 이것입니다.

시간관리가 안되는 이유

시간관리가 어려운 사람들에게는
몇 가지 공통적인 특징이 있습니다.

혹시 아래 중에
본인에게 해당되는 것이 있는지 확인해보세요.

1. 해야 할 일을 기록하지 않는다

시간관리가 잘 되는 사람은
모든 할 일을 기록합니다.

반대로 시간관리가 어려운 사람은

기억에 의존하고
생각날 때만 일을 합니다.

문제는 이것입니다.

사람의 기억은 할 일을 관리하기 위한 도구가 아닙니다.

그래서 결국

해야 할 일을 놓치고
중요한 일을 잊어버리고
일이 계속 밀리게 됩니다.

그래서 할일 관리 앱이나 ToDo 리스트가 필요한 이유입니다.

2. 일정과 할 일을 구분하지 못한다

많은 사람들이
일정과 할 일을 섞어서 관리합니다.

하지만 두 가지는 비슷하지만 분명히 다른 개념입니다.

✔ 일정 → 캘린더
✔ 할 일 → 할일 목록

예를 들어

일정 (Calendar)

회의
약속
출장
병원 예약

✅ 할 일 (Task)

보고서 작성
운동하기
책 읽기
공부하기

문제는 많은 사람들이

일정을 할일 목록에 적거나
할 일을 캘린더에 모두 넣으려고 한다는 것입니다.

그러면 현실에서 자주 발생하는

일정 취소
일정 변경
일정 밀림
갑작스러운 일

같은 상황이 생길 때
관리 체계가 무너집니다.

그래서 좋은 시간관리 도구는

✔ 일정과 할 일을 명확히 구분하고
✔ 두 시스템을 자연스럽게 연결해 주는

교통 정리 역할을 해야 합니다.

3. 우선순위를 정하지 않는다

모든 일을 동일하게 생각하면
정작 중요한 일을 놓치게 됩니다.

그래서 시간관리를 잘 하는 사람들은
항상 우선순위 기준이 있습니다.

대표적으로

중요도
긴급도

이 기준으로 할 일을 정리합니다.

4. 작은 성취를 기록하지 않는다

사람은 성취감이 있어야 계속 행동할 수 있습니다.

그래서 작은 일이라도

✔ 체크박스를 누르고
✔ 완료 표시를 하고
✔ 성취를 기록하는 것

이것이 굉장히 중요합니다.

작은 성공이 쌓이면
자연스럽게 실행력이 올라갑니다.

5. 일을 미루는 것에 죄책감을 가진다

현실에서는 일이 자주 미뤄집니다.

갑자기 일이 생기기도 하고
예상보다 시간이 오래 걸리기도 하고
일정이 바뀌기도 합니다.

그래서 중요한 사실이 있습니다.

사정이 생겨서 일을 미루는 것은 죄가 아닙니다.

진짜 문제는 따로 있습니다.

많은 시간관리 도구들이

일을 미루면서도
그 일을 끝까지 놓치지 않도록 관리해 주는 역할을
제대로 하지 못한다는 점입니다.

그래서 할 일을 미루는 순간

할 일이 잊혀지고
관리에서 사라지고
결국 못 하게 됩니다.

좋은 시간관리 도구는

✔ 일을 유연하게 미룰 수 있으면서도
✔ 완료될 때까지 놓치지 않도록 관리해 줍니다.

정리

시간관리의 핵심은 생각보다 단순합니다.

✔ 해야 할 일을 기록하고
✔ 일정과 할 일을 구분하고
✔ 우선순위를 정하고
✔ 작은 성취를 기록하고
✔ 미뤄진 일도 끝까지 관리하는 것

이 다섯 가지만 잘 해도
시간관리는 훨씬 쉬워집니다.

마무리

필자는 MBTI에서 70% 이상의 P 성향이라
시간관리가 항상 어려웠습니다.

하지만 지난 7년 동안 개발해 온 SPEEDETAIL 시간관리 앱을 사용하면서

직장
교회
가정

여러 역할을 시간관리 스트레스 없이 살아가고 있습니다.

SPEEDETAIL은
단순히 할 일 관리의 필요성을 강조하며
위기감만 주는 앱이 아니라

“어떻게 할 것인가(How To)”를 실제로 실행할 수 있도록 돕는 도구입니다.

시간관리에 성공한 경험이 없으셨다면
한 번 사용해 보세요.

정말 단순한 원리이지만
강력한 변화를 경험하실 수 있습니다.

할일 기반 인생관리 앱
Speedetail

Android
https://play.google.com/store/apps/details?id=com.speedetail.speedetailapp&pcampaignid=web_share

iOS
https://apps.apple.com/kr/app/speedetail/id6502599511

공식 사이트
https://www.speedetail.com

[Toeic] LC 원칙 & RC 원칙 & 문제 풀이 원칙

sddev — Fri, 6 Mar 2026 10:04:26 +0900

LC 원칙

0. LC에서 사용하는 용어는 대부분의 단어는 80% 정도 이미 알고 있고, 간혹 모르는 단어가 있더라도 모든 단어를 모르지 않는다는 사실을 명심한다.

0. 언어는 결국 의사소통이기 때문에, 말하는 사람도 전달하고자 하는 핵심 내용에 강세를 줘서 말한다는 사실을 기억해야 한다.

// 모든 단어를 들어야 이해할 수 있는게 아니라, 핵심 전달 단어만 전달되면 의사소통이 되는 것이다.
1. 모든 단어에 가중치를 두지 말고, 뭐라 장황하게 얘기해도 핵심 의도를 담은 단어(주로 명사와 동사)만 추출하는 훈련해라.
(쓸데 없는 단어를 버리는데 있다. 영어권 사람들은 핵심 단어만 듣도록 이미 튜닝이 되어 있다.)
(듣고 말하는데 완벽한 문법이 뭐가 필요한가? 의사 전달만 되면 되지)

2. 상황, 장소을 상상하고 예상하라. (듣기 문제의 경우 선택지를 먼저 읽으며, 상상해 봐라)

RC 원칙

기본 문법만 외우고, 기출문제 푼다.
https://www.youtube.com/watch?v=_tXHTsqyNp8

토익 시험 구성

0. 파본 검사 (1분 30초)
1. 듣기 영역 (LC, 45분, 100문항)

Part 0 안내 방송 (1분 30초) // Now let us begin
Part 1 (사진 묘사): 6문항
Part 2 (질의응답): 25문항
Part 3 (짧은 대화): 39문항
Part 4 (짧은 담화): 30문항

2. 독해 영역 (RC, 75분, 100문항)

Part 5 (단문 빈칸 채우기): 30문항 // 문제당 20초, 10분 내외
Part 6 (장문 빈칸 채우기): 16문항 // 문제당 50초, 13분 내외
Part 7 (독해): 54문항 (단일 / 복수 지문) // 문제당 50초, 45분 내외

Part 5 (단문 공란 메우기, 30문항): 품사, 동사 형태, 접속사/전치사, 대명사 등 문법 위주. 문장을 구조적으로 분석하여 10분 내에 풀어야 함.
Part 6 (장문 공란 메우기, 16문항): 문맥을 파악해 문장 채우기 및 어휘 문제. 문맥 흐름이 중요하며 10분 내 해결 권장.
Part 7 (독해, 54문항): 이메일, 기사, 공지 등 다양한 지문. 주제, 세부 내용, 추론 문제를 빠르게 찾아내야 하며, 가장 많은 시간(45분 이상) 투자 필요.

[AI] Claude Cowork & Plugins란?

sddev — Thu, 26 Feb 2026 13:35:55 +0900

Desktop Application의 형태로 설치형 프로그램
Claude Code 를 사용하면서 Cowork 탭도 제공하여, 일반 지식 업무 전반을 Ai 기반으로 동작할 수 있도록 함

기존 Code처럼 로컬 파일에 접근할 수 있고, 브라우저 작업도 가능하며, 주로 산출물은 코드가 아닌 문서(html, ppt, docx), 단 내부적으로 파이썬 코드를 만들어 수행하여 원하는 작업을 수행함

대규모 배치 작업, 분석 작업 등을 수행 가능하다.

진행과정 (스크립트 실행, 파일 생성 등)을 자세하게 설명해주는 장점이 있다. 문서를 만들어서 요약을 확인할 수 있다.

Plug-ins 기능을 제공하는데, 각 도메인별 명령, 스킬 목록들을 import 해올 수 있다.
- 명령 : 도메인 업무에 대한 전반적인 workflow(시나리오)를 자연어로 설명해두는 MD 파일로 관리한다.
- 스킬 : 단위 기능을 설명한 MD 파일. 명령에서 가져다 쓸 수 있는 도구에 가깝다.

skills MD 파일(시스템 프롬프트)을 가지고, 파이썬 코드를 자체로 생성해서 실행하여 문제를 해결한다. 생성한 코드들도 산출물로써 모두 확인 가능 및 재활용 가능하다. dynamic tool generation 시스템

권한을 어떻게 통제할 것인가에 대한 챌린지가 아직 존재한다.

[Insight]
1. Pre-built Agent(Component)로서의 Skill
2. Human in the loop, Multi turn
3. 방향성
- 복잡한 정책과 권한 체계, 레거시 시스템 연계가 핵심

[LGD] On-premise 환경 Lessons & Learned 정리

sddev — Wed, 11 Feb 2026 11:11:25 +0900

로컬 환경에서 원활하게, 사내 API를 호출하기 위해 API mocking 방안 고려 필요
(FastAPI의 경우 비동기 HTTP 통신을 가로채는 Respx 추천, FastAPI(httpx) 환경에서 가장 표준적임.)

AI-DLC 개요

sddev — Thu, 5 Feb 2026 13:37:26 +0900

AI-DLC란?

프로젝트의 라이프 사이클(분석설계 -> 구현 -> 운영)의 각 단계를 AI를 통해, 단계적으로 AI를 통해 구현해 나가는 방법론을 의미한다.

가장 먼저 프로젝트 개요, 요구사항, 컨텍스트를 기반으로,

Reverse Engineering이란? 기존 project가 존재하는 경우 LLM에게 분석시켜서, md 파일을 만들어 이해하게 하는 것이다.
Plan.md, Requirements.md, Workflow.md, UserStory.md(Given When Then, AC 등 정의)를 만들고,
해당 markdown을 기반으로 후속 절차들을 계속 수행해나가는 방식으로 진행시켜 나간다.

대체제로는 Spec-Kit/BMAD 등이 있다.

[AWS] 클라우드 인프라 구축 기본 - 리소스 사용관리(CloudWatch), 가용성(LoadBalancer), 글로벌 부하분산(Route53,CloudFront), 권한 관리(IAM)

sddev — Fri, 30 Jan 2026 11:44:50 +0900

Chapter 6. 클라우드 리소스 사용 관리

Section 1. Cloud Watch/Cloud Trail

1.1 CloudWatch

- AWS CloudWatch는 준실시간 로그, 지표 및 이벤트 데이터를 자동화된 대시보드에 수집하고 이를 시각화하여 인프라 및 애플리케이션 유지 관리를 간소화합니다. 모니터링을 해야 Scale In/Out을 할지 결정할 수 있다.

- On-Prem도 붙일 수 있다.

- 알림도 붙일 수 있다.

- Auto Scaling도 자동으로 진행되도록 할 수 있다.

네임스페이스

어떤 서비스에서 발생한 지표인지 알아야 하므로, Cloud Watch에서는 서비스 네임스페이스를 보고 어떤 서비스에서 발생한 지표인지 알 수 있다.

Cloud Watch 지표(metrics)

서비스별로 정의된 지표들이 있고, 해당 지표들을 그래프 형태로 볼 수 있다.

CloudWatch 알람

- 특정 Metrics의 조건을 통해, EC2 Action, AutoScaling, Notification(SNS) 서비스를 Trigger 할 수 있다.

CloudWatch Logs

아래와 같은 순서로 진행된다.

Logs > Metrics > alerts > actions

1.2 CloudTrail

CloudWatch는 그냥 Monitoring이지만, AWS의 모든 서비스의 모든 사용 이력을 API를 통해 저장해둠

AWS의 보안 및 감사를 위한 서비스

AWS의 모든 서비스가 사용될 때마다 언제 어디서 누구에 의해 사용되었는지 로그 저장

AWS 리소스의 변경 사항을 모두 추적할 수 있음(ex. CCTV)

여러 서비스에 대해 API 이용 로그 등을 제공

- 모든 서비스는 아래와 같이 REST API Endpoint를 가지고 있음

- https://서비스코드.리전코드.amazonanows.com/...

Logs를 모아서 S3 Bucket에 적재해둔다.

Cloud Trail 이벤트

- 관리 이벤트, 데이터 이벤트 등이 있어서 문제가 생겼을 때, 추적을 할수 있다.

CloudTrail vs CloudWatch

- CloudTrail : AWS 환경에서 수행된 모든 작업 로그

- CloudWatch : AWS를 모니터링하기 위한 서비스, 대시보드, 상태와 성능, 상황에 따른 Noti, Action

- CloudTrail이 로그를 모으고, CloudWatch는 로그를 통해 대시보드와 알림 등을 제공해준다.

VPC Flow Log

Agentless 기반 방화벽 로그

- Netflow와 유사

- Elastic Network Interface, Subnet, VPC당 활성화(어떤 사용자가 어떤 네트워크에 접속 시도하고 Deny 되었는지)

- CloudWatch Logs에 로깅

- CloudWatch 메트릭 생성하고 Alarm 설정

보통은 Prometheus & Grafana 오픈 소스를 통해, 모니터링 & 대시보드를 수행함

Section 2. AWS Budget / Cost Explorer

AWS Budgets

- 사용자 지정 예산을 설정하여 비용 & 사용량을 추적하고, 임계값 초과 시 이메일 또는 SNS 알림에서 수신된 알림에 빠르게 대응 가능

예산 유형을 지정할 수 있다.

- 요구에 맞는 사용자 지정 예산 책정 가능, 알림 보고서를 통해 지속적으로 정보 파악, 예산 기간 세부 지정

Cost Explorer

- 계정에 연결된 요금과 사용량을 검토
- 비용 및 사용량 데이터 보고서를 조회하고 작성

- 향후 3개월 동안의 예상 지출을 예측

- 예약형 인스턴스(RI)의 사용률 적용 범위에 대한 권장 사항을 확인

- 절감형 플랜의 사용률과 적용 범위에 대한 권장 사항을 확인

Section 3. CloudFormation

IaC[Infra As Code]란?

- Terraform과 같이 코드를 이용해서 infra 리소스를 생성할 수 있도록 한다.
<주로 Terraform 문법을 자주 사용한다.>

- 정말 잘 만들어 놓은 Infra를 다른 Region에 동일하게 구성할 때 훨씬 더 효율적이다.

CloudFormation

- 템플릿 기반 인프라 프로비저닝을 위한 관리형 서비스
(어찌되었건 코드를 실행하려면 서버가 필요한데, 실행할 서버 자체는 관리형으로 제공해주고 코드만 작성하면 됨)

- 인프라 환경을 코드(Yaml 또는 Json 형태 템플릿파일)로 작성

CloudFormation 템플릿

- 주로 yaml 형식을 사용

CloudFormation Designer

- UI Builder에서 만들고 코드로 변환해주는 기능

CloudFormation 스택

- IaC라고 하더라도 한번에 구성하는 것보다, 벽돌처럼 단위 단위별로 구분 지어 놓아서 구현해 놓고, 추후에 특정 서비스만 변경될 경우에 그부분만 수정 반영하도록 하기 위해서 스택 형식을 채용한다.

- 템플릿을 구분해서 만들면 하나의 템플릿이 하나의 Stack이 되고, 여러개의 Stack이 쌓여 전체 Infra가 구성된다.

- VPC, EC2 Instance 생성 등등 여러가지 리소스를 생성하는 템플릿을 모두 하나에 모아서 관리해도 되겠지만, 그렇게 되면 VPC 하나만 바꾸고 싶어도 수정하기가 부담스러워진다.

스택생성 Workflow

Chapter 7. 클라우드 인프라에 대한 가용성 처리

Section 1. ELB(Elastic Load Balancer) / ASG(Auto Scaling Group)

AWS Availability

동일 역할을 수행하는 Instance를 각 가용 영역에 분산 배치하면 서비스 가용성을 높일 수 있음

분산 배치 및 이중화 된 인스턴스로 어떻게 트래픽을 분배할 것인가?

Load Balancer(단일 진입접, 로드 분산)가 해당 역할을 해준다.

Load Balancer는 Health Check를 통해 인스턴스의 상태를 주기적으로 확인한다.

AWS Networking - ELB(Elastic Load Balancer)

Region 내 Load Balancing 서비스

- 다수의 가용영역으로 Traffic 분배

- HTTP/S, TCP/S 프로토콜 지원

- Backend Instance에 대한 Health Check

- 고가용성 기반의 L4(Transport, TCP 기반 Port 기반 로드 벨런싱), L7(Application, Http 기반 Path 기반? 로드 벨런싱) 서비스

ELB 유형

- ALB -> Application Load Balancer(L7, 분배 대상이 Application, Http 통신 기반 로드 밸런싱)

- NLB -> Network Load Balancer(L4, 분배 대상이 Network, Tcp 통신 기반 로드 벨런싱)

- GLB -> Gateway Load Balancer(분배 대상이 네트워크 장비 단위)

- 기존 Classic Load Balancer : 위처럼 유형 구분 없이, 분배

ALB 구조

트래픽을 수신하게 되면 Listener의 Rule에 따라 Target Group에 분배 후, Balancing Algorithm에 따라 각 서버에 분산

Target Group은 Instance 그룹 또는 Lambda라고 할 수 있다.

Balancing Algorithm

- Round Robin : 공평하게 돌아가면서 한번 씩

- Hashing : 헤시 알고리즘에 따라 요청 분기

- Weighted Round Robin : 가중치를 둔 Round Robin

NLB Balancing Algorithm

- Flowing Hash 알고리즘(ip, port)

AWS Networking Protocol

- L4 : TCP / UDP

ELB 주의 사항

- ELB를 생성할 때 반드시 AZ별 활성화가 필요하다.

- LB 등록 시, 활성화 되지 않은 AZ에 배치된 타겟(인스턴스)에는 트래픽이 수신되지 않는다.

- ALB의 IP Address는 지속적으로 변경될 수 있으므로, DNS를 사용해야함

- NLB는 고정 IP 부여 가능하다. ALB는 불가능

- SSL(Secure Socket Layer) 지원

- Client의 SLL을 ELB에서 처리(BE 부하 감소 효과)

- CrossZone Load Balancing(단, AZ별로 LB를 만들어야 하나봄)
- Sticky Sessions : 특정 경우에 A라는 Target Group으로 요청을 보내야한다는 기능을 적용 가능

ELB 라우팅 요청 구조

- ELB는 기본적으로 DNS 주소를 통해 접속 (DNS 주소 관리는 Route53 서비스가 담당)

- Client가 ELB DNS 주소로 접근 요청시 (Route53은 Client에게 1개 이상의 LB 노드 IP를 반환

Scale out & Scale in

- Scale out : 서비스 부하가 증가되어 인스턴스 증설 (주로 WAS 서버)

- Scale in : 서비스 부하 감소시 인스턴스 제거 (주로 WAS 서버)

- Scale up : 인스턴스 하나의 사양을 더 높임 (재기동 필요해서 약간의 다운 타임 존재, 주로 DB)

- Scale down : 인스턴스 하나의 사양을 더 낮춤 (재기동 필요해서 약간의 다운 타임 존재, 주로 DB)

Auto Scaling Group

- 자동 Scaling 기능

- ELB & Auto Scaling Group 조합으로 자동으로 Scale-in & out 되도록 운영

- ELB와 Auto Scaling Group은 조합으로 같이 사용된다. ELB 입장에서는 Auto Scale된 Instance 정보들을 다 파악해야되기 때문이다.

AWS Auth Scaling 구성 요소

- 무엇을 Scale-in & Scale-out 할 것인가? Launch Template(AMI, Instance Type, 자동으로 생성 or 삭제되는 Instance 정의)

- 자동화 동작은 어떤 방식으로 할 것인가? Auto Scaling Group(원하는 Capacity, Min/Max instance 개수, Target Group 등 자동 변경과 관련한 정의)

아래는 Autoscale 실습 중, 특정 Instance에 접속하여 CPU 이용률를 100% 찍도록 하는 방법이다.

sudo yum install -y stress
stress --cpu <vm cpu 갯수> --timeout <지속할 시간>

Chapter 8. 글로벌 서비스를 위한 부하 분산

Section 1. Route 53 / Transit GW

Route53

AWS가 제공하는 Domain Name System 서비스 입니다.
(도메인 텍스트 기반 주소로 접근해도 자동으로 IP주소를 변환하여 접근할 수 있도록 해주는 서버)

도메인 등록, 도메인 이전, DNS 라우팅, 상태 확인 등 기능을 제공함

가용성과 확장성이 뛰어난 DNS 웹서비스

DNS란?
Domain Name System (Nomain Name을 네트워크 주소로 변환해주는 시스템)

원래는 서버에 접속하려면 서버 IP 숫자를 입력해서 접근해야하는데, 다 알기 어렵다.

아주 예전에는 OS의 hosts 파일에, 아래 같이 domin과 ip를 매핑해서 쓰기도 했다.

```

google.com 216.58.220.142

```

단점은 계속 ip가 바뀌는 경우도 있고 해서, Domain 매핑해서 원하는 IP로 연결시켜주는 DNS가 등장하게 되었음

DNS의 동작순서

1. 가장 먼저 Local DNS를 보고 일치하는 domain이 있으면 해당 IP를 캐싱한 상태로 사용해서, Browser에 보낸다.

2. root dns -> com dns -> domain.com dns 순으로 찾아서 온다.

Route53의 특징 - Weight Round Robin

- 서버의 IP 주소나 도메인마다 가중치를 설정하여 트래픽을 조절하여, Region 레벨 LoadBalancer 역할을 해줄 수 있다.

- Failover 기능을 제공하여, 장애가 있는 Region에는 요청을 보내지 않는 기능이 있다.

- 지연이 제일 낮은 Region IP를 반환해줄 수 있다.

- ALB와 차이가 뭘까?

- Route53은 Region 별 Load Balancing 하는 것이고, ELB는 Region 내에서 Load Balancing 해준다.

Transit Gateway

가상 사설 클라우드(VPC)와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 네트워크 전송 허브

- VPC를 만들었는데, 다른 VPC와 연결하고 싶을 때 보통 VPC Peering을 사용해야 하는데, 문제점이 있어서 이를 해결하기 위해 사용해야 하는 서비스이다.

- VPC는 보통 팀별/프로젝트별/회사별로 만들어 지는데, 상황에 따라 가상 사설망끼리 연결해주고 싶은 요건이 생긴다.

- VPC는 가상 사설망이기 때문에, A VPC도 네트워크 대역을 10.0.xx.xx/16로 했을 경우도 있고, B VPC도 네트워크 대역을 10.0.xx.xx/16로 했을 경우도 있다. 즉 중복될 수 있다.

- VPC Peering의 단점은 연결해야할 VPC가 2개를 넘어서 3개 이상이 될 때, VPC간 연결을 위해 VPC간 모두 선을 연결해줘야 한다는 단점이 존재한다.

- Transit Gateway는 중앙에 Gateway 형태의 TG가 있고 VPC들은 Transit Gateway에 연결해두면 별도로 VPC간 연결을 하지 않아도 VPC 간 연결이 가능하도록 해준다.

- On-prem 과도 연결이 가능하다는 단점이 있다.

Section 2. Cloud Front / Global Accelator

Cloud Front

AWS가 제공하는 Cloud native한 Content Delivery Network(CDN) 서비스입니다.

- AWS는 이미 전 세계 각지에 사용자에게 최적의 Edge Server(Edge Loacation)을 찾아 캐시 및 AWS 글로벌 네트워크를 통해 빠르게 전송

- 사용자 기준 최적의 Edge Server를 통해 컨텐츠를 캐시해두고 전송해줌

- 다른 AWS 서비스와 쉽게 연동(AWS WAF, S3, Media, ACM...)

CloudFront 용어

- Origin Server : 기존 컨텐츠가 저장되어 있는 서버

- Cache Server : 빠른 콘텐츠 전달을 위해 지리적으로 사용자와 가깝게 위치한 서버

원본 서버와 컨텐츠가 먼 대륙에 있어도, 사용자 경험이 떨어지지 않도록 해준다.

원래는 Origin Server에 요청해야 하나, 먼저 Edge Server에 있는 Cache Server에 요청한다.

CloudFront 구성

Origin Server 정보와 도메인 할당이 필수적이고, 글로벌에 배포하는 방식이다.

CND이란?

컨텐츠를 전송하기 위한 네트워크이다. 짧은 지연시간, 사용자 경험(UX) 향상, 빠른 전송 속도 지원을 위한 Network

사용자에게 최대한 가까운 위치에서 컨텐츠를 빠르게 받아볼 수 있도록 해주는 서비스

Global Accelarator

엣지 로케이션을 사용하여 사용자에게서 애플리케이션까지 최적의 경로를 찾는 서비스

- 고정된 IP로 엔드포인트 제공

- 다중 리전 구성에서 최적의 리전으로 연결

- 헬스 체크를 통한 자동 트래픽 제어

- AWS 글로벌 네트워크를 통해 빠른 전송

글로벌 인터넷망은 속도를 보장할 수 없지만, 인터넷망에서 AWS망으로 요청만 주면 그 내부 AZ간의 통신 측면에서는 초고속 속도를 보장해 주겠다.

Chapter 9. 클라우드 신원 및 접근 관리 - 인증과 권한

Section 1. AWS IAM 자격 증명

IAM(Identity and Access Management)

- 인증(Authentication), 권한(Authorization)

인증과 권한의 차이가 뭘까?

- 인증(Auth) : 내가 어느 시스템, 서비스에 접근하고 싶어. 내가 그 서비스를 사용할 수 있는지 자격을 증명

- 권한(AuthR) : 이미 서비스에는 들어갈 수 있으나, 어느 행위까지 할 수 있는 레벨을 결정

자격 증명 (사용자 / 역할)

초기에 AWS에 가입하면 email + pw + MFA 인증으로 로그인하게 되는데 이를 Root 계정이라고 하고, 관리자 계정이고 모든 것을 할 수 있는 계정이라 해킹당하면 매우 위험하기 때문에, 일상 Task 용도에는 사용하지 않는다. 그래서 무조건 MFA 인증을 해야한다.

Root 계정을 가지고, IAM 계정(사용자, Admin 권한 부여)을 만들고 해당 계정으로 로그인한다.

Admin IAM User가 Role(Dev, Test, Analyze...) 을 만들고 여러 IAM User 들에게 Role을 할당한다.

최소 권한의 원칙이 맞지만, 너무 번거롭기 때문에 MFA 인증을 강제하는 방향으로 하는 경우가 많다.

- 장기 자격 증명 = 사용자(user) // IAM 사용자 자체에 할당된 권한 (보통 Policy(정책)을 통해 매핑한다)

-> 적절한 정보를 통해 특정 유저임을 확인 하는 자격 증명 방식

-> AWS가 미리 제공하는 권한을 정의해놓은 Policy들이 있다.

-> 직접 Policy들을 IAM User에 할당하거나, 여러 Policy를 가진 IAM Group에 해당 IAM User를 포함시킨다.

-> 주로 IAM Group으로 그룹화하여 관리

- 임시 자격 증명 = 역할(Role) // 모자라고 생각하면 좋다. 평소에는 개발자였다가 특정 Role 모자를 씌워주면 임시적으로 해당 Role도 할

당된 권한도 사용할 수 있게 된다.

-> 적절한 정보를 통해 특정 역할을 수행할 수 있는 권한을 일정기간 취득하여 사용하는 방식

-> 주의할 점은 Role을 사용하게 되면, Role을 할당하기 직전의 권한은 사용할 수 없다.

Root User / IAM User

- Root User : 모든 권한, 계정 생성 후 직접 사용하지 않을 것을 권장

- IAM User : 장기자격증명(Access Key, Secret Key 또는 ID/PW) // SDK,CLI 형태로 사용할 것이면 KEY 발급 필요

(번외) SSO 계정이란? 현재는 하나의 AWS 계정 내에서의 권한들을 이야기 하고 있지만, 회사 규모가 크면 여러개의 팀별로 AWS 계정을 두고 사용한다. 여러개의 계정을 통합하여 관리하고 싶을 때, SSO 계정의 필요성이 등장된다.

IAM 그룹

- IAM 사용자의 집합

- 그룹을 사용 안해도 되지만, 권한을 지정 시, 다수의 사용자에게 일괄 권한 할당이 가능하다.

- A그룹 안에 B그룹을 넣을 수는 없다. 즉 중첩 구조는 불가능하다.

- 한명의 사용자가 여러명의 그룹에 속하는 것인 가능하다.

보안자격증명

- AWS 관리 콘솔의 경우 ID + Password로 보안 자격 증명을 진행함

- API / CLI / SDK 의 경우 Access Key, Secret Key로 보안 자격 증명을 진행함

임시 자격증명 연동

- 임시 자격증명 할당을 통한 권한 연동은 리소스에게도 가능

- 외부 사람이지만 임시로 권한을 주고 싶을 때 Role을 사용한다. 그런 사용자를 Federation 사용자라고 한다.

Section 2. IAM 권한 / 정책

IAM 정책(Policy)

- 사용자(User)와 그룹(Group), 역할(Role)이 무엇을 할 수 있는지에 대한 권한(permission) 설정 데이터 문서

- AWS가 만들어 높은 관리형 정책들을 미리 제공한다.

- 가장 높은 정책은 "AdministatorAccess" 권한이다. 모든 AWS 서비스와 리소스에 대해서 접근 권한을 가짐

{
 "Effect": "Allow",
 "Action": "*",
 "Resource": "*"
}

IAM 정책(Policy) 구조

보통 아래에서 부터 해석하는 게 좋다.

Resource : 어떤 서비스에 대해서

Action : 그 서비스에 대한 어떤 액션을

Principal : 접근을 허용하고자 또는 차단하고자 하는 대상

Effect : 허용 또는 차단

IAM 정책(Policy) 종류(Type)

IAM 정책도 여러 유형이 많다. 총 6종류

- 권한 부여 정책 (권한을 부여하기 위한 정책)

1. 자격증명 기반 정책 (User, Group, Role에 부여하는 정책 - 사용자 관점이다! 사용자에게 부여하는 정책이다.)

-> 사용자가 어떤 리소스에 접근할 수 있는지

2. 리소스 기반 정책 (S3 버킷과 같은 리소스에 연결하는 JSON 정책 문서, 지정된 보안 주체에 해당 리소스에 대한 특정 작업을 수행할 수 있는 조건 정의 및 권한 부여, 리소스 기반 정책은 인라인 정책 - 리소스 관점이다! 리소스에 부여하는 정책이다.)

-> 리소스에 어떤 사용자가 접근할 수 있는지

-> 자격증명 기반 정책만 있으면 동일한 계정에 있는 리소스에 대해서면 접근을 제어할 수 있지만, 리소스 정책을 사용하면 다른 계정에 있는 사용자가 현 계정에 있는 리소스에 접근 가능하도록 허용해줄 수 있다.

3. Access Control Lists(ACLs)

- 가드레일 (부여 가능한 권한 범위를 제한하는데 사용되는 정책) :
자유 이용권이 있더라도 어리면 놀이기구를 못타는 제한이 있듯이, 권한이 부여되어 있더라도 조직 차원의 안전장치 가드레일로 인해 동작하지 못하도록 할 수 있다.

1. 권한 경계

2. Organication SPCs

3. 세션 정책

[docker] Docker 로그로 가득 찬 디스크 정리 기록

sddev — Mon, 26 Jan 2026 14:48:56 +0900

현상

docker 사용 시, 어느 시점에 /var/lib/docker 용량이 90GB를 넘으면서, 전체 서버 용량을 차지하는 현상 발생

1. 디스크 용량 확인

df -h

→ /dev/vda1 사용률이 100%로 확인됨. 주로 /var 아래가 문제인 경우가 많음.

2. /var 디렉토리 용량 분석

sudo du -sh /* 2>/dev/null | sort -hr | head -n 10
sudo du -sh /var/* | sort -hr | head -n 10

→ /var/lib가 대부분을 차지하고 있었음 (91GB)

3. /var/lib/docker 세부 분석

sudo du -sh /var/lib/docker/*

초기에 Permission denied 에러 발생했으므로 다음과 같이 실행:

sudo bash -c 'du -sh /var/lib/docker/* | sort -hr | head -n 20'

→ /var/lib/docker/containers 가 85GB 로 압도적

4. Docker 로그 파일만 삭제 (핵심)

Docker 컨테이너 로그는 기본적으로 json-file 형식으로 저장됨:

/var/lib/docker/containers/<container-id>/<container-id>-json.log

모든 컨테이너 로그 파일 일괄 삭제:

sudo find /var/lib/docker/containers/ -name '*-json.log' -type f -delete

5. 용량 재확인

sudo bash -c 'du -sh /var/lib/docker/* | sort -hr | head -n 20'
df -h

→ /var/lib/docker/containers 가 436KB로 줄어들고, 전체 디스크 용량도 회복됨

6. Docker 로그 재발 방지 설정 (예방법)

로그 파일 크기 제한 및 순환 설정:

sudo vi /etc/docker/daemon.json

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

설정 반영:

sudo systemctl restart docker

결론

docker system prune -a --volumes 로 전체 정리도 가능(신중)
단순 로그 정리만으로도 수십 GB의 디스크 공간을 확보 가능

# 출처

https://noli.tistory.com/105

[AWS] Agentic AI Factory

sddev — Thu, 22 Jan 2026 13:54:44 +0900

AWS 환경 기반의 멀티에이전트 시스템을 쉽게 구축/운영할 수 있도록 하는 개발 프레임워크

1. Intake request (요구사항 수집 - Vibe coding)
Technical Business Commercial Governance

아래 4가지 개별 Agent를 통해 Agent를 자동으로 생성한다.
- Assessment
- Design(설계)
- Planning
- Implementation(구현)

2. Agentcore Obserbility
- 자동으로 생성된 Agent를 평가하고 보완 수정한다.

3. Supervisor Function
- Agent catalog를 보고 Worker를 실행

[Chapter1 - 1] 디자인 패턴과 프로그래밍 패러다임 - 디자인 패턴

sddev — Wed, 21 Jan 2026 23:36:46 +0900

React.js, Spring 등 라이브러리나 프레임워크의 기본이 되는 디자인 패턴

어떠한 방식으로 로직을 구성해야 하는지에 대한 시각이 담겨 있는 프로그래밍 패러다임

용어 정리 - 라이브러리와 프레임워크

용어 : 라이브러리란? - 미리 만들어진 함수나 코드 모음

공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것을 의미한다.

폴더명, 파일명 등에 대한 규칙이 없고, 프레임워크에 비해 자유롭다.

'내가' 직접 컨트롤하여 사용하는 도구 '가위'와 비슷하다. 도구는 각각의 용도가 있다.

용어 : 프레임워크란? - 소프트웨어 개발 등 특정 목적을 달성하기 위해 재사용 가능한 기본 구조나 설계, 규칙 등을 미리 제공하여 개발을 더 쉽고 빠르게 할 수 있도록 돕는 도구 or 체계

공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것을 의미한다.

폴더명, 파일명 들에 대한 규칙이 있고, 라이브러리에 비해 좀 더 엄격하다.

'내가' 의존해서 사용하는 도구 '비행기'와 비슷하다.

나는 '비행기'가 정해놓은 규칙을 따르고, '비행기'가 복잡한 작업들을 내부적으로 컨트롤한다.

주요 의미
- 뼈대/골조: 건물을 지을 때의 뼈대처럼, 앱이나 웹사이트의 기본 구조를 잡아주는 역할.
- 틀/체계/구조: 정해진 규칙과 도구를 제공하여 개발자가 일정한 방식(틀)으로 작업하게 함.
- 공통 기능 제공: 데이터베이스 연결, 화면 구현 등 반복되는 공통 기능을 미리 만들어 제공해 개발 시간과 비용 절감.

간단한 비유
- 프레임워크: 틀이 짜여진 집, 사용자는 가구(코드)만 채우면 됨.
- 라이브러리(비교): 틀을 직접 짜고 필요한 부품(라이브러리)만 가져다 쓰는 것.
예시: 웹 프레임워크(Django, Spring)는 웹사이트 개발의 기본 구조를 제공하고, 게임 프레임워크는 렌더링이나 파일 입출력 모듈을 제공하는 식입니다

Section 1.1 디자인 패턴

용어 : 디자인 패턴이란? - 소프트웨어 개발 시 자주 발생하는 문제에 대한 검증된 해결책으로, 코드의 재사용성과 유연성을 높여주는 '설계 방식의 표준화된 틀', '설계 기법', '설계 모범 사례'

프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 '규약' 형태로 만들어 놓은 것을 의미한다.

주요 개념
- 정의: 반복되는 디자인 문제에 대한 검증된 해결책을 모아놓은 청사진 (Blueprint).
- 목표: 유연하고 효율적으로 객체와 클래스를 조립하는 방법 제시, 코드 품질 향상.

주요 분류 (GoF 기준)
- 생성 패턴 (Creational Patterns): 객체 생성 과정을 캡슐화하여 유연하게 만듦 (예: 싱글턴, 팩토리 메서드, 빌더).
- 구조 패턴 (Structural Patterns): 클래스와 객체를 조합하여 더 큰 구조를 만듦 (예: 어댑터, 데코레이터, 프록시).
- 행동 패턴 (Behavioral Patterns): 객체 간의 상호작용과 책임 분담에 초점 (예: 옵서버, 전략, 커맨드).

왜 사용하는가?
- 코드 가독성 및 유지보수성 향상: 검증된 구조로 인해 코드 이해가 쉬워짐.
- 생산성 증대: 문제 해결을 위한 고민 시간을 줄이고, 재사용 가능한 솔루션 적용.
- 객체지향 설계 능력 향상: 클래스와 객체에 대한 시야를 넓혀줌.

1.1.1 싱글톤 패턴

용어 : 싱글톤 패턴이란? - 특정 클래스의 인스턴스가 애플리케이션 전체에서 오직 하나만 생성되도록 보장하는 생성 디자인 패턴으로, 단 하나의 객체를 공유하며 전역 접근을 가능하게 하여 리소스 관리나 데이터 공유에 유용하지만, 테스트 어려움, 결합도 증가 등의 단점도 존재

하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴

하나의 클래스를 기반으로 여러 개의 개별적인 인스턴스를 만들 수 있지만, 그렇게 하지 않고 하나의 클래스를 기반으로 단 하나의 인스턴스를 만들어 이를 기반으로 로직을 만드는 데 쓰이며, 보통 데이터베이스 연결 모듈에 많이 사용

장점
- 메모리 절약: 객체를 여러 번 생성하지 않아 메모리 사용을 줄입니다.
- 데이터 공유: 모든 곳에서 동일한 객체를 통해 데이터를 공유하고 관리하기 쉽습니다 (예: 데이터베이스 연결 풀, 설정 관리).
- 엄격한 제어: 전역 변수 사용을 통제하고 하나의 인스턴스만 사용하도록 보장합니다.

단점
- 테스트 어려움: 전역 상태를 공유하므로 단위 테스트(Unit Test)가 어렵고 Mock 객체로 대체하기 힘듭니다.
- 높은 결합도: 여러 클래스가 싱글톤 객체에 의존하게 되어 코드 간의 결합도(Coupling)가 높아질 수 있습니다.
- 책임 과중: 단일 책임 원칙(SRP)을 위반하고, 싱글톤 인스턴스 자체의 관리 책임이 발생합니다.

사용 예시
- 로그 기록(Logger): 시스템 전체에서 하나의 로그 기록 객체를 공유.
- 데이터베이스 연결 풀(DBCP): 여러 곳에서 데이터베이스 연결을 효율적으로 공유.
- 설정 관리(Configuration Manager): 애플리케이션 설정을 한 곳에서 관리

자바스크립트의 싱글톤 패턴

// javascript에서 const 변수 = {}는 Object라는 내부 클래스로 인스턴스를 만드는 것과 동일하다.
const obj1 = { a: 27 } // 또는 new Object({a: 27})
const obj2 = { b: 27 }
console.log(obj1 === obj2) // false

// 일반적인 Singleton 패턴

class Singleton {
  constructor() {
    if (!Singleton.instance) {
    	Singleton.instance = this
    }
    return Singleton.instance
  }
  
  // 보통 아래와 같은 함수를 정의
  getInstance() {
  	return this
  }
}

const a = new Singleton()
const b = new Singleton()
console.log(a === b) // true

// DB 연결 Singleton 패턴

class DB {
  constructor(url) {
    if (!DB.instance) {
      DB.instance = createConnection(url)
    }
  }
  
  getInstance() {
  	return this.instance
  }
}

Java에서의 싱글톤 패턴

class Singleton {
  // private로 생성자를 감춤
  private static class singleInstanceHolder {
    private static final Singleton INSTANCE = new Singleton();
  }
  
  public static Singleton getInstance() {
    return singleInstanceHolder.INSTANCE;
  }
}

public class HelloWorld {
  public static void main(String[] args) {
    Singleton a = Singleton.getInstance();
    Singleton b = Singleton.getInstance();
    System.out.println(a.hashCode() == b.hashCode()); // true
  }
}

Mongoose의 싱글톤 패턴

싱글톤 패턴은 Node.js에서 MongoDB 데이터베이스를 연결할 때 쓰는 mongoose 모듈에서 볼 수 있다.

mongoose의 데이터베이스를 연결할 때 쓰는 connect()라는 함수는 싱글톤 인스턴스를 반환한다.

Mongoose.prototype.connect = function(uri, options, callback) {
  const _mongoose = this instanceof Mongoose ? this : mongoose;
  const conn = _mongoose.connection;
  return _mongoose._promiseOrCallback(callback, cb => {
  	conn.openUri(uri, options, err => {
    	if (err != null) {
        	return cb(err);
        }
        return cb(null, _mongoose);
    }
  });
}

MySQL의 싱글톤 패턴

Node.js에서 MySQL 데이터베이스를 연결할 때도 싱글톤 패턴이 쓰입니다.

// Main Module
const mysql = require('mysql');
const pool = mysql.createPool({
	connectionLimit: 10,
    host: 'example.org',
    user: 'user',
    password: 'password',
    database: 'db'
});
pool.connect();

// A Module
pool.query(query, ...);

// B Module
pool.query(query, ...);

싱글톤 패턴의 단점

TDD(Test Driven Development)를 할 때 걸림돌이 된다.

TDD를 할 때 단위 테스트를 주로 하는데, 단위 테스트는 테스트가 서로 독립적이어야 하며, 테스트를 어떤 순서로든 실행할 수 있어야 합니다.

싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 구현하는 패턴이므로 각 테스트마다 '독립적인' 인스턴스를 만들기가 어렵습니다.

의존성 주입

용어: 의존성이란? - 종속성이라고도 하며 A가 B에 의존성 있다는 것은 B의 변경 사항에 대해 A 또한 변경해야 된다는 것을 의미합니다.

용어 : 의존성 주입(Dependency Injection)이란? - 객체가 필요로 하는 다른 객체를 직접 생성하는 대신, 외부에서 생성하여 주입해주는 디자인 패턴으로, 코드의 결합도를 낮춰 유연성과 유지보수성을 높이며 테스트하기 쉽게 만드는 핵심 기술, 이는 객체 간의 의존 관계를 외부에서 설정하거나 프레임워크(스프링 등)가 대신 관리해주어, 특정 객체의 변경이 다른 객체에 미치는 영향을 최소화합니다.

싱글톤 패턴은 사용하기가 쉽고, 굉장히 실용적이지만 모듈 간의 결합을 강하게 만들 수 있다는 단점이 있습니다.

이때 의존성 주입을 통해 모듈 간의 결합을 조금 더 느슨하게 만들어 해결할 수 있습니다.

주요 개념
- 의존성(Dependency): A 객체가 B 객체를 사용할 때, A는 B에 의존한다고 하며 서로 영향을 주는 관계를 의미합니다.
- 주입(Injection): 의존하는 객체(의존성)를 외부에서 생성하여 주입해주는 행위입니다.

장점
- 결합도 낮춤: 객체 간의 결합도를 낮춰 유연성을 확보합니다.
- 유지보수성 향상: 변경에 대한 영향을 줄여 유지보수가 용이해집니다.
- 테스트 용이: 외부에서 의존성을 주입하므로, 테스트 시 가짜 객체(Mock)를 쉽게 주입하여 테스트할 수 있습니다.
- 재사용성 증가: 코드의 종속성이 줄어 재사용성이 높아집니다.

주입 방식 (스프링 기준)
- 생성자 주입 (Constructor Injection): 생성자를 통해 의존성을 주입하며 불변성이 보장되어 가장 권장됩니다.
- 메서드 주입 (Method Injection): setter와 같은 메서드를 통해 주입합니다.
- 필드 주입 (Field Injection): 필드에 직접 주입하며 코드가 간결하지만 테스트가 어렵고 프레임워크에 종속적이라 비추천됩니다.

예시
- Store 클래스가 Pencil 객체를 사용한다고 할 때, Store 내부에서 Pencil을 직접 생성하는 대신, 외부에서 Pencil 인스턴스를 만들어 Store에 넣어주는 방식이 의존성 주입입니다. 스프링에서는 이러한 과정을 컨테이너가 자동으로 처리해줍니다.