분명 개발수정했다는데 같은 오류 왜 또 나는거죠??

주니어 기획자의 이해를 돕기위한 문과적 설명

*본 시리즈는 우리 주니어들에게 제가 설명하는 방식들을 정리한 내용으로, 기획자가 딱 일할 수 있을 정도로만 문과적 으로 설명합니다.

이유는 2가지 중 하나에요,
테스트한 소스는 이미 다른 것이 수정됐는데
그걸 모르고 다시 옛날 버전에 수정해서
올리다보니까 그 중간에 수정된게 사라졌거나,,
진짜 최악은 수정된 소스로 테스트안해보고
그냥 올려놓은거거나죠,

테스트 기간이 길어지면 자꾸 죽었던 오류가 되살아나는 기현상이 벌어진다. 경험이 부족한 막내 기획자는 개발에 이 오류 또 발생했다고 울상이 되거나, 까칠한 대리는 개발에 이거 왜 또 발생하냐며 화를 낸다.

그런데 이 문제가 발생하는 이유는 배포 순서에 있다. 동시다발적으로 여러 개발자가 오류사항을 배정받아 이곳저곳 고치다보면 역시나 소스를 합쳐서 배포해야하는 문제가 생긴다. 역시나 '소스머지'이야기다,

그런데 지난번 글에서 이야기했던 소스머지가 프로젝트간 소스머지라는 큰 이야기였다면 이번엔 참으로 짜친다.

아래. 지난번 프로젝트간 소스머지관련 글.

https://brunch.co.kr/@windydog/359

왜 같은 페이지를 동시에 수정하면 오류가 날까?

테스트 서버에 배포가 된 후 발견된 오류 1번과 2번이 있다. 개발자 A는 1번을 배정받고 개발자 B는 2번을 배정받았다. 1번은 어려운 오류라서 수정에 몇일이 걸리고 2번오류는 쉬워서 금방 오류가 수정되고 테스트 서버에 반영되었다. 문제는 개발자 A가 오류 1번을 드디어 수정했을 때 발생한다. 2번 오류 수정본을 찾아서 합치는 과정을 놓치고 개발자 A가 수정한 것만 신나서 올려버리면,,2번 오류는 쉬운 오류인데도 다시 발생해버린다.

이 문제는 개발 내 관리의 문제이면서 동시에 사람이기에 있을 수 있는 문제다. 아직까지 소스간 버전차이를 분석해주는 툴이 있어도 결국 수정 전과 수정 후의 어느 소스가 멀쩡한지는 사람이 판단해줘야 하는 역할이니까.

그니까 기획자들이여, 재발한 2번 오류에 마음 속에 솟아나는 짜증은 어쩔수 없겠지만, 울상이 되거나 윽박지를 필요는 없다. 그냥 테스트하면서 자주 오류가 재발하고 소스가 다시 원복되는 것 같으면 지금 테스트서버 배포시 소스관리나 머지 실태를 물어보고 관리자급 개발담당자에게 이 부분에 대해 관리해달라고 대안을 달라고 이야기하면 된다. 우리가 화낼수록 나빠지는 건 우리 성격뿐이다.

하지만 두번째 케이스는 문제가 있다.

대리때 모바일 서비스 전면 리뉴얼 플젝을 할 때였다. 테스트기간에 한가지 부분에서 오류가 계속 났다. 특정케이스가 주문이 되지 않았다.

메시지가 왔다.

"오류 수정 완료했습니다. 확인해보세요"

"네 알겠습니다. (다시 해본 뒤) 아직도 안돼는데요????"

"아 그래요? 그럴 리가 없는데,..

(20분도 안지나고 잠시뒤) 다시 해보세요."

"벌써 수정하셨다고요? 알겠어요.

(다시 해본 뒤) 여전히 안되는데요??"

"네? 왜 안돼지???? "

그 때 머리 속에 든 생각은 하나였다. 의심되는 것이 있어서 얼른 개발자자리로 뛰어가서 테스트폰을 직접 보여주고 이 사람이 어떻게 하는지 지켜봤다.

오류를 보고 고개를 갸웃 거리더니 검은 바탕에 흰글씨인 코딩 화면을 꺼내서 몇 줄 슥슥 고치더니 따다닥하고 엔터를 친다. 1%가 100%가 되더니 다 됐단다. 확인해보란다. 활짝 웃는 그를 보고 한대 치고 싶었다.

이 개발자, 자기가 수정한 소스로 테스트를 안해보고 소스만 보고 수정하고 있었다. 완벽한 자기 과신형 개발자!!

"테스틀 안하고 전달하시면 어떡해요? 기획자가 테스트로봇이에요? 아니 기본적인건 확인해보고 완료 치셔야죠."

나는 그 뒤로 그 개발자 뒤에 의자를 깔고 앉았다. 오류수정 됐다고 보내놓은 건들을 한건 한건 다 테스트 시키고 개발수정하고 재테스트하고 보내는지 소위 병풍을 쳤다. 그리고 그날 새벽 2시까지 같이 작업하고 택시를 타고 돌아갔다.

아주 운이 나쁘게 별로인 개발자를 만난 사례다.

2번째 케이스의 문제는 관리 비효율에 있다. 오류가 진짜로 해소됐는지 체크하는 과정도 디버깅에 해당한다, 오류를 발견했고 수정했으면 변경된 프로그램이 문제 없는지 체크해야한다. 디버깅 되지 않은 수정 개발소스는 오류처리건수는 엄청 빠르게 늘어나도 사실 오류가 해소되지 않거나 다른 사이드 이펙트 오류로 상황이 더 나빠지기도 한다.

네이버 사전에도 프로그래머가 작성된 것이 정확한가 조사하는 작업이라고 되어 있다.

이럴 때는 개발자의 성향이 문제인 거라 빨리 처리하려면 관리를 빡세게 들어가야한다. 수정해도 수정이 또 제대로 안되는 것은 자연스럽지만 테스트도 안하고 완료했다고 하는 개발자는 최악이다.

오류가 우후죽순 재발해서 나타나는 프로젝트를 두더지 게임하듯이 해결해내고 나면 어쨌든 끝은 온다. 그러려면 초기 테스트양을 한번에 쭈욱 올라가는 것이 중요하다. 테스트는 오늘도 지겹겠지만, 재발하는 오류에 놀라고 당황해하진 말자. 결국 모든 일은 사람이 하는 일이다. 오류 나는 것은 정상이다. 좋은 협업자들은 대처하는 방식에 차이가 있을 뿐이다.