61일차 회고｜AutoHealing·데이터 계약·통합 테스트｜AI 오케스트레이션 개발자 국비지원

1. 오늘 배운 내용

오늘은 팀 프로젝트에서 담당하고 있는 AutoHealing 기능의 진행 상황을 확인하고, 팀원들이 연결한 코드와 기존 구현 사이의 호환성을 점검했다.

AutoHealing은 시스템에서 오류가 발생했을 때 재시도하거나, 캐시 또는 대체 경로를 활용해 서비스가 정상적으로 동작하도록 복구를 시도하는 기능이다.

현재 팀 프로젝트는 어르신의 바이탈 정보, 실내 환경, 기기 상태, CCTV 분석 결과 등을 수집해 보호자에게 현재 상태와 필요한 조치를 안내하는 서비스를 개발하는 것이다. 나는 이 과정에서 조회나 실행 중 장애가 발생했을 때 대응하는 복구 기능을 담당하고 있다.

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

백엔드 테스트 431개가 통과한 것도 확인했다. 하지만 실제 연결 과정에서는 테스트 통과 여부만으로는 확인할 수 없는 문제가 드러났다.

2. 구현보다 먼저 맞춰야 했던 데이터 계약

오늘 가장 중요하게 배운 내용은 각 기능이 개별적으로 정상 동작하는 것과 여러 기능이 연결되어 정상 동작하는 것은 다르다는 점이다.

문제는 바이탈 데이터의 입력 조건에서 발생했다.

수집 API는 심박수와 측정 시각만 있어도 요청을 받을 수 있었다. 반면 내가 구현한 저장 함수는 혈압, 체온, 산소포화도까지 요구하고 있었다. API에서 전달받은 데이터를 그대로 저장하려고 하자 필수값이 누락되어 오류가 발생했다.

각 기능만 따로 확인했을 때는 문제가 없었지만, 실제로 연결하니 서로 기대하는 데이터 구조가 달랐던 것이다.

여기서 데이터 계약(Data Contract) 의 중요성을 이해하게 됐다. 데이터 계약은 기능 간에 주고받는 데이터의 형식, 필수 항목, 자료형, 누락값 처리 방식 등을 미리 약속하는 것이다.

예를 들어 다음과 같이 입력 조건을 명확히 정해야 한다.

확인 항목합의해야 할 내용

필수 항목	심박수와 측정 시각만으로 저장할 수 있는가?
선택 항목	혈압, 체온, 산소포화도는 누락될 수 있는가?
검증 기준	입력값의 자료형과 허용 범위는 무엇인가?
누락값 처리	값을 비워 둘 것인가, 저장을 거부할 것인가?
위험 판정	일부 바이탈만 존재할 때 어떻게 판단할 것인가?

특히 주의해야 할 부분은 누락된 수치를 임의의 정상값으로 채우지 않는 것이다. 데이터가 없다는 사실과 실제 측정 결과가 정상이라는 것은 전혀 다르다.

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

3. AutoHealing은 무조건 재시도하는 기능이 아니다

이번 작업을 통해 AutoHealing에 대한 이해도 달라졌다.

처음에는 오류가 발생하면 정해진 횟수만큼 다시 시도하는 것이 핵심이라고 생각했다. 하지만 실제 장애 대응에서는 오류의 원인을 구분하고, 원인에 맞는 복구 방법을 선택하는 것이 더 중요했다.

예를 들어 네트워크 연결이 일시적으로 끊겼다면 재시도가 도움이 될 수 있다. 하지만 필수 데이터가 누락되었거나 함수 사이의 입력 계약이 맞지 않는다면 같은 요청을 반복해도 문제가 해결되지 않는다.

장애 유형에 따라 대응 방식도 달라져야 한다.

장애 유형고려할 대응 방식

일시적인 네트워크 오류	제한된 횟수의 재시도
필수 데이터 누락	입력 검증 및 오류 반환
최근 데이터가 존재하지 않음	데이터 부재 상태를 명확하게 처리
데이터베이스 자체의 장애	DB에 의존하는 캐시가 아닌 독립적인 대체 경로 검토

특히 데이터베이스가 고장 났을 때 같은 데이터베이스에 저장된 캐시를 조회하려는 방식은 복구 수단으로 적절하지 않을 수 있다. 캐시가 DB와 동일한 장애에 영향을 받는다면 대체 경로로서의 역할을 수행하지 못하기 때문이다.

이 과정에서 재시도와 대체 경로는 모든 오류에 일괄적으로 적용하는 기능이 아니라, 장애 원인과 의존 관계를 고려해 선택해야 한다는 점을 배웠다.

4. 통합 테스트가 알려준 것

오늘 확인한 백엔드 테스트 431개가 통과했다는 사실은 의미 있는 진전이었다. 하지만 이번 데이터 누락 문제를 통해 테스트 결과를 해석하는 관점도 달라졌다.

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

개별 기능의 테스트가 통과하더라도 서로 다른 입력 조건을 가정하고 있다면 실제 연결 과정에서 문제가 발생할 수 있다.

이번 사례에서는 다음과 같은 검증이 필요하다고 느꼈다.

• 심박수와 측정 시각만 있는 데이터가 저장되는지 확인하기

• 일부 바이탈 정보가 누락된 경우에도 의도한 방식으로 처리되는지 확인하기

• 필수값 누락과 DB 장애가 서로 다른 오류로 구분되는지 확인하기

• 실제 Agent와 API를 연결했을 때 데이터가 기대한 구조로 전달되는지 확인하기

테스트 개수가 많다는 사실만으로 모든 상황을 검증했다고 볼 수는 없다. 어떤 입력과 장애 상황을 테스트했는지까지 살펴봐야 한다.

5. 협업에서 배운 점: 모호한 표현을 구체적인 계약으로 바꾸기

코드뿐 아니라 팀원에게 전달하는 문서도 중요하다는 사실을 느꼈다.

예를 들어 문서에 단순히 '재시도 3회'라고 적으면 최초 호출을 포함해 총 세 번 실행한다는 의미인지, 최초 호출 이후 세 번을 더 시도한다는 의미인지 불분명할 수 있다.

타임아웃도 마찬가지다. 한 번의 호출에 적용되는 제한 시간인지, 여러 단계를 포함한 전체 작업에 적용되는 제한 시간인지 구분해야 한다.

이처럼 같은 문장을 읽고도 서로 다르게 이해한다면 각자의 구현은 정상이어도 연결 과정에서 문제가 생길 수 있다.

앞으로는 다음 항목을 구체적으로 정의해 공유하려고 한다.

• 입력값: 필수 항목, 선택 항목, 자료형, 누락값 처리

• 재시도: 최초 호출 포함 여부, 최대 시도 횟수, 재시도 대상 오류

• 타임아웃: 개별 호출과 전체 작업의 제한 시간

• 실패 결과: 오류 반환 방식과 복구 실패 시 처리

• 구현 상태: 개인 구현 완료와 실제 기능 연결 완료의 구분

특히 코드를 작성하고 커밋한 시점과 다른 모듈에 연결한 뒤 검증한 시점을 구분해서 공유하는 것이 중요하다고 느꼈다.

6. 다음 작업과 복습할 부분

다음에는 부분 바이탈 데이터를 저장할 수 있도록 검증 로직과 DB 구조를 보완할 예정이다. 단순히 오류가 발생하지 않도록 만드는 데 그치지 않고, 데이터가 누락된 상황을 명확하게 표현하고 처리할 수 있도록 개선하는 것이 목표다.

우선 저장 단계와 위험 판정 단계의 기준을 팀원들과 맞추고, 어떤 항목이 필수인지부터 정리해야 한다. 이후 부분 데이터와 누락값을 포함한 테스트를 추가해 실제 연결 과정에서도 의도한 대로 동작하는지 확인할 계획이다.

개인적으로는 다음 내용을 복습할 필요가 있다.

1. SQLite에서 선택적 컬럼과 NULL을 처리하는 방법

2. API 입력 스키마와 DB 저장 함수의 데이터 계약을 일치시키는 방법

3. 재시도 대상 오류와 즉시 실패해야 하는 오류를 구분하는 방법

4. 단위 테스트와 통합 테스트의 검증 범위를 설계하는 방법

5. DB 장애 시 캐시와 대체 경로가 실제로 독립적인지 확인하는 방법

7. 오늘의 회고

오늘은 새로운 기능을 추가하는 것보다 이미 구현한 기능이 팀 프로젝트 안에서 제대로 연결되는지 확인하는 데 집중했다.

그 과정에서 개별 테스트를 통과한 코드라도 다른 모듈과 연결되면 입력 조건의 차이 때문에 오류가 발생할 수 있다는 사실을 직접 확인했다.

특히 AutoHealing을 구현할 때는 오류가 발생하면 무조건 재시도하는 것이 아니라, 오류의 원인이 일시적인 장애인지, 잘못된 입력인지, 복구 경로 자체의 문제인지 구분해야 한다는 점을 배웠다.

또한 협업에서는 코드의 완성도뿐 아니라 데이터 형식과 실패 처리 방식에 대한 합의도 중요하다. 서로 다른 기준으로 구현한 기능을 연결하려면 먼저 그 기준을 명확하게 맞춰야 한다.

아직 부분 바이탈 데이터의 저장과 검증 기준을 보완해야 하지만, 이번 문제를 통해 복구 기능의 범위뿐 아니라 기능 간 연결을 검증하는 과정까지 생각하게 됐다.

오늘의 핵심은 장애 복구보다 먼저 데이터 계약을 맞추고, 테스트 통과와 실제 통합 완료를 구분해야 한다는 것이다.

#AI오케스트레이션 #멀티에이전트 #AutoHealing #데이터계약 #통합테스트 #단위테스트 #SQLite #API개발 #예외처리 #국비지원개발자