소프트웨어 이야기

두 클라이언트 분과 함께 진행중인 프로젝트에 대해서 이야기 하는 자리였습니다.
클라이언트이신 N 팀장님이 저를 대신해서,
처음으로 프로젝트를 함께 하시는 G팀장님께 설명을 드립니다.

"제가 이 팀하고 일을 몇 번 해보니까, 소프트웨어라는 것이 그래요.
기간이 10이라고 하면 8이나 9가 될 때까지는 아무 것도 안보이다가,
갑자기 탁! 하고 나타나서 잘 도는 식이죠.
그러니까, 지금 G팀장님이 조급해도 믿고 기다려 보세요. 잘~ 될 겁니다."

클라이언트 입장에서 믿고 기다린다는 것이 얼마나 큰 용기가 필요한 것이지 알기에,
저희 팀을 믿고 기다려 주시는 두 팀장님께 진심으로 감사를 드리는 자리였습니다.



언제 자세하게 이야기 할 기회가 있겠지만,
이런 식으로 결과물이 나오는 이유는 ' Emulation과 Component 방식' 때문입니다.
Embedded 시스템 상에서 소프트웨어를 디버깅 하는 것은 매우 까다로운 일입니다.
그런 이유로 Host 시스템인 Solaris, Linux, Windows등의 Emulation을 통해 대부분의
버그를 수정하게 됩니다. 90% 이상의 버그는 이 Emulation상에서 처리하게 되죠.
결국 Emulation상에서 모든 기능을 확인한 후에야 Hardware와 Integration하게 됩니다.
클라이언트 입장에서 보게 되면,
Emulation시험이 완료되기 까지는 아무런 Output도 나오지 않게 되는 거죠.

두 번째 이유는 Component방식의 개발 스타일 때문입니다.
최종 Software의 90% 정도는 Component이고 나머지 10% 정도가 Application code로
이루어 집니다. Component라는 것은 레고 블록과 같이 정형화 된 Library를 의미합니다.
(Source가 아닌)
프로젝트는 달라도 Component는 반복적으로 재사용되는 방식이죠.
재사용이라는 것은 장점이지만,
Component의 버그가 여러 프로젝트에 영향을 미치게 되는 위험성은 단점이 됩니다.
그러다 보니, Component에 대한 시험에 많은 시간을 보내게 됩니다.
Upgrade되면서 자연스럽게 여러 버전이 사용되기 때문에
API Backward compatibility도 기본적인 시험에 포함됩니다.
이러다 보니, 최종 Integration까지는 바쁘게 일해도
클라이언트 입장에서 보면, Output이 없어 보이는 것이 당연합니다.



기다림의 시간이란 클라이언트도 참 힘든 시기이지만,
프로젝트를 수행하는 개발자에게도 힘든 시간 입니다.
Integration해보고 싶은 유혹을 이겨내야 하니까요.



몇 년 전이었습니다.
프로젝트의 종료가 얼마 남지 않은 시기였는데,
Mutual Exclusion 문제가 있다는 것을 알게 되었습니다.
(Task나 Thread간에 동일한 Memory Space/Global을 수정하게 되는 문제입니다)
이 문제를 해결하기 위한 방법에는 두 가지 선택이 있었는데,
하나는 Application에서 처리하는 방법이었고,
다른 하나는 공통 Component의 개발이었습니다.
첫 번째는 쉬운 방법이었지만 이 프로젝트에서만 사용할 수 있는 방법이고,
두 번째는 범용적으로 사용할 수 있지만, 어려운 방법이었죠.

시간이 부족하다는 것을 알고는 있었지만, 두 번째를 선택했습니다.
3주라는 시간으로 Draft 1이 힘겹게 나왔습니다.
Release Quality까지는 그 두 배의 시간이 필요한 상황이었죠.
프로젝트는 더 기다릴 수 없었고, Draft 1 상태에서 Integration을 했습니다.

다행히도 문제 없이 잘 돌았습니다.
'그렇게 문제가 해결 되는 구나~' 라고 생각을 했는데
가혹한 시험을 하기 시작하면서, 추가적인 문제가 발생하기 시작했습니다.
Overloading이나 Long-term Aging 시험을 하면서 오류가 발견되었습니다.
오류를 수정하고, 또 오랜 기간 동안 시험을 하고,
또 오류를 수정하고, 추가 적인 시험을 하는 것이 계속되었습니다.
나중에 계산해보니 이렇게 보낸 기간이 6개월 이상이 되었죠.
우습게도 그 기간이 지나도록 Release Quality에는 도달하지 못하였고,
많은 버그의 수정 이후에도 Component는 Draft로 남게 되었습니다.

이 실수를 하면서, '기다림' 라는 것의 중요성을 깨닫게 되었고,
낮은 수준의 시험을 통과하고 Integration하는 것이 어떤 대가를 요구하는지 배우게 되었죠.
3주의 시간을 더 사용하고 Integration을 했더라면 아마도 결과는 바뀌었을 겁니다.
여유로움을 가지고 차후에 진행을 했더라면 아마도 결과는 바뀌었을 겁니다.
아직도 클라이언트께 이런 내용을 쉽고 명확하게 전달할 재주는 없지만,
'저희 팀을 믿고 기다려 주십사' 하고 말할 수 있는 용기는 이때 힘들게 배운 것 같습니다.



기다림과 여유로움을 갖추시고,
제가 한 실수를 반복하지 마시라는 의미에서 적어 봅니다.

Integration의 유혹을 이겨내도록 도와주시는 클라이언트 분들의 믿음에 감사 드리고,
Integration의 유혹을 이겨내면서,
수준 높은 Release Quality에 열정을 실천하시는 팀원들과
숨어있는 많은 True 엔지니어들께 박수를 보내 드립니다.