이번주 점수는? ⭐⭐⭐
😍 좋았던 것(Liked)
스스로 어떤 가치를 지니고 있는지 알아가는 요즘
개발자를 시작하면서 이게 맞는 선택일까 고민하고 좌절하던 날이 많았다. 정글에 있을 때 동굴을 깊은 바닥까지 찍고 나서일까, 요즘은 내가 개발자에 어울리는 사람인지에 대한 고민이 옅어졌다. 정확히는 맞지 않는다는 걸 잘 알아서인듯(?). 보다 정확히 말하면, 모든 면에서 개발자에 적합한 사람은 아니라는 걸 깨달았기 때문이다. 뭔가 역설적인데, 반대로 말하면 내가 어떤 가치를 가진 사람인지를 가면 갈수록 깨닫고 있는 요즘이랄까.
요근래 다양한 업계 사람들과 만나는 일이 잦다. 천성이 사람들과 이야기하는 걸 좋아하는지라 어딜 가나 왁자지껄 분위기를 띄운다. 그렇게 자리를 좋게 만들고 나면, 덕분에 긍정적인 에너지를 받았다는 피드백을 늘상 듣는다. 어렸을 때는 그냥 너랑 놀면 재밌다 정도였는데, 갈수록 이 성향이 매우 희소한 가치라는 걸 느낀다. 특히나 개발자 사이에서는 더더욱.
그러면 개발자 하기 힘들지 않냐, 일할 때는 늘상 컴퓨터랑 있어야 하는데 괜찮냐는 얘기를 들을 때가 있다. 그런데 아이러니하게도 일할 때는 조용히 있는 게 더 좋더라(?) 놀 때는 미친 듯이 놀고 일할 때는 정적으로 하니까 오히려 밸런스가 잘 맞는듯. 게다가 깨달은 게 하나 있다면 나는 공부하는 걸 좋아한다. 정확히는 모르는 걸 알아갈 때 희열을 느낀다. 끊임없이 자기계발해야 하는 이 업계가 정말 잘 맞는다(아직까지는..). 역설적으로 전에 있던 분야는 배움의 속도가 느려 재미가 없었다. 자극이 전혀 오지 않더라. 그런데 여기는 하루라도 공부하지 않으면 안될 것만 같은 그 속도가 오히려 좋다. 그러니 공부하자(제발).
📚 배운 것(Learned)
동료를 믿는다는 것
백엔드 리드님과 1개월 차를 넘긴 시점에서 인터뷰를 했다. 그동안 무엇을 공부했고 어떻게 진행했는지에 대해 말씀드리는 시간을 가졌다. 이것저것 열심히 했고 더 잘하기 위해 이런 노력을 하고 있다고 상세히 말씀드렸는데, 전혀 예상치 못한 반응이 나왔다.
“부담을 줄이자.” 그렇게 가혹하게 하지 않았으면 한다는 말씀을 해주셨다. 사실 불안한 게 하나 있었다. 엄연히 지금은 수습 기간이고, 이 기간 안에 과제를 수행하지 못하면 나갈 수도 있지 않을까 하는. 그걸 정확히 캐치하셨더라. 자바/스프링 안 배운 거 뻔히 알고, 그거 금방 배울 수 있는 게 아니라는 것도 아신다고. 3개월 해보고 “이 ㅅㄲ 각 안나오네!”하고 내쫓지 않는다고. 제로 베이스인 거 알고 데려왔다고.
사실 이 말을 이때만 해주신 게 아니었다. 처음 들어왔을 때도 그러셨고, 중간에도 말씀해주셨다. 그런데 이날따라 이 조언이 새롭게 들린 건 관점이 바뀌었기 때문이다. “나도 이 말을 믿어야 된다”. 조바심 내고 더 잘하려고 발버둥치는 건 어떤 면에서는 동료를 믿지 않는 것과 다름없다.
혼자 애쓰는 건 어떤 면에서는 동료를 믿지 않는 것이다. 동료가, 사수가 멀리 보고 천천히 뛰자고 했을 때, 동료를 믿는다면 온전히 내 등을 내줘야 한다. 내 등을 내준다는 건, 말 그대로 내 약점을 보여주는 것이다. 나 이만큼이나 하고 있다고 포장하지 않고, 있는 그대로 현재 이 상태라 말할 수 있는 것. “나 지금 이런 상태니까 이해해줘 알았지?”라고 할 수 있는 것.
열심히 하지 않겠다는 건 절대 아니다. 다만 옆 회사에 신입이 입사 3일차에 배포를 했네 마네에 흔들리지 않고, 못하면 3개월 이후에 짐 쌀 수도 있겠다는 불안감을 원동력으로 삼지 말자. 온전히 동료를 믿고 하루하루 정진하자. 3개월 마라톤하려고 여기 온 거 아니다.
백엔드팀 KPI 산정이 어려운 이유 & 개발자가 개발만 하면 안되는 이유
현재 우리 회사는 기능 중심(프로덕트팀, 엔지니어링팀, …)으로 팀이 나뉘어져 있다. 물론 목적 중심으로도 나뉘긴 하나 사실상 큰 의미를 지니지는 않는다. 그러다 보니 전사 KPI와 별개로 백엔드팀 KPI를 산정할 때 여러 어려움을 겪었다. 이를 어떻게 해결하면 좋을까 싶어 리서치를 하다가 좋은 아티클(링크)을 발견했다. 앞부분을 요약하면 아래와 같다.
회사에서는 팀을 꾸릴때 기능별로 분리하는 경우가 많은데, 이렇게 하면 아래와 같은 문제가 발생한다.
- 팀의 역할과 책임, 회사의 방향 그리고 프로덕트 자체의 니즈가 종종 충돌한다.
- ex) 프론트 팀 책임 영역: 웹사이트가 브라우저에서 잘 동작하게 하는 것 vs. 회사에서 중요하게 생각하는 영역: 수익/매출/사용자 지표 등
- 프로덕트 지표와 회사의 니즈는 거리가 가까운 반면, 개발팀과 회사의 니즈는 거리가 멀다.
- 다른 기능 조직의 역할에 공감을 하기 어렵다.
- 요청을 받아서 일을 시작하는 개발팀 입장에서 다른 모든 조직은 왜 자꾸 일을 가져오는지 귀찮은 존재
- 개발팀이 나빠서가 아니라 개발팀으로 일을 하게 될때 이런 정체 현상이 자연스럽게 발생
- 팀의 전문성이 없다.
- 회사 입장에서 팀의 전문성은 매출과 연결할 수 밖에 없음
- 반면 개발팀의 전문성은 매출과 상관관계는 있으나 인과관계가 없음 -> 개발 잘한다고 회사가 돈을 더 버는 건 아님.
이를 해결하기 위해 기능 단위가 아닌 목적 중심으로 팀을 나누어야 한다는 게 위 아티클의 내용이다. 읽으면서 또 한 번 느꼈다. 개발자가 개발만 잘하는 건 아무 의미 없구나. 물론 이런 거 신경 안쓰고 말 그대로 개발만 하고 싶어하는 사람도 있을 수 있겠다. 하지만 결국 개발을 하는 이유는 비즈니스 가치를 구현하기 위해서인데, 단순히 개발만 하면 안되는 게 이런 거구나. KPI 산정 잘하는 것도 매우 중요하고 이걸 잘하기 위해서 팀의 구조에 대해서 고민하는 것도 중요하다. 비즈니스와 협업을 고려할 줄 모르는 개발자가 어디까지 갈 수 있을지는 글쎄..주니어만 넘어서도 이런 고민을 하지 않으면 안될 것 같은데.
코딩 자동화 툴의 퀄리티가 갈수록 좋아지고 있다. 깃허브에서 나온 코파일럿은 퀄리티가 상상을 초월하는데 무료로 배포되고 있다. 얼마 전에는 아마존에서도 코딩 툴을 발표했다. 갈수록 하드 스킬은 쉽게 대체될 것이다. 노코드 툴의 퀄리티는 또 어떨까. 스프링 잘 치네, 자바 잘 쓰네 이런 거 자랑하는 개발자는 한 5-6년 안으로 싹다 물갈이될 가능성이 높다. 겨우 6년 밖에 안 걸린다고 생각했다면, 겨우 6년 전에 알파고 나왔다는 사실을 잊지 말자.
하지만 기술을 활용해 비즈니스 가치를 생산하는 건 별개의 문제다. 코딩만으로 사용자들에게 가치를 주는 제품이 탄생하진 않는다. 이건 단순히 하드 스킬만으로 해결될 수 없는 영역이다. 그 사이를 메꿀 사람들이 갈수록 많이 필요해질 것이다. 오히려 소프트 스킬이 풍부한 사람들이 5-10년 뒤에는 더욱 개발자를 해야 하는 세상이 올지도..? 알다가도 모를 세상이다 진짜.
1년차 백엔드 엔지니어로서 방향성(by 향로)
위에 ai 툴이네, 소프트 스킬이네 했지만 일단은 백엔드 엔지니어로서 소프트웨어 엔지니어링의 기반을 잘 다져야 하는 사실은 변함없다. 예전부터 변함없는 생각인 게 어떤 분야든 ai를 다룰 줄 아는 사람과 그렇지 않은 사람으로 나뉜다. AI/ML은 극소수의 모델링 디자이너와 나머지 대다수의 AI/ML 엔지니어로 구성되어 있다. <AI 홀릭> 유튜브에도 나오지만 뤼이드 AIOps VP셨던 크리스님 가라사대, ML 엔지니어 하려면 백엔드부터 손대라 하셨다. AI/ML 쪽에는 매우 얕지만 공부해둔 게 있으니, 백엔드/데이터 엔지니어링 역량을 앞으로 3년간 잘 쌓는다면 그 이후부터는 걱정이 없을 것. 일단 지금은 하드 스킬을 잘할 줄 알아야 한다.
향로님께서 말씀하셨던 1년차 백엔드 엔지니어가 가져야 할 방향성을 늘 새기려고 한다. 자세한 내용은 링크에 있으나 다시 한 번 더 새기자면.
1. 마인드셋: 사냥개 같은 집요함
→ 맡은 문제는 어떻게든 해결하고야 말겠다는 강한 집념
2. 격리된 테스트 환경 구축 반복
→ 첫번째로 연습할 것은 회사의 코드가 아닌, 나만의 코드로 문제 상황을 재연해보는 연습
3. 사용하는 시스템 디버깅 방법(이펙티브 디버깅, Debug It - 실용주의 디버깅)
→ 서비스 회사에서 일하고 있다면 만드는 것 보다 중요한게 사용하는 시스템의 문제를 해결 하는 능력
이다. 늘 보고 또 보면서 잘하고 있는지, 더 잘할 수 있는 건 없는지 새기려고 한다.
여기에 추가로 1년 동안 공부하고 싶은 것을 정리하면 아래와 같다.
- 김영한님 스프링 강의
- 오브젝트
- 자바 ORM 표준 JPA 프로그래밍
- 이펙티브 디버깅
- 실용주의 디버깅
- 인텔리J 사용법 강의
- 토비의 스프링 Vol.1
💦 부족했던 것(Lacked)
1일 1커밋 놓침(그것도 2번이나…)
왜 놓쳤을까? 놓친 것 자체가 중요한 게 아니다. 무엇이 문제였고, 왜 문제가 일어났으며 앞으로는 어떻게 하면 좋을지를 고민해야 한다.
시작은 회사에서 더이상 공부만 하지 않게 되면서였다. 사내 프로젝트 코드를 다루기 시작하니 개인 깃허브 계정에 커밋할 일이 없어졌다. 이는 즉 따로 시간을 내서 다른 공부를 반드시 해야 해결할 수 있는 문제이다.
그렇다면 업무 시간이 아닌 아침 혹은 저녁 이후에 공부를 해야하는데, 지난 주에는 매일 저녁에 약속이 들어찼다. 그러다 이틀이나 빼먹게 된 것. 즉, 저 이틀 동안은 따로 공부를 하지 않았다는 뜻이 된다.
공부를 하지 않았다면 자책이 아닌 왜 공부를 못했는지, 앞으로는 어떻게 할 수 있을지를 고민하면 된다. 그런데 반성해야 할 건 마인드셋이었다. 처음에 놓쳤다는 걸 깨닫고는 “에이, 날짜 수정해서 올려야겠다.”는 생각이 가장 먼저 떠올랐다. 이게 중요한 게 절대 아니다. 매일 커밋 올렸다는 사실이 중요한 게 아니다. 이 글(방향성이 명확한 노력으로 나만의 색깔을 가진 사람이 되기)에서도 잘 나와있으니 꼭 읽어보도록 하자.
자, 그러면 어떻게 공부를 매일 할 수 있을까? 오는 주는 저녁에 약속이 따로 잡혀있지 않아 저녁에 공부 시간을 확보할 수 있다. 하지만 저녁 시간은 늘 불규칙적이다. 반면 아침은? 그래서 지금은 아침에 운동하고 밤에 공부를 했다. 문제는 우선순위다. 현재로서는 공부가 훨씬 우선순위가 높다. 그러니 반대로 가자. 아침에 공부하고 밤에 운동해야 된다.
🕯 바라는 것(Longed for)
아침에 공부하기(중요한 걸 먼저 하자)
- 오는 주는 저녁에 공부 시간을 확보할 수 있는 날을 제외하고 아침에 2시간 동안 공부하고 출근한다.
'회고록 > 주간 회고' 카테고리의 다른 글
| [동료 피드백 회고]팀원들이 본 3개월 간 내 본모습은? (0) | 2022.08.14 |
|---|---|
| 7월 4주차(7/18 - 7/24) 회고 (0) | 2022.07.26 |
| 6월 3주차 회고(6/13~6/17) (0) | 2022.06.21 |
| 6월 2주차 회고(6/6~6/10) (0) | 2022.06.13 |
| 6월 1주차 회고(5/30~6/6) (0) | 2022.06.07 |