서비스를 멈추는 건 코드가 아니라 ‘문서 3장’이다
회의실이 좁았다. 법무, 보안, 조달, PM이 한 테이블에 다 앉아 있는 날은 보통 좋은 날이 아니다.
슬랙에는 이미 “오늘부터 이 경로는 막아주세요”가 올라와 있고, 메일에는 공급사 단가표가 붙어 있고, 누군가는 ‘사용 조건’ PDF를 열어둔 채로 말한다.
“이거, 기술적으로는 되죠?”
된다. 잘 돈다. 테스트도 통과한다.
그런데 오늘은 그게 문제가 아니다.
오늘의 질문은 딱 세 개다. 이걸 써도 되는가(조건), 이걸 계속 쓸 수 있는가(돈), 이걸 여기서 팔 수 있는가(규정).
그리고 신기하게도, 답은 레포지토리가 아니라 문서에서 나온다.
내가 말하는 ‘문서 3장’은 결국 이거다: 사용 조건(계약/정책) 1장, 원가표(BOM/조달) 1장, 규정/인프라 체크 1장.
“기술은 되는데, 이 문구 못 넣으면 오늘은 못 나가요.”
계약서가 ‘가능’을 ‘불가’로 바꾸는 순간
현장에서 계약서는 기능 명세가 아니라 브레이크다. 특히 AI는 더 그렇다. 모델이 똑똑하냐보다 “어떤 목적으로, 어떤 환경에서, 누가 책임지고 쓰느냐”가 먼저 깔린다.
Anthropic 관련 기사는, 이 지점이 실제로 어떻게 충돌하는지 보여준다. 말이 조금만 엇갈려도(사용 조건, 목적, 조직 요구), 기술이 아니라 계약과 조달이 먼저 결론을 내린다. 그 결론은 종종 단순하게 떨어진다: “지금은 안 됨”.
그때 내가 제일 먼저 확인했던 건 기능 리스트가 아니다.
- 우리가 제공하는 기능 중 “조건을 걸면 살릴 수 있는 것”과 “조건을 걸어도 위험한 것”을 나눈다.
- 고객/조직이 원하는 요구사항을 문장으로 다시 쓰고(법무가 읽을 수 있게), 우리가 지킬 수 있는 문장과 지킬 수 없는 문장을 갈라둔다.
이 과정이 싫은 이유는 뻔하다. 코드로 해결이 안 된다. 그래도 해야 한다. 안 그러면 개발팀이 며칠을 태워 만든 기능이, 마지막 한 페이지에서 멈춘다.
원가표(BOM)가 로드맵을 ‘조용히’ 바꾸는 방식
하드웨어 얘기는 인프라 팀의 일 같지만, 실제로는 제품 일정의 바닥에 깔려 있다.
메모리 쇼티지 관련 기사와 IDC 분석을 보면, 가격이 오를 때 일어나는 일은 꽤 노골적이다. 단가가 오르고, 출하량 전망이 흔들리고, 교체 주기가 미뤄진다. 그 여파는 “성능이 조금 떨어진다”가 아니라 “채용/온보딩/테스트/릴리스가 같이 늦어진다”로 온다.
IDC는 출하량 둔화와 ASP 상승을 같이 전망했다. 이 조합이 무서운 이유는, 우리 입장에선 “장비를 더 사서 병렬로 돌리기”가 갑자기 비싸지거나 늦어지기 때문이다. 결국 빌드/테스트 병렬성이 먼저 흔들린다.
여기서 문제는, 대부분의 팀이 이 변수를 장애처럼 다루지 않는다는 거다. 장애는 알림이 울리는데, 원가표는 조용히 온다. 대개 다음 분기 예산 회의쯤 가서야 표면으로 올라온다.
그래서 나는 BOM/원가표를 볼 때 ‘가격’보다 ‘연쇄’를 본다.
- 메모리 단가가 오르면 우리 제품에서 어떤 비용이 먼저 튀는지(빌드 머신 확장? 테스트 병렬성? 개발자 장비?)
- 그게 튀었을 때 무엇을 먼저 깎을지(테스트 범위? 릴리스 빈도? 실험 기능?)
이건 기술 판단이 아니라 경영 판단처럼 보이지만, 결국 기술팀이 먼저 질문을 던져야 한다. 안 그러면 답은 “그럼 다음 분기에요”로 정리된다.
규정과 인프라는 출시를 ‘호환성’ 문제로 만든다
Apple Pay의 인도 진출을 다룬 기사에서 드러나는 건, 결제가 기능 출시가 아니라 ‘환경 호환’이라는 사실이다. NFC만 있으면 끝나는 게 아니라, 결제 레일(예: UPI 같은 로컬 인프라), 규정, 데이터 처리 위치 같은 바깥 조건이 붙는다.
이런 건 개발자 입장에서 제일 답답하다.
- 코드가 완성돼도 “지금은 안 됨”이 나온다.
- ‘언제’가 기술이 아니라 외부 조건으로 정해진다.
그래서 나는 이 종류의 이슈를 아예 제품 설계에 넣는다.
- 지역별로 무엇을 켤 수 있고 무엇을 못 켜는지(기능 스위치가 아니라 정책 스위치)
- 결제/인증/저장 같은 핵심 경로에 우회로가 있는지(없으면 어디까지 포기할지)
규정은 결국 운영으로 들어온다. 예를 들어 “이 결제는 UPI를 타야 한다”거나 “결제 데이터는 국내에 둬야 한다” 같은 문장이 나오면, 그날부터는 기능 회의가 아니라 아키텍처 회의 + 운영 런북 회의가 열린다.
회의에서 바로 써먹는 질문들
이건 회의록에 그대로 붙여도 된다. (나도 그렇게 쓴다.)
- 이 기능이 멈추는 이유는 “기술 실패”가 아니라 “조건 위반”일 수 있다. 그 조건은 한 문장으로 뭐지?
- ‘사용 가능 범위’를 누가 정의하고, 그 문장을 어디에 박나? (법무/보안/PM 오너 + 계약 부록/내부 정책 문서/세일즈 FAQ 중 택1)
- 가격이 10%(예시 임계값) 오르면 우리가 먼저 포기할 건 뭔가? 테스트? 실험? 지역 롤아웃?
- 조달 리드타임이 두 배가 되면, 어떤 일정이 바로 밀리나? 온보딩? 릴리스? 고객 온사이트?
- 규정/인프라가 바뀌면 우리가 바꿔야 하는 건 코드인가, 운영인가, 계약 문구인가?
- 외부 환경이 막혔을 때(벤더/부품/규정) 고객에게 뭐라고 안내할지, 그리고 그 문장을 어디에 박아둘지.
- 누가 이렇게 물었을 때 답할 수 있나: “이거, 다음 분기에도 계속 되죠?” (그 ‘예/아니오’가 적힌 문서는 어디지?)
Go / No-Go 기준
멋있게 말할 것 없다. 아래 셋 중 하나라도 “아직”이면 No-Go가 맞다.
- 법무/보안이 읽을 수 있는 형태로 ‘사용 조건’이 한 문장으로 합의돼 있다(예외도 포함).
- 원가표가 흔들릴 때 바뀌는 계획이 있다(어디를 깎고 무엇을 늦출지).
- 규정/인프라 변수에 대한 우회로 또는 축소안이 있다(지역/기능 범위 포함).
- 멈췄을 때 고객 안내문 초안이 있다(무엇이 영향인지 / 왜인지(조건) / 다음 업데이트 시간).
참고자료
- Computerworld — Trump administration bans Anthropic, escalating clash over military use of AI
- https://www.computerworld.com/article/4138841/trump-administration-bans-anthropic-escalating-clash-over-military-use-of-ai-2.html
- Computerworld — Memory shortage batters PC market; double-digit sales drop coming, say analysts
- https://www.computerworld.com/article/4138726/memory-shortage-batters-pc-market-double-digit-sales-drop-coming-say-analysts.html
- IDC — Higher ASPs, lower unit volumes: How the memory crisis is reshaping the PC and smartphone outlook
- https://www.idc.com/resource-center/blog/higher-asps-lower-unit-volumes-how-the-memory-crisis-is-reshaping-the-pc-and-smartphone-outlook/
- Computerworld — Why Apple is ready to launch Apple Pay in India
- https://www.computerworld.com/article/4138661/why-apple-is-ready-to-launch-apple-pay-in-india.html
댓글
댓글 쓰기