허용하는 시스템이 더 강하다: 불완전한 경계가 만드는 신뢰의 설계

우리가 정말 통제하고 싶은 것은 무엇인가

새로운 기능이 들어오면 사람들은 보통 묻는다. 이걸 안전하게 막을 수 있나? 그런데 더 중요한 질문은 따로 있다. 이걸 언제, 어디서, 어떤 조건으로 허용할 것인가? 이 질문으로 넘어가는 순간, 시스템 설계는 완전히 다른 차원으로 들어간다.

겉으로 보면 한쪽은 개발 도구의 설정이고, 다른 한쪽은 카드 혜택의 조합처럼 보인다. 하지만 둘 다 같은 핵심을 건드린다. 현대의 시스템은 더 이상 단순히 금지와 허용으로만 움직이지 않는다. 경계를 닫는 기술보다, 경계를 조율하는 기술이 중요해진다. 타입스크립트가 낯선 확장자를 무조건 에러로 처리하지 않고, 이미 런타임이나 번들러가 책임지는 경우 예외를 허용하는 것처럼, 금융 상품도 각 카드의 실적과 혜택을 따로 떼어 보지 않고 하나의 묶음으로 재구성한다.

이 둘의 공통점은 단순하다. 둘 다 현실 세계의 복잡성을 인정한다. 현실에서는 모든 것을 하나의 규칙으로 통일할 수 없다. 대신 시스템은 무엇을 믿고, 무엇을 위임하고, 무엇을 합산할지를 정교하게 설계해야 한다.

강한 시스템은 모든 것을 직접 통제하지 않는다. 대신 신뢰할 수 있는 책임 경로를 만들고, 그 경로를 따라 예외를 허용한다.

---

금지의 미학에서 조율의 미학으로

오랫동안 좋은 시스템은 엄격해야 한다고 여겨졌다. 컴파일러는 모르는 확장자를 보면 멈춰야 하고, 카드 혜택은 각 상품별로 따로 계산해야 하며, 예외는 가능한 한 줄여야 한다는 생각이다. 이 방식은 분명 장점이 있다. 단순하고, 설명하기 쉽고, 오류를 빠르게 잡아낸다.

하지만 이 접근은 커질수록 한계를 드러낸다. 시스템이 복잡해질수록 예외는 불가피해진다. CSS 로더가 있는 번들러 환경에서 스타일 파일을 직접 import 하는 경우를 생각해 보자. 원칙만 따르면 “알 수 없는 파일이니 오류”가 맞다. 그러나 실제 세계에서는 이미 빌드 체인이 그 파일을 처리하고 있고, 타입 시스템은 그 사실을 덜 똑똑하게만 모를 뿐이다. 여기서 중요한 건 무조건적인 거부가 아니라, 실행 책임의 위치를 반영하는 것이다.

금융 상품의 세계도 비슷하다. 각 카드에 따로 실적 조건과 혜택이 붙어 있으면 사용자는 카드마다 소비를 분산시키기 쉽다. 그런데 실적이 합산되고 혜택이 연결되면, 사용자는 상품을 개별 점포가 아니라 하나의 생태계로 바라보게 된다. 이때 설계의 핵심은 단순한 할인율이 아니다. 조합 가능한 구조를 통해 행동을 묶는 것이다.

이 변화는 아주 중요하다. 좋은 시스템은 사용자를 규칙의 벌판 위에 세우지 않는다. 오히려 사용자가 실제로 어떻게 움직이는지 관찰하고, 그 흐름에 맞게 규칙을 재구성한다. 즉, 규칙은 현실을 억압하는 장치가 아니라 현실을 읽는 언어가 되어야 한다.

---

핵심은 예외가 아니라 책임의 배치다

많은 사람이 예외를 허용하는 순간 품질이 떨어진다고 생각한다. 하지만 진짜 질문은 예외의 유무가 아니다. 예외가 어디서 관리되는가다. 만약 아무 데서나 예외를 허용하면 혼란이 된다. 하지만 예외가 명확한 책임 구조 안에 들어가 있으면, 오히려 시스템은 더 정확해진다.

타입스크립트의 허용은 이런 구조를 전제로 한다. 컴파일러가 모든 파일 형식을 아는 척하지 않는 대신, 번들러나 런타임이 이미 처리해 주는 영역을 존중한다. 즉, 타입 시스템은 세계의 주인이 아니라 협업자가 된다. 이건 단순한 편의 기능이 아니라 철학의 변화다. “내가 모르면 틀린 것”이 아니라, “내가 모르는 부분은 다른 층이 책임질 수 있다”는 사고다.

카드 상품도 같은 원리로 읽을 수 있다. 개별 카드의 실적을 따로 보지 않고 합산한다는 것은 단순히 혜택을 크게 보이게 하려는 장치가 아니다. 그것은 소비 패턴의 현실을 받아들이는 방식이다. 사람들은 매달 여러 장의 카드를 들고 다니며, 특정 카드는 주유에, 특정 카드는 온라인에, 또 다른 카드는 생활비에 쓴다. 이런 분산된 행동을 억지로 하나의 카드에만 맞추라고 요구하면 오히려 사용성이 떨어진다. 반대로 실적과 혜택을 묶으면, 사용자는 복잡한 선택을 덜 하고도 더 나은 결과를 얻는다.

여기서 핵심은 단순화가 아니라 재배치다. 규칙을 없애는 것이 아니라, 규칙이 작동하는 층을 바꾸는 것이다.

성숙한 설계는 예외를 제거하려 하지 않는다. 예외를 담당할 층을 명확히 만든다.

이 관점에서 보면, 시스템의 품질은 얼마나 엄격한가가 아니라 얼마나 정확하게 책임을 분할했는가로 평가해야 한다. 모든 것을 한 층에 몰아넣으면 강해 보이지만 실제로는 경직된다. 반대로 각 층이 자신의 책임을 알고 다른 층을 존중하면, 시스템은 복잡성을 흡수할 수 있다.

---

조합 가능한 설계가 행동을 바꾼다

조합 가능성은 단지 기술적 편의가 아니다. 그것은 사람의 행동 자체를 바꾼다. 한 장의 카드가 아니라 두 장의 카드가 함께 작동하고, 한 가지 확장자 규칙이 아니라 여러 빌드 도구가 협력할 때, 사용자는 선택의 부담을 덜 느낀다. 그 결과 시스템은 사람의 습관을 다시 설계한다.

예를 들어 보자. 어떤 사람이 생활비용 카드와 포인트 적립 카드를 따로 쓰고 있다고 하자. 실적이 분리되어 있으면, 그는 매달 “어느 카드에 얼마를 써야 하지?”라는 계산을 해야 한다. 하지만 실적 합산 구조가 있으면, 그는 전체 포트폴리오의 효율만 생각하면 된다. 이때 중요한 변화는 상품 정보의 차이가 아니다. 의사결정 비용이 줄어든다는 점이다.

소프트웨어에서도 마찬가지다. 파일 확장자가 낯설어서 빌드가 멈추면 개발자는 시스템의 규칙을 일일이 기억해야 한다. 그러나 이미 다른 도구가 그 책임을 처리하는 구조라면, 타입 시스템은 그 현실을 인정하고 개발 흐름을 끊지 않는다. 이것은 생산성의 문제가 아니라 인지 부하의 문제다. 좋은 도구는 더 많은 규칙을 요구하는 것이 아니라, 사용자가 규칙을 덜 생각하게 만든다.

이 지점에서 흥미로운 통찰이 나온다. 조합 가능한 시스템은 더 관대해서 강한 것이 아니라, 더 정확해서 강하다. 겉으로는 허용이 늘어난 것처럼 보이지만, 실제로는 책임 경계가 더 선명해졌기 때문에 가능한 허용이다. 아무거나 허용하는 관대함은 약함이지만, 책임 구조 위에서의 허용은 강함이다.

이 차이는 여러 분야에서 반복된다. 팀 운영도 그렇고, API 설계도 그렇고, 혜택 구조도 그렇다. 사용자가 불편해하는 이유는 대개 규칙이 너무 적어서가 아니라, 규칙이 어디에 있는지 불분명하기 때문이다. 규칙이 명확하면 사람은 그 규칙을 오히려 편안하게 받아들인다. 예외가 예측 가능하기 때문이다.

---

우리가 설계해야 하는 것은 신뢰의 경로다

이제 두 사례를 하나의 원리로 묶을 수 있다. 좋은 시스템은 단순히 기능을 추가하지 않는다. 신뢰가 흐르는 경로를 설계한다. 타입스크립트의 허용은 “이 파일은 내가 모른다”가 아니라 “이건 다른 층이 책임진다”는 신뢰의 선언이다. 카드 실적 합산은 “이 혜택은 따로 놀지 않는다”가 아니라 “이 상품군은 하나의 경험으로 작동한다”는 신뢰의 선언이다.

이 관점에서 시스템 설계는 권한 관리와 같다. 모든 권한을 중앙에서 쥐면 안전해 보이지만, 실제로는 병목이 생긴다. 권한을 무작정 분산하면 혼란이 생긴다. 따라서 중요한 것은 누가 무엇을 결정할 수 있는지, 그리고 그 결정이 어디까지 유효한지를 정하는 일이다.

여기서 실무적으로 유용한 프레임이 하나 있다. 어떤 규칙을 만들 때마다 다음 세 질문을 던져 보라.

1. 이 규칙은 무엇을 보호하는가?
2. 이 규칙은 어떤 층의 책임을 대신하고 있는가?
3. 이 규칙이 현실과 충돌할 때, 예외를 허용할 조건은 무엇인가?

이 질문에 답할 수 있으면, 규칙은 경직된 금지가 아니라 설계된 유연성이 된다. 답할 수 없으면, 그 규칙은 대개 조직의 두려움을 문장으로 바꾼 것일 뿐이다.

생각해 보면 많은 실패한 시스템은 복잡해서 무너진 것이 아니다. 오히려 복잡성을 인정하지 않았기 때문에 무너졌다. 사람들은 실제로는 여러 도구를 함께 쓰고, 여러 혜택을 조합하고, 여러 책임 주체를 넘나들며 일한다. 시스템이 이 사실을 외면하면 사용자는 비공식적인 우회로를 만든다. 그때부터 진짜 복잡성이 시작된다.

---

Key Takeaways

• 금지보다 책임의 위치를 먼저 보라. 예외가 문제인지, 아니면 예외를 처리할 층이 잘못 배치된 것인지 구분해야 한다.
• 규칙을 단일화하지 말고 조율하라. 하나의 절대 규칙보다, 서로 다른 층이 협력하는 구조가 현실에 강하다.
• 사용자의 실제 행동을 기준으로 설계하라. 사람들이 어떻게 조합해서 쓰는지 보면, 어떤 경계가 부자연스러운지 보인다.
• 예외 허용은 관대함이 아니라 정밀함이다. 이미 다른 시스템이 책임지는 영역이라면, 상위 시스템은 그 사실을 인정해야 한다.
• 신뢰의 경로를 문서화하라. 누가 무엇을 처리하고, 어디까지 유효한지 명확할수록 시스템은 더 유연해진다.

---

결론: 강한 시스템은 완벽하게 닫히지 않는다

우리는 흔히 강한 시스템을 상상할 때, 빈틈없는 규칙과 철저한 차단을 떠올린다. 하지만 실제로 가장 강한 시스템은 조금 다르다. 완벽하게 닫힌 시스템이 아니라, 잘 설계된 연결을 가진 시스템이다. 그것은 현실의 불완전함을 부정하지 않고, 오히려 그 불완전함을 흡수할 수 있는 구조를 만든다.

타입스크립트가 낯선 확장자를 허용할 때, 그리고 카드의 실적과 혜택이 묶일 때, 공통적으로 일어나는 일은 같다. 시스템은 세상을 단순화하지 않는다. 대신 세상이 원래 복잡하다는 사실을 인정하고, 그 복잡성을 견딜 수 있는 방식으로 스스로를 바꾼다.

그래서 진짜 설계의 질문은 더 이상 “무엇을 막을 것인가”가 아니다. **“무엇을 믿고, 어디까지 맡기며, 어떤 예외를 질서 있게 허용할 것인가”**다. 이 질문에 답할 수 있는 시스템만이, 규칙을 강요하지 않고도 사람들의 행동을 부드럽게 바꿀 수 있다. 그리고 아마 그때부터 비로소 우리는 통제의 기술이 아니라, 신뢰의 기술을 설계하고 있는지도 모른다.