첫인상을 결정짓는 조용하고도 뚜렷한 손길, 작은 화면 속에서도 사용자의 길을 놓치지 않는 개발자 유승현의 이마고웍스 라이프

저는 학창시절에 화학만 바라보며 살았었어요. 대학교 학과도 다 화학과로 지원하구요. 눈에 보이는 변화가 재밌어서 화학 실험이 좋았거든요. 그랬던 제가 생각이 점차 바뀌게 된 계기가, 대학시절 제가 있던 자연과학대는 모든 실험을 수기로 작성했어야 했어요. 저는 그게 비효율적이라고 생각했던것 같아요.

진로 고민까지 겹쳤던 와중에 우연히 웹 프론트엔드 수업을 들었는데 ‘이거다!’ 싶었어요. 개발자는 효율적인 걸 추구하는 것 같았고, 프론트엔드는 시각적인 변화까지 있으니까요. 그 수업을 계기로 전과를 신청하고 이렇게 지금 이마고웍스까지 오게 되었네요.

맞아요. 이번달로 입사 3주년이 됐어요!! 인턴까지 하면 좀 더 될 거예요. 처음 이마고웍스를 마주했던 때가 잘 기억이 나질 않아서, 제가 인턴당시 썼던 블로그를 보고왔어요. (웃음)

가장 크게 다른점이 있다면 인원이 2배가 되었다는 점이에요. 제가 왔을 때는 50명이 조금 넘었는데, 이제는 100명을 넘어섰어요. 그렇게 사람이 많아지면서 서비스도 복잡해지고 다양해졌네요!

그때는 하나의 목표를 가지고 모두가 달려나갔다면, 지금은 각자의 목표에 집중한다는 점이 제가 입사했던 때와 다르게 느껴지는 점인 것 같아요.

어려운 질문이네요. 아직도 계속 배워나가는 입장이지만 요즘 저의 개발의 기준은 ‘사용자’ 라고 생각해요. 

말씀해주신 것처럼 개발을 하다 보면 기능을 나눌 때 어디까지가 개발 로직이고, 어디까지가 비즈니스 로직인지 고민될 때가 많거든요. 그런데 그 경계가 애매할수록 ‘사용자 입장에선 어떻게 보여야 할까?’ 를 기준으로 판단하니까 문제가 생각보다 쉽게 풀린다는걸 느꼈어요.

결국 개발자는 현실의 문제를 코드로 해결하는 사람이거든요.

저는 중도를 지키는 개발을 지향해요. 추상화를 많이 하면 팀원들이 코드를 읽기 어렵고, 너무 단순하면 유지보수가 힘들어지잖아요. 

그래서 오버 엔지니어링을 피하면서도 관심사를 분리할 수 있는 구조를 항상 고민하는 것 같아요. 화면을 만들 때도 컴포넌트를 단순히 많이 쪼개는 것보단 '어디까지가 재사용될 것인가' 를 기준으로 나누려고 노력해요.

그런데 중도를 지키려면 필연적으로 한쪽으로 치우쳐져 봐야 아는 것 같아요. 흔히 시행착오라고 부르는, ‘이렇게 짜니까 별로더라’ 라고 생각되는 경험이요. 시간이야 좀 걸리겠지만 이런 과정이 코드에 설득력을 더하는 과정이라고 생각해요.

자유롭게 공유하는 분위기나 문화를 만드는 게 중요한 것 같아요. 

저는 예전엔 고민이 있어도 문제를 혼자서만 해결하려는 습관이 있었는데, 저희 팀이랑 함께하면서 이런 고민들이 많이 해소되고 좋아졌어요. 혼자서는 하루 이상을 고민했던 문제나 정답이 없던 문제들을 팀원들에게 털어놓았을 때 고민했던 시간들이 무색할 정도로 문제가 쉽게 해결되는 경험을 종종 했거든요. 

여러 사람들의 다양한 경험이 합쳐지면 최적의 결정을 빠르게 내릴 수 있다는 걸 여실히 느꼈어요. 다만 이런 공유가 가능하려면 전제 되어야 하는 조건이 있어요. 내 의견이나 고민이 받아들여질 수 있다는 팀원간의 신뢰와 존중이 있어야 가능한것 같아요.

저희 팀은 사소한 것이라도 내 문제를 해결하듯이 같이 고민해주거든요. 그 부분을 너무 감사하게 생각하고 있어요.

저희는 ‘지라’ 라는 협업툴을 사용하는데, 그중 ‘변경점’ 이라는 기능으로 피드백을 반영해요. 

개발을 하다보면 기획, 디자인 단계에서 미처 생각하지 못한 예외사항이라던지 개발자의 시선으로 보이는 에러 처리 같은 것들이 반영되었으면 좋겠다고 생각하는데요. 그런 부분을 발견했을 때 기존 흐름에 변경이 생기거나 다른 직무의 구성원분들도 아셔야 될 경우에는 변경점 티켓을 만들어요. 

이렇게 해당 프로젝트의 PO, 기획, 디자이너, 개발자, QA분들의 합의를 거쳐 변경들이 적용되고 있어요. 변경점 기능을 잘 활용해서 관리하면 히스토리를 추적 관찰하기도 쉽고 티켓 관리도 자연스럽게 연동돼서 좋은 것 같더라고요.

질문을 듣자마자 Auth SDK가 바로 떠올랐어요. 이건 고객들에게 보여지는 서비스는 아니고 내부 기능의 한 조각인데요. 

우리 덴트버드 솔루션에 로그인하면 로그인한 상태로 클라우드, 크라운, 모델러 등 각 솔루션으로 자유롭게 이동할 수 있잖아요?

이게 개발적으로는 솔루션을 이동할 때마다 사용자가 권한을 갖고 있는지를 확인하는 ‘인가' 라는 과정을 거쳐야 하는데, 이 부분이 처음에는 각 프로젝트에서 개별적으로 개발되고 있었어요. 동일한 기능을 각각 개발하니까 일관성도 사라지고 유지보수도 어려워졌죠. 그래서 이걸 하나로 관리할 수 있는 개발 키트인 Auth SDK를 만들게 됐어요. 각 팀에서는 이 SDK를 쓰면 권한 관리는 신경 쓰지 않고 각 팀의 기능 개발에만 집중할 수 있거든요!

저한텐 이 프로젝트가 큰 도전이자 성장의 디딤돌이었는데요. 개발을 하면서 어려움도 많았지만 기술적으로도, 소프트스킬도 많이 성장할 수 있었어요. 그래서 기억에 남습니다.

요즘 제과제빵 학원을 다니고 있어요. 어릴 때부터 베이킹하는걸 좋아해서 빼빼로 데이나 발렌타인데이때 초콜릿을 만들어주는게 취미였거든요. 중학생 때는 요리대회에 나가서 상도 탔을 정도로 진심이었답니다?

언젠가 독학 말고 제대로 배우고 싶다는 막연한 소망이 있었는데, 올해부터 본격적으로 제과 수업을 듣기 시작했어요. 학원에서 만든 것들이 가끔 너무 많아서 회사에 들고 오는데, 동료분들이 맛있게 드셔주시는걸 보는게 요즘 가장 큰 행복이에요. 요리하는 사람들은 먹는 기쁨 보다 사람들이 맛있게 먹어주는걸 보는 기쁨이 더 크거든요.

요즘은 프론트엔드 아키텍처에 대해서 관심을 가지고 공부하고 있어요. 

AI가 들어오면서 개발 실력은 이미 인간을 뛰어 넘었는데, '우리가 대체되지 않을 부분은 뭘까?' 를 계속 고민해 왔거든요. 저는 그게 지식과 지식을 연결 짓는 능력인 것 같아요.

결국 개발자는 현실 세계의 문제를 코드로 푸는 사람이고, 도메인을 해석해서 팀과 제품 상황에 맞춰 아키텍처를 설계하는 건 사람의 영역이니까요. 그래서 요즘엔 FSD, DDD 같은 패턴을 공부하면서 저희 프로젝트 성격에 맞게 적용하려고 기존의 코드들을 활용해 이런저런 리팩토링을 시도해보고 있어요. 

비즈니스에 알맞는 적절한 설계를 제안할 수 있는 개발자가 되는게 목표입니다.

와 다들 저를 그렇게 생각해 주시나요? 너무 좋은데요?! 근데 리뷰에서도 그런말을 많이 받긴 했어요 하핫!

음... 저는 사람들을 좋아해서 사람들한테 관심이 많아요. 제가 아는 동료분들 MBTI는 다 외우고 있을 정도로요 ㅋㅋㅋ 사람들은 그걸 어떻게 다 기억하냐고 하는데, 제가 기억력이 좋은 건 아니고 그냥 관심이 많으니까 사람들의 행동을 보면 자연스럽게 떠오르는 것 같아요.

그런 것처럼 동료분들이랑 이런저런 대화를 하다 보면 자연스럽게 고민도 말하고 하잖아요. 이럴 때 제가 도움 드릴 수 있는 부분이나 먼저 경험한 것들을 말씀드리는 것 같아요. 아마 그 부분을 좋게 봐주시는 게 아닐까요?

저는 가장 가까운 사용자들을 마주하며 개발한다고 생각해요. 사내 프로그램인 백오피스나, 동료 개발자가 사용하는 Auth SDK 같은 산출물들은 우리 이마고웍스 멤버들이 사용하는 프로그램이거든요. 그래서 피드백도 바로 받을 수 있는 부분에서 만족감과 책임감을 같이 느끼고 있어요.

저는 관심 있는 분야가 많아서 백엔드도 배워보고 싶고, 3D도 공부해보고 싶고, 모바일 개발에도 관심이 깊어요. 올해부터 취미로 시작한 베이킹을 개발과 연결해 볼 수 없을까 고민하기도 하구요. 한편으로는 관심사가 너무 다양하게 퍼져 있어서 고민(관심사들끼리 연결 고리가 없거든요)이긴 한데, 언젠가는 점이 선으로 연결되는 순간이 오지 않을까 생각해요.