AWS AI-DLC에 대한 내 생각 — 내가 믿는 에이전틱 개발의 방향

TL;DR

• AWS AI-DLC는 컨셉·프로세스·구현 전반에서 내가 믿는 에이전틱 개발과 크게 다르다.

시작하며

이 글은 AWS와 무관한 개인적인 의견이며, 공개 자료와 개인 경험을 바탕으로 썼다.

AI를 활용한 개발 방식인 AI-DLC(AI-Driven Development Lifecycle)를 처음 접한 것은 2년 전 AWS PACE(Prototyping and Cloud Engineering)라는 조직에 있을 때였다. 원저자에게 간략한 소개를 들었다.

당시에는 개발자로서 개발에 드는 시간과 노력을 줄이고 프로세스를 효율화하는 데 온통 관심이 쏠려 있었다. 그래서 AI-DLC에 대해서도 별생각 없이 들었다.

작년 초에는 AI-DLC를 전담하는 팀이 생겼고, 나도 그 팀으로 가야 하는 상황이 됐다.

그 사이 나도 AI 에이전트에게 개발 작업을 맡기는 에이전틱 엔지니어링에 대한 생각이 정리됐다. 사람이 반복해서 개입해야 하는 이유를 하나씩 없애고, 에이전트가 스스로 일을 끝낼 수 있게 하는 방향이 맞다고 생각하게 됐다.

하지만 내가 접한 AI-DLC는 개발 단계마다 사람이 결과를 검토하고 승인하는 절차를 중요하게 다뤘다. 이런 방향에 동의하기 어려웠고, AI-DLC를 피해 현재의 어카운트 팀으로 옮겼다.

그런데 어카운트 팀에서도 AI-DLC를 전달해야 하는 경우가 점점 많아졌다. 앞으로는 회사 차원에서도 AI-DLC를 전달하는 일이 더 많아질 것으로 보인다.

그래서 AI-DLC의 어떤 부분에 동의하기 어려운지 글로 정리해보려 한다. 내 생각을 돌아보고, 실제로 도입하는 고객들의 경험과 내 생각 사이에 왜 차이가 생기는지도 고민해보고 싶다.

내가 AI-DLC와 다르게 생각하는 지점은 컨셉 → 프로세스 → 구현 세 가지다.

어떤 미래를 목표로 하느냐에 따라 일을 나누고 반복하는 방식이 달라지고, 그 차이는 실제 도구와 실행 환경을 만드는 방식에도 이어진다.

flowchart TB
    subgraph A["AI-DLC를 바라본 내 해석"]
        direction LR
        A1["컨셉<br/>사람이 중심"] --> A2["프로세스<br/>단계마다 함께 검토 · 승인"]
        A2 --> A3["구현<br/>도구에 작업 절차를 정해둠"]
    end

    subgraph B["내가 믿는 방향"]
        direction LR
        B1["컨셉<br/>에이전트가 중심"] --> B2["프로세스<br/>작게 만들고 피드백 받기"]
        B2 --> B3["구현<br/>도구 · 권한 · 결과 확인 방법 제공"]
    end

1. 컨셉의 차이 — 사람을 중심에 남기는 접근

도구를 사용해 작업을 수행하는 AI 에이전트에게 개발을 맡기는 에이전틱 엔지니어링에 대해, 나는 이전 글에서 그 방향을 판단할 기준을 하나 정했다.

에이전틱 엔지니어링의 장기적인 방향은 human in the loop(HITL), 즉 실행 과정에 반복적으로 개입하는 사람을 제거하는 것이라고 생각한다.¹

지금 당장 모든 사람을 빼자는 뜻은 아니고, 데이터 접근이나 실행 권한, 결과 확인 방법이 없어 사람이 대신 처리하는 일을 하나씩 해결하자는 뜻이다. 다른 팀의 도움이 필요한 일도 같은 관점에서 살펴보면 에이전트가 스스로 끝낼 수 있는 범위를 넓혀갈 수 있다.

AI-DLC는 다른 출발점을 가진다.

공식 소개 글에서는 AI가 계획하고 실행하되 중요한 결정은 사람이 내린다. 팀 전체가 모여 AI가 정리한 요구사항과 설계를 바로 확인하는 방식을 Mob Elaboration과 Mob Construction이라고 부른다.²

최근 공개된 adaptive workflow는 단순한 버그 수정과 새 시스템 개발에 똑같은 절차를 적용하지 않도록, 작업에 따라 필요한 단계를 고르고 얼마나 자세히 다룰지 조절한다. 초기 버전보다 분명 나아진 방향이다.

그럼에도 사람의 승인은 여전히 예외가 아니라 방법론의 중심이다.

공식 글도 AI의 결과를 믿고 쓸 수 있는지, 누가 책임지는지, 결과가 정확한지를 확인하려면 사람이 필요하다고 설명한다. 그래서 모든 단계에서 팀이 함께 결과를 검토하고 승인하도록 한다.³

이 접근은 AI에 익숙하지 않은 팀이 처음 워크숍을 해보거나, 규제와 감사 때문에 누가 무엇을 책임지는지 분명히 해야 하는 조직에는 유용할 수 있다.

다만 나는 앞으로 실제 서비스를 개발하는 조직은 지금 사람이 필요한 이유를 하나씩 없애갈 것이라고 생각한다.

데이터가 흩어져 있어서 사람이 찾는다면 에이전트가 필요한 데이터를 찾을 수 있게 연결한다. 권한이 없어서 사람이 대신 실행한다면 필요한 권한만 가진 도구를 만든다.

결과를 믿을 수 없어 사람이 일일이 읽는다면, 결과가 만족해야 할 조건을 정해 테스트로 확인하고 로그와 지표로 실제 동작까지 살펴볼 수 있게 한다.

반대로 사람이 항상 확인할 것이라고 가정하면, 데이터 접근이나 권한 문제를 해결하지 않고 사람이 대신 처리하는 데 머물기 쉽다.

두 조직은 지금은 비슷해 보여도 2~3년 뒤에는 전혀 다른 모습이 될 것이라고 생각한다.

flowchart LR
    S["현재<br/>사람이 대신 처리하는 일"] --> A1["에이전트 중심 조직"]
    S --> H1["사람 중심 조직"]

    A1 --> A2["데이터 접근 · 권한 · 결과 확인 방법 마련"]
    A2 --> A3["사람이 대신할 일을 줄임"]
    A3 --> A4["자동화할 수 있는 업무가 늘어남"]

    H1 --> H2["AI가 문서 · 코드 작성"]
    H2 --> H3["사람이 단계마다 검토 · 승인"]
    H3 --> H4["사람이 확인할 수 있는 양에 묶임"]

3년 뒤에야 에이전트가 주요 업무를 대신할 수 있다는 사실이 충분히 증명됐다고 해보자.

그때부터 팀마다 따로 관리하던 데이터를 연결하고, 에이전트에게 필요한 권한과 결과 확인 방법을 마련하기 시작하면 늦을 가능성이 크다. 모델은 빠르게 바뀌지만 회사가 데이터를 관리하고 책임을 나누는 방식은 같은 속도로 바뀌지 않기 때문이다.

내가 생각하는 미래와 AI-DLC의 컨셉은 이 지점에서 갈라진다.

Amazon의 Frontier Development는 에이전트가 사람의 개입 없이 오래 작업하도록 하는 방식이다. AWS의 엔지니어 Clare Liguori는 기존 시스템을 운영하는 Amazon Stores의 50개 팀 가운데, 배포 속도가 크게 오른 팀들이 일하는 방식을 의도적으로 바꿨다고 설명한다. 대부분 비슷한 도구를 썼는데도 결과가 갈렸다는 점이 흥미로웠다.⁴

Kiro가 공개한 Frontier Engineering 가이드는 그 방향을 더 구체적으로 보여준다. 두 번째 원칙은 에이전트가 일하는 시간을 늘리고 사람의 개입을 줄이라는 것으로, 목표를 다음과 같이 설명한다.⁵

목표는 실행 과정에서 사람의 개입을 점차 줄여가는 것이다. (원문 일부 번역)

사람은 방향을 정하고 결과를 확인하되, 그 사이의 구현과 테스트, 오류 수정은 에이전트가 스스로 반복하도록 맡기자는 이야기다.

나는 AI-DLC의 단계별 승인보다, 이렇게 에이전트가 스스로 끝낼 수 있는 범위를 넓히는 쪽에 더 동의한다.

2. 프로세스의 차이 — 큰 원을 더 빨리 도는 접근

AI로 개발하면서 가장 강력하다고 느낀 것은 요구사항을 정하고, 실제로 만들고, 테스트하고, 피드백을 받는 사이클을 거의 실시간에 가깝게 줄일 수 있다는 점이다.

예전에는 제품을 작게 만들어 확인하려 해도 종이에 화면을 그리거나 화면 구성을 간단히 보여주는 정도에 머물렀다.

지금은 일부 기능과 데이터를 임시로 대신하더라도, 기존 코드와 실제 화면을 연결해 서비스에 가까운 형태로 만들어볼 수 있다. 사용자가 직접 써볼 수 있는 결과를 먼저 띄우고, 그 결과를 보면서 다음에 필요한 기능을 정할 수 있다.

소프트웨어를 기획하고 개발해 운영하기까지의 과정을 SDLC(Software Development Life Cycle)라고 한다. 그중 요구사항을 한꺼번에 모아 설계와 개발을 진행하는 방식을 100미터짜리 철사를 구부려 큰 원 하나를 만드는 일이라고 생각해보자.

요구사항을 모으고, 설계하고, 개발하고, 테스트한 뒤 마지막에야 처음으로 원이 닫힌다.

내가 생각하는 에이전틱 개발은 10미터짜리 작은 원을 여러 개 만들어 용수철처럼 쌓는 방식에 가깝다.

각 원은 화면부터 그 뒤의 처리까지 함께 만들어 사용자가 처음부터 끝까지 써볼 수 있는 작은 기능 하나로, 이런 단위를 vertical slice라고 한다. 원의 크기는 문제에 따라 더 작게도, 조금 크게도 바꿀 수 있다.

flowchart TB
    subgraph BIG["큰 원을 압축하는 방식"]
        BR["많은 요구사항"] --> BD["설계 · 계획"]
        BD --> BI["대량 구현"]
        BI --> BT["통합 테스트 · 리뷰"]
        BT --> BF["늦은 제품 피드백"]
    end

    subgraph SMALL["작은 원을 연속해서 닫는 방식"]
        S1["작은 요구"] --> P1["동작하는 결과"] --> F1["사용자 피드백"]
        F1 --> S2["다음 작은 요구"] --> P2["다음 결과"] --> F2["다음 피드백"]
    end

제품을 직접 써보고 익숙해지면서 다음에 필요한 것을 정할 수 있으니, 한 번도 본 적 없는 제품의 요구사항을 회의실에서 미리 쏟아낼 필요가 없다. 그만큼 머릿속으로 제품 전체를 상상하고 판단해야 하는 부담, 즉 인지부하도 낮아진다.

리뷰하는 사람도 제품 전체를 한 번에 이해하는 대신, 방금 추가된 한 가지 동작과 그 증거만 확인하면 된다.⁶

내가 경험한 AI-DLC는 큰 원을 작은 원으로 바꾸기보다, 기존의 큰 원을 AI로 더 빨리 돌리는 프로세스에 가까웠다.

반면 내가 선호하는 프로세스는 요구사항과 동작하는 결과, 사용자 피드백의 작은 원을 반복해서 닫는 방식이다.

공식 방법론도 bolt라는 짧은 작업 기간을 두고, 할 일을 Unit of Work라는 작은 단위로 나눈다. adaptive workflow도 불필요한 단계를 건너뛸 수 있게 개선됐다.

그런데 각 단계에서 관련된 사람들이 모여 문제와 배경을 함께 이해하고, AI가 만든 계획과 결과물을 검토해 승인한 뒤 다음 단계로 넘어가는 방식은 그대로다.

전체 기간은 줄어들 수 있지만, 같은 양의 요구사항과 설계 판단, 리뷰가 더 짧은 시간 안에 몰리면 사람의 인지부하는 오히려 높아질 수 있다.

Clare의 Frontier Development 발표에서도 구현이 빨라진 뒤 제품 결정과 출시 승인이 더 긴 과정으로 남는다고 설명한다. 특히 되돌리기 쉬운 결정은 더 빨리 내려야 한다고 권한다.⁴⁷

이 관찰은 기존의 큰 개발 사이클을 그대로 둔 채 구현만 압축해서는 부족하다는 내 생각과 맞닿아 있다. 내가 작은 원을 선호하는 것도 한 번에 결정하고 검토할 범위를 줄여, 다음 고객 피드백까지의 대기를 짧게 만들고 싶기 때문이다.

AI-DLC 워크숍에 참여한 사람들이 좋았다고 말하는 이유 중에는 여러 이해관계자가 한자리에 모여 커뮤니케이션 비용이 줄었다는 이야기가 많았다.

그 효과는 분명 중요하지만 AI-DLC만의 효과라기보다, 작은 팀이 빠르게 결정하는 Two-Pizza Team 방식과 개발부터 운영까지 함께 책임지는 DevOps 문화가 잘 작동한 결과일 수도 있다.

좋은 협업 문화와 AI-DLC라는 방법론의 효과를 같은 것으로 보면, 다른 조직에 옮겼을 때 무엇을 재현해야 하는지가 흐려진다.

3. 구현의 차이 — 모델이 일할 순서까지 정해주는 하네스

이 차이는 작업 흐름을 실제 도구와 실행 환경에 옮길 때도 이어진다.

여기서 하네스는 모델이 일하는 데 필요한 배경 정보와 도구, 접근 권한, 코드를 실행할 환경과 결과를 확인할 방법을 통틀어 말한다.⁸

에이전트가 사람 없이 더 오래 일할수록 좋은 하네스가 필요하지만, 그 역할은 두 종류로 나눠볼 필요가 있다고 생각한다.

계획을 세우는 Planner, 문제점을 찾는 Critic, 결과를 검토하는 Reviewer, 작업을 되돌아보는 Reflection Agent처럼 역할을 나눠 여러 에이전트를 쓰거나, 사람이 일을 나누는 순서를 미리 정해두기도 한다. 모델이 스스로 풀기 어려운 문제를 이런 절차로 보완할 수 있다.

하지만 강한 모델은 문제에 따라 첫 행동을 다르게 고를 수 있다.

오류 기록을 바로 읽을 수도 있고, 테스트부터 실행할 수도 있고, 코드 변경 이력에서 언제 문제가 생겼는지 찾을 수도 있다. 짧은 계획이 필요한 문제도 있고, 긴 계획을 쓰는 행위 자체가 낭비인 문제도 있다.

이때 하네스가 항상 조사 → 계획 → 할 일 나누기 → 구현 → 검토 → 회고 순서를 강제하면, 모델이 문제를 어떻게 풀지까지 미리 결정하게 된다.

과거 모델의 약점을 보완하려고 만든 규칙을 새 모델에서도 걷어내지 못해 오히려 방해가 되는 문제를 나는 Harness Debt, 하네스 부채라고 부르고 싶다.

Kiro의 열 번째 원칙도 새 모델이 나오면 예전 모델의 약점을 보완하려고 만든 임시방편이 여전히 필요한지 다시 검토하라고 한다.⁹ 실패에서 배워 필요한 지침과 도구를 추가하는 만큼, 모델이 좋아졌을 때 더는 필요하지 않은 제약을 걷어내는 일도 중요하다는 뜻으로 읽었다.

flowchart LR
    M1["과거 모델<br/>스스로 문제를 풀기 어려움"] --> H1["사람이 복잡한 작업 순서를 정함"]
    H1 --> G["당시에는 성능 향상"]

    M2["새 모델<br/>스스로 문제를 더 잘 풂"] --> H2["예전 작업 순서를 계속 강제"]
    H2 --> D["더 나은 방법을 고르지 못함<br/>하네스 부채"]

    M2 --> E["실행에 필요한 환경 마련"]
    E --> T["도구 · 권한 · 결과 확인 방법 제공"]
    T --> J["해결 전략은 모델이 판단"]

최근 관심을 받는 Pi도 자신을 “minimal agent harness”, 즉 최소한의 기능을 갖춘 하네스라고 소개한다. 사용자는 확장 기능(extension), 작업 지침(skill), 재사용할 요청문(prompt template)을 추가해 원하는 작업 흐름을 만들 수 있다.¹⁰

이 자유도는 분명 매력적이지만, 최신 모델을 쓸 때 사용자가 더 많이 손본다고 결과가 더 좋아지는 것은 아니다. 사용자가 정한 절차 때문에 모델이 더 나은 방법을 선택하지 못할 수도 있기 때문이다.

결제나 금융 업무처럼 반드시 지켜야 하는 실행 순서와 승인 규칙이 있는 일에는 정해진 절차가 필요할 수 있지만, 모든 소프트웨어 개발을 같은 방식으로 해야 하는지는 별개의 문제다.

Claude Code와 Codex를 만드는 조직은 모델과 에이전트 제품을 함께 개발하므로, 새 모델이 나올 때마다 어떤 정보와 지침을 제공하고 어떤 판단을 모델에게 맡길지 함께 확인할 수 있다.

Anthropic도 앞으로 모델에게 어떤 정보와 지침이 필요할지 예측하기 어렵다고 설명한다. 그래서 Managed Agents에서는 작업 기록을 관리하는 session, 모델의 작업을 돕는 harness, 코드를 격리해서 실행하는 sandbox를 서로 분리해 연결했다고 한다.¹¹

OpenAI의 Codex 사례에도 계획을 남기고, 에이전트끼리 리뷰하며, 발견한 문제를 반복해서 고치는 절차가 있다. 내가 주목한 것은 코드 구조와 규칙을 자동으로 검사하고, 에이전트가 화면과 로그까지 직접 확인하도록 환경을 만들었다는 점이다.¹²

하네스는 모델에게 경기장을 제공해야지, 어떻게 경기할지를 대신 결정해서는 안 된다.

Kiro의 Frontier Engineering 가이드도 에이전트가 읽기 쉬운 코드 구조와 명확한 오류 메시지, 필요한 작업을 수행할 도구를 갖추라고 한다.¹³ 테스트를 실행하고 화면을 확인하는 도구까지 제공해, 실패한 결과를 사람이 옮겨주지 않아도 에이전트가 스스로 고칠 수 있게 하라는 설명도 있다.¹⁴

이런 투자는 내가 앞에서 구분한 실행 환경을 갖추는 일에 해당한다. 사람이 결과를 받아 매번 고쳐주는 일을 줄이고, 에이전트가 직접 확인하고 다시 시도할 수 있게 한다.

하네스는 모델이 읽을 수 있는 코드 저장소, 명령을 실행할 환경, 접근 가능한 데이터와 금지된 작업, 통과해야 할 테스트를 정한다.

그 경계 안에서 어떤 순서로 문제를 풀지는 가능한 한 모델에게 맡긴다.

Kiro의 여덟 번째 원칙도 필요한 파일과 도구, 네트워크에만 접근하도록 권한을 제한한 뒤, 사람이 계속 지켜보지 않아도 에이전트가 일하게 하라고 설명한다. 이를 옮기면 “안전장치를 자동화할 때마다 사람이 개입해야 할 이유가 하나씩 줄어든다”라는 뜻인데, 내가 하네스에 기대하는 역할과 가깝다.¹⁵ 되돌릴 수 없는 작업에는 승인을 남기면서도, 사람이 매번 확인하던 일을 시스템이 대신하도록 바꿔가는 방향이다.

AI-DLC의 adaptive workflow는 모든 작업에 같은 절차를 적용하던 문제를 상당히 줄였지만, 단계마다 무엇을 만들고 언제 승인받고 함께 검토할지는 여전히 도구에 정해두고 있다. 그런 점에서 모델의 사고방식과 작업 순서를 정해주는 장치에 가깝다고 생각한다.

모델이 좋아지면 하네스가 정해두었던 작업 순서와 해결 전략도 다시 검토해, 모델에게 맡길 수 있는 판단을 늘려야 한다고 생각한다.

4. 내 생각을 흔드는 고객들의 도입과 성과

나는 AI-DLC를 프로덕션 개발에 도입하거나 팀과 조직 전체로 확대하기가 어렵다고 생각한다. 앞서 살펴본 컨셉·프로세스·구현 세 측면에서도, 내가 이해하는 시장의 방향과 다른 부분이 많다.

그런데 AI-DLC가 잘 작동한다고 말하는 고객도, 도입하겠다는 고객도 계속 생긴다. 그런 이야기를 접할 때마다 내 생각이 흔들린다.

AWS의 공개 글에는 유럽의 한 금융사가 AI-DLC를 도입한 초기 사례가 나온다. 제품 담당자 한 명과 개발자 3명이 한 번의 sprint, 즉 정해진 작업 기간마다 35개 기능을 완성했다고 소개한다.¹⁶

이런 사례를 접하면 내가 놓친 조건이 있는지, 개인 프로젝트에서 얻은 경험을 팀과 조직에도 그대로 적용해서 생각하는 건 아닌지 돌아보게 된다.

내가 생각하는 방식도 개인을 넘어 팀과 조직 단위로 도입해봐야 한다고 생각한다. 실제 고객의 문제를 풀고 서비스를 출시한 뒤, 운영 중의 장애와 여러 사람이 함께 일하며 부딪히는 문제까지 겪어봐야 어느 부분이 통하고 어느 부분을 바꿔야 하는지 알 수 있을 것이다.

아마도 그 과정에서 직접 인사이트를 얻기 전까지는, 내 생각과 고객들의 경험 사이에서 계속 고민할 수밖에 없을 것 같다.

5. 개인의 경험에서 팀과 조직의 경험으로

스티브 잡스가 1992년 MIT 강연에서 컨설턴트에 관해 말한 영상이 있다.

잡스는 여러 회사를 넓게 볼 수 있어도 자신의 권고를 구현하고 그 결과와 실패를 오래 겪지 않으면 배움이 얕을 수 있다고 말했다. 과일 사진은 많이 봤지만 직접 맛보지는 못했다는 비유다.¹⁷

지금은 고객의 기술 선택과 시스템 설계를 돕는 SA(Solutions Architect)로 일하고 있다. 고객과 오래 일하고, 여러 회사에서 반복되는 패턴과 선택지를 보여주는 것 역시 분명한 전문성이므로, 잡스의 말을 SA 전체에 대한 평가로 가져오고 싶지는 않다.

다만 내게는 권고한 뒤의 운영 결과를 직접 겪는가라는 질문이 남았다.

나는 개발자로 커리어를 시작했고, SA가 된 뒤에도 개인 서비스를 직접 개발하고 배포하며 운영해왔다. 지금도 20만 줄과 10만 줄 규모의 서비스에 시간과 비용을 직접 들이고 운영도 책임지고 있지만, 공식적인 고객 사례는 아니다.

이 경험 덕분에 내가 선호하는 개발 방식에 대한 생각은 구체화됐다. 다만 개인 서비스를 운영하는 것만으로는, 여러 사람이 문제와 배경을 공유하고 의사결정과 운영 책임을 나눌 때도 같은 방식이 잘 작동하는지까지 확인하기 어렵다.

제품 조직에 속해 있어도 주어진 티켓만 처리하고 실제 결과에는 관심을 두지 않는 경우를 봤다. 팀과 조직에서의 경험도 문제 정의부터 운영까지 참여하고, 그 결과를 다음 결정에 반영할 때 쌓인다고 생각한다.

AI가 코드를 만드는 능력의 개인차를 줄일수록, 풀려는 문제와 배경을 공유하고 결과를 확인하며 같은 실패를 반복하지 않도록 하네스를 고치는 팀의 능력이 더 중요해진다고 생각한다.

내가 더 확인하고 싶은 것도 이 부분이다. 개인에게 잘 맞았던 작업 방식과 하네스를 팀이 함께 쓸 때 무엇을 바꿔야 하는지, 운영하면서 배운 것을 조직의 일하는 방식에 어떻게 반영할 수 있는지 직접 적용하며 알아가고 싶다.

마치며

나는 여전히 에이전틱 엔지니어링이 사람이 반복해서 개입해야 하는 이유를 시스템에서 하나씩 제거하는 방향으로 갈 것이라고 믿는다. 다만 AI-DLC를 도입하고 성과를 내는 고객들을 만날수록, 내가 예상한 방향과 현장의 선택이 다른 이유를 더 이해하고 싶어진다.

그래서 내가 생각하는 에이전틱 개발 방식을 팀과 조직 단위로 적용하고, 실제 고객의 문제를 함께 풀며 일해보고 싶다. 작게 만들고 배우는 Lean Startup 방식을 개발 프로세스와 하네스에도 적용해보려는 것이다.¹⁸

고객 반응과 운영 결과를 다음 작업에 반영하며 일하다 보면, 내 생각에서 무엇이 맞았고 무엇을 놓쳤는지도 조금씩 알 수 있을 것 같다.

• #ai
• #agent
• #agentic-development
• #ai-dlc
• #harness-engineering
• #hitl
• #solutions-architect