3번째 미니프로젝트 3일차 회고｜AutoHealing·멀티에이전트·장애 복구 검증｜AI 오케스트레이션 개발자 국비지원

 

이번 회고는 앞서 정리한 3팀의 어르신 돌봄 서비스 구현 과정과 다른 팀들의 최종 발표 및 질의응답을 바탕으로 작성할게. 다만 전달해 준 GitHub 저장소는 현재 외부에서 내용을 확인할 수 없어 코드의 파일명이나 세부 구현을 직접 대조하지는 못했어. 따라서 코드에서 확인하지 못한 세부 사항은 단정하지 않고, 지금까지 대화에서 확인된 실제 작업 내용 중심으로 정리했어.

3번째 미니프로젝트 3일차 회고｜AutoHealing·멀티에이전트·장애 복구 검증｜AI 오케스트레이션 개발자 국비지원

1. 마지막 날, 기능 구현에서 안정성 검증까지

이번 3번째 미니프로젝트의 주제는 어르신 돌봄 서비스를 위한 멀티에이전트 시스템이었다. 바이탈 데이터와 실내 환경, 기기 상태, CCTV 분석 결과를 활용해 어르신의 위험 상황을 파악하고, 문제가 발생했을 때 시스템이 스스로 복구를 시도하도록 만드는 것이 핵심이었다.

이번 프로젝트에서 내가 집중한 부분은 AutoHealing 기능의 구현과 검증이었다. AutoHealing은 시스템에 오류가 발생했을 때 단순히 실패를 반환하는 대신, 원인을 확인하고 정해진 절차에 따라 복구를 시도하는 기능이다.

처음에는 장애가 발생하면 재시도하거나 오류를 처리하는 것만으로 충분하다고 생각할 수 있다. 하지만 여러 에이전트와 기능을 연결하는 과정에서는 한 단계의 오류가 다른 단계에 영향을 줄 수 있었다. 따라서 오류를 처리하는 것뿐 아니라, 복구 이후에도 다음 단계가 정상적으로 실행될 수 있는지 확인하는 것이 중요했다.

마지막 날에는 우리 팀의 구현 과정을 돌아보는 동시에 다른 팀들의 발표와 질의응답을 통해 장애 복구를 설계할 때 놓치기 쉬운 부분도 살펴볼 수 있었다.

2. AutoHealing에서 중요했던 것은 복구 이후의 검증

멀티에이전트 시스템에서는 각 에이전트가 맡은 작업을 수행하고 그 결과를 다음 단계에 전달한다. 이때 결과가 누락되거나 예상한 형식과 다르면 이후 작업도 잘못된 방향으로 진행될 수 있다.

예를 들어 어르신의 상태를 판단하는 데 필요한 데이터가 정상적으로 전달되지 않았다면, 단순히 다음 단계로 넘어가는 것이 아니라 해당 데이터가 실제로 유효한지 확인해야 한다.

이번 프로젝트를 진행하면서 중요하게 느낀 부분은 다음과 같다.

오류 감지: 어느 단계에서 어떤 문제가 발생했는지 파악한다.

• 복구 시도: 재시도나 대체 경로 등 사전에 정한 방식으로 복구를 시도한다.

• 결과 검증: 오류가 사라졌다는 사실만으로 성공을 판단하지 않고, 결과가 정상인지 확인한다.

• 안전한 종료와 알림: 복구할 수 없다면 잘못된 결과를 정상 결과처럼 전달하지 않고, 필요한 정보를 남기거나 담당자에게 알린다.

특히 재시도는 모든 상황에서 정답이 아니었다. 일시적인 통신 오류라면 재시도가 효과적일 수 있지만, 필수 데이터가 계속 누락되는 상황에서 무조건 다음 단계로 진행하면 오히려 잘못된 판단을 만들 수 있다.

결국 AutoHealing의 목적은 단순히 시스템을 계속 실행하는 것이 아니라, 정상적으로 복구할 수 있는 상황과 안전하게 중단해야 하는 상황을 구분하는 것이라고 이해하게 되었다.

3. 팀원 간 통합 과정에서 데이터 계약이 중요했던 이유

이번 프로젝트에서는 개별 기능을 구현하는 것만큼 팀원들이 만든 기능을 연결하는 과정도 중요했다.

각 기능이 독립적으로 동작하더라도 서로 주고받는 데이터의 구조나 상태값이 다르면 통합 과정에서 문제가 발생할 수 있다. 여기서 데이터 계약이란 기능 간에 어떤 데이터를 어떤 형식으로 주고받을지 미리 정한 약속을 의미한다.

예를 들어 한 기능은 성공 여부를 특정 상태값으로 반환하고, 다른 기능은 다른 상태값을 기준으로 처리한다면 두 기능을 연결했을 때 예상과 다르게 동작할 수 있다. 필수 필드가 빠지거나 오류 상황에서 반환하는 형식이 달라지는 경우도 마찬가지다.

이번 작업을 통해 기능을 구현할 때는 해당 코드가 독립적으로 실행되는지만 확인해서는 부족하다는 점을 배웠다. 실제 시스템에 연결했을 때 입력과 출력이 서로 맞는지, 실패 상황에서도 약속된 형식으로 결과를 전달하는지 확인해야 했다.

또한 장애 복구 기능은 다른 기능과의 연결 관계에 영향을 받기 때문에, 개별 함수의 성공 여부와 전체 워크플로우의 정상 동작을 구분해서 검증할 필요가 있었다.

4. 다른 팀의 발표에서 배운 장애 대응 방식

마지막 날에는 다른 팀들의 발표를 통해 각기 다른 서비스에서 AutoHealing과 멀티에이전트 구조를 어떻게 활용하는지 살펴볼 수 있었다.

4-1. 게임 퀘스트 기획·검토 시스템

게임 운영자의 요청을 바탕으로 퀘스트 기획안을 작성하고, 다른 에이전트가 게임 데이터와 규칙을 기준으로 검토하는 구조였다. 검토 결과 문제가 있으면 수정 후 다시 검수하고, 복구할 수 없는 상황에서는 안전하게 종료하도록 설계했다.

이 발표에서 인상적이었던 점은 생성한 결과를 곧바로 사용하지 않고 별도의 검토 단계를 거치도록 구성했다는 것이다. AI가 결과를 만들었다는 사실과 그 결과가 실제 규칙에 맞는다는 사실은 다르다.

우리 팀의 어르신 돌봄 시스템에서도 데이터를 수집하거나 분석했다는 사실만으로 최종 판단에 사용하기에 충분하다고 볼 수 없다. 데이터의 유효성과 결과의 신뢰성을 별도로 확인해야 한다는 점에서 공통점이 있었다.

4-2. 생활민원 길잡이

생활민원 길잡이는 민원 분류부터 담당 기관 검색, 링크 검증, 문서 작성까지 여러 단계를 연결한 서비스였다. 공식 기관 정보가 잘못되거나 메일 발송에 실패하는 상황 등을 가정해 장애 대응 경로를 설계했다.

이 발표를 통해 복구 기능은 오류를 해결하는 데 그치지 않고, 대체 경로가 없을 때 어떻게 처리할지도 함께 설계해야 한다는 점을 확인했다.

특히 실제 행정 시스템에 접수하는 것과 테스트 환경에서 가상 발송하는 것을 구분하고, 법적 영향을 줄 수 있는 최종 판단은 사람이 맡도록 한 부분이 인상적이었다. 자동화가 가능하더라도 모든 결정을 AI에 맡기는 것이 적절한 것은 아니다.

4-3. 주식 모의매매 서비스

주식 모의매매 서비스는 시세·재무·뉴스 조사 에이전트가 결과를 수집하고, 작성 에이전트가 리포트를 만든 뒤 별도의 검토 에이전트가 근거를 확인하는 구조였다.

발표에서는 응답이 늦을 때 다른 모델로 전환하거나, 선택적인 뉴스 에이전트에 문제가 발생하면 해당 결과를 제외하고 진행하는 방식이 소개됐다. 반면 필수 에이전트가 실패하면 잘못된 리포트를 내보내지 않고 중단하도록 했다.

또한 장애를 주입해 대체 모델로 전환되는 과정을 확인했지만, 대체 모델이 정상적으로 동작하는 조건에서 진행한 실험이라는 한계도 발표자가 설명했다.

이 부분에서 중요한 점을 배웠다. 장애가 발생한 뒤 설계한 경로대로 실행됐다는 것과, 다양한 실제 장애 상황에서도 안정적으로 복구된다는 것은 서로 다른 검증 결과다. 복구 경로가 정상적으로 작동하는지 확인하는 시험과 복구할 수 없는 상황을 확인하는 시험을 모두 고려해야 한다.

5. 장애 복구율만으로 시스템의 안정성을 판단할 수 있을까?

다른 팀들의 발표와 질의응답을 들으며 특히 관심이 갔던 부분은 장애 복구율과 실제 안정성의 차이였다.

복구율이 높으면 좋은 결과처럼 보이지만, 모든 장애를 자동으로 복구하는 것이 반드시 좋은 설계는 아니다. 잘못된 데이터가 전달되거나 위험한 상황을 정상으로 판단할 가능성이 있다면, 자동으로 계속 실행하는 것보다 중단하고 사람에게 알리는 편이 안전할 수 있다.

우리 팀의 어르신 돌봄 서비스에서는 이 문제가 더욱 중요하다. 예를 들어 바이탈 센서의 응답이 없을 때 이전 측정값을 활용할 수는 있지만, 그 값이 얼마나 오래된 데이터인지에 따라 판단의 신뢰성이 달라진다.

CCTV 분석이 실패했다고 해서 어르신에게 위험이 없다고 판단할 수도 없다. 영상에서 대상이 보이지 않는 상황은 실제 외출일 수도 있지만, 카메라 사각지대나 장비 오류 때문일 수도 있기 때문이다.

따라서 앞으로 이러한 시스템을 더 발전시킨다면 다음 사항을 명확하게 구분해야 한다.

• 자동 복구에 성공한 경우

• 대체 데이터나 대체 경로를 사용한 경우

• 복구에 실패해 사람에게 처리를 넘긴 경우

• 데이터가 오래되었거나 불확실해 판단을 보류한 경우

이러한 구분은 단순히 수치를 높이기 위한 것이 아니다. 시스템이 현재 어떤 상태인지, 그 판단을 얼마나 신뢰할 수 있는지 운영자가 이해할 수 있도록 만드는 데 필요하다.

6. 이번 프로젝트를 통해 달라진 생각

이번 프로젝트를 시작하기 전에는 멀티에이전트 시스템에서 여러 에이전트를 연결하고, 각각의 작업을 수행하게 만드는 데 관심이 컸다. 하지만 실제로 기능을 통합하고 장애 대응을 고민하면서 에이전트의 개수나 기능의 다양성만으로 시스템의 완성도를 판단할 수 없다는 점을 알게 되었다.

에이전트가 정상적으로 응답하더라도 결과가 잘못되었을 수 있고, 개별 기능이 정상이어도 연결 과정에서 데이터 계약이 맞지 않으면 전체 워크플로우는 실패할 수 있다. 오류를 복구했더라도 복구 결과가 유효하지 않다면 최종적으로는 성공했다고 보기 어렵다.

이번 프로젝트에서 새롭게 이해한 핵심은 세 가지다.

첫째, 멀티에이전트 시스템은 역할 분리만큼 역할 사이의 연결 규칙이 중요하다.

둘째, AutoHealing은 재시도 횟수보다 실패 원인에 맞는 대응과 복구 이후의 검증이 중요하다.

셋째, 안전한 시스템은 모든 오류를 자동으로 없애는 시스템이 아니라, 복구 가능한 오류와 사람의 개입이 필요한 상황을 구분하는 시스템이다.

7. 현재 나의 상태와 앞으로 보완할 부분

이번 미니프로젝트를 통해 멀티에이전트 시스템의 실행 흐름과 장애 복구를 연결해서 생각하는 경험을 할 수 있었다. 특히 AutoHealing을 구현할 때 개별 기능의 동작뿐 아니라 팀원 간 데이터 계약, 통합 이후의 실행 상태, 복구 결과의 검증까지 함께 고려해야 한다는 점을 배웠다.

다만 다양한 장애 상황을 체계적으로 분류하고, 각각의 복구 성공 기준을 명확하게 정의하는 부분은 계속 보완해야 한다. 정상적인 경우의 실행 결과만 확인하는 것으로는 충분하지 않으며, 데이터 누락이나 응답 지연, 잘못된 결과, 복구 불가능한 상황까지 고려해야 한다.

앞으로는 다음과 같은 방식으로 복습할 계획이다.

• 장애 유형별로 기대 결과와 실제 결과를 비교하기

• 재시도, 대체 경로, 안전 종료의 적용 조건을 구분하기

• 복구 성공 여부를 판단하는 검증 기준 정리하기

• 팀원 간 입력·출력 데이터 계약과 오류 응답 형식 확인하기

• Trace와 로그를 활용해 장애 발생부터 최종 처리까지의 흐름 추적하기

8. 3번째 미니프로젝트를 마치며

이번 미니프로젝트는 AI 에이전트를 연결해 기능을 만드는 것에서 한 걸음 더 나아가, 여러 기능이 함께 동작하는 시스템을 어떻게 안정적으로 운영할 것인지 고민하는 과정이었다.

어르신 돌봄이라는 주제에서는 잘못된 판단이 실제 안전 문제로 이어질 수 있기 때문에, 자동화의 범위와 한계를 명확히 하는 것이 중요했다. 다른 팀들의 발표에서도 도메인은 달랐지만 결과 검증, 대체 경로, 안전 종료, 실행 기록이라는 공통된 고민을 확인할 수 있었다.

이번에 배운 내용을 다음 프로젝트에서도 활용하고 싶다. 기능이 정상적으로 실행되는지만 확인하는 데서 멈추지 않고, 오류가 발생했을 때 어떤 일이 일어나는지, 복구 후에도 결과가 유효한지, 자동으로 처리할 수 없는 상황에서는 어떻게 대응해야 하는지까지 함께 설계하는 개발자가 되고 싶다.

핵심 정리

• 멀티에이전트 시스템은 에이전트 간 데이터 계약과 실행 흐름이 중요하다.

• AutoHealing은 재시도뿐 아니라 복구 결과의 검증과 안전한 종료까지 포함한다.

• 장애 복구율만으로 시스템의 안정성을 판단할 수 없다.

• 오래된 데이터와 불확실한 분석 결과는 별도로 관리해야 한다.

• 자동화의 한계를 인정하고 필요한 경우 사람에게 처리를 넘기는 설계가 중요하다.