안녕하세요~
2011년도 상반기 와플스튜디오 리크루팅의 면접 후기로 블로그 첫 포스팅을 쓰게 된 초코회원 박면규입니다. 제가 이번에 후기를 쓰게 된 이유는, 제가 지원자 자격으로 와플의 리크루팅 면접을 두번이나 봤던 와플의 최초 재수생(?) 이기 때문입니다. 좀 수정되긴 했지만, 이번 리크루팅 지원서 질문들도 제가 만들었구요.

먼저 합격자 분들에게 축하한다는 말로 본격적인 후기를 시작하고 싶군요. 와플스튜디오의 새 회원이 되신 여러분들 모두 축하드려요~ 앞으로 왕성한 활동 기대하겠습니다^^
이번에 지원해 주셨지만 아쉽게 떨어지신 분들에겐 심심한 위로의 말씀을 드립니다. 하지만, 이번에 떨어지셨다고 해서 기회가 완전히 없는 것은 아니므로 너무 실망하지 마시고 부디 이 글을 잘 읽고 다음에 다시 한번 지원해 주셨으면 좋겠습니다. 서론이 길었네요. 시작 하겠습니다.

지원서(서류면접) 후기

이번 면접을 하기 전부터 가장 크게 느꼈던 부분은 페이스북과 소셜커머스의 영향력입니다. 현재 어마어마한 성장을 계속하고 있는 페이스북과, 작년에 본격적으로 활성화되기 시작했던 소셜커머스 붐의 여파가 이번 지원자 분들의 지원서에서도 여지없이 느껴졌습니다. 페이스북이 주커버그가 대학생때 만든 서비스라는게 부각되었고, 그로 인해 대학교 동아리인 와플스튜디오에도 사람들이 많은 관심을 가져 주신 것 같네요. 리크루팅 직전에 언론에 기사가 났던 것도 긍정적인 부분이 많았고요.

개인적으로 지원자분들의 지원서에서 아쉬웠던 점은, 정말 지원서를 공들여서 썼다는 느낌을 주신 분들이 별로 없었다는 점입니다. 지원저 제출 양식은 꽤 간단하게 되어있지만,  그렇다고 해서 단답식으로 작성하라고 그렇게 큰 공간을 준 건 아니었거든요. 서류에서부터 미운털(?)이 박힌 사람은 아무래도 실제로 면접을 볼 때에도 약간 색안경을 끼고 보게 되더군요.(그러면 안된다는 걸 알지만..)

그 다음으로 아쉬웠던 점은 저희 와플스튜디오라는 동아리에 대해 기본적인 정보나 활동등을 제대로 알지 못했던 분들도 계셨다는 점입니다. 적어도 어떤 단체에 들어가기 전에는 그 단체에서 무엇을 하는지, 어떤 활동을 하고 있는지에 대해서는 알아야 한다고 생각해요. 그런것조차 제대로 알지 못하는 사람이라면, 당연히 감점이 있을 수 밖에 없습니다. 여긴 뭐하는 동아리지? 일단 들어가서 활동해보고 판단해볼까? 하는 식의 마인드를 가진 사람을 저희가 원하는게 아니기 때문입니다. 그런 사람들을 원한다면 일년에 한번(이젠 상반기/하반기로 나누어서 진행될 예정입니다.) 면접을 봐서 사람들을 뽑을 이유가 없겠죠.

또 하나 아쉬웠던 점은, 주로 신입생이나 저학번이신 분들의 지원서에서 많이 드러나는 자신감의 부족입니다. 이건 저도 경험해봤기에 말씀 드릴 수 있지만, 신입생 분들은 아직 프로젝트 경험이나 개발 경험이 없는 경우가 대부분이기에 지원서에 이런 항목이 들어가는 거 자체가 약간 부담이 될 겁니다. 경험이 없는건 괜찮아요. 저희도 신입생들에게 많은 실력을 요구하는게 아니랍니다. 하지만 프로젝트 경험이나 개발 경험이 없다고 해서 개발에 대한 자신감까지 없는건 좋아보이지 않아요. 난 뭘 해도 할 수 있다는 자신감과 열정, 그리고 웹에 대한 관심이 중요합니다.  아직 앞날이 창창한 대학 새내기들이 자신감이 없어선 안되죠 ㅎㅎ
예를 들어볼게요. 저희 지원서중에 “지금까지 경험한 동아리활동이나 개인 또는 팀 프로젝트 활동의 정보와 기간, 그리고 그 활동의 성과를 설명해 주세요.” 라는 문항이 있었습니다.
A라는 사람은 없음.
B라는 사람은 아직 개발 경험은 없지만, 와플에 들어가 얼른 이것저것 많이 배워서 와플의 프로젝트에 참여해보고 싶습니다!
라고 쓴 두 사람이 있으면 전 B를 뽑습니다.

음 뭔가 좋은 예 같진 않지만 넘어갑시다. ㅋㅋ (이거 쓰다보니 다음 지원서에는 해보고싶은 프로젝트 문항을 넣어야겠다는 생각이 드는군요.)

면접 후기

이번 면접은 지원자가 많은 데 비해 면접을 진행할 시간이 부족해서 한 사람 한 사람의 면접 시간이 짧아 질 수 밖에 없었습니다. 그래서 보통 한 사람당 10분의 면접 시간을 가졌고, 진행 해 본 결과 10분은 면접을 진행하기에 결코 넉넉한 시간은 아니었던 것 같네요. 그 짧은 시간동안 지원자들을 판단하려면 특정 기준에 맞춰야 했습니다.

면접을 진행했던 동아리원 모두 각자의 기준을 가지고 지원자들을 판단했겠지만, 제가 판단한 기준은 ‘이 사람이 우리 동아리에 어떠한 기여를 할 수 있을 것인가’ 입니다. 그 외에 부가적으로 열정, 관심, 자신감 등을 보았구요.
와플은 동아리이지, 자원봉사 단체가 아니기 때문에 우선적으로 동아리에 특정한 ‘기여’를 할 수 있는가의 여부를 보게 되더군요. 물론 여기서의 ‘기여’라는 건 한 방향이아닌 양 방향으로, 서로가 서로의 발전에 도움을 줄 수 있는지 입니다. 그걸 위해서 또 보게되는 건 ‘이 사람이 우리 동아리 활동에 얼마만큼의 시간을 쏟을 수 있을 것인지’ 와 동아리 활동에 ‘얼마만큼의 열정을 가지고 있는지’ 였습니다. 그리고 마지막으로 본 건 정말 만들어보고 싶은 특정 서비스가 있는지의 여부입니다.

우선 하고싶은 게 구체적일 수록  높은 점수를 줬습니다. 너무 뜬구름 잡는 얘기나 자신이 만들어보고 싶은 어떤 것에 대한 열정이 없는 사람들에겐 큰 점수를 안 주게 되더군요. 그리고 이 사람이 우리 동아리 활동에 얼마만큼의 시간을 쏟을 수 있을 것인지를 보다보니, 앞으로 저희 동아리에 남아 있을 수 있는 시간 + 물리적인 거리(동아리 방에 얼마나 쉽게 올 수 있는지)를 보게 되었습니다. 지금까지 와플 활동을 하면서 동아리 활동에 저 두 가지가 참 큰 영향을 미친다는 것을 직접 느끼고 있기에, 아무래도 안 볼 수가 없더군요. 그래서 저 분야에서 점수가 낮으신 분들은 저 개인적으로는 높은 점수를 드리지 못했습니다. 이런 점에서 본의 아니게(?) 기숙사에 사는 새내기들에게 점수를 많이 주게되었습니다.
여담이지만, 면접을 진행하면서 지난날의 제 자신을 돌아보게 되었네요. 평가하다보니 ‘아, 내가 이래서 떨어졌었구나ㅠㅠ’ 하는 걸 느낄 수 있었습니다. 그리고 위의 기준은 순전히 저의 개인적인 의견이지, 동아리원 모두의 의견이 아님을 밝힙니다. 그러므로 혹여나 떨어지신 분 들 중엔 저 기준을 충족시키는 분들도 있을 거고, 합격자 분들 중에도 저 기준을 충족시키진 못하는 분들도 있을 거에요. 제 후기는 여기까지입니다.

첫 번째 포스팅을 마치며

휴 역시 블로그 포스팅은 힘드네요 ㅠ ㅋㅋ 제 생각이 글로 충분히 전달 될 수 있었는지 모르겠네요. 합격자 분들에겐 다시 한번 축하의 인사를, 그리고 불합격자 분들은 아직 기회는 더 있으니 너무 낙심하지 말라는 위로의 말씀을 전하면서 첫 번째 포스팅을 마치도록 하겠습니다. 좋은 주말 보내세요~

안녕하세요!

오랜만(?)입니다. 첫 번째 글은 재미있게 읽으셨나요? 어설픈 구석이 많은데 읽어 주신 분들이 많으셔서 다행입니다. 흐지부지 되는 거 아닐까 걱정했는데 ㅋㅋ 세 편 모두 완성할 수 있겠어요.

제가 세 편의 글을 통해 다루는 내용을 제대로 알기 위해서는, 영화 뿐만 아니라 마크가 작성하는 글을 유심히 지켜볼 필요가 있습니다. <소셜 네트워크>의 각본을 쓴 애론 소킨은 주커버그가 실제로 쓴 라이브저널 글을 참조했다고 하죠. 지금 그 페이지는 없어졌지만 이 영화와 관련된 재미있는 사실들을 다루었던 SlashFilm의 포스팅에서 내용을 보실 수 있습니다. 자타공인 소셜 네트워크 열혈 팬 김진영(@howsthatmovie)군이 운영하는 블로그 Crawled Inside에서도 소셜 네트워크에 관한 글을 여럿 찾아볼 수 있습니다. 철은 좀 지난 영화입니다만 관심 있으신 분들은 꼭 들러 보시길!

사용자 입력 검증하기

Mark (V.O.) Next is Elliot. They’re also open but with no indexes on Apache. I can run an empty search and it returns all of the images in the database in a single page. Then I can save the page and Mozilla will save all the images for me. Excellent. Moving right along. Flying by at super-speed on MARK’s computer screen have been commands and images that the rest of us can’t possibly understand.

이번엔 엘리엇 기숙사입니다. 대사는 좀 싱겁다는 느낌이 없잖아 있는데 해설은 참 오글오글.. 하네요. 이 씬에는 아무도 이해 못하는 장면은 커녕 마크가 블로깅하는 컷이 들어가 있습니다.

그는 폭풍 블로깅 중..

엘리엇 기숙사는 지난 글에 나왔던 커클랜드 기숙사보다는 좀 형편이 나아서, 아파치 자동 인덱스를 설정해 두지는 않았네요.

이 곳의 문제는 온라인 페이스북 페이지를 잘못 개발한 것이었습니다. 웹 어플리케이션을 개발할 때 사용자가 올바른 입력을 했는지 검증하는 것은 모두들 이미 알고 계시겠지만 아무리 강조해도 지나치지 않을 정도로 무척 중요합니다. 엘리엇 기숙사 페이스북의 서비스는 검색 기능에서 사용자 입력 검증을 소홀히 했네요.

검색 기능을 가장 게으른 방법으로 구현한다면, 검색어를 받아서 그 검색어를 이름에 포함하고 있는 학생들을 찾는 방법을 사용할 것입니다. ‘황’ 을 이용해서 검색했을 때 ‘황인범’ 과 ‘황호성’ 이 나온다거나, ‘원’ 으로 검색하면 ‘홍원욱’, ‘이성원’ 이 나오는 것처럼요.

이렇게 검색이 이루어질 때 빈 문자열이 입력되면 어떻게 될까요? 빈 문자열은 길이가 0인 문자열이라고 할 수 있습니다. 모든 문자열은 길이 0인 문자열을 포함한다고 보기 때문에, 모든 학생들의 이름에도 길이 0인 문자열이 포함되어 있고, 결국 빈 문자열을 제대로 처리해주지 않으면 모든 학생들의 목록을 결과로 내어놓게 됩니다.

가끔 이런 결과를 의도하는 경우도 있긴 하지만, 이런 실수는 흔히 찾아볼 수 있습니다. 회원 가입 페이지에서 우편 번호를 검색할 떄나, 쇼핑몰의 상품을 검색할 때나 가끔 한 번 씩 시도해 보세요. 빈 검색어를 그대로 입력하면 수백 개에서 수천, 수만 개에 이르는 검색 결과를 보실 수도 있을 겁니다.

Deep Web

위에서 쓴 것과 같이 사용자 입력이 필요한 폼을 페이지에 넣을 때는 주의할 필요가 있습니다. 자칫 잘못하다간 나쁜 사람들의 표적이 되어 소중한 데이터를 모두 공개하게 될 수도 있습니다. 그런데, 그런 나쁜 사람들에게만 정보를 보호하면 될까요?

검색 엔진을 만드는 사람들은 자신들의 검색 엔진에 가능한한 많은 정보를 담으려고 노력합니다. 이 정보들은 검색 엔진의 웹 크롤러가 웹 페이지들의 링크를 따라 다니면서 모은 페이지들에서 얻어진 것이죠. 보통 웹 크롤러들은 <a> 태그로 나타나는 링크들만 따라서 다니는데, 이 페이지들 만으로는 충분히 많은 정보를 얻을 수 없다고 생각하는 사람들이 있습니다.

어떤 페이지로부터 링크는 되지 않았지만 위와 같은 검색 기능 등의 결과로 얻을 수 있는 동적인 페이지들 안에도 유용한 정보들이 많이 존재할 것입니다. 이렇게 동적으로 생성되는 페이지에서 더 효과적으로 정보를 수집하고자 하는 연구 분야가 있습니다. 이 분야를 연구하는 사람들은 일반적으로 <a> 태그를 통해 도달할 수 있는 페이지들을 Surface Web이라고 하고, 이에 반해 평범한 링크로는 도달할 수 없는, 사용자의 요청에 따라 생성되는 페이지들은 Deep Web 안에 있다고 하죠. Surface Web과 Deep Web의 관계는 수면 위 빙산과 수면 아래 빙산으로 비유되곤 합니다. Deep Web에는 지금은 정확히 가늠할 수 없는, 그만큼 많은 정보들이 숨겨져 있다는 것입니다.

Deep Web과 자주 비교되는 빙산. Photo credit: KatDeiss on Flickr

Deep Web의 정보를 이용하려고 노력하는 크롤러는 어떤 페이지에서 검색 창을 만나면 페이지 안의 단어를 조합해서 검색어를 구성하여 입력한다거나, 페이지 내용과 관련 있는 인기 검색어를 입력해 봄으로써 단순한 링크로는 공개되지 않는 많은 정보들을 얻으려고 합니다.

구글은 이미 지난 2008년에 이렇게 HTML 폼 너머에 감춰진 페이지들을 수집하고 있다는 내용을 Official Webmaster Central 블로그에서 발표하기도 했습니다. 지금은 크롤러의 이런 행동이 웹 보안에 큰 위협은 아닐지도 모르지만, 크롤러의 기능이 강화되고 많은 검색 엔진들이 Deep Web의 정보를 잘 이용하기 시작한다면 민감한 정보를 이러한 검색 기능으로 감추는 것은 그렇게 좋지 않은 선택일 것입니다.

두 번째 글을 마치며

이번 글은 말이 한참 새는 바람에 원래 쓰고자 했던 내용 일부를 다루지 못했네요. 분량 조절 실패의 암담한 그림자가 드리우기 시작합니다. 어쨌든 이 내용이 저에게는 더 재미있어서요… 아무쪼록 흥미롭게 읽어 주셨으면 좋겠습니다

Photo credit: woodleywonderworks from flickr

예전에 IDEO에서는 브레인스토밍에 관한 흥미로운 실험을 한 적이 있었습니다. 정확히 내용은 기억 나지 않지만 비슷하게 묘사하자면 다음과 같습니다.

몹시 시끄럽고 통제가 잘 되지 않는 나이인 8~10살 정도의 아이들 수십명을 초대해서 함께 조촐하게 과자 파티를 대접하고, 새로운 장난감에 대한 아이디어를 얻기 위해 브레인스톰을 해보도록 했습니다. 아이들은 두 집단으로 나뉘었습니다. 나누는 기준은 성별입니다. 남자 아이들과 여자 아이들이 각자 독립된 공간에서 브레인스톰을 하도록 했죠. 새로운 장난감에 대한 아이디어가 어떻게 아이들을 통해 만들어질 수 있는지 관찰하려고 했던 것이 원래 의도였습니다.

그런데 결과는 기대보다 놀라웠었는데요, 남자 아이들로 이루어진 집단이 50개 남짓한 아이디어를 낸 반면 여자 아이들은 그보다 몇 배는 많은 200개 정도의 아이디어를 만들어 냈습니다. 전혀 예상하지 못한 결과였습니다. 물론 만들어낸 아이디어의 질에 대해서도 논할 필요가 있겠지만, 일단 양적으로 너무 압도적이었습니다.

그렇다면, 이 실험이 즉각 남자 아이들보다 여자 아이들이 우수하다거나 창의적이라는 걸 의미할까요? 그런 방향으로 연구해봐도 흥미롭긴 하겠지만, 여기서는 거기까지는 다루지 않겠고 일단 이 결과에 대한 직접적인 요인은 다음과 같습니다.

시종일관 남자 아이들은 열성적이었지만, 자기 자신의 아이디어를 중심적으로 생각하고 그 속에서 어떻게 자신을 돋보이게 할 수 있을까에 열중했습니다. 반면 여자 아이들은 서로의 아이디어를 토대로 이와 연결된 새로운 아이디어를 끄집어 내고 있었고,  이런 식으로 협력해가면서 더욱 많은 아이디어를 만들어 냈습니다. 남자 아이들처럼 열성적이기까지는 못하더라도 나름대로 활기있게 진행되었습니다.

글쓴이인 저는 남자이기 때문에 사실 남자 아이들이 이런 모습을 보인 것에 대해 대단히 수긍하는 입장입니다. 뭐랄까 문화적으로 남자들은 자기만의 고유성(authenticity)에 대해 무의식중에 계속 주입받는다랄까요. 상대방에게 지지 말아야 하고 남과 똑같아서는 안되고 등등. 여자 아이들이 상반된 결과를 보일 것이라는 데까지 생각이 미치지 못했지만,  저 정도 나이의 남자 아이들이라면  저런 모습을 보인다는 것이 충분히 머리 속에 자연스럽게 그려졌습니다. 제 자신도 내 아이디어에 너무 집착하지는 않는지 반성하게 됩니다. 이 글을 읽는 여러분의 생각은 어떤지 궁금합니다만, 유의할 점은 이 실험이 명확한 대조군을 가지고 여러번 실험을 해서 나온 것은 아니라 학문적인 의미는 사실 없다는 점입니다. (새로운 선입견을 만들지는 않나 걱정이 됩니다.)

하지만 어찌되었건, 좋은 교훈을 알려주긴 하죠. 그것은 좋은 아이디어를 얻기 위해서는 상대방의 아이디어를 존중하라는 것과, 상대방의 아이디어는 나의 새로운 아이디어를 만들어 내는데 매우 효과적이라는 점이죠. 그래서 위 이야기는 그 자체로도 흥미로운 내용이긴 하지만 사실 브레인스토밍과 관련된 중요한 원칙을 보여주고 있기도 합니다.

대체로 브레인스토밍에 관해 몇 가지 대원칙을 제시하는데요, 그 중 네 개 정도를 제시하면 다음과 같습니다.

1. 아이디어에 대한 비판은 최대한 미뤄라
2. 아이디어의 개수는 중요하다. 최대한 많이 만들고자 노력하라.
3. 나온 아이디어에서 파생된 새로운 아이디어를 만들어라
4. 말도 안될 것 같은 아이디어를 존중하라

아이들의 이야기는 3번에 관한 이야기라고 할 수 있습니다.  브레인스토밍은 아이디어를 끊김없이 최대한 많이 만들어내고자 하는 과정이기 대문에 사고의 흐름이 끊어지도록 하는 비판이나 평가는 나중으로 미루는 것이 필요하고, 최대한 많은 아이디어를 냄으로써 그 중에서 좋은 것이 나올 수 있도록 하는 것입니다. 말도 안될 것 같은 아이디어도 브레인스토밍에서는 중요한 것은 거기에서 말이 되는! 놀라운 아이디어가 생겨날 수도 있기 때문입니다.

제 개인적으로는 브레인스토밍 과정이 생물의 진화 과정과 비슷하다는 느낌을 받습니다. 기존의 아이디어로부터 새로운 아이디어가 생겨나고, 굉장히 독특하고 도발적인 아이디어가 커다란 장벽을 넘는 점프를 가능하게 하며, 둘 이상의 아이디어가 이종 교배하면서 전혀 새로운 아이디어를 만들어내며 진화하기 때문입니다.

경험적으로는, 위 원칙이 꽤 잘 먹히긴 하지만 2번 “아이디어의 개수는 중요하다. 최대한 많이 만들고자 노력하라.”는 주의해야 하는 부분입니다. 아이디어의 개수를 최대 목표로 정하고 나면 구성원들이 진지하게 좋은 아이디어를 내기보다는 숫자 채우기에 급급해지는 모습을 보이기 쉽기 때문입니다. 위 원칙은 결국 좋은 아이디어를 얻기 위한 수단일 뿐이지 목표가 되어서는 안되는 부분입니다.

이상 브레인스토밍에 대한 저의 짧은 생각이었는데요, 프로젝트의 시발점인 브레인스토밍의 묘미에 여러분도 빠져보는 것이 어떤가요?

“서바이벌 나는 디자이너다” 첫 번째 미션 주제를 공고합니다.

첫 주 미션은 서울대학교 모바일 앱의 Splash Screen을 디자인 하는 것입니다. 경연은 2011년 4월 2일(토), 와플스튜디오 정기회의가 끝난 직후부터 2시간 동안 치뤄집니다. 첫 주는 참가자들의 역량 파악을 위한 것으로 탈락은 없습니다. 다만 이번 경연에서 1위를 한 분의 작품은 향후 서울대학교 모바일앱의 Splash Screen으로 이용될 것입니다.

심사위원: 조현아, 황호성

P.S. 포스터 1시간 만에 급조하느라 퀄리티가 떨어지는 점 양해 부탁드립니다 ㅋㅋ

들어가며

영화 <소셜 네트워크>에는 조금이라도 개발에 관심이 있는 분들이라면 주목하지 않을 수 없었던 장면이 있습니다. 흥미로웠던 오프닝 다음으로 이어지는, 에리카(루니 마라)에게 차인 복수심에 불타오른 마크(제시 아이젠버그)가 페이스매쉬라는 웹 어플리케이션을 만드는 장면입니다. 보이스오버로 깔리는 마크의 혼잣말은 잘 모르는 분들이라면 어렵구나~ 복잡하구나~ 하고 흘려 보낼만한 부분이지만, 꽤 자세한 부분까지 신경 쓴 세세한 묘사가 돋보였습니다. 여기서 놓치기 아쉬운 것들이 몇 개 보여서 언젠가 정리해보고 싶던 차에, 이렇게 글을 쓸 기회가 생겼네요.

바로 이 장면! 제시 아이젠버그 표정 너무 귀엽네요..

정리한 내용은 한 포스트에 모두 넣기에는 너무 많아서 아마도 세 번 쯤에 걸쳐 쓰지 않을까 합니다. 첫 번째 포스팅은 가볍게 커클랜드 기숙사 홈페이지를 털 수 있게 해 주었던, 마크의 말마따나 어린애 장난같은 아파치의 자동 인덱스와 wget에 관한 겁니다.

MARK (V.O.) First up is Kirkland. They keep everything open and allow indexes in their Apache configuration, so a little WGET magic is all that’s necessary to download the entire Kirkland facebook. Kids’ stuff.

아파치의 자동 인덱스 (mod_autoindex)

아파치 httpd 같은 웹 서버는 어떤 파일을 달라는 요청을 받았을 때 그 파일을 보내는 것으로 응답합니다. 만약에 파일이 아닌 디렉토리를 달라는 요청을 받으면 어떻게 할까요? 디렉토리에 대한 요청을 받은 웹 서버는 요청 받은 디렉토리 안에 index.html 과 같이 그 디렉토리를 대표하는 파일(이하 인덱스라고 부르겠습니다.)을 찾아서, 이 파일을 디렉토리 대신 보내게 됩니다. 그런 파일이 없으면 웹 서버가 할 수 있는 일은 원하는 파일을 찾을 수 없다는 404 오류를 내는 것 뿐이죠.

아파치의 autoindex 모듈(mod_autoindex)은 인덱스가 없는 디렉토리에 대한 요청이 들어와도 자동으로 인덱스를 생성해 줍니다. 아파치에서 제공하는 엄청 긴 문서를 읽어보면 아시겠지만, 기능이 상당히 많습니다. 정렬은 기본이고 파일에 아이콘을 추가한다거나, 어떤 파일에만 특별한 설명을 붙인다거나, 페이지에 여러분이 원하는 내용을 추가한다거나 할 수 있습니다. kernel.org의 리눅스 소스 파일 배포 페이지에도 이 모듈을 사용한 것 같네요. 자동 인덱스는 이렇게 파일 배포에 쓰이는 페이지에서 사용하기 참 편리한 기능입니다. 웹 브라우저만 있으면 접근할 수 있도록 할 수 있고, 파일이 바뀌어도 따로 수정할 필요가 없으니 관리도 수월하니까요. 여기저기 필요한 분들도 많았을 것 같아요. 이와 비슷하게 웹 페이지를 통해 파일을 배포해주는 베리즈 웹쉐어(돌아오세요! ㅠㅠ)같은 유용한 프로그램들도 있으니 말입니다.

kernel.org의 파일 배포 페이지

그렇지만 이 모듈은 조심해서 사용해야 합니다. 아무 디렉토리에나 활성화하면 공개하지 않아야 하는 파일들도 모두에게 공개되어 버릴 수 있습니다. 마크도 커클랜드 기숙사 페이스북의 사진을 담아 두는 디렉토리에 자동 인덱스 모듈이 활성화되어 있다는 것을 발견하곤, 기숙사 학생들의 사진 목록을 가져올 수 있었습니다. 만약 모듈이 활성화되어 있지 않았다면 사진 디렉토리에 요청을 보내도 오류만 나왔겠죠. 이 모듈은 보통 아파치를 처음 설치하면 활성화되어 있기 때문에, 특별히 파일을 공유할 목적이 없다면 모듈을 비활성화하는 Options -Indexes 설정을 해 주시는 것이 좋습니다.

Wget

마크는 커클랜드 기숙사 전산 담당 직원의 멍청한 실수 덕에 사진 파일 목록이 담긴 페이지를 얻어왔습니다. 이 페이지에서 링크가 걸린 파일 하나하나를 받으면 모든 사진을 모을 수 있는 거죠. 근데 하나하나 클릭하고 앉아 있었으면 밤을 새도 시간이 부족했을지 모릅니다.

마크는 여기에서 Wget을 사용합니다. Wget은 정말정말정말 널리 쓰이는 유틸리티인데, 쉘에서 웹이나 FTP에 있는 파일을 가져올 때 씁니다. 이렇게요.

Wget을 이용해 blog.wafflestudio.com의 index.html을 저장해 봤습니다.

근데, 이렇게 간단해보이기만 하는 Wget이 HTML 페이지를 파싱할 수도 있는 것, 알고 계셨나요?

Wget은 Recursive download라고 해서, HTML 페이지 안에 <a> 태그의 href 속성이나 <img> 태그의 src 속성 같은 걸 이용해 한 페이지에 연결되어 있는 다른 페이지들도 한 큐에 가져오는 기능이 있습니다. 위와 똑같은 wget 명령에 -r 옵션만 추가해주면, 이런 결과가 나옵니다.

아까 그 wget에 -r 옵션을 추가해서 Recursive download를 해봤습니다.

위와 같이 Wget은 와플스튜디오 블로그 첫 페이지에 나오는 온갖 링크란 링크는 다 따라가면서 가져온 파일들을 서버와 똑같은 디렉토리 구조 아래 저장합니다. 달리 추가로 설정할 것도 없이 그냥 HTML 페이지를 파싱해줍니다. 글씨만 나와서 알아보기 힘드실 것 같지만요..

깊이를 지정할 수도 있어서, 링크를 한 번만 타는 게 아니고 5개까지 깊이 들어갈 수도 있습니다. 이 과정에서 걸리는 많은 파일 중에 확장자가 그림 파일인 것만 가져오도록 할 수도 있구요.

마크도 아까 얻은 사진 목록 페이지에 Wget의 Recursive download 기능을 사용했을 겁니다. ‘A little WGET magic’ 이라고 할 만 한가요? ㅋㅋ

Wget은 평소에 사용하는 것보다 훨씬 강력하고 다양한 기능을 제공합니다. 몇 분 정도 시간 괜찮으시면 Wget 매뉴얼을 읽어보세요. 누군가가 머리 싸매고 개발하려던 것들이 이미 다 예전에 만들어져 있는 것일 수도 있습니다.

다음에 계속!

지금까지 대사 하나만큼 왔습니다. 쓰고 보니까 생각만큼 많지는 않네요. 조금 시시한 것도 같고.. 아직 몇 마디 더 남았으니, 다음에는 이번보다 더 충실한 내용으로 돌아오도록 하겠습니다.

안녕하세요. 와플스튜디오 설립 참여자이며 2기 회장을 맡았던 이익제입니다.

와플스튜디오 동아리(이하 와플)가 만들어진지 벌써 5년째가 됩니다. 지금까지 snuev, 서울대학교 아이폰앱, 안드로이드앱 등 서울대생을 대상으로 하는 서비스를 개발, 운영하기도 했고, 실제 운영하지 못한 수많은 서비스들을 개발하면서 와플의 역량을 키워왔습니다. 이미 졸업한 회원들은 NHN, 다음 등 인터넷 기업에 취업하기도 했고, 스타트업에 참여하기도 하면서 각자의 커리어를 키워가고 있습니다. ‘학생들이 모여서 무엇을 하겠나’ 라는 시선도 있었지만 조금씩 와플만의 문화와 역사를 만들며 발전하고 있다고 생각됩니다. 앞으로도 많은 격려와 조언 부탁드립니다.

블로그 개편을 맞이하여 조금 더 많은 분들의 참여가 있었으면 하는 마음과 와플을 응원해주시길 바라는 마음으로 다시한번 동아리를 소개하려 합니다.

와플스튜디오는 스터디나 리서치를 목적으로 하는 개발이 아닌, 실제 사용자들에게 제공할 수 있는 완성도 높고 유용한 ‘서비스‘를 만드는 것을 목표로 만든 웹개발팀입니다. 서울대학교 컴퓨터공학부 학생을 주축으로 2007년 1월에 설립하였고, 현재는 대학과 전공, 지식의 정도에 상관없이 열정과 가능성을 가진 모든 사람을 대상으로 하고 있습니다. 쉽게 이야기해서, NHN이나 다음, 구글이나 트위터, 페이스북 같은 회사에서 하는 일을 부족하나마 공부하고 실제 개발하여 서비스하는 ‘동아리‘ 입니다.

많은 분들이 와플에 대해서

• 뭐하는 곳인가요? 첨들어봤 (…)
• 프로그래밍 하는 개발자들만 있는거 아닌가요?
• 서울대학교 컴퓨터공학부 학생만 가입할 수 있는거 아닌가요?
• 이미 잘 하는 사람들이 모여있는 곳 아닌가요?

등 궁금함을 가지고 있으리라 생각됩니다.

하지만 와플은 기획, 운영, 디자인, 개발 등 다양한 분야에 관심과 열정이 있는 누구나 참여할 수 있고, 소속 대학이나 전공, 나이에 전혀 구애받지 않은 동아리 입니다. HTML이 무엇인지도 몰랐던 회원부터 이미 다양한 분야에 경험이 있는 회원까지 지식의 정도 역시 구애받지 않습니다. 오직 웹서비스에 대한 관심과 열정만을 기준으로 회원을 모집하고 있습니다. 조금 세속적으로 표현하면 앞으로 웹서비스 관련 커리어를 키우고 싶으신 분들에게 적합한 동아리입니다.

와플은 ‘웹‘ 개발팀입니다.

다양한 소프트웨어 분야 중 ‘웹’을 선택한 이유는 그것이 매우 효과적인 서비스 배포 환경이기 때문입니다. 윈도우즈, 리눅스, 맥을 쓰는 사람이나 아이폰, 안드로이드폰, 아이패드, 겔럭시 탭 사용자에 관계 없이 브라우저만 있으면 많은 사람들이 사용할 수 있습니다.   또 웹서비스는 총체적인 지식과 플랫폼을 대상으로 구축, 개발하기 때문에 얻을 수 있는 경험이 풍부합니다. 카카오톡을 예로 들면, 여러 모바일기기에 적합한 어플리케이션을 개발해야 하고, 편리한 UX를 제공해야 합니다. 인터넷을 통해 서버와 통신해야하고, 서버측 어플리케이션은 광범위한 데이터베이스를 효과적으로 운영하여 모바일어플리케이션에 정보를 제공해야 합니다. 또 대규모 사용자를 대상으로 하기 때문에, 하나가 아닌 수십, 수백대의 서버컴퓨터를 운영하면서 사용자에게 ‘하나’의 서버처럼 동작하는 것처럼 느끼게 해줘야 하는 클라우드 기술이 필요합니다. 이들을 실제 운영하려면 방치하는게 아닌 지속적으로 관리하는 능력이 필요합니다. 이를 위해 필요한 사용자에게 보이지 않는 수많은 서비스들을 활용해야 합니다.

와플은 실제로 ‘서비스‘를 ‘제공‘하는것을 최우선 목표로 합니다.

스터디나 리서치를 목적으로 하는 서비스 개발은 기획 단계부터 다릅니다. 스터디나 리서치는 협소한 목표를 위해 필수 요소를 제외하고 개발하게 됩니다. 디자인은 간단한 기본 버튼 몇개나 심지어 화면을 제공하지 않고 텍스트를 직접 입력하는 환경으로 돌리기도 합니다. 하지만 실제 사용자에게 제공하는 것을 목적으로 한다면, 사용자들이 쉽게 사용할 수 있는 UX 환경을 만들고 디자인도 섬세하게 신경쓰게 됩니다. 목표로 하는 핵심 서비스를 제공하기 위해서 구축해야 하는 부수적인 기능들 역시 많으며 이를 효과적으로 설계해야 합니다. 서비스 자체의 안정성 역시 매우 높게 만들어야 하고 천재지변이나 예측하지 못한 오류들에 대응할 수 있도록 주시적인 백업이나 모니터링 등 운영적인 부분들 역시 지원해야 합니다. 이것들은 실제 사회에 나가 업무를 진행하는데 반드시 이해해야 하는 부분들입니다.

‘웹‘을 이해하고 실제 ‘서비스‘를 기획, 개발, 배포하기 위해서는 통합적인 지식과 능력이 필요합니다. 디자이너는 포토샵으로 그림만 그리고, 개발자는 프로그래밍만 – 그것도 서버프로그래밍, 자바스크립트 프로그래밍, 아이폰 앱개발 프로그래밍 등으로 나눠서 – 해서는 좋은 웹개발을 할 수 없습니다. 다른 사람의 역할에 대해서 이해하고 유기적으로 소통해야만 좋은 서비스를 만들 수 있습니다.

이를 위해 와플은 T자형 인재를 목표로 활동하고 있습니다.

회원은 와플에 들어오면 메인 커리어에 관계없이 모든 회원들이 기획, UX, 디자인, HTML과 CSS 등 서비스를 표현하는 방법 등을 공부하고, 자신이 하고자 하는 커리어에 심화스터디를 하고 있습니다. 동시에 동아리 내의 다양한 프로젝트’팀’에 참여하여 웹개발을 진행합니다. 현재 snuev, snu mobile 등 (배포하지 못한 팀들을 밝히긴 힘드나 많은 팀들이 활동하고 있습니다) 다양한 프로젝트 팀이 운영되고 있고 UX, HTML5스터디 등 그때 그때 새로운 그룹이 만들어져 활동하고 있습니다. 또 회원 누구나 지지를 얻으면 새로운 팀을 만들어 활동하고 또 여러팀에 속해서 활동하기도 합니다.

최종적으로 2년 이상 와플의 이런 활동을 통해 지식뿐만 아닌 효과적인 웹개발 ‘문화’를 체화하여 어떤 커리어든 자신이 원하는 곳에서 즐겁고 재밌게 활동하시길 바라고 있습니다.

곧 있을 6기 리크루팅에 많은 참여 부탁드립니다.

안녕하세요, 와플스튜디오 모바일 앱 팀장 한재화입니다.

와플스튜디오에서 제작한 ‘서울대학교’ 모바일 애플리케이션이 버젼업 되었습니다.

안드로이드 애플리케이션은 여기서 아이폰 애플리케이션은 여기서 다운로드 받을 수 있습니다.

와플스튜디오가 ‘서울대학교’ 아이폰 앱을 필두로 학교 생활정보 애플리케이션을 만든지도 1년이 다 되어 갑니다. 그동안 꾸준히 사용해주신 서울대 학우 여러분께 감사드리고, 더욱 발전하여 대학생활에 없어서는 안될 Must-have 앱이 되도록 노력하겠습니다.

이번 v0.8에서 크게 변화한 점은 다음과 같습니다.

1. MySNU 시간표 연동 MySNU 계정을 통해 자신의 시간표 정보를 스마트폰에 저장하고 볼 수 있습니다.
2. 강의실 정보 확인 ‘지도’ 메뉴에서 자신이 듣는 강의실의 위치 및 강의 정보를 확인할 수 있습니다.
3. 공지사항 기능 와플스튜디오의 신선한 소식을 전해드릴 수 있게 되었습니다.
4. 도서관 열람실 현황 확인 중앙도서관의 16개 열람실의 좌석 현황을 확인할 수 있습니다.

많은 사용자 여러분들의 성원 부탁드리며, 사용상의 문의 및 개선 제안은 mobile at wafflestudio.com으로 보내주시면 감사하겠습니다.