SAP 재작업 원가 점검 — 재작업률 · 표준 대비 차이 · 복귀율을 오더 한 줄에서 확인하는 제조원가 점검 화면
재작업 원가 집계 · 표준 재작업 원가와의 차이 · 재작업률과 복귀율 · 원인별 집중도 · 월별 추이 · 대사식 10종으로 스스로 검산 — 소개 영상과 실제 화면 7종, 그리고 CDS 코드까지
소개 영상블로그 목차 순서대로 · 자막 포함8개 장면조회 → 점검 필요 오더 → 오더 상세 → 재작업 공정 → 원인별 → 월별 추이 → 대사
주요 재생 지점
도입 포인트 — 이 앱을 사용해야 하는 이유
재작업은 원가 회의에서 가장 설명하기 어려운 비용입니다. 얼마나 났는가, 표준보다 많은가, 무엇이 키웠는가. 이 세 답은 오더 조회 · 차이 분석 · 개별 항목에 흩어져 있고, 재작업만 따로 모은 숫자는 대개 엑셀 안에만 있습니다. 이 앱은 세 답을 오더 한 줄에 붙이고, 그 합계가 어디서 왔는지 같은 화면에서 내려가 확인하게 합니다.
핵심 포인트 여덟 가지
| 포인트 | 고객이 얻는 것 | 지금 방식이라면 |
|---|---|---|
| ① 재작업 원가를 오더 한 줄에 모은다 | 재료비 · 노무비 · 기계 및 간접비를 오더마다 합쳐 재작업 원가로 보여 줍니다. 합계가 어디서 왔는지 같은 창에서 내려갑니다. | 재작업 원가를 코스트센터 개별 항목에서 건건이 찾아 엑셀에 붙이고, 오더와 맞추는 데 반나절이 걸립니다. |
| ② 표준 재작업 원가와 바로 견준다 | 재작업 수량에 제품별 표준 재작업 단가를 곱한 값과 실제 원가를 나란히 두고 차이와 차이율을 보여 줍니다. | 표준과 실제를 다른 리포트에서 가져와 눈으로 비교합니다. |
| ③ 재작업률은 가중해서 계산한다 | 오더 비율의 평균이 아니라 재작업 수량 합계 ÷ 투입 수량 합계로 다시 계산합니다. 월 합계가 오더 합계와 어긋나지 않습니다. | 평균의 평균으로 월 비율을 내서 큰 오더와 작은 오더가 같은 무게로 섞입니다. |
| ④ 복귀율로 재작업이 새는 곳을 본다 | 재작업한 수량 중 양품으로 돌아온 비율을 따로 계산해, 재작업하다 폐기로 바뀐 수량이 많은 오더를 짚습니다. | 재작업 건수만 세어서, 되살리지 못하고 버린 수량이 드러나지 않습니다. |
| ⑤ 원가가 비어 있는 오더를 잡아낸다 | 재작업 수량이 있는데 원가가 0 인 오더를 확인 필요로 표시합니다. 확인 실적과 원가 집계의 연결이 끊긴 자리입니다. | 원가가 집계되지 않은 오더는 리포트에 0 으로 나와 문제가 아닌 것처럼 보입니다. |
| ⑥ 원인별 · 월별로 다시 묶는다 | 같은 오더 값을 원인별 · 월별로 합산해 한 원인에 쏠린 달과 점검 필요 오더가 늘어나는 달을 찾습니다. | 원인별 · 월별 리포트를 따로 만들어 서로 숫자가 안 맞습니다. |
| ⑦ 판정 기준이 화면에 적혀 있다 | 재작업률 6% · 차이율 25% · 복귀율 80% · 원인 비중 40% 와 판정 순서를 읽을 수 있습니다. 기준값은 회사가 정하는 값으로 조정하는 것을 전제로 합니다. | 기준이 담당자 머릿속이나 엑셀 수식 안에만 있어 사람이 바뀌면 달라집니다. |
| ⑧ 스스로 검산하는 점검 도구 | 수량 · 금액 · 단위원가 · 월 합계 대사식 10종의 검사 건수와 차이 건수를 화면에서 보여 줍니다. | 숫자가 맞는지는 만든 사람만 압니다. |
사례로 보는 효과 — 합계는 괜찮은데 오더는 그렇지 않았다
이 사례에서 재작업 원가는 47,696,087원으로 표준 재작업 원가 50,054,100원보다 2,358,013원 적었습니다. 합계만 보면 문제가 없습니다. 그런데 오더로 내려가면 이야기가 달라집니다. 판정 기준에 걸린 오더가 15건 나옵니다 — 재작업 수량이 있는데 원가가 집계되지 않은 오더 3건, 재작업률이 한도를 넘은 오더 5건, 표준에서 25% 넘게 벗어난 오더 4건, 복귀율이 모자란 오더 3건입니다. 합계에서는 표준을 밑도는 오더와 넘는 오더가 서로 상쇄되어 보이지 않았을 뿐입니다.
월별로도 비슷합니다. 1~3월은 점검 필요 오더가 두 건씩이었는데 4월부터 세 건씩으로 늘었고, 5월 재작업률은 4.14% 로 가장 높았습니다. 원인별로는 치수 불량이 전체 재작업 원가의 23.5% 로 가장 크고 조립 불량이 19.6% 로 뒤를 잇습니다. 총액이 아니라 어디를 먼저 볼지가 정해집니다.
재작업 원가와 단위원가 가산분
재작업 원가 = 재료비 + 노무비 + 기계 및 간접비 · 공정 원가 = 노무 시간 × 임률 + 기계 시간 × 배부율 + 재료비
재작업률은 오더 비율의 평균이 아니라 재작업 수량 합계 ÷ 투입 수량 합계로 다시 계산합니다. 월 합계가 오더 합계와 어긋나지 않게 하려는 규칙입니다.
도입하면 달라지는 것
- 원가 점검 준비 — 재작업 원가를 개별 항목에서 건건이 모아 엑셀에 붙이는 일이 줄어듭니다.
- 회의의 주제 — “재작업이 늘었다”에서 “어느 원인의 어느 오더가 키웠나”로 넘어갑니다.
- 빠진 원가의 발견 — 수량은 있는데 원가가 0 인 오더를 정산 전에 잡습니다.
- 기준의 공유 — 판정 기준과 순서가 화면에 적혀 있어 담당자가 바뀌어도 같은 기준으로 봅니다.
이런 회사에 맞습니다
생산오더 기반으로 제조원가를 관리하면서 재작업 · 폐기 비용을 엑셀로 따로 모으고 있는 회사, 표준 원가 차이는 보지만 재작업 몫을 떼어 설명하기 어려운 원가팀, 그리고 원가 점검 기준을 사람 머릿속이 아니라 화면에 적어 두고 싶은 관리회계 조직에 맞습니다. 법정 보고나 공시 숫자를 만드는 화면은 아닙니다.
숫자를 믿을 수 있는가 — 검증 결과
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
도입 후 쓰는 순서
- 회계연도를 확인하고 조회를 누릅니다. 필요하면 전기 월 범위 · 제품 · 원인 · 점검 결과로 좁힙니다.
- 요약에서 재작업 원가 · 표준 대비 차이 · 재작업률과 점검 필요 건수를 봅니다.
- 점검 결과를 점검 필요로 바꿔 판정에 걸린 오더만 남깁니다.
- 오더 행을 눌러 재작업 원가가 어떻게 모였는지, 어느 공정이 키웠는지 봅니다.
- 원인별 · 월별 탭에서 쏠림과 추이를 확인합니다.
- 대사 결과가 모두 0 인지 확인한 뒤, 의심되는 오더는 표준 T-code 로 가서 확인합니다.
실행 화면
실제로 돌아가는 화면 7종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다. 자료는 가상의 검증용 데이터입니다.

화면을 열면 한 번 자동으로 조회됩니다. 재작업률은 오더별 비율을 평균내지 않고 재작업 수량 합계를 투입 수량 합계로 나누어 다시 계산합니다. 수량이 큰 오더가 비율을 더 크게 끄는 것이 현장의 감각과 맞기 때문입니다.

판정은 위에서 아래 순서로 먼저 걸리는 한 가지로 정해집니다. 결과 글자는 원인을 단정하지 않고 점검 필요 · 확인 필요로만 적습니다. 판단은 사람이 합니다.

합계가 맞는지 의심될 때 표를 닫지 않고 그 자리에서 확인하라고 만든 창입니다. 위쪽 세 값을 더하면 재작업 원가가 되고, 아래쪽 공정 원가를 더해도 같은 값이 나와야 합니다.

재작업은 공정을 한 번 더 도는 일이라 원가의 실체가 공정 단위에 있습니다. 오더 한 줄이 너무 크게 보일 때 어느 공정이 키웠는지를 여기서 찾습니다.

재작업을 줄이는 일은 결국 원인을 줄이는 일입니다. 월 총액만 보면 늘었다는 사실밖에 모르지만, 원인별로 나누면 어느 불량이 키웠는지가 보입니다.

데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.

데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
SAP 표준 기능 확장 포인트
이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.
표준으로 되는 것과 안 되는 것
| 하고 싶은 일 | SAP 표준 | 표준에서 걸리는 자리 | 이 앱이 하는 일 |
|---|---|---|---|
| 생산오더 하나 조회 | CO03 | 오더별로 열어야 하고 재작업만 따로 떼어 모아 보는 화면은 없습니다 | 오더 · 원인 · 월로 가로질러 재작업만 모아 봅니다 |
| 오더 차이 분석 | KKBC_ORD | 차이는 나오지만 재작업 몫이 어디서 왔는지는 가려내야 합니다 | 재작업 원가와 표준 재작업 원가의 차이를 따로 세워 둡니다 |
| 원가 개별 항목 | KSB1 · KOB1 | 코스트센터 · 오더 단위 항목을 건건이 엑셀로 내려 합치게 됩니다 | 공정별 노무 · 기계 배부를 오더 합계와 맞춰 보여 줍니다 |
| 공정 확인 실적 입력 | CO11N | 입력 화면이라 수량을 모아 비율을 보는 용도가 아닙니다 | 확인 실적의 재작업 · 폐기 수량으로 재작업률과 복귀율을 계산합니다 |
| 오더 정산 | KO88 | 정산 뒤에는 재작업 원가가 어디에 실렸는지 찾기 어렵습니다 | 정산 전에 재작업 원가가 실려 있는지 미리 점검합니다 |
| 재작업 원가의 점검 판정 | — | 표준에 없습니다. 보통 엑셀 수식으로 기준을 겁니다 | 판정 순서와 기준값을 화면에 적고, 걸린 이유를 한 줄로 보입니다 |
T-code 별 연계 지점
이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 화면을 없애야 하느냐”는 질문이 꼭 나오는데, 대부분은 없애지 않고 둡니다. 대사와 감사 대응은 표준 거래가 맡는 편이 안전합니다.
| T-code | 이름 | 연계 |
|---|---|---|
CO03 | 생산오더 조회 | 오더 상세의 수량 · 원가를 표준 화면에서 다시 확인 |
KKBC_ORD | 생산오더 차이 분석 | 표준 대비 차이 금액을 표준 차이 분석 결과와 맞춰 봄 |
KSB1 | 코스트센터 실제 개별 항목 | 재작업 공정의 노무 · 기계 배부 금액 원천 확인 |
KO88 | 오더 실제 정산 | 정산 전 오더에 재작업 원가가 실려 있는지 확인 |
분석 지표 정의
관련 기준서는 없고 대상 영역은 제조원가입니다. 아래 한도는 화면의 기본값이며 회사 정책에 맞게 조정해 쓰는 것을 전제로 합니다.
| 지표 | 정의 | 기본 한도 | 원천 |
|---|---|---|---|
| 재작업률 | 재작업 수량 ÷ 투입 수량 × 100 | 6.00% 초과 | 오더 확인 실적(수량) |
| 표준 대비 차이율 | (재작업 원가 − 표준 재작업 원가) ÷ 표준 | ±25.00% | 표준 단가 · 공정 실적 |
| 복귀율 | 복귀 수량 ÷ 재작업 수량 × 100 | 80.00% 미만 | 오더 확인 실적(수량) |
| 원인 집중도 | 월 재작업 원가 중 한 원인의 비중 | 40.00% 이상 | 재작업 원인 코드 |
| 단위원가 가산분 | 재작업 포함 단위원가 − 기본 단위원가(양품 기준) | — | 오더 원가 · 양품 수량 |
화면이 부르는 OData 구성
화면은 OData V2 서비스만 바라봅니다. 엔티티셋은 OrderSet(오더) · OpSet(재작업 공정) · CauseSet(원인별) · MonthSet(월별) · ReconSet(대사) 다섯 개이고, 펑션 GetReworkRate 가 월별 재작업률을 돌려줍니다. 서비스 주소는 manifest 의 상대 경로로 선언되어 실제 서비스로 바꾸면 화면은 그대로 동작합니다.
CDS 구성
데모를 신청하신 고객께 공개되는 내용입니다
CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.
데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.
자주 묻는 질문
도입 상담과 데모에서 나올 만한 질문을 네 묶음으로 나눠 적었습니다.
숫자와 산식
재작업률은 어떻게 계산합니까?
재작업 수량 ÷ 투입 수량 × 100 입니다. 월이나 원인처럼 묶어 볼 때는 오더별 비율을 평균내지 않고 수량 합계로 다시 나눕니다. 이 사례의 전체 재작업률 3.52% 는 재작업 5,892개를 투입 167,350개로 나눈 값입니다. 평균의 평균으로 내면 작은 오더가 큰 오더와 같은 무게로 섞여 월 합계와 어긋납니다.
투입 수량과 양품 수량은 어떻게 맞춥니까?
투입 수량은 1차 양품 + 재작업 + 폐기이고, 양품 수량은 1차 양품 + 재작업 후 복귀입니다. 오더마다 이 두 등식을 검산하며 대사식 R01 · R02 가 그것입니다. 84건 모두 차이가 없습니다. 투입 수량의 원천은 확인 실적이라 실제 시스템에서는 어느 필드를 쓸지 먼저 확인해야 합니다.
재작업 원가는 무엇을 더한 값입니까?
재료비 + 노무비 + 기계 및 간접비입니다. 노무비는 노무 시간 × 임률, 기계 및 간접비는 기계 시간 × 배부율로 공정마다 다시 계산하고, 재료비는 재작업에 추가로 들어간 자재 금액입니다. 공정 원가를 더한 값이 오더의 재작업 원가와 같은지를 대사식 R04 가 검산합니다.
표준 재작업 원가는 어디서 옵니까?
재작업 수량 × 제품별 표준 재작업 단가입니다. 이 화면의 표준 단가는 검증용 가상 값입니다. 실제 환경에서는 회사가 정한 표준 단가나 표준 시간을 어디서 가져올지가 도입에서 먼저 정할 항목이며, 저는 그 원천을 단정하지 않고 확인 필요로 남겼습니다.
표준 대비 차이가 음수인데 좋은 겁니까?
이 사례 전체는 실제 47,696,087원이 표준 50,054,100원보다 2,358,013원 적어 음수입니다. 다만 합계가 음수라고 안심하면 안 됩니다. 오더 단위로는 표준을 25% 넘게 벗어난 4건이 있고, 합계에서는 서로 상쇄되었을 뿐입니다. 그래서 차이율은 오더마다 따로 판정합니다.
단위원가 가산분은 무엇입니까?
재작업을 포함한 단위원가에서 기본 단위원가를 뺀 값입니다. 각각 양품 수량으로 나누어 소수 2자리까지 구합니다. 재작업이 양품 한 개의 원가를 얼마나 올렸는지를 보는 값이라, 재작업 원가 금액이 같아도 양품이 많은 오더는 가산분이 작습니다.
복귀율이 100% 를 넘을 수 있습니까?
아닙니다. 복귀 수량은 재작업 수량을 넘지 못하게 만들었습니다. 복귀율 = 복귀 수량 ÷ 재작업 수량 × 100 이고, 하한 80% 아래면 점검 필요입니다. 되살리지 못한 재작업 수량은 폐기로 넘어간 것이라 사유를 확인하라는 뜻입니다.
판정 기준
점검 필요로 표시되면 오류입니까?
아닙니다. 이 화면은 분류 · 집계 · 대사를 돕는 점검 도구이며 원인을 단정하지 않습니다. 점검 필요 · 확인 필요는 사람이 한 번 더 보라는 표시이고, 최종 판단은 회사가 합니다. 그래서 결과 글자에 오류나 위반 같은 단정적인 말은 쓰지 않았습니다.
기준값 6% · 25% · 80% · 40% 는 어디서 나온 숫자입니까?
화면의 기본값입니다. 특정 기준서나 법령에서 정한 값이 아니며, 회사 정책에 맞게 조정해 쓰는 것을 전제로 합니다. 관련 기준서는 없고, 이 화면의 대상 영역은 제조원가입니다.
한 오더가 여러 조건에 걸리면 어떻게 됩니까?
위에서 아래 순서로 먼저 걸리는 하나로 판정됩니다. 순서는 원가 미집계(R20) → 재작업률 초과(R10) → 표준 대비 차이 초과(R30) → 복귀율 미달(R40) 입니다. 원가가 비어 있으면 뒤의 비율 계산이 의미가 없기 때문에 그것을 가장 먼저 둡니다.
원가 미집계는 왜 따로 둡니까?
재작업 수량은 있는데 재작업 원가가 0 이면 리포트에서는 문제가 없어 보입니다. 하지만 실제로는 확인 실적과 원가 집계가 연결되지 않았을 가능성이 있습니다. 이 사례에는 3건이 있고, 원인을 단정하지 않은 채 공정 실적과 원가 집계의 연결을 확인하라고 안내합니다.
월이 점검 필요가 되는 조건은 무엇입니까?
월 재작업률이 6% 를 넘거나 그 달의 점검 필요 오더가 세 건 이상일 때입니다. 이 사례에서는 4 · 5 · 6월이 점검 필요 오더 3건씩이라 해당합니다. 월 재작업률 자체는 5월 4.14% 가 가장 높아 6% 한도에는 못 미칩니다. 비율은 낮아도 이상한 오더가 늘어나는 달을 놓치지 않으려고 건수 조건을 함께 두었습니다.
SAP 연계와 데이터
SAP 표준 화면으로는 무엇이 부족합니까?
표준 T-code 는 오더 하나를 조회하거나 차이를 보는 데 강합니다. 다만 재작업을 따로 떼어 오더 · 원인 · 월로 가로질러 보는 화면은 직접 만들어야 합니다. 이 앱은 표준을 대체하지 않고, 표준 거래로 확인하러 가기 전에 어디를 볼지 좁혀 주는 자리에 둡니다.
어떤 T-code 와 이어 봅니까?
오더 상세는 CO03, 표준 차이 금액은 KKBC_ORD, 노무 · 기계 배부 금액은 KSB1, 정산 전 재작업 원가가 실려 있는지는 KO88 로 맞춰 봅니다. 대사와 감사 대응은 표준 거래가 맡는 편이 안전하므로 기존 화면을 없애지 않습니다.
원천 테이블은 어디입니까?
오더는 AUFK · AFKO, 공정은 AFVC, 수량과 시간은 확인 실적 AFRU, 원가 금액은 COEP · COBK 입니다. 필드 이름과 원가요소 그룹은 릴리스와 고객 설정에 따라 달라 구현 전에 대상 시스템에서 확인해야 합니다.
재작업 오더를 별도 오더 유형으로 쓰는 회사는 어떻게 합니까?
이 화면은 재작업을 원 오더의 확인 실적에서 읽는 구성으로 만들었습니다. 재작업을 별도 오더로 발행하는 회사라면 그 오더를 원 오더에 어떻게 묶을지부터 정해야 합니다. 저는 그 구성을 단정하지 않았고 확인 필요 항목으로 남겼습니다.
실제 시스템에 연결하려면 무엇이 필요합니까?
화면은 OData 서비스만 바라봅니다. manifest 의 서비스 주소를 실제 OData 서비스로 바꾸면 화면은 그대로 동작합니다. 서비스 쪽에서는 원천 필드 매핑, 표준 재작업 단가, 재작업 원인 코드 체계를 먼저 정해야 합니다. 이 세 가지는 코딩이 아니라 합의입니다.
샘플 데이터는 실제 데이터입니까?
아닙니다. 모두 가상의 검증용 자료입니다. 2026년 1~6월, 월 14건씩 오더 84건, 제품 8종, 원인 6종으로 만들었고 판정 기준에 걸리는 건을 일부러 넣었습니다. 숫자를 보고 실제 회사의 수준을 판단하시면 안 됩니다.
운영과 도입
권한은 어떻게 겁니까?
회사코드 · 플랜트 · 오더 유형 같은 표준 권한 기준을 CDS 의 집계 단계에 겁니다. 집계를 읽는 곳에 걸지 않고 상세에만 걸면 합계와 상세의 차이로 남의 숫자가 드러납니다. 권한 기준은 보안 담당과 먼저 합의할 항목입니다.
오더가 수십만 건이면 어떻게 됩니까?
이 사례는 오더 84건이라 화면이 묶어도 되지만 운영 규모에서는 집계를 CDS 로 내려야 합니다. 월 · 원인 집계는 서비스에서 계산해 건수만 가져오고, 오더 목록은 $top 과 $skip 으로 나누어 받습니다. 아래 CDS 장에서 이어서 설명합니다.
기존 원가 리포트를 없애야 합니까?
없애지 않습니다. 법정 보고와 감사 대응은 표준 거래가 맡는 편이 안전합니다. 이 앱은 조회와 점검용이며, 쓰기 기능이 없고 전기나 정산을 대신하지 않습니다.
도입 전에 가장 먼저 정할 것은 무엇입니까?
세 가지입니다. 재작업 수량과 폐기 수량을 확인 실적의 어느 필드로 읽을지, 재작업 원가에 넣을 원가요소 그룹을 어디까지로 할지, 표준 재작업 단가를 어디서 가져올지입니다. 이 셋이 정해지면 기술 작업은 CDS 뷰를 만들고 서비스를 연결하는 일로 줄어듭니다.
현재 SAP 환경에서 어떻게 적용되는지 확인해 주실 수 있습니까?
네. 오른쪽 문의하기로 사용 중인 SAP 환경(S/4HANA · ECC)과 재작업을 다루는 방식을 알려 주시면 함께 확인해 드립니다. 데모는 목차의 데모 열기에서 바로 보실 수 있습니다.