소프트웨어 품질이 낮다고 동의하는 대부분의 사람들이 개발자의 수준을 먼저 얘기하곤 한다. 심지어 개발자들도 스스로의 수준을 얘기하는 경우가 더러 있다. 하지만, 이건 아니다. 수압이 낮아서 물이 안나오는 데 애꿋은 수도꼭지 탓만 하는 것과 비슷하다.
한국의 소프트웨어 품질이 낮은 이유는 프로그래머의 수준보다는 프로그래머의 의견이 무시되는 개발속도/기능 위주의 개발 환경 때문이다.
프로그램 개발에 관련해 여러사람들과 얘기하다보면 항상하는 얘기가 있다. 어느정도 규모나 완성도를 요구하는 소프트웨어의 개발은 고층건물을 짓는 것과 비슷하다는 얘기다. 단층 주택은 별 고민 없이 뚝딱뚝딱 지을 수 있다. 하지만 100층짜리 건물은 얘기가 다르다. 지반 공사 부터 시작해서 하중 계산, 고층에서의 진동, 내장재의 물리적 특성, 전기 분배, 상하수 배관 시설, 낸난방 및 공조 등의 각 부분에서 물리, 전기, 인체공학 등등의 여러 기술이 복합적으로 사용되어 건물이 완성된다. 프로그램도 마찬가지다. 조엘 온 소프트웨어에는 웹페이지에서 간단한 파일을 업로드 하는 페이지를 예로들고 있다. 수 Kb의 파일을 업로드하는 코드는 10분이면 완성이다. 하지만 Gb라면 어떨까. 파일 업로드 상태를 모니터하는 쓰레드와 서버와 주기적으로 통신하여 상태를 확인하는 코드, 업로드 중에 발생하는 여러 상황에 대한 고려, 업로드 실패시 전송된 부분에 대한 후처리 등 생각할 일이 많다.
하지만 이를 인식한 개발자의 의견이 반영되는 경우는 매우 드물다. 일반적으로는 그냥 업로드 파일의 크기를 수 Mb로 제한하고 대신 다른 다양한 기능을 더 추가하는 방향으로 진행된다. 기능적인 완성도를 추구하는 개발보다는 여러 가지 기능들을 빠른 시일에 화려한 UI와 개발하는 방향으로 진행된다. 굳이 일일이 예를들지 않아도 우리식(?)으로 개발된 프로그램들을 보면 대부분 이런 식이다.
A라는 거대 고객이 X라는 프로그램을 만들어 달란다. B사는 요구하는 기능을 충실히 구현하고 에러가 발생하지 않도록 많은 상황을 고려하여 신뢰성있는 소프트웨어를 개발하는데 집중한다. C사는 B사의 소프트웨어 보다 더 많은 기능을 넣고 화려한 UI로 장식한다. 고객 입장에서 최종 제품을 테스트 해보니 둘다 원하는 기능이 동작하는데 C사는 더 많은 기능을 제공하면서 더 이쁘다. 그래서 C사를 선택한다. 나중에 고객은 미처 예상하지 못했던 오류를 C사의 제품에서 발견한다. B사는 이러한 경우까지 고려했다고 처음에 설명했지만 고객은 오류를 직접 당하기 전까지는 이해하지 못한다. 결국 이런식의 제품 개발이 반복되어 B사도 다기능의 화려한 외양의 소프트웨어 개발에 매진하게 된다.
No comments:
Post a Comment