① 어떤 상황에서 AI를 활용했나요?

항공기 정비 현장에서 10종류의 엑셀 파일을 병행 관리했습니다. 비행이 끝나면 비행시간과 비행사이클을 여러 파일에 옮겨 적고, 현장에서 작성한 메모는 사무실에서 다시 입력했습니다. 과거에 같은 증상을 어떻게 조치했는지 찾으려면 기억에 의존해 연도별 작업지시서를 한 장씩 살펴봐야 했습니다. 항공기 복귀 시각도 휴대폰 항공추적 앱으로 수시로 확인했습니다.

불편한 점은 알았지만 직접 프로그램을 만들 개발 역량은 없었습니다. 대신 정비 절차와 계산 기준, 반드시 확인해야 할 사항은 설명할 수 있었습니다. 그 기준을 AI에 전달해 AMMS(Aircraft Maintenance Management System)를 만들고, 계산 결과는 제가 직접 검산했습니다.

개발하면서 ‘쓰지 못할 데이터는 만들지 않는다’는 원칙을 세웠습니다. 화면에 숫자를 많이 보여주기보다 다음에 어떤 점검이나 부품을 준비해야 하는지 알려주는 기록이 필요했습니다. 문서 작성 시간을 줄이고, 쌓인 기록을 반복결함 검토와 정비 일정 준비에 활용하고자 했습니다.

② 어떤 AI를 어떻게 활용했나요?

AI는 시스템을 만드는 과정과 완성된 시스템 안에서 각각 활용했습니다.

시스템을 만들 때 Claude로 기능을 구현하고 Codex로 코드를 검토했습니다. 비행시간·사이클 누계 계산법, 점검 주기별 다음 도래일 산정 기준, 작업지시서 종결 시 함께 갱신해야 할 이력 등을 먼저 설명했습니다. 구현 결과를 기존 엑셀 계산값과 대조하고, 값이 다르면 제가 확인한 계산 근거를 제시해 수정했습니다. 업무 규칙이 불분명할 때는 AI가 추정하지 말고 저에게 묻도록 했습니다. 사용한 기술은 React·Vite, Python FastAPI, SQLite, Claude API입니다.

시스템 안에서는 AI를 네 가지 업무에 사용합니다.

1. 사진·메모로 작업지시서 초안 작성 - 현장 사진과 메모를 입력하면 작업 제목과 ATA 계통 분류 초안을 제안합니다. 실제 수행내용과 부품 정보는 담당자가 확인해 입력합니다.
2. 정비이력 검색과 요약 - 자연어로 질문하면 관련 작업일, 조치내용, 사용부품을 요약하고 근거가 된 작업지시서 번호를 함께 보여줍니다. 기록에서 확인되지 않는 내용은 없다고 표시하도록 했습니다.
3. 기록 간 관계 후보 제시 - 서로 다른 기록이 관련돼 있을 가능성을 제시합니다. 반복결함에 해당하는지는 담당자가 원문을 대조해 판단합니다.
4. AD/SB 검토서 초안 작성 - AD(감항성개선지시서)와 제작사 기술회보(SB/SL)에서 적용조건, 요구조치, 기한을 추출해 기존 양식의 검토서 초안을 만듭니다. AD는 관련 기관 사이트에서 수집한 문서를 사용하고, SB/SL은 제작사에서 전달된 파일을 사용합니다. 항공기 적용 여부와 필요한 조치는 담당자가 판단합니다.

누계 계산, 점검 도래 판정, 복귀 알림, 반복 발생 탐지, 비행 이벤트 정리와 자재 부족 확인은 정해진 규칙에 따라 동작합니다. AI는 기록을 해석하고 초안을 만들며, 프로그램은 계산하고 집계합니다. 최종 확인과 판단은 정비사가 맡습니다.

③ 활용 결과 어떤 변화가 있었나요?

항공기 위치를 반복 확인하며 기다리던 시간을 정비 준비에 쓸 수 있게 됐습니다. 설정한 거리·고도 조건에 도달하면 알림을 받고 급유와 정비지원을 준비합니다. 격납고와 계류장에서는 휴대폰으로 비행시간·사이클 누계와 일정을 확인하고, 결함 메모와 사진을 작업지시서 초안으로 남깁니다. 사무실에서 같은 내용을 다시 입력하는 과정도 줄었습니다.

업무에 걸리는 시간도 감소했습니다. 아래 수치는 별도 측정 도구로 집계한 결과가 아닌, 제가 AMMS를 사용하며 추정한 평균입니다.

- 월간 정비실적보고: 120분 → 30분 (약 75% 감소)
- 작업지시서 작성: 6분 → 1분 (약 83% 감소)
- 비행실적 정리: 15분 → 3분 (약 80% 감소)
- 과거 이력 확인: 15분 → 2분 (약 87% 감소)

기록을 찾고 비교하는 방식도 바뀌었습니다. 현재 AMMS에는 작업지시서 1,507건, 7년간의 일일 운항실적 674건, 결함 94건, 결함 관련 부품 사용·교환 기록 133건이 저장돼 있습니다. 이는 AI 처리 건수가 아닌 저장된 기록의 규모입니다. 같은 부품에서 결함이 몇 차례 발생했는지, 발생 간격은 얼마인지, 이전에 어떤 조치를 했고 이후 재발했는지를 원문과 함께 확인할 수 있습니다. 긴 간격을 두고 다시 발생한 결함도 과거 조치와 대조해 다음 점검에 참고합니다.

항공기 비행데이터 분석 기능도 추가했습니다. 비행 중 결함 메시지가 발생한 시각을 기준으로 당시 항공기의 고도·속도·엔진·전기계통 상태와 신호 변화를 함께 확인하고 기록합니다. 정비사는 이 정보를 과거 결함 이력과 대조해 증상이 비슷한 사례를 찾고, 어떤 비행 구간과 계통을 먼저 살펴볼지 정합니다. 같은 시점에 변한 신호를 곧바로 원인으로 판단하지는 않습니다. 대신 검토에 사용한 시각과 데이터를 남겨 이후 고장탐구에서 다시 확인할 수 있게 됐습니다.

예정 작업에 필요한 부품의 재고가 부족하면 미리 표시합니다. 재고로 보유하지 않는 고가 부품은 작업 90일 전부터 필요 여부를 확인해 제작사 요청을 준비합니다. 아직 자재 부족으로 인한 운항 차질이 얼마나 줄었는지 수치로 평가하지는 않았지만, 신청 시점을 놓치지 않도록 돕고 있습니다.

④ 나만의 방식 또는 개선 포인트는 무엇인가요?

첫째, 정비사가 알고 있는 업무 기준부터 정리했습니다. AI에 기능 구현만 요청하기 전에 어떤 값을 어디서 확인하고, 업무에 따라 계산과 분류 기준이 어떻게 달라지는지 설명했습니다. 예를 들어 같은 타이어 교환이라도 마모로 인한 교환은 결함 조치이고, 휠 비파괴검사 주기에 따른 교환은 계획정비입니다. 이를 구분하지 않으면 반복결함 통계가 실제 상황을 반영하지 못합니다.

둘째, AI가 만든 결과를 자동으로 확정하지 않았습니다. AI는 초안과 후보를 제시하고, 담당자가 원문과 현장 사실을 대조해 결정합니다. 원본 기록은 보존해 판단 근거를 다시 확인할 수 있도록 했습니다. 서명된 종이 문서가 공식 정비기록이며, AMMS는 기록의 작성·검색·분석·집계를 돕는 시스템입니다.

셋째, 화면에 표시하는 데이터가 실제 업무에 쓰이는지 확인했습니다. 점수나 그래프를 추가하기 전에 그 정보를 보고 정비사가 무엇을 확인하거나 준비할 수 있는지 생각했습니다. ARES 비행데이터도 결함 메시지가 언제 발생했고 그 시점의 항공기 상태와 신호가 어땠는지를 보여줍니다. 원인과 조치는 다른 정비 근거까지 함께 검토해 정비사가 판단합니다.

지금도 기존 방식과 AMMS를 병행하며 계산값, 기록, 출력물을 대조하고 있습니다. 2027년까지 정확성과 안정성을 계속 확인할 계획입니다. 현재는 결함 원인을 예측하거나 부품 신뢰성 향상을 입증한 단계가 아닙니다.

⑤ 다른 사람도 따라 할 수 있나요?

저도 개발자가 아니었기 때문에 반복되는 업무 하나부터 시작했습니다. 기존 양식을 유지하면서 처리 순서와 확인 기준을 AI에 설명하고, 답을 이미 알고 있는 사례로 결과를 대조했습니다. 값이 맞으면 기존 방식과 병행해 사용 범위를 넓히고, 다르면 계산 근거를 확인해 수정했습니다.

이 방식에서 중요한 것은 업무 담당자의 검증입니다. AI가 문서를 해석하고 초안을 작성하더라도, 계산 기준과 현장 사실을 아는 사람이 결과를 확인해야 합니다. AMMS도 기록 통합에서 시작해 모바일 입력, 정비이력 검색, AD/SB 검토서 초안, ARES 비행데이터 분석과 사전 정비 준비로 범위를 넓혀왔습니다.

설비·장비·검사처럼 점검 기준과 과거 이력이 중요한 업무에도 이런 개발 과정은 참고할 수 있다고 생각합니다. 저에게 가장 큰 변화는 현장의 불편을 말하는 데서 그치지 않고, 직접 기능을 만들어 실제 기록과 대조할 수 있게 된 점입니다.