Table of contents
⚠️ 극히 개인적으로 느낀 것들 입니다. 가볍게 지나가 주세요. (_ _)
감격스로운 카카오 공채 합격이 엊그제 같은데 벌써 1년이 지나 있다.
"와,, 이렇게 물경력이 쌓이는 것인가,,," 생각이 들기도 했지만 돌아보면 정말 많은 것들이 있었다.
조금은 진부하지만 그간의 경험과 생각을 조금이나마 기록해보고자 한다.
나의 타임라인
무엇을 했는지 정리하려면 역시 타임라인만한 것이 없다.
모든 것을 담아내기 어렵지만 그래도 큼지막하게 정리해보았다.
| 연도 | 이벤트 |
|---|---|
| 21.11.29 ~ 22.02 | 카카오 입사 ✨ 온보딩 진행 |
| 22.03 ~ | 브런치 서비스 합류 |
| 22.04 ~ 05 | grunt -> webpack 전환, 테스트 코드 도입 |
| 22.06 ~ 07 | 모니터링 시스템 고도화, 개발 컨벤션 재구축 |
| 22.08 | 제 10회 브런치북 출판 프로젝트, MVI |
| 22.09 | if kakao 촬영 "브런치 심폐소생술" |
| 22.10 | 🏢🔥 |
| 22.11 ~ 12 | 경로 리소스 대청소 |
카카오 온보딩
공통 온보딩, 직무 온보딩, 기술 온보딩 과정으로 3달 가까이 교육이 진행되었고
CodeSquad의 크롱이 1달 동안 기술 온보딩(FE 교육)을 맡아주셨다.
사실 다른 것은 거의 기억이 안나고 기술 온보딩 때 열심히 삽질한 경험이 남게 되었던 것 같았다.
좋았던 것은 그저 숙제에 대해 점검하는 것이 아닌 과제의 큰 틀만 주고 스스로 탐구하고픈 영역을 설정하고 이를 점검해주는 형태로 교육이 진행되었다는 것이다.
그러면서 평소 접하기 힘들었을 BEM, Glassmorphism, VAC 패턴, stitches 등을 사용해볼 수 있게 되었다.
- w1
- https://github.com/bepyan/fe-w1-kakaopage
- HTML 마크업
- vanillaJS
- w2,3
- https://github.com/bepyan/fe-w23-shoppinghow
- vanillaJS (+ throttle)
- babel, webpack
- BEM styles rules
- w4
- https://github.com/bepyan/fe-w4-vending-machine
- React
- Glassmorphism
- w4,5
- https://github.com/bepyan/fe-w4-issue-tracker
- express (JWT, OAuth)
- React (+ VAC 패턴)
- stitches
교육이 진행되면서 기술공유해주는 세션이 있는데 css-in-js 라이브러리를 조사한 것을 정리해서 발표를 했고 velog 글로도 정리를 했었다. 생각보다 정리한 글이 여러 사람에게 도움이 된 것 같아 많이 뿌듯했다.
돈을 받고 편하게 공부를 한다니,, 개인적으로 이 때가 가장 걱정없이 편하게 시간을 보냈던 것 같다. 물론 그 당시엔 학습에 찌들렸던...
브런치 레거시 개선
올해는 브런치 레거시 환경과 내내 싸웠다고 봐도 무방한 것 같다. 이게 if kakao 발표까지 가게될지도 몰랐다..
대충 한마디로 요약하자면 webpack을 도입하여 es6 기반의 코드를 쉽게 작성할 수 있게 되었다.
발표에 대해서도 좀 할말이 많다만..
지금 다시 생각을 정리해보면 발표 때와 생각이 많이 바꿨다. 조금 옛날스러운 javascript의 구현 방식은 사실 큰 문제가 아니였다. 브런치가 관리하기 어렵게된 것은 결국 Java와 Javascript 진영간의 괴리이다.
브런치는 기본적으로 SSR로 서비스를 제공한다.
서버 사이드의 데이터를 템플릿 엔진(velocity)을 통해 마크업을 다루거나 js 단으로 데이터를 넘긴다.
js 단에서는 또 뷰 엔진(handlebars)를 활용하여 마크업을 다룬다.
이 과정을 제대로 이해하기 못한 상황에서 이슈를 대응하려하니 머리가 터지게 되는 것이다.
문제를 해결하려면 탐색해야하는 파일들이 무척이나 많고 4개의 문법을 넘나들고 개발 편법까지 이해해가야 했다.
사실 이들(velocity, handlebars)는 요즘것들에 비해 문법이 유연하지 못하고 intellisense가 부실해 개발자가 실수하기 무척 쉽다. 실제로 관련해서 크게 손대다가 4번의 prod hotfix를 진행한 경험이 있다..
javascript 내에서의 로직은 이에 비해 사소했던 것 같다. 어짜피 비즈니스 로직이 복잡해지면 ES6든, ES3이든 다루기 어려운 코드가 된다. 해법은 프레임워크, 라이브러리의 도움을 받는것...
이 괴리를 줄이기 위해서 초기에는 패턴을 도입해서 js 중심으로 리팩토링을 하려했으나, 이젠 velocity에서의 Java를 잘 사용하기, svelte 도입하는 방향으로 나아가려하고 있다.
그리고 테스트 코드에 대해서도 솔직한 한마디를 메모하자면, TDD를 하지 않으면 테스트 코드는 실질적인 도움이 되진 않는다. 다만 명분이 좋아 다른 사람들에게 이를 쉽게 내세울 수 있다.
사내 스터디, 행사
카카오답게 자유롭게 스터디, 행사에 참여할 수 있었다.
- 리팩토링 2판 독서 스터디
- 헤드 퍼스트 디자인 패턴 독서 스터디
- phaser3로 javascript 게임 만들기 스터디
- 북마크(기술 블로그 글) 공유 스터디
- if kakao 세션 발표
- K24 해커톤
- 함께 자라기 (DND 마스터 시리즈, 블로그 제작기)
- 6 nimmt! 보드게임 알고리즘 행사
- 단체티 제작 TF
- 팀 정기 발표
하나 하나 느낀 점들이 있지만 글로 정리하기엔 끝도 없을 것 같다.. 이래서 분기별로 글을 정리해야 하나..
이 역시 한마디 메모하자면 남한테서 얻어내려하기 보단 스스로 탐구해 가려 할 때 더 많은 수확이 있었던 것 같다.
나의 깨닳음
생각을 정리하면서 맺혀지는 깨닳음이 있었다.
성장이란 무엇인가?
신입 개발자로서 '성장'은 정말 중요한 키워드인 것 같다.
회사를 선택할 때 고려되는 가장 중요한 것 중에 하나이다.
그렇다면 과연 성장이란 무엇이고 난 카카오에서 1년간 얼마나 성장했을까?
성장에 대해 정말 다양한 정의를 내릴 수 있지만 개인적으로 soso님의 정의가 가장 마음에 와닿았다.
"나만의 관점이 많아지는 것" > https://so-so.dev/essay/no-silver-bullet/
크게 두 가지 의미를 내포하는 것 같다.
첫번째는 지식과 경험은 우리로 하여금 관점을 갖게 한다는 점이다.
우리는 늘상 새로운 지식을 습득하고 경험이 축적된다. 그리고 지식과 경험은 우리로 하여금 관점을 갖게 한다.
지식이 없으면 그 어떠한 판단을 내릴 수 없고 경험이 없으면 결과에 대해 예측하기 어려운 이유이기도 하다.
아래와 같은 간단한 예시를 들 수 있을 것 같다.
webpack는 번들링과 컴파일에 있어 상당히 유연한 설정을 갖추고 있다.
: webpack으로 파편화된 번들, 빌드 과정을 통합시켜 목표하는 코드 베이스를 쉽게 구축할 수 있다.
==가 ===로만 바꿔도 사이드 이펙트가 발생될 수 있다.
: 무턱 레거시 코드에 eslint auto fix를 돌리면 사고가 일어날 수 있다.
이런 작은 지식, 작은 경험이 하나 하나 축척되어 큰 관점을 갖게 되기도 한다.
이를 테면 '좋은 코드란 무엇인가?', '리팩토링을 어떻게 해가는게 좋을까?'와 같은 무거운 질문에 대한 관점이다.
관점을 갖춘 개발자는 매력적이다. 정답이 없는 상황을 명확한 기준으로 헤쳐가기 때문이다.
공채면접에서도 이를 느낄 수 있었다. 기업은 단순히 전문 지식을 많이 갖춘 지원자가 아닌 기술적인 연관관계, trade-off를 잘 설명할 수 있는 지원자를 원한다. 우린 종종 '남의 지식을 나의 것으로 만들어야 한다.'의 말을 듣곤 하는데 이와 같은 맥락이지않을까 생각한다.
두번째론 성장은 나를 기준으로 상대적이라는 것이다.
물론 나의 관점이 잘못되었을 수도 있고 그 깊이가 엷을 수도 있다.
하지만 어제의 나보다 더 나은, 더 풍부한 관점을 갖춘 것 자체가 성장이다.
따라서 내 옆에 있는 누구와 비교할 필요 없이 나만의 관점이 생긴 것 자체로 의미가 있고 칭찬할 일이다.
내가 새롭게 갖게된 관점을 정리하다보면 나의 성장이 눈에 띄게 나타나는 것 같다.
나의 성장을 소소하게 나눠보자면, 나는 레거시 시스템을 어떻게 다뤄야하는지에 대해 막연한 관점이 생긴 것 같다.
그 당시 '최선'이었을 코딩 방식을 이해하고 최대한 그대로 이어서 유지보수하는 것이다. 어떻게든 최신 세련된 코딩 방식을 도입하려는 건 오히려 시스템을 더 더럽게 만드는 것 같다. 만약 도저히 손을 댈 수 없다면 시스템 통째로 가라엎는 것이 더 빠를 수도 있다. 그리고 부족한 코딩 컨벤션 채워가고, 테스트할 수 있는, 모니터링되는 환경을 구축하는 것이다.
어떤 사람이 꼰대인가?
꼰대에 대한 정의를 내리라고 한다면 2가지 포인트가 생각이 나는 것 같다.
- 나의 관념을 상대방에게 강요하거나 주입하는 사람.
- 상대방에게 관심을 갖지 않고 그저 내가 하고 싶은 얘기를 던지는 사람.
나는 종종 상대방을 꼰대로 평가했었다.
할아버지와 대화를 나누면 참 답답한 구석이 있었다. '그게 왜 그런가면...' 논리가 꼬리를 물고 1시간 내내 반복되는 것이다.
할아버지 인생의 지혜를 무시하는 것이 아니지만 나는 그 순간 할아버지가 너무 꼰대스럽다고 생각했다.
'왜 상대방이 관심 없을 얘기를 저렇게 늘어뜨리지?'
'왜 자기 경험과 생각을 풀지 못해 안달일까?'
하지만 언젠가 돌아보니 내가 그런 사람이 되어 있는 것 같았다.
제대로 의견을 충돌시키지 않고 그저 나의 생각, 나의 의견에 굳혀져 있던 것이다.
구체적인 예시를 꼽긴 힘들지만 이는 계속 자신을 자각해야 문제임은 확실하다.
좋은 조직장, 상사가에 대해 생각을 하게 되었을 때도 이와 일맥상통한 부분이 있다.
대화를 나눌 때 비록 평소에 친분이 없음에도 '아 정말 나에게 관심이 있는구나!'라고 느낄 때 상대방에 대한 호감도가 수직상승했던 것 같다.
상대방에게 포커스를 두고, 상대방이 관심을 가질 만한, 도움이 될 만한 포인트를 가지고 대화를 이어가는 것이다.
그저 뻔한 소리이기는 하지만 중요한 것은 결국 상대방에 대한 관심인 것 같다.
좋은 문화는 나의 행동으로 맺어진다.
카카오는 정~~말 좋은 문화를 갖고 있다.
그러나 아쉽다고 생각되는게 이는 용두사미(龍頭蛇尾)하다는 것이다.
100:0 원칙이 있다면 뭐하나, 사내 정책을 공유되자마자 언론에 노출이 되고 심지어 언론을 통해서 먼저 알게 되기도 한다.
'신충헌'이 있으면 뭐하나, 거세게 충돌하고 헌신할 생각이 없이 자기 주장을 그저 밀고 들어 간다.
...
너무나 멋진 문화이지만 정작 조직 내에서 이를 행하는 사람이 잘 보이지 않는 것 같다.
내가 행동하지 않기 때문이다.
문화라는 것은 한 사람에게서 이뤄지는 것이 아니다. 사람들의 상호작용이 이뤄졌을 때 문화가 탄생된다.
내가 그 상호작용에 참여하지 않고 있는데 어떻게 그 문화를 경험할 수 있는가?
의견을 나누는 자리에서 기껏 자신의 생각을 충돌해보고, 상대방이 옮을 수 있다는 믿음을 갖고 질문하고 경청해보고..
관망하는 것이 아닌 행하였을 때 비로소 팀의 문화를 알 수 있다.
회의감을 가지고 불평하기 보단 나의 행동으로 좋은 문화를 맺어보자!
나의 NEXT
브런치 리팩토링 ongoing
솔직히 브런치 서비스에 오래 발을 담고 싶지는 않다. 돈을 버는 서비스가 아니고 활발하게 발전하지도 못한다.
그래도 1년 정도는 더 주도적으로 부딪혀서 값진 경험을 할 수 있을 것 같다.
svelte의 고도화가 기대된다.
다양한 취미를 누비기
코로나가 있기도 했지만 올 한해는 개발에 많은 포커스를 맞춰왔던 것 같다.
전문성을 키워가는건 좋지만 그것에 올인하는 것은 삶이 장기적으로 건강하진 못할 것 같다.
예전 취미 많던 시절 돌아가 풍성한 삶은 좀 이어가보면 어떨까? 그럼 연애부터...
겨울에 스키 타기, 화방(그림 그리기) 다니기, 비트 메이깅 해보기, 음료 제작 입문하기, 헬스 관련 첼린지 도전하기...
코드 리뷰어로 활동해보기
촌놈이 시내 구경하는 느낌이랄까? 암튼 재밋을 것 같다.
回顧錄 (회고록)