문제를 자동화 대상으로 보기 전에, 사람이 왜 그 일을 계속하고 있는지부터 확인합니다.

1. 관찰과 문제 정의

직접 광학계를 조립하며 “측정이 진행되는 동안 왜 사람이 계속 옆에 있어야 하는가”를 출발점으로 삼았습니다. 작업자의 전문 판단이 필요한 구간은 초기 세팅과 결과 확인이었고, 중간 지그 교체와 정형 데이터 기록은 반복작업이었습니다.

2. 물리적 제약부터 확인

• 듀얼레인 장비는 지그 3개를 컨베이어에 연속 투입할 수 있었습니다.
• 싱글레인은 물리적으로 지그 교체가 필요해 자동화 대상에서 제외했습니다.
• 광학계 벤더가 2곳이었고 다른 벤더 제품은 추가 캘리브레이션이 필요해 전면 적용하지 않았습니다.
• 기존 보고양식을 바꾸면 현장과 품질 기록의 전환 비용이 생기므로 출력 형식은 그대로 유지했습니다.

3. 실행 가능한 최소안

고정된 지그 크기를 기준으로 전용 출력 모드를 기획하고, Head를 고정 좌표로 이동해 Anchor를 확인한 뒤 지그별 캘리브레이션을 수행하도록 구성했습니다. 결과는 기존 Excel 보고양식에 맞게 정제해 내보냈습니다.

영향범위는 4개 파일이며 캘리브레이션 모드에서만 동작해 일반 장비 구동에는 영향을 주지 않았습니다. 개발자에게 범위와 위험을 설명해 허가를 받은 뒤 AI coding agent를 활용해 직접 구현했습니다.

4. 운영 중 실패 ① 컨베이어 조립오차

지그 삽입 시 컨베이어가 벌어져 캘리브레이션이 실패했습니다. 자동화 로직의 실패로 끝내지 않고 컨베이어 조립이 허용 오차 안에 있는지 먼저 확인해야 한다고 판단했습니다.

• 컨베이어에 Anchor 이미지를 추가했습니다.
• 캘리브레이션 진입 전에 Anchor 위치를 확인했습니다.
• 조립 상태가 오차범위를 벗어나면 측정을 시작하지 않도록 차단했습니다.

5. 운영 중 실패 ② 뚜껑 미장착과 공장 조명

조립 순서상 뚜껑 센서를 설치하기 전에 캘리브레이션을 수행하는 경우가 있어 공장 조명이 유입됐습니다. “뚜껑을 먼저 닫으라”는 절차를 추가하면 실제 조립 순서와 충돌하므로, 사람의 기억 대신 환경조건을 측정하게 했습니다.

• 캘리브레이션 진입 전 광량을 측정했습니다.
• 상한 초과 시 “광량이 초과됩니다. 암실에서 진행해주세요”를 표시했습니다.
• 하한 미달 시 “광량이 부족합니다. Project 설정을 점검해주세요”를 표시했습니다.
• 정상 범위에서만 캘리브레이션을 시작했습니다.

1. 인간이 남기는 최소 입력

QA는 스크린샷에 TC와 간단한 제목을 남기고 아래 고객영향 중 무엇인지 빠르게 판단합니다.

• 프로그램 또는 기능이 켜지지 않는가
• 원본과 화면 데이터가 다른가
• 업무 단계가 꼬이거나 다음 단계로 갈 수 없는가
• 금액·수량·정산에 영향을 주는가
• 기능은 되지만 시각적으로 잘못됐는가
• 핵심 CTA를 찾지 못해 고객이 이탈할 수 있는가

2. Agent가 받아서 하는 일

• 회사 표준 제목, 제품·버전·컴포넌트와 TC를 연결합니다.
• 사전조건·재현절차·Actual·Expected·발생빈도·증적을 구성합니다.
• 회사 Severity 규칙과 고객여정 위치를 이용해 우선순위 초안을 만듭니다.
• 유사 Jira를 검색해 중복 후보와 공통 원인을 묶습니다.
• 최종 QA 승인 이후에만 Jira에 등록합니다.

3. 자동화 이후 드러난 새로운 병목

문서화 병목이 사라지자 실제로 존재하던 이슈가 한꺼번에 개발팀으로 전달됐습니다. 품질이 갑자기 나빠진 것이 아니라 이전에는 사람이 작성할 수 있는 수만 보였던 것입니다. 그러나 모든 이슈를 같은 속도로 발사하면 Critical이 UI Minor에 묻히고 개발팀이 우선순위를 잃었습니다.

• 실행불가·보안·데이터손상·금전·핵심여정 차단은 즉시 개별 발사
• 우회 가능한 기능·성능·조건부 오류는 정기 배치
• 공통 컴포넌트 UI·문구 문제는 원인 또는 화면 기준으로 묶음
• 개인 취향 가능성이 높거나 기획 의도가 불명확하면 개선안으로 보류

4. 목표 KPI를 문서시간이 아니라 루프 회전수로 정의

자동화의 구매 대상은 “Jira 문서를 대신 쓰는 AI”가 아니었습니다. 오전에 이슈를 전달하고, 개발 패치가 나오면 당일 다시 설치·검증·재오픈해 수정–검증 루프를 하루에 더 많이 돌리는 능력이었습니다.

1. 앞단을 바꾸지 않기로 결정

사용자가 보던 결재와 Excel 양식은 그대로 유지했습니다. Agent와 정형 스크립트는 승인된 원문을 읽고, Excel COM 자동화가 기존 대장을 갱신하도록 배치했습니다.

2. 책임 경계를 단계화

ERP API 수정과 인사 DB SSO 권한은 만일의 사고를 우려해 HR이 반대했습니다. 우선 COM 방식으로 3개월 운영하고 문제점이 발견되지 않으면 경영본부장 협의 아래 API를 순차 검토하기로 했습니다.

3. 비정형 입력도 운영 데이터로 전환

사용자가 “07월 14일” 대신 “77월 14일”, “007/14”처럼 입력했지만 결재가 완료된 사례 등 비정형 날짜 6건이 발견됐습니다. 자동화를 실패로 보지 않고 기존 수기 과정에서 허용되던 데이터 오류를 가시화한 것으로 보고 파서와 Validator를 보완했습니다.

4. 채택을 설득이 아니라 사용결과로 얻음

처음부터 API 전환을 요구하지 않았고, 3개월간 기존 방식 안에서 안정적으로 시간을 줄였습니다. 이후 HR이 경영본부장에게 “API를 연결하면 어디까지 가능한지 정리해 달라”고 먼저 요청했습니다.

1. 병행검증

기존 수기 결과와 자동화 결과를 동일 증적 기준으로 병행했습니다. 결과가 다른 사례를 조사했을 때 자동화 오류가 아니라 수기 생성 시 누락된 항목임이 3회 이상 확인됐습니다.

2. 검토 방식 변화

자동 결과를 전부 다시 계산하면 자동화의 의미가 없으므로, 신뢰가 쌓인 뒤 사용자가 랜덤으로 2~3건을 뽑아 증적과 계산을 확인하고 결재하는 방식으로 바뀌었습니다.

3. 적용 범위 제한

공식 운영은 초과근무와 야간교통비부터 시작했습니다. 다른 재무 업무는 약 3개월의 운영 결과와 예외 유형을 검토한 뒤 확대하기로 했습니다.

1. 현장에서 질문을 구현 규칙으로 닫음

자사 검사기에는 여러 MES와 연동하기 위한 표준 데이터 발생지점과 문서가 있었습니다. 따라서 새 프레임워크를 만들기보다 그 데이터가 발생하는 시점에 ITAC JSON으로 매핑해 RESTful API Wrapper로 고객 내부 Node 서버에 전송하면 됐습니다. 어려운 부분은 코드보다 데이터의 업무 의미였습니다.

• 이미지 저장 완료 시점을 검사 완료로 보내도 되는가
• Review Station에서 판정이 바뀌면 어느 시점에 다시 보내는가
• 재검사 시 Serial을 새로 만들지 기존 이력에 Revision을 추가하는가
• ACK 지연·통신 실패·중복 전송을 어느 시스템이 재처리하는가

2. 구두 합의를 휘발시키지 않음

현장 담당자에게 현재 자사 시스템의 동작과 선택지를 제시해 답하기 쉽게 만들었습니다. 협의 내용을 동의 아래 기록하고 당일 확인 메일로 보내 “제가 이해한 내용 중 틀린 부분”을 수정받았습니다. 다음날 다시 묻는 대신 같은 자리의 기억을 서면 기준으로 바꾸는 방식이었습니다.

3. 문서가 아니라 실제 연동으로 증명

협의 내용을 JSON 매핑과 호출시점으로 정리해 검사기 SW 패치에 반영하고, 고객 테스트라인에 설치해 실제 ITAC 송수신을 검증했습니다. 출장 6일 만에 1차 연동 확인을 받았습니다.

4. 고객 보안 규정을 지킨 국내 재현환경

현장 PCB를 그대로 반출하면 완제품 ECU 정보 노출과 소송 위험이 있었습니다. 고객 공장장과 보안 담당 C-level의 서면 승인을 받고, 컨포멀 코팅 검증과 무관한 민감 MLCC·CSP와 좌표정보를 제거한 4개 유형·12개 샘플을 반출했습니다.

5. 확보한 샘플로 범위를 넘어선 결함 발견

국내에서 실제 샘플로 컨포멀 코팅 알고리즘을 반복 검증하던 중 메모리 누수로 장비가 다운되는 문제를 발견했습니다. 이를 수정해 ITAC 기능 추가 패치와 함께 반영했습니다.