Posts
All the articles I've posted.
-
AstroPaper 기본에서 더 얹은 것들 — 블로그를 프로덕트처럼 굴리기
이 블로그는 AstroPaper 를 그대로 두지 않고 '매일 발행하는 1인 콘텐츠 시스템' 관점에서 계속 확장 중. 어떤 문제에 부딪혔고 어떻게 도구로 만들었는지 정리 — 시리즈 페이지 (접기/펼치기) · 플레이그라운드 · KR/EN i18n · Sonnet 5 번역 자동화 파이프라인 · 내부/외부 링크 체커 · Mermaid 로컬 사전 렌더 · Scratch/Inbox 워크플로우 · 종료 프로젝트 자동 숨김 컨벤션 · 보안 스크러빙 지침 · Markdown 사후 검증기 · 사이드바를 걷은 에디토리얼 리디자인 · 정적 사이트에서 매일 갱신되는 발행 잔디 · 성과 우선 포트폴리오 카드. 각 기능마다 '기본 상태에서 뭐가 부족했는가 → 어떻게 해결했는가 → 결과' 3단 구조. 살아있는 문서라 새 기능 추가 시 계속 확장 예정.
-
1인 개발용 재활용 킷 — CLAUDE.md 규범 파일 + 2-에이전트 워크플로우
1인 개발엔 리뷰어 · PM · QA 가 없다. 그 역할을 (1) CLAUDE.md 규범 파일 (2) code-writer + code-reviewer 두 서브에이전트로 인코딩해서 기계가 규율을 강제하도록 만든 셋업. 최근 프로젝트에서 다듬은 결과 중 다른 프로젝트에도 그대로 옮길 수 있는 부분만 뽑아낸 재활용 킷 — CLAUDE.md 골격 · 2-에이전트 워크플로우 6단계 + 3개 운영 모드 (review-only / finalize / review-and-finalize) · 에이전트 프롬프트 템플릿 · 프로젝트 무관 작업 원칙 체크리스트. 권한 의도 분리 (writer 에 git 없음, reviewer 에 Write 없음) 로 커밋이 항상 리뷰 게이트를 통과. 5분이면 새 프로젝트에 심을 수 있다.
-
Spring Boot #2 — REST API 로 CRUD · 레이어드 아키텍처 · 전역 예외 처리기
Spring Boot #1 (첫 실행 · DI) 에 이어 #2 는 REST API 로 CRUD. REST 는 URL + HTTP 메서드의 조합이라는 정의부터 정리 (GET/POST/PUT/DELETE), 컨트롤러에 @GetMapping · @PostMapping · @PutMapping · @DeleteMapping 붙여서 todos CRUD 완성. curl 옵션 (-X 메서드 · -H 형식 · -d 데이터) 정리 및 5스텝 curl 흐름 검증 (생성 → 전체 조회 → 수정 → 삭제 → 최종 조회). 컨트롤러가 로직까지 다 들고 있으니 서비스로 분리 → 레이어드 아키텍처 (Controller = 요청/응답 / Service = 로직 / Repository = 저장). 예외 처리는 커스텀 예외 → 404 응답, 그리고 전역 예외 처리기 (Global Exception Handler) 를 두면 컨트롤러는 그냥 throw 만 하고 응답 매핑은 처리기가 담당 — 자바 #3 편에서 배운 "throw 는 강제 전파" 계약성이 실전으로 확장됨. 시행착오 2건 (참조 클래스 없이 서버 켜기 요청 · 라이브러리 추가 전 패키지 작성) 은 학습 지침에 반영해서 다음부터 재발 방지.
-
Spring Boot #1 — 첫 실행 (bootRun · Tomcat 내장) · @RestController · 의존성 주입 감 잡기
자바 #3 (예외 · 동시성 · Gradle) 을 매듭짓고 오늘부터 Spring Boot. Spring Initializr 로 hello-spring 프로젝트를 뽑고 ./gradlew bootRun 으로 실행 — 터미널이 "80% EXECUTING" 에서 멈춘 것처럼 보이는데 사실은 이미 서버가 8080 에 뜬 상태 (Gradle daemon 이 프로세스를 붙잡고 있어서 진행률이 그렇게 표시됨). Spring Boot 는 Tomcat 을 내장하고 있어서 별도 WAS 설치 없이 8080 이 뜨는 것. 엔드포인트가 없으면 8080 에 접속해도 에러 페이지가 나오고, @RestController + @GetMapping 으로 경로를 지정해야 응답이 붙는다. 이후 의존성 주입 (DI) 감 잡기 — 컨트롤러가 서비스 인스턴스를 new 로 만들지 않는데도 서비스가 주입되는 이유는 스프링이 시작 시 @Service 클래스의 인스턴스를 하나 만들어 빈 (Bean) 으로 보관하고 있다가 컨트롤러 생성자에 자동으로 꽂아주기 때문. 자바 #1 부터 이어진 인터페이스 감각 — 구현체를 모르고 넘겨받아서 쓰는 계약성 — 이 스프링에서 자동화된 형태. 결합도가 낮아지고 테스트가 쉬워지는 이유가 여기 있다.