지난 이야기https://for-habit.tistory.com/154 아키텍처 다이어그램, 매번 손으로 그리기 싫어서 자동화해본 이야기발단: Excalidraw는 좋은데 매번 그리기엔 너무 귀찮다우리 팀은 아키텍처 설계하거나 블로그 쓸 때 항상 Excalidraw로 그림을 그린다. 깔끔하고 손그림 느낌도 나고, 뭔가 "엔지니어가 직접 그린" 감for-habit.tistory.com 지난 글에서 아키텍처 다이어그램을 자동화하려고 이것저것 시도했던 이야기를 썼었다. 그때 글을 끄적거리며 깨달은 게 있었는데, Claude가 Excalidraw 파일을 직접 생성할 수 있다는 사실이었다. 어? 이거 되네? 그래서 바로 Claude Code에 Excalidraw JSON 포맷을 가르치는 스킬 파일을 만들기 시작했..

발단: Excalidraw는 좋은데 매번 그리기엔 너무 귀찮다우리 팀은 아키텍처 설계하거나 블로그 쓸 때 항상 Excalidraw로 그림을 그린다. 깔끔하고 손그림 느낌도 나고, 뭔가 "엔지니어가 직접 그린" 감성이 있어서 좋았다.근데 문제는, 이걸 매번 그리는 게 은근 시간이 든다는 거다.컴포넌트 하나하나 배치하고, 화살표 연결하고, 라벨 달고. 거기에 "좀 이쁘게" 만들려면? 색 맞추고, 정렬하고, 간격 조절하고... 생각보다 1시간은 금방 날아간다. 그림 그리는 시간도 결국 비용이다.그래서 생각했다. 이걸 자동화할 수 없을까? 최대한 인간의 개입을 줄이고, 이왕이면 우리 팀이 기존에 쓰던 Excalidraw 스타일로 뽑아낼 수 없을까?첫 번째 시도: MCP로 Excalidraw 직접 편집하기나는 이..

어느 날 갑자기 CI가 깨졌다2026년 2월 둘째 주. 평소처럼 PR을 올렸는데 GitHub Actions가 빨간불이다. 코드 한 줄 바꾸지 않았는데 이전까지 정상 동작하던 CI 테스트가 전부 실패하기 시작했다.로컬에서는 문제없이 통과하고, 일주일 전 동일한 코드로 돌린 CI도 정상인데 갑자기 오류가 발생했다. 당시 CI 로그 CircuitBreakerRedisFailureIntegrationTest > initializationError FAILED java.lang.IllegalStateException at CircuitBreakerRedisFailureIntegrationTest.java:78PlayingHistoryBufferFacadeTest > initializationError FA..

Claude Code에서 Superpowers 설치했더니 키보드가 먹통이 됐다요즘 Claude Code 마켓플레이스에 올라오는 플러그인들이 하나둘 늘어나고 있어서, 나도 이것저것 깔아보는 재미에 빠져 있었다. 그러다 Superpowers라는 플러그인을 발견했다. 스타 수가 5만 개가 넘는 인기 프로젝트길래, 당연히 별 문제 없겠지 싶어서 바로 설치했다.그런데 설치하고 나서 Claude Code를 터미널에서 실행했는데... 아무 키도 안 먹는다.진짜 말 그대로 아무 키도. 타이핑을 해도 글자가 안 찍히고, Ctrl+C도 안 되고, Escape도 안 된다. 커서만 멀뚱멀뚱 깜빡이지도 않고 그냥 굳어있다. 처음엔 뭔가 로딩이 오래 걸리나 싶어서 기다려봤는데, 아무리 기다려도 그대로다.혹시 내가 뭘 잘못 깐 ..

링크드인에서 접한 클로드 해커톤요즘 링크드인을 자주 본다. 이유는 단순하다. 클로드(Claude) 관련 꿀팁들이 링크드인에 미친 듯이 올라오기 때문이다. 국내에서 클로드 관련 최신 정보를 얻으려면 링크드인만 한 곳이 없었다. 덕분에 클로드 코드 관련 여러 가지 팁, 사용법, 워크플로우 같은 것들을 꾸준히 건져 올리고 있었다.그러던 중, 링크드인 피드에 올라온 글 하나가 눈에 확 들어왔다.AI Agent 해커톤 해커톤, 나가게 된 이유평소 링크드인에서 클로드 관련 팁을 주고받던 지인들이 있었는데, 마침 이 해커톤 소식을 보고 "같이 나가볼까?" 하게 되었다. 팀이 꾸려졌고, 우리는 해커톤에 참전하게 됐다.해커톤 개요는 이랬다: 주최: Seoul AI Builders날짜: 2월 7일 토요일, 12:00 ~ ..

관리자가 올리는 컨텐츠가 생명인 프로젝트Hearit은 오디오 기반 IT 학습 플랫폼이다. NotebookLM으로 오디오 콘텐츠를 만들어서 올린다. 당연히 컨텐츠가 핵심이다. 콘텐츠가 안 올라오면 서비스가 죽는다.콘텐츠는 나를 포함한 7명의 팀원이 1개씩, 일주일에 7개씩 올렸다. 근데 어느 순간부터 속도가 줄기 시작했다. 일주일에 3개, 2개... 그러다 어쩔 때는 일주일에 1개만 올라올 때가 있었다.대부분의 팀원들이 콘텐츠를 안 올린 것이다.솔직히 말하면, 귀찮았다원인을 찾아보니 별거 없었다.귀찮아서.다들 바빠지기도 했지만, 솔직히 그게 전부는 아니었다. 콘텐츠 하나 올리는 데 30~40분이 걸렸고, 그 시간 동안 계속 신경을 써야 했다. 집중이 끊기고, 다른 일 하다가 다시 돌아오고, 어디까지 했더라..

“이전에 듣던 지점부터 다시 재생하고 싶어요.”유저 테스트 기간 동안 가장 많이 받은 피드백이었습니다.사용자들은 중간에 멈춘 콘텐츠를 다시 찾는 과정에서 반복적인 불편함을 겪고 있었습니다.이 요구를 그대로 구현하면, 사용자의 상태를 아주 짧은 주기로 지속적으로 저장해야 하는 문제와 마주하게 됩니다.그러나 모든 요청을 즉시 데이터베이스에 기록하는 방식은, 요청 수가 늘어날수록 쓰기 부하와 지연을 빠르게 증폭시키며, 시스템 확장 시 가장 먼저 한계를 드러냅니다.따라서 빈번한 쓰기 요청은 즉시 저장해야 할 대상이 아니라, 조절하고 다뤄야 할 대상이 됩니다.중간에 완충 지점을 두고 불필요한 중복을 제거한 뒤, 의미 있는 시점에 묶어서 저장하는 구조가 필요합니다.더 나아가 서버가 여러 대로 확장되더라도, 모든 인..

프로젝트에서 JPA Auditing 덕분에 @CreatedDate, @LastModifiedDate 덕분에 엔티티 생성·수정 시점을 자동으로 관리할 수 있다!하지만 이 신기방기 편리한 JPA Auditing 을 쓰다보면 불편한 점이 하나 존재했는데 그건 바로 테스트... 시간에 의존하는 로직이 늘어날수록 테스트가 점점 불안정해졌고 “이 테스트가 실패한 게 로직 때문인지, 실행 타이밍 때문인지” 헷갈리는 순간이 많아졌다. 결국 시간 자체를 테스트에서 통제할 수 있어야 한다는 결론에 도달했고 그 과정에서 TestClock 기반의 시간 제어 테스트 인프라를 만들게 되었습니다.문제 상황: JPA Auditing으로 시간고정됨.JPA Auditing을 사용하면 엔티티 저장 시점에 현재 시간이 자동으로 주입됩니다...