현장 관찰부터 시작
문서에 적힌 표준보다 작업자가 실제로 반복·대기·우회하는 순간을 먼저 봅니다. “큰 문제 없으니 그냥 하자”는 업무도 생산량과 전문인력 투입 관점에서 다시 계산합니다.
Resume Summary · AX Portfolio
현장의 반복을 운영 가능한 시스템으로 바꾸는 AX Engineer
사람에게 절차를 더 외우게 하지 않고, 시스템이 시작 조건·예외·증적을 확인하게 합니다.
3D AOI 생산공정, 글로벌 고객 연동, 릴리즈 운영, QA, HR, 재무에서 사람이 계속 붙어 있어야 하거나 담당자의 기억과 책임에 의존하던 업무를 개선했습니다. 새 화면을 강요하기보다 기존 지그·보고서·PR·스크린샷·전자결재·Excel을 입력으로 활용하고, 자동화 결과는 사람의 리뷰와 정적 Validator로 통제합니다.
Manufacturing AXAgentic WorkflowProcess AutomationHuman-in-the-loopQuality GateChange ManagementAudit Trail
Profile
자동화 도입이 아니라, 지속 가능한 업무 흐름을 설계합니다.
PoC 데모보다 실제 운영, 자동화율보다 적용 경계, 편리함보다 원복·증적·책임 구조를 우선합니다.
앞단 변화 최소화
작업자에게 새 화면과 입력을 추가하기보다 기존 지그, Excel, 전자결재, 스크린샷을 그대로 사용하게 하고 자동화 계층을 뒤에 배치합니다.
작게 실행하고 원복 가능하게
물리적 제약과 영향 범위를 확인해 적용 가능한 구간부터 시작합니다. 일반 운전과 분리된 모드, 기존 양식 호환, Warning 기간을 통해 실패 비용을 제한합니다.
운영 실패를 Gate로 전환
적용 후 발생한 조립오차·환경광·비정형 입력을 개인 실수로 끝내지 않고 다음 실행 전에 시스템이 확인하는 Anchor·광량·Validator 규칙으로 바꿉니다.
Case Studies
제조·개발·QA·경영지원에서 반복한 문제 해결 방식
Case 01 · Manufacturing AX
3D AOI 광학계 캘리브레이션 공정 자동화
약 1시간 동안 작업자가 지그를 교체하고 결과를 기록하던 공정을, 듀얼레인 지그 연속 투입·고정좌표 이동·Anchor 확인·자동 데이터 출력 방식으로 전환했습니다.
- 적용 가능한 광학계 약 60%부터 제한 적용
- 영향 범위 4개 파일·캘리브레이션 모드로 격리 후 직접 구현
- 운영 중 조립오차와 환경광 실패를 사전검증 Gate로 보완
주 6시간 이상·15% 여력 확보, 연구소 지원 분기 4~5회 → 0~1회
상세 구조 보기Case 02 · Manufacturing AX / AI Native
독일계 글로벌 부품사 AOI–MES 통합 시뮬레이션 및 지속개선 환경
기존 MES 시뮬레이터의 소켓 프로토콜 호환성 문제를 해결하는 대체 시스템을 개발하고, Loader·AOI·Repair Station을 연계해 실제 생산공정의 80% 이상을 재현했습니다.
- MES 연동 결함 41건을 배포 전 발견, 패치 후 고객 불만 일 2~3건 → 0건
- 반복 VOC 7~8종을 사내 재현해 현장·개발 대응공수 분기 약 40시간 절감
- QA·비개발자가 Codex Agent로 개선안을 만들고 Dev MES에서 즉시 동작 확인
- 장비 화면 전·후 2프레임, 그림판 표시, 자연어 설명과 작업 의도를 멀티모달 입력으로 결합
실제 공정 80%+ 재현 · 결함 41건 선제 발견 · 고객 불만 0건 · 출장 4~5회 → 1회
상세 포트폴리오 펼치기 — 문제, 멀티모달 입력, Dev 검증과 Main 병합
1. 기존 검증환경의 한계
제공된 MES 시뮬레이터는 실제 현장에서 처리하던 메시지 접두어·프레이밍 규칙을 동일하게 처리하지 못했고, 실행 파일 형태라 내부 수정도 불가능했습니다. 그 결과 바코드 입력, MES 검색, PCB 생산라인 모델 변경 등 실제 공정에 필요한 외부 상호작용 대부분을 사내에서 검증할 수 없었습니다.
2. 대체 시뮬레이터와 생산라인 재현
개발팀이 제공한 연동 설명, 예시 데이터와 규약을 기준으로 웹 서버와 소켓 텔레그램 요청·응답 처리를 구현했습니다. 이후 Loader와 Repair Station을 연결해 보드 투입 대기, 검사 중 전·후단 순서, Repair Station 공간 부족, Repair Plus 상호작용 등 공정 예외까지 포함한 실제 생산흐름의 80% 이상을 재현했습니다.
3. 비개발자·QA를 위한 멀티모달 개선 입력
원격지 사용자가 문제를 발견한 즉시 시뮬레이터 Agent와 상호작용해 해결안을 만들 수 있도록 장비 화면의 문제 발생 전·후 2개 프레임을 입력으로 사용했습니다. 사용자는 그림판으로 의심 영역에 동그라미나 화살표를 표시하고, 자연어로 현상과 원래 수행하려던 작업 의도를 설명했습니다. 멀티모달 Agent는 두 화면의 변화·시각적 표시·사용자 설명·작업 의도를 함께 읽어 MES 신호, 설비 상태와 공정 순서를 추론하고 시뮬레이터 수정안을 구현했습니다. 해결안은 사용자 개인 환경에서 끝내지 않고 GitLab Dev 브랜치에 커밋해 개발 MES와 즉시 연동 검증했으며, 개발자가 지속 가능한 변경인지 검토하고 필요한 예외처리를 보강한 뒤 Main으로 병합하도록 구성했습니다.
4. Agent 구현과 GitLab 품질 Gate
Codex Agent가 개선사항을 구현하면 GitLab Dev 브랜치에 반영하고 실제 개발 MES와 연동해 담당자가 기능 동작을 바로 확인했습니다. 이후 책임자와 개발자가 단일 책임 원칙, 중복 객체·컨테이너 생성, 기존 객체 생명주기 우회, 변경 범위 확대와 회귀 위험을 검토한 뒤 Main 브랜치에 병합했습니다.
현장 문제 발생 → 사용자와 Agent의 멀티모달 상호작용·즉시 해결 → Dev 브랜치 커밋 → 개발 MES 실연동 검증 → 개발자 예외처리·지속가능성 검토 → Main 병합
5. 운영 성과
- MES 연동 결함 41건을 양산 패치 배포 전 추가 발견·개선
- 패치 이후 일일 고객 불만 2~3건에서 0건으로 감소
- 현지법인 출장 4~5회에서 설치·교육 목적 1회로 축소, 약 400만 원 절감
- 반복 VOC 7~8종 재현, 기술지원·개발 대응시간 분기 약 40시간 절감
공개 범위
고객사명, 내부 제품명, 실제 장비 화면, 원문 통신 규약, 메시지 전문과 보안상 민감한 시스템 구성은 공개하지 않습니다.
Case 03 · Release AX
PR 기반 변경관리·릴리즈 문서·Smoke Gate
릴리즈 직전 담당자의 기억으로 코드를 다시 읽던 방식을 PR 단위 변경 분석과 실제 앱 실행 검증으로 바꿨습니다.
- Commit·Jira·C++ 심볼·기존 문서를 Agent가 연결
- WinApp 실행 결과와 문서 불일치 시 NEED CHECK 또는 Fail
- 6개월 Warning 운영 후 Smoke 실패 시 Merge 차단
명시적 변경 누락 약 99% 감소, 전달시간 약 60% 단축
상세 구조 보기Case 04 · QA Operations
사람의 품질판단과 AI 행정을 분리한 피드백 루프
QA는 실행불가·데이터·업무단계·금전·시각·고객이탈 영향만 빠르게 판단하고, Agent가 회사 표준의 제목·우선순위·재현절차·증적을 구성하도록 했습니다.
- 이슈 1~3건은 사람이 직접, 대량 발생 구간만 자동화
- 스크린샷·TC·Jira·Git 연결과 중복·유사 이슈 분류
- 즉시 발사·배치·유사 묶음으로 개발 수용량까지 관리
이슈 처리 20분 → 3분, 2일간 231건 구조화
상세 구조 보기Case 05 · HR Change Management
기존 Excel을 유지한 초과근무·교통비 자동화
양식 변경 사고의 책임을 우려하는 조직에서 ERP API와 인사 DB 접근을 강제하지 않고 COM 자동화부터 단계 적용했습니다.
- 담당자 1명, 직원 170명, 월 340건 처리
- 기존 결재·Excel 화면을 유지하고 후행 반복만 자동화
- 비정형 날짜 입력 6건을 발견해 파서 검증 보완
월 16시간 → 검토 2시간, 3개월 후 현업이 API 확장 검토를 먼저 요청
상세 구조 보기Case 06 · Finance Trust Design
AI 해석과 결정론적 금액 계산 분리
“AI가 숫자를 틀리면 어떻게 하느냐”는 우려에 대해 LLM은 입력 구조화만 하고, 실제 금액은 정적 계산기와 Excel Power Query가 독립 검산하도록 설계했습니다.
- 수기·자동 결과 병행검증과 근거 데이터 동일화
- 불일치가 수기 누락임을 3회 이상 확인
- 초과근무·야간교통비부터 제한 운영 후 확대 검토
전수 수기 재계산에서 랜덤 2~3건 샘플 검토 방식으로 전환
상세 구조 보기Case 07 · Global Field Integration
글로벌 Tier-1 고객 ITAC 연동과 국내 재현환경 구축
초기 영업 요구에서 누락된 시스템 연동조건을 독일 현장에서 생산·IT·구매·의사결정자와 직접 확인하고 실제 테스트라인에 반영했습니다.
- 고객 관계자 6명과 이벤트 시점·재검사·ACK·Retry 규칙 확정
- 기존 MES 표준 데이터 접점과 JSON REST Adapter 활용
- 보안 책임자 서면 승인으로 PCB 4종 12개 국내 반출
회사 예상 1개월 대응을 2주 내 마무리, 6일 만에 1차 연동 확인
상세 구조 보기Failure Case · Agent Scope Control
성공한 국소 패치를 수평 확장하다, 컨테이너 재작성으로 번지는 순간 중단했습니다.
첫 제품에서는 갱신 후 UIA 하위 객체 연결이 끊기는 문제를 작은 변경으로 해결했습니다. 패밀리 제품도 같은 구조일 것이라 보고 확장했지만, 외형과 달리 내부 컨테이너 구조가 달랐고 AI Agent는 목표를 달성하기 위해 컨테이너 자체를 다시 쓰기 시작했습니다. 이때 판단 기준을 “코드가 동작할 수 있는가”에서 “이 목적에 허용 가능한 변경인가”로 바꾸고 즉시 취소했습니다.
초기 가정패밀리 제품의 화면과 기능이 유사하므로 객체 생성·갱신 구조도 유사할 것이다.
반증 신호UIA 연결 보완이 아니라 컨테이너 생성·바인딩·이벤트 구조까지 Diff가 확장됐다.
중단 기준요구사항의 대상이 “하위 객체”에서 “컨테이너 전체”로 바뀌는 순간 승인 범위를 벗어났다.
학습 환류성공 패턴의 복제보다 구조 동질성 확인, 변경 예산, 보호 영역, 단계별 승인이 먼저다.
수평 확장은 완료하지 못했지만, 기능 개선 하나가 제품 핵심 구조의 대규모 회귀 위험으로 바뀌기 전에 변경을 폐기했습니다.
사고 과정 펼치기 — 왜 “동작할 수도 있는 코드”를 버렸는가
1. 첫 성공을 어떤 문제로 해석했는가
최초 실행에서는 아이템 리스트 컨테이너의 하위 객체가 UIA에 정상 노출됐지만, 갱신 버튼을 누르면 동적으로 객체가 다시 만들어지며 기존 연결이 끊겼습니다. 화면 기능은 살아 있었으므로 문제를 컨테이너 전체가 아니라 “갱신 뒤 접근성 트리에 다시 연결되지 않는 객체 생명주기”로 좁혔습니다.
첫 제품에서는 하위 객체가 갱신 후 다시 연결되도록 최소 변경하고, 동적 생성 버튼에는 식별 가능한 Name을 부여했습니다. 여기까지는 목표·변경 범위·검증 대상이 일치했습니다.
2. 왜 수평 확장이 합리적으로 보였는가
패밀리 제품은 사용자에게 보이는 화면과 역할이 유사했습니다. 따라서 첫 제품에서 확인한 객체 생명주기 문제와 수정 패턴을 재사용하면 제품군 전체의 UI 자동화 안정성을 빠르게 높일 수 있다고 판단했습니다.
잘못된 전제는 “같은 제품군”을 “같은 내부 구조”로 번역한 것이었습니다. 외형적 유사성을 아키텍처 동질성의 증거로 사용했습니다.
3. 무엇이 단순한 구현 난이도가 아니라 중단 신호였는가
다른 제품에서는 컨테이너 내부 객체 생성과 갱신 방식이 달랐습니다. AI Agent는 같은 결과를 만들기 위해 기존 하위 객체 연결부만 수정하지 않고 컨테이너 생성 흐름, 바인딩, 이벤트 연결을 넓게 변경하기 시작했습니다.
- 원래 요청: 갱신 후 컨테이너 하위 객체가 UIA에 다시 노출되게 한다.
- 실제 변경: 기존 컨테이너의 생성·상태·이벤트 구조를 재설계한다.
두 번째 문장은 첫 번째 문장을 구현하는 여러 방법 중 하나일 수 있지만, 승인된 위험과 검증 비용은 완전히 다릅니다.
4. 왜 더 진행해서 결과를 확인하지 않았는가
컨테이너 전체를 건드리면 UIA뿐 아니라 선택 상태, 데이터 갱신, 이벤트 순서, 화면 동작, 메모리 상태까지 다시 검증해야 합니다.
“구현 가능”과 “운영 가능한 변경”은 다른 판정입니다. 목표 대비 변경 폭이 커지면 성공 여부를 확인하기 전에 중단하는 것이 더 싼 선택입니다.
5. 다음 수평 확장에 필요한 통제 조건
- 구조 동질성 확인: 클래스·상속·객체 생성 시점·바인딩·갱신 이벤트 비교
- Plan-only Gate: 수정 대상, 예상 Diff와 보호 영역 사전 승인
- 변경 예산: 허용 파일·클래스·책임 범위를 넘으면 자동 구현 중단
- 단일 객체 Canary: 객체 하나에서 기능 회귀 확인 후 확장
6. 이 실패가 보여주는 AX 역량
AI Native 업무에서 생산성은 생성한 코드량이 아니라 안전하게 위임할 수 있는 범위로 측정해야 합니다.
Operating Model
현장 문제를 운영 시스템으로 만드는 방식
PositioningAX Engineer / Manufacturing & Business Process Automation
Strength현장 불편을 공정·소프트웨어·검증 구조로 전환
Focus실제 운영, 현업 채택, 원복 가능한 자동화, 증적과 책임 경계