텍사스 규제 중단! 당장 코드부터 지워야 하는 이유

"이 기능은 혹시 모르니까 일단 개발해두죠."
"법무팀에서 나중에 필요할 수도 있다고 해서요."

회의실에서 이런 소리가 들리면 저는 노트북을 덮습니다. 비즈니스는 보험 상품이 아닙니다. '혹시 모를' 상황을 대비해 리소스를 태우는 건, 스타트업에서 가장 확실하게 망하는 지름길입니다. 특히 그 대상이 언제 바뀔지 모르는 '규제'라면 더더욱 그렇습니다.

최근 애플 개발자 뉴스에 텍사스 주법 SB2420 관련 업데이트가 올라왔습니다. 결론부터 말하자면, 연령 인증 관련 규제 시행이 법원 명령으로 중단되었습니다.

많은 주니어 PM과 개발자들이 이 소식을 듣고 "아, 그럼 이제 안 해도 되네?" 하고 끝냅니다. 하지만 시니어라면 여기서 멈추면 안 됩니다. 이건 단순한 뉴스 전달이 아니라, '불확실한 규제 상황에서 엔지니어링 리소스를 어떻게 아낄 것인가'에 대한 생존 가이드이기 때문입니다.

오늘은 규제 롤러코스터에서 살아남는 법, 그리고 당장 우리 백로그에서 무엇을 쳐내야 할지 정리합니다.

1. 팩트 체크: 무엇이 바뀌었나?

감으로 일하지 말고 팩트부터 봅시다.

상황: 텍사스 주법(SB2420) 시행 중단. (연방법원 명령)
애플의 대응: 기존에 발표했던 강제 시행 계획 일시 중단(Pause).
남은 것: 테스트용 샌드박스 도구는 유지. (Declared Age Range API, PermissionKit 등)
미래: 유타(Utah), 루이지애나(Louisiana) 법률은 2026년 발효 예정.

해석: 당장 운영 환경(Production)에 텍사스용 연령 인증 강제 로직을 태울 필요가 없어졌습니다. 하지만 완전히 끝난 건 아닙니다. 유타와 루이지애나라는 다음 파도가 2026년에 옵니다.

2. 최악의 시나리오: "일단 다 개발해놨는데요?"

제일 끔찍한 상황은 이겁니다.

규제가 예고되자마자 과도한 공포심에 사로잡혀, 기획팀이 온갖 엣지 케이스를 다 덮을 수 있는 거대한 '통합 연령 인증 시스템'을 기획합니다. 개발팀은 밤새워 API를 연동하고, QA팀은 테스트 시나리오를 짭니다.

그런데 오늘처럼 규제가 '일시 정지' 버튼을 눌러버립니다.

결과: 쓰지 않는 코드가 덕지덕지 붙은 앱.
비용: 개발 M/M 낭비 + 복잡해진 코드베이스 유지보수 비용 + 앱 용량 증가.
리스크: 사용하지 않는 인증 로직에서 터질 수 있는 잠재적 버그.

이게 바로 제가 "비즈니스 임팩트 없는 개발은 죄악"이라고 말하는 이유입니다. '나중'을 위한 개발은 없습니다. 지금 당장 필요한 것만 만드십시오.

3. 액션 아이템: 지금 당장 해야 할 일

이 뉴스를 보고 PO와 리드 개발자가 해야 할 행동은 명확합니다.

1) 프로덕션 배포 계획 전면 수정 (Rollback & Clean up)

텍사스 규제 대응으로 이번 스프린트에 포함된 티켓이 있다면? 가차 없이 백로그로 돌리거나 삭제하십시오. 이미 코드가 머지되었다면, 피쳐 플래그(Feature Flag)로 꺼버리는 게 아니라, 가능하다면 코드 자체를 걷어내는 것을 권장합니다.

피쳐 플래그는 만능이 아닙니다. 꺼진 플래그도 결국 관리해야 할 기술 부채입니다. 당장 안 쓸 거면 지우세요. 깃(Git)은 기억력이 좋습니다. 나중에 필요하면 그때 다시 살리면 됩니다.

2) API 연동은 '샌드박스'에서 멈추십시오

애플이 Declared Age Range API나 StoreKit 속성을 샌드박스용으로 남겨둔 이유는 명확합니다. "연습만 해둬라"는 겁니다.

개발팀 리드에게 이렇게 지시하십시오.
"유타/루이지애나 법안 대응을 위한 PoC(개념 증명) 수준까지만 확인하고, 실제 유저 플로우에는 태우지 마세요."

3) 2026년 로드맵 마킹

규제는 사라진 게 아니라 유예된 겁니다. 2026년 유타와 루이지애나 법안 발효 시점에 맞춰 다시 꺼낼 수 있도록 지라(Jira) 티켓 하나만 생성해 두십시오. "2025년 4분기 규제 검토" 정도로 박아두면 충분합니다. 지금 고민해봤자 그때 되면 API 스펙 또 바뀝니다.