안녕하세요 펄핏의 CTO Jake입니다. 고객의 신발 구매 경험에 도움을 줄 수 있는 AI 기술을 기획하고 개발하는 테크팀을 담당하고 있습니다. 이번 포스팅에서는 펄핏이 지향하는 테크팀의 필수 역량, 그중에서도 소프트 스킬에 대해 이야기해보려 합니다.
여러분은 소프트 스킬과 하드 스킬이라는 용어가 익숙하신가요? 위키에 따르면 소프트 스킬은 '하드 스킬을 보완하여 성과 달성을 위해 다른 사람들과 함께 잘 일할 수 있도록 하는 상호 교류, 의사소통, 사회적인 감성 능력 등의 조합' 이라고 합니다. 하드 스킬은 업무 수행에 필요한 기술(Technical) 이나 경영 관리 (Administrative) 등의 역량이라고 표현하고 있구요.
하드 스킬이 업무 수행의 핵심인 개발자, 데이터 분석가 등의 업무에서도 소프트 스킬이 필요할까요? 단언컨대, 테크팀이 일을 잘하기 위해서 소프트 스킬은 정말 중요합니다. 특히 저는 펄핏의 개발자를 포함한 테크 팀원들에게
1. 공유 커뮤니케이션
2. 주도적인 문제 해결
3. 맥락 이해하기
등의 소프트 스킬은 계속해서 훈련해서 역량을 쌓아야 한다고 강조합니다.
1. 공유 커뮤니케이션
네, 첫 번째 소프트 스킬은 역시 커뮤니케이션입니다. 소프트 스킬에서 가장 많이 언급되지만, 구체적인 건 조직마다 / 상황마다 많이 달라서 더 모호하게 느껴지는 영역이기도 합니다.
펄핏의 기본 커뮤니케이션 규칙은 문서를 기반으로 내용을 공유하고, 이를 서로에게 알려주는 것을 게을리하지 않는 것입니다.
사실 이 규칙은 테크팀 뿐 아니라 펄핏의 모든 팀원들에게 바라는 부분이지요. 그런데 테크팀에서 커뮤니케이션을 가장 강조하는 이유는 무엇일까요?
팀원 모두가 고객 중심으로 생각하고 일하기 위해서입니다
개발자의 코드는 결국 고객에게 가치를 제공하는 제품을 위한 것입니다. 펄핏 데이터 분석가의 데이터 모델은 고객에게 더 정확한 사이즈의 추천을 위한 것입니다. 고객과 떨어질 수 없는 것이 개발을 포함한 테크팀 업무이며, 고객을 더 잘 이해하기 위해서는 테크 팀원들끼리 뿐만 아니라 펄핏의 구성원 모두와 끊임없이 소통해야 합니다.
하지만 단순히 많은 의사소통이 좋은 커뮤니케이션은 아닙니다. 인간은 각자 이해하고 싶은 방식으로 이해하려고 하므로 오히려 서로 다른 생각을 하고 싱크가 어긋날 수 있습니다.
나의 결과물이 고객 입장에서 충분한지, 고객에게 더 좋은 방향으로 개선될 수 없는지 함께 발전시킬 수 있으려면 결국 문서를 통해 서로 생각의 싱크를 맞추는 게 필요합니다.
여기서 핵심은 보는 사람 중심으로 문서를 작성하는 것입니다. 개발자 사이에서는 코드를 통해서 서로의 의도와 생각을 파악할 수 있겠지만, 개발 언어를 모르는 사람과 코드로 소통하기는 결코 쉽지 않겠지요.
펄핏에서 지양하는 커뮤니케이션
ex. 요청하신 상품 조회 화면 속도 개선 작업은 다음과 같이 완료되었습니다.
- 데이터 베이스 커넥션 풀 최적화를 통해 속도 개선
- 이미지 리소스 캐싱을 위한 CDN 적용
- 동적 렌더링을 적용하여 리소스 로딩 속도 최적화
이 문서는 과연 누구를 위한 글일까요? 비개발자 동료가 이 문서의 내용을 얼마나 이해할 수 있을까요? for 는 '반복' 으로, switch는 '조건별 분기' 로 바꾸는 것처럼 단순히 코드를 사람의 언어로 바꾸는 것이 문서화는 아닙니다.
문서는 보는 사람들의 눈높이에 맞게 이해할 수 있도록 쓰여야 합니다. 그렇기 때문에 때로는 같은 내용을 두 번, 세 번 다른 수준으로 작성해야 할 일이 있을 수도 있지만 펄핏에서는 독심술 AI를 개발 중이라 그 정도 노력은 기본으로 해야 합니다.
2. 문제 중심 접근
스타트업은 세상의 문제를 조금은 다른 시각으로 다양한 시도를 해 볼 수 있는 최고의 환경입니다. 하지만 세상의 모든 문제는 멀리서 남의 문제로 볼 때는 단순해 보이지만, 가까이 내 문제가 되면 복잡하기 이를 데 없는 것 같습니다.
펄핏의 테크팀은 매일 어떻게 하면 고객에게 더 만족할 만한 추천 서비스를 만들 수 있는지 고민합니다. 펄핏의 테크팀은 누군가가 정한 솔루션을 구현하는 것으로 만족하지 않고, 고객의 어려움이나 비즈니스 팀이 맞닥뜨리는 문제를 함께 고민해야 하는 역할이어야 합니다.
저의 경험상 문제가 발생한 원인은 다양한 업무를 하는 사람들과 함께 찾는 것이 좋습니다. 개발자, 비개발자 모두 모여 공통으로 느끼는 문제 상황을 이야기하는 과정에서 코드의 품질, API의 응답 속도, 부하가 많이 걸리는 네트워크 등과 같은 기술적 문제를 넘어 좀 더 보편적이고 근원적인 원인을 발견하는 경우가 더 많습니다.
문제의 원인을 찾는 데 집중하고 문제를 이해하려는 노력은 펄핏의 테크팀에게 매우 중요한 역량입니다. 펄핏의 테크팀는 이미 정해진 솔루션을 단순히 구현하는 팀이 아닙니다. 스스로 문제를 이해하고 이를 기반으로 적극적으로 문제 해결에 참여해야 합니다.
제 경험에 의하면 이렇게 문제를 인지하고 해결 방법을 고민하는 것을 즐기는 개발자와 문제를 이해하기보다 바로 솔루션을 만들려고 하는 개발자는 성장 속도에서 큰 차이를 보였습니다. 게다가 아이러니하게도 시간이 지나면 두 개발자 사이에 가장 역량의 격차가 벌어지는 부분은 하드 스킬입니다. 다룰 줄 아는 기술 스택의 범위가 전자의 개발자가 훨씬 넓어지는 경우가 많습니다. 아마도 주어진 작업을 끝내는 것을 넘어서 궁극적인 문제 해결을 위해 다양한 기술적인 시도를 하면서 발전하는 것이 아닐까 합니다.
팀원이 문제 해결을 위해 다양한 시도를 해보고 싶다면 싫어할 리더는 없습니다. 특히 저는 팀원들에게 개발자의 무기인 Visual Studio Code와 AWS로 최대한 다양한 시도와 테스트를 해보라고 장려하고 있습니다.
개인적으로 팀원들에게 추천하는 문제 중심으로 생각하는 역량을 키우는 방법 중 하나는 '예상 답변을 포함해서 질문하기' 입니다.
"버튼 너비 26px 과 34px 디자인 중에 00 님은 어떤 것이 좋은가요?" 보다
"버튼 너비를 34px와 26px 로 만들어 비교해 보니 34px이 텍스트 여백이 넓어져 좋은 것 같은데 00 님 생각은 어때요?"
처럼 단순 Yer or No가 아닌 형태로 질문하도록 하는 것이지요.
상대방의 예상 답변을 생각해 보는 것은 내가 이해하는 문제의 목적을 명확히 할 수 있고, 질문자에게 공유함으로써 서로 같은 문제를 인식하고 있는지 파악하여 좀 더 빠르게 문제 해결에 다가갈 수 있습니다. 테크팀 리더로서 이런 질의 응답이 테크팀 안에서만 고립되어 이루어지지 않도록, 문제에 더 적합한 솔루션을 함께 고민하기 위해 모든 구성원들과 자유롭게 질문하고 의견을 받는 환경을 만들기 위해 노력하고 있습니다.
3. 맥락 이해하기
펄핏의 AI 추천 서비스만큼 어려운 인공지능 영역 중 하나가 한글 번역이라고 합니다.
번역기가 한글을 정확하게 이해하지 못하는 이유는 바로 문맥에 따라 달라지는 동사나 명사의 쓰임을 아직까지는 정확하게 모두 구분할 수 없어서입니다. 한글뿐 아니라 글 전체의 의미에 따라 그 뜻을 다르게 해석할 수 있는 단어는 영어나 다른 언어에도 모두 존재합니다. 즉, 단어의 전후 관계와 행간의 의미까지 파악해야 우리는 완벽한 의사소통을 할 수 있는 것이지요. 어쩌면 위에서 언급한 활발한 의사소통은 생각을 표현하는 관점에서 필요한 소프트 스킬이라 할 수 있고, 맥락을 잘 파악하는 것은 생각을 이해하는 관점에서 필요한 소프트 스킬이라고 할 수 있을 듯합니다.
테크팀에게 제가 맥락을 이해하는 능력을 강조하는 것은 다름 아니라 너무나도 분명한 하드 스킬 - 코드를 통해 결과를 만들어 내는 능력을 가지고 있기 때문입니다. 전체를 이해하지 않고 작업하면 결과는 만들 수 있어도 성과를 보장하지는 않기 때문입니다.
예를 들어 보겠습니다.
트렌디한 신발 정보를 조회하고 있는 사용자에게 외부 쇼핑몰 사이트로 연결하는 시범 서비스를 개발하려고 합니다.
이를 위해 상품의 이미지와 가격, 판매 중인 사이즈 데이터를 주기적으로 수집하는 기능을 만들고자 합니다.
해당 기능은 데이터 최신성 보장을 위해 하루에 최소 2회 이상 수행되어야 합니다.
개발자 A는
- 상품 DB의 상품 정보를 바탕으로 상용 검색엔진의 검색 API를 통해 검색된 결과 사이트를 Navigation 하는 Bot을 개발하고
- Bot을 통해 수집된 웹 페이지를 분석하는 Parser 엔진을 개발 후
- 시스템 부하 분산을 위해서 0시, 12시 해당 Parser 엔진 실행하는 스케줄 작업 설정을 진행하였고
개발자 B는
- 최근 2주 동안 많이 조회된 상품을 저장하는 임시 테이블을 만들어 해당 테이블의 상품 정보를 바탕으로
- 쿠팡, G마켓 등 사용률 상위 5개사 커머스 사이트의 검색창에서 검색한 결과 웹 페이지를 분석하는 Parser 엔진 개발 후
- 재고 업데이트가 주로 일어나는 시간 이후인 10시, 19시에 해당 Parser 엔진 실행 스케쥴 작업 설정을 진행했다고 가정해 보겠습니다.
만약, 개발자 A와 B가 비슷한 경력과 스킬셋을 가진 사람들이라면 B의 작업이 더 빨리 완료되었을 것입니다. 그리고 서버 리소스도 덜 사용했을 듯하군요.
B는 최근 '트렌디한' 상품으로 작업 대상을 한정하기 위해 2주 동안의 데이터만을 이용하여 성능의 최적화를 의도하였고, 2회 이상 수행이라는 요구 사항도 '최신성 보장' 이 내포하고 있는 의미를 파악하여 재고가 갱신되는 주기와 맞추는 노력도 보여줬습니다.
A는 정석대로 가장 이상적인 형태의 데이터 수집기를 완성하는 결과를 만든 것으로 보입니다. 다만, '시범 서비스' 가 의미하는 빠른 실행 후 검증이라는 목적에 맞는 개발이라고 볼 수는 없습니다.
결국 맥락을 이해하고 개발한다는 것은 전체를 고려해야 한다는 뜻입니다. 내가 만드는 화면이나 API, 모델이 전체 서비스의 일부라는 것을 인지하고 그 부분이 전체에 기여하는 모습, 전체의 결과가 개선될 수 있도록 고민할 수 있어야 한다는 뜻이지요.
이런 펄핏의 테크팀을 꿈꾸고 있습니다
어려운 일들을 매일매일 마주하는 팀원들과 교류하며 리더인 저 역시 말씀드린 소프트 스킬을 지속적으로 개선하려고 노력 중입니다.
펄핏의 테크팀은 내가 만들 수 있는 것을 빨리 만드는 팀이 아닙니다. 사용자가 필요한 것을 만드는 팀이어야 합니다. 개발자가, 데이터 분석가가 직접 모든 고객을 만날 수는 없지만 적어도 고객의 이야기를 듣고 있는 팀원에게 찾아가 그들의 목소리를 듣고 한 팀으로 일을 하고 싶어 하면 좋겠습니다.
훌륭한 Technical 역량을 가진 분들이 즐거운 동료들과 함께 제가 말씀드린 소프트 스킬을 키우고 싶다면 펄핏의 테크팀에 한 번 지원해 보시길 바랍니다!
