한 줄 요약
AI에게 맡긴 세 가지 일이 모두 정확히 15배 빨라졌다고 나왔습니다. 그래서 답이 맞는지부터 따져 봤습니다
엑셀 조건 검색과 정제
45분 → 3분
15배
개발자 없이 DB 추출
직접 질의문 작성
요청을 문장으로 옮겨 씀
야간 장애의 영문 보고
숫자 세 개만 대조
단말 50대 · 45분 · 7시
받은 답을 이렇게 검증했습니다
요구와 결과를 문장째 맞댐
'일별 추이'를 달라 했는데 전체 기간 총합을 세는 수식이 나왔습니다
같은 누락이 두 번째에도
첫 사례에서 빠진 것이 두 번째 사례에서도 똑같이 빠져 있었습니다
숫자만 원문과 대조
보고문에서는 이 세 값만 확인해도 대부분의 사고를 막습니다
물류 센터 운영에서 반복되던 데이터 요청 세 건을 생성형 AI로 처리한 기록입니다. 본문의 수치와 이름은 예시로 다시 꾸민 것입니다.
데이터의 흐름을 읽고,
AI로 처리 방법을 설계합니다.
방대한 물류 데이터 정제, 복잡한 DB 쿼리 추출, 긴급 글로벌 커뮤니케이션까지. 생성형 AI를 실무 도구로 활용해 물류 센터 운영에서 실제로 마주쳤던 업무 세 가지를 AI로 처리한 과정을 정리했습니다.
작업 배경
물류 센터 운영에서 반복적으로 발생하던 데이터 요청 세 건을 생성형 AI로 처리한 기록입니다.
다중 조건 집계, SQL 추출, 야간 장애의 영문 보고 순서로 구성했습니다.
본문의 수치와 이름은 예시로 재구성했습니다.
도전 1. 수만 건의 복잡한 조건부 데이터 정제
목표: 다중 조건 데이터의 정확하고 빠른 추출 및 핵심 지표(불량률) 산출
B열: 바코드 번호
C열: 유통기한 (일부 데이터 Null)
D열: 검수상태 (정상/에러 등 혼재)
"검수상태가 '에러'이면서 유통기한이 '빈칸'인 항목만 필터링하여 일별 불량률 추이를 즉시 보고할 것."
데이터를 추출하세요
도전 2. 개발자 없이 복잡한 DB 데이터 추출 (SQL)
목표: 일상적인 비즈니스 언어로 된 요청을 해석하여 정확한 SQL JOIN 쿼리로 변환 및 실행
- Orders Table: id, item_id, center_code, status
- Centers Table: center_code, center_name, region
DB를 조회하세요
SELECT o.id, o.item_id, c.center_name FROM Orders o JOIN Centers c ON o.center_code = c.center_code WHERE o.status = 'Delayed' AND o.center_code = 'SEL';
| id | item_id | center_name |
|---|---|---|
| ORD-8911 | ITM-A102 | 서울 센터 |
| ORD-8914 | ITM-B441 | 서울 센터 |
| ORD-8920 | ITM-C901 | 서울 센터 |
도전 3. 외국인 임원진 대상 긴급 이슈 보고
목표: 현장의 파편화된 한국어 상황 보고를 '구조화된 비즈니스 영문 이메일'로 즉각 변환
받은 답을 검증하는 단계
앞의 세 사례는 AI가 결과를 만들어내는 과정입니다.
실무에서 이 흐름이 완성되려면 받은 답이 요구사항과 맞는지 확인하는 단계가 붙어야 합니다.
실제로 첫 번째 사례에서 확인이 필요한 지점이 있습니다.
도전 1의 수식은 요구사항의 일부만 충족합니다
요구사항
검수상태가 에러이고 유통기한이 빈칸인 항목을 필터링해 일별 불량률 추이를 보고할 것
도출된 수식
=COUNTIFS(D:D, "에러", C:C, "")
두 조건을 만족하는 전체 기간 총 건수를 셉니다.
날짜별로 나누는 부분이 없습니다.
추이를 얻으려면 날짜 조건이 필요합니다
입고일이 있는 A열을 조건에 넣어 날짜별로 계산해야 합니다.
=COUNTIFS($D:$D,"에러",$C:$C,"",$A:$A,기준일)
날짜 목록을 한 열에 두고 이 수식을 아래로 채우면 추이가 나옵니다.
건수가 많다면 피벗 테이블로 입고일을 행에 두고 조건을 필터로 걸는 편이 빠릅니다.
함께 확인할 두 가지
- • 빈칸의 정의 — 조건에 쓴 빈 문자열은 아무것도 입력되지 않은 셀과,
수식 결과가 빈 문자열인 셀을 함께 셉니다. 원본이 시스템에서 내려온 파일이라면 후자가 섞여 있을 수 있어 실제 결측과 다르게 집계됩니다. - • 불량률의 분모 — 일별 추이를 보려면 분모도 일별 입고 건수여야 합니다. 전체 52,140건을 분모로 쓰면 날짜별 값이 모두 작게 나와 추이가 눌립니다.
이 지점이 문서의 강점을 오히려 분명하게 합니다
AI는 요청받은 조건을 수식으로 옮기는 일은 정확히 했습니다.
빠진 것은 요구사항에 있던 ‘일별 추이’라는 단어입니다.
이런 누락은 결과만 보면 드러나지 않고, 요구사항과 결과를 하나씩 대조할 때만 잡힙니다.
도구를 쓰는 능력과 도구의 답을 검수하는 능력은 별개이고, 실무에서 신뢰를 만드는 것은 후자입니다.
사례별로 확인해야 할 것
세 사례는 각각 다른 종류의 위험을 가집니다.
실행 전에 무엇을 보는지 정해두면 같은 방식을 반복해서 쓸 수 있습니다.
SQL 추출 — 틀려도 결과가 나옵니다
쿼리가 잘못돼도 오류 없이 실행되어 그럴듯한 리스트가 나옵니다.
그대로 보고하면 잘못된 데이터가 의사결정에 들어갑니다.
- • 건수 대조 — 이미 아는 값과 맞춰봅니다. 서울 센터 전체 출고 건수를 알고 있다면, 지연 건이 그보다 클 수 없습니다. JOIN 조건이 잘못되면 행이 중복되어 건수가 부풀어 오르므로 여기서 잡힙니다.
- • 이번 주의 기준 — 월요일 시작인지 최근 7일인지에 따라 결과가 달라집니다. 요청자가 말한 기간을 날짜로 되물어 확정합니다.
- • 조회 부하와 권한 — 운영 DB에 직접 조회하면 대량 스캔이 서비스에 영향을 줄 수 있습니다. 조회 전용 환경과 허용된 범위를 사전에 확인해 둡니다.
영문 보고 — 숫자와 이름이 바뀌면 사고가 됩니다
번역과 구조화는 AI가 잘하는 일이지만, 이 보고는 새벽에 임원에게 바로 전달됩니다.
검토자가 없는 시간대라 오류가 그대로 나갑니다.
- • 숫자 대조 — 단말 50대, 지연 45분, 복구 목표 7시. 이 세 값이 원문과 같은지만 확인하면 대부분의 사고를 막습니다.
- • 확정과 예정의 구분 — 원문의 커버 가능은 예상이고 정상화는 완료입니다. 영문에서 둘 다 완료로 표현되면 보고 내용이 사실과 달라집니다.
- • 책임 서술 확인 — 원인을 단정하는 문장이 들어가지 않았는지 봅니다. 원인 규명 전 단계에서는 현상과 조치만 적는 편이 안전합니다.
세 사례에서 실제로 실력이 드러난 지점
AI를 쓴 것 자체는 누구나 할 수 있습니다.
이 기록에서 성과를 만든 것은 AI에게 무엇을 주었는지입니다.
조건으로 분해했습니다
막연한 요청을 열과 값 기준의 조건으로 바꿔 전달했습니다.
이 분해가 없으면 AI도 수식을 만들 수 없습니다.
스키마를 정리해 주었습니다
테이블과 컬럼 구조를 먼저 제시했습니다.
스키마 없이 요청하면 존재하지 않는 컬럼을 쓴 쿼리가 나옵니다.
보고 대상을 지정했습니다
외국인 임원 대상이라는 조건을 주어 문체와 구조가 정해졌습니다.
대상 없이 번역만 요청하면 형식이 맞지 않습니다.
두 번째 사례에서도 같은 것이 빠졌습니다
앞에서 도전 1의 수식이 일별 추이를 빠뜨렸다는 것을 확인했습니다.
같은 방식으로 도전 2의 쿼리를 요구사항과 대조하면 같은 유형의 누락이 한 번 더 나옵니다.
요청에 있던 이번 주가 쿼리에 없습니다
요청
이번 주 출고 지연된 건 중에서 서울 센터 물량만 센터명과 상품 아이디를 포함해서 뽑아 줄 것
도출된 쿼리의 조건
상태가 지연인 것, 센터 코드가 특정 값인 것. 기간 조건이 없습니다.
전체 기간의 지연 건이 모두 나옵니다.
그런데 이번에는 원인이 다릅니다
제공한 스키마를 보면 주문 테이블의 열이 아이디, 상품 아이디, 센터 코드, 상태 넷뿐입니다.
날짜 열이 아예 없습니다.
기간으로 거르고 싶어도 걸 수 있는 열이 없습니다.
도전 1은 AI가 조건 하나를 놓친 경우였고, 도전 2는 요청자가 필요한 정보를 주지 않은 경우입니다.
그런데 결과는 같습니다.
조건이 빠진 쿼리가 아무 경고 없이 돌아옵니다.
필요한 열이 스키마에 있는지 먼저 확인하는 것이 요청을 잘 쓰는 것만큼 중요합니다.
센터 코드도 확인이 필요합니다
요청은 서울 센터라고 했고 쿼리는 센터 코드를 특정 문자열로 고정했습니다.
그 코드가 실제로 존재하는지는 스키마에 나와 있지 않으므로 추측한 값입니다.
센터 테이블에는 지역 열이 함께 제공되어 있는데 쓰이지 않았습니다.
서울에 센터가 둘 이상이면 코드 하나로는 일부만 나옵니다.
지역 열로 거르는 편이 요청 문장에 더 가깝고, 센터가 늘어나도 그대로 작동합니다.
검증하려면 그 일을 할 줄 알아야 합니다
두 사례 모두 결과만 보면 정상으로 보입니다.
수식은 숫자를 내놓고 쿼리는 행을 반환합니다.
빠진 조건은 요구사항과 결과를 한 줄씩 맞춰볼 때만 드러납니다.
그리고 그 대조를 하려면 수식과 쿼리를 읽을 줄 알아야 합니다.
도전 2의 제목은 개발자 없이 데이터 추출입니다.
쿼리를 받는 것은 개발자 없이 가능합니다.
다만 받은 쿼리가 요청과 맞는지 판단하는 데는 읽을 수 있는 만큼의 지식이 필요합니다.
제목을 개발자를 기다리지 않고 정도로 적으면 실제로 한 일에 더 가깝고,
검증 단계를 생략했다는 인상도 주지 않습니다.
이 문서가 스스로 검증 과정을 적어둔 것이 그 지식을 갖췄다는 증거이기도 합니다.
절감 배수가 세 작업 모두 같습니다
| 작업 | 수동 | 도구 활용 | 절감 | 배수 |
|---|---|---|---|---|
| 엑셀 조건 검색과 정제 | 45분 | 3분 | 42분 | 15.0배 |
| DB 쿼리 작성 | 60분 | 4분 | 56분 | 15.0배 |
| 글로벌 보고 작성 | 30분 | 2분 | 28분 | 15.0배 |
성격이 다른 세 작업이 똑같이 15배입니다
엑셀 수식 작성, 쿼리 작성, 외국어 보고서 작성은 필요한 기술도 걸리는 이유도 다릅니다.
그런데 세 작업의 절감 배수가 모두 정확히 15배로 같습니다.
45와 3, 60과 4, 30과 2로 나누어떨어지는 정수이기도 합니다.
측정한 값이 이렇게 맞아떨어지기는 어렵습니다.
한계 항목에 수동 작업 시간은 추정이라고 이미 밝혀두었으므로 표기 자체는 정직합니다.
다만 차트는 막대 길이로 보여주기 때문에 측정값처럼 읽힙니다.
발표에서는 같은 배수를 일괄 적용한 값이라고 먼저 말하고, 총 절감 시간 대신 작업 하나를 실제로 재본 기록을 하나만 제시하는 편이 설득력이 큽니다.
하나라도 실측이면 나머지 추정의 근거가 생깁니다.
저장해서 다시 쓰면 배수가 크게 떨어집니다
세 작업 중 엑셀 수식과 쿼리는 한 번 만들면 저장해 두고 재사용할 수 있습니다.
보고서는 내용이 매번 달라 재사용이 어렵습니다.
같은 작업을 열 번 한다고 놓고 비교하면 이렇게 갈립니다.
엑셀 수식 열 번
매번 새로 만들면 450분,
저장해 두고 조건만 바꾸면 90분입니다.
도구를 쓰면 30분입니다.
저장 습관이 있는 사람에게는 15배가 아니라 3배입니다.
쿼리 열 번
같은 방식으로 600분, 105분, 40분입니다.
배수가 15배에서 2.6배로 내려갑니다.
그래서 이 도구의 값어치는 반복이 아니라 처음에 있습니다
매번 같은 일을 한다면 수식이나 쿼리를 저장하는 것으로 충분합니다.
도구가 크게 이기는 구간은 처음 만나는 조건, 저장해 둔 것이 안 맞는 상황입니다.
세 사례가 모두 그런 성격이므로 제안의 방향은 맞습니다.
발표에서 반복 업무 자동화가 아니라 비정형 요청 대응으로 성격을 적으면 되묻기 어려운 주장이 됩니다. 반복 업무라면 도구보다 표준 양식을 만드는 것이 먼저라는 반론이 늘 따라옵니다.
절감 시간을 도입 근거로 쓰려면 빈도가 필요합니다
세 작업을 합치면 한 차례에 126분이 줄어듭니다.
이 값이 얼마나 큰지는 같은 일이 얼마나 자주 생기는지에 달려 있습니다.
주 1회면
연 109시간
월 1회면
연 25시간
분기 1회면
연 8시간
같은 126분이라도 결론이 연 109시간과 연 8시간으로 갈립니다.
빈도를 적어두면 절감 시간이 도입 근거가 되고, 없으면 인상적인 숫자로만 남습니다.
검증 시간도 함께 세어야 합니다.
앞의 두 사례에서 확인했듯 받은 답을 대조하는 데 드는 시간은 이 비교에 아직 들어가 있지 않습니다.
이 절의 한계
- • 열 번 반복 비교에서 저장해 둔 수식을 다시 쓰는 데 5분이 든다고 놓았습니다. 실제 값은 작업에 따라 다르므로 배수의 정확한 크기가 아니라 방향을 보는 계산입니다.
- • 쿼리와 수식의 누락은 문서에 적힌 요청 문장과 결과를 대조해 찾은 것입니다. 실제 업무에서는 구두로 오간 조건이 더 있었을 수 있습니다.
- • 센터 코드가 실제로 어떤 값인지는 이 문서로 확인할 수 없습니다. 지역 열을 쓰자는 제안은 스키마에 그 열이 있다는 사실에만 근거합니다.
- • 빈도별 연간 환산은 126분이 매번 그대로 절감된다는 가정 위에 있습니다. 실제로는 익숙해질수록 수동 작업 시간도 줄어듭니다.
이 기록의 한계
- • 본문에 밝힌 대로 수치와 이름은 예시로 재구성했습니다. 52,140건과 같은 값은 실제 데이터가 아닙니다.
- • 시간 절감 비교는 같은 작업을 수동으로 했을 때의 추정이며 두 방식을 나란히 계측한 값이 아닙니다.
- • 세 사례는 한 번씩 처리한 기록입니다. 반복 적용했을 때의 정확도는 확인되지 않았습니다.
- • 사내 데이터를 외부 AI에 입력할 수 있는지는 각 회사의 보안 지침에 따릅니다. 스키마와 현장 보고 내용도 판단 대상입니다.
- • DB 조회 권한과 운영 환경 분리 여부는 조직 구성에 종속되므로 그대로 재현되지 않을 수 있습니다.
- • AI 모델과 버전에 따라 같은 요청에도 다른 결과가 나옵니다. 도출된 수식과 쿼리는 한 시점의 결과입니다.
성과 요약: 도구 활용이 만드는 유의미한 시간 차이
업무의 본질을 정확히 이해하고 AI를 활용할 때, 가장 빠른 문제 해결이 가능합니다.
업무 효율 개선 효과를 정리했습니다
기술이나 코딩 지식 자체보다 더 중요한 것은 '문제를 끝까지 파고들어 해답을 찾아내는 집요함'이라고 생각합니다.
AI라는 강력한 도구를 무기로 삼아 복잡한 데이터를 단순화하고,
물류 현장에 필요한 오퍼레이션 개선안을 정리했습니다.