pxd people | "믿고 맡기는 개발자이고 싶어요"
문득 이런 생각이 드는 때가 있어요. ‘이 사람 자기 일을 정말 좋아하는구나.’ 일 얘기를 하면 유난히 빛나는 눈, 평소보다 세 배는 더 빠르게 쏟아내는 말, 편히 기댄 등을 떼고 바짝 당겨 앉은 자세 같은 것을 발견할 때죠. 그런 반짝이는 순간을 또 보고 싶어서 괜히 다가가 일 얘기를 꺼내기도 하는데요. 구성 요소를 ‘녀석'이라고 부르는 개발자를 만났을 땐 [pxd people] 인터뷰를 요청할 수밖에 없었어요. “이건 손이 좀 많이 가는 녀석인데요.” “저 녀석은 빠르게 나올 수 있어요.” 업무를 가리키며 이토록 아기자기하고 정겨운 단어를 쓰는 사람에게 듣는 개발 얘기는 얼마나 재밌을까요. XE 그룹 2팀 팀장이자 프론트엔드 개발자 김태용 님과 나눈 대화를 들려드릴게요.
Q. 태용 님 반갑습니다! 먼저 자기소개를 할 차례인데요. 생각할 시간이 필요하다고 하셨으니(웃음), 현재 하고 있는 일에 대해서 소개해 볼까요?
일단은 프론트엔드, 브라우저에 보이는 모든 것들을 작업하고요. pxd에서 우리 그룹은 ‘XE(eXperience Engineer)’라고 이름 지은 만큼, 개발로써 더 나은 사용자 경험을 만들어 가는 일을 한다고 생각해 주시면 좋을 것 같아요.
Q. 프론트엔드 개발 작업은 주로 어떻게 이뤄지나요?
pxd에서는 기본적으로 HTML을 사용해요. 웹의 기본 뼈대가 되는 언어라고 볼 수 있어요. HTML을 통해서 화면에 보이는 요소들의 의미를 부여해 주죠. 얘는 제목이야, 쟤는 본문이야, 이렇게요. 그 뼈대에 살을 붙여서 모양을 꾸미는 게 CSS예요. 색깔, 크기 등 모든 것을 포함하죠. 이렇게 뼈와 살을 완성했다면 Java Script는 ‘어떻게 움직일지' 기능을 입혀줘요. 팔은 이렇게 뻗고 걸을 땐 이렇게 발을 딛는 거야, 라고 움직이는 방법을 알려주는 녀석이죠. 그 외에도 React, Next.js 등이 있어요.
기획과 디자인이 완료된 후 그 결과물을 가지고 개발하기보다는, 앞선 단계에서 다른 분들과 함께 개발적인 이야기를 나누면서 진행하는 작업을 지향하죠. 반응형에서 어떻게 브레이크 포인트를 줄 것인가, 어떤 기술을 적용해 볼 것인가 등 계속 이야기를 나눠요. 그렇게 진행한 프로젝트는 과정 자체가 스무스했을 뿐 아니라 결과물도 만족스러워요.
Q. 각 영역을 철저히 나누는 분업보다는 기획, 디자인, 개발의 협업을 중요시한다고 볼 수 있겠네요.
분업이라면, 개발자들끼리 적절히 업무를 분배하는 방식으로 이뤄져요. 예를 들어, A 프로젝트가 바쁘게 진행돼요. 그럼 미리 일정을 고려해서 B 또는 C 프로젝트에 참여하고 있는 사람 중 비교적 일정이 여유 있는 사람들을 A 프로젝트에 투입시키는 거죠. 둘이서 야근할 일이라면, 셋이서 야근 없이 일찍 마치자는 주의예요.
Q. 뭔가 개발자라면 야근을 많이 한다는 선입견이 있었는데, 오히려 반대였군요.
실제로 저희는 불가피할 때를 제외하고 야근을 거의 하지 않아요. 워라밸이 정말 중요하다고 생각해서 포기할 수 없어요(웃음). 습관적인 야근은 업무를 루즈하게 만들고 효율이 떨어지면서 다시 또 야근하게 되고, 이런 악순환은 반복된다고 생각해요. 그래서 최대한 야근을 지양하고 있어요.
또 로테이션 제도를 활용하고 있어요. 3개월 주기로 프로젝트를 바꾸는 거죠. 작업자가 어느 한 곳에 매몰되어 있지 않고 다양한 작업물을 경험할 수 있게끔 하는 제도예요. PL도 마찬가지로 로테이션을 통해, 모두 돌아가면서 프로젝트를 리드하는 경험을 해볼 수 있게 해요. 17명 중 주니어를 제외한 10명 전부 PL 경험이 있을 정도죠.
Q. 업무 환경이 뒷받침하지 않으면 힘든 일일 것 같아요.
일단 코드 퀄리티 관리가 잘 돼야죠. 누가 봐도 간결하고 이해하기 쉬워야 해요. CSS 같은 경우에는 클래스 명만 봐도 ‘얘는 무슨 모양의 녀석이구나.’라고 예상할 수 있는, 그런 것들이 코드 퀄리티를 결정짓죠.
프로젝트를 한 번 내놓으면 끝이 아니고, 계속해서 성장시켜야 하니까요. 다음에 제가 또 하거나, 제가 아니더라도 누군가 프로젝트에 들어와서 일을 할 때 꼭 필요해요. 또, 업무 로테이션을 하다 보면 여러 사람의 손을 거치기 때문에 더 코드 퀄리티 관리에 신경 쓰는 부분도 있고요.
Q. 그런 제도를 이상적이라고 생각하면서도, 여러 요건 때문에 실천하기 어려운 조직들이 많을 것 같아요. 사공이 많아도 배가 산으로 가지 않는 비결이 있다면요?
내부 컨벤션*을 두고 어느 프로젝트든 동일한 환경과 스타일을 기준으로 작업하고 있어요. 작업의 성격을 분류해서 오랜 히스토리를 파악해야 하는 업무를 제외하고 빠르게 나눠서 할 수 있는 작업들을 여러 동료에게 전달하죠. 어느 날 아침 갑자기 “너 오늘부터 이거 해.”하는 건 아니고 (웃음) 그전부터 PL과 준비를 하고 있다가 투입하는 거죠. 개발자는 아무래도 일정상 조금 뒤에 있는 포지션이다 보니까, 기획이나 디자인 단계에서 하고 있는 프로젝트를 어느 정도 예상하고 미리 준비할 수 있는 부분들이 있어요.
*Code Convention: 일종의 코딩 스타일 규약. 읽기 쉽고 관리가 용이하다. 불필요한 의사결정 과정을 줄여 작업자가 효율적으로 유연성과 창의성을 발휘할 수 있도록 돕는다.
Q. 구성원끼리 지속적으로 활발히 소통한 덕에 가능한 일처럼 보여요. 회사에서 XE 그룹분들이 서로의 상황을 공유하는 장면을 많이 목격하기도 했어요.
업무 분배를 위해서는 적극적인 소통이 필요하죠. 우선 매일 아침 스크럼을 진행하고 있어요. 이슈가 있다면 공유하고, 잡담도 나눠요. 각자 일하다 보면 하루 종일 대화 한 마디 없이 회사에 있다가 퇴근하는 경우도 생기니까, 서로 짧게나마 대화할 수 있는 시간을 마련한 거죠. 오후 5시에는 일일 업무 보고를 하는데요. 오늘 한 일과 내일 할 일, 예정 출퇴근 시간 정도를 공유해요. 바로바로 얘기가 필요한 일은 따로 또 공유하는 편이고요.
Q. 기술 블로그를 통해 지식을 나누는 것도 ‘다 같이 편하자'는 분위기의 연장선에 있는 걸까요.
다른 분야에서 누군가 내 창작물을 갖다 썼다고 하면 화를 내는데, 개발자는 누가 “네 코드 갖다 썼는데 좋더라”라고 말하면 “그거 내 코드 아닌데?”라고 말하는, 유명한 밈도 있어요(웃음). 개발자끼리 서로서로 정보를 공유하며 다른 사람의 코드를 활용하거나, 내가 쓴 좋은 코드가 있다면 누구든 가져다 쓰거나, 그런 자유로운 분위기인 것 같긴 해요. 누군가 잘 짜놓은 코드를 가져다가 붙여 넣으면, 그만큼 절약한 시간을 다른 데에 쏟아 좋은 결과를 낼 수 있으니까요.
Q. 다른 직군과 협업하는 경우도 많은데, 개발자와 더 잘 소통하고 싶은 비개발자를 위한 팁이 있다면요?
사람마다 다르겠지만, 명확한 인풋이 있을 때 아웃풋이 명확히 나올 수 있는 것 같아요. 다양한 경력을 쌓으며 넓은 시야를 가진 개발자들이 많은 만큼 꼭 개발적으로 얘기할 필요는 없지만, 두루뭉술하게 대략적인 느낌을 설명하기보다는 원하는 바를 분명히 전달하는 게 좋을 것 같아요. 개발자들은 자부심이 높기 때문에 이 점을 적절하게 이용하면 어렵다고 생각했던 결과물을 구현해 낼 수도 있을 거예요(웃음).
Q. 태용 님도 개발자가 되기 전에는 디자인을 하셨다고 들었어요.
처음엔 웹 디자이너였어요. 디자인을 하다 보니 개발 쪽과 많이 부딪쳤는데, 자꾸 요청한 대로 안 된다고 하니까 ‘그럼 내가 한번 해본다.’라는 마음도 조금 있었어요(웃음). 이후 퍼블리셔로 3~4년 정도 경력을 쌓았는데, 코딩한 대로 결과가 나온다는 점이 매력적으로 다가왔어요. 명확한 답이 있다는 점이요. 데이터 바인딩까지 경험할 기회를 얻으면서 데이터를 컨트롤하는 업무에도 관심이 생겼어요. 그러다 “브라우저에서 보이는 모든 것들을 해보자.”라는 결심이 서서 프론트엔드 개발로 명확한 방향을 잡고 나아가기 시작했죠.
이젠 과거에 ‘안 된다'고 했던 개발자의 입장을 이해하기도 해요. 이런 이유, 저런 사정으로 안 된다고 얘기했구나…알게 됐죠. 안 된다는 게 실제로 ‘불가능한 일'은 아니라고 생각해요. 다만, 일정에 맞춰 어느 정도 효율적으로 구현할 것인가, 최고의 성능을 낼 수 있게 할 것인가 등 여러 가지를 종합적으로 고려할 때 지향하지 않는다는 방향성이 있을 뿐이죠.
Q. 디자이너로서의 경력이 개발할 때 도움이 되는 경우도 있을 것 같아요.
어느 정도는요. ‘디자이너가 어떤 인터랙션을 생각하며 이렇게 그렸을까?’라는 생각을 하면서 작업하려고 해요. 예를 들어 ‘사용자와 브라우저가 더 밀접하게 인터랙션하는 것'이 의도라면, 요청받은 작업 외에도 그 의도를 달성하기 위한 방법을 고민하고 제안해 보는 거죠. 화면상 눈에 보이는 것뿐 아니라, 그 너머 작업자의 의도를 파악하고 이해하면서 세세한 부분을 챙기려고 하는 편이에요. 디자이너분들의 입장을 또 들어봐야 알겠지만요(웃음).
Q. 직무를 전환하며 느낀 ‘개발자에게 꼭 필요한 역량’이 있다면 무엇일까요?
누군가 “만사 귀찮아하는 개발자가 개발을 잘한다.”라는 말을 했는데, 공감이 많이 됐어요. 귀찮기 때문에 최소 비용으로 최대한의 퍼포먼스를 뽑아내는 사람들이 있잖아요. 개발자에겐 꼭 필요한 부분이죠. 좋은 것 하나를 만들어서 여러 군데 두루 쓸 수 있으면 편하니까요. 또 호기심도 필요한 것 같아요. 작업을 하다 보면, ‘이게 되네? 근데 왜 되는지는 모르겠다.’ 이런 경우가 종종 있거든요. 그냥 넘어가는 사람도 있을 거고, 왜 그런지 궁금해하면서 파고드는 사람도 있을 거예요. 아무래도 후자가 업무 능력이 빨리 향상되죠.
Q. 개발자는 계속 새로운 언어나 기술을 공부해야만 한다고 들었어요.
“개발자는 늘 공부하며 살아야 한다.”라는 말이 있어요. 사람마다 다르겠지만, 저는 뭔가 새로운 것이 나왔을 때 직접 부딪쳐 보는 걸 좋아해요. 공부할 땐 관련 공식 문서를 주로 참고하는데요. 문서를 토대로 코드를 짜고 내가 짠 코드가 어떤 식으로 동작하고 표현되는지 확인하며 공부하는 거죠. 코드는 다르지만, 기존에 제가 알던 방식과 비슷하게 구현되는 것도 있고 완전히 새로운 기능도 있어요. 그런 것들을 알아가면서 동시에 깃허브, 개인 블로그 등을 참고하며 많은 정보를 모아요.
어떤 기술이 지금 당장 필요 없어 보일지는 몰라도, 기회가 생긴다면 직접 사용해 보는 게 좋은 것 같아요. 해보지도 않고 지레 별로야, 싫어, 하는 것보다는 해보고 나서 이 기술을 앞으로도 가져갈 것인지 아닌지 판단하는 거죠.
Q. 태용 님이 개발자로서 pxd를 택한 이유는 뭐였나요?
2019년 가을 무렵 현재 XE 그룹장이신 강재삼 님을 따라 합류하게 됐죠. 그룹장으로서 그룹원을 굉장히 많이 챙겨주시는 분이라는 게 느껴져요. 실제로 정도 많으시고요(웃음). 소위 사람 대우를 받을 수 있는 환경도 좋았어요.
사람이 ‘사람'으로서 존중받지 못하는 환경이 더러 있잖아요. 예를 들면, 딱 1년 만에 그만두고 나왔던 제 첫 회사는 휴가도 제대로 쓰기 어려웠고, 직원들이 며칠 내내 철야를 하든 말든 무조건 일정을 밀어붙이는 분위기였어요. 아침 8시에 출근을 하면, 회사 문을 잠갔죠(웃음). 소속 팀장에게 승인을 받아야만 나갈 수 있었어요. 공식적인 근무 시간은 9 to 9이었고요. 아무것도 모를 때니까, ‘IT 업계는 다 이렇구나.’라고 생각했었죠. 사실은 잘못된 건데도요.
Q. 그랬던 사회초년생이 이젠 어엿한 팀장이 됐어요. 팀원들을 리딩하는 입장에서 부담스러운 점은 없으신가요?
우리 그룹에선 리딩하는 사람에게 많은 숙제가 주어져요. 야근을 지금보다 더 줄이기 위한 방안을 고민한다든지, 우리 팀원의 개발 기술을 향상시키기 위한 방법을 찾는다든지, 하는 것들이요. 굉장히 어렵지만, 우리의 발전을 위해서 필요한 숙제들이에요. 부담감과 스트레스가 없다고 할 수 없지만 헤쳐 나가야죠. 그렇다고 막 혼자 끙끙거리며 숙제를 해내야 하는 것은 아니에요. 보통 매니저들이 함께 얘기하며 초안을 잡아 나가는 시간이 있죠. 제 개인적인 성향으로는 누군가를 리드하고 이런 일이 잘 맞지 않는다고 생각하지만, 그것과 별개로 팀장으로서 해야만 하는 일들이기에 노력하고 있어요.
성향상 먼저 말을 붙이기 어려워하고 누군가 말을 걸어야 대답을 하는 분들도 있죠. 저는 누군가를 억지로 끄집어내기보다는 자연스럽게 가까워지기를 기다려요. 사적으로 가깝지 않다고 해도 업무에 지장을 주는 건 아니니까요. 함께 시간을 보내면서 서로 마음을 열게 되면 그때 농담도 주고받고 장난도 치는 거죠.
Q. ‘함께, 일하는 것'이 확실히 중요하네요. 일 안팎으로 함께하는 게요.
우리 그룹이 정말 중요하게 생각하는 부분이죠. 가끔 채용 인터뷰 때 원하는 인재상에 대해 묻는 분들이 있는데, 그럴 때마다 항상 ‘함께 성장할 가능성’을 본다고 말씀드리곤 해요. 채용 과정에서 모든 능력치가 다 뛰어났는데도 결정적으로 ‘이 사람을 꼭 뽑아야겠다.'라는 생각이 들지 않는 경우도 있었어요. 우리와 함께할 때 시너지가 날지 확신이 서지 않았던 거죠. 지금 당장의 능력보다 더 중요하다고 생각하는 기준들이 있기 때문이에요. 이 사람이 어떤 생각을 갖고 있는지, 그 생각이 우리가 가고자 하는 방향과 같은지, 잠재력은 어느 정도인지, 그 잠재력을 발휘하며 함께 성장할 수 있는지.
Q. 태용 님은 어떤 개발자이자 동료가 되고 싶으신가요?
롤 모델이 따로 있지는 않고, 프론트엔드에 있어서는 안 되는 게 없는 사람. ‘쟤한테 맡기면 문제없어.'라고 생각할 수 있는 사람을 목표로 삼고 있어요. 보통 이런 이야기를 하면 ‘풀 스택 개발자’를 지향하는 분들이 많은데요. 저는 그보다는 현재 맡은 업무인 프론트엔드에서의 스페셜리스트가 되고 싶어요
Q. 잠시 미뤄뒀던 자기소개를 해주실 시간이에요!
농담 반 진담 반으로 맨날 아내에게 얘기하거든요. “내가 전업주부 할게. 네가 돈을 벌어와라.” 실제로 제가 집안일을 더 잘하기도 하고요(웃음). 저는 전업주부의 꿈을 가지고 있는, 하지만 이왕 개발을 할 거라면 완벽하게 해야겠다고 생각하는 프론트엔드 개발자입니다.
글. 임현경 - UX Writer
그림. 이원용 - Experience Designer