튼튼발자 개발 성장기🏋️

이 글의 코드, 패키지명, 클래스명, 수치는 모두 설명을 위해 바꾼 예시 값이다. 흐름과 비율만 실제와 비슷하게 맞췄다.한 줄 요약전체 테스트가 길게는 1시간 30분씩 걸렸다. 원인은 두 가지였다.여러 빌드를 동시에 돌려서 메모리가 모자랐다. (1시간 30분의 직접 원인)Spring 테스트 컨텍스트가 뜰 때마다 Kotest 람다가 만든 익명 클래스 1만여 개를 클래스패스 스캔으로 읽고 있었다. (단독 실행 25분의 원인)2번을 고치고 나니 단독 실행이 25분에서 12분이 됐다. 이 글은 원인을 좁혀 간 과정과, 검토했다가 버린 방안까지 정리한 기록이다.어떤 문제였나Kotlin + Spring Boot 프로젝트다. 테스트는 Kotest 와 JUnit 5 를 같이 쓰고, 통합 테스트는 Testcontaine..

AI 엔지니어링 노트 Graph Engineering Prompt에서 Graph까지 — AI 시대 엔지니어링 5단계 진화와 실전 적용 TL;DR · 오늘의 결론 결과를 만드는 건 모델이 아니라 설계다 1AI 아웃풋의 품질 = 모델 성능 × 설계 수준. 모델은 모두에게 동일하게 주어진다. 2설계는 5단계로 진화했다 — Prompt → Context → Harness → Loop → Graph 3작업의 복잡도가 설계 수준을 결정한다. 낮은 단계를 건너뛰면 상위 단계는 더 복잡하게 실패한다. 4필요한 건 새 도구가 아니라, 우리가 이미 쓰는 Jira · Confluence · Git을 설계 부품으로 다시 보는 것 01 같은 모델, 다른 결과 — 차이는 설계에서 온다 20..

인증서 및 키 불일치 추적기새로 구축한 SSE 프록시가 배포 검증을 모두 통과하고도 단 한 건의 TLS 연결도 받지 못했던 장애를 추적한 기록이다. 결론은 단순했지만(인증서와 키가 서로 다른 쌍), 거기까지 가는 길에 L4, 방화벽, 구형 클라이언트, nginx 로그 레벨이 차례로 우리를 속였다. 같은 함정에 빠질 사람들을 위해 추적 과정을 그대로 남긴다.배경: SSE 전용 nginx 프록시 구축실시간 시세를 SSE(Server-Sent Events)로 내려주는 백엔드 앞에 전용 nginx 프록시를 새로 두기로 했다. 기존 API 프록시(이하 api-proxy)와 같은 서버에 올리되, SSE 특성(장시간 연결, 버퍼링 금지, 수만 동접)에 맞춘 별도 컨테이너로 완전히 분리했다.클라이언트 ──https:4..

RAG (Retrieval Augmented Generation)LLM의 한계 환각 지식 컷오프 보안 및 개인화 불가Retrieval (검색) 대규모 언어 모델(LLM)이 학습하지 않은 정보를 가져오는 것 질문과 가장 연관성이 높은 문서 조각들을 벡터 DB에서 찾음Augmented (증강) 검색된 문서 조각을 사용자의 원래 질문과 합쳐서 "이 문서를 참고해서 질문에 답해줘"라는 식의 확장된 프롬프트 생성Generation (생성) 제공된 확실한 증거 데이터를 바탕으로 왜곡 없는 정확한 답변을 생성 Caution RAG는 환각을 줄이는 방법이지 완전히 없애는 방법은 아니다. 검색된 문서가 부정확하거나 질문과 관련없는 문서가 들어가면 답변도 틀릴 수 있다.Vector DBEmbedding ..

코드 1도 모르는 비개발자가 회사 문서로 답하는 AI 만들기 ChatGPT는 우리 회사 정책을 모른다. 그런데 알게 만들 수 있다면? 이 글은 코드 한 줄 없이 회사 문서를 학습시킨 Discord AI 비서를 만들면서 겪은 모든 과정과 시행착오의 기록이다. PROLOGUE "우리 회사 휴가 정책 알려줘"라고 AI한테 묻고 싶었다 나는 개발자다. 언젠가 회사 내부 정책이나 내가 담당하는 서비스의 도메인 지식 또는 서비스 정책을 한 번에 알아낼 수 있는 방법을 생각했다. "우리 팀 OKR 진행 상황 정리해줘"라고 물으면 AI는 모른다. "지난주 회의록에서 결정된 사항만 추려줘"도 마찬가지. 우리 회사의 모든 지식은 Google ..

Rules와 Skills의 명확한 분리블로그에서 제시한 .cursor/rules와 .cursor/skills 구조가 인상 깊었다. 나는 그동안 skills를 정의를 하고 사용하더라도 코드 작성 rule에 대해서는 AI에게 지시할 때마다 마크다운 파일에 규칙을 정리해두고 첨부(@ 사용)를 통해 인지하도록 했는데, IDE 레벨에서 프로젝트 구조에 따라 자동으로 컨텍스트를 주입한다는 게 확실히 체계적이다. 특히 globs 옵션으로 특정 경로에서만 규칙을 활성화하는 부분에서 새롭게 한가지 깨달았다. src/queries/**/*.ts 파일을 건드릴 때만 React Query 규칙을 주입하면, 불필요하게 전체 컨텍스트를 차지하지 않으니 토큰 비용도 아끼고 응답도 빨라지겠구나!!!생각해보니 LLM이 이미 아는 내용..

"말로 백 번 설명하는 것보다, 한 번의 강력한 시스템적 통제가 낫다." 바이브 코딩으로 짠 코드, 자꾸 에러가 나고 산으로 간다면 정답은 하네스(Harness)에 있다. 최근 개발 생태계는 '바이브 코딩(Vibe Coding)'이라는 새로운 패러다임에 열광하고 있다. 자연어로 "이런 기능 만들어줘", "이 페이지 디자인을 이렇게 바꿔줘"라고 말만 하면 AI가 뚝딱 코드를 만들어내는 시대다. 개발 속도는 이전과는 비교할 수 없을 정도로 비약적으로 빨라졌다. 하지만 실무 프로젝트에 AI를 본격적으로 도입해 본 사람이라면 깊이 공감할 것이다. AI는 강력하지만, 동시에 아주 위험하다. 기존 코드의 규칙을 무시하거나, 전혀 엉뚱한 아키텍처를 도입해 프로젝트 전체를 망가뜨리기도 한..

우아한형제들 기술블로그에서 [RAG, 들어는 봤는데… 내 서비스엔 어떻게 쓰지?]라는 글을 읽었다. 솔직히 RAG에 대해서는 기본적인 개념만 알고 있고, 실제로 구현해본적은 딱 한 번 있다. 당시에 RAG를 왜 써야하는지, 임베딩을 할때 텍스트(데이터)를 어떻게 청킹해서 벡터화 해야하는지 등 많은 난제에 부딪혔었다. 이 글은 마치 선배 개발자가 옆에서 "우리도 이렇게 삽질했어!"라고 말해주는 것처럼 구체적이고 솔직한 것 같다. 특히 MCP를 먼저 시도했다가 결국 RAG 서버를 직접 구현하게 된 과정이 매우 공감되었다.MCP의 꿈과 현실나도 처음에는 MCP가 뭔가 표준화된 은탄환이 될 줄 알았다. Anthropic에서 제안한 프로토콜이니까 앞으로 모든 LLM 도구들이 이걸 따르지 않을까 하는 기대가 있었다..