커서 전사 도입 성공 시킨 개발자는 지금 어떤 고민을 하고 있을까?

안녕하세요 채널팀의 Developer Relations 수입니다!

빠르게 다시 돌아온 채널 엔지니어팀 '리더십 인터뷰' 시리즈 인데요. 이번 주인공은 채널톡의 Front ALF 팀을 리드하고 계시는 몽 입니다! 채널 테크 블로그에서 높은 조회와 관심을 받았던 Cursor 전사 도입 아티클의 주인공이기도 한데요. 이번 인터뷰에서는 Cursor 전사 도입 이야기뿐만 아니라, 몽의 채널톡 리더로서의 역할과 고민들에 대해 함께 이야기해보려 합니다.

몽 안녕하세요! 소개 한번 부탁드릴게요.

안녕하세요. 채널톡에서 Core-Web 팀을 이끌었고, 현재는 Front ALF Feature 팀을 리딩하고 있는 몽 입니다. 몇 달 전까지는 Frontend Engineering 매니저로서의 역할에 더 집중해왔다면, 지금은 하나의 Feature 팀을 리딩하며 제품 단위의 성과에 더 밀접하게 관여하고 있습니다. 현재는 프론트 개발자 뿐만 아니라 각 도메인의 개발자, 디자이너, GTM 등 다양한 역할의 구성원들이 하나의 팀으로 유기적으로 협업할 수 있도록 팀 운영과 방향성을 함께 고민하고 있습니다.

Feature 팀이 무엇인지 궁금하다면? 👉🏻 채널톡 CTO가 말하는 함께 하고 싶은 개발자

Q. 채널톡에 합류하기까지의 이야기가 궁금해요.

제가 채널톡에 들어온 건 2020년이었는데요. 현재 채널 백엔드 리더인 빌로가 지원해보라는 제안을 통해 채널팀과의 인연을 시작하게 되었어요. 첫 오피스를 방문했을 때 기억도 합니다. 작은 라운지에서 사람들이 모여 이야기 하고 있는 모습이 정말 재미있어 보였어요. 그 모습을 보면서 ‘아, 이 회사 즐겁게 일할 수 있겠구나’하는 생각이 들었습니다. 인터뷰도 기술적인 부분 뿐만 아니라 비즈니스 관련 대화도 많이 한 흥미로운 인터뷰 였어요. 면접 이후 바로 오퍼를 받게 되면서 채널과의 인연을 이어가게 되었습니다.

Q. 채널톡에서 진행한 많은 프로젝트 중에서 기억에 남는게 있다면 어떤 것일까요?

기억에 남는 프로젝트를 꼽자면 몇 가지가 있는데요. 우선 굵직한 클라이언트 피처들을 정말 빡센 일정 안에서 책임감 있게 끝냈던 경험들이 떠올라요. 예를 들어, BM 개편이나 대형 프로젝트를 한 달 만에 마무리 했던 일들이 있었는데, 그런 프로젝트들은 지금 돌아봐도 꽤 임팩트 있었던 것 같습니다. 가장 성장했던 경험은 V4 인박스 전면 개편이었어요. 그때가 아마 입사 1년 차 쯤이었는데, 거의 6개월 동안 인박스 전체 코드를 뜯어 고치면서 기반을 다시 다졌어요. 지금도 그 코드가 현행 유지되고 있다는 점에서 개인적으로 의미가 큽니다. 개발하면서 배운 것도 많았고, 팀과 함께 해결한 과정도 기억에 남는 부분이에요. 또 다른 하나는 팀 구조가 바뀌면서 잠깐 팀 알프라는 팀에서 프로젝트를 진행했을 때예요. 그때 한 달 정도 LLM 기반의 대화형 기능을 구현 했는데, 기간은 짧았지만 팀원들과 굉장히 재밌게 집중해서 만들었던 경험이라 뚜렷하게 남아 있습니다.

Q. 채널에서 여러가지 경험을 쌓으면서 중요하게 생각하는 개발 가치는 무엇인가요?

제가 최근에 중요하게 생각하게 된 개발 가치는, AI를 쓰더라도 기반이 되는 전통적인 개발 원칙들—예를 들면 디자인 패턴, 아키텍처, 확장 가능한 코드 구조 같은 것들을 이해하려는 태도가 필요하다는 거예요. 웹팀 있었을 때 제가 마지막으로 했던 게 웹 온보딩 과제를 만드는거였는데요. 그 과제가 그래픽 캔버스 에디터를 리액트로 구현하는 거였어요. 겉으로 보기엔 그냥 기능 하나씩 붙이면 되는 것처럼 보이는데, 실제로는 아키텍처나 디자인 패턴을 제대로 고려하지 않으면 나중에 기능을 추가할 때 정말 고생하게 돼요. 예를 들어 선(line)이라는 객체를 만들었다고 치면, 이후에 기울기, 그라데이션, 중간 텍스트 삽입 같은 요구사항이 생길 수 있잖아요. 그런데 처음부터 확장성을 고려하지 않고 “일단 되게만” 만들면 결국 나중에 코드를 다 갈아엎어야 합니다. 저는 그 경험을 하면서 “당장 보이는 요구만 구현하는 개발”이 아니라, “변할 가능성까지 열어둔 설계”가 얼마나 중요한지 많이 배웠어요.

해당 과제를 만든 이후, 이 구조를 개인적인 프로젝트에도 활용해보기 시작했습니다. 이 경험이 자연스럽게 Cursor 전사 도입을 고민하게 된 출발점이 되기도 했는데요. 당시 프로젝트를 진행하면서 스스로 하나의 기준을 정했습니다. “가능한 AI만 사용해서 구현해보자.” 이 기준은 단순한 실험이라기보다, 실제로 잘 동작한다면 조직 차원에서도 충분히 제안할 수 있는가를 검증하기 위한 개인적인 테스트였습니다. 이 과정에서 Cursor를 처음 실험적으로 써봤어요. 당시에는 바이브 코딩이나 AI 실험 자체가 유행이었지만, “실무에서 AI와 어떻게 협업해야 생산성과 코드 품질이 동시에 올라갈까” 같은 논의는 거의 없던 시기였죠. 그 고민들이 쌓이면서 제 관점이 생겼고, 그게 뒤에 더 얘기하겠지만 지금의 Cursor 전사 도입까지 이어졌습니다.

결국 이 모든 과정으로 지나오면서 느낀건 AI 개발 속도가 굉장히 빠른데, 많은 개발자들이 그냥 “아 그런 게 나왔대” 하고 넘어가는 경우가 많더라고요. 저는 그보다는, “이걸로 어디까지 내 생산성을 끌어올릴 수 있을까?”, “AI가 나 대신 코드를 쓸 수 있는 수준까지 갈 수 있을까?” 같은 걸 진득하게 고민해보는 엔지니어가 됐으면 좋겠어요.

Q. Feature-Front ALF 팀! 어떤 방향성을 갖고 있는 팀인가요?

Feature-Front ALF 팀은 고객 상담의 자동화를 단계적으로 실현하는 AI 에이전트 ALF를 만드는 팀입니다. 현재는 상담툴 내 인바운드 상담 과정에서 ALF의 활용 비율과 문제 해결률을 높이는 것을 중요한 단기 목표로 두고 있습니다. 장기적으로는 단순히 “ALF를 사용하는 것”을 넘어서, 상담 과정에서 축적되는 데이터들을 기반으로 AI 상담의 품질이 스스로 개선되는 구조를 만드는 것이 비전입니다. 이를 위해 팀은 AI 제품 도입 과정의 허들을 낮추는 방향과, AI가 자신의 응답 품질을 판단하고 학습할 수 있도록 돕는 evaluation 영역을 중심으로 제품과 기술을 발전시키고 있습니다.

Q. Core-Web팀 리더에서 Feature 팀 리더로 전환하면서 어떤 변화가 있었나요?

웹팀에 있을 때는 웹 엔지니어들의 협업 효율을 높이는 데 더 집중했어요. 협업 과정에서 병목이 생기는 부분은 없는지 살피고, 좋은 코드를 작성할 수 있도록 가이드하거나 리뷰와 아키텍처 품질을 1:1로 챙기는 역할이 많았죠. 하지만 Feature팀으로 오고 나서는 ‘기술 중심’에서 ‘제품 중심’으로 관점이 옮겨졌어요. 이제는 단순히 코드를 잘 만드는 것을 넘어서, 이 기능이 왜 필요한지, 어떻게 팔지, 기존 시스템과 어떻게 자연스럽게 연결할지, 어떤 지표를 어떻게 트래킹해야 하는지 같은 제품·비즈니스적인 질문을 더 많이 하게 됩니다. 또한 팀에서 백엔드 매니징도 맡기 시작하면서 자연스럽게 도메인 확장도 필요해졌어요. 웹 엔지니어링 기반만으로는 한계가 있다 보니, 요즘은 백엔드 영역도 의도적으로 익히며 균형 잡힌 리더십을 갖추기 위해 노력하고 있습니다.

Q. 기술 외적으로 리더로서 시간을 많이 할애하는 일은 무엇인가요?

팀이 하나의 목표를 바라볼 수 있게 하는데 시간을 많이 썼던 것 같아요. 단순히 '어떤 피쳐'를 '언제' 내놓아야 한다는 것으로는 팀원들의 동기부여가 충분치 않다고 생각했기 때문입니다. 우리의 장기적인 비전은 이런 거고, 고객이 얻을 수 있는 이점은 무엇이 있으며, 그렇기 위해서는 이 피쳐가 있으면 장기 비전의 어떤 점을 충족하고 싶다는 식으로 모두가 하나의 북극성을 바라볼 수 있어야 한다고 생각했어요. 그래야 능률도 오르고, 개선 제안도 적극적으로 하면서 제품에 대한 자부심이 생기거든요.

Cursor 전사 도입의 뒷 이야기가 궁금해요!

최근 1년 사이 채널 엔지니어팀에도 다양한 AI 툴들이 도입되며 큰 변화가 있었는데요. 그 시작점이 바로 몽이 추진했던 Cursor 전사 도입이었죠.

Q. 당시 도입 과정에서 어려웠던 점이나 고민이 있었던 부분이 있었다면 어떤 점들이 있었을까요?

첫번째로는 리더십의 ‘와우 포인트’를 끌어내는 것이었어요. “Cursor가 있으면 여기까지 된다”를 눈으로 보고 체감해야 판단이 서잖아요. 그래서 POC 수준에서 기능을 80~90%까지 구현해 내는 사례들을 보여주려고 노력했어요. 재미있던 건 막상 도입하고 나서부터였어요. 리더십에서도 “이거 Cursor로 여기까지 돼요?”라는 반응이 계속 나왔거든요. 그런 순간들을 보면서 결국 설득은 말도 중요하지만 직접 경험하게 하는 것이라는 걸 다시 느꼈습니다. 그래서 도입 단계에서는 단순 설명보다는 “와우 포인트”를 직접 보여주는 게 중요했고 그걸 만들어내는 과정이 어렵지만 동시에 가장 핵심적인 부분이었어요.

또 다른 허들은 아무래도 보안이었어요. 당시에는 Cursor를 쓰는 회사가 거의 없었거든요. 요즘은 삼성이나 토스 같은 곳에서도 사용한다는 얘기가 들리지만, 그때는 레퍼런스가 없다 보니 보안 검증을 직접 해내야 했고 그 과정이 꽤 오래 걸렸습니다. 그래도 다행이었던 건, 회사가 이미 “AI로 생산성을 높이자”라는 방향성에는 공감하고 있었기 때문에, 그 자체를 설득하는 데는 큰 어려움이 없었어요. 방향성에 얼라인된 상태에서 리스크를 어떻게 최소화하느냐가 핵심 과제였죠.

커서 전사 도입의 과정이 궁금하다면? 👉🏻 "Cursor 전사 도입 6개월: 이후 변화들"

Q. 실제 도입도 결정이 된 이후 엔지니어팀의 실제 반응이나 적용에는 어려움이 없었나요?

도입이 결정되고 나서의 어려움은 사용 확산이었어요. 도입을 하는 과정에서도 예상하기를 했지만 제가 도입을 한다고 했을 때 생각했던 방향성과 실제 사용성 사이에는 아쉬움이 있었어요. 이미 익숙해져 있는 기술을 벗어나 새로운 도구를 누군가가 적극적으로 전파하지 않는 이상, 확산되기에는 쉽지 않겠다는 생각이 들었어요. 그래서 직접 팀들을 돌아다니면서 “왜 안 쓰세요?”라고 물어봤는데, 대부분의 답이 “잘 안 돼요”였어요. 그렇다고 모델이 좋지 않아서 아니었고 단지 잘 활용하는 방법을 초반에는 많이 모르셨어요. 결국 질문을 잘못 넣어서 그런 경우가 대부분 이더라고요. 그래서 처음에는 1:1로 “이럴 땐 이렇게 질문하면 돼요” 같은 식으로 교정을 돕기 시작했어요. 그러다 보니 이걸 개별적으로 반복하느라 비효율적이라는 생각이 들었고 결국 엔지니어 세션에서 잘 활용할 수 있는 방법에 대해 발표도 하게 되었습니다.

그 외에도 도메인별로 4~5명씩 모아서 실시간 리팩토링을 해보는 방식이도 시도했어요. 그 시간이 꽤 효과적이었어요. 여러가지 노력들로 사용자가 점점 늘기 시작했고 어느 순간부터는 사람들이 스스로 실험하고 응용 하면서 “어? 이거 생각보다 재밌네?”라는 분위기가 생기더라고요. 지금은 저보다 Cursor를 더 잘 쓰는 동료들도 너무 많습니다.

Q. 이제 커서 전사 도입도 1년 6개월이 넘어가고 있는데 그 동안 어떤 긍정적인 변화가 있었다고 생각하시는지? 반대로 긍정적인 효과 이면에 조심해야 하는 부분이 있다면 어떤게 있을까요?

전사 도입 이후 가장 눈에 띄는 변화는 팀 전체의 AI 활용도가 ‘실험 단계’를 넘어 ‘업무 습관’에 가까운 수준으로 올라왔다는 점이에요. 한국 엔지니어링 조직 중에서도 비교적 빠르게 안착한 편이라고 느끼고, 최근에는 엔지니어팀을 넘어 비즈팀·디자인팀까지 Cursor를 활용하는 사례가 자연스럽게 늘어나고 있습니다. 이 단계까지 오면 생산성 체감이 분명해지는 만큼, 이제는 “도입을 할까 말까”보다 어떻게 하면 비용 대비 효과를 최적화할지를 고민해야 하는 시점이기도 합니다.

반대로, 긍정적인 효과가 커질수록 조심해야 하는 지점도 명확해져요. 저는 AI 활용이 개발 문화를 지켜나가는 것과 꽤 비슷하다고 생각합니다. 누군가가 “잘 쓰는 방법”을 정리해두지 않으면 팀은 같은 시행 착오를 반복하거나, 반대로 편의성 때문에 남용으로 흐르기 쉽거든요.

그래서 전사 도입 이후에는 단순히 툴을 배포하는 것을 넘어서,

• 어떤 문제에 AI를 쓰면 효과적인지(적합한 사용처)

• 어떤 경우에는 사람이 더 책임 있게 판단해야 하는지(검증 기준)

• 팀이 공통으로 재사용할 수 있는 프롬프트/패턴을 어떻게 축적할지(지식화)

같은 가드레일과 공유 자산을 꾸준히 관리하는 역할이 중요해졌다고 느낍니다. 결국 AI는 “정답을 주는 도구”라기보다, 팀의 실행 속도를 크게 올려주는 만큼 팀 차원의 사용 원칙과 검증 루틴이 있을 때 가장 안전하고 오래 가는 레버리지가 되는 것 같아요.

커서 전사 도입의 비하인드가 더 궁금하다면?

👉🏻 📹 [re:COMMIT] 사내 동료는 AI입니다 코딩 위임 1년, 그 과정과 개발 조직의 변화

Q. 몽이 생각하시는 채널톡 개발자에게 필요한 역량은 무엇일까요?

채널톡은 B2B 서비스라는 특성상 고객사의 요구사항이 복잡하고, 상황에 따라 우선순위와 제약도 계속 달라집니다. 그래서 단순히 기능을 ‘잘 구현하는 것’보다, 그 복잡도를 일관된 구조로 정리하고 안정적으로 흡수할 수 있는 아키텍처 설계 역량이 더 중요하다고 생각합니다.

신입·주니어 개발자에게는 AI 활용 능력과 함께 ‘검증 능력’을 특히 강조하고 싶어요. AI는 생산성을 크게 높여주지만, 답이 항상 맞지는 않고—특히 아키텍처 관점에서 완성도 높은 선택을 자동으로 보장해주진 않거든요. 결국 중요한 건 AI가 내놓은 결과를 그대로 쓰는 게 아니라, 스스로 근거를 확인하고 개선하면서 품질을 끌어올리는 습관이라고 봅니다.

이 검증 루틴이 자리 잡으면 AI는 주니어에게 24시간 시니어 보조처럼 작동할 수 있습니다. 저는 AI에게 구체적인 페르소나를 부여해 상호작용하면서, 단순히 답을 받는 걸 넘어 사고력을 끌어올려 보는 활용을 추천하고 있어요.

Q. 현재 채널톡 엔지니어팀을 가장 잘 설명 할 수 있는 한 가지 특징을 꼽는다면 어떤게 있을까요?

‘변화에 적극적인 팀’이라고 할 수 있을 것 같아요. 채널톡은 조직 구조나 업무 방식에 있어 변화를 시도하는 주기가 빠른 편입니다. 이러한 잦은 변화가 무조건 긍정적이라고 할 수는 없지만, 이 과정 자체가 팀의 가장 큰 매력이자 성장 동력이라고 생각합니다. 지금이 바로 가장 빠르게 움직일 수 있는 최적의 시기라고 저는 생각해요. 조직 규모가 더 커진 후에는 아무리 바꾸고 싶어도 관성 때문에 쉽게 변화를 줄 수 없거든요. 저희는 아직 성장하는 단계에 있기에 더 나은 방향을 찾아 끊임 없이 실험하고 개선 해 나가는 적극성을 갖고 있습니다. 이 점이 채널톡에서 일하는 엔지니어들에게 가장 큰 성장 기회를 제공하고 있다고 생각해요.

Q. 마지막으로 현재 함께하는 동료들에게도 한 마디 해주신다면요?

실무에 치이다 보면 어느새 가장 익숙한 방식으로 코드를 작성하게 되기 마련입니다. 하지만 의식적으로 Safety zone을 벗어나려는 시도를 계속하는 것이 중요하다고 생각합니다. AI 시장은 지금까지 경험해보지 못한 속도로 변화하고 있는 만큼, 이러한 흐름 속에서 지금 함께하고 있는 팀원들과 서로 자극받으며 성장하고, 끝까지 잘 헤쳐 나갈 수 있기를 바랍니다.