knowledge

Wiki

• AOP와 Dynamic Proxy — @Transactional·@Cacheable의 비밀메서드에 @Transactional 하나 붙였을 뿐인데 앞뒤로 트랜잭션이 열리고 닫힌다. 내 코드엔 그런 로직이 한 줄도 없는데. 그 비밀은 스프링이 내 객체를 몰래 '프록시'로 바꿔치기하기 때문이다. AOP와 다이내믹 프록시가 어떻게 부가 기능을 끼워 넣는지 연다백엔드Spring스프링 내부→
• BeanFactory vs ApplicationContext — 스프링 컨테이너의 두 얼굴스프링은 객체를 대신 만들고 관리해 주는 '컨테이너'다. 그 컨테이너의 가장 밑바닥 인터페이스가 BeanFactory이고, 실무에서 실제로 쓰는 건 그 위에 편의 기능을 잔뜩 얹은 ApplicationContext다. 둘의 관계와 차이를 밑바닥부터 짚는다백엔드Spring스프링 내부→
• Bean 생성 과정 — 설계도에서 완성된 객체까지@Component 하나 붙였을 뿐인데 스프링은 그 객체를 알아서 만들어 꽂아 준다. 그 '알아서'의 내부를 연다. BeanDefinition이라는 설계도를 모으고 → 인스턴스를 만들고 → 의존성을 채우고 → 초기화하고 → 후처리로 마무리하는 다섯 단계를 순서대로 따라간다백엔드Spring스프링 내부→
• BeanPostProcessor — 애노테이션이 실제 동작으로 바뀌는 곳@Autowired를 붙이면 값이 채워지고, @EventListener를 붙이면 이벤트를 받고, @Transactional을 붙이면 트랜잭션이 걸린다. 이 '붙이면 저절로'의 정체가 바로 BeanPostProcessor다. 빈 생성 파이프라인에 끼어들어 애노테이션을 해석하는 확장 지점을 연다백엔드Spring스프링 내부→
• DispatcherServlet — HTTP 요청이 Controller까지 가는 길브라우저가 GET /orders/42를 보내면, 그게 어떻게 내 @GetMapping 메서드까지 도달할까. 그 사이엔 DispatcherServlet이라는 '중앙 교통정리원'이 있다. 요청을 받아 어느 컨트롤러로 보낼지 찾고, 인자를 만들어 넣고, 결과를 응답으로 바꾸는 전 과정을 연다백엔드Spring스프링 내부→
• API Gateway — 모든 요청이 지나는 단일 현관서비스가 수십 개로 쪼개지면 클라이언트는 그 주소를 다 알아야 하고, 인증·CORS 같은 공통 처리가 서비스마다 중복된다. 모든 외부 요청을 받아 적절한 서비스로 넘기는 단일 입구 — API Gateway가 무엇을 대신해 주는지 따라간다백엔드MSA네트워크→
• Config Server — 흩어진 설정을 한 곳에서 뿌리기DB 주소·키·플래그가 서비스마다 흩어지면, 값 하나 바꾸는 데 전부 재배포해야 한다. 설정을 중앙에 모아 각 서비스에 내려보내는 Config Server가 무엇을 풀어주는지, 부팅 시점의 흐름과 갱신·암호화까지 따라간다백엔드MSASpring→
• Docker — '제 컴퓨터에선 됐는데요'를 끝내는 법내 컴퓨터에선 도는데 서버에선 안 된다 — 환경이 다르기 때문이다. 앱과 그 실행 환경을 통째로 한 상자에 담아 어디서나 똑같이 돌리는 컨테이너. 이미지·레이어·컨테이너의 관계와, 가상머신과 무엇이 다른지 따라간다백엔드인프라DevOps→
• Eureka — 서비스들이 서로를 이름으로 찾는 전화번호부서비스가 수시로 죽고 살아나고 늘어나는 환경에서, IP를 코드에 박으면 곧 깨진다. 서비스가 자기 위치를 등록하고 서로를 이름으로 찾게 해주는 서비스 디스커버리 — Eureka의 등록·발견·헬스체크 흐름을 따라간다백엔드MSASpring→
• GitHub Actions — 푸시 한 번에 테스트·빌드·배포가 알아서 돌게코드를 올릴 때마다 사람이 손으로 테스트하고 빌드하고 배포하면 느리고 실수가 난다. 'push하면 이런 일들이 자동으로 일어나라'를 코드로 적어두는 CI/CD — GitHub Actions의 워크플로·잡·스텝 구조와 동작 흐름을 따라간다백엔드DevOpsCI/CD→
• Go로 백엔드 짜기 — 단순함과 동시성, 그리고 Gin·ChiGo는 기능을 덜어내 단순함을 택하고, 고루틴으로 동시성을 언어 차원에서 싸게 만든다. 왜 백엔드·인프라에서 Go가 자주 보이는지, 그리고 표준 라이브러리 위에 얇게 얹는 두 웹 프레임워크 Gin과 Chi가 무엇을 더해주는지 따라간다백엔드Go프레임워크→
• Grafana — 흩어진 지표를 한 화면에서 보고 경보 받기서비스가 많아지면 '지금 시스템이 괜찮은가'를 한눈에 볼 방법이 필요하다. 여러 곳에 쌓인 지표를 끌어와 대시보드로 그리고, 이상하면 알림을 쏘는 Grafana가 모니터링 흐름에서 어디에 서는지 따라간다백엔드인프라모니터링→
• 메시지 큐(MQ) — 서비스를 직접 부르지 않고 메시지로 잇기서비스가 서로를 직접 호출하면 상대가 느리거나 죽을 때 같이 무너진다. 사이에 큐를 두면 보낸 쪽은 던지고 떠나고, 받는 쪽은 자기 속도로 처리한다. 비동기 메시징의 원리와, 대표 구현인 Kafka가 무엇이 다른지까지 따라간다백엔드MSA데이터→
• NestJS — Node 백엔드에 '구조'를 강제하는 프레임워크Express는 자유로워서, 규모가 커지면 코드가 사람마다 제멋대로 흩어진다. NestJS는 모듈·컨트롤러·서비스로 자리를 정해주고 의존성 주입으로 조립한다. 그 구조가 무엇을 강제하고 왜 테스트·확장에 유리한지 따라간다백엔드Node프레임워크→
• SAGA — 여러 서비스에 걸친 일을 어떻게 '한 번에' 처리할까DB 하나면 트랜잭션으로 '전부 되거나 전부 안 되거나'가 공짜였다. 주문·결제·재고가 각자 다른 DB로 쪼개지면 그 보장이 깨진다. 중간에 실패하면 앞서 한 일을 되돌리는 보상 트랜잭션 — SAGA 패턴을 따라간다백엔드MSA데이터→
• Spring Cloud — 흩어진 서비스를 하나처럼 묶는 도구 모음서비스를 여러 개로 쪼개면 생기는 공통 문제들 — 설정 관리, 서로 찾기, 입구 통일, 장애 격리 — 을 스프링이 한 묶음으로 풀어주는 게 Spring Cloud다. 각 조각이 무슨 문제를 맡는지 지도부터 그려본다백엔드MSASpring→
• 비밀번호는 어떻게 저장되고, 로그인은 어떻게 유지될까회원가입 때 비밀번호가 평문이 아니라 해시로 저장되는 이유부터, 로그인 한 번으로 다음 요청들이 '나'로 인식되는 세션·JWT의 원리, 그리고 쿠키 보안 옵션까지 — 백엔드 인증의 한 사이클을 순서대로백엔드보안인증→
• 프론트와 백엔드가 요청 & 응답을 주고받을 때프론트엔드가 fetch로 요청을 만드는 순간부터 백엔드가 처리해 응답을 돌려주고, 그 데이터가 다시 화면에 반영되기까지 — 그 사이에 벌어지는 일들을 순서대로프론트엔드백엔드네트워크→