개발자로서의 자신을 설명한다면?
최수현: 사용자와 가까운 개발자라고 생각하고, 되고자 노력하고 있어요. 개발을 공부하면서 들었던 피드백 중 하나가 “사용자 중심의 시각을 지녔다.”였고, 회사에 들어와 디자인 팀원, PM에게 들었던 피드백도 “사용자가 어떻게 느낄지 의견을 내주어 좋다”란 부분이었어요.
유저-친화적이란 가치가 제가 추구했던 프론트엔드의 주요 가치였고, 앞으로도 챙기고 싶은 부분이에요. 서비스를 사용자에게 잘 전달하고, 사용자의 욕구를 서비스에 잘 전달하는 프론트엔드 개발자가 되고 싶어요.
요즘 굉장히 많은 서비스들이 출시되고, 부드럽고 편리한 인터페이스가 많이 있다 보니 그만큼 사용자들은 좋은 인터페이스를 민감하게 느끼는 것 같아요. 그래서 더 신경을 써야 한다고 생각하지만, 개발을 배우고, 일하면서 스스로 불편함에 무뎌지고 있다고 느끼기도 해요. 때문에 앞으로도 유저-친화적인 부분을 중심에 두고 개발하고 싶어요.
김용래: 보통 프론트엔드 개발자라고 하면 세련된 UI나 화려한 애니메이션, 사용자와의 멋진 인터랙션 같은 시각적인 요소들을 가장 먼저 떠올리게 되는 것 같아요.
실제로도 정말 중요한 부분들이고, 동시에 매력적인 요소라고 생각하지만 저는 개인적으로 사용자와 가장 가까이 맞닿은 환경에서 발생하는 복잡성들을 관리하는 쪽에 매력을 느꼈어요. 여느 상용 서비스들이 그렇듯 캐치테이블도 검색, 예약, 매장 등 많은 정보를 다루고 있는데 이러한 상황에서 데이터들을 체계적으로 관리할 수 있다면 좋겠다고 생각했어요.
좋은 설계를 통해 이러한 복잡성을 해결하고, 프로덕트의 생산성과 안정성에 기여할 수 있는 개발자가 되어보자는 목표를 가지고 입사하였고, 그 목표를 향해 한 걸음씩 나아가고 있습니다.
지금까지 개발하신 서비스나 기능들을 소개해주세요!
최수현: 주로 리뷰와 커뮤니티 기능을 개발하고 있습니다.
캐치테이블에서는 예약, 웨이팅, 픽업 서비스를 이용하면 리뷰를 작성할 수 있어요. 기존에는 사진만 업로드 가능했지만, 현재는 동영상도 업로드할 수 있고, 매장 상세 페이지나 타임라인 등에서는 짧게 재생되는 리뷰 영상도 볼 수 있습니다! 더불어 팔로우/팔로잉을 개편하는 작업도 했어요. ‘팔로우에게만 공개’란 기능인데, 나의 리뷰를 팔로우에게만 보여주는 기능이에요. 그 외에도 팔로우 신청을 받고 요청을 수락/거절하는 기능 등을 추가했답니다!
매 테스트마다 새로운 도전을 하는 기분이 들고는 합니다. 리뷰 서비스 관련 개발을 하면서 iOS, 안드로이드 개발자분들과 협의해야 하는 부분이 많아 의논하며 배우는 부분이 많았고, 커뮤니티 관련하여 서비스 전역에서 가능한 팔로우 기능을 어떻게 관리해야 하는 지에 대한 고민도 해볼 수 있었어요. 두 작업 모두 다른 프론트 파트원분과 같이 작업했는데 그 과정에서 개발이나 일정 관리 측면에서 많이 배울 수 있었습니다.
김용래: 입사 후 내부에서 사용하는 어드민 기능 추가를 시작으로 캐치페이 결제 경험 개선, 마케팅 프로모션, 캐치테이블 글로벌버전의 검색 / 예약 / 결제 고도화, 국내 매장 상세 페이지 개선 등의 과제들을 해결했어요. 돌아보니 이것저것 다양하게 진행했던 것 같은데, 매일매일 새로운 경험을 할 수 있어서 힘든 것보다도 즐거웠던 시간이었습니다.
특히 가장 먼저 맡았던 업무가 캐치페이 결제 경험 개선 건이었는데요, 사용자들이 캐치페이를 이용해 결제를 진행할 때 밟아야 할 단계를 간소화하여 더 빠르고 간편한 결제 경험을 느낄 수 있도록 하는 일이었습니다. 결제는 실수하면 치명적인 결과로 돌아올 수 있기에 기존의 정책과 결제 프로세스를 모두 파악하고 있어야 해서 막중한 책임감을 느꼈답니다.
일하시면서 어려웠던 점들과 깨달음이 있다면요?
최수현: 어려움을 겪고 있을 때 다른 사람에게 도움을 “잘” 요청하는 것이 중요한 것 같아요.
저는 모르는 것이 있으면 다른 사람에게 많이 묻는 편인데, 개발을 배우면서도 묻는 것이 습관이 되었던 것 같아요. 그럼에도 모르는 것을 모른다고 말하는 것이 부끄러워 감추려고 하기도 했구요. 그래서 이와 관련해서 많이 고민했는데, 두 가지 조언이 도움이 많이 되었습니다.
하나, 어디까지 알고, 어디부터 모르는지 말하기, 너무나 당연한 이야기지만 잊고 있던 부분이었습니다. 어떤 어려움을 겪을 때 “ — 해서 이런 문제가 있는데, 어떻게 해보면 좋을까요?”하고 묻곤 했습니다. 그런 제게 ‘어디까지 시도했고 어디까지 알아봤는지 말하지 않는다면 나 역시도 다시 처음부터 문제점을 해결하기 위해 찾아봐야 한다. 때문에 알고 있는 것을 공유해야 그 부분부터 해결책을 모색할 수 있다.’고 말씀해 주셨습니다. 그때 “내가 모른다.”가 아닌 “내가 어디까지 해봤다.”를 초점으로 전해야 한다는 것을 배웠습니다.
둘, 모르는 게 있을 때 물어보기. 리드님께서는 이 부분을 강조하셨습니다. 제 주변에 잘 물어볼 수 있도록 자리 배치를 신경 써주시고, 편하게 물을 수 있도록 분위기도 조성해주셨어요. 특히 일정에 대한 부분이나 다른 팀과 이야기를 해야 하는 부분 등에서 ‘이렇게 하는 게 괜찮을까?’하고 고민을 하다가 여쭤보면 명쾌하게 답을 제시해주시거나 다른 프론트 파트원을 연결 지어 주시기도 했습니다. 그럼 혼자 끙끙 몇 시간 앓던 것들이 금방 해결되기도 하고, 혼자라면 절대 예상하지 못했던 부분에서 문제의 원인을 발견하기도 했습니다. 이를 통해 혼자서 다 잘하겠다는 것이 욕심일 수 있겠구나, 오히려 일정을 맞추지 못해 문제를 만들어낼 수도 있겠다는 생각이 들기도 했습니다.
앞으로 성장하기 위해서는 더욱 “잘” 묻는 방법을 터득해야겠다고 생각이 듭니다. 주위에 실력 있는 사람들에게 도움을 받으며 성장해 받은 도움을 잘 전할 수 있는 사람이 되고 싶습니다.
김용래: 처음에는 누군가와 함께 업무를 진행한다는 게 낯설기도 하고, 쉽지 않은 일이었어요. 함께 프로젝트를 진행하는 PM님이나 백엔드 개발자분들 모두 친절하게 알려주시며 도와주셨지만, 스스로 업무 기한을 산정하고 이를 지키는 동시에 예상치 못한 곳에서 나타나는 이슈들에 대응하는 모든 과정이 처음이었던 제게는 참 어려운 과업이었습니다.
특히 일정을 산정하는 게 어려웠는데, 프로젝트 구조가 제대로 파악되지 않은 상태에서 “이러한 기능을 구현하는데 얼마나 걸릴까요?” 라는 질문에 답하기가 굉장히 곤란했습니다. 해당 기능이 가지고 있는 정책적인 부분부터 코드가 어떻게 굴러가는지 모르는 상태라 제 대답은 늘 “금방 확인해서 다시 말씀드릴게요!” 였습니다. 프로덕트에 대한 기반 지식이 부족했던 게 모든 일을 할 때 발목을 잡아 너무 아쉬운 부분이었어요.
제가 조금 더 도메인에 대해 잘 알고 있었다면 능숙하게 해결할 수 있었던 일들이었다는 생각이 들어서 이에 대한 갈증이 쭉 있었던 것 같아요.
긍정적으로 느껴졌던 점들은 어떤 게 있을까요?
최수현: 프론트 파트 안팎으로 의견을 많이 수용해준다는 점이요!
프론트 파트 안에서는 개발자로서 어려운 점이나, 하고 싶은 것들을 존중해준다는 느낌을 많이 받습니다. 예로, 이벤트 페이지를 제작하는 데에 많은 리소스가 든다는 문제를 해결하기 위해 에디터를 만들자는 의견을 받아들여 실행에 옮겼습니다. 그 결과 이벤트 페이지를 제작하는 리소스를 다른 개발 작업으로 돌릴 수 있었고, 그분은 현재도 마케팅 팀과 이야기하며 개선 작업을 계획하고 있습니다. (미디엄에 관련 글도 업로드 될 예정이니 읽어보시길 추천!)
물론 하고 싶은 것을 모두 할 수 없겠지만 근거가 있고, 가능한 일정이라면 조율을 통해 하고 싶은 것들을 해볼 수 있는 환경이라는 것을 많이 느꼈어요. 배우고 싶은 것/도입하고 싶은 것 등이 있다면 언제든 건의해볼 수 있다는 점이 든든하게 느껴져요.
프론트 파트 밖으로는 하나의 기능을 만들어가며 궁금한 점이나 건의 사항을 편하게 이야기할 수 있다는 점이 좋았습니다. 스스로 ‘디자인은 디자인 팀이, 기획은 기획한 PM이 제일 잘 하지 않을까?’ 하는 생각에 의견을 내도 될 지 주춤하기도 했는데, 그 생각이 무색하게 애니메이션이나 기획 등에서 추가되었으면 하는 부분이나 의아한 부분을 말씀드리면 늘 적극적으로 답을 해주셨습니다. 레퍼런스 등 근거를 통해 제가 이해할 수 있도록 설명해주시거나, 간혹 좋은 의견이라며 받아들여 주시곤 고맙다고 해주시기도 했습니다. 그럴 때 내가 이 기능을 함께 만들어나가고 있구나, 하는 생각이 들면서 더 잘하고 싶다는 마음이 많이 들어요.
작업을 하며 즐거운 마음이 드는 건 함께 협업하는 많은 분들이 저를 이해하고 배려해준다는, 내가 나로 존재한다는 것 때문인 것 같아요.
김용래: 개발부터 배포까지의 과정에 정해진 프로세스가 있다는 게 좋았어요. 팀 내부적으로는 코드 리뷰 문화부터, 전체적으로는 QA 과정까지 엔지니어가 개발 단계에서 할 수 있는 실수들을 바로 잡아줄 과정이 있다는 게 신입의 입장에서는 정말 다행이라고 느껴졌습니다.
프론트엔드 팀 내부에서는 서로 주력인 분야는 있을지언정 어떤 기능이든 맡아서 개발할 수 있는 환경이기 때문에, 모두가 코드 리뷰에 참여할 수 있는 점이 좋았어요. 반대로 말하면 저도 모두의 PR에 리뷰를 남길 수 있어 팀원들의 코드에 적극적으로 기여할 수 있었어요. 리뷰를 남김과 동시에 깊게 추상화 된 코드들처럼 잘 모르는 내용이 나오면 역으로 물어보기도 하고, 팀원들과 대화를 나누면서 기존 코드 베이스에 대한 이해도가 빠르게 깊어질 수 있었던 건 덤이었습니다.
그러나 이렇게 개발된 기능이라도, 완성도가 떨어지거나 심각한 버그를 유발한다면 제대로 사용할 수 없겠죠. 하나의 기능이 배포되기까지 QA팀이 2중, 3중으로 꼼꼼히 기능의 동작을 확인하시는데, 이러한 과정들 덕분에 리얼 환경에서 오작동 할 가능성이 현저히 줄어들어 개발자에게 든든한 안정감을 주고 계십니다.
실제로 결제 관련 태스크를 진행하며 배포 전 최종 테스트에서 특정 동작을 수행하면 결제가 여러 번 이루어지는 버그가 발견되었는데, QA팀이 확인해주지 않았다면 심각한 오류로 이어졌을 터라 등골이 서늘했던 경험이 있어요. 결국 그날은 기능을 내보내지 못했지만, 팀원 분들이 늦은 시간까지 현재 구현이 가진 문제와 해결 방안을 함께 파악해주셔서 다음날 오전에 무사히 배포할 수 있었습니다.
기능을 개발하며 특별히 신경썼던 부분이 있나요?
최수현: 정해진 일정을 맞추는 것이 중요하다고 생각해요.
하나의 기능이 출시되는 과정은 다음과 같아요. 기획 > 디자인 > 개발 > QA > 출시. 간혹 병렬로 이루어지는 경우도 있지만 대체로 이 과정을 따릅니다. 각 단계에서 PM, 디자인 팀, 개발자, QA가 열심히 각자의 일을 수행해요. 기획 과정에서 기능 출시 일정을 산정하는데, 앞선 단계에서 지연될수록 뒷 단계 담당자들의 마음은 조급해지기도 합니다.
때문에 개발자인 저는 정해진 일정에 QA에 넘기는 것을 우선순위로 하고 있어요. 이를 위해서 첫 번째로 기능 요구 사항을 받고 개발 일정 산정을 잘하는 것과, 두 번째로 업무 진척 상황을 잘 체크하는 것을 노력하고 있습니다. 기능을 쪼개 대략적으로 각각 기능을 개발하는 데 걸리는 시간을 설정하고, 어디까지 개발했는지 문서로 정리하면서 진행하고 있습니다. 다만, 아직 완벽하지는 않아 계속 저에게 맞는 방법을 찾으려 노력하고 있습니다!
더불어 간혹 일정이 촉박하거나, 추가 기능 요구 사항이 들어오는 경우가 있는데, 그런 경우 리드님께 말씀드려 일정을 조정하거나, PM님께서 일정을 조정해주시기도 합니다. 어려운 과제를 혼자 붙잡고 있는 것보다 의사소통하는 것이 굉장히 중요한 부분이라는 것도 많이 배웠습니다.
김용래: 저는 결제와 관련된 업무들을 많이 담당한 편인데, 다른 과제에 비해 히스토리와 정책에 대한 파악이 몹시 중요했어요. 결제 데이터를 만지려면 필연적으로 사용자 정보에 대해서도 잘 알아야 하는데요. 사용자가 현재 결제가 필요한 예약을 한 상태인지, 결제에 필요한 약관에는 모두 동의를 한 상태인지, 혹시 와인 주문을 하는 경우 성인 인증은 완료되었는지 등 하나의 동작에 엮여있는 정책들이 곳곳에 숨어있어 고려해야 할 사항이 많았습니다. 서비스 초창기에 있었던 약관의 선택적 동의와 관련된 데이터를 미처 파악하지 못해 버그가 발생했던 경험이 있어서 그 후로는 이러한 부분에 더 신경 쓰게 되었습니다.
두 번째로, 버그 없이 안정적으로 기능을 개발하는 동시에 동료들이 더 쉽게 개발할 수 있도록 기존 환경을 개선하고 싶었어요. 일례로, 몇 번의 서비스 개선을 거치면서 부서진 *타입들이 곳곳에 *레거시로 남아있거나, 비효율적인 방식을 사용하여 프로젝트 크기를 키우고 있던 부분들이 남아 있었는데요.
전자의 경우 현재 버전과 대조하여 각 타입들을 최신 형상에 맞게 수정하고, 이를 명확한 이름으로 변경하거나 주석을 추가하여 동료들이 가이드를 얻을 수 있도록 변경하는 *리팩토링을 수행했어요. 후자의 경우 캐치테이블 홈 화면 하단에서 만날 수 있는 “다이닝 매거진” 섹션이 대표적인데, 이전에 어드민 페이지 개선에 참여했던 경험을 살려 외부 업체와의 협력을 통해 받은 컨텐츠를 내부 에디터를 기반으로 한 파일들로 *마이그레이션하고, 이 데이터들을 서버 개발자분과 논의하여 새로 생성한 API를 통해 받아오게 변경하였어요. 이를 통해 불필요하게 차지하고 있던 파일들이 사라지고, 매번 새로운 콘텐츠를 추가하거나 수정할 때마다 더 이상 배포를 하지 않아도 되는 일석이조의 효과를 얻게 되었습니다.
기존에 주어진 사업 과제를 진행하는 동시에 개선할 부분을 찾고, 이를 주도적으로 해결하는 작업을 진행했다는 점에서 개인적으로 큰 의미로 다가온 일이었습니다.
용어 설명*
※타입: 각 데이터들이 어떤 형태를 띄고 있는지 알려주는 설명서
※레거시: 이전에 작성되어 프로젝트에 남아있는 코드들
※리팩토링: 효율적인 개발을 위해 코드를 개선, 수정하는 일
※마이그레이션: 데이터를 한 곳에서 다른 곳으로 이동하는 일
많은 것들을 배우고 느끼신 것 같은데, 앞으로 어떤 것들을 해보고 싶으신가요?
최수현: 회사에서 일을 하며 새롭게 알게 된 것 중 A/B 테스트와 로그 수집을 더 잘 해보고 싶어요.
A/B 테스트는 사용자를 여러 집단으로 구분하여 각기 다른 버전을 제공하고, 이를 토대로 사용자의 선호 등 데이터를 수집할 수 있어요. 캐치테이블에서는 주로 UI/UX 부분에서 테스트를 하고 있는데 저는 지금까지 2–3번 정도 테스트를 수행했습니다.
로그는 클릭이나 페이지 진입 등 사용자 인터렉션에 따라 로그를 보내고, 이를 적재하여 데이터로 활용할 수 있습니다. 매 기능 개발의 끝은 로그 작업이라고 할 수 있을 정도로 로깅을 많이 하다보니 더 잘하고 싶은 욕심이 생기더라구요.
두 가지 모두 사용자를 알 수 있는 지표라 더 체계적으로, 정확하게 하고 싶다는 생각이 들어요. 이런 데이터들을 잘 수집할수록 사용자가 선호하는 UI/UX나 키워드, 마케팅 요소 등을 잘 캐치해 알잘딱깔센한 서비스가 되지 않을까 싶어요.
김용래: 여러 과제를 맡아 컨텍스트를 빠르게 스위칭하는 과정에서 문서화의 중요성을 알게 되었어요. 머리로는 알고 있다고 생각했던 내용도 막상 로직이 복잡해지기 시작하면 헷갈리기도 하고, 또 다른 컨텍스트로 넘어갔을 때 빠르게 적응하기 위해선 디테일한 부분까지 잘 정리된 문서가 꼭 필요하겠더라고요. 기존 작업자분들이나 PM분들이 작성해주신 문서들에 도움을 받았던 것처럼, 저도 새로운 작업을 진행할 때 다음에 관련 작업을 맡을 사람을 위해 사내 문서를 꼼꼼히 작성해야겠다는 생각이 들었어요.
이전까진 “개발자면 코드만 깔끔하게 유지하면 되겠지!” 라고 은연중에 생각했었는데, 항상 미래의 자신과 다른 팀원들을 위해 코드와 문서 두 공간을 잘 관리하고 활용해야겠다는 인사이트를 얻었습니다. 혼자 일하는 곳이 아니기에 이런 팀적인 역할이 더욱 중요한 것 같아요.
개인적으로 이런 개발자가 되고 싶다! 하는 모습이 있을까요?
최수현: 개발 초기에 영향 범위를 예측하는 부분이 어렵기도 하고, 또 잘하고 싶은 부분이에요. 캐치테이블 서비스가 많은 기능을 가지고 있다 보니, 본래의 기능을 유지하며 새 기능을 넣기 위해 설계가 매우 중요하다는 것을 느꼈어요.
예로, 팔로우 기능을 개발할 때 아래와 같은 기능을 추가했어요.
0. (기존) 팔로우 요청 시 바로 팔로우됨
1. 팔로우에게만 리뷰 공개 설정할 수 있음
2. 팔로우에게만 리뷰 공개 설정을 한 계정은 팔로우를 했을때 요청됨으로 처리됨
3. 요청됨인 경우 요청을 수락/삭제를 할 수 있음여기서 팔로우(팔로우 요청)를 할 수 있는 버튼은 서비스 많은 곳에 산재해 있었는데, 대표적으로 타임라인, 다른 사용의 프로필, 알림 페이지 등이 있었습니다. 때문에 많은 API 수정이 필요했고, 여러 페이지에서 노출되는 팔로우 버튼의 상태도 동기화해야 하는 이슈가 있었습니다.
처음에 개발을 시작하고 개발해야 하는 기능은 이해했음에도 위에 언급한 부분에 대해 인지는 하지 못했습니다. 이 부분을 같이 개발한 프론트 파트원께서 확인해 작업을 해주셨습니다.
그 과정을 보면서 초반에 해당 기능이 어디서 사용되고 있는지, 어떻게 관리되고 있는지, 전역적으로 관리가 꼭 필요한 부분인지, API 변경이 필요한 부분인지, 변경을 한다면 어떻게 하는 것이 최적인지 등을 꼼꼼히 미리 확인해야한다는 생각이 많이 들었습니다. 그를 토대로 설계를 해야 작업 일정을 맞추는 것도, 돌발상황에 대처도 더 잘 할 수 있다고 느꼈습니다.
김용래: 조직 내에서 영향력을 가지며, 팀에서 시너지를 낼 수 있는 개발자가 되고 싶어요. 언젠가 저와 함께 일했던 분들에게 “용래님이 계신 덕분에 편하게 일 할 수 있었어요.” 같은 평가를 받을 수 있다면 좋겠습니다.
마지막 질문입니다! 캐치테이블에서 이루고 싶은 목표가 있다면?
최수현: 단순하지만, “이거, 잘하는 사람 누구있지?” 했을 때 “수현님이 그거 잘해요.”라는 이야기를 듣고 싶어요. 아직은 배우고 있는 단계인데 조금씩 제 색을 찾아다 보면 A/B테스트나 로그, 네이티브 브릿지, 설계, 상태 관리 등 뭐가 될지 모를 “이거”를 찾을 수 있을 거라고 믿어요.
김용래: 우선은 기술적으로 성장하여 스스로 만족할 수 있을 만큼의 실력을 갖춘 개발자가 되는 것이 목표입니다. 이러한 성장을 토대로, 캐치테이블을 더 안정적이고 견고한 서비스로 만들고 싶어요. 지금도 MAU가 많은 편이고, 앞으로도 더더더 많아질 서비스인 만큼 이러한 안정성이 굉장히 중요한 가치를 가질 것으로 생각합니다.
미래에 두 분이 만들어 갈 캐치테이블은 어떤 모습일지 정말 기대되는 인터뷰였습니다! 앞으로도 캐치테이블이 더 멋진 서비스로 거듭날 수 있길 바라봅니다.
