A-7. 분산·성능·보안의 물리적 제약
한 줄 요약: 네트워크, 병렬화, 하드웨어, 에너지, 보안에서 좋은 추상화만으로 사라지지 않는 제약을 프론트엔드 판단에 연결할 수 있다.
학습 목표
- CAP Theorem과 Fallacies of Distributed Computing을 프론트엔드의 API 지연, 캐시, 재시도, offline UI 문제로 연결할 수 있다.
- Amdahl's Law를 병렬화와 성능 최적화의 상한을 읽는 모델로 사용할 수 있다.
- Moore's Law, Koomey's Law, Jevons' Paradox를 하드웨어·에너지·효율 개선의 경계 조건으로 해석할 수 있다.
- Kerckhoffs's principle을 클라이언트 보안과 비밀 관리의 기준으로 설명할 수 있다.
배경: 왜 이것이 존재하는가
프론트엔드는 분산 데이터베이스를 직접 구현하지 않는 경우가 많다. 그러나 사용자는 프론트엔드를 통해 분산 시스템의 실패를 경험한다. API가 늦고, 캐시가 오래되고, mutation이 충돌하고, 오프라인에서 작업이 실패하고, 권한 상태가 바뀌며, 재시도 버튼을 여러 번 누른다. 네트워크와 서버의 제약은 결국 UI 상태가 된다.
성능과 보안도 비슷하다. 브라우저와 하드웨어는 무한히 빨라지지 않고, 병렬화에는 상한이 있으며, 클라이언트에 내려간 비밀은 비밀이 아니다. 이 문서의 법칙들은 낙관적인 추상화를 현실의 제약에 붙들어 매는 역할을 한다.
핵심 개념
분산 시스템의 선택은 UI 상태로 드러난다
CAP Theorem은 네트워크 파티션 상황에서 분산 데이터 저장소가 일관성(consistency)과 가용성(availability)을 동시에 완벽히 만족하기 어렵다는 이론으로 알려져 있다. 프론트엔드 개발자가 CAP을 직접 설계하지 않더라도, 그 선택의 결과를 UI에서 다룬다.
예를 들어 협업 편집 도구에서 사용자는 방금 수정한 값이 즉시 보이기를 기대한다. 서버는 여러 region과 offline client를 다뤄야 한다. 어떤 순간에는 "내 화면의 값", "다른 사용자의 값", "서버가 확정한 값"이 다를 수 있다. 이 차이를 숨기면 사용자는 데이터 손실로 느낀다. optimistic UI, conflict resolution, sync indicator, undo가 필요한 이유다.
CAP은 모든 시스템을 C/A/P 세 글자로 단순 분류하라는 뜻이 아니다. 실제 시스템은 지연, 장애 모델, 데이터 종류, 사용자 기대에 따라 다양한 선택을 한다. 프론트엔드에서는 "이 화면에서 사용자가 견딜 수 있는 불일치는 무엇인가"를 묻는 것이 더 실용적이다.
네트워크에 대한 잘못된 가정은 UI 버그가 된다
The Fallacies of Distributed Computing은 네트워크가 신뢰 가능하고, 지연이 없고, 대역폭이 무한하고, 보안이 이미 되어 있다는 식의 잘못된 가정을 경고한다. 프론트엔드에서는 다음과 같이 드러난다.
| 잘못된 가정 | UI에서 나타나는 문제 |
|---|---|
| 네트워크는 신뢰 가능하다 | 실패 상태와 재시도 경로가 없다 |
| 지연은 0에 가깝다 | loading, skeleton, 중복 제출 제어가 없다 |
| 대역폭은 충분하다 | 큰 bundle과 이미지가 느린 네트워크를 망친다 |
| topology는 변하지 않는다 | region, CDN, proxy 차이를 고려하지 않는다 |
| 네트워크는 안전하다 | 클라이언트 secret, 약한 CSP, 잘못된 cookie 정책이 생긴다 |
이 법칙은 비관주의가 아니다. 실패를 정상 경로로 설계하라는 요구다. fetch가 실패하고, abort되고, 중복되고, 오래 걸리고, partial data를 반환할 수 있다는 전제에서 UI를 만든다.
병렬화에는 상한이 있다
Amdahl's Law는 전체 작업 중 병렬화 가능한 부분의 비율이 속도 향상의 상한을 결정한다는 모델이다. 프론트엔드 성능에서도 유용하다. 이미 병렬로 불러올 수 있는 리소스를 나누는 것보다, render main thread를 오래 막는 동기 작업이 병목이라면 네트워크 병렬화의 효과는 제한된다.
예를 들어 큰 dashboard가 느릴 때 chart 데이터를 병렬 요청으로 바꿔도, 클라이언트에서 모든 데이터를 동기 파싱하고 layout을 반복하면 사용자는 여전히 느리게 느낀다. 병목이 network인지 JavaScript execution인지 rendering인지 memory인지 먼저 측정해야 한다.
Amdahl's Law도 모델이다. 사용자가 체감하는 성능은 전체 처리 시간뿐 아니라 첫 meaningful paint, input responsiveness, progressive rendering, perceived performance에 영향을 받는다. 수식의 상한과 사용자 경험의 개선은 구분해야 한다.
하드웨어와 효율 개선은 사용량을 바꾼다
Moore's Law는 오랫동안 하드웨어 성능 증가에 대한 낙관의 배경이었다. 그러나 성능 증가가 예전과 같은 방식으로 계속된다고 가정하면 안 된다. 브라우저는 다양한 기기에서 실행되고, 저가형 모바일, 배터리 제한, thermal throttling, 오래된 OS가 현실의 사용자 환경이다.
Koomey's Law는 연산의 에너지 효율을 보는 관점을 제공한다. 프론트엔드에서는 배터리, CPU 사용률, 네트워크 비용, 데이터 사용량과 연결된다. 영상, 애니메이션, 실시간 동기화, AI 기능은 사용자의 기기 자원을 소비한다.
Jevons' Paradox는 효율이 좋아질수록 사용량이 늘 수 있다는 역설이다. 이미지 최적화가 쉬워지면 더 많은 이미지를 넣고, 번들러가 똑똑해지면 더 많은 라이브러리를 추가하고, AI 호출이 싸지면 더 많은 자동화를 붙일 수 있다. 효율 개선이 비용 절감으로 이어지는지, 사용량 증가로 상쇄되는지 관찰해야 한다.
클라이언트에 있는 비밀은 비밀이 아니다
Kerckhoffs's principle은 시스템 보안이 알고리즘의 비밀이 아니라 키의 비밀에 의존해야 한다는 원칙으로 알려져 있다. 웹 프론트엔드에서는 더 직접적인 결론이 나온다. 브라우저로 내려간 JavaScript, source map, feature flag, API endpoint, client-side validation logic은 사용자가 볼 수 있다.
따라서 다음은 비밀이 될 수 없다.
- 프론트엔드 bundle에 포함된 API key
- 클라이언트 코드에 숨긴 할인 정책
- UI에서만 막은 관리자 기능
- 난독화된 권한 체크
- source map에 남은 내부 경로와 주석
프론트엔드는 사용성을 위해 상태를 숨길 수는 있지만 보안 근거로 숨김을 사용할 수 없다. 권한 검사는 서버에서 수행하고, 비밀은 서버나 안전한 secret store에 두며, 클라이언트는 실패와 권한 부족을 명확히 처리해야 한다.
실무 관점
분산·성능·보안 제약은 다음 UI 설계 질문으로 바뀐다.
| 제약 | 프론트엔드 질문 |
|---|---|
| 네트워크 실패 | 실패, retry, offline, 중복 제출, abort를 어떻게 보여 주는가 |
| 일관성 지연 | stale data, optimistic update, conflict를 어떻게 표현하는가 |
| 병렬화 상한 | 실제 병목이 network, CPU, render, memory 중 어디인가 |
| 기기 차이 | 저가형 모바일과 느린 네트워크에서 핵심 흐름이 가능한가 |
| 효율 역설 | 최적화 후 사용량이 늘어 비용이 다시 커지지 않는가 |
| 클라이언트 노출 | 이 정보가 bundle에 있어도 안전한가 |
성능 주장은 측정 방법과 함께 있어야 한다. Chrome DevTools Performance 패널, Network 패널, Lighthouse, WebPageTest, React Profiler, bundle analyzer를 통해 병목을 확인한다. 보안 주장은 threat model과 함께 있어야 한다. 공격자가 클라이언트 코드를 읽고 요청을 직접 만들 수 있다는 전제에서 검토한다.
더 깊이
프론트엔드가 분산 제약을 잘 다루려면 서버 상태 모델이 필요하다. 서버 상태는 원격 원천, 비동기 lifecycle, stale 가능성, 공유 ownership을 가진다. 클라이언트 상태처럼 단순 setState로 다루면 race condition과 오래된 데이터가 생긴다.
성능에서도 총량보다 임계 경로가 중요하다. Amdahl's Law가 전체 작업의 병렬화 상한을 보여 준다면, Core Web Vitals와 interaction 측정은 사용자가 체감하는 병목을 보여 준다. 전체 로딩이 빨라도 첫 입력이 막히면 사용자는 느리다고 느낀다.
보안에서는 obscurity와 defense in depth를 구분해야 한다. 구현 세부를 불필요하게 노출하지 않는 것은 좋다. 그러나 노출되지 않는다는 가정에 보안을 의존하면 안 된다. 클라이언트 난독화는 비용을 높일 수는 있지만 권한 검사를 대체하지 않는다.
회고 질문
- 이 화면은 네트워크 실패와 지연을 정상 상태로 다루는가?
- 사용자에게 보이는 데이터가 stale일 수 있음을 어떻게 표현하는가?
- 성능 병목은 계측으로 확인했는가, 추측인가?
- 최적화가 비용 절감이 아니라 사용량 증가로 이어질 가능성은 무엇인가?
- 클라이언트 bundle에 포함된 정보가 공개되어도 안전한가?
정리
- 프론트엔드는 분산 시스템의 실패와 지연을 UI 상태로 번역하는 계층이다.
- CAP과 네트워크 오류 모델은 단순 분류보다 사용자에게 허용 가능한 불일치를 묻는 데 유용하다.
- Amdahl's Law는 병렬화 효과의 상한을 보게 하지만 사용자 체감 성능과 구분해야 한다.
- 하드웨어와 효율 개선은 비용을 없애기보다 사용량을 바꿀 수 있다.
- 클라이언트에 내려간 정보는 비밀이 아니므로 보안 근거를 서버와 키 관리에 둔다.
확인 문제
- optimistic UI로 저장 완료를 즉시 보여 주었지만 서버 충돌이 자주 발생한다. 어떤 질문이 필요한가?
정답과 해설
사용자가 견딜 수 있는 불일치 범위, 충돌 감지와 해결 방식, rollback/undo, sync indicator, 서버 확정 상태 표시를 검토해야 한다. 분산 상태의 일관성 지연이 UI 상태로 드러난 사례다.
- dashboard가 느려서 API 요청을 병렬화했지만 체감 속도가 그대로다. Amdahl's Law 관점에서 무엇을 확인해야 하는가?
정답과 해설
전체 시간 중 병렬화한 구간의 비율이 충분한지 확인해야 한다. 병목이 JavaScript 파싱, chart 렌더링, layout, main thread blocking이면 네트워크 병렬화 효과는 제한된다.
- 할인 정책을 프론트엔드 코드에 숨겨 두고 UI에서만 적용 조건을 막았다. 어떤 원칙과 충돌하는가?
정답과 해설
Kerckhoffs's principle과 클라이언트 보안 모델에 어긋난다. 브라우저로 내려간 코드는 사용자가 볼 수 있으므로 할인 정책과 권한 검사는 서버에서 검증해야 한다.
참고 자료
- <dwmkerr/hacker-laws>: 분산, 성능, 보안 관련 법칙의 원문 목록이다.
- Phase 2-1. HTTP semantics: 네트워크 요청과 실패 모델을 연결해 읽는다.
- Phase 3-8. 네트워크 API: fetch, abort, 비동기 요청의 경계를 연결한다.
- Phase 8-3. 웹 성능: 성능 계측 방법을 연결한다.
- Phase 8-4. 웹 보안: 클라이언트 보안 경계를 연결한다.