AI Engineering Summit Tokyo 2026(1일차) 세션 리포트 — 「만들 수 있음」의 다음은 「운용·통제」, 8개 강연으로

AI Engineering Summit Tokyo 2026 (Summer)는 AI 엔지니어링의 실무에 초점을 맞춘 컨퍼런스입니다. 이 기사는 그 1일차(2026/06/08)에 청강한 8개 세션의 내용을 테마별로 정리하여 요약한 리포트입니다.

하루 종일 반복해서 나온 것은, 「AI로 코드나 프로덕트를 만들 수 있는 것」은 이제 전제가 되었으며, 논점은 「만든 것을 어떻게 운용하고, 통제하며, 계속 사용되게 할 것인가」로 옮겨가고 있다는 인식이었습니다. 데이터 기반(Data Infrastructure), 비용, 권한·감사, 검증(Validator), 그리고 「인간이 이해·설명할 수 있는 상태」를 어떻게 설계할 것인가—— 발표자가 달라도 동일한 문제 의식이 몇 번이고 나타났습니다.

이 기사에서 알 수 있는 것:

• 🧭 8개 세션을 관통하는 공통 테마 ("만들 수 있음" → "운용·통제"로의 시프트)
• 🏗️ 운용을 견딜 수 있는 에이전트 설계의 구체적 사례 (AI Ready한 데이터 기반, 평가 하네스(Evaluation Harness), 권한 설계)
• 💸 비용과 정밀도의 트레이드오프(Trade-off)를 어떻게 설계할 것인가 (라우팅·카스케이드·상한 설계)
• 🧠 지식을 개인의 세션에 가두지 않는 메커니즘 (AI-DLC의 체크포인트, 대화 문맥의 인계)
• 🔐 기업 도입의 장벽 (보안·감사·스케일)과 그 극복 방법

개별 세션에 들어가기에 앞서, 전체상을 먼저 배치하겠습니다. 다음 그림은 이날 반복해서 이야기된 「중심의 이동」을 보여줍니다.

이 그림의 포인트는 발표자의 업종(OpenAI, 데이터 기업, 부동산 테크, 의료 SI, 통신 캐리어 등)이 달라도 도달하는 목적지가 공통적이었다는 점입니다. 「PoC는 작동했다. 문제는 그 이후였다」라는 이야기가 표현을 바꿔가며 몇 번이나 나왔습니다. 이후 각 세션을 차례대로 살펴보겠습니다.

참고로, 청강한 8개 세션의 목록은 다음과 같습니다.

#	세션	발표자 (소속)	주제
1	Transforming the enterprise with FDE	미즈코시 마사미 씨 / Ryan Cain 씨 (OpenAI Japan)	FDE라는 동반형 진행 방식
...
첫 타자는 OpenAI Japan의 FDE (Forward Deployed Engineering) 팀에 의한 세션이었습니다. FDE는 비즈니스 과제에서 출발하여, 사용자와 동행하며 반복적으로 개발을 진행하고, 인테그레이션(Integration)을 실운용 수준까지 다듬어 그 지견을 프로덕트로 승화시키는 접근 방식입니다.

인상적이었던 것은 기술을 파는 것이 아니라 「업무 그 자체를 고객(현장에서 경영진까지)과 함께 동행하며 업계를 바꾸어 나간다」는 구조였습니다. FDE의 진행 방식은 다음 루프로 설명되었습니다.

이 그림의 포인트는 「사업 과제 ↔ 연구 ↔ 도입」이 일방통행이 아니라 루프가 되어 있다는 점입니다. 중요하게 여기는 사항으로 「데이터와 컨텍스트(Context)", 「신뢰성과 거버넌스(Governance)」가 꼽혔으며, 여기서도 “만들고 끝”이 아닌 자세가 나타났습니다. OpenAI 자신도 에이전트의 코드를 반년 만에 완전히 새로 작성하고 있다는 이야기가 있었으며, 진화의 속도 속에서 토대를 계속 재구축한다는 전제가 공유되었습니다.

이날 가장 정보 밀도가 높았던 것은 츄라 데이터(Chura Data) 대표이사인 마카비 아이 씨의 세션입니다. 출발점은 「“만들 수 있음”과 “계속 사용됨”은 별개의 문제」라는 한마디였습니다. 실제로 일어난 실패 사례로서, 운영 DB를 삭제했다, 존재하지 않는 할인을 만들어 고객에게 안내했다, 고객 지원(Customer Support)을 AI로 했더니 만족도가 떨어져 인간을 복귀시켰다 등 생생한 예시가 소개되었습니다.

PoC와 운영 환경의 차이는 다음과 같이 정리되었습니다.

• 고정 데이터로 검증하는 PoC에서 운영 환경으로 옮기면, 데이터를 AI 전제로 계속 업데이트해야 한다. 오래되었거나 미정비된 데이터는 할루시네이션(Hallucination)의 요인이 됩니다.
• 한정된 시나리오의 평가만으로는 부족하며, 다양하고 예상치 못한, 혹은 적대적인 입력에 대처하는 가드레일(Guardrail)이 필요합니다.
• 인간이 결과를 확인하는 PoC에서, 무인 또는 소수 인원으로 품질을 지키는 운용으로 변합니다. 트레이스(Trace)를 부여하고 자동 평가와 열화 감지가 필요합니다.
• 샌드박스(Sandbox)에서 운영 환경으로 옮기면, 에이전트가 권한을 가지고 실제 데이터를 조작하기 때문에 실패가 실질적인 피해로 이어집니다.

이 세션의 핵심은 AI가 사용할 수 있는 데이터 기반을 5개 층으로 파악한 정리였습니다.

각 층의 역할을 표로 정리하면 다음과 같습니다.

층	역할	예
컨텍스트 (Context)	데이터에 의미·출처·신선도·전제를 부여함	이 컬럼은 세금 별도인가 포함인가
...

보충 설명으로, 온톨로지(Ontology)에 올라가는 지표는 **시맨틱 레이어 (Semantic Layer)**에서 관리하며, '의미(정의)'와 '구현(쿼리)'을 하나의 정의 단위로 일원 관리해야 한다는 이야기가 있었습니다. 별도로 관리할 경우 이용 과정에서 정의가 어긋나는 **메트릭 드리프트 (metric drift)**가 발생하기 때문입니다. 나아가 데이터 기반은 "만들어서 끝"이 아니라, 메트릭 정의를 코드로 관리하는 definitions as code (PR 리뷰·CI 테스트·버전 관리·폐기 규칙·메트릭 오너)와, 열화를 지속적으로 감지하는 데이터 옵저버빌리티 (Data Observability) (리니지(Lineage)와 결합하여 상류의 원인과 하류의 파급 효과를 특정)가 필요하다고 이어졌습니다.

정밀도와 비용의 양립 또한 큰 주제였습니다. 최상위 모델을 다단으로 배치하면 정밀도는 높지만 과도한 비용이 발생하고, 저렴한 모델로 대체하면 비용은 낮지만 정밀도가 부족해지기 쉽습니다. 대응책은 크게 3가지 계통(동일 정밀도로 저렴하게 만들기 = 캐시·배치 / 최적점을 선택하기 = 라우팅·카스케이드 / 프론티어를 끌어올리기 = SLM·파인튜닝)으로 나뉘며, 어떤 순서로 접근하느냐가 중요하다고 강조되었습니다.

이 도표의 포인트는 많은 기업에서 SLM의 호스팅이나 파인튜닝은 마지막 선택지라는 순서입니다. 사례로서 Checkr는 대다수의 쉬운 태스크를 파인튜닝한 SLM에 맡기고, 어려운 일부만 상위 모델로 넘기는 카스케이드(Cascade) 구성으로 비용을 약 1/5로 줄이고 속도를 약 30배 향상시켰다고 소개되었습니다.

라우팅은 "복잡한 메커니즘보다 우선 규칙 기반(Rule-based)으로도 충분하다. 측정하면서 단계적으로 도입한다"가 기본 방침이었습니다.

경구로서 가슴에 와닿았던 것은 "비용은 조용히 폭주한다"였습니다. 에이전트는 호출 횟수를 사람이 제어하지 않는 설계가 되기 쉬워, 자신도 모르는 사이에 비용이 팽창합니다. 대표적인 예로, 폭주한 멀티 에이전트가 서로 264시간 동안 대화를 지속하여 11일 동안 약 $47,000의 LLM API 비용을 발생시킨 사례가 언급되었습니다. 스텝 상한·예산 상한·종료 판단을 수행하는 오케스트레이터(Orchestrator)가 없었고, API 에러도 발생하지 않았기 때문에 월간 청구서가 나올 때까지 발각되지 않았다고 합니다. 측정뿐만 아니라 상한을 설정하는 것이 대책이 됩니다.

운용 사상은 MLOps → LLMOps → AgentOps로 확장되며, 관측성(Observability)·추적 가능성(Traceability)·피드백 루프·안전성/거버넌스가 요점으로 꼽혔습니다. 다만 "한번에 전부 하기"보다는 투자 대비 효과를 보면서 최소 구성부터 넓혀가는 현실적인 해법이 제시되었습니다.

단계	내용
MUST (최우선)	트레이스(Trace) 수집 / 작은 데이터셋을 통한 평가 / 변경 시 회귀 테스트 / HITL (Human-in-the-loop, 사람의 확인)
...

권한 관련은 "권한의 최소화"와 "난립 관리"에 대해 6가지 대응책으로 정리되었습니다.

관점	대응책
과잉 권한에 대한 대책	① 고유 ID 부여 (공유 금지) ② 최소 권한 + 사용자 대리 (OBO) ③ 경계를 LLM에 맡기지 않음
난립에 대한 대책	④ 사용자(User)와 에이전트(Agent)를 이중으로 기록 ⑤ 레지스트리(Registry)로 기한 관리 ⑥ 고위험 작업은 승인 절차를 거침

마지막으로 "조용히 사용되지 않게 되는 것을 방지하기" 위해, KGI/KPI 미설정·사용자 시나리오 미설계·운용 책임자의 공백이 에이전트를 "사일런트하게(silently)" 형해화시킨다는 주의사항으로 마무리되었습니다.

부동산 테크 기업 estie의 스도(Sudo) 씨는 전사적으로 AI 제품 개발을 추진하는 "AI Enabling Unit"의 노력을 공유했습니다. 과제를 개별적으로 격파하는 것만으로는 AI 도입 속도를 따라갈 수 없고, 그렇다고 "어떤 기반을 구축해야 하는가"에 대한 구체적인 상을 잡기 어려운 상황—여기서 탄생한 것이 AgentHub입니다.

계기는 일주일에 하루씩 각자 관심 있는 일에 몰두하는 "실험 Day"였다고 합니다. 자사 데이터 기반에 접속하는 도구를 용도별로 다수 만들고, 에이전트가 프롬프트에 따라 적절한 도구 세트(Tool-set)를 선택하는 형태로 만들자 "부동산 데이터에 대해 물어볼 수 있는 에이전트"가 탄생했습니다. AgentHub는 제품에서 직접 AI 기능을 개별 구현하는 것이 아니라, AI 기능의 **공통 기반/리포지토리(Repository)**로서 자리매김하고 있습니다.

개발 전용 기능인 custom-agent 또한 흥미로운 고안이었습니다. 요청에 시스템 프롬프트(System Prompt)와 사용하고 싶은 도구(Tool) 리스트를 실어서 보내면, AgentHub에 구현하지 않고도 새로운 에이전트(Agent)를 테스트할 수 있습니다. 감을 잡으면 본편용으로 구현한다는 흐름입니다. 다만 custom-agent 상태로는 품질 보증이나 이용량 관측이 어렵기 때문에, "개발 속도에 치중한 기능과 운영 안정성에 치중한 기능은 분리한다"라는 원칙이 제시되었습니다.

정리에서는 "AI라면 무엇이든 할 수 있을 것 같다"라는 인식이 의외로 현실과 맞지 않기 때문에 "AI로 무엇을 할 것인가"에 대한 공통 인식이 중요하다는 이야기와, AI 시대에도 개발 속도와 운영 안정성을 나누는 등의 기존 설계 원칙은 유효하다는 지적이 인상 깊었습니다.

Helpfeel의 하시모토 씨 세션은 "AI에게 구현하게 할 뿐만 아니라, AI의 제정신을 의심하게 만드는 개발 프로세스"라는 관점이었습니다. 배경으로는 2025년 이후의 AI 개발에서 "1인이 내는 PR(Pull Request)의 수는 크게 늘지 않았지만, 하나의 PR 사이즈가 커졌다"는 점이 언급되었습니다. 큰 차이점(diff)을 "지식 노동자로서 리뷰해달라고 요청하는 것"만으로는 신뢰하기 어려워졌다는 문제의식입니다.

소개된 것은 자체 제작한 3가지 에이전트 스킬(Agent Skill)이었습니다.

Skill	목적	활용 상황
codex-consultation	AI끼리 격렬한 가설·반론·재검증을 수행하게 하여 코드 품질을 높이고 버그(bug)를 줄임	코드 품질을 높이고 싶을 때 / 버그를 없애고 싶을 때
...

특히 와닿았던 것은 "중요한 것은 '하지 않는 것과 그 이유'"라는 관점이었습니다. 수행한 내용 자체는 코드를 읽으면 알 수 있고 AI에게도 설명시킬 수 있지만, "여러 가지를 검토한 결과 이렇게 되었다"라는 내용—코드로 남지 않는 판단—이야말로 리뷰에서 보고 싶다는 이야기입니다. conversation-context-export는 Claude Code의 /compact와 궁합이 좋아, 긴 세션에서도 "하지 않는 것과 이유"를 인계할 수 있다고 합니다.

sanity-review의 체크 항목은 "개요란이 제대로 작성되었는가", "개요란과 구현의 비교", "구현의 질"의 3가지 포인트로, PR 개요란을 선언적으로 작성(확인 항목이 3개라면 3개를 명시)함으로써 후속 단계의 AI가 의심하기 쉬운 재료를 남기는 운용 방식이었습니다. 환경은 Claude Code(Opus)와 Codex CLI(GPT5.5-high)를 병용하며, IME 사전에 자주 쓰는 프롬프트를 등록해 두는 등의 실천적인 팁도 공유되었습니다.

💡 이 세션의 스킬군(codex-consultation / conversation-context-export・import / sanity-review)은 저희의 에이전트 운용에도 그대로 도입하고 싶다고 느낀 부분이었습니다. "인간이 이해할 수 있는 상태"를 완료 조건에 넣는다는 사고방식이 핵심입니다.

공모 세션에서는 3명이 각각 10분씩 등단했습니다. 발표 제목은 다음과 같습니다.

• 실수를 "놓치지 않는" AI Agent 구축 — 코드 품질 향상 Agent "D-Arc" (다이킨 공업 / 타카기 시오리)
• "오독", "오해", "오폭" 1초와 싸우는 면담 AI 에이전트 만드는 법 (Algomatic / 사카모토 카즈키)
• 의료 SI 현장에서 시작한 Dify × AWS를 통한 에이전트 구축과 데이터 익명화의 배움 (NEC 솔루션 이노베이터 / 쿄나카 토시키)

여기서는 메모를 자세히 작성한 쿄나카 씨의 의료 SI 사례를 중심으로 소개합니다. 의료 현장은 고객 정보·개인 정보를 포함하기 때문에 외부 SaaS로 그대로 던질 수 없다는 제약이 있습니다. 그 전제하에 "제약은 유지하면서 설계서 작성 작업을 가볍게 할 수 없을까"라는 질문으로부터, 히어링 시트(Hearing Sheet)에서 설계서와 테스트 사양서를 자동 생성하는 에이전트가 만들어졌습니다.

구성 방식은 핵심인 Dify를 AWS에 셀프 호스팅(Self-host)하는 것이었습니다. 이유는 개인 정보를 포함하므로 데이터 레지던시(Data Residency)를 확보하고 싶다는 점, Dify는 워크플로우를 시각화할 수 있어 제삼자가 나중에 추적할 수 있다는 점, AWS는 공식 구성 예시나 참고 사례가 풍부하다는 점 때문이었습니다.

가장 큰 배움은 "익명화에 대한 인력 확인의 무게"였다고 합니다. 최대의 비용은 "생성"이 아니라 "누락되지 않았는지 사람이 직접 확인하는 작업"이었습니다. GiNZA의 NER(개체명 인식)을 통해 <PERSON>이나 <PHONE>

<PERSON>이나 <PHONE>으로 교체하더라도 기계 처리만으로는 반드시 누락이 발생합니다. "○○ 병원의 다나카 선생님"과 같이 직위·역할과 결합된 문맥 의존적인 PII(개인 식별 정보)가 남게 되며, 검증 대상이 "나오지 않았음"을 확인하는 것이기에 체크리스트화하기 어렵습니다. 개인정보는 단 한 글자의 누락도 사고로 직결되기 때문에 "대체로 지워졌다"는 수준은 허용되지 않는다는 이야기였습니다.

그로부터 "리뷰의 목적이 바뀌었다"라는 재정의가 제시되었습니다. 기존의 리뷰는 "정확성"을 체크하는 것이었지만, 앞으로는 "설명할 수 있음"을 체크하는 것이 됩니다. "누락되지 않았음을 제삼자에게 설명할 수 있는" 상태를 만드는 것이 중요하며, 이를 위해 워크플로우를 시각화할 수 있는 로우코드(Low-code) 도구인 Dify가 효과적이라는 결론이었습니다. 로그·권한 관리·모델 전환이 내장되어 있어 규제 요건에 대응하기 쉬운 토대가 됩니다.

Belong의 후쿠이 씨 세션은 AWS의 **AI-DLC (AI-Driven Development Life Cycle)**를 실전 수준으로 적용하여, SDLC(소프트웨어 개발 생명 주기)에 독자적인 체크포인트를 추가해 팀의 프로세스로 만든 실천 사례였습니다. 배경 과제는 명확했습니다. "AI를 활용한 개발에서는 지식이나 판단이 개인의 AI 세션 내에 갇히기 쉽다"는 점입니다. 숙련된 사람은 속도를 높일 수 있지만, 그렇지 않은 사람에게는 결과만 보일 뿐이라 팀 내 격차가 벌어지게 됩니다.

AI-DLC는 Inception(사양(Spec) 정의·유저 스토리·유닛 분할) / Construction(논리 설계·도메인 모델·코드/테스트 생성) / Operation(CI/CD·IaC)의 3단계로 구성되며, 핵심 패턴은 "AI가 계획 → 사람이 승인 → AI가 구현"입니다. 이 세션에서는 그 위에 Checkpoint 설계를 얹었습니다.

Checkpoint의 목적은 "생각했지만 언어화되지 않은" 부분을 포착하는 것입니다. 판단 근거의 기록, 암묵적 가정의 명시화, 컨텍스트(Context)의 기록, 리뷰 정밀도 향상, 실패(기각안)의 학습을 목표로 합니다. 이를 통해 "사양(Spec) 정의의 민주화", "빠른 시작", "구현 수준의 상향 평준화(Bottom-up)"를 지향한다고 밝혔습니다.

설계를 뒷받침하는 두 가지 원칙도 실천적이었습니다. AI로부터 끌어내는 Knowledge Elicitation(지시가 아닌 "질문"을 던져 파운데이션 모델(Foundation Model)의 범용 지식을 끌어내는 것)과, AI에게 부여하는 Context Engineering(자사 고유의 컨텍스트를 구조화하여 제공하는 것. LLM Wiki처럼 요약·원 데이터·URL을 리포지토리에 유지하는 방식)입니다. 나아가 AI-DLC의 디렉토리 구조를 확장하여, Flow(티켓 단위의 작업 기록)와 Stock(유닛 단위의 장기 지식)을 분리하고, 티켓 완료 시 Flow에서 Stock으로 지식을 승격시키는 운영 방식을 소개했습니다.

적용 원칙은 "망설여진다면 적은 쪽부터"였습니다.

규모	체크포인트 적용
버그 수정·소규모 태스크	CP 없음 (통상적인 PR 플로우)
...

도입 후 좋았던 점으로는, 목표 이해가 리더 계층을 넘어 팀 전체에 전달되어 태스크의 가시성이 향상된 점, Spec/Design 정의 수준이 높아져 기안자의 층이 넓어진 점, 파운데이션 모델(Foundation Model)이 "원래는 깨닫지 못했던 관점"을 보완해 준 점 등을 꼽았습니다. 반면, 여러 리포지토리에 대한 적용이나 기존 거대 리포지토리의 사양(Spec)화, 고유 도메인(DWH 구축 등)의 사양(Spec) 정의에는 개선의 여지가 있어 아직 시행 및 개선 사이클의 과정에 있다고 전했습니다.

Techtouch의 이토 씨 세션은 조작 가이드를 AI로 생성하는 "AI Editor"를 주제로, 에이전트의 품질 안정화를 깊이 있게 다루었습니다. 출발점은 "첫 번째 장벽은 AI에게 맡길수록 출력이 불안정해진다는 것"이었습니다. LLM 단독으로는 실재하지 않는 UI 요소 ID를 참조하거나, 전제 조건이 누락되거나, 조건 분기가 성립하지 않거나, 스텝 구성이 매번 흔들리는 등의 문제가 발생합니다. 프로덕트에 필요한 것은 실무에 견딜 수 있고, 재현성이 있으며, 검증 가능하고, 사람이 판단할 수 있는 품질입니다.

전환점이 된 것은 **TCD (Techtouch Contextual Database)**였습니다. 이는 고객 과제에 대해 Techtouch를 어떻게 사용하여 해결해 왔는지에 대한 지식을 과제·목적·해결책·유도 프로세스·조작 요구사항·성공 패턴으로 모델링한 것입니다. "생성형 AI로 인해 변한 것은 도메인 모델링의 중요성이 아니라, 모델링된 지식의 사용 방식"이라는 지적이 핵심이었습니다.

그리고 컨텍스트(Context)를 전부 넣으면 시스템이 붕괴(느려짐·비용 상승·불안정)되기 때문에, 정보의 배치 설계가 중요하다고 하며 4가지 분류가 제시되었습니다.

"어떤 정보를 LLM에 읽힐 것인가만큼, 어떤 정보를 읽히지 않을 것인가가 중요하다"라는 말이 인상적이었습니다. Agent는 처리 단계가 아니라 데이터의 책무로 분할하며(지식 검색 / 방침 결정 / 구조 설계 / 데이터 변환 / 검증·수정), 안정적인 출력의 열쇠는 validator(검증기)——즉, AI의 출력을 믿는 것이 아니라 AI의 출력을 검사할 수 있는 구조로 만드는 것이라는 설계 사상이었습니다.

나아가 "사용자가 원하는 것은 정확도만이 아니다"라며, 왜 이 구성인지, 어디를 고치면 되는지, 스스로 제어할 수 있는지와 같은 납득감·투명성·제어 가능성을 중시했습니다. Step Structure View(골격을 확인·수정)와 User Story View(AI가 왜 그 구성을 선택했는지를 이야기 형식으로 표시)라는 두 가지 프리뷰 경험을 통해, "AI의 사고를 사용자가 이해하고 수정할 수 있는 인터페이스"를 구현하고 있었습니다. 마지막의 "Agent 개발이란 AI에게 프롬프트를 쓰는 일이 아니라, AI가 업무를 다룰 수 있도록 도메인을 설계하는 일"이라는 문장이 이날의 기저에 흐르는 핵심 주제를 잘 나타내고 있었습니다.

마지막은 소프트뱅크(SoftBank)의 나카야마(Nakayama) 씨가 진행한 AGENTIC STAR 세션이었습니다. 소프트뱅크는 AI 데이터 센터, 소버린 AI/클라우드, 국산 LLM (Sarashina), 생성형 AI·AI 에이전트 (AGENTIC STAR / dailyAI 등)를 차세대 사회 인프라로 위치시키고 있으며, 생성형 AI의 활용은 2022–23년의 채팅 LLM/RAG, 2024년의 Tool-Using AI를 거쳐, 2025년 이후에는 자율 실행 AI로 확장되고 있다는 시계열적 흐름이 제시되었습니다.

여기서도 축은 운용이었습니다. "무엇이든 할 수 있지만 아무도 감사(Audit)할 수 없다"는 점이 기업 도입의 가장 큰 장벽이며, 세션에서는 AI PoC의 88%가 본업 전개(Production)로 나아가지 못한다는 데이터도 소개되었습니다. PoC에서 끝나지 않기 위해 넘어야 할 벽은 5가지로, "어느 하나가 아니라 5가지 모두를 동시에 설계해야 한다"고 강조되었습니다.

각 벽의 과제와 대책은 다음과 같이 정리되었습니다.

벽	주요 과제	주요 대책
보안 (Security)	LLM으로의 데이터 송출 / 권한 부여 / 감사 로그 결여	LLM 프록시, 마스킹·차단, 툴 허가 리스트 (MCP), 통신 로그 취득. 가드레일(Guardrail)은 '부탁'에 불과하므로, 외부에서 물리적으로 차단
...

AGENTIC STAR 자체는 전용 가상 환경·거버넌스 기능·심리스(Seamless)한 MCP 연동·장기/단기 기억을 갖춘 엔터프라이즈용 자율 범용형 에이전트로, Marketplace Edition에서는 개발자가 "에이전트 개발 그 자체"에 전념할 수 있는 것을 목표로 한다고 소개되었습니다. 자율 점수로서 GAIA 벤치마크 88.5%, SWE-bench Verified 83.8%라는 수치도 제시되었습니다. 마지막의 "자율과 폭주는 종이 한 장 차이. 규칙과 경계 안에서 움직이기 시작해야 비로소 자율이라 부를 수 있다"라는 말이 하루 전체를 요약하는 듯했습니다.

8개 세션을 나열해 보면, 업종이나 입장을 초월하여 몇 가지 공통점이 떠오릅니다.

• 🔁 에이전트는 "확장"을 전제로 설계한다. 플로우를 유연하게 교체하거나 정지시킬 수 있는 것이 중요하며, 기능은 에이전트의 "도구(Tool)"로서 구현한다.
• 🧩 최적해는 시대에 따라 변한다. 따라서 교체하기 쉽게 만들어 두어야 한다. 규칙 기반(Rule-based)과 LLM 기반의 구분 사용이 현실적이었다.
• ❓ AI에게 "질문"하여 범용 지식을 끌어낸다. 지시할 뿐만 아니라, 파운데이션 모델(Foundation Model)로부터 끌어내는 자세(Knowledge Elicitation)가 여러 세션에서 공통적으로 나타났다.
• 🔍 품질 보증은 복수 모델의 상호 체크. Claude나 Codex 등 여러 AI에게 상호 리뷰를 시키는 운용이 Helpfeel과 전체 고찰 모두에서 언급되었다.
• 🛡️ 중심은 "생성"에서 "권한·감사"로. 에이전트가 프로덕트를 생성하는 것은 당연한 일이 되었으며, 시대는 에이전트의 권한 설계와 감사 방법에 집중하고 있다는 총괄에 도달했습니다.

이날 가장 얻어가고 싶다고 느낀 점은 리뷰(Review)의 재정의입니다. 의료 SI 세션이 보여주었듯이, 리뷰의 목적이 「정확함」에서 「설명할 수 있음」으로 이동하고 있습니다. AI가 대량으로 생성할 수 있는 시대에 인간이 담당해야 하는 역할은, 「누락되지 않았음」과 「왜 이렇게 했는가」를 제3자에게 설명할 수 있는 상태를 설계하는 것이라는 일관된 메시지였습니다.

마지막으로, 이날의 힌트로서 특히 기억에 남는 것을 한 가지 꼽아두겠습니다. 대시보드와 같은 결과물 자체를 AI 에이전트(AI Agent)에게 만들게 하고, 그 위에서 에이전트가 자율적으로 구동하게 하는 것——「사람이 만들고 AI가 사용하는」 것을 넘어 「AI가 만들고 AI가 운영하는」 단계를 운영과 통제(Governance) 설계와 세트로 생각하는 방향입니다. 만들 수 있음이 전제가 된 이후에 질문되는 것은, 역시 「어떻게 운영하고, 어떻게 설명 책임(Accountability)을 다할 것인가」였습니다.

• AI Engineering Summit Tokyo 2026 Summer (공식 사이트) — 컨퍼런스 개요 및 타임테이블.
• 본 리포트는 2026/06/08 (1일차)에 청강한 8개 세션의 개인 메모를 바탕으로 합니다. 각 세션에서 소개된 수치 및 사례는 발표 내용으로서 기록된 것입니다.