엔터프라이즈 소프트웨어 개발 서비스, 무엇을 사는가

엔터프라이즈 소프트웨어 개발 서비스라는 말은, 대부분의 개발사 웹사이트에서 쓰이는 의미로는 똑같은 일에 더 큰 숫자를 붙인 것을 뜻합니다. 팀도 같고 방식도 같은데 제안서에 고객사 로고 벽이 하나 붙고 가격이 세 배가 됩니다. 구매자도 이를 알기 때문에, 조달 부서는 이 단어를 무시하고 계약 부속서를 읽는 법을 익혔습니다.

그 아래에는 진짜 구분이 하나 있고, 그것은 회사 규모의 문제가 아닙니다. 40명짜리 보험사가 진짜 엔터프라이즈 프로그램을 굴릴 수 있고, 12,000명짜리 유통사가 사실상 웹사이트 하나를 발주하기도 합니다. 둘을 가르는 것은 그 시스템이 만드는 쪽에 지우는 의무입니다. 다른 시스템 몇 개와 대화해야 하는지, 얼마나 멈춰도 되는지, 누가 릴리스를 막을 수 있는지, 어느 규제 기관이 관심을 갖는지, 그리고 공급자가 손을 떼면 무슨 일이 벌어지는지입니다.

아래에서는 그 의무를 기준으로 이 범주를 정의합니다. 구매자가 그 의무를 감당할 수 있는 공급자와, 평범한 구축에 엔터프라이즈라는 표지만 씌운 공급자를 구별할 수 있도록 하기 위해서입니다.

소프트웨어 프로젝트를 실제로 엔터프라이즈로 만드는 것은 무엇입니까? 구매자의 규모가 아닙니다. 프로젝트가 엔터프라이즈가 되는 것은 평범한 구축에는 없는 제약을 지기 때문입니다. 넓은 연동 범위, 계약상의 가용성과 복구 의무, 규제 노출, 각각이 릴리스를 막을 수 있는 여러 이해관계자 집단, 순진한 설계를 무너뜨리는 데이터 양, 그리고 지금은 아무도 이해하지 못하는 시스템과 공존해야 한다는 요구입니다. 아키텍처와 비용 대부분을 결정하는 것은 기능 목록이 아니라 이 제약들입니다.

무엇이 프로젝트를 엔터프라이즈로 만드는가

쓸모 있는 판별법은 제약의 목록이고, 그중 하나가 아니라 대부분을 질 때 프로젝트가 여기에 해당합니다. 정직하게 적용하면 엔터프라이즈로 팔리는 것 상당수가 탈락하고, 소규모 구축으로 팔린 탓에 그렇게 산정되어 실패하는 일들이 오히려 해당합니다.

연동 범위

새 소프트웨어가 데이터를 주고받아야 하는 시스템의 수를 센 다음, 그 시스템들을 소유한 별개의 팀과 벤더의 수를 세십시오. 비용을 예측하는 것은 두 번째 숫자입니다. 사내 팀 하나가 소유한 세 개의 연동은 2주 작업입니다. 벤더 세 곳이 각각 소유한 세 개의 연동은, 각자 고유한 변경 창구와 샌드박스 가용 시간과 지원 데스크를 갖고 있어 한 분기 작업이 됩니다.

소유자마다 여러분이 통제할 수 없는 일정을 들고 옵니다. 샌드박스를 월 단위로 갱신하는 벤더가 여러분의 테스트 주기를 정하고, 인증에 6주가 걸리는 결제 사업자가 여러분의 오픈 날짜를 정합니다. 상대가 열 곳을 넘어가면 연동 일정표가 곧 프로젝트 계획이 되고, 개발은 그 틈에 끼어 들어갑니다.

가동률 의무

평범한 소프트웨어는 동작할 것이라고 기대됩니다. 엔터프라이즈 소프트웨어는 그 기대에 숫자가 붙고, 대개 서비스 크레딧이 딸린 계약에 적힙니다. 이 숫자가 가장 먼저 바꾸는 것은 아키텍처입니다. 단일 인스턴스 배포로는 코드가 아무리 좋아도 그 숫자를 지킬 수 없기 때문입니다.

유지보수 시간대를 허용하는 목표에서 허용하지 않는 목표로 넘어가는 한 걸음은, 대부분의 엔터프라이즈 예산에서 가장 비싼 한 줄이고, 그 값을 본 적 없는 사람들이 합의하는 일이 잦습니다. 의미 있는 가동률 SLA에 관한 글에서 그런 숫자가 어떻게 쓰이고 얼마나 일상적으로 잘못 쓰이는지 다뤘습니다.

거부권을 가진 이해관계자

평범한 프로젝트에는 제품 책임자가 있습니다. 엔터프라이즈 프로젝트에는 제품 책임자, 정보보안 조직, 개인정보 보호 책임자, 조달 담당, 네트워크를 소유한 인프라 팀, 앞으로 지원 부담을 물려받을 서비스 데스크, 그리고 흔히 임상, 법무, 컴플라이언스 검토자가 있습니다.

그중 누구든 릴리스를 멈출 수 있고, 그중 누구도 비용을 내는 사람에게 보고하지 않습니다. 따라서 의사결정에는 난이도와 무관한 달력상의 시간이 들고, 그것을 계획에 넣지 않은 공급자는 둘째 달부터 모든 일정을 놓칩니다.

이제 아무도 이해하지 못하는 시스템

모든 엔터프라이즈 환경에는 동작이 출력으로만 문서화된 시스템이 최소한 하나 있습니다. 그것을 만든 사람들은 떠났고, 명세가 있다 해도 그것은 더 이른 버전을 설명합니다. 그것은 돌아가고, 업무를 떠받치고 있으며, 손대는 것은 현명하지 않다고 여겨집니다.

새 소프트웨어는 그것과 공존해야 하므로, 먼저 누군가 그것이 실제로 무엇을 하는지 밝혀내야 합니다. 그것은 개발이 아니라 고고학입니다. 운영 데이터를 읽고, 호출을 추적하고, 사본을 대상으로 통제된 실험을 하고, 코드가 함축하는 규칙을 적어 내려가는 일입니다. 큰 환경에서는 몇 주짜리 작업이고, 눈에 보이는 기능을 만들어내지 않기 때문에 협상에서 가장 자주 삭제되는 항목입니다.

이것을 지우면 작업은 통합 테스트로 옮겨가고, 이미 결함을 고치느라 바쁜 사람들이 시간에 쫓기며 발견하게 됩니다. 조사를 별도로 견적하고 그것을 지켜내는 공급자는, 이런 프로그램이 어떻게 실패하는지에 대해 참말을 하고 있는 것입니다. 레거시 현대화와 재작성 대 리팩터링 판단에 관한 메모에서 그 고고학이 무엇을 찾아내는지 다뤘습니다.

조달이 일의 절반

기술자 대부분은 이 부분을 세 배쯤 낮춰 잡습니다. 진짜 엔터프라이즈 계약에서는 첫 대화부터 첫 코드 한 줄까지의 작업이 첫 인도 단위보다 오래 걸리고, 양쪽의 시니어 시간을 소모합니다.

2025년 2월 24일 이후 영국 공공 부문은 Procurement Act 2023 아래에서 움직이고, 공공 계약에 입찰하는 공급자는 확장된 Find a Tender 서비스 안의 중앙 디지털 플랫폼에 등록되어 있어야 합니다. 민간 부문 조달에는 그에 대응하는 단일 창구가 없고, 역설적으로 그 때문에 더 느립니다. 구매자마다 자기 방식을 따로 발명했기 때문입니다.

보안 질문서

스프레드시트 하나가 날아옵니다. 개발 생명주기, 접근 통제, 패치 주기, 하도급자, 데이터 소재지, 사고 대응 시간, 그리고 신원 조회를 묻습니다. 큰 구매자는 수백 문항을 보내고, 은행이나 NHS 트러스트는 그보다 더 보냅니다.

질문 자체는 어렵지 않지만, 답이 이미 정책으로 존재해야만 답할 수 있습니다. 입찰 도중에 처음으로 그것을 만들어내는 공급자는 4주에서 6주가 걸리고 몇 개는 틀립니다. 해본 적 있는 공급자는 유지되고 있는 답변 라이브러리에서 며칠 만에 답합니다. 그것은 그들을 선호할 정당한 이유입니다.

벤더 등록, 보험, 재무 심사

등록은 입찰과 별개이며 흔히 나란히 진행됩니다. 구매자가 지정한 수준의 전문직 배상책임보험과 사이버 배상책임보험, 사용자 배상책임보험, 때로는 생산물 배상책임보험의 증빙을 요구받습니다. 엔터프라이즈 구매자는 작은 컨설팅사가 기본으로는 갖고 있지 않은 보상 한도를 요구하는 경우가 많고, 입찰 도중에 보상 한도를 올리는 데는 시간이 걸립니다.

이어서 재무 심사가 옵니다. 구매자는 제출된 재무제표를 뽑고 신용 점수를 조회하며, 더 큰 계약에서는 월별 관리 회계나 모회사 보증을 요구합니다. 계약 금액을 감당할 수 없는 재무 상태의 공급자는 기술적 우수성과 무관하게 배제되고, 유능한 소규모 회사가 자기에게 맞았던 입찰에서 지는 이유가 바로 이것입니다.

영업 주기가 첫 증분보다 오래 가는 이유

두 시간표를 나란히 놓으면 문제의 모양이 보입니다. 자격 확인, 요구사항, 보안 검토, 법무 협상, 보험 증빙, 등록 절차는 수십만 GBP 규모의 계약에서 보통 넉 달에서 아홉 달을 차지합니다. 그리고 작업이 시작된 뒤 첫 쓸모 있는 소프트웨어 증분은 10주쯤 걸릴 수 있습니다.

그 주기의 처음에 쓰인 견적은 서명 시점에는 이미 낡았고, 그 간극 내내 고정 가격을 유지하는 공급자는 두껍게 얹었거나 나중에 범위를 두고 다툴 작정입니다. 기술 전제도 늙습니다. 입찰 때 최신이던 버전이 착수 때는 지원 종료일 수 있습니다.

모든 견적에 날짜를 적고 전제를 밝히고, 그 숫자가 살아남은 척하는 대신 서명 시점에 기준선을 다시 잡는 단계를 합의하십시오. 원래 숫자가 유효하다고 우기는 구매자는 변경 요청 파이프라인을 사는 것입니다. 쓸 만한 견적을 받아내는 소프트웨어 RFP 작성법 안내서에서 그 문서에 무엇이 들어가야 하는지 다뤘습니다.

진짜 산출물은 비기능 요구사항

기능 목록은 쓰기 쉽고, 무언가를 결정하는 일은 거의 없습니다. 아키텍처와 인프라 비용과 팀 규모와 테스트 주기의 길이를 결정하는 것은 비기능 요구사항이며, 대부분의 엔터프라이즈 프로그램에서 그것은 기능 목록이 마흔 쪽에 이르는 문서 안에서 두 문단 분량입니다.

이 불균형은 초과를 가장 확실하게 예고하는 신호입니다. 첫 워크숍을 가용성, 복구, 지연, 처리량, 감사 가능성, 보존에 쓰는 공급자는 시간을 끄는 것이 아닙니다. 이 여섯 숫자가 아키텍처 선택지 대부분을 지워버리고, 늦게 정하면 다시 만들어야 하기 때문입니다.

숫자와 조건이 붙은 검증 가능한 문장으로 쓰십시오. “시스템은 고가용이어야 한다"는 요구사항이 아닙니다. “주문 서비스는 5영업일 전에 통보한 두 시간의 창을 제외하고, 로드 밸런서에서 측정한 월간 가용성 99.9%를 유지해야 한다"는 요구사항입니다. 테스트가 그것을 불합격시킬 수 있기 때문입니다.

복구 시점과 복구 시간을 쉬운 말로

이 숫자들 가운데 둘은 어떤 기능보다 비용을 좌우하는데, 뜻을 서로 바꿔 쓰는 사람들이 흔히 인용합니다. 목표 복구 시점 (RPO) 은 데이터를 얼마나 잃어도 되는가입니다. RPO 한 시간은 재해 뒤 최대 한 시간 치 거래가 사라질 수 있음을 받아들인다는 뜻이고, 백업이나 복제 체계는 그보다 나빠지지 않음을 보장해야 합니다. 목표 복구 시간 (RTO) 은 얼마나 멈춰 있어도 되는가이고, RTO 네 시간은 사고 발생으로부터 네 시간 안에 서비스가 다시 트래픽을 처리하고 있다는 뜻입니다.

두 숫자 모두 곧바로 아키텍처로 번역됩니다. AWS는 재해 복구 지침에서 네 가지 큰 전략을 제시합니다. 백업과 복원, 파일럿 라이트, 웜 스탠바이, 그리고 다중 사이트 액티브/액티브입니다. 싸고 느린 것에서 비싸고 거의 즉시인 것까지 늘어서 있고, 두 목표가 합의되는 순간 선택은 이미 정해집니다.

책임감 있게 들린다는 이유로 공격적인 숫자에 합의하지 마십시오. RPO 0과 분 단위 RTO는 지속적 복제와 두 번째 라이브 환경을 뜻하고, 인프라 비용은 대략 두 배가 됩니다. 소규모 소프트웨어 팀을 위한 재해 복구 글에서 더 싼 등급이 무엇을 사주는지 보여드립니다.

가용성 산수와 SLA가 실제로 사주는 것

가용성 백분율은 소수점 뒤에 의미를 숨깁니다. 30일짜리 달에서 99.9%는 약 43분의 다운타임을, 99.95%는 약 22분을, 99.99%는 약 4분을 허용합니다. 이것은 배포와 인증서 갱신과 예상보다 오래 걸린 데이터베이스 장애 조치를 포함한, 그 달 전체의 예산입니다.

한 달에 4분은 업무 시간에 배포하고 엔지니어 한 명을 호출하는 팀에게는 달성 불가능합니다. 모든 계층의 이중화, 자동 장애 조치, 트래픽을 끊지 않는 배포, 그리고 새벽 세 시에 깨어 있는 사람이 필요합니다. 마지막 항목은 대개 인프라보다 비싸고, 원래 예산에는 거의 들어 있지 않습니다. 측정 지점도 계약에 못 박으십시오. 로드 밸런서에서 읽은 가용성과 실사용자 텔레메트리에서 읽은 가용성은 같은 사고에서 자릿수가 다를 수 있습니다.

지연, 처리량, 그리고 아무도 재보지 않은 부하

지연 목표에는 백분위와 범위가 필요합니다. 평균이 실패를 가리기 때문입니다. “초당 400 요청 부하에서 결제 엔드포인트 95 백분위 200밀리초"라는 목표는 검증 가능합니다. “빠르게"는 그렇지 않고 평균도 마찬가지입니다. 평균 200밀리초는 스무 명 중 한 명이 4초를 기다리는 상태와 얼마든지 양립하기 때문입니다.

처리량에는 평균이 아니라 최대치가 필요합니다. 유통은 크리스마스 직전 금요일에 맞추고, 급여 시스템은 그달 마지막 영업일에, 공공 서비스는 발송된 안내문에 적힌 마감일에 맞춰 용량을 잡습니다. 연평균에 맞춰 잡는 것이 오픈 첫 번째 바쁜 시간에 실패하는 방식입니다. 최대치는 기존 시스템의 로그에서 가져오십시오. 10대 1의 비율은 흔하고, 그 비율이 설계에 큐가 필요한지를 결정합니다.

감사 가능성과 보존

규제를 받는 구매자, 그리고 점점 규제를 받지 않는 구매자까지도 누가 언제 무엇을 바꿨는지에 몇 년 뒤에 답해야 합니다. 그것은 로깅 설정이 아니라 설계 요구사항입니다. 행을 덮어쓰는 시스템은 답할 수 없고, 그 답은 보존 정책이 정한 기간만큼 살아남아야 합니다.

세 가지를 일찍 정하십시오. 어떤 이벤트를 감사 대상으로 삼을 것인가. 보통은 모든 HTTP 요청이 아니라 법적 또는 재무적 의미가 있는 레코드의 상태 변경입니다. 각 분류의 레코드를 얼마나 오래 보관할 것인가. 이는 법률 문제이며 개인정보 보호 제약이 붙습니다. 개인 데이터를 필요보다 오래 갖고 있는 것 자체가 위반이기 때문입니다. 그리고 누가 그 기록을 읽을 수 있는가. 관리자가 고칠 수 있는 감사 로그는 아무것도 증명하지 못합니다. 보존과 삭제권이 여기서 충돌하고, 그 긴장은 정책이 아니라 스키마에서 해소됩니다.

구매자가 요구할 인증들

반복해서 등장하는 것이 셋이고, 끊임없이 혼동되며, 증명하는 바가 서로 다릅니다. 차이를 설명하지 못하는 공급자는 그것을 갖고 있지 않습니다.

Cyber Essentials와 Cyber Essentials Plus

Cyber Essentials는 영국 정부가 뒷받침하는 기준선으로, NCSC가 개발하고 공식 전달 파트너인 IASME를 통해 제공됩니다. 방화벽, 안전한 구성, 보안 업데이트 관리, 사용자 접근 통제, 악성코드 방지의 다섯 가지 기술 통제를 다룹니다. 기본 등급은 독립적으로 검토되는 자가 평가 질문서이고, NCSC는 조직 규모에 따라 GBP 320 플러스 VAT부터의 가격을 제시합니다.

Cyber Essentials Plus는 같은 다섯 가지 통제를 주장이 아니라 독립적인 기술 감사로 검증한 것입니다. 심사자는 내부와 외부 취약점 스캔을 수행하고 사용자 단말, 인터넷 게이트웨이, 인터넷에 노출된 서버의 표본을 시험합니다. Plus 감사는 기본 인증으로부터 3개월 안에 완료되어야 하며, 두 인증서의 유효 기간은 모두 12개월입니다.

이 제도는 기술적으로만이 아니라 상업적으로도 중요합니다. 2025년 2월 24일부터 중앙 부처와 그 산하 기관, 비부처 공공 기관, NHS 기관에 적용되고 있는 PPN 014는, 공급자가 시민의 개인정보, 공무원의 개인정보, 또는 OFFICIAL 등급 데이터를 처리하는 ICT 시스템을 다루는 경우 인증을 요구합니다.

ISO/IEC 27001

ISO/IEC 27001은 ISO와 IEC가 발행하는 정보보안 관리체계의 국제 표준입니다. 현행 판은 ISO/IEC 27001:2022이고, 2024년의 개정 1호가 ISO 관리체계 표준 전반에 적용된 변경에 맞춰 조직 상황 관련 조항에 기후 행동 문구를 추가했습니다.

이것은 관리체계 표준이고, 구매자가 잘못 읽는 지점이 바로 그것입니다. 인증받은 모든 조직이 구현한 고정된 통제 집합을 규정하지 않습니다. 조직이 자기 범위를 정의하고, 위험을 평가하고, 통제를 선택하고, 문서화된 검토와 개선의 주기를 돌릴 것을 요구합니다. 인증서는 ISO 자신이 아니라 인정받은 인증 기관이 감사 후에 발급합니다.

그러므로 쓸모 있는 질문은 공급자가 그것을 갖고 있느냐가 아니라, 인증서에 적힌 범위 진술이 무엇을 덮고 있느냐입니다. 본사 기능에 한정된 범위는 여러분의 소스 코드와 운영 자격 증명을 쥔 팀에 대해 아무것도 말해주지 않습니다. 인증서를 요구하고 그 범위를 읽으십시오.

SOC 2

SOC 2는 미국 것이고 종류가 다릅니다. AICPA는 그것을 “보안, 가용성, 처리 무결성, 기밀성 또는 프라이버시와 관련된 서비스 조직의 통제에 관한 보고서"로 정의하며, 자체 신뢰 서비스 기준에 따라 수행됩니다. 이것은 회계법인이 작성하는 인증 보고서이지 증명서가 아니고, 합격선도 내걸 로고도 없습니다.

중요한 구분은 유형입니다. Type 1 보고서는 통제를 기술하고 특정 시점에 그것이 적절히 설계되었는지를 평가합니다. Type 2 보고서는 통상 6개월이나 12개월의 기간에 걸쳐 그것이 효과적으로 운영되었는지를 시험합니다. Type 1은 사진이고 Type 2는 영상이며, Type 1을 동등한 것으로 받아들이는 구매자는 자기 생각보다 훨씬 적은 것을 받고 있습니다.

표지가 아니라 보고서를 읽으십시오. 감사인이 기술된 대로 운영되지 않은 통제를 기록하는 예외 절에 정보가 있고, 그곳이 바로 공급자가 여러분이 건너뛰기를 바라는 부분입니다.

그중 어느 것도 증명하지 못하는 것

셋 중 어느 것도 여러분의 소프트웨어가 안전하다고 증명하지 않습니다. Cyber Essentials는 인프라 위생의 기준선을 다룹니다. ISO 27001은 조직이 보안을 하나의 과정으로 관리하는지를 다룹니다. SOC 2는 표명된 통제가 일정 기간 운영되었는지를 다룹니다. 셋 다 제품이 아니라 공급자에 관한 것입니다.

애플리케이션 보안은 별개의 분야이고 증거도 별개입니다. 인증서 벽이 아니라 최근 모의 침투 테스트 보고서와 그 조치 상태를 요구하고, 누가 어떤 범위로 수행했는지 확인하십시오. 그것이 저희 모의 침투 테스트 서비스의 실체입니다.

업종별 규제 노출

일반적인 엔터프라이즈 조언이 위험해지는 지점이 규제입니다. 아래는 검증 가능한 의무를 짚는 데서 그치고 법률 자문에는 이르지 않으며, 그것은 자격 있는 자문가에게 받으셔야 합니다.

거의 모두에게 적용되는 영국 GDPR

시스템이 개인 데이터를 다룬다면 영국 GDPR 제32조가 컨트롤러와 프로세서 양쪽에 적용됩니다. 적절한 기술적, 조직적 조치를 요구하며 네 가지를 명시합니다. 가명 처리와 암호화, 처리 시스템의 지속적인 기밀성, 무결성, 가용성과 복원력, 사고 후 개인 데이터의 가용성과 접근을 적시에 복구할 수 있는 능력, 그리고 그 조치들의 효과성을 정기적으로 시험하고 평가하는 절차입니다.

그중 셋째를 다시 읽으십시오. 그것이 재해 복구를 운영상의 선호가 아니라 개인정보 보호 의무로 만들기 때문입니다. ICO의 데이터 보안 지침은 Cyber Essentials를 쓸모 있는 기준선으로 가리키면서도, 그것이 기본적인 통제 묶음일 뿐이며 모든 조직의 상황이나 모든 처리 활동의 위험을 다루지는 못한다고 분명히 말합니다.

금융과 보건, 짧고 조심스럽게

금융 서비스에서는 FCA의 운영 복원력 체계가 적용 대상 회사에 중요 업무 서비스를 식별하고, 그에 대한 영향 허용 한도를 설정하고, 심각하지만 있을 법한 중단 동안 그 한도 안에 머무를 수 있을 것을 요구합니다. 전환 기간은 2025년 3월 31일에 끝났으므로 의무는 살아 있고, 그 회사들에 납품하는 공급자가 무엇을 증거로 내야 하는지를 규정합니다.

보건과 돌봄에서는 보건 IT 시스템이 NHS England의 임상 위험 관리 표준에 걸립니다. 제조자를 위한 DCB0129와 그것을 도입하는 조직을 위한 DCB0160입니다. 둘 다 국가 차원의 검토 중이고 2026년 6월 29일부터 2026년 9월 11일까지 공개 자문이 진행되므로, 이 글을 포함한 어떤 요약에 기대기 전에 현재 상태를 확인하십시오.

여러분의 업종이 여기 없다면 의무를 일반적으로 다루십시오. 규제 기관을 찾아내고, 그 기관이 직접 공표한 요구사항을 읽고, 일반적인 보증 서사가 아니라 그 요구사항에 대해 공급자가 증거를 내게 하는 것입니다.

돈이 사라지는 곳은 연동 아키텍처

엔터프라이즈 비용은 시스템 내부가 아니라 시스템 사이의 이음매에 몰립니다. 기능은 대개 잘 이해되어 있습니다. 데이터 모델도 다르고 고객이라는 개념도 다른 여섯 시스템을 합의하게 만드는 데서 일정이 사라집니다.

점대점이냐 브로커냐

점대점이 기본이 되는 것은 첫 번째 연동이 실제로 그렇게 하는 편이 더 간단하기 때문입니다. 비용은 조합적으로 늘어납니다. n개의 시스템이 직접 대화하면 연결은 n의 제곱을 향해 가고, 각각에 고유한 재시도 로직과 자격 증명과 모니터링이 붙습니다. 네 개일 때는 괜찮습니다. 열다섯 개면 유지할 수 없습니다.

브로커나 이벤트 버스는 그 곡선을 뒤집습니다. 구성 요소 하나와 운영 부담, 그리고 설계로 우회해야 할 단일 장애점을 더하고, 대체로 여섯 번째나 여덟 번째 참여자쯤에서 본전을 뽑습니다. 실수는 양방향으로 일어납니다. 작은 환경은 필요 없는 연동 플랫폼을 사고, 큰 환경은 그물이 굳을 때까지 도입을 미룹니다.

동기냐 이벤트 기반이냐

동기 호출은 따라가기 쉽고, 가용성을 결합시킵니다. 여러분의 서비스가 네 시스템을 인라인으로 호출하고 각각이 99.9% 가동한다면, 버그를 하나도 쓰지 않은 상태에서 여러분 자신의 상한은 대략 99.6%입니다. 모든 동기 의존은 자기 가동률의 한 몫을 남의 운영 팀에 넘기는 일입니다.

이벤트 기반 설계는 그것을 분리하지만, 최종 일관성과 훨씬 어려운 디버깅이라는 대가를 치릅니다. 동기 호출은 사용자가 기다리고 있고 오래된 답이 용납되지 않는 경로에만 두고, 나머지는 전부 이벤트로 옮기십시오. 이것은 집안 규칙이 아니라 상호작용마다 결정할 일입니다.

멱등성, 재처리, 대사

분산 시스템은 메시지를 두 번 넘게 전달하고 가끔 잃어버리므로, 경계를 넘는 모든 쓰기 경로는 반복해도 안전해야 합니다. 정착된 방식은 클라이언트가 생성하는 멱등 키입니다. Stripe의 구현은 어떤 키에 대한 첫 요청의 상태 코드와 본문을 저장하고, 재시도에는 같은 결과를 돌려주며, 최소 24시간이 지난 뒤 키를 정리하고, 같은 키가 다른 파라미터로 오면 오류를 냅니다.

재처리는 같은 발상의 운영 쪽 절반입니다. 하류 시스템이 여섯 시간 동안 사용 불가였던 뒤에는 누군가 놓친 메시지를 밀어 넣어야 하고, 그것이 안전하려면 소비자가 멱등이고 메시지가 보관되어 있어야 합니다. 보관 기간과 재처리 장치를 정상 경로와 나란히 설계하십시오. 나중에 덧붙이면 모든 소비자를 고쳐야 하기 때문입니다.

대사는 뒷일로 취급되곤 하지만 그래서는 안 됩니다. 그것은 서로 일치해야 하는 두 시스템의 상태를 비교하고, 차이를 보고하고, 그것을 바로잡거나 사람에게 올리는 예약 작업입니다. 그것이 없으면 재무 시스템과의 조용한 어긋남을 몇 달 뒤 감사인이 찾아냅니다. 마지막에 누군가 쓰는 스크립트가 아니라, 담당자와 경보 경로를 가진 일급 산출물로 예산에 넣으십시오.

레거시 공존과 스트랭글러 피그

돌아가는 시스템을 통째로 교체하는 것은 선택지 가운데 위험이 가장 크고, 그래야 할 때보다 훨씬 자주 선택됩니다. 점진적 대안은 Microsoft가 스트랭글러 피그 패턴으로 문서화했습니다. 레거시 시스템 앞에 파사드를 두고 요청을 그리로 통과시킨 뒤, 기능을 한 조각씩 옮겨 옛 시스템에 남는 트래픽이 없어지면 끄는 방식입니다.

각 증분은 따로 가치가 있고 따로 되돌릴 수 있습니다. 세 번째 조각이 잘못되면 그것만 도로 돌리면 됩니다. Microsoft는 적용되지 않는 경우도 분명히 밝힙니다. 백엔드로 가는 요청을 가로챌 수 없을 때, 레거시 소스를 수정할 수 없을 때, 또는 시스템이 통째로 바꾸는 편이 쉬울 만큼 작을 때입니다.

두 가지 세부가 성패를 가릅니다. 파사드는 병목이나 단일 장애점이 되어서는 안 되므로, 뒤에 있는 서비스와 같은 수준의 가용성 설계가 필요합니다. 그리고 전환 기간의 시스템 간 호출에는 부패 방지 계층이 필요합니다. 레거시 의미론이 새 설계로 새어 들지 않게 하기 위해서입니다. 트래픽보다 데이터가 더 어렵습니다. 한 도메인의 테이블을 빼내려면 초기 적재, 변경 데이터 캡처 피드, 양쪽 저장소에 함께 쓰고 비교하는 검증 기간이 필요하고, 그다음에야 전환이며, 레거시 객체를 지우기 전까지는 롤백이 가능합니다.

엔터프라이즈 규모의 테스트

엔터프라이즈 프로그램의 테스트는 공학 문제인 만큼이나 물류 문제이고, 낙관적인 계획이 죽는 자리입니다.

환경

예산에 잡은 것보다 더 필요합니다. 개발, 상대방 샌드박스에 연결된 통합 환경, 숫자에 의미가 생길 만큼 운영에 가까운 성능 환경, 바쁜 비기술 인력이 쓸 수 있을 만큼 안정된 인수 환경, 그리고 운영입니다. 각각에 인프라 비용과 갱신 절차와 담당자가 붙습니다. 늘 밀려나는 것은 성능 환경이고, 그것을 건너뛴다는 말은 운영에서 부하 테스트를 한다는 뜻입니다.

테스트 데이터와 개인 데이터 문제

엔터프라이즈 시스템은 현실적인 데이터로 테스트해야 하고, 그 현실적인 데이터는 개인정보가 들어 있는 운영 데이터입니다. 그것을 테스트 환경으로 복사하는 것은 영국 GDPR 아래의 처리이고, GDPR Article 32의 의무가 거기까지 따라옵니다. 접근 통제와 그것을 담고 있는 환경의 보안도 포함해서입니다.

방어할 수 있는 답은 둘입니다. 데이터를 규제 밖으로 내보내려면 되돌릴 수 없어야 하는 익명화, 그리고 위험은 낮추지만 여전히 적용 범위에 남는 가명 처리입니다. 둘 다 데이터를 쓸모 있게 만드는 통계적 형태를 보존하는 엔지니어링 작업과 문서화된 절차를 필요로 합니다. 운영 데이터베이스를 공유 테스트 환경에 복원하는 일은 흔하고, 많은 구성에서 위법이며, 공급자 평가가 바로 그것을 드러내려고 설계된 행위입니다.

성능 테스트

성능 테스트는 앞서 합의한 처리량과 지연 숫자를 시스템이 충족하는지에 답하므로, 그 숫자가 적혀 있어야만 존재할 수 있습니다. 평균이 아니라 최대 프로파일을 시험하고, 최대치의 모양도 포함하십시오. 10분에 걸쳐 올라가는 것과 1초에 계단처럼 뛰는 것은 서로 다른 실패 양상을 끌어내기 때문입니다.

운영 수준의 데이터 양에 대고 돌리십시오. 10,000행에서는 즉시이고 4,000만 행에서는 쓸 수 없는 쿼리는 엔터프라이즈 소프트웨어에서 가장 흔한 성능 결함이고, 작은 데이터셋에서는 보이지 않습니다.

본업이 따로 있는 사람들이 하는 인수 테스트

사용자 인수 테스트는 2주 창으로 잡히고, 가장 확실하게 초과하는 단계입니다. 테스터가 곧 업무 전문가인데 업무는 여전히 그들을 필요로 하기 때문입니다. 그들은 주에 몇 시간을 내줄 것이고, 월말이면 그 여유가 사라집니다.

테스터를 계약에 이름으로 넣고, 주당 시간을 합의하고, 탐색을 부탁하는 대신 시나리오를 미리 대본으로 만들고, 결함 분류는 티켓 큐가 아니라 합동 세션으로 진행하십시오. 참여자 이름 없이 2주 인수 테스트를 견적하는 공급자는 그것을 운영해본 적이 없습니다.

인도 모델과 거버넌스

통하는 팀 형태는 크고 교체되는 쪽이 아니라 작고 안정적인 쪽입니다. 프로그램 전체의 아키텍처를 책임지는 기술 리드, 세 명에서 여섯 명의 엔지니어, 상대방 일정을 다루는 인도 리드, 그리고 품질 엔지니어와 인프라 전문가에 대한 공동 접근입니다. 진행 중에 사람을 더하면 어김없이 느려집니다. 제약은 손이 아니라 맥락이기 때문입니다.

첫 스프린트 전에 의사결정의 주인을 적어두십시오. 범위 변경을 승인할 수 있는 사람, 아키텍처 절충을 승인할 수 있는 사람, 릴리스를 수용할 수 있는 사람을 각각 한 명씩 지명하십시오. 그것이 세 사람 이름이면 결정은 며칠이 걸립니다. 위원회라면 몇 주가 걸리고 계획은 허구가 됩니다.

긴 프로그램을 정직하게 유지하는 것은 회의 주기입니다. 격주로 실무 그룹과 인도 검토, 월별로 예산 보유자와 거부권 보유자를 한 방에 모으는 운영 회의, 그리고 지난달의 수정본이 아니라 원래 기준선에 대비한 서면 상태 보고입니다. 상태가 영원히 초록인 공급자는 위험을 관리하는 것이 아니라 감추는 중입니다.

상업 모델과 위험을 지는 쪽

네 가지 모델이 거의 전부를 덮고, 각각 위험을 다른 곳에 둡니다. 질문은 무엇이 최선인가가 아니라 눈앞의 불확실성을 어느 쪽이 감당하기에 더 적합한가입니다.

실비 정산은 정말로 불확실한 일에 맞습니다. 조사, 레거시 고고학, 또는 문서가 부실한 상대방을 향한 연동 같은 일입니다. 구매자가 위험을 지고 완전한 유연성을 얻습니다. 여기에는 신뢰와, 실제로 누군가 지켜보는 소진 속도가 필요합니다.

상한이 있는 실비 정산은 천장을 더한 것이고 대개 합리적인 절충입니다. 저희 소프트웨어 개발 서비스 대부분도 이렇게 구성합니다. 상한을 넘는 초과는 공급자가 흡수하고, 구매자는 상한 아래에서는 쓴 만큼만 내며, 양쪽 다 범위를 정직하게 유지합니다. 상한에는 15에서 25퍼센트의 예비를 넣으십시오. 기대 비용에 딱 맞춰 상한을 잡는 공급자는 잘못 계산했거나 변경 요청을 계획하고 있습니다.

고정 가격은 범위가 정말로 고정된 경우에만 통하고, 엔터프라이즈 프로그램에서 그것은 전체가 아니라 하나의 증분에 대해 참입니다. 6주에서 10주짜리 고정 가격 증분을, 앞 증분이 착지한 뒤에 다음 범위를 잡는 방식으로 하면, 열여덟 달 앞을 누군가 명세할 수 있는 척하지 않고도 예산 확실성을 얻습니다.

매니지드 서비스는 시스템이 가동된 뒤의 올바른 형태입니다. 지원, 패치, 모니터링, 정해진 변경 허용량을 담은 월 정액을, 인원수가 아니라 구축 비용에 대한 연간 비율로 값 매깁니다. 서비스 정의에 응답 시간과 에스컬레이션 경로를 적게 하십시오.

엔터프라이즈 소프트웨어 개발 서비스: 무엇이 비용을 만드는가

영향이 큰 순서로 본 비용 요인

이 순서는 사람들을 놀라게 합니다. 기능이 맨 뒤이기 때문입니다. 첫째는 연동 범위, 구체적으로는 엔드포인트 수가 아니라 외부 소유자의 수입니다. 둘째는 비기능 목표입니다. 유지보수 시간대를 쓸 수 있는 서비스에서 쓸 수 없는 서비스로 넘어가는 한 걸음이 설계의 모든 층을 바꾸기 때문입니다.

셋째는 보증과 규제 부담입니다. 입찰 시간, 증거 생산, 감사 대응, 그리고 계약 기간 내내 느려지는 릴리스 절차입니다. 넷째는 데이터 이관과 대사이고, 어려움이 양이 아니라 옛 데이터의 품질에 있어 한결같이 과소평가됩니다. 다섯째는 이해관계자 집단의 수이고, 그것이 의사결정 지연을 정합니다. 여섯째는 환경의 개수입니다. 기능 범위는 일곱째이고, 그것이 보통 원래 예산에 들어 있는 유일한 항목입니다.

영국의 참고 가격대

아래 구간은 영국 프로젝트에서 얻은 저희 자체 추정이며, 조사와 구축과 테스트와 오픈을 포함하되 구매자 자신의 인력 시간은 제외한 첫해 비용으로 표시했습니다. 견적서가 아니라 참고이고, 위 요인들이 움직이기 때문에 폭이 넓습니다.

표 없이 말하면, 연동 두세 개에 사내 사용자, 목표 99.5%인 단일 서비스는 첫해에 GBP 120,000에서 GBP 250,000 사이에 놓입니다. 연동 다섯에서 여덟 개에 99.9%인 고객 대면 부서 시스템은 GBP 300,000에서 GBP 700,000입니다. 연동 열에서 스무 개에 목표 99.95%인, 레거시를 대체하는 핵심 플랫폼은 GBP 900,000에서 GBP 250만입니다. 99.99%인 다수 법인 규제 프로그램은 GBP 250만 언저리에서 시작해 위로 올라갑니다.

예산에 없는 운영 비용

그 위에 연간 운영 비용을 더하십시오. 지원, 호스팅, 패치, 보안 작업, 그리고 적당한 변경 허용량을 넣으면 구축 비용의 연 15에서 25퍼센트 사이에 놓입니다. 구축에는 돈을 대고 운영에는 대지 않는 예산은 둘째 해에 눈에 띄게 낡아가는 시스템을 만들고, 저희 소프트웨어 유지보수 비용 분석이 그 돈이 어디로 가는지 설명합니다.

종료와 연속성

떠날 수 없는 공급자는 대차대조표에 얹힌 위험이고, 아무도 주의를 기울이지 않는 협상 막바지까지 가장 자주 미뤄지는 조항입니다. 종료를 가능하게 하는 것은 네 가지입니다.

소스 코드와 그 이력은 구매자가 소유하거나 통지로 넘겨받을 수 있는 저장소에, 빌드 파이프라인 및 인프라 정의와 함께 있어야 합니다. 그것을 빌드하는 파이프라인 없는 코드는 동작하는 자산이 아니라 보관물입니다.

문서는 유능한 제3자가 시스템을 운영할 수 있을 정도여야 합니다. 아키텍처, 연동 계약, 실제로 일어난 적 있는 장애 유형에 대한 런북, 그리고 자격 증명 목록입니다. 읽히는 기술 문서에 관한 글에서 인수인계를 살아남는 것이 무엇인지 다뤘습니다.

에스크로는 공급자가 떠나는 경우가 아니라 무너지는 경우에 대비하는 것으로, 소스를 제3자에게 맡겨두고 정해진 조건에서 공개하게 합니다. 계약 규모에 비해 공급자가 작을 때 가질 만하고, 꼼꼼히 읽을 만합니다. 검증되지 않은 예치는 빌드되지 않는 코드를 공개하기 때문입니다. 그것이 정당화되는 때는 소프트웨어 에스크로, 정말 누구에게 필요한가에서 살펴봤습니다.

마지막으로 인수인계에 계약상 값을 매기십시오. 합의된 요율로 정해진 일수의 지식 이전을, 통지로 발동되게 해두면 다툼이 청구서가 됩니다. 같은 규율이 여러분의 공급자의 공급자에게도 적용되고, 저희 소프트웨어 공급망 보안 메모에서 다뤘습니다.

한 번의 미팅으로 공급자의 엔터프라이즈 역량 가려내기

다섯 가지 질문이면 한 시간 안에 대부분이 드러나고, 망설임이 답만큼이나 많은 것을 알려줍니다.

어떤 가용성과 복구 목표에 대해 인도해봤는지, 가용성을 어떻게 측정했는지 물으십시오. 99.95% 의무를 져본 공급자는 묻지 않아도 측정 지점과 당직 체계를 말합니다. 져본 적 없는 공급자는 이중화를 일반론으로 이야기합니다.

그들의 ISO 27001 인증서에 적힌 범위 진술이나 SOC 2 Type 2의 예외 절을 보여달라고 하십시오. 둘 다 그것을 보유한 공급자에게는 평범한 요청이고, 로고만 가진 공급자에게는 난처한 요청입니다. 그다음 운영에서 대사 불일치를 어떻게 처리했는지 물으십시오. 이건 이론으로 답할 수 없습니다.

최근 세 프로그램이 각각 얼마나 초과했고 왜 그랬는지 물으십시오. 누구나 초과하므로, 정보가 되는 것은 그 숫자를 알고 있느냐입니다. 그다음 종료 절차가 일수와 산출물로 어떤 모습인지 물으십시오. 그것을 적어둔 공급자는 그것으로 평가받을 것을 예상하고 있습니다.

구매자에게 남는 것

엔터프라이즈라는 단어는 가격대가 아니라 의무를 가리켜야 합니다. 연동 범위, 가용성과 복구 목표, 규제 노출, 종료 조건이 적히고 나면 후보군은 저절로 정리됩니다. 대부분의 공급자가 그 네 가지에 대해 증거를 낼 수 없기 때문입니다.

Mecanik은 이런 형태의 일을 소프트웨어 개발 서비스로, 보증 쪽은 모의 침투 테스트 서비스로 다룹니다. 후보군이 아니라 요구사항 자체를 조립하는 단계라면 기술 실사 체크리스트가 합리적인 출발점이고, 비기능 숫자부터 먼저 다투는 편이 낫습니다.

자주 묻는 질문

무엇이 엔터프라이즈 소프트웨어 개발에 해당합니까? 엔터프라이즈는 구매자의 규모가 아니라 제약으로 정의됩니다. 여러 주체가 소유한 넓은 연동 범위, 계약상의 가용성과 복구 의무, 규제 노출, 각각 릴리스를 막을 수 있는 여러 이해관계자 집단, 순진한 설계를 무너뜨리는 데이터 양, 그리고 아무도 완전히 이해하지 못하는 레거시 시스템과 공존해야 한다는 요구를 가질 때 프로젝트가 여기에 해당합니다. 큰 회사가 평범한 구축을 발주할 수도 있고, 규제를 받는 작은 회사가 진짜 엔터프라이즈 프로젝트를 발주할 수도 있습니다.

영국에서 엔터프라이즈 소프트웨어 개발 프로그램의 비용은 얼마입니까? 영국 프로젝트에서 얻은 저희 자체 추정으로, 연동 두세 개에 가용성 목표 99.5%인 단일 서비스는 첫해에 GBP 120,000에서 GBP 250,000입니다. 99.9%인 고객 대면 부서 시스템은 GBP 300,000에서 GBP 700,000입니다. 레거시를 대체하는 핵심 플랫폼은 GBP 900,000에서 GBP 250만입니다. 운영과 지원을 위해 구축 비용의 연 15에서 25퍼센트를 더하십시오.

엔터프라이즈 공급자에게 ISO 27001, Cyber Essentials, SOC 2가 필요합니까? 셋은 서로 다른 것을 증명합니다. Cyber Essentials는 영국 정부가 뒷받침하는 다섯 가지 기술 통제의 기준선이고, 독립적인 기술 감사로 검증되는 Plus 등급이 있으며 많은 공공 계약에서 PPN 014가 이를 요구합니다. ISO/IEC 27001:2022는 정보보안 관리체계를 인증하므로 인증서 자체보다 거기 적힌 범위 진술이 더 중요합니다. SOC 2는 회계법인이 작성하는 미국식 인증 보고서이고, 일정 기간 통제가 운영되었는지를 시험하는 것은 Type 2뿐입니다.

목표 복구 시점과 목표 복구 시간은 무엇입니까? 목표 복구 시점 (RPO) 은 재해 뒤 데이터를 얼마나 잃어도 받아들일 것인가이고, RPO 한 시간은 최대 한 시간 치 거래가 사라질 수 있다는 뜻입니다. 목표 복구 시간 (RTO) 은 얼마나 오래 쓸 수 없는 상태를 받아들일 것인가이고, RTO 네 시간은 서비스가 네 시간 안에 다시 트래픽을 처리해야 한다는 뜻입니다. 둘 다 백업과 복원, 파일럿 라이트, 웜 스탠바이, 다중 사이트 액티브/액티브 사이에서 선택을 강제하므로 어떤 기능보다 아키텍처와 비용을 좌우합니다.

엔터프라이즈 소프트웨어 계약에서 종료에 관해 무엇을 넣어야 합니까? 네 가지입니다. 소스 저장소와 빌드 파이프라인과 인프라 정의에 대한 소유권 또는 이전 가능한 접근권. 런북과 자격 증명 목록을 포함해, 유능한 제3자가 시스템을 운영하기에 충분한 문서. 계약 규모에 비해 공급자가 작을 때의 소스 코드 에스크로, 그것도 검증되지 않은 예치가 아니라 검증된 예치. 그리고 지식 이전의 일수와 요율을 명시한, 값이 매겨진 인수인계 조항입니다. 떠나는 일이 분쟁이 아니라 청구서가 되게 하기 위해서입니다.