1. 배운 내용

supervisor and routing

멀티 에이전트 오케스트레이션 패턴 중 감독자와 라우팅을 사용하는 것에 대해서 배웠다. 라우팅의 경우 단순히 흘러갈 방향을 정해주는 것이지만 감독자의 경우 해당 역할을 끝까지 책임져서 검증이 되면 다음 단계로 진행하게 한다.

2. 실제 작업한 내용

실습

감독자와 라우팅 패턴을 실행해보고 간단한 오케스트레이션을 구현해보았다.

3. 소감

사용자 편의성과 경험에 대해서 생각을 많이 하고 있는데 역시 내 안에 어떤 기준이 명확히 마련되어 있지 않다는 생각이 들었다. 추상적인 단어들을 구체화하고 좀 더 명확하게 개념과 실제 디자인이 연결될 수 있도록 설계 연습을 하고 있는 것 같다.

1. 배운 내용

역할과 계약

멀티 에이전트 오케스트레이션 관련해서 역할과 계약에 대해서 배웠다. 에이전트에 역할을 부여하고 작업을 나누고 명확한 입출력 계약을 사용하고 계약을 검증하고 정보 부족도 검증하고 사용자에게 요청하고 여러 llm을 유연하게 이용하고 흐름의 과정마다 검증을 한다. 이게 필요한 이유는 간단하다. 통제 불가능한 확률적 모델을 원하는 목표까지 안전하게 이끌기 위한 통제력 확보를 위한 것이다. 즉, 명확한 목표로 가기 위해 역할과 작업을 부여하고 계약을 사용하고 검증하고 실패를 방지 및 복구하기 위해 여러 장치를 사용하는 것이다.

2. 실제 작업한 내용

간단한 실습

역할과 계약을 부여한 간단한 오케스트레이션 시스템을 만들어보는 실습을 했다.

3. 소감

오케스트레이션을 개발하는 환경을 조성하는 걸 생각하다 보니 유지, 보수, 운영을 자연스럽게 고려하게 되고 각 요소들을 어떻게 조합할 지를 고민하게 되는 것 같다. 좀 더 간단하고 흥미를 가지도록 환경을 조성하는 것이 아직 나에게는 애매한 부분이 많은 것 같다. 디자인을 하면서 그 기준들을 정립해 나가야 할 것 같다.

1. 배움 정리

실행을 직접 하는 것에서 실행 구조를 만드는 것으로

이번 주에는 GitHub Actions와 AWS를 연결해서 인프라 구축부터 배포까지 자동화하는 과정을 확인했다.

이전에는 AWS에 직접 접속해서 서버를 만들고 Docker 이미지를 실행하는 과정을 중심으로 배웠다면 이번에는 사람이 하나씩 실행하던 작업을 하나의 흐름으로 만들었다.

GitHub Actions
↓
AWS 인증
↓
인프라 구축
↓
이미지 Build
↓
ECR Push
↓
EC2 실행
↓
SSM을 통한 배포

GitHub Actions에서는 OIDC를 이용해 AWS에 인증하고, RDS PostgreSQL, ElastiCache Redis, ECR, IAM, 네트워크 등의 인프라를 구성한 뒤 애플리케이션까지 배포할 수 있었다.

SSH를 이용해서 서버에 직접 들어가 명령을 실행하는 대신 SSM을 통해 배포 작업을 전달할 수도 있었다.

여기에서 중요한 것은 단순히 명령어를 자동으로 실행한다는 것보다 사람이 하던 여러 작업과 그 순서를 하나의 실행 가능한 구조로 정의했다는 것인 것 같다.

사람이 직접 판단하고 실행

A
↓
B
↓
C
↓
D


자동화된 Workflow

Trigger
↓
A
↓
B
↓
C
↓
D

어떤 작업의 순서와 조건이 충분히 명확하다면 사람이 매번 같은 판단을 반복할 필요가 없다.

이렇게 보면 자동화는 단순히 시간을 줄이는 것이 아니라 이미 결정된 판단을 시스템의 구조로 옮기는 과정이라고 볼 수도 있을 것 같다.

AI에게 작업을 맡길 때도 필요한 경계

AWS 설정, 조회, 생성, 삭제 같은 작업도 Codex를 이용해서 진행해봤다.

방향을 명확하게 정해주면 생각보다 넓은 범위의 작업을 잘 처리했지만, 인프라처럼 비용이나 실제 리소스 변경이 발생하는 작업에서는 결과가 잘못됐을 때의 영향도 커진다.

그래서 작업의 위험에 따라 AI에게 주는 자유도와 검증 수준도 달라져야 할 것 같다.

낮은 위험
↓
넓은 실행 범위
↓
결과 확인


높은 위험
↓
명확한 작업 범위
↓
중간 검증
↓
실행
↓
결과 검증

AWS는 리소스를 유지하는 것만으로도 비용이 발생할 수 있기 때문에 필요한 작업이 끝난 뒤에는 의존 관계를 고려해서 리소스를 제거하는 과정까지 자동화했다.

이전에 Human-in-the-Loop를 배우면서 생각했던 것과 비슷하게, 자동화나 AI Agent도 무엇을 할 수 있는가보다 어디까지 스스로 하도록 허용할 것인가가 중요하다.

결국 자율성을 높인다는 것은 통제를 없애는 것이 아니라

목표
+
허용되는 범위
+
검증 기준
+
실패했을 때의 처리

를 더 명확하게 만드는 것에 가까운 것 같다.

하나의 Agent에서 여러 Agent로

멀티에이전트 오케스트레이션을 배우면서 Agent를 여러 개 사용한다고 항상 좋은 시스템이 되는 것은 아니라는 점도 다시 생각하게 되었다.

하나의 Agent가 충분히 해결할 수 있는 작업을 여러 Agent로 나누면 오히려

작업 분배
Agent 선택
정보 전달
상태 관리
결과 통합
오류 처리
평가

같은 새로운 관리 작업이 생긴다.

따라서 멀티에이전트를 사용할지를 결정할 때는 단순히 작업이 어렵거나 크다는 것보다 작업을 의미 있게 분리할 수 있는지가 중요해 보인다.

하나의 작업
↓
서로 독립적인 부분으로 나눌 수 있는가?
        ↓
      YES
        ↓
병렬 또는 역할 분담 가능
        ↓
멀티에이전트 활용 가능

반대로 각 단계가 서로 강하게 의존하거나 하나의 Agent가 충분히 처리할 수 있다면 분리하면서 생기는 오케스트레이션 비용이 더 클 수도 있다.

그래서

Agent의 수가 많아지는 것 = 시스템의 능력이 높아지는 것

은 아닌 것 같다.

오히려

작업의 구조에 맞게 필요한 실행 주체를 선택하는 것

이 더 중요하다.

Workflow Pattern은 작업 관계를 표현하는 방법

멀티에이전트에서는 여러 Agent가 어떤 관계로 작업할지 정의하기 위한 다양한 Workflow Pattern도 확인했다.

대표적으로

Chain

A → B → C

처럼 앞의 결과를 다음 작업에 전달할 수도 있고,

Router

        → A
Input → → B
        → C

처럼 입력에 따라 적절한 Agent를 선택할 수도 있다.

서로 독립적인 작업이라면

        → A →
Input → → B → Merge
        → C →

처럼 병렬로 처리한 뒤 결과를 합칠 수 있다.

결과를 평가해서 다시 개선하는 구조도 만들 수 있다.

Generate
↓
Evaluate
↓
Pass? ─ YES → Result
 │
 NO
 │
 ↓
Improve
 └────────↺

각 패턴은 서로 완전히 다른 기술이라기보다 작업 사이의 관계를 표현하는 기본적인 구조에 가까운 것 같다.

이러한 구조를 조합하면 더 복잡한 Workflow도 만들 수 있고, 많은 Workflow를 결국 Node와 Edge로 이루어진 Graph 형태로 표현할 수 있다.

Node
→ Agent / Tool / 작업

Edge
→ 다음 작업과의 관계

이렇게 생각하면 멀티에이전트 오케스트레이션도 결국

어떤 작업들이 존재하고, 어떤 관계로 실행되는가

를 정의하는 문제라고 볼 수 있을 것 같다.

여러 Agent를 사용하면 새로운 시스템이 필요해진다

멀티에이전트를 실제로 활용하기 위해 필요한 기술들도 조사했다.

단순히 Agent 여러 개를 만드는 것으로 끝나는 것이 아니라 각각의 Agent가 작업할 수 있는 전체 환경이 필요하다.

[Workflow]
어떤 순서와 관계로 실행할 것인가

[Agent]
각각 어떤 역할과 능력을 가질 것인가

[Communication]
Agent가 어떻게 정보를 주고받을 것인가

[Trace]
각 Agent가 무엇을 했는지 어떻게 확인할 것인가

[Evaluation]
각 결과가 적절한지 어떻게 판단할 것인가

[UI]
사람이 전체 실행을 어떻게 확인하고 조작할 것인가

여기에 Agent 사이의 상호작용을 위한 A2A 같은 방식도 적용할 수 있고, 모든 역할에 큰 모델이 필요한 것이 아니라 작업에 따라 경량 오픈소스 모델을 사용할 수 있는지도 살펴봤다.

이전에 하나의 Agent를 공부할 때도 Memory, State, Trace, Evaluation 같은 주변 구조가 필요했는데 Agent의 수가 많아지면 이런 관리 구조의 중요성이 더 커진다.

Single Agent

User
↓
Agent
↓
Tool


Multi-Agent

             ┌→ Agent A ─┐
User → Orchestration → Agent B ─→ Merge
             └→ Agent C ─┘
                    ↓
          Trace / State / Evaluation

즉 멀티에이전트의 핵심은 Agent를 많이 만드는 것이 아니라 여러 실행 주체를 하나의 시스템으로 동작하게 만드는 것에 더 가까운 것 같다.

모든 것을 직접 만들 필요는 없다

멀티에이전트에 사용할 기술을 조사하면서 Workflow, UI, Trace, Agent, 평가 등 각 영역에 이미 만들어진 기술이 상당히 많다는 것도 다시 느꼈다.

하나의 시스템을 보면 겉으로는 하나의 제품이나 기술처럼 보이지만 안쪽에는 이미 만들어진 수많은 구성요소가 결합되어 있다.

System

├─ Workflow Engine
├─ Agent Framework
├─ Model
├─ Communication
├─ Observability
├─ Evaluation
├─ Storage
└─ UI

처음에는 원하는 시스템이 있으면 직접 구조를 만들고 구현해야 한다고 생각하기 쉽다.

하지만 실제로는 이미 잘 해결된 문제를 다시 구현하는 것보다 검증된 기술을 가져와 조합하는 것이 더 효율적인 경우가 많다.

여기에서 중요한 능력도 조금 달라지는 것 같다.

모든 것을 직접 구현하는 능력
        ↓

필요한 기능을 구분하는 능력
        +
이미 존재하는 기술을 찾는 능력
        +
적절한 기술을 선택하는 능력
        +
하나의 시스템으로 연결하는 능력

흔히 말하는 거인의 어깨 위에 선다는 것도 단순히 다른 사람의 코드를 가져다 쓰는 것이 아니라 이미 축적된 기술과 지식을 이해하고 그 위에서 더 높은 수준의 문제를 해결하는 것이라고 생각할 수 있을 것 같다.

이번 주 개념들을 하나로 연결해보기

이번 주에 배운 내용들을 다시 연결하면 처음에는 AWS 자동화와 멀티에이전트가 서로 다른 주제처럼 보였지만 구조적으로 비슷한 부분이 있었다.

GitHub Actions에서는 여러 작업을

인증
→ 인프라 구축
→ Build
→ 배포
→ 확인
→ 정리

라는 Workflow로 만든다.

멀티에이전트에서는 하나의 큰 작업을

작업 분석
↓
분리
↓
적절한 Agent에 할당
↓
실행
↓
결과 전달
↓
통합
↓
평가

하는 구조로 만든다.

둘 다 결국

큰 목표를 작은 실행 단위로 나누고 관계를 정의해서 전체가 하나의 작업처럼 동작하도록 만드는 것

이라고 볼 수 있다.

Goal
↓
Decomposition
↓
Tasks
↓
Dependency / Workflow
↓
Executor
↓
Execution
↓
Observation
↓
Merge / Evaluation
↓
Result

여기에서 Executor는 상황에 따라 달라질 수 있다.

사람
Tool
Script
GitHub Actions
AI Agent
다른 Service

즉 Workflow의 관점에서 보면 중요한 것은 누가 실행하느냐보다 먼저

무엇을 해야 하는가?
↓
어떻게 나눌 것인가?
↓
각 작업은 어떤 관계인가?
↓
누가 실행하는 것이 적절한가?

를 결정하는 것일 수도 있다.

이렇게 생각하면 이전에 공부했던 Agent, Workflow, CI/CD와 이번에 배우는 Multi-Agent도 완전히 별개의 개념이라기보다 작업을 구조화하고 적절한 실행 주체에게 위임하는 방법의 서로 다른 형태로 연결해서 볼 수 있을 것 같다.

그리고 실행 주체의 자율성이 높아질수록

명확한 목표
+
작업 경계
+
상태 관리
+
Trace
+
Evaluation
+
필요한 경우 사람의 개입

같은 관리 구조가 더 중요해진다.

결국 시스템이 복잡해질수록 중요한 것은 구성요소를 많이 추가하는 것이 아니라 어떤 책임을 어떤 구성요소에게 맡기고 서로 어떻게 연결할 것인지 명확하게 만드는 것이라고 생각한다.

2. 문제 및 개선

문제

1. 좋은 기술이 많아질수록 오히려 무엇을 선택해야 할지 어려워진다.

멀티에이전트를 조사하면서 Workflow, UI, Trace, Agent, A2A, Evaluation 등 각 영역마다 사용할 수 있는 기술이 많았다.

기능만 보면 모두 좋아 보이지만 모든 기술을 한 시스템에 넣으면 복잡도와 관리 비용만 증가할 수 있다.

2. 멀티에이전트를 사용하는 이유가 기술 자체가 되어서는 안 된다.

Agent를 여러 개 사용하거나 A2A 같은 기술을 적용하는 것이 흥미롭기는 하지만 실제 작업이 하나의 Agent로 충분히 해결된다면 굳이 시스템을 복잡하게 만들 필요는 없다.

새로운 기술을 사용하는 것과 문제를 더 잘 해결하는 것은 다른 문제인 것 같다.

3. 자동화나 AI에 많은 권한을 줄수록 실패했을 때의 영향도 커진다.

AWS처럼 실제 비용이나 리소스와 연결되는 환경에서는 잘못된 실행 하나가 바로 비용이나 장애로 이어질 수 있다.

작업을 자동화한다고 해서 검증 과정까지 없애서는 안 된다.

4. 계속 생각하고 비교하다 보니 실제로 시도하기 전에 너무 많은 경우를 고려하는 문제가 있다.

더 좋은 방법이나 실패 가능성을 계속 생각하면 결정을 내리는 것이 점점 어려워진다.

충분히 생각하는 것은 필요하지만 실제로 실행해보지 않으면 알 수 없는 것도 많다.

개선

1. 기술을 먼저 선택하기보다 필요한 역할을 먼저 정의한다.

필요한 역할
↓
필수 기능
↓
후보 기술 조사
↓
비용 / 복잡도 / 성능 비교
↓
가장 단순한 후보 선택

처음부터 많은 기술을 넣기보다 현재 시스템에서 실제로 필요한 기능부터 선택하는 것이 좋을 것 같다.

2. 멀티에이전트 적용 전에 작업의 분리 가능성을 먼저 확인한다.

하나의 Agent로 가능한가?
↓
YES → Single Agent

NO
↓
독립적으로 분리 가능한가?
↓
YES → Multi-Agent 검토

Agent의 수가 아니라 작업 구조를 기준으로 판단하는 것이 필요하다.

3. 위험이 큰 작업은 자동화의 범위와 검증 수준을 함께 높인다.

작업의 위험 평가
↓
권한 범위 결정
↓
실행 전 검증
↓
자동 실행
↓
실행 결과 확인
↓
필요하면 Rollback / Cleanup

특히 클라우드 인프라처럼 비용과 실제 리소스에 영향을 주는 작업은 생성뿐 아니라 제거와 실패 처리까지 하나의 Workflow에 포함하는 것이 좋을 것 같다.

4. 완벽한 계획보다 작은 이정표를 먼저 세우고 실행한다.

작은 목표
↓
시도
↓
결과 확인
↓
문제 발견
↓
다음 목표 수정

실패하지 않기 위해 모든 경우를 먼저 생각하기보다 복구 가능한 작은 범위에서는 직접 부딪혀보면서 배우는 것도 필요할 것 같다.

3. 소감

이번 주에는 GitHub Actions와 AWS를 이용해서 실제 인프라와 배포 과정을 자동화해보고 멀티에이전트 오케스트레이션을 배우면서 여러 실행 주체를 하나의 시스템으로 관리하는 방법을 생각해볼 수 있었다.

처음에는 AWS 자동화와 멀티에이전트가 서로 다른 내용이라고 생각했지만 다시 정리해보면 둘 다 큰 작업을 작은 단위로 나누고 각각의 실행 순서와 책임을 정의한다는 점에서 비슷한 부분이 있었다.

특히 멀티에이전트를 공부하면서 Agent를 많이 사용한다고 항상 좋은 것은 아니라는 점이 기억에 남는다.

Agent가 추가될 때마다 새로운 능력도 생길 수 있지만 그만큼 통신, 상태 관리, Trace, 결과 통합, 평가 같은 새로운 문제가 생긴다.

결국 시스템을 복잡하게 만드는 것은 쉽지만 그 복잡성이 실제로 필요한지를 판단하는 것이 더 어려운 문제인 것 같다.

기술 조사에서도 비슷한 생각을 했다.

이미 Workflow, Agent, Trace, Evaluation, UI 같은 각각의 문제를 잘 해결하는 기술들이 많이 존재하고 있다.

예전에는 무엇인가를 만들 때 직접 구현하는 부분을 먼저 생각했다면 이제는

이미 해결된 문제는 무엇인가? 내가 실제로 새롭게 해결해야 하는 문제는 무엇인가?

를 먼저 구분하는 것이 더 중요해 보인다.

기존 기술을 잘 활용한다면 모든 것을 처음부터 만들 필요 없이 더 높은 수준의 문제에 집중할 수 있다.

슬슬 거인의 어깨 위에서 보는 방법을 더 적극적으로 익혀야 할 것 같다.

개인적으로는 이번 주에도 어떻게 해야 할지 너무 오래 생각하는 경우가 있었다.

실패하지 않기 위해 더 좋은 방법을 찾는 것은 좋지만 어느 순간부터는 생각을 더 하는 것보다 직접 실행해보고 결과를 확인하는 것이 더 많은 정보를 줄 수도 있다.

지난주에 생각했던

예상
→ 실행
→ 관찰
→ Delta
→ 수정

도 결국 실행하지 않으면 뒤의 과정이 시작되지 않는다.

그래서 지금은 완벽한 방향을 처음부터 찾으려고 하기보다 작은 이정표를 정하고, 복구할 수 있는 범위에서는 직접 시도해보고, 실제 결과를 다음 판단에 사용하는 방식이 더 필요하다고 생각한다.

이번 주 내용을 한 문장으로 정리하면

모든 일을 하나의 주체가 잘하는 것보다, 일을 적절하게 나누고 이미 존재하는 능력을 연결해서 전체가 잘 동작하도록 만드는 것이 더 중요할 수 있다.

정도가 될 것 같다.

AI Agent뿐 아니라 사람, 자동화 도구, 기존 서비스까지 각각 잘하는 역할을 맡기고 이들을 하나의 목적을 향해 연결할 수 있다면 앞으로 만들 수 있는 시스템의 범위도 훨씬 넓어질 것 같다.

순서

1. 자원과 조건 정의
2. 결과 지표 정의
3. 관계 매핑 (1,2 요소)
4. 트레이드 오프 정의
5. 이후 트레이드 오프 관계 등을 이용해 자원 배분 설계

세부 사항 (예시)

1. Input (원시 자원과 제약) 시스템을 구성하고 유지하기 위해 투입하거나 감당해야 하는 물리적·구조적 원재료

컴퓨팅 파워 (Compute / CPU): 로직을 수행하고 연산을 처리하는 물리적 능력

저장 공간 (Storage Space): 데이터를 적재하는 물리적 용량 (메모리 RAM, 디스크 SSD/HDD)

저장소 계층 및 I/O 경로 (Storage Hierarchy): 데이터가 어디에 위치하며 어떤 물리적 경로를 거치는가 (RAM ➔ Local SSD ➔ Network DB). 지연 시간의 근본 원인

네트워크 (Network Bandwidth & Topology): 노드 간 데이터 이동 통로와 물리적 거리

시스템 복잡도 (Cognitive Load / Blast Radius): 미들웨어와 분산 노드가 늘어날 때 발생하는 인적 운영 제약 및 장애 전파 범위

2. Output (결과 지표) 자원의 배치와 흐름에 따라 최종적으로 측정되는 시스템의 성과 및 상태 지표

대기 시간 (Latency): 하나의 요청이 처리되거나 응답이 돌아오는 데 걸리는 절대적 시간

처리량 (Throughput): 단위 시간당 시스템이 소화할 수 있는 일의 총량 (TPS, QPS)

정합성 (Consistency): 분산된 데이터 간의 일치 여부와 신뢰도

가용성 (Availability): 시스템이 멈추지 않고 정상 응답을 제공하는 확률

3. 관계 매핑 (인과관계) 자원과 결과 사이에 작용하는 물리적·구조적 법칙

저장소 계층 ➔ 대기 시간: 데이터를 원격 네트워크 DB(느린 계층)에서 인메모리 캐시(빠른 계층)로 옮길수록 I/O 대기 시간이 사라져 Latency가 극적으로 단축

동기화 ➔ 처리량/대기 시간: 모든 노드가 완벽한 정합성을 맞출 때까지 락을 잡고 대기(Blocking)하면, Throughput은 바닥을 치고 Latency는 치솟습니다. 반대로 이벤트를 비동기 큐로 흐르게 두면 처리량은 늘어나지만 일시적 정합성이 깨짐

분산/미들웨어 ➔ 복잡도: 단일 서버의 한계를 넘어 스케일 아웃과 미들웨어를 붙일수록 처리량의 한계는 늘어나지만, 시스템 복잡도와 장애 반경이 폭발적으로 증가

4. 트레이드오프 (최종 선택의 경계) 인과관계 속에서 피할 수 없는 '교환 비율'이자 아키텍트의 의사결정 영역

공간과 복잡도를 지불하여 시간을 살 것인가? (예: 캐싱과 비동기 큐 도입 ➔ 속도 확보 vs 데이터 불일치 및 운영 복잡도 감수)

처리량을 포기하고 정합성을 지킬 것인가? (예: 엄격한 트랜잭션 락 ➔ 데이터 안전성 확보 vs 트래픽 병목 감수)

유연성을 버리고 단순성(Scale-up)을 택할 것인가? (예: 복잡한 MSA 대신 고성능 단일 서버 ➔ 구조적 깨끗함 확보 vs 물리적 확장 한계 감수)

이후 설계

시스템의 목적과 목표, 사용자 예상 시나리오, 실제 비용과 책임 및 감당 가능한 범위 등을 고려하여 자원 배분의 최적화 설계를 한다.

1. 배운 내용

멀티 에이전트

이전에 배운 개념을 실습용 프로젝트로 살펴보았다. 멀티 에이전트를 활용하는 여러 가지 워크플로우 패턴들을 확인했다.

2. 실제 작업한 내용

멀티 에이전트 활용을 위한 기술 조사

경량 오픈 소스 모델들의 성능이나 활용도에 대한 것과 멀티 에이전트를 만들기 위한 여러 기술들을 조사했다. 워크플로우, UI, 트레이스, A2A, 평가, 에이전트 등 각 컴포넌트마다 적용해볼만한 기술들을 결정하고 있다.

3. 소감

지금 사용되는 기술이나 물건 등을 보면 그 안에는 여러 요소들이 복합적으로 결합되어서 만들어져 있다는 걸 알 수 있다. 슬슬 거인의 어깨 위에 서서 볼 때가 되고 있는 것 같다.

1. 배운 내용

멀티 에이전트 오케스트레이션

싱글과 멀티 에이전트 간의 비교와 언제 멀티 에이전트 오케스트레이션으로 시스템을 만들면 좋을 지에 대한 기준 그리고 멀티 에이전트 오케스트레이션에 워크플로우 패턴, 필요한 기술들을 배웠다. 즉, 멀티 에이전트를 사용하는 데 고려할 것은 작업의 크기와 분리 가능성이다. 그리고 오케스트레이션을 하기 위해서는 관리하는 작업이 추가로 발생한다. 워크플로우 패턴은 기본적인 패턴과 이를 조합하여 복잡하게 만들 수 있지만 결국 그래프로 모두 표현 가능한 패턴들이다. 유명한 패턴들로는 체인, 라우터, 병렬, 병합, 평가 피드백 등이 있다.

2. 실제 작업한 내용

실습

멀티 에이전트에 대한 간단한 패턴들을 확인해 보았다.

3. 소감

자신을 되돌아보면서 어떻게 해야 할까 고민하는 시간이 많아지는 것 같은데 조금이라도 이정표를 세워서 차근차근 해나가는 것이 필요한 것 같다. 생각해보면 간단한데 너무 어렵게 생각하고 실패에 대한 두려움 때문에 망설이는 마음들이 많은 것 같아서 부딪혀 보는 것도 시도해봐야 겠다.

1. 배운 내용

github action

github action으로 인증 설정을 하면 AWS 서버에 배포까지 가능하다.

2. 실제 작업한 내용

AWS와 github action

ssh 없이 AWS OIDC로 인증하여 인프라(DB - RDS PostgreSQL, redis - ElastiCache Redis, ECR, SSM, IAM, 네트워크, cloudformation 등)dmf 구축하고 CI와 이미지 빌드, ECR로 이미지 업로드, EC2 시작과 SSM 등록, SSM으로 배포 흐름으로 github action이 동작한다. AWS는 유지만으로도 비용이 들기 때문에 비용 최소화를 위해 역순으로 제거하는 흐름도 만들었다.

3. 소감

코덱스를 이용해서 AWS 설정과 조회, 생성, 삭제 등을 모두 진행해 봤는데 방향만 잘 설정해주면 작업을 잘 완료하는 것 같다. 다만 당연한 이야기지만 더 자세히 방향을 정해주면 더 빠르고 정확하게 처리해서 비용이나 리스크가 크다면 검증 절차를 좀 더 거치도록 하면 될 것 같다.

1. 배움 정리

코드가 실행되는 것에서 시스템이 유지되는 것까지

이번 주에는 Docker를 이용한 배포를 다시 연습하고 GitHub Actions, AWS를 이용해서 실제 서버에 프로젝트를 배포하는 과정을 배웠다.

처음에는 각각 별개의 기술처럼 느껴졌지만 전체적인 흐름으로 연결하면 하나의 프로젝트가 개발자의 로컬 환경을 벗어나 실제로 실행 가능한 시스템이 되는 과정이라고 볼 수 있을 것 같다.

Source Code
↓
Build / Test
↓
Docker Image
↓
Registry
↓
AWS Server
↓
Container 실행
↓
사용자가 접근 가능한 서비스

Docker를 이용하면 애플리케이션과 실행에 필요한 런타임, 라이브러리 등의 의존성을 이미지 형태로 묶어서 비교적 일관된 환경에서 실행할 수 있다.

환경별 설정이나 Secret처럼 실행 환경에 따라 달라지는 값은 이미지 자체에 모두 포함하기보다 환경 변수나 외부 설정 등을 통해 실행 시점에 주입할 수도 있다.

Application
+
Runtime
+
Dependency
        ↓
   Docker Image

환경별 Configuration / Secret
        ↓
   Runtime에 주입

Registry를 이용하면 만들어진 이미지를 다른 환경으로 전달할 수 있고, AWS에서는 EC2 인스턴스를 생성하고 SSH를 통해 서버에 접근해서 Docker 이미지를 실행했다.

마지막에는 하나의 서버에서 실행하는 것에서 더 확장해서 서로 다른 AWS 인스턴스가 연결되어 하나의 시스템으로 동작하는 것도 실습했다.

이를 보면 배포도 단순하게 프로그램을 서버에 올리는 작업이라기보다

코드
→ 재현 가능한 실행 환경
→ 원격 서버
→ 여러 실행 주체의 연결

로 점점 범위가 확장되는 과정이라고 생각할 수 있을 것 같다.

반복되는 작업을 자동화하기

직접 Docker 이미지를 만들고 Registry에 올리고 서버에서 다시 받아 실행하는 과정을 반복하면서 왜 CI/CD가 필요한지도 조금 더 명확하게 이해할 수 있었다.

사람이 직접 하면

코드 수정
↓
테스트
↓
이미지 생성
↓
이미지 Push
↓
서버 접속
↓
새로운 이미지 적용
↓
실행 확인

을 계속 반복해야 한다.

GitHub Actions를 이용하면 코드가 변경되는 것을 기준으로 테스트나 빌드 같은 작업을 자동화할 수 있고, 필요하다면 배포까지 자동화할 수도 있다.

CI/CD를 조금 더 넓게 보면 개발 결과를 지속적으로 검증하고 실제 실행 환경까지 안정적으로 전달하기 위한 과정이라고 볼 수 있을 것 같다.

여기에 GitOps 방식을 사용하는 경우에는 예를 들어

Git
↓
GitHub Actions
Build / Test
↓
Container Registry
↓
GitOps Repository
↓
Argo CD / Flux
↓
Kubernetes

처럼 구성할 수도 있다.

GitHub Actions가 코드의 빌드와 테스트 같은 CI 작업을 담당하고, GitOps에서는 Git에 기록된 원하는 상태를 기준으로 Argo CD나 Flux 같은 도구가 실제 Kubernetes 환경과 동기화하도록 만들 수 있다.

Kubernetes도 선언된 원하는 상태와 현재 상태의 차이를 확인하고 Controller를 통해 그 차이를 줄이는 방향으로 동작한다.

그래서 단순히 "자동으로 배포한다"보다 더 넓게 보면

원하는 실행 상태를 정의하고 실제 시스템이 그 상태에 가까워지도록 지속적으로 관리한다

는 구조가 있다는 점이 흥미로웠다.

원하는 상태와 실제 상태의 차이

GitOps와 Kubernetes에 대해 찾아보면서 개인적으로 생각하고 있던 하네스 구조와 비슷한 부분이 있다는 생각이 들었다.

최근 사람과 AI 모델이 얼마나 정렬되어 있는지를 확인하기 위한 간단한 구조로

예측
→ 실행
→ 관찰
→ Delta

를 생각하고 있었다.

내가 예상한 결과와 실제 AI가 만든 결과를 비교하고 둘 사이의 차이를 기록하는 방식이다.

Kubernetes의 Control Loop는 정확히 같은 구조는 아니지만 더 추상적으로 보면 비슷한 특징을 가지고 있다.

Desired State
      ↓
Current State 관찰
      ↓
차이 확인
      ↓
Reconciliation
      ↓
다시 관찰
      ↺

Kubernetes에는 내가 생각한 구조의 Prediction 단계가 따로 존재하는 것은 아니지만, 둘 다 목표와 현재 상태의 차이를 관찰하고 그 차이를 줄이는 방향으로 다음 행동을 조정한다는 공통점이 있다.

이를 조금 더 일반화하면

목표
↓
행동
↓
관찰
↓
차이 확인
↓
수정
↓
다시 행동

과 같은 Closed-loop Feedback 구조로 볼 수 있을 것 같다.

내가 생각한 AI 협업에서는 여기에 실행 전에 결과를 예상하는 Prediction을 추가한 형태다.

Goal
↓
Prediction
↓
Action
↓
Observation
↓
Delta
↓
Update
↺

처음에는 AI와 사람의 정렬을 확인하기 위한 단순한 실험으로 생각했지만, 더 일반적으로 보면 Agent나 운영 시스템에서도 비슷한 피드백 구조를 찾을 수 있을 것 같다.

관찰할 수 있어야 개선할 수 있다

목표 상태와 현재 상태의 차이를 확인하려면 먼저 현재 시스템에서 어떤 일이 일어나고 있는지 알아야 한다.

여기에서 배포 자동화와 별도로 운영 중인 시스템을 관찰하는 Observability가 중요해진다.

CI/CD가 변경된 코드를 검증하고 실행 환경까지 전달하는 과정이라면 Observability는 그 결과로 실행되고 있는 시스템이 실제로 어떻게 동작하는지를 확인하는 역할에 가깝다.

CI / CD
변경 사항 검증 및 전달
        ↓
Runtime System
        ↓
Observability
Metrics / Logs / Traces
        ↓
현재 상태 파악
        ↓
문제 판단
        ↓
다음 변경과 개선

Metrics, Logs, Traces는 Observability를 가능하게 하는 대표적인 정보라고 볼 수 있다.

이전에 Agent를 배우면서 Trace가 중요하다고 생각했던 것도 비슷한 이유였다.

최종 결과만 보면 어떤 과정에서 문제가 생겼는지 알기 어렵다.

시스템에서도 단순히 서비스가 실행되는지만 확인하는 것보다 어떤 상태이고 어떤 변화가 발생했는지를 확인할 수 있어야 문제를 수정할 수 있다.

이렇게 보면 이전에 배운 Agent의 Trace와 시스템의 Observability는 완전히 같은 개념은 아니지만

내부에서 일어난 일을 외부에서 판단할 수 있는 정보로 만드는 것

이라는 공통 역할을 가지고 있다고 볼 수 있을 것 같다.

Context와 공유된 전제

이번 주에 기술적인 내용과 별개로 계속 생각하게 된 것이 Context였다.

알고 있는 개념을 다른 사람에게 설명했는데 생각보다 잘 전달되지 않는 경우가 있었다.

처음에는 단순히 설명 방법의 문제라고 생각했지만, 내가 상대도 알고 있을 것이라고 생각한 정보와 실제 상대가 가지고 있는 정보가 다를 수 있다는 점이 더 중요할 수도 있다는 생각이 들었다.

예를 들어 내가 어떤 개념을

A → B → C

라는 흐름으로 이해하고 있다고 해보자.

나는 상대도 이미 A → B까지는 알고 있다고 생각해서 C만 설명할 수 있다.

내가 예상한 상대의 Context

A → B

하지만 실제로 상대가 알고 있는 것이 A뿐이라면

실제 상대의 Context

A

내가 C만 전달했을 때 상대에게는

A → ? → C

처럼 중간 연결이 없는 상태가 된다.

결국 문제는 단순히 내가 설명을 짧게 했다는 것이 아니라 내가 공유되어 있다고 가정한 전제와 실제로 공유된 Context가 달랐다는 것이다.

AI와 대화할 때도 비슷한 문제가 생길 수 있다.

내 머릿속에서는

프로젝트 목표
↓
이전에 정한 설계 원칙
↓
현재까지의 작업
↓
이번 요청

이 하나의 흐름으로 연결되어 있을 수 있다.

그래서 나는 이전 내용이 충분히 공유되어 있다고 생각하고

"이제 다음 모듈을 구현해줘"

라고만 요청할 수 있다.

하지만 실제 모델의 Context에 이전 설계 원칙이나 결정 과정이 충분히 들어 있지 않다면

프로젝트 목표
↓
?
↓
?
↓
이번 요청

과 같은 상태가 된다.

그러면 모델은 빠진 부분을 현재 Context와 학습된 지식을 이용해 추론해서 채우게 되고, 그 결과 내가 예상한 방향과 다른 결과가 나올 수 있다.

사용자가 전제한 Context

A → B → C → 요청


모델이 실제로 가진 Context

A → ? → ? → 요청
        ↓
누락된 부분을 추론
        ↓
예상과 다른 결과

이렇게 보면 좋은 Context 관리는 단순히 정보를 많이 넣는 문제가 아니라

무엇이 이미 공유되어 있는가
+
무엇이 공유되어 있다고 내가 가정하고 있는가
+
현재 판단에 실제로 필요한 정보는 무엇인가

를 구분하는 문제에 더 가까운 것 같다.

모든 정보를 항상 전달하는 것은 현실적으로 어렵기 때문에 중요한 전제를 명시하고, 결과를 통해 서로의 이해가 맞는지 확인하면서 필요한 Context를 다시 보완하는 과정이 필요하다.

결국 Context 관리도 공유됐다고 예상한 정보와 실제로 공유된 정보 사이의 차이를 줄이는 과정이라고 생각할 수 있을 것 같다.

이번 주 개념들을 하나로 연결해보기

이번 주에 배운 내용과 개인적으로 고민한 것을 다시 합쳐보면 여러 영역에서 비슷한 구조가 반복되고 있었다.

소프트웨어 배포에서는

Code
↓
CI
↓
Artifact
↓
Deployment
↓
Runtime
↓
Observation
↓
Feedback

GitOps와 Kubernetes에서는

Desired State
↓
Current State 관찰
↓
Delta
↓
Reconciliation
↓
다시 관찰

AI와 사람의 협업에서는

Intent / Goal
↓
Prediction
↓
AI Execution
↓
Result Observation
↓
Delta
↓
Adjustment

사람 사이의 의사소통에서도 조금 다르게 보면

전달하려는 의미
↓
표현
↓
상대가 해석한 의미
↓
반응
↓
차이 확인
↓
설명 수정

과 같은 구조를 생각해볼 수 있다.

물론 각각은 목적과 동작 방식이 다른 시스템이고 완전히 같은 구조라고 할 수는 없다.

다만 더 높은 수준에서 보면

원하는 상태가 있고, 어떤 행동의 결과를 관찰한 뒤 차이가 있다면 다음 행동을 수정한다

는 피드백 구조가 반복되고 있다는 점이 흥미롭다.

그래서 현재 AI와의 협업에서 사용할 가장 작은 구조를

Goal
↓
Prediction
↓
Action
↓
Observation
↓
Delta
↓
Update
↺

정도로 생각하고 있다.

중요한 것은 단순히 루프가 있다는 것이 아니라 무엇을 Goal로 정의할지, 무엇을 예측하고 관찰할지, 어떤 차이를 중요한 Delta로 볼지를 결정하는 것이다.

목표가 달라지면 같은 행동이라도 평가 기준이 달라질 수 있고, 하나의 행동에도 비용, 시간, 정확도, 안정성처럼 여러 목적이 동시에 존재할 수 있다.

Context 역시 비슷하다.

공유됐다고 예상한 Context
vs
실제로 공유된 Context
        ↓
차이 확인
        ↓
필요한 정보 보완

처럼 생각하면 결과의 차이뿐 아니라 판단에 사용된 정보의 차이도 관찰하고 수정해야 하는 대상이 될 수 있다.

결국 좋은 시스템을 만들려면 실행 구조뿐 아니라 목표, 관찰 기준, 그리고 판단에 필요한 Context를 명확하게 만드는 것도 필요할 것 같다.

2. 문제 및 개선

문제

1. 하네스의 전체 구조를 생각할수록 무엇부터 만들어야 할지 불분명해진다.

필요한 기능을 생각하면 Context 관리, Memory, 실행 관리, 평가, 기록, 피드백 등 계속 새로운 요소가 추가된다.

모든 것을 먼저 설계하고 구현하려고 하면 실제로 동작하는 것을 만들기 전에 구조만 계속 커질 가능성이 있다.

2. 인프라 기술들이 서로 다른 개념처럼 보여 전체 구조를 익히는 데 시간이 필요하다.

Docker, GitHub Actions, AWS, GitOps, Kubernetes, Observability는 각각 다른 역할과 개념을 가지고 있다.

각 기술의 사용법만 따라가면 무엇을 해결하기 위해 존재하는지 놓치기 쉬운 것 같다.

3. 예측과 관찰 사이에서 무엇을 비교해야 하는지가 아직 명확하지 않다.

예측–실행–관찰–델타 루프 자체는 단순하지만 실제로 사용하려면 어떤 값을 예측하고 어떤 차이를 기록할지 정의해야 한다.

하나의 작업에도 품질, 시간, 비용, 안정성 등 여러 목적이 존재할 수 있기 때문에 Delta도 하나의 값으로 표현하기 어려울 수 있다.

4. 공유된 Context의 차이를 정확하게 파악하기 어렵다.

내가 상대나 AI가 알고 있을 것이라고 생각하는 정보와 실제로 상대가 가지고 있는 정보가 다를 수 있다.

하지만 상대가 어떤 전제를 가지고 있는지 완전히 알 수 없기 때문에 이 차이를 처음부터 정확하게 파악하는 것은 어렵다.

개선

1. 완전한 하네스를 먼저 만들기보다 가장 작은 피드백 루프부터 실제로 사용해본다.

목표
→ 예상 기록
→ AI 실행
→ 결과 관찰
→ 차이 기록

이 정도의 작은 구조부터 반복적으로 사용하고 실제 문제가 발생하는 지점에 필요한 모듈을 추가하는 방식으로 진행하는 것이 좋을 것 같다.

2. 새로운 기술을 배울 때 제품 이름보다 역할을 먼저 본다.

GitHub Actions
→ 자동 검증 / 실행

Docker
→ 실행 환경 패키징

Registry
→ Artifact 저장 / 전달

AWS
→ 실행 인프라

Kubernetes
→ 선언된 실행 상태 관리

Observability
→ 실제 동작과 상태를 관찰할 수 있게 하는 정보 제공

처럼 역할을 먼저 이해하면 새로운 기술이 나와도 기존 구조에서 어디에 들어가는지 판단하기 쉬울 것 같다.

3. Delta를 하나의 점수로 만들기보다 목적별로 분리해본다.

Expected
vs
Actual

├─ 품질 차이
├─ 시간 차이
├─ 비용 차이
├─ 과정 차이
└─ 위험 차이

각 작업에서 중요한 항목만 선택하고 반복하면서 실제로 필요한 평가 기준을 찾아가는 것이 좋을 것 같다.

4. Context를 완벽하게 맞추려고 하기보다 중요한 전제를 확인할 수 있는 구조를 만든다.

상대나 AI가 무엇을 알고 있는지 완전히 파악할 수는 없기 때문에 중요한 전제는 명시하고, 중간 결과나 반응을 통해 서로의 이해가 맞는지 확인하는 것이 현실적인 방법일 것 같다.

중요한 전제 전달
↓
실행 / 설명
↓
상대의 결과 또는 반응 관찰
↓
예상과 다른 부분 확인
↓
누락된 Context 보완

결과의 차이뿐 아니라 왜 그런 차이가 발생했는지 Context 수준에서도 확인하는 과정을 반복해볼 수 있을 것 같다.

3. 소감

이번 주는 지난주보다 새로운 개념을 많이 배우기보다는 Docker와 AWS를 반복해서 사용하면서 실제 배포 과정에 조금 익숙해지는 시간이었던 것 같다.

처음에는 Docker, GitHub Actions, AWS, Kubernetes가 각각 별개의 기술처럼 느껴졌는데 전체 흐름을 다시 생각해보니 코드에서 실제 서비스까지 이어지는 과정에서 서로 다른 역할을 담당하고 있다는 것이 조금씩 보이기 시작했다.

특히 Kubernetes의 Desired State와 현재 상태를 비교하고 차이를 줄이는 구조를 보면서 개인적으로 생각하고 있던 예측–실행–관찰–델타 구조와 공통점이 있다는 것이 흥미로웠다.

두 구조가 완전히 같은 것은 아니지만 목표와 실제 상태의 차이를 관찰하고 다음 행동을 수정하는 피드백 구조라는 점에서는 연결해서 생각해볼 수 있었다.

최근 하네스를 설계하면서 너무 많은 요소를 먼저 생각하다 보니 오히려 무엇부터 만들어야 하는지 애매해지는 문제가 있었다.

지금은 완성된 구조를 먼저 만들기보다

예상을 걸고 → 실행하고 → 관찰하고 → 차이를 기록한다

는 가장 작은 루프부터 실제로 사용해보는 것이 더 중요할 것 같다.

실패나 차이가 반복해서 발생하면 그때 필요한 Context 관리나 평가, 기록 같은 기능을 추가할 수 있다.

그렇게 만들어진 시스템이라면 처음부터 내가 생각한 구조를 강제로 구현하는 것보다 실제 경험을 통해 필요한 구조가 점점 생겨날 수 있다.

궁극적으로는 시스템이 단순히 이전 기록을 저장하는 것을 넘어

경험
↓
관찰
↓
차이
↓
패턴
↓
다음 판단의 개선

처럼 자신의 실행 경험을 다음 작업에 활용할 수 있었으면 좋겠다.

사람이나 AI와의 상호작용에서도 비슷한 생각을 했다.

나는 내가 알고 있는 내용이나 이전에 설명한 내용이 상대에게도 충분히 공유되어 있다고 생각하기 쉽다.

하지만 실제로는 내가 전제로 하는 Context와 상대가 가지고 있는 Context 사이에 빈 부분이 있을 수 있고, 그 차이 때문에 같은 요청이나 설명도 다르게 해석될 수 있다.

결국 모든 정보를 처음부터 완벽하게 공유하는 것은 현실적으로 어렵다.

그래서 더 중요한 것은 어떤 정보가 공유되어 있다고 내가 가정하고 있는지를 의식하고, 예상과 다른 결과가 나왔을 때 결과 자체뿐 아니라 Context의 차이도 다시 확인하는 것일 수 있을 것 같다.

기술적인 시스템과 사람의 판단은 많이 다르지만, 적어도 지금 나에게는

한 번에 완벽한 답을 만드는 것보다 관찰하고 차이를 확인한 뒤 수정할 수 있는 구조를 만드는 것

이 계속 반복해서 나타나는 중요한 기준인 것 같다.

1. 내가 계속 찾고 있는 것

A. 불변량

기술이나 구조가 바뀌어도 계속 필요한 조건은 무엇인가?

확인:

• 이 원리는 특정 모델이나 프레임워크에 의존하는가?
• 구조를 바꿔도 여전히 필요한가?
• 여러 문제에서도 반복해서 나타나는가?
• 단순한 패턴이 아니라 반드시 지켜져야 하는 조건인가?

원칙:

설계를 고정하지 말고, 변화 속에서도 살아남는 것만 핵심으로 남긴다.

B. 사람-AI 의도 정렬

내가 원하는 방향을 AI가 얼마나 정확하게 이해하고 있는가?

작업 전에 최소한 확인:

• 나는 무엇을 바꾸고 싶은가?
• 어떤 방향이 더 중요한가?
• 무엇은 절대 깨지면 안 되는가?
• 무엇은 아직 결정하지 않았는가?
• 어떤 상태면 성공인가?
• 어디까지 AI가 자율적으로 판단해도 되는가?

AI가 엇나갔을 때 확인:

• 목표를 잘못 이해했는가?
• 조건이 빠졌는가?
• 잘못된 가정을 했는가?
• 추상화 수준이 잘못됐는가?
• 내 판단 기준이 전달되지 않았는가?

원칙:

결과만 수정하지 말고, 왜 의도가 어긋났는지를 찾는다.

C. 실제 협업 시스템

현재 나와 AI의 협업에서 반복되는 비용을 줄이고 있는가?

자동화 후보:

• 같은 배경을 반복 설명한다 → Context / State
• 이전 결정을 잊는다 → Decision History
• 매번 비슷한 추론을 반복한다 → Pattern / Skill
• AI 결과를 계속 직접 확인한다 → Validator
• 질문이 너무 많다 → Escalation Policy
• 프로젝트가 커지면 맥락이 깨진다 → Projection / Retrieval
• 같은 실패가 반복된다 → Experience / Delta 기록

원칙:

미래를 상상해 기능을 만들기보다, 현재 반복해서 발생하는 문제부터 시스템에 흡수한다.

작업 중 가장 중요한 루프

실제 작업
→ 의도 전달
→ AI 실행
→ 결과 관찰
→ 예상과 실제의 차이 확인
→ 교정
→ 원인 기록
→ 반복되면 시스템화
→ 여러 상황에서도 남으면 불변량 후보

교정이 발생했을 때 반드시 볼 것

AI의 해석
≠
내 실제 의도

이 순간이 가장 중요한 데이터다.

질문:

1. 무엇이 달랐는가?
2. 왜 그렇게 해석했을까?
3. 다음에는 어떤 정보가 있으면 피할 수 있는가?
4. 이번 교정은 개인 취향인가?
5. 아니면 다른 작업에도 적용되는 일반 원칙인가?
6. 반복된다면 시스템이 대신 처리할 수 있는가?

Pattern과 Invariant를 구분하기

예:

Pattern
Fast Path / Slow Path

Invariant
검증된 해결에는 반복 추론을 최소화한다.

Pattern
Pattern Manager

Invariant
검증되지 않은 경험은 안정된 능력으로 승격하지 않는다.

Pattern
Work Model

Invariant
실행자는 현재 작업에 필요한 목표·상태·제약을 알아야 한다.

기억할 것:

구현 형태가 사라져도 의미가 남는다면 불변량 후보에 가깝다.

새로운 개념이 애매할 때 사용할 질문

1. 이것은 대상인가?
2. 과정인가?
3. 관계인가?
4. 조건이나 규칙인가?
5. 하나의 단어에 여러 개념이 섞였는가?
6. 관찰하거나 검증할 수 있는가?

전부 사용할 필요는 없다.

말이 자꾸 미끄러지거나 설계가 모호해질 때만 사용한다.

시스템을 수정할 때 판단 기준

새 기능을 추가하기 전에:

실제 반복 문제인가?
        │
   아니오 ─→ 만들지 않음
        │
       예
        ↓
기존 구조로 해결 가능한가?
        │
       예 ─→ 기존 구조 개선
        │
      아니오
        ↓
최소 기능 추가
        ↓
실제 작업에서 검증

원칙:

가설 때문에 구조를 키우지 않는다.

실험의 목적 구분

System Experiment

이 기능이 실제 협업을 더 잘하게 만드는가?

Alignment Experiment

내 의도를 AI가 어디서 잘못 이해하는가?

Invariant Experiment

조건과 구조를 바꿔도 이 원리가 여전히 필요한가?

가능하면 하나의 실제 작업에서 세 가지를 동시에 관찰한다.

주기적으로 확인할 질문

• 최근 AI와 가장 많이 엇나간 지점은?
• 내가 반복해서 설명한 것은?
• 내가 반복해서 교정한 것은?
• 시스템이 대신 기억하거나 판단할 수 있었던 것은?
• 최근 설계 변경에도 살아남은 원리는?
• 불변량이라 생각했지만 깨진 것은?
• 반복 추론 중 Pattern/Skill로 바꿀 수 있는 것은?
• 내가 직접 판단해야 할 부분과 AI에게 맡길 부분의 경계는 적절한가?

최종 방향

불변량 탐색
+
사람-AI 의도 정렬 능력 향상
+
실제 협업 비용 감소

이 세 가지를 별도 프로젝트로 만들지 않는다.

AI를 실제로 사용한다
        ↓
엇나감과 성공을 관찰한다
        ↓
정렬 능력이 좋아진다
        ↓
반복 문제를 시스템이 흡수한다
        ↓
설계가 계속 변한다
        ↓
끝까지 살아남는 불변량을 찾는다

가장 중요한 한 문장

미래의 시스템을 미리 완성하려 하지 말고, 실제 AI와 계속 협업하면서 변화는 허용하되 반복해서 살아남는 원리만 핵심으로 남긴다.

1. 배운 내용

AWS 서버

하나의 인스턴스에서 확장하여 여러 개의 인스턴스가 결합하여 동작하는 시스템을 구축했다. 즉, AWS 인스턴스 간의 연결도 고려하여 배포하는 연습을 했다.

github action

github action으로 인한 CI/CD 자동화를 복습했다.

2. 실제 작업한 내용

AWS 서버

팀원들 간 다른 AWS 인스턴스들을 연결하여 시스템이 동작하는 실습을 했다.

3. 소감

이번 주는 복습이 상대적으로 많은 주간이었던 것 같다. 개인적으로 설계하는 거에 많은 생각을 했던 것 같다. 사람들의 관계에 대해서도 조금 더 알아가고 배워가는 시간을 가진 것 같다. 특별히 정보의 비대칭성과 특정 정보를 인지하고 있는 정보 또한 중요한 것 같다. 다만 이걸 모두 고려하고 행동하는 건 불가능에 가깝기 때문에 항상 내가 잘못할 수 있다는 걸 인정할 수 있는 태도가 중요한 것 같다.

1. 배운 내용

복습

도커와 AWS를 이용해서 AWS 서버에 도커를 설치하고 이미지를 받아서 배포하는 작업을 했다.

2. 실제 작업한 내용

CI/CD 개념 학습

CI/CD에 이미 표준과 같은 흐름들이 자리 잡은 것들이 있다. CI를 github action으로 처리하고 쿠버네티스(그 사이에 GitOps CD 구성)로 CD를 완성하는 구조가 가장 표준의 흐름처럼 보인다. 쿠버네티스는 상태 기계와 피드백 루프가 핵심이며 항상 목표한 상태를 유지하는 목적으로 CD를 담당한다. 이 목적에 맞게 쿠버네티스의 핵심 기능들을 플러그 인해서 사용하는 생태계가 갖추어 있는 것 같다.

정리하면 [ 1. 소스 코드 관리 (SCM) ] • Git / GitHub / GitLab │ ▼ (Code Push / PR) [ 2. 지속적 통합 (CI: Continuous Integration) ] • 빌드 및 테스트 자동화: GitHub Actions / GitLab CI / Jenkins • 아티팩트 저장소 (Registry): Docker Hub / AWS ECR / GitHub Packages │ ▼ (Container Image Push) [ 3. 배포 선언 및 형상 관리 (GitOps / CD 구성) ] • 선언적 설정 저장소: Git (Manifest Repository) • 동기화 엔진: Argo CD / Flux CD │ ▼ (Desired State Sync) [ 4. 지속적 배포 및 운영 (CD: Continuous Deployment) ] • 오케스트레이션 엔진: Kubernetes (K8s) • 런타임 및 인프라: containerd / CNI (Calico/Cilium) / CSI (Persistent Storage) │ ▼ (Feedback Loop) [ 5. 관측 가능성 (Observability & Monitoring) ] • 메트릭/로그/트레이싱: Prometheus / Grafana / OpenTelemetry

이런 흐름이고 여기에 최근에는 AI가 더해져서 "경험적"으로 안전한 흐름을 자동적으로 구축하고 관리하는 시스템이 되어 가고 있는 것 같다.

3. 소감

개발과는 다른 개념이고 기반 지식들이 어느 정도 필요해서 적응이 조금 느린 분들이 있는 것 같다. 공부를 하면서 "예측-관찰"의 차이를 결정하는 것 또한 목적과 관련되어 있고 행동자체도 목적이 여러 개가 있는 걸 분리할 수 있었는데 이를 어떻게 설계하면 좋을 지에 대해서 아직 더 정리가 필요할 것 같다.

1. 배운 내용

AWS 설정

제공 받은 AWS 계정으로 로그인하고 EC2 서비스 인스턴스를 만들고 활용하고 종료(제거)까지의 흐름을 배웠다. AWS 서버를 이용하기 위해서 ssh를 활용했고 파일 전송이 필요한 경우 scp를 활용했다.

2. 실제 작업한 내용

AWS 서버 활용

미리 작업해둔 도커 이미지를 AWS에 설치해서 컨테이너로 동작할 수 있도록 했다. AWS 서버에서 필요한 패키지를 설치하고 이미지 받고 컨테이너로 실행해서 실제 AWS 서버로 접속되는 지 확인이 가능했다.

AWS 보안 설정

AWS 계정으로 할 수 있는 범위가 많으니 MFA(Multi-Factor Authentication, 다중 요소 인증) 설정을 해두었다. 즉, 아이디, 비밀번호로만 인증하는 게 아니라 여러 요소들이 한 번에 있을 때 인증되는 걸 설정한 것이다. 예를 들어 USB에 키를 담아서 USB가 있어야만 인증이 되도록 하거나 휴대폰에 담아 휴대폰이 있어야만 인증이 되게 할 수도 있다.

3. 소감

AWS 말로만 들었는데 실제 해보니 생각보다 어렵지는 않았다. 조금 UI가 마음에 들지는 않지만 서버 설정을 할 게 많은 것을 고려하면 나쁘지 않은 정도였던 것 같다. 알고 있는 개념을 전달하려고 하는데 잘 전달되지 않은데 그 사람이 어떻게 사고하는 지를 파악하는 능력이 필요할 것 같다는 생각이 들었다. 근데 실제로 어떻게 파악해야 하는 지는 아직 모르겠다. 작업을 하면서 느낀 것들은 컨텍스트 관리가 필수라는 것이다.

1. 배운 내용

깃허브 CI/CD

.github를 이용하면 깃허브에서 제공하는 actions으로 CI/CD를 자동적으로 할 수 있다. 즉, 통합, 배포에 관한 테스트를 모두 깃허브에서 진행하는 것이다.

2. 실제 작업한 내용

도커 활용한 배포

이전에 배운 도커를 활용한 배포 실습을 여러 번 연습했다. 즉, 완성된 프로젝트 기준으로 로컬 테스트 -> 컴포즈를 이용한 이미지 생성, 도커 허브에 푸시 -> 사용자 입장에서 컴포즈를 이용한 이미지 풀 -> 조립 및 실행 하는 흐름들을 계속 연습했다.

3. 소감

하네스 관해서 생각하고 고민하다가 사람과 인공지능 모델의 정렬에 대해서 생각을 하다가 간단한 예측-실행-관찰-델타 루프(모델)가 나에게 중요한 역할을 할 거라는 느낌이 들었다. 이를 실험해서 앞으로 아이디어를 확장하는 식으로 하면 될 것 같다.

1. 배운 내용

도커를 이용한 배포

저번 주 금요일에 했던 내용을 복습했다. 즉, 프로젝트를 사용자가 편하게 실행할 수 있도록 이미지로 만들고 도커 허브에 올리고 사용자는 도커 컴포즈를 통해 간단한 명령어로 이미지를 받고 조립하여 테스트 또는 실행할 수 있는 상태가 된다.

2. 실제 작업한 내용

도커를 이용한 배포

프로젝트를 도커를 이용해서 이미지 배포와 사용자 입장에서 실행하는 것까지 실습을 했다.

3. 소감

많은 사람들이 생각보다 도커를 활용해서 이미지를 배포하고 테스트하는데 어려움을 겪었다. 하네스를 만들기 위해서 전체적으로 뼈대를 만드는 데 여러 가지 고려할 것들이 많아서 무엇부터 구축을 해야 할 지 감이 오지 않는데 지금은 필요할 때마다 만드는 방식과 모듈을 하나씩 만들어 결합하는 방식으로 진행하고 있다. 완성이 되면 시스템 자체가 경험을 쌓아나갈 수 있는 시스템이 되었으면 좋겠다.

1. 배움 정리

AI가 다루는 세계의 확장

처음 LLM을 사용할 때는 주로 텍스트를 입력하고 텍스트를 출력하는 형태로 생각했지만 멀티모달 모델을 통해서 AI가 처리할 수 있는 정보의 범위가 훨씬 넓어지고 있다는 것을 배웠다.

텍스트뿐 아니라 이미지, 음성, 영상이나 여러 형식의 파일을 함께 처리할 수 있게 되면 AI가 상황을 이해하기 위해 사용할 수 있는 정보 자체가 달라진다.

단순하게 나누면

텍스트 모델
텍스트 → 이해/판단 → 텍스트

멀티모달 모델
텍스트
이미지
음성
영상
파일
  ↓
통합된 정보
  ↓
이해 / 판단

이라고 볼 수 있을 것 같다.

이전에 배운 RAG나 Memory와도 연결해서 생각할 수 있다.

RAG와 Memory가 어떤 정보를 가져오고 유지할 것인가에 가까웠다면 멀티모달은 그 정보가 꼭 텍스트일 필요가 없도록 AI가 인식할 수 있는 정보의 형태 자체를 확장하는 것에 가깝다.

RAG / Memory
→ 필요한 정보를 어디에서 가져올 것인가

Multimodal
→ 어떤 형태의 정보를 이해할 수 있는가

여기에 피지컬 AI까지 생각하면 조금 더 범위를 넓힐 수 있다.

멀티모달이 AI가 실제 세계에서 만들어지는 다양한 정보를 인식할 수 있게 한다면 피지컬 AI는 판단의 결과를 다시 실제 세계의 행동으로 연결하는 방향이라고 볼 수 있을 것 같다.

현실 세계
   ↓
텍스트 / 이미지 / 음성 / 센서
   ↓
Perception
   ↓
AI의 판단
   ↓
Action
   ↓
현실 세계

아직 로봇이 사람처럼 복잡한 손동작을 안정적으로 수행하는 것처럼 해결해야 할 문제가 많지만, AI가 디지털 환경 안에서 정보를 처리하는 것을 넘어 실제 환경을 인식하고 행동하는 방향으로 발전하고 있다는 점이 흥미로웠다.

결국 AI의 발전을 단순히 모델의 추론 능력이 좋아지는 것으로만 볼 것이 아니라 AI가 인식할 수 있는 세계와 행동할 수 있는 범위가 넓어지는 과정으로 볼 수도 있을 것 같다.

동작하는 코드에서 실행 가능한 시스템으로

Docker를 이용한 이미지 배포를 배우면서 구현한 프로그램을 다른 환경에서도 실행 가능한 형태로 만드는 것에 대해서 생각해볼 수 있었다.

개발자의 컴퓨터에서 코드가 실행되는 것과 실제 서비스를 다른 환경에서 실행할 수 있는 것은 다른 문제다.

코드
↓
필요한 라이브러리
실행 환경
환경 설정
의존성
↓
실행

각 환경을 사람이 직접 맞추면 개발 환경과 운영 환경이 달라져 예상하지 못한 문제가 생길 수 있다.

Docker는 애플리케이션과 필요한 실행 환경을 이미지라는 형태로 묶어서 일정한 환경에서 실행할 수 있도록 한다.

Application
+
Runtime
+
Dependency
+
Configuration
        ↓
   Docker Image
        ↓
    Container

Dockerfile을 이용해 어떤 환경의 이미지를 만들 것인지 정의하고, 여러 서비스나 실행 설정을 함께 관리해야 할 경우에는 Compose를 이용해 컨테이너들의 구성을 정의할 수도 있다.

이를 통해 이전 프로젝트도 이미지 형태로 만들어 직접 배포해봤다.

이 과정에서 프로젝트를 완성한다는 것도 조금 다르게 생각하게 되었다.

코드가 동작한다
≠
다른 환경에서도 실행할 수 있다
≠
서비스를 안정적으로 운영할 수 있다

구현 이후에도 실행 환경을 재현하고, 배포하고, 운영할 수 있어야 실제 사용할 수 있는 시스템에 가까워진다.

이전에 배운 워크플로우나 Agent가 논리적인 실행 구조에 대한 내용이었다면 Docker는 그 구조가 실제로 동작할 물리적인 실행 환경을 고정하는 방법이라고 볼 수도 있을 것 같다.

AI를 활용하는 팀에서의 오케스트레이션

이번 팀 프로젝트에서는 팀장을 맡아 이전보다 팀원들에게 많은 자유도를 주는 방식으로 진행해봤다.

Codex와 같은 AI를 이용하면 각자가 구현할 수 있는 범위가 넓어졌기 때문에 처음에는 최소한의 가이드라인만 정하고 각자 자유롭게 작업하도록 하는 것이 효율적일 것이라고 생각했다.

하지만 실제로 진행하면서 같은 AI를 사용하더라도 사용하는 사람의 경험과 활용 능력에 따라 결과물의 범위와 품질, 자신이 관리할 수 있는 코드의 범위가 달라질 수 있다는 것을 확인했다.

높은 자유도
↓
다양한 접근 방법
↓
빠른 구현

하지만

공통 기준 부족
↓
결과의 편차 증가
↓
통합 / 관리의 어려움 증가

그래서 진행 중에 다시 가이드라인을 정하고 각자의 상황과 능력에 맞춰 작업을 재분배했다.

여기에서 이전에 Agent를 공부하며 생각했던 것과 비슷한 구조를 느꼈다.

Agent도 모든 행동을 미리 정해버리면 자율성을 활용하기 어렵고, 반대로 모든 판단을 맡겨버리면 결과를 통제하기 어렵다.

팀에서도 마찬가지로 모든 것을 팀장이 결정하면 각자의 장점을 활용하기 어렵지만 완전히 자유롭게 두면 하나의 결과로 합치기 어려워질 수 있다.

공통 목표
+
반드시 지켜야 하는 기준
+
각자의 자유로운 판단
+
중간 결과 확인
+
필요할 때 방향 조정

정도의 구조가 필요한 것 같다.

결국 팀을 관리한다는 것은 모든 작업을 결정하는 것보다 목적과 기준을 공유하고 각자가 판단할 수 있는 범위를 만들면서 전체 방향이 벗어나지 않도록 조율하는 것에 가까웠다.

어떻게 보면 사람의 협업에서도 일종의 오케스트레이션이 필요한 셈이다.

추상적인 생각을 전달 가능한 형태로 만드는 것

이번 프로젝트에서 예상보다 어려웠던 부분은 발표 자료와 영상을 만드는 일이었다.

프로젝트가 무엇을 하고 어떤 목적을 가지고 있는지는 이해하고 있었지만 그것을

무엇부터 보여줄지
어떤 내용을 생략할지
어떤 내용을 강조할지
어떤 순서로 설명할지
어떤 형태로 시각화할지

구체적으로 결정하는 것은 다른 문제였다.

생각해보면 추상적인 내용을 이해하는 것과 그것을 다른 사람이 이해할 수 있는 형태로 표현하는 것 사이에는 별도의 변환 과정이 필요하다.

내가 이해하고 있는 개념
↓
전달해야 하는 핵심 선택
↓
논리적인 순서
↓
시각적 구조
↓
발표 자료
↓
상대의 이해

AI를 사용하면 PPT나 이미지 같은 결과물을 매우 빠르게 만들 수 있지만 무엇을 어떻게 보여주고 싶은지에 대한 기준이 없으면 AI에게도 원하는 결과를 요구하기 어렵다.

이전부터 AI에게 일을 맡길 때 의도와 평가 기준이 중요하다고 생각했는데 디자인과 발표에서도 같은 문제가 나타났다.

AI를 잘 활용하기 위해서 모든 것을 직접 만들 수 있을 필요는 없지만 최소한

무엇을 전달하려는가 좋은 결과가 어떤 것인가 지금 결과에서 무엇이 잘못됐는가

를 판단할 수 있는 기준은 필요하다.

이번 주의 내용을 하나로 연결해보기

이번 주의 내용은 처음에는 멀티모달, 팀 프로젝트, Docker, 피지컬 AI처럼 서로 다른 주제처럼 보였다.

하지만 다시 연결해서 생각하면 모두 AI가 실제 세계에서 사용할 수 있는 시스템이 되기 위해 필요한 범위를 확장하는 과정으로 볼 수도 있을 것 같다.

[인식]
Multimodal
다양한 형태의 정보를 이해한다.
        ↓

[판단]
LLM / Agent
정보를 바탕으로 다음 행동을 결정한다.
        ↓

[실행]
Tool / Software / Physical AI
디지털 또는 실제 세계에 행동한다.
        ↓

[실행 환경]
Docker
시스템이 일정한 환경에서 실행되도록 만든다.
        ↓

[조율과 통제]
Human / Team / Orchestration
목적과 기준을 유지하고 필요한 순간에 방향을 조정한다.

이렇게 보면 AI 시스템을 만드는 범위도 계속 넓어지고 있다.

처음에는

입력 → LLM → 출력

정도로 생각할 수 있었지만 실제로 사용할 수 있는 시스템은

현실의 정보
↓
인식
↓
필요한 정보와 상태 관리
↓
판단
↓
행동
↓
실행 환경
↓
관찰과 통제
↓
다시 현실의 결과

까지 생각해야 한다.

그리고 이번 프로젝트 경험까지 연결하면 기술적인 시스템뿐 아니라 그 시스템을 만드는 사람들의 작업도 비슷한 구조가 필요하다는 생각이 든다.

팀원에게 모든 작업 방법을 지정하는 것보다 목표와 기준을 제공하고 자율적으로 실행하도록 한 뒤 중간 결과를 확인하고 필요한 순간에 방향을 수정한다.

목표
↓
기준 설정
↓
작업 분배
↓
자율적 실행
↓
중간 결과 확인
↓
방향 조정
↓
통합

이전에 AI Agent에서 생각했던

Goal
→ Plan
→ Action
→ Observation
→ Evaluation
→ Update

과 구조적으로 비슷한 부분이 있다.

결국 AI든 사람이든 자율적으로 작업하는 주체가 많아질수록 모든 행동을 직접 통제하는 것보다 목적, 경계, 관찰, 피드백을 잘 설계하는 것이 중요하다고 생각한다.

2. 문제 및 개선

문제

1. 자유도를 높인다고 항상 효율적인 것은 아니었다.

이번 프로젝트에서는 최소한의 가이드라인만 제공하고 팀원들이 자유롭게 AI를 활용하도록 했지만 각자가 AI를 활용할 수 있는 범위와 결과물을 관리할 수 있는 능력이 달라 결과의 편차가 생겼다.

자유도를 높이는 것 자체보다 자유롭게 판단할 수 있는 영역과 반드시 맞춰야 하는 영역을 먼저 구분할 필요가 있었다.

2. 여러 가능성을 계속 고려하면서 의사결정이 흔들리는 경우가 있었다.

프로젝트 중간에는 예상하지 못한 상황이나 더 좋은 방법이 계속 생긴다.

가능성을 많이 볼 수 있는 것은 장점이지만 모든 가능성을 동시에 고려하면 지금 가장 중요한 것이 무엇인지 놓칠 수 있다.

3. 추상적인 개념을 구체적인 표현으로 변환하는 기준이 부족했다.

발표에서 전달해야 하는 내용은 알고 있었지만 어떤 순서와 디자인으로 표현해야 다른 사람이 가장 쉽게 이해할 수 있는지 결정하기 어려웠다.

코드나 시스템 구조뿐 아니라 정보 전달과 디자인에서도 추상적인 의도를 구체적인 결과로 변환하는 능력이 필요했다.

4. AI가 결과를 만드는 속도와 사람이 판단하는 속도의 차이가 커지고 있다.

AI는 코드, 문서, 이미지나 발표 자료를 매우 빠르게 생성할 수 있지만 사람이 모든 결과를 같은 속도로 이해하고 평가할 수는 없다.

결과 생성 자체보다 무엇을 만들지 결정하고 결과가 적절한지 판단하는 부분이 점점 더 중요해지는 것 같다.

개선

1. 자유도를 단순히 높이거나 낮추기보다 고정해야 하는 기준과 자유롭게 선택할 수 있는 부분을 분리한다.

고정
목적
인터페이스
제약
완료 조건

자율
구현 방법
사용 도구
세부 구조

정도로 나누면 공통된 방향을 유지하면서도 각자의 판단을 활용할 수 있을 것 같다.

2. 의사결정을 해야 할 때는 현재 목적의 우선순위를 먼저 확인한다.

현재 가장 중요한 목표
↓
반드시 만족해야 하는 조건
↓
선택 가능한 방법
↓
비용 / 시간 / 위험 비교
↓
결정

더 좋은 가능성이 존재한다는 것과 지금 그 가능성을 선택해야 한다는 것은 다르기 때문에 현재 목적과 제한된 시간 안에서 판단하는 연습이 필요하다.

3. 발표나 디자인도 구현과 비슷하게 단계적으로 구성한다.

바로 PPT를 만드는 대신

목적
→ 전달해야 할 핵심
→ 정보의 순서
→ 스토리보드
→ 시각화
→ 디자인

순으로 구체화하면 추상적인 생각과 최종 결과 사이의 간격을 줄일 수 있을 것 같다.

4. AI의 생성 속도를 따라가려고 하기보다 판단 기준과 검증 능력을 높이는 방향으로 활용한다.

사람이 AI보다 빠르게 결과물을 만들 필요는 없다.

대신 AI가 만든 결과에서 중요한 부분을 빠르게 확인하고 수정 방향을 결정할 수 있는 능력이 더 중요해질 것 같다.

3. 소감

이번 주는 수업 내용보다 팀 프로젝트를 실제로 진행하면서 배운 부분이 많았던 것 같다.

이전 프로젝트 경험도 있었고 팀원들의 도움도 있어서 팀장을 맡는 것 자체에 대해서는 전보다 부담을 덜 느꼈다.

다만 팀원들에게 어느 정도의 자유도를 주는 것이 좋은지, 계획과 다른 상황이 생겼을 때 어떤 기준으로 결정을 내려야 하는지, 결과물을 어떻게 하나로 합칠 것인지처럼 실제로 진행하면서만 알 수 있는 문제들이 있었다.

처음에는 좋은 팀장은 정확한 계획을 만들고 모든 상황을 잘 관리하는 사람이라고 생각했던 부분도 있었던 것 같다.

지금은 오히려 모든 것을 원하는 방향으로 통제하는 것이 아니라 상황을 정확하게 인식하고 현재 가장 중요한 목적을 기준으로 적절한 방향을 선택해 팀이 움직일 수 있도록 만드는 것이 중요하다고 생각한다.

이런 부분은 Agent나 오케스트레이션을 공부하면서 생각했던 내용과도 많이 닮아 있었다.

자율적인 주체를 활용하려면 모든 행동을 직접 정하는 대신 목표와 경계를 명확히 하고 중간 결과를 관찰하면서 필요한 순간에 개입해야 한다.

AI를 활용하는 방식이나 사람과 협업하는 방식이 생각보다 비슷한 문제를 가지고 있다는 점이 재미있었다.

멀티모달과 피지컬 AI에 대해서 배우면서는 AI의 범위가 생각보다 빠르게 넓어지고 있다는 느낌도 받았다.

텍스트 안에서 답변을 만드는 모델에서 이미지와 음성, 실제 환경을 이해하고 결국 현실에 행동하는 시스템으로 확장된다면 앞으로는 모델 자체뿐 아니라 AI가 무엇을 보고, 무엇을 기억하고, 무엇을 할 수 있으며, 어디까지 행동하도록 허용할 것인가가 더 중요해질 것 같다.

Docker를 이용해 프로젝트를 직접 이미지로 배포해본 것도 프로젝트를 구현하는 것과 실제 실행 가능한 형태로 만드는 것의 차이를 생각하게 했다.

결국 이번 주의 여러 경험을 연결하면 계속 같은 방향을 보고 있는 것 같다.

더 많은 것을 직접 통제하는 것보다 목적과 기준을 명확히 하고, 자율적으로 실행할 수 있는 구조를 만들고, 결과를 관찰하면서 필요한 순간에 개입하는 것.

AI 시스템을 만드는 데에도, AI를 이용해 개발하는 데에도, 팀을 이끄는 데에도 비슷하게 적용할 수 있는 기준인 것 같다.

다음 프로젝트에서는 이번 프로젝트에서 경험한 문제들을 단순히 기억하는 데에서 끝내지 않고 공통된 기준이나 가이드라인으로 정리해서 처음부터 적용해보고 싶다.

1. 배운 내용

피지컬 AI 전망

다큐를 통해서 피지컬 AI 현재 상황과 앞으로 해결해야 할 부분에 대해서 생각해 볼 수 있었다. 자료에 따르면 지금 액추에이터로 비교적 간단히 하드웨어들을 만들 수 있고 점점 활용하기 위한 개발이 빨라지고 있다고 한다. 한국의 경우 시급히 공장의 노하우를 피지컬 AI가 배워야 할 필요가 있다고 한다. 그리고 결국 아직 해결되지 않은 "손"을 사용하는 법을 배워야 될 것이라고 한다.

도커 이미지 배포

도커를 이용하여 프로젝트를 배포하는 방법에 대해서 배웠다. 도커 파일과 컴포즈 파일이 필요하고 이를 명령어를 활용해서 이미지를 올리고 받을 수 있고 컨테이너까지 만들어서 활용 가능하다. 즉, 이를 이용하면 쉽게 배포, 운영이 가능하다.

2. 실제 작업한 내용

프로젝트 이미지 배포

이전에 작업한 프로젝트를 이미지로 배포했다.

3. 소감

피지컬 AI 소식은 새로웠던 것 같다. 생각보다 이미 가까이에 기술이 접근하고 있다는 걸 느꼈다. 이제 또 새로운 조를 만나서 프로젝트를 하게 되는데 이전 프로젝트에 대한 피드백을 잘 정리해서 좋은 방향으로 나아갈 수 있게 정리가 필요할 것 같다.

이를 보완하게 위해서 발표 자료를 만드는 파이프라인과 템플릿 정도를 만들고 디자인에 대해서 생각과 고민을 했다.

디자인에 대한 생각

절대적인 기준은 없는 것 같다. 당연히 사용자에 대한 고려가 있어야 하는데 너무 막연하게 느껴진다. 그래서 생각을 한 건 내가 바라보는 "좋음"을 기준으로 생각하는 방법이다. 먼저 내가 좋아하는 것들을 나열해보고 거기서 공통적인 부분을 찾아내고 이를 디자인에 적용해보려고 한다. 디자인에 대해 더 넓은 안목을 기르려면 더 많이 경험하는 게 중요하다고 생각하는데 즉, 다른 사람들이 디자인한 것들을 많이 접하면서 좋은 점들을 배우는 게 좋을 것 같다.

발표 자료 생성 파이프라인

1. 발표 목표 정의
2. 자료 수집
3. 정보 구조화, 지식 그래프 생성
4. 스토리텔링, 슬라이드 설계
5. 레이아웃, 노드 연결선 매핑
6. 최신 스키마 blueprint 조립
7. 템플릿 렌더링, 시각 QA
8. 최종 검증

이와 같이 과정을 만들어서 자료에서 흐름, 내용, 구조를 하나씩 만들면서 보다 더 원하는 디자인을 완성하려고 했다. 이를 위해서 간단한 모듈형 템플릿을 만들고 실험을 했다. 최종 완성되는 형태는 웹 페이지고 간편하게 브라우저로 볼 수 있도록 했다.

아직 틀을 잡는 정도지만 모듈형이기 때문에 여러 에셋들을 저장하면 더 많은 것들을 조합해서 만들 수 있어서 나의 디자인 적인 생각과 경험이 정리될수록 나에게 맞는 디자인을 더 빠르게 만들 수 있을 것 같다.

프로젝트는 한 번에 기록하는 게 좋을 것 같다.

1 & 2 & 3 배운 내용 및 실제 작업한 내용 및 소감

팀 프로젝트

팀장 역할을 맡아서 프로젝트의 전반적인 관리를 맡았다. 이전과 다르게 진행한 점은 최소한의 가이드라인으로 팀원들에게 자유도를 높게 해서 진행한 점이다. 코덱스를 활용하는 점을 생각해서 최소한의 틀로 자유도를 높게 했지만 활용하는 능력에 따라 만들어낸 결과물을 관리할 수 있는 범위가 달랐다. 그래서 가이드라인과 틀을 다시 잡고 능력에 따라서 작업을 다시 분배했다.

작업의 중간 중간마다 작업의 진행도를 확인했고 중간 결과, 문제 상황, 계획과 다른 변수 발생 등의 순간마다 최대한 빠르게 합리적인 판단을 위해 목적의 우선 순위를 정해서 의사결정을 했다. 그럼에도 여러 가지 가능성과 더 잘하고자 하는 욕심 때문에 고민하거나 흔들렸던 것 같다.

발표 자료와 발표 준비를 하는데에 예상보다 오래 걸렸다. PPT와 영상을 제작했는데 디자인과 목적, 의도 그리고 전달한 내용을 구체화해서 만들어 내는 게 스스로 그려지지 않는다는 것을 느꼈다. 즉, 추상화된 여러 개념들이 있지만 이를 어떤 순서로 어떤 디자인으로 보여줄 건 지를 구체화할 기준이 명확하게 내 안에 없었던 것 같다.

또한 발표 자료나 발표 준비를 할 때 AI의 결과물을 만드는 속도가 너무 빠르다 보니 사람이 직접 만드는 게 의욕이 떨어지는 부분이 있었다. 그리고 디자인에 대한 인공지능 활용을 경험을 하지 않아서 AI에게 원하는 결과를 얻기가 어려웠다. 근본적으로 어떤 순서로 어떤 내용을 어떻게 보여줘야 할 지 명확한 기준과 이걸 실제로 연결할 수 있는 활용 능력이 필요하다고 느꼈다.

협업해서 프로젝트를 진행하기 때문에 모든 걸 완벽히 원하는 방향으로 갈 수는 없고 여러 제약과 상황 그리고 같이 협업하는 팀원들을 고려하여 적절한 균형점을 찾고 이끌어 가야하는 걸 배운 것 같다.

1. 배운 내용

멀티모달

llm 관련 모델은 단순히 텍스트를 입출력하는 모델만 있는 것이 아니라 다른 유형의 이미지, 소리, 여러 유형의 파일들을 동시에 처리할 수 있는 모델들도 존재한다. 즉, 여러가지 유형의 데이터들을 가공할 수 있다는 것이다.

2. 실제 작업한 내용

팀 프로젝트

이전부터 작업했던 흐름에 따라 팀장으로서 방향을 설정하고 이끄는 걸 했다.

3. 소감

이전의 경험과 팀원들의 도움으로 진행하는 일에 대해서 전보다는 마음을 편하게 가질 수 있는 것 같다. 물론 완벽하게 미리 그려놓은 그림대로 흘러가지는 않지만 팀장으로서 각 상황에 대한 정확한 인지를 하려고 노력하고 상황에 대해서 방향을 잡고 팀원들을 그 방향으로 이끄는 게 중요한 것 같다.

1. 작업이 여기까지 온 흐름

출발점은 AI가 실제 작업을 안정적으로 수행하게 만드는 하네스였다.

고정된 하나의 하네스보다 작업에 따라 모델·도구·메모리·평가기를 조립할 수 있는 구조가 적합하다고 판단하면서 메타 하네스로 확장되었다.

그러나 메타 하네스가 무엇을 조립해야 하는지 결정하려면 더 앞단에서

사용자가 실제로 무엇을 원하는가?

를 명시적으로 표현할 필요가 생겼다.

AI 실행 구조
    ↓
Harness
    ↓
작업별 동적 구성
    ↓
Meta Harness
    ↓
무엇을 구성해야 하는가?
    ↓
Intent Representation
    ↓
Intent Compiler

즉 메타 하네스와 의도 컴파일러는 별개의 아이디어라기보다 하나의 실행 문제를 서로 다른 경계에서 해결하는 구조다.

2. 핵심 개념을 추출하면

현재까지 등장한 개념은 역할에 따라 다음 여섯 집합으로 압축할 수 있다.

인간 의도를 해석하기 위한 정보

• Natural Language
• Context
• World Model
• User Model
• Terminology

의미를 명시적으로 표현하는 구조

• Intent
• Semantic Model
• Intent IR
• Uncertainty

실행 방법을 결정하는 구조

• Validation
• Planning
• Composition

실제 작업을 수행하는 구조

• Composer
• Work Controller
• Execution Fabric

시스템 전체를 제어하는 구조

• Governance

실행 결과를 다시 판단에 사용하는 구조

• Result
• Evaluation
• Feedback
• Quality Loop

각각을 따로 이해하는 것보다 이들이 어떤 관계를 가지는가가 중요하다.

3. 전체 개념 그래프

이 그래프에서 가장 중요한 것은 크게 세 가지 흐름이다.

의미 형성
Natural Language + Context
        ↓
Intent

실행 구조 형성
Intent IR
        ↓
Plan / Composition
        ↓
Meta Harness

자기 수정
Execution
        ↓
Evaluation
        ↓
Feedback
        ↺

4. 가장 중요한 경계: Intent IR

Intent IR의 의미는 단순히 자연어를 JSON으로 바꾸는 것이 아니다.

핵심은

인간의 표현 방식과 실행 시스템 사이에 안정적인 의미 계약을 만드는 것

이다.

이 경계가 안정되면 위쪽에서는 자연어·음성·UI 등 입력 방식이 달라질 수 있고, 아래쪽에서는 LLM·Agent Framework·Tool·Runtime이 달라질 수 있다.

다양한 인간 표현
        ↓
     Intent IR
        ↓
다양한 실행 시스템

따라서 의도 컴파일러에서 가장 먼저 안정시켜야 할 대상은 컴파일 과정 자체보다 무엇을 Intent IR에 표현할 것인가다.

5. Intent는 문장 안에만 존재하지 않는다

일반적인 컴파일러에서는 입력 언어의 구조와 의미 규칙이 이미 상당 부분 정해져 있다.

자연어 의도 해석은 다르다.

"다음 진행해"

라는 표현만으로는 실제 행동을 결정할 수 없다.

의미는 오히려 다음 관계에서 생긴다.

따라서 의도 해석을

Natural Language → Parsing → Intent

로만 이해하면 부족하다.

더 정확한 모델은

Intent =
입력
+ 현재 상태
+ 세계에 대한 모델
+ 사용자에 대한 모델
+ 용어의 의미

이다.

이 때문에 Context, World Model, Personalization, Terminology는 부가적인 편의 기능이 아니라 의미 분석의 일부가 된다.

6. Intent Language는 발견하는 것에 가깝다

Intent Language를 먼저 만들고 인간의 의도를 그 틀에 맞추는 방식은 위험하다.

예를 들어 처음부터

GOAL
CONSTRAINT
RESOURCE
...

를 정해 버리면 실제 작업에 존재하는 의미를 언어에 억지로 맞추게 될 수 있다.

현재 작업에서는 반대 방향이 더 적합하다.

즉,

Syntax → Meaning

이 아니라

Observed Meaning → Semantic Model → Representation

순서다.

기존의 메타 하네스 계획서와 실제 대화 기록은 따라서 단순 기록물이 아니라 Intent Model을 추출하기 위한 데이터가 된다.

7. 현재까지 드러난 Intent의 의미 축

지금까지의 작업에서 반복되는 요소들을 추출하면 대략 다음 관계가 보인다.

이것은 최종 Schema가 아니다.

오히려 실제 작업을 분석하면서 계속 검증해야 할 현재의 가설적 Ontology에 가깝다.

중요한 질문은

어떤 필드가 있어야 하는가?

보다

실제 작업을 설명할 때 어떤 의미 관계가 반복해서 필요한가?

이다.

8. Intent · Plan · Execution의 분리

앞으로 특히 중요한 경계다.

예를 들어

Intent
메타 하네스 구현 계획의 완전성을 검증한다.

Plan
요구사항 추출
→ 구조 대응
→ 누락 탐색
→ 수정안 생성

Execution
문서 읽기
→ 항목 비교
→ 결과 작성

이 셋을 나누면 실패도 분해할 수 있다.

의도를 잘못 이해했는가?
        ↓
계획이 잘못되었는가?
        ↓
실행 과정에서 실패했는가?

이 구분은 이후 Evaluation과 Feedback의 방향을 결정하는 데도 중요하다.

9. Meta Harness 내부의 책임 경계

메타 하네스에서는 세 가지 질문을 분리하는 것이 핵심이다.

Composer

작업을 수행하기 위해 필요한 능력을 선택하고 조합한다.

• Model
• Agent
• Tool
• Memory
• Evaluator
• Workflow

Work Controller

실행 중인 작업의 상태와 진행을 관리한다.

• 현재 단계
• 완료 상태
• dependency
• retry
• checkpoint
• 다음 행동

Execution Fabric

실제 계산과 외부 행동을 수행한다.

• LLM 호출
• Tool 실행
• API
• Shell
• Sandbox
• Remote Runtime

따라서

Composition ≠ Orchestration ≠ Execution

이다.

이 경계가 분명해야 각각을 독립적으로 교체하고 개선할 수 있다.

10. Governance와 Quality는 다른 방향으로 작동한다

둘 다 시스템 전체에 영향을 주지만 같은 종류의 기능은 아니다.

Governance의 질문은

이 행동을 수행해도 되는가?

이다.

Quality의 질문은

수행한 결과가 얼마나 좋은가?

이다.

따라서

Governance
= 가능한 행동 공간을 제한

Quality
= 실제 행동의 결과를 평가

한다.

Governance는 cross-cutting constraint에 가깝고, Quality는 feedback loop에 가깝다.

11. Feedback은 어디로 돌아가야 하는가

Evaluation 결과를 단순히 다음 실행의 Prompt에 추가하는 것만으로는 부족하다.

실패의 원인에 따라 수정 지점이 다르기 때문이다.

따라서 자기개선의 핵심은 단순한 Feedback 저장이 아니라

Feedback이 어느 의사결정 계층을 수정해야 하는지 식별하는 것

이다.

12. 현재까지 얻은 핵심 통찰

1. 메타 하네스의 본질은 모듈의 수보다 경계다.

Interpretation
Planning
Composition
Control
Execution
Evaluation

이 서로 섞이지 않아야 각 계층을 독립적으로 발전시킬 수 있다.

2. Meta Harness 앞에는 의미의 안정적인 경계가 필요하다.

Human Intent
    ↓
Intent IR
    ↓
Executable System

3. Intent Compiler의 핵심 산출물은 Intent IR이다.

중요한 것은 Compiler라는 이름이 아니라

실행 계층에 어떤 의미 정보를 넘길 것인가

이다.

4. Intent Language는 발명하기보다 실제 작업에서 추출해야 한다.

실제 사례
→ 반복되는 의미
→ Semantic Model
→ Intent IR

5. Context·World Model·User Model·Terminology는 의미론의 일부다.

의도는 문장 자체보다 문장과 상태의 관계에서 결정된다.

6. Intent는 정적인 단일 객체보다 Graph에 가까울 가능성이 높다.

복잡한 작업에는

Intent
 ├─ Sub-intent
 ├─ Dependency
 ├─ Constraint
 ├─ Assumption
 └─ Uncertainty

가 함께 존재하기 때문이다.

7. Feedback 역시 하나의 목적지만 가지지 않는다.

Evaluation
 ├→ Intent 수정
 ├→ Plan 수정
 ├→ Composition 수정
 └→ Execution 수정

처럼 실패 원인에 따라 환류 지점이 달라져야 한다.

13. 기존 개념을 현재 설계와 연결하면

새로운 개념을 배우기 위한 목록이 아니라, 현재 가지고 있는 추상적 개념을 더 정확하게 표현하기 위해 빌려 쓸 수 있는 대응 관계다.

Compiler IR
→ 인간 표현과 실행 표현을 분리하는 안정적인 경계

Compiler Pass
→ 하나의 거대한 추론 대신 단계별 의미 변환

Semantic Analysis
→ 문장 구조가 아니라 실제 의미와 유효성을 판단하는 계층

Symbol Table
→ Terminology와 참조 대상을 안정적으로 연결하는 사고 모델

Ontology
→ Intent를 구성하는 개념과 관계를 정의하는 모델

Planning
→ 원하는 상태와 그 상태에 도달하는 방법을 분리

State Machine
→ Work Controller의 실행 상태 표현

Policy Engine
→ Governance를 실제 실행 로직과 분리

Observability
→ 실행 기록을 다음 판단에 사용할 수 있는 구조화된 데이터로 변환

핵심은 이 개념들을 그대로 가져오는 것이 아니다.

현재 설계에서 이미 존재하는 추상적 문제를 어떤 기존 개념이 가장 잘 설명하는가

를 기준으로 이용하는 것이다.

14. 앞으로 설계에서 계속 던질 질문

의미의 위치

이 정보는 Intent 자체인가?
Context에서 참조해야 하는가?
World Model의 상태인가?
User Model의 특성인가?

책임의 위치

이 판단은
Intent Resolution?
Validation?
Planner?
Composer?
Runtime?
중 어디에서 해야 하는가?

표현의 수준

Intent IR은
사용자가 원하는 것을 표현해야 하는가,
실행 시스템이 필요한 것을 표현해야 하는가,
둘 사이의 안정적인 최소 계약이어야 하는가?

불확실성

해석이 확정되지 않았을 때
시스템은 하나를 선택해야 하는가,
복수 후보를 유지해야 하는가?

변화

작업 중 의도가 바뀌면
기존 Intent를 mutate하는가,
새로운 Intent state를 만드는가?

평가

성공은 최종 Result만 평가하면 되는가,
원래 Intent와 결과 사이의 차이를 평가해야 하는가?

자기개선

실패가 발생했을 때
어느 계층의 판단을 수정해야 하는가?

15. 전체 구조의 압축

현재 작업을 가장 짧게 표현하면 다음과 같다.

불완전한 인간 의도를 명시적인 의미 구조로 만들고, 그 의미에서 실행 구조를 동적으로 생성하며, 실행 결과를 다시 적절한 판단 계층으로 환류시키는 시스템을 설계하고 있다.

따라서 앞으로 중요한 것은 새로운 기능을 계속 추가하는 것이 아니라,

각 개념의 경계를 명확히 하고, 노드 사이에 어떤 정보가 흐르는지 정의하며, 실제 작업 사례를 통해 그 그래프가 충분한지 검증하는 것

이다.