콘솔 로그에 query조회시 로그가 두번씩 중복해서 남는 현상이 발견되었습니다. 모든 경우는 아니었고 어떨 때는 두번 나오고 대부분의 경우 한번만 표시가 되었습니다. log4j2부터 모든 부분에서 원인을 찾아보너라 약 일주일 정도 동안 머리속을 떠나지 않는 고민이었습니다.

우선 상황을 재연해보았습니다. 여러 경우의 데이터를 넣어보았고, 결과적으로 중복로그가 나오는 경우는 하나의 데이터도 조회되지 않는 경우라는 사실을 발견하였습니다. (이 정확한 원인이 되는 경우의 수를 찾는데도 약 3일정도의 시간이 걸린 것 같습니다.) 사용하고 있는 프레임워크가 넥사크로였기에 구글링과 넥사크로 메뉴얼을 뒤져서 메뉴얼에도 잘 나오지 않는 원인을 파악 할 수 있었습니다. 심지어는 넥사크로 고객센터에 연락했으나 제대로 된 답변을 얻지 못하였습니다.

중복 에러가 발생하는 이유는 다음과 같았습니다. 데이터를 가져올 때, Row값이 0이면 데이터가 없다고 판단하여 컬럼명을 가져오지 않게 됩니다. 칼럼명을 가져오기 위해 넥사크로에서는 해당 쿼리를 사용해서 헤더정보를 재조회하는 쿼리를 보내게 되고 이때 두번째 로그가 남게되는 것이었습니다.

원인을 알았으나 해결책은 없어보였습니다. Log4j와 같은 로그 프레임워크에서 관리할 수 있는 영역이 아니었기 때문입니다. 넥사크로에서 제공하는 uiadaptor의 방식 자체가 query를 두번 보내는 방식을 사용하기 떄문이었습니다.

좀 더 확인해보니 좀 더 정확한 내용을 구글 검색을 통해 발견 할 수 있었습니다. 중복 로드가 발생한 더 근복적인 원인은 Map을 사용하였기 때문입니다. VO를 사용할 경우 vo의 변수이름 가져와 헤더를 구현하는데 Map의 경우 헤더 정보를 가져올 자료가 없어 문제가 발생한 것이었습니다. 즉, VO를 사용할 경우, 중복로그를 막을 수 있었는데 결과적으로는 VO로 변경할 떄 자료가 틀어질 우려가 있어 보류되게 되었습니다.

되돌아보며..

Map보다는 VO를 사용하는 것이 더 객체지향적이라는 사실을 잘 알고 있습니다. 단기적으로는 Map을 사용하는 것이 작업을 줄일 수 있을지 모르지만, 장기적으로 유지보수함에 있어서 코드와 자료의 내용을 파악하기가 점차 어려워지고 복잡해지기 때문입니다. 그러나 Map을 사용하기로 정해졌다면 그 안해서 최적화되고, 잘 만들어진 프로젝트를 즉 중복로그가 생성되지 않는 프로젝트로 완성하고 싶었으나 욕심과 달리 기한과 데이터의 변형에 대한 우려로 인해 하지 못한 것에 대한 아쉬움이 많이 남는 것 같습니다. 단위테스트를 생활화한 프로젝트였다면 이런 변경과 변형에 더 자유롭고 안정적이었을 것이라는 아쉬움이 남습니다.