채팅 수집은 처음에 Node·TypeScript로 구현하기로 했습니다. 기존 자산을 재사용할 수 있었고, 프론트엔드 담당 팀원이 익숙한 언어이기도 했습니다. 그런데 담당자가 Spring을 주로 쓰는 인원으로 바뀌었습니다. 코드는 재사용할 수 있어도, 앞으로 변경을 읽고 검토할 사람은 달라진 상황이었습니다.
저는 전체 서비스의 역할과 인터페이스를 조율하면서 이 결정을 다시 열었습니다. 2026년 7월 31일, 채팅 수집을 Spring으로 전환하는 결정을 반영했습니다. Spring이 더 빠르다는 성능 판단이 아니라, 처음 선택의 근거였던 담당자의 역량이 달라졌기 때문입니다. 코어 구현은 팀원이 맡았고, 저는 미디어·인프라와 맞닿는 계약 및 코어 설계를 함께 검토했습니다.
재사용 비용만 보면 이후의 검토 비용이 빠집니다
Node 자산이 있다는 사실은 초기 구현에 유리했습니다. 그러나 맡는 사람이 바뀐 뒤에도 같은 이점이 유지되는지는 다시 따져야 했습니다. 익숙하지 않은 코드를 수정할 때 오류를 놓치거나 변경 검토가 한 사람에게 몰린다면, 처음 아낀 작업이 이후의 유지 비용으로 돌아올 수 있습니다.
3인 팀에서는 누가 구현하는지만큼 누가 변경을 읽고 실패를 조사할 수 있는지도 중요했습니다. 저는 자신이 주로 다루는 Go를 다른 서비스에도 통일하기보다, 각 담당자가 책임질 수 있는 기술을 선택하고 서비스가 만나는 부분을 함께 정하는 쪽을 택했습니다.
| 역할 | 언어·환경 | 당시 선택의 근거 |
|---|---|---|
| 계정·권한·클립 상태를 다루는 코어 API | Spring | 팀의 구현·검토 역량과 생태계 |
| 미디어 파일·장기 실행 작업 | Go | 동시 작업과 바이너리 포장을 다루는 자체 계층 |
| OBS 플러그인 | C++ | libobs와 직접 연결되는 구현 |
| 음성·모델 처리 | Python | 모델 실행 도구와의 접점; 설계 배치와 완료 상태는 별도 |
| 채팅 수집 | Node·TypeScript → Spring | 담당자 변경 뒤 구현·검토 책임을 다시 맞춤 |
이 배치는 언어별 성능 순위가 아닙니다. 같은 기능을 여러 언어로 구현해 벤치마크하지도 않았습니다. OBS는 공식 플러그인 문서가 설명하는 libobs 통합이 필요했고, 코어에서는 미세한 언어 성능 차이보다 팀의 Spring 검토 역량을 우선했습니다.
다른 언어를 선택했으므로 서비스 바깥의 의미는 맞춰야 했습니다
구현 언어를 자유롭게 고르는 대신, 각 서비스가 상태를 해석하는 방식까지 달라져서는 안 됩니다. 미디어가 파일을 만들었어도 업로드가 끝나기 전이라면 코어가 곧바로 편집 가능한 상태로 표시할 수는 없습니다. 업로드를 재시도할 때 같은 대상을 알아볼 식별자와, 방송 재접속을 같은 회차로 볼 조건도 필요했습니다.
그래서 내부 객체를 공유하는 대신 API·이벤트의 데이터 형태, 식별자, 상태 변경 시점, 실패 응답과 담당 서비스를 맞췄습니다. 내부 구현은 담당자가 바꿀 수 있어도 다른 서비스가 읽는 의미는 합의한 계약을 따르도록 한 것입니다. 전체 연결은 프로젝트 아키텍처 기록에 정리했습니다.
채팅의 언어를 바꾸는 판단도 여기에 맞췄습니다. 기존 자산이 있다는 이유만으로 담당자의 변경을 무시하기보다, 서비스가 제공할 계약을 유지하면서 내부 구현을 맡을 사람이 검토할 수 있게 조정했습니다.
선택을 나눠 가진 만큼 통합 비용도 남았습니다
언어가 여러 개이면 빌드·테스트·배포 도구도 여러 개입니다. 모노레포에서 변경 경로에 따라 검증 대상을 나누고, 서비스 간 상태와 오류를 같은 의미로 관측할 수 있도록 맞추는 비용은 남았습니다. 이를 경로 필터와 서비스 계약으로 관리하는 방향을 택했습니다.
따라서 이 사례의 결과는 속도 향상률이 아니라, 담당 변경에 맞춰 스택 결정을 갱신한 것입니다. 2026년 10월 판본의 서비스 배치는 설계와 역할 분담을 보여 주며, Python 처리나 렌더 워커를 포함한 모든 경로의 운영 완료를 뜻하지는 않습니다.
채팅을 Spring으로 바꾼 이유를 설명하려면 언어의 장점을 나열하는 것보다, 기존 결정을 성립시킨 사람이 달라졌다는 사실부터 봐야 합니다. 이후 스택을 고를 때도 누가 구현하고 검토하며 실패를 조사할지를 먼저 확인하려고 합니다. 그 답이 바뀌었다면 이미 내린 기술 결정도 다시 검토할 수 있어야 합니다.