Javascript Polyfill CDN Service

Financial Times 에서 자바스크립트 및 HTML5 에 최대한 유연하게 대응할 수 있는 CDN을 공개했다.

일단 링크를 보라. https://cdn.polyfill.io/v1/

귀찮게 뭐하러 polyfill 찾아 구하는가?

얘가 그냥 브라우저 확인해서 알아서 polyfill 해준다.

닥치고 써라. HTML5를 여러 브라우저에 최대한 쓰고싶다면.

composite / 2015년 1월 30일 / 미분류 / 0 Comments

CloudFlare로 DNS에 보안을 더하는 방법

내가 아래 포스트에 아무리 CloudFlare 라 해도 허점으로 인한 진짜 IP 뽀려내기 글을 올렸었다.

그렇다면 네트워크 관리자는 이 안전하다는 CloudFlare DNS에 진짜 보안을 더할 것인가? 고민이 많지만 이미 cloudFlare 에서도 언급한 내용이다.

하지만 되새김질 하라는 의미이기도 하고 모르거나 관심없었던 관리자도 얼렁 관심을 가져서 서버 보안에 도움이 되라고 쓴다.

내친구도 저거 쓰니까.

1. direct.domain.com 등의 쉽게 다이렉트로 연결되는 도메인을 차단하라.

CloudFlare 는 도메인 세팅할 때 direct 라는 서브도메인을 기본으로 세팅한다. 이걸 통해 진짜로 들어갔을 때에 대한 경우를 비교하라고. 아시다시피 CloudFlare 의 웹 캐싱은 당신이 리소스를 바꾼다 해도 적용하는 시간이 클라이언트마다 틀리다. 최적화를 해주는 대신 업데이트 주기가 길다는 소리. 그래서 주어진 것이지만, CloudFlare 는 Development mode 라는 기능이 제공되기 때문에 그딴거 필요없다. 그 이유는 아래에 설명한다.

2. Development mode 는 테스트시에만 잠깐 이용하라.

Development mode 는 개발시 자주 있는 리소스 변경 사항을 바로 적용할 수 있도록 캐싱 기능을 잠시 꺼두는 기능이다. 기본적으로 3시간이 주어지며, 연장 가능하거나 해제할 수 있다. 하지만 이 기능은 오픈 전 테스트에서만 사용하는 것을 권장하고, 별도의 도메인을 만들어 별도의 테스트를 진행할 것을 권장한다.

3. MX 레코드는 공개된다. 가능하면 공개형 메일 서비스를 이용하라.

메일 프로토콜은 DNS 검색 툴로도 금방 뽀록난다. 왜냐면 메일은 정방향과 역방향 둘 다 쓰기 때문에, 도메인과 IP 둘다 뽀록난다. 그러므로 MX 레코드는 가능하면 구글 등의 메일 서비스를 이용하는 것을 추천한다. 요즘 메일 서비스는 자체 메일 서버보다 훨 나을 것이다. 자체 메일 서버를 사용할 거면 내부적으로만 사용할 것을 추천한다. 메일 서버도 해킹 놀이터의 대상이기 때문이다.

4. 불필요한 직접 바인딩을 자제하라.

CloudFlare 로 보안성과 성능이 향상된 웹 사이트를 쓰면서 직접 바인딩으로 서비스 할 거면 CloudFlare 뭐하러 쓰는가?

5. CloudFlare 서비스가 불필요한 (웹 서비스 외) 도메인은 CloudFlare 가 아닌 다른 DNS 서비스를 이용하라.

웹 서비스가 아니라면 CloudFlare 안 쓰는게 낫다. CloudFlare 는 웹 서비스를 위한 DNS 관리를 제공하는 그 이상 그 이하도 아니다. 다양한 DNS 레코드 종류 등록을 지원하지 않기 때문에, 만약 다른 통신 서비스를 사용해야 한다면 DNS도 바꾸는 것을 추천한다.

끝.

composite / 2014년 5월 19일 / 미분류 / 0 Comments

Cloudflare 로 호스팅하는 웹 사이트의 진짜 IP 뽀려내기.

요즘 한국인도 CloudFlare 를 많이 이용하는데,

주로 해외에 효율적인 캐싱 서비스로 트래픽 조절을 할 수 있는 서비스라서 이용한다.

물론 뉴스타파같이 국내에 중점을 두는 사이트도 있고,

아이폰 탈옥툴 처럼 엄연히 불법은 아니지만 만든이를 숨기고자 하는 서비스도 있다.

(애플에서는 탈옥은 불법 아니지만 탈옥폰에 대해서 지원하지 않는다고 명시하고 있다.)

뭐 가장 큰 특징이 바로 CloudFlare 의 효율적인 캐시 정책과 DDOS 같은 무식한 공격에 방어하는 효과가 뛰어나서이다.

(실제로 Cloudflare 를 통해 호스팅한 사이트가 DDOS 공격을 받았는데 접속이 오래 걸렸을 뿐 서버가 뻗은 적이 없다고 하여 CloudFlare 서비스가 인기를 끈 원인이기도 했다.)

미국에도 한국의 보수(…)처럼 익명성을 혐오하는 이들이 있다. 좋게 보면 파수꾼일 수 있고, 나쁘게 보면 파파라치일 수 있다.

한국의 익명성은… 실명제하고 별 다를 거 없더라.

어쨌든 미국의 익명성을 반대하는 사람들은 불법적이라던가 등의 사이트가 하필 CloudFlare 에 호스팅을 해서, 이를 신고할 증거로 쓰지 못하기 때문에 애먹는(?)다고 한다.

그래서 몇몇 유저들이 CloudFlare 호스팅 하는 사이트의 진짜 IP 를 알아내는 방법을 “공유”하고 있다.

참고로 해킹 기술이 아니며, 그냥 네트워크 관리자라면 “아하 이거?” 할 수 있는 툴로 사용하는 방법이거나, 구글 검색으로 쉽게 접할 수 있는 별거 아닌 도구들이다.

물론 해킹으로 가능할 지는 모르겠지만, 불법이고, 이를 CloudFlare 가 인지하면 당신 고소미 먹으므로 알아서 해라.

어쨌든, 소개한다.

1. Uncovering bad guys hiding behind CloudFlare – CloudFlare Watch (현재 사이트 작동 안함)

http://www.cloudflare-watch.org/cfs.html (사이트 작동 안해서 링크 일부러 안적용)

Daniel Brandt 가 만든 이 사이트는 공공정보연구(Public Infomation Research) 프로젝트의 일환으로 “Cloudflare” 가 범죄 사이트도 수용하고 호스팅해줘서 “CrimeFlare” 라는 별칭을 만드는 등 CloudFlare 서비스에 반발하기 위해 만든 사이트라고 한다.

네임서버 히스토리 등의 공개적인 네임서버 IP 정보를 수집하여 CloudFlare 외 IP를 모두 솎아내서 정리했다는 이 사이트는 반익명성 네티즌에게 엄청난 호응을 얻었으나, 당연히 익명성을 요구하는 다수의 네티즌들에게는 반발의 대상이었고, 자금이 부족했던지 올해 초에 결국 사이트 자체가 폐쇄되었다.

그가 만들었던 동기 원문은 여기 살아있고, 영어다. 볼 사람 보라고.

http://cryptome.org/2012/07/cloudflare-watch.htm

  1. ping

물론 그냥 domain.com 만 핑걸면 cloudflare 만 잡힌다 하지만 CloudFlare 는 다이렉트로 접속하는 IP가 있다.

direct.domain.com : CloudFlare 기본 세팅할 때 다이렉트로 IP로 접속하라고 세팅한 IP. 뭘 좀 안다면 당연히 이는 삭제 대상인데, 실수라던가 귀찮아서 삭제 안할 경우 진짜 IP가 잡힐 수도 있다.

mail.domain.com : 주로 MX 레코드로, 이는 대부분 잡히지만 아닐 수도 있다. 뉴스타파가 잡히긴 했지만 메일 서버가 미국으로 잡히고, 메일 서비스는 심지어 무료로 제공하는 곳도 있기 때문에 신빙성이 적다.

그 외 알려진 서브도메인 알아서 하도록. 여기까지. 그래도 안잡히거나 CloudFlare IP만 잡히면 포기하자.

3. http://network-tools.com/

이 사이트는 해당 호스트에 대한 DNS 정보와 Traceroute 등등 호스트에 대해 공개된 정보를 보여주는 사이트이다.

도메인 Traceroute 및 DNS 정보, 도메인 정보와 IP whois 를 지원한다. 걍 IP나 도메인 누르고 GO 누르면 끝.

4. http://toolbar.netcraft.com/site_report?url=(도메인)

얘도 네트워크관리자라면 아 할 툴인데. 이녀석은 주로 DNS 내역을 보는 사이트이다. 따라서 오래된 도메인이라면 진짜 IP 대역도 볼 수 있는데, 뉴스타파는 신생 사이트고 처음부터 CloudFlare 를 채용했기 때문에 여기서 볼 수 없을 것이다.

그리고 그 오래된 IP가 접속되고, 올바른 곳인지는 나도 모른다. 알아서 판단하라.

5. # nmap -sV -sS -F <target>

nmap 은 DNS를 어떻게든 알아내는 DNS-brute 기능이 내장된 리눅스 유틸이다. 윈도우 사용자는 걍 구글링 해서 온라인 쓰던가.

어쨌든 이걸로 해당 호스트를 검색하면 해당 호스트의 레코드를 최대한 볼 수 있으며, 그 중 진짜 IP 대역이 있을 수도 있다.

물론 찾고 알아보고 발견하는 것은 각자의 몫이니 더이상 자세한 얘기는 생략한다.

내가 이 글을 올리는 이유는 내 친구를 포함해 CloudFlare 를 통해 웹 서비스 등을 이용하는 관리자라면 어떻게 보안성을 구축하고 운영할 것인지에 대한 참고사항이다. 이걸로 IP 잡고 뽀록내서 잡아서 뭐하게? 예를 들어 와레즈다? 불법 자료 공유한 정황을 증거로 남기면 된다. 그러면 경찰이 알아서 추적해서 잡아준다. 바보 아니다. 설령 반익명성 네티즌이라 해도 이거 쓰는 목적에 따라 범죄행위일 수도 있다. 무단 서버 침입일 수도 있기 때문이다.

CloudFlare 라도 항상 안전한 웹 사이트 운영은 힘들다. 이를 잘 알고 대비를 해 두면 당신의 서버는 안전할 것이다.

composite / 2014년 5월 13일 / 미분류 / 1 Comment

홈 네트워크 플레이? 소규모 IT 회사 보안? 하마치는 잊어라! NeoRouter!

윈도우던 리눅스던 일단 원격 접속해서 관리하는 것은 껄끄럽다. 아무대나 접속하자니 누군가 공격해서 비번 딸 것 같고, VPN 하자니 VPN 외의 망을 못쓰고 필요할 때만 키고 필요없으면 꺼야 하고, 고충이 이만 저만이 아닐 것이다.

같이 게임하는 사람들이라던가, 아니면 넷캔이라고 해서 온라인으로 같이 그림그리는 등의 너무 제한적인 네트워크 환경에는 하마치가 제격이었다. 옛날에는.

하마치는 이미 5년전인가 6년전인가 전에 그룹 하나당 16명 제한을 5명 제한으로 낮춰버렸다.

게이밍하는 사람이던, 홈 서버 관리하는 개인 입장에서는 상당히 껄끄럽기 그지없다.

랜 게임에서 네트워크당 접속 수가 늘었는데… 5명이 왠말인가.

게이밍 진영에서는 하마치 대체 프로그램인 아마 위피엔 같은 툴을 써왔을 테지만 그것도 이미 서비스 종료.

그래서 게임 진영은 이미 게임에 특화된 네트워크 프로그램으로 자리를 옮겼고, (예를 들면 가레나 등?)

소규모 IT 회사에서 VPN 구축은 부담의 대상이 되거나 아예 서버 호스팅이나 클라우드로 자리를 옮긴다.

하지만 역시 소규모 업체에서도 보안은 정말 피할 수 없고, 솔루션을 구입했는데 내부망에서만 된다. 골치 아픈건 이해한다.

그렇다고 하마치를? 겨우 5명으로 뭐하게. 게다가 상업적으로 무료도 아니고.

만약 이 글을 보고 있는 여러분이 소규모 IT 관리자나, 나처럼 쉽게 구축 가능한 홈 서버 보안을 원한다면,

지금부터 이 솔루션을 보라. 하마치는 이제 잊어라. 한물 갔다.

크로스 플랫폼이고, 쉽게 구축할 수 있는 VPN 방식의 네트워크 보안 솔루션이며, 기업이나 집에서도 쉽게 무료로 사용할 수 있다.

NeoRouter 를 소개한다.

NeoRouter 는 간단히 소개하자면 VPN 프로그램이다. 서버와 클라이언트로 나뉜다.

그렇다. 하마치하고는 틀리다. 하마치는 중계 서버를 제공하므로 서버가 따로 없다.(있긴 한데 솔루션으로 고가에 판매한다.)

하지만 NeoRouter 는 서버가 필요하다. 아마 그게 단점일 것이다.

하지만 하마치는 잊어라. VPN 구축에 대해 전문적인 지식도 필요없다.

윈도우의 경우 그냥 설치 마법사로 깔 수 있고, 맥과 리눅스로 서버와 클라이언트가 제공되며, 리눅스의 경우는 패키지를 제공하기 때문에 쉽게 설치할 수 있다.

한가지 설정해야 하는 사항이 있다면? 이 프로그램은 TCP 포트 32976 을 사용한다. 가정의 경우 공유기, 기업의 경우 방화벽에서 해당 포트를 서버 컴퓨터에서 열어줘야 한다. (포트 바꿔도 되는지 확인은 안해봤다.)

이것만 유의하면 VPN 서버 설치는 끝.

외국에서는 많은 소규모 IT나 홈 서버 보안에 하마치 대신에 선택하고 있다.

굿바이 하마치!

일단 특징은 아래와 같다.

  • 윈도우, 맥, 리눅스, FreeBSD, 심지어 라즈베리, 안드로이드까지 서버와 클라이언트 모두 지원, iOS 는 클라이언트만 지원
    (하마치는 윈도우와 맥만 지원)
  • OpenWRT나 토마토 (LinkSys 같은 외산 공유기에서 사용하는 커스텀 펌웨어 공유기 관리도구) 에서까지도 서버로 지원
  • 아무데서나 클라이언트 프로그램만 있으면 접속 가능 (심지어 포터블 버전도 제공. 포터블은 클라이언트만 가능)
  • P2P 를 기본 방식으로 채택하며, 포트 변경 불가 등의 불가항력인 사항의 경우 NeoRouter 에서 릴레이 서버 제공
  • 비관리 서버 (하마치의 비관리 방식과 동일)
  • 애드온, 프록시, WOL, 네트워크 브릿지 지원. (네트워크 브릿지 궁금하면 구글링 ㄱㄱ)
  • 스킨 제공으로 사용자가 원하는 UI 꾸미기 가능

이것도 무료와 유료로 나뉘는데, 간단히 비교해 보면 아래와 같다.

  • 무료 버전은 최대 256 클라이언트 접속 가능, 유료 버전은 클라이언트 수만큼 한번 과금하면 영원히 사용 가능.
    (유료 예: 10클라이언트당 99달러, 1000클라이언트는 999달러. 라이센스는 서버당으로 제공)
  • 유료 버전은 내장 방화벽, 사용자 접근설정, 패킷 필터링, 사용자 감시 등의 관리 기능을 제공한다.

참고로 하마치의 그룹명을 담당하는게 NeoRouter 의 도메인이다. 그걸 알아야 접속이 가능하다. 물론 계정도 있다.

고로 하마치처럼 NeoRouter 는 도메인(그룹)이 공개되지 않기 때문에 안심해도 된다. 물론 접속하려면 해당 도메인을 알아야지.

이제 슬슬 나도 깔아보고 리뷰 올리겠다.

무료 버전은 방화벽이 없고 해당 서버가 로컬로 취급되기 때문에 해당 서버에 대해서 완전한 접근을 제공한다.

만약 무료로 쓰고 싶은데 보안성이 걱정되면 NeoRouter 에 쓸 간단하거나 저렴한 컴퓨터나 서버(NAS도 됨)를 구축하거나, 프로 버전을 구입한다. 사양 많이 안타므로 미니 컴퓨터로 해도 된다.

원격 접속 등의 컴퓨터 관리 목적이라면 무료에 없는 기능은 큰 문제는 안된다. 어자피 다른 프로토콜을 사용하게 되면 흔적은 남으니까. 거기에 대해 관리를 잘 한다면 무료 버전도 매리트가 있을 것이다.

한가지 첨언하자면, NeoRouter 유료인 방화벽 기능은 윈도우의 경우 “고급보안 방화벽”의 연결 보안 규칙으로, 리눅스의 경우 iptable 에서 포트 포워딩 방식으로 가능하다. PC1은 원하는 원격 대역, PC2 에다가 NeoRouter 대역을 설정하여 연결 규칙을 만들면 된다.

composite / 2014년 5월 7일 / 미분류 / 0 Comments

VMWARE를 쓸 때 SSD 활용 팁 (보조 HDD가 있을 경우)

노트북의 하드 성능은 정말 관리 안하면 쥐약이다. 일단 보통 5400RPM 이다보니 PC 용 HDD인 7200RPM보다도 약간의 성능 저하가 있다. 게다가 노트북 하드가 상당히 조밀조밀하다보니 열 발산이 많고, 게다가 통풍이 잘 안되면 HDD 가 금방 죽는 건 시간문제다. 그래서 그런지 스탠드형 쿨러는 노트북에서 필수 아이템. 내가 이런 식으로 당하다 보니까 안정적인 사용을 위해 이런 조치를 했다.

그리고 또한가지 문제. VMWARE 가 느려졌다. 나는 가상PC 와 가상하드를 죄다 보조 HDD에 관리를 하는데,

윈도우를 다시 깔고 나서 VMWARE 가 엄청나게 답답해졌다. HDD가 끝없이 읽어댄다. 그렇다 보니 가상PC 이용도 어렵고 심지어 보조 HDD에 있는 파일 열기도 껄끄럽다.

VMWARE 온갖 최적화 팁을 써도, 윈도우 최적화를 해도, 조각모음하고 디스크검사 하고, 심지어 HDD까지 바꿨는데도 개선할 기미는 보이지 않았다.

결국, 나는 생각을 달리 해봤다.

그리고 지금. 나는 VMWARE를 쾌적하게 쓰고 있다.

운영체제를 SSD, 저장을 보조 HDD로 한다면, 내가 쓰는 팁으로 VMWARE를 최적화 한번 해봐라. 우왕굳.

아주 간단하다. 가상PC 파일(.vmx) 과 그 떨거지들을 모두 SSD 에 맡기고, 가상디스크(.vmdk) 만 HDD에 맡기면 된다.

VMWARE 가 왜인지 vmx 폴더에서 캐시를 하고 있다. 게다가 자주 일어난다.

그렇다 보니 HDD가 느려지는건 시간문제. HDD가 캐시와 디스크 관리를 하니 HDD가 죽어난다.

그래서 캐시를 SSD에 맡기고 나서부터는 우왕굳. 쾌적해졌다.

가상PC의 재원이 이렇다. 2 CPU에 램 2GB를 할당했다.

1GB 까지는 별다른 일 없이 잘 되는데, 2GB 부터는 HDD가 풀로 읽고 있으니..

그렇다 보니 스왑을 하는 모양인데, 이게 많은 I/O가 오가므로 HDD에게는 장애가 될 수 있다.

Edit -> Preference 에서 Memory 탭에 RAM 에 모든 걸 맡겨도 같은 증상이 일어났는데 이렇게 관리했더니 말끔히 해결했다.

만약 나같은 환경에 VMWARE 쓰기 힘들다면 나같은 방법을 쓰면 깨끗해진다.

그 외 팁을 공유하면 감사하다.

composite / 2014년 3월 11일 / 미분류 / 12 Comments

한국을 위한 CSS 그리드 디자인 프레임워크

그렇다. 사정은 잘 안다. 부트스트랩이나 파운데이션 같은 올인원 CSS 프레임워크는 안맞을 수밖에.

특히 디자이너가 있고, 기획이 재대로 되어 있다면, 한국 웹 사정에 부트스트랩은 어찌보면 경우에 따라 안어울릴 것이다.

디자인 떡칠해서 화려한 웹페이지 만들어야 직성이 풀리는 한국 웹사정에 안맞다 보니까.

하지만 이런 단어만 들으면 디자이너와 퍼블리셔는 가장 먼저 입에서 시발이라고 나올 것이다.

반응형 웹.

맞다. 반응형 웹의 주인공은 CSS의 미디어 쿼리다. 하지만 배우고 적용하기 까지는 시발 좆같다.

퍼블이나 디자가 왠지 개발자가 되어 가고 있는 기분 같을 것이다.

그럼 시발 개발자는 니들 하는 업무 다하고 있는 개발자도 있는데.

어쨌든, 그래도 자신이 맡은 업무에 충실하면서 클라를 만족하고 싶지 않은가?

그래서 시발 존나 위험한 개발자인 내가 소개한다. 퍼블과 디자인 니들을 위한 반응형 웹을 위한 CSS 프레임워크다.

나머지 디자인과 레이아웃 구성은 니들 꼴리는데로 하면 된다.

1. 960 Grid System (http://960.gs/)

전 세계에 인기를 한몸에 받고, 파생 CSS 프레임워크를 탄생시키게 한 장본인이자 웹에 생산성을 불어넣은 엄청난 놈이다.

이녀석은 웹 페이지의 한 행을 몇 열씩 나누게 하는 방식을 선보였는데, 전 세계적으로 인기를 한몸에 받았다.

이녀석의 특징은 960인데, 페이지의 기본 크기를 960으로 잡고 시작한다. 그리고 한 행당 12단씩 나눌 수 있다.

실질적인 컨텐츠가 들어갈 길이는 940이다. 여백 제외하고 말이다.

사용법이 무진장 간단하다.

<div class=”grid_나눌 숫자”>내용</div>

<div class=”clear”>행 나눔 (주로 공백을 넣는다. &nbsp; 같이.)</div>

예를 들어 12단 나눌 수 있을 경우, 3개씩 나누고자 한다면 이렇게 하면 된다.

<div class=”grid_4″>내용</div>

<div class=”grid_4″>내용</div>

<div class=”grid_4″>내용</div>

<div class=”clear”>&nbsp;</div>

이런 식으로 4+4+4=12 로, 총 12단으로 맞추는 것을 고려하여 4*3=12 니까 3개 div 에 grid_4 클래스를 넣으면 div 를 삽입하면 된다.

존나 쉽지 않은가?

단점은 니들이 원하는 반응형 그리드는 아니다. 타블렛이나 데스크탑에 적합한 레이아웃 구조에 탁월한 선택이다.

하지만 이거와 미디어쿼리를 합치면 반응형 그리드 디자인을 만들 수 있다.

그러면서 왜 이녀석을 소개하냐면 이녀석이 웹 그리드 디자인을 프레임워크로 탄생시킨 원조이기 때문이다.

2. Fluid Baseline Grid (http://fluidbaselinegrid.com/)

이녀석부터 이제 반응형 웹 디자인을 고려한 그리드 디자인 프레임워크 되겠다.

이녀석의 특징은 Baseline 인데, 글씨 크기 위주의 웹을 고려한 그리드 디자인을 생각했다고 보면 된다.

그래서 어찌보면 이미지 떡칠의 한국형 웹과 안맞을 지는 모르겠다. 그래도 소개한다.

이녀석의 특징은 % 단위의 넓이를 나눠서 처리한다는 것이다. 960.gs 또한 이를 지원한다.

그리고 이녀석은 최대 3단계 레이아웃이 있는데,

g1 은 작은 단위로 모바일에 표시 가능하도록 작은 크기의 영역을 잡는다.

g2 는 중간 단위로 타블렛에 표시 가능하도록 중간 크기의 영역을 잡는다.

g3 은 큰 단위의 테스크탑에 표시 가능하도록 큰 크기의 영역을 잡는다.

<div>

    <div class=”g2″>

         난 타블렛에서 하나를 다 잡아 먹는다.

     <div>

    <div class=”g3″>

         난 어느 장치에서 봐도 하나를 다 잡아 먹는다.

     <div>

    <div class=”g1″>

         난 휴대폰에서 하나의 영역을 잡아먹는다.

     <div>

</div>

솔직히 뭐 이 이상은 나눌 일이 없다고 봐도 무방하지 않은가? 그럼 됐다.

3. Negative Grid (http://chrisplaneta.com/free/negativegrid-generator/)

만약 직접 그리드 구조를 짜야 한다면 이녀석을 추천한다. 이녀석은 원하는 크기, 그리드 개수, 여백 등을 지정할 수 있다.

당연히 px 가 아닌 % 이기 때문에 % 단위로 짜야 한다. 만약 px 단위를 원한다면 960 그리드를 써라.

이녀석 또한 960 그리드와 마찬가지로 생성기 시스템인데, % 위주인 방식에서 틀리다.

게다가 가볍다. CSS 생성했는데 보기도 쉽고 내용도 별로 없다. 그리고 prefix 설정도 가능해서 반응형 웹 구성에 잘 맞는다.

사용방법은 대략 이렇다.

<div>

    <div class=”col4″>3단</div>

    <div class=”col4″>3단</div>

    <div class=”col4″>3단</div>

</div>

별거 없다. 나눌 크기를 정해서 col(또는 직접 정한 prefix) 옆에 숫자만 붙여주면 된다. 최대 숫자는 니가 정한대로다. 예를 들어 12개로 나뉘었다면 1부터 12까지를 쓰면 된다.

여백을 만드는 방법은 push(또는 직접 정한 prefix) 옆에 숫자만 붙여넣으면 된다.

난 굳이 미디어 쿼리 혼합하는 방법은 안가르쳐준다. 어자피 반응형 웹을 만들 거고 거기에 대응하기 위해 미디어 쿼리를 배웠을테니까.

그래서 이거와 잘 혼합한다면 깔쌈한 사이트가 만들어질 것이다.

IE를 위해서라면 respond.js 가 필요하다. 그냥 스크립트 쳐넣으면 끝이다 나머진 CSS에 맡겨라. 구글신 영접하면 바로 나온다.

귀찮아서 끝.

니들 그냥 좆돼봐라.

composite / 2014년 2월 27일 / 미분류 / 2 Comments

ECMAScript 6 Harmony 를 네 브라우저에 돌려봐라!

나 참.. 기분 존나 나쁘네.

뭐? CoffeeScript? TypeScript? 어쩌고 저째? 자바스크립트가 죽을 거라고?

난 동의 안한다. 제아무리 자바스크립트를 편하게 만들어도 오리지날이다. 결국 그들도 자스로 움직인다. 제아무리 편해도.

스칼라가 결국 자바에서 돌아가기 위해 자바 코드로 생성해서 컴파일 하는 것처럼 말이다.

튜닝의 끝은 순정이란 말이 괜히 나오는게 아니지.

그래서 소개한다. 니 브라우저에 직접 ECMA 6 을 적용할 기회를 내가 선사해 주겠다. 2가지 프로젝트가 있다.

1. Traceur

구글신은 미쳤다. 이번에 소개할 피로젝트는 자바 2명 타요가 아닌 외계인 2명 타요 해서 ECMA 6을 몸소 체험할 수 있는

Traceur 를 소개한다.

프로젝트 페이지는 https://github.com/google/traceur-compiler

이 스크립트 컴파일러는 ES6 을 당신 브라우저에 돌릴 수 있게 한다.

일단 IE 8은 안된다. 쳇. 최소한 8이라도 지원해주지.

크롬과 불여우는 일단 된다. 올ㅋ

Traceur 가 지원하는 ECMA 6 기능이다.

일단 여태 나오고 알려진 것들을 지원한다.

하지만 이 ES6 하모니를 쓸 때 몇가지 주의할 점이 있다.

알다시피 ES6은 확정된 표준이 아니다. 특히 클래스와 모듈이 그 대표적인데, 이들이 어떻게 바뀔지는 장담을 못하겠다.

제발 안바뀌길 바래라.

뭐.. 그래봐야 기반 스크립트 (타입스크립트 등) 또한 아직까지 안정화된 버전을 내놓지 못하고 있기 때문에

물론 커피스크립트는 상당히 안정화 되고 쓰는 사람 많은거 안다.

근데 뭐가 좋다 말을 못하겠지만, 그래도 그런 스크립트는 표준에 넣지 못할 것이다.

난 커피스크립트가 자바의 스칼라처럼 생각하지만, 그래도 스칼라도 많이 쓰지 않는가? 물론 갈라파고스 한국은 빼고.

난 표준을 만들고 따르는 주의자긴 하지. 자바스크립트는 아직까지는 강력하기 때문에. 단지 좀 귀찮고 짱나서 그렇지.

어쨌든, ES6 을 직접 체험해보고자 한다면, 이 컴파일러를 이용해 제작된 ES6Fiddle 을 사용하라.

http://www.es6fiddle.net/

ECMAScript 6 이 어떻게 돌아가는지 알 수 있을 것이다.

2. continuum 

그에 비해 이 ES6 컴파일러는 커뮤니티의 참여로 만들어졌다. 그다음 낫고, IE 8부터 지원해주기 때문에 우왕굳.

프로젝트 사이트는 https://github.com/Benvie/continuum

체험 사이트는 http://benvie.github.io/continuum/

현재 구현된 기능들이다.

  • 통합 할당 및 인자
  • 가변 처리자 및 배열 초기자
  • 가변 인자
  • 클래스와 상속
  • 화살표식 함수(람다식) (.NET 의 람다식과 동일한 형식)
  • 블록 단위 변수
  • 새로운 Math 함수
  • 새로운 Object 함수
  • 새로운 String 함수
  • concise methods in object literals
  • 열거 및 삭제 가능한 프로토타입
  • Map, Set, 그리고 WeakMap (가비지 컬렉션이 현실화되지는 않았음)
  • 열거자와 for…of 반복문
  • 템플릿
  • 모듈과 imports, exports
  • 내장 ‘@std’ 모듈 module std = [email protected]' 또는 import call from [email protected]'
  • 생성기
  • 프록시와 리플렉션
  • Symbols with syntactic @name support
  • 형식화된 배열Typed Arrays
  • Object.observe (es-next/es7)
  • 인자 기본값
  • 꼬리물기 호출 최적화
  • 배열 초기화 식 (부분 지원)

아래 기능은 아직 구현이 안되어 있으며 추후 지원될 예정이라 한다.

  • 생성기 식
  • 이진 데이터 api (structs, etc.)
  • 프로미즈 (내가 Feature request 했음.)

물론 프로미즈같은 경우 promisejs 또는 q 로 해결은 가능하기 때문에 커버는 해줄만 하다.

ECMA 6 기능에 목이 말랐다면 지금 바로 체험하라.

아참, 마지막으로 ES6의 새로운 기능을 한글로 잘 정리한 위키 페이지가 있어 이걸 소개하고 쿨하게 끝내겠다.

http://wiki.codekin.com/index.php/ECMAScript_%ED%95%98%EB%AA%A8%EB%8B%88

끝이다.

추신 업데이트 사항 : Traceur 외에 나머지 ES6 컴파일러는 몇달동안 활동이 없다. 그냥 Traceur 써라. 진자끝.

composite / 2014년 2월 25일 / 미분류 / 0 Comments

태그에는

다들 HTML 배우면서 가장 간단하면서 많이 지키는 사항이 있다. 물론 맞는 말이다. 표준이기 때문에.

  • inline 요소 안에는 block 요소를 자식으로 가질 수 없다.
  • block 요소 안에는 inline 및 block 요소가 모두 허용된다.
  • 단, p 요소 안에는 inline 요소만 허용된다.
  • inline 요소 안에는 inline 요소만 허용된다.

근데 나모 웹에디터 때문에 <p> 요소에다가 <div> 넣는 등의 표준을 위반하는 사례가 있다. 그리고 IE 기반 위지윅 에디터가 그리한데, designMode 기능이 기본 문단 태그를 <p> 로 지정했기 때문이다. 그래서 초창기 위지윅 에디터가 상당히 말이 많았고, 그리고 이에 대한 문제를 고치느라 고생하던 시절이 있었다.

하지만 지금은 많은 위지윅 에디터가 문단 태그를 <div> 로 강제하였기 때문에 더이상 HTML 표준 위반 및 XHTML 표준 전선 이상 무!

자. 잡담은 끝내고 이제 본론으로 들어가보자. HTML 표준에는 일단 문장(inline) 요소에는 문단(block) 요소를 넣을 수 없게 되어 있다. 따라서 원래 <a> 태그에 <div> 태그같은 게 들어갈 수 없는게 정설이다.

하지만 HTML5 부터는 얘기가 달라졌다.

마치 p 태그가 인라인 요소만 허용한다는 예외 처럼, a 태그에도 예외가 생겼다.



두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구두구



그러하다.
HTML5 에서는 <a> 태그 안에 아무 태그나 넣을 수 있게 되었다.
이 때문에, 플랫 디자인 다음이 뜬금없는 카드 디자인 패턴이 나온 것이다.
예제 코드를 보자.
<article>
<a href="story1.html">
<h3>Bruce Lawson voted sexiest man on Earth</h3>
<p><img src="bruce.jpg" alt="gorgeous lovebundle. ">A congress representing all the planet's women unanimously voted Bruce Lawson as sexiest man alive.</p>
<p>Read more</p>
</a>
</article>
이렇게 생겼다.
하나의 글 영역 안에 모든 것들을 링크 걸고, 그 안에 제목과 요약 내용, 그리고 read more 라고 링크를 부추기는 글을 넣는다.
이렇게 하면 장점이 뭐냐?
웹 접근성이 향상된다. 모바일이나 특수 컴퓨터 (시력장애인 등을 위한) 에서 링크 클릭에 대한 접근성이 향상된다.
또한 이런 접근성으로 인해 스크립트 의존성이 떨어지며, 원하는 문서를 손쉽게 이동할 수 있는 장점이 생긴다.
바로 접근성을 고려해서 W3C가 이렇게 HTML5 표준과 함께 내놓은 거다.
여담으로, XHTML2 에서는 모든 요소에 href 를 넣을 것을 고려했다고 한다. 바로 이런 접근성에 용이하기 위해.
하지만 알다시피 XHTML2 는 완전히 새로운 표준을 지향했고, 하위 호환성이 철저히 무시한 덕분에 많은 웹 관련 개발자와 디자이너, 연구진들이 반발했고, 그리고 무산된 표준이 바로 XHTML2 였다.
만약 XHTML2 표준으로 웹 페이지를 만들었고, 브라우저가 그걸 지원하려면 정말 엄청 머리 아팠을 것 같지 않은가?
왜냐하면 바로 하위 호환성이 사라지기 때문에, 엔진을 2개 만들어야 하는 꼴이 되니까. 당연히 달갑지 않았던 거다.
지금은 HTML5 에서는 이 표준이 아직 하위 호환성이 적잖아 문제가 있다. 모든 브라우저가 이 표준을 지원한다. 쿼크 모드에 대한 호환성 때문인데, 이 기능이 지원된 게 다행이라 생각하지 않는가? 만약 <div> 가 <a> 로 감쌌다고 지우면, 이건 정말 골치아플 수도 있다.
하지만 아직까지 현재 브라우저에 한계가 있는데,
비록 <a> 태그 안에 모든 태그가 지원된다 해도, 현재 표준에 의한 예외 사항이 있는데, 바로 테이블이다.
테이블 태그 안에 비표준 태그들을 싸그리 지우도록 엔진이 설계한 덕분에, <a> 태그를 <tr> 안에 넣지 못하는 사태가 일어난다.
이에 대응할 지는 아직 지켜봐야 할 단계지만, 이를 지원한다면, 웹 접근성 향상에 어느정도 기여할 것으로 기대된다.
자. 이제 찬양하라. HTML5를!
자세한 링크는 HTML5 에서 신뢰성 있는 정보를 제공하는 HTML5닥터 에서 보도록 한다.

composite / 2014년 2월 18일 / 미분류 / 0 Comments

JetBrains 의 IDE 제품을 포터블로 쓰기.

먼저 노파심에 말하는데, 이건 공식 포럼에서 얻은 글을 한글로 재구성한거고, 불법 아니다.

못믿겠으면 니가 직접 포럼이나 지원에 물어보던가.

자바 개발자라면 Intelij IDEA 를 들어봤을 것이고, 쓰는 사람도 있을 것이다.

여담으로 희한하게 전자정부 프레임워크 개발시 이 IDE로 개발이 안된다. 왜그런진 나도 모르겠다. 내 경험상.

그리고 요즘 HTML5 최강 에디터라 불리었다고 들었던 WebStorm 출시 이후 아마 많은 주목을 받았을 것이고,

PHP 개발자 중에서도 PHPStorm 을 쓰는 유저도 좀 있을 것이다. 필자는 PHP 플젝 뛸때 PHPDesigner 썼다.

강력하긴 강력한데 저장시 한글 처리 누락 때문에 조금 고생한거 빼면.. 꼼꼼해야 하는 단점만 빼면 한글 잘 안깨지고 쓸만하다.

어쨌든, 상용이지만 전세계 자바 개발자들에게 인기가 많아서 오픈소스인 이클립스와 쌍벽을 이루며, (NetBeans? 2인자.)

하드 리소스를 많이 활용하는 이클립스와 달리 램을 좀 활용하는 인텔리는 어정쩡한 노트북에서도 괜찮은 개발환경을 만들어낸다.

이에 힘입어 제조사인 JetBrains 에서는 이 인텔리 IDE 를 기반으로 개발한게 WebStorm 과 PHPStorm 등이 있는데,

이들의 공통점이래봐야 기반이 인텔리다. 개발할 언어 대상이 틀리고 거게에 맞춰서 개발했을 뿐.

이제 본론으로 들어가서, 이들을 포터블로 만드는 게 가능한가?

가능하다.

인텔리 IDE는 자바로 만들어졌다. 인텔리 플러그인도 자바로 개발이 가능하고, JetBrains 에 배포가 가능하다.

또한 JetBrains 에서도 다양한 플러그인을 만들어 배포하고, 유저 플러그인도 꽤나 많아 왠만한 환경 개발에 불편함이 없다.

특히, node.js 개발에 많이 신경을 썼고, 배척하지 않는 모습이 유저층을 사로잡았다고 봐도 된다.

어쨌든, 인텔리 IDE 기반이라 어떤 프로그램을 실행해도 개발언어 환경만 틀릴 뿐 환경이 하나도 안변하고, 자바로 실행하니 별도의 시스템 세팅 (레지스트리 등록한다던가 ThinApp 로 포터블화 등) 또한 필요가 없다.

이 IDE를 이제 포터블로 만드는 방법을 알아보자. 전혀 어렵지 않으므로 금방 따라할 수 있다.

또한 WebStorm, PHPStorm, InteliJ IDEA 등 관련 IDE 제품에 모두 적용이 가능하며, 윈도우 기준이지만 맥에서도 비슷한 방법으로 만들 수 있다.

<

p style=”text-align: center; clear: none; float: none;”>

먼저 자신이 구입했거나 사용하길 원하는 IDE 제품을 다운받는다. 만약 이미 깔았다면, 무시하고 일단 설치본을 받는다. 이미 설치한 사람은 조금만 참으면 내가 알려주겠다. 그냥 따라하라.

다운받은 exe 파일의 확장자를 zip으로 바꾸거나, 그냥 가지고 있는 압축 프로그램으로 연다. (알집 왜쓰냐?)

원하는 폴더(USB 등)에 압축을 모두 푼다. 남김없이. 폴더명은 원하는 폴더명으로 해도 된다. 폴더 만들고 푸는 것을 추천한다.

그리고 폴더 구조는 바꾸지 말자. 실행 안되는 수가 있다.

그러면 bin 폴더와 jre, lib 등등.. 여러가지 폴더가 있다. 여기서 손대지 말고 bin 폴더로 가자.

그리고 idea.properties 를 쓰고 있는 아무 편집기로 열자 (기존에 깔았던 IDEA 제품으로 열지 말고.)

그러면 path=${user.home} 이 들어있는 상위 4개 세팅값이 주석으로 처리되어 있을 것이다. 물론 당연히 기본값이라 생각하면 된다.

주석을 풀고, ${user.home} 모두 ${idea.home} 으로 바꿔준다. 그러면 사용자 전용 폴더가 아닌, 당신이 압축 푼 폴더에다가 .WebIde 폴더를 생성할 것이다. (첫 실행시)

끝.

허무하다. 정말 허무해.

만약 이미 설치형으로 이미 깔았다면, 설정값을 옮기는 2가지 방법이 있다.

사용자 폴더에 (윈도우 기준 C:(XP는 Users and Settings, 비스타 이상은 Users)(사용자명).WebIde, 맥이나 리눅스는 /home/(사용자명)/.WebIde) 폴더를 찾으면 있을 것이다. 그걸 모조리 압축 푼 곳으로 이동한다. 버전이 같다면 이렇게 해도 된다.

또는, 압축 푼 폴더/bin/(제품명).exe 을 실행하여 프로그램을 실행하면 기존 config 를 가져올 것이냐 물을 것이다. 그 때 config 를 지정해서 옮기는 방법이 있다.

편한 방법을 쓰면 된다.

참고로, 라이센스 키 또한 config 에 저장되기 때문에, 정품 등록을 하고 config 환경을 가져왔다면 별도의 키 입력은 필요없이 기존 세팅대로 개발하면 되며,

만약 그러지 않고 쌩으로 시작하길 원한다면, 등록 키가 있다면 다음에 나올 라이센스 키 여부를 물을 때 넣으면 된다.

없으면 그냥 21일 체험판 되는거다.

그리고 써주면 된다. 그러면 당신의 개발환경에 날개를 달아줄 것이다. 특히 프리랜서.

덤으로 오픈소스 라이센스에 대해 알려주겠다.

당신이 오픈소스 라이브러리나 프레임워크, 프로그램 등을 개발했다면 공짜로 쓸 수 있다.

단점이 있다면 년 단위로 갱신을 해야 한다는 것이고, 심사 후 제공하는 것이다.

심사에 성공했다면, 라이센스 키를 보내주는데, 그 키는 사용자 제한이 없어서 오픈소스 참여자 모두 다 써도 불법이 아닌 라이센스가 된다. (단, 라이센스 키를 인터넷 공개 행위 등으로 외부로 공개하면 불법이 된다.)

신청서는 여기를 클릭하면 있다.

그리고 마소 MVP가 됐다면, 이 또한 연간 공짜로 쓸 수 있다. 마소 증명 URL을 증명으로 제출하기만 하면 된다. 단점이라면 닷넷 기반 제품으로 한정되있다는 점이다. (비닷넷으로 WebStorm 제품만 가능)

하지만 닷넷 리플렉션 프로그램인 ReSharper 라는 강력한 프로그램을 공짜로 쓸 수 있으니 MVP라면 놓치지 말자.

그럼 즐개발 해라. 끝.

composite / 2014년 2월 12일 / 미분류 / 0 Comments

웹 개발자 도구의 역사

웹디자인의 역사는 뭐 웹디자인 관련 블로그만 검색해도 질리게 나온다.

하지만 웹 디자인을 발전시키게 해준 초석인 웹 개발자 환경의 역사는 구글링을 해봐도 잘 안나왔다.

이 얼마나 슬픈 일인가 개발자들이여!

그래서 내가 정리해준다.

1. 넷스케이프에도 개발자 도구는 있었다.

이 글 보는사람들 중 넷스케이프에 신경쓴 개발자가 몇 있을지는 나도 모르겠지만, 때는 1998년이다.

솔직히 넷스케이프 시절에 필자는 초딩이였다. 그때는 모뎀 인터넷 시절이었고, 인터넷이 종량제이며, 인터넷을 할려면 전화를 못받는다는 단점 때문에 상당히 제한적이었지만, 그래도 나름 문화컬쳐였다. 

그런 초딩 시절에 넷스케이프 4 에 자바스크립트 디버거가 있었는데, John Bandhauer 가 개발한 자바스크립트 디버거는 그때당시 자바스크립트는 그저 옵션에 불과했지만, 자바스크립트 개발하는데 있어서 생산성을 촉진시킨 하나의 유물인 것은 확실하다.


2. Venkman Javascript Debugger.

Venkman Debugger

이 기술을 넷스케이프가 모질라로 올인하면서 디버깅 기술까지 전수받았는데, 2001년 출시한 모질라 기반 자바스크립트 디버거를 Venkman Javascript Debugger 라 불렀다.

이녀석의 강점은 모질라 기반임에도 불구하고 크로스 플랫폼에서도 디버깅 환경을 제공하고자 하는 노력이었다,

그래서 Ajax 가 뜰 때 당시에 이 역사가 재조명되었지만, 다른 개발자 도구가 워낙에 좋아서 거기서 그치는 비운의 도구였다.

debugger; 키워드를 ECMA 표준으로 등재시킨 툴이였고, 별도의 프로세스로 돌아갔어도 불여우가 역시 개발자를 위한 브라우저구나 하는 무릎 탁 치게 하는 기원이였다고 해도 과언이 아니었다.

자세한 내용은 링크를 참고하라. : https://developer.mozilla.org/ko/docs/Venkman

3. DOM 시각화.

당신의 웹 어플리케이션에 동적으로 컨텐츠를 넣었다가 갑자기 레이아웃이 깨졌다면, 어떻게 모니터링하고 대처했을까?

분명 테이블이 잘 만들어진것 같은데 테이블이 무너져 보인다면, 소스를 다시 보면서 캐치해야 하니..

하지만 기존 웹브라우저는 잡아내는 방법이 너무나 제한적이었다. 소스 보기를 해도 원 소스를 보여주지 동적으로 추가된 곳까지 신경써주지는 않았으니까. 어찌나 불편했을까? 뭐.. 한국은 액티브엑스가 동적 컨텐츠를 제공하는데 아주 잘 활용해서 말이 통할려나 모르겠지만.

이것을 해냈다. 해냈어. 불여우가해냈어!

View Source Chart

DOM Inspector. 우리말로는 DOM 검사기.

DOM 검사기는 DOM 구조를 트리 구조로 시각화해서 눈으로 보여주는 아주 획기적인 도구였다.

이 도구 덕분에 테이블 등에 엉뚱한 태그가 들어가서 테이블 구조가 깨지는 문제를 손쉽게 해결할 수 있었고,

동적으로 컨텐츠가 들어갔어도 바로 볼 수 있었다.

XML에 비해 HTML은 엄격하지 않아서 물론 잘못 코딩해도 보이긴 하지만, 레이아웃 깨졌거나 뭐 엉뚱한 글자가 페이지여 보여서 컴플레인 들어오면 이젠 두렵지 않은 도구가 되었다.

하지만 한국은 이때도 액티브엑스 전성기라서 우리나라 웹 페이지는 저 구조에 크게 신경쓰지 않았거나,

테이블 기반 구조로 저게 필요한 상황을 만들었음에도 깨지기만 하면 정말 고치기 힘든 웹 사이트 구조를 만들어냈다.

그래도 저게 있어서 한국의 지랄같이 테이블 의존성 구조에서 어느정도 벗어날 수 있었지만, 그 은혜를 모른다.

정말 테이블 태그로 만든 레이아웃은 미관엔 좋았지만.. 개발과 유지보수가 어려운 단점은 피할 수 없었다.

그게 왜냐면, 디자이너들이 나모 웹에디터같은 위지윅 개발도구에 의지하고, 개발자조차도 거기에 의지한 탓이다.

그나마 테이블은 미리보기에도 그대로 볼 수 있었기 때문이었고, CSS 표현력이 제한적이라서 div 기반의 레이아웃에서 잘 보여준다는 보장이 없었으니까.

그래서 이때 웹 개발 비용이 부담된건 사실이다. 아무리 편해도 그게 한계가 있다는 것을 여실히 보여준 트랜드였던 것이다.

쪽팔리게 개발자가 나모웹에디터나 쓰고.. 으이구..

이제 Ajax 이후 하드코딩의 시대가 도래했는데, 이 DOM 검사기 도구는 하늘이 내려준 선물임은 확실하다.

4. Web Developer for Firefox.

불여우가 왜 웹 개발자를 위한 브라우저인지 다시한번 마음에 새기는 혁신(?)이 왔는데, 

하나의 작은 툴바에서부터 시작됐다. Chris Pederick 이 만든 Web Devloper toolbar 였는데, 웹 개발자를 위한 편의성 도구들을 제공하여 웹 개발에 도움을 주게 만든 일등공신이었다.

이 툴바의 강점은 Disable CSS와 Disable Javascript 기능인데, 이는 크로스 플랫폼, 크로스 브라우징 보기, 그리고 CSS가 적용되지 않은 경우와, 자바스크립트가 비활성화된 브라우저의 경우, 그리고 시맨틱과 웹 접근성 개발에 도움을 주는 기능들이 한자리에 모여서 웹 개발자들에게는 없어서는 안될 도구로 성장했다.

2003년 첫 릴리즈 이후 계속 버전업 해가면서 기능과 성능 최적화가 되고, 처음엔 미약했지만 끝은 비대한 웹개발자에겐 모르면 간첩인 도구가 됐다.

근데 한국의 경우 웹접근성이 주목받은 때가 2010년이다. 외국에 비해 7~8년 늦은 접근성이다. 비즈니스와 편의성에만 추구한 나머지 웹취약계층과 접근성은 개나 줘버렸었다. 가뜩이나 IE에만 신경썼는데 오죽했을까? 인종차별 인종차별 소리지르면서 정적 한국이 내가 보기엔 존나 차별하는것 같다.

그렇다고.

5. 개발자 도구의 시작, Firebug.

불여우가 왜 괜히 웹 개발자를 위한 브라우저일까? 애초부터 그렇게 시작한 거다.

한국에 IE와 불여우, 크롬 3대장이 웹 시장을 주름잡기 시작했는데, 불여우가 일반인에게 쓰기 어려운 브라우저인 이유가 바로 이런 개발자 환경에 신경쓴 환경이기도 하다.

어쨌든, 개발자 도구의 표준안을 마련한 도구, Firebug다.

Firebug HTML Tree

하지만 Firebug가 처음부터 표준안을 선도한 것은 아니었다. 버전 0.2 에서는 자바스크립트 콘솔과 CSS 구조, 선택한 DOM의 속성을 제공한 게 전부였다.

0.3 에서는 DOM 기능에 충실하게 출시해서 DOM 이벤트와 속성, 해당 적용된 DOM의 CSS 속성들도 볼 수 있게 됐다.

그리고 혁신을 이루어낸 것은 버전 0.4 부터인데,

0.3을 기점으로 자체 DOM 검사기를 포함하는 것으로 시작해서, 자바스크립트에 표준 바람을 불게 만든 console 객체를 출시했다. 비록 Firebug 밖에 되지 않았지만, 혁신을 이루게 한 건 사실이다. 귀찮게 로그성 데이터를 DOM에 뿌릴 필요 없었고, 정보도 바로바로 볼 수 있었던 덕에 많은 웹 개발자에게 Firebug는 이제 없어선 안될 도구가 되고, console 객체 또한 조금 늦지만 ECMA 표준에 등재된 쾌거를 이루었다.

그리고 이 주목받은 기능을 등에 업고 1.0을 출시했을 때는 상용 도구로 개발될 예정이었으나, 불여우에 왠 뜬금없는 상용 툴? 뚝.

아 미안. 그냥 공짜임. 콜! 오픈소스다. BSD로. 아주 좋소!

어쨌든, 지금의 Firebug 화면과 유사하게 나온다. 콘솔과 DOM 검사기, CSS와 스크립트 디버거, 그리고 DOM 객체 구조와 네트워크 타이밍까지. 웹 개발에 있어서 제공하는 모든 것들을 제공했다.

현재는 쿠키와 프로파일러, 설정 등 다양한 기능들이 커뮤니티를 통해 제공했다.

그리고 웹 사이트 성능 측정 도구인 YSlow. 웹 개발자라면 다 아는 도구다. 야후까지 가세해서 Firebug는 웹 개발자가 모르면 간첩.

그리고 이에 힘입어 Firebug Lite 까지 출시했는데, Firebug를 다른 브라우저에서 돌리고 웹개발에 편의성을 주도록 개발한 녀석이다.

그래서 오페라 브라우저에 신경쓰는 웹 개발자에겐 가뭄에 비같은 도구로 잘 활용했었다. 지금은 오페라도 자체 개발자 도구 제공해서 상관은 없지만.

IE에게는 가뭄에 산성비같은 도구였다. Firebug가 느리기 때문인데, 이는 Firebug 문제가 아니라 JScript 엔진이 병신같아서 그런 거다. 엔진 자체가 느려 터졌다고.

하지만 IE 8부터 자체 개발자 도구가 생겼으니 굳이 고민을 할 필요는 없어보인다.

현재는 불여우에 자체 개발자 도구로 제공하고, Firebug 보다 더 빠른 성능을 제공해 주지만, 아직도 많은 불여우 기반 웹 개발자는 Firebug를 쓰고 있다.

여담으로, Firebug 또한 한국에서 최고의 개발자 도구로 주목받았을 땐 한글화해준 고마운 사람이 있었다, 하지만 그는 누군지 모르고, 게다가 현재는 Firebug 한글화가 진행되지 않고 있다.

그래서 현재 Firebug 는 받으면 영어로 나오며, Firebug 공식 홈페이지에 한글화 번역자는 등재되지 않고 있다.

왜죠?

6. 개발자 도구의 반격, Internet Explorer.

한국인이야 알다시피 IE는 웹 환경의 혁신(?)을 불러일으킨 브라우저다. 하지만 너무 자체적으로 표준으로만 만들었다 보니 다른 브라우저에서 안되고, 액티브엑스 때문에 갈라파고스화를 만들어낸 주범이었다.

물론 이것도 마소가 독점하려고 일부러 그렇게 만든건 맞다. 하지만 IE의 보안성 부재와 불여우의 선전, 그리고 구글까지 웹 브라우저를 만들고 나서려고 하니 마소에게 똥줄타지 않을 수가 없다보니…

IE 7을 출시했다. 사용자 측면에서는 탭 브라우징이 끝이다. 시발. 장난하냐?

그리고 IE 7의 실패를 맛본 마소는 이번엔 IE 8 을 출시했다. 물론 욕나오는 브라우저긴 하다. 버그 작렬과 쳐진 성능. 즉, IE 6에 익숙했던 똥컴에게 IE8은 지랄같은 존재였던 것이다.

하지만 마소가 이제 점점 웹표준 수순을 밟고 가려는 의도가 점점 보이고 있는 웹브라우저였고,

마소도 몇몇 기술을 웹 표준에 등록했는데, 대표적인 기술이 localStorage 다.querySelector 도 있긴 한데 제한적이니…

참고로 Ajax를 만들어게 이룩한건 IE의 ActiveX 였지만, 모질라의 XMLHttpRequest가 채택되고, IE에서는 XMLDOM 액티브엑스의 래퍼(Wrapper)로 쓰였다.

그리고 IE 8에서 F12를 누르면 개발자 도구가 나오는데, 혁신을 이루게 만든 하나의 기능이 있었는데 바로 “프로파일러”다.

자바스크립트 프로파일러는, 수집하는 동안 사용자가 브라우징하는 동안에 이벤트와 속성, 함수 호출 내역을 기록하는 기능인데, 사실 이걸 재대로 쓰는 개발자는 많지 않지만, 동적 UI 편의성 모니터링과 개선에 이만한 기능이 없다.

그리고 자바스크립트 디버거 성능이 장난이 아니었다. 비주얼 스튜디오로 나태한 디버거를 만들어낸 마소 답게, 비주얼 스튜디오 좀 만졌다면 IE 자스 디버거는 이보다 편할 수 없을 것이다. 굳이 안만져봤다 해도 상당히 좋은 기능으로 자리매김하였다.

하지만 IE 개발자 도구의 단점이 이런 장점을 덮어버렸는데,

DOM 검사기를 제공한 건 잘한 일이지만 동적이지 못한 단점이 있다. 즉, DOM 변경에 대응을 하지 않았다는 것이다. 수동으로 새로고침을 해야지 그 결과를 볼 수 있다. 상당히 불편한 기능이다.

그리고 자바스크립트 콘솔을 제공하는데, Firebug 가 다른 콘솔은 객체만 치면 객체의 대략적인 속성이나 constructor 가 뭔지 알 수라도 있는데, IE에서는 그저 [object] 로 나온다. 시발 어쩌라고.

그리고 네트워크 탭이 없었다. 물론 Fiddler 가 그 역할을 대신해주긴 했지만, Ajax나 동적 스크립트, 그리고 누락된 리소스 알아내는데 Fiddler 켜야 하니 불편하지 않을 수 없었다.

그리하여 IE 9에는 네트워크 탭이 생겼는데, 이녀석인 프로파일러처럼 개발자가 키면 수집하고 안키면 수집 안하는 식이다.

이는 어찌보면 편하기도 하고 불편하기도 한데, 내가 쓴 바로는 그닥 불편하지 않고, 필요한 경우에만 켰다가 필요없는 경우에 끄는 기능도 괜찮다고 생각한다. 키고 끄는게 가능하지만 조금 불편한 감이 있는 Firebug와, 아예 수집만 주구장촹 하는 웹키트 기반에 비해서 IE는 IE만의 특징이 있다고 보면 된다.

IE 10까지 별다른 진척 없다가 IE 11에서 개발자 도구가 플랫 UI를 안고 탈바꿈 하였는데, IE 11의 DOM 검사기는 이제 수동으로 새로고침 안해도 변경되면 반영하게 됐다. 그 외 나머진 별 다를거 없고.

그리고 UI 응답성 테스트가 생겼는데. 그냥 YSlow 비슷하다 보면 된다. 일종의 프로파일러다. UI가 렌더링된 시간을 기록하여 시각적 결과를 제공해준다. 이건 잘만든 기능이다.

이렇게 IE의 개발자 도구도 강력해지긴 했는데, 아직도 고질적인 문제는 IE는 각 버전마다 렌더링이.. 시발.. 아주그냥.. 시발..

7. Webkit, 개발자 도구로 대동단결.

맥으로 웹개발하는 사람이라면 알겠지만, 사파리나 크롬이나 개발자 도구는 똑같이 생겼다. 그 이유인 즉슨, 둘 다 사용하는 엔진인 웹키트가 개발자 도구를 대동단결했으니까. (웹키트 엔진에 번들로 제공한다고.)

웹키트의 개발자 도구는 조금 늦은 감이 있다. 웹키트 자체 DOM 검사기가 2006년에 소개됐으니까.

하지만 초기에 기능이 워낙 강력해서 Firebug 보다 나았던 시절도 있었다는 것.

왜냐면 이녀석은 시각적 효과가 화려하게 제공되고, 자바스크립트 콘솔이 강력했다. 자동완성을 먼저 지원했기 때문이다.

사실 IE 8과 비슷한 시기에 웹키트 기반 개발자 도구가 대중에 공개됐는데, Firebug 에 비해 이녀석은 아예 그냥 모든 사이트라면 F12 만 누르면 죄다 수집하고 분석하고 기록한다.

어찌보면 편하기도 하지만, 프레임으로 지속적으로 불러오는 웹 사이트 구조라면 계속 수집해서 목록이 늘어날수록 성능이 떨어지는 단점이 있다. 이는 어쩔 수 없다.

그래서 조금은 불편한 감이 있기도 하다. 왜냐면 Firebug 와는 달리 특정 기능만 키고 끌 수가 없으니까.

그래도 나름 웹키트 다운 면모가 있다.

그리고 사파리와 크롬은 결국 개발자 도구도 다른 길로 걷게 되는데, 사파리는 웹키트의 주를 이루니 웹키트 흘러가는대로 가지만, 크롬은 웹키트 변형 엔진인 블링크를 만들어 쓰기 시작해서 지금도 비슷하게 생겼지만 점점 달라지고 있다는거.

8. 마치며.

사실 각 플랫폼별로 나열했기 때문에 누가 먼저 하고 그다음 누가 했는지 햇갈릴 것이다. 그건 필자도 인정한다.

한가지 분명한 사실은, 넷스케이프에서 가장 먼저 개발자 도구를 만들기 시작했고, 그 전신을 이어받은 모질라가 먼저 개발자 도구를 만들고 선도한 것은 틀림없는 사실이다.

불여우가 웹 개발자를 위한 브라우저라고 누차 강조한 이유가 그 역사를 달고 태어났기 때문이라고 나는 자신있게 말한다.

어쨌든, 이렇게 개발자 도구가 서로 경쟁하고 선도하고 발전하면서, 웹 개발이 이렇게 발전할 수 있었던게 아닐까 싶다.

웹 디자인도, 웹 개발에 초석이 되지 않았다면, 가뜩이나 웹 디자인에 가장 많은 의존을 하는 CSS 개발도 어려웠을 것이다.

생산성도 향상되고 디자인도 여러가지로 화려해졌지만, 그렇다고 단가가 낮아진 건 아니다.

클라이언트가 요구하는 건 점점 더 다양해지고, 이를 수용할 수 있는 웹 디자이너와 개발자는 그만한 가치가 있기 때문이다.

이렇듯 웹 개발자 도구는, 절대 무시해선 안될 도구다. 특히 웹 개발자는 더. 액티브엑스? 몰라. 그딴거.

개발자 도구. 고맙게 쓰자.

composite / 2014년 2월 10일 / 미분류 / 0 Comments