대규모 소프트웨어 개발은 코드 양보다 조정 비용과 구조 설계가 더 어렵다
작은 프로그램을 잘 만드는 사람이라고 해서 곧바로 큰 시스템도 잘 다루는 것은 아니다. 대규모 개발에서 어려운 것은 코드가 많다는 사실 자체보다, 그 코드가 서로 얽히고 사람들 사이에서 설명되고 유지되어야 한다는 점이다. 프레드 브룩스가 오래전에 지적했듯 소프트웨어의 핵심 난제는 복잡성, 적합성, 변화 가능성, 보이지 않음에 있다.
그래서 큰 프로젝트가 흔들릴 때 원인을 개발자가 더 필요하다나 야근이 부족하다에서 찾으면 거의 항상 빗나간다. 규모가 커질수록 기능 구현 비용보다 설계, 조정, 전달, 의사결정 비용이 훨씬 빠르게 늘어나기 때문이다.
대규모 개발은 기능 수보다 관계 수가 문제다
작은 프로그램은 한 사람이 전체 구조를 머릿속에 넣고 다닐 수 있다. 하지만 서비스, 엔진, 툴, 데이터 파이프라인, 배포 환경, 운영 절차가 얽히면 이야기가 달라진다. 한 모듈의 변경이 다른 모듈의 성능, 테스트, 배포 일정, 운영 안정성에 동시에 영향을 준다.
이때 복잡성은 선형적으로 늘지 않는다. 코드 한 줄이 아니라 인터페이스와 의존성의 수가 문제를 만든다. 그래서 대규모 시스템에서는 기능 추가보다 경계 설계와 변경의 전파를 줄이는 구조가 먼저 중요해진다.
사람을 더 넣는다고 일정이 자동으로 줄지 않는다
브룩스의 가장 유명한 통찰 가운데 하나는 늦어진 소프트웨어 프로젝트에 사람을 더 넣으면 더 늦어진다는 말이다. 이 문장을 문자 그대로만 받아들이면 단순한 경구처럼 보이지만, 핵심은 훈련과 조정 비용이다. 새 인력을 투입하면 기존 인력이 온보딩, 리뷰, 맥락 공유에 시간을 써야 하고, 커뮤니케이션 경로도 늘어난다.
규모가 커질수록 팀 운영에서 중요한 것은 인원 수 그 자체보다 역할 구분과 의사결정 구조다. 누가 무엇을 책임지고, 어떤 문서와 인터페이스가 그 책임을 연결하는지가 없으면 사람 수는 곧 소음이 된다.
대규모 시스템은 문서와 경계가 없으면 금세 개인 의존형이 된다
작은 프로젝트는 구두 설명으로도 굴러간다. 하지만 큰 프로젝트는 그렇지 않다. 설계 의도, 데이터 계약, 운영 절차, 예외 처리 원칙을 남기지 않으면 시스템은 금방 이건 그 사람이 알아 상태가 된다. 그리고 그 사람이 빠지는 순간부터 유지보수 비용이 급격히 올라간다.
이 지점에서 중요한 것은 문서를 많이 쓰는 것이 아니라, 꼭 필요한 지식을 공유 가능한 형태로 남기는 일이다.
- 모듈의 책임은 무엇인가
- 어떤 입력과 출력이 약속되어 있는가
- 무엇을 바꾸면 어디까지 영향이 퍼지는가
- 장애가 나면 어디서부터 봐야 하는가
이 정도만 명확해도 대규모 개발의 위험은 크게 줄어든다.
게임 개발에서는 기술 문제와 운영 문제가 함께 커진다
게임 프로젝트는 특히 복잡하다. 런타임 코드만 있는 것이 아니라 툴, 에디터, 빌드, 콘텐츠 데이터, 클라이언트-서버 동기화, 라이브 운영이 함께 움직인다. 그래서 재미있는 기능을 만들었다와 상용 서비스로 유지된다 사이의 거리가 멀다.
프로토타입은 한 기능의 가능성을 확인하는 데 충분하지만, 상용 시스템은 장애 대응, 계측, 배포, 회귀 테스트, 운영 도구까지 필요하다. 규모가 커질수록 진짜 실력은 기능 구현보다 이 운영 현실을 견디는 구조를 만드는 데서 드러난다.
마치며
대규모 소프트웨어 개발을 어려워 보이게 만드는 것은 신비한 천재성이 아니다. 대부분은 복잡성을 다루는 구조, 사람 사이의 조정, 경계 설계, 문서화의 문제다. 작은 프로그램을 잘 만드는 능력은 분명 중요하지만, 큰 시스템을 만들려면 그 위에 공유 가능한 구조를 세우는 역량이 더 필요하다.
결국 큰 시스템을 잘 만든다는 말은 코드를 많이 쓴다는 뜻이 아니다. 많은 사람이 오래 다뤄도 무너지지 않는 구조를 만든다는 뜻에 더 가깝다.