화면을 넘어 서버와 네트워크까지, ZEP 개발자 노성균님의 일하는 방식

클라이언트 개발은 사용자가 직접 보고 만지는 화면과 기능을 만드는 일입니다. ZEP에서 아바타를 움직이고, 채팅하고, 버튼을 누르는 경험이 클라이언트 개발을 통해 구현됩니다.

하지만 ZEP처럼 실시간 서비스에서는 화면만 잘 만드는 것으로 충분하지 않습니다. 네트워크 상태와 RTC 연결, 오류 발생 시 재시도처럼 사용자가 안정적으로 서비스를 이용하기 위한 흐름까지 함께 고민해야 합니다.

ZEP에서 클라이언트 개발을 담당하는 성균님은 사용자가 직접 마주하는 기능을 만들고 서비스 품질을 개선합니다. 웹 프론트엔드를 넘어 최근에는 서버와 인프라 영역까지 함께 살피며, 제품을 더 넓은 관점에서 이해하려고 노력하고 있습니다.

클라이언트 개발은 화면을 구현하는 일에서 끝나지 않습니다. ZEP처럼 실시간으로 연결되는 서비스에서는 사용자의 네트워크와 기기 환경, 서버와의 통신 상태까지 함께 고려해야 합니다. 사용자와 가장 가까운 곳에서 서비스를 만들고, 보이지 않는 문제까지 관찰하며 해결하는 클라이언트 개발자 성균님의 이야기를 소개합니다.

사용자와 가장 가까운 제품을 만들다

ZEP에서 어떤 일을 하고 계신가요?

ZEP에서 클라이언트 개발을 담당하고 있습니다. 웹 프론트엔드뿐 아니라 최근에는 서버 작업도 함께 하면서, 사용자가 실제로 사용하는 기능을 만들고 서비스 품질을 개선하는 일을 하고 있습니다.

클라이언트 개발자는 어떤 일을 하나요?

클라이언트 개발은 사용자와 가장 가까운 영역을 만드는 일이라고 생각합니다. 서버가 데이터와 비즈니스 로직을 안정적으로 제공한다면, 클라이언트는 사용자가 그것을 편하고 자연스럽게 사용할 수 있도록 구현하는 역할을 합니다.

특히 ZEP은 실시간 서비스이기 때문에 UI만 보는 것은 충분하지 않습니다. RTC나 네트워크 상태처럼 사용자가 직접 보기는 어렵지만 서비스 경험에 큰 영향을 주는 부분도 함께 고민해야 합니다.

ZEP의 클라이언트 개발에서 특히 복잡한 점은 무엇인가요?

실시간 로직을 함께 봐야 한다는 점이 가장 큽니다. 사용자마다 네트워크 환경도 다르고 사용하는 기기도 다르기 때문에, 다양한 상황을 전제로 폴백 로직을 설계해야 합니다.

폴백 로직은 정상적인 요청이 실패했을 때 어떻게 대응할지를 미리 정해두는 것입니다. 네트워크 응답을 제대로 받지 못하면 재시도하고, 문제가 크다면 재접속을 유도하는 식입니다.

화면 너머의 흐름을 이해하는 개발자

좋은 클라이언트 개발자는 어떤 사람이라고 생각하시나요?

화면을 잘 구현하는 것도 중요하지만, 서비스의 전반적인 흐름을 함께 그릴 수 있는 사람이 좋은 클라이언트 개발자라고 생각합니다.

사용자 경험부터 서버와 네트워크까지 이해하고 문제를 해결할 수 있어야 합니다. 그래서 구현 능력만큼이나 문제를 정확히 정의하고, 다른 파트와 원활하게 소통하는 능력이 중요합니다.

클라이언트 개발자가 서버의 인증 방식을 이해하면 폴백 로직을 더 체계적으로 설계할 수 있습니다. 반대로 서버 개발자도 클라이언트와 사용자의 경험을 함께 고려하면, 오류가 발생했을 때 어떤 방식으로 대응할지 더 구체적으로 고민할 수 있습니다.

가장 기억에 남는 작업은 무엇인가요?

계속 담당해온 RTC 관련 작업이 가장 기억에 남습니다. 단순히 화면을 구현하는 것과 달리, 사용자의 네트워크나 디바이스 환경에 따라 문제가 다르게 나타나기 때문에 원인을 찾는 것부터 쉽지 않았습니다.

클라이언트에서 어떤 정보를 수집하고, 그 정보를 바탕으로 문제를 어떻게 진단할지 고민하면서 기능을 구현하는 것만큼 문제를 잘 관찰하고 해결할 수 있는 구조를 만드는 일이 중요하다는 것을 배웠습니다.

AI 시대의 개발과 설계

예전의 개발과 요즘의 개발은 어떻게 달라졌다고 느끼시나요?

예전에는 손코딩의 시대였다고 생각합니다. 얼마나 설계를 잘하고 코딩을 잘하느냐가 중요했죠.

지금은 AI가 있는 만큼 방향을 잘 잡는 일이 더 중요해진 것 같습니다. 직접 작성하는 코드의 양보다 판단력과 문제 해결 능력이 차지하는 비중이 커졌다고 느낍니다.

AI는 업무에서 주로 어떻게 활용하시나요?

기능 구현에 들어가기 전에 아키텍처를 설계할 때 가장 많이 사용합니다. 다만 AI가 처음 제안한 안을 바로 채택하지는 않습니다. 다른 대안은 없는지 확인하고, 현재 상황에 더 적합한 방식이 무엇인지 비교하는 과정을 거칩니다.

오버 엔지니어링은 무엇이고, 왜 주의해야 하나요?

필요한 수준을 넘어 불필요한 로직까지 과하게 설계하는 것이라고 볼 수 있습니다. 예를 들어 서버와의 연결이 끊어졌을 때 재시도 로직과 상태 체크 로직만 있으면 충분한데, 여기에 주기적으로 서버와 클라이언트의 상태를 확인하는 로직까지 추가하는 식입니다.

구현이 복잡해지면 유지보수해야 할 코드가 늘어나고, 실제 문제를 해결하는 데 필요한 범위를 넘어설 수 있습니다. 그래서 AI에게 설계 문서대로 구현이 완료됐다는 답을 받은 뒤에도 실제로 그렇게 동작하는지 직접 확인합니다.

기술 부채를 다시 바라보는 성장

업무적으로 성장하기 위해 어떤 노력을 하고 계신가요?

제 영역을 클라이언트에만 한정하지 않으려고 노력하고 있습니다. 지금은 서버와 인프라 영역까지 함께 살펴보고 있고, 실제 업무에서도 조금씩 맡아보려고 합니다.

이렇게 다른 영역을 함께 보면 클라이언트에서 발생한 문제가 서버와 어떤 방식으로 연결되는지 더 잘 이해할 수 있습니다. 동시에 AI 같은 도구를 적극적으로 활용하면서 생산성을 높이는 방법도 계속 실험하고 있습니다.

현재 RTC에서 풀고 싶은 문제는 무엇인가요?

연결이 끊어지거나 오래된 정보를 내려주는 상황에 대응하는 회복 로직의 아키텍처를 재설계하고 있습니다.

지금 시점에서는 좋은 판단이었던 구조도 시간이 지나면 기술 부채가 될 수 있다고 생각합니다. 특히 RTC처럼 여러 환경과 상태를 함께 고려해야 하는 영역에서는, 서비스를 운영하며 쌓인 경험을 바탕으로 구조를 계속 개선해나가는 과정이 필요합니다.

ZEP에서 일하며 느낀 가장 큰 장점은 무엇인가요?

맡을 수 있는 영역이 넓다는 점입니다. 단순히 화면을 만드는 데 그치지 않고 서버나 RTC 같은 다양한 영역까지 직접 살펴볼 수 있습니다.

그 과정에서 개발자로서 제품과 기술을 바라보는 시야가 많이 넓어졌다고 느꼈습니다. ZEP QUIZ와 ZEP School의 엔진이 되는 ZEP을 개발하며 퀄리티를 최대한 끌어올리려고 노력하게 된다는 점에서, ‘높은 기준’이라는 코어밸류가 저와 가장 가깝다고 생각합니다.

클라이언트 개발은 화면을 구현하는 데서 끝나지 않습니다. 사용자 경험과 서버·네트워크의 흐름을 함께 이해하고, 복잡한 문제를 관찰해 더 나은 구조로 해결해가는 일입니다.