안녕하세요. 아이들나라플랫폼팀 장원익입니다
최근 아이들나라에서는 ‘엔터, 엔지니어들의 터놓는 시간’ 라는 특별한 활동을 주기적으로 갖고 있습니다.
바로 지난 ‘엔터’ 시간에는 우리가 원하는 동료상에 대한 이야기를 주제로 사내의 모든 엔지니어가 모여 이런 저런 이야기도 하며, 팀마다 원하는 동료에 대하여 정의를 하는 시간을 가졌습니다.
각 팀마다 모여 함께 일하고 싶은 동료에 대해 이야기를 하며, 동료들과 정말 많은 이야기를 하였고 저는 역시나 신나게 원하는 동료상에 대한 저의 의견을 펼치고 있었습니다.
~~ 하는 동료는 별로야, ~~ 하는 동료가 좋지 하면서 말이죠.
이렇게 활동이 끝나며 자리에 돌아가 앉아보며 이런 의문이 들었습니다.
그럼 과연 나는 내가 원하는 동료일까?
스스로에게 물어본 이 질문에 대한 답을 하기 위해 최근 저의 모습에 대해서 되돌아 보았는데요, 쉽게 답을 할 수 없었습니다.
나의 가장 최근 모습
우선 정말 바쁘고 정신 없던 최근 한달을 돌아보았습니다.
최근에 저는 이런 일들을 했었어요
•
아이들나라 회원 체계 개편
•
바우처(이용권)을 통한 기간 구독 상품 출시
제가 속해있는 아이들나라 플랫폼팀은 크게 2개의 도메인을 담당하고 있습니다. (회원-인증, 주문-구독)
저는 입사 이후 지금까지 주문-구독 파트에서 일을 하면서 어쩌면(?) 아이들나라 구독 도메인의 전문가가 되어있었죠.
하지만 팀 내의 도메인 로테이션에 의해 회원-인증 파트로 도메인을 옮기게 되었습니다.
처음으로 경험한 회원 파트의 “아이들나라 회원 체계 개편” 프로젝트
아이들나라 회원 체계는 다소 복잡한 구조를 띄고 있습니다.
아이들나라는 LGU+ 의 회원 체계와 와 강한 결합을 가지고 있었으며 독립적인 회원 체계를 갖기 위해 많은 노력들이 필요했습니다
이 작업은 리드급 엔지니어 한 분과 저 이렇게 2명이 진행했던 프로젝트입니다.
하지만 리드 엔지니어의 갑작스런 개인 사정으로 인해 QA 가 진행되는 시점에 휴직에 들어가게 되어 온전히 저 혼자 하나의 도메인을 맡아서 마무리 해야하는 상황이었죠.
여러모로 이 프로젝트는 저에게 있어 아주 의미가 컸습니다.
처음으로 하나의 도메인을 오너십을 가지며 communication 과 개발을 진행했던 프로젝트니까요.
다행이 QA 가 마무리되는 시점이었기 때문에 버그 처리와 여러 문의만 대응을 하면 순조롭게 끝날것 같았습니다.
하지만 갑작스럽게 커다란 일 하나가 저에게 떨어졌습니다.
갑작스럽게 떨어진 “바우처 구독” 프로젝트
갑작스럽게 팀장님이 저에게 나름 큰 미션을 주셨습니다.
아이들나라 구독 시스템에 바우처를 통한 기간권 구독을 할 수 있도록 신규 비즈니스를 추가하고싶다는 요구사항이었습니다.
신규 비즈니스의 내용은 이렇습니다.
•
6개월, 12개월 구독권 상품을 추가하고싶어요.
•
6개월, 12개월 이후는 자동 해지가 되어야합니다.
•
이 서비스 출시까지 9일이 남았어요
팀 내의 다른 개발자들은 다른 우선순위가 높은 작업에 이미 투입이 되어있었기 때문에 앞선 통합회원 작업이 비교적 마무리 되던 제가 이 일의 적임자 였던 것이죠.
9 working day 안에 기획, 개발, QA, 오픈 준비 모두 끝나야 하는 급박한 프로젝트가 무섭기도 했지만 동시에 설레기도 했습니다.
진짜 기획부터 오픈까지 제 ownership 과 전문성을 테스트할 수 있는 기회니까요.
결국 성공적으로 오픈을 하게 되었고, business impact 또한 제가 생각하기에 다른 여러 프로젝트들 중에 매우 높은 편이었다고 생각합니다.
이제 이 과정에서 제가 느꼈던 동료 상에 대해서 이야기 해볼게요
나는 함께 일 하고 싶은 동료인가?
앞선 엔지니어 세미나에서 제가 중요하다고 생각했던 상위 3가지 항목에 대해서 저를 다시 평가해봤습니다.
1.
무엇이든 만들어줄 수 있는(실행력 있는) 동료인가?
2.
도메인에 대한 전문성을 겸비 하였는가?
3.
커뮤니케이션과 협업에 능한 동료인가?
하나씩 질문에 답을 해볼게요.
1. 무엇이든 만들어줄 수 있는 동료인가?
‘테크 커리어 — 돈 존스’ 책을 보면 요구사항에 대해서 늘 No 라고 말 하는 엔지니어를 부르는 말인 걸림돌이 되는 엔지니어 라는 표현을 합니다.
~~ 라는 서비스를 만들고싶은데 가능할까요? 라는 이야기를 들으면 다음과 같은 생각으로 항상 삐딱한 자세였던것 같아요. (물론 이렇게 표현은 안하지만요)
•
이걸 이 기한까지 하라고?
•
이 사람이 기존 시스템에 대한 이해도가 있을까? 이해도가 있다면 이런 요구사항을 말하는게 맞나?
•
이 구조를 만들라고? 이러면 기존 구조가 망가지는데?
•
이 요구사항을 수용하면 확장성이 떨어져.
이 오만한 생각들이 사라진 것은 비교적 최근의 어느 한 순간이었습니다.
이 서비스가 정말 잘 되었으면 좋겠다. 정말 많은 사람들이 쓰길 바라고 성공하는 서비스가 되었으면 좋겠다! (이 생각이 들기 위해 여러 일련의 과정이 있었지만요)
라는 마음이 들었던 순간부터 성과를 고민하고 추진할 수 있는 사람들 (마케터, 기획자, PO) 들을 끝까지 지지하고싶다는 생각이 들었습니다.
물론 회사의 상황에 따라서 무엇이든 들어주는 사람이 득이되고 실이 될 수 있겠죠? 하지만 지금으로는 무조건적인 득 이라는 확신이 있습니다.
그래서 제가 그들이 전달하려는 가치에 공감 하기만 한다면 끝까지 지지해주는 것이 최고의 성과를 낼 수 있을 것이라는 판단이 들었고 이번에는 business first, 안되는건 없다. 라는 생각으로 임했던 것 같습니다. (저와 일했던 동료들에게 전달이 되었을지 모르겠네요)
그래서 최대한 들어주려 하고 최대한 가능한 방법만 모색했던 것 같아요
2. 도메인 전문성을 겸비하였는가?
아이들나라의 웹 구독을 zero 부터 만들었던 경험이 있던 저에게 구독 도메인은 스스로 전문성이 있다고 생각합니다.
그래서 9 working day 안에 (1일 정책 정의 및 분석, 4일 개발, 3일 qa, 1일 오픈 준비) 최소한의 노력과 최대한의 가치 전달을 목표로 과거 제가 엔지니어링을 했던 지식들을 모아봤습니다.
그리고 이번 요구사항으로 변경되는 다음 4개의 도메인에 대해서 최소한의 side-effect, 최소한의 코드작업으로 due date 에 맞출 수 있었습니다.
•
상품
•
구독
•
바우처(신규)
•
view
과거에 저와 팀 동료들이 확장성을 염두하고 했던 설계가 빛을 발하더군요.
3. 커뮤니케이션과 협업에 능한 동료인가?
이 질문에 대한 답은 No 입니다.
앞선 2가지 질문에 대해서는 나름 자부심도 있고 할 이야기가 많지만 이 질문에 대한 답은 그렇지 않습니다.
1.
약속을 했으면 지켜야 한다
무언가를 해주기로 약속했다면 누군가는 기다리게 됩니다.
그들이 원하는 결과가 없으면 기다리고 기다리다 지쳐 다시 한 번 저에게 물어보겠죠?
“원익님 혹시 이거 다 되었을까요..?” 그럼 저는 “아! 잠시만요!” 라고 하죠
약속했던 것을 등한시 하면 요청자도, 저도 서로 껄끄러워지는 상황으로 가게 되더라구요.
일례로 QA 를 진행하던 상황을 볼까요?
다양한 tc 를 테스트하기 위해서는 데이터의 상태를 원하는 대로 조작할 수 있도록 QA tool 을 보통 제공합니다.
하지만 일정과 시간이 없어서 직접 요청을 건 by 건으로 요청해주면 제가 수동 보정을 해주기로 약속하였죠.
하지만 이 선택이 큰 실수였습니다. 꼼꼼하고 다양한 TC 덕에 너무나도 많은 요청이 오게되었고 tc 수행이 저와 했던 약속 때문에 QA 진행에 큰 허들이 되었죠.
또 다른 상황으로는 기획 리뷰에서 엿볼 수 있습니다.
이번 작업에는 전사 리소스 문제로 FE, BE 만 있었고 모바일 개발자가 없었습니다.
하지만 작업 내용은 분명 모바일 view 에도 영향이 갔었죠.
기획서에 분명 mobile view 쪽 확인이 필요하다는 문구가 있었고, 제가 오히려 나서서 “제가 확인하겠습니다” 라고 했지만 실제로는 바쁘다는 핑계로 출시 전날까지 까먹고 있던 것이었습니다.
결국 QA 가 거의 마무리가 되된 출시 하루 전 code freezing 이 되었는데 부랴부랴 긴급 배포가 나가야 하냐 말아야 하냐에 대한 논의가 이루어졌습니다.
2. 리스크 관리에 실패했다
앞선 약속 이야기의 연장선입니다.
•
사실 QA tool 을 제공하지 못한 것은 어쩌면 불가항력이었습니다.
•
또 기획 리뷰에서도 꼼꼼하게 확인하지 못한 것도 불가항력이었습니다.
너무 바쁘고 할 일이 많았기 때문이라고 변명할 수 있고 납득이 될 것이라 생각합니다.
정말 그럴까요? 만약 정말 그렇다면 이것 자체가 risk 고, 저는 risk 관리에 실패한 것입니다.
프로젝트 막바지 즈음 voc 대응해줘야 하지, QA 버그 수정해야지, QA 데이터를 수동 보정 해야하지 이 3개가 한번에 오니까 정말 순식간에 숨이 턱 막히고 멘탈이 나가더군요.
아니나 다를까 이 모습을 바로 캐치하신 팀장님의 risk 센서가 동작하셨는지 먼저 나서서 팀원들 전체 프로젝트를 잠시 holding 하고 제가 가지고 있던 짐을 하나씩 덜어주며 팀 전체가 투입되어 모두가 함께 마무리를 지었습니다.
제가 만약 risk 관리가 가능했더라면 리소스를 관리하는 역할을 가진 팀장님에게 먼저 나서서 ‘이거 리스크에요’ 라고 이야기 했어야 합니다.
마치며,
이렇게 지난 최근 저의 모습을 돌아보며 스스로에게 ‘나는 내가 원하는 동료상에 부합할까?’ 라는 질문을 해보면 100% 부합하지는 않으나 점점 나아지고 있다. 라는게 제 결론입니다.
시간이 지나면서 오만했던 생각들이 깨지며 새로운 생각들로 채워지며, 또 그 생각들이 깨지며 다시 새로운 생각들로 차는것 같아요.
이런 고민을 할 수 있도록 도와준 아이들나라의 ‘엔터’ 운영위원들과 성장을 할 수 있게 좋은 재료를 준비해주는 아이들나라에게 첫번째 감사 인사를 올리고, 스스로 불꽃이 꺼지지 않도록 잘 버텨주는 자신에게도 감사함을 느끼며 글을 마무리하겠습니다.
앞으로도 새로운 생각들과 경험들로 또 찾아뵙겠습니다.
감사합니다.