'npe'에 해당하는 글 1건

336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
최근 리팩토링 경험담이라는 시리즈 글을 쓰고 있습니다. 해당 시리즈 글의 흐름상 이 글의 내용이 부분적으로 들어가게 되어 아래 글을 해당 문백에 맞도록 약간의 수정을 하고 이동시키게 되었습니다. 원래 글의 내용은 취소선을 그어 남겨놓았으며, 내용은 거의 유사하오니 가능하면 아래 링크를 통해 해당 글과 관련 글을 읽어보시기를 추천드립니다. 불편을 드려 죄송합니다.

이동한 주소 리팩토링 경험담 #8 - 검증시점을 앞당기기 위한 빠른 실패

올해 초 저는 서버에서 발생하는 NullPointerException를 수정하는 업무를 하게 되었습니다. 로그를 보니 다양한 상황에서 다양한 형태로 NullPointerException이 발생하고 있었습니다. 그런데 업무을 진행하며 문제를 분석하다보니 그동안 어렴풋이 생각하던 부분이 좀더 명확해졌고 저는 이번 글에서 당시 했던 생각을 나눠보고자 합니다.

아래는 오류의 원인을 찾고있는 한 개발자의 가상사례입니다.
어느날 한 개발자가 웹 애플리케이션의 오류로그를 살펴봅니다. 그런데 데이터베이스에 나이를 저장하는 쿼리 부분에서 제약조건위배 오류가 발생하고 있습니다. 오류에 대해 자세히 살펴보니 나이 필드에 NOT NULL 제약이 걸려있음에도 Null 값이 입력되고 있다는 내용입니다. 곧바로 쿼리 부분에 문제가 있나라는 생각이 머리에 스칩니다. 소스를 재빨리 찾아 쿼리에 값을 넣어주는(Binding) 부분을 자세히 살펴봅니다. 그런데 큰 문제가 없어보입니다. 자연스럽게 비즈니스 레이어(Business Layer)를 살펴보게 됩니다. 혹시 나이 부분에 대해 뭔가 다루는 부분이 있나 자세히 살펴봅니다. 하지만 특별한 것을 발견하지 못합니다. 마지막으로 프리젠테이션 레이어(Presentation Layer)를 살펴봅니다. 그리고 프리젠테이션 레이어에서 나이 값이 잘 들어왔는지에 대한 검사를 하고 있지 않다는 것을 발견합니다. 거의 이 부분이 원인일 것이라 생각하지만 확신할 수는 없습니다. 왜냐하면 프로그래밍에는 너무 다양한 상황이 있다는 것을 알고 있기 때문입니다. 

2010/02/18 추가 
위의 경우는 오류로그가 Stacktrace를 포함하지 않는 경우에만 유효한 이야기입니다. 왜냐하면 Stacktrace를 볼 수 있다면 원인을 금방 알아낼 수 있기 때문입니다. 따라서 좀 억지스럽지만 Stacktrace를 찍지 않았다고 가정한 경우로 생각하시고 본래 전달하고자 하는 의미에 집중해주시면 좋을 것 같습니다.

위의 예를 통해 저는 두 가지 문제점을 봅니다. 첫 번째는 개발자가 원인을 조사하기 위해 여러 파일들을 살펴보아야 했다는 점입니다. 두 번째는 시간을 들여 여러 파일을 살펴보았음에도 불구하고 명확한 결론이 아닌 거의 확실한 추정 정도의 수준에서 조사를 끝낼 수 밖에 없다는 것입니다.  

여기서 위 사례에 한 가지 가정을 더해보겠습니다. 마지막에 개발자가 추정한 것이 실제원인이였다는 가정입니다. 이 가정 하에서 보면 위와 같이 일을 어렵게 만든 원인을 알 수 있습니다. 바로 '오류 희석'입니다.

널리 사용되거나 공식적인 용어는 아니지만 오류 희석은 시간 혹은 공간을 지남에 따라 오류가 본래의 모습을 점점 잃어버리는 것을 뜻합니다. 위 사례의 경우 근본 원인은 사용자가 나이를 입력하지 않았다는 것입니다. 하지만 실제적으로 문제는 프리젠테이션 레이어와 비즈니스 레이어를 지나 데이터베이스에 질의하는 부분에서 전혀 다른 모습으로 발생하였습니다. 그 결과로 개발자는 문제를 찾기위해 문제가 발생한 지점 까지 도달할 수 있는 모든 경로를 역추적해야 했습니다. 

그렇다면 해결책은 무엇인가요? 해결책은 무척 간단합니다. 바로 프리젠테이션 레이어에서 나이가 정확히 들어오는지를 검사하고 만약 나이가 정상적으로 들어오지 않는다면 엄격하게 예외처리를 해주면 됩니다. 사용자에게 '나이를 입력해주세요.'라는 문구를 보여줄 수도 있고, 바로 에러를 발생시켜 처리를 중지할 수도 있습니다. 이렇게 처리한다면 문제가 발생했을 때 사용자든 개발자든 문제를 정확히 알 수 있습니다. 특히 개발자가 에러로그를 보았을 경우 개발자는 소스 파일을 탐색하거나 추정을 할 필요가 없습니다. 왜냐하면 에러로그 그 자체만으로도 무슨 문제인지 너무나도 명확하게 알 수 있기 때문입니다.

Fedex에는 1-10-100 원칙이라는 것이 있다고 합니다. 간단히 설명하자면 문제를 조기에 처리하지 않으면 처리비용은 점점 증가한다는 것입니다. 저는 소프트웨어 개발의 많은 부분에서도 동일한 원칙이 적용된다고 봅니다. 문제가 발생했을 때 그 문제가 시간 혹은 공간을 지나기 전에 가능한 빨리 인지하고 처리하면 보다 낮은 비용으로 처리가 가능하지만, 그렇지 못했을 경우에는 위 가상사례와 같이 더 많은 비용이 필요하게 되는 것입니다. 특히 S/W분야에서는 추구하는 방향 관점에서 보았을 때 빠른 실패(Fail-Fast)가 Fedex의 1-10-100 원칙과 유사점을 가집니다. 좌측 링크가 걸린 위키피디아 내용에서 직접적으로 언급되지 않았습니다만, 필요한 곳에서 적절히 사용된 빠른 실패는 많은 비용을 줄일 수 있을 것입니다.

하지만 주의해야 할 점은 모든 곳에서 빠른 실패가 필요하지는 않다는 점입니다. 때로는 문제 혹은 결함을 허용하는 것이 매우 중요한 일인 경우가 있습니다. 예를 들어 포털의 메인화면을 생각해볼 수 있습니다. 포털의 메인화면은 매우 다양한 구성요소로 이루어져 있습니다. 그런데 그 중 우측 하단 쇼핑 정보를 가져오는 부분에 문제가 생겼다고 가정을 해봅시다. 이 경우 화면을 보여주기 위한 모든 처리를 중지한 후 화면을 표시하지 않는 것 보다는 그 부분을 제외하고 다른 부분은 정상적으로 보여주는 것이 현명한 판단일 것입니다. 

2009/05/06 ~ 2009/12/02




'

WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

,