블로그에 남겨야겠다고 생각한 내용이었는데, 벌써 한달이 넘게 지난 일이군요. 지난 얘기지만, 꼭 남겨두고 싶은 얘기들이 있어서 메모를 뒤적이며 기억을 되살려 남겨봅니다. 5월말 Werner Vogels박사 방한에 관련한 내용입니다.

Werner Vogels

아마존닷컴의 부사장이자 CTO인 Werner Vogels 박사님이 방한했습니다. All Things Distributed라는 테크니컬 블로그를 통해, 많은 개발자가 익히 알고 있는 분입니다. 모든 NoSQL 바람의 시초라고 할 수 있는 Amazon Dynamo 논문을 알게된 이래로, 블로그 피드도 구독하고 있으며, 그의 업적으로 전세계에 서비스중인 Amazon Web Services도 큰 관심을 두고 있습니다. 박사님에 대한 자세한 설명은 위키피디아에도 잘 나와 있습니다.

Facebook AWS User Group을 대상으로 특강

서울 디지털 포럼 2012에서 강연하기 위해 서울에 오셨다는데, 온 김에 페이스북의 AWS사용자 그룹을 대상으로 따로 시간을 내서 특강을 한다는 소식을 접했습니다. 윤석찬님이 Daum 한남오피스 건물 강연장을 쓸 수 있도록 섭외에 주셨지요. 덕분에 Daum의 직원들도 편하게 참가할 수 있었습니다.

발표한 내용은, AWS에 대한 기본적인 소개 정도로 볼 수 있었구요, 발표도 좋았고 질문과 답변시간에 다양한 언급도 기록해둘만 했습니다. 강의와 Q&A시간을 통틀어서 메모한 사항은 아래와 같습니다.

1. 이 시대의 보안모델
2. 모바일 애플리케이션을 먼저 만들기
3. 트랜잭션이 필요한 경우를 구분하기
4. Update빈도가 적은 데이터의 경우, DynamoDB대신, S3에 JSON/HTML데이터를 저장하는 방법

보안 모델에 대해, 과거에는 해자로 둘러쌓인 성(castle)으로 비유할 수 있었다고 말합니다. 내부의 보안 네트워크와 외부의 신뢰할 수 없는 네트워크로 구분하여 방화벽(성문)을 통과한 접근에 대해서는 모든 것이 허용된 모델이죠. 지금의 IT환경이 다 이렇습니다. 하지만, 이제는 점점 그렇게 통제할 수 있는 시대가 아닙니다. 현재에는 도시 모델로 가야한다고 말합니다. 해자를 깊게파고 성벽을 높인다고 해결될 일이 아니라는 겁니다. 각각의 자원에 대해 자체적 보안을 강화하고 내부의 정찰도 중요시 해야할 것으로 보입니다. 게다가 오래전부터 각각의 OS에서도 자체 방화벽이나 보안모델을 쉽게 설정해 사용할 수 있으니, 잘 활용해볼만한 때가 된거 같습니다.

어떤 서비스나 어플리케이션을 개발할 때, 모바일 대응이 먼저라고 말합니다. 일반 PC웹 트래픽대비 모바일의 성장세가 가파르고 이제 은 모바일이라는 거죠. 아주 당연한 얘기라 부연할 내용이 없습니다. 그저 끄덕이며 넘어갈 수 밖에요.

DynamoDB에 대한 청중의 질문중, 트랜잭션처리에 관한 것이 있었습니다. 그는 트랜잭션이 필요한 두가지 관점을 언급했습니다. 첫째, 하나의 레코드(아이템)에 대해 다수의 writer가 접근할 때의 atomicity를 위한 관점이 있고, 둘째로, 다수의 레코드가 한번에 모두 업데이트되거나, 모두 그대로 남게하기 위한 관점(All or Nothing)입니다. 전자의 경우에는 DynamoDB도 잘 대응이 되어있지만, 후자의 경우는 아닙니다. 후자의 트랜잭션 처리가 필요하다면 별도의 처리가 필요합니다. 기존의 RDB들이 아주 잘하는 일이죠. 당연한 얘기지만, DynamoDB가 모든 애플리케이션에 만능으로 적합한 것은 아닙니다. 필요한 활용에 따라 적절한 서비스를 잘 골라 활용하는게 중요합니다.

마지막으로 메모한 팁이 흥미로웠습니다. Update빈도가 적은 데이터의 경우 S3에 JSON이나 HTML렌더링 데이터를 마치 캐쉬(cache)데이터인양 저장해놓고 클라이언트에서 직접 HTTP로 가져가는 방법을 언급했습니다. 왜 이런 생각을 못했을까 싶습니다.

저녁식사

박사님측 인원분들과 Daum직원 몇분이서 저녁식사를 함께 하게되었습니다. 고기와 맥주를 매우 좋아하시더군요. 간단한 질문에도 장황하게 많은 내용을 설명하면서 답변하시는 스타일이라, 언어의 장벽에도 불구하고, 끊이지 않는 대화가 이어졌습니다. 중간중간 아주 반짝이는 눈빛으로 자기가 하고 있는 일에 대한 열정을 보여주는 모습이 인상적이었습니다.

제가 “AWS의 훌륭한 프로덕트들을 오픈소스로 공개할 생각은 없었냐”고 여쭤봤는데, 오픈소스에 대해서는 고려하지 않고 계셨습니다. 소스를 공개하는것이 다가 아니고, 그에 따르는 운영이나 서비스를 제공하는 것이 의미있다고 강조했으며, AWS가 하는 일이 그 서비스를 값싼 전기 공급하듯 제공하는 것이라고 말합니다. “과거에는 직접 비싼 발전소를 짓고 전기를 썼었다면, 이제는 전력회사가 값싼 전기를 곳곳에 공급하는 것처럼 말입니다”

또 하나의 질문으로, Dynamo논문의 오픈소스 구현체인 Riak에 대해 어떻게 생각하시냐고 여쭤봤습니다. 제가 살펴본 구현체중 가장 맘에 드는 제품이기에 어떻게 평가하시는지가 궁금했습니다. (저는 리악에 가까운 발음으로 여쭤봤는데, 못알아들으시고 라이악에 가까운 발음으로 부르시더군요. 라이악이었나봅니다, 라이악.) Riak을 포함한 Cassandra, Voldemort 모두 다 Dynamo 논문의 카피에 불과하지 않냐고 말합니다. Dynamo 논문도 새로운 내용은 없고, 단지 이미 알려진 분산 기술들을 한군데 총체해놓은 것이 새로운 것이라면 새로운 것이라고 겸손히 말한 한편, 오픈소스 제품들에 대해서는 “무엇이 새로운가?”라는 평가였습니다.

이어지는 여러 주제의 얘기 끝에 대화의 맥이 끊겼을 즈음, 박사님께 사인 한장을 부탁했습니다. 농담으로 생각하셨는지 장난이었는지, 아니면 소주병이 특별해 보였는지, 소주병을 가르키며 소주병 바닥에다 사인을 해주시려 합니다. “아닙니다. 따로 싸인 받을 것을 가져왔습니다.”라고 말하며 따로 프린트해 온 박사님 논문을 내밀었습니다.

그러자, 사인하시길 망설이는듯 잠깐 기다리라고 하시더군요. 알고보니, 좋은 글귀(?)를 적어주시기 위해 고민하신거더군요.

코팅해서 보관해야겠습니다.

이런 분들을 만나서 얘기를 나눌 때의 장점은, 책이나 웹의 자료에서 쉽게 느끼기 어려운 열정을 전파받을 수 있다는 점입니다. 아쉬운 점은, 그 기운을 다시 글로 옮기기가 어렵다는 것이죠.

저도 제가 하는 일에 있어서, 박사님 같은 열정을 뿜어낼 수 있게되기를 기대해봅니다.

소프트웨어 공학 수업 수료

지난 포스트에서 소개드렸던 ‘Software Engineering for SaaS’ 수업의 5주과정이 모두 끝났습니다. 총 2만여명이 하나 이상의 강의 영상을 보았고, 1만여명이 한 번 이상의 과제 제출이나 퀴즈 응시를 했다는군요. 수료 기준은 총 과제 점수의 절반 이상, 그리고 총 퀴즈 점수의 절반 이상을 받는 것이었으며, 약 3,500명 정도가 수료 대상이라고 합니다.

저랑 같이 일하는 개발자 한 분도 이 수업 내용을 극찬했었는데요, 이렇게 좋은 수업의 내용을 전세계에서 3,500명이 열심히 들었다고 하니, 현업 종사자로서 위기감이 들기까지 합니다.

수업의 품질

사실, 정작 학생들은 이 수업이 얼마나 좋은 내용인지 모를 수도 있겠다 싶습니다. 현업에서 실무 경험을 해 본 사람이라면 정말 와닿을 만한 중요 사항들을 멋지게 정리해준 수업 내용에는 감탄을 너머 소름끼칠 정도였습니다. ‘미국 학생들은 이런 수업을 듣고 사회에 나온단 말인가!’하며 놀랄만했죠.

보통 대학 수업의 이미지가, 학술적 연구 중심의, 따라서 어느 정도 현업과 동떨어진 느낌이었다면, 이 수업을 진행한 교수님들의 얘기들은, 현업과 밀접한, 게다가 가장 최신이라고 할만한 현 시점의 기술들을 함께 설명하며 수업을 진행한다는 것이 정말 놀라웠습니다. 현업의 유명 개발자들을 쫓아다니며 인터뷰하는 영상까지 수업 보너스 영상으로 제공되고 있습니다. 농담 반, 진담 반으로 주변 사람과 “이런 수업들을 듣고 졸업한 신입 사원은, 3~4년차 개발자랑 비슷한 업무 능력을 보이겠다”고 얘기 했을 정도입니다.

2차 수업 진행

이 훌륭한 수업을 들을 수 있는 기회는 앞으로도 있습니다. 5월 18일부터 개정된 내용으로 다시 진행한다고 합니다. 근래의 웹서비스 개발에 관심이 있으시다면, 꼭 들어볼만한 수업입니다. 그리고 올해말, 10월이나 11월쯤에는 추가된 주제로 part2 수업을 진행한다고합니다. 저는 그 수업도 또 들어볼 예정입니다.

클라우드환경의 소프트웨어공학 수업

Coursera라는 단체(?)를 통해 무료로 제공되는 공개 수업을 소개합니다. 공개 수업 제목은 ‘Software Engineering for Software as a Service’입니다. 총 5주 과정으로, 현재 3주차과정이 진행되고 있습니다. 루비온레일스로 Software-as-a-Service 애플리케이션을 개발하고 배포하는 애자일 개발에 대해 알려줍니다. 버클리 대학에서 실제 했던 수업내용을 녹화해서 제공하는것 같구요, 버클리 학생들은 이 수업을 위해 주당 5~10시간정도를 할애했다고 합니다. 강의 내용은 약간의 프로그래밍을 해 본 사람이 웹서비스 애플리케이션을 개발해서 배포하는 것까지 다 해볼 수 있도록 탄탄하게 구성된 것 같습니다.

강의는 https://www.coursera.org/saas/class에서 등록해서 신청할 수 있고, 한편당 7~10분 길이의 강의동영상을 보면서 공부하면 됩니다. 총 4번의 과제 제출이 있고, 퀴즈 시험도 봅니다. 강의안을 살펴보면, 루비와 레일스의 기본을 포함해서, HTML/CSS까지 기초적으로 다 다루어줍니다. 게다가 Amazon EC2를 다뤄보는 과제도 있고, GitHub에서 간단한 레일스 애플리케이션을 클론받아서, 약간의 수정을 가해서 Heroku에 배포해보는 과제도 있습니다. 갖가지 유용한 플랫폼을 다뤄보는 경험도 되는거죠.

과제 제출/평가 시스템

온라인으로 숙제를 제출하고 평가받는 시스템인데요, 첫번째 과제의 경우, 기본적인 루비프로그래밍 연습 과제입니다. 과제로 주어진 내용의 소스코드를 작성해서 온라인으로 제출하면, 맞게 구현했는지를 자동으로 평가해서 알려줍니다.

아마도 자동으로 스펙돌려서 통과한 정도에 따라서 점수 평가하는 것으로 보입니다. 제출하고 잠시 기다리면, 스펙통과후의 점수를 확인할 수 있습니다. 하긴 6만여명(!)이 수강중이라는데, 이정도 과제제출 시스템은 있어야 제대로 평가할 수 있겠죠. 저는 아직 수강이 밀려서 퀴즈는 보지 않았는데, 퀴즈 평가 시스템도 훌륭할 것으로 기대중입니다.

강의 수준

소개되는 갖가지 요소들도 최신의(?) 기술들임은 물론이요, 강의 내용과 학생들의 질문도 대단히 수준급으로 보입니다. 교육의 질이 이렇게 다를 수 있나 의심스러울 정도로 말이죠. 루비언어에 대한 강의도 대단히 깔끔하고 간결합니다. 루비를 새로 배우시려는 분들은 물론이고, 알고 있는 내용을 리뷰하기도 아주 좋을 만큼입니다.

열려있는 수강 기회

이렇게 좋은 강의를 무료로 신청해서 아무 때나 들을 수 있으니, 공부하고자 하는 마음만 있으면 됩니다. Coursera 사이트에 가보면, 이 수업 말고도 다른 강의들이 준비중인게 많이 있습니다. SaaS수업이 너무 마음에 든 나머지, 다른 과목들도 시간 내서 들어보려는 욕심이 생겼습니다.

2000년도, 첫 직장에 다니던 때에는 ‘10년 경력’이라는 표현은 나와는 상관 없는 일이었습니다. 그저 ‘10년 경력이면 대단한 실력의 프로그래머가 되겠구나’라고 막연히 생각했었죠. 그야말로 어느덧 시간이 흘러 경력 햇수는 쌓였는데, 꼭 그만한 실력이 함께 쌓이는 것은 아닌가 봅니다. 10년 내내 열심히 실력을 연마하지 않은거겠죠.

이 글은, 그런 10년 경력의 프로그래머가 구글 코드 잼 코리아 2012(Google Code Jam Korea 2012)에 참가한 뒤 쓰는 후기입니다.

Google Code Jam

Google Code Jam는 2003년 부터 매년 구글에서 개최하는 프로그래밍 경진 대회로, 참가자가 본인이 선호하는 프로그래밍 언어로 제한된 시간 안에 주어진 복잡한 알고리즘 문제를 해결하는 대회입니다. 매년 수 많은 세계 각국의 참가자가 다양한 프로그래밍 언어로 참가하고 있습니다. 컴퓨터공학을 공부하는 학생이나, 현업 개발자, 아니면 취미로 프로그래밍을 하는 사람들까지 개인 능력을 뽐내거나, 구글에의 취업을 목표로 하는등 다양한 동기로 참가하고 있는 대회입니다.

2012년에는 특이하게도, 한국 지역의 별도 대회가 개최되었습니다. 이름하여 구글 코드 잼 코리아 2012입니다. ‘한국 거주자이면서 한국어를 사용하는 사람을 대상으로 한다’고 명시되어 있었습니다. 매년 수 많은 한국인 참가자의 호응에 힘업어 개최하게 되었다고 적혀있습니다. 아마도, 구글 코리아에서 대규모 채용을 앞두고 열리는 대회가 아닐까 추측해봅니다.

어떻게 참가하게 되었나?

이런 대회가 있다는 것을 제작년에 알았습니다. 제작년에 처음 대회 공지를 보고, 호기심이 일었습니다. ‘참가하면 어떤 성적을 거둘 수 있을까?’ 학창시절 이런 대회에 참가해보지 않은 것에 대한 아쉬움도 있었고, 참가하면 우수한 성적을 거둘 것 같다는 근거 없는 자신감도 있었습니다. 한편으로는 내 실력이 어느 수준인가를 객관적으로 평가 받아보고 싶었습니다.

지금까지 참가 결과

제작년에 처음 참가했을 때는, 아무런 감이 없었습니다. 예선-본선3라운드-아일랜드 더블린에서의 오프라인 결승으로 단계별 진행이었는데, 혼자 착각에는 ‘혹시 결승에 진출해서 아일랜드에 가게되면 휴가 일정을 맞출 수 있을 것인가’를 걱정하기까지 했었죠. 그것 참 걱정도 팔자였습니다.

그 해에는 간신히 예선을 통과하고, 본선 1라운드 참가합니다. 본선 1라운드는 세번의 기회 중 한번이라도 1,000위 이내의 성적을 거두면 본선 2라운드로 진출하게 되는데, 모두 1,800여위의 저조한 성적을 거두며 2라운드 진출에 실패했지요. 사실 이 때 적잖은 충격을 받았습니다. 더블린에 가려면 어떻게 일정을 맞출까 고민하던 자만의 나라에서 거닐다가, 본선 2라운드 진출 실패라는 나락으로 떨어진 충격이 얼얼했습니다.

작년의 두번째 참가 때에는 작전을 바꾸기로 합니다. 코드잼의 출제 문제가, 각종 복잡한 알고리즘과 수학적 문제 해결 능력이 중요한데, 제가 그런 면에서의 경쟁력이 약하다는 판단이 선거죠. 때마침, Seven Languages in Seven Weeks라는 책을 보고 있던 때이기도 했고, 몇몇 새로운 프로그래밍 언어에 관심이 많았던 터라, ‘다양한 언어로 도전하기’라는 번외 과제에 도전합니다. 복잡한 알고리즘 및 수학적 문제 해결의 정면승부에는 자신이 없었으므로, 다른 도전 과제로 자신감 회복을 노려보기로 한 꼼수입니다. 비록 번외였고, 결국 본선1라운드 문제를 단 문제도 풀지 못했지만, 약간의 자신감을 회복하는 결과를 남겼습니다.

올해의 2012년 한국지역 대회의 결과는, 벌써 후기를 올린다는 사실에서 아시는 분들은 이미 예측하셨을지 모르겠습니다. 아직 본선1라운드도 시작되지 않았는데 벌써 후기를 올린다는 것은, 예선 탈락이라는 뜻이지요. 이번 충격은 첫 해의 충격 못지 않았습니다. 예선 탈락은 처음인데다, 한국 지역 한정 대회이니까, 예선 문제가 더 쉽지 않을까 기대했었는데도 한 문제밖에 못 푼 것이죠. 매년 순위가 떨어지고 있는데 문제가 더 어려워졌기 때문인건지, 아니면 제 풀이 능력이 더 떨어진건지, 어쨋건, 예선 탈락은 거의 좌절감으로 이어집니다.

가치평가

첫 해의 좌절 이후 줄곧, 그런 생각을 하기도 합니다. “이런 복잡한 알고리즘이나 수학적 문제풀이 능력이 실제 개발 업무에서의 업무수행능력과는 큰 연관이 없다”라고 말이죠. 사실, 대학 3학년 때 알고리즘 수업 이후로, Dynamic Programming이나, Backtracking등을 적용해 볼 기회는 많지 않았던 것 같습니다. 기억에는 “다음 캘린더”서비스를 개발할 때, 일정그래프를 겹치지 않게 그려내는 로직을 구현한 때가 유일하지 않았나 생각됩니다. 그래 실제로 이런 복잡한 알고리즘 외에도 중요한 업무 능력들이 많다며, 이게 다가 아니라고 위안을 삼습니다. 한발 더 나아가서 ‘영어 시험 점수가 영어 실력과 직결되는 것은 아니다’라고 까지 뻗어볼 수 있겠습니다만, 거기까지 가보니 좀 지나친 자기합리화가 아닌가 싶더군요.

분명, 단순히 알고리즘을 구현하고 코드로 문제를 푸는 것 외에도, 개발자 업무에 있어서 다양한 능력이 필요합니다. 네트워크도 알아야죠, 기본적인 서버 운영도 알아야죠, 데이터베이스도 쓸 줄 알아야하는 것은 물론이요, 무엇보다 동료들과의 원할한 협업을 위한 커뮤니케이션 스킬이 가장 중요하다고 볼 수도 있죠.

그럼에도 불구하고, 구글코드잼 같은 경진대회 스타일의 문제풀이가 갖는 가치가 있습니다. 주어진 문제를 제대로 파악하고 이해하는 능력과, 그 문제를 끈기있게 접근해서 풀어내는 능력이 드러난다는 점에 주목해봅니다. 단지 알고리즘 풀이나 수학적 문제 해결 능력에 한정된 업무가 많지는 않을 수도 있습니다만, 기본적으로 어떤 문제를 제대로 인식하고 해결하는 능력은 엔지니어로서 가장 중요한 자질이 아닌가 싶습니다. 구글 코드잼 같은 경진대회가 문제풀이라는 영역으로 그런 자질을 시험해 볼 수 있는 기능이 있는게 아닐까요?

게다가, 주어진 시간동안 집중해서 끈기있게 푸는 근성도 평가됩니다. 길게는 24시간, 짧게는 3시간동안의 집중력을 검증해보는 기회입니다.

또하나 덧붙여서, 영어 읽기 능력에 대한 평가도 겸해집니다. 이번 한국대회야 한국어로 출제됐기 때문에 그렇지 않지만, 세계대회는 당연히 영어로 문제가 출제되기 때문에, 기본적인 영어 해석능력도 평가해볼 수 있습니다. 아무래도 영어 해석능력은 개발업무에 있어 꽤 큰 비중이 있다고 생각합니다.

느낀점

스스로의 프로그래밍 문제 해결 능력을 객관적으로 평가받았습니다. 다른 참가자들의 뛰어난 능력에 감탄하기도 했습니다. 학생때나 그 이후나, 알고리즘 공부를 열심히 하지 않았던 것 같다는 반성도 해보구요. 다시 알고리즘 책을 파고들어서 열심히 준비하면, 조금 더 풀 수는 있을 것 같다는 생각은 들지만, 높은 순위의 사람들처럼 천재적으로 풀어낼 자신은 없습니다.

오랫동안 개발 일을 해왔다는 사실만으로, 내가 프로그래밍을 잘하는 것이라고 착각하고 자만했던 일을 싹 걷어낼 수 있는 계기가 된 것 같습니다. 겸손한 마음으로 더 열심히 노력해야겠다는 생각이 꿈틀꿈틀합니다. 남들에게 잘보이기 위한 겸손이 아니라, 더 열심히 배우기 위한 겸손이 필요합니다.

너무 스스로 기죽는 것을 막기 위해, 좋게 평가하는 부분도 언급해보겠습니다. 한편으로는, 어려운 문제 풀이를 두고, 끝까지 포기하지 않고 도전하는 근성이 만족스러웠습니다. ‘내 현재 능력으로 더 이상 노력한다고 풀릴 문제가 아닌거같아’라고 생각이 들면서도, 매번 마감시간까지 포기하지 않고 도전했던 점은 기특합니다. 아직 내게도 근성이 남아있구나 생각하며 스스로를 토닥여보았습니다.

앞으로의 방향

이 상태로는 더 도전한다고 나은 성적을 거둘것 같지는 않습니다. 차근히 알고리즘 책부터 다시 보며 연습해야 다른 결과를 낼 수 있습니다. 당장 그런 공부를 하지는 않을 것이기에, 올해 세계대회는 아마도 참가하지 않을 것 같군요. 이 분야가 아니더라도 다른 재미있고 제가 더 잘할 수 있는 공부거리가 많이 있습니다. 당장 현업에 필요한 공부거리도 많구요.

코드잼이 아니라, 제가 잘하는 분야에 더 집중해서 장점을 키워나가는게 목표입니다. 하지만, 언젠가 이 굴욕(?)을 씻기 위해 틈틈히 공부하고 연습하고 있을지도 모르겠습니다.

GitHub을 소개한 글

엊그제 류광님의 웹 항해일지 - GitHub 특집을 읽었습니다. GitHub에 관련한 소개와 함께 유용한 관련 링크를 알려주셨습니다. 덕분에 GitHub/git에 관심있는 다른 분들의 블로그도 찾아가 볼 수 있었지요. 그 글에도 처음으로 언급돼있듯이, 석찬님이 이미 2009년 1월에 Github, 코드 개발 기반 소셜 네트웍이라는 글로 아주 상세하게 잘 설명해 주셨더군요. 두 글을 읽어보시면, 아 ‘나도 Git/GitHub을 써야겠구나’하는 생각이 들게끔 잘 소개해주신 것 같습니다.

Git: 분산 버전 관리 시스템

Git의 장점은 여러가지가 있지만, 저는 강력한 브랜치/머지 기능과 GitHub의 존재를 가장 먼저 꼽을 것 같습니다.

그전까지 쓰던 버전관리 시스템으로는 브랜치(branch)를 사실상 쓸 수 없었습니다. 브랜치를 만드는 것 까지야 쉽게 할 수 있지만, 조금 지나서 머지(merge)를 하려다보면, 매우 안좋은 경험(?)을 하게되곤 했죠. 따라서 “브랜치 = 쓰면 안되는 기능”이라는 인식이 자연히 생겼던 것 같습니다.

Git에 이르러서야, 브랜치기능을 제대로 쓸 수 있게되지 않았나 합니다. 브랜치를 워낙 쉽고 가볍게 쓸 수 있다보니, 팀협업에 있어서 좋은 것은 물론이요, 혼자서도 툭하면 브랜치 따서 작업하는 일이 기본이 되었죠.

GitHub

게다가, GitHub은 Git의 원격 저장소기능을 뛰어넘는 훨씬 중요한 역할을 합니다. 소셜코딩이라는 문화도 만들어 내고, 오픈소스 프로젝트의 문화마저 바꿨다고 해도 과언이 아닐 것 같습니다. 심지어 어떤 미국 벤처기업의 개발자 채용공고에서 ‘이력서에 GitHub 계정의 링크를 같이 보내라’는 문구를 본 적도 있습니다.

국내의 Git 소셜 코드 커뮤니티

당연한 얘기지만, 국내에서도 GitHub을 이용하는데 아무런 문제가 없습니다. 누구나 무료 계정을 만들 수 있고, 원한다면 유료 계정도 쓸 수 있겠죠. 이렇게, GitHub으로 충분할텐데도 불구하고, 그 비슷한 커뮤니티가 국내에도 있었으면 좋겠다라는 생각을 했습니다. 제가 모르는 것일테지만, 국내에 이렇게 ‘소스코드’로 커뮤니티역할을 잘 하는 곳이 없지않나 생각이 들구요, GitHub의 모델이라면 ‘국내 개발자 커뮤니티’의 역할을 어느정도 할 수 있지 않을까 생각합니다.

두가지 문제 앞에서 고민중입니다.

1. 국내에서 git을 사용하는 개발자의 수가, 하나의 커뮤니티가 될 수준만큼 충분이 있을 것인가?
2. GitHub을 따라서 만든 국내만의 사이트가 어떤 차별화 요소가 있는가?

직감적으로는, ‘국내에 한국어로 서비스가 있으면 좋겠다’라는 믿음으로 틈틈히 고민중인 상황입니다.

어떻게 생각하세요? ‘국내의 Git 소셜코드 커뮤니티’, 의미 있을까요?

전체글목록