직접 만들지 말라 …

• Don't Roll Your Own ... 원칙은 암호화뿐 아니라 웹 UI에도 적용되며, 브라우저가 이미 안정적으로 제공하는 기능을 불필요하게 대체하지 않아야 함
• 자체 스크롤, 링크 처리, 텍스트 선택, 복사·붙여넣기 같은 기본 동작 대체는 익숙한 입력 반응을 깨뜨려 사용자가 조작 방식을 다시 신경 쓰게 만듦
• GitHub의 파일·이슈 링크처럼 JavaScript가 링크 탐색을 가로채면, 현재 탭에서 처리되기를 기다리는 것보다 새 탭으로 여는 편이 더 빠를 때가 있음
• 기본 비밀번호 필드와 <input type="date">는 자동완성, 비밀번호 관리자, 접근성 도구, 모바일 키보드와 협력하므로 가짜 UI로 바꾸면 기능이 깨질 수 있음
• 몇 달마다 바뀌는 레이아웃과 폼 컨트롤은 사용자가 업무보다 재학습에 시간을 쓰게 하며, 안정적인 브라우저 기본 동작을 유지하는 편이 바람직함

---

“직접 만들지 말라” 원칙의 웹 UI 적용

• 암호화 직접 구현 금지는 민감한 데이터를 보호하는 운영 소프트웨어에서 검증되지 않은 사설 구현에 의존하지 말라는 원칙임
• 암호화 코드를 아무도 작성하면 안 된다는 뜻이 아니라, 가능한 한 검토되고 검증된 패키지와 도구를 사용해야 한다는 뜻에 가까움
• 약 20년 전에는 부적절한 초기화 벡터, 예측 가능한 키스트림, 평문 일부 유출 같은 문제가 있는 자체 RC4 구현이 실제로 존재했음
• 현재 주요 전자상거래 사이트나 은행은 일반적으로 웹 서비스에 자체 암호화를 쓰지 않으며, 결제·의료·개인정보 처리 같은 규제 영역에서는 강한 암호화 요건 위반이 큰 벌금으로 이어질 수 있음
• 웹사이트 디자인은 암호화와 같지 않지만, 브라우저가 이미 잘 처리하고 사용자가 매일 의존하는 기능을 다시 구현하면 사용자 경험이 나빠질 수 있음

브라우저 기본 기능을 대체할 때 생기는 문제

• 페이지 스크롤을 직접 구현하면 마우스, 터치패드, 키보드 입력에 대한 익숙한 반응이 깨질 수 있음
• 기본 스크롤 동작을 덮어쓰면 페이지가 너무 느리거나 빠르게 움직이고, 키보드 스크롤이 작동하지 않을 수도 있음
• 사용자가 의식하지 않고 쓰던 동작이 낯선 동작으로 바뀌면, 페이지 조작 자체를 다시 신경 써야 함
• 직접 구현하지 말아야 할 대표 기능에는 링크 탐색, 텍스트 선택, 컨텍스트 메뉴, 복사·붙여넣기, 비밀번호 필드, 날짜 선택기가 포함됨
• 진지한 업무용 웹사이트에 사용자 인터페이스 기능을 넣을 때는 화려한 기능을 추가할지, 브라우저 기본 동작에 맡길지 보수적으로 결정할 필요가 있음

링크 탐색과 GitHub 사례

• 웹브라우저는 링크를 따라가는 일을 이미 잘 처리하며, 링크 탐색은 브라우저의 핵심 기능임
• 정상적인 링크 동작을 방해해야 한다고 느껴진다면, 달성하려는 목표가 일반적인 링크 탐색을 깨뜨릴 만큼 중요한지 다시 검토해야 함
• GitHub에서는 파일 링크나 이슈 링크를 클릭하면 JavaScript로 구현된 큰 기능이 클릭 처리를 대신함
• Firefox나 Chrome에서 F12로 개발자 도구를 열고, Debugger 또는 Sources 탭의 Event Listener Breakpoints에서 Mouse의 click을 선택한 뒤 GitHub 링크를 클릭하면 이 동작을 확인할 수 있음
• GitHub에서 현재 탭의 JavaScript 탐색 처리를 기다리는 것보다 새 탭으로 링크를 여는 편이 더 빠를 때가 있음

비밀번호 입력과 날짜 선택기

• 브라우저의 비밀번호 입력 필드는 비밀번호 저장, 자동 입력, 새 계정용 강한 비밀번호 생성 기능을 제공할 수 있음
• 기본 비밀번호 필드는 안전하지 않은 HTTP 연결로 비밀번호가 제출될 때 경고하고, 비밀번호 관리자·자동완성·모바일 키보드·접근성 도구와도 협력함
• 가짜 비밀번호 필드로 대체하면 이런 기능이 깨질 수 있으며, 일반 텍스트 필드를 직접 마스킹하면 브라우저·운영체제·보조 도구가 비밀번호를 일반 가시 텍스트처럼 다룰 수 있음
• <input type="date">는 날짜 범위 선택을 직접 지원하지 않지만, 시작일과 종료일 입력 필드 2개를 제공하면 브라우저 기본 날짜 선택기를 유지할 수 있음
• 사용자 정의 날짜 선택기는 구현마다 방식이 달라, 연도 보기로 확대해야 하거나 생년을 고르기 위해 이전 연도 버튼을 수십 번 눌러야 하거나 날짜 직접 입력이 막힐 수 있음
• 기본 날짜 선택기 지원이 부족한 브라우저에 달력 위젯이 필요하다면, <input type="date">를 대체하지 말고 같은 필드를 조작하는 보조 위젯으로 추가하는 편이 나음

잦은 UI 변경의 비용

• 폼 컨트롤을 함부로 바꾸면 기존 문제를 해결하는 동시에 새로운 문제를 거의 항상 도입함
• 웹사이트 레이아웃과 인터페이스를 몇 달마다 바꾸면 일부 사용자는 적응하더라도, 나이 든 사용자는 매번 새로운 도구를 배우는 것과 같은 부담을 겪음
• 여러 웹사이트가 계속 인터페이스를 바꾸면 사용자는 기능적 이득 없이 익숙한 것을 다시 배우는 데 상당한 시간을 써야 함
• Linux 배포판이 몇 달마다 핵심 명령과 명령줄 옵션을 모두 다시 설계하거나, 세탁기 버튼 배치가 매일 아침 바뀌는 상황처럼 반복적인 UI 재배치는 불쾌한 경험이 됨
• 웹 UI는 사용자가 업무를 끝내기 위해 쓰는 도구이므로, 브라우저가 이미 제공하는 익숙하고 안정적인 동작을 불필요하게 대체하지 않는 편이 바람직함

[kirinonakar]

우리나라처럼 자체 암호화, 자체 보안 프로그램이 많은 나라가 없을 것 같네요.

[GN⁺]

Lobste.rs 의견들

• 페이지 스크롤을 직접 구현하지 말라는 데는 동의함. 네이티브만큼 잘 만들 수 없고, 예외로 인정할 만한 건 지도처럼 스크롤이 확대/축소로 매핑되는 관례가 있는 경우 정도임

  링크 내비게이션을 직접 구현하지 말라는 걸 규칙으로 삼는 데는 강하게 반대함. 일반 콘텐츠 사이트라면 클라이언트 측 라우팅(CSR)을 권하지 않겠지만, 어떤 앱에서는 오히려 적극 권장할 수 있고 GitHub 같은 서비스는 중간쯤에 있음

  다만 항상 실제 <a href> 요소를 써서 브라우저의 네이티브 기능이 동작하게 해야 함. 웹메일 클라이언트 같은 앱은 CSR을 쓰는 게 맞고, GitHub도 예전처럼 가볍게 적용했을 때는 개선됐지만 최근 프론트엔드 접근은 꽤 나빠졌음

  문제는 CSR이 너무 자주 허술하게 구현되고, 나쁜 네트워크 조건에 강건하게 만들지 않는다는 점임. 브라우저는 이런 상황에 강하고, 탭 로딩 표시나 bfcache 같은 최적화도 CSR에서는 방해받을 수 있음

  텍스트 선택 직접 구현은 모바일에서 손가락을 형광펜처럼 쓰는 주석 앱 같은 아주 특수한 경우만 예외로 볼 수 있음. 오히려 ::selection도 쓰지 말라고 덧붙이고 싶음. ::selection{}을 스타일시트에 추가하는 것만으로 선택 영역이 안 보이게 되는 건 나쁜 설계임

  컨텍스트 메뉴 직접 구현 금지에는 반대함. 이메일 클라이언트, 파일 관리자, 워드프로세서 같은 앱에서는 자체 항목이 필요하고, 브라우저가 확장 방법을 제공하지 않으니 완전한 커스텀 메뉴가 지금은 실용적인 선택임. Firefox에서는 Shift+우클릭으로 네이티브 메뉴를 강제로 열 수 있어 다행임

  복사/붙여넣기 직접 구현 금지는 해석에 따라 동의할 수도, 반대할 수도 있어 더 명확해야 함

  비밀번호 필드를 직접 구현한 사례는 기술 데모 외에는 거의 본 기억이 없음. 표시/숨김 버튼으로 <input type>을 password에서 text로 바꾸는 정도는 여기에 해당하지 않는다고 봄

  날짜 선택기를 직접 구현하지 말라는 데도 반대함. 네이티브 컨트롤을 권장하고 싶지만 한계와 불일치가 크고, 지난 10년간 고치려는 관심도 거의 없었음. 선택기에 정보를 덧붙일 수 없고, 생년월일처럼 오래전 날짜를 고르는 동작은 어떤 플랫폼에서는 끔찍함. 예: Safari's date-picker is the cause of 1/3 of our customer support issues

  커스텀 날짜 선택기는 접근성 문제가 많지만 보통 사용자에게는 더 나은 경우도 잦고, 네이티브 컨트롤에 없는 기능이 필요해 못 쓰는 경우도 많음. 단순 날짜 선택은 내가 쓰는 브라우저에서는 직접 입력이 가능해 네이티브를 선호하지만, 많은 사용자에게는 네이티브가 충분히 좋지 않음. 날짜 범위는 <input type=date> 두 개로 만들면 대부분에게 훨씬 나빠질 가능성이 큼

  • 접근성 고려가 필요하거나 그 혜택을 받는 사람들과 “보통 사람”을 대비시키는 표현은 일부 독자를 소외시키기 쉽다. 실제로 접근성 보조를 쓰는 사람들의 경험과 필요를 꽤 신경 쓰는 것 같아 보여서 더 짚고 싶어짐

  • Safari의 날짜 선택기를 직접 써보니 얼마나 제한적인지 알겠음. 그런데 왜 웹사이트들이 네이티브 날짜 선택기를 캘린더 위젯으로 대체하는지 늘 궁금했음

    캘린더 위젯을 네이티브 위젯 옆에 함께 둘 수는 없을까? 입력 방법이 두 개로 보일 수 있어 UI가 헷갈릴 수는 있지만, 적절한 라벨로 하나를 고급 날짜 선택기라고 표시하면 해결할 방법이 있을 것 같음. 그러면 네이티브 날짜 선택기를 편하게 쓰는 사람은 잃지 않고, 브라우저의 날짜 선택기가 부족한 사람도 도움을 받을 수 있음

    문서 작성 도구나 다이어그램 작성기 같은 웹앱에서 컨텍스트 메뉴가 필요하다는 건 알지만, 우클릭했을 때 브라우저의 일반 메뉴가 사라지면 여전히 불편함. 그래서 Firefox 설정에서 보통 dom.event.contextmenu.enabled = false를 둠. 그러면 Firefox 메뉴가 위에, 웹앱 메뉴가 뒤에 뜨지만 네이티브 메뉴가 동작하니 괜찮은 우회책임. 가능하면 웹앱의 메뉴 막대를 쓰고, 브라우저 네이티브 컨텍스트 메뉴는 건드리지 않는 쪽이 더 좋음. Shift+우클릭 팁도 좋은 해결책임

  • 접근 가능한 컨트롤이 필요한 사람들도 정상적인 사람임

  • 비밀번호 필드를 직접 구현한 사례는 페루의 거의 모든 은행에서 볼 수 있음

    날짜 선택기는 네이티브를 쓰고 싶지만 구현자 쪽에서 개선하려는 관심이 별로 없어 보임. Firefox에는 시간/시계 선택 UI 관련 이슈가 있고, 진행이 더딤: https://bugzilla.mozilla.org/show_bug.cgi?id=datetime

• 웹 폼에서는 좋은 지적임. 브라우저에 기대는 게 가장 단순하고 빠르며 거의 항상 가장 일관적인 방법임

  하지만 암호학 코드 쪽은 다름. 올바른 암호 코드를 작성하는 게 쉽지는 않지만 불가능하지도 않음. 어떤 상황에서는 선택지가 너무 적어서 직접 만드는 게 최선일 수도 있음

  여기서 보안 정통파가 문제인 건 새 암호 코드를 작성하려면 자기들 내부 집단에 속해야 한다고 단정하는 경향임. 암호학 박사 학위나 DJB, Dan Boneh 밑 인턴 경력을 보이지 못하면 암호 코드를 쓰면 안 된다는 식임. “학습용”은 괜찮지만, 배운 걸 실제로 적용하려 하면 안 된다고 함. 심지어 외부 집단의 실제 역량을 알아보는 데도 어려움을 보이는 경우가 있음. 흥미롭게도 이런 보안 정통파와 논문을 쓰는 실제 암호학자의 겹침은 매우 작아 보임

  이제는 메모리 안전하지 않은 언어로 아무것도 쓰지 말라고까지 확장되고 있음. 치명적 취약점의 70%가 그렇다 해도 실제 원인은 무엇이었나? 스택에 없는 작은 객체마다 malloc()이나 명시적 new를 쓰거나, 널 종료 문자열을 다루는 데서 대부분 문제가 생겼을 거라고 봄. 아레나와 슬라이스를 썼다면 그런 문제는 훨씬 적었을 것임. 물론 어떤 고위험 시나리오에서는 특정 버그 부류를 완전히 제거해야 하며, 그때는 메모리 안전성이 최우선임

  다음은 신뢰할 수 없는 입력을 처리하는 건 아무것도 쓰지 말라는 걸까? 기존 바퀴가 전부 네모난데도 바퀴를 다시 만들지 말라는 걸까? 그래도 JavaScript 비대화를 피하고 브라우저가 제공하는 폼을 쓴다면, 자체 웹 프레임워크를 만드는 것까지 크게 문제 삼지는 않을 것 같음

  • C의 원죄는 배열을 넘길 때 상한 정보를 잃고 포인터로 붕괴되는 데 있다고 봄

  • “직접 암호를 만들지 말라”는 절대 명제가 아니라 강한 경고로 이해해 왔음. 박사 학위가 없어도 안전하게 구현할 수 있다는 점은 맞지만, 여전히 엄청난 학습이 필요함

    명세를 꼼꼼히 구현하는 수준이면 훨씬 덜 필요할 수 있음. 하지만 대부분의 소프트웨어는 빠른 암호 구현을 원하고, 그러면 복잡도가 크게 올라감. 링크한 Monocypher 취약점도 좋은 예임. 갑자기 쌍유리 동치와 Edwards 점, Montgomery ladder가 어떻게 연결되는지 알아야 함

    박사 학위 같은 자격은 다른 사람들이 당신이 뭘 하는지 안다고 신뢰하는 데 도움을 줌. 감사도 다른 경로임. Monocypher는 Cure53의 박사 두 명에게 감사를 받은 것으로 보임. 문제는 대부분의 프로그래머가 암호 라이브러리가 안전한지 판단할 준비가 안 돼 있어서, 자격이나 감사자의 자격 같은 비기술적 신호에 의존하게 된다는 점임. 더 직접적인 방법이 있으면 좋겠지만, 자격은 꽤 괜찮게 동작함

  • 직접 암호를 작성하는 게 가능하다는 건 당연함. 불가능했다면 암호 라이브러리도 없었을 것임. 핵심은 할 수 있느냐가 아니라, 사용자 비밀번호를 해시하고 개인 데이터를 보호하는 운영 환경에서 당신이나 내가 손수 만든 암호를 신뢰할 수 있느냐임. 나는 신뢰하지 않음

  • 예전 직장에서 오래된 코드가 라이선스 검사에 MD5를 쓰고 있었고, 낡은 C++ 코드를 실행할 수 없는 환경에서 검증해야 해서 MD5를 재구현해야 했음. 기존 라이브러리를 찾았지만 IV 변경을 지원하는 게 없었음

  • 직접 암호를 만들 용기는 없지만, 보안 업계가 이제는 자체 인증도 하지 말라고까지 하는 건 조금 지나쳐 보임

• 브라우저가 직접 구현하지 않아도 쓸 만한 다중 선택 필드를 제공해 주면 좋겠음

  • 있긴 한데 형편없음

• <input type="date"> 두 개로 시작일과 종료일을 받는 방식은 날짜 범위에는 번거롭고 직관적이지도 않음. 개념적으로 하나인 것을 시각적으로 관련 없어 보이는 두 개의 별도 뷰로 나누게 됨

  날짜 범위가 없다는 건 <input type="date">의 여러 문제 중 하나일 뿐임. 예를 들어 특정 날짜를 제외할 수 없어서 예약 서비스를 제공하는 거의 모든 경우에는 출발점부터 쓸 수 없음

  날짜를 어디서나 같은 방식으로 쓰기 위해 입력 두 개라는 작은 비용을 감수하겠다는 입장이 주류일지는 의심스러움. 평균 사용자는 필드를 싫어하고, 한 필드보다 더 나쁜 건 두 필드임. 익숙함 논리도 설득력이 약함. 내 경험상 웹에서 네이티브 날짜 입력은 드묾

  • 날짜 범위 시작일과 종료일에 각각 제대로 동작하지 않는 커스텀 캘린더 위젯을 두 개 붙인 웹사이트를 여럿 봤음. 엎친 데 덮친 격임

  • 날짜 범위 부분에는 나도 동의하지 않았음. 날짜 범위는 개념적으로는 단일 컨트롤이지만 실제로 얼마나 복잡할 수 있는지 보여주는 예로 자주 씀. “항상 네이티브 컨트롤을 써라”는 구호는 문제에 더 특화된 더 나은 컨트롤을 제공할 수 있을 때 사용자 경험을 오히려 나쁘게 만들 수 있음

    네이티브로 구현할 수 없는 날짜/날짜 범위 컨트롤의 유용한 기능으로 가격 표시가 있음. 항공권이나 호텔을 찾을 때 어느 날이 더 싼지 비싼지 날짜 선택기 안에서 바로 보이면 매우 유용함. 네이티브 컨트롤이라면 그 정보를 보려면 훨씬 많이 클릭하거나 별도 표를 봐야 하지만, 커스텀 컨트롤은 날짜마다 그런 메타데이터를 붙일 수 있음

    고전적인 예는 생년월일 입력임. 날짜 선택기는 보통 현재 달 한 달을 기본으로 보여주는데, 원하는 날짜와 거의 관련이 없어서 최악임. 여기서는 커스텀 컨트롤을 쓸 수도 있지만, 텍스트 박스 조합이 더 나은 경우도 많음. 완전한 자체 컨트롤이라기보다는 네이티브 컨트롤 조합이지만, 모든 경우를 잘 처리하는 “만능” 날짜 선택기는 없다는 게 핵심임

• 몇 년 전 일이라 다시 확인해야 하지만, html5 날짜 선택기 대신 직접 구현할 수밖에 없던 안타까운 이유가 있었음. 일부 브라우저의 <input type=date> UI가 정말 끔찍했음

  컨텍스트 메뉴 직접 구현은 드물지만 필요할 때는 아주 유용함. 예를 들어 웹페이지 안에서 다이어그램 편집기를 만든다면, 다이어그램의 노드를 클릭해 유용한 작업을 할 수 있도록 커스텀 컨텍스트 메뉴를 만들어 줬으면 함. 모든 상호작용을 왼쪽 클릭 UI, 예컨대 동작 팔레트와 노드를 번갈아 클릭하는 방식으로만 몰아넣는 건 좋지 않음

  목록의 나머지 항목에는 강하게 동의함

• 암호학 예시와 스크롤 동작 문제를 어떻게 같이 해석해야 할지 모르겠음. 둘은 매우 다른 영역처럼 느껴짐

  웹사이트가 너무 많은 일을 한다는 일반론에는 동의함. 다만 그 동작은 사용자와 웹사이트의 목표에 따라 달라짐

  prefers-reduced-motion처럼 prefers-user-scroll 같은 설정이 중간 지점의 해결책이 될 수 있지 않을까?

  • 세로 스크롤 영역을 구현하기 위해 스크롤재킹을 쓰는 정당한 사용 사례는 없음. 그런 코드는 애초에 작성되지 말았어야 함

    다만 이 말은 세로 스크롤 영역에 한정함. 스크롤을 비스크롤 동작으로 다시 매핑하는 경우에는 사용 사례가 있고, 여전히 매우 문제가 많지만 세로쓰기 문자 체계에서 세로를 가로로 매핑하는 경우도 논의할 수 있음. 그 밖에도 한두 가지 정당한 사용 사례가 있을 수 있지만, 실제 구현 방식은 보통 여전히 잘못돼 있음

• 페이지 스크롤 직접 구현 금지에는 강하게 동의함. KotlinConf에서 Compose Multiplatform for Web의 스크롤 구현 어려움을 다룬 흥미로운 발표를 들었음

  문제 중 하나는 웹 브라우저가 네이티브 앱보다 스크롤 이벤트를 덜 보내서, 스크롤 방향 계산 알고리즘이 실패했다는 점이었음. 모든 점을 지나가는 포물선을 그리고 마지막 점에서의 기울기를 쓰는 방식인데, 점이 너무 적으면 스크롤 방향이 반대로 나올 수 있음

  다른 플랫폼에서 이식하거나 이런 상호작용을 다시 구현할 때는 잘못된 가정으로 시작하거나, 브라우저가 기본 제공하는 “이상한” 동작을 잊기 쉬움

  • 원래 앱에서 그런 스크롤 이벤트가 무엇에 쓰였길래 웹 맥락에서도 복제해야 했는지 궁금함. 스크롤을 무언가의 구동 입력으로 쓰는 방식에는 조금 의심이 듦

• “플랫폼에 기대라”는 조언은 정확하지만, 플랫폼을 계속 따라가는 일은 어렵다. enterkeyhint나 inputmode처럼 존재는 대충 알지만 효과를 잊는 것들이 있음

  이번 주 우리 팀이 이를 돕기 위해 [0]을 공개했음. 구현 모범 사례를 스킬 형태로 제공함. 문서도 사람이 읽기 꽤 좋음. 예: [1]

  [0] https://github.com/GoogleChrome/modern-web-guidance
  [1] https://github.com/GoogleChrome/modern-web-guidance/…

• 글의 어조가 어긋나 있음. 사람들이 언제, 왜 바퀴를 다시 만들 필요가 없는지 충분히 이해하도록 설명하는 쪽이 훨씬 생산적임

  글은 이유 설명은 잘하지만, “직접 만들지 말라”는 독단적 표현 때문에 덜 좋아짐

  “직접 암호를 만들지 말라”는 구호도 결국 교리처럼 느껴짐. 그것을 쓸 줄 아는 전문가는 누구이고 누가 그들을 임명했나? 그렇게 말하기 전에 직접 코드를 들여다봤나? Heartbleed 같은 취약점을 보면 실제로는 초보적인 실수였다는 걸 알 수 있지 않나?

  • 그들은 암호학에 인생을 바친 사람들임. 누가 임명한 게 아니라, 유용한 연구를 발표하고 해당 분야를 아는 사람들의 검증을 거치며 자격을 얻었음

    알고리즘은 공개되고, 검토되고, 공개적으로 공격받고, 개선되고, 표준화됨. 닫힌 문 뒤에서 이뤄지는 일이 아님. 논문도 공개되어 있고 코드도 공개되어 있음. 언제든 볼 수 있음. 당신이 보지 않았다고 아무도 보지 않은 건 아님. 사람들은 들여다보고 깨려고 시도함. 우리가 쓰는 이유는 공격을 견뎌냈기 때문임

    Heartbleed를 보고 내놓을 해법이 OpenSSL을 직접 다시 구현하는 것이라면, 당신이 만든 OpenSSL에는 실제 OpenSSL의 Heartbleed 하나마다 쉰 개의 Heartbleed가 있을 것이라고 장담함. 차이는 실제 OpenSSL은 아는 사람들이 검토하고, 테스트하고, 감사하고, 공격하고, 고친다는 것임. 당신 것은 비공개로 틀린 채 남아 있을 뿐임

  • 핵심은 AES 호출을 겁 없이 할 줄 아는 무결한 전문가가 있다는 게 아님. 안전하게 동작하는 인기 래퍼를 쓰면 버그가 생겨도 한 곳에서 발견하고 고칠 수 있다는 점임

    새로운 부채널 공격이 발견돼도 한 곳에서 대응할 수 있음. 직접 만든 것은 새로운 공격을 계속 추적하는 데 전업으로 시간을 쓰지 않는 한 그런 개선을 얻지 못함

• 이건 웹 도구를 형편없이 쓰는 사람들에 대한 불평에 가깝다. 직접 구현이 타당한 사용 사례까지 다뤘다면 더 흥미로웠을 것임. 그래야 독자가 “절대 직접 하지 말라”는 유치한 모델 대신 유용한 걸 배울 수 있음

  숙련이란 직접 만들 지식과 기술을 갖추고, 언제 그렇게 하지 말아야 하는지 아는 지혜를 함께 갖는 것임

  그래도 불만에는 공감함. 나도 비슷한 불만이 많았음. 문제는 웹 상호작용을 웹 개발자가 쉽게 참조할 수 있을 만큼 철저하고 포괄적으로 문서화하려는 노력이 많지 않았다는 데 있음. 프로그래밍 인접 지식이 제대로 문서화되고 다음 세대로 전달되지 못하는 심각한 문제가 있어서, 같은 문제를 계속 재발견하게 됨. 보통 업계 안에서는 표준적인 동작과 상호작용 묶음이 승자로 자리 잡지만, 아무도 그것을 적어 두지 않음