심사관이 묻는 건 기능이 아니라 판단이었다.

"A 알고리즘 지금 어느 단계예요?"

바로 답하지 못했습니다. 머릿속으로는 알고 있었지만, 정확히 정리된 건 아니었습니다. 서류 마감 하루 전에 빠진 항목이 발견된 적도 있었습니다. 그때 깨달았습니다. 성실함의 문제가 아니라 구조의 문제였다는 걸.

리밸런싱이 있는 날에는 하루가 통째로 사라졌습니다.

전략별 매매 실행, 체결 확인, 결과 검증. 빠뜨릴 수 없지만 반복적인 작업이 시간을 잡아먹었습니다. 병목 지점을 분석하고 자동화 대상을 선별해 개발팀에 요건을 전달했습니다. 이후 리밸런싱 소요 시간은 하루 → 1~2시간으로 줄었습니다.

"투자성향 질문지의 설계 근거와 점수 체계의 산정 로직을 설명해주세요."

퇴직연금에 편입되는 상품이기 때문에, 투자자 성향을 분류하는 질문지가 필수였습니다. 심사관은 결과물이 아니라 그 뒤의 설계 논리를 물었습니다.

업계에서 쓰이는 다양한 투자성향 설문을 비교 분석한 뒤, 공통 항목을 추출하고 투자자의 리스크 허용 범위를 직관적으로 판별할 수 있는 문항 구조로 재설계했습니다. 점수 산정도 같은 벤치마크 기반으로 설계 근거를 제시했습니다.

개발자용 흐름도를 심사관에게 보여줬습니다. DB 스키마, API 엔드포인트, 큐 시스템.

잠깐 정적이 흘렀습니다. 그 몇 초가 꽤 길게 느껴졌습니다. 처음부터 다시 설명해야 했습니다. 그 뒤로 같은 로직을 심사관용 프로세스 다이어그램으로 다시 그렸습니다. 시장 데이터 → AI 분석 → 포트폴리오 → 리밸런싱 → 주문. 각 단계에 자동/수동 마커와 예외 경로를 표시했습니다.