Spring Framework의 주축이 되는 3가지 개념을 말한다.
IoC/DI (제어의 역전 / 의존성 주입)AOP(Aspect Oriented Programming)PSA(Portable Service Abstraction1-1. IoC — 제어의 역전
핵심 객체 생성의 주도권이 개발자 → 스프링으로 넘어가는 것
제어의 역전은 다른 객체를 직접 생성하거나 제어하는 것이 아니라 외부에서 관리하는 객체를 가져와 사용하는 것을 말한다. 클래스 B 객체를 직접 생성하는 것이 아니므로, 어딘가에서 받아와서 사용하고 있다고 추측해볼 수 있다. 이처럼 제어의 역전을 적용하면 객체를 외부에서 관리하게 되고, 실제로 사용할 때에는 외부에서 제공해주는 객체를 받아오게 된다.
스프링에서는 제어의 역전 개념을 중요한 컨셉으로 삼고 있으며, 여기서 외부(= 객체를 관리하는 주체)를 “스프링 컨테이너”라고 한다.
```plain text // 기존 — 개발자가 직접 new OrderService order = new OrderService(new FixDiscountPolicy());
// IoC — 선언만 하면 스프링 컨테이너가 알아서 만들어줌 @Service public class OrderService { … }
핵심: `new`를 개발자가 안 써도 됨. 스프링 컨테이너가 대신 객체를 만들고 관리.
**Q. "제어가 역전된다"는 게 뭔데?**
기존은 개발자 코드가 직접 `new` 해서 객체를 만듦 → 개발자가 주도권.IoC는 `@Service` 달아놓고 기다리면 스프링이 알아서 만들어서 줌 → 스프링이 주도권."누가 만드냐"의 주도권이 바뀐 것 = 역전.
**Q. 결국 코드 어딘가는 고쳐야 하잖아. 기존이랑 뭐가 달라?**
고치는 건 맞음. 근데 **어디를** 고치냐가 다름.기존은 Fix가 OrderService, CartService... 여러 파일에 흩어져 있어서 다 찾아서 고쳐야 함.IoC는 Fix가 AppConfig 딱 한 곳에만 있어서 거기만 고치면 끝.
## **1-2. DI — 의존성 주입**
**핵심** 필요한 객체를 밖에서 파라미터로 넣어주는 것
스프링에서는 객체들을 관리하기 위해 제어의 역전을 사용한다. 그리고 **제어의 역전을 구현하기 위해 사용하는 방법이 DI**다.
의존성 = 없으면 동작 못 하는 관계. OrderService는 DiscountPolicy 없으면 동작 못 함.
```plain text
// 나쁜 방식 — Fix가 안에 박혀있음
class OrderService {
DiscountPolicy dp = new FixDiscountPolicy(); // 바꾸려면 이 파일 직접 고쳐야 함
}
// DI 방식 — 밖에서 넣어줌
class OrderService {
DiscountPolicy dp;
public OrderService(DiscountPolicy dp) {
this.dp = dp;
}
}
@Service
@RequiredArgsConstructor
public class OrderService {
private final DiscountPolicy dp; // 스프링이 알아서 꽂아줌
}
OrderService 코드는 하나도 안 건드리고, 파라미터만 바꾸면 됨.
final + 생성자 주입 조합 권장: 한 번 주입되면 못 바꾸니까 안전하고, 반드시 주입받아야 한다는 걸 강제.
핵심 기술이 바뀌어도 내 코드는 안 바꿔도 됨
스프링이 제공하는 다양한 기술(JPA, MyBatis, JDBC 등)을 추상화해 개발자가 일관된 방식으로 쓸 수 있게 해줌. 어떤 DB 기술을 사용하든 일관된 방식으로 데이터베이스에 접근하도록 인터페이스를 지원함.
```plain text // DB 기술이 바뀌어도 코드는 그대로 repository.save(객체); // JDBC든 JPA든 MyBatis든 똑같이 씀
DIP 원칙을 스프링이 기술(DB, 트랜잭션 등)에 직접 적용한 것. DB 깊이 배우면 더 잘 이해됨.
## **3. AOP — 관점 지향 프로그래밍**
**핵심** 공통 기능(로그, 보안, 트랜잭션)을 따로 빼서 한 곳에서 관리
| **종단 (세로)** | **횡단 (가로)** |
| ------------------ | -------------------- |
| 핵심 로직 (주문, 결제, 배송) | 공통 기능 (로그, 보안, 트랜잭션) |
| 각 기능이 독립적으로 흐름 | 모든 기능을 가로로 횡단하며 적용 |
```plain text
// AOP 없으면
public void 주문() { 로그(); 보안(); /* 주문 로직 */ }
public void 결제() { 로그(); 보안(); /* 결제 로직 */ }
// AOP 있으면
@Aspect
public class CommonAspect { 로그(); 보안(); }
public void 주문() { /* 주문 로직만 */ }
public void 결제() { /* 결제 로직만 */ }
먼저 로컬에서 블로그를 띄우는 것부터 시작했다.
rbenv 로 Ruby 3.3.5 설치bundle install 로 github-pages gem 설치bundle exec jekyll serve 로 로컬 서버 실행생각보다 Ruby 버전 맞추는 게 제일 귀찮았다. macOS 기본 Ruby(2.6)로는 최신 github-pages gem이 안 깔려서, rbenv 로 별도 버전을 따로 잡아줘야 했다.
로컬 실행은 이 명령으로 고정했다.
bundle exec jekyll serve --livereload --force_polling
--livereload : 저장하면 브라우저가 자동으로 새로고침--force_polling : 폴더 경로에 한글이 있으면 macOS가 파일 변경을 감지 못 하는 이슈가 있어서 폴링으로 강제한글 카테고리/permalink를 쓰니 빌드할 때 인코딩 에러가 났다. 쉘 로케일이 C 라서 그랬고, ~/.zshrc 에 로케일을 잡아주니 해결됐다.
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8
jekyll-seo-tag, jekyll-feed, jekyll-sitemap 플러그인 추가_config.yml 에 GTM 스니펫 자동 삽입 구조 (gtm_id 값만 넣으면 <head>/<body> 에 삽입)pages.yml)로 푸시하면 자동 배포되도록 구성여기가 이번 작업의 메인이었다. 매번 마크다운 파일을 직접 만드는 게 번거로워서, Notion 데이터베이스에 글을 쓰면 자동으로 블로그 포스트로 올라오게 만들었다.
구성은 이렇다.
@notionhq/client 로 Notion 데이터베이스를 읽고, notion-to-md 로 본문을 마크다운으로 변환scripts/notion-sync.js 가 각 페이지의 제목·날짜·카테고리·태그 속성을 프론트매터로 만들어 _posts 에 저장notion-sync.yml)가 30분마다 실행되어, 변경이 있으면 커밋·푸시하고 Pages 배포까지 트리거on:
schedule:
- cron: "*/30 * * * *"
workflow_dispatch:
동기화 스크립트는 npm run sync 하나로 돌아간다.
"scripts": {
"sync": "node scripts/notion-sync.js"
}
Notion 속성 이름을 코드에서 정확히 매칭해야 하는데, 대소문자나 공백이 조금만 달라도 값을 못 읽었다. 그래서 속성 이름 매칭을 대소문자·공백 무시 방식으로 바꿔서 안정적으로 읽히게 했다.
이제 Notion에 글만 쓰면 30분 안에 블로그에 자동으로 올라온다. 마크다운 파일을 직접 건드릴 일이 거의 없어졌다.
완벽하지 않아도 일단 굴러가는 파이프라인이 만들어진 게 좋다. 여기서부터 천천히.
]]>기록을 꾸준히 남길 공간이 필요해서 블로그를 만들었고, 너무 복잡하지 않게 오래 가져갈 수 있는 방식으로 시작해보고 싶었다.
앞으로 이곳에는 일하면서 배운 점, 작업하면서 막혔던 부분, 그리고 나중에 다시 보고 싶은 생각들을 천천히 정리해둘 예정이다.
완벽하게 쓰려고 하기보다, 짧더라도 자주 남기는 쪽으로 가보려고 한다.
]]>이 블로그에서는 일하면서 배운 점, 만드는 과정, 그리고 정리해두고 싶은 생각들을 천천히 쌓아갈 예정입니다.
첫 세팅은 GitHub Pages + Jekyll 조합으로 시작했습니다. 가볍고 관리가 쉬워서 개인용 기록 공간으로 잘 맞습니다.