---
title: Post Mortem 23.08.25
---
# 사후분석 : 포스 컨트롤 사용 안하는 부품 저장시 저장 안되는 문제

## 사후 분석 진행 순서

### 1. 결함 식별

- 결함이 발견된 시기와 장소:
- 결함 현상 :
- NPE에서 부품 편집후 저장 버튼 누르면 'Force Control 값이 범위에 벗어남' 에러가 발생하며 저장안되는데 포스관련UI는 보이지 않아서 수정이 불가.
- 임시조치방안 : 장비타입을 포스 지원하는 장비로 바꾼뒤에 포스 값 수정하고 저장해야 함.
- 결함 생성 :
- 7/10 NPE 트렁크 [artf120406]
- r62205 - XM520에서 Force Control 값 10000 넣고 SM411로 바꿔서 저장하면 저장되는 문제 수정. 하면서 발생.
- 결함 배포 :
- 7/14 4.6 브랜치 r62265 머지.
- 7/25 4.600.000.020 발행
- 결함 발견 :
- 7/24 통합검증시 김률 책임이 발견
- https://trello.com/c/L15dpUWq
- 결함이 발견된 시스템/모듈/기능:
- NPE
- 결함의 유형:
- 해당경우에는 부품저장이 안되는 A급 결함

### 2. 결함 분석

- 결함 발생 원인:
- 박현제연구원이 통합검증시 발견한 문제점 'XM520에서 Force Control 값 10000 넣고 SM411로 바꿔서 저장하면 저장되는 문제'를 해결하기 위해 수정했는데, 사실 이게 문제가 아니라 원래 이렇게 동작해야 하는 것이었음.
- 사양을 몰랐음.
- 포스컨트롤 안되는 장비에서는 체크안해야 한다는 점을 몰랐음.
- 오히려 체크안하던 코드를 체크하도록 수정하여 결함 발생.

// if (UPEUtility.IsCurrentMachineCheckPickPlaceDelayWhenForceControlInUse() == true)
// {
   if (!new PickPlaceDelayRangeValidataionRule().Validate(null, null).IsValid)
   {
        UPEUtility.LogMethodFail("TitleAndNavigationviewModel", "ExecuteSaveCommand", "PickPlaceDelayRangeValidataionRule.Validate");
    }
// }

- 결함이 발견되지 않았던 이유:
- 검증시에도 틀린 사양에 맞춰서 검증하여서 발견 안됨.
- 유닛테스트도 틀린 사양에 맞춰서 작성되어서 발견 안됨.
- 리뷰는 했는가?
- 했음
- 결함이 야기한 영향:
- 해당 버전 고객사 적용 중지되어 손실.
- 내부통합검증에서 검출되어 고객사에는 문제 안됨.
- XM520, HM520W에는 적용되었으며 포스컨트롤 지원 장비여서 문제안됨
- HM520에는 미적용으로 영향 없음
- 결함 수정에 필요한 자원:
- 박형근

### 3. 결함 수정

- 수정된 코드/패치:
- 7/26 r62391 PickPlaceDelayRangeValidationRule.cs

            public override ValidationResult Validate(object value, System.Globalization.CultureInfo cultureInfo)
        {
            // ...
            +// ForceControl 사용안하는 장비는 체크하지 않는다.
            +if (UPEUtility.IsCurrentMachineSupportForceControl() == false)
            +    return new ValidationResult(true, "Valid");

- 수정된 코드/패치의 효과:
- 검증 완료.
- 유닛테스트도 수정하여 검증 완료
- 수정 작업에 사용된 자원:
- 박형근
- 수정 작업의 기간:
- 8시간

### 4. 결함 예방

- 이러한 결함이 다시 발생하지 않도록 하는 방법:
- 사양 확인. 수정전에 미리 최수석에게 한번 확인받자?
- 유닛테스트에 케이스 추가.
- 결함 예방을 위해 변경된 프로세스/절차:
- 추가적인 QA/QC 검증:

### 5. 결함 관리

- 결함 추적/관리 도구:
- 결함이 발생한 이유와 원인을 분석하여 개선할 점:
- 결함을 예방하기 위한 계획:

## 5 Whys

| 왜? | 원인 | 할 일 |
| ---- | ---- | ----- |
| Text | Text | Text |
| Text | Text | Text |
| Text | Text | Text |
| Text | Text | Text |
| Text | Text | Text |

## PokaYoke
- 에러를 만들지 않는 방법
- 에러가 만들어지면 알람을 주는 방법 (지도카, 안돈)

## KPTA
- Keep (잘한점)
- 김률책임이 잘했다. 그래서 고객사는 문제없었다.
- 리드타임내에 고쳤다. 8시간소요.

- Problem (개선할점)
- 코드수정시 코드위에 아티팩트와 내용이 적혔있었다면 찾아봤을텐데
- 이런 경우가 많아서 장비/OLP/Elite에 따라 고려를 많이 해야한다. 잊지말고. 특히 NPE는 다 같이 쓰니까.
- 장비별로 다른 사양의 파라미터에 대한 절차서는 없을까? 체크리스트?
- 딜레마인것들이 많아서 ...
- 보수적으로 받아들이고 많이 방어를 해주고 신중을 기하도록 체크리스트도 만들자.
- 파라미터 추가도 여기저기 다발로 들어온다.
- 부품 타입을 고려해야 하는 파라미터도 있다.
- 비전이 많이 요청한다.
- 고객 신경안쓰고 구현위주로 요청되는 경우 많다.
- 피더팀이 외부에서 요구사항이 많은데 되게 보수적으로 접근한다. 잘 안들어준다. 그게 맞는것 같다.
- Show/Hide 되는 파라미터 많은가? => 많다.
- 파라미터가 많다는 VOC때문에 일부러 안보이게 한다.
- TC 테스트를 기능구현에 반대되는 것에 대한 테스트를, 기능구현과 상반되는 테스트를 만들어서 테스트하자
- 이 이전에 딜레이 값 자체도 문제다. 현재 절대값인데 %또는 레벨값으로 하면 어떨까?
- Try (시도할것)
- 개인적으로는
- 사양 다시 한번 확인
- 보수적으로 접근, 최대한 원래 동작 유지하면서 수정
- 특히 NPE는 여러군데에서 쓰이니까 두번 생각하기
- 기능구현과 상반되는 테스트 하기
- 이미 DB,PCB에 들어있는 이상값도 고려하기.
- 사전에 보정하는 함수 DoCorrection()에서 체크.
- 개인 체크리스트를 만들어서 체크하겠음.
- 이미 누군가가 수정한 것을 다시 수정할때는 일단 물어보자. 일단 짚고 넘어가자.3
- 좀 덩어리 큰 기능테스트는 통합 검증 환경을 사용하자.2
- 코드수정할때 수정한사람. 이름, 아티팩트, 고려사항 꼭 적자.4
- 주석을 아끼지 말자. 일기는 쓰지 말자. 특히 사양과 관련된것.1
- ASSERT도 아끼지 말자.1
- Action (할일)
- 개인적으로는
- 사양 다시 한번 확인
- 보수적으로 접근, 최대한 원래 동작 유지하면서 수정
- 특히 NPE는 여러군데에서 쓰이니까 두번 생각하기
- 기능구현과 상반되는 테스트 하기
- 이미 DB,PCB에 들어있는 이상값도 고려하기.
- 사전에 보정하는 함수 DoCorrection()에서 체크.
- 개인 체크리스트를 만들어서 체크하겠음.
- 이미 누군가가 수정한 것을 다시 수정할때는 일단 물어보자. 일단 짚고 넘어가자.3점
- 코드수정할때 수정한사람. 이름, 아티팩트, 고려사항 꼭 적자.4점