DPS와 DAS: 중요한 건 예외 처리·확정 설계

DPS/DAS를 사용할 때는 단순한 신호기로 볼 것이 아닌 “어디서 확정하고, 예외를 어디로 보낼지” 설계가 필요합니다.
니어솔루션's avatar
Feb 12, 2026
DPS와 DAS: 중요한 건 예외 처리·확정 설계

불은 켜지는데 오투입·누락은 왜 그대로일까

선반 앞에서 불이 켜지고 숫자가 뜨면, 현장 분위기는 다들 일단 “따라가기”바쁩니다.
피킹 존에서 불이 반짝이고, 작업자는 익숙한 듯 손을 움직입니다.
그런데 출고 마감 시간만 가까워지면 “누락 하나”가 통째로 재작업이 되곤 하죠.
버튼도 눌렀고, 스캔도 했는데… 왜  오투입·누락이 줄지 않을까요?
라이트 장비의 문제가 아니라,

확정 타이밍과 예외 처리 설계가 흔들릴 때 이런 일이 생깁니다.
그래서 이 글은 DPS DAS를 단순한 “장비 소개”가 아니라

운영 설계(확정·예외·슬롯) 관점에서 정리하고자 합니다.


DPS와 DAS

DPS와 DAS에 대해 간략하게 되짚어 봅시다.

  • DPS(Pick-to-Light): “여기서 몇 개 집어”를 불/표시로 안내하는 피킹.

  • DAS(Put-to-Light): “이 토트/주문에 몇 개 넣어”를 불/표시로 안내하는 분류.

그러나 무엇보다 둘 다 핵심은 “불빛”이 아니라 확정(스캔/버튼)과 기록(로그)입니다.


DPS에서 오류가 안 줄어드는 순간: ‘확정 타이밍’이 비어 있다

피킹이 바쁜 날, 작업자는 불이 켜진 칸에서 물건을 집고 지나갑니다.
문제는 언제 “맞게 집었다”를 확정하느냐입니다.
버튼만 누르고 지나가면 “했음”만 남고, 무엇을/몇 개를/왜 틀렸는지는 사라집니다.

운영적으로 이렇게 해석하면 쉬워요.

  • 확정이 빠르면 속도는 나지만, 누락·오투입이 뒤 공정(검수/패킹)에서 발생합니다.

  • 확정이 늦으면 정확도는 오르지만, 피크 때 대기가 생깁니다.

그래서 포인트는 “DPS를 쓰면 정확해진다”가 아니라, 우리 센터는 ‘확정’을 어느 공정에 둘 건지입니다.


DAS에서 병목이 생기는 순간: 슬롯이 피크를 못 버틴다

분류 벽 앞에서 불이 켜져도, 슬롯이 꽉 차면 작업자는 멈춥니다.
DAS는 구조적으로 동시 처리 가능한 주문 수 = 슬롯 수에 묶이기 때문이죠.

여기서 그렇다고 “슬롯 수 산정”을 장비 스펙처럼 쓰면 곤란합니다.
현장 언어로 표현하자면 이렇습니다.

  • 피크 시간대에 ‘동시로 걸리는 주문/토트’가 슬롯보다 많아지는 순간, 오투입·누락·보류가 늘어난다.


예외처리가 엑셀로 새는 순간: 라이트는 ‘교육비’가 아니라 ‘재발비’가 된다

작업 중 결품, 파손, 라벨 불명, 재피킹 요청은 항상 나옵니다.
그러나 이때 이런 예외가 시스템 밖(엑셀/메신저)으로 새면, 다음날 똑같이 터집니다.

그래서 우리 다뤄야 할 건 장비가 아니라 예외 목록(보류→복귀 경로)입니다.
“어디로 보내고,

누가 처리하고,

어떤 조건에서 다시 흐름으로 복귀시키는지”가 없으면,

결국 숙련자만 커버 가능한 장치가 되어버립니다.


업계 레퍼런스: 장비가 아니라 ‘운영 UI+확정 설계’로 읽자

  • AIOI Systems는 디지털 피킹 시스템이 전 세계 73개국에서 활용된다고 소개합니다. (출처: Global Kigyo/AIOI 소개 PDF, 2025, p.1)

  • Sorion의 Put-to-Light 사례는 45개 컴파트먼트 구성, 스캔 후 버튼/센서로 완료 확정, 결과 파일 출력까지 “확정→기록” 흐름을 보여줍니다. (출처: Sorion, 2020)

  • Daifuku는 DAS는 ‘픽투라이트 장비’를 분류에 가져다 쓴 형태라서 표현이 헷갈리지만, 작업 동작 기준으론 Put-to-Light(분류/투입)에 가깝습니다. 배치 피킹 물량을 목적지별로 나누는 용도에 적합하다고 말합니다. (출처: Daifuku 제품 설명, 연도 확인 불가)

  • Ishida는 Put-to-Light가 “불 보고 놓고 버튼으로 완료” 같은 단순한 확정 동작으로 정확도·재작업을 줄이는 방향을 강조합니다. 현장에선 교육 편차를 줄이는 UI로 해석됩니다. (출처: Ishida, 연도 확인 불가)

공통점: 예외처리와 연동이 흔들리는 순간, 병목은 피크에서 먼저 발생합니다.


실무 포인트

피크에 단기 인력이 들어오면, 라이트는 “빠른 장치”가 아니라 교육을 덜 타는 UI가 됩니다.
그래서 노무/피크는 확정 동작을 단순하게, 대신 예외는 큐로 모으는 설계가 필요합니다.

연동은 더 현실적입니다. WMS/OMS/설비가 같은 상태를 다른 말로 기록하면, 현장은 결국 수기로 맞춥니다.
데이터 품질은 “예외 코드가 통일돼 있나”로 시작하면 됩니다. 코드가 없으면 운영 리포트가 아니라 회고담이 돼요.
운영 문화는 권한(R&R)·SOP·교육이 없으면 “아는 사람만 쓰는 기능”으로 남습니다.


체크리스트

체크 질문

현장 체크 포인트

확인할 데이터/산출물

DPS/DAS에서 “완료 확정”은 버튼/스캔 중 무엇이고, 어느 단계에서 찍히나?

피크·컷오프(SLA) 앞에서 확정이 흔들리면 누락이 재작업으로 번짐

작업 단계별 SOP, 스캔 로그, 버튼(확정) 이벤트 로그

오투입/누락이 났을 때 “보류 큐”로 빠지고 다시 복귀하는 경로가 정해져 있나?

예외가 메신저로 새면 재발방지가 불가능해짐

예외 코드 목록, 보류 큐 목록, 예외 처리 이력(담당/시간)

DAS 슬롯(셀) 수는 피크 시간대 동시 주문/토트를 버티나?

피크 변동이 크면 슬롯 부족이 병목공정으로 직결

시간대별 동시 작업량 리포트, 슬롯 점유율 로그

단기 인력/3PL/교대가 섞일 때 확정 동작이 일관되게 수행되나?

교육 편차가 커질수록 “확정 누락”이 늘어남

교육 이수 기록, 교대별 오류/재작업 리포트

결품/파손/라벨 불명 시 ‘멈춤 기준’과 담당자 승인 흐름이 있나?

QC/클레임이 몰리는 날 예외처리 리드타임이 출고지연을 만든다

QC/보류 SOP, 승인 권한표(R&R), 승인 로그

WMS/OMS/설비가 상태값(대기/진행/보류)을 같은 의미로 기록하나?

연동이 어긋나면 현장은 수기로 봉합한다

상태 코드 정의서, 인터페이스(IF) 정의서, 상태 변경 이력

재발방지는 “오투입 TOP 원인”을 매주 같은 포맷으로 뽑나?

운영 리포트가 없으면 개선이 구호로 끝남

주간 운영 리포트 템플릿, 오류 원인 분류표, 개선 이력

파일럿→확대 시 컷오버(전환) 계획과 롤백 기준이 있나?

컷오버 리스크가 크면 ‘될 때만 되는 자동화’로 남음

컷오버 계획서, 롤백 시나리오, 테스트 체크리스트

표 30초 사용법
① 각 질문에 현재 상태를 한 문장으로 적기
② 산출물이 실제로 뽑히는지 확인
③ 없으면 ‘데이터/룰 정의가 먼저’로 결론


결론

AIOI Systems가 디지털 피킹 시스템이 73개국에서 활용된다고 소개하는 건, 현장이 라이트를 “장비”가 아니라 “작업 표준화 장치”로 보고 있다는 신호로 읽힙니다.
현장 체감은 최고 속도보다 피크와 컷오프 앞에서 예외처리·누락이 얼마나 안정적으로 닫히는지로 갈립니다.


솔루션

라이트(DPS/DAS)는 현장 UI입니다. 성패는 “오늘 피크에서 무엇을 먼저 처리할지”, “예외를 어디로 모을지”, “확정이 어떤 로그로 남는지”를 통제하는 실행레이어에서 갈립니다.

저희 니어솔루션은 이런 상황에서 NearWES 같은 실행 레이어 관점으로, 장비를 더 소개하기보다 흐름을 덜 흔들리게 만드는 기준을 먼저 잡는 쪽으로 접근합니다.
예를 들면, 피크에 동시 주문이 슬롯을 넘을 때 우선순위를 바꾸는 룰, 결품/파손이 발생했을 때 보류 큐로 모아 복귀시키는 경로, 작업 확정 이벤트를 남겨 “왜 터졌는지”를 다음 주 리포트로 연결하는 방식 같은 것들입니다.


FAQ

Q1. DPS랑 DAS의 차이점에 대해 설명해주세요.
피크 시간대에 “집는” 공정이 중심이면 DPS, “나눠 담는” 분류/콘솔리데이션이 중심이면 DAS로 역할이 갈립니다. 둘 다 결국 확정(버튼/스캔)과 예외처리 큐가 없으면 누락이 반복됩니다.

Q2. 라이트를 달면 누락이 자동으로 줄어드나요?
아니요. 피크에 단기 인력이 섞이면 버튼만 누르고 지나가는 “확정 누락”이 생길 수 있습니다. 누락을 줄이려면 확정 타이밍과 예외 경로(보류→복귀)를 먼저 정해야 합니다.

Q3. DAS 슬롯 수는 어떻게 잡아야 하나요?
상황에 따라 다릅니다. 컷오프 직전 동시 주문/토트가 얼마나 겹치는지에 따라 필요한 슬롯이 달라집니다. 그래서 “평균 처리량”보다 피크 시간대 동시량과 보류 큐 체류시간을 같이 봐야 합니다.

Q4. 예외처리는 꼭 시스템 안에 있어야 하나요?
네. 혼합 운영(결품/파손/라벨 불명)이 많은 날일수록 예외가 엑셀로 새면 재발방지가 어렵습니다. 예외 코드를 통일하고 보류 큐에서 닫히게 하면, 교육 편차가 있어도 운영이 덜 흔들립니다.


[출처 목록]

보고서/논문

웹아티클/벤더 페이지/케이스

Share article

Nearsolution