목록으로
들어가며
유남주(가명)님은 2년 차 프론트엔드 개발자입니다. 제가 작성한 이력서 작성에 대한 글을 읽고 이력서를 고쳤는데, 어딘지 모르게 마음에 들지 않아 고민이라 합니다. 주제는 '사용자가 겪는 문제를 해결해 사용자 경험을 개선하는 개발자'인데, 구체적이면서도 막연한 느낌이 들었습니다. 뭐가 문제일까요? 이력서에 적힌 주제는 잠시 덮어두고, 유남주님에게 경험담을 들었습니다.
대화, 웃음, 대화, 질문, 질문, 질문, 질문, 질문, 잠시 고민.30여 분 동안 이야기를 나눴습니다. 또렷하진 않지만, 유남주님의 경험들을 관통하는 무언가 있었습니다. 함께 들여다볼까요?
멘토링
고객에게 전달할 가치의 근원
이력서 경력란 가장 앞에 배치된 경험 항목은 코드를 리팩터링하여 고객 피드백에 대한 대응력을 높인 내용입니다.
“
컴포넌트 구조를 개선하여 대응력 향상
”
“유남주님, 이 작업은 왜 한 거예요?”
“네? 그야 이력서에 쓴 바와 같이...”
“컴포넌트가 재사용되지 못한 채 늘고, 비즈니스 로직이 컴포넌트마다 제각기 구현되어 혼란이 야기된 걸 보며 왜 리팩터링 해야겠다고 생각했는지 물어보는 거예요.”
“아~ 흐음. 그러게요. 왜 하던 일도 있던 상황에서 저 일을 하고 싶었던 거지?”
유남주님은 생각에 잠겼습니다. 잠시 후 그는 기존 구현체에 구현에 관한 맥락이 있고, 비슷한 로직을 담고 있는 컴포넌트가 산개해있었지만, 다른 관점에서 보면 미세하게 비즈니스 로직이 다르다는 걸 개별 컴포넌트가 나타내는 것이라 했습니다.
“그렇군요. 그래도 왜 리팩터링을 한 것인지 답이 되지 않아요. 새로 구현할 수도 있었잖아요”
“점진적으로 적용하는 게 중요하다 생각했어요. 기존 구현체엔 테스트 코드가 없어서 코드를 바꾸는 게 부담스러웠거든요. 그래서 손이 여러 번 가더라도 점진적으로 리팩터링 하는 게 좋겠다고 생각했어요”
“그럼 왜 점진적으로 진행한 거예요?”
“사용자가 저희 서비스를 사용하는 경험을 조금이라도 해치고 싶지 않았어요. 저희 프로젝트는 B2B 서비스여서 사소한 것이라도 의도대로 동작하지 않으면 사용자들이 불편해져요. 특히 저희 프로젝트를 사용하는 사용자들의 직군 특성 상 성과급 받을지 여부가 중요한데요. 저희가 작은 것이라도 안일하게 구현하면 누군가의 성과급에 영향이 미칠 수 있어요”
“유남주님 기준으로 놓고 봤을 때, 사용자 경험을 해친 상황이란 구체적으로 무엇인가요? 사례를 들어주시겠어요?”
그는 잠시 고민합니다.
“사용자의 피드백은 결국 저희 기획에 반영되어 개발로 전달되는 것이니까... 기획 의도와 목적에 부합하는 가치가 조금이라도 훼손된 채 사용자에게 전달되는 것이 사용자의 경험을 해치는 거라고 생각해요”
유남주님이 사용자가 겪는 문제를 해결해 사용자 경험을 개선한다는 말이 어떤 의미인지 이제야 이해됩니다. 그리고 이력서 주제, 즉 유남주님이 어떤 사람인지 설명하는 핵심말(keyword)이 나온 것 같습니다. 아직 확신은 이르니 좀 더 이야기를 나눠봅니다.
고객이 겪게 될 문제에 공감하다
두 번째 프로젝트는 문서화에 관한 내용입니다.
“
비즈니스 로직을 문서화하여 협업과 소통의 질에 기여
”
유남주님 말로는 이 작업에 일주일이 걸렸고, 순 투입 시간은 2일이라고 합니다. 시간이 꽤 걸렸다 생각했는데, 목차를 보니 생각보다 훨씬 분량이 많았습니다. 게다가 작업엔 일주일이 걸렸는데 순 투입 시간이 2일이라는 건 다른 업무와 병행했다는 뜻이지요.
“문서화 작업하면 좋긴 하지만 그 당시 우선순위에서 그리 높은 건 아니었을텐데, 그렇게까지 열심이었던 이유는 뭐예요?”
“개발하면서 비즈니스 로직에 논리적인 모순이나 오류가 빈번히 발생했어요. 가끔 QA 할 때 비즈니스 로직을 헷갈려서 문제없던 구현을 문제 있게 고치기도 했어요. 비즈니스 정책이 변경되거나 추가되면 야근을 종종 했고, 야근을 했는데도 일정이 지연되기도 했죠. 그래서 비즈니스 로직을 고치는 걸 개발팀은 부담스러워했고, 고쳐야 하는 사실에 예민해지기도 했어요”
“아~ 그럼 문서화 작업한 이유는 개발팀이 안전하고 효율성 있게 협업하게 하기 위해서예요? 그럼 왜 개발팀이 비즈니스 로직에 대해 안전하고 효율성 있게 협업하도록 한 거예요?”
이번에도 유남주님은 잠시 조용해지며 깊이 생각합니다.
“그 당시에 제가 가장 스트레스 받는 요인은 일정 지연이었어요. 똑같은 실수, 똑같은 시행착오를 되풀이하며 일정이 지연되는 게 너무 괴로웠어요.”
“왜요?”
“약속된 일정에 변경 사항을 고객에게 전달하지 못하면 고객에겐 원래 계획에 차질이 생기는 거예요. 고객이 기대하는 걸 적시에 그대로 전해야 저희가 제대로 일하는 거라 생각해요”
“좋아요. 그럼 말이죠. 일정을 어긴 것이 동인인가요, 아니면 고객이 계획에 차질이 벌어지는 게 동인인가요?”
유남주님은 같은 것 아니냐고 조심스레 반문했습니다. 자기인지(메타인지, meta cognitive)가 어려운 이유 중 하나는 미처 인지하기도 전에 우리 뇌가 빠르게 판단하고 처리해버리는, 즉, 암묵지가 작용하기 때문입니다. 암묵지를 말과 글의 영역으로 끌어와 다른 사람도 인지할 수 있게 실체화해야 하는데, 끌어올 고리를 찾지 못해 더듬거리다 포기하기 일쑤지요.
“일정을 어길 때 밤에 잠못잘 것 같나요, 아니면 유남주님으로 인해 고객의 계획에 차질이 생길 때 밤에 잠못잘 것 같나요? 둘 중에 비교해서요.”
유남주님은 고민 후 고객의 계획에 차질을 일으킬 때라고 대답합니다. 이제 꽤 그 무엇이 모습을 드러냈습니다.
지속가능한 엔지니어링
“
성능을 최적화하여 고객의 사용자 경험을 증진
”
신입이나 주니어 개발자의 이력서에 등장하는 표현인 최적화는 채용담당자의 먹잇감이 되기 십상입니다. 답이 있는 게 아니라 소신이나 철학을 바탕으로 토론을 해야 하는 주제거든요. 게다가 그 소신이나 철학이 경험에 바탕할수록 유리한 경우가 많습니다. 비슷한 성격을 띠는 주제로 클린 코드, MSA(Micro Service Architecture), 디자인 패턴, TDD(Test Driven Development), 애자일 등이 있습니다.
유남주님은 분명 최적화하여 성능을 개선했습니다. 문제는 왜?(why) 굳이 그때?(when), 투입 비용 대비 가치가 있는가?(what)에 대해 납득할만큼 설명하느냐 지요.
“남주님”
유남주님은 이제 익숙하다는 듯이 자신만만하게 미소 짓습니다. 음, 그거 물어보려는 거 아닌데.
“최적화할 요소가 여럿 있었을텐데, 성능 최적화는 몇 번째에 한 거예요?”
예상한 질문이 아니여서 그런지 유남주님이 조금 당황하며 가장 먼저 수행했다고 대답합니다.
“사용자 경험을 개선할 최적화 요소가 여럿 있는데, 왜 성능 최적화를 가장 먼저 한 거예요?”
느리고 버벅대면 사용자 경험이 좋지 않다는 걸 제가 질문하는 의도가 아니라는 걸 파악한 유남주님이 고민에 빠졌습니다. 이번엔 고민이 깁니다. 조금 도와줘야겠습니다.
“남주님, 성능 최적화를 하기로 결정하기 전에, 어떤 얘기가 오갔나요?”
“사용성이 좋지 않은 페이지를 리뉴얼하기, 새로운 기능 추가, API 응답 속도 개선, API 스펙을 바꿔서 호출 빈도 줄이기 등 여러 의견이 나왔어요.”
“분위기는 어땠어요?”
유남주님 말로는, 팀장님이 소집한 회의여서 다들 참여하긴 했지만, 언젠가는 할 수 있을지 몰라도 당장 할 수 없는 현실때문에 아무도 나서지 못했다고 합니다. 어떡해서든 사용자 경험을 개선하고 싶었던 유남주님은 좋은 방법을 떠올렸으니, 그게 바로 이력서에 명시한 것들이었습니다. 작업 자체는 간단한 것이지만, 효과는 좋았습니다. 즉, 효과와 효율이 좋게 공학적(engineering)으로 문제를 정의하고 해결하여 좋은 결과를 낸 것이지요.
“근데 원래 하던 일과 병행했다면 일정에 영향이 갔을 것 같아요.”
“일정도 지연되지 않고 모두 해냈어요. 제가 야근을 좀 하긴 했지만”
“그렇게까지요?”
“만약 일정에 영향이 가거나 사용자 경험 개선 정도가 미미했다면 시도하지 않았을 거예요. 일정 지연과 고객의 계획 차질 중 후자를 더 중요하게 여긴 것이지 일정을 지키는 게 중요하지 않는 건 아니예요. 하지만 기껏 비용 산정해서 우선순위를 정하고, 일정을 정해 지키는 것도 중요해요. 야근 없이 일정을 소화해야 팀이 지속가능하게 제품을 발전시켜나갈 수 있잖아요.”
“아하, 그러니까 일정이란 고객에게 빠르게 전달하는 속도와 팀이 안전하게 협업하는 속도 사이에서 중간값으로 정한 거라는 말이군요. 어느 한 쪽으로 기울면 고객이 겪는 문제를 해결하거나 가치를 전달하는 일을 지속가능하게 하지 못하고요. 비록 본인이 야근을 했을지언정”
“맞아요, 멘토님. 그리고 제가 하고 싶어서 한 일이라 며칠 야근하는 건 괜찮아요. 누군가를 돕는 기분도 들고요.”
유남주님이 다부지게 말했습니다.
“남주님, 2년차 맞아요?”
마치며
유남주님은 개인 프로젝트 경험담에서도 공통된 특성을 드러냈습니다. 이를 종합하면 다음과 같습니다.
-
일정
-
엔지니어링 관점
-
공감
-
누군가를 돕기
유남주님이 일정을 바라보는 관점은 고객이 겪고 있는 문제를 해결하는 데 있습니다. 무작정 짧은 일정을 설정해 빠르게 해결하지 않는 이유죠. 팀이 지속 가능하고 건강하게 고객이 겪는 문제를 처리하려면 고객과 팀 간 일정에서 균형점을 찾으려 애썼습니다.
유남주님에게 프로그래밍은 고객이 겪는 문제를 해결하는 방법 중 하나였습니다. 프로그래밍 기술이나 도구도 마찬가지였어요. 예를 들어, 유지보수하기 좋은 코드를 작성하려 공부하는 목적은 그래야 고객이 겪는 문제를 해결하기 좋기 때문인 거죠. 이 정도로 고객, 고객하는 주니어 개발자는 처음이었습니다. 대화를 더 나눠보니 다른 이에게 향한 공감력이 크고, 프로그래밍이 아니더라도 다른 이를 돕길 좋아한다는 걸 깨달았습니다.
공감과 누군가를 돕고자 하는 마음을 주제문에 녹여내긴 쉽지 않습니다. 그래서 주제문엔 일정과 엔지니어링을 추가해봤습니다.
-
바꾸기 전 : 사용자가 겪는 문제를 해결해 사용자 경험을 개선하는 개발자
-
바꾼 후 : 고객이 겪는 문제를 공학적 관점과 방법으로 해결해 사업적 실행과 가치에 기여하는 개발자
유남주님은 자신의 특성이 프로그래밍에서도 발현되는 걸 몰랐다고 했습니다. 다들 원래 그렇게 일하는 것이라 여겼던 거죠. 주변에서 책임감이 강하다고 해서 그렇게 여겼다고 합니다. 멘토링 받은 덕에 자신을 좀 더 알게 된 것 같다며 좋아합니다. 자신을 더 알게 됐으니 이력서가 더 나아지겠군요.
뿌듯합니다.
🚨 본 컨텐츠에 등장하는 인물 중 글쓴이를 제외한 모든 인물의 이름은 가명이며, 지명, 시간, 단체나 기관, 사건은 각색하고 창작하였습니다. 일부라도 비슷하거나 겹치는 경우는 우연히 일치하는 것이니 이 점, 양지해주시길 바랍니다. 🚨
푸딩캠프 뉴스레터를 구독하면 학습과 성장, 기술에 관해 요약된 컨텐츠를 매주 편하게 받아보실 수 있습니다.