BLOG main image
분류 전체보기 (466)
Yuno (232)
Travel (130)
Culture (46)
Other (11)
Programming (17)
Picture (22)

[필리핀,마닐라] 그린벨트 (Gr..
월풍도원(月風道院) - Delight..
Tamiflu and parvo.
Tamiflu and side effects.
[미국,라스베가스] 라스베가스..
월풍도원(月風道院) - Delight..
[미국,라스베가스,그랜드캐년]..
월풍도원(月風道院) - Delight..
[태국,방콕]태국 숙소,방콕 -..
월풍도원(月風道院) - Delight..
«   2012/02   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29      
1,476,564 Visitors up to today!
Today 148 hit, Yesterday 253 hit

'버그'에 해당되는 글 3건
[Yuno.org, 2010/03/20 13:17, Programming/Development Story]


몇년 전에 읽었던 "조엘 온 소프트웨어"라는 책이 있습니다. 혹시 아직 안보신 개발자 또는 개발자와 함께 일하시는 분들은 한번 읽어 보시기를 추천합니다 ; 이 책의 22장에 보면 " 테스터를 두지 않는 (잘못된) 다섯가지 이유 " 라는 부분이 있습니다. 

다섯가지 이유를 저자는  1)  버그는 프로그래머가 게을러서 생기니까요.  2) 우리 소프트웨어는 웹에 올려놓아서 버그는 금방 고쳐질 수 있으니까요. 3) 고객이 소프트웨어를 테스트해줄 테니까요. 4) 우수한 테스터는 테스터로 일하려고 하지 않거든요. 5) 테스터를 고용할 돈이 없으니까요. 로 들고 있습니다.

이러한 이유를 들어서 테스터를 두지 않는 다면 멍청한 짓이다! 라고 저자는 이야기 하고 있습니다. 저 역시 이 부분을 상당 부분 동감합니다. 제가 지금까지 보고, 겪은 거의 모든 회사는 출시 전날까지 작업을 합니다. 심지어는 패키징 하기 직전까지 코드 작업을 하는 경우가 있습니다. 그나마 그 작업이 버그 수정이라면 다행이지만, 기능 추가와 같은 신규 코드 작업도 있습니다. 그리고는 그냥 업로드 해버립니다. 가끔은 그럴때, 그런데 이거 테스트 없이 그냥 풀어도되나요? 라고 물었을때 거의 모든 사람의 경우 (심지어 나 역시) "테스트 서버(베타 서버)에 올릴 것이니까 괜찮아, 버그 테스트는 유저들이 해줄테고 리포트 들어온거 수정해서 다시 패치 하면 되지" 라는 말을 합니다. (반성중)

바른 자세일까요? 네. 마치 이건 도덕 시험 같습니다. 누구나 저런 자세가 옳다고는 생각하지 않습니다만 "현실"을 생각하면 어쩔 수 없다는 거죠. 네. 저도 현실을 생각해서 저렇게 행동하고 답 했습니다. 그런데, 왜 현실을 고려 할 수 밖에 없는 것일까요? "테스터를 고용할 돈이 없으니까요" 라고 말합니다. 와우! 다섯가지 이유를 하나씩 정말 다 따라갑니다! 

버그가 없이 프로그램을 작성 할 수 있는 프로그래머는 세상에 없습니다. 버그는 프로그래머가 미처 생각하지 못하고 지나친 부분에서 발생합니다. 버그는 프로그램에게는 필연적인 존재입니다. 어떻게 해서든지 출시전에 그 문제점을 찾아서 프로그래머에게 전달을 해야 합니다.

기업에게 있어서 "이미지"라는 것은 매우 중요한 요소입니다. 유저(고객)에게 각인 되는 이미지 중에서 제일 강한 녀석은 바로 첫 인상이죠. 사람과 마찬가지 이지만 말이죠. 어쨋든, 고객이 다운로드 받은 프로그램을 실행 했는데 어처구니 없는 버그가 나온다? ... 그 엄청난 이미지 훼손을 회복하는데 걸리는 시간은 예상을 뛰어 넘습니다. 또한 만약에 그것이 이미 시장에서 어느 정도의 점유율을 차지 하고 있는 제품이 아닌 신규로 릴리즈 된 녀석이라면 시장의 기대 값은 정말 순식간에 0점까지 치닫게 됩니다. 고생은 고생대로 하고, 욕은 욕대로 먹고.. 한 국가에만 릴리즈 되는 것이라면 그나마 이정도 선이지만 해외 파트너사로 릴리즈 했을때는 ... 이거 참 난감해집니다.

이러한 문제는 테스터 조직을 갖추게 된다면 상당 부분 해결이 되지 않을까요?

테스터는 꼭 전문가여야 할 필요는 없습니다. 특정 고객층을 목표로 배포 되는 프로그램이 아닌 대부분의 프로그램은 불특정 다수에게 배포 되어 사용이 되어집니다. 테스터 조직을 전문적으로 관리해줄 관리자와 일반 사용자 처럼 해당 프로그램을 사용해줄 테스터만 있어도 충분한 효과를 낼 수 있습니다! 출시가 잦아서 잦은 테스트가 필요한 제품이 아니라면, QA 조직의 대부분을 임시직 (계약직을 비롯한 파트타임 아르바이트)으로도 충분합니다. 오히려 불특정 다수에게 배포 되는 프로그램은 전문적 지식을 갖추지 않은 일반인 파트타임 아르바이트가 더 효과적일 수도 있습니다. 아니면 해당 소프트웨어를 사용하는 사람들 중에 일부를 파트 타임 아르바이트로 고용해서 테스트를 진행 하게 할 수도 있습니다!

버그가 발견 되면 프로그래머는 슬퍼 할 수 밖에 없습니다. 내 자식 같은 코드에서 버그가 .... 가 아닌 한 밤중에 끌려 나올수도 있기 때문입니다!!! 한 밤중에 긴급 점검을 위해서 택시를 타야 하는 경우, 얼마나 가슴이 아픈지 모릅니다.

테스트 조직에 모든걸 다 해결해 주리라고는 믿지 않습니다. 다만, 테스트 조직의 QA 단계를 지나치면서 고객에게 가는 버그의 수를 줄이고, 버그에서 깍아 먹는 회사 이미지를 보호하고, 한 밤중에 긴급 점검으로 끌려 나오는 빈도 수를 줄이기는 해주리라고는 믿습니다.

아, 그렇다고 프로그래머에게 테스트를 맡기면 안됩니다. 프로그래머는 테스트를 싫어합니다. 또한 테스트를 진행해도 일반 테스터 보다 버그 발견률이 낮을 수도 있습니다. 그것은 아이러니 하게도 프로그래머는 정상적인 방법으로만 사용을 하는 경향이 크기 때문입니다. 하지만, 애시당초 정상적인 프로세스 상에서 버그가 발견 되서 출시 되는 경우는 적습니다. 일반 사용자는 정상적은 방법으로만 사용하지 않습니다. =_= 

아 뭐 ..

그냥 테스트 전문 조직이 있었으면 좋겠다는 푸념이었습니다. 버그 없는 게임을 만들어서 유저에게 욕을 그만 먹었으면 좋겠습니다. ㄷㄷ

이제는 청춘불패나 보러 가야겠습니다. ...;

p.s 테스트 조직에게 출시 거부권이 있다면 더 좋겠지만, 현실적으로는 힘들겠군요. 어떤 회사도 출시를 늦출리는 없을테니 프로그래머를 더 쪼아서 ... ... 저도 프로그래머인지라 차마 더 쪼임 당할 수 있는 발언은 차마 할 수가 없군요 ㅋㅋ
저작자 표시 비영리 변경 금지


--
레이니아 | 2010/03/20 18:21 | PERMALINK | EDIT/DEL | REPLY
(테스터를 여럿 해본 입장에서) 잘 읽고 갑니다^^
이상하게 꼭 테스터가 버그보고를 한 이후에 프로그래머분들이 버그재현하실 때에는 꼭 정상작동하곤 해서 마찰이 잦곤 했는데...(...)

알 수 없는 특정한 조건에서 버그가 튀어나올때 프로그래머분들의 얼굴에 생기는 고뇌는 지금 생각해도 가슴이 아프네요:(

다시한번 글 잘 읽고 갑니다^^
YDK | 2010/03/20 21:03 | PERMALINK | EDIT/DEL | REPLY
학교를다니는 학생입니다. 늘 제가 만든코드를 테스트하는과정에서는 버그가 없는데 교수님께 제출하는날부터 거의 매일 버그의 존재를 이메일로 받습니다. 실무에서도 똑같네요, 뼈속깊은곳까지 습관을 들여놔여 겠습니다. 좋은글 잘 보고 갑니다.^^
sziim | 2010/03/22 13:05 | PERMALINK | EDIT/DEL | REPLY
좋은글 잘 보았습니다.
작년에 인턴으로 소프트웨어 기업에서 소프트웨어 테스트 엔지니어로 일할 기회가 있었는데
그곳은 출시 전에 QA승인 없이 출시가 불가능한 프로세스를 갖고 있었습니다.
그때는 그러한 프로세스... 당연히 학교에서 배우던대로 진행되는구나 싶었는데

어느덧 학교를 졸업하고 취직을 하니 실제로 저 프로세스를 운용하는 회사는 없는거 같더군요.
생각해보니 제가 일했던 그 곳도 단기간 수정 불가능한 이슈는 1차 업데이트로 모두 돌려버리고 출시일에 맞춰 출시했지만요 ㅋ
Name
Password
Homepage
Secret
[Yuno.org, 2006/09/30 11:35, Programming/Development Story]

완료 된지 시간이 조금은 지난 프로젝트. 게임으로 따지면 서비스가 시작된지 조금 된 게임들. 프로그램으로 따지면 최초 개발 이후 고객에 따라서 커스터마이징을 하고 있는 과정 정도에 있는 경우에 해당한다.

어떤 프로젝트든지 완벽한 문서와 모든 코드를 숙지 할 수 있는 교육 과정이 있다면야 문제 없지만, 현실적으로는 그런 일은 드물다. 아니 있을 수 없다고 해야 할런지..

완성된 프로젝트를 이어 받아서 커스터마이징 및 유지 보수, 추가 작업을 하다 보면 가끔은 이런 기능이 있으면 좋을 텐데 하고 관련 자료를 찾아서 적용 준비를 하다보면 평소에는 보이지 않던 파일명과 클래스명이 보이곤 한다. 혹시.. 라는 마음에 찾아 보면 역시나 oTL.. 이미 구현이 되어 있지만, 코드 깊은 곳에 묻혀 있어 알 수 없었다던가 특수한 경우에만 작동하게 되어 있다던지 하는 일이 있다.

나름 난감하다. 그 기간동안 이런게 있다는 사실을 몰랐다니! 아쉬워 해봐야 소용 없다.. 하지만 다른 숨겨진 기능을 찾기에는 유지 보수에도 시간이 부족하다. 결국 프로젝트를 구성하고 있는 모든 구성요소를 모른채 계속 일을 이어 갈 수 밖에 없다.

oTL

이런 일은 가끔 예상치 못한 문제를 낳기도 한다.

예를 들어서 게임에서는 유저의 시야권에 다른 케릭터가 접근하게 되면 해당 사실을 서버에게 알려준다. 그런데 완성되고 나서 몇년이 지난후에 새 개발팀이 해당 프로젝트를 맡아서 진행하다가 이미 시야에 들어온 유저의 데이터의 갱신이 필요한 일이 생겼다.

그래서 작업 방법을 고민하다가 시야에 유저가 들어왔을때 해당 사실을 통보해주는 모듈을 사용하여, 같은 UserID를 가진 User Object가 다시 전송되면 업데이트 되는 방식으로 구현. 서비스를 한동안 진행하던 중에 우연히 코드중에 유저의 정보만을 업데이트 시켜주는 현재는 자주 사용되지 않는 패킷 모듈이 있었음을 발견 한다.

그런데 문제는 서버에서는 유저 데이터를 업데이트 시켜줄때 사용하는 정보와 유저가 시야에 들어왔을때 사용 되는 데이터가 동일할 것으로 예상. 공통적으로 유저 정보를 보내는 모듈을 사용하고 있었다.

어느 한쪽이 패킷 규약이 변경되면 다른 한쪽 역시 같은 모듈을 사용하므로 같이 변경 되는 그러한 방식.
그런데 서버 개발자도, 클라이언트 개발자도 이것을 모르고 있었다는거.. 결국 패킷은 데이터가 밀리는 현상이 발생. 특정 유저의 경우에는 예상치 못한 값에 의한 클라이언트 크래쉬가 일어나게 되었다. ;

난감..

한참동안을 원인을 못찾다가 이런걸 발견 하게 되면 정말 가슴이 아프다. 왜 조금 더 꼼꼼하게 살펴 보지 못했을까.. 하는 아쉬움은 이미 늦어 버렸으니까..



--
Name
Password
Homepage
Secret
[Yuno.org, 2006/09/30 03:14, Programming/Code Story]

많은 프로그래머들이 겪고 있는 신비로움일까. 아니면 무지에서 나오는 결과일까.

내가 속한 팀에서는 대부분 사내 테스트이 경우에는 디버그 버젼의 클라이언트를 이용해서 사용한다. 더 많은 클라이언트, 케릭터 정보, 많은 로그들을 얻을 수 있다는 장점이 릴리즈 버젼의 클라이언트 보다 더 크게 작용하기 때문이다.

그런데 여기서 가끔 문제가 생긴다. 릴리즈 버젼의 바이너리와 달리 디버그 버젼은 탱크와도 같아서 정말 튼튼하다. 프로그래머의 가벼운 실수 쯤은 가뿐히 넘어가 버린다.

많은 프로그래머가 실수하는 배열의 인덱스 오류로 인한 오버 플로우 정도는 디버그 컴파일시에 생기는 패딩 효과에 의해서 무마 되어 버린다.

그런데 오늘 정말 거지 같은 일이 있었다.

Windows API를 사용하는데 같은 클래스의 같은 메소드에서 Windows API의 결과가 릴리즈와 디버그가 달랐다. 한시간 넘게 고민하고 고쳐보고 구글질을 해봤지만 결국 원인 규명에는 실패. 참 난감하다.

이렇게 한참을 한 가지 문제를 해결 못해서 끙끙 거리다 보면, 어떤 책의 구절을 찾기 위해서 책장에서 책을 하나 하나 꺼내서 뒤지다가 없으면 책을 내동댕이 쳐서 엉망이 되어버린 방 처럼 머리속이 엉망이 된다.

그럴때는 지우개라도 사용해서 머리를 깨끗하게 비우고 다시 시작하고 싶다.

그리고, 많은 경우가 잠시 바람을 쐬고 처음 부터 차근 차근 하면 해결 되기도 한다. -_-

하지만. 오늘은 실패했다. ㄴㅁ..



--
Remisa | 2006/10/13 02:20 | PERMALINK | EDIT/DEL | REPLY
그래서 저는 디버그도 릴리즈 모드로 한답니다. ^^;;
아무 정보도 없이 테스트 코드만 한참 짜다보면 실력도 늘거든요.. ㅁㄴ알먼아ㅣ;러ㅏㅣ;
Name
Password
Homepage
Secret
*1