Risk Mgmt: Known-Knwon to Unkonw-Unknown

오늘 장애가 났다.

Map<String,Integer> 타입의 map에서 값을 꺼내와서 반환형이 int인 함수의 반환값으로 사용하는 코드이다.

public int getSomething(int x){

  return map.get(x);

}

map.get(x) 했을 때 적절한것이 없으면 null을 반환한다는 사실은 알려져있다.

null을 int로 casting 할 수 없다는 사실도 알려져있다.

하지만 return map.get(x)만 보고 NPE가 날것이라고 생각 못한 상황이다.

Known-Unknown Risk일까?

Unknown-Known Risk일까?

아니면 둘 다 아닐까?

해결법은 뭘까?

정적 코드 분석으로 잡아낼 수 있을까? -> 이건 미티게이션인가? 컨틴전시 플랜일까? 아니면 다른 무엇일까?

적어도 action 레벨에서는 try..catch해서 처리했어야 했다. -> 이건 미티게이션이라고 볼 수 있겠지?

ㄴ 무엇일지는 알 수 없지만 뭔가 발생할 수 있다는 점을 인지하고 있을 때의 대처법... 방어적 코딩..

안전한 코딩을 Risk Mgmt.와 연관지어 설명할 수 있을 것 같으면서도... 뭔가 매끄럽게 이어지질 않는다.

그래서 그림1, 그림2, 그림3 같은 것들도 구글링해서 찾아보고

집에있는 PMBOK이나 관련 책도 뒤져봤다...근데 Known/Unknown-Known/Unknown에 대한 언급을 못찾았다.

그러던 중에...링크1을 찾았다...

knwon knowns 류의 말은 2002년 럼스펠트가 얘기하면서 널리 퍼졌는데 이 용어에 대한 긍정/부정 다양한 평가들이 나왔고...위키 페이지 내용은 주로 까는 쪽이다..;;

아래 그림들을 대충 보면 알것 같으면서도 모르겠는 용어인건 맞는것 같다...뭐 내가 영어권 사람도 아니고 머리가 나빠서 이해 못하는 것일 수는 있겠지만..;;

근데 또 웃긴건 설명을 듣다보면 그럴듯 하긴 하다. 문제는 설명들이 미묘하게 다른데 누가 정답인지 모른다는거?

그림1의 챠트가 좀 직관적으로 이해가 되는데, 아래 축의 Unkown/known을 그림2에서와 같이 Unconscious/Conscious로 바꾸면 좀 더 이해가 쉽다.

U/K x U/K로 구성된 2x2 매트릭스인데, 앞단의 U/K는 내가 인지하고 있는지 여부(Conscious or not)이고

뒷단의 U/K는 알려진 사실인지 여부이다. 물론 우주적으로 알려졌는지를 따진다면야 안알려진것이 없겠으니, "내가 찾으려고 했다면 찾을 수 있었을 정도로 근처에 있는 범위 안에 존제하는 정보" 쯤으로 보면 되려나?

그림1은 2x2 매트릭스가 데이터가 많을 수록 좋은쪽으로 변할 수 있다는 내용..으로 보이고.

그림2는 Known-Unkonwn과 Unknown-Unknown 만을 사례를 들어 보여준것.

그림3은 KK을 뺀 나머지 3가지에 대한 설명이다.

가장 애매한게 Unknown-Known인데(그림1의 왼쪽위)

- 내가 이미 알고는 있었지만 떠올리지 못한 것 -> 이게 딱 위 장애의 원인.

- 내가 이미 알고 있지만 무의식중에 인지하기를 거부하고 있는 것.

- 나는 모르지만 내 주변 동료들은 알고 있었던 것 -> 링크2의 사례처럼 같은 회사의 다른 부서가 같은 목적물을 몰래 만듦.

- 나는 모르지만 고객은 알고 있었다. -> 그림2의 오른쪽 위와 같이 Requirment를 제대로 수집했는지 등을 따져물음.

Known-Unknown도 애매하기는 한데...알고는 있지만 확신은 없는 경우들이다..

- 과연 우리가 고객 요구사항을 확실히 받은 것일까? 만약 아니라면 어떤 대비책을 마련해놔야 하나?

- 음...애매하다..;;

사실...

KK는 알고 있는 사실이니 그에 맞게 대처하면 될 사항들.

UU는 이세상에 100%는 없으니 어떤 경우에도 폭삭망하지 않을 대비책은 만들어두자는 수준의 대응책들. 예비비를 두는 것이 전형적인 예.

나머지는 KU이든 UK든 어쨌든 최대한 예상 가능한 Risk들을 자주 반복되는 Risk 목록등을 활용해서 리스트업하고, 고객 및 주변 관련자들과 최대한 정보를 모으고 분석해서 Risk를 파악해내는 정도로 대응할 건들이다...

그래서 이걸 어떻게 코딩에 접목하지???

접목하는게 의미가 있긴 할까???

모르겠다..;;

아무튼, 이번 장애는

1. 알려진 사실들의 조합으로 장애가 날것을 예측할 수 있었으나 실패한 것이고.

2. Integer를 int로 캐스팅할때 NPE 가능성에 따른 정적코드분석을 통해 대응가능할것 같기는 한데..사실 정적분석 돌리기만하고 보진 않고 있으니 이거로 해결 될지 미지수고...워낙 defact가 많아서 손 놓음..;;

3. 어쨌든 최종 fail over로써 넣었어야할 코드가 이상한 위치에 있었기 때문에 Sidemenu 전체가 문제가 됐던거니 이 부분은 바로 개선해야 하겠다...

그림1: http://www.govloop.com/community/blog/im-v-km/#comment-29064

그림2:http://donmcalister.com/2012/02/23/knowledge-risk-management-competence/

그림3:http://smartorg.com/2013/07/valuepoint19/

링크1:http://en.wikipedia.org/wiki/There_are_known_knowns

랑크2:http://books.google.co.kr/books?id=vqnTceVAjsUC&pg=PA55