성장하지 않아도 괜찮습니다 - INFCON 2024
성장해야 한다고 말합니다. 회사에서는 올해 당신은 얼마나 성장할건지 묻습니다. 성장이 무엇인지도 모르는데 성장하고 싶다고 합니다. 죄송합니다. 이건 뭔가 잘못된 것 같지 않나요? 이 발표
www.inflearn.com
본 포스팅은 INFCON 2024에서 김영재님의 '성장하지 않아도 괜찮습니다' 발표 내용을 개인적인 생각과 함께 정리한 글입니다.
관련 저작권은 인프런과 김영재님에게 있습니다. 문제가 되는 부분은 댓글로 남겨주시면 감사하겠습니다.
Speaker Profile
- LINE ABC Studio, 기술임원
- 데마에칸(일본 No.1 푸드 딜리버리) CPO
- Product Members: 450명 (KR: 60명, JP: 390명)
- 前 네이버 CLOVA lead
- Bapul CTO (네이버 / LINE 엑싯)
- 센서 / 임베디드 연구원
- 5번 창업, 2번 엑싯
현재까지도 활발하게 코딩을 하는 샤프한(?) 개발자로, '개발자에서 아키텍트로'라는 책을 번역했다.
(국내에 몇 없는 아키텍트에 관련된 책으로 교보문고 베스트 셀러 2위까지 올라갔던 책이라고 한다. 다음에 읽어볼 책으로 좋을 것 같다)
Why?
매년 연초 진행하는 세미나 '구름 커밋'에서 올해 '시야가 넓은 개발자는 무엇이 다를까?'라는 주제로 세미나를 진행했었고,
특정 파트에서 개발자들로부터 유독 많은 공감을 받았던 챕터를 보강해 이번 발표를 진행하게 됐다.
(이 이야기가 요즘 IT 업계에서 일하는 분들이 많이 듣고 싶어하는 내용이라고 생각했기 때문에)
도대체 성장이란 무엇인가?
자기소개서나 이력서에 자주 등장하는 '성장하는 개발자',
동료들과 대화 주제, 회사의 원온원 가이드 등 수많은 곳에서 성장이라는 키워드를 쉽게 접하게 된다.
하지만, '저는 성장할 거예요!' 이 말이 굉장히 어색하게 느껴졌다.
보통 성장이라 함은 '사람이나 동식물 등이 자라서 커지는 것을 일컫는 말'로 내가 나에게 쓰기보다는 내가 다른 무언가를 보고 '성장했다'라는 표현이 더 자연스럽기 때문이다.
나 자신에게 성장이라는 단어를 쓴다면 다음과 같이 정의할 수 있을 것이다.
시간이 한참 지난 뒤에 되돌아볼 때 느끼는 것
그마저도 내 입으로 차마 말할 수 없는 것
도대체 왜 IT 업계에서 이 성장이라는 단어가 유독 강조될까?
우리나라의 사회문화적인 것과 관계가 있다고 생각한다.
급속도로 성장한 대한민국 사회에서는 성장을 지나치게 강조한다. 이에 따라 수많은 사람들이 압박감, 불안감, 부담감을 호소한다.
이력서에 조차 많은 개발자들이 '성장하는 개발자'라는 타이틀을 내세우지만, 정작 '성장을 뭐라고 정의할 수 있나요?'라고 물어보면 답을 하지 못하는 경우가 태반이다. 단순히 '연봉을 많이 받는 것?', '더 높은 곳으로 올라가는 것?' 성장을 정의하기에 다음과 같은 것들은 철학적으로 너무도 빈약하다.
특히나, 위험한 것은 하던 것을 꾸준히 하는 것이 그것 자체만으로 너무나 가치가 있는 일인데 이것이 마치 현실에 안주 하는것, 그저 도태되는 것처럼 부정적으로 생각하는 인식이 사회에 만연해지고 있다는 것이다.
전혀 그렇지 않습니다.
하던거 계속 해도 됩니다.
꾸준함이 곧 의미를 만든다. 오히려 지금 하는 일을 더 긴 호흡으로 지치지 않고 하는 지속가능성에 집중해야 한다.
우리에게 부족한 것은 호흡이 너무도 짧고, 팀플레이가 부족하다는 것이다. (협업에 대한 경험 부족)
성장은 결국 결과일 뿐, 성장을 '동사'로 사용하면 나를 잃어버리게 된다.
이 이야기가 굉장히 와닿았다. 나는 항상 여유가 부족했다.
전공자가 아니니까, 빨리 시작하지 않았으니까, 직무를 전환했으니까 온갖 이유와 함께 불안 속에서 성장을 쫓아온 것 같다.
쉴 때는 뭘하며 쉬어야 하는지조차 제대로 알지 못했다. 마치 단거리 달리기를 하는 사람처럼 전속력으로 달리다보니 숨이 차고, 주변을 잘 보살피지 못하는 것 같다는 생각을 했다. 저 멀리 있는 사람을 보며 나도 빨리 저들처럼 성장해야돼라고.
내가 좋아하는 발표자 성재님을 비롯해 개발자 분들이 결국은 같은 이야기를 하는 것 하신다.
커리어를 긴 호흡으로 꾸준하게 바라봐야 한다고.
관련하여 좋았던 글들을 아래에 첨부해둔다. 항상 마음이 조급해지면 이 말들을 되새기며 한 템포 속도를 낮춰보자
어떻게?
성장이 아니라면 '지금 하는 일'을 어떻게 접근해야 될까? 다음의 네 가지 키워드에 집중해서 지금 하는 일을 해보자.
1. 많이
'지금 하는 일을 많이 하려면 어떻게 해야할까?' 이에 대한 답을 엔지니어링에서 얻었다.
엔지니어링과 마찬가지로, 일을 할 수록 나 자신의 재생산 비용을 낮춰야 한다.
엔지니어링이란 말은 디자인도, 기획도, 개발도 모두 가능하다. (ex. 루틴의 자동화, 지식의 일반화)
자동화
요즘은 대부분의 사람들이 자동화 경험 정도는 있다. 하지만, 문제는 거의 모든 자동화 스크립트가 업무 하나에 대해서만 자동화를 한다는 것이다.
예를 들어, 마케팅팀의 자동화를 도와준다고 했을 때 100명의 회원 중에서 3명을 뽑는 자동화 스크립트를 만든다고 가정해보자.
다음 달엔 500명의 회원에서 5명을 뽑는다고 하면, 많은 사람들이 기존 스크립트에서 하드 코딩된 숫자를 바꾸는 작업 정도로 그친다.
여기서 한 레벨 더 나아가, 아예 지구 반대편의 다른 마케팅 회사의 일까지 도와주는 프로덕트로 확장되어 요구사항도 복잡해진다면 뭔가 좀 더 거창한 프로덕트처럼 만들어 가꾸어 나갈 수 있다.
즉 결론은, 아주 작은 스크립트를 만들더라도 처음부터 '이걸 잘 만들어서 지구 반대편에 있는 곳까지 도와주는 것을 만들면 어떨까?'라는 생각으로 개발한다면 단순한 자동화일지라도 큰 도움이 된다.
관련하여, 김영재님이 작성하신 오픈소스답게 소프트웨어 설계하기라는 글을 읽어본다면 더 이해에 도움이 될 것 같다.
일반화
단 한번이라도, 동료가 내 스타일로 일하게 해보는 것이다.
이는 굉장히 어렵다. 그 이유는 상대방이 보수적이어서가 아니라 모두가 '당신과 내 상황은 다르다'라는 전제가 깔려있기 때문이다.
결국, 상대방이 나의 스타일대로 일하게 하려면 지식을 깎고 깎아서 일반화할 필요가 있다.
추상적인 표현이라 어렵게 들리지만, 이를 위한 가장 쉬운 훈련 방법은 '사내 블로그에 글을 쓰는 것'이다.
왜냐? 나의 배경과 맥락을 하나도 모르는 누군가에게 내가 겪은 것을 온전한 글로 쓴 후 당신도 한번 해보길 권장하며 끝내기 때문에 이는 지식의 일반화를 하기 굉장히 좋은 방법이 될 수 있다.
다음과 같은 사례가 있다.
머천트팀에서 Focus Group Test(FGT)에 대한 구체적인 내용의 사내 블로그 글은 추후 딜리버리 팀의 FGT에서도 활용될 수 있다.
가로축을 사용자 여정으로 정의하고 세로 축을 기능의 특성에 따라 세 단계로 나눠 요건을 정리하는 템플릿을 만들었고, 해당 템플릿을 통해 수백 명의 직원과 수십 명의 경영진으로 스테이크홀더가 매우 많은 조직에서의 파편화된 요건을 정리할 수 있었다.
모든 팀에서 해당 템플릿을 기준으로 로드맵을 작성하고 우선순위를 결정함으로써 합의 과정도 엔지니어링(시간 비용이 낮아짐) 될 수 있었다.
즉, 지금 하는 일을 많이 하려면 업무에 있어서 재생산 비용을 낮춰야 하고, 이를 위해 자동화(단순 스크립트 작성이 아닌 확장성을 고려한)와 일반화(사내 블로그에 글을 씀으로써 동료가 내 스타일대로 일을 하게 만들어보는 것)를 실천해볼 수 있다.
2. 함께
반복되는 질문을 통해 프로세스에서 나쁜 프로세스를 찾아내는 방법이 있을 수 있다.
예를 들어, 사무실에서 반복적으로 들리는 질문, Slack이나 Teams에서 올라오는 질문을 통해 '저 질문은 왜 계속 있는걸까?'라는 생각을 시작으로 하나씩 원인을 찾아 들어가 없애보는 것이다.
다음은 실제 영재님의 해결 사례 예시
모든 릴리즈에 대해 버전 관련 질문이 너무 많았다고 한다. 이를 해결하고자 버저닝 규칙을 만들었다고 한다.
지금하는 일을 함께하기 위해 '사람들이 반복적으로 질문하는 문제'에 집중하고 이를 해결하는 프로세스를 만들어보자.
3. 크게
수많은 PM, PO, 데이터 분석가들이 위 3단 논법을 알고있지만 이는 예상대로 동작하지 않는다.
왜냐하면, 처음 수집되는 데이터에서 어느 정도 모호함이 있기 때문이다.
결국 의사결정을 하는 쪽으로 가면 갈수록 숫자로 소통하기 때문에 수치화와 가시화가 반드시 필요하다.
모호한 지점의 데이터를 더 잘 가시화하려면 특히 유저의 의견(Voice of Customer)을 반영해야 한다.
아래는 이 부분을 해결하고자 오픈소스로 개발한 ABC User Feedback!
우선순위 공식
주주총회에서 서비스들의 우선순위에 관한 수많은 질문에 답변하고자 해당 부분을 수치화
지금하는 일을 크게 하고 싶다면, 유저의 의견을 수치화 및 가시화할 수 있어야 한다.
4. 오래
나의 아이덴티티를 발견하는 과정
거창한 주제를 생각할 필요없이, 지금하는 걸 더 많이 하는게 첫 걸음이다.
지치지 않고 계속해서 하다보면 하나의 키워드가 모아질 때가 온다. 그리고 이것이 곧 나의 아이덴티티가 된다.
누군가 나에 대해 물어봤을 때, 일반화를 통해 이런 과정으로 변화해야 한다.
'xx씨는 어떤 사람이에요?'
'어... 백엔드 엔지니어요'가 아닌 '그 분은 (아이덴티티)를 중요하게 생각하는 백엔드 엔지니어입니다.'가 돼야 한다.
당신은 무엇에 집중하고 있습니까?
다음의 질문에 '모두가 한 사람에 대해 같은 대답을 할 수 있는 것', '결국 자신의 키워드를 가지게 되는 것'이 가장 이상적인 팀의 상태라고 생각한다.
정리
위의 과정을 꾸준히 반복하면 된다. 이것은 성장이 아니다.
성장이 아니라 얼마나 더 용량이 큰 사람이 되는가에 집중해야 한다.
느낀 점
솔직하게 업무를 할 때, 이런 점을 고려하며 일을 하지 못했던 것 같다.
물론 사내에 이렇게 일을 하는 사람 역시 없었지만, 나 스스로 '지금 하는 일'을 많이, 함께, 크게, 오래 하려고 노력했다면 문제가 반복되던 환경을 바꿀 수 있지 않았을까 라는 생각이 들기도 했다.
일본의 소설가 무라카미 하루키는 '하루도 빠짐없이 매일 200자 원고지 20매만 쓰고 그 이상은 쓰지 않는다'고 한다.
그가 그렇게 오랜 세월 글을 쓸 수 있었던 것은 영재님이 강조한 것처럼 긴 호흡으로 매일 꾸준히 글을 썼기 때문이 가장 크지 않을까.
나는 이 영상을 보기전까지도, '아 영상 볼 시간에 다른 기술도 공부해야 하는데' 라는 생각에 불안과 초조함을 느꼈다.
하지만, 결국은 빠른 속도로 쏟아지는 최신 기술에 허덕이며 성장하고 있다고 착각하지 말고, '지금 하는 일'에서 더 효율적인 방법은 없을지, 조금 더 퍼포먼스를 낼 수 있는 방법은 없을지 등을 고민하고 공유하는 것에 집중해야 함을 배울 수 있었다.
언젠가는 영재님처럼 꾸준함을 통해 좋은 영향력을 줄 수 있는 엔지니어가 되도록 이 배움을 잊지 말자.
'ETC > Tech Conference & Seminar' 카테고리의 다른 글
| [6월 우아한테크세미나] 한기용님의 ‘글로벌 개발자로 성장하는 법’ (0) | 2024.06.04 |
|---|---|
| SEF 2023에 다녀오다 (2) | 2023.09.09 |