2011. 3. 13. 00:56
     

요즘 회사일 때문에 고민이 많습니다. 아무래도 릴리즈를 앞두고 있기 때문에 더 그런 것 같기도 한데.... 사실 프로젝트를 진행하는 내내 제 고민은 한가지 였습니다.

"어떻게 해야 코드가 완전하다는 것을 보장할 수 있을까?"

이전 과제를 할 때 수정한 코드로 인해 사이드 이펙트(Side Effect)가 많이 생겨서 계속 문제가 되었습니다. 그래서 상당히 골머리를 썩였던지라, 새로 프로젝트를 시작할 때부터 이런 생각이 머리에서 떠나질 않았습니다. 그러던 중에 아는 후배에게 영감을 얻어 코드를 구현하는 단계부터 테스트 코드를 같이 구현하는 방법을 써봤는데, 이게 상당히 효과가 있어서 단위 기능 구현까지는 어느 정도 버그를 줄일 수 있었습니다.

그런데.... 이것도 잠시일 뿐... 코드가 통합되면서 다시 문제가 불거졌습니다. 완성된 단위 함수를 이용해서 작업을 수행하던 중에 문제가 생긴겁니다. ㅠㅠ 일을 분담하다보니 서로 못 보던 부분이 있었고, 미처 챙기지 못해서 당연히 있을 거라고 생각한 부분에 코드가 빠져있었습니다. 그래서 그 접점에 부랴부랴 코드를 챙겨넣고 나니 다시 고민이 시작되더군요.

"통합 과정에서 생긴 이런 문제는 어떻게 해결해야하나..."

한참을 고민한 끝에 도달한 결론은 통합 테스트 시나리오를 보강하는 것이었습니다. 통합 테스트를 할 때도 단순히 기본 동작을 위주로 테스트할 것이 아니라, 내가 고민하고 있는 Case가 정상적으로 동작하는지 확인하는 케이스를 만들어서 은근 슬쩍(?) 끼워 넣는 겁니다. 그러면 팀원들이 통합 테스트를 진행할 때 그 Case를 구현하지 않았으면 문제가 발생할테니까요.
(사실 테스트에서 Fail이 발생하는 것을 보는 것만큼 충격적인 것은 없지요... 쿨럭..;;;)

그래서 테스트 시나리오까지 보강하고 났더니 안심이 되긴 하는데 이번에는 이런 생각이 들더군요.

"과연 이 테스트 시나리오로 충분한 건가? 혹시 다른 Case는 없나?"
"테스트 시나리오가 충분하지 않다면... 혹시 다른 방법으로 코드가 완전하다는 것을 확인할 방법은 없을까?"

이 문제를 며칠째 고민 중인데 아직 여기에 대해서는 혜안을 얻지 못했습니다. 현재 머리 속에서 나온 답은 계속해서 다른 통합 테스트 시나리오를 구성하는 방법인데, 아무래도 새로운 기능을 계속 추가하고 앞으로 나아가야 하는 개발팀에 있기 때문에 이도 한계가 있습니다. 테스트만 주구장창 고민하게는 두지 않는 다는 것이죠. 물론 테스트 부서가 따로 있기 때문에 테스트를 제가 굳이 고민하지 않아도 되지만... 뭐랄까요... 테스트 시나리오가 기존 시스템을 기준으로 만들어져 있어서 새로 추가하느 기능에 대해서는 좀 둔하다랄까요. 그래서 불안한게 솔찍한 심정입니다. ㅠㅠ

아... 정말 어떻게해야 할까요? 컴퓨터가 알아서 코드를 분석하고 취약한 시나리오나 뭐 케이스를 만들어주면 참 좋을텐데... 그럼 제가 이런 고민을 하지 않아도 좋을텐데 말이죠. 혹시 이런 종류의 프로그램이 어디 없을까요? ^^;;;;;;





Android App

Posted by 호기심 많은 kkamagui(까마귀, 한승훈)

댓글을 달아 주세요

  1. 코카스 2011.03.13 01:17  댓글주소  수정/삭제  댓글쓰기

    주어진 요구사항을 만족하는지 검증하는 기술이 있지만 한계가 너무 큽니다.
    1. 주어진 요구사항이 구체적으로 있어야 하고(사실 요구사항을 제대로 파악하는 것 자체도 쉽지 않죠)
    2. 모든 경우를 주어진 시간 내에 확인하기 위해 프로그램이 매우 단순해야 하거나
    3-1. 오류가 나는 상황을 놓칠 수 있거나,
    3-2. 오류가 아닌데도 오류라고 걍 질러버리거나 하는 한계가 있습니다.
    우주선이나 비행기, 원자로 및 댐 제어 프로그램의 경우 위의 조건을 비교적 많이 만족하는 편이라 검증하는 기술을 도입하는 편입니다만 검증 기술을 성공적으로 도입했다는 것 자체와 경험담이 연구 논문이 될 정도로 아직은 일반적이라고 보기는 힘듭니다. coverity가 평이 괜찮은데 검출할 수 있는 오류 종류의 한계가 있고요. 무엇보다도 어떤 매직 툴이 있더라도 요구사항을 빼먹지 않고 정확하게 정리한다는 게 현실적으로 많이 어려워 보입니다.
    지금 대학원 연구로 검증, 테스트 자동 생성 쪽을 진행하고 있는데 이런 한계점들을 보고 있습니다. 열심히 연구하고는 있는데 워낙 어려운 문제라 그런지 업계에 바로바로 적용할만한 성과가 없네요.

    • Favicon of http://www.mint64os.pe.kr BlogIcon kkamagui 2011.03.13 12:09  댓글주소  수정/삭제

      코카스님 안녕하세요 ^^ 반갑습니다. ^^

      테스트 자동 생성 쪽을 연구하고 계신다니, 완전 멋지시군요. ㅠㅠ)-b

      정말 코드를 분석해서 예외 Case Test를 만들어주는 프로그램이 나온다면, 더할 나위없이 좋을 것 같습니다. ^^

      멋진 툴을 만드셔서 저 같은 프로그래머의 고민도 좀 줄여주시고, 야근도 좀 줄여주셨으면 좋겠어요 ㅠㅠ

  2. 쟁이 2011.03.13 07:25  댓글주소  수정/삭제  댓글쓰기

    - 모대기업에 다니는 지인이, 자신의 부서에서 개발에 사용하는 방법이 Test Driven Development라고 하더군요. 팀원 각자가 자신이 맡은 모듈의 기능을 정의하고, 그에 대한 시험항목을 만들고, 시험항목을 만족하도록 개발하는 방식이라더군요. 하지만 이 방법은 까마귀님이 언급한 첫번째 방법과 유사합니다.
    - 매우 기계적이고 제한적이지만 문제의 가능성들이라도 줄여보자는 방법으로 코드의 syntax 분석을 통해서 잠재적 오류(위험) 코드를 검출해 주는 S/W가 있는 것으로 압니다. 실제 효용성에 대해서는 의문이지만 너무나 많은 버그로 인해 고민하고 있다면 시도해 볼 가치가 있을지도 모릅니다. 제가 접해본 바로는 너무나 많은 위험요소를 지적하고, 관리자는 이를 수정하라고 요구하기 때문에 실무자로서는 무척이나 짜증이 나더군요.
    - 문제의 근본적인 원인은 인간의 직관/사고방식의 차이와 그 표현방식의 자유도에서 비롯된다고 생각합니다.
    한가지 예를 들어 볼까요?
    까마귀님이 이 고민에 대한 글을 포스팅 하면서 세운 제목은 "코드가 완전하다는 것을 보장할 수 있는 방법이 있을까요?"입니다. 전 제목만을 보고 좀 의아하더군요. 코드가 완전하다는 것을 알고 있는데 이를 증명할 방법을 찾는다는 것인가?라구요.
    우리 모두가 공통으로 배우고 수십년을 사용해 온 한국어를 사용하면서도 각 개인은 자신의 사고범위 안에서 옳다고 생각하는 한에는 언어를 자유롭게 구사합니다. 하지만 벌써 오류가 생겼죠? 내가 의도한 것과 다르게 받아들이는 사람이 생겼죠. 이것도 일종의 버그라고 볼 수 있을 텐데, 까마귀님이라면 이 버그를 어떻게 해결하시겠습니까?

    • Favicon of http://www.mint64os.pe.kr BlogIcon kkamagui 2011.03.13 12:18  댓글주소  수정/삭제

      안녕하세요, 쟁이님 ^^ 만나서 반갑습니다.

      제가 이런 제목을 썼던 이유는 무슨 방법을 써야 코드에 버그가 없고 완전하다는 것을 알 수 있을까 하는 의도였는데... 제목이 좀 오해를 불러 일으킬만 했던 것 같네요. ㅠㅠ

      쟁이님이 글의 마지막에 말씀하신 언어에 대한 내용은 "실제로 누군가가 내 말을 오해했을 때 어떻게 해야하나?"로 이해할 수 있을 것 같습니다. 보통 이런 경우는 상대에게 다른 방식으로 나의 의도를 전달하고 이것이 정상적으로 전달될 때까지 반복하는 방식으로 해결하지 않나요?

      음... 그러고보니 이런 방식은 테스트를 수행하고 그 결과가 원하는 방식으로 처리되어 나오는지를 확인하는 과정과 비슷하다고 볼 수 있을 것 같네요.

      그렇다는 말은 결국 테스트 케이스를 적절히 잘 만드는 방법 말고는 없다는 이야기일지도 모르겠군요. ㅠㅠ

  3. Favicon of https://zelon.tistory.com BlogIcon zelon 2011.03.13 14:16 신고  댓글주소  수정/삭제  댓글쓰기

    그래도 유닛 테스트를 활용한다니 다행이네. 우리 부서는 이런것도 잘 안해서 혼자하고 있다는 -_-;;;

    그리고 앞에 분도 적어놓으셨던데 coverage 를 체크하는 프로그램이 있는데, 얘가 if, else, function 등 실행 안 해본 코드가 몇 % 라는것을 알려주는데, 네가 만든 통합 시나리오 테스트 케이스를 돌릴 때의 coverage 를 체크해서, 모든 테스트 케이스를 돌렸을 때 code coverage 가 100% 가 된다면, 그나마 안심할 수 있지 않을까? cover 하지 않은 코드가 있다면 다시 거기에 대한 테스트 케이스를 만들고 해서 100%를 만들어 보는게 어떨까? 물론 100% 버그가 없다고 말은 못하지만 100% 의 코드가 다 실행되었고, 그 테스트 결과가 팀이 원하는 결과(테스트 케이스 pass)라면 안심할 수 있을것 같은데 ^^;;;

    static analysis program 이 코드를 정적으로 분석해서 위험한 코드를 알려주는 것도 꽤 괜찮기는 한듯....

    회사에서 재미있게 일하는 거 같아 부럽네 :)

    • Favicon of http://www.mint64os.pe.kr BlogIcon kkamagui 2011.03.13 21:38  댓글주소  수정/삭제

      앗~ 진욱이횽 안녕하세요 ;)

      저도 뭐 거창하게 하는 건 아니에요 ㅠㅠ 그냥 소소하게 펑션 단위로 테스트 코드를 넣어서 테스트하는 정도... 그리고 전체 테스트 시나리오 살짝 만들어서 돌리는 정도에요. ㅠㅠ

      커버리지 툴도 한번 써보긴했는데 사용하면 현재 코드에서 빠진 시나리오를 찾을 수는 있지만... 이게 새로운 시나리오를 만들게 해주지는 않더라구요. ㅠㅠ

      결국 코드나 설계 문서를 보면서 코너 케이스를 유발하는 시나리오를 만들고 이걸 다시 테스트 코드로 옮기는 작업을 하고 있어요. 이 테스트 시나리오를 통과 못하면 코너 케이스에 대한 대비가 안되어있다고 생각할 수 있도록...

      그런데 이것도 하다보니 의문이 들더라구요. "과연 이게 정말 코너 케이스인가?" "혹시 예측하지 못한 다른 상황이 있는 것은 아닌가?" 하면서 말이죠. ㅠㅠ

      아아... 진짜 이 바닥도 쉽지는 않는 것 같아요. ;)

      ps 1) 회사일은 전혀~ 재미있지 않아요 ㅠㅠ
      ps 2) 나중에 대구 내려가면 연락 드릴테니 밥 한끼 먹어요 횽 ;)
      ps 3) 옛날에 진욱이 횽이 우분투 쓰던 모습이 생각나서 노트북에 쿠분투를 한번 깔아봤는데요, 이제 거의 윈도우를 따라 잡았더군요. 완전 멋지네요 @0@)-b

    • 장영일 2011.03.22 09:36  댓글주소  수정/삭제

      앗. 밥 먹을 저도 불러줘요 ㅎㅎ

    • 김상규 2011.03.25 22:07  댓글주소  수정/삭제

      ㅎㅎ 영일이 형은 아주 오랫만에 뵙는듯 한데요 ㅋㅋ
      얼굴 까먹겠네용 ㅜㅜ

    • Favicon of http://www.mint64os.pe.kr BlogIcon kkamagui 2011.03.26 18:42  댓글주소  수정/삭제

      영일 : 당근이지~ 꼭 같이 한번 먹자고 @0@)-b

      상규 : 오오~ 니도 영일이 알제? ㅋㅋ 난제 니도 기회가됨ㅕ같이 밥 한번 먹자고 ;)

    • 장영일 2011.04.07 18:33  댓글주소  수정/삭제

      상규 하이 ^^ 진짜 올만이다~ 잘 지내고 있지?!!
      승훈이형 동문회 해야겠네요 ㅋㅋㅋ

    • Favicon of http://www.mint64os.pe.kr BlogIcon kkamagui 2011.04.16 14:58  댓글주소  수정/삭제

      엉~ 그러게 동문회 한번 해야겠네 ㅋㅋㅋ

      한번 추진해도고 ;)

  4. issacjin 2011.03.14 12:39  댓글주소  수정/삭제  댓글쓰기

    저도 형처럼 하고 있는데....
    그래도 신기하면서도 다행인것은,
    특정 부분의 테스트를 빠트리면, 거기서는 꼭 버그가 나오더라는..ㅋ
    완벽! 이런거 자체가 어느 분야든 범접하기 힘든거잖아요.하하.

    • Favicon of http://www.mint64os.pe.kr BlogIcon kkamagui 2011.03.14 22:32  댓글주소  수정/삭제

      오오~ 나의 시도에 불을 당긴 분이구나 ㅋㅋ

      엉~ 니말이 맞는거 같다 ㅋㅋ 덕분에 단위 모듈에 대한 버그는 많이 줄었는데... 천지 빼먹은 코너 케이스에 대한 부분은 아직까지 이렇다 할 성과가 없네 ^^;;;;

      이것도 괜찮은 아이디어 있으면 좀 알려줘 ㅋㅋㅋ

  5. Favicon of http://charsyam.pe.kr BlogIcon CharSyam 2011.03.31 21:11  댓글주소  수정/삭제  댓글쓰기

    코드는 완전할 수 있으나, 그 코드가 요구하는 요구사항은 완전한가는 별개의 문제라고 생각합니다.
    정적 분석, 유닛테스트, 다 고려해서 작성하더라도, 그 코드 자체가 정말 요구 사항에 만족하는지 검증은
    하기 힘든것 같습니다.

    • Favicon of http://www.mint64os.pe.kr BlogIcon kkamagui 2011.04.02 15:12  댓글주소  수정/삭제

      아아... 그렇군요. ㅠㅠ

      저희쪽은 요구사항 자체도 아주 두리뭉실하게 되어 있어서... 더 힘든 것 같습니다.

      결국... 최대한 고민해서 뭘 더 찾아내는 수 밖에는 없겠군요. ㅠㅠ