Hello, World!
Test Banner
경력·학력·프로젝트에 선택 요약 필드가 추가되고, 기술스택이 자유 입력+태그 자동완성으로 바뀌었으며, 관심 태그 반영과 기업별 적합도 화면이 새로 생겼습니다.
AI 프롬프트 운영 체계가 완성되어 코칭 품질 개선을 코드 배포 없이 빠르고 안전하게 적용할 수 있게 됐어요.
새 AI 프롬프트가 적용되기 전 표준 테스트를 통과해야 하는 품질 검증 체계를 도입했습니다.
맞춤 변형과 이력서 임포트 결과에 좋아요/별로예요 피드백을 남기면 AI 코칭 품질 개선에 반영됩니다.
PDF·DOCX·PPTX·MD·HWPX 파일 업로드 또는 공개 URL 입력으로 기존 경력기술서를 AI가 분석해 이력서 빌더 양식에 자동 입력합니다.
JFR로 잡은 12분짜리 Jenkins 배치 Hang무신사 물류기술실 WMS팀 — Spring Batch · Jenkins · JFR(Java Flight Recorder) · Aurora MySQL들어가며저희 팀은 무신사의 창고 운영을 책임지는 MWMS(Musinsa Warehouse Management System) 를 만들고 있습니다. 매일 다량의 출고 작업이 인입되면 작업자에게 보낼 피킹 지시서 단위로 작업이 분해되는데, 이 분해 작업을 수행하는 Spring Batch가 한동안 저희를 괴롭혔습니다.본격적인 시작은 이미 한 차례 큰 개선이 끝난 뒤였습니다. Spring Batch의 Tasklet을 Reader/Writer 청크 구조로 전환하고, Writer 안에 박혀있던 조회를 모두 Reader로 끌어올려 장기 트랜잭션을 분해하는 작업이었죠. 그 결과 단건 처리 시간이 평균 526.7초 → 41.2초(12.8배), 최악 케이스가 5,035초 → 113초(44.6배) 줄었습니다.그런데도 사라지지 않는 잔불이 있었습니다. Jenkins Slot 하나가 5분, 어떤 날은 12분 동안 묶이는 현상. 코드는 멀쩡한데, 무엇이 그 시간을 잡아먹고 있는지 재현이 안 됐습니다.이 글은 그 잔불을 추적하기 위해 Java Flight Recorder(JFR) 를 운영에 투입하고, 처음 의심했던 라이브러리가 알리바이를 증명한 끝에 진짜 범인을 찾아낸 추적기입니다.💡 이 글의 대상 독자저희 팀은 중장기적으로 Jenkins 기반 배치를 Temporal 워크플로우 엔진으로 이관하는 로드맵을 수립했으며, 이번 이슈에서 마주한 임계점들 역시 해당 아키텍처 전환을 통해 해결할 예정입니다. 다만 Jenkins로 Spring Batch를 트리거하는 구조는 여전히 많은 기술 조직에서 활용 중이므로, 이관 전까지 안정적인 시스템 운영을 위한 디버깅 사례로서 본 글이 도움되기를 기대합니다. 아울러 JFR은 워크플로우 엔진의 종류와 관계없이 적용할 수 있는 유용한 진단 도구입니다.1. 배경...
주요소식 26년 6월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다. TypeScript 7.0 RC Go로 재작성된 네이티브 컴파일러를 탑재한 TypeScript 7.0의 릴리스 후보(RC)가 공개되었다. 기존 타입 체크 로직과 구조를 그대로 유지한 채 포팅해 6.0보다 약 10배 빠르며, Bloomberg, Figma, Google, Slack, Vercel 등 여러 기업의 팀과 프리릴리스 빌드를 테스트해 왔다. 향후 한 달 내 정식 릴리스될 예정으로, 대규모 코드베이스에서 타입 체크와 빌드 속도로 고생해 온 팀이라면 미리 검증해 볼 가치가 있다. Ship the policy, not the code 프런트엔드와 백엔드처럼 별도로 배포되는 두 시스템에 동일한 비즈니스 규칙을 구현할 때 발생하는 코드 중복과 불일치 문제를 다룬다. 백엔드가 "allowedActions": ["CANCEL"] 같은 결정값을 내려보내거나, CASL이나 JSON Schema 같은 표준 형식으로 정책 자체를 데이터로 직렬화해 전송하는 방안을 제시한다. 마이크로서비스나 BFF 구조에서 규칙 일관성을 고민하는 개발자에게 실용적인 관점을 제공한다. Getting started with loops Claude Code 팀이 코딩 에이전트에게 프롬프트를 반복 입력하는 대신 "루프를 설계"하는 접근을 정리한 글이다. 트리거 방식과 종료 기준에 따라 턴 기반, 목표 기반, 시간 기반, 프로액티브 4가지 유형으로 분류하고, 검증 절차를 스킬(SKILL.md)로 인코딩해 자가 검증 능력을 높이는 방법을 소개한다. 명확한 종료 기준 설정과 대규모 실행 전 파일럿 테스트 등 토큰 사용량 관리 팁도 함께 제안한다. React Doctor AI 에이전트가 작성한 React 코드의 품질 문제를 자동으로 잡아내는 도구다. 상태 관리, 이펙트, 성능, 아키텍처, 보안, 접근성 전반을 검사하며 Next.js, Vite, TanStack, React Native, Expo 등...
메트릭 가시성 확보부터 Prompt Caching 도입까지들어가며안녕하세요, 29CM Pricing 팀에서 백엔드 개발을 맡고 있는 정다해입니다.29CM에서는 상품 속성 추출, 그룹 평가, 고객 응대 등 여러 기능에서 AWS Bedrock 기반 LLM을 사용하고 있습니다. 운영 중 LLM 비용이 꾸준히 증가하는 추세가 관찰되어 비용 구조 분석을 시작했습니다.분석을 시작하자마자 첫 번째 장애물에 부딪혔습니다. AWS Bedrock 콘솔은 일별 토큰·비용 합계는 보여주지만, 어떤 API가 얼마만큼의 토큰을 사용하는지는 API별로 분리해 알려주지 않습니다. 비용은 보이는데 원인이 보이지 않는 상태에서는 어디부터 줄여야 할지 결정할 수 없었습니다.이 글은 LLM 비용 절감을 위해 메트릭 가시성을 먼저 만들고, 비용 발생 원인을 파악한 뒤, Prompt Caching을 도입한 과정을 정리한 기록입니다. 모든 최적화가 끝난 뒤 결과는 이렇습니다.LLM 서비스의 비용은 늘어나는데 어디부터 손대야 할지 막막한 엔지니어에게 이 글이 작은 도움이 되었으면 합니다.1. 문제 정의 — 비용은 보이는데 원인이 보이지 않는다LLM 비용이 늘고 있다는 걸 처음 알아챘을 때, 우리에게 있는 정보는 두 가지였습니다.AWS Bedrock 콘솔이 보여주는 일별 입력 토큰 합계, 출력 토큰 합계, 비용 합계어떤 API가 LLM을 호출하는지에 대한 소스 코드 수준의 추정이 정보로는 아래의 핵심 질문에 답할 수 없었습니다.토큰을 가장 많이 쓰는 API입력 · 출력 · 캐시 읽기 · 캐시 쓰기 비중시간대별 분포 및 호출량따라서 어떤 부분부터 최적화해야 가장 큰 비용 절감 효과를 볼 수 있을지도 판단할 수 없었습니다.첫 번째 문제는 비용이 아니라 가시성이었습니다. 비용을 줄이려면 가시성부터 마련해야 했습니다.2. 첫 번째 작업 — API별 토큰 메트릭 대시보드 구축비용 최적화의 출발점은 가시성 확보였습니다. Bedrock 호출에서 다음 정보를 API별로 추적하도록 메트릭 파이프라인을 만들었습니다....
