agentic-engineering

올바른 방향으로 빠르게 나아가는 방법 | Figma 블로그 (새 탭에서 열림)

AI는 소프트웨어 제작 속도를 크게 높였지만, 빠른 실행이 곧 올바른 제품을 의미하지는 않는다. AI가 만든 결과물을 그대로 받아들이면 기술 부채가 늘고, 평균적인 디자인과 기능에 머물 수 있다. 따라서 좋은 팀은 먼저 무엇을 만들지 충분히 고민하고, 명확한 맥락과 시스템을 제공한 뒤, 자신만의 관점으로 결과물을 다듬어야 한다. ## AI는 실행을 가속하지만 판단을 대신하지 못한다 - AI는 짧은 프롬프트만으로도 완성도 높아 보이는 프로토타입과 코드를 만들어낸다. - 그러나 겉보기의 완성도는 내부 구조, 제약 조건, 시스템 동작 방식까지 올바르다는 뜻이 아니다. - 과거에는 결과물의 세련됨 뒤에 전문가의 의사결정과 트레이드오프가 있었지만, 이제는 AI가 그 빈틈을 임의로 채울 수 있다. - **인지적 항복(cognitive surrender)**은 AI의 출력을 검토 없이 자신의 판단처럼 받아들이는 현상이다. - 첫 번째 결과물이 그럴듯하다는 이유로 바로 출시하지 말고, 문제의 본질과 실제로 만들 가치가 있는 것을 먼저 정의해야 한다. 글에서는 이를 **고려의 의무(consideration imperative)**로 표현한다. ## 맥락과 의도를 먼저 제공해야 한다 - 에이전틱 엔지니어링에서는 개발자의 역할이 코드를 직접 작성하는 것에서 **의도를 명확히 표현하고 검증하는 것**으로 이동한다. - Google의 관련 백서는 다음 요소를 중요한 기반으로 제시한다. - **결정론적 계층**: 테스트, 타입 검사, 검증처럼 매번 동일하게 실행되며 AI의 오류를 잡는 장치 - **고신호 맥락**: 명세, 문서화된 컴포넌트, 설계 원칙 등 에이전트가 의도를 정확히 이해하도록 돕는 정보 - **명확한 인터페이스**: 시스템 각 부분이 어떻게 연결되는지 에이전트가 추측하지 않도록 정의한 계약 - 디자인에서 코드로 전환할 때도 에이전트가 실제 프로덕션 컴포넌트의 구조를 모르면 픽셀을 보고 임의로 재구성할 가능성이 높다. - Figma MCP의 Code Connect처럼 실제 컴포넌트의 코드, props, variants를 제공하면 에이전트가 기존 시스템에 맞는 결과를 만들 수 있다. - 강력한 디자인 시스템은 결정 사항을 재사용 가능한 어휘와 가드레일로 codify해 결과물의 일관성을 높이고 코드와 기술 부채를 줄인다. - 초기에는 명세와 시스템을 준비하는 데 더 많은 시간이 들지만, 장기적으로 유지보수 비용을 낮춘다. ## “괜찮은 결과”는 쉽게 평균이 된다 - AI 모델은 방대한 기존 데이터를 학습했기 때문에 이미 널리 사용된 패턴과 스타일, 즉 **분포 안의 평균적인 결과**를 생성하는 경향이 있다. - 예를 들면 다음과 같은 결과가 반복될 수 있다. - 로고: 단순한 기하학적 형태와 그라디언트 - 발표 자료: 흔한 산세리프 글꼴과 익숙한 레이아웃 - React 컴포넌트: 둥근 모서리의 전형적인 카드 UI - 이런 결과는 틀리지는 않지만 차별성이 부족하다. - AI가 만든 “충분히 좋은” 결과를 반복해서 받아들이면 사용자의 판단 기준이 좁아지고, “무엇이어야 하는가?”보다 “덜 나쁜 선택은 무엇인가?”를 고르게 된다. - AI의 품질이 향상될수록 개인이 과거보다 나은 결과를 만들 수 있지만, 동시에 다른 AI 생성물과 비슷해질 위험도 커진다. ## 제품의 관점은 사람이 결정해야 한다 - AI는 실행과 변형을 빠르게 수행할 수 있지만, 제품의 목적과 차별화된 방향까지 자동으로 결정하게 두어서는 안 된다. - 명확한 의도와 평가 기준이 없으면 모델이 기본값과 평균적인 패턴을 대신 선택한다. - 팀은 AI가 제시한 결과를 출발점으로 활용하되, 왜 이 기능과 디자인이 필요한지, 누구를 위한 것인지, 무엇이 달라야 하는지를 직접 판단해야 한다. - 결국 속도의 핵심은 첫 결과물을 빨리 내는 것이 아니라, 명확한 맥락과 검증 장치를 통해 **올바른 방향으로 빠르게 반복하는 것**이다. AI를 활용할 때는 프롬프트 작성보다 먼저 목표, 제약 조건, 성공 기준을 문서화하는 것이 좋다. 테스트·타입 검사·디자인 시스템·명확한 인터페이스를 갖추고, AI 결과물을 반드시 사람의 관점과 제품 기준으로 검토해야 평균적인 결과와 기술 부채를 피할 수 있다.

GitLab은 왜 ‘Open Weights and American AI Leadership’ 서한에 서명했나 (새 탭에서 열림)

GitLab은 고객 선택권, 데이터 프라이버시, AI 모델 중립성을 강화하기 위해 ‘Open Weights and American AI Leadership’ 서한에 서명했다. 오픈 웨이트 모델은 비용·배포 환경·데이터 주권에 대한 통제력을 높이고, AI 안전성과 혁신을 촉진한다고 본다. GitLab은 개방형 모델과 독점 모델을 함께 지원하는 멀티모델·클라우드 중립적 DevSecOps 환경을 지향한다. ## 오픈 웨이트 모델을 지지하는 이유 - 오픈 웨이트 모델은 개발팀이 모델을 직접 선택하고 운영할 수 있게 한다. - 특정 클라우드나 AI 제공업체에 종속되지 않아 고객의 선택권과 협상력을 높인다. - 모델을 직접 배포할 수 있어 비용, 보안, 데이터 저장 위치를 조직의 요구에 맞게 관리할 수 있다. - 필요한 경우 외부 네트워크와 분리된 에어갭 환경에서도 모델을 운영할 수 있다. - 다양한 모델 제공업체가 경쟁하면 혁신과 보안 수준이 향상될 수 있다. ## 파운데이션 모델과 오픈 웨이트 모델의 조합 - 파운데이션 모델은 범용적인 성능과 폭넓은 활용 사례에서 강점을 보인다. - 오픈 웨이트 모델은 다음과 같은 통제력을 제공한다. - 모델 실행 위치 선택 - 비용 최적화 - 데이터 레지던시 관리 - 소스 코드와 전략적 지식재산 보호 - GitLab은 두 유형의 모델 중 하나만 선택하기보다, 업무와 보안 요구에 따라 함께 사용할 수 있어야 한다고 설명한다. ## GitLab의 모델·클라우드 중립 전략 - GitLab은 소프트웨어 개발 생명주기를 조율하는 DevSecOps 플랫폼으로서 팀의 업무 흐름에 여러 AI 모델을 연결한다. - 특정 클라우드나 단일 AI 모델 제공업체에 조직이 묶이지 않도록 하는 것이 핵심이다. - 모델 선택권이 실질적으로 유지되려면 AI 모델 시장 자체가 개방적으로 운영되어야 한다. - 이는 기업이 보안·개인정보·경쟁상의 위협으로부터 코드와 전략적 IP를 보호하는 데 중요하다. ## 개방성과 AI 안전성에 대한 입장 - GitLab은 안전하고 보안이 강화된 AI 생태계 구축에 개방성이 중요한 역할을 한다고 본다. - 오픈 웨이트 모델의 개발·배포·사용을 보장하는 정책을 지지한다. - 다만 모든 모델에 무제한 자유를 부여하기보다 다음과 같은 접근을 제안한다. - 위험 수준에 따른 비례적 안전장치 - 실제 악용 사례를 겨냥한 도구와 규제 - 혁신과 고객 선택권을 과도하게 제한하지 않는 정책 - 개방형 모델과 독점 모델이 성능과 가치로 경쟁하는 환경이 바람직하다고 주장한다. ## 실용적인 시사점 기업은 단일 AI 모델이나 클라우드에 의존하기보다, 업무별로 적합한 모델을 선택하고 보안·비용·데이터 위치를 함께 통제할 수 있는 멀티모델 전략을 검토하는 것이 좋다. GitLab의 서명은 이러한 모델 중립성과 오픈 웨이트 생태계에 대한 지지를 정책적·제품 전략적으로 확인한 것이다.

GitLab: 에이전틱 엔지니어링 시대를 위해 설계되다 (새 탭에서 열림)

GitLab은 AI 코딩의 속도를 늦추기보다, 에이전트가 대규모로 활동해도 통제와 보안을 유지할 수 있는 통합 인프라가 필요하다고 주장합니다. 이를 위해 에이전트 규모의 소스 코드 관리, 전체 SDLC를 이해하는 컨텍스트 그래프, 보안·거버넌스, 작업 오케스트레이션, 유연한 구매 모델을 제공하겠다고 발표했습니다. 결론적으로 GitLab은 인간과 에이전트가 동일한 플랫폼에서 계획·개발·배포·감사를 수행하는 “에이전틱 엔지니어링” 플랫폼을 지향합니다. ## AI 코딩의 확산과 관리되지 않은 혼란 - 조사 대상 1,500명 이상의 개발자와 기술 리더 중: - 조직의 91%가 AI 코딩 도구를 2개 이상 사용 - 54%는 3개 이상 사용 - 일부 고객의 코드베이스는 1년 만에 최대 5배 성장 - 그러나 기존 소프트웨어 생명주기는 인간의 작업 속도를 전제로 설계되어 에이전트 규모의 병렬 작업을 감당하기 어렵습니다. - 주요 문제: - 에이전트가 코드만 알고 전체 SDLC 맥락은 이해하지 못함 - 대규모 모노레포나 여러 저장소에서 컨텍스트가 부족해 작업이 중단됨 - 코드·의존성·배포 변경 속도가 거버넌스보다 빨라짐 - 좌석 수와 크레딧을 미리 구매해야 하는 고정형 계약이 AI 사용량 변동에 맞지 않음 - 응답자의 73%는 코드 유지보수를 걱정했으며, 전체 SDLC에서 생산성 향상을 체감한 비율은 21%에 불과했습니다. ## GitLab의 에이전틱 인프라 구조 GitLab은 소스 코드 관리, CI/CD, 거버넌스, 배포를 하나의 플랫폼에서 제공하며, 현재 5,000만 명 이상의 사용자와 10만 개 조직이 사용한다고 설명합니다. - **모터 시스템**: 소스 코드 관리, 파이프라인, 배포 등 실제 실행 담당 - **신경 시스템**: 에이전트와 개발자가 올바른 판단을 내리도록 전체 맥락 제공 - **면역 시스템**: 모든 작업에 보안과 거버넌스 적용 - **오케스트레이션 시스템**: 전체 생명주기의 작업을 계획하고 조율 - 이 네 요소는 사람이 작업하든 에이전트가 작업하든 동일하게 작동하도록 설계됩니다. ## 차세대 SCM과 에이전트 규모의 동시성 기존 Git은 수백 명의 개발자가 병렬로 작업하는 환경에는 적합하지만, 각 개발자가 수백 개의 에이전트를 실행하는 상황에서는 한계가 발생합니다. - **클론 비용**: 에이전트가 파일 하나를 읽기 위해 저장소 전체를 복제하며, 재시도마다 비용이 반복됨 - **동시성 붕괴**: 수천 개의 세션이 인간 중심으로 설계된 백엔드에 몰려 병목과 불안정성이 발생 - **격리 부족**: 에이전트가 계정과 브랜치 공간을 공유해 작업이 섞이고, 폐기나 추적이 어려움 - GitLab은 Git 프로토콜과의 호환성 및 감사 가능성은 유지하면서, 에이전트 전용 백엔드와 인터페이스를 갖춘 차세대 SCM을 비공개 베타로 공개했습니다. - 초기 내부 테스트 결과: - 토큰 사용량 최대 2배 감소 - 실제 실행 시간 최대 50배 단축 - 네트워크 트래픽 최대 1,000배 감소 ## GitLab Orbit: 전체 SDLC를 연결하는 컨텍스트 그래프 에이전트는 코드를 작성하는 능력에 비해 코드 주변의 시스템과 생명주기를 파악하는 능력이 부족합니다. 이로 인해 잘못된 작업을 반복하거나, 겉보기에는 올바르지만 나중에 되돌려야 하는 결과를 만들 수 있습니다. - **GitLab Orbit**은 코드, 작업 항목, 파이프라인, 배포, 운영 신호를 하나의 실시간 그래프로 연결합니다. - 에이전트는 분산된 정보가 아니라 GitLab의 원천 데이터를 기반으로 추론할 수 있습니다. - 개발자는 Data Explorer를 통해 동일한 그래프를 조회하고 변경 사항이나 장애 원인을 추적할 수 있습니다. - 초기 내부 테스트에서 Orbit을 사용한 에이전트는: - 응답 속도 최대 11배 향상 - 비용 효율 최대 4.5배 향상 - 환각 최대 45배 감소 - Compare the Market의 A/B 테스트에서는 그래프 기반 에이전트가 코드 리뷰 댓글의 정확한 위치를: - 70%의 확률로 지정 - RAG 방식은 58% - 이 테스트는 실제 머지 리퀘스트 79건을 대상으로 진행됐으며, 그래프 기반 컨텍스트가 일반적인 검색 기반 방식보다 높은 정확도를 보였습니다. - Orbit은 현재 공개 베타 단계입니다. ## 에이전트 보안과 거버넌스 GitLab은 에이전트가 코드와 운영 환경에 직접 영향을 미치는 상황을 고려해, 에이전트 자체를 관리하는 기능도 발표했습니다. - 에이전트의 신원과 권한을 관리 - 정책을 적용해 허용 가능한 행동 범위 제한 - 모든 에이전트 작업을 감사 로그로 추적 - 위험한 작업에 승인 절차 적용 - 에이전트용 보안 및 거버넌스 기능은 비공개 베타로 제공될 예정입니다. ## GitLab Duo Agent Platform의 오케스트레이션 - GitLab Duo Agent Platform은 에이전트가 개발자의 작업 흐름을 중단하지 않고 다음 작업을 수행하도록 조율합니다. - 이슈 처리 - 코드 리뷰 - CI/CD 파이프라인 문제 수정 - 플랫폼은 소스 코드, 컨텍스트, 보안 정책을 연결해 단순 코드 생성이 아닌 전체 개발 생명주기 자동화를 목표로 합니다. - 해당 플랫폼은 2026년 1월부터 정식 제공되고 있습니다. ## GitLab Flex와 새로운 구매 방식 - AI 도입 속도와 사용량은 조직마다 크게 달라 기존의 고정된 좌석·크레딧 계약으로 예측하기 어렵습니다. - GitLab Flex는 실제 AI 도입 방식과 사용 패턴에 맞춰 구매할 수 있는 유연한 라이선스 모델입니다. - 현재 주문을 받고 있습니다. ## 실용적인 결론 AI 코딩 도구를 도입하는 것만으로는 에이전틱 엔지니어링의 생산성을 확보하기 어렵습니다. 대규모 동시성을 처리하는 SCM, 전체 SDLC 컨텍스트, 세밀한 권한·감사·승인 체계, 작업 오케스트레이션을 함께 구축해야 하며, GitLab은 이를 하나의 통합 플랫폼으로 제공하려는 전략을 제시하고 있습니다.