레몬베이스 엔지니어의 더하기에서 곱하기로 가는 여정
안녕하세요. 레몬베이스 Backend Engineer로 일하고 있는 Whatsup 입니다 .🙂
작년 이맘때쯤, Developer Imposter Syndrome 라는 글을 작성한 후 정말 많은 응원을 받았었는데요. 오늘은 엔지니어로서 더하기에서 곱하기로 가는 저의 성장 이야기를 공유하고자 합니다.
저를 포함한 많은 엔지니어들이 기술 능력을 키우고 성장하는 것에 집중하고 있다고 생각하는데요. 열심히 노력해서 성장하는 것과 효율적으로 성장하는 것은 다르다고 생각합니다.
제가 레몬베이스에 합류할 당시에는 높은 임팩트를 만들어내는 것 보다 개인의 역량을 키우는 것에 집중했는데 이로 인해 같은 일을 하더라도 좁은 시야로 바라보고 임팩트가 작은 일에도 많은 시간을 쏟았던 경험들이 있어요.
순조로운 여정만 있던 것은 아니지만, 그 과정에서 얻은 경험과 성장은 바꿀 수 없는 값진 보물이 된 것 같아요. 여러분들에게도 제가 고민하면서 겪은 시행착오와 배움들을 공유하고자 합니다.
레몬베이스에서의 고민 시작
저는 레몬베이스에서 5명 미만의 엔지니어 조직에서 풀스택 엔지니어로 시작해서 다양한 제품을 개발하는 메이커로 활동했습니다.
제품과 회사의 성장과 함께 다양한 요구사항이 증가하고, 동료들과 협업하는 일이 늘어나면서 마음속에 지금보다 일을 더 잘하고 싶다는 고민이 강해지기 시작했어요.
작은 규모의 팀에서는 주로 개인의 생산성을 우선시했는데, 큰 규모의 팀으로 성장하면서 개인의 생산성보다 더 중요한 요소가 있다는 인식이 강해졌습니다. 이러한 변화로 개인의 생산성과 성장 등 다양한 고민이 시작되었으며, 이러한 고민들을 하나씩 설명하려고 합니다.
1. 개인의 생산성과 성장에 대한 고민
개인의 생산성과 성장에 대한 고민을 시작하면서 제일 먼저 “나는 어떤 방향으로 성장하고 싶고, 어떤 모습이 되고 싶은가?” 에 대해서 간단하게 글로 정리해봤습니다.
- 고객에게 더 많은 가치를 전달하는 엔지니어가 되고 싶다.
-> 새로운 기술과 개발 방법을 학습하여 제품을 개선하고, 고객들의 요구사항을 충족시키기 위해 최선을 다하는 엔지니어 - 팀에서 뛰어난 동료 엔지니어로 인정받고 싶다.
-> 협업을 통해 팀의 성과를 높이며, 동료들과 함께 배우고 성장하는 기회를 최대한 활용하는 엔지니어
글로 정리하고 나서 보니 저는 아래와 같은 결론을 내릴 수 있었습니다.
- 개인의 생산성을 지금보다 더 향상시킬 수 있다면 결과적으로 더 많은 문제를 해결할 수 있는 상태가 되지 않을까? 그러면 내가 원하는 모습의 엔지니어 될 수 있지 않을까?
- 10배의 법칙 -> 지금보다 10배 더 많은 문제를 해결하는 엔지니어가 되는 것을 생각해보자.
- 10배 더 많은 문제를 해결하려면 경험하지 못한 문제를 잘 해결해야한다.
- 내가 경험해보지 못한 것들을 간접적으로 체험하기 위해 많은 책을 읽고, 다양한 컨퍼런스에서 어떤 문제를 어떻게 해결하는지 들어보고 고민해보자.
- 다른 엔지니어들과 더 많은 상호작용을 할 수 있는 스터디를 진행해보자.
- 처음 들어보는 개념들이 있다면 지금보다 배로 학습하자
10배의 엔지니어 되기 -> 개인의 생산성을 높이고 싶어!
개인의 생산성을 높여서 지금보다 10배 더 많은 문제를 해결하는 엔지니어가 되기 위해 아래와 같은 활동들을 진행해봤는데요
- 기술 및 독서 스터디
- 지식을 확장하기 위해 함께 공부하며 서로의 경험을 공유하고 새로운 아이디어를 얻기 위해 시작했어요 - 컨퍼런스 정리
- 경험하지 못한 문제를 해결하는 과정이나 새로운 흐름과 개념을 파악하기 위해 내용을 정리하고 지식을 체계화해서 실무에 적용할 수 있는 방법을 찾아봤어요 - 처음 보는 개념들에 대한 학습(Agile, Shape Up 등)
- Agile, Shape Up과 같은 잘 모르지만 업무에서 사용하는 새로운 개념에 대한 학습에도 힘을 쏟았어요.
개인의 생산성을 높이기 위해 활동했던 자료들
이런 노력을 통해 개인의 생산성을 높이고 끊임없이 성장하는 엔지니어가 되려고 했어요. 특히 개인의 성장과 능력 향상뿐만 아니라 팀에게도 긍정적인 영향을 줄 수 있었습니다.
2. 엔지니어와 메이커 사이에서의 고민
개인의 성장을 위해 여러 기술적 학습(스터디, 컨퍼런스 등)을 하면서 엔지니어와 메이커 사이에서의 고민 또한 시작되었습니다.
- 엔지니어로서 기술적인 성장을 하는 것은 중요하다.
- 메이커로서 제품이 성공해야 나도 성공할 수 있다.
- 기술이 뛰어나다고 제품이 성공하지 않는다. 그러나 그 반대는 존재한다.
- 성공적인 제품은 훌륭한 엔지니어 그 이상이 필요하다.
고민을 시작하면서 저는 “훌륭한 엔지니어 그 이상은 무엇을 의미하는 것일까?” 라는 의문을 가지기 시작했습니다. 그래서 찾아봤더니 다양한 아티클과 책에서 공통적으로 이야기하는 것이 있었고 이를 간단하게 정리해보면 다음과 같았습니다.
훌륭한 엔지니어 그 이상이란?
높은 기술적 역량 뿐 아니라 비즈니스 능력과 사회적 기술까지 아우르는 포괄적 역량을 갖추어 한다. 다양한 기술적 도전에 대응하고 수 많은 요구 사항을 해결할 수 있는 인내력 또한 필요하다.
전문성, 풍부한 경험, 그리고 다방면에 걸친 영향력을 갖춘 슈퍼 플레이어가 되어야한다. 이는 문제를 신속하게 해결하는 것 뿐만 아니라 문제를 정의하고 해결책을 찾는데 시간을 투자하며 업무 프로세스를 개선하고 팀 간 협력을 촉진하는 능력으로 나타난다.
기술 영역 뿐 아니라 채용과 온보딩 프로세스, 그리고 조직 전반적인 문화를 향상시킬 수 있는 역할도 수행해야 한다.
따라서 훌륭한 엔지니어는 단순히 기술적인 역량에만 그치지 않고, 나무를 보지 않고 숲을 볼 수 있는 능력을 키우며 비즈니스와 사회적 측면에서도 높은 역량을 발휘하는 다양한 역할을 수행하는 것을 의미한다.
이런 종합적인 역량을 갖춘 엔지니어는 현대 비즈니스 환경에서 더 큰 성공을 이룰 수 있도록 도와준다.
쉽게 요약하면 아래와 같습니다.
- 높은 기술적 능력 + 비즈니스 능력 + 사회적 능력의 조합을 갖추어야한다.
- 슈퍼 플레이어가 되어야 한다.
- 문제의 솔루션으로 점프하지 않고 문제를 결정하는데 시간 보내기
- 나무를 보지 않고 숲을 볼 수 있는 능력을 키우기
- 기술 뿐 아니라 업무 프로세스, 채용, 온보딩 프로세스 등 다양한 영역에 기여를 해야 한다. - 물론 자신의 업무를 잘 하는 것은 Default이다.
훌륭한 엔지니어이자 메이커로 성장하고 싶어!
훌륭한 엔지니어 그 이상이 되기 위해 저는 레몬베이스의 다양한 부분에서 기여할 곳을 찾기 시작했습니다. 간략하게 진행했던 활동들을 소개해드리면 다음과 같아요.
(1) 내가 엔지니어로서 기여할 수 있는 곳 찾아서 완결짓는 경험해보기
- 프론트엔드 기여
- React Class Component -> Functional Component 모두 전환
- TypeScript 전환
- Deep PropDrilling + Coupling 코드의 구조 문제 해결
- 레몬베이스 디자인 시스템(LDS) 개발
- 프론트엔드 테스트 코드 작성 - 백엔드 기여
- Django + DRF 패턴을 레몬베이스 DDD 가이드 패턴으로 변경
- 기존 코드 성능 개선 - 제품에서 경험해보지 못한 영역 기여(업무 외 시간 활용)
- 레몬베이스 수시 피드백 제품 개발
- 1:1 미팅 — 구글 캘린더 연동 개발 - 다양한 영역에서의 기여
- 온보딩 프로세스 개선
- 매주 2건 이상 지식 공유 + 스터디
- 내부 해커톤 진행
(2) 동료들에게 엔지니어로서 부족한 부분에 대해 피드백 받았던 것들을 개선 및 개인 회고 진행하기
레몬베이스에서는 양질의 피드백을 수시로 주고받는 문화가 정착되어 있어요. 그래서 같이 일하는 동료들에게 피드백을 요청하여 내가 잘하고 있는 것은 무엇인지, 잘 못하는 부분은 무엇인지 파악할 수 있었습니다.
(아래는 실제 피드백을 받았던 내용들 중 일부입니다)
1. 문제를 좀 더 잘 분해해서 접근하기
2. 기획, 디자인에 대해 스스로 더 고민하고 판단하기
3. 복잡한 코드를 개선해보기
4. 생각이 매몰될 땐 일단 자리에서 벗어나보기
5. 풀기 어려운 문제에 조금 더 집중해서 해결해보기 -> 뾰족한 문제를 풀어보고, 생각해보기
6. 코드의 구조를 잡는 훈련을 시도해보기
7. 동료들의 성장을 도울 수 있는 상태가 되어보기
8. 본질적인 문제에 대해 집중해보기
9. 동료들에게 어떤 사람이 되고 싶은지 정리해보기
10. 제품 퀄리티에 대해 집착해보는 것 — UI/UX에 대한 집착
11. 맡은 일이 작더라도 꼼꼼하고 완결성 있게 마무리해보기 — 완결성 있는 업무 처리
12. 트랜잭션, 인덱스, 데이터베이스 구조, 쿼리 최적화, ORM, DDD 등에 대한 깊이있는 이해를 키워나가기
13. 새로운 지식, 경험을 쌓으면서 레몬베이스 제품 혹은 팀에 기여할 수 있는 주제를 찾아보기
엔지니어링 일지 작성을 통해 개인 회고 진행(일부 내용 공개)
이 외에도 내가 할 수 있는 것을 찾아보니
위와 같은 노력과 학습을 통해서 다양한 일들을 경험하며, 이 외에도 내가 할 수 있는 것들이 많이 있다는 것을 알았습니다. 엄청나게 많은 것들 중 일부를 공유해드리면 다음과 같습니다.
- Django ORM 효율성 극대화하기
- 에러 핸들링 세분화
- 이메일 발송과 관련한 파편화된 알림 도메인 모으기
- Text Editor 라이브러리 교체
- QA 환경 개선
- Mocking 환경 구축
- 복잡해지는 도메인 지식에 따라 서비스 레이어별 분리
- 개발가이드 개선
- Python, Django, DRF 버전 업그레이드
- 비즈니스 팀 — 메이커 조직 — 엔지니어 조직 간 업무프로세스 개선
- …
깨달음: 열심히 하긴 했는데 나의 리소스는 한정되어 있네..?
많은 일들을 경험하고 또 내가 할 수 있는 일들을 정리해보면서 생각보다 기여할 수 있는 것들이 많다는 것을 알게 되었습니다.
하지만 더불어 나의 리소스는 한정되어 있다는 사실도 알게 되었어요. 법정 근로 최대 시간인 주 52 시간을 넘기고 싶지 않았고, 사실 그 이상 하려고 해도 번아웃을 가져올 수 있다는 것을 경험했거든요.
지금보다 더 성장하고 더 많은 기여를 하고 싶은데, 이를 위해 더 많은 시간을 투자해야 한다는 현실을 마주하게 되었습니다. 지금보다 더 많은 시간을 투입할 수 없음에도, 내가 해야 할 일과 성장해야 할 부분이 많다는 것을 깨달았습니다.
이런 무한한 도전과 성장의 과정에서 끝이 보이지 않는 러닝머신에 있는 것 같은 느낌을 받으며 번아웃이 점점 더 가까워지는 것 같았습니다.
(이 때 번아웃을 조금 경험하고 다른 엔지니어들은 어떻게 이러한 도전을 극복하고 있는지 고민하면서 쓴 글이 Developer Imposter Syndrome 이었습니다.)
그래서 저는 “내가 사용할 수 있는 리소스는 한정되어 있다”를 인정하고 팀의 생산성과 성장에 대한 고민을 시작했습니다.
3. 팀의 생산성과 성장에 대한 고민
“개인의 생산성을 10배 향상시키자”라는 접근에서 시작해서 “나의 시간과 리소스는 한정되어있다”를 인정하니 그 다음은 “나의 생산성 뿐만 아니라 팀원들의 생산성을 향상 시킬 수 있는 방법을 찾아보자”는 생각이 떠올랐습니다.
단순하게 아래처럼 정리하고 생각을 해봤어요.
정리하고나니 한층 더 명확하게 “더하기에서 곱하기가 되는 엔지니어가 되어야겠다.”는 생각이 강해졌습니다. (같이 일을 하기만 해도 능률이 향상되는 토템 같은 느낌이 드는 엔지니어가 되야겠다는 생각을 해봤습니다)
이제는 곱하기 엔지니어로 성장하고 싶어!
기존에는 ‘내가 어떻게 하면 일을 잘 할 수 있을까?’가 고민이었다면 그 다음 단계는 동료와 팀을 생각하면서 자연스럽게 내가 바라보는 시선의 높이를 위로 올리고 임팩트를 만들어내는 것을 고민하기 시작했던 것 같아요.
그러면서 아래와 같이 시선의 높이를 높여가는 방식을 고민하기 시작했습니다.
- 나랑 같이 일 하는 스쿼드 내 BE 엔지니어들과 일을 더 잘 하기 위해서 무엇을 해야하지?
- 나랑 같이 일 하는 스쿼드 내 엔지니어들과 일을 더 잘 하기 위해서 무엇을 해야하지?
- 나랑 같이 일 하는 스쿼드 내 모든 동료들과 일을 더 잘 하기 위해서 무엇을 해야하지?
- 백엔드 챕터 구성원들이 2배의 성과를 내기 위해서 무엇을 해야하지?
- 엔지니어링 그룹 구성원들이 2배의 성과를 내기 위해서 무엇을 해야하지?
- 레몬베이스팀 구성원들이 2배의 성과를 내기 위해서 무엇을 해야하지?
처음부터 5번, 6번을 하면 좋겠지만 쉽지는 않기 때문에 1번부터 순차적으로 어떤 것들을 할 수 있을지 고민해보기 시작했습니다. 그리고 시선의 높이를 개인에서 동료와 팀으로 옮기니 아래와 같은 고민들을 자연스럽게 하게 되었습니다.
- 어떻게 하면 제안부터 결정까지의 속도를 빨라지게 할 수 있을까?
- 어떻게 하면 같은 것을 구현할 때, 더 빠르게 구현하게 할 수 있을까?
- 어떻게 하면 의견 충돌이 있을 때 더 빠르게 해소가 되도록 만들 수 있을까?
- 어떻게 하면 엔지니어링 그룹의 문화를 구성원들이 더 주도적으로 만들어가도록 할 수 있을까?
- 어떻게 하면 신규 입사자분들이 더 빠르게 기술적으로 온보딩 될 수 있도록 만들까?
어떤 건 사람을 위한 고민도 있고, 조직 문화적인 고민도 있고, 실무적인 고민들도 생기면서 차근차근 내가 기여할 수 있는 것들을 찾아보기 시작했습니다.
곱하기 엔지니어가 되기 위한 여정
곱하기 엔지니어가 되기 위해 진행했던 것들을 간략하게 소개하려고 해요.
특히 열린 조직 문화와 동료의 성장에 진심인 팀 동료들과 함께 진행하면서 많은 도움을 받을 수 있었고, 더 시너지가 났던 것 같습니다.
(1) 시간 절약 도구 개선
제일먼저 기술적으로 팀원들의 시간을 절약하여 팀 생산성을 올릴 수 있는 도구에 투자를 해보았습니다. 아래와 같은 활동들을 진행했습니다.
- CI/CD 환경 + 성능 개선
- “지금 테스트서버 쓰시는 분?” (GitOps로 브랜치별 배포 시스템 구축하기) (1/2)
- “지금 테스트서버 쓰시는 분?” (GitOps로 브랜치별 배포 시스템 구축하기) (2/2) - 테스트 코드 성능 개선
- 170초 -> 43초 속도 개선
- 복잡한 테스트코드를 쉽게 생성, 관리할 수 있도록 모듈화 적용 - 개발 가이드 문서화 및 적용
- 백엔드 개발 가이드 문서화 후 점진적으로 모든 도메인 로직에 대해 백엔드 가이드 적용 - 레몬베이스 제품 보안 취약점 분석 후 대응 후 지식 공유
- Python Version Upgrade를 통한 Python 성능 향상
- 공통 영역에 해당하는 기능들을 집중적으로 성능 개선 진행
- 엑셀 다운로드 기능 (2.33초 -> 1.15초 성능 개선)
- 엑셀 업로드 기능(30초 -> 1초 성능 개선)
(2) 긍정 문화 전파
- 다양한 구성원들과 주기적으로 1:1 미팅 진행
- Stop, Start, Continue 피드백 주고 받고, 개선 Action Item 만들기
- 업무적, 개인적인 부분 상관없이 서로 도움을 줄 수 있는 부분 찾아보기
- 구성원들의 현재 상태를 1:1 미팅할 때 마다 헬스체크 진행해보기
- 만다라트 목표 설정 or 커뮤니케이션 관련 독서 스터디 진행 - 서로간의 이해를 높일 수 있는 스터디 시작
- 디자이너와 엔지니어가 함께하는 북 스터디(디자인, 엔지니어 서적을 번갈아가면서 같이 스터디 진행)
- 비엔지니어들과 함께하는 HTML + CSS + JavaScript 스터디
- 엔지니어들과 함께하는 AWS 스터디
(3) 엔지니어 문화 개선
- 엔지니어 온보딩 프로세스 개선 후 문서화 진행
- 엔지니어 배포 프로세스 개선 후 문서화 진행
- 스쿼드 내 엔지니어 헬스 체크 + 스터디 문화 구축
- API 문서화 + 개발 가이드 문서화 개선 진행
(4) 회색 지대 영역 + 실무 영역 개선하기
- 공통 도메인 영역 + 레거시 코드로 인해 모두가 개선하기 어려워하는 부분들을 개선 진행
- 특히 엑셀 다운로드, 업로드와 관련해서 모듈화를 통해 관련한 VOC 유입건도 줄어들었음
- 테스트코드 실행 시 Slow Test Code Top 10을 찾아서 출력하도록 개선
이 외에도 곱하기로 기여할 수 있는 많은 일들
- 지금보다 더 확장성 있는 디자인 시스템 (LDS)
- 반복적인 업무에 대한 자동화 — 엔지니어 조직 뿐 아니라, 다양한 조직들에게 필요한 것들
- 정보의 흐름과 공유 빈도 + 지식 시스템 개선
- 프론트엔드 / 백엔드 인프라 독립
- …
더 높은 임팩트를 만들기 위한 고민
이런 작업들을 하다보니 곱하기로 기여할 수 있는 업무들도 더하기처럼 너무 많았고, 성공적인 제품을 만들기 위해서 Maker로서 해야할 일도 너무 많았습니다. 또, 혼자 시간을 쏟아 해결하기 어려운 문제들도 많이 있다는 것을 알게되었습니다.
최선을 다하는 것도 중요하고, 최선을 다해 다방면 노력하다보면 노력의 성과를 받을 수 있을 것이라 생각하기 쉽지만 사실 그렇지 않은 경우들도 많이 있었습니다. 내가 예상했던 것 보다 높은 임팩트를 만들어내지 못했던 것들은 “이것을 할 시간에 저걸 했더라면..” 라는 아쉬움이 생겼습니다.
이런 고민들이 반복되면서 이미 최선을 다하는 사람에게는 더 중요한 것이 있다는 사실을 깨달았습니다. 크게 요약하면 아래와 같습니다.
- 내가 해야하는 것들의 무게는 동일하지 않다
- 모든 과업을 훌륭하게 할 수 없다.
- 내가 하는 과업의 Impact를 높이고, 업무에 수반되는 스트레스를 줄여야한다.
- 더 많은 노력이 반드시 더 많은 영향력을 의미하지 않는다. 시간은 가장 제한적이고 중요한 자원이다.
(Doing great work != Putting in your best effort for everything)
이런 사실을 깨닫고, 내가 할 수 있는 것들 중 같은 시간을 투입했을 때 임팩트가 더 큰 업무들을 찾아야겠다는 생각을 하기 시작했습니다. 그리고 임팩트를 판단하는 것이 중요하다는 사실을 깨달았습니다.
💡 Impact = Leverage 라고 생각해요
- 지렛대는 평범한 사람도 무거운 것들을 움직일 수 있게 한다
- Leverage 가 높은 작업을 식별하는 것이 중요하다.
- 파레토 원칙: 20% 작업을 통해 80% 효과를 만들어내자
Eisenhower Matrix + LNO Framework 사용
저는 임팩트를 판단하기 위해 아이젠하워 매트릭스와 LNO 프레임워크를 많이 사용했는데요. 간략하게 소개드리면 다음과 같습니다.
Eisenhower Matrix는 긴급성과 중요도에 따라 작업을 결정하고 우선순위를 지정하는데 도움이 되는 분류 방법입니다. 위임해야 하거나 전혀 수행하지 않아도 되는 덜 긴급하고 중요한 작업을 분류하는데 많이 사용해요.
LNO Framework는 해야할 일의 목록을 Leverage에 기반해 측정할 수 있도록 도움을 주는 방법인데요
Leverage에 해당하는 것은 작업을 완료했을 때 들어간 노력 대비 10배의 결과를 창출할 것으로 예상되는 작업입니다.
-> CI/CD 개선, 브랜치별 배포 시스템 등이 해당됩니다.
Netural에 해당하는 것은 작업을 완료했을 때 들어간 노력과 성과가 동일한 작업을 의미합니다. (수행할 가치가 있지만 큰 결과는 기대하지 않는 일)
-> 리팩토링, 테스트 코드 성능 개선 등이 해당됩니다.
Overhead 작업은 노력 대비 성과가 작아 수행할 가치는 없지만 수행해야하는 작업을 의미합니다.
-> Text Editor 라이브러리 교체 등이 해당됩니다.
이런 방법들을 활용해서 현재는 같은 시간을 활용했을 때 어떤 것이 더 높은 임팩트를 가져오는지 판단해서 작업을 진행하고 있어요.
이런 고민들을 하는 과정에서 배운 점
그 외에도 다양한 고민들을 하는 과정에서 배운점을 공유드리면 다음과 같습니다.
- Fixed Mindset -> Growth Mindset은 생각보다 정말 중요하다
- 만약 주변 동료들이 내가 바뀌지 않는 사람이라고 생각했더라면?
- 만약 내가 “어차피 난 해도 안될거야..”라고 생각했더라면? - 학습 속도에 대한 투자 → 천천히 꾸준히 올바른 방향성을 가지고 접근하는게 중요하다
- 복리의 법칙은 배신하지 않는다
- 높은 영향력을 행사하려면 장기간에 걸쳐 일관된 노력을 기울여야 한다. - 중요하고 긴급한 일에 집중해야한다.
- 긴급성과 중요성을 혼동하지 않는 것이 중요하다
- 레버리지가 높은 활동과 손쉬운 활동을 혼동하면 안 된다. - 작은 단계를 하나씩 거치는 방법
- 한 번에 큰 단계가 아닌, 점진적으로 거쳐가는 방법 (분할정복) - 일정 보호하는 것도 좋은 전략이었다.
- 수요일 회의 없는 날
- 내가 필요없어도 되는 회의라면 참석하지 않는 결정을 내리기 - 내가 진행 중인 작업 양을 제한하기
- 지속적인 컨텍스트 스위칭은 깊은 참여와 몰입을 방해하여 성공 가능성 감소
- 내가 너무 많은 일을 하는거 같은데..? 그럼 멈춰야한다
- “최고의 성과를 내는 팀을 만드려면 85%의 노력을 하는 것이 중요하다”는 점을 인식하기(To Build a Top Performing Team, Ask for 85% Effort) - 우선순위 습관화
- 내가 하는 업무들에 대한 우선순위를 항상 판단해야한다.
- 레버리지 포인트를 찾는 것을 습관화해야한다. - 반복 속도에 대한 투자 (시간 절약 도구 투자)
- 반복적으로 불편함을 느끼는 부분은 개선해야한다. - 회사의 성장이 개인의 성장을 의미하지 않는다.
- 그때는 맞았지만, 지금은 다를 수 있다.
- 내가 가진 한계를 잘 이해하고 주어진 리소스 안에서 최선을 다해 나아가는 것은 중요하다.
더 많은 동료와 협업하는 것도 중요하다
- 동료의 병목이 어디이고 + 동료의 부족한 점이 무엇인지 파악해서 성장을 위한 피드백을 서로 잘 주고받아야한다.
- 이 과정을 통해 커뮤니케이션과 리더십 스킬 향상될 수 있었다.
- 리더십이라는 것은 꼭 리더만이 발휘할 수 있는 영역은 아니다. 동료로서 충분히 리더십을 발휘할 수 있는 영역이 있다.
- 내가 저주받은 토템이라서 나와 함께 일하는 모든 사람들의 능력치가 하락되고 있는지는 아닌지 피드백을 통해 점검을 잘 해야한다. (무엇이 문제인지 아는 것은 중요하다) - What이 How보다 더 중요하다
- 함께 성장하는 생태계를 구축하기 — Growth Mindset
- 블로그, 공유, 1:1 미팅, 채용, 문화, 온보딩 등 다양한 영역에서 많은 영향력을 넓게 기여하고 전파하는 것이 중요하다.
남은 고민들
- 나의 시간을 Leverage 활동에 보다 집중해서 성장의 질을 향상시키려면 무엇이 우선순위가 높은지 더 판단이 필요함
- 반복 속도 최적화, 자동화 구축, 높은 추상화, 코드 품질에 대한 지식과 노하우를 쌓아야함
- 존중할 수 있는 팀 문화와 집단적 지혜를 구축하기 위한 고민이 필요함
- 메이커로서의 실용주의와 엔지니어로서의 품질의 균형을 잘 판단하도록 노력해야함
결론
이런 깨달음을 통해 여전히 어렵지만 이전보다는 제가 가진 자원을 효율적으로 활용하는 방법을 얻을 수 있었습니다. 제가 겪은 경험들이 여러분들에게 앞으로 더 많은 영향력을 끼치는 엔지니어로 성장할 수 있도록 도움이 되면 좋겠습니다.
- 더 높은 임팩트를 만들어내기 위한 성장을 하는 것이 중요하다
- 개인의 성장에서 시야를 높여 팀, 조직을 위한 성장에 기여하는 것이 더 큰 임팩트를 만들어내는 일이다.
- 기술적 성장 뿐 아니라 문화, 커뮤니케이션 등을 통한 기여도 중요하다. (결국 사람이 하는 일)
- 더 큰 임팩트를 만들기 위한 일의 기준을 생각해야한다.
- 메이커와 엔지니어로서의 균형을 잘 판단할 수 있어야한다.
- 내가 중요하다고 생각하는 것을 혼자 열심히 하는 것보다 팀에서 중요하게 여기는 것을 분류하고 함께 잘 해결할 수 있는 방법을 찾는 것이중요하다.
글을 마치며 레몬베이스 팀은 엔지니어 채용을 적극적으로 진행 중입니다.
성장에 진심인 분들, 더 나은 세상을 만드는 좋은 제품을 만드는 데 관심이 있는 분들의 많은 지원을 기다립니다! :) [채용 공고 바로 가기]
