3년 차에 누가 패치하는지 물어라 - 만드는 비용이 싸져도 가진 비용은 그대로다

3년 차에 누가 패치하는지 물어라

TL;DR

• 자기 실패에서 시작하는데 초기 B2B 스타트업에서 벤더 솔루션을 사는 대신 잘 알려진 오픈소스 컴포넌트 위에 인증을 만드는 것을 승인했고, 특이한 요구사항 때문에 필요한 확장은 약 일주일이면 된다고 했다. 결산은 달랐다. 일주일 추정은 대략 맞았지만 그 뒤에 온 것은 아니었고, 라이선스에 쓰지 않은 돈이 엔지니어링 시간과 출시하지 못한 기능, 내 캘린더로 돌아와 결국 본전이었다
• 결말은 30일 차이로 갈렸는데 퇴사 뒤 회사는 벤더 솔루션으로 옮겼고 약 한 달 뒤 그 오픈소스 컴포넌트에 심각한 취약점이 있었으며 그것을 돌리던 여러 사이트가 침해되었다. 그래서 교훈이 남는다. 대략 30일 차이로 비켜갔는데, 운이 좋았던 것과 옳았던 것은 같지 않고 그때는 그 차이를 알 수 없었다
• 핵심 명제는 두 비용의 분리인데 AI는 만드는 비용인 첫 번째 비용을 붕괴시켰지만 만들어 놓은 것을 가진 비용인 두 번째는 늘 그랬던 것과 거의 같다. 이유가 구조적이다. 벤더는 사업이 달려 있으므로 계속 갱신하지만 내부 도구는 누군가 하던 일을 멈추고 갱신할 때 갱신되며, AI가 돕더라도 누군가 CVE를 알아채고 그것이 중요하다고 판단하고 결과를 책임지는 부분은 없어지지 않는다
• 네 가지 질문으로 정리되는데 폭발 반경은 실패하거나 침해되면 무엇이 멈추는지 묻고, 소유 비용은 향후 몇 년간 누가 감시하고 패치하고 새벽 두 시에 답하는지를 팀이 아니라 사람 이름으로 묻는다. 이유가 한 문장인데 팀은 호출되지 않기 때문이다. 나머지 둘은 차별성과 탈출 경로이고 회의에 한 가지만 가져간다면 3년 차에 누가 패치하는지를 묻는다
• 같은 판단이 채용으로 확장되는데 차별적이지도 사업에 결정적이지도 않은 역량이라면 이제 사람 대신 에이전트로 상당 부분을 덮을 수 있고 비차별적이란 잘 이해되고 널리 알려졌다는 뜻이라 정확히 에이전트가 잘 다루는 것이다. 성격은 그대로다. 전통적 의미로 아무것도 구매되지 않지만 이것은 구매 결정이며, 계약 대신 토큰에 쓰는 것도 여전히 무언가를 영구히 소유하기로 선택하는 일이다

Source

Build vs Buy When Building Just Got Cheap — Kevin Goldsmith, 「It Depends: Lessons in Technology Leadership」, 2026년 8월 23일

[kevingoldsmith.substack.com/p/build-vs-buy-when-building-just-got](https://kevingoldsmith.substack.com/p/build-vs-buy-when-building-just-got)

Knowledge

일주일 추정은 맞았고 그 뒤가 틀렸다

초기 단계 B2B 스타트업에서 벤더 솔루션을 사는 대신 잘 알려진 오픈소스 컴포넌트 위에 인증을 만드는 것을 승인했다. 당시 근거는 이랬다. 돈이 많지 않았고 복잡한 것을 만들고 있었고 절약할 모든 기회를 찾고 있었다. 인증 벤더는 비쌌고 리드 개발자는 확신했고 그 오픈소스 프로젝트는 견고했다. 몇 가지 특이한 요구사항이 있어서 확장이 필요했는데, 그 확장이 약 일주일 걸릴 것이라고 했다. 일주일 추정은 대략 맞았다. 그 뒤에 온 것은 아니었다.

한동안은 잘 작동했고 초기 고객들도 괜찮았다. 그다음 유지보수가 시작됐다. 인증은 흔한 공격 벡터이므로 기반 프로젝트가 끊임없이 업데이트를 내놓았고 그 모든 것에 맞춰 속도를 유지해야 했다. 고객들은 벤더라면 기본으로 제공할 기능을 요청했고 그것도 직접 만들어야 했다. 예상 못 한 비용도 붙었다. 기업에 판매하고 있었으므로 자체 제작 인증이 왜 신뢰할 만한지 잠재 고객에게 설명하는 보안 리뷰에 실제 시간을 썼다. 그것은 그들이 이미 신뢰하는 벤더의 이름을 대는 것보다 훨씬 어려운 대화다.

결산은 이랬다. 라이선스에 쓰지 않은 돈이 엔지니어링 시간과 출시하지 못한 기능, 그리고 내 캘린더로 돌아왔다. 본전이었다.

30일 차이

내가 떠난 뒤 회사는 벤더 솔루션으로 옮겼다. 그 결정에 이견은 없었다. 약 한 달 뒤 그 오픈소스 컴포넌트에 심각한 취약점이 있었고 그것을 돌리던 여러 사이트가 침해되었다. 대략 30일 차이로 비켜갔다. 예상보다 그것을 더 많이 생각한다. 운이 좋았던 것과 옳았던 것은 같지 않고 그때는 그 차이를 알 수 없었기 때문이다.

절대적인 만트라는 의도된 것이었다

여러 해 동안 팀에게 한 줄을 줬다. 이미 존재하는 것을 발명하지 말자. 그것이 겨눈 논거는 개발자를 관리한다면 들어 봤을 것들이다. 이 벤더는 우리가 일하는 방식과 잘 맞지 않는다. 이 오픈소스 라이브러리는 내가 만들었을 방식이 아니다. 내가 더 나은 것을 아마 주말에 쓸 수 있고 그러면 그 물건에 돈 내는 것을 멈출 수 있다.

It Depends라는 뉴스레터를 쓰면서 절대주의적 만트라를 운영하는 것이 좀 어색하다는 것을 안다. 그런데 그 절대주의가 요점이었다. 개발자들이 아이디어를 가져오기 전에 무엇을 마주하는지 알도록 기준을 명백하게 만드는 것이 목적이었다. 그것은 우리가 그것을 하지 않겠다는 뜻이 절대 아니었고 그것을 하려면 아주 좋은 이유가 필요하다는 뜻이었다. 더 맥락적이고 합리적으로 들리게 만들었다면, 사람들은 이미 만들고 싶어 하던 것을 만들기 위한 합리적으로 들리는 변명을 찾아냈을 것이다.

실용주의의 근거는 단순하다. 엔지니어링 시간은 여전히 대부분 회사가 가진 가장 희소한 것이고 엔지니어는 소프트웨어 사업에서 가장 비싼 사람들에 속한다. 그 시간과 돈을 회사를 경쟁자와 다르게 만드는 것에 써야 한다. 자체 캐싱 계층을 쓰는 것은 거의 값어치가 없다.

진짜 이유의 기준은 이렇다. 기성품이 아무것도 당신을 서빙할 수 없는 규모에서 운영하고 있고 자체 제작이 고객이 느낄 수 있는 방식으로 실제로 제품을 더 좋게 만든다면 그것은 진짜 이유다. 반대로 정직한 답이 회사 밖의 누구도 절대 알아채지 못할 몇 가지 경우를 빼면 대체로 작동한다는 것이라면, 그것은 만들지 말아야 할 이유다. AI가 있어도 실용주의 논거는 엔지니어링 시간이 어디로 가는지에 관한 것이다.

논거를 내는 사람과 크기가 바뀌었다

바뀐 것은 개발자들이 뭔가를 만들고 싶어 한다는 사실이 아니다. 바뀐 것은 논거를 내는 사람이 누구인지와 그 물건이 얼마나 큰지다. 더 이상 로깅 라이브러리를 쓰고 싶어 하는 시니어 엔지니어가 아니다. 한 줄에 연간 CRM 라이선스가 있고 다른 줄에 개발자 몇 명과 토큰이 좀 있는 스프레드시트인데, 두 번째 숫자가 더 작다. 대상은 프로젝트 관리 소프트웨어와 내부 관리 도구, 리포팅 계층이다. 이것들은 예전에 아주 큰 회사에서만 사내 제작이 실용적이었다. 마이크로소프트와 어도비, 스포티파이에서 정확히 이런 것들의 내부 버전을 가지고 있었다. 그 규모에서는 기성 옵션이 진짜로 맞지 않았고 비차별적 소프트웨어를 만드는 전담 팀도 여전히 더 나은 길이었기 때문이다. 반면 300명 회사에서는 그 계산이 절대 성립하지 않았다. CRM을 사고 할 일을 했다.

그 계산이 이동했다는 것은 진지하게 받아들여질 만하다. 다만 나는 내 입장을 수정하는 것이지 버리는 것이 아니고 그 수정은 그 주변의 열광이 시사하는 것보다 작다.

두 비용의 분리

AI는 만드는 비용, 즉 첫 번째 비용을 붕괴시켰다. 만들어 놓은 것을 가진 비용, 두 번째 비용은 늘 그랬던 것과 거의 같다. 세 주체가 다르게 움직인다. 벤더는 사업이 그것에 달려 있으므로 제품을 계속 갱신한다. 오픈소스 프로젝트는 유지보수하는 사람들이 갱신하며 그들이 유지보수하지 않으면 유지보수되는 것으로 바꾼다. 내부 도구는 누군가 하던 일을 멈추고 갱신할 때 갱신된다. 그렇다, AI가 그것도 돕는다. 그런데 누군가 CVE를 알아채고 그것이 중요하다고 판단하고 결과를 책임지는 부분은 제거하지 않는다. 그 주의는 절대 사라지지 않는다. 코드가 무료일 때조차 무료가 아니다.

여기서의 실패 양상은 느리고 조용하다. 그것이 이 일이 계속 일어나는 이유다. 그 물건을 만들 때 실수를 발견하지 않는다. 만들 때는 훌륭해 보인다. 18개월 뒤에 발견한다. 이것이 재미있는 프로젝트였던 사람은 떠났고 새 영업 리더가 그 도구가 다르게 작동하기를 원하며 그 코드를 본 적 없는 누군가가 그것을 배워야 한다. 아무도 첫 분기에 빌드 결정을 후회하지 않는다. 그것이 이 문제의 전부다. 그러니 진짜 질문은 만드는 것이 더 싸냐가 아니었다. 무엇을 소유할 의지가 있느냐다.

네 가지 질문

이미 존재하는 것을 만들기 전에 넷을 묻는다. 첫째, 폭발 반경이다. 이것이 실패하거나 침해되거나 조용히 유지보수되지 않게 되면 무엇이 멈추는가. 내부 대시보드가 꺼지는 것은 짜증이지만 인증이 꺼지거나 침해되는 것은 회사를 끝낼 수 있다. 둘째, 소유 비용이다. 향후 몇 년간 누가 그것을 감시하고 패치하고 보안을 지키고 새벽 두 시에 답하는가. 팀이 아니라 사람 이름을 대야 한다. 팀은 호출되지 않는다. 셋째, 차별성이다. 이것을 만드는 것이 사업에 중요한 무언가에 영향을 주는가, 아니면 그저 대안보다 당신 취향에 더 맞을 뿐인가. 맞음은 이제 이전에는 아니었던 방식으로 진짜 논거인데, 그 맞음의 이득이 의미 있을 때만이다.

넷째, 탈출 경로다. 1년 안에 좋은 서드파티 옵션이 나타나면 고통 없이 당신 것을 버릴 수 있는가. 다리로서 만드는 것은 정당한 전략이지만 영구적 약속으로서 만드는 것은 다른 결정이고 의도적으로 그 결정을 내려야 한다. 이 테스트는 대화를 비용에서 떼어낸다. 지금 그 논거가 승리하고 있는 곳이고 때로는 잘못된 이유로 그렇다. 그리고 슬라이드에서 똑같아 보이는 두 빌드 사례를 분리한다. 작고 격리되고 탈출하기 쉬운 것과, 다른 모든 것이 의존하는 영구적인 것이다.

회의에 가져갈 한 가지 질문을 원한다면 이것이다. 3년 차에 누가 그것을 패치하는가. 아무도 답할 수 없다면 아직 결정을 내리지 않은 것이다.

탈출을 미리 염두에 둔 빌드 결정

그 인증 결정의 반례는 최근의 것이다. 여러 프로세스를 자동화하기 위해 회사 전반에서 MCP 서버를 쓰기 시작했을 때, 여러 벤더가 아직 공식 서버를 갖고 있지 않았다. 기다리는 대신 그 벤더들의 API에 대고 내부 MCP 서버를 만들었다. 공식 서버가 나오는 순간 그것으로 옮겼다. 자체 버전을 무한정 유지보수하고 보안을 지키지 않아도 되도록 그랬다. 그 벤더들은 자기 서버를 계속 작동하고 최신으로 유지하는 데 우리보다 훨씬 더 동기가 있다. 인증 빌드 바이 결정과 같은 본능인데 반대 결과다. 차이는 엔지니어링의 품질이 아니었다. 폭발 반경과 나갈 길이 있느냐였다. MCP 서버는 다른 아무것도 존재하지 않았기 때문에 만들었다. 인증은 더 싸기 때문에 오픈소스 위에 만들었다. 그중 하나만 좋은 이유였다.

선이 움직인 곳과 움직이지 않은 곳

만드는 것이 이제 타당한 곳이 있다. 이용 가능한 모든 상업적 또는 오픈소스 옵션이 일하는 방식을 바꾸게 강요하는 작은 서비스와 맞춤 컴포넌트다. 어떤 벤더도 절대 만들지 않을 시스템 간 접착제인데, 한때 컨설팅 회사를 고용했을 만한 종류의 작업이다. 폭발 반경이 격리되어 있고 회사에 대한 맞음이 진짜로 처리량에 영향을 주는 내부 도구다. 그리고 다리인데, 아직 아무것도 존재하지 않고 시장이 따라잡을 것으로 예상하는 경우이며 나타났을 때 실제로 탈출을 실행한다는 조건이 붙는다.

반면 타당하지 않은 곳의 목록은 전혀 바뀌지 않았다. 인증과 신원, 결제, 고객 데이터를 담은 모든 것, 그리고 크리티컬 패스에 있는 모든 것이다. 서드파티 인증을 자체 제작으로 교체하는 것은 침해에 노출시키며 어떤 라이선스 절약도 그 사고를 감당하지 못한다. 규모의 논거도 있다. 그 기능 중 하나를 작동하고 안전하게 유지하는 것만으로 존재하는 회사들이 있고 개발자 몇 명과 토큰 좀으로 그들보다 더 투자할 수는 없다. 그 기능이 당신의 사업인 경우는 예외다. 그 경우에는 그것이 차별적이고 애초에 개발자 몇 명보다 훨씬 많이 쓸 예정이었다.

비용 계산의 함정

이 비용이 계산되는 방식에 함정이 있다. 사람들은 라이선스 항목 대 빌드 노력을 비교한다. 개발자 두 명과 3주, 토큰 몇백 달러 대 연 1만 달러 라이선스. CFO가 당신보다 먼저 그 계산을 돌릴 수 있고 결론은 명백해 보인다. 빠진 것이 많다. 여러 해의 소유와 온콜, 패치, 컴플라이언스 증거, 이것이 당신의 SOC 2에 하는 일, 그리고 그것을 쓴 사람이 지루해지거나 떠날 때의 재구축이다. 대화가 일어나기 전에 다년 숫자를 돌려야 한다. 나중이 아니다.

모델링은 이렇게 한다. 초기 엔지니어링 시간만이 아니라 연간 지속 유지보수 시간, 패치, 업그레이드, 온콜 사고를 추정하고 각각에 대해 개발자 시간의 실제 비용을 포함해 합산한다. 컴플라이언스와 지원에 대한 예상 비용, 팀원이 떠날 때 재작업의 가능성도 더한다. 예컨대 초기 빌드 노력을 개발자 시간 6주라고 하고 예상 연간 유지보수를 연 3주 같은 식으로 더하고 추가 지원이나 컴플라이언스 시간을 3년에서 5년 기간에 걸쳐 더한다. 그 합을 같은 기간의 소프트웨어 라이선스에 통합과 설정 비용을 더한 것과 비교한다. 이 표를 들고 예산 대화에 들어가는 리더는 재무의 지지를 받을 가능성이 훨씬 크다.

공급망 위험은 이제 양방향으로 작동한다

여기가 내 생각이 단순히 조정된 것이 아니라 진짜로 이동한 곳이다. 모든 서드파티 라이브러리는 공급망 공격 표면이다. 그래서 작은 것들에 대해서는 이제 또 다른 의존성을 추가하는 대신 노출을 줄이기 위해 만드는 쪽으로 기울 수 있다. 몇 년 전이라면 라이브러리를 쓰고 시간 낭비를 멈추라고 했을 것이다. 단서는 어디서나 같다. 얼마나 작은지, 얼마나 많은 것이 그것에 의존하는지, 차별적인지다. 대가도 명확하다. 직접 만드는 것은 당신이 권고문을 읽고 패치를 배포하는 사람이 된다는 뜻이고 많은 팀이 그것을 위한 인력을 갖추지 못했다. 그럼에도 서드파티 의존성이 항상 더 낮은 위험 선택이라는 반사적 답은 더 이상 자동으로 참이 아니다.

두 실패 패턴을 조심해야 한다. 첫째는 주말 프로토타입인데, 아무도 결정하지 않았는데 누군가 끼워 넣어서 조용히 프로덕션이 되는 것이다. 둘째는 한계적 개선인데, 진짜 개선이지만 여전히 영구적 유지보수 의무의 값어치가 없다. 약간 더 나은 것은 의미 있게 더 나은 것과 같지 않기 때문이다.

이번 주에 할 일이 있다. 팀이 소유한 내부 도구를 나열하고 각각에 대해 내일 취약점이 떨어지면 누가 패치할 것인지, 그리고 그것이 떨어졌다는 것을 애초에 어떻게 알 것인지 이름을 댄다. 이름이 붙지 않은 프로젝트가 교체하거나 소유를 약속할 사람을 구해야 하는 것이다. 아무도 약속하지 않으면 그것이 당신의 답이다. 이 검토를 정기적 습관으로 만들고 소유와 책임 확인에 분기 주기를 설정하면 좋다. 일회성 연습이 아닌 반복 프로세스로 다루면 위험 관리를 제도화하는 데 도움이 된다.

같은 결정이 채용에서도 나타난다

대부분의 사람이 이것을 아직 연결하지 못했다. 역량 격차가 있다고 하자. 팀의 누구도 모르는 기술이거나 진입하려는 사업 영역일 수 있다. 역사적으로는 그것을 메우거나 가르치도록 계약직을 고용했거나 자리를 열었거나 팀을 만들었다. 이제 새 선택지가 있다. 그 역량이 차별적이지도 사업에 결정적이지도 않은 곳에서는 사람 대신 에이전트로 상당 부분을 덮을 수 있다. 논리는 이렇다. 비차별적이란 보통 잘 이해되고 널리 알려졌다는 뜻이고 그것이 정확히 에이전트가 잘 다루는 것이다. 그래서 그 특정 영역의 전문가보다 폭넓게 유능한 더 적은 사람으로 해낼 수 있다.

사업에 결정적인 곳에서는 전략이 바뀐다. 다섯 명 팀을 고용했을 만한 곳에서 강한 사람 한두 명을 고용하고 그들을 증강한다. 전통적 의미로 아무것도 구매되지 않지만 이것은 구매 결정이다. 연간 SaaS 계약이 없을 뿐이다. 계약 대신 토큰에 쓰는 것도 여전히 무언가를 영구히 소유하기로 선택하는 것을 뜻한다. 구매하는 것이 소프트웨어가 아니라 역량이라고 해서 폭발 반경과 소유가 중요하지 않게 되지는 않는다. 예전에는 격차를 사람으로만 채웠다. 이제는 그중 일부를 지출로 채울 수 있고 어느 것을 고를지 아는 것이 진짜 리더십 판단이다.

하게 될 세 가지 대화

첫째는 그것을 만들고 싶어 하는 엔지니어와의 대화다. 두 동기가 외부에서 똑같아 보인다. 문제가 흥미롭다는 것, 또는 벤더가 기존 솔루션을 만든 방식에 동의하지 않으며 왜 그것이 틀렸는지 정확히 말할 수 있다는 것. 둘 다 정당한 감정이지만 어느 것도 사업 논거가 아니다. 대응은 차단이 아니다. 그 에너지를 실제로 회사를 차별화하는 작업으로 돌리는 것이고 그것은 보통 더 어렵고 즉각적으로 덜 재미있다. 누군가 해결된 문제를 풀고 싶은 이유를 설명하며 오면, 그들이 말하고 있는 것은 도전을 원한다는 것이다. 도전을 주면 된다.

둘째는 재무와의 대화다. 소프트웨어 지출이 지금 실제로 정밀 조사를 받고 있는데, 부분적으로 AI 비용이 같은 예산에 떨어지고 있기 때문이다. 라이선스 항목을 설명할 수 없는 CTO나 엔지니어링 부사장은 그 논쟁에서 진다. 3년 소유 숫자를 들고 들어가면 대화가 비용 회피에서 위험 이전으로 바뀐다. 항목을 방어하는 것이 아니라, 회사가 다른 누군가에게 무엇을 지게 하는 대가를 지불하고 있는지 설명하는 것이다. 셋째는 데모를 본 임원과의 대화다. 누군가 이틀에 인상적인 것을 만들었고 점점 그 누군가는 기술 조직에 아예 있지도 않다. 바이브 코딩을 실험하는 영업 사원이나 제품 관리자다. 그러면 질문이 온다. 이제 그 데모가 복제한 것처럼 보이는 것에 회사가 왜 연간 여섯 자리를 지불하고 있는가.

정직한 답은 두 갈래다. 하나는 데모에 없었던 모든 것에 관한 것이다. 다른 하나는 그 뒤의 산술이다. 벤더는 그 제품에 백 명이 일하고 있고 당신은 두 명일 수 있는데, 그 둘이 라이선스보다 더 비싸다.

선은 느껴지는 것보다 덜 움직였다

지난 20년 대부분에 걸쳐 해결된 문제에 엔지니어링 자원을 쓰는 것은 실용적이지 않았다. 맞춰진 대안을 만드는 것이 거의 값어치가 없었으므로 그 입장을 유지하기 쉬웠다. 내가 쓰는 모든 것을 관통하는 한 가지가 있다면 실용주의가 이긴다는 것이다. 진짜로 바뀐 것은 회사에 특별히 맞춰진 것을 만드는 것이 충분히 싸져서 맞음이 처음으로 진짜 논거가 되었다는 점이다. 바뀌지 않은 것은 위험과 보안, 총 소유 비용이다. 사내에서 인증을 만들지 않을 이유들은 정확히 언제나 그랬던 이유들이고 그중 어느 것도 그것을 쓰는 데 얼마나 오래 걸리는지에 관한 것이 아니었다.

과잉 교정이 일어나고 있다. 데모가 설득력 있고 청구서가 짜증나기 때문이다. 실제 이동은 가장자리에서 일어난다. 작은 것들과 격리된 것들, 탈출이 있는 것들이다. 원칙은 두 문장이다. 사업이 달라야 하는 것들을 만들라. 사업이 그저 작동해야만 하는 것들을 사라. 싸게 만들 수 있다는 것은 애초에 논거가 아니었고 지금도 아니다. 싸다는 것은 무언가를 창조하는 비용만 계산하고 그것을 지고 가는 비용은 계산하지 않기 때문이다. 오늘 팀이 소유한 것을 보고 그것이 비용이 얼마인지 이제 아는 상태에서 그중 무엇을 다시 소유하기로 선택할지 물어보라. 다음에 누군가 만들자고 제안하는 것에 대해서도 같은 질문을 하면 된다. 이미 존재하는 것을 발명하지 않는 것은 애초에 그것을 발명하는 비용에 관한 것이 아니었다. 그렇게 할 때 무엇을 떠안는지에 관한 것이었다.

더 생각해보기

• 본전이었다는 결산은 어느 항목까지 세었을 때 나오는가.
• 30일 차이로 비켜갔다는 사실은 그 결정의 평가를 어떻게 바꿔야 하는가.
• 만드는 비용과 가진 비용의 비율이 얼마부터 빌드가 정당해지는가.
• 팀이 아니라 사람 이름을 대라는 요구는 조직 개편이 잦은 회사에서 어떻게 유지되는가.
• 탈출 경로를 미리 정하는 설계는 실제로 얼마나 자주 실행되는가.
• 공급망 위험 때문에 직접 만드는 판단은 어떤 규모까지 유효한가.
• 주말 프로토타입이 조용히 프로덕션이 되는 것을 막는 기제는 무엇인가.
• 약간 더 나은 것과 의미 있게 더 나은 것의 경계는 무엇으로 판별하는가.
• 역량 격차를 에이전트로 덮는 결정에서 폭발 반경은 어떻게 계산하는가.
• 데모가 복제한 것처럼 보인다는 임원의 질문에 어떤 증거로 답해야 하는가.