로직의 오류를 잡아내야 하는 경우에 있어 방어로직이 필요한가?

2018-08-06 17:28

서버 api 를 설계하다 보면 부딪히는 문제 중 하나가.

서버 로직의 오류를 예외핸들링 하는 경우에 대해 판단해야하는 경우입니다. 제목처럼 방어로직이 필요한가? 에 대한 가치판단이 필요한.. (대안이 처음부터 있는 설계라면 이런 설계가 되지 않았겠지만, 어쨌든 대안이 없다는 가정아래 얘기하는 부분이니 ^^;; 잘된 설계 잘못된 설계 이런 얘긴 논외로 하고..)

억지스럽게 예를 하나 들어보자면, ThreadLocal 을 활용해서 layer 간에 특정 데이터를 담아서 통신을 하는 경우. 서버 로직 개발자들끼리 커뮤니케이션을 통해서 Controller 에 반드시 특정 데이터를 ThreadLocal 에 담기로 했다고 가정을 합니다. 그리고 Service layer 담당 개발자는 ThreadLocal 에 데이터가 담겨있다고 가정을 하고 Service layer 개발을 합니다.

이때 만약, Service layer 개발자가 해당 데이터를 다루는 코드에 방어로직을 넣는다면..?

단 한 번의 테스트만으로 핸들링되지 않는 예외가 발생하면서 바로 잡을 수 있는 코드가 방어로직으로 인해 짬처리가 된다면... 잠재적인 예외가 내포된 코드가 될 수 있다고 생각합니다. 런타임에서 발현 가능한 예외처리에 대해서, 서버에서 코드수정을 해야만 하는 코드들이라면. 가능한 최대한 빠르게 예외를 찾아내야하고 그에 대해 픽스할 수 있어야 한다 생각합니다.

방어로직의 삽입은 일반적으로 친절한 코드입니다만, 핸들링할 수 없는 경우에 대한 방어로직의 삽입은 잠재적인 치명적인 버그를 숨겨두는 셈이라 생각합니다.

특수한 상황에 있어서의 방어로직에 대한 짧은 생각을 적어봅니다.

0개의 의견 from SLiPP

의견 추가하기

연관태그

← 목록으로