[SK네트웍스 Family 엔코아AI캠퍼스] AI 오케스트레이션 캠프 1기_10월 1주차 회고

 

10월 첫째 주는 멀티 에이전트의 실행 구조를 이해하는 데서 나아가, 장애 상황에서도 서비스를 안정적으로 운영하고 팀원들의 코드를 하나의 시스템으로 연결하는 방법을 고민하기 시작한 한 주였다.

이번 주간 회고는 일일 회고에서 다룬 학습 내용을 바탕으로, 기술을 배운 순서대로 나열하기보다 멀티 에이전트 시스템의 설계와 검증, 장애 대응, 협업 코드 통합이라는 흐름으로 정리했다.

1. 이번 주 학습 요약

이번 주에는 멀티 에이전트 시스템을 설계할 때 고려해야 할 요소가 점점 구체적으로 드러났다.

초반에는 에이전트의 실행 결과를 평가하고, 실패했을 때 재시도하거나 다른 경로로 복구하는 방법을 배웠다. 이후에는 Prompt Injection 방어, Validation과 Guardrail, 멱등성, 실행 기록 관리 등 실제 서비스 운영에 필요한 안정성 요소를 살펴봤다.

또한 AWS EC2와 GitHub Actions를 이용한 CI/CD 환경을 다루면서 코드 변경 사항을 검증하고 배포하는 과정도 학습했다.

주 후반에는 이러한 개념을 실제 팀 프로젝트에 적용하기 시작했다. 어르신 돌봄 서비스의 AutoHealing 기능을 담당하면서 기존에 작성한 코드가 다른 팀원의 API와 Agent에 연결될 때 어떤 문제가 발생하는지 확인했다.

이번 주의 학습 흐름을 정리하면 다음과 같다.

설계: 에이전트의 역할과 결과 평가 기준을 정의한다.

• 검증: 입력과 출력이 올바른지, 보안 정책을 위반하지 않는지 확인한다.

• 복구: 실패 원인에 따라 재시도하거나 대체 경로를 선택한다.

• 운영: CI/CD를 통해 코드를 검증하고 배포한다.

• 통합: 서로 다른 모듈의 데이터 형식과 처리 기준을 맞추고 실제 연결 상태를 확인한다.

개별 기술을 이해하는 단계에서 실제 시스템이 정상적으로 동작하기 위한 조건을 고민하는 단계로 넘어가고 있다는 것을 느꼈다.

2. 가장 인상 깊었던 학습: 실패를 고려한 멀티 에이전트 설계

이번 주 가장 인상 깊었던 내용은 에이전트가 결과를 생성하는 것과 그 결과를 실제 업무에 사용할 수 있는 것은 다르다는 점이었다.

Evaluation과 Failure Recovery

멀티 에이전트 시스템에서는 한 에이전트의 결과가 다음 에이전트의 입력으로 전달된다. 따라서 앞 단계에서 잘못된 결과를 만들면 이후 작업까지 영향을 받을 수 있다.

이를 방지하기 위해 Evaluation(평가)을 통해 결과가 정해진 기준을 만족하는지 확인할 수 있다.

Writer

결과 생성

Evaluator

평가 기준에 따라 결과 검증

통과

다음 단계 진행

실패

피드백 전달

Reviser

피드백을 반영해 결과 수정 후 재평가

평가 결과에 따라 다음 단계로 진행하거나 결과를 수정하는 구조

여기서 중요한 것은 평가에 실패했을 때 무조건 처음부터 다시 실행하지 않는다는 점이다.

• Retry: 일시적인 오류가 발생했을 때 같은 작업을 다시 시도한다.

• Fallback: 기존 방법을 사용할 수 없을 때 다른 데이터 소스나 처리 경로를 활용한다.

• Replan: 기존 실행 계획으로 문제를 해결할 수 없을 때 계획을 다시 세운다.

• Block: 위험하거나 잘못된 상태에서는 실행을 중단한다.

• Human Intervention: AI가 독자적으로 판단하기 어려운 상황에서 사용자나 담당자의 개입을 요청한다.

예를 들어 여러 에이전트가 병렬로 실행되는 상황에서 하나의 에이전트만 실패했다면, 이미 성공한 작업의 결과는 보존하고 실패한 에이전트만 다시 실행할 수 있다.

이러한 구조를 이해하면서 멀티 에이전트 개발에서는 정상적인 실행 경로뿐 아니라 실패했을 때 어디까지 복구할 수 있는지도 미리 설계해야 한다는 것을 배웠다.

Security와 Guardrail

시스템이 정상적으로 동작하더라도 보안 문제가 발생하면 실제 서비스로 사용하기 어렵다.

이번 주에는 Prompt Injection, Input Validation, 개인정보 마스킹, 최소 권한 원칙, Response Guard 등의 개념도 살펴봤다.

특히 Validation과 Guardrail의 차이를 구분하는 것이 중요했다.

• Validation: 입력값의 형식과 필수 항목이 올바른지 확인한다.

• Guardrail: 요청이나 실행 결과가 정책에 어긋나거나 위험하지 않은지 통제한다.

예를 들어 필수 입력값이 모두 존재하더라도 시스템 프롬프트를 노출하라는 요청이라면 별도의 보안 정책으로 차단해야 한다.

또한 에이전트가 생성한 결과를 그대로 사용자에게 전달하는 것이 아니라, 최종 응답에 민감정보가 포함되어 있는지와 실제 실행 결과에 부합하는지도 확인해야 한다.

이전까지는 에이전트가 어떤 결과를 생성하는지에 집중했다면, 이제는 그 결과를 신뢰하고 사용하기 위해 어떤 검증이 필요한지 생각하게 됐다.

3. 어려웠던 점과 해결 과정: 개별 기능과 통합된 기능의 차이

이번 주 후반부터는 실제 팀 프로젝트에서 AutoHealing 기능을 연결하고 검증하는 과정이 중요해졌다.

AutoHealing은 시스템에 장애가 발생했을 때 재시도, 캐시 또는 대체 경로 등을 활용해 정상적인 동작을 회복하도록 돕는 기능이다.

현재 진행 중인 어르신 돌봄 서비스는 바이탈 정보, 실내 환경, 기기 상태, CCTV 분석 결과 등을 바탕으로 어르신의 상태를 확인하고 보호자에게 필요한 정보를 제공하는 프로젝트다. 나는 이 과정에서 장애 대응과 복구 기능을 담당하고 있다.

기존 작업에서는 SQLite를 활용한 바이탈 데이터 저장 및 조회, 캐시, 실행 로그, 재시도 로직 등을 구현했다. 개인 브랜치에서 작업한 내용을 커밋하고 PR(Pull Request)을 통해 병합한 뒤, 실제 Agent와 API에 연결된 상태를 확인했다.

백엔드 테스트 431개가 통과한 것도 확인했지만, 실제 통합 과정에서 별도의 문제가 발견됐다.

바이탈 데이터의 입력 조건이 서로 달랐다

수집 API에서는 심박수와 측정 시각만 있어도 요청을 받을 수 있었지만, 저장 함수에서는 혈압과 체온, 산소포화도까지 요구하고 있었다.

즉, 각 기능을 개별적으로 확인했을 때는 문제가 없었지만 API에서 전달받은 데이터를 저장 함수에 연결하자 필수값 누락으로 오류가 발생한 것이다.

이 문제를 통해 데이터 계약(Data Contract)의 중요성을 체감했다.

데이터 계약은 서로 다른 기능이 데이터를 주고받을 때 어떤 항목이 필요한지, 자료형은 무엇인지, 값이 누락되면 어떻게 처리할지를 미리 약속하는 것이다.

이번에 확인한 문제의 흐름

수집 API

심박수 + 측정 시각

바이탈 저장 함수

혈압 + 체온 + 산소포화도까지 요구

입력 조건 불일치

API와 저장 함수가 서로 다른 데이터 조건을 가정해 오류 발생

이때 단순히 누락된 값을 임의의 정상 수치로 채워 오류를 피하는 것은 올바른 해결 방법이 아니다. 측정되지 않은 값과 실제 측정 결과가 정상인 것은 다르기 때문이다.

따라서 저장 단계에서는 일부 데이터만 들어오는 경우를 어떻게 처리할지 정하고, 위험 판정 단계에서는 실제로 확보된 정보를 바탕으로 판단하도록 기준을 구분해야 한다.

이번 문제를 통해 복구 기능을 개발할 때도 오류가 발생하면 무조건 재시도하는 것이 아니라 원인을 먼저 구분해야 한다는 점을 배웠다.

• 일시적인 네트워크 오류라면 제한된 횟수만큼 재시도한다.

• 필수 데이터가 누락됐다면 입력 조건을 검증하고 오류를 반환한다.

• 데이터베이스에 장애가 발생했다면 실제로 독립적인 대체 경로가 있는지 확인한다.

잘못된 입력으로 발생한 오류는 같은 요청을 반복한다고 해결되지 않는다. 복구 로직은 오류의 원인과 시스템의 의존 관계를 고려해 설계해야 한다.

테스트 통과와 통합 완료는 다르다

이번 경험에서 또 하나 중요했던 것은 테스트 결과를 해석하는 관점이다.

단위 테스트(Unit Test)는 개별 함수나 모듈이 의도한 대로 동작하는지 확인한다. 통합 테스트(Integration Test)는 여러 모듈이 연결됐을 때 데이터와 호출 흐름이 올바르게 이어지는지 확인한다.

테스트가 많이 통과했더라도 모든 입력 조건과 장애 상황을 검증했다고 볼 수는 없다.

이번 문제를 기준으로 보면 다음과 같은 테스트가 필요하다.

• 심박수와 측정 시각만 있는 데이터가 정상적으로 저장되는가?

• 일부 바이탈 정보가 누락되면 정해진 방식으로 처리되는가?

• 필수값 누락과 데이터베이스 장애를 서로 다른 오류로 구분하는가?

• 실제 Agent와 API를 연결했을 때 데이터가 올바른 형식으로 전달되는가?

이 과정을 통해 테스트 개수만 확인하는 것이 아니라 어떤 상황을 검증했는지 살펴봐야 한다는 점을 이해했다.

4. 이번 주에 새롭게 이해한 점

이번 주의 배움을 관통하는 핵심은 기능을 구현하는 것과 시스템을 안정적으로 운영하는 것은 다른 문제라는 것이다.

처음에는 에이전트의 역할을 나누고 필요한 도구를 연결해 원하는 결과를 생성하는 것이 멀티 에이전트 개발의 핵심이라고 생각했다.

하지만 Evaluation, Guardrail, Failure Recovery, AutoHealing을 학습하면서 실제 서비스에는 그 이상의 고려 사항이 필요하다는 것을 알게 됐다.

첫째, 결과가 만들어졌다고 해서 바로 다음 단계로 넘겨서는 안 된다. 정해진 기준을 만족하는지 검증해야 한다.

둘째, 오류가 발생했다고 해서 무조건 재시도해서는 안 된다. 오류가 일시적인 문제인지, 잘못된 입력인지, 복구 경로 자체의 문제인지 구분해야 한다.

셋째, 개별 기능이 정상적으로 동작해도 전체 시스템이 정상적으로 동작한다는 보장은 없다. 각 기능이 기대하는 입력과 출력의 조건이 일치해야 한다.

넷째, 협업에서는 코드뿐 아니라 구현 기준도 공유해야 한다. 예를 들어 '재시도 3회'라는 표현도 최초 호출을 포함하는지, 최초 호출 이후 세 번을 더 시도하는지에 따라 구현이 달라질 수 있다. 타임아웃 역시 개별 호출에 적용하는지 전체 작업에 적용하는지 명확하게 정의해야 한다.

마지막으로 CI/CD는 단순히 배포를 자동화하는 기능이 아니라 코드 변경을 반복적으로 검증하고, 각 구성 요소를 독립적으로 관리하기 위한 개발 환경이라는 점도 다시 확인했다.

이러한 배움은 모두 같은 방향을 가리키고 있었다. 개별 기능을 만드는 것에서 나아가, 각 기능이 서로 연결되고 실패 상황에서도 예측 가능한 방식으로 동작하도록 만드는 것이 중요하다는 것이다.

5. 현재 나의 상태

이번 주를 마무리하면서 지금까지 이해한 부분과 앞으로 보완해야 할 부분을 구분해봤다.

현재 이해하고 있는 부분

• Evaluation과 Reviser를 이용한 결과 검증 흐름

• Retry, Fallback, Replan 등 장애 유형에 따른 복구 전략

• Validation과 Guardrail의 차이

• AutoHealing에서 오류 원인에 따라 대응 방식을 달리해야 하는 이유

• API와 저장 함수 사이의 데이터 계약이 중요한 이유

• 단위 테스트와 통합 테스트의 차이

앞으로 더 보완할 부분

• 부분적으로 수집된 바이탈 데이터의 저장 및 검증 기준

• SQLite의 선택적 컬럼과 NULL 처리

• 재시도 대상 오류와 즉시 실패해야 하는 오류의 구분

• 실제 장애 상황에서 복구 경로가 정상적으로 동작하는지 검증하는 방법

• 여러 모듈의 입력·출력 계약을 사전에 정의하고 공유하는 방법

• Evaluation과 Failure Recovery를 하나의 실행 흐름으로 구현하는 방법

아직 각 개념을 모든 상황에 자유롭게 적용할 수 있는 단계는 아니다. 특히 이번 프로젝트에서 확인한 데이터 계약 문제를 해결하려면 입력 조건을 명확하게 정리하고, 저장 로직과 검증 로직을 수정한 뒤 통합 테스트로 확인하는 과정이 필요하다.

앞으로는 개념을 이해하는 데서 끝내지 않고 실제 코드에서 어떤 조건으로 구현되어 있는지 확인하는 습관을 들이고 싶다.

6. 다음 주 계획

다음 주에는 이번 주에 발견한 문제를 해결하면서 프로젝트의 안정성을 높이는 데 집중할 계획이다.

첫 번째, 바이탈 데이터의 계약을 명확하게 정의하기.

필수 항목과 선택 항목을 구분하고, 데이터가 누락됐을 때 저장 단계와 위험 판정 단계에서 각각 어떻게 처리할지 팀원들과 기준을 맞춰야 한다.

두 번째, AutoHealing의 복구 조건을 구체화하기.

오류가 발생하면 모두 재시도하는 방식이 아니라 오류 유형에 따라 재시도, 대체 경로 사용, 즉시 실패 등을 구분해야 한다. 특히 대체 경로가 실제로 원래 장애의 영향을 받지 않는지도 확인할 필요가 있다.

세 번째, 통합 테스트를 통해 연결 상태 검증하기.

개별 함수의 테스트 결과뿐 아니라 실제 API에서 데이터를 받아 저장하고, Agent가 해당 데이터를 사용하는 전체 흐름을 확인해야 한다. 정상 입력뿐 아니라 일부 값이 누락된 경우와 데이터베이스 장애 상황도 테스트 대상으로 고려할 것이다.

네 번째, 협업 과정에서 계약과 구현 상태를 명확하게 공유하기.

입력값, 누락값 처리, 재시도 횟수, 타임아웃, 오류 반환 방식 등을 구체적으로 문서화하고, 개인 구현이 완료된 상태와 전체 시스템에 연결해 검증한 상태를 구분해 공유하려고 한다.

이번 주에 배운 내용을 다음 주 프로젝트 작업과 연결한다면, 단순히 기능을 추가하는 것보다 이미 만든 기능이 다양한 상황에서도 의도대로 동작하는지 확인하는 데 더 많은 의미가 있을 것 같다.

7. KPT 회고

Keep — 계속 유지할 것

개별 기능의 구현에만 집중하지 않고 실제 연결 과정에서 어떤 문제가 발생하는지 확인하는 태도를 유지하고 싶다. 테스트 결과를 확인할 때도 통과 여부만 보는 것이 아니라 어떤 입력과 상황을 검증했는지 함께 살펴보려고 한다.

Problem — 개선할 점

각 기능이 기대하는 데이터 형식과 필수 항목이 다르면 통합 과정에서 예상하지 못한 오류가 발생할 수 있다. 구현 전에 계약을 명확하게 정리하는 과정이 부족하면 이후 수정 비용이 커질 수 있다는 점을 확인했다.

또한 개념을 이해하는 것과 실제 프로젝트에서 안정적으로 구현하는 것 사이에는 여전히 차이가 있다. 특히 예외 처리와 복구 로직은 다양한 장애 상황을 직접 검증하면서 보완할 필요가 있다.

Try — 다음 주에 시도할 것

바이탈 데이터의 필수·선택 항목과 누락값 처리 기준을 정리하고, 이를 기준으로 저장 로직과 테스트를 보완해보려고 한다. 또한 정상 상황뿐 아니라 데이터 누락, 일시적인 네트워크 오류, 데이터베이스 장애 등 서로 다른 실패 상황을 구분해 검증할 것이다.

무엇보다 코드를 작성한 뒤 완료했다고 판단하기보다, 실제 연결된 시스템에서 기대한 결과가 나오는지 확인하는 것까지 작업의 일부로 생각하려고 한다.

마무리

10월 첫째 주는 멀티 에이전트의 실행 구조를 이해하는 단계에서 나아가, 실제 시스템의 안정성과 운영을 고민하기 시작한 한 주였다.

Evaluation과 Guardrail을 통해 결과를 검증하는 방법을 배웠고, Failure Recovery와 AutoHealing을 통해 오류가 발생했을 때 어떻게 대응해야 하는지 생각해봤다. 그리고 팀 프로젝트에서 API와 저장 함수의 입력 조건이 달라 발생한 문제를 확인하면서 데이터 계약과 통합 테스트의 중요성을 직접 경험했다.

아직 해결하고 보완해야 할 부분이 남아 있지만, 이번 주에는 단순히 기능이 동작하는지 확인하는 것에서 한 단계 더 나아가 왜 동작하지 않는지, 어떤 조건이 맞지 않는지, 어떻게 검증해야 다시 같은 문제가 발생하지 않을지 고민하게 됐다.

앞으로도 새로운 기술을 배우는 것만큼이나 이미 구현한 기능이 다른 모듈과 올바르게 연결되는지, 실패 상황에서도 예측 가능한 방식으로 동작하는지를 확인하는 데 집중하고 싶다.

해시태그

#AI오케스트레이션 #멀티에이전트 #AI에이전트 #AutoHealing #데이터계약 #통합테스트 #FailureRecovery #GitHubActions #AWS #국비지원개발자