Outsider's Dev Story: Web 2.0 & Semantic 카테고리 글 목록https://blog.outsider.ne.kr/Stay Hungry. Stay Foolish. Don't Be Satisfied.2024-03-15T15:23:11+09:00Textcube 1.10.7 : Tempo primo[Book] HTTP 완벽 가이드: 웹은 어떻게 동작하는가Outsiderhttps://blog.outsider.ne.kr/14312019-02-28T04:31:46+09:002019-02-28T04:31:46+09:00<div>
<fieldset style="padding: 20px 5px 5px 5px;">
<legend><a href="https://coupa.ng/bgHk16">HTTP 완벽 가이드: 웹은 어떻게 동작하는가</a></legend>
<table>
<tbody>
<tr>
<td>
<a href="https://coupa.ng/bgHk16"><img src="//blog.outsider.ne.kr/attach/1/2738963024.jpg" alt="책 표지" title="" /></a>
</td>
<td style="vertical-align: top">
<a href="https://coupa.ng/bgHk16">HTTP 완벽 가이드: 웹은 어떻게 동작하는가</a> - ⭐⭐⭐⭐⭐
<br>데이빗 고울리, 브라이언 토티, 마조리 세이어, 세일루 레디, 안슈 아가왈 공저<br>이응준, 정상일 공역<br>인사이트
</td>
</tr>
</tbody>
</table>
</fieldset>
<br>
</div>
<p>이 책의 원서인 <a href="http://shop.oreilly.com/product/9781565925090.do">HTTP: The Definitive Guide</a>는 2009년에 나왔고 번역서는 2014년에 나왔다. HTTP/1.1은 1997년에 처음 발행되었고(물론 이 뒤에 몇 번의 개정이 되었지만 큰 내용이 바뀐 것은 아니다.) HTTP/2는 2015년에야 표준화가 되었기에 당연히 이 책도 HTTP/1.1까지만 다루고 있다. 번역서에서 2014년의 내용이 약간 반영되었지만, 원서가 10년 전에 쓰였기에 오래된 내용이 약간 보인다. 예를 들면 CGI에 대해서 설명한다거나 nginx에 대한 언급은 전혀 없다거나 하는 등이다.</p>
<p>그런데도 HTTP 자체가 그리 자주 바뀌지 않고 아직도 HTTP/1.1을 중심으로 사용하기 때문에 오래된 내용을 빼고 읽더라도 이 책의 가치는 여전히 높다. 웹 개발자는 물론 요즘 개발하면서 HTTP를 몰라도 되는 부분은 그리 많지 않다고 생각하기에 이 책을 읽어보기를 추천한다. <strong>보통 도구나 라이브러리에 의존해서 사용하기에 세부 내용을 몰라도 개발하는 데 큰 문제가 없다고 느낄 수도 있지만, 개인적으로 HTTP에 대한 이해는 필수 지식으로 생각하는 편이다.</strong> 2014년에 번역서가 나왔기에 HTTP/2를 설명하는 장을 역자분들이 추가해 주셔서 최신 HTTP 스팩까지 다 다루고 있는 것과 마찬가지다.</p>
<blockquote>
<p>왜 HTTP를 이해하는 것이 중요한가? 월드 와이드 웹을 지탱하는 가장 중요한 기술 두 가지는 HTML과 HTTP이다. 이 두 기술은 팀 버너스-리가 웹을 발명할 때 함께 만들어졌다. 이 둘 중 하나라도 빠지면 웹은 성립하지 않으며, 한편으론 이 둘만 있어도 어떻게든 웹은 성립할 수 있다.</p>
</blockquote>
<p>대부분의 "완벽 가이드"라는 제목이 붙은 책이 그렇듯이 이 책도 상당히 두꺼워서 700페이지가 넘는다. 이런 책은 레퍼런스 북 느낌이 있어서 뭔가 지루할 것 같고 두꺼워서 시작하기 어려운 느낌이 있는 편이고 책의 주제가 HTTP이다 보니 각종 헤더와 상태 코드에 대한 설명만 <strong>너무 지루하지 않을까 하는 막연한 생각에 손에 잘 안 잡혔는데 읽고 나니 너무 좋은 책이라 왜 이제 읽었나 싶었다.</strong> 주제가 데모나 코드를 보여주기 어려우므로 지루하기 쉽다고 생각하는데 메시지, 커넥션, 웹서버, 캐시 등 이해하기 쉽게 분류가 되어 있고 정리가 잘 되어 있어서 재미있게 읽을 수 있었고 나중에 해당 부분만 참고해 보기 좋게 구성되어 있다. 한번 정독을 하고 나중에 HTTP에 대해서 찾아보고 싶은 내용이 있을 때 다시 보면 좋을 것 같다. 개발하면서 가끔 특정 헤더나 사용 관련해서 헷갈릴 때가 있는데 읽고 나니 나중에 이 책을 다시 참고해 보면 아주 좋아 보인다. <strong>왜 이제야 읽었지 하는 생각을 하면서 읽었다.</strong></p>
<p>HTTP/0.9부터 HTTP/1.0, HTTP/1.1까지 다 다루고 있다. 2019년에 HTTP/1.0과 HTTP/1.1의 호환성을 구분해서 개발하는 경우는 거의 없다고는 생각하지만, HTTP/1.1까지 오기까지 어떻게 달라졌는지를 이해하면 왜 지금의 HTTP/1.1이 이런 형태가 되어 있는지 이해할 수 있어서 나한테는 꽤 유용했다. HTTP 자체에 관해서 설명하다 보니 HTTP를 사용하는 개발자의 입장보다는 HTTP와 호환되는 서버 혹은 프락시를 구현하는 개발자를 대상으로 각 헤더는 어떤 의미가 있고 어떻게 다루어야 하는지, 실제 구현에서는 어떤 문제가 있는지 등을 설명한다. HTTP를 직접 구현해서 사용할 일은 거의 없다고 생각하지만 사용하는 처지에서도 각 의미를 명확히 이해하고 있는 것은 개발할 때 도움이 많이 된다.</p>
<p>책을 읽으면서도 아예 몰랐던 배경이나 의미 등도 알게 되었고 알고 있었으나 명확하게 알지 못했던 부분을 알게 되어 HTTP에 대한 지식을 정리하는 데 꽤 많은 도움이 되었다. 아래는 읽으면서 기억해 두려고 체크해 놓은 내용을 적어놓은 것이다.</p>
<blockquote>
<p>HTTP는 웹에서 전송되는 객체 각각에 신중하게 MIME 타입이라는 데이터 포맷 라벨을 붙인다. MIME(Multipurpose Internet Mail Extensions, 다목적 인터넷 메일 확장)은 원래 각기 다른 전자메일 시스템 사이에서 메시지가 오갈 때 겪는 문제점을 해결하기 위해 설계되었다. MIME은 이메일에서 워낙 잘 동작했기 때문에, HTTP에서도 멀티미디어 콘텐츠를 기술하고 라벨을 붙이기 위해 채택되었다.</p>
</blockquote>
<blockquote>
<p>줄 바꿈 문자열은 'CRLF' 라고 쓴다. HTTP 명세에 따른다면 줄 바꿈 문자열은 CRLF이 지만 견고한 애플리케이션이라면 그냥 개행 문자도 받아들일 수 있어야 한다는 점을 언급할 필요가 있을 듯하다.</p>
</blockquote>
<blockquote>
<p>버전 번호는 분수로 다루어지지 않음에 주의하라. 버전의 각 숫자(예를 들어, HTTP/1.0의 '1'과 '0')는 각각 분리된 숫자로 다루어진다. 따라서 어느 쪽이 큰 지 HTTP 버전을 비교할 때 각 숫자는 반드시 따로따로 비교해야 한다. 예를 들어, HTTP/2.22는 HTTP/2.3보다 크다. 왜냐하면 22는 3보다 큰 숫자이기 때문이다.</p>
</blockquote>
<blockquote>
<p>서버 개발자들은 반드시 반환되는 헤더가 GET으로 얻는 것과 정확히 일치함을 보장해야 한다. 또한, HTTP/1.1 준수를 위해서는 HEAD 메서드가 반드시 구현되어 있어야 한다.</p>
</blockquote>
<blockquote>
<p>302, 303, 307 상태 코드 사이에서 중복되는 부분이 있음을 눈치챘을 것이다. 이 상태 코드들이 어떻게 사용되는가에 대해서는 약간 미묘한 차이가 있는데, 이는 주로 HTTP/1.0과 HTTP/1.1 애플리케이션이 이 상태 코드를 다루는 방식의 차이점에 기인한다. HTTP/1.0 클라이언트가 POST 요청을 보내고 302 리다이 렉트 상태 코드가 담긴 응답을 받으면, 클라이언트는 Location 헤더에 들어있는 리다이렉트 URL을 GET 요청으로(원래 요청에서 POST였던 것과는 달리) 따라갈 것이다. HTTP/1.0 서버가 HTTP/1.0 클라이언트로부터 POST 요청을 받은 뒤 302 상태 코드를 보내는 상황이라면, 서버는 클라이언트가 리다이렉션 URL에 대한 GET 요청으로 리다이렉트를 따라가길 기대한다. 그런데 HTTP/1.1이 혼란을 일으켰다. HTTP/1.1 명세는 그러한 리다이렉션을 위해 303 상태 코드를 사용한다(서버는 뒤이어 GET 요청이 오도록 POST 요청을 리다이렉션하기 위해 303 상태 코드를 보낼 수 있다). 이 혼란을 막기 위해, HTTP/1.1 명세는 HTTP/1.1 클라이언트의 일시적인 리다이렉트를 위해 302 상태 코드 대신 307 상태 코드를 사용하라고 한다. 그리고 서버는 302 상태 코드를 HTTP/1.0 클라이언트에게 사용하기 위해 남겨둘 수 있을 것이다.</p>
</blockquote>
<blockquote>
<p>두 가지 지속 커 넥션 타입이 있는데, HTTP/1.0+에는 'keep-alive' 커넥션이 있고 HTTP/1.1에는 '지속' 커넥션이 있다. keep-alive는 사용하지 않기로 결정되어 HTTP/1.1 명세에서 빠졌다. 하지만 아직도 브라우저와 서버 간에 keep-alive 핸드쉐이크가 널리 사용되고 있기 때문에, HTTP 애플리케이션은 그것을 처리할 수 있게 개발해야 한다.</p>
</blockquote>
<blockquote>
<p>HTTP/1.0 keep-alive 커넥션을 구현한 클라이언트는 커넥션을 유지하기 위해서 요청에 Connection:Keep-Alive 헤더를 포함시킨다. 이 요청을 받은 서버는 그다음 요청도 이 커넥션을 통해 받고자 한다면, 응답 메시지에 같은 헤더를 포함시켜 응답한다.</p>
</blockquote>
<blockquote>
<p>Keep-Alive 헤더는 커넥션을 유지하기를 바라는 요청일 뿐이다. 클라이언트나 서버가 keep-alive 요청을 받았다고 해서 무조건 그것을 따를 필요는 없다. 언제든지 현재의 keep-alive 커넥션을 끊을 수 있으며 keep-alive 커넥션에서 처리되는 트랜잭션의 수를 제한할 수도 있다. keep-alive의 동작은 Keep- Alive 헤더의 쉼표로 구분된 옵션들로 제어할 수 있다. timeout 파라미터는 Keep-Alive 응답 헤더를 통해 보낸다. 이는 커넥션이 얼마간 유지될 것인지를 의미한다. 하지만 이대로 동작한다는 보장은 없다.</p>
</blockquote>
<blockquote>
<p>HTTP/1.1에서는 keep-alive 커넥션을 지원하지 않는 대신, 설계가 더 개선된 지속 커넥션을 지원한다. 지속 커넥션의 목적은 keep-alive 커넥션과 같지만, 그에 비해 더 잘 동작한다. HTTP/1.1에서는 별도 설정을 하지 않는 한, 모든 커넥션을 지속 커넥션으로 취급한다. HTTP/1.1 애플리케이션은 트랜잭션이 끝난 다음 커넥션을 끊으려면 Connection: close 헤더를 명시해야 한다.</p>
</blockquote>
<blockquote>
<p>한 번 혹은 여러 번 실행됐는지에 상관없이 같은 결과를 반환한다면 그 트랜잭션은 멱등(idempotent)하다고 한다. GET, HEAD, PUT, DELETE, TRACE 그리고 OPTIONS 메서드들은 멱등하다고 이해하면 된다.</p>
</blockquote>
<blockquote>
<p>프락시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하고, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다. 실질적으로 프락시와 게이트웨이의 차이점은 모호하다.</p>
</blockquote>
<blockquote>
<p>Via 헤더 필드는 메시지가 지나는 각 중간 노드(프락시나 게이트웨이)의 정보를 나열한다. 메시지가 또 다른 노드를 지날 때마다, 중간 노드는 Via 목록의 끝에 반드시 추가되어야 한다. Via 헤더 필드는 쉼표로 구분된 경유지(waypoint)의 목록이다. 각 경유지는 개별 프락시 서버나 게이트웨이 흡을 나타내며 그들 중간 노드의 프로토콜과 주소에 대한 정보를 담고 있다.</p>
</blockquote>
<blockquote>
<p>캐시가 Date 헤더를 조정해서는 안 된다는 것에 주의하라. Date 헤더는 그 객체가 원서버에서 최초로 생겨난 일시를 표현하는 것이다.</p>
</blockquote>
<blockquote>
<p>HTTP/1.1은, 비록 콘텐츠가 조금 변경되었더라도 "그 정도면 같은 것"이라고 서버가 주장할 수 있도록 해주는 '약한 검사기(weak validator)'를 지원한다. 강한 검사기(strong validator)는 콘텐츠가 바뀔 때마다 바뀐다. 약한 검사기는 어느 정도 콘텐츠 변경을 허용하지만, 콘텐츠의 중요한 의미가 변경되면 함께 변경된다. 조건부 특정 범위 가져오기 같은 몇몇 동작은 약한 검사기로는 불가능하기 때문에, 서버는 'w/'' 접두사로 약한 검사기를 구분한다. ETag: w/"v2.6" If-None-Match: w/"v2.6"</p>
</blockquote>
<blockquote>
<p>HTTP/1.1 클라이언트는 만약 서버가 엔터티 태그를 반환했다면, 반드시 엔터티 태그 검사기를 사용해야 한다. 만약 서버가 Last-Modified 값만을 반환했다면, 클라이언트는 If-Modified-Since 검사를 사용할 수 있다. 만약 엔터티 태그와 최근 변경 일시가 모두 사용 가능하다면, HTTP/1.0과 HTTP/1.1 캐시 모두 적절히 응답할 수 있도록 클라이언트는 각각을 위해 두 가지의 재검사 정책을 모두 사용해야 한다.</p>
</blockquote>
<blockquote>
<p>Pragma: no-cache 헤더는 HTTP/1.0+와의 하위호환성을 위해 HTTP/1.1에 포함되어 었다. HTTP/1.1 애플리케이션은 Pragma: no-cache만 이해할 수 있는 HTTP/1.0 애플리케이션에 대응해야 하는 경우가 아니라면 Cache-Control: no-cache를 사용해야 한다.</p>
</blockquote>
<blockquote>
<p>'차셋(Charset)'은 형편없는 이름이다. 엄밀히 말해, MIME 차셋 태그(Content-Type charset 매개변수와 Accept-Charset 헤더에서 쓰이는)는 문자 집합을 의미하는 것이 결코 아니다. MIME 차셋 값은 데이터 비트를 고유한 문자의 코드로 매핑하는 알고리즘의 이름이다. 이것은 문자 인코딩 구조와 코딩된 문자 집합의 개념을 합친 것이다.</p>
</blockquote>
<blockquote>
<p>퓨니코드란 유니코드 문자열을 호스트 명에서 사용 가능한 문자만으로 이루어진 문자열로 변환하는 방법으로, RFC 3492로 정의되어 있다.</p>
</blockquote>
<blockquote>
<p>캐시는 반드시 캐시된 문서의 올바른 '최선의' 버전을 제공해주려 해야 하기 때문에, HTTP 프로토콜은 서버가 응답에 넣어 보낼 수 있는 Vary 헤더를 정의한다. Vary 헤더는 캐시에게(그리고 클라이언트나 그 외의 모든 다운스트림 프락시에게) 서버가 내 줄 응답의 최선의 버전을 결정하기 위해 어떤 요청 헤더를 참고하고 있는지 말해 준다.</p>
</blockquote>
<blockquote>
<p>Host 헤더는 관련 업체들이 HTTP/1.0을 확장해 만든 HTTP/1.0+에서 처음 소개되었다. HTTP/1.1 명세를 따르려면 Host 헤더를 반드시 기술해야 한다. Host 헤더는 브라우저와 서버 대부분이 지원하지만, 아직 몇몇 클라이언트와 서버(그리고 로봇)는 지원하지 않는다.</p>
</blockquote>
<blockquote>
<p>적중 계량(Hit Metering) 규약은 HTTP의 확장으로, 그 문제의 해결책으로 제시되었다. 적중 계량 규약에서는 캐시가 정기적으로 캐시 접근 통계를 원서버에 보고하도록 한다. RFC 2227은 적중 계량 규약을 상세히 정의한다.</p>
</blockquote>
<blockquote>
<p>벤더 트리는 상용 제품에서 사용되는 미디어 타입에 대한 것이다. 새로운 벤더 타입에 대한 공식적 검토는 장려되지만, 필수는 아니다. 벤더 트리 타입은 "vnd ."로 시작된다.</p>
</blockquote>
<p><strong><a href="https://blog.outsider.ne.kr/1431?commentInput=true#entry1431WriteComment">댓글 쓰기</a></strong></p>"HTTP/3 explained" 한국어 번역Outsiderhttps://blog.outsider.ne.kr/14302019-02-23T03:02:41+09:002019-02-23T03:02:33+09:00<p>1999년 <a href="https://tools.ietf.org/html/rfc2616">HTTP/1.1(RFC 2616)이 발행</a> 되고 2015년 <a href="https://tools.ietf.org/html/rfc7540">HTTP/2(RFC 7540)가 16년만에 발행</a>되었지만 너무 오래 기다려서 그런지 HTTP/2는 빠르게 업계에 도입되었다고 생각하는 편이다. HTTP/2에 큰 불만은 없었지만, 작년 11월 <a href="https://daniel.haxx.se/blog/2018/11/11/http-3/">QUIC이 HTTP/3가 되었다는 소식</a>을 접했다. HTTP/2가 나올 때도 이미 QUIC이 존재했기에 아직 최종 명세가 안 나왔어도 QUIC을 기반으로 한 HTTP/3에는 어떤 기능이 있는지 궁금했다. QUIC의 이름은 들어봤으나 HTTP/2가 나오면서 크게 신경을 안 썼기 때문에 HTTP/3로 다시 들려온 QUIC이 궁금해졌다.</p>
<p>그러다가 이달 초 <a href="https://http3-explained.haxx.se/en/">HTTP/3 explained</a>를 보게 되었다. HTTP/3의 내용을 정리해서 ebook 형태로 무료 제공을 하고 있는데 내용이 많지도 않고 HTTP/3에 관해 내용을 파악할 수 있을 것 같아서 번역을 해보려고 시작했다. 마침 일본어, 프랑스어, 이탈리어 등으로는 번역이 되어 있지만, 한국어로는 번역이 되어 있지 않았다. 기여도 할 겸 HTTP/3는 자세히 볼만한 가치가 있어 보여서 번역을 시작했다.</p>
<p>혼자 조용히 하다가 귀찮아 지면 멈추려고 맘 편히 2월 7일에 시작했는데 구독자가 6천 명도 넘는 <a href="https://www.youtube.com/channel/UCwjaZf1WggZdbczi36bWlBA">백기선 님이 유튜브에서</a> 2월 7일 <a href="https://www.youtube.com/watch?v=pAS84ZJF-Fg">GitHub 사용에 대한 방송</a>을 하다가 바로 내가 포크한 걸 보고 번역한다는 걸 눈치챘다. 이어서 <a href="https://github.com/outsideris/http3-explained/pulls?q=is%3Apr+is%3Aclosed">내가 번역해서 올린 내용을 교정</a>하면서 <a href="https://www.youtube.com/watch?v=fLaEmKGQDYg">방송으로도 번역하셨다</a>. 방송을 보고 오셨는지 <a href="https://github.com/outsideris/http3-explained/pulls?q=is%3Apr+author%3Ajukkume">jukkume님도 오셔서 번역을 리뷰해 주셨다</a>.</p>
<p>번역을 하다 보면 의미를 이해하고 풀어쓰는 데 집중하다 보니 좀 어색한 번역이 나오기 마련이다. 다시 읽어보면서 문장을 고치기는 하지만 전문 번역도 아니라서 너무 많은 시간을 들이지는 않는 편이다. 이번에는 두 분이나 내가 번역한 것을 리뷰해 주시니까 빨리 마무리해야겠다는 압박과 한국어로 잘 안 풀어지는 것은 결국 리뷰해주시겠지 하는 편안함을 둘 다 가지고 번역을 했다. 내용이 아주 많지는 않아서 한 2주 정도의 시간에 모든 번역을 마무리하고 <a href="https://github.com/bagder/http3-explained">원 저장소</a>에 머지했다.</p>
<p style="text-align: center;"><img src="//blog.outsider.ne.kr/attach/1/8422275656.jpg" width="750" height="704" alt="HTTP/3 explained 웹사이트" title="" /></p>
<p>이제 <a href="https://daniel.haxx.se/http3-explained/">HTTP/3 explained</a>에서 웹과 ebook 형식(PDF, Mobi, ePub)으로 <a href="https://http3-explained.haxx.se/ko/">한국어판</a>을 볼 수 있다. 책의 내용을 약간 설명하면 HTTP/3를 구현하는 세부 구현에 관해서 설명한다기 보다는 QUIC이 HTTP/3가 되기까지의 과정과 어떤 부분을 해결하고 있는지 왜 TCP가 아니라 UDP를 선택했는지 프로토콜에서 지원하는 기능은 무엇인지 등을 설명하고 있다. 아직 최종 스펙이 나오지 않고 진행 중이지만 이 책을 읽어보면 HTTP/3에 대해서 전반적으로 이해할 수 있게 될 거로 생각한다.</p>
<p>번역을 하다가 이 책을 쓴 Daniel Stenberg가 <a href="https://curl.haxx.se/">curl</a>을 만든 사람이란 걸 알고 좀 깜짝 놀랐다. 이번 <a href="https://github.com/bagder/http3-explained/pull/81">번역 PR이 머지</a>되고 한국어 쪽을 담당하게 되어 저장소에 접근 권한을 얻게 되었다.</p>
<p>책을 읽으면서 번역이 잘못되거나 어색한 부분이 있다면 언제든 Pull Request를 보내주면 검토 후 머지하도록 하겠습니다. 온라인 문서라서 이후 HTTP/3의 진행에 따라 책의 내용도 갱신될 것이라고 기대하고 있습니다.</p>
<p><strong><a href="https://blog.outsider.ne.kr/1430?commentInput=true#entry1430WriteComment">댓글 쓰기</a></strong></p>[번역] Microsoft Edge와 Chromium 오픈소스: 우리의 의도Outsiderhttps://blog.outsider.ne.kr/14162018-12-22T20:19:22+09:002018-12-22T20:19:22+09:00<p>Microsoft가 자사의 Edge 웹 브라우저를 Chromium 기반으로 바꾸겠다고 발표하면서 <a href="https://github.com/MicrosoftEdge/MSEdge">Microsoft Edge and Chromium Open Source: Our Intent</a>라는 글을 올렸다. 최근 몇 년간 오픈소스를 향한 Microsoft의 행보는 이미 알고 있었음에도 Microsoft의 상징 중 하나인 웹 브라우저를 다른 오픈소스 기반으로 바꿀 거라는 건 전혀 예상하지 못했다.</p>
<p>웹을 좋아하고 웹에서 오랫동안 작업을 해왔기에 이 변화는 꽤 충격적이었고 이 변화에 대한 내 의견과 상관없이 이 사건 자체가 웹에는 큰 의미가 있다고 생각해서 위 문서의 <a href="https://github.com/MicrosoftEdge/MSEdge/blob/master/LICENSE.txt">MIT 라이센스</a>하에 번역했다.(한글에는 이탤릭체가 없으므로 원문의 이탤릭체는 모두 볼드체로 바꾸었다.)<br />
<br><br></p>
<h1>Microsoft Edge와 Chromium 오픈소스: 우리의 의도</h1>
<p>작성자: Microsoft Edge 팀<br />
마지막 수정일: 2018-12-06<br />
<br></p>
<h2>이 문서를 작성한 이유</h2>
<p>지난 몇 년 동안 Microsoft는 오픈소스 소프트웨어(OSS) 커뮤니티에 의미 있는 참여를 늘려가면서 세계에서 가장 큰 OSS 프로젝트 후원사 중 하나가 되었습니다. 데스크톱 Microsoft Edge 개발에 Chromium 오픈소스를 도입하기 시작했습니다. Chromium 오픈소스에 더 많이 기여하고 더 큰 사용자가 되면서 고객에서 더 나은 웹 호환성을 제공하고 모든 웹 개발자를 위해 웹을 덜 분화되게 만들었습니다.</p>
<p><strong>이 작업을 어떻게 진행할지에 대해 우리 생각을 명확하게 하려고 이 문서를 작성했습니다</strong>.: Microsoft Edge와 Chromium 오픈소스 프로젝트와 관련한 우리 계획과 의도를 설명하려고 합니다. 이 문서의 내용과 관련 있고 유용하리라 생각한 독자는 (a) Chromium에서 승인자/메인테이너로 작업하면서 프로젝트를 이끄는 사람들, (b) 우리가 계획하고 있는 기여에 관심 있는 다른 브라우저를 만드는 회사와 엔지니어, (c) 광범위한 웹 개발자 커뮤니티, 기업 IT 관리자, Windows와 Microsoft Edge에서 우리와 작업하는 파트너 회사들입니다. 물론 이 모든 독자와 우리는 궁극적으로 이 작업의 혜택을 받을 최종 사용자를 먼저 고려합니다.<br />
<br></p>
<h3>TL;DR</h3>
<p>Microsoft Edge에서 오픈 소스로 작업하는 것은 새로운 일이 아닙니다. 1년 전 새로운 모바일 브라우저를 처음부터 오픈소스로 만들었습니다. 데스크톱 Microsoft Edge에서도 다양한 기능에 오픈소스를 사용했고(ANGLE, 웹 오디오, Brotli 등) ARM 기반 윈도우 기기에서 브라우징이 발전하도록 Chromium 프로젝트에 기여했습니다. 이러한 맥락에서 데스크톱 Microsoft Edge 개발에 Chromium 오픈소스 프로젝트를 도입해서 고객에서 더 나은 웹 호환성을 제공하고 모든 웹 개발자가 덜 파편화된 웹을 사용할 수 있도록 계획을 세우고 있습니다. 이제 앞으로 나갈 준비가 되었습니다.</p>
<p>PC와 다른 기기 모두에서 Microsoft Edge 뿐 아니라 다른 브라우저도 좋아질 수 있도록 Chromium의 핵심 기여자가 되고자 합니다. 아래 "Microsoft Edge의 OSS 원칙"과 "앞으로 할 일"에서 어떻게 기여할지를 명확하게 설명하고 있습니다.</p>
<p>수년간 효과적으로 동작하고 잘 정립된 오픈소스 모델을 받아들이는 것이 계획입니다. 장기간 신중하게 설계된 아키텍처와 협업 엔지니어링에 맞는 의미 있고 긍정적인 기여를 통해 여러 기기에서 웹을 사용하는 모든 사람에게 최상의 결과로 이어지도록 커뮤니티와 노력하고 있습니다.<br />
<br></p>
<h2>오늘날의 Microsoft와 웹</h2>
<p>문맥을 통해 우리의 <strong>의도</strong>를 절실하게 알게 되었습니다. 역사적으로 Microsoft는 세 가지 주요 고객층 최종 사용자, 개발자, 기업/조직에 집중해왔습니다. 이 고객들은 우리가 과거 Internet Explorer에 했던 투자와 현재 Microsoft Edge에 하는 투자를 알고 있습니다. 지난 몇 년 동안 고객의 목소리에 귀를 기울인 결과 환경의 복잡성이 증가해서 일관성, 단순성, 가독성, 호환성을 고객들이 바라고 있음을 알게 되었습니다.</p>
<p>수년간 Google 및 다른 브라우저 제조자와 효과적인 파트너 관계를 맺었다. 처음에는 W3C에서 지금은 WHATWG에서 더 가깝게 이 복잡성을 줄이고 웹의 전체적인 경험을 개선하려고 웹 플랫폼의 공통 표준을 만들었습니다. 업계의 브라우저 제조사가 상당한 진전을 보여 공통 표준을 준수하고 있지만, 기반을 둔 구현체가 다르고 릴리스 일정이 다르므로 오픈 웹 약속의 이점을 개발자가 완전히 누리기가 어려웠습니다.</p>
<p>우리는 브라우저 생태계에서 경쟁력 있고 다양한 시장 이점을 유지하면서도 Microsoft 고객에게 제공될 공통으로 호환되는 웹 플랫폼이 더 크게 발전할 수 있고 커다란 웹 커뮤니티에 공통<br />
커다란 웹 커뮤니티에 상호 이익을 줄 기회를 발견했습니다. 고객 유형에 걸쳐서 우리가 본 아래의 기회를 생각해 보세요.</p>
<ul>
<li><p><strong>최종 사용자</strong> - Microsoft Edge가 표준에 기반을 둔 HTML과 Chrome 등 많이 사용되는 브라우저에서 추가된 기능 모두에 아주 높은 호환성을 갖고 있음에도 불구하고 독자적인 웹 플랫폼 코드 베이스는 때로 호환성 문제를 겪었습니다. 이는 웹 개발자가 합리적으로 HTML 표준에는 덜 신경 쓰면서 고객이 겪을 경험을 개발하고 확인하려고 Chrome처럼 널리 사용되는 플랫폼에 더 집중하기 때문입니다. 계속해서 이러한 이슈를 수정하고 열심히 갱신했지만, 전체 윈도우 운영체제와 같은 일정에 따라 별도로 배포되는 컴포넌트인 Microsoft Edge의 구현체는 업데이트가 느리고 이에 따라 플랫폼 파편화와 호환성에서 빈틈을 보이게 되었습니다. 오픈소스 소프트웨어(OSS)를 더 많이 사용하면 최종 사용자의 이러한 경험을 개선할 수 있다고 생각했습니다.</p></li>
<li><p>Windows PC에서 Microsoft Edge 브라우저가 아닌 <strong>다른 브라우저</strong> 사용자는 때로 기기 종류에 따라 일관되지 않는 기능이나 성능/배터리 문제를 겪게 됩니다. 어떤 브라우저는 터치 기능이나 ARM 프로세서 같은 윈도우의 새로운 기능을 느리게 받아들입니다. 모두가 알다시피 우리는 최근 Chromium에 기반을 둔 브라우저에서 이런 종류의 하드웨어 지원을 기여하기 시작했습니다. Chromium 오픈소스에 새로운 기능을 기여해서 웹과 사용자 경험을 가속할 수 있고 이는 모든 브라우저와 사용자에게 이익이 된다고 생각했습니다.</p></li>
<li><p><strong>개발자</strong> - 다양한 종류의 기기가 끊임없이 늘어가고 웹의 사용이 늘어나면서 웹사이트 테스트와 관련한 복잡성과 부하가 엄청나게 커졌습니다. 웹 개발자, 특히 작은 회사에서 일하는 웹 개발자는 다양한 시스템을 테스트해야 하므로 작업 중인 웹사이트가 모든 기기와 브라우저에도 잘 동작한다고 확신하는 것이 거의 불가능해졌습니다. Microsoft Edge 웹 플랫폼이 다른 Chromium 브라우저와 연계하면 웹 개발자의 이러한 복잡도를 낮추고 다른 브라우저에서 사용할 수 있는 Windows의 기능을 의미 있게 정리해서 제공할 수 있습니다.</p></li>
<li><p><strong>IT 기업</strong> - IT 관리자는 사용자가 가진 기기나 회사 기기 등 아주 다양한 기기에서 새로운 웹사이트나 예전 웹사이트를 사용하는 사용자의 복잡성을 마주하게 됩니다. 기기 플랫폼에 상관없이 IT 기업의 브라우저를 위해 더 나은 웹 호환성을 만들고 웹 플랫폼을 정리할 때의 이미 있는 가치를 보았습니다.</p></li>
</ul>
<p><strong>우리가 (a) 여러 브라우저의 이득이 되도록 공유된 오픈소스 프로젝트에 가치 있고 새로운 기능을 만들고, (b) 대규모로 배포하는 브라우저에서 공유된 오픈소스의 사용을 높이면 위 모든 대상에게 공통적인 이득을 제공할 수 있다고 생각합니다. 이 두 가지 모두를 할 생각입니다.</strong><br />
<br></p>
<h3>웹 중심 오픈소스에 대한 최근 투자</h3>
<p>작년부터 Chromium과 WebRTC 오픈소스 프로젝트에 참여하기 시작했고(Microsoft에서 다양하게 참여하는 OSS 영역 중 하나로) 더 많은 기기 유형을 고려했습니다.</p>
<ul>
<li><p><strong>Chromium을 ARM64로 포팅하기</strong> : Chromium 기반 브라우저를 ARM 기기의 Windows에서 네이티브로 컴파일하고 실행할 수 있도록 Google 엔지니어와 협업을 많이 했습니다. 엔지니어링에 투자한 결과 ARM 기반 Windows PC에 Chromium 기반 브라우저를 네이티브 구현체로 곧 배포할 수 있게 되어 성능과 배터리를 상당히 개선할 수 있었습니다. 이는 Chromium에 투자해서 새로운 유형의 PC에서 브라우저의 웹 경험을 높일 수 있다는 좋은 예시가 되었습니다.</p></li>
<li><p><strong>Windows UWP 앱에서 Web RTC를 활성화하는 작업</strong>: 1년 이상 Universal Windows Platform(UWP)의 WebRTC 작업을 했습니다. 그 결과 데스크톱, Xbox, 홀로렌즈/VR, IoT를 포함해 모든 Windows 10 플랫폼에서 개발자에게 WebRTC 솔루션을 제공할 수 있었습니다. 지난주 WebRTC Lib의 UWP 용으로 포크한 작업을 WebRTC.org 저장소에 다시 넣기로 Google과 합의했습니다.</p></li>
<li><p><strong>ANGLE 개선</strong>: 과거에 ANGLE의 D3D11 백엔드와 성능을 개선했습니다. 최근에는 ANGLE를 Microsoft Edge의 WebGL 공식 백엔드로 만들려고 Intel, ANGLE 팀과 협업했습니다.</p></li>
</ul>
<p>이러한 작업을 통해 웹에서 오픈소스 기여가 수수하지만, 여전히 의미 있다는 것을 알게 되었고 협업하면서 사용하는 방법과 건전하게 Chromium에 기여하는 방법에 관해 가치 있는 관점을 갖게 되었습니다. Microsoft의 OSS 전문성이 커지고 더 많이 집중하게 되면서 웹 팀은 이러한 교훈을 받아들이고 수많은 사람의 웹 경험을 바꿀 수 있어서 기쁩니다.<br />
<br></p>
<h2>Microsoft Edge + 오픈소스: Microsoft의 새로운 방향</h2>
<p>더 깊게 들어가 보겠습니다. OSS 기여자와 파트너에게 우리 의도를 투명하게 공개하기 위해 이 문서를 작성했습니다.<br />
<br></p>
<h3>Microsoft Edge의 OSS 사용</h3>
<p>Microsost Edge 모바일 브라우저와 Microsost Edge 데스크톱의 일부 컴포넌트에서 이미 Chromium 오픈소스를 사용하고 있었지만 Microsost Edge 데스크톱에서 Chromium 오픈소스를 훨씬 더 많이 사용하고 커뮤니티에 기여를 많이 하기로 결정했습니다.</p>
<p>Microsoft Edge에서 이러한 진화의 핵심 관점은 다음과 같습니다.</p>
<ol>
<li><p><strong>Microsoft Edge 데스크톱의 웹 플랫폼으로 Chromium을 도입할 것입니다</strong>. 호환성을 높이고 개발자의 테스트 매트릭스를 간단하게 하려고 Microsoft Edge의 웹 플랫폼을 (a) 웹 표준에 맞추고 (b) 또 하나의 Chromium 기반 브라우저로 만들려고 합니다.</p></li>
<li><p><strong>Microsoft Edge 앱의 아키텍처를 발전시켜서 Windows 7, Windows 8, Windows 10을 포함한 모든 버전의 Windows에서 배포할 수 있게 할 것입니다. macOS 같은 다른 데스크톱 플랫폼에서도 Microsoft Edge를 배포할 것입니다</strong>. : 최종 사용자(더 높은 호환성)와 개발자(더 적은 파편화)의 웹 경험을 개선하려면 최대한 널리 사용될 수 있는 일관된 웹 플랫폼이 필요합니다. 이를 위해 Chromium의 크로스 플랫폼 앱 기술을 사용하고 우리 배포 모델을 바꿔서 지원하는 모든 운영체제에서 Microsoft Edge의 경험과 Microsoft Edge를 이용할 수 있도록 하겠습니다.</p></li>
<li><p><strong>Windows에서 모든 Chromium 기반 브라우저의 경험을 개선하기 위해 Windows 플랫폼의 전문적 지식을 제공할 것입니다</strong>. : 위에서 설명한 작업과 일관되고 유익한 새로운 기술의 기여해서 Chromium 오픈소스에 더 많이 참여하는 것이 우리 생각입니다. Windows에서 더 좋은 웹을 만드는 것이 우리의 고객, 파트너, 사업에 좋다는 것을 깨달았습니다. 그래서 이를 위해 활발히 기여할 생각입니다. 배터리 수명, 터치, 접근성, 보안, 공통 관심 영역에서 Chromium 커뮤니티와 파트너로 일할 기회가 생겨서 기쁩니다.<br />
<br></p></li>
</ol>
<h3>우리의 기여: 원칙과 기대</h3>
<p>이 문서의 핵심 목표는 우리가 어떻게 기여하고 Chromium 브라우저에 가치 있는 새 기술을 도입할 때 필요한 엔지니어링 계획을 어떻게 시작할지를 Chromium OSS에 이미 참여하고 있는 팀과 사람들에게 알리는 것입니다.</p>
<p>커다란 Chromium 프로젝트에 더 깊이 참여하게 되어 기쁩니다. 이는 심사숙고한 결정이었으면 다음 단계로 옳은 결정이라고 믿고 있습니다. 즉, 배우는 자세로 이 단계를 받아들일 것입니다. Chromium을 사용하고 기여하면서 이미 많은 것을 배웠고 넓은 커뮤니티와 협업하면서 다시 기여할 수 있기를 기대하고 있습니다. 시간이 지나면 참여하는 내용과 범위가 달라질 것입니다.</p>
<h3>Microsoft Edge의 OSS 원칙</h3>
<ol>
<li><p><strong>장기적인 관점으로 결정했습니다</strong>. Chromium 프로젝트에서 우리의 엔지니어들이 배우면서 전문가가 되어 커뮤니티에서 활발하고 책임 있는 멤버로 성장하기를 기대하고 있습니다. Chromium 프로젝트에 더 많이 기여하고 계속 유지 보수할 것입니다.</p></li>
<li><p><strong>웹 플랫폼의 개선점을 찾을 때 우리가 취할 기본자세는 기여하는 것입니다</strong>. 다양한 사용자 경험 기능 및 연결된 서비스로 Microsoft Edge를 세계 수준의 브라우저로 제공하는데 집중하고 있습니다. 하지만 새로운 플랫폼 기능과 관련해서는 '모두가 혜택을 얻을방법(rising tide that floats all boats)'을 찾을 것입니다. Windows에서 ARM64 지원, 접근성, 보안, 터치 입력, 전력 개선 등의 영역에서 의미 있게 기여하고 버그를 수정하면서 시작할 것입니다.</p></li>
<li><p><strong>웹 오픈소스 프로젝트의 본질이면서 Chromium을 성공하게 만든 아키텍처 요구사항과 엔지니어링 접근을 존중합니다</strong>. 다중 기기 지원, 다중 OS 지원, 철저한 실시간 엔지니어링 등 Chromium OSS 및 다른 프로젝트를 관리하는 많은 관점이 있습니다. 역사적으로 우리 회사는 Windows PC에 집중해왔고 Windows에서 브라우저를 개선하는 기여를 할 수 있다고 믿어왔지만, Android를 포함해서 넓은 범위의 기기를 받아들이는 웹 OSS 프로젝트를 이해하고 이러한 기여가 기기의 다양성을 수용해야 한다고 생각합니다. Chromium의 크로스 플랫폼과 크로스 디바이스의 요구사항에 맞춰서 아키텍처를 설계하고 일관되게 기여할 것입니다.</p></li>
<li><p><strong>오픈 웹의 진화는 표준 커뮤니티에서 가장 잘 이뤄지고 오픈 웹은 다양한 관점에서 열린 토론을 할 때 이득을 얻는다고 생각합니다</strong>. 경쟁적으로 브라우저를 개발하는 제조사의 관점과 더 커다란 웹 커뮤니티의 목소리를 듣고 고려한 뒤 W3C, ECMA, WATWG에서 표준 논의에 활발하게 참여할 것입니다.<br />
<br></p></li>
</ol>
<h3>기여: 처음에 집중할 영역</h3>
<p>OSS 작업을 하면서 우리 엔지니어링 전문성으로 사용자와 개발자에게 가장 큰 차이를 만들 수 있는 곳을 고려해서 기여할 때 "집중할 영역"의 초기 목록을 만들었습니다.</p>
<p>Chromium의 모든 고객을 위해 Chromium 코드베이스에 의미 있는 가치를 만들고 함께 배우면서 실천할 수 있는 시작점으로 이 목록을 생각하고 있다는 점을 강조하고 싶습니다.</p>
<ul>
<li><p><strong>ARM64</strong> - Chromium 코드베이스가 ARM-64을 지원하도록 포팅하는 작업을 마무리해서 이러한 기기에서 네이티브로 지원하는 브라우저로 만들 생각입니다.</p></li>
<li><p><strong>접근성</strong> - 모든 고객의 요구사항을 맞추기 위해 Microsoft UI Automation(UIA) 인터페이스를 Chromium 코드베이스에 추가하는 작업을 할 것입니다. 이를 통해 고 대비, 자막 스타일, 접근성 제어 개선, 삽입 기호(caret) 브라우징 지원 같은 Windows 접근 센터 단축키(Ease of Access) 설정을 통합해서 Windows에서 나레이터 기능과 다른 보조 기술을 지원할 수 있습니다.</p></li>
<li><p>터치 같은 최신 입력 방식을 위한 <strong>PC 하드웨어 진화</strong> - 특히 최신 Windows 기기의 데스크톱 터치, 제스처 인식, 자연스러운 스크롤/패닝을 개선할 수 있습니다.</p></li>
<li><p><strong>보안</strong> - 모든 브라우저 제조사는 당연히 웹 사용자를 최대한 안전하게 보호하는 것이 가장 중요합니다. 공유된 이 목표를 위해 Chromium 보안팀과 긴말하게 협력하고 특히 Windows 플랫폼에서의 일반적인 보안 프로그램에 대한 우리의 경험과 전문 지식으로 기여할 수 있기를 기대합니다.<br />
<br></p></li>
</ul>
<h2>앞으로 할 일</h2>
<p>이는 Microsoft와 Microsoft Edge 팀에게 있어서 큰 도약이고 Chromium 프로젝트에도 큰 진전이 될 것입니다. 그리고 커다란 웹 커뮤니티에 이득이 될 것이라고 강하게 믿고 있습니다. Chromium 프로젝트 내에서 우리가 공통 웹 플랫폼을 어떻게 발전시킬 수 있을지 Google 및 Chromium 프로젝트의 다른 기여자들과 함께 참여하려고 합니다. 동시에 차별화된 사용자 경험 기능 및 연결된 서비스로 Chromium 오픈소스로 만들어진 Microsoft Edge 브라우저가 경쟁하는 가치를 인식하고 최고의 비전을 제시하려고 합니다.</p>
<p>표준 단체에서의 작업과 이전에 공유한 엔지니어링 노력으로 이미 Chromium의 많은 기여자와 긍정적인 작업 관계를 맺었습니다. 이렇게 오픈 웹 구현에 기여하는 제일 나은 방법을 배우면서 관계를 구축하기를 기대하고 있습니다.</p>
<p>이 문서를 따르면서 다음에 취할 행동을 구체적으로 설명하려고 간단한 목록을 준비했습니다.</p>
<ol>
<li>위에서 설명한 영역에서 어떻게 기여할 수 있을지 Chromium 프로젝트 내 여러 분야 엔지니어링 책임자와 연락을 시작할 것입니다. 이는 Google뿐 아니라 다른 회사도 포함되어 있습니다.</li>
<li>WHATWG, W3C뿐 아니라 OEM 파트너와 상호작용이 많은 개발 파트너 등 핵심 파트너에게 Microsoft Edge의 이번 전략 변화를 알릴 것입니다.</li>
<li>블로그에 공개적으로 발표해서 관심 있는 외부 커뮤니티 사람들이 이 전략 변경을 투명하게 알 수 있도록 하겠습니다.</li>
<li>이 문서를 GitHub에 올려서 관심 있는 개발자나 웹 커뮤니티 멤버가 이 계획을 읽을 수 있도록 하겠습니다.</li>
</ol>
<p>Chromium 프로젝트에 함께 참여하기 시작했으므로 당신의 의견이나 조언, 피드백을 환영합니다.</p>
<p><strong><a href="https://blog.outsider.ne.kr/1416?commentInput=true#entry1416WriteComment">댓글 쓰기</a></strong></p>회원가입 시 이메일/아이디가 중복될 때의 응답 HTTP status codeOutsiderhttps://blog.outsider.ne.kr/11212015-01-31T19:37:01+09:002015-01-31T19:37:00+09:00<p>회원가입을 만들다가 갑자기 궁금한 생각이 들었다.(처음 만들어 보는 것도 아닌데!!) 회원가입을 하려고 POST 요청을 보냈는데 이메일이 겹치거나 아이디가 겹칠 경우 서버의 응답 상태코드는 무엇이 되어야 하는가? 물론 스펙을 떠나서 200 OK로 응답을 주고 응답 보디에서 결과를 보내주는 방법도 현실적으로는 가능한 방법이지만 이건 또 다른 주제의 내용이므로 여기서는 스펙을 따른다고 했을 때를 전제로 한다.<br />
<br></p>
<h2>400 Bad Request</h2>
<p>처음에는 <strong>400 Bad Request</strong>로 구현을 했다.</p>
<blockquote>
<p>The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.<br />
-<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html">RFC 2616</a></p>
</blockquote>
<p>RFC 2616에 따르면 위와 같이 정의가 되어 있다. 요청에서 지켜야 할 문법을 제대로 지키지 못해서 서버가 이해를 못 했기 때문에 튕겨낸다는 것인데 회원 가입 같은 경우는 곰곰이 생각해 보면 이 상황에 어울려 보지는 않는다. 회원가입 같은 경우 요청은 정상적이고 클라이언트 입장에서는 요청을 보내기 전에는 알 수 없는 상태이기 때문이다.</p>
<blockquote>
<p>The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).<br />
- <a href="http://tools.ietf.org/html/rfc7231#section-6.5.1">RFC 7231</a></p>
</blockquote>
<p>하지만 RFC 2616의 개정판인 RFC 7231에서는 <code>400 Bad Request</code>의 의미가 좀 더 광범위해서 서버가 처리 못 하는 것뿐 아니라 어떤 오류로 처리하지 않는 부분에도 <code>400</code>을 쓸 수 있다고 정의하고 있다.(스펙의 해석은 어려운 부분이긴 하지만..) 그래서 스펙대로라면 이제(RFC 7231에서 개정되었으므로) 400도 사용 가능하다고 생각한다.<br />
<br></p>
<h2>409 Conflict</h2>
<p>상태코드에는 <strong>409 Conflict</strong>코드도 존재한다.</p>
<blockquote>
<p>The request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict.<br />
-<a href="http://tools.ietf.org/html/rfc7231#section-6.5.8">RFC 7231</a></p>
</blockquote>
<p>리소스의 현재 상태와 충돌해서 요청을 처리할 수 없으므로 클라이언트가 요청을 다시 클라이언트가 이 충돌을 수정해서 요청을 다시 보낼 경우가 Conflict다.(RFC 2616과 큰 차이는 없다.) 내가 이해하기에는 지금의 상황에 가장 적합하게 느껴진다.<br />
<br></p>
<h2>403 Forbidden</h2>
<p>관련해서 찾다 보니 유효성 검증 실패에는 403을 써야 한다는 의견도 있었다. 보통 403이 인가(Authroization) 실패로 생각하지만, RFC 2616에는 그렇게 명시하고 있지 않으므로 403이 적합하다는 말이다.(이메일이나 아이디 중복도 유효성 검사의 과정이긴 하지만 여기서는 비밀번호나 아이디 자릿수나 허용 문자 등의 유효성 검증에 더 가까워 보인다.)</p>
<blockquote>
<p>The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.<br />
-<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html">RFC 2616</a></p>
</blockquote>
<p>하지만 RFC 7231에서는 사람들이 일반적으로 생각하는 대로 인가에 사용하도록 명시하고 있으므로 이제는 이견의 여지는 없어 보인다.</p>
<blockquote>
<p>The server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).<br />
- <a href="http://tools.ietf.org/html/rfc7231#section-6.5.3">RFC 7231</a></p>
</blockquote>
<p><br><br></p>
<p>이래저래 고민하다가 나는 <strong>409 Conflict</strong>를 쓰기로 했다. 여러 가지를 비교해 본 결과 가장 적합하다고 생각해서...(스펙은 항상 어렵;;)</p>
<p><strong><a href="https://blog.outsider.ne.kr/1121?commentInput=true#entry1121WriteComment">댓글 쓰기</a></strong></p>Kickstarter에 대한 생각Outsiderhttps://blog.outsider.ne.kr/8182012-08-10T02:56:06+09:002012-08-10T02:56:06+09:00대부분의 개발자들이 그렇지만 새로운 웹서비스도 많이 써보면서 많은 자극도 받고 제가 만들어 보고 싶은 서비스나 프로그램도 많이 생각하다보니 서비스에 대한 생각을 좀 정리해보고 싶다는 생각을 하게 되었습니다. 이는 뭐 제가 전문가도 아니니 평가라기 보다는 서비스들에 대한 생각을 정리해보고 나중에 다시 보면서 안목을 늘리기 위함이고 다른 사람의 생각을 듣고 싶은 마음입니다. 한두달 전에 트위터에도 올리긴 했는데 그 뒤에도 한번도 올리지 못했네요. 기술얘기보다는 좀 추상적이기 때문에 글로 정리하기가 쉽지은 않군요.<br><br><br><b><font size="5">매력적인 Kickstarter</font></b><br><font color="#CC9900"><a href="http://www.kickstarter.com/" target="_blank">Kickstarter</a>는 아실만한 사람은 다 알만한 서비스이지만 간단히 설면하면 홈페이지에 "Kickstarter is the world's largest funding platform for creative projects."라고 나온대로 음악, 기술, 영화, 디자인 등 다양한 분야에서 프로젝트를 올리면 다수의 사람들이 펀딩에 참여하고 펀딩받은 금액으로 프로젝트를 진행하는 플랫폼입니다. </font><br><br><div class="imageblock center" style="text-align: center; clear: both;"><img src="//blog.outsider.ne.kr/attach/1/1046544699.gif" alt="KickStarter 로고" height="59" width="500" /></div><br>어떻게 보면 아이템을 가지고 있지만 사업을 위해서 투자가 필요한 스타트업과 스타트업에 투자하는 엔젤투자자나 벤처캐피탈의 관계를 온라인으로 옮겨놓았다고 할 수 있습니다. 그런 면에서 <a href="http://ko.wikipedia.org/wiki/%EA%B7%B8%EB%9D%BC%EB%AF%BC_%EC%9D%80%ED%96%89" target="_blank">그라민은행</a>을 온라인으로 만들어놓은 <a href="http://www.kiva.org/" target="_blank">Kiva</a>와도 유사합니다. 엄청난 돈을 가진 VC나 엔젤투자자는 아니지만 투자자의 수를 수백, 수천으로 분산해서 투자자(?)는 소액을 투자하고 사업자는 필요한 자금을 유치할 수 있습니다.<br><br>실제 Kickstarter를 이용해서 펀딩을 받거나 펀딩을 해본 적은 없어서 디테일한 세부사항은 모르지만 Kickstarter는 아주 매력적입니다. 스타트업이나 회사의 규모보다도 작은 경우 투자를 받는 다는 것은 무척 어려운 일인데 Kickstarter에 오렸을 때 사람들에게 주목을 받으면 아이디어를 구현할 투자를 받을 수 있습니다. 이는 아이디어를 가졌지만 딱히 투자를 받기 어려웠던 사람들에게는 고무적인 일이고 Kickstarter가 인기를 얻은 덕분에(물론 그 배경에는 좋은 아이디어의 아이템들이 많이 있었습니다.) 펀딩에 참여할 준비가 된 많은 사람들이 Kickstarter에 머물고 있습니다.<br><br>그리고 한편으로 <font color="#CC9900">Kickstarter는 홍보의 효과도 줄 수 있는듯 합니다.</font> 대기업처럼 인프라를 갖지 않은 스타트업들에게는 좋은 아이디어와 구현물이 있다고 하더라도 사람들에게 알리는 것이 문제입니다. 그래서 많은 아이디어들이 사람들이 인지하지도 못한 채 사라져갑니다. 하지만 Kickstarter에서 인기를 얻게 되면 미리 사람들에게 자신의 제품을 알릴 수 있고 제품이 완성될 때까지 이러한 주목을 어느정도 유지할 수 있습니다. 제품을 출시하기도 전에 이런 포지션을 가질 수 있다는 것을 생각한다면 엄청난 매리트입니다.<br><br>저는 이런 서비스를 좋아합니다. 생산자와 소비자가 모두 자연스럽게 윈윈할 수 있으면서 그동안 존재하지 않았던 새로운 가치를 창출했다고 생각합니다. (큐레이션에 대한 책은 보지 않았지만 개인적으로 그닥 흥미를 못 느끼는 UI만 좀 괜찮아진 북마킹서비스에다가 억지로 큐레이션이라는 말을 갖다 붙이는 것보다 이런 서비스가 더 큐레이션에 가깝다고 봅니다.)<br><br><br><b><font size="5">Kickstarter에 대한 우려</font></b><br>Kickstarter를 처음 알게 된 순간부터 아주 매력적이라고 생각했지만 보면 볼수록 약간씩 우려되는 점들이 있습니다.(이런 우려에도 불구하고 아직까진 잘 나가고 있는듯 합니다.)<br><br><div class="imageblock center" style="text-align: center; clear: both;"><img src="//blog.outsider.ne.kr/attach/1/1220727230.jpg" alt="Kickstarter" height="192" width="550" /></div><br><br><b><font size="4">과도한 펀딩</font></b><br>Kickstarter를 보고 있으면 펀딩이 좀 과한 것 아닌가 하는 생각이 종종 듭니다. 얼마전 <a href="http://www.kickstarter.com/blog/ouyas-big-day" target="_blank">가장 많이(혹은 빨리) 펀딩을 받은 아이템에 대한 글</a>을 Kickstarter에서 올린적이 있습니다. 그 순위는 다음과 같습니다.<br><br><ol><li>OUYA - $2,589,687.77</li><li>Double Fine Adventure - $1,064,652.05</li><li>Pebble - $863,132.92</li><li>Wasteland 2 - $555,407.84</li><li>Shadowrun Returns - $378,008.28</li><li>Amanda Palmer - $223,348.50</li><li>The Icarus Deception - $178,194.00</li><li>Elevation Dock - $161,507.00</li><li>Penny Arcade Sells Out - $151,221.17</li><li>gTar - $138,891.00</li></ol>위 기록은 저 글을 적는 시점의 금액입니다. 안드로이드 기반의 콘솔게임기인 <a href="http://www.kickstarter.com/projects/ouya/ouya-a-new-kind-of-video-game-console" target="_blank">OUYA</a>는 6만여명에게서 $8,596,475의 투자금을 유치했습니다. 이 금액은 100억원에 가까운 돈입니다. 어드벤처 게임인 <a href="http://www.kickstarter.com/projects/doublefine/double-fine-adventure?ref=live" target="_blank">Double Fine Adventure</a>는 37억원정도를 유치했고 아이폰/안드로이드와 연동되는 시계인 <a href="http://www.kickstarter.com/projects/597507018/pebble-e-paper-watch-for-iphone-and-android?ref=live" target="_blank">Pebble</a>는 110억정도를 유치했습니다. 이렇게 최상위 제품외에도 새로운 IDE인 <a href="http://www.kickstarter.com/projects/ibdknox/light-table?ref=live" target="_blank">Light Table</a>은 3억5천정도를 모았습니다. 실제로 목표했던 금액을 훨씬 웃도는 금액들입니다.<br><br>물론 이렇게 크게 유치하는 만큼 빈익빈 부익부현상이 발생하는 것일 수도 있고 (킥스타터에서는 펀딩이 잘 안되는 제품들은 찾아보기가 좋지 않습니다.) 제품의 가치는 쉽게 금액으로 판단할 수 없기에 합당하냐 아니냐를 말하는 것이 조심스럽기는 합니다. 하지만 저는 이런 인기 제품들을 보면서 펀딩이 과도하다는 느낌을 지울 수 없었습니다. 회사라는 입장에서 보면 몇억, 몇십억정도의 금액은 큰 금액이라고 말할 수는 없지만 과연 킥스타터가 아니라 직접 펀딩을 유치했으면 저정도의 금액을 벌 수 있었을까? 아니면 펀딩없이 제품을 릴리즈했을 때 저 금액을 벌어들일 수 있었을까 하면 좀 회의적입니다.<br><br><br><b><font size="4">리스크에 대한 보상??</font></b><br>또 한편으로는 펀딩에 참여하는 사람들이 리스크에 대한 어떤 보상을 받는 느낌이 별로 없습니다.(저만 그럴지도...) Kickstarter에 올라온 제품들은 동영상이나 사진등으로 제품을 보여주고 있기는 하지만 실제로 만져볼 수 있는 제품은 없는 상태이고 대부분은 여러달 후에나 제품이 나오는 상황입니다. 펀딩을 안해봐서 정확히는 모르지만 아마 펀딩참여할 때 돈을 입금할 테니 돈을 미리주고 물건을 나중에 받는 것입니다.<br><br>이건 당연히 리스크입니다. 그리고 제품이 릴리즈되었을 때 기대했던 것과 똑같은 제품이 나온다는 보장도 없습니다만 믿고 투자를 한 것입니다. 수많은 회사들이 만들겠다고 한 것과 다른 제품을 완성하고 수많은 프로젝트들이 개발도중 산으로 가는 것을 생각하면 Kickstarter에 올라온 제품들이라고 소비자의 기대를 완전히 충족시켜주는 회사들만 모여있을 리가 당연히 없습니다. 그러면 기대한 제품을 제대로 받지 못할 수도 있는 리스크를 감당한 채 미리 돈을 준 것입니다.(정확한 돈이 결재되는 시점은 잘 모르겠습니다만 킥스타터는 목표금액을 이뤘을 때만 지급하기 때문에 펀딩이 끝나는 시점에 결제가 되지 않나 생각합니다.)<br><br>VC나 엔젤투자자도 비숫한 위치라고 할 수도 있지만 Kickstarter에서는 좀 다릅니다. VC나 엔젤투자자는 투자를 하고 실제 성공을 했을 때 계약에 따라 수익을 나눠갖게 됩니다. 하지만 Kickstarter에서는 보통 제품을 받게 됩니다. 금액에 따라 옵션이 추가된다거나 고급 제품을 준다거나 하는 등의 차등을 두고 릴리즈 되었을 때 그에 대한하는 제품을 주는 방식입니다. 제품이 릴리즈 되면 당연히 판매를 할 것이므로 회사는 추가수익을 얻겠지만 투자자는 약속된 제품을 받고 끝입니다. <br><br>제 기준에서는 리스크를 감당하는 대신 훨신 싸게 구매를 할 수 있어야 할것 같은데 그다지 싸지 않습니다. Kickstarter에서 제가 관심을 가진 제품들은 꽤 있지만 결국 구매는 하지 않은 것이 비싸서입니다. 아이패드용 키보드케이스인 <a href="http://www.kickstarter.com/projects/552506690/brydge-ipad-do-more" target="_blank">Brydge</a>도 제품만으로는 엄청 갖고 싶은 제품이었지만 스피커없는 모델이 170불로 거진 20만원 정도합니다. 아이패드 키보드케이스중에 최고라 생각하지만 다른 제품과 비교했을 때 비싼것이 사실입니다.(아니면 출시했을 때는 훨씬더 비싸거나...) 위에서 얘기한 라이트테이블도 50불인데 소프트웨어를 많이 구입하는 저로써도 50불이 넘는 개발도구는 몇가지 안됩니다. 몇가지 사려고 했다가도 리스크는 있지만 이익은 없는것 같아서 그냥 약간 더 비싸지더라도 제품 나온거 보고 사자! 쪽으로 기울었습니다.(몇개월짜리 예판처럼 보여서...)<br><br>실제로 <a href="http://www.kickstarter.com/projects/552506690/brydge-ipad-do-more" target="_blank">Brydge</a>같은 경우 펀딩후에 <a href="http://www.zdnet.com/brydge-ipad-keyboard-gets-a-reboot-7000002010/" target="_blank">힌지의 디자인을 초기의 미려한 디자인에서 이상한 디자인으로 바꾼다고</a> 올렸다가 많은 비난을 사고 있습니다. 이런 경우를 포함해서 아예 프로젝트 자체가 실패했을 경우 어떻게 되는가도 궁금할 따름입니다.<br><br><br><br>아무쪼록 우려는 우려고 창의적인 프로젝트가 원할하게 진행될 수 있도록 한 컨셉은 무척 맘에 들기 때문에 이러한 문제를 잘 해결하고 잘 성장하길 바랄 뿐입니다. ㅎㅎ<br><p><strong><a href="https://blog.outsider.ne.kr/818?commentInput=true#entry818WriteComment">댓글 쓰기</a></strong></p>