101번째 동료가 오는 게 무서웠던 우리들의 이야기: 키냅스(kynapse) 탄생 비화
안녕하세요!
세상의 모든 지식을 연결하겠다는 원대한 포부를 품었지만,
정작 우리 사내 지식 관리 시스템이 터져나가는 걸 보고 “이건 아니지!”를 외치며 등판한 kynapse 개발 팀장 손상우입니다.
이번 포스팅은 당시의 긴박했던 상황과 기술적인 고뇌, 그리고 팀원들 사이의 시시콜콜한 에피소드까지 디테일하게 작성했습니다.
마치 옆자리에 앉아있는 듯한 착각이 들 정도로 생생한 비하인드 스토리를 담았으니, 커피 한 잔 준비하시고 천천히 따라와 주세요.
공포의 숫자 ‘100’, 그리고 다가오는 101번째 손님
사건의 발단은 아주 단순한 숫자에서 시작되었습니다.
저희는 사내 위키로 아주 고전적인(자비 없는 10년전 버전..) 컨플루언스 온프레미스 모델을 사용하고 있었어요.
그런데 이 친구가 아주 도도합니다. 사용자 라이선스가 딱 100명으로 묶여 있었거든요.
회사가 성장하고 새로운 식구가 늘어날수록, 저희 개발팀의 심장은 쫄깃해졌습니다.
신규 입사자가 온다는 소식은 원래 축복이어야 하잖아요? 하지만 저희에겐 공포 영화의 예고편 같았습니다.
인사팀에서 “다음 주에 신입사원 한 분 오십니다!”라고 메신저를 보내면, 저희는 환영 인사를 건네기도 전에 라이선스 현황판부터 확인해야 했습니다.
“101번째 동료가 출근하는 날, 과연 누가 지식의 터전에서 계정을 뺏기고 쫓겨날 것인가?”
거의 IT판 ‘실미도’나 ‘오징어 게임’이었죠
누군가 퇴사해야만 계정이 하나 비는 이 비극적인 구조를 보며 저희는 생각했습니다.
지식 공유가 핵심인 회사에서 지식 접근권으로 서바이벌을 한다니, 이건 선을 넘어도 한참 넘은 일이었죠.
계정이 없어서 업무 문서를 못 보는 동료가 생긴다는 건, 전쟁터에 나가는 병사에게 총을 안 주는 것과 같으니까요.
결국 저희는 결단했습니다.
“이럴 거면 우리가 직접 만들자. 1,000명이 와도 끄떡없고, 우리 입맛에 딱 맞는 놈으로!”
무림의 고수들이 비급을 찾듯: 오픈소스 탐험기
3월의 어느 날, 개발자 5명이 모여 ‘키냅스 프로젝트’의 깃발을 올렸습니다.
맨바닥에서 모든 코드를 짜기엔 시간이 없었기에 전 세계의 훌륭한 오픈소스를 뒤지기 시작했죠.
마치 전설의 비급을 찾아 헤매는 무림 고수들처럼요.
첫 번째 후보, xwiki와의 험난한 만남
처음 레이더망에 걸린 건 xwiki였습니다.
저희 주력 스택인 Java 기반이라 “이건 운명이다! 우리가 제일 잘 아는 맛이야!”라며 환호했죠.
하지만 웬걸, 뚜껑을 열어보니 상황이 달랐습니다.
- 과유불급의 정석: 플러그인이 너무 많아 어디서부터 손대야 할지 감이 안 왔습니다. 마치 스위치가 1,000개 달린 비행기 조종석에 앉은 기분이었죠. “나는 그냥 이륙하고 싶은데, 왜 안테나 각도까지 조절해야 해?”라는 탄식이 절로 나왔습니다.
- 불친절한 가이드: ”이거 어떻게 고쳐요?”라고 커뮤니티에 물어도 돌아오는 건 싸늘한 침묵뿐이었습니다. 가이드 문서는 마치 고대 암호문 같았죠.
- UI/UX의 거대한 벽: 심플함과는 거리가 먼, 마치 90년대 관공서 시스템 같은 투박한 UI는 저희가 지향하는 ‘누구나 쓰고 싶은 도구’와 맞지 않았습니다.
두 번째 후보, 구세주 ‘Outline’의 등장
결국 저희는 과감히 이별을 고했습니다.
그리고 운명처럼 Outline을 만났죠. Node.js, Koa, React, postgresql… 요즘 트렌디한 맛집 스택은 다 모여 있더군요.
문서화는 깔끔했고, 무엇보다 첫 구동 시 느꼈던 그 “매끈함”이 저희를 사로잡았습니다.
“오, 이거라면 우리 팀원들이 좋아하겠는데?”라는 확신이 들었습니다.
‘체리픽’ 한 스푼에 ‘라이선스’ 확인 두 스푼
오픈소스를 가져다 쓰는 건 요리로 치면 밀키트를 사는 것과 같지만, 기업용 서비스를 만들 때는 ‘성분 표시(라이선스)’를 누구보다 꼼꼼히 봐야 합니다. 자칫하면 나중에 큰 법적 문제로 돌아올 수 있으니까요.
저희는 각 버전별 라이선스를 샅샅이 뒤졌고, 최신 버전이 몇 년 뒤 공개 라이선스로 전환된다는 로드맵까지 확인한 뒤 가장 안정적인 v0.60.3을 베이스캠프로 낙점했습니다.
그런데 문제가 하나 있었어요. 이 버전은 아직 Typescript가 적용되기 전이었거든요.
“자바스크립트로 그냥 편하게 갈까?”라는 유혹도 있었지만, 향후 유지보수와 에러 방지를 생각하면 타입스크립트는 포기할 수 없는 ‘보험’이었습니다.
저희는 v0.61.0에서 타입스크립트로 전환된 커밋을 일일이 추적해, 필요한 부분만 Cherry-pick으로 쏙 뽑아와 우리 버전에 이식했습니다.
노드 기반이라 설치와 실행은 또 얼마나 쉽던지! “기대했던 것보다 훨씬 더 잘되는데?”라며 감탄했던 기억이 나네요.
첫 실행 버튼을 누르고 화면이 뜨던 그 순간,
“이제 요리할 준비는 완벽하다.”
공룡(Notion) 말고, 우리는 ‘SMB의 친절한 이웃’
저희의 목표는 명확했습니다.
노션이나 컨플루언스 같은 글로벌 거대 공룡들과 힘자랑을 하려는 게 아닙니다.
그들은 너무 크고, 때로는 너무 무겁죠.
저희는 딱 필요한 것만 빠르고 안전하게 쓰고 싶은 SMB(중소·중견기업) 시장을 정조준했습니다.
“접속하자마자 설명서 없이 바로 문서를 만들 수 있어야 한다!”는 원칙하에,
오픈소스의 큰 틀은 유지하되 나머지는 싹 다 갈아엎기 시작했습니다.
- 디자인 리뉴얼: 아이콘부터 메뉴 배치까지, 우리만의 감각으로 새로 그렸습니다. 촌스러운 메뉴는 저희 자존심이 허락하지 않았거든요.
- 개인 컬렉션의 탄생: 원본에는 없던 ‘개인 전용 저장소’ 개념을 넣기 위해 데이터 구조 작업을 진행했습니다.
- 사이냅 에디터 이식: 이건 저희만의 ‘치트키’입니다. 블록 편집의 답답함 대신 MS 워드 수준의 강력한 편집 경험을 위해, 20년 문서 기술이 집약된 사내 솔루션 ‘사이냅 에디터’를 통째로 집어넣었습니다. 이제 브라우저에서도 워드처럼 쓱쓱 써 내려갈 수 있게 된 거죠.
- 로그인 & RBAC: 소셜 로그인만 되던 녀석에게 자체 회원가입 기능을 달아주고, RBAC, 그룹, 캘린더 기능 등 추가했습니다.
바이브 코딩과 AI 동료의 등장
이 모든 과정은 소위 말하는 ‘바이브 코딩’으로 진행됐습니다.
오픈소스의 복잡한 로직을 마치 음악을 듣듯 몸으로 받아들이며(?) 빠르게 이해도를 높여갔죠.
코드를 보면 작성자의 의도가 느껴지는 경지에 다다랐달까요? “아, 이 친구 여기서 좀 졸았나 본데?” 같은 느낌까지 올 정도로 소스 코드를 탐닉했습니다.
이번 프로젝트의 진정한 일등 공신을 꼽으라면 단연 AI입니다.
예전 같으면 구글링하며 스택오버플로우에서 밤을 지새웠을 에러들도, 이제는 옆자리의 AI 동료에게 툭 던지면 해결책이 나왔거든요.
“이 라이브러리랑 저 에디터랑 충돌나는데 어떻게 할까?”라고 물으면 AI는 빠르게 최선의 방안을 제안합니다.
AI 덕분에 코드 분석 속도가 비약적으로 상승했고, 이는 곧 개발 효율의 극대화로 이어졌습니다.
지금 돌이켜보면, AI가 없던 시절에는 도대체 어떻게 일했나 싶을 정도입니다.
구글링하던 시절이 마치 엊그제 같은데, 이제는 AI와 페어 프로그래밍을 하는 시대라니… 감회가 새롭네요.
사실 AI와 함께하는 코딩은 단순히 속도만 빠른 게 아니었습니다.
우리가 놓치기 쉬운 엣지 케이스를 짚어주고, 리팩토링 제안까지 해주니 개발의 질 자체가 달라졌죠.
“이건 5명이 하는 프로젝트가 아니라, 5명의 인간과 1명의 초지능이 함께하는 프로젝트다”라는 농담이 나올 정도였습니다.
에필로그
3월에 시작해 5월 초 본부 오픈이라는 촉박한 일정.
5명의 개발자는 그렇게 ‘지식의 터전’을 새로 짓기 시작했습니다.
단순히 계정 부족을 해결하는 수준을 넘어, 우리 회사의 모든 문서가 살아 움직이는 AI 지식 베이스가 되는 그날까지!
인프라를 구축하고, AI+RAG를 구성하고, 우리만의 독보적인 에디터를 심는 과정은 마치 거대한 퍼즐을 맞추는 것과 같았습니다.
과연 저희는 5월의 햇살 아래서 무사히 본부 오픈을 할 수 있을까요? 그리고 101번째 동료는 무사히 계정을 발급받았을까요?
기대해 주세요!
이런 서비스, 우리 회사에도 시급하다면?
👉 kynapse.ai 더 알아보기