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

line4분 읽기큐레이션 요약

오픈챗 이름 및 설명 글로 유해성 판단하는 모델 개발하기

LINE AI Services Lab은 오픈챗 이름과 설명을 바탕으로 징계 수위와 사유를 예측하는 자동 모니터링 모델을 개발했다. 기존 모델의 적용 범위를 넓히기 위해 데이터를 정제하고, 안전성 모더레이션에 특화된 2B 규모의 Granite Guardian 3.1 2B를 LoRA로 학습했다. 최종적으로 자연어 단일 토큰과 토큰별 확률을 활용해 실시간 운영에 적합한 분류 구조를 구현했다. ## 오픈챗 모니터링의 목적 - 오픈챗은 생성되거나 이름·설명 글이 수정될 때마다 운영 정책 위반 여부를 검수해야 한다. - LINE은 글로벌 서비스로 생성·수정되는 오픈챗이 많아, 사람의 수동 검수만으로는 대응하기 어렵다. - 기존 모니터링 모델은 여러 국가에서 효과를 보였지만, 국가별로 세분화된 판단 기준이 필요한 경우에는 자동 검수가 제한됐다. - 이번 프로젝트의 목표는 자동 검수 적용 국가와 범위를 확대하고, 기존 적용 국가의 정확도도 높이는 것이었다. ## 중복 데이터와 불일치 라벨 정제 - 현재 가이드라인과 일치하도록 해당 가이드라인이 적용된 기간의 수동 검수 데이터만 학습에 사용했다. - 동일한 오픈챗 이름과 설명에 서로 다른 징계 결과가 부여된 사례를 하나의 최종 라벨로 통합했다. - 징계 코드 처리 기준: - 가장 높은 수위의 징계가 2회 이상이면 해당 징계를 최종 라벨로 선택한다. - 최고 수위 징계가 한 번만 나타나면 노이즈일 가능성을 고려해 두 번째로 높은 수위의 징계를 선택한다. - 징계 사유 처리 기준: - 동일 그룹에서 가장 많이 등장한 사유를 우선한다. - 빈도가 같으면 전체 데이터에서 더 드문 사유를 선택한다. - 이는 희귀한 사유가 해당 데이터를 더 구체적으로 설명할 수 있다는 TF-IDF의 발상에서 착안했다. ## Granite Guardian 3.1 2B 선정 - 사전 학습 모델은 다음 조건으로 검토했다. - 디코더 기반 모델 - 안전성 모더레이션 과제로 튜닝된 모델 - 약 2B 규모 - 상업적 활용이 가능한 Apache 라이선스 - 실시간으로 대량의 오픈챗을 처리해야 하므로, 대형 모델보다 추론 비용과 응답 속도가 낮은 모델이 필요했다. - Granite Guardian은 입력이 유해한지에 대해 `Yes` 또는 `No` 토큰을 생성하는 방식으로 안전성을 판별한다. - 특정 후보 토큰의 생성 확률을 비교하므로 출력 형식이 흔들리지 않고, 확률을 신뢰도로 활용해 운영 임계값을 조정하기 쉽다. ## 징계 코드와 사유를 함께 예측하는 학습 구조 - 오픈챗 검수는 단순한 유해·무해 이진 분류가 아니다. - 유해성의 정도에 따라 징계 수위가 달라진다. - 징계 사유도 함께 예측하고 안내해야 한다. - 이를 위해 모델 응답을 다음과 같은 구조로 정의했다. ```text Action:{징계 코드 토큰} Reason:{징계 사유 토큰} ``` - Cross Entropy Loss를 사용하되, 전체 프롬프트가 아니라 모델의 응답 영역에 대해서만 손실을 계산했다. - 입력 문장을 복사하는 능력보다 징계 코드와 사유를 정확히 예측하는 능력이 중요하기 때문이다. - 전체 파라미터 대신 LoRA를 적용했다. - 기존 모델 파라미터는 고정한다. - 학습해야 할 변화량을 작은 행렬 두 개의 곱으로 근사한다. - 업데이트 파라미터와 메모리 사용량을 줄이면서 사전 학습 능력을 유지한다. ## 자연어 단일 토큰을 활용한 추론 - 실제 징계 코드와 사유 코드는 알파벳·숫자 조합이라 토크나이저에 의해 여러 토큰으로 분할될 수 있다. - 여러 토큰으로 나뉘면 각 코드의 생성 확률을 직접 비교하기 어렵다. - 따라서 코드와 사유를 의미 있는 자연어 표현으로 매핑하고, 각각 하나의 토큰으로 표현되도록 구성했다. - 자연어 토큰은 임의의 코드값보다 모델이 의미를 학습하기에도 유리할 것으로 판단했다. ## 단계별 확률 계산과 KV 캐싱 - 첫 번째 단계에서 모델의 마지막 출력 로짓 중 징계 코드 토큰에 해당하는 값만 추출한다. - 해당 값에 softmax를 적용해 코드별 확률을 계산하고, 가장 높은 확률의 징계 코드를 선택한다. - 이후 선택된 코드와 `Reason:` 프롬프트를 모델에 추가 입력해 징계 사유를 예측한다. - 징계 사유 역시 사유 토큰 후보의 확률만 비교해 최종 결과를 선택한다. - 두 번째 단계에서는 첫 번째 추론의 `past_key_values`를 재사용하는 KV 캐싱을 적용해 반복적인 계산을 줄였다. ## 실용적인 결론 이 사례는 대규모 생성 모델을 그대로 사용하는 대신, 작은 안전성 특화 디코더 모델에 구조화된 출력 형식과 LoRA를 결합해 실시간 콘텐츠 모니터링에 맞춘 접근이다. 운영 환경에서는 단순 정확도뿐 아니라 라벨 품질, 토큰별 신뢰도, 임계값별 검수량과 오탐·미탐 비용을 함께 평가하는 것이 중요하다.

원문 읽기(새 탭에서 열림)
gitlab4분 읽기큐레이션 요약

포레스터 컨설팅: GitLab Duo 에이전트 플랫폼, 400% 투자 수익률 달성

GitLab Duo Agent Platform 도입 기업은 3년간 400%의 투자수익률(ROI)과 750만 달러의 순현재가치(NPV)를 달성했으며, 투자금 회수 기간은 6개월 이내로 분석됐다. 효과는 단순한 코드 생성 속도 향상에 그치지 않고, 개발자 온보딩·코드 리뷰·보안 취약점 수정·대규모 마이그레이션 등 소프트웨어 생명주기 전반에서 나타났다. 다만 수치는 4개 기업의 경험을 바탕으로 구성한 가상 조직의 사례이므로 모든 기업에 동일하게 적용된다고 보기는 어렵다. ## 분석 대상과 투자 구조 - Forrester Consulting은 금융 서비스, 소프트웨어 개발, 엔터테인먼트, 보험 업계의 의사결정권자 4명을 인터뷰했다. - 인터뷰 결과를 바탕으로 다음과 같은 복합 조직을 구성했다. - 연 매출 30억 달러 - 직원 3,000명 - GitLab Duo Agent Platform 사용자 수가 3년간 150명에서 250명으로 증가 - 3년간 위험 조정 비용은 약 190만 달러였다. - 소비 크레딧: 130만 달러 - 구현 및 운영 관리: 58만 9,000달러 - 파일럿, 교육, 지원에 필요한 내부 인력 비용 포함 - 총 편익은 940만 달러로 산정됐다. - 투자 대비 수익률: 400% - 순현재가치: 750만 달러 - 투자금 회수 기간: 6개월 미만 ## 도입 전: 수작업과 전문 인력 의존 - 빌드, 코드 리뷰, 보안 작업이 수작업 중심으로 운영됐다. - 신규 개발자가 코드베이스나 사내 규칙을 이해하려면 선임 엔지니어의 직접적인 지원이 필요했다. - 보안 취약점 수정은 관련 지식과 맥락을 가진 소수의 전문가가 처리할 때까지 대기열에 쌓였다. - 개발자들은 코드를 작성하는 시간보다 코드 리뷰와 문제 해결에 더 많은 시간을 소모했다. - 비공식적인 지식 공유와 특정 인력에 대한 의존성이 전체 개발 흐름의 병목으로 작용했다. ## 개발자 온보딩과 코드 이해 가속 - 신규 개발자의 온보딩 시간이 80% 단축됐다. - IDE와 저장소에 통합된 에이전트형 채팅이 코드 구조, 프로젝트 규칙, 작업 맥락을 설명했다. - 신규 인력이 선임 개발자를 매번 호출하지 않고도 낯선 코드베이스를 스스로 탐색할 수 있었다. - 이 효과로 3년간 약 58만 2,000달러의 비용 절감이 발생한 것으로 추정됐다. ## 마이그레이션 기간 단축 - 온프레미스 GitLab에서 GitLab SaaS로 이전하는 대규모 마이그레이션을 수행했다. - 당초 8개월로 계획했던 작업이 2개월 만에 완료됐다. - 파이프라인 실패 원인을 진단하고 실시간으로 해결하는 데 GitLab Duo Agent Platform을 활용했다. - 전체 일정이 75% 단축됐으며, 인건비 약 15만 7,000달러를 절감했다. ## 보안 및 QA 대응 효율 향상 - 보안 엔지니어와 QA 엔지니어는 업무 시간의 약 40%를 절약했다. - 플랫폼이 오류와 취약점의 원인을 상황에 맞게 설명하고 수정 방안을 제안했다. - 이로 인해 문제 해결 과정에서 선임 엔지니어에게 의존하는 정도가 줄었다. - 3년간 약 130만 달러의 인건비 절감 효과가 산정됐다. - 취약점 대응이 대기열 중심의 처리에서 즉각적인 진단과 수정 방식으로 바뀌었다. ## 개발자 생산성과 배포 속도 향상 - 각 개발자는 주당 업무 시간의 약 20%를 기능 개발에 더 사용할 수 있게 됐다. - 에이전트형 채팅과 AI 에이전트가 다음 작업을 지원하거나 자동화했다. - 코드 리뷰 - 테스트 작성 및 실행 - 오류 분석 - 트러블슈팅 - 전체 개발자에게서 발생한 생산성 향상 효과는 약 740만 달러로 추정됐다. - 일부 기업에서는 수주가 걸리던 기능 릴리스가 수일 내 완료되는 사례도 보고됐다. - 연구는 코드 생성 자체보다, 생성된 코드가 리뷰·테스트·보안 검증·배포로 이어지는 전체 흐름의 개선이 더 큰 경제적 효과를 만든다고 설명한다. ## 정량화되지 않은 추가 효과 - 여러 AI 개발 도구를 GitLab 기반 플랫폼으로 통합해 중복 비용을 줄일 가능성이 있다. - 개발자 만족도와 업무 경험이 개선될 수 있다. - 팀 간 지식 공유가 쉬워져 특정 전문가에 대한 의존성이 낮아질 수 있다. - 이러한 효과는 이번 재무 모델에는 포함되지 않았다. ## 연구 결과를 해석할 때의 주의점 - 이 연구는 GitLab이 의뢰하고 Forrester Consulting이 수행했다. - 결과는 인터뷰한 기업들의 경험과 이를 바탕으로 만든 복합 조직에 근거한다. - Forrester는 다른 조직이 동일한 ROI를 얻을 것이라고 보장하지 않는다. - 따라서 실제 도입 시에는 사용자 수, 기존 도구 비용, 교육·운영 인력, 보안 프로세스, 개발 병목을 기준으로 별도 측정해야 한다. 기업이 에이전트형 개발 플랫폼을 검토할 때는 코드 생성량만 평가하기보다 온보딩 시간, 리뷰·테스트 소요 시간, 취약점 수정 시간, 배포 주기, 마이그레이션 기간을 함께 측정하는 것이 바람직하다. AI의 투자 효과는 개별 개발자의 속도보다 소프트웨어 전체 생명주기에 얼마나 깊게 통합되는지에 따라 커진다.

원문 읽기(새 탭에서 열림)
gitlab5분 읽기큐레이션 요약

GitLab 19.2 릴리스 노트 | GitLab Docs

GitLab 19.2는 GitLab Duo와 AI 에이전트 기능을 중심으로 개발·보안·운영 자동화를 강화한 릴리스입니다. Duo CLI와 커스텀 플로우가 정식 출시되었고, 정책 기반 예약 파이프라인과 Agentic Chat 연동이 추가되었습니다. 또한 의존성 취약점 자동 수정, 비기본 브랜치 취약점 추적, 하위 그룹 단위의 Duo 접근 제어가 베타 또는 정식 기능으로 제공됩니다. ## GitLab Duo CLI 정식 출시 - 터미널에서 GitLab Duo Agent Platform을 사용할 수 있습니다. - 코드베이스에 대한 복잡한 질문을 하거나 변경 작업을 자율적으로 수행하도록 요청할 수 있습니다. - 외부 AI 도구와 달리 GitLab 프로젝트, 파이프라인, 에이전트 설정을 문맥으로 활용합니다. - 주요 기능: - 대화형 모드와 CI/CD용 헤드리스 모드 - 모델 선택 및 세션 공유 - 도구 실행 승인 - MCP(Model Context Protocol) 연결 - 슬래시 명령어와 컨텍스트 사용량·압축 관리 - `AGENTS.md`와 스킬을 활용한 사용자 정의 - `glab`을 통해 설치하거나 독립 실행형 도구로 설치할 수 있습니다. - GitLab Self-Managed와 Dedicated에서는 관리자가 기능을 켜거나 끌 수 있습니다. ## GitLab Duo 커스텀 플로우 정식 출시 - 여러 단계로 구성된 AI 기반 작업 흐름을 YAML로 정의하고 재사용할 수 있습니다. - GitLab 이벤트에 따라 반복적인 개발·운영 작업을 자동 실행합니다. - 주요 기능: - 팀별 YAML 워크플로 - 복잡한 작업을 위한 멀티 에이전트 오케스트레이션 - 승인이나 피드백을 받는 HITL(Human-in-the-loop) 체크포인트 - 멘션, 담당자 지정, 파이프라인, 머지 리퀘스트 이벤트 트리거 - 프로젝트 또는 AI Catalog에서 플로우 생성·관리 - 공개·비공개 가시성 설정 - 서비스 계정과 복합 ID를 이용한 보안 실행 - 실행 전 YAML 검증 - GitLab CI/CD 안에서 실행되므로 별도 외부 자동화 플랫폼 없이 운영할 수 있습니다. ## 예약 파이프라인 실행 정책 정식 출시 - 보안 정책 프로젝트에서 일정을 한 번 정의하면 범위 내 여러 프로젝트에 강제 적용할 수 있습니다. - 각 프로젝트의 `.gitlab-ci.yml`을 직접 수정하지 않아도 됩니다. - 커밋 활동과 무관하게 일·주·월 단위로 다음 작업을 실행할 수 있습니다. - 컴플라이언스 검사 - 보안 스캔 - 의존성 취약점 점검 - 각 정책은 별도 파이프라인으로 실행됩니다. - 시간대, 실행 시간 분산 범위, 대상 브랜치를 설정할 수 있습니다. - 코드 변경이 드문 저장소에서도 새롭게 발견된 취약점을 주기적으로 탐지하는 데 유용합니다. ## Agentic Chat에서 기본 플로우 시작 - 기존에는 특정 UI 동작, 멘션, 담당자 지정 등을 통해 시작하던 기본 플로우를 Agentic Chat 대화 중에도 실행할 수 있습니다. - 요청 내용에 맞춰 전문 플로우로 넘길 수 있습니다. - Developer Flow: 코드 변경 또는 머지 리퀘스트 생성 - Code Review Flow: 머지 리퀘스트 검토 - Fix CI/CD Pipeline Flow: 실패한 파이프라인 진단 및 수정 - 사용자가 채팅에서 전환을 승인한 뒤, 대화창이나 **AI > Sessions**에서 진행 상황을 확인합니다. ## 의존성 스캔 자동 수정 베타 - 취약한 의존성을 자동으로 수정하는 두 가지 기능이 추가되었습니다. - 자동 의존성 버전 업데이트: - 취약한 의존성을 안전한 버전으로 올리는 머지 리퀘스트를 자동 생성합니다. - 기본적으로 패치 및 마이너 버전 업데이트를 대상으로 합니다. - Agentic Breaking Change Resolution: - 의존성 업데이트 후 파이프라인이 주요 변경 사항으로 실패하면 GitLab Duo가 원인을 분석합니다. - 파이프라인 오류, 의존성 변경 로그, 프로젝트의 실제 사용 방식을 함께 검토합니다. - 같은 머지 리퀘스트에 수정 사항을 커밋하고 파이프라인을 통과할 때까지 재실행합니다. - 활성화하면 메이저 버전 업데이트도 대상에 포함됩니다. - GitLab Credits를 사용합니다. - 결과적으로 GitLab이 수정 머지 리퀘스트를 생성하고, Duo가 복잡한 호환성 문제까지 해결하는 자동화된 보안 수정 흐름을 제공합니다. ## 비기본 브랜치 취약점 추적 베타 - 기본 브랜치 외에도 장기 유지되는 릴리스·배포 브랜치의 취약점을 추적할 수 있습니다. - 예시는 다음과 같습니다. - `project-qa` - `project-prod` - `project-iOS` - `project-android` - 보안 설정에서 추적 브랜치를 추가할 수 있으며, 네임스페이스 프로젝트 수의 최대 두 배까지 등록할 수 있습니다. - 취약점 보고서와 프로젝트 보안 대시보드에서 브랜치별 필터링을 지원합니다. - CVE를 포함한 모든 취약점 유형을 추적합니다. - 브랜치가 기본 브랜치에 병합될 때 취약점 상태 메타데이터를 일관되게 유지합니다. - 추적 브랜치의 취약점 상태도 갱신할 수 있습니다. - 사용 브랜치는 너무 많이 지정하기보다 환경별·플랫폼별 장기 브랜치로 제한하는 것이 권장됩니다. ## 하위 그룹별 GitLab Duo 접근 제어 - GitLab Dedicated 및 Dedicated for Government 관리자는 특정 하위 그룹에서 Duo와 Duo Agent Platform을 제한할 수 있습니다. - 기존에는 전체 인스턴스에서 비활성화하거나 모든 그룹에서 사용 가능하게 하는 방식만 제공되었습니다. - 이제 하위 그룹별 기본 거부(default-deny) 및 허용 목록(allowlist) 정책을 적용할 수 있습니다. - 특정 그룹을 **Always off**로 잠그면 하위 그룹과 프로젝트에서도 기능을 활성화할 수 없습니다. - 다른 그룹은 Owner 권한 사용자의 선택에 맡길 수 있습니다. - 잠금 설정과 해제는 관리자만 수행할 수 있으며, 영향을 받는 Owner에게는 상위 그룹 정책으로 기능이 잠겼다는 안내가 표시됩니다. - 조직의 규정 준수와 AI 기능 사용 범위에 대한 플랫폼 거버넌스를 세밀하게 관리할 수 있습니다. ## 실용적인 적용 방향 - 개발팀은 Duo CLI와 Agentic Chat을 코드 작성, 코드 리뷰, 실패한 파이프라인 수정에 활용할 수 있습니다. - 보안팀은 예약 파이프라인 정책과 의존성 자동 수정으로 지속적인 취약점 대응 체계를 구성할 수 있습니다. - 릴리스 브랜치를 운영하는 조직은 비기본 브랜치 추적을 제한적으로 적용하는 것이 좋습니다. - 규제 환경에서는 하위 그룹별 Duo 허용 정책을 사용해 AI 기능을 조직 단위로 통제하는 것이 적합합니다.

원문 읽기(새 탭에서 열림)
gitlab3분 읽기큐레이션 요약

GitLab Duo Agent Platform을 터미널로 가져오세요

GitLab 19.2에서 GitLab Duo CLI가 정식 출시되어, 코드 작성뿐 아니라 파이프라인 실패·테스트·보안 취약점·CI/CD 작업까지 터미널에서 처리할 수 있게 됐다. GitLab 프로젝트와 파이프라인, 에이전트 설정 및 권한 정보를 이미 알고 있어 별도 도구보다 더 일관된 컨텍스트를 제공한다. 대화형 모드와 CI·스크립트용 헤드리스 모드를 모두 지원하며, 터미널·GitLab UI·에디터 간 세션도 공유된다. ## 터미널 중심 개발의 필요성 - 기존 에이전트형 AI는 파일 편집과 코드 생성에 집중되어 있었다. - 실제 소프트웨어 전달 과정에서는 다음과 같은 문제가 자주 발생한다. - 파이프라인 실패 - 테스트 오류 - 의존성 문제 - CI 설정 오류 - 보안 취약점 - 이러한 문제의 핵심 컨텍스트는 로컬 코드보다 GitLab 프로젝트와 파이프라인에 있기 때문에, 일반적인 코딩 전용 CLI 도구로는 충분히 대응하기 어렵다. - 외부 CLI 도구를 사용하면 조직 단위 관리자 제어, MCP 설정 진단, GitLab 전체 에이전트 생명주기와의 통합이 부족할 수 있다. ## GitLab Duo CLI의 주요 기능 - 터미널에서 코드 탐색, 리팩터링, CI/CD 정리, 파이프라인 장애 분석, 다단계 작업을 수행할 수 있다. - GitLab UI, Duo CLI, 에디터 확장 기능 사이에서 세션과 대화가 공유된다. - 브라우저에서 시작한 작업을 터미널에서 이어갈 수 있다. - 동일한 프로젝트 맥락과 대화 내용을 유지할 수 있다. - GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 사용할 수 있다. - Self-Managed와 Dedicated 환경에서는 관리자가 인스턴스 단위로 접근을 활성화하거나 비활성화할 수 있다. - `/doctor` 명령으로 설치·환경 설정을 점검하고, `/mcp` 명령으로 MCP 구성을 확인할 수 있다. ## 계획 모드와 빌드 모드 - **Plan 모드** - 코드베이스와 관련 상황을 조사한다. - 파일을 변경하지 않고 해결 방법을 먼저 계획한다. - **Build 모드** - 사용자가 승인한 뒤 실제 코드나 설정을 변경한다. - 대화형 세션에서는 도구 실행 전에 승인을 요청하므로, 변경 사항을 검토하면서 작업할 수 있다. ## 헤드리스 모드와 자동화 - 헤드리스 모드는 사용자의 입력이나 승인 없이 실행되는 비대화형 방식이다. - CI 러너, 셸 스크립트, 자동화 작업에 적합하다. - 다음 명령으로 목표를 전달해 실행할 수 있다. ```bash glab duo cli run --goal duo run --goal ``` - 예를 들어 현재 셸에서 다음과 같이 특정 머지 리퀘스트의 파이프라인 실패 원인 분석과 수정안을 요청할 수 있다. ```bash glab duo cli > The pipelines in MR 23 are failing. Please help me fix them. ``` - Duo CLI는 관련 상황을 분석하고 수정안을 제안한 뒤, 적용 전에 검토할 수 있도록 한다. ## 설치와 실행 방식 - GitLab CLI를 사용하는 가장 간단한 방법은 다음 명령이다. ```bash glab duo cli ``` - `glab`이 인증을 처리하므로 별도의 인증 절차를 줄일 수 있다. - Duo CLI를 독립 도구로 설치하고 개인 액세스 토큰으로 실행하는 방식도 제공된다. ```bash duo ``` - 두 방식 모두 대화형 모드와 헤드리스 모드 등 동일한 기능을 지원한다. ## 프로젝트 지침과 확장성 - Duo CLI는 프로젝트 또는 조직의 사용자 지정 지침을 따를 수 있다. - 지원되는 지침 파일의 예시는 다음과 같다. - `chat-rules.md` - `AGENTS.md` - `SKILL.md` - 대화형 세션에는 사용자 정의 슬래시 명령을 추가할 수 있어 팀의 반복적인 작업 흐름을 확장할 수 있다. ## 실용적인 활용 방법 GitLab CLI를 이미 사용 중인 팀은 `glab duo cli`부터 도입하는 것이 좋다. 먼저 Plan 모드로 파이프라인이나 CI 설정 문제를 분석한 뒤 Build 모드에서 변경을 승인하고, 반복 작업은 `run --goal`을 이용해 CI나 스크립트에 연결하면 된다. 관리자는 Self-Managed·Dedicated 환경에서 접근 권한과 MCP 구성을 점검한 후 단계적으로 배포할 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Sightlines 1호: Config에서 얻은 인사이트 | Figma 블로그

AI 시대에도 좋은 리더십의 기본과 디자인의 본질은 변하지 않는다. 리더들은 AI를 제품·팀·업무 시스템에 통합하면서도 품질을 유지하는 방법을 실험하고 있으며, 속도보다 중요한 것은 인간의 판단력과 협업이라고 강조한다. 자동화로 생산량이 늘어날수록 좋은 결과를 선별하는 ‘취향(taste)’과 세밀한 완성도가 핵심 경쟁력이 된다. ## AI 시대의 리더들이 고민하는 과제 - AI를 제품, 조직, 업무 프로세스에 어떻게 도입할지 아직 대부분의 리더가 탐색 중이다. - AI가 제공하는 빠른 제작 속도를 활용하면서도 품질 저하를 막아야 한다. - AI 이전의 전문성, 팀 구조, 협업 방식 중 무엇을 유지하고 무엇을 바꿀지 재검토하고 있다. - 변화의 방향을 리더 자신도 완전히 알지 못하는 상황에서 팀을 이끌어야 한다. ## 변하지 않는 리더십의 기본 - 좋은 리더의 핵심 역량은 AI 시대에도 크게 달라지지 않는다. - 호기심이 많고 비판적으로 사고하는 사람들로 팀을 구성해야 한다. - 빠르게 결과를 만드는 것보다 높은 완성도와 장인정신에 대한 기준을 유지해야 한다. - 리더는 모든 세부 사항을 직접 통제할 수 없으므로, 신뢰할 수 있는 인재를 채용하고 권한을 위임해야 한다. ## 초보자의 관점으로 실험하기 - 리더와 팀원 모두 기존 방식이나 전문성에만 의존하지 않고 원칙부터 다시 검토해야 한다. - AI 도구를 단순히 도입하는 데 그치지 말고, 실제 프로토타입을 만들며 가능성과 한계를 확인해야 한다. - 리더도 팀과 함께 직접 실험하며 변화 과정을 경험해야 한다. - 새로운 도구를 좇기보다 어떤 문제를 해결하려는지, 고객과 인간에게 어떤 가치를 주는지를 먼저 판단해야 한다. ## 개인 작업보다 중요해진 협업 - AI 도구는 사람을 혼자 작업하는 흐름으로 끌어갈 수 있지만, 리더들은 오히려 협업을 강화하고 있다. - 작업물을 공개하고, 팀 전체가 피드백과 비평을 주고받아야 한다. - 여러 사람이 결과물을 함께 검토하고 최선의 방향을 논쟁하는 과정이 품질을 높인다. - 협업은 단순한 업무 분담이 아니라 판단 기준을 공유하고 결과의 완성도를 높이는 방식이다. ## 자동화 시대의 핵심 경쟁력은 ‘취향’ - AI로 누구나 빠르게 많은 결과물을 만들 수 있게 되면서 결과물의 양 자체는 차별점이 되기 어렵다. - 무엇이 좋은지 판단하고, 불필요하거나 수준 낮은 결과를 과감히 제거하는 편집 능력이 중요해진다. - 한동안 낮은 품질의 디자인이 많아질 수 있지만, 뛰어난 작업은 결국 드러난다는 전망이 제시된다. - 창작자의 상상력, 판단력, 편집 능력은 자동화하기 어려운 인간 고유의 역량으로 남는다. ## 인간 중심 디자인과 세부 완성도 - 도구 자체를 따라가기보다 최종 사용자인 인간을 중심에 두어야 한다. - 디자인은 고객에게 기업이 얼마나 세심하게 신경 썼는지를 보여주는 수단이다. - 작은 세부 사항까지 정교하게 다듬으면 고객에게 논리적 만족을 넘어 감정적 반응을 이끌어낼 수 있다. - AI 시대에도 인간을 이해하고 배려하는 태도와 세심한 품질 관리가 중요하다. AI를 활용할 때는 속도와 생산성만 추구하기보다, 실험·협업·비판적 검토를 함께 운영하는 것이 바람직하다. 특히 팀은 AI가 만든 결과를 그대로 받아들이지 말고, 인간의 취향과 판단력으로 선별하고 다듬는 체계를 갖춰야 한다.

원문 읽기(새 탭에서 열림)
gitlab3분 읽기큐레이션 요약

GitLab Duo Security Review, 스캐너가 놓치는 논리 결함 발견

정적 보안 스캐너는 SQL 인젝션이나 하드코딩된 비밀처럼 알려진 패턴에는 강하지만, 애플리케이션의 권한 모델과 업무 흐름을 이해해야 발견할 수 있는 논리적 취약점에는 한계가 있습니다. GitLab Duo Security Review의 Security Review Flow는 MR의 변경 내용을 주변 코드와 함께 분석해 권한 누락, 정보 노출, 비즈니스 로직 오류, 경쟁 조건 등을 찾아냅니다. 퍼블릭 베타 단계이며, 기존 스캐너와 수동 보안 검토를 보완하는 용도로 설계되었습니다. ## 패턴 기반 스캐너가 놓치는 취약점 - 코드 한 줄만 보면 정상적으로 보이지만, 애플리케이션의 도메인 규칙을 위반하는 문제가 주요 대상입니다. - **접근 제어 및 권한 문제** - 객체 ID만 바꿔 다른 사용자의 데이터를 조회하는 BOLA(Broken Object Level Authorization) - 관리자 전용 기능이나 상태 변경 작업에 대한 권한 검사 누락 - **데이터 노출** - 객체를 직렬화해 반환하는 코드는 문법상 문제가 없어도, 민감한 필드가 포함되면 정보 노출이 발생할 수 있습니다. - 어떤 필드가 민감한지, 어떤 사용자가 받아도 되는지는 도메인 지식이 필요합니다. - **제어 흐름과 업무 로직** - 결제 없이 주문 완료 단계에 접근 - 가격을 결정하는 파라미터를 조작 - 특정 상태에 반복 진입 - 동시 요청으로 상태 검증을 우회하는 경쟁 조건(race condition) ## MR마다 보안 판단을 적용하는 Security Review Flow - GitLab Duo Agent Platform의 기능으로, 코드 변경 시점에 보안 검토를 수행합니다. - 다음 유형의 문제를 탐지하도록 설계되었습니다. - 객체 수준 및 함수 수준 권한 우회 - 상태 변경 작업의 권한 검사 누락 - 정보 노출 및 대량 할당(mass assignment) - 비즈니스 로직 오류 - 상태 기반 워크플로의 경쟁 조건 - 수동 보안 리뷰나 침투 테스트를 대체하지 않고 보완합니다. - 수정 비용이 낮은 MR 단계에서 문제를 발견하는 것이 목적이며, GitLab 애플리케이션 보안팀도 내부 MR에 사용해 왔습니다. ## 변경 내용과 주변 맥락을 함께 분석 - MR의 diff뿐 아니라 다음 정보를 함께 검토합니다. - 원본 파일 - 변경된 코드 - MR 토론 내용 - 관련 코드 - 보안 엔지니어처럼 코드의 의도와 실행 흐름을 추론합니다. - 별도의 검증 단계가 각 발견 사항을 다시 점검해 오탐 가능성을 줄입니다. - 발견 결과는 관련 코드 라인의 diff 스레드와 내부 노트에 표시됩니다. - 퍼블릭 프로젝트에서는 보안 세부 정보가 외부에 노출되지 않도록 내부 노트에만 결과가 기록됩니다. ## 발견 사항과 MR 처리 방식 각 결과에는 다음 정보가 포함됩니다. - 취약점 유형과 CWE(Common Weakness Enumeration) 참조 - 심각도: Critical, High, Medium, Low - 분류 등급 - Tier 1: 악용 가능성이 높은 취약점 - Tier 2: 논리적 결함 - Tier 3: 설계 문제 - 문제에 대한 평이한 설명 - 가능한 경우 제공되는 수정 제안 심각도에 따라 MR 상태도 달라집니다. - Critical 또는 High: `Request changes` - Medium 또는 Low: `Comment` - 취약점이 발견되지 않아도 자동 승인하지 않으며, 최종 승인은 항상 사람이 담당합니다. 발견된 문제는 수정 제안 적용, 오탐으로 기각, 위험 수용 중 하나로 처리할 수 있습니다. 수정 후에는 새 검토를 요청해 변경 사항이 해결되었는지 다시 확인합니다. ## 도입 대상과 비용 - Security Review Flow는 GitLab Ultimate 고객을 위한 퍼블릭 베타 기능입니다. - GitLab.com, Self-Managed, Dedicated 환경에서 사용할 수 있습니다. - GitLab Duo Agent Platform 무료 체험 또는 Ultimate 구독에 포함된 GitLab Credits로 이용할 수 있습니다. - 비용은 diff의 복잡도와 선택한 모델에 따라 달라지므로, 전체 적용 전에 일부 MR에서 시험하는 것이 권장됩니다. - 베타 이후 가격은 변경될 수 있습니다. 실무에서는 기존 SAST·시크릿 스캐너를 계속 사용하면서, 인증·인가와 상태 전이가 복잡한 MR에 Security Review Flow를 추가하는 방식이 적절합니다. 특히 결제, 계정 권한, 개인정보, 멀티테넌트 데이터처럼 업무 규칙 위반의 영향이 큰 변경부터 적용하는 것이 효과적입니다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

워크플로우 랩: Figma Make로 디자인을 직접 배포하기 | Figma 블로그

디자인과 개발의 핸드오프는 일방향일 필요가 없으며, 디자이너가 Figma Make에서 실제 코드베이스를 직접 수정하고 PR까지 이어지는 작업 흐름을 제안한다. 작은 접근성·사용성 개선을 티켓과 백로그에 맡기지 않고 디자이너가 직접 처리하면, 엔지니어는 대규모 아키텍처 작업에 집중하면서도 제품의 완성도를 높일 수 있다. Figma Design, Figma Make, Figma agent, GitHub 연동을 활용해 캔버스에서 검토하고 코드로 반영하는 것이 핵심이다. ## 작은 개선이 백로그에 묻히는 문제 - “간격을 조금 줄여 달라”거나 “스크린 리더가 잘못 읽는다”와 같은 수정은 중요하지만 규모가 작아 우선순위 경쟁에서 밀리기 쉽다. - 디자이너가 요구사항을 티켓으로 작성하면 엔지니어가 의도를 해석해야 하므로, 스크린샷과 설명을 주고받는 과정에서 디자인의 뉘앙스가 손실된다. - 그 결과 엔지니어는 실제 구현보다 디자이너의 결정을 번역하는 데 시간을 쓰게 된다. - 글에서는 이러한 문제를 해결하기 위해 디자이너가 저위험·고완성도 작업을 처음부터 끝까지 맡는 방식을 제안한다. ## MOSF 웹사이트의 접근성 개선 사례 - 가상의 박물관인 ‘Museum of Speculative Futures(MOSF)’가 사례로 등장한다. - 엔지니어는 대규모 정보 구조 재작성에 집중해야 하고, 디자이너는 웹사이트의 접근성 문제를 해결하려 한다. - PM은 엔지니어가 구조 개편 같은 고난도 작업을 계속 담당하고, 디자이너가 세부적인 접근성·사용성 개선을 직접 처리하도록 역할을 나눈다. - 목표는 기술적으로 동작하는 수준을 넘어, 다양한 사용자가 실제로 편리하게 사용할 수 있는 웹사이트를 만드는 것이다. ## 캔버스에서 사용자 피드백 수집 - 디자이너는 수정 전에 현재 경험을 점검하기 위해 Figma Design의 Figma agent를 사용한다. - 첫 방문자, 재방문 회원, 스크린 리더 사용자 등 여러 합성 페르소나를 생성하고 사이트를 탐색하게 한다. - 합성 페르소나는 실제 사용자 조사나 대면 테스트를 대체하지 않지만, 초기에 명백한 마찰을 발견해 후속 사용자 조사에 집중할 여지를 만든다. - 탐색 결과 다음과 같은 문제가 확인된다. - 전시 페이지의 내비게이션 라벨이 모호함 - 주요 행동 유도 버튼(CTA)이 눈에 잘 띄지 않음 - 날짜 선택기가 한눈에 이해하기 어려움 - 검색 결과가 없을 때 빈 화면만 표시됨 - 각각은 대규모 기능 변경은 아니지만, 여러 문제가 누적되면 사이트의 접근성과 사용성이 크게 떨어질 수 있다. ## 팀 검토를 거친 디자인 수정 - 디자이너는 에이전트가 발견한 문제를 바탕으로 디자인을 수정한다. - 이후 디자이너, 엔지니어, PM이 캔버스에서 변경 사항을 함께 검토한다. - 검토 대상에는 방문 페이지의 더 명확한 라벨, 눈에 잘 띄는 CTA, 사용하기 쉬운 날짜 선택기 등이 포함된다. - 디자인 단계에서 팀의 합의를 먼저 확보하므로, 코드 수정 이후에 요구사항을 다시 해석하거나 되돌리는 일을 줄일 수 있다. ## Figma Make로 실제 코드에서 작업 - 디자이너는 프로덕션 코드와 연결된 Figma Make를 사용해 캔버스의 수정 사항을 실제 코드에 반영한다. - 기존처럼 티켓을 생성해 백로그에 넣고 엔지니어가 나중에 구현하기를 기다리지 않는 것이 핵심이다. - Figma Make, GitHub 연동, 주석과 리뷰 기능을 통해 디자인 변경을 코드 변경으로 연결하고 팀 검토를 이어간다. - 최종적으로 작업은 풀 리퀘스트(PR) 단계까지 진행되며, 디자이너가 캔버스에서 시작한 개선을 병합 가능한 코드 변경으로 전달한다. - 이 방식은 엔지니어의 책임을 없애는 것이 아니라, 엔지니어가 코드 품질과 구조를 검토하는 동안 디자이너가 세부적인 사용자 경험 개선을 주도하도록 역할을 재배치한다. 작은 접근성·사용성 개선은 별도 티켓으로 쌓아두기보다, 디자이너가 실제 코드에서 직접 수정하고 엔지니어와 PR 리뷰를 진행하는 편이 효율적이다. 다만 합성 페르소나의 결과는 초기 탐색용으로 활용하고, 중요한 접근성 판단은 실제 사용자 조사와 기술 검증으로 보완하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)
gitlab3분 읽기큐레이션 요약

버전 업으로 빌드가 깨졌을 때 GitLab이 해결해 줍니다

GitLab의 Dependency Scanning Auto-Remediation은 취약한 의존성을 자동으로 업그레이드하고, 버전 변경으로 빌드가 깨지면 AI가 코드까지 수정하는 기능이다. 수정 사항은 동일한 머지 리퀘스트에서 검토되며, 기존 승인 절차와 감사 기록을 그대로 따른다. 이를 통해 개발자가 보안 취약점 수정에 직접 많은 시간을 쓰지 않고도 컴플라이언스 기한 내에 대응할 수 있다는 것이 글의 결론이다. ## 의존성 보안 백로그가 증가하는 이유 - 취약하거나 오래된 외부 컴포넌트는 OWASP Top 10에 포함되는 대표적인 위험 요소다. - Maven 생태계 조사에 따르면 최신 릴리스에 유입되는 취약점의 약 63%가 직접 의존성이 아닌 전이적 의존성에서 발생했다. - 취약점 수정은 기능 개발과 경쟁하는 수작업이어서, 특히 PCI-DSS와 FedRAMP의 30일 기한을 넘기는 고위험 취약점이 생기기 쉽다. - 의존성 업데이트 8건 중 약 1건은 호환성이 깨지는 변경을 포함하며, “하위 호환”으로 표시된 업데이트도 실제 프로젝트의 빌드를 깨뜨릴 수 있다. - AI를 활용한 익스플로잇 개발과 무기화가 빨라지면서 취약점을 장기간 방치할 위험도 커지고 있다. ## 취약점 발견부터 수정까지 자동화 - SBOM 기반 의존성 스캐닝이 수정 가능한 취약점을 발견하면, GitLab이 가장 가까운 안전 버전으로 올리는 머지 리퀘스트를 자동 생성한다. - 적절한 수정 버전이 없으면 무리하게 변경하지 않고 취약점을 보고서에 유지한다. - 자동 생성된 머지 리퀘스트는 전용 서비스 계정으로 작성되어 변경 주체를 추적할 수 있다. - 취약점의 심각도, 허용할 업데이트 범위(패치·마이너·메이저)를 설정할 수 있다. - 특정 취약점에 대해서는 취약점 보고서에서 사용자가 직접 자동 수정을 실행할 수도 있다. ## AI 기반 breaking change 해결 - 버전 업그레이드 후 파이프라인이 실패하면 GitLab Duo Agent Platform이 자동으로 원인을 분석한다. - 분석 대상에는 다음이 포함된다. - 파이프라인 오류 메시지 - 의존성의 변경 로그 - 프로젝트 코드에서 해당 의존성을 사용하는 방식 - AI는 같은 머지 리퀘스트 안에서 필요한 애플리케이션 코드 수정 커밋을 추가한다. - 수정 후에도 파이프라인이 통과하지 않으면 자동으로 중단하고, 분석 결과를 머지 리퀘스트에 남겨 개발자가 이어서 처리할 수 있게 한다. - 지원 생태계는 Bundler, Maven, Gradle, 주요 Python 및 JavaScript/TypeScript 패키지 관리자이며, Rust와 Go 지원도 예정되어 있다. ## 검토와 감사 절차를 유지하는 자동화 - 자동 수정은 절대로 자체적으로 병합되지 않는다. - 모든 변경은 기존 리뷰어 승인과 브랜치 보호 규칙을 거친다. - 머지 리퀘스트에는 다음 정보가 명시된다. - 어떤 취약점을 해결하는지 - 어떤 버전으로 업데이트하는지 - 빌드를 통과시키기 위해 AI가 제안한 코드 변경 - 변경 내용, 승인자, 승인 과정이 감사 기록으로 남아 보안 및 규제 대응에 활용할 수 있다. - 자동화는 조직 자체의 파이프라인에서 실행되므로 기존 접근 제어와 승인 게이트를 상속한다. ## 자동화 폭주를 막는 안전장치 - 쿨다운 기간을 설정해 모든 파이프라인마다 새로운 수정 작업이 생성되는 것을 방지한다. - 닫힌 머지 리퀘스트는 더 최신 수정 버전이 등장하지 않는 한 다시 만들지 않는다. - 프로젝트 또는 그룹 단위 구성 프로필로 조직의 위험 허용 수준에 맞게 정책을 관리할 수 있다. - 기능은 현재 퍼블릭 베타이며 GitLab.com에서 제공되고, GitLab Self-Managed와 Dedicated에도 순차적으로 적용된다. - 자동 버전 업데이트는 GitLab Ultimate에 추가 비용 없이 포함된다. AI 기반 breaking change 해결은 GitLab Duo Agent Platform의 무료 체험 또는 Ultimate에 포함된 GitLab Credits로 이용할 수 있다. ## 실용적인 적용 권장 사항 - 먼저 패치·마이너 업데이트만 허용해 자동화 범위를 제한하고, 안정화 후 메이저 업데이트로 확대하는 것이 안전하다. - AI가 작성한 코드도 반드시 일반 코드 리뷰와 테스트를 거쳐야 한다. - PCI-DSS나 FedRAMP처럼 기한이 명확한 환경에서는 고위험 취약점과 전이적 의존성을 우선 대상으로 삼는 것이 효과적이다.

원문 읽기(새 탭에서 열림)
gitlab3분 읽기큐레이션 요약

다단계 소프트웨어 딜리버리를 신뢰할 수 있는 에이전틱 플로우로 전환하세요

GitLab 19.2에서 Custom Flows가 정식 출시되며, 반복적인 소프트웨어 개발 절차를 AI 기반 워크플로로 정의하고 자동 실행할 수 있게 되었습니다. 팀은 이슈 구현, 파이프라인 오류 수정, 머지 리퀘스트 검토 같은 다단계 작업을 GitLab 이벤트나 Agentic Chat에서 시작하고, 사람은 승인과 중요한 판단에 집중할 수 있습니다. 이를 통해 개인의 기억과 수작업에 의존하던 런북을 일관된 자동화로 전환합니다. ## 다단계 개발 작업이 수작업으로 남는 이유 - 실제 소프트웨어 개발은 단일 명령으로 끝나지 않습니다. - 작업 맥락 수집 - 코드 수정 - 머지 리퀘스트 생성 - CI 결과 대기 - 리뷰 의견 반영 - 기존의 AI 채팅은 답변만 제공하므로 각 단계의 실행과 인계는 사용자가 직접 처리해야 합니다. - 사내 스크립트는 접근 권한, 트리거, 리뷰 정책이 변경되어도 자동으로 따라가지 못합니다. - 그 결과 팀이 반복적으로 수행하는 절차가 자동화되지 못하고 개인의 경험이나 팀 내 구두 지식에 머물렀습니다. ## Custom Flows를 통한 워크플로 자동화 - Custom Flows는 한 번 정의한 다단계 작업을 GitLab 플랫폼에서 실행합니다. - 다음과 같은 GitLab 이벤트를 트리거로 사용할 수 있습니다. - 멘션 - 작업 할당 - 파이프라인 상태 변화 - 머지 리퀘스트 생명주기 - 워크 아이템 변경 - 워크 아이템 상태 변경 - 예를 들어 다음과 같은 자가 복구 파이프라인을 자동화할 수 있습니다. - 실패한 테스트 분석 - 수정 코드 생성 - 변경 사항 커밋 - 팀에 결과 알림 - 복합 ID(composite identity)로 실행되므로 권한 범위를 제한하고 각 작업의 실행 주체를 추적할 수 있습니다. - 민감한 단계에는 사람의 승인을 요구하는 human-in-the-loop 체크포인트를 추가할 수 있습니다. ## Agentic Chat에서 전문 플로우 실행 - 사용자가 Agentic Chat에 작업을 설명하면 요청 내용에 맞는 Foundational Flow를 추천합니다. - 사용자는 실행을 승인한 뒤 대화 화면에서 진행 상황을 확인할 수 있습니다. - 대표적인 전문 플로우는 다음과 같습니다. - **Developer Flow**: 이슈나 변경 요청 구현 - **Code Review Flow**: 머지 리퀘스트 검토 - **Fix CI/CD Pipeline Flow**: 실패한 파이프라인 진단 및 수정 - 기존 채팅형 AI와 달리, 사용자가 각 중간 단계를 직접 클릭하거나 복사할 필요 없이 전체 작업이 GitLab 안에서 이어집니다. ## 코드 리뷰 자동화 제어 - 자동 코드 리뷰를 모든 머지 리퀘스트에 적용하지 않도록 제외 규칙을 설정할 수 있습니다. - 봇이 작성한 머지 리퀘스트나 특정 브랜치 패턴을 검토 대상에서 제외해 불필요한 크레딧 소비를 막습니다. - 사용자 정의 리뷰 지침을 통해 팀의 기준에 맞는 검토가 가능합니다. - 따라서 어떤 머지 리퀘스트를 리뷰할지뿐 아니라 무엇을 중점적으로 검사할지도 지정할 수 있습니다. ## 설정과 확장 기능 - Custom Flow는 프로젝트 또는 AI Catalog에서 생성할 수 있습니다. - 공개 범위를 정하고 필요한 프로젝트에서 활성화한 뒤, 적절한 GitLab 이벤트를 연결합니다. - GitLab 19.2에서는 공개 플로우를 최대 100개 프로젝트에 일괄 활성화할 수 있습니다. - 향후에는 Flow Creation Agent가 제공될 예정입니다. - 사용자가 자연어로 원하는 작업 절차를 설명하면 - 전체 스키마를 직접 작성하지 않아도 실행 가능한 플로우 정의를 생성하는 방식입니다. ## 도입 시 고려할 점 - 이벤트 기반 플로우는 수행한 작업량에 따라 크레딧을 소비합니다. - 처음부터 대규모 그룹 전체에 적용하기보다는 몇 개 프로젝트에서 먼저 테스트하는 것이 권장됩니다. - 자동화 범위가 넓어질수록 권한 설정, 승인 단계, 제외 규칙을 함께 설계해야 합니다. - GitLab Duo Agent Platform 무료 체험이나 Premium·Ultimate 구독에 포함된 GitLab Credits로 사용할 수 있습니다. 작업 절차가 반복적이고 팀마다 동일하게 수행된다면 Custom Flows로 먼저 인코딩하는 것이 좋습니다. 특히 이슈 구현, CI 오류 복구, 코드 리뷰처럼 단계가 명확한 업무부터 도입하고, 크레딧 사용량과 승인 지점을 확인한 뒤 적용 범위를 넓히는 방식이 실용적입니다.

원문 읽기(새 탭에서 열림)
github4분 읽기큐레이션 요약

초보자를 위한 GitHub: GitHub 필수 기능 마스터를 위한 로드맵

GitHub는 코드 저장소를 넘어, 버전 관리와 협업을 배우고 오픈소스에 참여하기 위한 개발자의 기반이다. 이 글은 Git과 GitHub의 기본 개념부터 계정 보안, 저장소 생성, Markdown, 브랜치와 풀 리퀘스트를 활용한 협업 흐름까지 초보자가 익혀야 할 내용을 단계적으로 설명한다. 핵심은 변경 사항을 Git으로 관리하고, GitHub에서 브랜치와 풀 리퀘스트를 통해 안전하게 공유·검토·통합하는 것이다. ## 버전 관리와 Git의 기본 개념 - 버전 관리는 파일의 변경 내용을 시간순으로 기록해 무엇이 언제, 왜 바뀌었는지 확인하고 이전 상태로 되돌릴 수 있게 한다. - Git은 가장 널리 사용되는 버전 관리 시스템이다. - Git의 작업 영역은 다음 세 가지로 나뉜다. - **Working directory**: 실제 파일을 수정하는 공간 - **Staging area**: 다음 커밋에 포함할 변경 사항을 검토하고 준비하는 공간 - **Local repository**: 커밋된 변경 이력이 저장되는 공간 - 기본 흐름은 `git status`로 상태를 확인하고, `git add`로 변경 사항을 스테이징한 뒤, `git commit`으로 기록을 저장하는 방식이다. - “코드를 push한다”는 말은 로컬에 만든 커밋을 GitHub의 원격 저장소에 업로드한다는 뜻이다. ## GitHub 계정 보안과 프로필 관리 - GitHub 계정은 개발자 정체성과 포트폴리오 역할을 하므로 보안을 강화해야 한다. - **Settings → Password and authentication**에서 2단계 인증(2FA)을 활성화하면 비밀번호가 유출돼도 추가 인증 없이는 계정에 접근하기 어렵다. - 2FA 복구 코드는 기기를 잃어버렸을 때 계정에 다시 로그인할 수 있는 중요한 수단이므로 비밀번호 관리자에 안전하게 보관해야 한다. - 사용자 이름과 동일한 이름의 공개 저장소를 만들고 README를 추가하면, 해당 README가 GitHub 프로필에 표시된다. - 프로필 README에는 기술, 프로젝트, 관심 분야 등을 작성해 개발자 포트폴리오로 활용할 수 있다. ## 자주 사용하는 Git 명령어 - `git config --global user.name "..."`: 커밋에 기록할 사용자 이름 설정 - `git init`: 현재 폴더를 Git 저장소로 초기화 - `git clone <url>`: 원격 저장소를 로컬로 복제 - `git status`: 변경 사항과 스테이징 상태 확인 - `git add .`: 모든 변경 사항을 스테이징 - `git commit -m "message"`: 스테이징된 변경 사항을 커밋 - `git switch -c <branch>`: 새 브랜치를 만들고 해당 브랜치로 이동 - `git push`: 로컬 커밋을 GitHub에 업로드 - `git pull`: GitHub의 최신 변경 사항을 내려받고 병합 - `git merge <branch>`: 다른 브랜치의 변경 사항을 현재 브랜치에 통합 ## 첫 번째 GitHub 저장소 만들기 - 저장소(repository)는 프로젝트 파일과 변경 이력을 관리하고 여러 사람이 함께 작업하는 프로젝트의 중심 공간이다. - GitHub 대시보드에서 **New**를 선택한 뒤 저장소 이름과 공개·비공개 여부를 지정해 만들 수 있다. - README를 함께 생성하면 방문자가 프로젝트를 처음 이해하는 안내문 역할을 한다. - 필요에 따라 다음 항목도 추가할 수 있다. - **`.gitignore`**: 운영체제 파일, 의존성 폴더, 임시 빌드 결과물처럼 추적할 필요가 없는 파일을 Git에서 제외 - **라이선스**: 다른 사람이 코드를 어떤 조건으로 사용·수정·배포할 수 있는지 명시 - `.gitignore`를 사용하면 저장소에 실제 소스 코드와 중요한 파일만 남겨 프로젝트를 깔끔하게 유지할 수 있다. ## Markdown으로 문서 작성하기 - Markdown은 일반 텍스트에 간단한 기호를 추가해 제목, 목록, 링크, 코드 블록 등을 표현하는 가벼운 문서 형식이다. - GitHub의 README, 이슈, 풀 리퀘스트, 댓글 등 대부분의 텍스트 작성 영역에서 사용된다. - 일부 HTML 태그와 함께 사용해 문서를 읽기 쉽고 구조적으로 만들 수 있다. - 좋은 Markdown 문서는 프로젝트의 목적과 사용 방법을 빠르게 전달해 저장소의 접근성을 높인다. ## GitHub Flow를 이용한 협업 - GitHub Flow는 공유 프로젝트에 변경 사항을 안전하게 반영하기 위한 반복적인 작업 절차다. - 일반적인 순서는 다음과 같다. 1. 저장소를 로컬에 `clone` 2. 작업용 브랜치 생성 3. 코드나 문서 수정 4. 변경 사항 커밋 5. GitHub에 `push` 6. 풀 리퀘스트 생성 7. 검토와 승인 후 병합 - 기능별로 브랜치를 분리하면 기존 코드에 직접 영향을 주지 않고 독립적으로 작업할 수 있다. - 풀 리퀘스트를 통해 동료가 변경 내용을 검토하고, 테스트 결과나 새로운 동작을 확인한 뒤 병합할 수 있다. - 예를 들어 공유 AI 프롬프트를 수정할 때도 별도 브랜치에서 변경하고, 풀 리퀘스트로 결과를 검토한 후 병합하면 팀 전체가 개선된 프롬프트를 사용할 수 있다. 처음에는 모든 Git 명령어를 외우기보다 `status → add → commit → push` 흐름과 브랜치·풀 리퀘스트 과정을 반복해 익히는 것이 좋다. 또한 2FA를 설정하고, README와 `.gitignore`를 갖춘 저장소를 만들어 작은 프로젝트부터 GitHub Flow를 연습하면 협업과 오픈소스 참여로 자연스럽게 확장할 수 있다.

원문 읽기(새 탭에서 열림)
meta4분 읽기큐레이션 요약

메타 광고 딥 퍼널 최적화를 위한 계층적 관심사 표현 탐구

Hierarchical Interest Representation은 사용자와 광고주·제품·서비스를 하나의 그래프로 연결하고, 이들의 잠재적 관심사를 여러 수준의 임베딩으로 학습하는 Meta Ads의 상위 표현 계층이다. 희소한 광고 참여 신호에 텍스트·이미지·영상 기반의 세계 지식을 결합해, 사용자의 잠재 관심과 광고주의 상품을 연결하고 딥 퍼널 광고 성과를 높이는 것이 목표다. 수십억 건의 상호작용을 이용해 학습한 범용 임베딩과 관심 토큰은 검색, 개인화, 추천, 감독 신호, 랭킹 모델 전반에 활용될 수 있다. ## 딥 퍼널 광고 최적화를 위한 표현 계층 - 사용자가 스크롤, 클릭, 반응, 구매 등으로 표현한 선호를 바탕으로 명시적·암묵적 관심사를 추론한다. - 광고주가 제공하는 상품·서비스와 사용자의 잠재 관심을 연결해, 단순 노출이나 클릭을 넘어 전환 등 딥 퍼널 목표를 최적화한다. - Meta의 Generative Ads Model(GEM), Andromeda, Adaptive Ranking Model 등 광고 추천 생태계의 여러 단계에서 사용할 수 있는 상위 표현 계층을 지향한다. - 대규모 참여 데이터에서 안정적인 관심 앵커를 추출해, 사용자가 아직 직접 반응하지 않은 광고의 발견 가능성도 높인다. ## 광고 생태계를 그래프로 모델링 - 사용자, 광고주, 제품, 서비스, 캠페인 등을 그래프의 노드로 표현한다. - 노드 사이의 노출, 클릭, 참여, 구매 등의 활동과 이벤트는 엣지가 된다. - Meta의 광고 네트워크는 매월 수백만 광고주와 수백만 개 광고가 수십억 명의 사용자에게 제공되는 초대형 그래프다. - 사용자와 특정 광고 사이의 직접적인 딥 퍼널 신호는 희소하기 때문에, 그래프에서 멀리 떨어진 연결과 공통 패턴을 함께 학습해야 한다. ## 희소한 신호와 동적인 관심사 - 사용자는 ‘관심 있음/관심 없음’ 같은 직접 피드백뿐 아니라 광고 참여 행동으로도 관심을 표현한다. - 광고 노출 기회와 전환 피드백은 광고·상품의 전체 규모에 비해 제한적이다. - 개별 사용자와 광고의 연결만 보면 데이터가 부족하므로, 관련 사용자·상품·광고주 사이의 장거리 관계를 활용해야 한다. - 대규모 그래프에서 장거리 관계를 계산하려면 메모리 효율적인 어텐션 커널과 고성능 학습 알고리즘이 필요하다. ## 차원 축소와 관심 원시 단위 - 원시 광고 그래프를 학습된 잠재 관심 단위인 ‘슈퍼 노드’ 중심의 슈퍼 그래프로 변환한다. - 원래는 희소했던 사용자-광고 연결을 공통 관심 원시 단위로 묶어 더 조밀한 관계로 만든다. - 관심 원시 단위의 어휘는 개별 광고보다 안정적이고 정적이므로, 광고 비즈니스와 상품 구성이 바뀌어도 재사용하기 쉽다. - 이를 통해 개별 광고에 대한 충분한 이력이 없는 사용자나 상품에도 일반화할 수 있다. ## 멀티모달 지식 보강 - 광고주와 제품의 페이지 메타데이터, 카탈로그 속성, 텍스트, 이미지, 영상 정보를 활용한다. - 언어 모델과 비전 모델로 콘텐츠를 처리해, 사용자가 해당 상품과 어떻게 상호작용했는지뿐 아니라 상품 자체가 무엇인지도 표현한다. - 참여 데이터가 부족한 희귀하거나 새롭게 등장한 광고주·제품에 대해서도 의미적 유사성을 바탕으로 추론할 수 있다. - 실제 세계의 지식과 행동 기반 신호를 결합해 콜드스타트와 신호 부족 문제를 완화한다. ## 통합 관계 임베딩 - 사용자, 광고주, 제품, 서비스와 잠재 관심 원시 단위를 하나의 거리 기반 공간에 배치한다. - 임베딩 간 거리를 이용해 다음 관계를 추정할 수 있다. - 사용자와 관심 원시 단위의 근접성 - 광고·광고주가 어떤 관심사를 제공하는지 - 관심 원시 단위끼리의 유사성 - 유사한 사용자, 광고, 제품의 이웃 관계 - 서로 다른 유형의 엔터티 간 친화도 - 동일한 표현 공간을 사용하므로 사용자 관심과 광고 상품의 의미적 연결을 직접 계산할 수 있다. ## 여러 계층의 관심 표현 - 상위 계층은 여행·스포츠·패션처럼 안정적이고 넓은 관심사를 표현한다. - 하위 계층은 특정 브랜드, 세부 상품, 구매 의도처럼 희소하지만 정밀한 관심사를 표현한다. - 조밀하고 안정적인 관계는 더 거친 계층으로, 드물고 구체적인 관계는 더 세밀한 계층으로 표현한다. - 여러 계층을 연쇄적으로 학습하면 검색·개인화에는 넓은 관심 표현을, 최종 랭킹에는 구체적인 의도 표현을 선택적으로 사용할 수 있다. ## 트랜스포머 기반 그래프 학습 - LLM에서 영감을 받은 트랜스포머 구조를 대규모 광고 그래프에 적용한다. - 희소 어텐션을 사용해 모든 노드 간 연결을 계산하지 않고도 장거리 그래프 관계를 포착한다. - 편향을 고려한 어텐션과 자기지도 방식의 교차 뷰 지식 증류를 활용해 여러 관점의 그래프 정보를 통합한다. - 사용자 행동의 시간적 변화와 광고주·제품 콘텐츠의 의미 정보를 함께 학습한다. - 전체 시스템은 실제 Meta 광고 데이터의 수십억 건 상호작용으로 엔드투엔드 학습된다. ## 범용 임베딩과 Bag-of-Meaning 토큰 - 광고 생태계의 사용자·광고주·제품·서비스에 대한 범용 임베딩을 생성한다. - 여러 의미 단위로 구성된 ‘Bag-of-Meaning’ 관심 토큰은 사용자의 관심과 광고의 의미를 공통 어휘로 표현한다. - 이 결과는 다음 용도로 확장될 수 있다. - 광고 및 상품 검색·후보 생성 - 개인화 추천 - 랭킹 모델의 입력 특성 - 학습을 위한 감독 신호 - 특정 도메인에 최적화된 전문 랭킹 아키텍처 실용적으로는 직접적인 전환 데이터가 부족한 광고·상품을 다뤄야 하거나, 신규 엔터티와 장기적인 관심 관계를 포착해야 하는 시스템에 특히 유용하다. 다만 범용 임베딩을 실제 광고 순위에 적용할 때는 최신성, 사용자 프라이버시, 관심사 편향, 계층별 표현의 검증을 함께 관리해야 한다.

원문 읽기(새 탭에서 열림)
google3분 읽기큐레이션 요약

확산 모델의 창의성을 명확히 이해하기 위한 여정

확산 모델의 창의성은 학습 데이터의 단순 암기가 아니라, 신경망이 점수 함수(score function)를 완벽하지 않고 매끄럽게 학습하는 데서 비롯됩니다. 정규화와 신경망의 암묵적 정규화는 점수 함수의 급격한 변화를 완화하고, 생성 과정이 학습 샘플 사이를 보간하도록 만듭니다. 그 결과 모델은 데이터의 구조를 유지하면서도 학습 데이터에 없는 새롭고 그럴듯한 샘플을 생성할 수 있습니다. ## 확산 모델의 생성과 점수 함수 - 확산 모델은 실제 데이터를 노이즈로 오염시킨 뒤, 이를 단계적으로 되돌리는 **디노이징** 과정을 학습합니다. - 생성 과정에서 점수 함수는 현재 데이터가 어느 방향으로 이동해야 하는지 알려주는 일종의 힘의 장 역할을 합니다. - 점수 함수를 완벽하게 학습한다면 노이즈 입자들은 특정 학습 샘플로 수렴할 수 있습니다. - 이 경우 모델은 새로운 데이터를 만드는 생성기보다 학습 데이터를 찾아내는 검색 도구에 가까워집니다. - 즉, 점수 함수의 완벽한 재현은 오히려 암기를 유발할 수 있습니다. ## 1차원 사례에서 나타나는 보간 효과 - 학습 데이터가 `-1`과 `+1` 두 점뿐인 1차원 세계를 생각할 수 있습니다. - 완벽한 점수 함수는 `0` 부근에서 방향이 급격히 바뀝니다. - 왼쪽의 입자는 `-1`로 이동합니다. - 오른쪽의 입자는 `+1`로 이동합니다. - 결과적으로 모든 입자가 두 학습 데이터 중 하나에 도달합니다. - 신경망이 학습한 점수 함수는 이처럼 급격한 변화를 그대로 표현하기 어렵습니다. - 특히 weight decay 같은 정규화는 급격한 절벽 형태를 완만한 경사로 바꿉니다. - 중앙 영역의 힘이 약해지면서 입자들이 학습 데이터에 즉시 수렴하지 않고, 두 점 사이의 **보간 영역(interpolation zone)** 에 머무를 수 있습니다. - 이 보간 영역에서 생성된 샘플이 학습 데이터에는 없지만 두 데이터의 특성을 공유하는 새로운 결과가 됩니다. ## 정규화가 만드는 점수 함수의 평활화 - 연구진은 1차원 점수 함수를 두 층 ReLU 신경망으로 학습하고 AdamW와 다양한 weight decay 설정을 비교했습니다. - weight decay가 강할수록 점수 함수의 중앙 부분이 더 부드러워졌습니다. - 점수 함수가 부드러워지면 데이터 사이를 흐르는 입자의 속도가 느려지고, 특정 학습 샘플로의 붕괴가 완화됩니다. - 명시적인 weight decay를 사용하지 않아도 경사 기반 학습 알고리즘 자체의 **암묵적 정규화** 때문에 같은 평활화가 나타날 수 있습니다. - 따라서 확산 모델의 창의성은 우연한 학습 실패가 아니라, 신경망 학습 방식에서 자연스럽게 발생하는 수학적 결과로 해석할 수 있습니다. ## 데이터 매니폴드 복원 - 고해상도 이미지처럼 복잡한 데이터는 고차원 픽셀 공간에 존재하지만, 의미 있는 이미지가 차지하는 영역은 극히 일부입니다. - 이 의미 있는 데이터들의 집합을 **데이터 매니폴드**라고 하며, 확산 모델은 유한한 학습 데이터로부터 이 숨겨진 구조를 추정해야 합니다. - 생성은 단순히 학습 샘플을 복사하는 것이 아니라, 데이터 매니폴드 위에서 새로운 점을 찾는 문제로 볼 수 있습니다. - 다차원 공간에서 점수 평활화는 모든 방향에 동일하게 작용하지 않습니다. - 매니폴드에 접하는 방향에서는 학습 샘플로 지나치게 수렴하는 경향을 늦춥니다. - 매니폴드를 향하는 방향에서는 이동을 크게 방해하지 않습니다. - 이 특성 덕분에 입자는 무의미한 고차원 공간에서 매니폴드로 이동하면서도, 매니폴드 위에서는 특정 학습 데이터에 과도하게 붕괴하지 않습니다. - 결과적으로 생성물의 현실성과 새로움 사이에서 균형이 형성됩니다. ## 실용적 의미 확산 모델의 창의성을 이해하려면 단순히 데이터 암기 여부만 볼 것이 아니라, 학습된 점수 함수가 얼마나 매끄러운지와 정규화가 생성 궤적에 미치는 영향을 함께 분석해야 합니다. 적절한 평활화는 학습 데이터에 대한 충실도와 새로운 샘플 생성 능력을 동시에 확보하는 핵심 메커니즘으로 볼 수 있습니다.

원문 읽기(새 탭에서 열림)
slack5분 읽기큐레이션 요약

Shipyard: Slack의 차세대 EC2 플랫폼을 구축한 방법

Slack은 장기 실행 EC2 인스턴스를 지속적으로 수정하는 기존 운영 방식의 한계를 해결하기 위해 차세대 EC2 플랫폼인 Shipyard를 구축했다. Shipyard는 EC2를 계속 변경되는 서버가 아니라 빌드·배포 가능한 불변 아티팩트로 다루며, 점진적 배포와 메트릭 기반 자동 중단·롤백을 지원한다. 이를 통해 컨테이너로 전환하기 어려운 워크로드에도 현대적인 배포 안정성과 예측 가능성을 제공한다. ## 기존 EC2 운영 방식의 한계 - Chef 기반으로 장기간 실행되는 인스턴스를 계속 업데이트하는 방식은 다음 문제를 낳았다. - 서비스 단위 배포가 복잡함 - 인프라 드리프트가 시간이 지날수록 누적됨 - 여러 계층의 변경 사항을 조율해야 함 - 수동 변경과 자동 설정 적용이 충돌할 수 있음 - Slack은 기존 Chef 환경을 다중 스택, 버전 관리, 분리된 프로덕션 환경, 신호 기반 실행 등으로 개선했지만 근본적인 구조적 한계는 남아 있었다. - 컨테이너가 일부 문제를 해결했지만 인프라 컴포넌트, Kubernetes 워커 노드, egress 네트워크 스택 등은 쉽게 컨테이너화하기 어려웠다. ## Shipyard의 핵심 방향 - 인스턴스를 지속적으로 수정하는 대신 이미지와 배포 산출물을 중심으로 운영한다. - 서비스 단위 배포 기능을 제공해 애플리케이션 배포와 유사한 방식으로 EC2 인프라를 관리한다. - 빌드 파이프라인, 배포 오케스트레이션, 자동 안전 장치를 긴밀하게 연동한다. - 인프라 변경을 불변성, 점진적 롤아웃, 자동화된 안전 검증을 갖춘 배포 과정으로 전환한다. ## 멀티 아키텍처와 멀티 운영체제 - AMD64와 ARM 기반 AWS Graviton 인스턴스를 모두 지원한다. - Ubuntu, RHEL, Amazon Linux 등 여러 운영체제를 사용할 수 있다. - 비용, 성능, 호환성에 따라 서비스별 실행 환경을 선택할 수 있다. - 컨테이너 전환이 어려운 다양한 EC2 워크로드를 동일한 플랫폼에서 운영할 수 있다. ## 메트릭 기반 점진적 배포 - Shipyard는 Slack의 배포 오케스트레이션 시스템인 Gondola와 통합된다. - 배포 과정에서 서비스 상태 지표를 기반으로 자동 안전 검사를 수행한다. - 오류율, 성능 저하 등 서비스 헬스 신호가 나빠지면 배포를 자동으로 중단할 수 있다. - 문제가 발생하면 이전의 정상 버전으로 자동 롤백할 수 있다. - 따라서 배포 실패의 영향 범위를 줄이고, 운영자의 수동 판단 의존도를 낮춘다. ## 계층형 이미지와 빠른 프로비저닝 - 컨테이너 이미지와 유사한 계층형 이미지 구조를 사용한다. - 공통 인프라 요소를 포함한 골든 베이스 이미지를 먼저 만들고, 그 위에 서비스별 이미지를 쌓는다. - 인스턴스 시작 시 수행해야 할 작업을 줄여 리전 간에도 빠르고 예측 가능한 프로비저닝이 가능하다. - 실행 시점에 많은 설정을 적용하던 기존 방식보다 부팅 과정의 변동성이 작다. ## 설정 관리 방식의 변화 - 기존에는 실행 중인 인스턴스가 주기적으로 Chef 작업을 실행해 설정을 확인하고 원하는 상태로 되돌렸다. - Shipyard에서는 이미지 생성과 초기 프로비저닝 같은 명확한 수명 주기 단계에서 설정을 적용한다. - 설정 관리 도구는 시스템 전체를 계속 수정하기보다 서비스 배포에 집중한다. - 이 방식의 장점은 다음과 같다. - 백그라운드 작업 부하 감소 - 수동 변경의 의도치 않은 덮어쓰기 방지 - 시간이 지나면서 인스턴스 상태가 달라지는 현상 감소 - 시스템 동작과 장애 원인 분석의 단순화 ## Peekaboo 기반 실시간 인벤토리 - Shipyard는 EC2 플릿을 거의 실시간으로 확인하기 위한 인벤토리 시스템 Peekaboo를 제공한다. - 기존처럼 Chef Server를 단일 정보 원천으로 사용하지 않고 AWS 이벤트와 인스턴스 메타데이터를 직접 활용한다. - Shipyard로 배포되지 않은 인스턴스도 추적해 전체 EC2 플릿을 한곳에서 확인할 수 있다. - AWS EventBridge, OpenSearch, Lambda를 기반으로 구축되었다. - UI, API, CLI를 제공해 다음 작업을 지원한다. - 전체 인스턴스 상태 탐색 - 다른 시스템과의 통합 - 명령줄에서 빠른 상태 확인 - 중앙화된 가시성을 통해 어떤 인스턴스가 어디에 있고 어떤 상태인지 파악하기 쉬워진다. ## 짧은 수명의 불변 인스턴스 - 각 EC2 인스턴스에 제한된 수명을 부여하고 정기적으로 자동 교체한다. - 인스턴스를 직접 수정해 오래 유지하기보다 새 이미지를 배포해 교체하는 방식을 채택한다. - 보안 취약점이 노출된 채 남아 있는 시간을 줄일 수 있다. - 운영팀은 개별 서버를 고치는 대신 최신 이미지를 기반으로 인스턴스를 재생성하는 데 집중한다. - 결과적으로 EC2 플릿의 상태를 지속적으로 신선하게 유지할 수 있다. ## Golden Base Image인 slack-zero - Shipyard의 기반에는 Slack Compute Platform Team이 관리하는 공통 이미지 `slack-zero`가 있다. - 보안 및 모니터링 팀과 협력해 표준화된 기반 환경을 유지한다. - 포함 내용: - 운영체제 기본 설정과 보안 강화 - 네트워크 및 서비스 디스커버리 설정 - 모니터링·보안 에이전트 - 공통 도구와 기반 시스템 설정 - 서비스는 `slack-zero`를 기반으로 필요한 런타임과 애플리케이션 요소를 추가한다. - 기반 이미지는 불변이지만 영구적으로 유지하지는 않는다. - 보안 패치, 모니터링 업데이트, 네트워크 개선이 필요하면 새 이미지를 생성한다. - 서비스 이미지는 최신 `slack-zero`를 기반으로 다시 빌드해 변경 사항을 상속한다. ## AWS Image Builder 활용 - Slack은 기존 Packer 대신 AWS Image Builder를 사용해 `slack-zero`를 생성한다. - AWS Image Builder의 장점으로 다음이 언급된다. - 수명 주기 정책을 통한 오래된 AMI 자동 정리 - AMI 저장 비용 절감 - 새 이미지가 생성될 때 SSM Parameter에 최신 AMI 정보를 게시 - 이를 통해 서비스 이미지 빌드와 인스턴스 교체 과정에서 최신 기반 이미지를 일관되게 참조할 수 있다. Shipyard의 핵심은 EC2를 수동으로 계속 관리하는 서버가 아니라, 버전이 지정된 이미지로 빌드하고 안전하게 교체하는 배포 대상으로 바꾸는 데 있다. EC2를 계속 사용해야 하지만 컨테이너의 불변성, 계층형 이미지, 점진적 배포, 자동 롤백의 이점을 원하는 조직이라면 이와 같은 플랫폼 접근이 효과적이다.

원문 읽기(새 탭에서 열림)
cloudflare3분 읽기큐레이션 요약

잘못된 DNSSEC 롤오버로 .AL이 다운됐다. 이제 1.1.1.1이 검증 우회 시점을 알려준다

2026년 7월 3일, 알바니아의 .AL 운영자가 DNSSEC 키 롤오버를 잘못 수행해 루트 영역의 DS 레코드와 실제 DNSKEY가 불일치했고, 검증하는 DNS 리졸버에서 .AL 전체가 장애를 겪었다. Cloudflare는 임시로 Negative Trust Anchor(NTA)를 적용해 접속을 복구했지만 DNSSEC 검증을 우회해야 했다. 이번에는 응답에 Extended DNS Error(EDE) 코드 33을 함께 반환해, 클라이언트가 해당 응답이 NTA 때문에 검증되지 않았음을 알 수 있도록 했다. ### .AL DNSSEC 장애의 발생 과정 - DNSSEC는 루트 영역의 DS 레코드에서 TLD의 DNSKEY로 이어지는 신뢰 체인을 구성한다. - 14:15 UTC경 .AL 운영자가 새 DNSKEY를 게시하고 기존 키를 제거했다. - 루트 영역의 DS 레코드는 여전히 기존 키 `id=26319`를 가리키고 있었다. - 리졸버는 일치하는 DNSKEY를 찾지 못해 검증에 실패했다. - 17:00 UTC경 새 DNSKEY까지 제거되면서 .AL 영역에 DNSKEY가 전혀 남지 않았다. - 19:15 UTC경 루트 영역에서 .AL의 DS 레코드를 제거하자 검증 대상이 사라져 DNS 조회가 복구됐다. - 게시 시점에도 .AL은 서명되지 않은 상태였으며, 모든 .AL 도메인은 DNSSEC 보호를 사용할 수 없었다. ### 장애가 .AL 전체로 확산된 이유 - .AL TLD 자체의 DNSSEC 신뢰 체인이 끊어지면 그 하위의 모든 도메인도 검증할 수 없다. - 도메인이 어디에 호스팅되어 있거나 어떤 권위 DNS 서버를 사용하든, 검증 리졸버는 DNSSEC 실패를 감지하면 응답 대신 `SERVFAIL`을 반환한다. - 캐시된 레코드가 만료될수록 재검증 요청이 늘어나 `SERVFAIL` 비율이 상승했다. - Cloudflare 1.1.1.1은 17:15 UTC에 NTA를 배포한 뒤 정상 응답을 제공하면서 장애가 급격히 완화됐다. ### Negative Trust Anchor를 통한 복구 - RFC 7646의 NTA는 특정 영역을 서명되지 않은 영역처럼 취급해 DNSSEC 검증을 일시적으로 우회한다. - Cloudflare는 .AL 운영자와 직접 연락하려 했지만, 연락처 역시 .AL 도메인에 있어 장애 중 접근할 수 없었다. - 약 3시간 후 .AL에 NTA를 적용해 1.1.1.1 사용자에게 정상적인 DNS 응답을 제공했다. - NTA의 대가로 해당 기간 동안 .AL 응답은 DNSSEC로 암호학적 진위를 보장받지 못했다. - 장애가 공개적으로 확인됐고 모든 검증 리졸버에 영향을 주고 있었기 때문에, 도메인 접근성을 유지하는 편이 낫다고 판단했다. - 루트 영역에서 DS 레코드가 제거된 다음 날 NTA를 삭제했다. ### NTA의 보안상 문제 - NTA가 적용된 응답은 일반적인 성공 응답과 겉보기에는 동일하다. - 사용자는 응답만 보고 DNSSEC 검증이 수행됐는지, 위조 가능성이 남아 있는지 알 수 없었다. - RFC 7646은 운영자가 NTA 적용 현황을 공개하도록 권고하지만, 상태 페이지나 공지는 사용자가 직접 확인해야 한다. - 애플리케이션, 모니터링 도구, 일반 DNS 클라이언트가 응답 자체만으로 검증 우회를 감지할 방법이 부족했다. ### EDE를 이용한 투명성 확보 - RFC 8914의 Extended DNS Error는 정상 응답이나 오류 응답에 추가 설명을 포함할 수 있다. - Quad9의 Babak Farrokhi가 NTA 적용 사실을 DNS 응답에 표시하는 새 EDE 코드를 제안했고, Cloudflare가 공동 저자로 참여했다. - 1.1.1.1은 .AL 장애 중 다음 정보를 함께 반환했다. - `EDE: 9 (DNSKEY Missing)`: DS와 일치하는 DNSKEY를 찾지 못했다는 원래 검증 오류 - `EDE: 33 (Negative Trust Anchor)`: 해당 조회에 NTA가 적용되어 DNSSEC 검증이 우회됐다는 사실 - 따라서 클라이언트는 `NOERROR`와 실제 IP 주소를 받더라도, 그 응답이 검증된 결과가 아님을 구분할 수 있다. ### 실용적인 결론 DNSSEC 장애 시 NTA는 대규모 접속 장애를 완화하는 유용한 비상 수단이지만, 보안 검증을 포기하는 조치이므로 제한적으로 사용해야 한다. DNS 리졸버와 모니터링 도구는 EDE, 특히 NTA를 나타내는 코드 33을 확인해 검증 우회 상태를 사용자와 시스템에 명확히 알려야 하며, TLD 운영자는 키 롤오버 전에 DS·DNSKEY 전환 절차를 철저히 검증해야 한다.

원문 읽기(새 탭에서 열림)
netflix4분 읽기큐레이션 요약

대규모 서비스 토폴로지 구축: 아키텍처, 도전 과제, 그리고 얻은 교훈

넷플릭스는 장애 대응과 변경 영향 분석을 위해 실시간 서비스 의존성 지도를 구축했으며, 이를 위해 배치가 아닌 스트리밍 중심 아키텍처를 선택했다. 시스템은 eBPF 네트워크 흐름, IPC 메트릭, 분산 추적 데이터를 물리적으로 분리된 계층에 저장하고, 필요할 때 통합해 제공한다. 대규모 트래픽에서도 안정적으로 동작하기 위해 백프레셔와 분산 집계 파이프라인을 적용했으며, 약간의 지연을 허용하는 대신 데이터 손실과 시스템 장애를 방지했다. ## 실시간 서비스 토폴로지가 필요한 이유 - 기존의 시간별·일별 배치 방식은 데이터가 생성될 때 이미 오래된 상태가 된다. - 장애 대응 시 한 시간 전의 의존성 지도는 현재의 장애 원인과 영향 범위를 정확히 보여주기 어렵다. - 실시간 변경 검증과 장애 분석을 위해 지속적인 데이터 수집과 갱신이 필요하다. - 넷플릭스의 시스템은 일반적으로 수십 분 이내에 토폴로지 정보를 갱신하는 것을 목표로 한다. ## 스트리밍 중심 아키텍처 - 여러 리전의 Kafka 스트림에서 네트워크 흐름 데이터를 지속적으로 수집한다. - IPC 메트릭은 Server-Sent Events(SSE) 형태로 전달하고, 반응형 파이프라인에서 처리한다. - 배치 처리처럼 완전한 스냅샷을 기다리지 않고, 데이터가 도착하는 즉시 토폴로지를 갱신한다. - 대규모 트래픽을 처리하면서도 처리 지연이 누적되지 않도록 스트리밍 처리와 부하 제어를 함께 설계했다. ## 백프레셔를 통한 안정적인 부하 제어 - 단순한 무제한 큐는 트래픽이 급증할 때 메모리를 고갈시키고 인스턴스 장애를 일으킬 수 있다. - 버퍼가 가득 찼을 때 데이터를 버리는 방식은 연결 정보가 사라져 토폴로지가 불완전해진다. - 배치 방식은 데이터를 보존할 수 있지만, 장애가 끝난 뒤에야 결과를 확인하게 될 수 있다. - 백프레셔는 하위 단계의 처리 속도에 맞춰 상위 단계가 자동으로 속도를 줄이는 방식이다. - 그래프 데이터베이스가 느려지면 Stage 2가 Stage 1에 감속을 요청한다. - 감속 신호는 Kafka 소비자까지 전파된다. - Kafka에 데이터가 남아 있으므로 처리 능력이 회복된 뒤 이어서 처리할 수 있다. - GC 일시정지, 외부 저장소 지연, 트래픽 급증 상황에서도 시스템이 중단되거나 데이터를 대량으로 버리지 않고 점진적으로 느려진다. - 실시간성이 몇 초 또는 몇 분 늦어지는 대신, 시간 단위로 오래된 데이터나 누락된 토폴로지를 피할 수 있다. - 반응형 스트림은 전통적인 동기식 처리보다 이해하고 운영하기 어렵지만, 넷플릭스 규모에서는 안정성을 위한 필수 요소로 평가된다. ## 데이터 소스별 물리적 토폴로지 계층 넷플릭스는 서로 다른 특성을 가진 데이터를 하나의 저장소에 억지로 통합하지 않고, 세 개의 계층으로 분리했다. - **네트워크 계층** - eBPF 기반 네트워크 흐름 로그를 그래프 데이터베이스에 저장한다. - 서비스 간 연결을 폭넓게 포착하지만 애플리케이션 수준의 상세한 맥락은 부족하다. - **IPC 계층** - 애플리케이션 메트릭을 별도의 그래프 데이터베이스에 저장한다. - 엔드포인트 정보가 풍부하지만 계측된 서비스만 포함한다. - **트레이싱 계층** - 분산 추적 데이터를 Parquet 기반 컬럼형 저장소에 저장한다. - 실제 요청 경로를 보여주지만 샘플링으로 인해 전체 트래픽을 대표하지 않을 수 있다. - 각 계층을 물리적으로 분리하면 처리량, 쿼리 패턴, 데이터 발전 주기에 맞춰 독립적으로 최적화할 수 있다. - 쿼리 시에는 필요한 저장소에 병렬 질의한 뒤 결과를 병합해 통합된 서비스 뷰를 제공한다. ## 네트워크 중간 장비를 해결하는 분산 집계 파이프라인 네트워크 흐름 로그는 실제 서비스 의존성이 아니라 개별 네트워크 홉만 보여주는 문제가 있다. - 실제 경로가 `App A → 로드 밸런서 → App B`라면 흐름 로그에는 두 개의 별도 연결로 기록된다. - 이 데이터를 그대로 시각화하면 서비스 대신 로드 밸런서, NAT 게이트웨이, API 게이트웨이, 프록시 같은 인프라 컴포넌트가 중심에 나타난다. - 따라서 여러 홉을 분석해 논리적인 `App A → App B` 의존성으로 재구성해야 한다. - 이를 위해 네트워크 계층 수집은 세 단계의 분산 집계 파이프라인으로 구성된다. ### Stage 1: 초기 집계 - 네 개 리전의 Kafka에서 흐름 로그를 소비한다. - 잘못된 흐름 로그를 필터링한다. - 5분 단위 시간 창으로 데이터를 묶는다. - 각 시간 창마다 초기 집계 객체를 생성한다. - 일관성 해싱을 사용해 집계 대상을 분산한다. - 생성된 집계 결과를 SSE를 통해 Stage 2로 스트리밍한다. - 이 단계에서는 중간 장비가 포함된 네트워크 홉을 식별하지만, 최종적인 서비스 간 연결은 아직 확정하지 않는다. ## 대규모 분산 시스템에서 얻은 설계 교훈 - 실시간 처리는 단순히 빠르게 처리하는 문제가 아니라, 느려지는 상황에서도 시스템을 무너지지 않게 만드는 문제다. - 데이터 손실보다 일시적인 지연을 선택하는 것이 서비스 토폴로지와 장애 분석에는 더 적합할 수 있다. - 서로 다른 데이터의 특성이 뚜렷하다면 저장소와 처리 계층을 분리하고, 조회 시 통합하는 편이 확장성과 독립적인 최적화에 유리하다. - 로컬 환경에서 정상 동작하는 구현도 운영 환경에서는 Kafka 지연, 메모리 부족, 트래픽 편중, GC 비용 등으로 쉽게 한계에 도달할 수 있다. - 따라서 대규모 시스템은 초기 설계뿐 아니라 부하 상황에서의 관찰, 병목 측정, 단계별 최적화 방법론이 중요하다. 실용적으로는 스트리밍 파이프라인을 구축할 때 무제한 버퍼나 무조건적인 데이터 삭제보다 백프레셔를 우선 고려하는 것이 좋다. 또한 서로 다른 품질과 용도를 가진 데이터 소스를 하나의 모델로 통합하기보다, 각 소스에 맞는 저장 계층을 유지하고 조회 단계에서 결합하는 방식이 운영 유연성을 높인다.

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