기업 기술블로그의 Testing 관련 글 277개
같은 PR도 어떤 LLM에 어떤 프롬프트로 맡기느냐에 따라 결함이 잡히기도 하고 그냥 묻히기도 합니다. Code Review War는 쓸 수 있는 모든 LLM을 워커로 동원하고 8개 리뷰 관점(페르소나)을 실행 단위로 얹어 PR을 병렬 리뷰한 뒤, 심판 모델의 검증과 결정적 병합을 거쳐 한 장의 라인 단위 리뷰로 만드는 시스템입니다. 이 글에서는 결함을 매설한 샘플 PR과 정답지 자동 채점으로 구성별 품질을 측정하여 단일 모델 대비 결함 탐지가
테스트는 실패하는데 코딩 에이전트가 '완료했다'며 멈춘 적이 있나요? 에이전트가 완료를 스스로 판단하기 때문입니다. 이 판정을 시스템에 맡기는 루프 엔지니어링을 살펴보고, Claude Code /goal을 분석해 Stop 훅으로 재구현해 봤습니다.
스스로 만들고 고치는 자동화, 토스닥터 V2를 다시 만든 이야기
AI 에이전트가 스스로 검증하고 수정하려면, 테스트 결과부터 신뢰할 수 있어야 합니다
들어가며 지난 글 LLM as a Judge를 활용한 CodeBuddy 성능 평가에서는 사내 AI 코드 리뷰 서비스 코드버디(CodeBuddy)의 응답 품질을 어떻게 측정할 것인지를 다뤘습니다. 평가 체계를 세우고 나니 다음 질문이 따라왔습니다. "그래서 이 리뷰가 실제로 무엇을 막아주고 있는가?" 코드버디는 PR을 요약하고(describe), 리뷰하고(review), 개선안을 제안합니다(improve). 정확도는 꾸준히 올라갔습니다. 그런데
AI와 만들수록 Mock은 더 빨리 늘어납니다
컨벤션 문서는 지켜지지 않지만, 컴파일 에러는 지킵니다.
Liquibase와 Testcontainers 위에, 테스트 DB의 조립·격리·캐시를 설계하다
terraform plan은 무엇이 바뀌는지 보여줍니다. 동작하는지는 apply해야 압니다. 그 사이의 낭떠러지를 메운 이야기.
페이지 1 / 16 (총 277개)
