제7회와 제8회에서 전달해 드린 '솔라리스(Solaris)'와 '월면 탐사 로버(Lunar Exploration Rover)' 두 프로젝트는 사실 내부적으로 완료까지 7시간 전후부터 7시간 반 이상이라는 긴 시간이 소요되었습니다.
'AI에게 맡기고 있는데, 왜 이렇게 오래 걸리는 걸까? 어딘가에서 무한 루프나 버그가 발생하지 않았을까?'
이렇게 의문이 들자 저는 AI 스스로 과거 작업 로그를 철저히 조사하게 하고, 지연의 이유와 버그 유무를 HTML 리포트로 시각화하도록 했습니다.
우선 개발 과정에서 시간 비교의 기준이 되었던 형상(造形) 시간 비교 이미지와 솔라리스의 모델/경로 전체도를 참고해 주십시오.
조사용 집계 스크립트나 생성된 HTML 형식의 지연 조사 리포트는 모두 아래 GitHub 리포지토리에 공개했습니다.
먼저 두 메인 스레드의 세션 ID를 지정하여, 그 원인을 있는 그대로 요청했습니다.
01a1cacb-987e-7612-a47b-152e856122fd / 01a1cb1a-7a36-72e2-8a9b-4471d813553a에서 엄청 오래 걸렸습니다. 왜일까요?
게다가, 글자만으로는 전체 타임라인을 파악하기 어려우므로 리포트의 시각화도 부탁했습니다.
AI는 작업 로그(JSONL 형식의 이벤트 히스토리)를 분석하는 집계 스크립트를 작성했고, 중복 구간을 제거한 실측 타임라인을 집계하여 HTML 형식의 지연 조사 리포트를 만들어 주었습니다.
로그를 정밀하게 집계한 결과, '방치되어 있던 공백 시간'이 아니라 실제로 방대한 추론(Inference)과 검증(Verification) 작업이 진행되고 있었다는 것이 수치로 명확해졌습니다.
| 항목 | 솔라리스 | 월면 탐사 로버 |
|---|
| 전체 DR 작업 구간 | 약 6시간 50분 (마감 시점 기준 R05 수정 중) | 약 7시간 31분 (R11에서 DR0~4 통과) |
| ... | | |
| ※전체 부모 스레드에서는, 서브 에이전트의 구동 요청이 41회 (시작 확인은 40회), 에이전트 간 연락은 497회 (마감 재집계 시 498회)에 달했습니다. | | |
시간이 오래 걸렸다는 사실 자체는 알았지만, 가장 알고 싶은 것은 '그 7시간 반이라는 시간이 의미 있는 시간이었는지, 아니면 쓸모없는 버그로 공전하고 있었는지?' 하는 점입니다. 그래서 다음과 같이 구분을 요청했습니다.
제대로 리뷰되고 수정 루프가 길다면 괜찮아요! 별난 버그 같은 건 있나요?
이 질문에 대해 AI는 조사 결과를 **'건전한 설계 리뷰/수정 루프(Healthy Design Review/Correction Loop)'**와 '분석 코드나 입력 데이터의 버그(Bug in Analysis Code or Input Data)' 두 가지로 깔끔하게 나누어 보고했습니다.
결론적으로, 무한 루프나 데드락(Deadlock)의 증거는 발견되지 않았습니다.
로버가 R00부터 R11까지 12번이나 버전을 거친 것은, 최초 CAD 부품 간 간섭(Interference), 약 0.6 mm 두께의 얇은 축받이(Bearing), 너트가 빠지는 것을 방지하는 고정 방향 오류, 통로 바닥 지지력 부족 후보 등 실제 설계 결함을 리뷰를 통해 발견하고 수정하여 재심사하는 루프가 올바르게 작동했기 때문입니다.
솔라리스 측도 도중에 '60 mm로의 치수 확정', '서포트 축소(BEN 지견)', '100% 충전과의 비교' 같은 사양 확장(Specification Extension)이 추가된 것이 작업 범위를 넓힌 큰 요인이었습니다.
하지만 모든 과정이 건전한 루프만은 아니었고, 막을 수 있었어야 할 구현 버그나 입력 데이터의 불일치가 3건 발견되었습니다.
솔라리스의 분석 조건이 메쉬(Mesh)마다 달랐음- 구조 해석에서 메쉬를 세밀하게 하여 수렴성(Convergence)을 확인할 때, 하중 면적(15.8288 / 15.6190 / 15.0948 mm²), 고정 조건 선택, 재료 할당이 메쉬마다 달랐습니다. 같은 조건으로 비교가 이루어지지 않아 수렴 판정과 수정 작업을 불필요하게 반복하는 원인이 되었습니다.
로버의 분석 코드에 참조 오류가 있었음- R11 최종 패키지를 Kaggle에서 계산할 때, 계기판 접합 정보 읽기 오류로 인해 한 번 멈추는 일이 있었습니다(다만 수정 후 재실행 완료까지는 약 5분 40초였으며, 7시간 반 전체의 주원인은 아니었습니다).
솔라리스 R05의 하중면이 색 경계로 분할되어 있었음- CAD상으로는 유효한 형상이지만, 색 경계 때문에 15.6 mm²의 하중면이 두 개로 나뉘어 있어 그대로 분석 입력으로 사용할 수 없는 문제가 발생했습니다.
이번 자체 조사를 통해 AI에 의한 자율 설계 및 심사 워크플로우의 병목 지점(Bottleneck)이 명확하게 드러났습니다.
해석을 투입하기 전 '입력 검사'를 자동화하기 - 메쉬 간 하중 면적이나 고정 조건이 일치하는지, 하중면이 단일 평면인지 등을 계산 작업에 투입하기 전에 자동으로 체크만 해도 불필요한 재계산 루프를 대폭 줄일 수 있습니다.
조립/형상 검사를 초기 단계로 앞당기기 - 나사/너트의 삽입 경로나 층별 지지 부족 등을 CAD를 만든 직후 통합 검사에 포함해 놓으면, 후반부에 R09 → R10 → R11 순서로 재작업하는 수고를 줄일 수 있습니다.
'AI 에이전트에게 장시간 작업을 맡긴 후, 로그에서 어디에 몇 분을 사용했는지 분석하게 하는' 방식은 다른 AI 개발 프로젝트에서도 그대로 응용할 수 있습니다. 이번 흐름을 따라 하려면 다음 3단계로 프롬프트를 던지는 것이 좋습니다.
우선 솔직하게 시간을 묻기 : '이 작업에 시간이 걸리는 이유는 무엇인가?'라고 로그 집계를 요청합니다.
- HTML 등으로 시각화시키기 : 'html 등으로 시각화해 달라'고 부탁하여 타임라인이나 내역을 목록으로 볼 수 있게 합니다.
- 건전한 루프와 버그를 구분하기 : '제대로 된 검토나 수정 과정에서 오래 걸린 건지, 이상한 버그나 공회전이 있었는지?'라고 질문하여 개선해야 할 구현 실수만 걸러냅니다.
집계용 스크립트나 HTML 리포트의 실제 예시는 맨 앞의 GitHub 레포지토리에서도 확인할 수 있습니다.
이번에는 Solaris와 달 탐사 로버 개발에 7시간 반 이상이 걸린 이유를 AI 스스로 로그 조사 및 시각화를 하게 한 결과를 전해드렸습니다.
- 메인 스레드의 Reasoning 구간만으로도 Solaris가 약 3시간 59분, 로버가 약 4시간 44분이 작동했으며, 무한 루프는 없었습니다.
- 장시간화의 대부분은 '결함 발견 → 수정 → 재심사'라는 건전한 설계 루프와 사양 추가에 의한 것이었습니다.
- 한편으로는 메쉬별 해석 조건 불일치 등의 버그 3건도 특정할 수 있었고, 초기 입력 검사를 강화해야 한다는 교훈을 얻었습니다.
AI에게 제조를 맡기는 것뿐만 아니라, '왜 시간이 걸렸는지', '버그는 없었는지'까지 AI 스스로 감사하게 함으로써 개발 프로세스 자체를 점점 더 똑똑하게 만들 수 있다는 느낌을 받았습니다!
