카카오, 겁나 빠른 황소 프로젝트

오늘은 카카오의 지금을 만들어낸 프로젝트, '겁나 빠른 황소' 프로젝트에 대해 알아보려 합니다.

 

카카오톡은, '10년 3월 처음 출시했고, 그 당시 등장과 함께 엄청난 인기를 끌면서 굉장힌 트래픽이 유발되었다 합니다. 그래도 나름, 그 당시에도 서버를 꽤 증설해왔기에 문제는 없다 생각했지만. 경기장 근처나 번화가와 같이 다수의 사람이 밀집한 구역에서는 메시지 전송/수신이 쉽지 않았다고 합니다.

 

'12년 1월 기준으로 확인해 보면, '1분에 69만 건'의 카카오톡 메시지가 발생했고, 하루 총 10억 건에 이르는 메시지가 전송되었다고 하니. 정말 밀집한 구역에서는 메시지 주고 받는게 굉장히 힘들었을 것이라 생각되기도 하네요. 또 그 당시에는, 3G 시대였으니까요!

 

좌 : 카카오톡 하루 메시지 전송 건수, 출처 : 카카오 / 우 : 카카오톡 공지사항, 출처 : 카카오

 

그래서, 카카오는 '11년도에 '겁나 빠른 황소'라는 이름의 프로젝트를 진행하며, 지연 없이 메시지를 전송하기 위한 카카오만의 새로운 프로토콜을 개발해냈습니다. 

 

겁나 빠른 황소 프로젝트로 개발된 프로토콜은, LOCO 프로토콜이라 하며, 해당 프로토콜은, 기존의 메시지 전송 방식인 HTTPS POST 방식의 전송 방식에서 벗어나 더 빠른 속도로 주고받을 수 있는 프로토콜입니다. 어찌됐건, TCP/IP 바탕으로 작동하는 새로운 HTTP Request/Response 프로토콜이라 생각해도 좋을 것 같네요.

 

해당 프로토콜은, 패킷 사이즈 경량화, 푸시 시스템 구조 최적화, 백엔드 시스템 성능 개선 등 크게 세 가지를 이루어냈고, 패킷 사이즈를 최적화한 메시지를 여러 경로로 나누어 처리하고, 일 6억 건('11년 기준)에 달하는 메시지를 지연 없이 전송할 수 있게 했습니다.

 

잠깐, 패킷 사이즈 경량화? 왜 필요했을까요. 일단 기본적으로, TCP를 사용해 패킷을 보낼 때에는 기본적으로 필요한 구성들이 있습니다. 예를 들어, Checksum과 같이 데이터 송신 중 발생할 수 있는 오류를 검출할 수 있는 데이터나 뭐, 아래와 같이 여러 세그먼트들이 있죠. 기본적으로 포함되어 있죠.

TCP Header 구조

기본적으로 TCP 세그먼트는 40 Byte 상당의 플래그와 헤더를 포함해 전송한다 합니다. 만약, 단어 하나, 예를 들어 1 Byte의 메시지가 전송될 때 위와 같은 기본 세그먼트들이 포함되어 전송된다면 상당히 비효율적일 것입니다.

 

그래서 과거에도 이러한 이슈 때문에 'Nagel 알고리즘'을 활용하기도 했습니다. Nagel 알고리즘은 세그먼트가 최대 크기(LAN 1,500 Byte / WAN 수백 Byte)가 되지 않으면 전송을 하지 않고, 전송하기 충분할 만큼의 세그먼트가 쌓였을 때는 버퍼에 저장되어 있던 데이터를 전송시키는 것으로. 위와 같은 상황에서 쓰였습니다. 그러나, 크기가 작은 HTTP 메시지는 지연된다는 문제점이 있었습니다. 카카오톡에서 내 메시지가 다른 메시지와 함께 전송되도록 마냥 기다릴 수는 없는 노릇이기에 사용하기 부적합하긴 하죠.

 

무튼, 이러한 이유 말고도 더 많은 이유들이 존재하겠지만! 어찌됐건, 카카오는 LOCO 프로토콜을 만들어냅니다. 실제로 굉장히 빨라졌다고 하죠. 그 당시에는 뭐 20배? 정도 빨라졌다고 합니다.

 

자, 지금까지 겁나 빠른 황소 프로젝트에 대해 알아봤습니다. 그런데, 최근에 node-kakao라는 오픈소스(?)가 많은 사람들의 관심을 끌고 있더군요.

 

node-kakao는 LOCO 프로토콜을 통해 패킷이 이동될 때 패킷을 분석하여 카카오톡에 존재하지 않는 기능들을 만들어낼 수가 있었습니다. 몇 달 전에는 '카톡서 나는 원숭이다 뜨면 해킹? 카카오는 사실 아냐'라는 기사가 떴었는데, 이런 것이 바로 사용자가 LOCO 프로토콜을 리버싱해 만들어낸 기능이었습니다.

 

카톡서 '나는 원숭이다' 뜨면 해킹?... 카카오는 사실 아냐, 출처 : 한국경제/온라인 커뮤니티 캡쳐

 

뭐, 카카오 유저들이 해당 프로토콜을 이용해 이러한 문제들이 발생하긴 했지만, 카카오도 어쩔 수 없는 것 같습니다. 꾸준히 해당 문제가 카카오 데브톡에 제보가 되긴 하는데, 아직도 별 말이 없는 것을 보니, 뭐. 다른 것을 하기도 바쁜데. 그렇게 보안상 취약하다 판단되지도 않으니 가만 두는 것 같다 생각이 듭니다.

 

개발관련 커뮤니티에  node-kakao를 사용해 어떠한 기능을 만들어내는 것이 종종 보이는데, 카카오톡 오픈채팅방에서의 움직이는 방제(?), 오픈채팅에서 누가 메시지를 읽었는지 판별하는 기능 등 여러 사례들이 보이더군요. node-kakao 라이브러리 사용은 제 생각엔 카카오 정책 위반은 맞는데, 뭐 MIT 라이센스에 따라 저자 또는 저작권자는 SW에 관해 아무런 책임도 지지 않으며, 사용하면서 발생한 모든 문제점은 사용자에게 책임이 있다고 하니. 사용할 때 조심할 것을 권장한다. 단순히 재밌어보여서, 다른 사람들도 하니까!는 식으로 접근하지 말길.....

 

아, 그리고 해당 라이브러리를 사용해서 카카오톡의 공식 챗봇빌더인 카카오 오픈빌더 i에서 등록절차 등을 거치지 않더라도 챗봇을 만들 수 있다. 과거에 공식적으로 제공하는 오픈빌더가 없었을 때에는. 자신의 계정을 챗봇화하는 등으로 사용했다고 하니. 참 신기했다. 리버싱의 세계란... 정말이지. 대단하구나 싶다. 구글링하다 발견한 것인데, 카카오를 리버싱해 이런 식으로도 가상의 여자친구가 응답해주는 챗봇을 만드는데 활용할 수 있었다(카카오톡으로 여친 만들기)

카카오톡으로 여친 만들기 2013.06.29

 

앞으로 카카오가 이러한 이슈에 대해 어떻게 대처할지는 모르겠지만. 최근 커뮤니티 중심으로나 점점 많이들 사용하는 것 같다. 언젠가는 이러한 이슈에 대해 꼭 대응을 해야하지 않을까? 하는 생각도 든다.

---

의견 1 : 카카오톡 과거 to 현재 스프린트 식 개발

 

나름 짧게 정리하자면,

 

기존 방식은 패킷 기본구성이 무거웠고 개선된 방식은 기본 구성 용량을 꽉꽉 채워야 했는데, 이 도한 메시지에는 어울리지 않은 방식이었다. 그래서 나름 새로운 방식으로 개발했다. 개발된 프로토콜은 오픈소스가 아닌데, 유저들이 리버싱하여 패킷을 분석해 자기들 마음대로 활용하기 시작했다. 라는 것 같네요.

 

글을 쉽고 재밌게 써주어 즐겁게 읽었습니다. 이 겁나 빠른 황소 프로젝트가 사실상 카톡이 지금까지 살아남게 해 준 첫 동아줄이라 생각합니다. 마이피플이라는 어플도 있었고 무료 시장에 많은 기업들이 있었죠. 계속된 위기가 있었지만 이겨낸 비결과 그리고 지금의 위치는 스프린트식 개발 덕이 크다 생각합니다.

 

카카오톡은 4 2 개발을 과거에 적용했다고 합니다. 4명의 개발 인원이 2 달간 진행하여 성과 확인 방식인데 우리가 생각하는 길과도 엇비슷하다 느껴지네요. 하여튼. 카카오 김범수 의장은 애초에 깨어있던 사람이 아니었나 싶습니다.

 

첫 카카오톡부터 다 써보신 분 계세요?(brunch.co.kr/@andkakao/107)

첫 카카오톡부터 다 써보신 분 계세요?

[조직문화] 4-2 법칙, 카카오톡을 성공으로 이끌다(blog.mailplug.com/334)

[조직문화] 4-2 법칙, 카카오톡을 성공으로 이끌다