[Coding Standard] 스키마의 주인: DDL을 어디에 둘 것인가
Entity에 필드를 하나 추가한다고 하자.
최근 포스트
[Coding Standard] 페이징 방식: 임의 페이지로 점프할 수 있어야 하는가
목록 조회를 어떻게 반환할지는 이미 정해져 있었다. 계층별 DTO 네이밍 표준이 PagingResult<T>를 만들었고, Repository부터 api까지 그 타입 하나로 올라간다.
[Coding Standard] 컨트롤러 두 종류: JSON과 HTML을 어디서 가를 것인가
패키지 구조 표준은 도메인 안을 네 겹으로 나누고 들어오는 칸을 api라고 불렀다. 그때는 컨트롤러가 한 종류라고 전제하고 있었다.
[Plan] AI가 읽는 층을 따로 만들었다: 압축이 아니라 조준의 문제였다
이 블로그는 글을 쓰는 곳이자 내가 정한 것을 다시 찾아 읽는 곳이다. 그런데 요즘은 나만 읽지 않는다. Claude Code, Copilot, Codex가 이 저장소를 뒤져서 “예전에 뭐라고 정했지?”에 답한다.
[Coding Standard] 성공 응답 상태: HTTP 결과와 공통 봉투를 어떻게 맞출 것인가
예외 처리 표준의 HttpApiResponse에는 success(int status, T data)가 있었다. 하지만 언제 200, 201, 202를 넘길지는 정하지 않았다. 더 큰 문제는 본문의 status만 바뀌고 실제 HTTP 응답은 여전히 200일 수 있다는 점이었다.