처음 온 개발자를 위한 기본 경로
CS 감각부터 Linux와 배포까지 흐름을 잡습니다.
20 posts2 steps
Reading Paths
Recent Posts
롤백돼도 남아야 하는 기록: 트랜잭션을 REQUIRES_NEW로 쪼갠 이유
“실패한 시도도 남겨라” 내가 운영에 참여하는 시스템(농산물 생산 이력 관리, 규제 산업)의 감사 로그 요구에는 처음 들으면 갸웃하게 되는 조항이 하나 있었다. 실패한 시도도 남겨라. 로그라는 건 보통 '일어난 일'의 기록인데, 이 요구는 일어나다 만 일 — 시도됐지만 실패해서 데이터에는 아무 흔적도 남기지 못한 일 — 까지 적으라고 말한다. 규제 산업에서는 '누가 무엇을 시도했고 실패했는가'도 … 더 읽기
남의 이름으로 기록된 로그인: ThreadLocal에 남은 유령
고백부터 하겠다 우리 시스템은 한동안, 어떤 로그인을 남의 이름으로 기록하고 있었다. B가 로그인했는데 기록에는 A가 남는 식으로. 먼저 말해두면 이 결함은 원인 규명과 수정이 끝난 '과거 사례'다. 그러니 이 글은 취약점 공지가 아니라 부검 기록 — 사고의 경위와 원인, 재발 방지책을 남기는 포스트모템이다. 시리즈 이름에 SQL이 붙어 있지만 이번 범인은 SQL이 아니다. 그래도 이 시리즈가 … 더 읽기
WITH RECURSIVE로 범인 찾기: 코드 한 줄 안 고치고 끝난 장애
“삭제 버튼이 안 먹어요” 운영 시스템에서 이런 신고를 받으면 머릿속에는 대개 같은 순서로 생각이 흐른다. 최근 배포에 뭐가 들어갔더라. 저 기능을 마지막으로 만진 게 누구더라 — 설마 나인가. 신고를 다 읽기도 전에 커밋 기록부터 뒤지는 것. 코드 쓰는 사람의 오래된 반사신경이고, 대개는 그 반사신경이 맞는다. 이 글은 그 반사신경이 틀렸던 어느 사건의 기록이다. 그리고 이 … 더 읽기
잔량 컬럼은 없다: 조회할 때마다 계산되는 재고
장부에 없는 숫자 퀴즈 하나. 재고 관리 시스템에서 '남은 수량'은 어디에 저장돼 있을까. 대부분 stock이나 remain_qty 같은 컬럼을 떠올릴 것이다. 나도 그랬다. 그런데 내가 운영에 참여하는 시스템(농산물 생산 이력 관리, Spring Boot + JPA/Hibernate + MyBatis + PostgreSQL)에서 가장 중요한 숫자인 '건조물 잔량'은 어느 테이블에도 저장돼 있지 않다. 화면에는 매번 잘만 표시되는 그 숫자가, 데이터베이스 … 더 읽기
15초 걸리던 API: JPA N+1 문제가 보낸 청구서
“목록 화면이 느려요” 목록 화면은 서비스의 현관이다. 사용자가 하루에도 수십 번 여닫는 문이고, 그래서 이 문이 무거워지면 불만은 가장 먼저, 가장 크게 들어온다. 내가 운영에 참여하는 시스템(농산물 생산 이력 관리, Spring Boot + JPA/Hibernate + PostgreSQL)에도 그런 문이 하나 있었다. 수확 이력 목록 API. 조회 버튼을 누르면 응답까지 '10초에서 15초'가 걸렸다. 페이지가 죽은 게 … 더 읽기
SQL을 직접 짜본 게 언제였더라: AI의 리팩토링 계획을 뒤집은 날
편리함의 청구서 오늘 하루 짠 코드를 돌아보자. repository.save()를 몇 번 호출했고, findBy로 시작하는 메서드 이름을 몇 개 지었는가. 그리고 SQL은 몇 줄 직접 썼는가. 나는 마지막 질문 앞에서 오래 멈췄던 적이 있다. 메서드 이름만 지으면 쿼리가 알아서 만들어진다. 복잡한 조회는 이미 있는 XML을 복사해 조건 하나만 바꾼다. 막히면 AI에게 물어본다. 요즘 백엔드의 데이터 접근은 대개 … 더 읽기