techlist.io
KREN

Techlist.io - 한국 테크 블로그 큐레이터

gitlab3분 읽기큐레이션 요약

Git 2.55.0의 새로운 기능은 무엇인가?

Git 2.55.0은 커밋 수정, 대규모 저장소 성능, 여러 원격 저장소 관리, 로그 가독성을 개선한 릴리스입니다. 특히 `git history fixup`, Linux용 내장 fsmonitor, 원격 그룹 대상 `git push`, `git log --graph`의 레인 폭 제한이 눈에 띕니다. 또한 Git 코드베이스의 Rust 도입과 부분 클론에서의 `git grep`, `git cherry` 성능 개선도 주요 변경 사항으로 소개됩니다. ## `git history fixup`으로 기존 커밋 수정 - 기존 방식은 다음 두 단계가 필요했습니다. ```bash git commit --fixup=<commit-id> git rebase -i --autosquash <commit-id>^ ``` - Git 2.55에서는 스테이징된 변경 사항을 지정한 커밋에 바로 반영할 수 있습니다. ```bash git history fixup <commit-id> ``` - 대화형 리베이스 없이 커밋을 수정할 수 있어 절차가 간단해집니다. - 수정된 커밋을 포함하는 다른 로컬 브랜치도 함께 갱신됩니다. - 따라서 스택형 브랜치에서 중간 커밋을 수정하면 관련 브랜치가 자동으로 재배치됩니다. ## Linux용 내장 fsmonitor 데몬 - 대규모 모노레포에서는 `git status`가 전체 작업 트리를 탐색해야 하므로 느려질 수 있습니다. - `core.fsmonitor`를 활성화하면 파일 시스템 변경을 백그라운드에서 감시하고, Git이 변경 가능성이 있는 파일만 확인할 수 있습니다. - 기존 내장 fsmonitor는 Windows와 macOS만 지원했지만 Git 2.55부터 GNU/Linux도 지원합니다. - Linux에서는 권한 상승이 필요한 `fanotify` 대신 `inotify`를 사용합니다. - 저장소의 모든 디렉터리에 감시자를 등록하므로, 큰 저장소에서는 감시자 수 제한을 초과할 수 있습니다. - 필요하면 다음 커널 설정을 늘려야 합니다. ```text fs.inotify.max_user_watches ``` ## 원격 그룹으로 한 번에 push - 기존에는 원격 그룹을 `git fetch`에서만 사용할 수 있었습니다. - 다음과 같이 원격 그룹을 설정합니다. ```bash git config set remotes.forks "origin upstream" ``` - Git 2.55부터 그룹 전체에 브랜치를 push할 수 있습니다. ```bash git push forks main ``` - 지정한 브랜치가 그룹에 포함된 각 원격 저장소로 독립적으로 전송됩니다. - 각 원격 저장소의 `remote.<name>.push` 매핑과 mirror 설정도 개별적으로 적용됩니다. ## `git log --graph`의 레인 폭 제한 - `git log --graph`는 브랜치와 병합 관계를 ASCII 그래프로 표시합니다. - 기여자가 많거나 병렬 브랜치가 많은 저장소에서는 그래프가 지나치게 넓어져 가독성이 떨어질 수 있습니다. - Git 2.55는 그래프의 레인 폭을 제한하는 기능을 제공해 복잡한 커밋 이력을 보다 compact하게 표시할 수 있도록 합니다. ## Rust 도입과 부분 클론 성능 개선 - Git 2.55 릴리스의 추가 주제로 Git 코드베이스 내 Rust 사용 확대가 소개됩니다. - 부분 클론 환경에서 `git grep`과 `git cherry`가 더 빠르게 동작하도록 성능 개선이 이루어졌습니다. - 제공된 글 내용에는 Rust 도입 방식이나 각 명령의 구체적인 개선 수치는 자세히 설명되지 않습니다. 대규모 저장소를 사용한다면 Linux에서 `core.fsmonitor=true`를 활성화하고, `inotify` 감시자 제한을 점검하는 것이 좋습니다. 여러 미러나 포크에 동시에 배포하는 팀은 원격 그룹 push를 활용하면 반복 작업을 줄일 수 있습니다.

원문 읽기(새 탭에서 열림)
RustGitLinuxversion-control+2
github3분 읽기큐레이션 요약

Hubber로서 전환하기

GitHub의 Arthur Searle은 회사의 핸들 중심 문화와 원격 근무 환경, 성별 확정 의료 지원 덕분에 직장에서 비교적 안전하고 자연스럽게 트랜지션할 수 있었다고 말합니다. 이름·대명사 변경 과정의 행정적 마찰은 있었지만, 동료들의 존중과 지지를 통해 자신의 정체성으로 일하는 기쁨을 경험했습니다. 이 글은 트랜스젠더 구성원이 직장에서 겪는 어려움뿐 아니라, 포용적인 환경이 만들어내는 안도감과 기쁨도 함께 보여줍니다. ## IT 지원에서 보안 엔지니어로 - Arthur는 IT 지원과 운영 업무로 커리어를 시작한 뒤, 독학으로 코딩을 배웠습니다. - 동료의 추천으로 GitHub에 입사해 IT Engineering 팀에서 근무했습니다. - 보안 관련 문제와 풀 리퀘스트를 여러 보안 팀에 지속적으로 제기한 결과, 6개월 만에 Enterprise Security 팀으로 이동했습니다. - 주요 SaaS 플랫폼의 인프라를 코드로 이전하는 작업에 참여했고, 옥스퍼드대학교에서 버전 관리 관련 강연도 진행했습니다. ## 핸들 중심 문화가 만든 정체성의 연속성 - 입사 당시 법적 이름은 Ursula였지만, 온라인 핸들은 계속 `gleeblezoid`였습니다. - GitHub의 원격 중심 문화에서는 실명보다 핸들을 자주 사용하기 때문에, 이름을 바꾸더라도 기존의 업무 정체성과 관계를 유지하기 쉬웠습니다. - 다른 회사처럼 모든 사람이 외모와 실명만으로 서로를 식별하는 환경이었다면 트랜지션 과정이 더 어려웠을 것이라고 설명합니다. - 내부 시스템에서 이름과 대명사를 업데이트한 뒤, 대부분의 동료가 자연스럽게 새 이름을 사용했습니다. ## 의료 지원과 원격 근무의 장점 - GitHub는 직원 모두에게 성별 확정 의료와 관련된 복지 혜택을 제공합니다. - Arthur는 해당 혜택으로 다음과 같은 비용을 지원받을 수 있었다고 말합니다. - 음성 훈련 - HRT 처방약 - 상담 및 치료 - 원격 근무 덕분에 출근 복장이나 이동 중 다른 사람의 시선에 대해 걱정할 필요가 적었습니다. - 업무 소통 대부분이 Slack과 GitHub에 글로 남기 때문에, 음성 훈련이나 HRT로 목소리가 변하는 시기에 하루 종일 직접 말해야 하는 부담도 줄었습니다. - 만화 캐릭터 아바타처럼 외모와 성별 표현에서 자유로운 문화 역시 불필요한 추측과 판단을 줄였습니다. ## 직장에서 트랜스젠더로 살아가는 현실 - Arthur는 직장에서 커밍아웃하지 못하거나, 이름 변경 과정에서 행정적 문제를 겪는 트랜스젠더 동료들을 알고 있다고 말합니다. - 새로운 사람을 만날 때마다 자신의 정체성을 반복해서 설명해야 하는 경우도 있습니다. - 본인은 급여 시스템 등에서 법적 이름을 바꾸는 행정 절차를 제외하면 비교적 순조롭게 트랜지션할 수 있었습니다. - 동료들은 그를 특별히 다르게 대하지 않고, 원하는 이름과 대명사를 사용하며 일반적인 동료로 존중했습니다. ## 지지와 긍정적인 감정 - 트랜스젠더로 살아가는 일이 항상 쉽거나 사회적으로 받아들여지는 것은 아니지만, 경험이 고난만으로 정의되는 것은 아니라고 강조합니다. - 직장에서 처음 자신의 이름을 듣고 남성 대명사로 불렸을 때 큰 감동을 느꼈습니다. - 한 동료가 면도 키트를 보내준 일처럼, 동료들의 작은 배려가 강한 소속감과 기쁨을 만들었습니다. - 동료들은 Arthur와 관련된 농담과 밈을 공유하며 그의 트랜지션을 진심으로 축하하고 지지했습니다. - 그는 “항상 남성이었지만, 남성으로 살아가고 사회에 참여할 시간과 지원이 필요했다”고 말하며 글을 마무리합니다. 기업이 트랜스젠더 구성원을 지원하려면 의료비 보장뿐 아니라 이름·대명사 변경 절차, 원격·비동기 소통, 외모에 대한 판단을 줄이는 문화까지 함께 마련해야 합니다. 궁극적으로 중요한 것은 트랜지션을 특별한 사건으로만 다루지 않고, 구성원이 원하는 정체성으로 존중받으며 평범하게 일할 수 있도록 하는 것입니다.

원문 읽기(새 탭에서 열림)
githubslackversion-controlinfrastructure-as-code+3
line4분 읽기큐레이션 요약

프롬프팅에서 워크플로로, AI로 프런트엔드 개발 생산성 끌어올리기

코딩 속도보다 더 큰 병목은 Jira, Figma, Confluence, Slack, Git 등에 흩어진 정보를 모으고 조정하는 비용입니다. 글은 LLM을 단발성 프롬프트 도구가 아니라 반복 가능한 개발 워크플로의 실행 엔진으로 활용해야 한다고 주장합니다. 이를 통해 구현 전 요구 사항을 통합하고, 불확실성을 드러내며, 구현 후 검증까지 자동화하는 오케스트레이션 중심의 프런트엔드 개발이 가능해집니다. ## 프런트엔드 개발의 병목 변화 - 하나의 기능을 구현하려면 여러 시스템을 오가야 합니다. - 요구 사항: Jira - 디자인: Figma - 기술·정책 문서: Confluence - 의사결정과 논의: Slack - 구현과 검증: Git - 프런트엔드 개발자는 이 정보를 통합해 실제 사용 가능한 결과물로 조립하는 역할을 담당합니다. - 주요 부담은 코드를 작성하는 일보다 다음과 같은 컨텍스트 작업에 있습니다. - 티켓과 디자인 분석 - 에지 케이스 확인 - 제품·백엔드 팀과의 동기화 - 기존 코드와 재사용 가능한 구성 요소 탐색 ## 프롬프트에서 반복 가능한 워크플로로 - 단발성 프롬프트는 한 번의 작업에는 유용하지만, 반복성과 누적 효과가 부족합니다. - 워크플로는 입력부터 출력까지의 표준화된 경로입니다. - 여러 시스템에서 관련 컨텍스트 수집 - 요구 사항 요약 - 모호하거나 충돌하는 내용 식별 - 구현 계획과 파일 목록 제안 - 사람이 검토한 뒤 코드 수정 진행 - 이 구조에서 LLM은 단순히 코드를 생성하는 도구가 아니라 워크플로를 실행하는 엔진입니다. - 한 번 구축한 워크플로는 티켓의 내용이 달라져도 동일한 패턴으로 적용할 수 있어 확장성이 높습니다. ## 연결된 개발 컨텍스트와 Noah MCP - LY Corporation의 Noah MCP는 Jira, Confluence, Slack, GitHub 같은 내부 도구를 연결합니다. - AI 에이전트가 사람이 복사해 붙여넣은 정보가 아니라 실제 업무 시스템에 존재하는 컨텍스트를 직접 읽고 추론할 수 있게 합니다. - 이를 통해 개발자는 각 시스템을 수동으로 방문하고 정보를 노트에 조합하는 작업을 줄일 수 있습니다. - 핵심은 AI를 별도의 도구로 사용하는 것이 아니라 기존 업무 흐름 안에 배치하는 것입니다. ## 구현 전 요구 사항 통합 예시 기능은 검색·필터·정렬과 역할 기반 필터 표시가 있는 목록 페이지입니다. 기존 방식에서는 개발자가 Jira, Figma, Confluence, Slack, 코드베이스를 직접 확인한 뒤 계획을 작성합니다. 워크플로 기반 방식에서는 에이전트에게 다음을 요청합니다. - Jira 티켓 분석 - 관련 Confluence 문서 검색 - Slack의 최근 의사결정 확인 - 유사한 코드 구현 탐색 - 코드 수정 없이 다음 결과 반환 - 요구 사항 요약 - 프런트엔드 영향 범위 - 관련 파일 - 구현 체크리스트 - 테스트 체크리스트 - 미해결 질문 에이전트가 도출한 계획에는 다음과 같은 구체적인 정보가 포함됩니다. - `FeatureListPage.tsx`, `FeatureList.tsx` 등 신규 파일 - 기존 `useTableFilters`, `useUrlState` 훅의 재사용 - `GET /api/<feature>`의 기존 페이지네이션 API 활용 - 역할별 필터 표시 - viewer: 검색, 상태 필터, 날짜 범위 - editor: owner 필터 추가 - admin: 내부 전용 플래그 추가 - 필터·정렬·페이지 상태를 URL 파라미터와 동기화 - 로딩, 빈 결과, 검색 결과 없음 상태 구현 ## 숨겨진 요구 사항과 재작업 방지 - Slack 논의에서 필터 상태를 `localStorage`가 아니라 URL에 저장해야 한다는 결정이 발견됩니다. - URL 공유가 가능해지고 - 새로고침 후에도 상태가 유지되며 - 다른 사용자가 동일한 화면을 재현할 수 있습니다. - 코드베이스 검색을 통해 이미 존재하는 훅을 재사용할 수 있습니다. - 불필요한 중복 구현 방지 - 기존 동작과의 일관성 유지 - 개발 시간 단축 - 구현 전에 다음과 같은 미해결 사항도 드러납니다. - 필터·정렬 상태를 URL에 저장할지 여부 - 빈 상태에서 “필터 초기화” 버튼을 제공할지 여부 - 이런 문제를 PR 리뷰 단계가 아니라 구현 전에 발견하면 재작업 가능성을 줄일 수 있습니다. ## 코딩 이후의 폐쇄 루프 검증 워크플로는 코드 생성에서 끝나지 않고 검증 단계까지 포함해야 합니다. - 구현 후 원래 계획과 실제 변경 사항을 대조합니다. - 자동 검증 항목을 실행합니다. - 타입 검사 - 린트 - 관련 단위 테스트 - 스모크 테스트 또는 로컬 검증 흐름 - 에이전트는 다음 결과를 보고합니다. - 통과한 검사 - 실패 후 수정한 문제 - 자동화하지 못한 검증 - UI 상태별 스크린샷이나 확인 메모 - PR 전 남은 위험 요소 - 이 폐쇄 루프를 통해 계획, 구현, 검증이 하나의 연속된 개발 사이클이 됩니다. ## 실용적인 적용 방향 프런트엔드 팀은 먼저 Jira·문서·메신저·코드 검색을 묶은 “구현 전 분석 워크플로”부터 도입하는 것이 좋습니다. 이후 구현 계획 승인, 코드 수정, 자동 테스트, PR 전 검증을 단계적으로 연결하면 단순한 코드 생성보다 재작업 감소와 품질 향상이라는 더 큰 효과를 얻을 수 있습니다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델모델 컨텍스트 프로토콜ReactTypeScript+4
line5분 읽기큐레이션 요약

임베딩 안정화로 검색 리랭킹의 콜드 스타트 문제를 해결하다: LINE Part Time Jobs 적용 사례

LINE Part Time Jobs는 기존 2타워 임베딩 기반 리랭킹의 콜드 스타트와 검색 쿼리 미반영 문제를 해결하기 위해, 임베딩 공간을 날짜별로 안정화하는 후처리 방식을 도입했습니다. 저차원 SVD와 직교 Procrustes 정렬을 통해 매일 재학습되는 임베딩의 연속성을 유지했고, 그 결과 오프라인 전환 nDCG가 약 9%, 클릭 nDCG가 약 4.5% 향상되었습니다. A/B 테스트에서도 서비스 전체 KPI 4.7%, 매출 6.5% 증가를 달성했습니다. ## LINE Part Time Jobs 검색 리랭킹 구조 - 검색 시스템은 다음 두 단계로 구성됩니다. - **검색(retrieval):** 사용자의 쿼리에 맞는 구인 공고 후보를 수집 - **리랭킹(reranking):** 수집된 후보를 사용자별로 재정렬 - 기존에는 별도 배치 파이프라인에서 생성한 사용자·아이템 2타워 임베딩을 활용했습니다. - 사용자 임베딩과 아이템 임베딩의 코사인 유사도를 계산해 검색 결과 순위를 정했습니다. - 이 방식은 실시간 연산 부담을 줄일 수 있지만 다음 한계가 있었습니다. - 검색 쿼리와 역, 거리 같은 화면별 정보가 임베딩에 충분히 반영되지 않음 - 검색 외 추천 모듈이나 LINE 공식 계정에서 발생한 행동까지 함께 포함됨 - 검색 화면에 특화된 사용자 의도를 정밀하게 반영하기 어려움 ## 전용 리랭킹 모델 도입 과정의 문제 ### 공고 교체로 인한 콜드 스타트 - LINE Part Time Jobs의 공고는 월초에 대부분 교체됩니다. - 새로운 공고에 대한 클릭·지원 데이터가 충분히 쌓이기 전에는 전용 리랭킹 모델이 학습할 데이터가 부족합니다. - 그 결과 공고 교체 직후 모델 성능이 크게 저하되는 콜드 스타트 문제가 발생했습니다. ### 매일 변하는 임베딩 공간 - 2타워 모델은 성능 유지를 위해 주기적으로 랜덤 가중치에서 처음부터 재학습됩니다. - 재학습할 때마다 임베딩 공간의 방향과 좌표계가 달라질 수 있습니다. - 따라서 오늘 생성한 임베딩과 어제 생성한 임베딩은 실제 의미가 비슷해도 벡터 좌표상 직접 비교하기 어렵습니다. - 학습 시점과 추론 시점에 서로 다른 버전의 임베딩을 사용하면 다운스트림 리랭킹 모델의 입력 분포가 달라져 성능이 떨어질 수 있습니다. ## 임베딩 안정화 방식 - 각 날짜의 임베딩을 전날 안정화된 임베딩 공간에 맞춰 정렬합니다. - 첫날 임베딩은 별도 변환 없이 기준으로 사용합니다. - 이후에는 전날 결과를 다음 날의 기준으로 삼아 임베딩 공간을 순차적으로 연결합니다. - 이 방식은 특정 기준일에 모든 임베딩을 맞추는 대신, 시간에 따른 공간의 연속성을 유지합니다. - 결과적으로 임베딩 피처와 다운스트림 모델의 업데이트 시점을 엄격히 일치시키지 않아도 됩니다. ## 저차원 SVD와 직교 Procrustes ### 저차원 SVD - 아이템 임베딩과 사용자 임베딩을 각각 행렬 \(T\), \(W\)로 표현합니다. - 2타워 모델의 점수는 \(TW^\top\)로 계산되지만, 이 대규모 행렬을 직접 분해하지는 않습니다. - 대신 저차원 SVD를 사용해 변환 행렬 \(M_T\), \(M_W\)를 구합니다. - 변환 결과는 다음과 같습니다. - 아이템 임베딩: \(T' = TM_T\) - 사용자 임베딩: \(W' = WM_W\) - 이를 통해 각 학습에서 생성된 임베딩을 보다 표준화된 저차원 표현으로 변환합니다. ### 직교 Procrustes 정렬 - 당일 임베딩과 전날 안정화된 임베딩이 최대한 일치하도록 직교 변환을 계산합니다. - 직교 변환은 회전과 반전만 수행하므로 벡터 간 거리와 내적 구조를 보존합니다. - 따라서 임베딩의 유사도 기반 점수 계산 특성을 유지하면서 일별 공간 차이를 보정할 수 있습니다. ## 대규모 데이터 처리를 위한 구현 - 데이터 규모가 크기 때문에 알고리즘을 Apache Spark 기반 분산 처리로 구현했습니다. - 저차원 SVD에서는 원 논문의 QR 분해 대신 숄레스키 분해를 사용했습니다. - Gramian 행렬 \(G = A^\top A\)를 계산 - \(G = R^\top R\) 형태로 숄레스키 분해 - QR 분해에서 필요한 상삼각 행렬 \(R\)을 효율적으로 획득 - 직교 Procrustes에서는 다음과 같이 처리했습니다. - 대규모 행렬곱 \(M = B^\top A\)는 Spark로 분산 계산 - \(M\)은 임베딩 차원 \(e \times e\)의 작은 행렬이므로 SVD는 단일 노드에서 NumPy로 계산 - 대규모 벡터 데이터와 소규모 변환 행렬을 구분해 계산 자원을 효율적으로 배분했습니다. ## 안정화 효과와 평가 결과 - 안정화 전에는 서로 다른 날짜의 임베딩 상관관계가 거의 0에 가까웠습니다. - 안정화 후에는 다음 수준의 유사도를 유지했습니다. - 일주일 후: 약 0.88 - 한 달 후: 약 0.87 - 안정화하지 않은 임베딩을 다운스트림 모델에 추가하면 공간 불일치로 nDCG가 약 1~5% 하락했습니다. - 안정화된 임베딩을 사용한 경우: - 전환 nDCG 약 9.0% 향상 - 클릭 nDCG 약 4.5% 향상 ## A/B 테스트 결과와 해석 - 안정화된 임베딩과 콜드 스타트 대응책을 결합한 모델을 온라인 실험했습니다. - 검색 화면 단독 KPI에서는 통계적으로 유의미한 개선이 뚜렷하지 않았습니다. - 그러나 서비스 전체 기준으로는 다음 성과를 얻었습니다. - KPI 4.7% 향상 - 매출 6.5% 향상 - 이는 임베딩이 검색 화면뿐 아니라 서비스 전반의 사용자 행동과 장기적인 선호를 반영했기 때문으로 분석됩니다. - 검색 이후 다른 페이지로 이동하거나 다른 추천 모듈에서 지원하는 행동까지 긍정적인 영향을 받은 것으로 보입니다. - 기존 2타워 모델 구조나 학습 파이프라인을 변경하지 않고 임베딩 후처리만 추가했다는 점도 운영상 중요한 장점입니다. ## 실용적인 결론 재학습마다 좌표계가 달라지는 임베딩을 다운스트림 모델의 피처로 사용할 때는 날짜별 공간 정렬이 효과적인 해결책이 될 수 있습니다. 특히 저차원 SVD와 직교 Procrustes를 결합하면 임베딩의 유사도 구조를 유지하면서 버전 불일치와 드리프트를 줄일 수 있으므로, 기존 모델을 크게 변경하기 어려운 대규모 추천·검색 시스템에 적용하기 적합합니다.

원문 읽기(새 탭에서 열림)
머신러닝apache-sparkonline-learningtwo-tower-embedding+4
toss4분 읽기큐레이션 요약

누군가는 토스를 테스트하는 동안, 우리는 테스트하는 법을 만듭니다.

토스 QA Platform 팀은 매주 수백 건의 변경이 포함된 앱을 안정적으로 배포하기 위해, 테스트와 품질 관리의 표준화를 추진하고 있습니다. 단순히 테스트 도구를 제공하는 데 그치지 않고, AI와 자체 플랫폼을 활용해 테스트 실행부터 결함 분석, 출시 후 대응까지 효율화하려 합니다. 궁극적으로는 사람이 중요한 판단에 집중하고, 반복적인 검증은 자동화하는 것이 목표입니다. ## 매주 반복되는 릴리즈 검증 - 토스는 매주 새로운 버전을 배포하며, 한 번의 릴리즈마다 평균 300~400건의 코드가 변경됩니다. - 릴리즈 후보가 올라오면 다음 순서로 검증합니다. - **토스닥터(Toss Doctor)**: 로그인부터 탈퇴까지 핵심 기능을 빠르게 확인하는 스모크 테스트 - **PRCheck**: 변경된 코드와 영향 범위, 버그 위험도, 테스트 우선순위 분석 - **토스체커(Toss Checker)**: 기존 기능이 손상되지 않았는지 확인하는 전사적 리그레션 테스트 - 배포 후에는 크래시 지표를 모니터링하고, 문제가 발생하면 핫픽스를 즉시 배포할지 다음 릴리즈에서 해결할지 판단합니다. - 핫픽스는 사용자에게 추가 업데이트를 요구하므로, 단순히 빠른 대응보다 재발 가능성과 해결의 안전성을 함께 고려합니다. ## 토스 전체의 품질을 지원하는 QA - QA Platform 팀의 역할은 특정 제품의 테스트에 국한되지 않습니다. - QA를 처음 시작하는 팀에 테스트 방향을 제시하고, 사내 도구의 품질을 보증하며, 조직 단위의 QA 프로세스 설계를 지원합니다. - 목표는 누구나 쉽게 테스트 케이스를 만들고, 빠르고 정확하게 테스트할 수 있는 환경을 구축하는 것입니다. - 이를 통해 개별 팀이 아닌 토스 전체의 품질 수준을 끌어올리려 합니다. ## 토스 품질의 세 가지 표준 - **매번 신뢰할 수 있는 배포** - 한 번 성공하는 것이 아니라 매주 일정한 품질과 신뢰성을 유지하는 것이 중요합니다. - **결함을 정확히 발견하는 테스트** - 테스트의 양보다 실제 사고로 이어질 가능성이 높은 결함을 놓치지 않는 것이 핵심입니다. - **효율적인 품질 보증** - 반복 작업을 사람의 수작업만으로 처리하지 않고 자동화해, 지속 가능한 방식으로 품질을 유지해야 합니다. - 올해는 여기에 AI를 활용해 자동으로 수행되는 테스트의 범위를 넓히고 있습니다. 다만 모든 판단을 AI에 맡기기보다, 사람은 사람의 판단이 필요한 영역에 집중하도록 역할을 나눕니다. ## 자체 QA 플랫폼 ‘토션’ - 상용 도구는 토스의 빠른 배포 주기와 업무 방식에 맞게 유연하게 바꾸기 어려웠기 때문에 자체 플랫폼 **토션(Tossion)**을 개발했습니다. - 토션은 처음에 TestRail을 대체하는 플랫폼으로 시작했습니다. - 테스트 케이스 작성 - 테스트 실행 - 결과 기록 - 테스트 관련 봇 통합 - 여러 봇은 **토스버틀러(Toss Butler)**라는 하나의 봇으로 통합해 토스의 업무 흐름에 맞췄습니다. - 이후 다음 기능들이 추가됐습니다. - **PRCheck**: PR 변경 사항을 분석하고 테스트가 필요한 영역을 제시 - **tcgen**: PRD, 디자인 문서 등 여러 맥락을 바탕으로 테스트 케이스 초안 자동 생성 - **자동화 테스트 플랫폼**: 매뉴얼 테스트와 자동화 테스트 결과를 한 화면에서 비교 - **Crash Trend 대시보드**: 크래시의 발생 추세와 토스에 적합한 지표를 분석 - **핫픽스 대시보드**: 장애 원인 분류와 재발 방지 대책 관리 ## 도구 제공만으로는 부족했던 이유 - 팀은 테스트 케이스를 쉽게 만들면 사람들이 테스트를 더 적극적으로 수행할 것이라고 예상했습니다. - 하지만 tcgen을 공개한 뒤 기대만큼 사용되지 않았습니다. - 실제 사용자가 원한 것은 테스트 도구가 아니라 다음과 같은 지원이었습니다. - 누군가 테스트를 빠르고 정확하게 대신 수행할 것 - 테스트 결과의 품질까지 책임질 것 - 도구를 제공하는 것은 사용자 입장에서 업무를 줄이는 것이 아니라 새로운 업무를 넘기는 일이 될 수 있었습니다. - 이에 따라 QA Platform 팀은 도구를 제공하는 데서 나아가, 직접 테스트를 처리하고 품질까지 책임지는 방향으로 전략을 바꿨습니다. ## AI와 빠른 방향 전환 - AI는 빠르게 발전하기 때문에 어제 효과적이었던 방식이 오늘에는 낡을 수 있습니다. - QA 도구가 품질 향상을 돕기보다 변화 속도를 늦추지 않도록, 지속적인 검토와 폐기가 필요합니다. - 실제로 API 테스트를 위한 **API Labs**는 방향이 맞지 않다고 판단해 개발 8시간 만에 폐기했습니다. - 토션, 토스닥터, 토스체커, 자체 스킬들도 완성된 제품이 아니라 필요하면 언제든 교체할 수 있는 시스템으로 설계됐습니다. - AI가 도구를 만드는 속도는 높여도 다음 문제를 대신 결정하지는 못합니다. - 무엇을 품질로 정의할 것인가 - 어떤 기준을 끝까지 지킬 것인가 - 어떤 테스트를 사람에게 맡길 것인가 - 따라서 품질 기준을 세우고 도구의 방향을 조정하는 일은 여전히 QA 팀의 핵심 역할입니다. ## 앞으로 이어질 이야기 - 이후 시리즈에서는 다음 주제를 구체적으로 다룰 예정입니다. - 토션이 어떻게 시작됐는지 - 토스닥터가 배포 전 무엇을 검증하는지 - 토스체커가 증가하는 회귀 테스트를 어떻게 자동화하는지 - 지능형 AI 봇이 여러 도구를 어떻게 연결하는지 - 토스 QA Platform 팀은 매주 반복되는 변화 앞에서 “정말 배포해도 괜찮은가”를 확인하며, 테스트를 수행하는 방법 자체를 만들어가고 있습니다. 실용적으로는 테스트 도구를 도입할 때 기능 수보다 사용자의 실제 부담을 줄이는지 먼저 검증해야 합니다. 또한 AI 기반 QA 시스템은 완성품으로 보기보다, 품질 기준과 업무 방식의 변화에 맞춰 빠르게 교체·개선할 수 있도록 설계하는 것이 중요합니다.

원문 읽기(새 탭에서 열림)
AItest-automationregression-testingrelease-management+4
google4분 읽기큐레이션 요약

동결된 멀티 토큰 예측으로 Pixel에서 Gemini Nano 모델 가속하기

기존 Gemini Nano v3 모델을 다시 학습하지 않고도 Multi-Token Prediction(MTP)을 추가해 Pixel 기기에서 온디바이스 추론을 가속하는 방법을 소개한다. 별도의 드래프터 모델 대신 본 모델에 가벼운 MTP 헤드를 붙이고, 기존 KV 캐시를 공유하는 zero-copy 구조를 사용해 메모리와 지연 시간을 줄였다. 그 결과 Pixel 9·10의 일부 기능에서 토큰 생성 속도가 50% 이상 향상되고, 인스턴스당 최대 130MB의 메모리를 절약했다. ## 모바일에서 자동회귀 생성이 느린 이유 - 기존 언어 모델은 한 번에 하나의 토큰만 생성하므로, N개 토큰을 만들려면 대형 모델의 추론을 N번 수행해야 한다. - 모바일 기기는 서버보다 RAM과 전력 예산이 제한적이다. - 토큰을 순차적으로 생성하는 과정은 연산 자원을 충분히 활용하지 못하고 메모리 대역폭과 배터리를 많이 소모한다. - 알림 요약, 메시지 교정처럼 짧은 응답도 빠르게 처리해야 하므로 추론 효율이 사용자 경험에 직접 영향을 준다. ## 별도 드래프터의 한계와 MTP - speculative decoding은 다음과 같은 두 단계로 동작한다. - **Draft:** 작은 드래프터 모델이 여러 후보 토큰을 빠르게 생성한다. - **Verify:** 대형 모델이 후보들을 병렬로 검증하고, 일치하는 토큰만 수용한다. - 별도 드래프터 모델은 추가 파라미터와 RAM을 필요로 한다. - 본 모델이 이미 계산한 풍부한 의미 정보를 활용하지 못하고, 텍스트 이력만으로 후보를 예측한다. - MTP는 별도 언어 모델 대신 본 모델의 마지막 층에 경량 Transformer 기반 MTP 헤드를 추가한다. - MTP 헤드는 본 모델의 hidden state를 이용해 여러 미래 토큰을 예측하고, 본 모델은 이를 병렬 검증한다. - 이러한 구조를 글에서는 본 모델의 깊은 지점에서 빠져나와 토큰을 예측하는 **“late exit” 전략**으로 설명한다. ## 동결된 백본에 MTP 헤드 추가 - 이미 배포된 Gemini Nano v3의 가중치는 그대로 동결한다. - 새로 학습하는 부분은 미래 토큰 예측을 담당하는 MTP 헤드뿐이다. - 기존 모델 전체를 다시 사전 학습하거나 별도 드래프터를 작업별로 미세 조정할 필요가 없다. - 백본을 동결하므로 기본 모델의 성능과 안전 정렬을 변경하지 않는다. - 잘못된 후보 토큰은 검증 단계에서 폐기되기 때문에 최종 출력은 기존 대형 모델과 비트 단위로 동일하다. - 따라서 기존 모델과의 하위 호환성을 유지하면서 추론 효율만 개선할 수 있다. ## KV 캐시를 공유하는 zero-copy 구조 - 일반적인 별도 드래프터는 자체 KV 캐시를 생성하고 유지해야 하므로 메모리를 중복 사용한다. - 제안된 MTP 헤드는 본 모델의 KV 캐시에 직접 cross-attention으로 접근한다. - 별도 프롬프트 처리(prefill)나 독립적인 과거 문맥 저장이 필요하지 않다. - 주요 효과는 다음과 같다. - 드래프터가 프롬프트를 다시 처리하지 않아 prefill 지연 감소 - 드래프터 전용 임베딩 테이블과 attention 구조 제거 - 애플리케이션별 튜닝 파라미터 및 중복 KV 캐시 절감 - standalone 드래프터와 비교해 인스턴스당 최대 130MB의 메모리를 절약했다. ## 풍부한 표현이 만드는 예측 정확도 향상 - MTP 헤드는 대형 백본이 이미 계산한 최종 hidden state를 활용하므로 별도 드래프터보다 정확한 후보를 생성한다. - Pixel 9에서 비슷한 규모의 standalone 드래프터보다 작업에 따라 50% 이상의 속도 향상을 보였다. - 복잡한 지시를 따르는 요약·재작성 작업에서 MTP가 크게 우수했다. - 스마트 답장처럼 문장 구조가 예측 가능한 작업에서는 본 모델의 구문 패턴을 잘 학습했다. - 이런 작업에서는 토큰 수용률이 최대 55% 향상됐다. ## Pixel 실사용 결과 - Gemini Nano MTP는 Pixel 9 및 Pixel 10 시리즈에 배포됐다. - 검증과 드래프팅 사이의 의존성을 처리하도록 온디바이스 추론 스택도 함께 재설계했다. - AI 알림 요약과 Proofread 같은 실제 작업에서 추론 한 번당 평균 약 2개의 추가 토큰을 정확히 예측했다. - 수용되는 토큰이 많아지면서 전체 검증 횟수가 감소했다. - 무거운 프로세서를 깨우는 횟수도 줄어들어 응답 시간이 짧아지고 배터리 사용량이 감소했다. ## 실용적인 결론 이미 배포된 온디바이스 모델을 유지해야 하는 경우, 별도 드래프터를 추가하는 것보다 동결된 백본에 MTP 헤드를 붙이고 KV 캐시를 공유하는 방식이 효율적이다. 특히 메모리와 전력이 제한된 모바일 환경에서 모델 출력의 동일성을 유지하면서 속도와 배터리 효율을 함께 개선할 수 있는 현실적인 최적화 전략이다.

원문 읽기(새 탭에서 열림)
쿠버네티스transformeredge-computingspeculative-decoding+3
github4분 읽기큐레이션 요약

모델과 작업별 GitHub Copilot 에이전틱 하니스의 성능 및 효율성 평가

GitHub은 모델 자체의 지능뿐 아니라 도구·컨텍스트·작업 흐름을 조율하는 에이전틱 하니스(harness)가 실제 성능을 좌우한다고 주장합니다. 동일한 모델과 작업을 기준으로 비교한 결과, GitHub Copilot 하니스는 모델 제공업체의 하니스와 비슷한 작업 해결률을 유지하면서 대부분 더 적은 토큰을 사용하는 것으로 나타났습니다. 따라서 하나의 하니스를 개선하면 Copilot CLI, 앱, 코드 리뷰, IDE 등 여러 제품 경험이 함께 향상된다는 결론입니다. ## 에이전틱 하니스의 역할 - 모델은 기본적인 추론 능력을 제공하지만, 하니스가 그 능력을 실제 작업에 적용하는 방식을 결정합니다. - 하니스는 다음 요소를 조율합니다. - 사용할 도구 - 모델에 제공할 컨텍스트 - 작업 실행 순서와 워크플로 - 메모리 및 MCP 서버 활용 - GitHub Copilot의 하니스는 Copilot SDK의 공통 구성 요소입니다. - Copilot CLI, Copilot 앱, Copilot 코드 리뷰, VS Code·Xcode 등 다양한 GitHub 및 Microsoft 경험에서 공유됩니다. - GitHub은 좋은 하니스의 조건으로 빠른 속도, 낮은 토큰 사용량, 예측 가능성을 제시합니다. ## 벤치마크 비교 방법 - 공개 벤치마크와 GitHub·Microsoft 대규모 코드베이스에서 도출한 내부 벤치마크를 함께 사용합니다. - 통제된 실험 결과를 실제 사용 지표와 온라인 실험으로 보완합니다. - 비교 시 다음 조건을 동일하게 맞췄습니다. - 같은 모델 - 같은 벤치마크 작업 - 동일하게 정규화한 컨텍스트 윈도우 - 동일한 추론 수준 - 동일한 도구 선택 및 MCP 서버 - 비교 대상은 다음과 같습니다. - GitHub Copilot CLI - Claude 모델의 기본 하니스인 Claude Code - GPT 모델의 기본 하니스인 Codex CLI - 평가 모델은 Claude Sonnet 4.6, Claude Opus 4.7, GPT-5.4, GPT-5.5입니다. ## 사용한 벤치마크 - **SWE-bench Verified** - 오픈소스 Python 저장소의 사람이 검증한 버그 수정 500개 - 코딩 에이전트의 대표적인 산업 표준 벤치마크 - **SWE-bench Pro** - 여러 단계의 추론과 광범위한 코드 변경이 필요한 어려운 작업 - 실제 소프트웨어 엔지니어링에 가까운 복잡한 문제를 평가 - **SkillsBench** - 에이전트가 스킬을 얼마나 효과적으로 사용하고 호출하는지 평가 - **TerminalBench** - 개발자가 사용하는 명령줄·터미널 기반 작업 수행 능력 측정 - **Win-Hill** - Windows 컨테이너에서 실행되는 내부 벤치마크 - 운영체제와 실행 환경이 달라져도 성능이 유지되는지 검증 ## 토큰 효율 - 동일한 모델과 작업을 사용했을 때 Copilot 하니스는 대부분의 설정에서 더 적은 토큰을 소비했습니다. - 토큰 사용량이 줄었음에도 전반적인 작업 완료율은 다른 모델 제공업체 하니스와 비슷한 수준이었습니다. - Claude Sonnet 4.6과 Opus 4.7에서는 Copilot CLI가 비교된 모든 사례에서 더 나은 결과를 보였습니다. - GPT-5.4와 GPT-5.5에서도 대부분 Copilot CLI가 우세했지만, SWE-bench Verified에서는 각각 7%, 4% 낮은 성능을 기록했습니다. - 단순히 비용을 줄이는 것이 아니라, 작업 해결 능력을 유지하면서 토큰 소비를 낮추는 것이 핵심입니다. ## 작업 해결률 - 전체적으로 Copilot 하니스의 작업 해결률은 모델 제공업체 하니스와 대등했습니다. - SWE-bench Verified에서는: - Sonnet 4.6과 Opus 4.7에서 Copilot CLI가 더 높은 해결률을 보였습니다. - GPT-5.4와 GPT-5.5에서는 더 낮았습니다. - SWE-bench Pro에서는: - Sonnet 4.6에서만 Copilot CLI가 소폭 낮았습니다. - 나머지 모델에서는 더 나은 성능을 보였습니다. - SkillsBench에서는 Claude 모델에서 낮았지만 GPT 모델에서는 더 높았습니다. - Win-Hill에서는 모든 모델에서 같거나 더 나은 결과를 기록했습니다. - TerminalBench 2에서는: - Sonnet 4.6과 Opus 4.7에서 더 높았습니다. - GPT-5.5에서는 동률이었습니다. - GPT-5.4에서는 더 낮았습니다. - 저자들은 모델의 확률적 특성으로 인한 실행별 변동을 고려하면 이러한 차이는 실질적으로 “동등한 수준”이라고 해석합니다. ## 실행별 변동성과 비용 분석 - TerminalBench 2.0을 사용해 작업 해결률뿐 아니라 작업당 비용과 실행별 변동도 분석했습니다. - 벤치마크 결과는 한 번의 실행만으로 하니스 성능을 판단하기 어렵다는 점을 보여줍니다. - 같은 에이전트와 모델 조합도 실행마다 결과가 달라질 수 있습니다. - 평가에서는 더 많은 작업을 해결하면서 비용을 적게 쓰는 구성이 더 좋은 것으로 간주합니다. - Copilot CLI는 이러한 분석에서 모델 제공업체 하니스와 비교해 같거나 더 나은 해결률·토큰 효율을 보였습니다. ## 실용적인 의미 - 모델을 선택할 때 모델의 벤치마크 점수만 보지 말고 하니스의 도구 사용, 컨텍스트 관리, 토큰 효율도 함께 평가해야 합니다. - 여러 모델을 한 제품에서 사용해야 한다면, 특정 모델에 종속되지 않으면서 성능을 유지하는 공통 하니스가 유리합니다. - 실제 도입 전에는 SWE-bench 같은 표준 평가뿐 아니라 조직의 코드베이스와 터미널 작업을 반영한 내부 벤치마크를 반복 실행하는 것이 좋습니다. - 단일 실행 결과보다 해결률, 비용, 토큰 사용량, 실행 간 변동을 함께 비교해야 신뢰할 수 있는 판단을 내릴 수 있습니다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델AI 에이전트모델 컨텍스트 프로토콜github-copilot+3
meta5분 읽기큐레이션 요약

AI 네이티브 시대의 프라이버시 인식 인프라: 자산 분류 사례 연구

프라이버시 통제는 데이터의 정체와 사용 맥락을 정확히 이해해야 제대로 작동하며, 이를 위한 자산 분류가 모든 보존·접근·목적 제한·공유·익명화 정책의 기반이 된다. Meta는 LLM을 모든 운영 판단에 사용하는 대신, 풍부한 맥락과 인간 검토를 바탕으로 모호하거나 새로운 자산을 해석하게 하고, 검증된 패턴은 버전 관리되는 결정론적 규칙으로 전환하는 하이브리드 방식을 제안한다. 그 결과 일상적인 운영 집행은 빠르고 재현 가능하며 감사하기 쉬운 규칙이 담당하고, LLM은 점차 예외적인 경우에만 사용된다. ## 프라이버시 인프라에서 자산 분류가 중요한 이유 - 프라이버시 인식 인프라(PAI)는 다음 네 가지 운영 문제를 다룬다. - 어떤 데이터가 존재하고 어떻게 관리되는지 파악 - 특정 정책과 관련된 데이터 흐름 탐색 - 보존 기간, 접근 권한, 허용 목적, downstream 공유 제한 집행 - 검증 가능한 증거를 통한 컴플라이언스 입증 - 자산 분류는 이 중 ‘데이터 이해’ 계층에 해당하며, 이후 모든 통제의 기반이 된다. - 분류 대상은 테이블과 컬럼에 한정되지 않는다. - 중첩 페이로드의 필드 - 로그 키와 이벤트 파라미터 - API 필드 - ML 피처와 임베딩 - 중간 파이프라인에서 생성된 파생 데이터셋 - 같은 데이터가 파이프라인을 거치며 피처, 모델 학습 데이터, 결합된 파생 신호 등 여러 표현으로 바뀌므로, 분류는 데이터의 형태보다 의미와 계보(lineage)를 따라야 한다. ## 데이터 분류가 어려운 네 가지 이유 - **노이즈가 많고 신호가 약하다** - 자산마다 수십 개의 맥락 필드를 제공하면 모델이 매번 중요한 정보를 다시 찾아야 한다. - 불필요한 필드가 토큰과 주의를 소모해 실제 결정 경계를 흐린다. - 예를 들어 `age`는 개인정보 맥락에서는 사람의 나이지만, 인프라 파이프라인에서는 캐시 TTL일 수 있다. - 코드 해석과 lineage 분석이 없으면 캐시 파이프라인 전체에 불필요한 제한이 적용되는 false positive가 발생한다. - **관련 정보가 여러 시스템에 흩어져 있다** - 코드, 데이터 계보, 소유자, 의미론적 주석, 문서, 실제 사용 패턴을 함께 확인해야 한다. - **요구사항과 정책 해석이 계속 변한다** - 제품 기능이 빠르게 바뀌면 정적 규칙이나 주기적 수동 검토만으로는 정책 공백이 생긴다. - **분류 오류가 downstream 전체에 전파된다** - false positive는 불필요한 제한을 유발한다. - false negative는 보호되지 않은 데이터가 남는 문제를 만든다. - 따라서 모호성을 다루는 추론 능력과 설명·재현 가능한 집행 방식이 모두 필요하다. ## LLM과 결정론적 규칙의 역할 분담 - LLM은 다음 상황에 제한적으로 사용한다. - 기존 규칙으로 처리하기 어려운 모호한 자산 - 초기 데이터가 부족한 cold start 상황 - 이전에 보지 못한 새로운 패턴 - 검증된 패턴은 버전이 있는 결정론적 규칙으로 변환한다. - 낮은 지연 시간 - 동일 입력에 대한 재현성 - 실행 결과의 감사 가능성 - 대규모 운영에 적합한 비용과 성능 - 일반적인 운영 판단은 LLM이 아니라 규칙이 담당한다. - 인간은 다음 단계에 관여한다. - 기준 라벨(reference label) 판정 - 보호 정책에 영향을 주는 규칙 승격 검토 및 승인 - 장기적으로는 LLM이 담당하는 운영 범위를 줄이고, 규칙이 처리하는 안정적인 영역을 넓히는 것이 목표다. ## 원칙 1: 프롬프트보다 맥락이 중요하다 - 분류 실패의 주요 원인은 지시문이 약해서가 아니라 모델에 제공된 증거가 부족하거나 정리되지 않았기 때문이다. - 원시 필드를 그대로 전달하면 중요한 정보와 오해를 일으키는 정보가 섞인다. - 대신 다음 요소를 포함한 **evidence brief**를 구성한다. - 판단을 지지하는 신호 - 판단과 모순되는 신호 - 각 정보의 출처(provenance) - 모델이 이미 알고 있는 정보와 중복되는 순환 필드의 마스킹 - 프롬프트를 계속 최적화하는 것보다, 코드·계보·소유권·문서 등 관련 증거를 선별하고 구조화하는 편이 정확도 향상에 더 효과적이다. - 즉, 모델에 무엇을 어떻게 묻는지보다 먼저 무엇을 보여줄지를 설계해야 한다. ## 원칙 2: 평가와 최적화를 분리한다 - LLM의 결과는 추천이며, 그 자체가 정답 데이터가 되어서는 안 된다. - 평가 체계는 분류기와 독립적으로 유지해야 한다. - 서로 다른 모델과 프롬프트 전략 - 고정된 reference set - 사람이 검토한 라벨 - 회귀(regression) 통과 기준 - 분류 결과를 다시 평가 기준으로 사용하면 실제 개선이 아니라 모델의 드리프트를 측정할 위험이 있다. - 인간 검토 라벨은 모델 출력과 분리된 신뢰 가능한 기준점으로 사용해야 한다. ## 원칙 3: 안정적인 동작을 규칙으로 증류한다 - 반복적으로 검증된 분류 패턴은 사람이 검토한 뒤 결정론적 규칙으로 만든다. - 규칙에는 버전, 적용 조건, 판단 근거를 남겨야 한다. - 규칙 기반 집행은 LLM 추론보다 빠르고, 결과를 재생(replay)할 수 있으며, 감사와 디버깅이 쉽다. - LLM은 새로운 패턴을 발견하는 학습 장치로 활용하고, 안정화된 지식은 규칙에 축적한다. ## 플랫폼 서비스로서의 분류 계약 분류기는 개별 모델 호출이 아니라 안정적인 플랫폼 서비스처럼 설계해야 한다. - 입력 - 자산 식별자 - 정리된 맥락 정보 묶음 - 출력 - 분류기 taxonomy상의 카테고리 - 모델의 원시 confidence score - 판단에 영향을 준 증거를 보여주는 decision trace - 결정론적 규칙으로 판단했다면 매칭된 규칙 - 사용된 맥락, 규칙, 프롬프트의 버전 정보 - confidence는 모델의 자기평가일 뿐이므로, 사람이 검토한 라벨과 비교해 실제 보정 상태를 평가해야 한다. - 모든 분류기를 하나의 보편적 taxonomy로 통합하지 않고, 각 분류기가 하나의 범위가 좁은 질문을 담당하도록 한다. - 예: 사용자 데이터인지 운영 데이터인지 분류 - 예: 특정 AI 학습 용도에 적합한 자산인지 분류 - 좁은 범위의 분류기는 평가·디버깅·거버넌스가 쉽고, 여러 분류기의 결과를 downstream에서 조합할 수 있다. 실무적으로는 LLM을 최종 집행 엔진으로 삼기보다, 사람이 검토한 라벨과 충분한 맥락을 이용해 새로운 패턴을 발견하는 보조 계층으로 두는 것이 바람직하다. 이후 안정화된 판단은 버전 관리되는 규칙으로 승격해 운영하고, 모든 결과에 증거·버전·추적 정보를 남겨 재현성과 감사 가능성을 확보해야 한다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델data-governancehuman-in-the-loopdata-lineage+3
dropbox3분 읽기큐레이션 요약

DSPy를 활용해 Dash 채팅에서 AI 평가를 더 나은 응답으로 전환한 방법

Dropbox는 Dash chat 에이전트의 최종 답변만 평가하지 않고, 의도 파악·검색·도구 사용·근거 선택·다중 턴 대응까지 전체 실행 과정을 평가했습니다. 이후 사람의 평가 데이터를 활용해 LLM 평가자(judge)를 보정하고, DSPy의 GEPA·MIPROv2로 평가자와 에이전트 시스템 프롬프트를 최적화했습니다. 그 결과 불완전한 답변을 줄이고 토큰 사용량도 낮추면서 답변 품질을 유지할 수 있었습니다. ## 에이전트 평가가 어려운 이유 - 전통적인 검색 평가는 단일 결과의 관련성을 주로 측정하지만, 에이전트는 여러 단계의 의사결정을 수행합니다. - 평가 대상에는 다음 과정이 모두 포함됩니다. - 사용자의 의도 해석 - 문서·메시지·회의 기록 등 적절한 컨텍스트 수집 - 검색 및 문서 읽기 같은 도구 사용 - 여러 출처의 정보 종합 - 직접 답변, 추가 검색, 요약, 명확화 질문 중 적절한 선택 - 대화가 여러 턴에 걸쳐 진행될 수 있으므로 최종 답변뿐 아니라 피드백 반영과 재검색 과정도 평가해야 합니다. - 따라서 답변 품질, 의도 이해, 컨텍스트 선택, 도구 사용, 근거성, 지시 준수, 과업 완료 여부를 পৃথ도로 분석해야 실패 원인을 찾을 수 있습니다. ## 사람의 평가로 LLM judge 보정 - 내부 채팅 샘플과 에이전트 trace 로그를 수집하고, 사람이 다음 다섯 가지 차원을 평가했습니다. - 사용자 의도 추종 - 의미적 관련성 - 도구 호출 품질 - 지시사항 준수 - 컨텍스트 선택 - 평가자는 먼저 의도와 컨텍스트가 적절했는지 확인한 뒤 검색·검색 결과 활용·도구 행동을 검토했습니다. - 이후 최종 답변이 선택된 근거에 의해 뒷받침되는지, 관련성·근거성·완전성·지시 준수 여부를 평가했습니다. - 일부 지표는 1~5점으로 점수화하고, 함께 다음 정보를 기록했습니다. - 점수의 근거가 되는 reasoning note - 오래된 근거, 누락된 컨텍스트, 근거 없는 주장, 불완전한 답변, 개인화 실패 등의 failure code - 점수는 결과를 요약하지만, 평가 메모와 실패 코드는 문제가 발생한 위치와 원인을 보여줍니다. - 이 데이터는 judge 프롬프트 보정뿐 아니라 디버깅, 오류 분석, 개선 로드맵 수립, 우선순위 결정에도 활용됐습니다. ## DSPy를 이용한 평가자 개선 - 목표는 LLM judge의 점수가 사람의 판단과 더 일치하도록 만드는 것이었습니다. - judge는 단순히 답변에 점수를 매기는 것이 아니라 다음과 같은 정해진 절차를 따라야 했습니다. - 사용자의 의도 추론 - 대화 내용 검토 - 에이전트 trace와 지원 근거 확인 - 컨텍스트 선택과 도구 사용 분석 - 점수·실패 코드·평가 메모 작성 - DSPy를 최적화 도구로 사용하고, GEPA와 MIPROv2를 알고리즘으로 활용했습니다. - 알고리즘은 사람의 라벨이 있는 예제에서 프롬프트 변경안을 자동으로 제안하고 테스트했습니다. - 지원한 최적화 방식에는 다음이 포함됩니다. - judge 지침을 처음부터 새로 작성 - 기존 평가 행동을 유지하면서 다른 기반 모델에 맞게 조정 - 특정 실패 유형을 집중적으로 수정하는 타깃 최적화 - 이렇게 최적화된 judge는 이후 채팅 에이전트 자체의 시스템 프롬프트를 개선하는 평가 신호로 사용됐습니다. ## 평가에서 에이전트 개선으로 이어지는 피드백 루프 - 전체 과정은 다음 순환 구조로 구성됩니다. - 사람의 라벨이 judge를 보정 - 개선된 judge가 대규모 평가 신호 생성 - 평가 신호가 에이전트 프롬프트와 행동 개선에 사용 - 이 구조를 통해 사람의 평가를 모든 대화에 직접 적용하지 않고도 에이전트를 반복적으로 최적화할 수 있었습니다. - 최종적으로 불완전한 답변이 크게 줄었고, 답변 품질을 떨어뜨리지 않으면서 토큰 사용량도 절감했습니다. 실무적으로는 에이전트 개선 전에 평가자의 신뢰성을 먼저 검증해야 합니다. 최종 점수만 수집하기보다 trace, 평가 이유, 실패 유형을 함께 기록하고, 사람의 라벨과 DSPy 같은 자동 최적화 도구를 결합하면 평가를 지속적인 품질 개선 시스템으로 전환할 수 있습니다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델AI 에이전트dspyprompt-optimization+4
cloudflare3분 읽기큐레이션 요약

Cloudflare Workflows를 위한 사가 롤백 구축 방법

Cloudflare Workflows에 Saga 패턴 기반의 롤백 기능이 추가되어, 각 `step.do()`에 보상 작업을 함께 선언할 수 있게 되었습니다. 여러 외부 시스템을 거치는 워크플로에서 중간 단계가 실패해도 이전 작업을 역순으로 되돌릴 수 있으며, 롤백 자체도 내구성 있는 단계로 실행됩니다. 이를 통해 개발자가 별도의 `try-catch`, 실행 이력 추적, 수동 롤백 순서 관리를 구현할 필요가 줄어듭니다. ## 분산 작업에서 롤백이 필요한 이유 - Workflow는 여러 단계에 걸쳐 외부 시스템을 호출하고, 각 단계의 상태를 저장하며 실패 시 재시도합니다. - 그러나 이미 완료된 외부 작업은 단순히 “취소”할 수 없습니다. - 예: Bank A에서 출금이 성공한 뒤 Bank B 입금이 실패하면, Bank A의 출금을 삭제하는 대신 다시 입금해야 합니다. - 원래 작업과 이를 의미적으로 되돌리는 보상 작업의 조합을 Saga 패턴이라고 합니다. - 기존에는 개발자가 성공한 단계를 추적하고, 실패 시 어떤 작업을 어떤 순서로 취소할지 직접 관리해야 했습니다. ## `step.do()`에 보상 로직 선언 - 이제 `step.do()`의 마지막 인자로 `rollback` 함수를 전달할 수 있습니다. ```ts await step.do( "debit-bank-a", () => bankA.debit(from, amount), { rollback: async ({ output }) => bankA.credit(from, amount, output.id), } ); ``` - 각 정방향 작업과 롤백 작업이 같은 위치에 정의됩니다. - 새로운 단계를 추가할 때 해당 단계의 보상 로직도 함께 추가할 수 있습니다. - 별도의 대형 `catch` 블록이나 성공 단계 추적 변수, 수동 실행 순서 관리가 필요하지 않습니다. - 롤백 함수는 정방향 작업의 결과인 `output`을 받아 보상 작업에 활용할 수 있습니다. ## 롤백 실행 순서와 실패한 단계 처리 - 어떤 단계에서 오류가 발생하면, 롤백 핸들러는 단계가 시작된 순서의 역순으로 실행됩니다. - 출금 → 입금 → 알림 순서라면, 롤백은 입금 취소 → 출금 환불 순서입니다. - 오류가 발생한 단계 자체도 롤백 대상이 될 수 있습니다. - 외부 시스템에는 작업이 반영됐지만, 결과를 Workflow에 반환하기 전에 단계가 실패할 수 있기 때문입니다. - 예를 들어 결제 제공자가 금액을 승인한 뒤 `chargeId`를 반환하기 전에 오류가 발생할 수 있습니다. - 따라서 롤백 함수는 `output === undefined`인 경우도 안전하게 처리해야 합니다. - 사용자가 오류를 잡고 Workflow를 정상적으로 계속 진행하면 롤백은 시작되지 않습니다. - 다만 오류를 잡은 뒤 Workflow가 나중에 다른 이유로 실패하면, 그때까지 등록된 롤백 핸들러가 역순으로 실행될 수 있습니다. ## 롤백도 내구성 있는 작업으로 실행 - 롤백은 단순한 메모리상의 정리 코드가 아니라 Workflow의 내구성 모델에 따라 실행됩니다. - 재시작이나 일시적인 장애가 발생해도 롤백 작업을 추적하고 재시도할 수 있습니다. - 롤백 과정에서 하나의 보상 작업이 실패하더라도 이후 롤백을 계속 진행할 수 있도록 설계해야 합니다. - 롤백 실패는 운영자가 대응할 수 있도록 알림이나 별도 모니터링을 연결하는 것이 필요합니다. ## 멱등성 보장의 중요성 - 일반 Workflow 단계와 마찬가지로 롤백 함수도 멱등적이어야 합니다. - 같은 롤백이 여러 번 실행되어도 결과가 중복 적용되면 안 됩니다. - 권장 방식: - 결제 환불에는 결제 제공자의 멱등성 키 사용 - 재고 해제는 여러 번 호출해도 한 번만 해제되도록 구현 - 출금·입금과 롤백 각각에 고유한 멱등성 키 부여 - 예시에서는 다음과 같이 작업별 키를 사용합니다. ```ts `${transferId}:debit-account-a` `${transferId}:rollback-debit-account-a` ``` - 이를 통해 Workflow 재시도나 롤백 재실행으로 인해 동일한 이체가 중복 처리되는 것을 방지합니다. ## 실용적인 적용 권장사항 - 외부 시스템을 변경하는 모든 단계에 가능한 한 명시적인 롤백 함수를 함께 정의하세요. - 롤백 함수는 `output`이 없거나 일부 작업만 반영된 상황도 처리해야 합니다. - 정방향 작업과 롤백 모두에 안정적인 멱등성 키를 사용하세요. - 롤백 실패는 조용히 무시하지 말고 알림, 재처리 큐, 운영 대시보드 등으로 추적하세요. - Saga 롤백은 트랜잭션을 원자적으로 만드는 기능이 아니라, 실패 후 상태를 보정하는 보상 처리机制이므로 외부 API의 보상 연산을 신중히 설계해야 합니다.

원문 읽기(새 탭에서 열림)
cloudflare-workflowsrollbackidempotencysaga-pattern+2
line4분 읽기큐레이션 요약

AI 에이전트끼리 토론한다면? 멀티 에이전트 협업으로 재설계하는 개발 프로세스

AI 코딩의 병목은 코드 생성 속도가 아니라 의도 정의, 가정 검증, 구현 확인, 리뷰 준비를 사람이 직접 조율하는 데 있다. LY Corporation은 이를 해결하기 위해 제안자와 도전자 AI 팀이 스펙·빌드·전달의 세 단계에서 토론하고, 조율자가 수정·상위 보고·진행 여부를 결정하는 파이프라인을 설계했다. 목표는 사람의 판단을 없애는 것이 아니라, 사람이 검토하기 전에 AI가 자신의 작업을 근거와 함께 입증하도록 만드는 것이다. ## 사람이 조율하는 AI 보조 방식의 한계 - 기존 방식에서는 AI가 스펙 작성, 코드 생성, 테스트, PR 설명 등을 빠르게 수행한다. - 그러나 각 단계 사이에서 사람이 다음 작업을 요청하고, 실패 결과를 전달하고, diff와 PR을 검토해야 한다. - 따라서 개별 작업은 빨라져도 의도·구현·검증·리뷰·전달 사이의 조율 비용은 그대로 남는다. - 진정한 생산성 향상은 각 단계를 단순히 가속하는 것이 아니라, 수동 인수인계를 프로세스에서 제거하는 데 있다. ## 제안자와 도전자로 나뉜 AI 협업 - 제안자는 산출물을 작성하고 단계가 진행될수록 이를 발전시킨다. - 도전자는 제안자의 결과를 검증하며, 단계별로 서로 다른 관점에서 문제를 제기한다. - 스펙 단계: 소크라테스식 질문으로 모호성·누락을 찾는다. - 빌드 단계: 테스트와 실행 결과 등 근거를 바탕으로 반론한다. - 전달 단계: 구현과 PR이 최종 리뷰에 충분한지 점검한다. - 역할을 분리하면 하나의 AI가 스펙, 구현, 검증, 리뷰를 모두 낙관적으로 처리하는 문제를 줄일 수 있다. - 사람은 시작 시 의도를 정의하고, 결과를 승인하거나, 해결하기 어려운 문제가 상위 보고될 때 주로 개입한다. ## 스펙·빌드·전달 파이프라인 ### 스펙: 이후 작업의 계약 정의 - 스펙은 다음 내용을 포함한다. - 목표와 제약 조건 - 해석된 요구 사항 - 명시적 가정 - 미해결 질문 - 제안된 접근 방식 - 완료 정의 - 빌드 에이전트는 “합리적으로 보이는” 구현을 임의로 선택하지 않고, 승인된 스펙에서 테스트와 검증 계획을 도출한다. - 스펙이 부실하면 이후 구현과 리뷰의 기준도 불명확해지므로 전체 파이프라인이 약해진다. - 기존 API, 테스트, 의존성, 코딩 관습, Jira·Confluence·설계 문서 등을 조사해 질문과 가정을 구체화한다. ### 빌드: 테스트 우선 구현과 반론 - 제안자는 코드를 수정하기 전에 스펙을 다음 항목으로 변환한다. - 예상 동작 - 에지 케이스 - 추가·수정할 테스트 - 실행 명령 - 도전자는 구현 전이나 구현 중에 검증 설계 자체를 문제 삼을 수 있다. - 제안자가 도전자의 이의를 거부하려면 실행 경로, 컴파일·린트 출력, 실패 테스트 등 구체적인 증거를 제시해야 한다. - 단순히 테스트가 녹색이라는 사실만으로 검증 누락을 숨길 수 없도록 설계됐다. ### 전달: 리뷰 가능한 PR 패키지 - 최종 산출물은 코드뿐 아니라 리뷰어가 신뢰할 수 있는 PR 패키지다. - 패키지에는 다음 정보가 포함된다. - 무엇이 변경되었는가 - 어떤 파일과 영역을 먼저 봐야 하는가 - 어떤 검사와 테스트를 통과했는가 - 남은 위험과 불확실성은 무엇인가 - 도전자가 어떤 문제를 제기했고 어떻게 처리했는가 - 전달 단계의 조율자는 중재자라기보다 출시 가능성을 판단하는 심사위원 역할을 한다. ## 조율자와 구조화된 토론 프로토콜 - 조율자는 제안자와 도전자 사이에서 토론을 관리한다. - 주요 책임은 다음과 같다. - 논의가 주제에서 벗어나면 방향 수정 - 교착 상태 해소 - 산출물 수정 요청 - 안전하지 않은 불확실성의 상위 보고 - 다음 단계 진행 여부 결정 - 스펙과 빌드에서는 수렴을 이끄는 중재자 역할을 하고, 전달 단계에서는 근거가 충분한지 판정한다. - 각 에이전트는 제한된 프롬프트와 자체 컨텍스트를 사용하며, 공통으로 접근하는 것은 워크스페이스·산출물·조율자가 누적한 기록이다. - 에이전트 간 실시간 공동 컨텍스트 대신 구조화된 산출물과 transcript를 통해 협업한다. ## JSON 기반 상태 머신 - 각 토론 라운드는 제안자와 도전자의 교환 및 조율자의 결정을 포함한다. - 에이전트는 긴 에세이가 아니라 조율자가 파싱할 수 있는 엄격한 JSON을 반환한다. - JSON에는 상태, 요약, 전문가 의견, 판단 근거, 요구 사항, 제약, 완료 정의, 가정, 질문 등이 담긴다. - 예를 들어 `/api/search`만 변경할지 인접한 검색 엔드포인트까지 포함할지 불명확하면, 도전자는 범위 경계를 명시적인 질문으로 제기한다. - 모호성이 작고 기존 근거로 안전하게 판단할 수 있으면 제안자가 가정으로 기록하고 진행한다. - 반대로 답이 없으면 위험하거나 파괴적이거나 되돌리기 어려운 문제라면 추측하지 않고 사람에게 상위 보고한다. ## 전문 역할과 근거 중심 검증 - 각 단계에는 목적에 맞는 전문 역할이 배정된다. - `requirements-synthesizer`: 요구 사항 정리 - `security-analyst`: 보안 위험 분석 - `test-coverage-reviewer`: 테스트 범위 검토 - `technical-writer`: 전달 문서 작성 - `evidence-verifier`: 구현과 검증 근거 확인 - 중요한 판단은 직감이 아니라 코드, 테스트, 문서, 실행 결과 같은 근거에 기반한다. - 핵심은 여러 AI를 단순히 병렬 실행하는 것이 아니라, 서로 다른 책임과 관점을 부여해 주장과 반론을 구조화하는 데 있다. ## 실용적인 결론 AI 코딩 시스템을 설계할 때는 코드 생성 에이전트 하나를 더 빠르게 만드는 것보다, 스펙부터 PR 전달까지의 인수인계를 자동화하는 것이 더 큰 효과를 낼 수 있다. 특히 스펙을 계약으로 명확히 만들고, 단계별 도전과 근거 제출을 강제하며, 위험한 가정은 사람에게 상위 보고하도록 구성하는 것이 핵심이다.

원문 읽기(새 탭에서 열림)
AI 에이전트CI/CD코드 리뷰json+3
line5분 읽기큐레이션 요약

AI 시대의 개발 능력은 검증력으로 결정된다, Flava API Gateway 개발 중 배운 빠른 검증과 로컬 환경 구성 전략

코딩 에이전트는 빠르게 코드를 생성하지만, 설계 불명확성·출력 비결정성·검증 지연 때문에 신뢰할 수 없는 결과를 만들 수 있다. LY Corporation의 Flava API Gateway 팀은 이를 해결하기 위해 **스펙 주도 개발, 검증 자동화, 빠르고 독립적인 로컬 환경**을 구축했다. 결론적으로 AI의 생산성을 활용하려면 개발자의 전문성과 테스트·린터·사전 설계를 오히려 더 강화해야 한다. ## 코딩 에이전트가 만드는 개발 병목 - 에이전트의 코드 생성 속도에 비해 CI 대기, 환경 프로비저닝, 원격 테스트 같은 단계는 느리다. - 에이전트는 다음과 같은 오류를 반복적으로 만들 수 있다. - 컴파일되지 않는 코드 - 존재하지 않는 API 참조 - 명시되지 않은 설계 결정을 임의로 선택 - 동일한 프롬프트라도 실행마다 결과가 달라질 수 있어 출력의 일관성과 역량을 일반화하기 어렵다. - AI가 개발자의 리뷰 속도보다 빠르게 코드를 생성하면, 검토되지 않은 코드가 누적될 위험이 있다. - 따라서 AI 활용의 핵심은 단순한 생성 속도가 아니라, 잘못된 결과를 빠르게 발견하고 수정하는 개발 시스템이다. ## Flava API Gateway와 세 가지 대응책 - Flava API Gateway는 LY Corporation의 사내 프라이빗 클라우드 Flava에서 API를 생성·배포·모니터링하는 제품이다. - Kong이 데이터 플레인을 담당하고, 컨트롤 플레인은 각 팀이 독립적으로 API를 관리할 수 있는 다중 테넌트 REST API를 제공한다. - 팀은 다음 세 가지 원칙을 채택했다. - 코드 작성 전 설계와 요구사항을 확정하는 **스펙 주도 개발** - 테스트와 린터로 에이전트가 스스로 오류를 찾도록 하는 **검증 자동화** - CI를 기다리지 않고 전체 검증 루프를 돌리는 **빠른 로컬 환경** ## 스펙 주도 개발로 구현 방향 고정 - 에이전트가 설계가 정해지기 전에 구현을 시작하면, 에이전트가 임의로 설계 결정을 내리면서 비결정성이 커진다. - Flava 팀은 먼저 OpenAPI 스펙으로 컨트롤 플레인의 전체 설계를 정의했다. - OpenAPI 스펙은 다음 역할을 한다. - 에이전트가 따라야 할 명시적 기준 - 구현 결과가 설계에서 벗어났는지 판단하는 검증 기준 - API 동작 계약의 문서화 - 이후 기능을 작은 단위로 나누고 OpenSpec을 사용해 각 기능을 구현했다. ## Nickel을 활용한 OpenAPI 관리 - 원본 OpenAPI YAML은 반복적이고 장황해 수작업 유지보수가 어렵다. - 스펙과 실제 구현이 어긋나면 에이전트를 통제하는 기준으로서의 가치가 떨어진다. - 팀은 Nickel을 사용해 API 리소스를 선언적으로 정의하고, 이를 전체 CRUD 엔드포인트 스펙으로 변환했다. - 예를 들어 리소스 정의만으로 다음 요소를 일관되게 생성할 수 있다. - 목록·생성·조회·삭제 엔드포인트 - 페이지네이션과 정렬 - 정확히 일치하는 필터와 부분 문자열 필터 - ETag 기반 낙관적 잠금 - 공통 오류 응답 - 이 방식은 반복적인 YAML 작성량을 줄이고, API 설계 규칙을 생성기에 집중시킨다. ## OpenSpec 기반의 협업 워크플로 OpenSpec은 에이전트가 구현 전에 행동 계약에 합의하도록 다음 네 가지 산출물을 요구한다. - **제안(Proposal)**: 무엇을, 왜 변경하는지 설명 - **설계(Design)**: 기술적 결정과 트레이드오프 정리 - **델타 스펙(Delta Specs)**: 변경되는 요구사항을 Given-When-Then 시나리오로 정의 - **작업 목록(Task List)**: 구현 단계를 체크리스트로 분해 워크플로는 다음 순서로 진행된다. - 개발자와 에이전트가 기능, 세부사항, 에지 케이스를 함께 검토한다. - 에이전트가 네 가지 산출물을 작성한다. - 에이전트가 작업 목록을 단계적으로 실행하며 구현한다. - 완료 후 변경 사항을 아카이브하고 델타 스펙을 메인 스펙에 병합한다. - 축적된 델타 스펙은 시간이 지나면서 시스템 전체의 “살아 있는 스펙”이 된다. ## 검증 자동화로 에이전트의 오류 수정 유도 - 프롬프트에 주의사항을 계속 추가하는 방식은 효과가 제한적이며, 제약이 많아질수록 출력 품질이 낮아질 가능성도 있다. - 대신 테스트와 린터가 오류를 구체적으로 드러내도록 구성했다. - 에이전트는 다음과 같은 반복 루프를 수행한다. - 코드를 작성한다. - 테스트·린터·포매터를 실행한다. - 실패 원인을 확인한다. - 코드를 수정한다. - 다시 검증하고 다음 오류로 넘어간다. - 모든 요구사항을 처음부터 프롬프트에 주입하는 대신, 필요한 제약을 실패 시점에 점진적으로 제공하는 방식이다. - 프로젝트별 스킬에 테스트, 린터, 포매터를 묶고 `AGENTS.md`를 통해 언제 해당 스킬을 사용할지 안내했다. - 검사 지침을 매 턴마다 전달하지 않고 필요할 때만 로드해 에이전트의 불필요한 컨텍스트 부담도 줄였다. ## 세 계층 테스트와 완전한 로컬 검증 전체 테스트 모음은 2,754개이며 다음 세 계층으로 구성된다. - **단위 테스트** - 비즈니스 로직을 분리해 검증 - **통합 테스트** - 실제 PostgreSQL 사용 - 제약 조건, 트리거, 소프트 삭제 연쇄, 트랜잭션 검증 - 전체 인프로세스 HTTP 스택 검증 - 모든 응답의 OpenAPI 준수 여부 확인 - **E2E 테스트** - 실제 Athenz 인증 - Kong 데이터 플레인 - API 키 적용 - 멀티 테넌트 격리 - 전체 시스템 동작 검증 ## CI 의존성을 줄인 빠른 개발 환경 - 개발자가 직접 작성할 때는 CI 왕복을 줄이기 위해 어느 정도 완성된 코드를 먼저 제출할 수 있지만, 에이전트는 짧은 간격으로 수많은 시도를 반복한다. - 모든 시도를 원격 CI로 보내면 다음 문제가 생긴다. - 긴 대기 시간 - 반복 과정에서 에이전트가 컨텍스트를 잃을 가능성 - 원격 환경의 로그와 상태를 조사하기 어려움 - 완전한 로컬 환경을 구축하면 에이전트가 즉각적인 피드백을 받고 현재 작업 흐름을 유지할 수 있다. - 로컬 의존성의 로그와 상태를 직접 확인할 수 있어 실패 원인 분석도 쉬워진다. - 전체 테스트는 개발자 기기에서 약 15초 안에 실행되도록 최적화했다. - 이를 위해 테스트를 병렬화하고 테스트 간 격리를 강화했다. 공유 테이블을 매번 삭제하는 방식보다 각 테스트 패키지가 독립적으로 생성한 데이터를 사용해 실행 간 충돌을 줄이는 방향을 택했다. ## 실용적인 적용 권장사항 AI 코딩 에이전트를 도입할 때는 프롬프트를 복잡하게 만드는 것보다 먼저 API·행동 스펙을 문서화하고, 테스트·린터·포매터를 자동 실행하며, 핵심 검증을 로컬에서 빠르게 끝낼 수 있게 만드는 것이 효과적이다. 에이전트의 성능을 높이는 가장 현실적인 방법은 더 많은 일을 맡기는 것이 아니라, 실패를 즉시 알려 주고 스스로 수정할 수 있는 짧은 피드백 루프를 구축하는 것이다.

원문 읽기(새 탭에서 열림)
PostgreSQLcoding-agentsautomated-testingopenapi+4
gitlab4분 읽기큐레이션 요약

Google Antigravity 에이전트, GitLab Orbit로 전체 컨텍스트 확보

Google Antigravity에 GitLab Orbit를 연결하면 코딩 에이전트가 단순히 파일과 터미널만 보는 것을 넘어 GitLab의 프로젝트, 의존성, 파이프라인, 머지 리퀘스트, 취약점, 코드 소유권까지 함께 이해할 수 있다. Orbit는 GitLab 데이터를 지식 그래프로 구성하고 MCP를 통해 에이전트에 제공하며, 이를 통해 변경 영향 분석과 코드베이스 탐색 같은 작업의 정확도와 속도를 높인다. 글에 따르면 초기 내부 테스트에서 응답 속도는 최대 11배 빨라지고, 토큰 사용량은 최대 4.5배, 환각은 최대 45배 줄었다. ## GitLab Orbit가 제공하는 컨텍스트 그래프 - GitLab 인스턴스의 다음 요소를 노드와 관계로 색인한다. - 그룹과 프로젝트 - 사용자와 코드 소유자 - 이슈 및 작업 항목 - 머지 리퀘스트 - 파이프라인 - 취약점 - 소스 코드와 프로젝트 간 의존성 - 지식 그래프는 코드 변경과 GitLab 활동을 연결해 에이전트가 시스템 전체의 맥락을 파악하도록 한다. - MCP 도구 두 가지를 제공한다. - `query_graph`: GitLab Orbit의 JSON DSL로 그래프를 질의 - `get_graph_schema`: 사용 가능한 노드 유형, 속성, 관계 확인 - 코드 변경 후 몇 분 내에 그래프를 다시 색인하므로 오래된 위키보다 최신 상태를 반영한다. ## Antigravity 에이전트의 활용 범위 확대 Orbit가 없으면 Antigravity 에이전트는 주로 현재 열려 있는 파일과 터미널에 의존한다. Orbit를 연결하면 다음과 같은 질문에 답할 수 있다. - 특정 모듈에 의존하는 프로젝트와 서비스는 무엇인가? - 해당 프로젝트에 해결되지 않은 취약점이 있는가? - 과거 리뷰 이력과 파일 소유권을 기준으로 적절한 리뷰어는 누구인가? - 특정 그룹에서 파이프라인 실패가 가장 많은 프로젝트는 무엇인가? 에이전트는 브라우저를 오가거나 사용자가 정보를 복사해 주지 않아도 구조화된 그래프 결과를 받아 답변을 생성한다. ## 변경 영향도와 충돌 분석 공유 인증 라이브러리처럼 여러 서비스가 사용하는 코드를 리팩터링할 때 Orbit가 특히 유용하다. - 해당 모듈을 import하는 모든 프로젝트를 조회한다. - 관련 파일을 수정 중인 열린 머지 리퀘스트를 확인한다. - 각 변경 사항의 담당자와 소유자를 찾아낸다. - 리팩터링이 기존 작업과 충돌할 가능성과 사전에 협의해야 할 사람을 한 번에 파악할 수 있다. 기존 에이전트가 파일 자체만 분석하는 것과 달리, 코드 의존성과 진행 중인 협업 작업까지 함께 고려한다는 점이 핵심이다. ## 온보딩과 코드베이스 탐색 익숙하지 않은 서비스에 복귀하거나 새로 합류한 개발자는 에이전트에게 다음 정보를 요청할 수 있다. - 서비스가 의존하는 프로젝트와 모듈 - 주요 진입점 파일 - 최근 일주일 동안 해당 서비스에 열린 머지 리퀘스트 에이전트는 조회 결과를 일회성 채팅 답변이 아니라 다시 볼 수 있는 **Walkthrough Artifact** 형태의 탐색 자료로 만들 수 있다. 그래프가 변경 후 빠르게 갱신되기 때문에 낡은 문서에 의존하지 않고 현재 코드베이스를 기준으로 학습할 수 있다. ## 실시간 의존성 다이어그램 생성 - 기술 리드는 그룹의 서비스 의존성 그래프를 조회한 뒤 Nano Banana Pro를 사용해 아키텍처 다이어그램으로 렌더링할 수 있다. - 특정 보안 취약점이 열려 있는 서비스만 필터링하는 등 범위를 좁혀 새 다이어그램을 만들 수 있다. - 다이어그램의 노드와 연결선은 최신 GitLab 그래프에서 생성된다. - 사용자의 GitLab 권한에 따라 결과가 필터링되므로 접근 권한이 없는 정보가 포함되지 않는다. - GitLab도 Software Architecture Map을 개발 중이지만, 글에서는 Antigravity 환경에서 이 기능을 즉시 사용할 수 있다고 설명한다. ## 설치와 사용 조건 - Antigravity 설정의 **Customization → MCP** 섹션에서 MCP Store를 연다. - **Add MCP**를 선택하고 GitLab Orbit를 추가한다. - 화면 안내에 따라 GitLab 인증을 완료하면 별도 설정 파일이나 터미널 작업 없이 에이전트가 Orbit 도구를 사용할 수 있다. - Orbit는 GitLab Duo Agent Platform과 동일한 컨텍스트 엔진을 사용한다. - 지원 언어는 Ruby, Java, Kotlin, Python, TypeScript, JavaScript, Rust, C#이며 기본 브랜치의 코드를 색인한다. - MCP 질의에는 GitLab Credits가 사용되지만 `get_graph_schema` 호출은 무료다. - GitLab.com의 Premium 및 Ultimate 요금제에서 사용할 수 있으며, 먼저 최상위 그룹에서 Orbit를 활성화해야 한다. ## 실용적인 결론 대규모 GitLab 환경에서 의존성 분석, 보안 점검, 리뷰어 선정, 온보딩을 자주 수행한다면 Orbit를 연결할 가치가 크다. 다만 성능 개선 수치는 초기 내부 테스트 결과이므로 실제 효과는 저장소 규모, 그래프 품질, 질의 설계에 따라 검증하고 GitLab Credits 사용량과 권한 설정도 함께 관리하는 것이 좋다.

원문 읽기(새 탭에서 열림)
모델 컨텍스트 프로토콜DevSecOpsgitlab-duo-agent-platformgitlab-orbit+3
google4분 읽기큐레이션 요약

선형 탄력적 캐싱으로 클라우드 비용 효율성 최적화

인메모리 캐시는 성능을 높이지만, 고정된 메모리 크기로 운영하면 수요가 낮을 때 비용이 낭비되고 수요가 많을 때 캐시 미스로 성능이 저하된다. 선형 탄력적 캐싱은 메모리 점유 비용과 캐시 미스 비용의 균형을 ‘스키 대여 문제’로 모델링해, 워크로드에 따라 페이지별 보관 시간과 캐시 크기를 동적으로 조정한다. Spanner 실험에서는 메모리 사용량을 15.5%, 총소유비용(TCO)을 약 5% 줄이면서 캐시 미스 증가는 5.5%에 그쳤다. ## 고정 크기 캐시의 비용 문제 - 기존 캐시는 미리 정한 메모리 용량 안에서 LRU 같은 정책으로 데이터를 제거한다. - 캐시가 너무 작으면 디스크나 다른 저장 시스템에 대한 접근이 늘어 성능이 떨어진다. - 반대로 피크 수요에 맞춰 캐시를 크게 잡으면 평상시 사용하지 않는 메모리 비용이 발생한다. - 특히 클라우드와 서버리스 환경에서는 메모리 용량과 사용 시간이 직접 비용으로 연결된다. ## 스키 대여 문제로 모델링한 캐싱 - 각 데이터 페이지는 다음 두 선택지 사이에서 판단된다. - **대여:** 데이터를 RAM에 유지하면서 메모리 비용을 계속 지불한다. - **구매:** 데이터를 제거해 메모리 비용을 아끼지만, 재요청 시 캐시 미스에 따른 지연 및 I/O 비용을 부담한다. - 페이지를 너무 오래 보관하면 메모리 비용이 커지고, 너무 빨리 제거하면 캐시 미스 비용이 커진다. - 전통적인 스키 대여 알고리즘은 누적 대여 비용이 재취득 비용과 같아지는 시점에 데이터를 제거하는 손익분기 전략을 사용한다. - 연구진은 최악의 경우를 보장하는 방식뿐 아니라, 실제 워크로드의 반복적인 접근 패턴을 학습해 더 나은 TTL을 예측하는 방법을 적용했다. ## TTL과 물리적 캐시 용량의 분리 - 이론적으로 캐시의 핵심 문제를 다음 두 부분으로 나눌 수 있음을 보였다. - 각 페이지를 얼마나 오래 보관할지 결정하는 문제 - 캐시가 실제로 가득 찼을 때 어떤 페이지를 제거할지 결정하는 문제 - 페이지 요청 시 스키 대여 알고리즘이 해당 페이지의 TTL을 계산한다. - TTL이 만료되기 전 재접근이 없으면 페이지를 자동으로 제거한다. - 캐시가 물리적으로 가득 차면 LRU 같은 전통적인 제거 정책이 보조적으로 작동한다. - 이 분리 덕분에 동적 캐시 크기 조절을 기존 캐시 시스템에 비교적 간단히 통합할 수 있다. ## Spanner의 경량 머신러닝 적용 - Spanner의 초당 수십억 건 요청을 처리하기 위해 TTL 예측 모델은 매우 가벼워야 했다. - 연구진은 몇 줄의 C++ 코드로 변환 가능한 얕은 결정 트리를 사용했다. - 모델이 고려한 주요 특징은 다음과 같다. - 데이터 페이지의 크기 - 캐시 미스 발생 시 데이터를 다시 가져오는 비용 - 수행되는 데이터베이스 연산의 유형 - 페이지의 과거 접근 패턴 - 결정 트리는 해석 가능하므로, 어떤 데이터가 오래 캐시할 가치가 있는지도 분석할 수 있다. ## Spanner 운영 환경의 실험 결과 - 고정 크기 캐시와 비교했을 때: - 메모리 사용량 **15.5% 감소** - 캐시 미스 **5.5% 증가** - 총소유비용(TCO) 약 **5% 감소** - 캐시 미스 증가는 비용이 낮은 데이터에 집중됐다. - 저장 시스템에 실제로 발생한 I/O 비용 증가는 약 **0.5%**에 불과했다. - 즉, 모든 캐시 미스를 동일하게 줄이기보다, 재취득 비용이 큰 데이터는 유지하고 저렴한 데이터는 적극적으로 제거하는 비용 인식형 전략이 효과적이었다. ## 공개 캐시 트레이스 검증 - Google 인프라에만 특화된 결과인지 확인하기 위해 다양한 공개 캐시 추적 데이터를 사용했다. - 고정 크기 캐시의 기준 정책으로는 페이지 크기가 서로 다른 상황을 처리할 수 있는 GDSF를 사용했다. - 여러 탄력적 캐시 변형을 비교했다. - 손익분기 스키 대여 정책 - 무작위화된 스키 대여 정책 - 학습된 TTL을 사용하는 정책 - 애플리케이션 수준의 특징이 없는 공개 데이터에서는 각 페이지별 최적 TTL을 학습했다. - 트레이스를 학습과 테스트로 나누고, 테스트 전에 일정 기간 캐시를 채우는 워밍업 절차를 적용했다. - 학습 데이터에서 관찰된 페이지는 미리 계산한 TTL을 사용하고, 처음 등장한 페이지는 기본 스키 대여 정책으로 처리했다. ## 다양한 워크로드에서의 효과 - 실험 결과, 탄력적 캐싱은 다양한 워크로드에서 고정 크기 캐시보다 일관되게 낮은 비용을 보였다. - 메모리 비용이 캐시 미스 비용보다 비싸질수록 탄력적 캐싱의 절감 효과가 커졌다. - 비슷한 메모리 규모를 사용하는 경우에도 탄력적 정책이 더 낮은 캐시 미스율을 보였다. - 캐시 크기를 수요에 맞춰 자동 조정하기 때문에 유휴 메모리 낭비를 줄이면서 성능을 유지할 수 있다. 실무에서는 모든 페이지를 동일하게 취급하는 LRU만 사용하기보다, 페이지 크기와 재조회 비용을 반영해 TTL을 차등 설정하는 방식이 유용하다. 특히 메모리 비용이 높고 데이터별 재취득 비용 차이가 큰 클라우드 데이터베이스에서는 선형 탄력적 캐싱을 적용해 비용 절감 효과를 측정해볼 만하다.

원문 읽기(새 탭에서 열림)
머신러닝cachingc-plus-plusdatabase-systems+4
discord3분 읽기큐레이션 요약

Discord 업데이트: 2026년 6월 25일 변경 사항

Discord의 2026년 6월 25일 업데이트는 게임 탐색과 친구들과의 플레이를 돕는 기능, 모바일 사용성 개선, 채팅·음성 커뮤니케이션 편의 기능에 초점을 맞췄다. 매주 갱신되는 Trending Games 페이지와 강화된 게임 프로필을 통해 인기 게임 정보를 확인할 수 있으며, 모바일에서는 반응·프로필·업로드·위시리스트 기능이 개선됐다. 또한 DM과 채널 고정, 통화 확인, 게임 내 Discord 친구 초대 등 커뮤니케이션 기능도 보강됐다. ### 인기 게임 탐색 기능 - **Trending Games 페이지**가 매주 목요일 업데이트된다. - Discord 전체에서 인기를 얻고 있는 싱글플레이 및 멀티플레이 게임을 확인할 수 있다. - 게임 나이트나 스트리밍을 위한 새로운 게임을 찾는 데 활용할 수 있다. - 게임 프로필 페이지에서 다음 정보를 확인할 수 있도록 개선됐다. - 게임 스크린샷 - 지원 플랫폼 - Steam 및 OpenCritic 리뷰 - Discord 내 인기 정도 - 공식 게임 서버 링크 ### 모바일 반응 및 프로필 개선 - **Tappitytap-Tap to React** 기능으로 메시지를 두 번 탭해 지정된 이모지로 빠르게 반응할 수 있다. - 사용할 기본 반응 이모지는 `User Settings > Chat`에서 설정할 수 있다. - 모바일에 새롭게 **You Bar**가 추가되어 자신의 프로필과 정체성 정보에 쉽게 접근할 수 있다. - You Bar를 탭하면 프로필을 열 수 있어 모바일 내비게이션이 단순해진다. ### 모바일 통화와 미디어 기능 - DM이나 그룹 DM에서 통화 버튼을 누르면 실제로 전화를 걸지 확인하는 절차가 추가됐다. - 실수로 늦은 시간에 전체 그룹을 깨우는 상황을 방지한다. - iOS에서는 이미지 압축 및 지연 시간 최적화로 사진 업로드 성능이 개선됐다. - 파일 크기 약 **17% 감소** - 업로드 지연 시간 약 **12% 감소** - 모바일에서도 Shop 아이템을 프로필의 **Wishlist**에 추가할 수 있다. - 다른 사용자의 프로필을 통해 해당 사용자의 위시리스트도 확인할 수 있다. ### Discord와 게임 클라이언트 연동 - Discord 계정과 Riot 계정 연동 기능이 League of Legends와 VALORANT에 적용되기 시작했다. - 게임 클라이언트 안에서 Discord 친구 목록을 확인할 수 있다. - Discord 친구를 게임에서 직접 초대해 함께 플레이할 수 있다. ### DM, 채널 및 음성 기능 개선 - DM과 그룹 DM을 목록 상단에 고정할 수 있다. - 서버에서는 자주 사용하는 채널을 채널 목록 상단에 고정할 수 있다. - 음성 채널 초대 시 현재 누가 해당 채널에서 활동 중인지 표시된다. - 이를 통해 스트리밍 중인 채널에 의도치 않게 들어가거나 상대를 놀라게 하는 일을 줄일 수 있다. - 데스크톱에서는 새 친구를 추가한 뒤 DM 목록에서 간단한 인사 메시지를 보내도록 권장한다. - 추천 메시지를 사용하지 않고 원하는 내용으로 직접 메시지를 보낼 수도 있다. 이번 업데이트는 게임을 발견하고 친구를 초대하는 과정을 간소화하면서, 모바일에서의 반응·업로드·프로필 관리 경험도 개선한 것이 특징이다. 게임 나이트를 준비한다면 Trending Games와 게임 프로필을 활용하고, 자주 연락하는 사람이나 채널은 고정 기능으로 정리하는 것이 유용하다.

원문 읽기(새 탭에서 열림)
discordiOSmobile-appsteam+4