구름은 한 달에 한 번 수요일에 기술, 개발, 성장, 조직 문화 등에 관한 이야기를 나누는 COMMIT 세미나를 진행하고 있습니다. COMMIT은 COMMUNICATION과 IT의 합성어로 개발자가 소스 코드를 커밋하듯 IT 업계를 이루는 분들의 경험과 역량을 함께 ‘커밋한다’는 의미를 담고 있어요.
2025년 11월 COMMIT의 주제는 ‘스타트업의 서비스 설계’입니다. 네이버와 카카오에서 대규모 시스템을 경험하고, 핀테크 스타트업의 제로 투 원(Zero to One, 세상에 없던 새로운 제품이나 서비스를 창조하여 ‘0에서 1’을 만드는 것) 과정을 거쳐 현재는 AI 가상화 플랫폼 ‘래블업(Lablup)’ 소프트웨어 엔지니어로 재직 중인 강대명 님이 발표합니다.
AI의 등장으로 더 빠르게 만들 수 있는 시대 속에서 서비스의 기반을 흔들리지 않게 유지하려면 개발자는 무엇에 주의하고 어떻게 해야 할까요? 구름스퀘어 강남에서 강대명 님과 이야기를 나눠 봤습니다.
written by Seori
edited by snow
 강대명 Lablup, Software Engineer 범죄 수사 솔루션부터 시작해, 지금은 인공지능 인프라 기술에 푹 빠져 있는 개발자입니다. 네이버 메일이나 카카오스토리처럼 수천만 명의 사용자를 담는 대규모 서비스를 만들면서 자연스럽게 하둡, 스파크, 카프카 같은 대용량 데이터 처리 기술의 전문가가 되었습니다. 소스 코드를 직접 들여다보고 내부 구조를 이해하는 일을 즐기며 오픈소스를 사랑합니다. 특히 레디스를 좋아하며 꾸준히 기여했습니다. 핀테크 서비스의 CTO로 일하며 새로운 경험을 쌓았고, 지금은 다시 AI 인프라 회사에서 한 명의 개발자로 기술 개발에 몰두하고 있습니다. |
Q. 래블업에서는 어떤 일을 하고 계신가요?
래블업은 AI 가상화 플랫폼을 만들고 있습니다. AI 가속부터 학습, 추론까지 아우르는 올인원 제품을 목표로 하고 있죠. 저는 선행 리서치 팀에서 플랫폼 기술을 조사하고, 기존 시스템과의 연결 방식을 검토하는 업무를 맡고 있어요. 새로운 기능 개발보다, 앞으로 필요한 기술을 미리 확인하고 검증하는 역할이죠.
Q. 일종의 R&D(선행 기술 연구 개발) 업무군요.
AI로 인한 변화에도 관심이 많을 듯합니다.
AI로 기회와 위기가 공존하는 지금의 상황을 어떻게 보고 계신가요?
개인적으로는 조금 낙관적으로 보고 있어요. 요즘은 AI 도입으로 1인 창업이나 소규모 창업도 충분히 가능해졌잖아요. 또, 저는 직접 창업을 한 건 아니지만 스타트업에 들어와 보니 해야 할 일이 정말 많더라고요. 그중에는 AI가 대체할 수 없는 일들도 분명 있었어요.
사람을 만나거나 전략을 세우는 일처럼, 결국은 사람이 판단하고 움직여야 하는 영역이죠. 사람이 이런 역할을 맡게 되면 개발에 집중할 시간은 줄어들겠지만, 오히려 AI를 서비스에 녹이고 연결하는 역할은 더 중요해지고 있다고 보고 있어요.
Q. 스타트업에서는 이러한 시기에 무엇을 가장 고민해야 할까요?
(서비스가 장기적으로 안정되게 운영되며 사용자에게 지속적인 가치를 제공하는 능력인) ‘서비스의 지속 가능성’에 대해 가장 많이 고민해야 한다고 생각해요. 요즘은 서비스를 출시하는 건 정말 쉬워졌지만, 유지·보수하고 계속 발전시키는 건 쉽지 않습니다. 스타트업이 자주 겪는 실수는 두 가지예요. 하나는 빠르게 내기 위해 ‘일단 기능이 동작하기만 하면 된다’고 생각하는 경우, 또 하나는 완벽을 기하다가 출시 시점을 놓치는 경우죠.
결국, 어떻게 판단하느냐가 중요합니다. 어떤 때는 기술 부채를 안고 가야 하고, 또 어떤 때는 지금 해결하고 가야 하죠. 그 판단은 항상 어렵지만, 이러한 판단이 ‘서비스의 지속 가능성’과 직결된다고 생각합니다. 시행착오는 누구나 겪지만, 그걸 빨리 인식하고 개선하는 서비스가 더 오래 살아남을 거라고 봐요.
Q. 판단을 하려면 기준이 있어야 할 텐데요.
대명 님은 어떤 기준을 갖고 계신가요?
저는 서비스에 대한 사용자의 신뢰를 얼마나 해치는가를 가장 중요한 기준으로 봅니다. 투자 일정이나 고객과의 약속이 걸린 기능이라면, 조금 불완전하더라도 빠르게 내보내는 게 맞을 거예요. 하지만 서비스 신뢰도에 직접적인 영향을 미치는 경우라면 이야기는 달라져요.
예를 들어 금융 서비스에서 시간이나 금액이 잘못 표시되는 오류는 단순한 버그가 아니라 신뢰 전체를 무너뜨릴 수 있어요. 이 경우는 아무리 느리더라도 반드시 검증을 거쳐야 합니다. 반대로, 이미지 업로드 같은 기능은 약간의 버그가 있더라도 시도하면서 개선해 나갈 수 있어요. 용량을 조금 더 차지하거나 서버 비용이 조금 늘어나는 정도라면 나중에 고쳐도 되겠죠.
Q. ‘기준’과 ‘결과(현실)’ 사이에는 필연적으로 간극이 있을 수밖에 없습니다. 기준에 따라 판단해도 항상 옳은 결과로 이어진 건 아니었을 듯해요.
맞아요. 그런 경우가 너무 많죠 (웃음). 한 가지 기억에 남는 건 푸시 시스템을 만들었을 때예요. 처음엔 유저가 많지 않아서 한 번에 5만~10만 명 정도만 보낼 수 있으면 충분하다고 생각했거든요. 그런데 사용자가 30만 명으로 늘면서 성능이 급격히 떨어졌습니다. 당시엔 마케팅 측면까지 고려하지 못했는데, 광고를 진행하면서 ‘얼마나 빠르고 많이 보낼 수 있느냐’가 곧 수익과 직결되는 문제가 되었죠. 결국 처음부터 구조를 잘못 설계했다는 걸 뒤늦게 깨닫고 개선 작업을 해야 했습니다.
Q. 그 간극을 좁히기 위해서는 어떻게 해야 할까요?
만약 간극을 줄일 수 없다면 ‘대처’가 중요할 텐데요.
간극이 존재함을 받아들이고 그 결과를 성장의 기회로 받아들이는 태도가 중요하다고 생각해요. 절대 틀리지 않는 기준은 없거든요. 언제든 틀릴 수 있음을 인정하고 끊임없이 검증하며 기준을 수정해나가야 해요.
문제에 따라서는 때론 당장 바꾸기 어려운 경우도 있어요. 일정이나 상황을 고려해야 하니까요. 그래서 한 번에 완벽히 고치기보다는, 시간 날 때마다 바꿀 수 있는 부분을 찾아 조금씩 개선해요. 결국 선택의 문제예요. 완벽을 추구할지, 일단 빠르게 진행하고 큰 문제는 나중에 해결할지를 판단해야 하죠. 또 환경이 바뀌거나 새로운 기술이 나오면, 처음엔 맞다고 생각했던 게 달라지기도 합니다. 그럴 때마다 다시 손봐야 하는데, 이런 과정을 저희는 ‘기술 부채를 갚는다’고 불러요. 당장은 완벽하지 않더라도, 나중에 개선할 여지를 남겨 두고 꾸준히 갚아 나가는 식으로 접근하고 있습니다.
Q. 11월 COMMIT에서 ‘스타트업의 서비스 설계’로 발표하시는데요.
어떤 이야기를 들려주실 건가요?
많은 개발자분이 ‘어떻게 구현할까’에만 집중하는 경우가 많아요. 하지만 스타트업에서는 단순히 개발만 하는 것이 아니라, 운영, 오퍼레이션, CS, 배포, 통계 분석까지 다뤄야 합니다. 물론 모든 걸 직접 다 하진 않지만, 이들이 기술적으로 어떻게 연결돼야 나중에 효율적으로 돌아갈지를 생각하는 것이 중요하죠.
예를 들어 배포 자동화(CI/CD), 로그 관리, 통계 시스템 같은 것들이 처음부터 잘 설계돼야 서비스가 안정적으로 성장할 수 있습니다. 이런 부분을 놓치면 운영 단계에서 더 큰 부담이 생기게 됩니다.
그래서 이번 COMMIT에서는 단순히 기능 구현을 넘어, 서비스 전체를 보는 시야를 함께 가져가셨으면 합니다. 조금 더 넓게 생각해서, “이 기술이 나중에 어떤 흐름으로 연결될까?”를 고민해 보는 시간이 되길 바랍니다.
