https://youtu.be/_2ZRGUegLjo?si=Jl8a8BlxIB0rMDRm
Netty는 Java 프로그래밍 언어 상에서 동작하는 네트워크 애플리케이션 프레임워크다. 발표자는 이를 다음과 같이 설명한다:
"프레임워크라고 쉽게 개발할 수 있게 해주는 뼈대 역할을 하는 라이브러리 같은 것이죠. 애플리케이션을 개발하는 것을 쉽고 빠르게 할 수 있게 해 주는 프레임워크인데 쉽고 빠르게만 되는게 아니라 이 프레임워크가 제공하는 틀을 따라서 개발을 하게 되면 유지보수가 쉬운 형태, 그러면서도 성능은 좋은 네트워크 애플리케이션을 개발할 수 있게 된다는 것이죠."
비동기/이벤트 기반 패러다임을 채용해서 성능상 이점을 최대한 가져가고, 서버가 이벤트에 반응하는 방식으로 개발할 때 편리하다는 장점이 있다.
프로젝트 성장 지표 (2014년 → 2015년)
- GitHub Stars: 3,200개 → 5,000개
- Forks: 1,500개 → 2,500개
- Contributors: 122명 → 166명
"프로젝트가 순조로이 잘 진행되고 있고요. 이게 재밌는 것이 이걸 진행하는 사람들이 전부 같은 회사 소속의 사람들이 아니라 전부 지리적으로 떨어져 있는 사람들이 개발을 함께 진행을 하고 있다는 것이 좀 흥미로울 수 있죠."
실제 사용처
- 웹 서비스: Twitter 등
- 인스턴트 메시징: LINE, 카카오
- 멀티플레이어 게임: 마인크래프트
- NoSQL 데이터베이스: Cassandra, OpenTSDB
- 고빈도거래(HFT)
- 미디어 스트리밍: Red5 (Flash 미디어 스트리밍 서버)
"거의 모든 소켓, 자바 버추얼 머신과 소켓을 쓰는 분야에서는 다 쓰이고 있고 또 쓸 수 있다는 것을 알 수가 있습니다."
배경: SMS 연동 서비스 아르바이트
대학교 2~3학년 때 이동통신사와 연동해서 SMS를 전송하는 서비스를 개발하게 됐다. 당시 5개 이동통신사가 모두 다른 프로토콜을 사용하고 있었다.
"이게 좀 이해가 안 가는 것은 SMS 전송을 위한 표준 프로토콜이 있었음에도 불구하고 다 독자적인 프로토콜을 쓰고 있었다는 건데요. 어쨌든 뭐 현실이 그러하니까 다 구현을 해야 했는데..."
프로토콜 문서를 분석해보니, 메시지 자체의 형식(전문 형식)은 다르지만 메시지의 종류와 흐름은 전부 공통이었다. 같은 요구사항(SMS 전송)을 위해 만들어진 프로토콜이니 당연한 것이었다.
아이디어: 관심사의 분리
"내가 다섯 군데 프로토콜을 전부 다 따로 구현하는게 아니라 전문 형식을 코딩하고 디코딩하는 부분, 그리고 그 전문을 어떤 추상화된 객체로 만든 다음에 그걸 처리하는 비즈니스 로직 처리 부분, 이렇게 두 가지로 분리하는 식을 하게 되면..."
- 기존 방식: 전문 해석 5개 + 비즈니스 로직 5개 = 10개
- 새로운 방식: 전문 해석 5개 + 비즈니스 로직 1개 = 6개
이벤트 기반 설계의 필요성
SMS 시스템은 메시지를 주고받는 구조다. 메시지를 보내면 응답이 오고, 발송 결과 알림이 오면 그걸 받았다는 알림을 주고, 데이터베이스에 결과를 저장하는 식이다.
"GUI 개발할 때 이벤트 기반으로 많이 개발을 하잖아요. 버튼이 눌리면 버튼이 눌렸을 때 그거에 대한 이벤트 핸들러가 호출이 되듯이, 메시지가 왔을 때 메시지에 대한 이벤트 핸들러가 호출이 돼서 나는 그거에 대한, 받은 메시지에 대해서 집중해서 그 메시지 처리하는 로직에만 집중할 수 있게 되면 개발이 편리하겠다, 이런 생각을 하게 된 것이죠."
솔직한 고백
"사실 이런 생각을 했다고 하더라도 프레임워크를 다 만들고 그 위에 올리고 이렇게 하는 것은 사실 좀 힘이 드는 일이기도 하죠. 그래서 어떻게 보면은 하라는 일은 안 하고, 짜라는 코드는 안 짜고 라이브러리를 먼저 짠 다음에 짠 꼴이 되긴 했는데..."
결과적으로 공부가 됐고, 다른 사람들도 이런 기능을 필요로 했기 때문에 좋은 일이 됐다.
오픈소스에 대한 관심
당시 한국어로 번역된 "오픈 소스"라는 책을 읽었다. 성당과 시장 모델, Cygwin이나 Red Hat 사람들의 인터뷰 등이 실린 책이었다.
"그런 걸 보면서 오픈 소스가 정말 가능성이 있고 또 많은 사람들이 협업을 통해서 재밌게 할 수 있겠다라는 생각이 들었던 거죠."
공개 동기들
"기본적으로 내가 프로그램을 짜면 나만 갖고 있는 거보다는 남들이 같이 즐거워해 주고 같이 이야기하고 하면 더 발전할 수 있기 때문에, 그리고 또 오픈 소스를 하면 또 세계가 다 쓰는 소프트웨어가 될 수도 있고, 그다음에 리누스 토발즈가 말했듯이 뭐 그냥 재미있기도 하고요. 아니면 뭐 관심을 좀 받고 싶다 이런 생각도 있었을 거 같아요."
"이게 너무 오래전 일이라 이게 이런 이유로 딱 이렇게 했다라고 말씀드리기엔 좀 힘든 면이 있는 거 같아요. 하지만 대체적으로 이런 여러 가지 감정들, 그리고 또 그때는 대학생이고 또 젊었고 뭐 약간 시간도 많았고 그래서 시작할 수 있게 되지 않았나 이렇게 추측하고 있습니다."
사용자가 생기다
"프로젝트지만 사용자가 나만 있는게 아니라 다른 사람도 있다는 것이죠. 그래서 이게 내 프로젝트가 나만 이게 필요하다고 생각한게 아니었구나, 다른 사람들도 이 프로젝트를 필요로 하는게 맞구나, 즉 내가 생각한게 맞구나라는 거에 대한 확인이 될 수도 있고..."
프로젝트의 "신"이 되다
"회사에서 보통 프로젝트를 하면은 내가 리드가 되는 경우보다는 그렇지 않은 경우가 더 많죠. 근데 여기서는 내가 프로젝트를 시작했으니까 내가 프로젝트의 주인인 거죠. 그래서 내가 CTO면서 내가 고객응대도 하는, 즉 프로젝트의 창시자, 프로젝트의 신인 거죠. 그래서 뭐든지 다 할 수 있는, 어떻게 보면은 힘을 얻었다고 할 수 있는, 그렇기 때문에 더 재미있는 상태인 것입니다."
빠른 대응의 쾌감
회사 프로젝트에서는 릴리즈 스케줄, 하위 호환성, 로드맵 등에 따라 버그가 언제 고쳐질지 결정된다. 빨리 고치고 싶은 버그도 늦게 나가기도 한다.
"여기서는 내가 신이기 때문에 버그가 있으면 오늘 고쳐서 릴리즈 해 주고, 그러면 또 사람들이 '이 프로젝트 정말 끝내 주네요' 뭐 이렇게 칭찬도 받고, 그러면서 상당히 재미있는 여러 선순환이 일어나게 되어서 프로젝트가 성장을 해 나가게 됩니다."
임피던스 미스매치 발생
"프로젝트가 커지면 이게 더 이상 혼자만의 것이 아니게 되기도 하고..."
"처음에는 내가 혼자서 시작한 프로젝트이기 때문에 규모가 어느 정도 관리 가능한 수준이 되는데, 이게 어느 정도 인기를 끌게 되면은 버그 리포트라든지 뭐 질문 이런 것들은 점점 많이 들어오기 시작하는데 실제 프로젝트에 기여를 하게 되는, 예를 들어 풀 리퀘스트를 보내는 사람의 수는 현저하게 떨어지는 거죠."
"프로젝트가 아직 규모상 아주 큰 단계는 아니기 때문에 실제 컨트리뷰션, 코드상의 컨트리뷰션 하는 사용자는 많지가 않은데 사용자는 많아지는, 그런 어떤 임피던스 미스매치가 발생을 하게 됩니다."
일이 눈덩이처럼 불어남
"어떻게 보면 일을 많이 했더니 일이 더 많이 생기고, 일을 조금 하면 일이 더 조금 생기진 않고 조금보다는 좀 더 많이 생기고, 그래서 어쨌든 일을 하면 할수록 일이 더 생기는, 눈덩이처럼 불어나게 되는데요..."
기술 부채의 발생
"이렇게 바쁘다 보면은 또 컨트리뷰터 별로 없고 하면은 조금 코드의 완성도가 좀 떨어지는 코드를 넣기도 하게 되는데요. 뭐 예를 들어서 현업의 일이 바쁘기 때문에 이걸 좀 대충 하게 할 수도 있겠고 뭐 여러 가지 이유가 있겠죠."
"그래서 이런 경우에 이제 똥을 싼다고 하죠. 내가 싼 똥에 내가 빠진다고. 나중에 이제 그게 다시 돌아와서 그 문제 때문에 나중에 더 큰 문제가 생겨서 더 코드를 많이 짜야 되는 뭐 이런 경우도 생기고요."
"또라이 질량 보존의 법칙"
"기본적으로는 발런티어 기반해서 내가 혼자 내가 남는 시간에 별히 돈을 받지 않고 하는 일이지만 어쨌든간에 커뮤니티라는게 되고 하다 보면은 꼭 좀 이상한 사람들이 가끔씩 오게 됩니다."
"보통 이제 그런 사람들을 프로젝트의 관리자, 프로젝트의 신으로서 관리를 해야 되는데 이게 코드를 다루는 일이 아니라 사람을 다뤄야 하는 일이다 보니까 또 좀 피곤하지 않을 수 없는 것이죠."
회사 일처럼 변해버림
"이런 일들이 내가 원래 이런 일을 원해서, 그러니까 재미를 즐기기 위해서 시작을 했다고 할 수도 있는데 이거 하다 보니까 회사처럼 일이 많아지고 힘들어지기 시작하는 거죠."
관점의 전환
"이거를 좀 어떻게 해결할 필요가 있겠죠. 그래서 생각을 해보면 이게 위기이기도 한데 기회이기도 하더라는 거죠."
"만약에 이 프로젝트를 시작 안 했다면 이런 일도 없었겠지. 그렇기 때문에 시작을 해서 더 가치가 있다고 해야 할까. 회사에서 단순히 팀원으로서만 일했다면 이런 일을 겪지 않았을 수도 있겠지만, 겪을 수 있었으니까 뭔가 좀 내가 발전할 수 있는 기회. 예를 들어서 내가 지금은 사원이지만 팀장님으로 이런 일을 나중에 겪게 됐을 때는 이런 경험이 도움이 되겠지..."
"회사에서만 겪을 수 있는 문제가 아니라 오픈 소스에서도 좀 더 앞서서 경험을 하고 그걸 통해서 발전해 나가는 그런 것이죠."
한 발짝 물러서기
"이런 위기가 발생했을 때 너무 힘들어만 하지 말고, 어차피 또 회사 일과는 또 다른게 남는 시간에 하는 거고 하다 보니까 또 내 프로젝트고, 그렇기 때문에 당장 이거를 막 죽자살자 해결할 필요는 없는 거죠. 그래서 한 발짝 물러서서 문제를 바라볼 필요가 있다는 것이죠."
"그래서 이쯤 되면 거의 인생 수업이 된다 그런 겁니다."
"하다 보면은 일이 많다고 해서 막 오버타임 하면서 막 다 하게 되는데 사실 그중에 정말 우선 순위가 극도로 높은 일은 많지 않거든요."
"그런 것들의 경우에는 그냥 가만히 내버려 두거나, 그 이슈를 리포트 한 사람한테 '한번 당신이 이 일을 책임지고 나서서 한번 작업해 보는 건 어때요? 아마 이 문제에 대해서 잘 이해하고 있으니까 잘할 수 있을 것 같아요' 이런 식으로 얘기를 한다던가..."
"그렇게 해서 컨트리뷰션 계속 잘하는 사람이 있으면 그 사람을 아예 팀에 들여서 그 사람이랑 같이 문제를 해결한다든지 해서 나 혼자 하던 것을 다 함께함으로써 좀 더 부하를, 나 자신에게 들어오는 부하를 낮출 수 있다는 거죠."
"이런 전략을 사용하게 되면은 협업하는 재미도 느끼게 되고 또 당장 급하지 않은 이슈는 약간 좀 우선 순위를 낮출 수 있는 그런 효과가 있어서 좀 더 스트레스를 덜 받게 되죠."
"모든 소프트웨어 개발에서 가장 중요한 원칙 중에 하나가 DRY라고 해서 Don't Repeat Yourself예요. 그래서 굳이 반복적으로 일어나는 일들은 내가 하지 않고 기계가 할 수 있도록 하는게 좋습니다."
실제 사용 도구들
-
Sonar (정적 분석 도구)
"풀 리퀘스트가 오면은 풀 리퀘스트의 변경 사항 부분에 대해서 이 소나라고 하는 도구가 정적 분석을 수행해서 어떤 이슈가 있는지 알려 주는 것이죠. 그래서 이 발생한 이슈들이 전부 수정되기 전까지는 내가 직접 보지 않아도 되고..."
"기존에는 내가 코드를 일일이 처음부터 다 보고, 뭐 예를 들어서 라인의 끝에 빈 문자열이 있다든지 이런 아주 사소한 스타일 에러, 이런 거는 내가 안 봐도 되는 상황이 되는 거죠. 스타일 에러가 있으면 빌드가 실패해 버린다든지 하는 식으로 해서요."
-
Spark 프로젝트 스타일의 자동화
- 모든 테스트 패스 여부 확인
- 머지 가능 여부 확인
- 퍼블릭 클래스 추가 내역 자동 보고
- 퍼블릭 API 변경사항 자동 보고
-
Rust의 bors 봇
"러스트 프로젝트에서는 bors라고 해서 봇이 있는데 그 봇을 이용해서 봇이 테스트도 올려주고 그다음에 bors한테 명령을 하면은 자동으로 머지도 해주고 이런 것까지 자동화를 할 수 있는 것이죠."
"이런 위임할 수 있는 일들을 전부 다 위임을 하게 되면 좀 더 내가 생각할 수 있는 여유도 있게 되고, 좀 더 프로젝트가 덜 안 재미있어진다, 그러니까 지루한 부분이 줄어든다고 할 수 있겠습니다."
서두르면 안 되는 이유
"어떤 끝내주는 기능이 등장을 했어요. 그래서 이 기능이 우리 무슨무슨 회사에서 꼭 필요하다, 예를 들어서 제일 유명한 뭐 트위터, 페이스북, 애플에서 이 기능이 꼭 필요하니까 요번 릴리즈에 꼭 넣어 주면 안 될까 뭐 이런 일이 있을 수 있겠죠."
"근데 이렇게 서둘러 내놓다 보면은 이런 오픈 소스 프로젝트는 나 말고도 다른 사람들이 다 쓰기 때문에 하위 호환성이라든지 API 호환성 같은게 이제 중요하게 됩니다."
"퍼블릭 API 이렇게 시간이 없어서 적당히 대충 만들었는데 그걸 사람들이 다 쓰고 있으면 나중에 그걸 고치기가 힘들어지는 거죠. 아니면 Deprecated 추가하고, Deprecated 된 API 삭제하고, 삭제된 API 누가 아직까지 오래된 버전을 쓰다가 업그레이드 했더니 에러가 났다고 또 리포트를 하고, 그럼 잘못했다고 또 알려주고, 근데 그 사람이 초보자면 또 뭐... 그러면 이게 내가 다시 프로젝트가 재미가 없어지는 거죠."
회사와의 차이점
"회사에서는 일할 때는 어떤 시간적 제약이 훨씬 강하기 때문에 '여기에서 끊고 다음번에 개발한다' 뭐 이런게 있을 수 있죠. 또 회사라는 어떤 정해진 조직 안에 있기 때문에 하위 호환성을 좀 깨뜨리면서 작업을 하더라도 문제가 안 되는데, 오픈 소스는 그런 부분이 다르더군요."
아이디어 숙성의 가치
"시간을 들여서 제대로 한다, 제대로 리뷰하고 잘하면은 시간이 들지만 아이디어가 숙성된다 하는 측면에서 좀 더 좋은 부분도 있습니다."
"사용자가 아직 이 기능을 제대로 써 보지도 못했는데 릴리즈를, 그러니까 베타에서 뭐 파이널 릴리즈로 넘어가는 데까지 시간이 너무 짧다 그러면 사용자 피드백을 충분히 받지 못하기 때문에 파이널이 나온 다음에야 사용자들이 '이런 문제가 있었어요' 하면은 이제 되돌리기가 힘든 아까와 같은 상황이 나오는 거죠."
"충분히 사용자 피드백을 받을 수 있는 시간 그런 것들을 여유 있게 잡아서 하면은 좀 더 덜 재미없는 일이 덜 생기지 않을까 이렇게 생각합니다."
예상치 못한 해결책이 나타나기도 함
"단순히 그냥 잠깐 두고 지내다 보면 그게 다른 방향에서 아예 새로운, 즉 문제를 아예 없애 버리는 해결책이 나온다든지 그런 좋은 일이 있을 수도 있겠죠."
실용적인 대안
"당장 내놓아서 빨리 피드백을 받는게 더 좋은 경우도 있거든요. 그런 경우에는 이제 뭐 API 자체에서 이 패키지는 experimental 하기 때문에 나중에 바뀔 수 있다라고 알려 준다든지, 아니면 뭐 베타라든지 알파 같은 페이즈를 충분히 둔다든지 하는 식으로 해결하는 쪽으로 진행을 하면 제 경우에는 도움이 되더라고요."
과잉 반응 자제
"살다 보면 모든게 부정적으로 보일 때도 있고, 뭐 일이 피곤하고 하다 보면은 짜증도 나고 하는게 다 당연한 일인데요. 그래서 항상 내가 과잉 반응하는 것은 아닌지 좀 생각해 볼 필요가 있습니다."
프로젝트 비판 ≠ 개인 공격
"그 사람이 프로젝트 욕을 막 해요. 근데 이게 나한테 욕하는 것처럼 들릴 수도 있는데, 사실은 프로젝트에 대한 욕인 거죠. 그러면은 굳이 내가 기분 나쁘다기보다 이 프로젝트 문제를 해결하면 결국 되는 거죠."
"그 사람한테 '너한테 이 프로젝트에 대해서 문제가 있다는 건 알겠는데 우리가 그 문제가 뭔지 사실 잘 이해를 못 하겠다, 좀 알려주면 안 되니' 이런 식으로 이제 한번 끊고 들어가게 되면, 그쪽에서도 약간 좀 그 또라이 질량이 감소되는 그런 상황이 발생을 하게 됩니다."
숨겨진 가치 발견
"보통 그래서 그 사람이 좀 잘 표현을 못해서 그런 걸수 있고 뭐 좀 표현 방식이 투박해서 그럴 수도 있기 때문에 그런 식으로 해서 천천히 이끌어 나가게 되다 보면 의외로 이제 좋은 피드백이 나올 수가 있거든요."
"내가 생각하지 못했던 프로젝트 사용성 상의 어떤 측면에서의 문제점... 이런 사람들은 보통 이제 프로젝트를 오랫동안 사용하지 못하고 사용한지 얼마 안 됐는데 초보자인 거죠. 그래서 프로젝트를 처음 사용하는 입장에서 뭔가 문제가 발생한 거죠."
"이런게 이제 중요한게 사용성 상의, 어떤 내 프로젝트의 사용성 상의 측면에서 문제가 있을 수 있다는 신호일 수 있거든요. 그래서 요것도 위기를 기회로 삼아서 이렇게 잘 구워 삶으면 프로젝트가 성공할 수 있는, 더 앞으로 나아갈 수 있는 밑거름이 될 수 있다는 것이죠."
감정 노동으로 받아들이기
"너무 이제 부정적으로 반응하기보다는 그냥 나는... 뭐 약간 감정 노동 비슷하다고 할 수도 있겠는데, 일단 잘 이야기를 들어 준다라고 생각하시면 될 거 같습니다."
진짜 문제 있는 사람은 무시
"근데 이제 이도저도 아니고 그냥 좀 이상한 애들도 있어요. 그런 애들은 그냥 답장을 안 하는게 좋습니다. 괜히 했다가 이제 옆에 그림에 계신 분처럼 이제 날밤을 까게 되는데요. 굳이 이렇게 해서 서로 인생 낭비하지 않는게 좋다고 보겠습니다."
(발표자는 유명한 인터넷 밈 - 누군가가 "인터넷에 누가 틀린 말을 했어!"라며 밤새 싸우는 만화 - 을 인용함)
끝나지 않는 이슈
"가장 기본적인 문제의 근본적인 원인은 해결해야 될 이슈가 내가 평생 동안 해도 다 해결을 못 한다는 것이죠. 그러니까 일을 하면 일을 할수록 이슈가 더 생기기 때문에 프로젝트가 성장하고 하다 보면 일이 더 생기기 때문에..."
"팀이 이슈를 해결하는 속도와 그 팀원들의 기대수명을 곱해 봐도 해결할 수 있는 이슈의 수보다 훨씬 작다는 것을 직감적으로 느끼게 됩니다. 그래서 항상 일은 있다라고 생각을 그냥 받아들이고..."
일-삶-오픈소스의 삼중 균형
"기존에는 일과 삶 사이의 어떤 균형에 대해서 많이들 다루고 있는데 이번에는 또 하나가 더 생겼어요. 그래서 일과 삶과 오픈 소스 프로젝트 사이의 균형, 아니면 그냥 다 같이 사는 공생관계 이런 것들에 대해서 어떻게 할 것인가 이런 고민들이 이제 지속적으로 생기게 되겠죠."
경쟁자와 파괴적 혁신자의 등장
"우리가 치킨집 내놓으면 옆에 치킨집도 생기듯이, 경쟁자나 아니면은 우리 집은 그냥 치킨만 했는데 다른 집은 세상에 순살 치킨이랑 양념 치킨까지 해요, 그러면 이거는 비즈니스를 파괴할 수 있는 어떤 디스럽터가 될 수 있는 거죠."
분산 팀 커뮤니케이션
"멤버들이 늘어나게 되면서 어떤 멤버는 한국에서 살지만 어떤 멤버는 일본에 있고 어떤 멤버는 독일에 있고 어떤 멤버는 미국에 있다 이러면은 이제 완전히 분산된 팀이기 때문에 그런 팀 멤버들과 커뮤니케이션을 어떻게 하느냐..."
"우리는 보통은 이제 얼굴과 얼굴 마주하고 하는 커뮤니케이션에 익숙해져 있다는 거죠. 그래서 텍스트만으로 어떤 뉘앙스를 전달하고 그런 것들을 또 영어로 해야 되고 하는게 어떤 하나의 벽이 될 수가 있는데..."
"이런 것들도 하다 보면 또 늘게 되기도 하고 또 발전하는 계기가 되게 되기도 합니다. 또 다행인 것은 모든 사람이 다 영어를 잘하지 않는 것은 사실이기 때문에... 일본 사람들은 특히 뭐 더하고, 그렇기 때문에 서로서로 그런 걸 이해 가면서 하다 보면 또 재미도 있고 장점도 있고 단점도 있는 거 같아요."
기타 문제들
- 하위 호환성 문제
- 구버전에서 신버전으로의 마이그레이션 가이드
- 버전 정책 (Major.Minor.Micro에서 Micro만 올라갔는데 호환성 깨지면 안 됨)
- 문서화
- 의도와 다른 사용법 대응 (A 용도로 만들었는데 B 용도로 쓰는 사용자들)
프로젝트 노예?
"이런 문제들이 뭐 하다 보면 이제 '내가 프로젝트 노예가 된게 아니냐, 이 노예 12년이 노예 1년 더해서 13년 된 거 같다' 이런 생각이 들 때도 있어요. 하지만 뭐 좋은게 좋은 거죠."
기분에 따라 다른 대답
힘들 때:
"아 난 잘 모르겠다, 이거 하던 거니까 계속한다 이렇게 생각할 수 있겠죠. 그리고 막 때려치고 싶다, 이제 이제는 딴 거 하고 싶다 하는 생각이 들 때도 있어요."
기분 좋을 때:
"아 이걸 하면서 더 높은 목표를 향해 내가 나아간다는 어떤 느낌을 받기도 하고, 그다음에 잘 모르는, 그러니까 직접 만난 적도 없는 동료들과 함께 기술적으로도 성장하고 인간적으로도 성장할 수 있다는 점에서 뭐 내 커리어 면에서 좋고..."
실제 커리어 이점
"제가 이 프로젝트를 하면서 이것을 계기로 해서 이제 뭐 전에 다니던 직장인 NHN이라든지 트위터라든지 아니면은 뭐 지금 있는 라인이라던지 이런 곳에 다 들어갈 수 있게 된 거잖아요."
기분 아주 좋을 때:
"아 이걸 함으로써 이제 세상이 더 나은 곳이 되어가고 있구나 하는 뭐 약간 뭔가 내 옆에 천사가 앉은 그런 느낌이 들 수도 있는 것이죠."
결론
"이런 다양한 기분이 뭐 왔다 갔다 하는 것은 뭐 사실이라고 할 수 있겠습니다. 그래도 하면은 힘들 때 빼고는 다 좋다고 생각하면 마음이 편합니다."
그냥 시작하라
"많은 분들이 이제 저한테 가끔씩 메일도 보내 주시고 하는데 '이거 어떻게 시작하면 좋겠느냐' 그냥 하면 되는데 왜 사람들이 물어보는지 저는 사실 잘 모르겠어요."
"어떻게 하면 잘 되는지 알고 시작해서 다 하면은 동네 치킨집도 다 잘 됐겠죠."
"시작하기 전에 그렇게 걱정하고 하는 것보다는 일단 빨리 시작을 해서, 만약 새로운 프로젝트라면 선점 효과도 누리고, 그렇지 않더라도 새로운 시도를 여러 번 해 보면서 또 부딪히기도 하고 또 실패도 하고 또 성공도 해보고..."
페이스북 비유:
"예를 들어서 내가 스타트업을 할 건데 스타트업을 하기 전에 걱정을 한참 하다가 페이스북이 딱 떴는데 '아 저거 내가 하려고 했던 건데' 이거 의미가 없는 거잖아요. 그런 것처럼 일단 시작을 하는게 중요하다고 봅니다."
성공 보장은 없다
"물론 시작을 한다고 이렇게 프로젝트가 커져서 13년 동안 이것만 하게 되리라는 보장은 없고요. 뭐 하면 좋을 수도 있고 뭐 나쁠 수도 있고..."
가장 중요한 건 과정
"어쨌든간에 가장 중요한 건 과정이라는 것이죠. 그래서 결과적으로 프로젝트가 성공을 하는 것도 좋지만 과정적인 측면에서..."
과정에서 얻는 것들
-
회사에서는 겪을 수 없었던 경험
"회사에서는 겪을 수 없었던 어떤 일을 시간이 걸리더라도 제대로 수행하는 법"
-
설득과 커뮤니케이션
"내가 한 이 작업물을 다른 사람한테 보여주고 설득하고 이해할 수 있는 형태로 보여 주는 거. 예를 들어서 내가 이 프로젝트를 만든 다음에 뭐 웹사이트에 공유를 해야겠죠. 예를 들어서 레딧이라든지 해커 뉴스에 올려 가지고 많은 사람들의 뭐 동감을 얻어 낸다든지..."
-
미션 전달
"웹사이트는 그 프로젝트의 미션이 어떤 것인지를 이해시키고, 이런 것들을 직접 해보는 과정"
-
협업의 재미
"혼자서 작업하는 재미, 그리고 함께 일하는 재미 이런 것들을 함께 느껴보는 것"
-
다양성과 성장
"다양한 배경의 사람들로부터 새로운 아이디어라든지 아니면은 도전이라든지 이런 것들을 받아들이는 경험, 그리고 또 그걸 통해서 성장하는 과정"
최종 메시지
"상당히 해볼 만한 일이 아닌가, 저는 그렇게 결론을 내린 상태입니다. 아마도 여러분도 한번 해보시면 그렇지 않을까."
"물론 이제 프로젝트가 시작해서 팔이 날리고 그냥 망할 수도 있습니다. 하지만 그래도 한번 더 해 보면, 계속하다 보면 좋은 일이 있지 않을까. 또 그러면서 과정에서 또 성장하고..."