프론트엔드 개발자는 서비스 말고 ‘운영툴’도 만듭니다

내 주변에는 프론트엔드 개발자로 일하고 있거나, 취업을 준비 중인 친구들이 많다. 이 친구들과 만나면 개발에 관한 이야기를 주로 나눈다. 특히 관심이 가는 서비스나, 본인이 만들고 싶은 서비스를 얘기하다 보면, 생각보다 특정 서비스 또는 특정 도메인에서 일해야겠다는 목표를 가진 경우가 많지 않았다. 돌이켜보면 나도 그랬다. 취준생이었을 당시, 여러 서비스를 두루 이용해 보면서 목표로 하는 한 분야를 정하려고 노력했지만, 일하고 싶은 도메인이나 서비스를 하나로 정한다는 건 쉽지 않은 일이었다. 각 서비스는 저마다의 장단점을 가지고 있기 때문이다.

그러던 중 나는 ‘운영툴 개발’이라는 프론트엔드 직무를 알게 되었다. 운영툴은 회사 내부 구성원들이 사용하는 서비스다. 처음에는 이 직무가 낯설게 느껴졌다. 주로 내부 구성원을 대상으로 하는 프로젝트라서 ‘복잡하지 않은 쉬운 작업만 하게 되는 것은 아닐까?’하는 생각이 들었지만, 막상 해보니 일반 서비스 개발과는 또 다른 특징과 장단점이 있었다.

현재 나는 회사 내부에서 쓰는 여러 운영툴의 프론트엔드 파트를 담당하고 있다. 다만 회사마다 운영툴의 개수와 규모는 모두 달라서, 내 경험이 일반적이라고 설명할 순 없다. 그러나 이 직무를 준비하면서 정보가 많지 않아 어려웠던 기억이 있고, 작은 도움이라도 주고 싶다는 생각이 들었다. 이번 글에서는 필자가 어떤 ‘운영툴’을 만들고 있는지, 이러한 툴을 만들며 느낀 장단점과 특징을 공유해 보고자 한다.

내가 만들고 있는 운영툴들

나는 현재 게임 회사 플랫폼팀에서 여러 가지 툴을 만들고 있다. 그중에선 내가 입사하기 훨씬 전부터 만들어진 툴도 있고, 새로 개발하고 있는 것도 있다. 우선 어떤 종류의 툴이 있는지 간단히 소개한 후, 이후 장/단점과 특징 등을 살펴보고자 한다.

1) 서비스 운영을 도와주는 툴

서비스 운영툴은 게임 유저들이 겪는 여러 가지 장애 상황에 대응하거나, 일괄 작업을 수행할 수 있는 툴이다. 이 툴은 툴 사용자가 가진 권한에 따라 접근할 수 있는 메뉴가 구분되어 있다. 또한 동일한 라우트에서도 권한별로 제공되는 UI와 기능이 다르다. 이 툴은 내가 입사하기 훨씬 오래전부터 있었던 툴이지만, 여러 번 마이그레이션 되었기 때문에 코드베이스는 깨끗한 편이다. 입사 당시에는 리팩토링 및 마이그레이션이 진행 중이어서 함께 참여할 수 있었는데, 그 덕분에 코드베이스를 빠르게 숙지할 수 있었다.

2) 쿠버네티스 인프라를 관리하는 툴

관리해야 하는 프로젝트가 많아지면, 데브옵스팀에서 처리해야 할 배포 관련 요청도 점차 늘어나기 마련이다. 그래서 데브옵스팀과 협업하여 쿠버네티스 인프라 대시보드 툴을 제작했다. 깃허브 오픈소스 프로젝트 중에‘OpenLens’라는 잘 만들어진 대시보드 툴이 있는데, 이 툴에서는 너무 많은 정보가 조회되어 오히려 사용하기 불편할 수 있다는 의견이 있었다. 그래서 자체 툴을 제작하게 되었다. 우리가 만든 자체 대시보드 툴은 웹 URL로 접근할 수 있고, 쿠버네티스 인프라의 특정 클러스터 정보를 조회할 수 있다. 수많은 메타정보 중에 업무상 꼭 필요한 것들만 간단하게 조회 및 수정할 수 있는 툴이다.

3) 에셋을 관리하는 툴

회사에 다니면서 ‘grey area(애매한 부분)’가 종종 발생한다는 것을 알게 되었다. 여기서 애매한 부분이란 협업하는 과정에서 누구의 일이라고 딱 잘라 말하기 어려운 일을 의미한다. 애매한 부분이 없으면 가장 좋겠지만, 사람 간의 협업에서 이를 완전히 없애기는 힘들다.

예를 들어, 작업물을 전달하는 과정에서도 애매한 부분이 발생한다. 일반적으로 기획자, 디자이너, 개발자는 모두 다른 업무 툴을 사용한다. 그러면 디자이너가 만든 에셋을 어떻게 기획자에게 전달하고, 또 개발자에게는 어떻게 전달하면 좋을까? 지난 2014년 넥슨 개발자 컨퍼런스(NDC 2014)를 살펴보면, <팀을 구하는 툴 개발>이라는 발표 내용이 있다. 이 발표에선 ‘전달 과정에서의 비효율이 사람들에게 얼마나 큰 절망감을 안겨주는지’에 대해 다루고 있다. 그래서 우리 팀도 최근 이 전달 과정에서의 비효율이 크다는 점에 착안하여, 중간 다리 역할을 해줄 수 있는 툴을 개발하기로 했다. 현재는 기획자와 개발자가 에셋을 주고받는 부분을 우선적으로 만들고 있다.

운영툴 개발 업무의 장점

1) 마감에 쫓기기보다 코드 퀄리티에 신경 쓸 수 있다

툴 개발 업무의 최대 장점은 사용자가 ‘동료들’이라는 점이다. 동료들은 일반 고객과 달리 요구사항을 분명하고 자세하게 알려준다. 또한 실시간으로 의견을 주고받으며 개선할 수도 있다. 예전에 앱 서비스를 만들 때는 사용자가 리포트한 버그를 재현하기 위한 어려움이 컸고, 직접 의견을 물을 수 없어서 답답할 때가 많았다. 그래서 사용자와 직접 소통하며 개발할 수 있는 현재가 훨씬 수월하게 느껴진다.

게다가 동료들은 일반 사용자보다 훨씬 더 많은 배려를 해준다. 물론 그 호의를 당연하게 여기면 안 되겠지만, 일정 압박에 덜 시달리는 만큼 코드 퀄리티에 더욱 신경 쓸 수 있고, 더 좋은 개선안을 떠올릴 수도 있다. 당장 눈앞의 해결책에 매몰되지 않고 생각을 확장시킬 수 있으므로, 결과적으로 주니어 개발자에게는 이 하나하나의 작업이 의미 있는 성장으로 이어질 수 있다.

2) 개발 자유도가 높다

자유롭게 개발한다는 것은 무엇일까? 내 생각에는 기획과 디자인에 다양한 의견을 낼 수 있다는 것이다. 일반 사용자를 대상으로 한 서비스의 경우, 사용자의 서비스 이용을 촉진하기 위한 A/B 테스트 등을 진행하며, 가장 좋은 UI/UX를 찾아내야 한다. 그러나 운영툴 개발의 경우, 사용자의 서비스 이용을 촉진하는 것이 아닌 편의성에 초점을 맞춰 개발하게 된다. 주로 개발자가 직접 고민해서 만든 후, 피드백을 통해 개선해 나가는 방식이라 자유도가 꽤 높은 편이다. 물론 이 과정에서 좋은 UI/UX란 무엇인지, 스스로 고민하는 기회도 생긴다.

우리팀의 경우 UI 라이브러리를 직접 만들어 적용하고 있는데, 실력 향상에 정말 많은 도움이 된다. 컴포넌트가 사용될 다양한 환경(CSR/SSR, 디바이스 종류, 뷰포트 사이즈 등)을 고려해서 설계하는 과정에서 데이터의 생명주기나, 렌더링 퍼포먼스를 다양한 관점에서 고민하기 때문이다. 혼자서 사이드 프로젝트로 진행했다면 훨씬 더 시간이 걸렸을 텐데 회사 팀원들과 함께 작업하니, 약 두세 달 만에 꽤 괜찮은 라이브러리를 완성할 수 있었다.

회사에 따라 운영툴을 풀스택으로 개발하는 곳도 많다. 우리 회사도 관리해야 하는 툴과 피처의 개수가 적었던 시기에는 풀스택으로 개발한 것으로 알고 있다. 혼자서 API를 설계해 붙이게 되면, 그만큼 어려움도 있겠지만 자유도는 상당히 높아진다. 이처럼 여러 가지 면에서 개발 자유도가 상당히 높은 직무다.

3) 다양한 프로젝트에 참여할 수 있다

여러 프로젝트에 참여할 수 있다는 점도 하나의 장점이라고 생각한다. 앞서 만든 프로젝트에서 얻은 지식을 바탕으로, 다음 프로젝트를 시작할 때 더 좋은 상태를 유지하며 개발할 수 있기 때문이다. 기존에 있던 것을 리팩토링하는 것보다, 새롭게 잘 만드는 것이 훨씬 더 쉽다. 한 프로젝트에서 깨달은 점을 다음 프로젝트에 적용한다면, 실수를 반복하지 않는 선순환이 이루어질 수 있다.

사실 여러 툴에 관여하기 위해서는 도메인을 잘 아는 것이 많은 도움이 된다. 그래서 대부분의 툴 개발팀에는 시니어 개발자가 있을 것이다. 신입 혹은 주니어 개발자 입장에서 시니어가 없는 팀에 합류한다는 건, 이정표가 없는 가시밭길에 맨발로 들어가는 것만큼 힘든 일이다. 단순히 ‘책임감’ 때문만은 아니다. 시니어는 길을 잃더라도 다시 돌아올 수 있는 이정표가 되어주고, 끝까지 갈 수 있게 운동화 하나라도 구해다 줄 수 있는 존재이기 때문이다. 아직 주니어라면, 개인적으로는 시니어가 있는 팀에 합류하는 것이 어떤 서비스를 선택할지보다 훨씬 더 중요하다고 느낀다. 그래서 나는 운영툴 개발이 괜찮은 선택이었다고 생각한다.

운영툴 개발 업무의 단점

모든 일에는 장단점이 있다고 생각한다. 앞서 장점으로 언급했던 부분이 어떤 점에서는 단점이 될 수도 있으니 참고해 보면 좋겠다.

1) 고객을 상대하는 보람이 적다

이전에 앱을 개발했을 때는 사용자가 남기는 리뷰가 무척 신경 쓰였다. 하지만 신규 패치를 하고 좋은 유저 피드백을 받으면 그렇게 뿌듯할 수가 없었다. 그러나 지금은 그런 보람이 별로 없다는 점에서 아쉬운 부분이다. (앞서 말한 툴 개선을 위해 동료들에게 실시간 피드백을 받는 것과는 또 다른 영역이다.) 이 또한 회사마다 다를 수 있지만, 나의 경우 내부 툴과 관련해 리뷰를 남기는 공간이 따로 없다.

물론 리뷰 공간을 만든다고 해서 좋은 리뷰만 있진 않겠지만, 그래도 수시로 리뷰를 확인할 수 있다면 소소한 보람과 즐거움이 될 것 같다. 만약 본인이 ‘일반 유저를 대상으로 한 서비스’가 맞는 사람인지 잘 모르겠다면, 스스로에게 ‘유저 피드백’이 의미하는 바가 무엇인지, 얼마나 중요하게 생각하는 지 등을 고민해 보면 좋을 것이다.

2) 도메인을 잘 모르는 상태라면 적응이 오래 걸린다

운영툴은 말 그대로 서비스의 뒷편에서 운영할 수 있는 기능을 개발하는 것으로, 도메인을 잘 모르는 상태라면 맥락을 파악하고 기능을 개발하는 것이 일반 서비스보다 훨씬 더 어렵다. 게다가 일반 서비스와 다르게 직접 이용해 보기도 어렵다. 라이브 데이터로 직접 테스트해 보기 위해서는 일단 권한을 받아야 하고, 이 절차가 상당히 까다롭다. 아마도 우리 회사만 적용되는 부분은 아닐 것 같다. 그래서 초반에 도메인에 익숙해지고 적응하려면 꽤 오랜 시간이 걸린다. 앞서 운영툴 개발팀에는 대부분 시니어 개발자가 있을 것이라 말한 이유도 이 때문이다.

3) 여러 툴을 동시에 개발해야 하는 경우가 있다

모든 회사가 그렇겠지만, 일이 동시에 몰릴 때는 정말 정신이 없다. 만약 내가 담당하는 툴을 사용하는 동료들이 동시에 바빠져서, 기능 요청이 비슷한 시기에 몰린다면 개발자도 눈코 뜰 새 없이 바빠진다. 그도 그럴것이 다른 팀 동료들은 내가 몇 개의 운영툴을 관리하고, 얼마나 기능 요청을 받는지 알 수 없다. 그래서 일정 조율을 미리 잘하는 것도 중요하겠지만, 그럴 수 없는 상황에서는 동시다발적으로 많은 일을 처리해야 할 때도 있을 것이다.

‘무엇’을 만들고, 어떻게 ‘고민’하는 개발자가 될 것인가

나 역시 취준생을 거쳐 주니어 개발자를 이제 막 벗어나고 있는 시점에서, 앞으로의 진로 방향에 대해 종종 고민하곤 한다. 다른 사람들은 무엇을 개발하고 있는지, 거기서 어떤 성장을 이루고 있는지 등을 유심히 살펴보곤 하는데, 좋은 커리어를 쌓아나가는 개발자들을 보고 느낀 점은 결국 ‘긍정적인 마음가짐’과 ‘끊임없이 고민하는 태도’였다.

유저 인터페이스가 있는 모든 곳에는 크고 작은 프론트엔드 작업이 포함되어 있다. 그런데 그 수많은 화면 중 개발자의 고민이 들어가지 않은 곳은 하나도 없다. 바꿔 말하면 어떤 것을 만들던 고민이 필요하다는 뜻이고, 그 고민을 해서 좋은 답을 낼 수 있는 나만의 생각 루틴이 있어야 한다는 의미다. 여기에서 내가 ‘무엇을 만드는지’보다, ‘어떻게 고민하는지’가 더 중요하다고 생각한다. 고민에 고민을 거듭해 실천해 본 사람은 어떤 일을 맡더라도 스스로 성장할 수 있다. 그리고 그렇게 믿을수록 결과는 더욱 좋아진다.

만약 프론트엔드 개발자를 꿈꾼다면, 어떤 영역에서 프론트엔드가 활약할 수 있는지 넓게 알고 있으면 좋다. 그리고 확실하게 자신 있는 분야를 빨리 찾는 것도 좋다. 그러나 아직 무엇을 만들어야 할지 잘 모르겠다면, 무작정 하나의 정답을 찾으려고 하기보단, 다양한 선택지를 두고 긍정적으로 탐색해 보면 좋겠다. 어쩌면 나처럼 우연히 시작하게 된 직무에서 뜻밖의 성장을 할 수 있을지도 모르니 말이다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.