지난 1년간 에이전틱 엔지니어링(agentic engineering) 에 대한 논의는 제어 도구 모음(harnesses) 과 루프(loops), 함대(fleets) 및 소프트웨어 팩토리(software factories) 로 이동했습니다. 제 의견은 엔지니어가 외부 루프(outer loop) , 즉 이러한 시스템에 대한 책임(accountability) 을 소유해야 한다는 것입니다. 이는 Fable 및 GPT-5.6 같은 강력한 모델이 등장함에 따라 더욱 중요해지고 있습니다.

에이전트는 영향력을 가지며, 영향력은 의무를 창출합니다. 누군가는 정확히 무엇이 변경되었는지, 왜 안전한지, 그리고 만약 틀렸을 경우 어떤 일이 발생할지 설명할 수 있어야 합니다. 그렇지 않으면 그들의 행동은 정당화될 수 없습니다. 따라서 조직에서 그들을 요청할 가능성도 처음부터 낮아집니다.
그래서 저는 세 가지 용어에 대해 이야기하고자 합니다. 첫 번째, 품질(Quality) 은 시스템을 가동하기 전에 설치하는 모든 검사를 의미합니다. 이러한 검사는 증거를 생성하고, 그 증거로부터 우리는 판결(Verdict) 을 도출합니다.
두 번째, 판결(Verdict) 은 작업이 우리의 종속 시스템에 진입하기 전에 내리는 최종 결정을 의미합니다. 저는 이 콘텐츠의 라인 프로듀서(line-producer)입니다. 제 이름으로 출시되는 작업을 수행하는 팀을 운영합니다. 모델이 라인을 작성할 수는 있지만, 판결은 제 몫입니다. 제 팀의 작업은 제 결정 없이 종속 시스템에 진입할 수 없습니다. 판결은 생산 결정입니다: 출시할지, 차단할지, 리디렉션할지, 응답 범위를 좁힐지, 가드레일을 추가할지, 아니면 완전히 거부할지 결정하는 것입니다.
세 번째, 설명 가능성(Answerability) 은 누군가 질문할 경우 왜 그렇게 했는지 설명할 수 있다는 보장을 의미합니다.
다르게 말하자면, 우리의 에이전트(제가 정의하기로는 모델과 파일, 도구, 메모리, 스킬, 샌드박스, 권한, 관찰 가능성, 복구 기능의 제어 도구 모음이 결합된 것)는 우리의 루프(제가 정의하기로는 조사, 구현, 검증, 반복)를 실행합니다. 그리고 이것이 우리의 소프트웨어 팩토리를 창출합니다.

모델은 단지 엔진일 뿐입니다. 제어 도구 모음 - 도구, 메모리, 권한, 샌드박스, 테스트 - 은 실제 작업을 안전하게 수행할 수 있도록 그 주변에 구축하는 자동차입니다.

이 제어 도구 모음을 반복 가능한 주기로 감싸십시오: 조사, 구현, 검증, 반복. 루프는 한 번의 좋은 실행이 신뢰하고 다시 실행할 수 있는 프로세스로 전환되는 방식입니다. 이 제어 도구 모음을 반복 가능한 주기(조사, 구현, 검증, 반복)로 감싸되, 모델 자체의 판단이 아닌 독립적인 검사가 작업 완료 시점을 결정하도록 하십시오.

이제 여러 루프를 동시에 실행하십시오. 팩토리는 규모화된 루프입니다. 에이전트는 내부에서 작업을 전달하고, 인간은 경계에서 결정을 소유합니다.
그리고 이 팩토리의 핵심에는 시스템 내부와 외부 사이의 신중한 경계가 있습니다. 시스템 내부: 우리는 입력(제품 팀의 의도, 이전에 출시된 작업에 대한 지식, 최근 사고, 사용자의 특정 피드백 등)을 수집합니다. 에이전트 루프는 작업을 조사하고, 계획을 구현하며, 결과를 검증합니다. 그런 다음 증거가 그 경계를 넘습니다. 종속 시스템을 소유한 인간은 증거를 보고 진행 여부를 결정합니다.

그리고 그것이, 여러분, 우리가 이루려는 전환입니다. 이전에는 에이전트가 실행 루프의 내부 루프를 수행하고 있었습니다. 이제는 에이전트가 내부 실행 루프를 실행합니다. 엔지니어는 외부 루프를 소유합니다.

시스템 내부에는 에이전트가 수행하는 단 한 가지 유형의 작업이 있습니다: 역량(Capability). 작업을 조사하고, 계획을 구현하고, 결과를 테스트하고, 보고하는 역량입니다. 이것이 모델의 역량입니다. 그리고 앞서 말했듯이, 그 미래는 이미 도래했습니다.
시스템 외부에는 단 한 가지 유형의 작업이 있습니다: 대행(Agency). 결정하고, 검증하고, 승인하고, 소유할 수 있는 대행 권한입니다.
우리는 여전히 코드에 대해 이야기하고 있습니다. 단지 그것이 특정 장소에 존재하고, 자신이 하는 일을 아는 사람들에 의해 수행되어야 할 뿐입니다.
AI 코드의 잠재력은 더 이상 미미하지 않습니다. Sonar 2026 설문조사에서 우리는 팀에게 AI의 도움을 받은 커밋의 비율에 대해 물었습니다. 그 비율은 작았지만 무시할 수 없는 수준이었습니다. 그리고 여러 응답자들은 AI 지원 커밋의 비율이 상당히 증가할 것으로 예상한다고 말했습니다. Sonar의 2026 코드 현황 보고서에 따르면, 커밋된 코드의 42%가 AI가 생성했거나 AI의 상당한 도움을 받은 것으로 나타났으며, 이 비율은 정체되지 않고 계속 증가할 것으로 예상됩니다.

다시 말해, 창작(Creation)은 점점 저렴해지고 있습니다. 더 희소해진 자원은 리뷰, 검증, 이해, 그리고 유지보수입니다.
우리는 통제의 속도보다 생성의 속도를 더 빠르게 움직였습니다. 그 결과 신뢰-검증 격차(trust-verification gap)가 발생했습니다. 우리가 대화를 나눈 많은 사람들은 여전히 AI 코드에 대해 어느 정도 불신을 표현합니다. 그러나 그들 중 상당수가 그러한 불신을 일관되게 검증 프로세스에 구축하고 있는 것 같지는 않습니다.

그리고 그것은 위험한 위치입니다. 우리는 AI 코드의 신뢰성을 검증할 수 있는 더 저렴하고 명확한 방법이 필요할 것입니다.
GitLab 2026년 6월 보고서를 보면 거버넌스 질문이 변화했음을 알 수 있습니다. GitLab의 2026년 6월 AI 책임 연구에 따르면 리뷰와 검증이 AI 사용 시 현재의 병목 현상이며, 더 우려되는 점은 거버넌스가 일반적으로 코드 생성 이후, 즉 위험을 수용하고 소유권 통제권을 상실한 후에 이루어진다는 것입니다. 오늘날 문제는 단순한 통제만이 아닙니다. 시스템에 어떤 제약 조건을 설정할 것인지, 증거를 통해 작업을 어떻게 확인할 것인지, 팀에 어떻게 책임을 물을 것인지에 관한 것입니다. AI 라이프사이클의 어느 부분을 누가 소유할 것인지에 관한 것입니다.

따라서 이 시리즈의 마지막 구분은 프로세스와 품질 사이의 구분입니다. 품질은 역압력(back pressure)의 개념입니다. 우리는 이것을 문자 그대로 의미합니다. 우리는 에이전트가 행사할 수 있는 최대한의 자율성을 부여하고 싶지 않습니다. 우리는 에이전트를 중단시키고, 규제하고, 작업을 확인하고, 인간다움을 보장할 수 있을 만큼의 충분한 역압력을 가질 수 있는 정도의 자율성만을 부여하고자 합니다.
일반 엔지니어링은 수행 중인 작업이 올바른 일을 하고 있음을 나타내는 많은 신호를 제공합니다. 타입 검사, 테스트, 훅, 샌드박스 제한, 감사 로그, 모니터 등이 있습니다. 우리의 엔지니어링 시스템은 이러한 종류의 신호로 가득 차 있으며, 시스템의 정직성을 유지하기 위한 충분한 역압력을 제공하도록 설계되었습니다.
따라서 우리의 에이전트가 동일한 신호를 방출하는 한, 우리는 일반 엔지니어링이 적절한 역압력을 제공할 것이라고 신뢰할 수 있습니다.
시스템을 신뢰한다고 해서 루프에 인간이 필요 없다는 의미는 아닙니다. 단지 인간이 내부 루프에 있을 필요가 없다는 뜻입니다. 우리는 인간이 제약 조건 루프(어떤 입력, 아키텍처, 명령어 또는 불변 조건을 설정해야 하는가?), 샘플링 루프(얼마나 많은 출력을 샘플링하고 검토해야 하는가?), 감사 루프(어떤 증거를 보관해야 하며 감사 로그의 효율성을 어떻게 보장할 것인가?), 그리고 소유권 루프(생산 경계의 어느 부분을 소유해야 하는가?)에 있기를 원합니다.
하지만 인간이 내부 루프에 있을 필요는 없습니다.
에이전트는 당신이 검토할 수 있는 것보다 더 많은 것을 출시할 수 있습니다.

그리고 희소 자원은 로그나 테스트 같은 품질 신호에 의해 정보를 얻은 여러분 자신의 핵심적인 인간 판단입니다.
2026년 6월 AI 보고서에 따르면, 실험 환경에서 수준 규모의 시간 지평선을 가진 에이전트 위임은 사실상 이미 실현되었습니다. 올해 OpenAI의 에이전트와 업무의 미래에 대한 연구는 이러한 아이디어에 대한 훌륭한 자료였습니다. 따라서 우리 시스템이 우리가 검토할 수 있는 것보다 더 많은 것을 출시하기 시작함에 따라, 이 소유권 경계를 어떻게 설정할지 생각하기 시작해야 합니다.

그리고 바로 여기서 설명 가능성이 등장합니다.
장기 지평선 에이전트의 경우, 수준 규모의 시간 지평선에 걸쳐 내려진 결정은 그 자체로 결정입니다. 그리고 모든 결정이 기록되지는 않습니다. 모든 결정을 입력 토큰까지 추적할 수는 없습니다. 당신이 하는 모든 것이 현재 문제에 대해 얻은 출력이 올바른 선택이라고 믿는 것뿐이라면, 그 결정에 이르기까지의 의사 결정 체인을 재구성하는 데 필요한 수백, 나아가 수천 시간의 인간 노동은 불가능해집니다. 따라서 다시 말하지만, 설명 가능성은 우리 시스템 설계의 핵심에 있어야 합니다.
세 가지 숨겨진 비용
그리고 세 가지 숨겨진 비용이 있습니다:
인지적 항복(Cognitive surrender) ~ AI가 제공하는 것을 맹목적으로 수용하는 것. 작업을 에이전트에게 위임할 때, 그 작업 자체는 에이전트의 작업처럼 보일 수 있습니다. 그러나 그것은 실제로 여러분의 작업입니다. 여러분의 평판입니다. 여러분의 책임입니다. 그리고 출력물의 결함을 겪는 것은 여러분의 소프트웨어입니다. 그리고 그 출력물을 반영하기 위해 변경되어야 하는 것도 여러분의 소프트웨어입니다. 따라서 에이전트의 출력은 여러분의 답변이 됩니다. 그리고 그와 함께 모든 책임이 따릅니다. 이 내용을 정리한 Wharton 연구는 AI가 옳을 때는 안심이 됩니다. 하지만 AI가 틀렸을 때는 소식이 좋지 않습니다. AI가 틀렸을 때, 거의 4분의 3에 달하는 사람들이 그럼에도 불구하고 그것을 수용했으며, AI가 없었을 때보다 더 확신을 느꼈습니다.

인지적 부채(Cognitive debt) ~ 문제 해결 방법에 대한 이해와 기억의 침식. 작업을 에이전트에게 위임할 때, 당신은 모든 사고 작업을 에이전트에게 오프로딩하는 것입니다. 스스로 모든 것을 생각하는 데는 시간과 에너지가 들지만, 방대한 코드베이스에서 그것을 생각해내는 것은 학습 곡선을 오르려고 할 때는 사용할 수 없는 자원을 필요로 합니다. 따라서 당신이 얻는 출력은 종종 당신 스스로 달성할 수 없는 것입니다. 그리고 에이전트 계획의 시간 지평선이 길어질수록, 에이전트가 생성하는 코드와 당신의 이해 사이의 격차는 더 커집니다. 그 격차는 누적됩니다. 부채는 쌓입니다. 그리고 학습 곡선을 오르는 비용은 거의 기하급수적으로 증가합니다. AI에 의존하여 코드를 작성하는 엔지니어가 직접 작성하는 엔지니어만큼 코드를 이해하는지 조사한 Anthropic의 무작위 대조 시험이 있습니다. 결론은 암울했습니다: 이해력 퀴즈에서 AI를 통해 작업한 엔지니어는 그렇지 않은 엔지니어보다 17% 포인트 낮은 점수를 받았습니다(50% 대 67%).

그리고 오케스트레이션 비용(Orchestration tax) 이 있습니다. 지금은 많은 에이전트를 쉽게 가동할 수 있지만, 여러분의 인지 대역폭은 같은 방식으로 병렬화되지 않습니다. 에이전트를 최악의 행동에서 벗어나도록 유도하고, 에이전트가 생성한 작업을 분류하여 주의가 필요한 작업을 식별하고, 먼저 관심 있는 작업에 집중하도록 지시하며, 가장 중요한 제약 조건과 가장 위험한 가정을 실행 전에 검증하는 것...
이 모든 것은 작업이 필요하며 자동화될 수 없습니다.
인간의 판단을 대체할 수 있는 것은 없습니다.

브라운필드(Brownfield) 시스템은 특히 여기서 위험합니다. 감사해야 할 시스템 동작이 코드에 존재하지 않기 때문입니다. 그것은 흉터(scars) 속에 존재합니다.
해결책? 아키텍처 결정에서 주의(attention)를 최우선으로 하십시오. 워크트리(worktrees), 범위(scopes), 증거(evidence)를 사용하여 초기 계획과 그로부터 파생된 작업 간의 결합도를 낮추십시오. 실행 불가능한 단계를 해결하기 위한 노력에 시간 제한을 두십시오. 그리고 소프트웨어의 변경을 엄격한 옵트인(opt-in) 권한으로 만드십시오.
알파(Alpha), 감쇠(Decay), 취향(Taste): 이 세 가지는 다양한 분야에서 경력과 성과를 형성하는 핵심 패턴입니다.

알파는 당신이 가장 가치 있는 게임 수를 둘 때, 경쟁에서 최고 성취자가 차지하는 선도적 역할입니다. 감쇠는 모든 사람이 반복과 타인 관찰을 통해 배우는 확립된 패턴입니다(원한다면 고원(plateaus)이라고 부르십시오). 취향은 알파의 선도 또는 감쇠의 변화를 감지할 수 있는 가장 이른 시점입니다. 어떤 일이 일어나고 있다는 증거가 전혀 없을 때 무엇이 다가오는지에 대한 우리의 판단입니다. Paul Graham의 요점은 누구나 무엇이든 만들 수 있을 때, 무엇을 만들지 선택하는 것이 더 중요해진다는 것이며, Mitchell Hashimoto의 정의는 실용적인 것입니다: 아직 객관적인 지표가 존재하지 않는 곳에서 높은 수준의 질적 판단을 내리는 것입니다. 이제부터 취향이 모든 것을 주도합니다: 알파의 변화는 취향의 변화입니다. 그리고 감쇠는 우리가 다른 무언가를 맛보기(taste) 시작하기 때문에 사라집니다.

다음 단계? 취향을 실행 가능하게 만드십시오(Operationalize your taste). 어떻게? 그것이 무엇을 의미하는지, 즉 당신이 무엇을 원초적(limbic)에서 의식적(conscious)으로 전환하려고 하는지 반영하는 이름을 붙이십시오. 비평과 예시를 통해 연습하십시오. 그 근거를 명시적으로 만드십시오.

그리고 업계에서 가장 지속 가능한 경쟁 우위를 제공하는 수를 계속 두십시오. 그것은 무엇입니까? 작업을 단순히 수행하는 것에서 가르치고, 체계화하고, 언제 수행해야 할지 결정하고, 결과를 소유하는 것으로 최전선(edge)을 계속 이동시키는 것입니다.

모든 사람이 개발자(developer)일 수는 있지만, 모든 사람이 엔지니어(engineer)인 것은 아닙니다. 엔지니어링은 개발자가 더 엄격한 업무 규율을 받아들일 때 변형되는 것입니다: 철저하고 논리적으로 타당한 추론, 제약 조건과 트레이드오프에 대한 고려, 위험과 노출에 대한 인식, 그리고 실질적인 책임감입니다.

미래에는 사람들이 엔지니어링의 행정 업무를 떠나 엔지니어링이 더욱 까다로워짐에 따라 등장하는 새로운 역할을 수용하게 될 것입니다. 장인 정신의 본질에서 분리되었지만 각자가 무엇을 하는지 명확히 하는 역할들입니다. 프로토타입을 만드는 사람, 구축하는 사람, 정리하는 사람, 성장시키는 사람, 유지보수하는 사람이 있을 것입니다.

인간은 반대 방향으로도 시스템의 최전선을 유지합니다. 반대 방향에서 알파를 증가시킵니다: 무엇을 할 가치가 있는지 선택하고, 그것이 수행되어야 할 제약 조건을 정의하고, 증거가 진행하기에 충분한지 결정하며, 결과를 돌보는 것입니다. 단일 팀이든 수백 개의 팀이든, 이것은 오직 인간만이 유지할 수 있는 최전선입니다.
책임(Accountability)이 팩토리를 확장할 것입니다. 주의와 취향처럼, 책임은 모든 것이 작동하게 만드는 세 가지 이중성 중 하나입니다. 책임 없이는 규칙이 없습니다. 질문자와의 실랑이도 없습니다. 트레이드오프도 없습니다. 위험도 없습니다. 안전망도 없습니다. 아무도 결정의 결과를 소유하지 않는다면, 높은 대행(high agency)은 오직 혼란만을 가져올 수 있습니다.

최전선(edge)의 반감기는 한 번의 릴리스이지만, 서명(signature)의 반감기는 경력입니다. 서명은 작업물에 대한 여러분의 이름으로, 출시된 것을 뒷받침할 수 있다는 느낌을 갖게 합니다. 기술은 영향력을 제공하고, 책임은 영향력을 신뢰로 전환합니다.

오직 사람만이 선택할 수 있습니다. 오직 사람만이 결과를 물려받습니다. 에이전트는 정책 내에서 안전하게 선택하고, 경로를 지정하고, 병합하고, 에스컬레이션하도록 요청받을 수 있지만, 결과를 물려받을 수는 없습니다.

모든 코드베이스에는 아마도 변경이 수용될 때 이해된 체크리스트, 결정에 사용된 증거, 변경에 책임이 있는 사람, 변경이 차단된 후의 시스템 상태를 명시적으로 밝히는 일종의 책임 계약(accountability contract)이 함께 제공되어야 할 것입니다. 다음과 같은 항목들로 구성됩니다:
- 여러분의 주의와 취향
- 여러분의 증거, 판결 및 소유권
- 여러분의 알파, 감쇠 및 취향
높은 대행(High Agency)
일반적인 에이전틱 워크플로우에서 높은 대행은 언제 위임할지, 언제 검사할지, 언제 중단할지, 언제 프로세스의 결과를 소유할지를 아는 기술입니다. 대행 사다리(agency ladder)는 낮은 수준에서 높은 수준으로 올라갑니다: 잠재적 문제를 플래그 지정하고, 조사하고, 실행하고, 진단하고, 해결책을 제안하고, 수정 사항을 권장하며, 문제를 해결합니다. 대행 사다리의 높은 단계는 식별력(discernment)입니다: 발견했지만 수정할 가치가 없어 넘어가는 것입니다.

소프트웨어 팩토리를 지탱하는 열두 개의 기둥
확장을 희망하는 팩토리에게 브라운필드는 개척지(frontier)입니다. 이 모든 영리한 작은 혁신들은 아직 큰 변화처럼 느껴지지 않을 수 있지만, 프로덕션 환경은 방대합니다. 완전히 새로운 시스템을 구축할 때는 완전한 통제권을 가지므로 충분한 역압력 메커니즘을 계획하고 구현하기가 훨씬 쉽습니다. 그러나 레거시 시스템에 지능형 에이전트를 추가하는 것은 전혀 다른 문제입니다.
레거시 시스템에는 프로덕션 동작의 전체, 고객의 미래 기대치, 마이그레이션 이력, 릴리스 및 예산 주기 기간, 묵시적 가정, 엣지 케이스, 데이터 이상 현상, 런북 절차, 그리고 시스템을 돌보려는 의지 없이 축적된 모든 흉터가 포함됩니다.
브라운필드의 관리자가 되려면 지속 가능한 엔지니어링(durable engineering) 형태가 필요합니다. 암묵적 지식을 명시적 제약 조건으로 전환하고, 이를 팀 간 및 세대를 거쳐 일관되게 유지하고, 해당 지식을 테스트 절차 및 기능 사양으로 공식화하고, 해당 지식을 객관적 증거와 연결하는 작업이 수행되어야 합니다. 이 모든 과정은 실패를 더 많은 학습으로 전환하면서 이루어져야 합니다. 시스템이 항상 받아왔던 관리를 받지 못한다면 모든 것이 무너질 수 있기 때문입니다.
새로운 일(New Work)은 진짜 일(Real Work)입니다
확장함에 따라 작업은 더 흥미로워질 것입니다. 다른 모든 것이 구축되면 사람들은 새로운 것을 구축하고 싶어할 것이기 때문입니다. 그들은 자신의 장인 정신을 통해 발전시킨 알파와 취향을 활용하여 소프트웨어 팩토리에 접목할 수 있는 새로운 루프를 설계하고자 할 것입니다. 또는 소프트웨어 팩토리의 모든 지식을 하나의 우아하고, 선의를 가지며, 원칙적인 노력에 적용하는 그린필드 시스템을 구축하고자 할 것입니다. 그들은 새로운 시스템에 대한 검증 수준에 부합하는 새로운 형태의 증거를 설계하고 구현하고자 할 것입니다. 그들은 이제 너무 복잡해져서 전담 관심이 필요한 브라운필드 시스템을 돌보고자 할 것입니다. 그들은 새로운 역압력 메커니즘을 설계하고 관리하고자 할 것입니다. 그들은 새로운 에이전트를 설계하고자 할 것입니다. 그리고 그들은 대행(agency)을 구축하고자 할 것입니다.

그리고 그렇게 하는 과정에서, 그들은 이 모든 것이 진짜 일임을 깨닫게 될 것입니다. 그것은 좋은 일입니다.
자동화는 병목 현상을 만듭니다. 소유할 가치가 있는 생산의 병목 현상입니다. 자동화는 우리에게 산업 규모에 대한 통제권을 주기 때문입니다. 하지만 산업 규모에서 발생하는 새로운 병목 현상도 있습니다. 병목 현상은 "이것을 구축할 수 있는가?"에서 "이것이 존재해야 하는가, 우리가 이에 대해 답변할 수 있는가?"로 이동합니다.
제가 제안하는 것은 에이전틱 엔지니어링을 확장하기 위한 실용적인 운영 모델입니다. 내부 루프와 외부 루프가 있습니다. 내부 루프는 작업이 수행되는 곳입니다. 루프는 가능한 한 독립적으로 설계됩니다. 모든 품질 보증과 검증을 루프 내부에 배치하십시오. 루프 자체를 설계하고 검증했다면, 남은 유일한 일은 루프의 실행 속도와 운영 범위를 제어하는 역압력 메커니즘을 구축하여 자율성을 부여하는 것입니다. 그리고 인간을 그들의 정당한 위치, 즉 올바른 결정에 배치하십시오. 이해를 인계(release gate)나 게이트로 취급하지 말고, 인간이 통찰력을 제공할 준비가 된 결정의 지점으로 취급하십시오. 그리고 존재하며 프로덕션 및 새로운 팀과 엔지니어에게 다시 제공되는 모든 산출물에 대해 더 나은 산출물을 남기십시오.
팩토리를 구축하십시오; 불을 계속 켜 두십시오; 작업을 읽기 쉽고, 검증 가능하며, 소유되도록 만드십시오.
에이전트가 작성할 수 있습니다. 하지만 사용자에게 도달하기 전에, 누군가는 그것이 왜 존재해야 하는지, 프로덕션의 일부가 되기에 충분히 안전한지, 그리고 그것이 틀렸을 때 어떻게 할 것인지 설명할 수 있어야 합니다.
그것이 외부 루프에서의 에이전틱 엔지니어링입니다 - 그것이 지금의 작업입니다.
Pangram은 이 기사를 100% 인간이 작성한 것으로 평가했습니다: https://www.pangram.com/history/ae6caccc-b70f-4336-a019-5c3411516871





