하네스 설계 (2) — 모든 결정의 "왜" 이전 글에서는 개인 하네스가 무엇을 하는지를 정리했다. 이 글은 그 각각의 결정이 왜 그렇게 내려졌는지를 다룬다. 설계 문서는 결론만 적기 마련이다. "블랙리스트로 간다", "토큰은 한 턴만 유효하다", "보호 브랜치는 토

나는 Claude Code를 단순한 코드 생성 도구가 아니라, OMC(oh-my-claudecode)와 결합된 AI 개발 워크플로우의 일부로 사용한다.Claude Code: 코드 읽기, 파일 수정, 명령 실행, hook, transcript 등 AI 개발 런타임 제공O

AI 코딩 도구가 쏟아지는 시대, "팀 전체가 일관되게 쓰는 것"이 진짜 경쟁력이다.AI의 발전 속도가 무섭다. 불과 1년 전만 해도 "AI가 코드를 짜준다"는 말이 과장처럼 들렸는데, 지금은 Claude Code, Cursor, Copilot 같은 도구들이 실무 개발

난 문자열을 검색할 예정이기에 문자열을 나누는 기준을 알아보겠다.: 세글자씩 잘라서 역색인 구조로 만들기: 토큰으로 잘라서 역색인 구조로 만들기의미를 가진 최소 단위무엇을 토큰으로 볼지는 토크나이저가 정함PostgreSQL의 ts_parse가 실제로 이렇게 동작함. 2

< 기존 인기순 쿼리 >cursorScore이 없으면 바로 true 되는거로 생각되었는데 첫 페이지에 제대로 반영 못함.< Hibernate가 PostgreSQL에 보내는 실제 SQL >:cursorScore 같은 이름 있는 파라미터가 $1, $2 같은 위치

데이터 규모가 작음 (게시글 수백~수천 건 수준)후보가 적으니 similarity() 전체 계산해도 빠름인덱스 크기가 작고 쓰기 부담 없음구현이 단순 — % 연산자 + ILIKE로 필터링하고 similarity()로 점수 매기면 끝 검색 응답이 체감될 정도로 느려질

커서 기반 페이지네이션 (무한스크롤)최신 기반과 인기 기반으로 무한스크롤이 가능하다.근데 안에서 커서를 지정하는게 인코딩방식으로 한다.내가 필요한건 인기Scroe와 PostId인데, 이걸 넘겨주면 되지 않나?하지만 문제는 인기순으로만 한다면 문제가 없겠지만 전에 다른

Native Query로 similarity() 계산 -> 정렬 -> ID만 반환함 (Join 없이 ID만)JPQL + EntityGraph 활용: ID 목록으로 author 자동 Join fetch 함.: JPA는 세 가지 종류가 있음1\. 메서드 이름으로 자동 생성

그럼 지금 어떤 테스트들을 한거야? 자세하게 설명좀해줘그리고 DB를 어떻게 들어갔어? -> 이거도 뭐한건지 자세히 설명해줘아까 dev와 .env를 본 이유가 뭔지 자세하게 알려줘. 이게 목적이 뭔지오전 5:021\. 어떤 테스트를 한 거야?목적: 구현한 검색 기능이 실

관련도 검색을 하려고 한다. 검색은 게시글 검색우리 서비스에선 제목, 본문, 치료영역, 나이 이렇게 내용이 있음.: 역인덱스 저장 + 역인덱스 탐색<일반 인덱스><역인덱스>: 글자를 세글자씩 쪼개는 것Ex. 개발의 신이 될거예요=> 개발의 / 발의" " /

크게 세가지 방법이 있음Offset커서Keyset방식 : LIMIT와 OFFSET SQL 구문을 사용하여 특정 페이지 번호를 지정해 데이터를 가져옴.특징 : 구현이 간단, 사용자가 특정 페이지로 직접 이동하는 UI에 적합함단점 : 뒤로 갈수록 이전 행들을 모두 읽고 버

이 내용에 대해 쓰는 이유는 토큰이 URL상 노출되어 어떤 원리가 적용되는지 공부하고자 씀HTTP : 웹에서 클라이언트와 서버가 데이터를 주고받기 위해 사용하는 가장 기초적인 약속(프로토콜) -> 요청과 응답이 존재구조: 해더(여기에 토큰), 바디(데이터-JSON,HT

댓글 달기가 성공한 후 eventPublisher.publishEvent() 호출리스너가 @EventLinstner라면 즉시 실행되겠지만, @TranszaztionalEventListner라면 해당 작업을 커밋 후 리스트에 등록을 하도록 요청함.이 리스트에 등록하는 건

Emitter 관리 데이터 : Map<Long, Map<String, SseEmitter>>=> <UserId, <emitterId, SseEmitter>>emitterId : 한 사용자가 가진 여러 통로 고유ID (크롬, 모바일, 사파리 ...)

댓글을 작성할 때, 알림이 가도록 하는게 비즈니스 로직임한 트랜잭션 안에서 댓글 작성 -> DB 저장 -> 알림 발송까지 하면 너무 오래 스레드를 잡고있음.또한 후에 서버가 분리될 수도, SSE가 아닌 다른 외부 시스템을 도입할 수도 있음. 만약 외부와 소통(알림발송)

클로드 에이전트를 사용해야 효율이 올라감subAgents 가 있고 AgentTeams가 있음SubAgents는 비동기적으로 처리 (에이전트끼리 상호 대화 X)AgentsTeams은 동기적으로 처리 (에이전트끼리 상호 대화 함)근데 subagents를 만들고 나중에 상호

SKILL.md 파일에 반복 업무 맡김그럼 프롬포트랑 뭐가 다름?\-> 프롬포트는 재사용성이 떨어짐. 매번 재사용해야하고 일관성이 항상 같다고 보장할 수 없음. 또한 팀공유가 어렵고 트리거 방식임.하지만 SKILLS는 파일로 보관하고 동일한 품질로 진행되며 파일로 보관

세컨드 브레인을 구축해야함새로운 패턴, 해결책, 의사결정 이유에 대해 로컬 마크다운 파일에 저장해야함앱을 개발하는 동안에 마주했던 패턴들이나 해결책 들에 대해 명시해주면, 다음에 비슷한 포인트가 있을 때 이걸 참고하게끔 하면 됨. 근데 이제 이걸 수동으로 할 필요가 없

프로덕션 DB 직접 쿼리 금지, 시크릿 파일 커밋 금지 등폴더 구조를 트리 형태로pnpm dev, pnpm test - Claude가 알아서 빌드 & 테스트 실행비즈니스 로직네이밍 규칙, 커밋 메시지 포맷근데 매번 CLAUDE.MD를 읽기 때문에 크기가 커지면 커질수록