이뇽의세상

요즘 프론트엔드 개발자가 노력해야 할 커리어 방향성에 대해

Hello이뇽 — Sun, 3 Aug 2025 01:13:14 +0900

아무래도 요즘 핫한 이슈가 AI인 만큼, 나 역시 요즘 최대 관심사는 AI가 되어 있는 상태다.

LINE에 합류한지 어느덧 (아직은 짧디 짧은)8개월이 되었지만, 최근 OKR 중 AI 활용에 대한 성과 지표가 생기면서 요즘이 LINE 활동 중 가장 재밌는 시기인 것 같다.

AI를 통해 우리 업무적으로 생산성을 끌어올리고, 버그율은 내리기 위한 다양한 연구와 작업을 진행하고 있다.
Cursor Rule과 다양한 mcp 서버 연동을 통해, 에이전트가 우리가 의도하던 방향으로 정확하고 빠르게 작업하도록 하기 위한 환경을 계속 구축 중인데, 중간중간에 에이전트 활용을 하면서 놀라운 퍼포먼스를 보여줄 때마다 도파민이 터지는 느낌이다.

이러니 몰두를 안할 수가 있나...

심지어 이러한 과정을 내 성과로 만들 수 있다고 생각하니 요즘 일이 너무 재미있는 것 같다. 에이전트가 곧 실력 좋은 동료 한명을 구축한다는 생각으로 미래를 꿈꾸며 에이전트 환경을 개선 중이다.

그러나 또 한편으로는, 에이전트가 놀라운 퍼포먼스를 보여줄 때마다 나의 커리어에 대한 생각도 들게 되었다.

이러한 AI로 인해 연차별 코딩 실력에 대한 격차가 사실 많이 줄어들고 있다. 왠만한 어려운 기능과 세밀한 코드 구현은 AI가 굉장히 잘해주고 있다보니, 개발 인력이 과거보단 점차 필요가 없어지고 있는게 사실이다. 실제로 요즘 개발 취업난이 굉장히 힘들다고 하니...

과거 내가 주니어 프론트엔드로써 역량을 쌓기 위해, 컴포넌트 재활용 설계과 상태관리 같은 노하우를 습득하고 실전에 어떻게 잘 활용할지 연구하고 고민했던 것 같다. 그 당시 컴포넌트 설계와 재활용은 나에게 마치 레고를 조립하고 만지듯 재밌게 코딩했었다.

그러나 내 개인적인 의견으로는, 이러한 역량을 쌓기 위해 노력하는 것은 더 이상 중요하지 않게 된 것 같다. 지금은 에이전트가 사람보다 더 빠르고 견고하게 잘 해주기 때문이다.

이제는 우리가 신경써야 하는 부분은, 에이전트를 이용해서 우리의 생산성을 어떻게 최대한 끌어올릴 수 있는지 연구하고 고민하는 것이다.

에이전트를 많이 만져보며 이에대한 노하우를 습득하고 실전에서 활용하는 것. 내가 생각한 요즘 프론트엔드가 가져야할 트렌드는 바로 이것이라고 생각한다.

물론 연차로 쌓은 '일을 잘하기 위한 경험'은 무시할 수 없겠지만, 개발 실력 자체를 더 잘 쌓기 위한 노력을 하는게 의미가 있는가 의구심이 들게 되었다. 그래서 당분간은 AI 활용에 집중을 해보려고 한다.

더 나아가, 요즘엔 내 삶에 AI를 어떻게 접목시켜서 삶의 질을 끌어올릴 수 있을지를 계속 고민하고 시도해 보고있다. 내 주 관심사인 투자와 옵시디언을 활용한 기록 데이터 정보 등등. 활용할 수 있는 MCP도 많으니 이것들을 잘 활용해서 정말 재밌는 시도를 많이 해보고 싶다.

AI, 굉장한 무기인 만큼 잘 활용해보자.

이뇽의 개발 인생 2부 종료 (2019 ~ 2024년)

Hello이뇽 — Tue, 17 Dec 2024 10:48:28 +0900

5년 전 코드스테이츠를 수료 후, 프론트엔드 신입이자 주니어 개발자로서의 새로운 삶을 시작했을 때가 아직도 생생한데 벌써 5년이라는 시간이 흘렀다.

이뇽의 개발 인생 1부 종료(링크)

5년 동안 나는 정말 많이 변했다. 변했다는 것은 개발 실력도 있겠지만, 성격이나 성향, 생각하는 방식과 관점 등 ‘정인용’이라는 사람에 대해 많은 것의 변화를 느끼게 되었다. 그만큼 정말 많은 것을 경험하고 활동하고 다양한 것을 느낄 수 있었던 것 같다.

그리고 이 모든 과정들을 사랑한다.
5년 전 나의 개발 인생 1부 를 작성하면서, 서론에 “나는 정말 운이 좋았다” 라고 적었듯이, 이번의 2부를 마감하면서도 정말 운이 좋았다는 말을 빼놓을 수 없을 것 같다. 그만큼 내가 살아가며 선택한 것들이, 안 좋은 것도 있었지만 대부분 모든 결과가 좋았다.

코드스테이츠 수료 후, 수월했던 취준생활

코드스테이츠 수료 후 당시, 끝까지 남아서 수료한 수강생들에게 선릉 위워크 3호점(당시 콴다 오피스) 핫데스크를 2개월 동안 이용할 수 있도록 지원을 해준 덕분에, 마냥 좁은 집에서 묵묵하게 준비하기보단, 같이 수료한 동기들과 사이드 프로젝트를 진행하고 계속 자극을 유지하면서 면접을 보러 다닐 수 있었다.

꽤 많은 면접 제안을 계속 받게 되어서 자신감을 잘 유지할 수 있었다. 입사 제안을 받을 때마다 괜히 “더 좋을 곳으로 갈 수 있지 않을까” 욕심도 들다보니 마지막에 입사를 포기한 곳도 꽤 있었다. 그래서 내가 정확히 어떤 기업을 가고 싶은 것일까 정의가 필요했던 것 같다.

신입이다보니 대부분 작은 스타트업 계열 위주이긴 했지만, 그 안에서 “내가 좋아하는 도메인”에서 일해보고 싶다는 생각을 가지고, 다시금 기업 리스트를 보던 중, 오프라인 독서모임 서비스인 T사를 알게 되었다.

독서과 글쓰기를 엄청 좋아하던 나였기에, 이 서비스를 알게되지마자 “여기다!” 소리를 질렀고, 해당 기업이 코드스테이츠와 연계점을 가지고 있는 것을 알게된 후 취준 담당을 해주던 분께 바로 컨텍할 수 있도록 도움을 요청드렸다.

그리고 며칠 후 연락을 받게 되었던 당시 CTO의 입사 전형 메일.
난 이때 의욕이 100%를 넘어, 거짓 없이 800% 정도 되었던 것 같다.

리스트 페이지를 작업하는 과제 전형을 받았고, 나는 내 역량을 어필하기 위해 필수 스펙에는 없었지만, Webpack과 Typescript 환경을 직접 세팅하면서 로우 레벨 단의 환경 세팅부터 페이지를 만들어내는 과정까지 직접 작업하면서 과제를 수행한 것이 생각난다.

그리고 너무 기뻤던 과제 합격 후 면접 제안 메일. CEO와 CTO 두분과 나 셋이서 진행되는 방식이었다.
그런데 너무 특이했던 것은 “나의 역량을 확인하기 위해 그들이 지원자에게 질문이 아닌, 지원자가 질문을 하고 그들이 답변을 하는 것.”.
시간이 지나 돌이켜보면 그냥 어떻게 개발자의 역량을 검증해야될지 몰라, 그냥 사람이 좋은지 판단하기 위한 방법이었을 뿐이었으나, 그 당시 나는 해당 서비스에 완전히 콩깍지가 씌어져 있었던지, 이것을 “특이하다”고 생각하기보다 “특별하다”고 생각을 했다.

그리고 면접 후 입사 제안 메일을 받았을 때는, 그 당시 몇달간의 기간 중 가장 벅차오르는 기쁨을 느낄 정도였다.

사실 그 당시엔 전자 문서 B2B 서비스인 “스팬딧” 이라는 기업에도 전형을 진행 중이었고 무사히 입사 제안을 받았던 상태였다.

코드스테이츠의 마지막 4주 프로젝트에서 인프라와 백엔드 포지션으로 업무를 수행했어서 스팬딧에서는 백엔드 개발자로 전형을 진행 중이었는데, CTO와의 기술면접이 너무나 분위기가 좋고 인상이 깊었다.
CTO분도 엄청나게 젠틀하셨고 신입 지원자인 나를 굉장히 존중해주는 느낌을 많이 받을 수 있었다.

당시 Node 개발만 해봤던 나에게 파이썬의 개발의 제안해주시면서도 내가 파이썬을 해보지 않았는데 괜찮겠냐는 질문에, “충분히 고려하고 있고, 빠르게 습득해서 역량을 펼치는 단계가 오시리라 믿기 때문에 괜찮다” 라는 말씀에 너무나 큰 감사함을 느꼈었다.

하지만 그럼에도 T사의 콩깍지에 씌어있던 나는 너무나 죄송하다는 말씀과 정중히 입사제안 거절 의사를 드리게 되었다. 그럼에도 “짧게라도 멋진 분을 뵐 수 있어 좋았고, 잘 하시길 바랍니다.” 라는 답변을 받으며 나를 응원해주었다.

가끔 아직도 생각난다.
그때 내가 스팬딧이라는 기업에 백엔드 개발자로 활동을 시작했다면, 지금의 프론트엔드 개발자와 완전히 다른 개발 인생을 살았겠구나, 하며.

T사의 크루 활동 시작, 그리고 시작된 악몽

하늘을 찌를 정도의 의욕을 가지고 해당 서비스의 크루로 합류하게 되었다.
개발자로써, 그리고 이 기업의 크루로써 정말 재미있고 열심히 활동해서 많은 퍼포먼스를 내겠다는 생각이 가득했다.

그러나 이러한 나의 꿈을 철처하게 짖밟혀 버렸고…

나보다 앞서 활동하던, 나의 (사수 같지도 않았던) 사수인 주니어 개발자.
나의 역량을 펼치려고 뭔가를 시도하려고 하면, 이에 대해 굉장히 비판하고 비난을 해대는 바람에, 내가 뭔가를 하고 싶어도 눈치만 봐야했고, 결국 내 기여 욕구를 짖눌러야했다.

그렇게 하루하루 힘들게 보낸 것이 11개월, 한번은 오전에 입무를 시작하려는 나에게 잠깐 논의할게 있다고 다른층 비어져 있는 미팅룸으로 데리고 왔다. 그리고 다짜고짜 내 연봉을 물어봤다. 그런걸 왜 물어보냐고 하니, 짜증 섞인 목소리와 함께 빨리 말하라며 나를 밀어 붙이기 시작했다. 나는 정신이 나가 아무 말 하지 못하고 가만히 있을 수 밖에 없었다.

내가 끝내 말을 하지 않으니, 본인이 분명히 더 오래 다녔고 더 실력이 높다고 생각하는데, 분명히 내가 자기보다 더 높게 받고 있을 것 같다며, 그 생각만 하면 너무 화가나서 참을 수 없다고 했다. 그리고 이렇게 대우를 해주지 않는 회사는 다닐 생각이 없다고 말했다.

지금까지도 너무나 힘들었으나, 어떻게든 붙잡고 있던 내 모든 멘탈이 나가는 순간이었다. 그 일이 일어난 이후로 이틀 정도는 회사 자체가 지옥처럼 느껴졌다. 출근 후 강남역까지 도착했으나 그 오피스에 들어가는 것 자체가 너무 무섭고 두려움을 느꼈다. 그래서 괜히 주위 한바퀴 더 돌고 마지못해 들어갔었던 기억이 난다.

그 자리에 있는 것만으로도 에너지가 깎이고 나를 잃어가는 느낌이 들었고, 퇴근 후에는 아무것도 할 수 없이 우울감 속에 갇히게 되었다.

이 서비스를 정말 사랑했다. 개발자로써 역량을 내뿜을 환경은 아니었지만, “세상을 더 지적으로, 사람들을 더 친하게” 라는 모토 위에서 사람들에게 좋은 영향력을 펼칠 수 있는 서비스라 생각했던 만큼 이 곳의 크루라는 자부심을 가지고 있었던 나였음을 알기에, 생각도 들지 않았고 생각이 들어도 절대로 하기 싫었던 최후의 선택을 결국에는 하게 되었다.

“그래… 퇴사하자.."

어려운 결정을 한 뒤 다음날 아침, 평소와 다르게 발걸음이 굉장히 가벼웠고, 기분도 꽤나 상쾌했다. 정확하게는 무거운 짐을 모두 버려버린 것 같아 정말 시원한 느낌이었다.

전날 밤까지만 해도 이 무거운 결정을 할 수 밖에 없었던 내 스스로가 너무 미웠고 슬펐는데, 자고 일어나니 이 지옥같은 곳을 드디어 떠나게 되는 느낌이라 그랬나보다.

그리고 나는 HR팀에게 퇴사 의사를 밝히고 최대한 빨리 퇴사하고 싶다는 요청을 드렸다. 마음이 홀가분했다.
그런데 갑자기 오전에 그 친구가 나에게 할 얘기가 있다며 잠깐 시간이 되냐고 물어봤다. 평소였으면 또 무슨 비난을 하려고 그럴까 하며 스트레스 였겠지만, 이제는 무엇이든 상관없는 나였기에 알겠다 하고 따라 내려가 빈 미팅룸으로 들어갔다. 그리고 다짜고자 나에게 사과를 했다.

본인이 너무 무례했다고, 본인이 사회생활을 오래 안해봐서 몰랐다고, 내가 정말 잘못된 행동을 했다고..
갑자기 얘가 왜 저러나 싶었는데, 본인이 그 얘기를 한 뒤 주위 분들과도 본인이 한 행동에 대해 애기를 해보면서 본인이 잘못된 행동을 했었음을 알게 되었다고 얘기를 해주었다.

그리고 본인 때문에 내가 퇴사를 하는 것을 알게 되고, 죄송하다며 눈물까지 흘리는 모습을 보니 안쓰러웠다.

너무 안타깝고 진심으로 반성하는 모습에 괜찮다고 용서해주겠다고 했다.
그러니 나에게 퇴사를 다시 한번만 생각해줄 수 없냐는 말에, 솔직히 고민을 하게 되었다. 내가 계속 여기에 있어도 되는지.

하지만 그 전날 밤 부로 나의 마음이 떠나버렸고, 이 어려운 결정을 다시 미룰 용기가 나지 않았고 그렇게 하지 않았다.
퇴사 결정 후 나는 다음 이직할 곳 구하거나 그런 것을 생각할 에너지가 없었다. 우선 나에게는 휴식이 필요했었고, 그 일이 일어난 후 나는 2주일 정도 마무리 기간을 가진 뒤 이 서비스의 크루로써의 활동을 마치게 되었다.

최고의 복지가 좋은 동료는 맞지만, 그 좋은 복지를 가지고 있듯 겉포장에 속았으며, 오히려 최악의 동료를 만나 1년도 채우지 못한 채 11개월의 지옥같았던 활동이 끝나게 되었다.
좋아하는 서비스, 하지만 그 서비스 안에서 일하는 것은 완전히 다른 것임을 깨달은 채, 1년도 채우지 못한 약 11개월의 크루 활동을 이렇게 끝나버렸다.

재정비, 그리고 새로운 시작 '콴다'

혼자 제주도 가서 3일동안 여기저기 계속 걷기만 했다. 회복이 필요했다.
관광도 아닌, 그냥 바다 둘레길을 계속 걸었다.

그리고 내가 무엇을 하고 싶은지, 어떤 개발자가 되고 싶고 어떤 기업에서 일하고 싶은지 정리를 해보았다.
그리고 나는 개발자로써 필요로 한 기본기를 다시 다지고, 도메인 보단 내 역량을 펼칠 수 있는 환경으로 가자고 판단했다.

그런데 이때가 참 희한하게도 구직이 너무나 어려웠다. 당시 너무나 많은 개발자 양성 중이었어서 그런지, 어디든 경쟁률이 장난이 아니었다. 그러다보니 각 기업에서는 면접 난이도까지 미친듯이 올라가는 것이 새삼 느껴졌다. 프론트엔드 개발자를 뽑는데 L4, L7 레이어에 해당하는 프록시 서버가 무엇이 있는지 물어보는 수준이었다.
그렇게 4개월 정도 엄청 어려운 구직 수난에 해메고 있을 때, 나는 '콴다'라는 기업을 처음으로 알게 되었다.

그 당시 '콴다'와 '여기어때' 두 군데 전형 진행 중이었고, 두군데 동시에 합격을 하면서 드디어 4개월만에 백수에서 탈출하는구나 하며 안도감과 행복의 기쁨을 누릴 수 있었다.

그 당시 '여기어때'가 나한테는 더 익숙한 서비스인 만큼 이쪽으로 가고 싶었다.
그러나 기업에 대해 알아보려 할수록 여기어때는 블로그도 없고 기업문화를 느껴볼 수 있는 요소들이 없어 알아볼수록 마음이 가지 않았다.
반면에 콴다라는 기업을 알아갈수록 너무나 매력적이고 내가 꿈꾸던 문화와 분위기를 가지고 있음을 알 수 있었다.

그렇게 두 기업을 고민하다가 결국 인지도보단 숨은 매력도를 가지고 있는 콴다를 선택하게 되면서 나의 콴다 생활을 시작하게 되었다.

그리고 역시나 예상했듯, 나는 여기서 좋은 사람들, 좋은 분위기, 성장할 수 있는 좋은 환경에서 미친듯이 몰입하며 개발자로써 성장할 수 있는 시간을 가지게 되었다.

이때 내가 콴다를 선택해서 합류한 것은, 내 인생에 정말 잘한 선택 중 하나였다.

나의 이탈을 여러번 막아주었던 콴다..

폭발적인 성장 과정과 그 과정을 통해 느낀점들을 블로그로 남기다보니 자연스레 나의 글을 읽고 연락을 주는 기업이 꽤 있었다. 본인들 기업에 지원해보라는 연락도 있고 바로 면접 제안을 주시는 기업도 있었고, 심지어 본인들은 정말 작은 기업이다보니 감히 본인들과 함께 하자는 말은 못하겠고, 어떻게하면 인용님과 같은 인재를 모셔올 수 있을지 알려달라는 메일도 받았던 적이 있었다.

그 중 뱅크샐러드에서 연락을 받았던 것이 제일 기억에 남는다.
면접을 보면서 정말 많은 대화를 나누었는데, 그때 프론트엔드 리더 분이 나를 정말 마음에 들어했음이 느껴질 정도로, 오히려 그분이 본인의 서비스와 팀이 얼마나 좋은지 나에게 어필하셨던게 기억에 남는다.

그렇게 수월하게 연봉 협상과 입사 날짜까지 진행되었고, 나는 처음으로 콴다 측에 1년만에 퇴사 의사를 밝히게 되었다.
나는 사실 그때 뱅크샐러드로 가게 될 줄 알았다. 당시 뱅크샐러드가 분위기가 안좋다는 소문은 들어서 꽤 찝찝했지만, 꽤 적지않은 연봉 제안을 주셨기 때문에 우선 가야겠다고 생각을 했다.

그러나 콴다에서 나를 붙잡아 주었다.
거기서 부른 제안에 맞춰줄테니 남아줄 수 있냐는 요청을 해주신 것이다.

그때 나는 콴다에서 정말 재미있게 일하고 있었고 폭팔적으로 성장하던 시기였어서, 사실 이때 분위기도 좋지 않은 다른 환경으로 오로지 연봉만 보고 이동한다는게 좋은 선택이 아닐 수도 있었기 때문에, 콴다에서 그렇게 맞춰준다고 하면 남지 않을 이유가 하나도 없었다. 무엇보다 그렇게 제안해주신게 나의 능력을 인정해주고 나를 아낀다고 느껴져서 너무나 감사했다.

그렇게 첫번째 이탈을 하려는 나를 콴다에서 계속 활동할 수 있도록 꼭 붙잡아주셨다.

그리고 나는 정말 많은 활동과 프로젝트를 진행하며 한번 더 개발자로써 폭팔적으로 성장할 수 있었던 시간을 보낼 수 있었다. 너무나 재밌고 즐거웠고 행복해서, 오히려 주말이 다가오는게 싫을 정도였다.
그와중에 러닝 루틴은 계속 지켰고, 저녁 먹고 새벽까지 운영하는 탐앤탐스에 가서 또 작업하고, 주말에도 서슴치않게 항상 나와서 키보드를 두드렸지만, 몸은 힘들었지만 정신은 하나도 힘들지 않았던 것 같다.
주말이여도 오피스에서 내 시간을 보내는 것이 즐거웠다.

하지만, 콴다 생활한지 3년만에 또 한번 나는 이탈을 시도했다. 그 당시 이미 어느정도 익숙한 환경이 되어버린 만큼 새로운 자극을 느끼고 싶었던 때였던 것 같다. 그래서 적극적으로 이직 준비를 했었고, 카카오에 합격했다.
분야는 헬스케어였고, 도메인이 꽤 나쁘지 않았던 것 같다.

단, 하나 걸리는 것이 있다면… 그 당시 나는 Core Group에 새롭게 합류를 했는데, 프론트엔드 포지션이 나밖에 없어서 콴다에서는 내가 무조건적으로 필요한 상태였다.
꽤 오래 다녔던 기업이었고, 개발자로써 많이 성장할 수 있었던 곳인만큼, 콴다의 상황을 고려하지 않고 오로지 ‘나’만 생각하고 결정하는 행동이 나에게는 쉽지 않았던 선택이었다.

그럼에도 ‘나’ 스스로가 제일 중요하다고 생각이 들어, 쉽지 않은 퇴사 얘기를 꺼내게 되었다.
그리곤 콴다에서는 한번 더 나를 붙잡아주었다..

무엇이 개선되면 너가 남아있을 의향이 있는지, 너가 생각하는 우리에게 원하는 부분이 무엇인지..
나에게 콴다는 너무나 익숙해졌고 더 이상의 레슨런을 찾기 힘든 환경이 된 것 같다 말씀을 드렸다.
그랬더니, ‘앞으로 Core Group의 변화가 있을 것이고 변화된 환경에서 너가 재미있게 일할 수 있을 것이다’, ‘너가 다시 재미있게 일할 수 있게 도와주겠다’며 자기들을 믿어달라고 말씀해주셨다.

콴다에서 나를 너무나 아끼고 존중해 주었음을 두번째로 느끼며 감사함을 느꼈다.
그리고는 한번 더 콴다에 남는 선택을 하게 되며, 그때부터 나는 제대로 Core Group의 프론트엔드 멤버로써의 활동이 시작되었다.

각 포지션에서 15명 내외의 적당한 멤버들끼리 모여 콴다 앱 내 매출과 프리미엄 상품을 위한 활동을 했는데, 진실로 그 과정과 활동 기간이 너무나 재밌었다.
그 전까지는 개발자로써의 성장과 활동만 추구를 했다면, Core Group에서는 온전히 비즈니스적인 관점에 집중할 수 있었던 기간이었던 것 같다.
왜 이런 프로젝트를 진행하는지, 왜 사람들이 이 포인트에서 와우를 하는지, 왜 이런 UI/UX를 가져가는지 분석하게 되었던 것 같다.
그리고 무엇보다 그룹 멤버들이 다같이 하나의 목표만을 바라보며 으쌰으쌰하면서 다같이 움직이는 그 과정이 정말 협업하는 느낌이었다.
또한 분기별로 그룹 사람들 다같이 놀러가서 재밌게 놀았던 추억들이 쌓이면서 나쁜 의미의 가족이 아닌, 정말로 좋은 가족같은 분위기였던 것 같다.

마지막 이탈.. 그리고 정말로 안녕.

그렇게 행복한 시간으로 1년 정도 채워져 갈때 쯤, 이제는 정말로 콴다와 이별을 하게 되는 순간이 다가옴을 느꼈다.

넓고 넓었던 콴다의 모든 것을 꽤차게 되었고, 정말 많은 것을 배우고 느끼며, 약 4년 간의 길고 길었던 콴다 생활을 마무리하게 되었다.

돌이켜보니 어느덧 나는 미들 급 개발자가 되어 있었다.

정신없이 개발에 몰두하고 열심히 뛰어오다보니 어느덧 나는 주니어 시절을 보내고 미들 급 개발자가 되었다.
그리고 이 쯤에서 슬슬 나의 개발 활동 2부를 종료하고 이렇게 글로 작성해도 괜찮겠다고 판단했다.

너무나 많은 일이 있었다. 재밌었다!

많은 선택지가 있었지만, 하나하나 선택을 통해 나를 여기까지 오게 해준 모든 것들, 그리고 나를 함께하고 이끌어주신 모든 분들께 진심으로 감사함을 전하고 싶다.

1,2부에서는 내가 개발자로써 성장에 집중하는 과정을 거쳤다면, 아마도 3부에서는 개발자를 포함해 내 삶과 가정, 인생의 목표에 대해 집중하는 삶을 보내지 않을까 싶다.

벌써부터 온전히 개발자로써의 목표보다는, 내 삶과 행복, 내 인생의 목표에 대해서 이미 생각해보며 살아가고 있다.

앞으로 나는 또 어떤 삶을 보내게 되면 어떤 것을 마주하게 되며 살게 될까 궁금하다. 분명히 앞으로도 더 많이 정신없고 힘들 수도 있다. 어쩌면 앞으로는 방향성을 더 찾기가 힘들 수도 있다.
그렇지만 정말 마음 굳게 먹고 똑바로 올바른 방향을 바라보도록 노력해야 할 것 같다.

느낌이 정말 이상하다. 1부 종료의 글을 쓸 때, 내 미래를 굉장히 궁금해 하며 종료를 했는데, 벌써 5년의 기간이 흐르고 이렇게 또 나의 미래에 대해 궁금함을 가지며 이 글을 마무리 한다.

미래의 내가 이 글을 읽을 때, 한번 더 웃으면서 좋은 시기였음을 느끼며 3부를 쓸 수 있기를.

'환경'이란 요소가 우리에게 주는 영향

Hello이뇽 — Fri, 8 Nov 2024 00:54:32 +0900

AI시대에 살아가면서 너무 많이 정보통 속에서 내가 원하는 가치를 찾기 위해 열심히 살아가고 있다.

그러다 문득, 이러한 동일한 세상에 살아가면서도, 이러한 AI 시대를 아직 받아들이기 못하고 본인의 삶의 변화를 느끼지 못하거나 영향을 받지 못하며 살아가는 사람들이 참 많을 수도 있겠다는 생각이 들었다.

몇달 전, 오랜만에 만났던 내 고향 친구들은 딱히 지금의 AI시대에 비해 본인들에게 변화된 영향이 별로 없다는 말을 듣고, 나는 친구들과 다르게 어떻게 이러한 변화를 받을 수 있을까를 생각해 보게 되었다.

어쩌면 나도 친구들처럼 작은 지방에서만 살아가고 있다던가, 혹은 이 IT업계라는 곳에서 활동하고 있지 않았다면 나도 지금의 큰 변화를 딱히 느끼지 못했을 수도 있었을 것이다. 하지만 개발자로써 IT업계에 종사하며 '콴다'라는 조직 안에서 성장을 추구하는 동료들 사이에서 활동을 하다보니 자연스레 나도 이에 대한 변화를 받아들이고, 내가 취할 수 있는 것들이 생기고 정보를 얻게되고 다룰 수 있는 여러 도구들도 생기게 되는 것 같다.

그만큼 내가 어디서 어떻게 활동을 하냐에 따라서 내 운명이 바뀔 수 있음을 느꼈다.
만약 나도 내 주위의 좋은 환경과 성장을 추구하는, 그리고 변하는 시대를 받아들이고 이에 맞춰 살아가는 사람들이 있지 않았다면 지금까지의 위치에 이루지 못했을 것이다.

오늘은 뛰어난 동료 중 한명과 티타임을 했는데, '내가 추구하는 가치'에 대해서 얘기를 하게 되었는데, 그 시간이 너무나 좋았다.
내가 생각해보지 않았던 값어치 있는 얘기였고, 이러한 대화를 할 수 있는 동료가 있기 때문에 성장과 삶의 진정한 가치에 대해서 생각을 할 수 있는 기회가 생기고 액션을 취할 수 있게 됨을 느낀다.

생각 없이 살아가지 말고, 내가 살아가는 환경을 좋은 환경으로 만들어가자.

나약한 생각을 버리고, 어떻게하면 멋진 개발자가 될지를 고민하자

Hello이뇽 — Fri, 11 Oct 2024 22:40:13 +0900

최근 특정 프로젝트에 대해 굉장히 지친 상태가 될 만큼 QA가 길어진 프로젝트가 하나 있었다.
기획은 아주 조그마했지만, 그 기획에 엉켜있던 지금까지의 많은 컨텍스트와 기술 부채들이 걸림돌이 되었던 것이다.

분명 내가 했던 것들도 아닌데...과거의 개발자들과 기획자들이 지금 당장의 빠른 임팩트를 내어보기 위해 나중의 후폭풍은 생각하지 않고 우선 지금 당장의 문제를 해결할 수 있는 방식을 택하다보니 발생한 결과들이었다.

어떻게든 닥친 문제를 해결할 수 있는 역량 자체도 어쩌면 좋은 것이지만, 장기간 해당 코드의 유지보수를 생각하는 부분이 정말 중요한 것 같다는 생각이 들어, 최근에 코어그룹 엔지니어들에게 "나중의 문제가 발생하지 않는 방식의 코드를 생각하는 관점을 가지자"는 얘기를 한 적도 있었다.

그래서 그런지 요즘 코드를 구현할 때, 나중의 내가 혹은 누군가가 현재 작성하는 코드 부분을 들여다봤을 때 의도를 알 수 있도록, 그리고 나중에 문제가 발생할 것 같은 부분들을 계속 생각하면서 구현하게 되는 습관이 들이려고 하다보니 확실히 코드의 일관성도 잡히는 것 같고 코드에 주석을 상세하게 남기는 것도 습관화가 된 것 깉다.

내가 쓰는 주석은, 무엇을 어떻게 구현한 코드인지 설명하는 주석이 아니라, 왜 이렇게 구현할 수 밖에 없었는지 배경 설명이 필요한 주석이다. 가끔 컨퍼런스 같은 곳 가면 '본인들은 주석을 다는 것을 싫어한다. 코드로 대화하면 되지 않냐' 라고 말하는데, 넓고 깊은 서비스를 개발해 보지 않은 주니어 개발자들이 겉멋만 들어서 하는 말로 밖에 보이지 않는다.

그 넓은 비즈니스 컨텍스트와 깊은 기술적인 부분들을 어떻게 코드로 설명할 것인가? 컨텍스트 배경이 필요할 때마다 관련 엔지니어나 PM을 찾을 것이 아니라면, 그리고 1,2년만에 들여다본 본인의 코드를 누군가가 봤을 때 정말 100% 의도를 이해시킬 수 있다는 자신감이 있는게 아니라면 주석을 아낌없이 작성해야만 한다. 그 코드를 바라볼 미래의 나 혹은 누군가에게 감사함을 얻게 될 것이다.

그러다가 오늘 문득 House Keeping 기간이 필요할 것 같다는 생각이 들었다.
올해 초부터 지금까지 급급한 프로젝트 일정으로 진행하다보니 기술 부채들이 쌓인 것도 있었고, 앞으로도 이러한 작은 기획 하나에 오랜 기간 얽매이지 않으려면 기술적 재정비 기간이 필요할 것 같다는 생각이 들었다.

그래서 그룹 채널에 공개적으로 현재 진행 중인 큰 프로젝트 하나가 끝나면 일주일의 House Keeping 기간을 고려해 달라는 장문의 글을 작성했다. 왜 기간이 왜 필요한지, 이 기간을 어떻게 사용할 것이고 지금까지 이러한 기간이 없음으로써 어떤 문제가 있었으며 앞으로 이러한 일이 발생하지 않도록 하기 위해 필요하다는 논리적인 글로 채워 작성을 했다.

그리고 답변을 기다리는 중, 다른 채널을 둘러보다가 문득 우리 사내 CTO께서 "Claude를 이용한 AI 동영상 풀이 제작" 이라는 멋진 기술을 만들어 내서 비즈니스 적으로 굉장히 도움이 될 만한 기술을 공유한 것을 보게 되었다.

그 쓰레드를 보면서 놀라면서도, 문득 오늘 내가 코어그룹 채널에 작성했던 글이 생각났다.

어쩌면 내가 되어야 하는 모습은 CTO와 같은 그런 모습이고, 회사에 비즈니스적으로 도움이 되는 사람이 되어야 하는데, 나는 오히려 겨우 홈페이지 작업 하나 하면서 본인 일이 힘들다며 본인을 달랠 수 있는 시간을 달라고 떼를 쓴 사람이 된 것 같았다. 너무 창피했다.

그래서 이미 많은 사람들이 봐버렸고 너무 늦었지만, 늦게라도 그 글을 지우고 반성했다.

CTO와 같은 역량을 가지려면, 그리고 정말 회사에 필요한 인재가 되려면 "비즈니스에 도움이 되는 기술을 연구하고 선보이는 사람, 그리고 기술로 내가 소속한 회사와 서비스에 기여를 하는 사람"이 되어야 겠다는 생각을 했다.

안그래도 빠르게 움직여야 하는 시기에..., 개발이 힘들다고 재정비 시간을 달라며 투덜대는 개발자가 아니라!!

React Compiler 파헤치기

Hello이뇽 — Wed, 24 Jul 2024 02:20:17 +0900

우리는 리액트에서 렌더링 최적화를 위해, 변화되지 않는 부분들을 리렌더링 되지 않도록 useMemo, React.memo, useCallback Hook을 사용한다.

그러나 이러한 함수들을 사용할 때, 정확하게 필요한 곳에 적용하여 완전히 렌더링 최적화를 시킬 수 있다면 아주 좋겠지만, 사실상 Deep하게 이러한 위치를 찾는 것과 리렌더링 최적화 분석을 하는 것이 굉장히 까다롭고 시간이 들어간다.

적절한 곳에 사용하지 못하면 해당 Hook에 대해 큰 이점을 챙길 수 없을 뿐더러 그렇다고 모든 곳에 메모제이션 처리를 해버리면, 그만큼 메모리에 저장되는 메모제이션 상태가 많아지기 때문에 성능에 악영향을 끼칠 수 있게 된다.

그만큼 React 내에서 메모제이션 기능을 통한 렌더링 최적화를 적용하는게 마냥 쉽지 않은 영역인데, 이를 쉽게 해결해줄 react Compiler라는 기능이 주목을 받고 있다.

React Compiler의 동작원리

compiler는 Javascript knowledge(아마 그냥 순수 자바스크립트를 얘기한듯?)와 React's rules를 이용하여, 컴포넌트와 Hooks 내 값들과 그룹을 메모제이션한다. 여기서 React's rules란, 간단하게 React에서 권장하는 코드를 작성하기 위한 Rule인데, 아래 Rules of React 섹션에서 자세히 다루고 있다.

만약 Rule이 맞지 않는 부분을 만나면, 해당하는 부분만 자동으로 스킵하고 계속하서 다른 부분을 컴파일을 한다.

Compiler는 크게 아래의 두 문제에 대해 해결하려고 하고 있다.

[자식 컴포넌트의 리렌더링 최적화]

일반적으로, React.memo를 감싸져 있지 않는 자식 컴포넌트는, 내려받는 Props의 변경사항이 없어도 부모 컴포넌트의 상태가 변하고 리렌더링 될 때마다 자식 컴포넌트까지 리렌더링 되는 이슈가 있었다. 이를 자동으로 최적화를 시켜준다.

# React 코드

function FriendList({ friends }) {
  const onlineCount = useFriendOnlineCount();
  if (friends.length === 0) {
    return <NoFriends />;
  }
  return (
    <div>
      <span>{onlineCount} online</span>
      {friends.map((friend) => (
        <FriendListCard key={friend.id} friend={friend} />
      ))}
      <MessageButton />
    </div>
  );
}

# Compiler를 통한 코드

function FriendList(t0) {
  const $ = _c(9);
  const { friends } = t0;
  const onlineCount = useFriendOnlineCount();
  if (friends.length === 0) {
    let t1;
    if ($[0] === Symbol.for("react.memo_cache_sentinel")) {
      t1 = <NoFriends />;
      $[0] = t1;
    } else {
      t1 = $[0];
    }
    return t1;
  }
  let t1;
  if ($[1] !== onlineCount) {
    t1 = <span>{onlineCount} online</span>;
    $[1] = onlineCount;
    $[2] = t1;
  } else {
    t1 = $[2];
  }
  let t2;
  if ($[3] !== friends) {
    t2 = friends.map(_temp);
    $[3] = friends;
    $[4] = t2;
  } else {
    t2 = $[4];
  }
  let t3;
  if ($[5] === Symbol.for("react.memo_cache_sentinel")) {
    t3 = <MessageButton />;
    $[5] = t3;
  } else {
    t3 = $[5];
  }
  let t4;
  if ($[6] !== t1 || $[7] !== t2) {
    t4 = (
      <div>
        {t1}
        {t2}
        {t3}
      </div>
    );
    $[6] = t1;
    $[7] = t2;
    $[8] = t4;
  } else {
    t4 = $[8];
  }
  return t4;
}
function _temp(friend) {
  return <FriendListCard key={friend.id} friend={friend} />;
}

Reference PlayGround

[React 스코브 바깥의 무거운 함수 실행의 최적화]

특정 함수가 가지고 있는 무거운 실행이, 파라미터가 변하면 이에 대해 새롭게 계산이 되어야 하는게 맞지만, 파라미터가 변하지 않아도 계속해서 계산이 되는 문제가 있었다. 이전엔 이러한 부분을 useMemo()를 통해 최적화를 시켰으나 compiler에서는 자동으로 최적화를 시켜준다.

# React 코드

// **Not** memoized by React Compiler, since this is not a component or hook
function expensivelyProcessAReallyLargeArrayOfObjects() { /* ... */ }

// Memoized by React Compiler since this is a component
function TableContainer({ items }) {
  const data = expensivelyProcessAReallyLargeArrayOfObjects(items);

  return <div>{data}</div>
}

# Compiler를 통한 코드

function expensivelyProcessAReallyLargeArrayOfObjects() {}
function TableContainer(t0) {
  const $ = _c(4);
  const { items } = t0;
  let t1;
  if ($[0] !== items) {
    t1 = expensivelyProcessAReallyLargeArrayOfObjects(items);
    $[0] = items;
    $[1] = t1;
  } else {
    t1 = $[1];
  }
  const data = t1;
  let t2;
  if ($[2] !== data) {
    t2 = <div>{data}</div>;
    $[2] = data;
    $[3] = t2;
  } else {
    t2 = $[3];
  }
  return t2;
}

PlayGround

그러나 만약 위처럼 expensivelyProcessAReallyLargeArrayOfObjects 함수가 실제로 엄청 무거운 함수라면, 리액 밖에서 자체 메모제이션을 하는 구현을 고려해볼 수 있다.

React Compiler는 실제로 Component와 Hooks에 대해서만 memoize를 하는데, 해당 함수가 각기 다른 컴포넌트에서 사용될때마다 심지어 완전히 동일한 Props가 전달된다고 해도 해당 함수는 각 컴포넌트에서 중복되게 동작하게 될 것이기 때문이다.

예를 들어 아래와 같은 경우이다.

function expensivelyProcessAReallyLargeArrayOfObjects() { /* ... */ }

function TableOne({ items }) {
  const data = expensivelyProcessAReallyLargeArrayOfObjects(items);

  return <div>{data}</div>
}

function TableTwo({ items }) {
  const data = expensivelyProcessAReallyLargeArrayOfObjects(items);

  return <div>{data}</div>
}

위 코드와 같은 상황이고 두 Table Component에서 전달받은 items Props가 같다고 했을 때, 만약 React Compiler가 Component와 Hooks를 포함한 모든 function들을 memoize를 할 수 있었다면 두 개의 Table 중 한군데 에서만 무거운 함수가 실행되고, 다른 컴포넌트에서는 이전에 메모이즈된 값을 그대로 사용할 수 있었을 것이다.

그러나 Compiler는 리액트 바깥의 함수는 메모이즈 대상으로 판단하지 않기 때문에, 각기 별도로 무거운 함수가 수행되게 된다.

그래서 필요하다면 해당 함수 자체에 메모제이션 처리를 하도록 하는게 효율적일 수 있다.

만약 해당 함수가 실질적으로 영향도가 큰 함수인지 확인하고 싶다면, profiling을 이용해 볼 수 있다고 나오는데, 막상 보면 아래 코드처럼 렌더링 시간 측정하는 방식이 나온다.

console.time('filter array');
const visibleTodos = filterTodos(todos, tab);
console.timeEnd('filter array');

react Compiler 코드 직접 까보기

그렇다면 실제로 메모이즈를 담고있는 _c는 어떻게 구현이 되어 있을까?
그 실체를 파악하기 위해 직접 코드를 까보았다.

// compiler/packages/react-compiler-runtimes/src/index.ts

type MemoCache = Array<number | typeof $empty>;

const $empty = Symbol.for('react.memo_cache_sentinel');
/**
 * DANGER: this hook is NEVER meant to be called directly!
 **/
export function c(size: number) {
  return React.useState(() => {
    const $ = new Array(size);
    for (let ii = 0; ii < size; ii++) {
      $[ii] = $empty;
    }
    // This symbol is added to tell the react devtools that this array is from
    // useMemoCache.
    // @ts-ignore
    $[$empty] = true;
    return $;
  })[0];
}

위 코드에 보다시피, useState로 생성한 변수에 불변성을 담고있지 않는 형태로 데이터를 저장한다.
생각보다 간단해서 당황했다.

이외에 같은 파일에 있는 다른 코드들도 궁금해서 따라가보았더니,
대부분 runtime에 사용되는 코드가 아니라, 컴파일 시 @babel/core의 옵션으로 이용되는 함수들이었다.

React Compiler가 컴파일 할 코드에 기대하고 있는 부분

1. 유효하고 시멘틱한 자바스크립트 코드
2. nullable하고 optional한 값, 그리고 접근하기 전에 선언이 되어 있음. (Typescript 사용 중이면, strictNullChecks로 확인 가능)
3. Rules of React에 따르는 코드.

Compiler는 Rules of React에 많이 의존된다. 만약 이에 맞지 않는 코드 영역은 과감히 스킵이 된다. 만약 Rules of React 기준에 벗어나는지 확인하려면 eslint-plugin-react-compiler를 사용해볼 수 있다.

지금까지 React Compiler가 어떤 부분을 도와주는 것인지에 대해 알아보았는데, 중간 중간에 소개되면서 Compiler가 Rules of React에 의존된다는 말이 많이 나왔을 것이다.

그러면 도대체 Rules of React 가 무엇일까?
아래에서 자세하게 한번 알아보자.

Rules of React

우선 간단하게 소개한다면, React 관점으로 권장하는 코드 표현 방식이라고 할 수 있다.

각 프로그래밍 언어마다 코드의 작성 방식이 많이 다른 만큼, 리액트에서도 역시 방대하고 넓은 작성 방식 중 좋은 형태의 코드 구성을 위한 권장 표현 방식이 있는데, Rules of React는 이에 대해서 가이드를 하고 있다.

따라서 해당 Rule를 잘 숙지하고 따를수록 잘 구성된 애플리케이션을 구축할 수 있지만, 만약 반대로 Rules에 위반이 될수록 버그율이 높아지고, 추론과 이해가 어려운 코드가 될 확률이 높다고 한다.

따라서 최대한 Rule을 따르되, 이를 위해서 React StrictMode와 Rule에 관련된 ESLint Plugin을 사용하는 것이 좋다.

Rule은 크게 세가지로 나뉜다.

- Components and Hooks must be pure
- React calls Components and Hooks
- Rules of Hooks

[Components And Hooks must be pure]

컴포넌트와 Hooks를 Pure하게 구현하는 것은 앱을 디버깅하기 쉽고 코드의 흐름이 예측하기 쉽게 해준다. Pure해야한다는 것을 조금 더 세분화 시킨다면 아래와 같다.

- 컴포넌트는 멱등성을 가져야 한다.
- 사이드 이펙트는 렌더링 밖에서 일어나야 한다.
- props와 state는 immutable 해야한다.
- Hooks의 Arguments와 Return 값은 immutable 해야한다.
- 값이 JSX로 전달되었을때는 Immutable 해야한다.

각 내용마다 엄청 Deep하게 가이드가 되어 있긴 하지만, 큰 틀에서는 "의도되지 않은 타이밍에 값이 변경되지 않도록 구성시킨다"이다.

예시로 다음 코드를 한번 보자.

function Clock() {
  const time = new Date(); //   Bad: always returns a different result!
  return <span>{time.toLocaleString()}</span>
}

위 코드는 렌더링 될 때마다 time 값이 변하게 되는데, 이러면 우리는 time 값을 예측할 수 없고 언제 값이 변하는 시도를 하는지도 알 수 없다.

이러한 문제를 해결하기 위해서는 아래처럼 변경할 수 있다.

import { useState, useEffect } from 'react';

function useTime() {
  // 1. Keep track of the current date's state. `useState` receives an initializer function as its
  //    initial state. It only runs once when the hook is called, so only the current date at the
  //    time the hook is called is set first.
  const [time, setTime] = useState(() => new Date());

  useEffect(() => {
    // 2. Update the current date every second using `setInterval`.
    const id = setInterval(() => {
      setTime(new Date()); // ✅ Good: non-idempotent code no longer runs in render
    }, 1000);
    // 3. Return a cleanup function so we don't leak the `setInterval` timer.
    return () => clearInterval(id);
  }, []);

  return time;
}

export default function Clock() {
  const time = useTime();
  return <span>{time.toLocaleString()}</span>;
}

이처럼 구현하면 렌더링 될때마다 변경되지 않고, 명확한 타이밍에 값이 변경이 됨으로써, 값을 예측하고 디버깅할 수 있다.

[React calls Components and hooks]

리액트는 유저에게 최적화된 방식으로 화면을 구성하는 것을 포커싱을 두고 있기 때문에, 컴포넌트와 Hooks의를 작성할 때 지켜야할 규칙을 명시하고 있다.

아래는 해당 Rule에 대해서 세 단계로 나누어 설명하는 부분이다.

Never call component functions directly

해당 규칙은 component 함수를 직접 코드 상에서 호출하지 말라는 뜻인데, 예시로 아래와 같다.

function BlogPost() {
  return <Layout><Article /></Layout>; // ✅ Good: Only use components in JSX
}

function BlogPost() {
  return <Layout>{Article()}</Layout>; //   Bad: Never call them directly
}

컴포넌트 함수가 렌더링 중에 함수가 호출되는 시점이 결정되어야 하는데, 이를 JSX를 이용해서 하기 때문에 함수를 직접적으로 호출하면 안된다.

또한 Hooks를 포함하는 컴포넌트라면, 컴포넌트를 직접적으로 호출하게 된다면 Rules of Hooks의 규칙을 위반하게 되므로 조심해야한다.

Never pass around Hooks as regular values

Hooks의 장점은 특정 기능에 대해 독립적으로 모듈화 해서 각 컴포넌트에 사용하도록 할 수 있다는 것이다.
이러한 Hooks는 컴포넌트에 특화된 기능이므로 Hooks의 Rules에 맞추어 사용해야하는 것을 가이드 한다.

Don't dynamically mutate a Hook

Hooks를 동적인 방식으로 정의하여 사용할 수 없다. 예시로는 아래와 같다.

function ChatInput() {
  const useDataWithLogging = withLogging(useData); //   Bad: don't write higher order Hooks
  const data = useDataWithLogging();
}

Don't dynamically use Hooks

또한 Hooks는 사용할 때도 동적인 방식으로 사용할 수 없다.

function ChatInput() {
  return <Button useData={useDataWithLogging} /> //   Bad: don't pass Hooks as props
}

----------------------------------------

function ChatInput() {
  return <Button />
}

function Button() {
  const data = useDataWithLogging(); // ✅ Good: Use the Hook directly
}

function useDataWithLogging() {
  // If there's any conditional logic to change the Hook's behavior, it should be inlined into
  // the Hook
}

[Rules of Hooks]

Hooks는 컴포넌트 함수 내에서 사용할 수 있는 함수인데, 이 또한 별도의 Rule을 가지고 있으며 아래에 상세하게 다룬다.

Only call Hooks at the top level.

우선 Hooks는 use라는 prefix로 네이밍이 된다. Hooks는 Loop 함수 내에서 호출할 수 없고, 중첩 함수, try/catch/finally, if구문 내 등안에서 사용할 수 없으며, 무조건 React 함수 내부의 Top Level에서 호출이 되어야 한다.

function Counter() {
  // ✅ Good: top-level in a function component
  const [count, setCount] = useState(0);
  // ...
}

function useWindowWidth() {
  // ✅ Good: top-level in a custom Hook
  const [width, setWidth] = useState(window.innerWidth);
  // ...
}

Only call Hooks from React functions.

요건 당연한 얘기지만, Hooks는 무조건 React 함수 내에서만 호출해야한다.

지금까지 Rules of React에 대해 알아보았다.
해당 Rule은 좋은 코드 구성이 될 수 있도록 가이드 되는 표현 형식이기도 하지만, React Compiler의 최적화 대상으로 잘 타겟팅 되어 최적화된 렌더링으로 동작하는 코드로 컴파일이 되기 위해 따를 필요가 있다.

React Compiler 직접 사용해보기

우선 React Compiler를 설치하기 전에, 우리의 코드베이스가 Compiler에 적합한지 체크해볼 수 있다.

npx react-compiler-healthcheck@latest

위를 실행하면
- 컴포넌트들이 얼마나 성공적으로 최적화가 될지, 얼마나 더 나아지는지 확인.
- StrictMode 사용성을 체크함. 이것을 활성화하고 따르는 것이 Rules of React를 따르는 부분에 더 최적화 시킬 수 있음.
- Compiler와 적합하지 않는 라이브러리 사용성을 체크함.

을 확인해볼 수 있다.

위 프로젝트에서는 총 176개의 컴포넌트 중 168개각 성공적으로 컴파일 했다고 나온다.

eslint-plugin-react-compiler

React compiler는 eslint plugin을 포함한다. 이를 통해 편집기에서 바로 컴파일러의 분석을 표시하여 확인할 수 있다. 참고로 이 플러그인은 compiler에 의존되지 않은 상태로 동작하면서, 프로젝트 내에 compiler를 사용하지 않아도 사용할 수 있다.
React팀에서는 이 린트 플러그인이 코드베이스의 퀄리티 향상 개선에 도움을 줄 수 있기 때문에 사용하는 것을 권장하고 있다.

$ yarn add -D eslint-plugin-react-compiler

// eslint config
module.exports = {
  plugins: [
    'eslint-plugin-react-compiler',
  ],
  rules: {
    'react-compiler/react-compiler': "error",
  },
}

해당 eslint Plugin은 Editor에서 Rules of React 규칙의 위반사항을 표시한다. 이 작업이 수행될 때, 컴파일러는 컴포넌트와 Hook의 최적화를 스킵한 것을 의미한다. 그리고 컴파일러는 다른 컴포넌트들을 또 서치하고 최적화를 시도한다.

꼭 Compiler에 의해 최적화가 되어야한다는 것이 아니라면, 너무 억지로 해당 Lint Rule에 맞추어서 수정하려는 노력을 하지 않아도 된다. 단지, 최대한 Lint Rule에 적합하게 되어 있을수록 코드베이스의 Health Check가 좋다는 걸 증명할 수 있다.

`babel-plugin-react-compiler` 를 이용해서 빌드 파이프라인 때 compiler를 실행시킬 수 있는 babel plugin을 제공한다.
프로젝트 install 후에, babel config 세팅을 할 때, 무조건 제일 첫번째로 해당 플러그인이 실행되도록 해야한다.

const ReactCompilerConfig = { /* ... */ };

module.exports = function () {
  return {
    plugins: [
      ['babel-plugin-react-compiler', ReactCompilerConfig], // must run first!
      // ...
    ],
  };
};

[주의 사항]

Javascript의 유연한 특성 때문에, compiler가 모든 위반 사항에 대해서 캐치를 못할 수도 있고 이로인해 정의되지 않는 동작을 하는 React 규칙을 위반하는 컴포넌트나 Hooks를 실수로 컴파일 할 수도 있다.

이러한 이유로 만약 기존에 있던 프로젝트에 Compiler를 사용하고 싶다면, 작은 단위의 디렉토리부터 적용을 하는 것을 추천한다.

const ReactCompilerConfig = {
  sources: (filename) => {
    return filename.indexOf('src/path/to/dir') !== -1;
  },
};

특수한 케이스로, "compilationMode: annotation" 기능을 이용해서 opt-in 기능을 사용할 수 있는데, 이는 "use memo" 어노테이션이 붙은 Component와 Hooks에만 Compiler가 동작하도록 할 수 있다.

const ReactCompilerConfig = {
  compilationMode: "annotation",
};

// src/app.jsx
export default function App() {
  "use memo";
  // ...
}

[현재 세팅할 수 있는 프레임워크]

Vite, Next.js, Remix, Webpack, Expo, Rsbuild, Rspack

Should I try out the compiler?

React Compiler 기능은 아직 experimental 단계이므로, 우와좌왕하는 부분이 많다. 프로덕션 앱에 해당 기능을 적용하는 것 자체가 코드베이스가 Rules of React에 잘 따르는지 체크가 가능할 수 있음. 굳이 해당 기능을 빠르게 적용하려고 할 필요가 없다. 천천히 stable Release될 때까지 기다렸다가 적용하는 것을 추천한다.

그러나 해당 기능이 관심이 많아서 미리 써본다면 별도의 Working Group이 있어서, 여기에 합류해서 추가 정보를 얻어보는 것을 추천한다.

함께 자라기를 다시 읽으며

Hello이뇽 — Thu, 18 Jul 2024 01:25:06 +0900

[팀 내에서 퍼포먼스를 잘 내는 사람]

가장 성과를 잘 내는 사람은 자기의 포지션에서 능력이 굉장히 뛰어난 사람보다, 능력은 어느정도여도 사회성이 좋은 사람이다.
사회성이 좋으면 내가 힘든 상황이 와도 언제든 도움을 받을 수 있다. 또한 내가 도움을 주면서 나 역시 한번 더 성장할 계기가 된다.
또한 무엇보다 팀원들끼리의 신뢰와 안정감을 유지할 수 있음.

[애자일, 삶의 애자일]

내가 생각한 애자일은, 개발에서만 적용되는 방법론이 아닌, 우리 삶에 적용할 수 있는 철학이다.
애자일을 통해 우리의 삶을 더 나은 방향을 이끌어 갈 수 있다.

애자일은 빠른 액션에 그에 대한 피드백 수용이다.

불확실성과 친밀해지기 위한 두가지 키워드: 학습과 협력

[학습]
목적지와 우리의 위치를 항상 정검하고, 정확한 방향으로 가고 있는지를 수시로 체크를 한다.
이로인해 방향이 계속 재조정이 될 것인데, 틀어지는 방향에 대해 우리는 계속 학습을 해야한다.

[협력]
좋지 않은 일은 팀내 한명만 겪고 같이 공유하면, 다같이 예방을 함으로써 많은 리소스 절감을 할 수 있다.
반대로 좋은 일은 팀내 한명만 겪고 같이 공유하면, 다같이 좋은 부분을 적용함으로써 확장시킬 수 있다.

이로써 팀 단합은 복리 현상이 일어난다.

혼자서 뛰어난 사람은 고독하게 혼자서 해결하고 혼자서 성장해야한다.

우선 스스로 너무 뛰어나려고 하지 않기. 잘난척 하지 않기. 겸손해지기.
상대방의 공로를 인정하기. 받아들이기.
비판보단 칭찬하기.

내가 겼었던 점은 자주 공유해보자. 반대로 다른 사람들이 공유하는 부분들을 귀찮아하지 말고 적극적으로 들여다봐보자.

내 삶의 목표에서 잘 나아가고 있는지 수시로 체크를 해보자.
내 업무 방식을 계속 점검하고 개선한다.

현재 내가 놓여있는 상황을 돌이켜보고 생각을 정리

Hello이뇽 — Sun, 16 Jun 2024 18:52:22 +0900

최근에 약 3주 정도의 리프레시 기간을 통해 짧지만 많은 것을 공부하고 쉬고 보고 놀았다.
그리고 다시 콴다 팀으로 돌아간지 어느덧 약 2주 정도 지났다.

돌아가서 지금까지는, 기존의 CoreGroup에서 진행하던 테스크보단, 우리 콴다가 앞으로 AI 산업 안에서 교육 서비스로 살아남기 위해 새로운 모습으로 리뉴얼 중인데 이와 관련된 많은 준비에 몰두중이다.

이와 관련하여 나 역시 새로운 지식을 습득해야할 것이 많아진 상태이다.
React-native, 안드로이드 기반의 개발을 의한 학습을 하며 지금은 이미 어느정도 실무에 기여하고 있다.

어떻게보면 지금 새로운 것들을 어느정도 마주하고 있고, 새로운 서비스에 대해서도 곧 마주하게 될 예정인데,
지금의 내 상태는 생각보다 열정이 그렇게 크지않다. 심지어 큰 Lesson Learn이 있는 느낌도 아닌 것 같다.

내가 노력의 방향성이 잘못된 것일까?
분명 지금은 새로운 도메인에 대한 기술적 실무를 마주할 수 있도록 제대로 준비를 하고 있으나, 나는 무언가 더 큰 폭발적인 성장성을 원하는 듯 했다.

내가 리프레시 마지막 주에 치앙마이 여행을 다녀왔는데, 사실 그렇게 재밌지 않았다. 그냥 이전에도 몇번 다녀왔던 동남아 여행과 다를게 없었다. 그럼에도 어느정도 어래 쉬는 기간이니까 어디라도 다녀와야 되지 않나 생각에 가까운 곳으로 다녀온 것이긴 한데, 그렇게 큰 감흥이 없었다.

그리고 지금들어 생각이 드는건, 차라리 큰 돈이 들더라도 평소에 정말 갈 수 없었을 만한 알레스카 같은 곳을 다녀올 걸 그랬다 라는 느낌이 들었다.

그리고 어쩌면, 지금의 내 콴다 생활도 지금 이때와 동일한 상태이지 않을까 생각이 들었다.

지금 내가 테스크에 쫒기지 않아 무엇이든 Lesson Learn을 할 수 있는 이 기간을, 빠르게 배울 수 있는 가벼운 것보단, 내가 언제 배울 수 있을지 모르는 것을 이때 공부하고 있으면 좋지 않을까 생각이 들었다.

그렇다고 당연히 아무거나 공부하기보단, 효과적으로 내 개발 역량을 끌어올릴 수 있는 것을 해야한다.

무엇이 있을까?

문제 해결 능력을 올리려면 아래들이 있을 것이다.

- 안드로이드 (웹뷰 개발을 많이 하면서 네이티브 영역도 들여다 볼때가 참 많았기 때문에, 이 영역에 대한 이해도를 높인다.)
- 백엔드 (서비스 내부적인 시스템 이해도를 높이려면 필수)

우선 위 두개가 지금 당장은 좋아 보인다. (사실 iOS도 탐나는데 지금은 욕심내지 말자.)

Rust로 뭔가를 할 수 있나?
- 더 빠른 E2E 테스트 코드?
- Rust 기반 이미지 최적화 기능?
- Rust 관련된 sharp 같은게 있을까?
- 안드로이드 빌드를 Rust로?

현재 이러한 Lesson learn을 효과적으로 학습하고 몰두하려면, 내가 그 상황에 쳐해놓고 몰두하게 해야한다.
- 안드로이드 백로그 테스크를 직접 처리한다. 내가 한다.
- 안드로이드 관련 CI/CD 인프라적인 부분을 내가 직접 개선한다.
- mobileClient 팀의 인프라 담당을 내가 직접 한다.

Spring은 사이드 프로젝트를 통해서 해보자.

내가 가진 내적 가치에 대해

Hello이뇽 — Sun, 16 Jun 2024 17:19:17 +0900

리프레시 기간동안 여러 책을 읽었는데, 그 중 공간이 주는 가치에 대해 다루는 글을 읽게 되며, 문득 나에 대한 내적 가치에 대해서도 생각을 해보게 되었다.

희소가치란, 그 시장에 있어서 수요보다 공급이 부족한 현상을 말한다.
나 라는 사람에 대해서 내적 가치를 정리해보면,

- 나는 개발자이다.
- 웹, 앱 서비스 개발이 가능한 사람이며, 어느정도 컴퓨터 공학적인 지식을 가지고 있다.
- 새로운 것을 배우고 학습하는 것을 즐겨하며 시간 보내는 것을 꺼려하지 않는다.

위 정도로 될 수 있을 것 같고, 이를 잘 살리기 위해서는 나의 전문성을 잘 살리는 것이 중요하다.
전문성을 살리기 위해서는, 특정 분야에서 이해도가 높고 경험을 통한 많은 인사이트를 가지고 있는 사람을 말한다.

콴다 내에서는 내가 발산할 수 있는 가치가 무엇일까?

코어 그룹에서 매출을 올리기 위해 진행하는 프로젝트에 필요한 개발을 문제없이 진행.

그 이상으로 내가 줄 수 있는 가치

유저에게 더 좋은 유저 경험을 준다.
안정적인 개발 환경을 구축한다.
좋은 문화를 만들어 낼 수 있는 능력.

약 3주 간의 리프레시 시간을 가지게 되었다.

Hello이뇽 — Tue, 21 May 2024 00:35:49 +0900

현재 다니고 있는 회사에서 어느덧 3년 이상 근무를 하게되서 리프레시 휴가를 가지게 되었고, 24년 5월 15일 공휴일을 시작으로 6월 2일까지 약 3주 가까이 나의 시간을 가질 수 있는 기회가 생겼다.

그리고 지금은 벌써 리프레시 휴가를 쓴지 5일차가 끝나간다.

사실 이번에 리프레시 휴가를 올리고 나서, 꽤나 장기적인 나만의 시간을 가질 수 있는 이 흔치 않은 기회를 어떻게 써야할지 정말 많은 고민을 했다. 주위 사람들도 그렇고, 대부분 유럽여행을 떠나기 일쑤인데, 나 역시 평소라면 가기 힘든 곳이기 때문에 이번 기회에 유럽여행을 다녀와볼까 했다.

그런데 또 한편으로는, 나는 지금 욕심내고 싶은 활동들이 너무 많았다.
평소 회사 일로 너무 바빠 하지 못했던 주식과 부동산 공부라던가, 하루종일 영어 공부 몰두하기를 차라리 이번 기회에 해봐야겠다 생각도 들었다.

과연 내가 제일 하고 싶은 것은 무엇일까 생각을 했을 때,
지금 당장 여행을 못가는 것이 많이 아쉽기는 하지만, 사실 유럽여행은 언제든 나이 들어서도 다녀올 수 있겠다 생각이 들었고,
평소 내가 하려했지만 바빠서 하지 못한, 지금 당장 내가 하고 싶은, 어쩌면 지금이 아니면 좋은 시기를 놓칠 수도 있지 않을까 생각이 들었던 활동들을 이번 기회에 한번 미련없이 해보아야 겠다 라는 생각이 들었다.

그래서 약 3주 가까운 시간동안 나는 아래의 TodoList들을 끝내겠다 라는 목표를 세웠다.

- RN을 통해서 작은 사이드 프로젝트를 끝내기.
- 오랜만에 구미에 내려갔다 오기.
- 영어 독해, 회화 공부에 하루종일 몰두하기.
- 주식, 부동산 공부를 하기.
- 닌텐도 스위치로 '젤다의 전설' 게임하기.
- 치앙마이 다녀오기.

현재 5일차 동안 상황

RN 공부 및 사이드 프로젝트

RN을 통한 작은 사이드 프로젝트를 무사히 잘 마쳤다. 애초에 매우 작은 단위의 프로젝트였다보니 빠르게 끝낼 수 있었던 것 같지만, 그럼에도 이를 통해서 RN에 대한 이해도를 꽤 많이 올릴 수 있었던 것 같다.

그리고 사실 회사에서도 차근차근 RN을 도입하기 시작하면서, RN에 대한 더 많은 이해도를 올리고자 강의도 끊고 공부를 계속 하긴 했는데, 생각보다 집중도 많이 떨어지고 시간을 잘 보내는 느낌이 나지 않았다.
어쩌면 아직은 휴가기간이고 필요를 크게 느끼는 상황에 몰려있는 상태가 아니기 때문일 수도 있겠다 라는 생각이 많이 들었다.

그래서 사실 리프레시 시작하고도 계속 회사 슬랙을 보고 RN 공부를 하고 그랬는데,
다행히 앱 개발부터 빌드, 배포 플로우까지 해보고 어느정도 컨텍스트가 생겼으니, 오늘 5일 차를 기준으로 더 이상 코드를 보지 않으려고 한다.

다른 더 재미있게 몰두할 수 있는 것에 시간을 보내보자.

구미에 내려갔다오기

진짜 몇년만에 구미에 가서 내가 돌고 싶었던 곳, 그리워 하던 곳들을 샅샅히 돌고 왔다.
정말 다니는 내내 아직도 익숙하고 친숙한 곳들이었기 때문에, 시간 여행을 하고 온 느낌이었다. 아직도 며칠 전 돌았던 그 동네가 꿈처럼 느껴진다.

내일부터 몰두할 것들

내일부터는 나만의 루틴을 가지고 다시 시간을 보내보려고 한다.

- 아침에 운동 후 가볍게 밥 먹기
- 오전까진 연리목 카페 가서 영어 환경 놓여있기
- 증권, 주식 공부.
- 게임하기

그리고 다음주에는 치앙마이 여행

그래도 나름 장기 휴가인데, 아예 해외여행을 안가는 것은 좀 아쉬워서 4,5일 가까운 치앙마이 여행을 끼워넣어봤다.
그래야 휴가가 끝나고 나름 휴가를 보내고 온 느낌이 들 것 같아서.
그렇지만 그 전까지는 정말 내가 하고싶은 것들 최대한 많이 집중해서 이루고, 휴가도 잘 보내고 오자!!

[React Native] RN 공부하며 익힌 내용 정리

Hello이뇽 — Wed, 15 May 2024 00:03:55 +0900

무지성으로, RN에 대한 기본 개념 쌓아야 하는 내용들을 작성한 내용.

ReactNative가 Native 코드로 변환 및 동작할 수 있는 원리

우선 ReactNative 코드가 Android, iOS 환경에서 돌아갈 수 있는 코드로 컴파일이 가능한 이유는, 각 네이티브의 구성 요소와 매핑이 되도록 정해져 있는 react-native에서 제공하는 CoreComponent를 사용하여 구현할 수 있기 때문이다.

<View>, <Text>등, react-native에서 정한 Core Component를 기반으로 구현하면, 빌드 타임에 이러한 요소들이 각 네이티브의 요소로 변환되면서 UI를 그릴 수 있게 된다.

그러나 이렇게 native로 변환되는 부분은 UI 담당인 마크업 부분만 컴파일되서 변환되는 것이고, 돌아가는 내부로직 코드들이 네이티브 코드로 변환되는 것은 아니다.

따라서, Native Thread, JS Thread 두가지가 존재하게 되는데,
Native Thread는 네이티브 단 UI를 그리고 동작시키는 담당하고, JS Thread는 내부 로직이 돌아가는 부분을 담당한다.

User Interaction을 받은 이벤트 호출, 혹은 반대로 내부 로직의 결과로 인한 UI 조작을 할때마다 각 스레드별 인터렉션이 필요로 하게 될건데, 이는 직접 인터렉션은 할 수 없고 Bridge를 통해서 한다.

Bridge는 웹뷰 개발을 해본 사람이라면 알듯이, 네이티브와 Javascript간 통신하기 위한 인터페이스를 말한다.
이를 알아서 구축하고 인터렉션한다.

정리하면,
- UI는 네이티브
- 내부로직은 여전히 Js
- 각 스레드는 Bridge를 통해 인터렉션함.

기본 컴포넌트 개념

[Core Components와 Native Components]

https://reactnative.dev/docs/intro-react-native-components

해당 섹션에서는 React Native가 컴포넌트로써 어떻게 동작하는지 설명한다.

[Views and mobile development]

안드로이드와 iOS를 개발할 떄 가장 기본적인 UI 블록은 view 이다.
텍스트, 이미지, 혹은 유저 인풋값에 대한 화면에 보여지는 요소를 담을 수 있는 작은 사각형 엘리먼트이다.

view는 다른 view를 포함할 수 있다.

[Native Components]

React Native는 Javascript를 통해서 React Component를 구성하고 views를 작성한다.

React Native가 이에 유사되는 Android와 iOS View를 생성하게 되는데, 이를 위해 Android와 iOS에서 보여지는 동일한 view로 구현하도록 제공되는 컴포넌트가 있는데, 이를 Native Components 라고 부른다.

React Native 바로 앱 구축을 할 수 있는 기본 구성 요소를 Core Components라고 한다.

또한 별도로 Android와 iOS에 최적화된 별도의 Native Component를 사용할 수도 있다.

이러한 컴포넌트 생태계를 활발하게 하기 위한 공간도 있음.

https://reactnative.directory/

[Core Components]

RN에서는 다양항 Core Components를 가지고 있음.

(Native Component와의 차이를 정확히 몰라서 별도로 찾아봤는데, 그냥 React Native에서 기본적으로 제공하는 기본 컴포넌트를 얘기하는 것이다.)

위 표 외에 더 많은 Core Component들은 아래 링크에서 확인할 수 있음.

https://reactnative.dev/docs/components-and-apis

디버그 하는 방식 - 중요

android는 Flipper를 많이 사용하는 것 같다.

iOS는 아직 조금 더 알아보아야 함.

기타 개념

[CPU 환 경] x86_64와 ARM 64의 차이

과거에는 Intel에서 제작한 x86 그리고, AMD에서 x86을 호환하여 더 확장시킨 x86_64를 기반으로 PC 환경이 갖추어져 있었기 때문에 개발자들이 큰 문제를 겪지 않았지만, 최근 ARM 기반의 CPU가 큰 성장세를 띄고 PC 시장에서 많이 사용하게 되면서 개발자들이 이러한 CPU 환경에 대해 신경을 쓰기 시작하게 되었다.

원래 ARM은 저사양 디바이스, 저사양 기기에서 사용되던 단순한 아키텍처를 가진 방식인 만큼 저사양, 저전력 기반으로 사용되던 CPU 였으나, 시간이 흐르며 ARM의 성능이 x86 못지 않게 빨라지면서도, 저사양, 저전력 스펙을 그대로 유지되며 발전해오면서 x86이 꽤차고 있던 자리를 압박하기 시작했고, AWS의 Cloud Machine Craviton 출시와 Apple의 M1처럼 ARM을 이용한 제품이 하나씩 나오기 시작하며, 결국 PC 시장에서까지 ARM이 급속도로 퍼지기 시작했다.

그리고 우리 개발자 환경에서까지 ARM 혹은 x86이 섞이기 시작하며, 어떤 시스템을 돌리냐에 따라 CPU의 환경까지 고려해야될 시키가 오게 되었다.

[로그인 인증 처리]

Encrypt Storage 모듈을 이용해서 처리할 수 있음.

[Navigation]

react Navigation 모듈을 이용하면 편하다.
항상 모듈을 이용할 때마다 iOS를 위해 아래 명령어를 실행 시켜줘야 한다.

npx pod-install ios

[접근권한]
react native pemissions 모듈을 이용하면 편하다.

사이드 프로젝트 진행한 내용 소개 및
ReactNative를 사용해보며 느낀 소감

정말 간단하게 CoreComponent만을 가지고, 뽀로로 이미지 올려서 더하기,빼기, 결과보기 하는 앱을 만들어 보았다.
(전혀 예쁘지 않다)

코드 아키텍처는 리액트와 큰 차이가 없어서 어렵지 않았지만, 의외로 어려웠던 부분은 마크업과 스타일을 적용하는 부분이었다.
우선 기본 HTML,css를 절대 쓸 수 없으며, react-native에서 정해진 Core Component를 기반으로 구현해야 하는데, 아직 어떤 것들이 있는지 어떤 프로퍼티가 어떻게 동작을 해야하는지 잘 모르던 상태여서, 내가 원하던 방식에 대한 컴포넌트와 프로퍼티를 찾기가 좀 힘들었다. 스타일 적용 방식도 css와 꽤 많이 다르다. flex나 padding 등 특정 스타일에 대해 적용하려할 때 필요로한 프로퍼티가 조금씩 다른게 많아서 꽤나 찾아보아야 했다.

그래도 작게나마 하나 만들고, 클론 코딩 하나 해보고 나니 감이 꽤나 잡혔다. 네비게이션이나 인증 처리 같은 작업들은 온전히 JS 코드로 작업하기보단, 네이티브 변환 때문이라도 왠만하면 라이브러리를 쓰는 방식으로 하는 것 같다.

향후 진행해보면 재밌을 내용 정리

- preact를 이용하여 번들 사이즈 줄여보기(가능할지 아직 검색도 안해봐서 우선 작성해봄)

- CI/CD 구축

- TDD 환경 세팅

- CodePush를 위해 업로드하는 파일들을, MS Cloud Storage가 아닌, 자체 Storage에서 업로드해서 사용할 수 있는 방식.