기술 실사는 코드 품질을 겨루는 대회가 아니며, 실사를 준비하는 팀은 대개 엉뚱한 곳에 시간을 쏟습니다. 회사를 인수하려는 사람 중에 당신이 만든 추상화에 점수를 매기려는 사람은 없습니다. 인수자는 이 시스템을 소유하는 데 얼마가 들지, 그리고 돈이 오간 뒤에 상황이 얼마나 나빠질 수 있는지를 계산하려는 것입니다.

이렇게 질문을 다시 세우는 일이 중요한 이유는, 무엇부터 손봐야 하는지가 달라지기 때문입니다. 보기에 지저분해도 돌아가고, 팀이 이해하고 있으며, 안전하게 바꿀 수 있는 코드는 사소한 지적에 그칩니다. 반대로 우아하지만 단 한 사람만 이해하는 코드는 심각한 지적이며, 가격을 움직이는 쪽은 언제나 두 번째 경우입니다.

모든 질문 뒤에 있는 진짜 질문: 창업 엔지니어가 거래 종결 다음 주에 회사를 떠난다면, 이 시스템은 계속 돌아가고 계속 바뀔 수 있습니까? 제안 금액을 낮추는 지적은 거의 전부 이 질문에 대한 구체적인 답변입니다. 한 사람의 머릿속에 몰린 지식, 문서로 남지 않은 배포 절차, 아무도 확인하지 않은 라이선스, 특정 개인의 기억에만 존재하는 접속 정보가 그것입니다.

기술 실사가 실제로 평가하는 것

네 가지 위험이 있으며, 대체로 기업 가치에 영향을 주는 순서대로 나열하면 다음과 같습니다.

핵심 인력 의존 위험. 시스템이 문서화된 절차가 아니라 특정 개인에게 의존하는지를 봅니다. 이것은 일관되게 가장 큰 손해를 부르는 지적입니다. 사후에 고치기가 가장 어렵고, 인수 대상 그 자체를 직접 위협하기 때문입니다.

계속 운영하는 비용. 시스템을 계속 돌리고 발전시키는 데 무엇이 필요한지를 봅니다. 인프라 지출, 라이선스 의무, 필요한 팀의 규모, 그리고 로드맵 가운데 새로운 작업이 아니라 유지보수에 잡아먹힐 비중이 여기에 들어갑니다.

법적 책임. 상업적 이용과 충돌하는 라이선스, 민원이 제기되면 버티지 못할 방식으로 다뤄지는 개인정보, 보안상의 노출, 그리고 회사가 실제로는 지키지 못하고 있는 규제 의무가 모두 포함됩니다.

변경 가능성. 새로운 기능을 예측 가능한 속도로 내보낼 수 있는지, 아니면 모든 변경이 전혀 상관없는 부분을 망가뜨릴 위험을 안고 있는지를 봅니다.

코드 품질은 오직 네 번째 항목을 통해서만 의미를 가집니다. 검토자가 창업자의 예상보다 코드를 읽는 데 시간을 적게 쓰고, 배포가 어떻게 이뤄지는지 묻는 데 시간을 더 쓰는 이유가 바로 여기에 있습니다.

가격을 낮추는 지적들

한 사람 말고는 아무도 배포하지 못한다. 누군가의 머릿속이나 그 사람의 노트북에만 존재하는 릴리스 절차는, 오늘 아무리 잘 돌아가더라도 심각한 운영 위험으로 취급됩니다.

중요한 경로에 테스트가 없다. 검토자가 대체로 무시하는 커버리지 수치를 말하는 것이 아니라, 시스템을 조금이라도 확신을 갖고 바꿀 수 있는지를 말합니다. 매출이 흐르는 경로 주변에 테스트가 없는 코드베이스는 더 느린 로드맵을 가격에 반영시킵니다. 소프트웨어 테스트 전략 가이드에서 실제로 값을 하는 테스트가 무엇인지 다뤘습니다.

라이선스 오염. 독점 제품 안에 들어간 카피레프트 코드는 거래를 다시 값 매기는 데 그치지 않고 아예 중단시킬 수 있는 몇 안 되는 지적이며, 보통 스캐너가 몇 분 만에 찾아냅니다.

방어할 근거가 없는 개인정보. 명확한 적법 근거 없이 수집했거나, 기한 없이 보관하고 있거나, 회사가 목록조차 만들지 못하는 곳에 보관 중인 데이터입니다. GDPR 기술적 준수 에서 다룬 작동 방식이 검토자가 확인하는 바로 그 지점입니다.

개인이나 공급업체에 대한 문서화되지 않은 의존. 계약이 없는 공급업체와의 핵심 연동, 또는 개인 계정에 올라가 있는 인프라는 둘 다 관리되지 않는 위험으로 읽힙니다.

기본적인 보안이 빠져 있다. 모의 침투 결과가 아니라, 비밀 키가 버전 관리 시스템에 들어 있는지, 사람이 떠날 때 권한이 회수되는지, 지금 이 순간 패치되지 않은 채 인터넷에 노출된 것이 있는지를 봅니다.

검토자가 신경 쓰지 않는 것

준비에 쓸 수 있는 시간이 한정되어 있고 대개 잘못 쓰이기 때문에 짚어둘 필요가 있습니다.

어떤 프레임워크를 골랐는지는 사람을 채용할 수 있는 한 아무도 신경 쓰지 않습니다. 아키텍처 유행도 마찬가지입니다. 제품을 계속 내보내고 있는 모놀리스는 지적 사항이 아닙니다. 코드 스타일이나 이름 짓기, 인터넷의 누군가가 권하는 패턴이 없다는 사실도 마찬가지입니다.

기술 부채가 0이기를 기대하지도 않습니다. 어느 회사에나 있고 존재 자체는 정상입니다. 중요한 것은 팀이 그것이 어디에 있는지 알고 있으며 그 비용을 설명할 수 있는가입니다. 자신이 아는 문제를 명확한 목록으로 내놓는 팀은 유능하게 읽힙니다. 문제가 하나도 없다고 주장하는 팀은 상황을 모르는 팀으로 읽히고, 그러면 검토자가 혼자 찾아내야 하므로 시간이 더 걸리고 보고서도 더 나빠집니다.

아무것도 다시 쓰지 않고 준비하기

도움이 되는 일의 대부분은 몇 달이 아니라 며칠이면 되고, 그중 무엇도 아키텍처를 건드리지 않습니다.

배포 방법을 적어 두십시오. 빈 서버에서 시작해 시스템이 돌아가기까지의 과정을 적으면 됩니다. 이 문서 하나가 가장 손해가 큰 지적 범주를 정면으로 다루며, 하루 오후면 씁니다.

의존성과 그 라이선스를 목록으로 만드십시오. 자동화 도구가 금방 만들어 주며, 검토자보다 먼저 답을 알고 있다는 사실이 결과가 깨끗하다는 사실보다 훨씬 값집니다.

비밀 키를 버전 관리에서 빼내고 누가 무엇에 접근할 수 있는지 목록을 만드십시오. 그런 다음 회사를 떠난 사람의 접근 권한을 모두 회수하십시오.

잘못되어 있다고 아는 것을 문서로 남기십시오. 알려진 문제와 대략적인 수정 비용을 담은 짧고 솔직한 대장이면 충분합니다. 이것을 먼저 내미는 행동은 검토의 어조를 확실히 좋게 만드는 몇 안 되는 방법입니다.

인프라가 개인 계정이 아니라 회사 소유인지 확인하십시오. 도메인과 인증서, 저장소까지 모두 법인의 통제 아래 있어야 합니다.

지적 사항은 어떻게 처리되는가

지적이 거래를 깨뜨리는 일은 드뭅니다. 지적은 조건이 됩니다.

지적은 보통 세 가지 결과 가운데 하나로 정리됩니다. 수정 비용을 반영한 가격 조정, 계약서에 들어가는 진술보장이나 면책 조항, 또는 거래 종결 전에 충족해야 하는 선행 조건입니다. 거래를 아예 무산시키는 경우는 라이선스 오염과 방치된 중대한 개인정보 노출 정도로 한정됩니다.

그러니 현실적인 목표는 완벽한 시스템이 아닙니다. 문제가 무엇인지 알려져 있고, 범위가 정해져 있으며, 말로 설명할 수 있는 시스템입니다. 수치로 표현된 문제는 가격에 반영되지만, 수치로 표현되지 않은 문제는 실제보다 더 나쁠 것이라고 가정되기 때문입니다.

Mecanik은 소프트웨어 개발 업무의 일부로 이런 기술 검토를 수행하며, 대개 인수자 쪽에서 일합니다. 패턴은 늘 같습니다. 검토를 잘 통과하는 시스템은 정교한 시스템이 아니라, 누군가가 기록을 남겨 둔 시스템입니다.

관련 게시물: 소프트웨어 에스크로: 정말 필요한 곳은 어디인가 , 영국 핀테크 소프트웨어 개발: FCA, 결제 레일, 비용 , 고정가 계약과 시간 및 자재 계약 중 무엇을 고를까? 그리고 영국 맞춤형 소프트웨어 개발: 구매자를 위한 완전 가이드 .

자주 묻는 질문

기술 실사란 무엇인가요? 소프트웨어 시스템을 소유하는 데 얼마가 들지, 그리고 인수나 투자 이후에 상황이 얼마나 나빠질 수 있는지를 평가하는 작업입니다. 코드 품질 자체에 점수를 매기는 것이 아니라 핵심 인력 의존 위험, 계속 운영하는 비용, 법적 책임, 그리고 시스템을 계속 바꿔 나갈 수 있는 능력을 살펴봅니다.

가격을 가장 많이 낮추는 지적은 무엇인가요? 지식이 특정 개인에게 몰려 있는 상태, 특히 단 한 사람만 수행할 수 있는 배포 절차입니다. 그다음은 매출 경로에 의미 있는 테스트가 없는 경우, 독점 제품 안에 들어간 카피레프트 코드로 인한 라이선스 오염, 방어할 적법 근거가 없는 개인정보, 그리고 버전 관리에 커밋된 비밀 키입니다.

검토자가 우리 기술 부채를 문제 삼나요? 기술 부채가 있을 것이라고 이미 예상합니다. 어느 회사에나 있고 존재 자체는 지적 사항이 아닙니다. 중요한 것은 팀이 그것이 어디에 있는지 알고 있으며 고치는 비용을 설명할 수 있는가입니다. 알려진 문제를 정리한 명확한 대장은 역량으로 읽히고, 문제가 없다는 주장은 인식 부족으로 읽혀 검토 결과를 나쁘게 만듭니다.

기술 실사는 어떻게 준비하나요? 빈 서버에서 시스템을 띄우는 방법을 적고, 의존성과 라이선스를 목록으로 만들고, 비밀 키를 버전 관리에서 제거하고, 아직 접근 권한을 가진 사람이 누구인지 확인하고, 인프라와 도메인이 개인이 아니라 회사 소유인지 확인한 뒤, 알려진 문제와 대략적인 수정 비용을 담은 솔직한 대장을 만드십시오.

기술적 지적 하나가 거래를 완전히 무산시킬 수 있나요? 드뭅니다. 대부분의 지적은 가격 조정, 계약서상의 보장 조항, 또는 거래 종결 전에 충족해야 할 조건으로 바뀝니다. 실제로 거래를 중단시키는 예외는 독점 제품 안의 카피레프트 라이선스 오염과 방치된 중대한 개인정보 보호 노출입니다.