제약조건에 대해서 (PRIMARY KEY, UNIQUE, NOT NULL, CHECK)
검증 로직을 어디에 둘 것인가 신입 때 저는 데이터 검증을 전부 애플리케이션 코드에서 했습니다. “이메일은 중복되면 안 돼”, “나이는 0보다 커야 해” 같은 규칙을 서비스 레이어에서 if문으로 막았죠. 그런데 배치 작업, 다른 관리 도구, 직접 날린 SQL처럼 애플리케이션을 거치지 않는 경로가 생기면 그 검증은 무용지물이 됩니다. 데이터의 무결성...
쿠오
AI 검색
키워드가 정확히 일치하지 않아도 의미로 글을 찾아줍니다. 모든 처리는 브라우저 안에서 일어나며 — 서버·API 키·외부 전송이 없습니다. (검색 모델은 처음 한 번만 받고 이후 캐시됩니다.)
📚 오늘의 공부
매일 자동으로 바뀌는 복습 6선 — Network · OS · Algorithm · Database 각 1편 + 랜덤 2편.
전체 글
더보기 →
싱글톤 빈에 상태를 두면 안 되는 이유
스프링 빈이 싱글톤이라 인스턴스 필드를 모든 요청 스레드가 공유한다는 사실과, 지역변수·ThreadLocal로 상태를 분리하는 원칙을 설명한다.
스크롤을 내릴수록 따라오는 목록 — 무한 스크롤 서버 설계
무한 스크롤 UI를 받치는 서버의 연속 조회 계약. 데이터 삽입·삭제 시 생기는 중복·누락을 anchor 기반 안정 페이징으로 막는 법을 다룬다.
DNS는 어떻게 이름을 주소로 바꾸나 — 루트부터 권한 서버까지, 그리고 캐시의 마법
DNS 재귀·반복 질의로 루트→TLD→권한 서버를 따라가는 과정, A·CNAME·MX 등 레코드, 캐시와 TTL, GeoDNS·가중치 라우팅(Route 53), DoH·DoT까지 이름이 IP로 바뀌는 원리를 정리합니다.
텍스트 검색 최적화: phraseto_tsquery
LIKE ‘%검색어%’의 한계 검색 기능을 WHERE content LIKE '%키워드%'로 만들어 두면 처음엔 잘 돌아갑니다. 그런데 데이터가 늘면 인덱스를 못 타서 느려지고, “단어 순서”나 “어절” 같은 건 신경 쓸 수도 없습니다. PostgreSQL은 이런 상황을 위해 전문 검색(Full Text Search) 기능을 내장하고 있는데, 그 핵...
같은 클래스 메서드 호출엔 트랜잭션이 안 걸린다
@Transactional이 프록시 기반 AOP로 동작해 같은 클래스 내부 호출(self-invocation)을 가로채지 못하는 원리와 우회법을 설명한다.
끌어다 놓은 순서를 서버가 기억하게 하기 — 행 재정렬의 저장
드래그앤드롭으로 바뀐 목록 순서를 정수 순서 컬럼에 반영하는 갱신 전략. 전체 재번호, 간격 기반 순서값(LexoRank류), 인접 스왑과 동시성 충돌을 비교한다.
저장된 필터를 다시 열면 그대로여야 한다 — 필터 상태 영속화
사용자가 만든 복합 검색 필터를 프리셋으로 저장하고 복원하는 설계. 정규화 트리플 vs JSON 블롭, 마이그레이션, 저장·적용 시점 검증을 다룬다.
PostGIS 성능 비교: GEOMETRY vs TEXT 저장 방식
“그냥 문자열로 저장하면 안 되나요?” PostGIS를 도입하면서 팀에서 나온 질문이 있었습니다. “어차피 위경도인데 '127.0276,37.4979' 같은 문자열로 TEXT에 저장하고, 필요할 때 파싱하면 안 되나요?” 저장도 단순하고 마이그레이션도 편하니까요. 직관적으로는 geometry 타입이 빠를 것 같았지만, 막연한 느낌 말고 실제로 얼마...