시험 초기에 받은 결함 하나가 이번 인증의 방향을 정했습니다. 필수 입력값이 빠진 에이전트플로우를 실행하면 채팅 영역에는 "에이전트플로우 실행이 완료되었습니다"가 뜨고, 같은 화면의 로그 영역에는 빨간 오류가 찍혀 있었습니다. 두 영역이 서로 다른 이야기를 하고 있었고, 시험원은 이것을 "실행 결과 상태가 서로 일치하지 않음"이라고 적었습니다.
실행 파이프라인의 끝에서 완료 메시지를 내보내는 코드와 각 노드의 오류를 로그로 흘리는 코드는 서로를 모르고 있었습니다. 오류가 발생하면 채팅 영역에도 동일하게 오류 문구를 내보내도록 고치는 것은 어렵지 않았습니다. 어려웠던 것은 그다음이었습니다. 이런 불일치가 한 곳이 아니었습니다.
별표를 붙였다가, 뗐다가, 검증을 만들었습니다
필수 입력값 결함의 첫 대응은 각 노드의 필수 항목에 별표(*)를 표시하는 것이었습니다. 사용자가 무엇을 채워야 하는지 보이게 하자는 취지였고 2차 리포트 회신에도 그렇게 적었습니다. 그런데 6월 2일, 이 별표를 도로 제거했습니다. 별표는 "비우면 저장이나 실행이 막힌다"는 약속처럼 읽히는데, 그 약속을 지켜줄 검증 로직이 없었기 때문입니다. 표시가 검증보다 먼저 가면 오해를 만듭니다.
진짜 검증은 6월 12일에 실행 계층에 넣었습니다. 워크플로우 실행 요청이 들어오면 실행 전에 전체 노드를 훑어, required로 선언된 파라미터의 값이 비어 있는지와 required 입력 포트에 연결선이 없는지를 검사합니다. 누락이 있으면 실행을 시작하지 않고, 어느 노드의 어느 항목이 비었는지를 오류 문구에 담아 반환합니다. "잠시 후 다시 시도해주세요" 같은 문구로는 사용자가 무엇을 해야 할지 알 수 없다는 시험기관의 보완 요청을 그대로 반영한 것입니다.
검증 로직에서 공을 들인 부분은 오탐 방지였습니다. 0과 False는 비어 있는 값이 아니라 유효한 값으로 취급해야 하고, 다른 파라미터 값에 따라 화면에 나타나는 조건부 파라미터는 비활성 상태라면 required여도 검사에서 빼야 합니다. 검증이 과하게 엄격하면 이번에는 정상 플로우가 막혔다는 새로운 결함이 생깁니다. 별표는 그 뒤에야 다시 붙일 자격이 생겼습니다.
모든 실패가 같은 문장으로 보고되고 있었습니다
API 도구 저장이 실패하면 원인이 무엇이든 "도구 저장에 실패했습니다"가 떴습니다. 사용자 정보 편집이 거부되면 "사용자 정보 업데이트에 실패했습니다", 설정 초기화가 실패하면 "클라이언트 초기화에 실패했습니다"였습니다. 서버는 구체적인 원인을 반환하고 있었는데, 프론트엔드가 catch 블록에서 그 원인을 버리고 고정 문구로 바꾸고 있었습니다.
수정 자체는 서버와 통신 계층이 반환하는 오류 원인을 안내 문구에 함께 표시하는 것이었습니다. 이 패턴을 리포트에 적힌 화면만 고치지 않고 같은 구조를 쓰는 화면 전체에 적용했습니다. 고정 문구는 개발할 때는 깔끔해 보이지만, 문제가 생긴 순간에는 사용자와 지원 조직 모두의 시간을 태우는 비용이 됩니다.
성공으로 위장한 실패를 걷어냈습니다
더 조용한 유형도 있었습니다. 인증 프로필 API는 일부 실패 경로에서 HTTP 200을 반환하고 있었습니다. 화면에는 아무 문제가 없어 보이는데 저장은 되지 않는, 이른바 silent 200입니다. 5월 31일 핫픽스로 이 경로를 차단해 실패가 실패 코드로 나가게 했습니다.
스케줄 실행 이력에서도 같은 구조가 발견됐습니다. 실패 탭에 시스템 예외로 죽은 실행만 분류되고, 그 밖의 실패는 어디에도 나타나지 않았습니다. 실패로 분류하는 범위를 넓히고 마지막 실행 상태를 저장하는 컬럼을 추가해, 실패한 스케줄이 실패 탭에서 조회되도록 했습니다. JSON 형식이 잘못된 메타데이터를 조용히 저장하는 척하던 입력도 이때 함께 검증을 붙였습니다.
오류 처리는 예외 처리가 아니라 대화 설계였습니다
이 계열의 수정을 마치고 보니 공통점이 하나 있었습니다. 어느 것도 "예외를 못 잡아서" 생긴 결함이 아니었습니다. 예외는 잡혔고 로그도 남았습니다. 문제는 그 사실이 사용자에게 전달되는 마지막 구간에서 매번 뭉개졌다는 것입니다. 완료 메시지로, 고정 문구로, 200 응답으로.
실패를 숨기는 성공 메시지는 버그보다 나쁩니다. 버그는 고치면 되지만, 거짓 성공은 사용자가 자신의 조작을 의심하게 만들기 때문입니다. 다음 편에서는 이 관점을 옵션과 파라미터로 확장합니다. 설정을 바꿨는데 결과가 같아 보이면 왜 결함인지, 노드 파라미터 전수 점검에서 무엇이 나왔는지를 다룹니다.
이전 편 → 운영 중인 시스템의 비밀번호 해시를 argon2id로 바꾼 과정 (2편)
다음 편 → 설정을 바꿔도 결과가 같으면 결함입니다 (4편)