'오류희석'에 해당하는 글 1건

336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
지금까지의 글에서 검증시점을 앞당김으로 인해 발생하는 이익에 대해서 소개했고 이어 구체적으로 사용할 수 있는 여러 가지 방법에 대해 소개했습니다. 하지만 글의 흐름상 언급하지 못한 부분이 있어 여기서 소개합니다. 지금까지 했던 얘기해서 크게 벗어나는 얘기는 아니고 동일한 맥락을 가지고 있기 때문에 참고하면 좋을 것 같습니다. 아래는 오류의 원인을 찾고 있는 한 개발자의 가상사례입니다.

어느 날 한 개발자가 웹 애플리케이션의 오류로그를 살펴봅니다. 그런데 데이터베이스에 나이를 저장하는 쿼리 부분에서 제약조건위배 오류가 발생하고 있습니다. 오류에 대해 자세히 살펴보니 나이 필드에 NOT NULL 제약이 걸려있음에도 NULL 값이 입력되고 있다는 내용입니다. 그런데 오류를 자세히 보니 실행경로를 보여주는 Stacktrace 정보가 없습니다. 코드를 보니 누군가가 Exception을 잡아서 그냥 한 줄 로그만 출력하게 해놓았습니다. 이런! 열악한 상황이지만 어쨌든 문제는 찾아야 하기 때문에 쿼리 부분에 문제가 있나 라는 생각을 해봅니다. 쿼리에 값을 넣어주는(Binding) 부분을 자세히 살펴봅니다. 그런데 큰 문제가 없어 보입니다. 그 다음으로는 자연스레 서비스 레이어(Service Layer)를 살펴보게 됩니다. 혹시 나이 부분에 대해 뭔가 다루는 부분이 있나 자세히 살펴봅니다. 하지만 특별한 것을 발견하지 못합니다. 마지막으로 프리젠테이션 레이어(Presentation Layer)를 살펴봅니다. 그리고 프리젠테이션 레이어에서 나이 값이 잘 들어왔는지에 대한 검사를 하고 있지 않다는 것을 발견합니다. 거의 이 부분이 원인일 것이라 생각하지만 확신할 수는 없습니다. 왜냐하면 프로그래밍에는 너무 다양한 상황이 있다는 것을 알고 있기 때문입니다. 

위의 예를 통해 저는 두 가지 문제점을 봅니다. 첫째는 개발자가 원인을 조사하기 위해 여러 파일들을 살펴보아야 했다는 점입니다. 두 번째는 시간을 들여 여러 파일을 살펴보았음에도 불구하고 명확한 결론이 아닌 거의 확실한 추정 정도의 수준에서 조사를 끝낼 수 밖에 없다는 것입니다. 여기서 위 사례에 한 가지 가정을 더해봅시다. 마지막에 개발자가 추정한 것이 실제원인이었다는 가정입니다. 이 가정 하에서 보면 위와 같이 일을 어렵게 만든 원인을 알 수 있습니다. 바로 '오류 희석'입니다.

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

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

위에서 얘기한 것은 빠른 실패(Fail-Fast)의 대표적인 예입니다. 빠른 실패(Fail-Fast)는 이전에 언급했던 Fedex의 1-10-100 원칙과 유사점을 가집니다. 빠른 실패의 취지는 이왕 실패할거면 빨리 실패하자는 것입니다. 왜냐하면 위의 예대로 잘못된 부분이 있음에도 실패하지 않고 시간이 지나다 보면 오류희석으로 인해 잘못된 부분을 점점 탐지하기 어려워지고 실패에 대한 처리 또한 어려워지기 때문입니다. 그래서 앞서 얘기했던 검증시점을 앞당기려면 보다 빠르게 실패하는 것이 좋습니다.

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


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

,