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

gitlab·2026년 4월 27일원문

glab CLI로 AI 에이전트에 GitLab 직접 액세스 권한 부여하기 (새 탭에서 열림)

GitLab CLI(`glab`)를 MCP(Model Context Protocol)와 결합하면 AI 에이전트가 프로젝트 데이터에 직접적이고 구조적으로 접근할 수 있게 되어 개발 워크플로우의 효율성이 극대화됩니다. 이를 통해 개발자는 수동으로 정보를 복사하여 붙여넣는 번거로움을 없애고, 할루시네이션(환각) 없이 실시간 데이터에 기반한 정확한 코드 리뷰와 이슈 관리가 가능해집니다. 결과적으로 AI 에이전트는 단순한 조력자를 넘어 프로젝트의 상태를 직접 파악하고 작업을 수행하는 강력한 도구로 진화합니다. ### MCP를 통한 AI와 GitLab의 연결 * **개방형 표준 활용:** MCP는 AI 도구가 런타임에 외부 기능을 발견하고 사용할 수 있게 해주는 표준 프로토콜로, 이를 통해 AI 어시스턴트가 GitLab 이슈 읽기, MR 댓글 작성, 파이프라인 상태 확인 등을 직접 수행할 수 있습니다. * **간편한 서버 실행:** `glab mcp serve` 명령어를 실행하는 것만으로 MCP 서버를 구동하여 Claude Code, Cursor 등 다양한 AI 클라이언트와 연결할 수 있습니다. * **구조화된 JSON 데이터:** MCP를 통해 호출되는 모든 `glab` 명령은 자동으로 `--output json` 형식을 사용하여, AI 에이전트가 파싱하기 쉬운 깨끗하고 정제된 데이터를 제공합니다. * **안정성 확보:** 터미널의 대화형 입력이 필요한 명령은 제외하고 에이전트 환경에서 신뢰할 수 있게 작동하는 명령 위주로 노출하여 작업 중단 오류를 방지합니다. ### AI 기반 코드 리뷰 자동화 * **전체 컨텍스트 파악:** `glab mr view --comments --unresolved` 명령을 사용하면 MR의 메타데이터, 설명, 해결되지 않은 모든 토론 내용을 단일 JSON 페이로드로 가져와 AI에게 전달할 수 있습니다. * **효율적인 피드백 요약:** 사용자는 여러 탭을 오가는 대신 AI에게 "MR에서 해결해야 할 사항이 무엇인가?"라고 질문하여 우선순위가 지정된 요약과 제안된 변경 사항을 즉시 받을 수 있습니다. * **프로그래밍 방식의 처리:** AI가 피드백을 반영한 후 `glab mr note resolve` 명령을 직접 실행하여 토론을 해결 상태로 변경하는 등 코드 리뷰의 전 과정을 자동화된 루프 내에서 처리할 수 있습니다. ### 실시간 데이터 기반의 이슈 분석 및 디버깅 * **정확한 정보 제공:** 웹 UI에서 텍스트를 복사해 붙여넣는 방식은 정보가 누락되거나 왜곡될 위험이 크지만, `glab`은 이슈 번호, 마일스톤, 라벨 등의 속성을 정확한 구조로 제공합니다. * **훈련 데이터 한계 극복:** AI가 과거의 학습 데이터나 웹 스크래핑에 의존하지 않고, API를 통해 실시간 프로젝트 상태를 조회하므로 파이프라인 실패 원인 분석이나 이슈 분류 시 정확도가 비약적으로 향상됩니다. * **워크플로우 마찰 감소:** 에이전트가 직접 GitLab 데이터를 가져오고 보고하기 때문에 개발자는 정보 전달자 역할에서 벗어나 실제 문제 해결에 더 집중할 수 있습니다. 반복적인 코드 리뷰 분석이나 이슈 트리이징(Triage) 시간을 줄이고 싶다면 `glab` CLI를 MCP 서버로 활용해 보세요. 특히 Claude나 Cursor와 같은 최신 AI 도구를 사용 중이라면, `glab mcp serve`를 통해 AI 에이전트에게 GitLab 프로젝트에 대한 직접적인 실행력을 부여함으로써 진정한 자율 개발 환경을 구축할 수 있습니다.

머신러닝모델 컨텍스트 프로토콜코드 리뷰json+3

netflix·2026년 4월 24일원문

넷플릭스의 카메라 파일 처리 규모 확장 (새 탭에서 열림)

넷플릭스는 전 세계에서 생성되는 방대한 양의 카메라 원본 푸티지를 효율적으로 처리하기 위해 '미디어 프로덕션 스위트(MPS)'를 구축하고, 이를 업계 표준 솔루션인 FilmLight API(FLAPI)와 통합했습니다. 자체 엔진을 처음부터 개발하는 대신 검증된 외부 기술을 클라우드 기반의 서버리스 환경에 내재화함으로써, 복잡한 메타데이터 관리와 고해상도 이미지 프로세싱의 일관성을 확보했습니다. 이를 통해 제작 현장의 수동 작업을 자동화하고 기술적 오류를 최소화하여 창작자들이 오로지 작품의 퀄리티에만 집중할 수 있는 확장성 있는 제작 생태계를 마련했습니다. ### 미디어 프로덕션 스위트(MPS)의 도입 배경 * **제작 복잡도 해소**: 글로벌 제작 규모가 커짐에 따라 파일 관리 업무(File Wrangling)가 창의적인 의사결정 시간을 잠식하고, 지역 및 업체별로 미디어 처리 방식이 일관되지 않는 문제가 발생했습니다. * **휴먼 에러 방지**: 수동으로 진행되는 미디어 관리 프로세스는 실수가 발생하기 쉽고 감사(Audit)가 어려워, 이를 자동화하고 표준화할 필요성이 커졌습니다. * **효율성 극대화**: 반복적인 워크플로우를 공통 플랫폼으로 통합하여 프로덕션부터 포스트 프로덕션까지의 미디어 이동을 간소화하고자 했습니다. ### 핵심 엔진으로서의 FilmLight API(FLAPI) 통합 * **신뢰성 있는 컬러 사이언스**: 업계에서 널리 사용되는 Baselight 및 Daylight의 엔진을 API 형태로 활용하여, 다양한 카메라 포맷에 대한 검증된 디베이어링(Debayering)과 컬러 처리를 보장받았습니다. * **최신 포맷 대응**: 매번 출시되는 새로운 카메라와 녹화 포맷에 대응하기 위해 자체 엔진을 유지보수하는 대신, 전문 파트너사인 FilmLight의 기술력을 활용해 유연성을 확보했습니다. * **인프라 호환성**: FLAPI를 도커(Docker) 이미지로 패키징하여 넷플릭스의 클라우드 인프라와 전 세계 프로덕션 컴퓨팅 센터에 동일하게 배포함으로써 작업의 일관성을 유지합니다. ### 메타데이터 파싱 및 워크플로우 검사 * **데이터 정규화**: 푸티지 입고 시 FLAPI를 통해 카메라 메타데이터를 추출하고, 이를 넷플릭스의 표준 스키마로 변환하여 하위 프로세스에서 검색 및 재사용이 가능하도록 만듭니다. * **자동화된 검증**: 타임코드 및 릴(Reel) 이름을 기반으로 푸티지를 매칭하고, 처리 과정에서 발생할 수 있는 오류를 추적하거나 파이프라인 전체의 유효성을 검사하는 데 활용합니다. ### VFX 플레이트 생성 및 결과물 자동화 * **정밀한 이미지 처리**: ASC FDL(Framing Decision Lists)을 활용한 크롭 및 디스퀴즈(De-squeeze), AMF(ACES Metadata Files)를 통한 일관된 컬러 파이프라인 적용으로 정확한 VFX 소스를 생성합니다. * **워크플로우 일관성**: 제작 현장의 데일리 작업부터 최종 완성 단계까지 동일한 컬러 변환이 적용되도록 보장하며, 이를 통해 VFX 업체 등 협업 파트너에게 정확한 OpenEXR 파일을 제공합니다. * **사전 검증**: 워크플로우 전문가가 워크스테이션에서 내린 결정사항을 클라우드 파이프라인에 그대로 적용하여 실제 촬영 시작 전 프로세스를 완벽히 검증할 수 있습니다. ### 클라우드 네이티브 미디어 팩토리 아키텍처 * **서버리스 및 컨테이너화**: 고성능 GPU 워크스테이션에 의존하는 전통적인 방식에서 벗어나, 리눅스 도커 이미지 기반의 서버리스 함수로 작업을 분산 처리합니다. * **CPU 기반 확장성**: 특정 고사양 하드웨어 대신 범용 CPU 인스턴스에서 작동하도록 최적화하여, 클라우드의 유연한 컴퓨팅 자원을 활용한 대규모 병렬 처리를 실현했습니다. * **상태 없는(Stateless) 운영**: 각 작업 단위가 독립적이고 상태를 유지하지 않도록 설계하여, 오류 발생 시 즉각적으로 재실행할 수 있는 높은 운영 신뢰성을 확보했습니다. 넷플릭스의 사례는 모든 기술을 내재화하기보다 업계 표준 솔루션을 클라우드 네이티브 환경에 전략적으로 통합함으로써 얻을 수 있는 확장성의 이점을 잘 보여줍니다. 대규모 미디어 처리가 필요한 기업이라면 단일 장비의 성능 향상보다는 작업을 원자화(Atomicity)하고 API 기반의 클라우드 병렬 처리 구조를 구축하는 것이 비용 효율성과 안정성 측면에서 유리합니다.

데이터베이스 설계클라우드 컴퓨팅Docker & 컨테이너image-processing+4

line·2026년 4월 24일원문

ODW #4: 코파일럿에서 파일럿으로, 에이전틱 코딩으로 구현부터 PR까지 자동화 (새 탭에서 열림)

LY Corporation의 'Orchestration 길드'는 단순한 코드 보조를 넘어 AI가 자율적으로 개발 사이클을 주도하는 '에이전틱 코딩(Agentic Coding)'으로의 전환을 제안합니다. 명세 주도 개발(SDD)과 MCP(Model Context Protocol)를 결합하여 AI 에이전트가 기획 문서를 읽고 구현 계획 수립부터 풀 리퀘스트(PR) 작성까지 수행하도록 하는 것이 핵심입니다. 이를 통해 개발자는 단순 반복 업무에서 벗어나 고차원적인 설계와 검토에 집중함으로써 전체적인 생산성을 비약적으로 높일 수 있습니다. **단순 보조를 넘어선 에이전틱 코딩의 정의** * 기존 AI 도구가 코드 자동 완성 수준에 머물렀다면, 에이전틱 코딩은 고수준의 목표를 스스로 분해하고 자율적으로 실행하며 피드백을 통해 조정하는 방식입니다. * AI 에이전트가 전체 코드베이스와 파일 간 관계를 이해하고, 테스트 실패 시 스스로 수정하며 빌드 성공까지 반복하는 '파일럿' 역할을 수행합니다. * Jira와 Confluence 같은 사내 시스템을 MCP로 연결하여 AI가 최신 요구 사항 명세서를 직접 참조할 수 있는 환경을 구축하는 것이 기술적 토대가 됩니다. **1단계: MCP 기반의 구현 계획 수립과 리뷰** * 에이전틱 코딩의 성패는 초기 구현 계획의 정교함에 달려 있으며, 이를 위해 Jira와 Confluence URL에서 정보를 수집하는 커스텀 슬래시 명령어를 활용합니다. * Claude Code의 'Explore Agent' 기능을 병렬로 사용하여 메인 컨텍스트를 유지하면서도 광범위한 코드 분석과 문서 조사를 동시에 수행합니다. * 분석 결과는 `plan.md`와 같은 독립된 파일로 출력하여 사람이 미리 리뷰할 수 있게 함으로써, AI가 엉뚱한 방향으로 구현을 시작하는 리스크를 방지합니다. **2단계: 자율적 구현과 품질 검증 및 PR 작성** * 확정된 구현 계획서를 바탕으로 AI가 코드를 작성하며, 단순 생성을 넘어 테스트 코드 추가, 린트(Lint), 빌드(Build) 과정을 스스로 반복합니다. * 작업 단계를 명시한 커스텀 명령어를 통해 AI가 할 일 목록(To-do list)을 생성하고 누락 없이 작업을 완수하도록 가이드합니다. * 구현 완료 후에는 미리 정의된 템플릿에 따라 배경, 대응 영역, 테스트 관점 등을 포함한 상세한 PR 설명을 자동으로 작성하여 공유합니다. **3단계: AI 셀프 리뷰와 피드백 대응** * 작성된 PR에 대해 AI가 스스로 스크리닝 리뷰를 수행하고, 잠재적인 오류나 개선 사항에 대해 코멘트를 남깁니다. * AI는 자신의 셀프 코멘트뿐만 아니라 다른 팀원이 남긴 리뷰 내용까지 파악하여 수정안을 제시하고 실제 코드에 반영합니다. * 이 과정에서 사람은 AI가 내린 판단의 적절성만 최종 승인함으로써 리뷰 및 수정에 드는 비용을 획기적으로 줄입니다. **에이전틱 코딩 도입의 성과와 과제** * **장점:** 여러 에이전트를 병렬로 실행하여 코드 생성 속도를 높일 수 있으며, 사전 계획 수립 과정을 통해 잠재적 리스크를 조기에 발견할 수 있습니다. * **주의 사항:** AI가 생성한 대량의 코드를 검토해야 하는 리뷰어의 부담이 커질 수 있으므로, '최종 책임은 사람에게 있다'는 인식과 품질 유지 프로세스가 필수적입니다. * **워크숍 결과:** 약 2,500명의 엔지니어가 참여하여 40% 이상이 실무에 적용하거나 활용할 의사를 밝히는 등 긍정적인 확산 효과를 확인했습니다. 에이전틱 코딩을 성공적으로 도입하기 위해서는 명확한 명세서 작성을 선행하고, AI가 작업 계획을 파일 형태로 기록하게 하여 사람과의 접점을 만드는 것이 중요합니다. 기술 부채를 방지하기 위해 AI가 작성한 코드의 품질을 엄격히 관리하는 체계를 병행할 것을 권장합니다.

AI모델 컨텍스트 프로토콜github-copilotagentic-coding+4

gitlab·2026년 4월 24일원문

19.0 Omnibus-GitLab FIPS 패키지에서 curl 제거 (새 탭에서 열림)

GitLab은 2026년 5월 출시 예정인 19.0 버전부터 Omnibus-GitLab FIPS 패키지 내부에 자체 빌드하여 포함하던 `curl`을 제거합니다. 앞으로 FIPS 환경의 사용자들은 GitLab이 제공하는 번들 대신 사용 중인 Linux 배포판의 `curl` 패키지를 직접 활용하게 되며, 이는 기존의 OpenSSL 라이브러리 관리 방식과 동일한 모델로 통합되는 것입니다. 이번 변경을 통해 GitLab은 패키지 유지보수의 효율성을 높이고, OS 수준의 암호화 라이브러리와의 호환성을 강화하고자 합니다. ### 기술적 배경 및 변경 사유 * **OpenSSL 1.x 지원 중단:** 최신 버전인 `curl 8.18.0`부터 OpenSSL 1.x 환경에서의 컴파일 지원이 중단되었습니다. 이로 인해 Amazon Linux 2나 AlmaLinux 8(RHEL 8 기반)과 같이 구형 라이브러리를 사용하는 환경에서 기존 방식의 패키징을 지속하기 어려워졌습니다. * **FIPS 관리 모델의 일관성:** FIPS 패키지는 이미 배포판의 암호화 라이브러리를 링크하여 사용하고 있습니다. `curl` 또한 이와 동일한 방식으로 전환함으로써 보안 및 관리 모델의 일관성을 확보합니다. * **유지보수 및 보안 강화:** OpenSSL 3.0 이상을 사용하는 최신 배포판을 포함한 모든 FIPS 패키지에 이 변경 사항을 적용하여 전체적인 보안 관리 체계를 개선합니다. ### 적용 대상 및 일정 * **적용 시점:** 2026년 5월 21일 출시되는 GitLab 19.0 버전 및 이후의 패치 릴리스부터 적용됩니다. * **영향 범위:** 모든 Omnibus-GitLab FIPS 패키지 사용자가 대상입니다. * **사용자 조치:** GitLab 인스턴스 자체의 동작 방식은 변하지 않으므로 즉각적인 기능 설정 변경은 필요하지 않으나, 시스템 환경에 대한 점검이 권장됩니다. ### 보안 관리 책임의 변화 * **보안 업데이트 주체 변경:** 이제 GitLab은 FIPS 패키지용 `curl`의 보안 패치를 직접 배포하지 않습니다. 사용자는 운영체제(OS)에서 제공하는 업데이트를 통해 `curl`의 최신 보안 상태를 유지해야 합니다. * **취약점 스캐닝 결과:** 보안 스캐너는 더 이상 GitLab 번들 버전이 아닌, 호스트 OS에 설치된 `curl` 패키지를 기준으로 취약점을 식별하게 됩니다. FIPS 환경에서 GitLab을 운영 중인 관리자는 19.0 업데이트 이후 `curl` 관련 보안 취약점 대응이 운영체제 패키지 관리 프로세스에 포함되도록 관리 절차를 재점검해야 합니다. 특히 시스템 보안 스캔 결과가 OS 패키지 상태를 반영하게 되므로, 정기적인 OS 업데이트를 통해 최신 보안 패치를 적용할 것을 권장합니다.

gitlabDevSecOpsLinuxcurl+3

discord·2026년 4월 24일·3분 읽기큐레이션 요약

적게 측정하고 더 많이 배우기: 중요한 것을 포착하는 더 적고 질 높은 지표 활용

Discord는 실험에서 측정 지표를 많이 포함할수록 계산·해석 비용뿐 아니라 통계적 오류도 커진다고 설명합니다. 다중 가설 검정 보정은 거짓 양성을 줄이지만 실제 변화를 놓칠 가능성, 즉 재현율을 낮출 수 있습니다. 따라서 가장 효과적인 해결책은 모든 지표를 넣는 대신, 서로 다른 개념을 대표하는 소수의 고품질 지표를 선택하는 것입니다. ## 지표가 많아질수록 커지는 문제 - Discord의 실험에는 모든 실험에 자동으로 포함되는 “Default Metric List”가 있었음. - 각 팀이 중요하다고 생각하는 지표를 계속 추가했지만, 기존 지표는 거의 제거되지 않아 목록이 비대해짐. - 지표가 100개이고 각 지표의 유의수준을 5%로 두면, 실제 효과가 없어도 평균적으로 약 5개가 우연히 유의미하게 나타날 수 있음. - 지표가 많아질수록: - 실험 결과를 읽고 해석하기 어려워짐 - 계산 비용이 증가함 - 하나 이상의 거짓 양성이 발생할 확률이 높아짐 - 다중 검정 보정을 적용할 경우 실제 효과를 발견하는 재현율이 낮아짐 ## 다중 비교 문제와 Benjamini-Hochberg 보정 - Discord는 여러 지표를 동시에 검정할 때 Benjamini-Hochberg(BH) 보정을 사용함. - BH는 전체 지표 중 거짓 발견의 비율인 FDR(False Discovery Rate)을 일반적으로 5% 이하로 유지하도록 설계됨. - 지표를 p-value 오름차순으로 정렬한 뒤, 각 지표의 순위에 따라 다음 임계값과 비교함: - `i × α / n` - `i`: p-value 순위 - `α`: 유의수준(예: 0.05) - `n`: 전체 지표 수 - 예를 들어 보정 전 p-value가 0.038인 지표는 일반적인 0.05 기준에서는 유의하지만, BH 보정 후에는 유의하지 않을 수 있음. - BH는 거짓 양성을 줄이는 대신 유의미한 실제 변화를 탐지하는 재현율을 떨어뜨림. - BH는 각 지표가 실제로 변할 가능성에 대한 사전 정보를 활용하지 않으므로 모든 지표를 동일하게 취급함. ## 시뮬레이션으로 확인한 거짓 양성과 재현율의 균형 - Discord는 통계적 공식만 따르지 않고 50,000회의 실험을 시뮬레이션해 지표 수의 영향을 확인함. - 기본 실험 조건: - 효과가 없는 지표 20개는 평균 0, 표준편차 1인 정규분포에서 생성 - 한 지표에는 실제 효과 `z = 2.8`을 부여 - 지표 개수를 바꿔가며 일반 p-value 기준과 BH 보정 결과를 비교 - 시뮬레이션 결과: - 보정하지 않으면 지표 수가 늘어날수록 실험 전체에서 거짓 양성이 발생할 확률이 급격히 증가함. - 5개 지표에서는 거짓 양성률이 약 23%였지만, 50개에서는 약 93%까지 상승함. - BH 보정은 거짓 양성률을 약 5% 수준으로 유지함. - 그러나 지표 수가 5개에서 50개로 늘어나면 BH 적용 시 재현율이 약 60%에서 30%로 하락함. - 보정하지 않은 경우 재현율은 약 80%로 유지되지만, 거짓 양성이 지나치게 많아짐. ## 더 나은 실험 지표를 선택하는 방법 - 다중 검정 보정은 문제를 해결하는 만능 통계 기법이 아님. - 많은 지표를 넣은 뒤 보정으로 처리하는 방식은: - 거짓 경보는 줄이지만 - 실제 제품 변화를 놓칠 가능성을 높임 - 자동으로 모든 실험에 포함할 지표는 수를 줄여야 함. - 서로 중복되는 지표보다 사용자 행동, 품질, 안정성 등 서로 다른 개념을 대표하는 지표를 우선해야 함. - 지표의 개수뿐 아니라 각 지표가 실제 의사결정에 얼마나 유용한지도 정기적으로 검토해야 함. 실무적으로는 실험 기본 지표 목록을 작게 유지하고, 추가 지표는 명확한 가설이나 의사결정 목적이 있을 때만 포함하는 것이 좋습니다. BH 같은 보정 기법을 사용하더라도 지표 선택의 품질과 중복 제거가 통계적 보정보다 우선입니다.

원문 읽기(새 탭에서 열림)

a-b-testingstatistical-analysisexperiment-designbenjamini-hochberg-correction+3

toss·2026년 4월 23일원문

토스플레이스 데이터봇 ‘판다(PANDA)’를 소개합니다 : 모든 팀원이 데이터 전문가처럼 일하는 방법 (새 탭에서 열림)

토스플레이스는 데이터 분석가에게 집중된 단순 추출 요청을 해결하고 전사적인 데이터 민주주의를 실현하기 위해 AI 데이터 분석 어시스턴트 ‘판다(PANDA)’를 개발했습니다. 판다는 단순한 챗봇을 넘어 표준 데이터 마트 정비와 에이전트 기반의 자율 루프 시스템을 통해 데이터 조회부터 실무 인사이트 제공까지 수행하며, 출시 후 전사 구성원의 70%가 활용하는 필수적인 도구로 자리 잡았습니다. 기술적 복잡함보다 비즈니스 맥락과 데이터 거버넌스에 집중함으로써, 누구나 데이터 분석가의 도움 없이도 정확한 의사결정을 내릴 수 있는 환경을 구축했다는 데 큰 의의가 있습니다. ### 데이터 신뢰성을 위한 표준 데이터 마트(SSOT) 구축 * AI가 일관된 답을 낼 수 있도록 Data Analysis와 Platform 팀이 협업하여 핵심 데이터를 단일화된 테이블로 정비했습니다. * **표준 네이밍 컨벤션:** 테이블명은 `{역할}_{도메인}_{주제}`(예: fact_device_error_log)로, 컬럼명은 `{접두어}_{대상}_{속성}_{접미어}`(예: is_merchant_active)로 규칙화하여 AI가 이름만으로도 데이터의 목적을 이해하게 했습니다. * 모든 테이블과 컬럼에 상세 설명을 추가하여 AI가 데이터를 정확하게 탐색할 수 있는 기반 정보를 제공했습니다. ### 데이터 선택의 정확도를 높이는 Scoring & Ranking 시스템 * 질문에 대해 매번 다른 테이블을 선택하는 문제를 방지하기 위해 유사도와 신뢰도를 결합한 점수 체계를 도입했습니다. * **최종 점수 산출:** `(질문-테이블 유사도) × (데이터 계층 가중치)` 공식을 적용합니다. * **계층별 가중치:** 전사 주요 지표(SSOT)는 4배, 검증된 표준 마트는 3배, 도메인 마트는 2배, 원시 로그 데이터는 1배의 가중치를 부여하여 가장 신뢰할 수 있는 소스를 우선 선택하게 합니다. * dbt tags를 활용해 관리되는 테이블만 Manifest 파일로 가져와 탐색 범위를 최적화했습니다. ### 비즈니스 맥락 연결과 에이전틱 루프(Agentic Loop) * ‘설치 매장’이나 ‘업종 분류’와 같은 비즈니스 용어 정의를 데이터 구조와 연결하여 AI가 단순 수치 이상의 맥락을 파악하도록 설계했습니다. * AI가 스스로 상황에 맞는 도구를 선택하고, 결과가 부정확할 경우 스키마를 다시 확인하여 쿼리를 수정 및 재실행하는 자율적 재시도 과정을 거칩니다. * '테이블 탐색 → 쿼리 실행 → 결과 검증 → 수정 → 최종 결과 도출'의 과정을 반복하며 정답률을 높이는 구조를 갖췄습니다. ### 실무 활용성을 고려한 답변 구조 및 성과 * 단순 숫자 나열이 아니라 **결과, 조회 기준, 실무 인사이트**라는 3단계 구조로 답변을 제공하여 사용자의 해석 시간을 단축했습니다. * 출시 직후 전체 팀원의 절반 이상이 사용했으며, 현재는 70%의 사용률을 기록하며 데이터 요청에 대한 심리적 문턱을 낮추고 실질적인 업무 방식의 변화를 이끌어냈습니다. * 개발자, 기획자 등 비데이터 직군에서도 활발히 사용하며 데이터 분석가의 리소스를 고부가가치 분석 업무에 집중할 수 있도록 지원합니다. 성질 급한 AI 모델의 성능에만 의존하기보다, **데이터의 표준화와 비즈니스 로직의 명확한 정의(Governance)**가 선행될 때 비로소 실효성 있는 AI 서비스가 완성된다는 점을 시사합니다. 사내 데이터 민주화를 고민한다면, 기술적 기교 이전에 AI가 읽기 좋은 데이터 환경을 만드는 것부터 시작할 것을 추천합니다.

AI데이터베이스 설계머신러닝sql+4

toss·2026년 4월 23일원문

StarRocks 운영기: Resource Group으로 멀티테넌트 워크로드 격리하기 (새 탭에서 열림)

토스는 서비스 조회와 대규모 분석 쿼리를 하나의 플랫폼에서 처리하기 위해 StarRocks를 실시간 OLAP 엔진으로 도입하고, 다양한 워크로드가 공존하는 환경에서 리소스 그룹(Resource Group)을 통해 안정적인 운영 체계를 구축했습니다. 특히 CPU 우선순위 설정과 전용 코어 할당 방식을 전략적으로 선택하여, 대규모 배치 작업이 진행되는 중에도 서비스 쿼리의 응답 속도(SLA)를 일관되게 유지하는 최적의 격리 구조를 설계했습니다. **비즈니스 중요도에 따른 워크로드 분류** * 워크로드의 성격에 따라 서비스 쿼리, 서버 배치, 대규모 적재·백필, 모니터링·사용자 도구 순으로 우선순위를 정의했습니다. * 실시간 응답이 필수적인 서비스 쿼리는 가장 먼저 보호하고, 클러스터 전체에 부하를 줄 수 있는 대규모 적재나 단순 모니터링 조회는 하위 순위나 상한선을 두어 관리합니다. **가중치 기반의 유연한 리소스 분배 (cpu_weight)** * CPU 경합이 발생할 때 설정된 비율에 따라 리소스를 분배하는 방식으로, Linux CFS(Completely Fair Scheduler)와 유사한 자체 스케줄링 메커니즘을 사용합니다. * 리소스가 여유로울 때는 다른 그룹의 남는 자원을 빌려 쓸 수 있어(Borrowing), 일반적인 멀티테넌트 환경에서 리소스 효율성을 극대화하는 기본 설정으로 활용됩니다. * 내부적으로 파이프라인 드라이버가 100ms 타임 슬라이스 단위로 양보하며 동작하므로, 중요도가 높은 그룹이 더 많은 CPU 시간을 확보하게 됩니다. **물리적 코어 예약을 통한 배타적 격리 (exclusive_cpu_cores)** * 높은 SLA가 요구되는 특정 서비스의 경우, 물리적 코어를 전용으로 예약하여 다른 워크로드의 간섭을 완전히 차단합니다. * 이 설정은 단순히 논리적 할당에 그치지 않고, `pthread_setaffinity_np`를 통해 스레드를 코어에 바인딩하며 쿼리 실행을 위한 3벌의 ThreadPool(Driver, Scan, ConnectorScan)을 별도로 생성합니다. * 공유 리소스 풀과의 경합이 원천적으로 제거되므로, 헤비 배치 작업과 서비스 조회가 겹치는 상황에서도 응답 시간이 튀는 현상을 방지할 수 있습니다. **토스쇼핑 사례를 통한 단계적 최적화** * 초기에는 `cpu_weight` 조정을 통해 서비스 계정에 높은 우선순위를 부여했으나, 대규모 배치 작업 시 서비스 응답 속도가 불안정해지는 한계가 있었습니다. * 이를 해결하기 위해 서비스 전용 리소스 그룹에 `exclusive_cpu_cores`를 적용하여 물리적인 리소스 벽을 세웠습니다. * 결과적으로 분당 1,500건 이상의 서비스 요청이 발생하는 구간에서도 배치 작업의 영향 없이 안정적인 레이턴시를 확보하는 데 성공했습니다. **정교한 쿼리 매칭을 위한 Classifier 설계** * `user`, `role`, `query_type`, `db` 등의 속성을 기반으로 쿼리를 적절한 리소스 그룹에 할당하는 Classifier 규칙을 수립했습니다. * 운영 안정성을 위해 가급적 `user` 또는 `db` 단위로 그룹을 묶는 패턴을 권장하며, 이를 통해 특정 서비스나 배치 주체가 정해진 리소스 범위 내에서만 동작하도록 강제합니다. * CPU 제어 외에도 `mem_limit`과 `concurrency_limit`을 병행 설정하여 풀 스캔 쿼리의 메모리 독점이나 과도한 동시 접속으로 인한 클러스터 마비를 방지합니다. **실용적인 운영 제언** 가장 효율적인 운영 전략은 기본적으로 `cpu_weight`를 사용하여 리소스 효율을 높이되, 실시간 서비스와 같이 지연 시간에 민감한 워크로드에 한해서만 `exclusive_cpu_cores`를 단계적으로 도입하는 것입니다. 또한 리소스 그룹 설정 시 실제 물리 코어 수와 워크로드 간의 의존 관계를 면밀히 검토해야 예상치 못한 성능 저하를 막을 수 있습니다.

데이터베이스 설계mysqlhadoopstarrocks+4

toss·2026년 4월 23일원문

양자컴퓨터 시대에 대비한 양자내성암호 적용, 왜 10년 먼저 서비스에 적용했을까? (새 탭에서 열림)

토스페이먼츠는 20년 된 레거시 시스템을 개편하며 수만 개 가맹점의 안정성을 유지하는 동시에, 양자컴퓨터 시대를 대비한 보안 프로토콜 고도화를 성공적으로 완수했습니다. 보안은 '현재의 안전'뿐만 아니라 미래의 위협까지 선제적으로 대응해야 하는 영역이기에, 4년에 걸친 단계적 로드맵을 통해 가맹점의 부담을 최소화하며 양자내성암호(PQC)를 도입했습니다. 결제 데이터의 장기적 안전을 확보하기 위해 기술적 한계를 넘어서는 전사적 협업과 가맹점 밀착 지원이 이 과정의 핵심이었습니다. **보안 프로토콜 개선을 가로막는 관성과 현실적 제약** * **보수적 운영 원칙:** "돌아가면 건들지 마라"는 미션 크리티컬한 결제 서비스의 불문율이 보안 업데이트의 큰 장벽이 됩니다. * **가맹점의 낙후된 기술 스택:** 수만 개 가맹점 중에는 수십 년 전 기술 스택을 그대로 사용하는 곳이 많아, 최신 보안 정책 적용 시 결제가 중단될 위험이 큽니다. * **기술 지원의 한계:** 보안 용어에 익숙하지 않은 소상공인이나 전담 개발팀이 없는 가맹점은 단순 안내문만으로 대응하기 어려워 세밀한 기술 컨설팅이 필수적입니다. **양자컴퓨터의 위협과 '선수집·후복호화' 공격** * **기존 암호 체계의 붕괴:** 현재 사용되는 RSA, ECDSA 등은 양자컴퓨터의 압도적인 계산 능력 앞에서 사실상 무용지물이 됩니다. * **선수집·후복호화(Harvest Now, Decrypt Later):** 지금 암호화된 데이터를 미리 수집해두었다가 나중에 양자컴퓨터로 풀어보는 공격 방식으로, 결제 데이터처럼 장기적 가치를 지닌 정보에 치명적입니다. * **Q-Day 대비:** 실용 수준의 양자컴퓨터가 등장할 2030년경을 대비해, 데이터 유효 기간을 고려하면 지금 당장 암호 체계를 전환해야 합니다. **4단계 보안 프로토콜 고도화 로드맵** * **HTTP/3 도입 (2022):** 브라우저가 자동으로 최신 규약을 선택하게 함으로써 가맹점 작업 없이 보안성과 속도를 동시에 개선했습니다. * **취약 Cipher Suite 제거 (2022~2025):** 가장 고된 작업으로, 가맹점별 사용 환경을 분석해 3년 넘게 개별 기술 지원과 유예 기간을 거쳐 안전하지 않은 알고리즘을 퇴출했습니다. * **TLS 1.3 전면 도입 (2022~2025):** 구형 환경과의 호환성을 위해 TLS 1.2를 유지하면서도, 지원 가능한 클라이언트는 자동으로 더 안전한 1.3 버전을 쓰도록 기본값을 상향했습니다. * **양자내성암호(PQC) 도입 (2026):** PQC 지원 브라우저에는 최상위 보안 채널을 제공하고 미지원 환경에는 기존 암호를 제공하는 하이브리드 방식으로 연동 부담 없이 미래 위협에 대응했습니다. **조직적 협업과 실증적 성과** * **다학제적 팀워크:** 자체 데이터센터(IDC)를 관리하는 인프라 팀, AWS 환경을 담당하는 서버 플랫폼 팀, 그리고 가맹점 접점에서 기술 상담을 수행하는 TAM 팀의 유기적 협업이 성공의 열쇠였습니다. * **민간 보안 선도:** 정부의 '양자내성암호 전환 마스터플랜'에 발맞추어 민간 결제 생태계에서 선제적으로 기술 실증을 완료하여 결제 보안의 새로운 표준을 제시했습니다. 결제 서비스의 보안은 단순히 서버 설정을 바꾸는 기술적 작업을 넘어, 연결된 수많은 파트너와 함께 호흡하며 신뢰를 쌓아가는 과정입니다. 미래의 보안 위협은 이미 시작되었기에, 가맹점 환경을 배려하면서도 선제적으로 암호 체계를 전환하는 결단이 지속 가능한 비즈니스를 위한 필수 조건입니다.

데이터베이스 설계api-integrationpost-quantum-cryptographyhttp-3+3

naver·2026년 4월 22일원문

네이버 검색의 대규모 메트릭 저장소, VictoriaMetrics 운영기 (새 탭에서 열림)

데이터베이스 설계 시 관습적으로 사용하는 '소프트 삭제(Soft Delete)' 방식이 유발하는 구조적 결함과 성능 저하 문제를 심층적으로 분석하고 이를 해결할 수 있는 아키텍처 대안을 제시합니다. 삭제 여부를 나타내는 플래그(Flag) 컬럼을 사용하는 방식은 구현이 간단해 보이지만, 장기적으로는 쿼리의 복잡도를 높이고 데이터 무결성을 위협하는 원인이 됩니다. 따라서 서비스의 규모와 요구사항에 따라 데이터 이관이나 상태 관리를 통한 물리적 삭제를 적절히 혼합하는 전략이 필요합니다. **소프트 삭제가 초래하는 기술적 부채** - **쿼리 복잡도 및 휴먼 에러**: 모든 조회 쿼리에 `WHERE deleted = false`와 같은 조건을 강제해야 하며, 조인(Join) 연산이 늘어날수록 조건을 누락할 위험이 커져 보안 및 비즈니스 로직 오류로 이어집니다. - **유니크 제약 조건(Unique Constraint) 충돌**: 사용자 ID나 이메일처럼 유일성이 보장되어야 하는 컬럼에서, 삭제된 레코드가 테이블에 남아 있으면 동일한 값의 새 데이터를 삽입할 때 인덱스 충돌이 발생합니다. - **인덱스 효율 저하**: 삭제 플래그는 카디널리티(Cardinality)가 매우 낮은 데이터이므로 인덱스를 생성해도 스캔 효율이 떨어지며, 불필요한 데이터가 테이블에 계속 축적되어 전체적인 I/O 성능을 저하시킵니다. **무결성 유지를 위한 아키텍처 대안** - **데이터 이관(History/Archive Table) 방식**: 삭제가 발생할 때 해당 로우를 원본 테이블에서 물리적으로 삭제하는 대신, 트리거나 애플리케이션 로직을 통해 '삭제 전용 테이블'로 옮겨 메인 테이블의 크기를 최적화합니다. - **데이터베이스 뷰(View) 활용**: 애플리케이션 계층에서는 삭제되지 않은 데이터만 필터링된 뷰를 참조하게 함으로써 개발자가 실수로 삭제된 데이터를 조회하는 상황을 원천적으로 차단합니다. - **복합 유니크 인덱스 설계**: 삭제 시점을 기록하는 `deleted_at` 컬럼을 활용하여 `(ID, deleted_at)` 형태의 복합 인덱스를 구성함으로써, 삭제된 데이터와 활성 데이터 간의 제약 조건 충돌을 우회합니다. **실무적인 선택 기준** 단순히 데이터 복구 가능성을 위해 소프트 삭제를 채택하기보다는, 해당 데이터가 비즈니스적으로 '상태가 변경된 것(예: 탈퇴 회원)'인지 아니면 '완전히 폐기된 것'인지를 먼저 구분해야 합니다. 법적 근거에 의한 보관이 목적이라면 별도의 이력 테이블로 분리하는 것이 성능과 유지보수 측면에서 유리하며, 단순한 실수 방지가 목적이라면 트랜잭션 로그나 백업 시스템을 활용하는 물리 삭제 방식을 우선적으로 고려하는 것이 권장됩니다.

오픈 소스software-developmentdeveloper-communitystartups

kakao·2026년 4월 22일·4분 읽기큐레이션 요약

카카오톡 예약하기에서 그려 본 캘린더

카카오톡 예약하기는 카드 목록만으로는 재고와 예약을 한눈에 파악하기 어렵다는 문제를 해결하기 위해 타임 블록형 캘린더를 구현했다. 예약을 시작 시간과 종료 시간에 따라 정렬하고, 겹치는 예약을 그래프로 모델링한 뒤 DFS로 배치 깊이와 확장 가능 범위를 계산했다. 이후 루트 노드 간의 길이 차이로 남는 공간이 생기는 예외까지 보정해 예약 블록을 최대한 빈틈없이 배치했다. ## 캘린더 제작 배경과 요구사항 - 파트너센터의 예약 관리 화면은 예약을 카드 목록으로 보여주고 있었다. - 카드 목록은 많은 예약과 재고를 한눈에 비교하기 어렵다는 불편이 있었다. - 이를 해결하기 위해 예약과 재고를 시간축 위에서 확인할 수 있는 타임 블록형 캘린더를 제작했다. - 주요 요구사항은 다음과 같다. - 하나의 시간대에 최대 10개의 예약이 존재할 수 있다. - 하나의 예약은 최대 6시간을 차지한다. - 예약 블록 사이에 빈 공간을 최소화하면서 최대한 잘 보이게 배치해야 한다. ## 예약 배치 순서 ### 이용 시간이 이른 예약부터 정렬 - 예약이 입력된 순서가 아니라 시작 시간이 빠른 순서대로 배치했다. - 판매자가 하루를 시작할 때 가장 먼저 확인할 가능성이 높은 예약을 왼쪽 위에 배치하기 위한 결정이다. - 사용자의 시선이 일반적으로 왼쪽 위에서 오른쪽 아래로 이동한다는 시각적 우선순위도 고려했다. - 첫 번째 배치 규칙은 **“이용 시간이 이른 순서로 정렬한다”**이다. ### 같은 시간에는 소요 시간이 긴 예약부터 정렬 - 같은 시간대에 여러 예약이 겹치면 소요 시간이 긴 예약을 앞에 배치했다. - 긴 예약이 뒤로 밀리면 앞쪽 예약이 차지한 공간 때문에 긴 블록의 확장이 제한될 수 있다. - 긴 예약을 먼저 배치하면 이후 예약들이 남은 공간을 기준으로 배치되고, 각 예약이 확보할 수 있는 영역을 예측하기 쉬워진다. - 두 번째 배치 규칙은 **“같은 시간 내에서는 소요 시간이 긴 순서로 정렬한다”**이다. ## 예약을 그래프로 모델링 - 단순히 DOM 요소의 위치를 조정하는 대신, 예약 간의 겹침 관계를 그래프로 표현했다. - 각 예약을 그래프의 노드로 만들고, 서로 영향을 주는 예약을 연결했다. - 노드에는 예약 정보와 함께 이전 예약(`prevBooking`), 다음 예약(`nextBooking`) 같은 연결 관계를 저장했다. - 이 구조를 이용하면 예약이 어떤 경로로 연결되어 있고, 어느 정도까지 확장될 수 있는지 계산할 수 있다. ## DFS를 이용한 위치와 확장 범위 계산 - 각 노드에서 DFS를 수행해 다음 정보를 계산했다. - 그래프에서의 깊이 또는 레벨 - 연결된 예약 중 가장 끝에 있는 예약까지의 최대 거리(`maxLength`) - 깊이는 예약 블록의 가로 방향 위치를 결정하는 데 사용된다. - 최대 거리는 해당 예약이 오른쪽으로 얼마나 확장될 수 있는지 판단하는 기준이 된다. - 계산된 값을 바탕으로 각 노드의 다음 UI 속성을 구한다. - `left`: 블록의 시작 위치 - `width`: 블록이 차지할 가로 너비 - 그래프의 가장 왼쪽에 있는 노드부터 기준을 잡아 예약 블록을 배치하고 확장했다. ## 루트 노드 간 길이 차이로 발생한 예외 - 초기 알고리즘은 모든 예약이 연결된 그래프에서도 공간이 남는 경우를 완전히 처리하지 못했다. - 위쪽 루트 노드의 `maxLength`가 더 길고, 아래쪽 루트 노드의 `maxLength`가 짧으면 하위 그래프가 끝까지 확장되지 않았다. - 그 결과 예약 간 연결은 유지되지만 일부 빈 공간이 남는 문제가 발생했다. - 이 문제를 해결하기 위해 다음과 같은 보정 과정을 추가했다. - 현재 노드의 `left + width`보다 다음 노드의 `left`가 크면 두 노드 사이에 확장 가능한 공간이 있다고 판단한다. - 해당 노드와 연결된 예약들을 확인한다. - 여러 개의 빈 공간이 있으면 가장 작은 공간을 기준으로 연결된 노드들의 너비를 확장한다. - 이 과정을 반복해 예약 블록이 가능한 한 빈틈없이 영역을 채우도록 했다. ## 구현 과정에서 얻은 교훈 - 겉보기에는 단순한 UI라도 다양한 입력 데이터와 최악의 배치 상황을 고려해야 한다. - 타임 블록 캘린더는 예약의 정렬, 겹침 처리, 가로 확장, 예외 보정이 결합된 알고리즘 문제에 가깝다. - 그래프와 DFS 같은 자료구조·알고리즘이 실제 프런트엔드 UI 배치 문제를 해결하는 데 직접 활용될 수 있다. - 프런트엔드 개발자는 데이터를 화면에 어떻게 보여줄지 결정하는 책임과 권한을 함께 가진다. - 실제 서비스에서는 초기 알고리즘을 완성형으로 보기보다, 운영 중 발견되는 버그와 새로운 입력 패턴에 맞춰 지속적으로 개선해야 한다. 타임 블록 캘린더를 구현할 때는 먼저 예약을 시작 시간과 지속 시간 기준으로 안정적으로 정렬하고, 겹침 관계를 그래프로 모델링하는 방식이 유용하다. 이후 DFS로 배치 깊이와 확장 범위를 계산하되, 루트별 길이 차이로 생기는 잔여 공간과 같은 예외 케이스를 별도로 검증하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

사용자 인터페이스data-visualizationfrontendcalendar-ui+2

cloudflare·2026년 4월 22일원문

신뢰할 수 있는 Rust Worker 만들기: wasm-bindgen에서의 패닉 및 중단 복구 (새 탭에서 열림)

Cloudflare Workers 환경에서 Rust로 작성된 WebAssembly(Wasm)는 예기치 못한 패닉(Panic)이나 중단(Abort)이 발생할 경우 런타임이 정의되지 않은 상태로 남아 동일한 인스턴스의 다른 요청까지 실패하게 만드는 '샌드박스 오염' 문제를 안고 있었습니다. 이를 해결하기 위해 Cloudflare는 `wasm-bindgen` 메인 프로젝트와 협력하여 Wasm 예외 처리 기능을 활용한 `panic=unwind` 지원과 중단 복구 메커니즘을 도입했습니다. 결과적으로 단일 요청의 실패가 전체 서비스 중단으로 이어지는 것을 방지하고, 상태 유지가 필요한 애플리케이션에서도 안정적인 오류 복구가 가능해졌습니다. ### 초기 대응 및 완화 전략 본격적인 기능 개선에 앞서, Cloudflare는 운영 환경에서의 피해를 최소화하기 위해 사용자 정의 패닉 핸들러와 JavaScript 프록시를 활용한 초기 완화책을 적용했습니다. * **패닉 핸들러 도입:** Rust 내부에 상태를 추적하는 패닉 핸들러를 설치하여 실패가 발생하면 전체 애플리케이션을 다시 초기화하도록 설정했습니다. * **Proxy 기반 간접 참조:** JavaScript 영역에서 Rust 호출 경계를 `Proxy`로 감싸 모든 진입점을 캡슐화하고, 실패 시 안전하게 Wasm 모듈을 재로드했습니다. * **한계점:** 이 방식은 서비스 가용성은 높였으나, 전체 애플리케이션을 재시작해야 하므로 메모리에 상태를 보관하는 Durable Objects 같은 서비스에서는 데이터 손실이 발생하는 단점이 있었습니다. ### Wasm 예외 처리를 통한 panic=unwind 구현 상태를 보존하면서 오류를 복구하기 위해 Wasm의 최신 표준인 예외 처리(Exception Handling) 제안을 활용하여 Rust의 패닉 언와인딩(Unwinding)을 구현했습니다. * **컴파일 옵션 변경:** `RUSTFLAGS='-Cpanic=unwind'`와 `-Zbuild-std`를 사용하여 표준 라이브러리가 언와인딩을 지원하도록 다시 빌드했습니다. * **wasm-bindgen 툴체인 업데이트:** Wasm 파서인 Walrus가 `try`, `catch`, `rethrow` 명령어를 인식하도록 수정하고, JavaScript와 Rust 경계에서 예외가 올바르게 전달되도록 개선했습니다. * **Boundary 처리:** Rust에서 발생한 패닉이 JavaScript의 `PanicError`로 변환되도록 했으며, `extern "C-unwind"`를 통해 함수 호출 경계를 넘나드는 언와인딩을 허용했습니다. * **클로저 안전성:** `MaybeUnwindSafe` 트레잇을 도입하여 언와인딩 시 안전하지 않은 참조를 캡처하는 클로저를 체크하고, 필요한 경우 패닉 시 즉시 중단되는 `Closure::new_aborting` 변형을 제공합니다. ### 중단(Abort) 복구 및 포이즌 필(Poison Pill) 메커니즘 메모리 부족(OOM)과 같이 언와인딩이 불가능한 '중단' 상황에서는 메모리 상태가 오염될 가능성이 높기 때문에, 해당 인스턴스의 재실행을 원천 봉쇄하는 전략을 사용합니다. * **포이즌 필 플래그:** `wasm-bindgen`은 이제 모든 Wasm 모듈에 내부 상태 플래그를 주입합니다. 만약 Rust 코드에서 중단이 발생하면 이 플래그가 즉시 설정됩니다. * **재실행 방지:** 이후 JavaScript에서 해당 Wasm 인스턴스의 어떤 함수라도 호출하려고 하면, Rust 코드를 실행하기 전에 플래그를 먼저 확인하여 즉시 JavaScript 에러를 발생시킵니다. * **안전성 보장:** 이를 통해 오염된 메모리 상태에서 코드가 다시 실행되어 발생할 수 있는 보안 취약점이나 예측 불가능한 동작을 완전히 차단합니다. Wasm 기반의 Rust 서비스를 운영한다면 최신 버전의 `wasm-bindgen`과 `workers` 라이브러리를 사용하고, 특히 Durable Objects와 같이 상태 보존이 중요한 경우 `panic=unwind` 설정을 활성화할 것을 권장합니다. 이는 단순한 안정성 향상을 넘어, Wasm이 네이티브 환경과 동등한 수준의 오류 복구 능력을 갖추게 되었음을 의미합니다.

데이터베이스 설계Rustwebassemblywasm-bindgen+2

line·2026년 4월 22일원문

신뢰성 향상을 위한 SLO/SLI 도입 3편 - 서비스 적용 사례 (새 탭에서 열림)

SLI(Service Level Indicator)와 SLO(Service Level Objective)의 도입은 단순히 지표를 설정하는 기술적 작업을 넘어, 사용자 중심의 관점으로 서비스를 재정의하고 조직의 협업 문화를 구축하는 과정입니다. 정량적인 지표와 오류 예산(Error Budget) 개념을 활용하면 서비스의 신뢰성과 비즈니스 혁신 사이에서 객관적인 판단 근거를 마련할 수 있습니다. 결과적으로 SLO는 사용자에게 안정적인 경험을 제공하는 동시에 엔지니어링 리소스를 효율적으로 배분하는 핵심 도구가 됩니다. **신뢰성 향상을 위한 마인드셋과 협업** * **사용자 여정 중심의 사고**: 서비스의 수많은 기능 중 사용자가 가장 많이 사용하거나 반드시 필요한 '핵심 사용자 여정(CUJ)'을 식별하는 것이 첫걸음입니다. * **다학제적 협업 체계**: 서비스 담당 부서(CUJ 정의), 인프라 조직(측정 환경 구축), SRE(도구 구현 및 모니터링) 등 이해관계자 모두가 목표를 공유하고 책임을 나누는 문화가 필수적입니다. **SLI/SLO 구현의 4단계 프로세스** * **CUJ 분석**: 가입, 메시지 송수신, 인증과 같이 비즈니스 목표와 사용자 경험에 직결되는 핵심 기능을 사용자 관점에서 선별합니다. * **SLI 정의**: 게이트웨이나 백엔드 등 적절한 측정 위치를 선정하고, 응답 시간(Latency)의 퍼센타일과 응답 성공률(Success Rate)에 대한 명확한 성공/실패 기준을 수립합니다. * **SLO 타깃 설정**: 28일 등 특정 기간 동안 달성할 현실적인 목표 수치를 정하며, 안정성 확보 비용과 사용자 경험 사이의 적절한 균형점을 찾습니다. * **시각화**: 전체 상태와 오류 예산 현황을 한눈에 파악할 수 있도록 대시보드를 구성하며, 색상(초록/주황/빨강)을 활용해 직관적인 인지성을 높입니다. **오류 예산을 활용한 의사 결정 및 운영** * **정량적 소통**: '서비스가 느리다'는 추상적 표현 대신 '응답 시간이 SLI 기준인 400ms를 초과했다'는 식의 정확한 데이터로 문제를 파악합니다. * **리소스 배분 가이드**: 오류 예산이 넉넉하면 신규 기능 출시나 공격적인 릴리스에 집중하고, 예산이 소진되어 가며 안정성 강화와 이슈 대응에 리소스를 우선 투입합니다. * **온콜(On-call) 및 예방**: 오류 예산의 상태 변화를 실시간 알림으로 받아 이슈에 신속히 대응하며, 정기적인 SLO 점검을 통해 서비스 품질을 지속적으로 관리합니다. 성공적인 SRE 문화를 정착시키기 위해서는 SLO를 단순한 규제가 아닌, 서비스의 안정성과 혁신 속도 사이에서 균형을 잡아주는 나침반으로 활용하는 것이 중요합니다. 측정 가능한 지표를 통해 막연한 불안감을 해소하고, 데이터에 기반한 의사결정을 내릴 때 비로소 지속 가능한 서비스 신뢰성을 확보할 수 있습니다.

옵저버빌리티site-reliability-engineeringresource-allocationservice-level-indicator+4

gitlab·2026년 4월 22일원문

GitLab AI 해커톤 2026: 수상자를 만나보세요 (새 탭에서 열림)

GitLab AI 해커톤 2026은 단순한 코드 생성을 넘어 보안, 컴플라이언스, 배포 등 소프트웨어 개발 전 과정을 자율적으로 수행하는 600개 이상의 AI 에이전트 생태계를 확인한 자리였습니다. 구글 클라우드 및 앤스로픽(Anthropic)과 협업한 이번 행사에는 약 7,000명의 개발자가 참여하여, 실질적인 워크플로우에 통합되어 팀을 대신해 행동하는 혁신적인 솔루션들을 대거 선보였습니다. 이는 AI가 챗봇 형태를 벗어나 복잡한 엔지니어링 문제를 해결하는 능동적인 에이전트로 진화했음을 입증하는 결과입니다. ### 조직 지식 보존과 시스템 이해: LORE 및 GraphDev * **대상(Grand Prize) 수상작 'LORE'**: 8개의 에이전트와 라우터를 활용해 엔지니어의 머릿속에만 있던 '암묵적 지식'을 기록하고 관리합니다. 지식 그래프의 순환 루프 방지 로직과 탄소 추적 기능을 갖췄으며, 해커톤 프로젝트임에도 43개의 테스트 코드를 포함할 정도로 완성도가 높습니다. * **Anthropic 부문 우승작 'GraphDev'**: 코드 간의 연결 고리를 매핑하여 시스템이 시간에 따라 어떻게 변하는지 보여줍니다. 코드 변경 시 미칠 영향을 사전에 시각화하여 복잡한 시스템의 진화 과정을 쉽게 파악할 수 있도록 돕습니다. * **RepoWarden**: 코드의 기능뿐만 아니라 '왜' 그렇게 작성되었는지를 캡처하는 '리빙 스펙 엔진(Living Specification Engine)' 역할을 수행합니다. ### 보안 및 컴플라이언스 자동화 * **보안 자동화 솔루션**: 구글 클라우드 부문 우승작 'Gitdefender'는 코드 리뷰 중 보안 문제를 발견하면 즉시 수정 코드를 작성하고 리뷰를 생성합니다. 'RedAgent'는 AI가 생성한 보안 보고서를 재검증하여 AI 진단 결과에 대한 신뢰 격차를 해소합니다. * **컴플라이언스 관리**: 'Compliance Sentinel'은 머지 요청(MR)의 리스크를 점검해 위반 사항이 있으면 차단하며, 'MR Compliance Auditor'는 증거 자료를 수집해 SOC 2 통제 항목과 매핑한 후 실시간 대시보드로 송출합니다. * **SecurityMonkey**: 테스트 브랜치에 알려진 취약점을 주입하여 현재 보안 스캐너가 이를 얼마나 잘 잡아내는지 점검하는 독특한 접근 방식을 선보였습니다. ### 기술적 완성도와 운영 효율화 * **안전한 마이그레이션**: 'Time-Traveler'는 운영 환경의 복제본을 생성하여 데이터베이스 마이그레이션을 선제적으로 실행해 봄으로써 배포 실패를 방지합니다. 5개의 에이전트가 브릿지로 연결되어 실제 PostgreSQL 환경에서 작동합니다. * **모바일 기반 워크플로우**: 'stregent'는 개발자가 노트북 없이도 WhatsApp을 통해 CI/CD 파이프라인을 모니터링하고 수정 사항을 머지할 수 있는 모바일 우선 경험을 제공합니다. * **문서화 에이전트 'DocSync'**: 감지(Detector), 작성(Writer), 검토(Reviewer)라는 세 단계 에이전트 체계를 통해 문서화 작업을 자동화하며, 신뢰도가 낮을 경우 사람에게 이슈를 생성해 검토를 요청합니다. ### 지속가능성을 고려한 그린 에이전트(Green Agent) * **탄소 배출 최적화**: 'GreenPipe'와 'CarbonLint' 등은 CI/CD 파이프라인과 LLM 실행에 따른 탄소 발자국을 측정하고 보고서를 생성합니다. * **운영 비용 절감**: 일부 프로젝트는 모델 최적화와 에너지 효율적인 아키텍처 설계를 통해 운영 비용을 월 $556에서 $18로 약 96% 절감하는 성과를 거두었습니다. * **실시간 최적화 팁**: 'Carbon Tracker'는 각 파이프라인 작업의 탄소 배출량을 계산하여 머지 요청 시 최적화 팁을 자동으로 댓글로 남겨줍니다. 이제 AI 에이전트는 단순한 도구를 넘어 로컬 지식 그래프와 결합하여 코드의 맥락과 역사를 이해하는 방향으로 발전하고 있습니다. 기업들은 GitLab Duo Agent Platform과 같은 환경을 통해 보안 점검, 데이터베이스 마이그레이션, 컴플라이언스 준수와 같은 고난도 수동 작업을 자동화함으로써 엔지니어링 생산성을 획기적으로 높일 수 있을 것입니다.

데이터베이스 설계머신러닝CI/CDgitlab+4

spotify·2026년 4월 22일·4분 읽기큐레이션 요약

LLM 평가로 더 나은 실험하기 — 포크가 아닌 퍼널 | Spotify Engineering

LLM 평가(evals)는 실험을 대체하는 도구가 아니라, 실험 전에 유망한 후보를 걸러내고 실험 후 판단 기준을 보정하는 퍼널의 일부다. Evals는 출력의 품질과 의도 부합 여부를 검증하지만, 실제 사용자의 행동과 사업 성과까지 검증하지는 못한다. 따라서 오프라인 평가와 온라인 A/B 테스트를 반복적으로 연결해야 실험 성공률과 평가 모델의 신뢰도를 함께 높일 수 있다. ## Evals와 실험의 역할 차이 - **Evals는 검증(verification)**을 담당한다. - 출력이 관련성, 일관성, 어조, 의도 부합성 등 정해진 품질 기준을 만족하는지 평가한다. - 대규모 데이터에서 사람의 수작업 평가보다 빠르고 저렴하게 후보를 비교할 수 있다. - **실험은 검증(validation)**을 담당한다. - 실제 사용자가 변경된 결과에 어떻게 반응하는지 확인한다. - 개선된 출력이 참여도, 유지율, 매출 등 실제 사업 성과로 이어지는지 측정한다. - 따라서 관계는 “eval 또는 실험”이라는 분기가 아니라, **eval로 후보를 좁힌 뒤 실험으로 사업 효과를 확인하는 퍼널**이어야 한다. - Spotify의 사례에서도 A/B 테스트 중 긍정적인 결과로 출시되는 비율은 약 12%지만, 약 64%는 회귀를 발견하거나 가설을 수정하는 등 유효한 학습을 제공한다. ## Evals가 제공하지만 제공하지 못하는 것 - LLM judge는 다음과 같은 품질 문제를 대규모로 탐지할 수 있다. - 사용자 의도와 맞지 않는 추천 - 신뢰를 훼손하는 콘텐츠 - 응답의 관련성, coherence, 어조 문제 - 평가 과정에서 팀이 예상하지 못한 문제 패턴을 발견할 수 있다. - 예를 들어 부적절한 추천이 특정 사용자군이나 상황에서 반복된다는 사실을 찾아낼 수 있다. - 발견된 패턴은 제품 개선 가설이 된다. - 같은 judge를 수정 후에도 사용하면 문제가 실제로 줄었는지 확인할 수 있다. - 문제가 되는 평가 항목의 발생 빈도가 감소하면 구현 품질이 개선된 것으로 볼 수 있다. - 그러나 eval만으로는 다음을 알 수 없다. - 사용자의 장기 참여도가 높아졌는지 - 이탈이나 churn이 줄었는지 - 시스템 전체에서 예상치 못한 부작용이 발생했는지 - Spotify에서는 출시된 실험의 약 42%가 세션 길이, 충돌률, 유지율 등 **최적화 대상이 아니었던 보조 지표의 회귀** 때문에 되돌려졌다. 이런 문제는 오프라인 eval에서 포착되지 않을 수 있으므로 온라인 실험과 가드레일 지표가 필요하다. ## 두 단계의 보정과 평가 드리프트 - Evals는 실제 성과를 직접 측정하는 것이 아니라, 성과를 대신하는 **프록시 점수**다. - 기존의 정량 지표(랭킹 점수, precision, recall) 위에 LLM judge라는 또 하나의 보정 계층이 추가된다. - 두 계층 모두 실제 온라인 결과와 비교해 보정해야 한다. - judge가 더 높은 점수를 준 변형이 실제로 더 나은 사용자 경험을 제공하는가? - judge가 실질적 가치가 아닌 표면적 문체나 특정 패턴을 보상하고 있지는 않은가? - 평가 기준은 시간이 지나면서 드리프트할 수 있다. - 모델, 사용자 행동, 콘텐츠 유형, 제품 목표가 바뀌면 기존 judge의 점수와 실제 성과의 관계가 약해질 수 있다. - Qodo의 코딩 eval에서는 Anthropic의 Opus 4.5가 개선되지 않은 것처럼 보였지만, 실제로는 긴 작업에서 성능이 크게 향상된 사례가 있었다. - 반대로 eval 점수는 좋아졌지만 실제 사용자 성과가 개선되지 않는 경우도 가능하다. - 따라서 오프라인 점수와 온라인 결과를 지속적으로 비교해야 eval이 단순한 의견이 아니라 신뢰할 수 있는 증거가 된다. ## 실험 전후를 연결하는 피드백 루프 - **실험 전** - 여러 후보를 LLM eval로 평가한다. - 품질 기준을 충족하지 못하는 후보를 제거한다. - 남은 후보에 실험 리소스를 집중해 실험의 적중률을 높인다. - **실험 중** - 주요 사업 지표뿐 아니라 최적화하지 않은 가드레일 지표도 관찰한다. - 세션 길이, 오류율, 충돌률, 유지율처럼 회귀 가능성이 있는 지표를 함께 확인한다. - **실험 후** - A/B 테스트에 사용된 실제 데이터에 eval을 다시 적용한다. - judge가 선호한 변형이 실제 사용자 성과도 개선했는지 비교한다. - eval 점수와 실험 결과 사이의 차이를 다음 평가 기준을 개선하는 신호로 활용한다. - 결과가 어느 쪽이든 학습이 발생한다. - eval과 사용자 성과가 함께 개선되면 judge가 가치 있는 품질 요소를 측정하고 있다는 뜻이다. - eval만 개선되고 사용자 성과가 그대로라면 judge가 사업 성과와 무관한 요소를 측정하고 있다는 뜻이다. ## 상황에 따른 실험 강도 - 모든 변경에 동일한 수준의 증거를 요구할 필요는 없다. - 빠른 반복 단계에서는 방향성을 파악하기 위한 간단한 테스트를 사용할 수 있다. - 출시 결정이나 영향 범위가 큰 변경에는 충분한 표본, 장기 지표, 가드레일을 포함한 엄격한 실험이 필요하다. - 시스템이 복잡할수록 실험을 생략해 발생하는 대규모 회귀 위험이 커진다. 실무적으로는 LLM eval을 **후보 선별과 품질 진단**에 사용하고, 최종 출시는 반드시 사용자 대상 실험과 가드레일 지표로 판단하는 방식이 권장된다. 실험 결과를 다시 eval 보정에 반영하면 시간이 지날수록 더 정확한 평가 체계를 구축할 수 있다.

원문 읽기(새 탭에서 열림)

머신러닝a-b-testingllm-evalsonline-experiments+3

gitlab·2026년 4월 22일원문

GitLab 패치 릴리스: 18.11.1, 18.10.4, 18.9.6 | GitLab 문서 (새 탭에서 열림)

GitLab은 2026년 4월 22일, 다수의 보안 취약점과 버그를 해결하기 위해 GitLab Community Edition(CE) 및 Enterprise Edition(EE)의 패치 버전인 18.11.1, 18.10.4, 18.9.6을 출시했습니다. 이번 업데이트는 GraphQL API의 CSRF 문제와 Web IDE 내 임의 자바스크립트 실행 등 심각도가 높은 보안 결함을 포함하여 총 10건 이상의 취약점을 해결하는 것을 핵심으로 합니다. 시스템의 안전한 운영을 위해 자체 호스팅(Self-managed) 환경을 사용하는 모든 관리자는 최신 패치 버전으로 즉시 업그레이드할 것을 강력히 권고합니다. ### 고위험 보안 취약점 해결 * **CVE-2026-4922 (GraphQL API CSRF):** GraphQL API의 CSRF 보호가 불충분하여 인증되지 않은 사용자가 인증된 사용자를 대신해 뮤테이션(Mutation)을 실행할 수 있는 문제를 해결했습니다. (CVSS 점수 8.1) * **CVE-2026-5816 (Web IDE 경로 검증 오류):** 특정 조건에서 웹 IDE 자산의 경로 검증이 부적절하게 이루어져, 인증되지 않은 사용자가 사용자의 브라우저 세션에서 임의의 자바스크립트를 실행할 수 있는 취약점을 수정했습니다. (CVSS 점수 8.0) * **CVE-2026-5262 (Storybook XSS):** Storybook 개발 환경에서 입력값 검증 미흡으로 인해 인증되지 않은 사용자가 토큰에 접근할 수 있는 교차 사이트 스크립팅(XSS) 이슈를 해결했습니다. (CVSS 점수 8.0) ### 서비스 거부(DoS) 취약점 보완 * **리소스 고갈 방지:** 토론(Discussions) 엔드포인트(CVE-2025-0186), 노트(Notes) 엔드포인트(CVE-2025-6016), GraphQL API(CVE-2025-3922)에서 리소스 할당 제한이 미흡하여 서버 자원을 고갈시킬 수 있는 DoS 문제를 수정했습니다. * **Jira 가져오기 오류(CVE-2026-1660):** 이슈를 가져오는 과정에서 부적절한 입력값 검증으로 인해 인증된 사용자가 DoS를 유발할 수 있는 취약점을 해결했습니다. ### 접근 제어 및 세션 관리 개선 * **가상 레지스트리 세션(CVE-2026-6515):** 만료되거나 잘못된 범위의 인증 정보를 사용하여 가상 레지스트리에 접근할 수 있었던 세션 만료 관련 이슈를 수정했습니다. * **비공개 정보 노출 차단(CVE-2026-5377):** 이슈 설명 렌더링 과정의 접근 제어 오류로 인해, 공개 프로젝트 내에서 비공개 이슈의 제목이 노출될 수 있는 문제를 해결했습니다. * **UI 레이어 및 API 보안:** Mermaid 샌드박스 내 입력값 검증 오류(CVE-2026-3254)와 프로젝트 포크(Fork) 관계 API의 부적절한 접근 제어 문제를 수정했습니다. 현재 GitLab.com은 이미 패치된 버전이 적용되어 있으며, GitLab Dedicated 고객은 별도의 조치가 필요하지 않습니다. 그러나 Omnibus, Helm Chart, 소스 코드 설치 등 모든 유형의 자체 호스팅 설치 환경은 이번 취약점의 영향을 받으므로, 관리자는 보안 하이진 유지를 위해 지원되는 최신 패치 버전으로 즉시 업그레이드해야 합니다. 상세한 취약점 정보는 패치 릴리스 30일 후에 GitLab 이슈 트래커를 통해 공개될 예정입니다.

gitlabGraphQLvulnerability-managementcross-site-scripting+4