[人터뷰] 해피톡 채팅상담, 10년 레거시 탈출하기 : Kotlin 전환 프로젝트의 모든 것

해피톡이 지난 몇 달간 많은 변화를 겪었습니다. 10년 가까이 이어져 온 채팅상담 서비스 뼈대를 전면적으로 손보고 있는데요.

사실 사용자 입장에서의 UI/UX뿐만 아니라, 서비스 개발 언어부터 바꾸는 대규모 프로젝트, 일명 <Kotlin Conversion Project>를 진행하고 있습니다.

<PHP> 기반 레거시 구조에서 벗어나, 서비스 성능·안정성·유지보수성·개발 생산성을 모두 근본적으로 끌어올리는 대규모 기술 전환 프로젝트죠.

그동안에도 작은 단위의 개선과 업데이트를 꾸준이 이어왔지만, 이번엔 서비스 기초를 완전히 새로 쌓았는데요.

오래 쌓인 레거시를 정리하고, 고객 경험을 더 안정적이고 빠르게 제공하기 위한 블룸에이아이의 올해의 핵심 도전 중 하나였습니다.

이번 인터뷰에서는 해피톡 채팅상담의 대규모 기술 전환을 이끈 리더 두 분, CX본부장 지디와 개발그룹장 이엘을 만나 프로젝트의 여정에 대해 직접 들었습니다.

“안녕하세요, 해피톡 솔루션 총괄 본부장 지디입니다. 해피톡 채팅상담의 전체 레이아웃 관리, 서비스 트렌드 제시, 개발 영역에 대한 터치 등 여러가지 일을 두루 하다보니 저희들끼리는 ‘잡부’라고 합니다. 하하 😂”

“CX본부 개발그룹장 이엘입니다. 지디와 함께 이번 프로젝트를 이끌며 프로젝트 매니저(PM)로서 컨버전 부문 기획, UI/UX 영역까지 리드했습니다. 개발 정책 수립도 담당했고요. 말하고 보니 책임이 정말 막중하네요. 🤭”

🛠레거시를 넘어 새로운 기반으로

코드 and 디자인 표준화로 서비스 최적화하기

Q. 10년 가까이 서비스 중인 해피톡의 근간을 바꿔야겠다는 결정, 쉽지 않았을 것 같습니다. 프로젝트를 시작하게 된 계기는 무엇인가요?

지디: 말씀하신 것처럼 ‘해피톡 채팅상담’은 10여년간 운영되면서 데이터 규모가 방대해지고 오래된 시스템들이 레거시로 쌓였습니다.

오류가 하나 발생하면 ‘이게 어디서 터진 걸까?’를 확인하기까지 10명 가까운 인력이 붙는 경우도 있었고 하루를 통째로 써도 원인이 잡히지 않을 때도 있었어요. 기존에 사용하던 프로그래밍 언어인 PHP의 문법 자체는 쉽고 접근성이 높지만, 기존 프로젝트의 구조적 한계가 있어서 디버깅이 좀 어렵습니다. 적용된 PHP 버전도 옛날 거고요.

같은 맥락으로 PHP 개발자 수급 문제도 컸습니다. 트렌드를 따라갈 줄 아는 양질의 개발자를 확보하기 점점 어려워지다보니, 계속 성장하려면 개발 생태계를 개선할 필요가 있었죠.

고객들이 보는 UI /UX 역시 레거시 환경에서는 리터칭 하기가 정말 어려웠어요. 작은 요소 하나만 바꾸려 해도 뒤에 연결된 기능들이 영향을 받아 근본적인 사용자 경험 개선이 쉽지 않은 구조였죠.

여러 프로그래밍 언어를 비교해봤고, Java기반의 <Kotlin>이 해피톡 서비스와 핏이 가장 잘 맞는 언어라고 판단했습니다. 코드가 심플해 개발 속도가 빨라지고 함수형 프로그래밍이나 대규모 실시간 서비스 구조에서도 안정적이면서, 예측 가능한 비동기 처리가 가능했거든요.

결국 이번 PHP → Kotlin 언어 전환 프로젝트는 해피톡의 개발 생산성, 기술적 리스크, 인력 생태계, 사용자 경험까지 전체를 재정비하기 위한 필연적인 선택이었습니다.

Q. 생각보다 더 큰 프로젝트인데요! 원활한 진행을 위해 세운 목표나 원칙이 있나요?

이엘: 프로젝트의 목표는 해피톡 채팅상담의 안정성과 사용성 최적화예요. 이걸 달성하기 위한 최우선 원칙은 개발 및 디자인 표준 확립입니다.

솔직히 만드는 사람 입장에서 레거시 환경은 개발 표준화가 미흡했는데요. 이전까지는 팀별로 사용하던 개발 규칙이나 코드 스타일이 조금씩 달랐어요.

그래서 프로젝트 초기에 해피톡 컨벤션 룰(공통 개발 표준)을 확립해 이를 기반으로 팀원 모두가 일관된 시스템 구조를 구현·유지할 수 있도록 했습니다.

보일러 플레이트나 API 규약을 표준화하면 개발자마다 결과물이 크게 달라지지 않고, 신규 입사자가 와도 같은 방식으로 코드를 쓸 수 있거든요. “이 프로젝트 안에서는 모두가 이 방식으로 만든다”는 공통 규칙을 우선시했습니다.

그 결과 [요구사항 → 설계 → 구현 → 리뷰 → 테스트]까지 이어지는 개발 프로세스가 명확해졌고, 팀별 협업 마찰도 많이 줄었습니다. 코드 재사용성이나 유지보수 효율이 자연스레 높아졌고요.

개발 표준을 확립한 덕분에, 향후 신규 기능을 만들거나 운영을 개선할 때도 동일한 규칙 아래서 지속적으로 확장할 수 있는 환경이 마련됐습니다. 장기적으로는 같은 시스템을 돌리더라도 절반의 인력으로도 운용 가능한 구조가 된다고 생각해요.

Q. 프로젝트는 어떤 흐름으로 진행되는지 궁금하네요. 현재 어디까지 왔나요?

이엘 : 전체적인 흐름은 [현행 시스템 분석 → TO-BE 기획·UI/UX 설계 → 개발 설계 → 구현 → 테스트 → 배포] 이 순서를 따랐습니다.

우선 내부적으로는 앞서 말씀드린 것과 같이 개발 표준을 수립하고 잠복되어 있던 오류들을 발굴해 개선하는 작업을 해왔어요. 레거시 분석을 해보니 숨어있던 문제들이 꽤 많이 나왔지만, 정책부터 다시 정비하고 AI 코드 분석을 병행한 결과 누적된 오류 95% 이상을 해결할 수 있었습니다.

대외적으로는 일관된 사용성을 위해 고객들이 보는 화면 개선, UI/ UX를 전면 리뉴얼했어요. 해피톡만의 디자인 시스템을 새로 적용했고요.

화면 템플릿이나 버튼, 폼 같은 디자인 컴포넌트들을 전부 표준화하고 가독성을 높여서 어떤 화면으로 이동하더라도 이해하기 쉽고 쓰기 편하게 바꿨습니다.

전체 프로젝트는 총 1, 2차로 나눠서 진행 중인데 현재는 1차 단계 기준으로 93%까지 진행되어 마무리짓는 단계입니다. 해피톡이 라이브 중인 서비스인만큼 고객 혼란을 최소화하기 위해, 한 번에 배포하기보다는 스프린트 단위로 분할해서 순차 오픈했어요.

🪄속도와 안정성 챙긴 새로운 채팅상담

AI 활용해 레거시 코드 분석하고 오류 정리

Q. 그럼 이번 개편으로 해피톡 채팅상담 사용자들은 어떤 변화를 체감할 수 있을까요?

지디 : 트래픽이 몰려도 더 빠르고 안정적인 응답 속도를 기대하실 수 있습니다. 레거시 환경을 대거 정비하면서 상담 화면에서 발생하던 지연이나 불규칙한 오류를 모두 잡아냈거든요. 개발 코드도, UI/UX도 표준화했기 때문에 개선 요청을 하시면 더 짧은 주기로 기능 개선이 가능합니다.

실제로 문제 대응 속도도 정말 많이 올라갔어요.

이전 PHP 시스템은 로그가 부족해서 문제 추적에 비교적 오랜 시간이 걸렸지만, 지금은 상세 로그를 촘촘하게 적재해서 장애가 생기면 원인을 파악하고 복구하는데 걸리는 시간이 1/5 이하까지 줄었습니다.

장애가 발생하더라도 어디서 왜 발생했고 어떻게 해결해야 겠다는 점들이 바로 보이기 때문에, 운영 안정성이 눈에 띄게 좋아졌고 고객이 겪는 불편도 점점 더 감소할 것 같아요. VOC 대응 속도가 획기적으로 빨라질 겁니다.

Q. 사용자는 물론이고 서비스를 만드는 입장에서도 성능이나 유지보수, 보안 측면에서 변화를 크게 느끼실 것 같아요.

이엘 : 가장 먼저 느낀 변화는 속도와 안정성이에요. 핵심 API의 응답 속도가 빨라졌고, 트래픽이 몰리는 피크 타임에도 서비스가 안정적으로 돌아가니 체감 성능이 선명해졌습니다.

유지보수성도 큰 폭으로 개선됐어요. 코드와 API를 동일한 규칙 아래 맞춰놓으니 같은 문제가 반복되는 경우가 줄고 배포에 걸리는 시간도 훨씬 짧아졌습니다.

그리고 무엇보다 레거시에 숨어있던 오류들을 대거 정비하면서 MTTR(서비스 복구까지 걸리는 평균 시간)이 눈에 띄게 줄었습니다. 지디가 말씀하신 것처럼 장애가 발생해도 원인을 더 빨리 찾을 수 있으니 실무자의 업무 부담도 크게 줄었죠.

보안은 아예 개발 과정 속에 기본값으로 내재화했습니다. 권한 관리, 암호화, 감사 로그 같은 보안 요소들이 따로 떼어놓고 처리해야 하는 작업이 아니라, 새 기능을 개발하면 자동으로 따라오는 기본이 된 거죠.

이렇게 기반을 정비하면서 성능, 안정성, 유지보수, 보안까지 모든 영역이 전반적으로 더 단단해졌다고 볼 수 있습니다.

Q. 아주 계획적인 프로젝트지만, 전환 과정에서 겪는 어려움이나 기술적 난관도 있을 것 같은데요.

이엘: 물론 있었습니다. 가장 큰 난관은 복잡한 레거시 의존성, 무엇보다 기존 DB 스키마(DB 구조 설계도)를 변경하기 어렵다는 제약이었어요.

해피톡은 10년 가까이 쌓인 채팅 데이터가 테라(TB) 단위라서 테이블 하나만 변경해도 리스크가 굉장히 커요. 전문 툴로 테이블 변경을 돌려도 하나의 테이블을 바꾸는 데 보름 이상 걸릴 정도였죠. 그래서 가능한 부분만 최소 범위로 변경하고, 나머지는 건드리지 않는 방향으로 접근하기로 했습니다.

우선 스키마를 직접 수정할 수 없었기 때문에, 중간에 호환 레이어를 두어 새 구조와 기존 시스템을 안전하게 분리했습니다. 그 위에서 읽기, 쓰기 경계 재정리, API, SQL 규약 표준화, 트랜잭션 경계 재설계 등을 진행하면서 전환 리스크를 줄였습니다.

또 다른 어려움은 프로젝트 초기 ‘러닝 커브(Learning Curve)’였어요. 팀원 모두가 PHP에 익숙한 건 아니기 때문에 레거시 구조를 분석하는 데 시간이 걸린 건데요.

이 때는 AI 도구를 활용해 기존 코드를 분석하고 정리했어요. 덕분에 새로운 시스템 시나리오를 작성하고 Kotlin으로 안전하게 구현할 수 있었습니다.

Q. 레거시 분석에도 AI를 활용하셨군요. 기술적인 문제 풀이에 AI가 어떤 도움이 됐는지 더 듣고싶어요.

지디 : 네, 이번 프로젝트를 진행하면서 AI 도구의 도움을 정말 많이 받았습니다.

기존 PHP 레거시 코드 분석에 큰 역할을 한 AI 도구는 <클로드 코드(Claude code)>인데요. 클로드 코드가 의존성과 로직 흐름을 일목요연하게 정리해줘서 분석 시간이 크게 줄었습니다. 덕분에 전환 작업을 더 안전하게 할 수 있었고요.

그 다음으로 도입한 툴은 <코드래빗(CodeRabbit)>입니다. 작업 초반에는 개발자마다 Kotlin 숙련도가 다르다 보니, PR(코드 리뷰) 작업이 특정 개발자에게 몰리는 현상이 있었어요. 리뷰를 제대로 하려면 2~3시간씩 걸릴 때도 있었고요.

코드래빗이 기본적인 문법·스타일 체크를 먼저 해주니 우리는 중요한 로직에만 집중할 수 있었고, 리뷰 시간이 확 줄었습니다. 무엇보다 개발자들이 ‘동료의 코드 리뷰’ 때문에 받던 스트레스가 많이 사라졌습니다.

사실 지금 블룸에이아이 전사적으로 코드래빗을 사용 중인데, 이번 컨버전 프로젝트를 진행하면서 그 효과를 체감한 것이 계기가 되어 본격적으로 사용하게 됐습니다.

🤝따로 또 같이, 함께라서 가능했던 변화

CX 본부의 팀워크가 성공으로 이끈 장기 프로젝트

Q. 이쯤되면 프로젝트 주역들이 궁금해지네요! 해피톡 채팅상담의 설계자들이 모인 CX본부도 소개해주세요.

지디 : 블룸에이아이 CX 본부는 ‘해피톡 채팅상담’ 서비스를 개발하는 본부입니다. 고객이 보는 상담 화면부터 운영 도구, 기능, 설계, 실험, 운영 안정화까지 채팅상담 서비스 전반을 책임지고 있어요.

본부 안에는 네 개의 팀이 있고 CX기획팀과 개발그룹에 속하는 RX팀, AX팀, FX팀으로 구성되어 있습니다.

먼저 CX 기획팀은 해피톡 고객경험 전략과 지표, 설계를 총괄하고 제품이 시장에 나올 수 있도록 개발팀과 긴밀히 커뮤니케이션하고 있습니다.

개발그룹은 프로젝트 규모에 따라 나뉜다고 보시면 됩니다.

RX팀은 단기 프로젝트와 실험을 담당하는 팀으로 PoC, MVP를 짧은 주기로 만들어 ‘이 기능이 정말 효과가 있을까?’를 빠르게 검증하는 조직이에요. 속도를 최우선으로 하되 품질 기준은 반드시 지키는 팀입니다.

AX팀은 실행에 특화된 팀이에요. 해피톡 상담서비스의 운영 안정화와 품질 향상을 책임지고, 실시간 모니터링과 신속한 이슈 대응, 소규모 기능 업그레이드를 상시로 진행하고 있습니다.

마지막으로 FX팀은 해피톡의 중장기 로드맵을 책임지는 미래 전략 팀입니다. 플랫폼 아키텍처 고도화와 기술 전환을 주도하고 있어요. 이번 인터뷰 주제인 Kotlin 개발언어 전환이 바로 FX팀의 올해 대표 과제였습니다.

이렇게 해피톡 채팅상담 서비스만을 위해 4개의 팀이 따로 또 같이, 체계적으로 협업하고 있습니다. 이런 팀 구조 덕분에 해피톡 서비스 품질은 그대로 유지하면서 컨버전 프로젝트를 함께 진행할 수 있다고 생각합니다.

Q. FX팀을 중심으로 CX본부가 함께 만들어가는 프로젝트네요. 협업 과정에서 겪은 인상적인 장면이 있을까요? 어려움이 있었다면 어떻게 풀었는지 궁금해요.

이엘 : 이번처럼 호흡이 긴 프로젝트는 개발뿐만 아니라 기획, 디자인, QA팀과의 협업이 필수예요. 다행히 각 팀에서 적극적으로 도와주셔서 큰 갈등 없이 원활하게 진행됐습니다.

물론 논쟁이 없었던 건 아닌데요. 가장 크게 의견이 갈린 건 ‘한 번에 배포할 것인가’, ‘단계적으로 배포할 것인가’였어요.

“어차피 바꿀 거면 한번에 확 바꾸자! vs 라이브 서비스니까 조금씩 안정적으로 가자!”

프로젝트 초반에는 작업을 빨리 끝내야 한다는 부담이 커서 여론이 나뉘었죠.

논의 끝에 고객이 실시간으로 혼란을 겪지 않도록 순차 오픈을 선택했습니다. 대표님께도 ‘고객이 변화를 실시간으로 느끼면 좋지 않을까’ 말씀드리면서 설득했고요.

합리적인 선택이었다고 생각해요. 지금 돌이켜보면 분석과 설계에 2~3개월 더 쓰고, 구현을 애자일 방법론으로 수행했으면 좋았겠다는 아쉬움도 있지만요. 아직 프로젝트가 진행 중이니 앞으로 더 잘 하면 됩니다! 😄

지디 : 사실 프로젝트 기간이 넉넉했다고 말하기는 힘들어요. 개발 뿐만 아니라 QA와 기획, 운영 담당자들도 고생 많이 했습니다.

배포 중에 예기치 못한 성능 저하가 발생한 경우가 있었어요. 하지만 이 때도 본부간 협력이 적극적이어서 빠른 의사결정 끝에 롤백하고 개선 후 무사히 재배포 했습니다.

어느 조직이나 마찬가지겠지만, 크고 작은 문제는 생길 수밖에 없어요. 하지만 팀원들의 협조 덕에 잘 마무리되고 있습니다. 정말 고마워요.

개발자들이 한 단계 더 성장할 수 있도록 적절한 가이드를 주고 과제도 주는 게 제 역할인데, 해피톡 서비스를 개선하는 도전을 이어가면서 저 역시 성장하고 있음을 느낍니다.

🚀성장하는 해피톡의 다음 챕터

더 많은 고객과 함께하는 AI 파트너

Q. 해피톡에게 이번 전환은 하나의 큰 변곡점이었을 텐데요. 끊임없이 성장 중인 해피톡의 다음 목표는 뭘까요?

지디 : 저는 해피톡이 모든 고객의 문제를 해결해줄 수 있는 든든한 솔루션으로 자리했으면 좋겠어요.

100개의 고객은 저마다의 문제로 100가지 고민을 들고 올텐데 해피톡이 모두 해결해줄 수 있다고 믿어요. 고객이 우리 서비스를 쓰면서 ‘아, 이건 진짜 내 문제를 해결해주네’라고 느끼길 바랍니다.

지금 해피톡 고객사는 대형 기업이 많아요. 하지만 결국 더 많은 SMB(Small and Medium Business, 스타트업/중소기업)도 부담 없이 쓸 수 있어야 시장이 넓어지고, 우리의 기술이 더 많은 곳에서 가치를 만들 수 있어요.

그걸 해결하는 게 앞으로 해피톡 CX본부의 숙제입니다.

빠르고 안전한 변화를 일상화하고, 고객사의 다양한 요구를 시스템적으로 확장할 수 있는 기반을 계속 만들어갈 거예요.

이엘 : 해피톡은 AI와 함께 진화하는 서비스가 될 예정입니다.

현재는 상담요약, 템플릿 추천, ‘친절하게 말하기’ 기능을 비롯해 맞춤법과 문장 표현을 자동으로 교정해주는 AI 기능을 제공하고 있어요. 덕분에 상담사는 핵심 내용 전달에만 집중하고, 문장 다듬기나 톤 조절 같은 작업은 AI에게 맡길 수 있죠.

우리는 여기서 더 나아가 해피톡 AI가 상담사의 진짜 ‘AI 어시스턴트’가 되는 모습을 목표로 하고 있어요.

상담 전에는 고객의 과거 이력과 문의 맥락을 미리 정리해주는 ‘상담 준비 노트’ 제공, 상담 중에는 정책·문서·FAQ 기반의 답변 추천과 표현 제안, 상담 후에는 자동 요약·태깅·분류, VOC 인사이트, 리포트 생성까지 전 과정을 지원하는 형태를 계획 중입니다.

해피톡이 지향하는 AI 서비스는 사람을 대체하는 기술이 아닙니다. 상담사가 더 사람다운 대화에 집중할 수 있도록 뒤에서 모든 것을 정리해주는 동료 같은 AI 어시스턴트를 만드는 것, 그게 우리가 추구하는 다음 단계입니다.

+ 🎢 두려움 사라진 자리엔 팀이

지디 : 오랫동안 개발을 해왔지만, 이번 프로젝트를 통해 새롭게 느낀 점이 많아요. 새삼스럽지만 도전에 대한 두려움이 많이 사라졌습니다.

레거시라는 큰 산을 넘다 보면 예상 못한 문제들이 계속 나옵니다. 그런데 그걸 하나씩 해결해가다 보니까 ‘아 우리 팀이라면 이런 문제도 충분히 이겨낼 수 있구나’ 하는 확신이 생기더라고요.

개인의 역량만으로는 절대 불가능한 일이에요. 리더로서 진짜 의미의 팀플레이가 뭔지 다시 한 번 느꼈습니다.