Bonjgi의 Tech Blog

두 점, 혹은 두 시계열이 얼마나 닮았는지 수치로 재는 두 가지 거리. 유클리드 거리의 제곱-합-루트가 각각 무슨 의미인지, 맨해튼 거리와는 어떻게 다른지 직관까지 정리한다.

전통적 기획 문서 네 계층(BRD / PRD / Tech-spec / Task)의 역할을 정리하고, 에이전트 하네스에서 각 문서가 어떻게 소비되는지 분해한다. 1인·소규모 프로젝트에서는 이 계층을 지탱하는 전제 세 가지가 깨지면서 풀 체인이 과잉이 되는 지점을 짚고, Shape Up·Linear·DACI를 참고해 2~3계층 경량 체계로 축소하는 전략을 정리한다. 이 블로그 저장소의 specs / plans 구조를 예로 들어 실제 운용 모양까지 검증한다.

스펙·계획·실행으로 가기 전, 컨텍스트를 맞추는 단계를 위한 여섯 가지 패턴을 같은 축 위에 올려 비교한다. CLAUDE.md, Claude Code memory, Cline Memory Bank, superpowers brainstorming, BMAD Analyst, llm-wiki 3-Layer.

한 오픈소스 Claude Code 포트의 789개 커밋과 ROADMAP.md를 해부해, AI 에이전트가 스스로 로드맵을 읽고 쓰고 반영하는 루프를 어떻게 구축하는지 분석한다. 그리고 내 프로젝트에 도입할 수 있는 실천 레시피로 정리한다.

AI 에이전트 평가의 기본 구조와 핵심 용어(task, trial, grader, transcript, outcome 등)를 원문을 따라 정리한다.

수동 테스트의 한계부터 eval-driven development까지, eval이 에이전트 개발에 가져다주는 가치를 원문을 따라 해설한다.

code-based, model-based, human 세 가지 grader 유형과 코딩/대화형/리서치/컴퓨터 사용 에이전트별 eval 전략을 원문을 따라 해설한다.

에이전트 eval 결과가 매번 다른 이유와 이를 다루는 두 가지 핵심 메트릭 pass@k, pass^k를 원문을 따라 해설한다.

eval이 없는 상태에서 신뢰할 수 있는 eval 시스템을 구축하기까지의 8단계 로드맵과 Swiss Cheese Model을 원문을 따라 해설한다.

claude-obsidian 플러그인의 핵심 스킬인 wiki의 아키텍처, 6가지 모드, 프론트매터 스키마, CSS/Git/MCP 설정을 코드 레벨에서 분석한다.

Obsidian Flavored Markdown의 wikilink, embed, callout, properties, 수식, Mermaid 다이어그램을 코드 레벨에서 분석한다.

소스 1개가 8-15개 위키 페이지로 변환되는 인제스트 프로세스, Delta Tracking, 배치 모드, 모순 플래깅을 코드 레벨에서 분석한다.

Quick/Standard/Deep 3가지 조회 모드, 토큰 예산 관리, 답변 파일링 메커니즘을 코드 레벨에서 분석한다.

8가지 건강 체크 항목, 린트 에이전트, 대시보드/캔버스 맵 자동 생성을 코드 레벨에서 분석한다.

대화에서 가치 있는 내용을 위키 페이지로 저장하는 /save 스킬의 노트 타입 결정, 중복 방지, 자동 wikilink를 코드 레벨에서 분석한다.

웹페이지에서 광고/클러터를 제거하고 정제된 마크다운으로 변환하는 defuddle의 토큰 절감 효과와 wiki-ingest 통합을 분석한다.

3라운드 자동 검색 루프, 신뢰도 점수, 도메인별 규칙, program.md 설정을 코드 레벨에서 분석한다.

JSON Canvas 오픈 표준, 노드 타입 5종, Zone 기반 조직, 자동 배치 알고리즘을 코드 레벨에서 분석한다.

Obsidian 네이티브 데이터베이스의 .base 파일 문법, 필터/수식/뷰 타입, 위키 템플릿을 코드 레벨에서 분석한다.

사용자의 요청을 받은 에이전트가 코드를 쓰기 전에 거치는 스킬 디스패칭 메커니즘을 해부한다.

아이디어가 설계서가 되기까지의 전체 과정 — HARD-GATE, 9단계 체크리스트, 이중 승인 게이트, Visual Companion을 분석한다.

설계서에서 동작하는 코드까지 — 계획 수립, worktree 격리, 서브에이전트 실행의 내부 구조를 추적한다.

빨간불에서 시작하는 품질 루프 — Red-Green-Refactor, 4-phase 디버깅, 증거 기반 완료 선언의 내부 구조.

코드리뷰 요청, 피드백 수용과 거부, 브랜치 마무리까지 — 개발 사이클의 마지막 구간을 해부한다.

스킬, 플러그인, 에이전트 — 비슷해 보이지만 역할이 다른 4가지 도구를 비교하고, 언제 무엇을 쓸지 정리한다.

회귀 문제에서 자주 쓰는 오차 지표 MAE, MSE, RMSE의 의미, 차이, 선택 기준을 예시와 함께 정리했다.

트랜잭션 타이밍, 예외 전파, 실행 순서 등 Spring 이벤트 리스너에서 자주 발생하는 문제들과 해결 방법을 정리했다.

테스트 속도는 35% 차이지만, 프로덕션과 100% 동일한 환경을 보장하는 Testcontainers를 추천하는 이유.

서브에이전트를 병렬로 실행하고 결과를 취합하는 패턴 실습.

PM-엔지니어-QA 세 에이전트가 협업하는 오케스트레이터 워크플로우 실습.

메인에이전트와 서브에이전트간의 통신 살펴보기

Brew bundle로 Brewfile을 만들고, 다른 Mac에 그대로 복원하는 방법.

터미널에서 mas로 App Store 앱을 검색하고 설치하는 방법.

출처 : [진짜 빠르고 편한 파이썬 uv ](https://www.youtube.com/watch?v=1kZ-touiEQ8) 구성과 실행시 간편함 pip 구성시 복잡함 pip 구성시 다음과 같이 매우 복잡하다. [만들 때] python3.13 -m venv .ve

mcp-atlassian을 로컬에서 디버깅하기 위한 간단한 실행 절차.

MCP json에서 STDIO와 SSE 구성 예시를 간단히 정리.

zprofile과 iCloud를 이용해 환경 변수를 여러 Mac에서 공유하는 방법.

Bean Validation과 정적 분석용 null 어노테이션의 차이를 정리.

JFR/JMC와 IntelliJ Profiler를 함께 정리해 본다.

업스트림/다운스트림을 구분하면 무엇이 좋아지는지 정리해 본다.

도메인 서비스의 역할과 repository 의존성에 대한 개인적인 정리.

Byte 범위 오류 수정 경험을 바탕으로 경계값 테스트를 어떻게 구성했는지 정리했다.

Next.js 15와 Velite로 만든 정적 기술 블로그를 시작한다.

모니터의 개념과 wait/notify/notifyAll을 간단히 정리.

제네릭 소거와 바이트코드 메타데이터, 리플렉션의 관계를 정리.

gradle에서 implementation과 api의 의존성 전이 차이를 정리.

위도/경도의 표기 방식과 1도당 거리 차이를 정리.

지구의 기울기와 일조량 차이로 계절이 생기는 이유를 정리.

Fixture Monkey를 쓰면서 느낀 점과 1.0.17 업데이트 요약.

인덱스/샤드 개념과 OpenSearch에서의 제약을 정리.

OpenSearch에서 은전한닢 플러그인을 설치하고 인덱스를 구성한 기록.

PostgreSQL과 MongoDB 벤치마크 결과를 간단히 요약.

pg_dump plain 덤프를 sed로 수정하고 psql로 복구하는 방법.

10진수 실수를 2진수로 바꾸는 과정을 요약.

SpEL로 사칙/논리/관계 연산을 중위표현식 그대로 평가하는 방법.

마틴파울러의 CommandQuerySeparation 을 읽고.마이어의 저서에서 만들어졌다 한다.기본적인 아이디어는 다음과 같다.쿼리 : 결과 반환, (사이드이펙트 없음)명령 : 시스템 상태를 변경. 값을 반환치 않음. (command는 많은 문맥을 지니므로, modi

예전에 이벤트에 거대 객체를 포함하여 발행하는것을 메모리 측면에서 부담스럽다 는 의견을 받은적이 있다.subscriber 의 인자는 publisher가 발행한 객체의 참조 만 갖고있어서 전혀 무관하다.(물론 이벤트에는 필요한것만 담기는게 유지보수성에는 더 좋지만..)매

@Transactional 롤백의 장단점 비교DB에 대한 처리는 모두 깔끔하게 롤백해줌 (이게 정말정말 크다)커밋이 아예 안되므로 병렬테스트시 유리함. 성능도 조금 빠를듯?단점은 @Transactional 의 경계가 생기는 문제가 대부분이고 크리티컬한 편이다.flush

DTO : https://martinfowler.com/eaaCatalog/dataTransferObject.html Local DTO : https://martinfowler.com/bliki/LocalDTO.html

App과 DB 관계에서 이상적인건 1:1이다.그다음으로 이상적인건 1:N 이다.절대 지양해야할것은 N:1 (또는 N:N) 이다.요약하자면, DB의 master(app)은 반드시 1개 이어야 한다.1:1, 1:N, N:1 순으로 설명을 했다.1:1은 설명할 필요없는 가장

쿼리플래닝 : https://www.postgresql.org/docs/current/runtime-config-query.html쿼리성능분석하기 : https://seunghyunson.tistory.com/20

Exec 형식 (e.g RUN "echo", "hello")Shell 형식 (e.g RUN echo hello)CMD, RUN, ENTRYPOINT는 2가지 명령어 실행 형식을 지원하고 있다.셸에서 실행되냐 아니냐의 차이 이다. (Exec는 컨테이너 프로세스에서 실

/opt/homebrew/bin/ 를 보면 다음과 같이 심볼릭 링크들이 걸려있다.여기서, 설치된 파이썬 정보도 볼수 있는데, 3.10 으로 설치되어있다.그래서 명령어도 python pydoc3.11 을 입력해야 했다.따라서 다음과 같이 심볼릭 링크를 걸어줘야 한다.그럼

Transactional 바운더리를 경계로 다음과 같은 동작의 차이가 있다.Audit 처리는 (@CreatedAt, @VErsion 등) 트랜잭션이 끝나고 영속화가 되어야 비로소 갱신된다.지연로딩은 트랜잭션 안에서 동작한다.예시로 코드를 보며 설명해 보겠다.다음과 같이

부동소수점이슈를 먼저 인지 해야 한다. 다음 double의 비교는 실패한다.이러한 부동소수점에 대한 이슈는 아래 영상에서도 재밌게 설명하고 있으니 나중에 참고하자.https://www.youtube.com/watch?v=1qbZ7s9DFq8BigDecimal.

Controller -> Service 처리 과정에서 DTO 패턴을 적용하여 Request, Response객체를 넘기지 않고 한번 변환하는 경우를 종종 보는데, 아래 2가지 방식에 따라 때론 필요 없다고 생각한다.오케스트레이션의 주체에 따라 2가지 패턴이 있는데1\.

LocalDateTime은 쓰기가 편하다. LocalDateTime은 Zone 정보가 필요없다.그래서 IOS 포맷으로 변환시 Zone (또는 Offset) 표기가 빠져 있어서 간결하다.ZonedDateTime.of() 의 경우 Zone 을 꼭 넣어줘야 한다.Offset

KafkaProducer는 물론, spring-kafka의 KafkaTemplate도 send할때는 비동기적으로 처리된다.대체로 Kafka로 메세지를 발행할때 굳이 반환값이 궁금할 일은 없다.하지만 때론, "정확히 브로커까지 전달이 되었는지" 판별이 필요할 때가 있다.

"단일 진실 공급원(SSOT)은 정보 시스템 설계 및 이론 중 하나로 정보와 스키마를 오직 하나의 출처에서만 생성, 편집하도록 하는 방법론이다. 단일 출처를 통해 데이터를 생성, 편집, 접근하므로 데이터의 정합성을 지키고 잘못된 데이터 유통을 방지하고 모두가 동일한 데

Application Service의 메소드를 설계하는 2가지 방법이 있다.1\. 서비스를 Delegator 라고 여기고 설계하기2\. 서비스를 고수준 레이어로 바라보고 설계하기컨트롤러는 서비스에 모든걸 위임하는 패턴이다.Service 메소드 시그니처가 Req와 Res

둘다 가변길이로, Hello 저장하면 5바이트를 사용한다. (인코딩에 따라 다르긴 하다)TINYINT 등등 모두 가변길이라 문자열 저장하는데 저장공간을 염려할 필욘 없을것 같다.대략 b-tree 인덱스를 걸수 있냐 없냐 정도의 차이일듯 하다.text최대크기 65535

juni5 공식문서(https://junit.org/junit5/docs/current/user-guide/> JUnit Jupiter에서 제공하는 어설션 기능만으로도 많은 테스트 시나리오에 충분하지만, 더 강력한 성능과 매처와 같은 추가 기능이 필요하거나 필

16부터 toList가 생겼다.단순히 간결한것 정도로만 알고있었는데 다음과 같은 차이가 있다.원문 링크 : https://binux.tistory.com/146수정이 불가능하다는 장점이 있다.기왕이면 Null도 불허용 했음 더 좋았을텐데 ㅎㅎ

깃헙의 코파일럿 같은건데, 뉴스레터? 블로그? 를 통해 알게 됐다. 개인용으로 무료 이다. Intellij 는 연동 가이드가 별로 없어서 작성해 본다.개발자 아이디 같은건가 보다.개인 무료버전의 코드 위스퍼러는 AWS Builder id로만 인증이 가능하다. 가이드 문

ByteBuffer는 단점이 많다.내부 구조도 알아야하고, immutable 하지도 않고, Thread-safe 하지도 못하다.이런 자료형을 주고받는 코드를 작성하면 실수를 유발할수 있겠다.그것도 아주 치명적이고 찾기도 어려운..도대체 무슨장점이 있어서 KmsClien

크게 2가지로 구분해본다.대칭 키 알고리즘 vs 비대칭 키 알고리즘암호화, 복호화 모두 같은 키를 사용한다.빠르고 안전하다.키관리가 어렵다. (안전한 키 교환 방법이 필요하다.)AES, DESC, BlowfishAES는 128 192, 256가 있는데 256이 가장 안

TaskExecutor 만들때 이런식으로 bean에 등록해서 종종 쓴다.그런데 항상 옵션이 헷갈린다.생각보다 비슷하지만 틀리게 쓴 블로그도 많아서 이번기회에 정리 해 둔다.들어가기에 앞서 Pool 에 대해서.ThreadPoolTaskExecutor 를 디버깅 해보면 다

유튜브 채널 큰돌의터전 영상을 보면서 정리 했다.MongoDB와 MySQL 누가 더 빠를까? wired tiger engine (3.2 부터)1\. snappy 블록 압축 알고리즘 (인덱스와 데이터를 압축해서 관리)2\. BSON 파일은 JSON 처럼 보이지만 디스크

아래와 같이 한쪽으로 노드가 늘어날수 있다.높이(뎁스) 가 다르다. (한쪽으로 편향적이다)이러면 26을 찾을때는 2뎁스, 18을 찾을때는 4뎁스가 된다.그래서 나온것이 B-tree 인덱스.높이가 같다. (밸런스)B-tree 인덱스는 clustered index, non

출처 : https://blog.bytebytego.com/p/ep-43-8-data-structures-that-power다음은 데이터 인덱싱에 사용되는 가장 널리 사용되는 데이터 구조 중 일부입니다.1\. Skiplist: 일반적인 메모리 내 인덱스 유형입

출처 : https://blog.bytebytego.com/i/95179881/how-can-redis-be-used

Redisson? 하이버커넥트 기술블로그 레디스와 분산 락(1/2) - 레디스를 활용한 분산 락과 안전하고 빠른 락의 구현 를 보고 활용하면 좋겠단 생각을 했다. 락 구현방식 2가지를 소개하고 있다. Lettuce 를 이용한 간단한 분산 락 구현 Redisson

서식지를 이동하는 철새 떼의 모습을 예로 들며, 철새가 어떤 본능이나초능력으로 떼를 지어 날아가는 게 아니라, 한마리의 새가 주변을 관찰하는 상호 작용을 통해 다른 새와 거리, 방향을 유지해 날아가는 것이라고 설명했다. 그는 “새들은 이렇게 피드백 루프를 통해 이동하면

출처 : 패스트캠퍼스 Kubernetes와 Docker로 한 번에 끝내는 컨테이너 기반 MSAubunto 18.04 버전t3.medium8081 오픈t3.small 으로 하면 nexus 실행이 정상 동작하지 않는다. 기본스펙은 되고 log 도 딱히 실패로그가 안남아서

https://brew.sh/index_kobrew install awscli gradle adoptopenjdk/openjdk/adoptopenjdk8 redis jqbrew install --cask docker google-chrome slack iter

MySQL 을 사용하고 있는데, UUID 를 사용하면서 성능이슈를 겪은바 있다. 조회 할때도, 조인 할때도 성능이 좋지 않았다. (다른 RDBMS 는 다른결과일수 있다.)UUID는 다음과 같은 단점이 있기때문.상대적으로 큰 크기 (36byte. bigint 는 8byt

brew 로 여러 자바버전을 설치해서 사용해야 하는데 셋팅할때마다 헷갈린다.따로 정리하려고 했는데 이분보다 잘 작성할수 없을거 같아서 링크로 대체한다.https://llighter.github.io/install-java-on-mac/

오늘 MySQL 기본 격리 레벨이 뭔지 의논할 일이 있었다.READ COMMITTED 이냐 REPEATABLE READ 이냐 였다.결론부터 말하자면 READ COMMITTED 를 기본으로 사용하는것은 오라클 이고, 이노디비를 사용하는 MySQL 은 REPEATABLE

태초에 다음과 같이 Order 를 OrderDto 로 반환하는 코드가 있었다.orderMapper는 다음과 같다. 단순히 Dto로 매핑을 해주는 간단한 코드 이다.OrderDto 는 사내에서 거의 모든 클라이언트가 사용중인 규격 이었고, 필요로 하는 모든 정보를 포함해

로컬에 카프카를 설치하고 동기와 비동기 코드 속도차이를 비교 하려고 한다.결과부터 얘기 하자면1만개 처리시 속도차이는 100배 넘게 차이가 났다. (9987519583 / 074682958 = 113.73)상대적인 속도로는 async가 매우 빨라지면 최대 300배도 차

출처 : https://www.inflearn.com/course/infcon2022 모듈을 구분하는 기준 - B.C특징, 성격, 사이클에 맞게끔 경계를 나눠보기.4가지 그룹으로 나눌수 있다.위 4가지 모듈을 기반으로 나눴을때 멀티모듈 gradle 구조.{pr

(레거시 시스템) 개편의 기술 - 배달 플랫폼에서 겪은 N번의 개편 경험기, 권용근 독후감각 레이어마다 깊이(뎁스, 또는 레벨) 을 둬서 한쪽으로만 흐르게 해서 스파게티 코드를 줄인다.eg. Controller -> Service -> Domain역방향은 당연히 다른방

출처 :마이크로서비스 패턴 (책)독후감spring security 를 설정할때 gw 에 설정하자구성서버를 설정했을때 장점들을 알게되었다.관측 가능한 서비스를 위한 섀시 프레임워크들에 대해서 알게되었다서비스메시와 구현체인 이스티오에 대해서 알게되었다.궁금한점gw는 외부

출처 :마이크로서비스 패턴 (책)큰 모놀리식 애플리케이션은 테스트하기 아주 어렵다.테스터블리티 확보는 msa 도입 계기중 하나.msa 는 특유의 복잡성 때문에 반드시 자동화 필요. (상호작용까지)9장은 개론을, 10장은 고급 테스트 개념을 다룬다.

AWS MKS (managed kafka) 를 쓰고있다.Terraform 으로 토픽 생성 등이 관리되고 있는데, 요청한대로 만들어졌는지 확인하기 어려웠다.kafkactl 툴을 소개받았는데, kafkacli 보다 유용해 보여서 정리해 본다.아래영상을 보면 알겠지만 con

출처 : 마이크로서비스 패턴 (책) 8.1 외부 API 설계 이슈 API가 잘게 나뉘어져 있으면 여러번 요청 해야함. UX 저하 유발 클라가 API 구조를 깊게 알고 만들어야하므로 나중에 변경이 어려움 (캡슐화 못함) 방화벽 외부는 저성능. (낮은대역폭 높은지연)

참고1 (영문). https://redis.io/docs/manual/keyspace-notifications/ 참고2 (한글). https://velog.io/@ma2sql/%EB%B2%88%EC%97%AD-Redis-Keyspace-Notifications 참고2

아래 3.1, 3.2 장은 익숙한 내용이 많아서 생략한다. 3.1 마이크로서비스 아키텍처 IPC 개요 3.1.1 상호 작용 스타일 3.1.2 마이크로서비스 API 정의 3.1.3 API 발전시키기 3.1.4 메시지 포맷 3.2 동기 RPI 패턴 응용

문제영역과 해결영역에 대해서 얘기해본다.Junha Baek 님 medium(https://tech.junhabaek.net/ddd-%EC%A0%84%EB%9E%B5%EC%A0%81-%EC%84%A4%EA%B3%84-event-storming-bounded-co

Pageable 인터페이스를 인자로 받을수 있고 실제로는 PageRequest 구현체를 받는것.PageRequest.of 로도 생성이 가능하다./members?page=0&size=3&sort=id,desc&sort=username,desc 와 같은 형식으로 전달 받을

nslookup 명령어를 익혀보자

Overview 기존 코드를 바탕으로 클래스 다이어그램을 그려야 할때가 종종 있다. 클래스 다이어그램을 2가지 방법으로 그릴수 있다. Intellij Java Class Diagram 으로 자동으로 그리기 PlantUML 문법을 작성하여 그리기 Intellij Java Class Diagram 는 자바 클래스 파일을 바탕으로 자동으로 다이어그램을 그려준...

MDC 는 로그에 컨텍스트를 남기는 용도로 사용된다.MDC.put(k,v) , MDC.get(k) 를 이용하여 저장하고 읽을수가 있다.맵과 같은데 특징은 이 맵이 쓰레드 단위로 생성된다.웹프로그램의 가장 앞단인 필터에서 MDC 에 저장하고자 하는 값을 put 하면 된

AWS 서비스의 접두사들이 AWS 와 Amazon 두가지가 있다.Amazon EC2Amazon AuroraAmazon Elasticache Amazon MSK (Managed Streaming for Apache Kafka)Amazon EKS (Elastic Kuber

@Cacheable 이용시 redis 를 활용해서 캐싱할수 있다. 관련된 코드는 이전 포스팅 참고해도 되고, spring cache redis 검색해서 나오는 다른 블로그를 참고 하자.하지만 의존하는 모든 외부 서비스는 장애가 생길수 있다.레디스가 동작하지 않는 동안에

@Cacheable 의 구현체는 여러가지가 있다. 마침 EhCache 와 Redis 2개를 같이 써야 했다.이럴땐 각각의 CacheManager 를 구현하여 빈으로 등록 해두고, @Cacheable 어노테이션의 cacheManager 옵션에 해당하는 이름을 입력하면 입

캐시는 언제까지 캐싱할지, 몇회만큼 캐싱할지 등 구체적인 설정이 가능 해야 한다.모든 캐시 구현체들은 해당 설정들을 조정 할수 있도록 방법을 제공한다.redis 는 기본적으로 TTL 활용할수 있는데 RedisCacheManager 역시 아래 2개의 메소드를 통해 Red