소프트웨어 개발에 대한 오해와 실체

사장님의 한마디에서 시작된 오해

김도현 사장님이 개발사와 첫 미팅에서 이렇게 말했다고 하자. "요즘 나온 좋은 프로그램 도구 하나만 쓰면 개발자들이 알아서 빠르게 만들어주는 거 아닌가요? 옆 가게도 그렇게 했다던데요." 이 한 문장 안에는 소프트웨어 개발에 대한 오해가 최소 두 가지 들어있다 — 좋은 도구가 좋은 소프트웨어를 만들어준다는 믿음, 그리고 다른 가게의 경험이 책마루에도 그대로 적용될 거라는 믿음.

1장에서 소프트웨어 개발이 왜 공학적 절차를 필요로 하는지 살펴봤다. 이번 장은 반대편에서 접근한다 — 소프트웨어 개발을 둘러싸고 사람들이 흔히 갖는 그릇된 믿음(오해)이 무엇이고, 그 오해가 실제로 프로젝트를 어떻게 망가뜨리는지를 관리자·고객·엔지니어 세 입장에서 하나씩 짚어본다.

소프트웨어는 왜 이렇게 오해받기 쉬운가

오해가 유독 소프트웨어 개발에서 자주 생기는 데는 이유가 있다. 건물이나 자동차는 눈에 보이고 손에 만져진다 — 골조가 세워지는 걸 보면 공사가 얼마나 진행됐는지 누구나 짐작할 수 있다. 반면 소프트웨어는 화면에 뭔가 뜨기 전까지는 진행 상황이 눈에 보이지 않는다. 책마루 사장님 입장에서는 개발자가 매일 무슨 일을 하는지, 정말 진도가 나가고 있는지 확인할 방법이 마땅치 않다. 이 "보이지 않는다"는 특성이 오해가 자라나는 토양이 된다.

비용 구조도 오해를 부추긴다. 건축은 전체 비용의 대부분이 실제 시공(자재와 인건비)에 들어간다. 그런데 소프트웨어는 반대에 가깝다 — 코드를 타이핑하는 구현 단계는 전체 개발 비용의 일부일 뿐이고, 나머지 대부분은 무엇을 어떻게 만들지 정하는 요구사항 분석·설계, 그리고 제대로 만들어졌는지 확인하는 테스트에 들어간다. "그냥 코드만 짜면 되는 거 아니냐"는 생각은 이 비용 구조를 거꾸로 이해한 데서 나온다.

오류가 발견되는 시점도 마찬가지로 반직관적이다. 요구사항 분석 단계에서 잡아낸 오류 하나를 고치는 비용을 1이라 하면, 같은 오류를 테스트 단계에서 발견했을 때는 그 몇 배, 이미 배달된 뒤 사장님이 직접 발견했을 때는 훨씬 더 큰 비용이 든다. 책마루의 배달 가능 지역 판단 기준이 잘못 정의된 채로 설계·구현까지 진행됐다가 오픈 직전에야 발견된다면, 관련된 화면과 로직을 전부 다시 뜯어고쳐야 한다. "오류는 어차피 나중에 테스트하면서 잡으면 된다"는 생각이 위험한 이유가 여기에 있다 — 늦게 잡을수록 청구서가 커진다.

소프트웨어 위기라는 표현이 뜻하는 것

이런 오해들이 개별 프로젝트 하나에서 끝나지 않고 업계 전체에서 반복되는 현상을 흔히 소프트웨어 위기라고 부른다. 여기서 "위기"는 갑자기 무너진다는 뜻이 아니라, 뚜렷한 도약 없이 문제가 서서히 누적되는 상태를 가리킨다. 다른 공학 분야는 새로운 재료나 공법이 등장할 때마다 생산성이 눈에 띄게 뛰어오르는 전환점을 겪어왔다. 반면 소프트웨어 개발은 언어와 도구는 계속 바뀌었어도, "요구사항을 잘못 이해하면 뒤에서 큰 비용을 치른다"는 근본 구조 자체는 수십 년째 그대로다.

이 정체의 원인은 한 가지가 아니라 여러 갈래가 겹친 결과에 가깝다. 손님(사장님)의 기대 수준은 계속 높아지는데 그 기대를 정확히 읽어내는 절차는 부실하고, 관리자와 엔지니어가 새로운 개발 기법을 접할 기회가 충분치 않으며, 무엇보다 소프트웨어 개발의 역사가 다른 공학 분야에 비해 짧아 참고할 만한 축적된 경험치가 상대적으로 적다. 책마루처럼 작은 프로젝트라고 이 위기에서 자유로운 건 아니다 — 오히려 전담 관리 인력을 따로 둘 여유가 없는 소규모 프로젝트일수록, 앞서 살펴본 오해 하나하나가 프로젝트 전체를 흔드는 위험 요소로 더 쉽게 번진다.

위기를 벗어나는 첫걸음은 거창한 해법을 찾는 게 아니라, 지금 우리 프로젝트 안에 이런 오해가 자리 잡고 있지는 않은지 있는 그대로 인식하는 것이다. 문제를 정확히 인식하는 사람만이 그 문제를 고칠 방법을 찾을 수 있다는 원칙은 소프트웨어 개발에서도 그대로 통한다.

관리자가 자주 빠지는 세 가지 오해

오해 1: 좋은 도구를 사면 좋은 소프트웨어가 저절로 나온다. 사장님이 최신 개발 툴이나 클라우드 서비스를 계약했다고 해서 책마루 시스템의 품질이 자동으로 올라가지는 않는다. 소프트웨어 개발은 여전히 사람이 판단하고 설계하는 일이다. 좋은 도구는 그 판단을 더 빠르게 실행하도록 도와줄 뿐, 판단 자체를 대신해주지 않는다. 개발팀이 재고 동시성 문제를 어떻게 풀지 이해하지 못한 채로 최신 프레임워크를 쓴다고 문제가 저절로 풀리지 않는 것과 같다.

오해 2: 개발자가 요구사항을 분석하고 있으면 "노는 시간"이다. 책마루 프로젝트 중반에 사장님이 "화면이 하나도 안 보이는데 다들 회의만 하고 있다"며 답답해하는 상황을 상상해보자. 실제로는 개발팀이 "배달 가능 지역을 우편번호로 판단할지, 주소 텍스트로 판단할지"를 놓고 이후 개발 방향을 정하는 중일 수 있다. 이 논의를 건너뛰고 코드부터 짜면, 나중에 그 판단이 틀렸다는 게 드러났을 때 이미 짠 코드를 통째로 버려야 한다. 분석하고 생각하는 시간은 눈에 보이지 않을 뿐 결코 낭비가 아니다.

오해 3: 일정이 밀리면 사람을 더 투입하면 된다. 책마루 결제 연동이 예정보다 2주 늦어지고 있다고 하자. 이때 사장님이 "그럼 개발자 두 명 더 구해서 붙이자"고 제안할 수 있다. 하지만 새로 투입된 인력은 책마루 프로젝트의 맥락(재고 데이터 구조, 이미 내려진 설계 결정)을 처음부터 배워야 하고, 기존 팀원들은 그 교육에 시간을 뺏긴다. 프로젝트 후반부에 인력을 추가하는 것은 오히려 일정을 더 늦추는 경우가 많다.

왜 인력 추가가 역효과를 내는가: 의사소통 경로는 인원수가 늘어날수록 산술급수가 아니라 기하급수적으로 늘어난다. 2명이 협업할 때 소통 경로는 1개지만, 5명이면 10개다. 새 인력을 투입하면 일할 손은 늘지만, 그만큼 맞춰야 할 소통 비용도 함께 불어난다.

고객이 자주 빠지는 두 가지 오해

오해 1: 대략적인 목표만 말해두면 나머지는 알아서 채워질 것이다. 사장님이 "온라인 주문 되게만 해주세요, 세부적인 건 나중에 정해도 되잖아요"라고 말했다고 하자. 실제로는 반대다. 계약(제안서 포함)으로 프로젝트가 시작되면, 그 안에는 개략적인 목표만 담기고 구체적인 내용은 요구사항 분석 과정에서 채워져야 한다. 그런데 이 구체화는 사장님 혼자의 몫이 아니라 개발팀과 사장님이 함께 채워야 하는 과정이다. "나중에 알아서"라는 태도로 이 과정을 미루면, 오픈이 임박해서야 "이게 아니었는데"라는 실망이 터져나온다.

오해 2: 요구사항은 소프트웨어니까 언제든 쉽게 바꿀 수 있다. 소프트웨어가 물리적인 벽돌보다 유연한 것은 사실이다. 하지만 그 유연함을 "아무 때나 바꿔도 공짜"라는 뜻으로 오해하면 곤란하다. 배달 가능 지역 기준을 요구사항 분석 단계에서 바꾸는 것과, 이미 결제·재고 로직이 그 기준에 맞춰 다 짜인 뒤에 바꾸는 것은 비용이 전혀 다르다. 변경 자체를 막을 수는 없지만 — 오히려 자연스러운 일이지만 — 변경이 언제 일어나느냐가 그 비용을 좌우한다는 사실은 고객도 알고 있어야 한다.

엔지니어가 자주 빠지는 세 가지 오해

오해 1: 프로그램이 돌아가기 시작하면 내 일은 끝난 것이다. 책마루 주문 시스템이 오픈해서 정상 작동한다고 개발자의 역할이 끝나는 게 아니다. 배달앱 API가 바뀌거나, 재고 동시성 버그가 뒤늦게 발견되거나, 사장님이 정기구독 배송 기능을 추가로 원할 수 있다. 시스템이 배달된 시점은 유지보수라는 새로운 국면의 시작이다. 이 장기적인 안목 없이 "일단 돌아가면 끝"이라는 태도로 짠 코드는 나중에 고치기 어려운 코드가 되기 쉽다.

오해 2: 실제로 시스템을 돌려보기 전까지는 품질을 판단할 방법이 없다. 품질은 마지막 테스트 한 번으로 얻어지는 게 아니다. 요구사항 명세서 검토 단계에서 "이 요구사항이 맞게 정리됐나"를 점검하고, 설계 문서 검토 단계에서 "이 설계가 요구사항을 제대로 반영했나"를 점검하는 식으로, 각 단계마다 품질을 걸러내는 지점이 있다. 책마루 프로젝트라면 요구사항 명세서를 사장님과 함께 검토하는 자리 자체가 이미 품질 관리 활동이다 — 코드가 한 줄도 없는 시점에도 품질은 관리될 수 있다.

오해 3: 프로젝트의 결과물은 작동하는 프로그램 하나뿐이다. 요구사항 명세서, 설계 문서, 테스트 결과 같은 중간 산출물은 부차적인 게 아니라 그 자체로 중요한 결과물이다. 책마루 시스템을 만든 개발사가 나중에 바뀌거나 다른 개발자가 유지보수를 맡게 됐을 때, 이 문서들이 없으면 코드만 보고 "왜 이렇게 짰는지"를 처음부터 다시 추리해야 한다. 문서를 남기는 일은 당장의 개발 속도를 늦추는 것처럼 보여도, 시스템의 수명을 늘리는 투자에 가깝다.

세 가지 오해를 나란히 놓고 보면 공통된 태도가 보인다 — 자신이 짠 코드를 "이번 프로젝트에서 끝나는 결과물"로 보느냐, "앞으로도 계속 쓰일 자산"으로 보느냐의 차이다. 아마추어와 프로의 차이는 코드를 얼마나 빨리 짜느냐가 아니라, 자신의 결과물이 배달된 이후에도 계속 책임을 진다는 감각을 갖고 있느냐에 있다. 책마루 시스템이 오픈한 뒤에도 개발사와 사장님의 관계가 이어지는 이유가 여기에 있다.

오해를 걷어내면 남는 것

지금까지 살펴본 여덟 가지 오해를 관통하는 공통점이 하나 있다 — 전부 "지름길이 있을 것"이라는 기대에서 나온다는 점이다. 좋은 도구만 사면, 인력만 더 투입하면, 목표만 대충 던져두면, 프로그램만 돌아가면 — 이런 기대는 소프트웨어 개발의 본질적인 복잡성을 무시한 것이다. 흔히 말하는 소프트웨어 위기(생산성이 사용자의 기대를 따라가지 못하고, 품질과 유지보수가 계속 어려워지는 상태)도 결국 이런 오해가 누적된 결과에 가깝다.

오해를 걷어낸 자리에 남는 실체는 단순하다 — 소프트웨어 개발은 지름길이 없는, 계획하고 분석하고 설계하고 검증하는 절차를 성실히 밟아야 하는 일이라는 것. 관리자와 고객과 엔지니어가 각자의 오해를 인식하고 내려놓을 때, 비로소 1장에서 다룬 소프트웨어 공학의 6단계가 제 역할을 할 수 있는 조건이 만들어진다.

책마루 프로젝트로 다시 돌아가보자. 첫 미팅에서 "좋은 도구 하나면 되는 거 아니냐"고 물었던 사장님이, 오해를 하나씩 걷어내고 나면 질문이 이렇게 바뀐다 — "그럼 우리 요구사항을 정확히 정리하는 데 시간을 얼마나 써야 할까요?", "요구사항이 중간에 바뀌면 어느 시점까지는 큰 비용 없이 반영할 수 있나요?" 오해가 사라진 자리에 남는 건 정답이 아니라 더 나은 질문이다. 그리고 이 더 나은 질문에 답하려면, 애초에 어떤 절차와 방법으로 개발을 진행할지부터 정해야 한다.

핵심 정리

• 소프트웨어는 눈에 보이지 않고 비용 구조가 직관과 반대(구현보다 분석·설계·테스트에 더 많은 비용)라는 특성 때문에 유독 오해가 자라나기 쉽다.
• 관리자는 "도구가 해결해준다", "분석은 비생산적이다", "인력을 추가하면 된다"는 오해에 빠지기 쉽다 — 특히 마지막 오해는 의사소통 비용의 기하급수적 증가 때문에 오히려 역효과를 낸다.
• 고객은 "목표만 대충 던지면 된다", "요구사항은 아무 때나 공짜로 바꿀 수 있다"는 오해에 빠지기 쉽다.
• 엔지니어는 "동작하면 끝", "테스트 전엔 품질을 알 수 없다", "결과물은 프로그램뿐이다"라는 오해에 빠지기 쉽다.
• 이 오해들의 공통점은 소프트웨어 개발의 복잡성을 우회할 지름길이 있다고 믿는 것 — 실체는 정반대로, 계획과 분석과 검증을 성실히 거치는 절차뿐이다.

다음 장(3장)에서는 이 절차를 실제로 어떤 순서와 방식으로 밟아나갈지 — 폭포수 모델부터 애자일까지 소프트웨어 개발 방법론을 다룬다.