본문 바로가기

카테고리 없음

에러 잡는 마음가짐

> 들어가기전 잡담

어제는 친한 친구와 약속이 있었고, 오늘도 친구와 약속이 있었는데 모두 취소가 되었습니다. 허탈한 마음을 뒤로하고 투표를 하고 서점에 갔다가 집에 왔습니다.

이쯤 되면 시간도 남고 제가 한방 포스팅이라고 부르는 블로깅을 할 수도 있었는데 블로깅도 리듬을 타는 것 같습니다. 이제 회사일 바빠져서 블로깅 천천히 하겠다고 쓴 글이 무안하게 얼마전에는 글을 많이 쓴다 싶더니만 이번주는 글쓰기에 손이 가질 않았습니다.

머릿속에 떠오르는 글감중 최근 경험담이 담긴 간단한 글을 쓰면서 다시 닻을 올리고 항해(=블로깅)를 해야겠습니다.


> 본문


에러는 잡힌다. 짧은 경력이지만 내가 아는 에러는 완전히 죽진 않더라도, 잡히지 않은 적은 없었다. 그러나 에러를 잡는 과정은 잃어버린 지갑을 찾는 것처럼 언제나 나(=개발자)를 속 태운다.

A모듈을 개발했다. A모듈은 시간이란 자원이 넉넉하게 주어져서 나는 침착하게 개발 할 수 있었다. 내가 생각할 수 있는 발생가능한 모든 에러 발생 경우의 수를 테스트 자동화 클래스(=JUnit 프레임워크)로 만들어서 테스트를 했더니, 지금까지 문제가 발생하지 않았다. 다행히 A모듈은 튼튼하게 키우기 사작했다.

B모듈을 개발했다. B모듈은 다른 시스템 자원하고 같이 돌아가기 때문에(=네트워크 모듈) 발생 가능한 모든 경우의 수를 생각할 수 있더라도, 그 경우의 수에 대하여 테스트 자동화 하기는 어려웠다. 그래서 ‘이러면 되겠지~’ 하고 개발한 부분이 있었는데 최근에 다양한 경우에서 에러가 뻥뻥~ 터져나왔다.

회사 선배와 같이 붙어서 에러를 해결해 나갔다. 에러가 거의 해결되는 과정에서 회사 선배가 이렇게 말씀하셨다.

산골 선배 : “그럴 가능성은 거의 없겠지만..B1에러 상황도 혹시 있을까..아니 없을꺼야..산골아 이정도 잡았으면 되겠지?”

산골 대리 : (흠..B1에러 상황도 혹시 터질수도 있겠지만..아마도 그럴 일은 없을것 같다..) “흠흠..넵..처리 것 같아요.”

산골 선배 : 산골아 그럼 다른 문제는 혹시 없을까? 이렇게 하고 마무리 할까?

산골 대리 : (흠흠..그럴 가능성은 희박하지만..B2에러 상황도 있을수도 있는데..아니야..B2에러가 터질리는 없겠지..) “네 이정도 다듬었으면 된 것 같은데요..인자..마무리 하고 퇴근하시죠. 헤헤~ ^ ^”


그런데 얼마 후 우리의 대화를 무시하고 너무도 당당하게 B1, B2 에러가 뻥뻥~ 터졌다. 다시 에러를 잡기 시작했다.

이렇게 안 좋은 경우로 에러를 잡자 이번에는 발생 가능한 모든 에러 발생 경우의 수를 엑셀 파일로 정리하여 하나하나 다시 테스트 하기로 했다. 엑셀 파일로 정리하여 하나하나 수작업으로 테스트 했더니 예상 못했던 한두가지 문제가 더 발생됐고 이 문제들을 해결하면서 일단 B모듈 처리는 마무리 한 상태이다.

이번 경험들은 사실은 항상 반복하여 경험하는 것들이라서 다시 한번 정리가 필요하다는 생각을 했다. 귀차니즘을 이겨내고 튼튼한 프로그램 개발을 위해 이 글로 마음을 가다듬는다.


> 에러 잡는 마음가짐 (내 마음대로 정리한..)

1. 개발하다가 마음속으로 ‘그럴리 없겠지만 혹시 A문제가 터지지 않을까..’ 라는 신호는 미리 에러를 감지해주는 고마운 신호다.

2. ‘이 정도면 되겠지~’를 감으로 증명하지 말고 증거자료로 증명하자.

3. 가장 좋은 에러 검증 증거자료는 JUnit 프레임워크로 테스트 자동화 하는 것이다.

4. 테스트 자동화가 불가능하다면 엑셀 파일등의 문서로 가능한 모든 에러 발생 경우의 수를 정리하여 테스트 하자.

5. 에러는 잡힌다. 에러 잡는 초조한 순간에는 이 생각을 하며 마음을 차분하게 가다듬자.


덧1) 혹시 위의 에러 잡는 마음가짐 말고 또 없을까요? 고수 개발자님들의 피드백 부탁드립니다. ^ ^