오늘은 재미있는(?) 디버깅 이야기이다.
우리가 프로그래밍(아니면 코딩이던..)을 하게 될때면
IF, ELSE와 같은 조건문을 숱하게 사용하게 될 것이다.
이럴때 기존의 처리 로직에 뭔가를 테스트를 하고 있었다면
해당 내용을 프로덕트에 배포하기 전에 꼼꼼히 점검하지 않으면
믿어 의심치 않았던 기존로직에 테스트 코드가 섞여 들어갈 수 있고
이는 바로 운영상황에서의 오류로 직결 될수가 있기에
이를 제대로 점검해야 한다는.. 이런 이야기이다.
꼭 개발자가 아니라도
어떤 상황에서 이런 오류가 발생할 수 있는지 간접체험 해봄으로써
일반인들이 봤을때?(^^;) 소프트웨어는 왜 이렇게 오류가 많은지
또 왜 테스트가 그토록 중요한지 알아볼 수 있는 즐거움이 있을 것이라고 생각한다.
물론 지금부터 언급할 사례가 아주 일반적인 것은 아니고
세상의 많은 소프트웨어들은 철저한 테스트 후에
사용자 환경에 적용되고 있다는 것을..
그리고 IT 직업에 종사하고 있는 많은 사람들이
모두들 이런 노력을 기울이고 있다는 것을 먼저 밝혀둔다. ^^;
자, 그럼 시작해 본다.
기존의 로직에 새로운 처리를 추가하기 위해서는
보통 기존의 로직을 논리적인 단위로 묶고 그 부분을 IF 또는 ELSE 부분에서 처리하고
새로운 처리 로직을 그 외의 부분에서 처리를 하게 되는 경우가 있다.
그러나, 이 조건문 처리를 하기 전에
기존 로직에 여러가지 테스트를 하던 중이었다면
기존의 테스트 로직이 섞여 들어갈 수 있는 것이다.
예를 들어 아래와 같은 처리 로직이 있었다고 하자.
some_result = other.system.method?jsondata=https://www.othersystem2.com/v1/testprocess
(실제 특정 개발 언어 사례가 아니기 때문에 개념적인 처리 내용만 이해하면 된다.)
처리는 간단하다.
어떤 처리를 하는지 그 내부를 명확히 볼 수 없는 시스템(other.system)이 있고
그 시스템의 함수(method)를 호출한다고 하자.
그럼 어떤 결과를 반환해 줄것이고 그것을 some_result라는 변수에 저장한다.
여기서 파라메터로 넘길 수 있는 것은 jsondata인데 파라메터명에서 유추할 수 있는 것처럼
JSON형태의 데이터를 넘겨야 하는 것을 알 수 있다.
(타 외부 시스템과의 연동을 할때면 대개의 경우 변수명에서부터 유추할 수 있는 정보들이 많다.)
그럴때 저 특정 URL을 통해서 JSON 데이터를 반환받고
(위의 예제로 보면 https://www.othersystem2.com/v1/testprocess 이 URL이 되겠다.)
그 데이터를 다른 시스템에 넘겨서 some_result라는 변수에 결과를 받아야 한다.
물론 반환받는 데이터는 JSON 데이터 형태여야 할 것이고
그런 형태가 아니라면 아마 데이터 형식이 잘못되었다는 형태의
오류 메시지를 받게될 가능성이 많다.
참고로 JSON은 JavaScript Object Nation의 약자로 텍스트 기반의 데이터 표현 형식인데
{"key": "value"} 또는 [ {"key1":"value1"}, {"key2":"value2"}] 와 같이 표현한다.
즉 어떤 내용(value)을 키에 해당하는 변수에 담는 방식으로서 예를 들면 아래와 같다.
{
"이름": "홍길동",
"나이": 1000
}
[] 이렇게 대괄호로 감싸져 있는 것은 배열로 여러개의 구조가 담기고
{} 이렇게 중괄호로 감싸져 있는 것은 하나의 구조가 담겼다는 의미인데
추후에 인터넷을 검색해보면 그 원리는 간단히 파악이 가능할 것이다.
어쨌든.. 이렇게 JSON 데이터를 받아야 할것 같은데
왠일인지 의도하는대로 처리가 되지 않는다.(고 가정해보자)
그렇다면 여러가지를 테스트 해볼 수 있는데
먼저 https://www.othersystem2.com/v1/testprocess 이 URL을 호출했을때
올바른 형태의 JSON 데이터가 반환되는지를 먼저 확인해 볼 수 있다.
아마 대부분은 이 단계에서 처리가 될 것이다.
JSON으로 데이터를 반환하지 않는다고 othersystem2 쪽에 연락을 취하면 될것이고
이후 테스트를 진행하면 성공일 것이기 때문이다.
그러나 이 테스트가 제대로 되지 않거나
other.system.method가 어떤 처리를 하는지는 잘 모르겠는데
어쨌든 JSON 데이터를 잘못 넘기는 것 같다고 추측이 될때는
직접 JSON 형태의 데이터를 넘겨 보면서 테스트를 해볼 수 있는 것이다.
바로 아래와 같은 형태이다.
some_result = other.system.method?jsondata={"이름": "홍길동", "나이": 1000}
좋다.. 이제 정상적으로 some_result에 결과를 받아올 수 있었다.
그럼 어떻게 해야 할것인가?
이제는 분기처리를 해야 할 것이다.
바로 아래와 같은 형태로
jsonstring = {"이름": "홍길동", "나이": 1000}
if (새로운 로직이면) {
... some logic1
... some logic2
some_result = other.system.method?jsondata=jsonstring
} else {
// 기존의 로직은 그대로 유지
... some old logic1
... some old logic2
some_result = other.system.method?jsondata=jsonstring // 테스트중..
//some_result = other.system.method?jsondata=https://www.othersystem2.com/v1/testprocess
}
이상한 점을 눈치챘는가?
(참고로 //로 시작하는 행은 주석으로 프로그래밍으로 간주되지 않는다.)
즉, URL을 통해서 JSON 데이터를 넘기는게 기존 로직이었는데
그게 빠지고 jsonstring을 변수로 받아서 넘기는 부분이
그대로 운영 상황으로 넘어간 것이다.
기존의 로직은 그대로 유지하고, 그 부분은 변경한게 전혀 없으니
문제 될 것이 없다고 편하게 생각해버린(?) 판단의 오류가 있었다.
이 경우에는 보통 스크립트 오류라고 하는
화면에는 보이지 않는 오류가 발생했을 가능성이 크다.
또한 이렇게 오래걸리는 처리는 화면에 로딩중.. 과 같은 이미지를 보여주기 마련인데
사람들이 흔히 생각할 수 있듯이 뭔가를 처리중이어서 그런 이미지가 보이고 있는 것이 아니라
단순히 반복되는 이미지인 경우가 대부분일 것이다.
웹 어플리케이션을 예로 들어보면
모래시계 이미지가 돌아간다거나
아니면 귀여운 캐릭터가 걸어간다거나 하는식일 것이다.
그러니, 사용자 입장에서 봤을때는 마치
처리는 하고 있는데 처리가 끝나지 않는 무한로딩처럼 보일 것이다.
그렇기 때문에 오늘 특정 시점부터 어떤 처리가 무한로딩이 걸리면서
이후 처리가 되지 않는다는 고객의 피드백을 받게 될 가능성이 크다.
자, 운영 상황이다. 이럴때는 어떤게 가장 빠른 해결책일까?
해당 로직을 수정한 사람입장에서는 문제를 빠르게 찾아서 해결하고 싶겠지만
안타깝게도 이런 경우에 가장 빠른 해결책은 "원복"이다.
즉, 변경했던 소스를 원상복구하는 것이다.
그리고 정상처리가 되는 것을 확인한 다음 차근차근 원인을 찾아보아야 한다.
그러면 기존에 정상적으로 처리되어왔던, 의심의 여지가 없었다고 생각했던 로직에
JSON 형태의 결과를 직접 넘기는 테스트 코드가 오염되었다는 것을 알게 될 것이다.
그렇기에 테스트가 중요한 것이다.
테스트는 새로 추가한 기능 뿐만이 아니라
기존에 되던 기능들도 정상 작동하는지 또한 확인이 필요하다.
(이걸 회귀 테스트라고도 한다.)
이를 굳이 교훈으로 정리해보자면
기존 로직을 논리적으로 나누어서 분리하고 새로운 로직을 추가할 경우에는
기존의 로직에 변경된 것은 없는지
변수를 통해서 처리하는 경우 로직의 본질적인 내용이 변경되지는 않는지
반드시 체크해야 한다는 것이다.
오늘은 여기까지..
이제 타는듯이 뜨거웠던 여름도 한풀 꺽이고
비로소 가을이 다가오는듯 하다. 모쪼록 모두의 건강을 바란다.
끝.
