소프트웨어 개발에서 버그는 숙명입니다. 대략 100~1000줄마다 버그가 하나씩 생긴다고 합니다. 아무리 유능한 개발자라 해도 버그를 피할 수는 없는 것이죠.
그래서 버그를 늘리지 않는 가장 확실한 방법은 코드를 한 줄도 늘리지 않는 것입니다.
반 농담이지만 이렇게 개념을 순수하게 살펴 보는 것은 도움이 됩니다.
이제 현실을 살펴 볼까요. 코드를 늘리지 않는다면 소프트웨어의 유용성은 서서히 삭아 없어질 겁니다. 프로그램은 가만히 있어도 환경이 변하면서 소프트웨어에는 계속 버그가 발생합니다.
그렇다면 필요한 것은 효과적인 중간점입니다. 최소한의 변경으로 최대한의 효과를 내는 것이 답입니다.
이를 위해 가장 먼저 필요한 전술은 고칠 필요가 없는 것을 고치지 않는 것입니다.
그런데 고칠지 말지는 어떻게 판단하나요?
코드를 얼마나 잘 수정하는가보다 중요한 것은 수정할 것과 수정하지 않을 것을 가리는 것입니다. 즉, 이슈 정의가 가장 중요한 첫 단계입니다.
고칠 필요가 없는 것을 고친다면 아무리 효율적으로 잘 고친다 한들 낭비일 테니까요.
관점에 따라 달라지는 이슈: 근거를 명확히 하기
예를 들어 보겠습니다.
어떤 웹사이트 사용자가 개발자에게 상품을 장바구니에 담은 다음에 어디로도 이동하지 않는다고 버그를 보고했습니다. 장바구니에 담은 다음에는 목록으로 이동해야 정상이라는 것입니다.
이것은 버그일까요? 이런 UI 이슈는 조금 까다로운데, 이 경우에는 어떤 관점에서 보느냐에 따라 이게 버그일 수도 있고 아닐 수도 있습니다.
매출을 늘린다는 관점에서 볼 때는 버그가 아닐 수 있습니다. 목록으로 돌아간 사용자는 금세 다른 것에 관심을 빼앗겨 구매를 잊을 지도 모르기 때문입니다. 이런 관점에서 본다면 오히려 장바구니로 곧장 보내는 게 더 나은 문제해결일 겁니다.
그러나 사용자의 관점에서 본다면 어떨까요? 목록으로 가면 좀더 생각할 시간을 가지게 돼 좋은 선택을 하게 될 지도 모르는 일입니다.
어떤 기업은 사용자를 독촉하지 않는 것을 가치로 삼을 지도 모르겠습니다. 그렇다면 상세 페이지에 그대로 있는 현재의 동작이 가장 나은 방법일 수도 있지요.
관점은 조직의 가치와 연결됩니다. 따라서 이런 경우 필요한 것은 근거를 명확하게 하는 것입니다.
사용자 보고의 행간을 읽기
어떤 경우에는 명백히 버그가 아닌 것이 버그로 보고되기도 합니다.
예컨대 한 사용자가 어떤 기능이 없다고 버그 보고를 했습니다. 그런데 확인해 보니 단지 그 사용자만 기능을 찾지 못한 것이었습니다.
이런 경우는 버그가 아닙니다. 안내로 충분하고 개발 쪽에서는 대응을 하지 않는 것이 더 효율적입니다.
그러나 비슷한 상황인데 다른 결론을 내려야 할 때도 있습니다. 있는 기능이 없다는 버그 보고가 반복적으로 들어온다면 어떻게 봐야 할까요? 기능이 있으므로 여전히 버그가 아니라고 판단해야 할까요? 이 경우 기능상 버그는 아니지만 UI 버그일 수 있습니다. 즉, 우리는 사용자들의 반응에서 행간을 읽어야 합니다.
이런 일을 잘 하려면 어떻게 해야 할까요? 사용자의 이야기를 유심히 듣고, 그의 말 자체가 아니라 상황에 주의를 기울여야 합니다.
사실 사용자가 보고하는 이슈는 사용자의 조작 실수인 경우가 꽤 있기 때문에 유심히 듣는 것이 쉬운 일은 아닙니다. 그러나 사용자의 말에는 어떤 원석이 담겨 있습니다. 원석을 가공해 가치로 만드는 것은 이슈 대응자의 몫입니다. ‘이 사용자는 왜 이런 상황에 처하게 됐을까? 내가 어떻게 도울 수 있을까?’ 하는 태도로 접근을 해야만 그렇게 할 수 있습니다.
이 점을 이해한다면 훨씬 나은 대응을 할 수 있을 것입니다.
코드가 잘못된 것이라면 분명한 버그일까?
코드에 오류가 있는 것이라면 버그가 분명하다고 생각할 수도 있습니다. 그러나 그것도 그리 단순하지는 않습니다. 다음 사례를 봅시다.
윈도우 3.x용 심시티를 만들었 던 존 로스가 제게 해 준 이야기가 있습니다. 심시티에 해제한 메모리를 다시 읽는 버그가 있었는데, 메모리를 그냥 내버려 두는 읜도우 3.x에서는 문제가 없었답니다. 여기서부터가 놀랍습니다. 윈도우95 베타 버전에서 심시티가 돌아가지 않았습니다. 마이크로소프트 사는 버그를 찾은 후, 윈도우 95에서 심시티를 처리하기 위한 특별 코드를 추가했습니다. (《조엘 온 소프트웨어》 358p, 에이콘, 2005)
윈도우 3.x용 심시티는 프로그램적 버그가 있음에도 잘 돌아갔습니다. 윈도우95는 메모리를 더 잘 관리하게 됐습니다. 이것은 윈도우 입장에서는 문제를 해결한 것이었습니다. 그런데 심시티 입장에서는 없던 버그가 생긴 것이 됐습니다.
재밌는 것은 윈도우95 개발진의 판단입니다. 메모리 관리를 더 잘 하게 되었고, 프로그램적 문제도 없는 윈도우95에서 심시티가 돌아가지 않는 이슈가 발생했습니다. 프로그램적으로 말하면 심시티가 문제였습니다. 그러나 윈도우95 개발진은 심시티를 처리하는 특별 코드를 추가해 이슈를 해결했습니다.
95년은 지금처럼 인터넷이 발달했던 때도 아닙니다. 따라서 만약 윈도우95가 이 이슈를 해결하지 않은 채로(즉, 프로그램적으로는 윈도우95에 아무런 문제도 없으니 그대로 출시를 했다면) 심시티는 윈도우95에서 돌아가지 않았을 것입니다. 그러면 많은 심시티 사용자들이 윈도우95로 업그레이드를 망설였을 테죠. 결국 윈도우95가 타격을 입었을 것입니다. 따라서 이것은 실질적으로는 심시티의 이슈가 아니라 윈도우95의 이슈였습니다. MS 개발진은 이슈 정의를 훌륭하게 한 것입니다.
어떻게 하면 윈도우 개발진처럼 사고할 수 있을까요? 이슈 정의를 프로그램 내부에서만 해서는 안 됩니다. 바깥으로도 눈을 돌려야 합니다. 많은 사람들이 문제라고 하면 그것은 문제일 가능성이 높습니다.
부족한 기능을 택하기
어떤 경우에는 기능을 부족하게 구현해서 오히려 이슈를 쉽게 해결하는 경우도 있습니다. 즉, 해결해야 할 과제의 범위 설정도 중요하다는 것입니다.
상품 입력 시스템을 만들 때였습니다. 처음에는 분류 같은 건 필요없다고 했고, 저는 그에 따라서 프로그램을 거의 다 만들었습니다. 상품을 입력하고 수정하고 불러오고 보여 주는 기능을 만들었죠.
그런데 출시가 임박했을 때 요구사항 변경이 있었습니다. 상품에 분류를 추가해 달라는 것이었습니다.
막판에 도입하기에는 상당히 노력이 많이 드는 변경이었는데 기한도 비용도 늘어나지 않은 채로 요구사항이 전달됐습니다.
저는 머리가 복잡해졌습니다. 분류를 저장하는 테이블을 만들고 연관 테이블도 만들어야 합니다. 분류에 따른 뷰 페이지도 만들어야 하고, 상품 입력/수정 UI도 만들어야 합니다. 저장 로직도 변경해야 했습니다.
저는 사수에게 이런 변경은 지금 일정에서 너무 힘들고 거의 불가능하다고 이야기했습니다.
그런데 사수는 요구사항과 고객의 의도를 듣더니 간단한 해결책을 내놨습니다. 분류에 따른 UI는 필요 없고, 분류 테이블을 만들 필요도 없고, 그냥 컬럼을 하나 추가하고 거기에 분류를 텍스트로 입력하게 하자는 것이었습니다.
분류 이름을 수정하게 되면 귀찮게 되겠지만 이 경우에는 분류를 수정할 일이 거의 없으므로 지금 일정과 비용으론 이게 최선이고, 고객과는 분류명을 한 번 정한 뒤엔 수정하지 않는 방식으로 합의를 보겠다고 했습니다. 이 해법대로라면 프로젝트 비용과 일정에 아무런 문제가 없어졌습니다.
이 일로 저는 큰 깨달음을 얻었습니다.
부족한 기능을 택함으로써 당면한 이슈를 해결하고, 이를 통해 또다른 이슈(일정 지연, 비용 초과)의 유발을 예방할 수도 있다는 것이었습니다.
과제의 범위를 설정하는 것은 정말 중요합니다. 그러려면 고객의 필요를 정확히 파악해야 했던 것입니다. 이 경우에도 답은 코드 안이 아니라 밖에 있었습니다.
정리
코드의 결함을 줄이는 중요한 한 가지 방법은 이슈인 것과 이슈가 아닌 것을 구분함으로써, 이슈가 아닌 것을 해결하지 않는 것입니다. 코드 작성이 없다면 버그 유발도 없습니다.
이슈임을 확인했다면 해결해야 할 범위를 적절히 설정하는 것입니다. 최소한의 변경으로 해결한다면 버그는 최소화될 것입니다.
이에 더해 단일 책임 원칙 같은 코드 내적인 소프트웨어 엔지니어링 원칙들을 지킨다면 금상첨화겠지요.
《코드 심플리시티》 6장을 참고했습니다.
댓글 남기기