본문 바로가기

분류 전체보기

(66)
[공지사항] 프론트엔드 직무 관련 무료 멘토링 진행해요 23.06.01 업무가 바쁜 관계로 잠깐 중단합니다. 안녕하세요. 블로그 주인 행복한 시지프 라고 합니다. 멘토링 활동에 관심이 많이 생겨서, 일단 무료 멘토링을 진행해보려고 합니다. 부족한 점이 많지만, 제가 도움이 될 수 있는 한에서 도움을 드려보고자 해요. 관심있으신분 읽어보시고 연락주세요. 저의 지인이든, 처음보는 분이든 상관없습니다. 한줄 소개 비전공자에서 토스 프론트엔드 개발자가 되기까지. 학습방법을 많이 고민했고, 가장 효율적인 학습법을 제안해드려요. 나의 커리어 패스와 경험 소개 2021.1 프론트엔드 개발 시작 2021.2 발표시간 계산기 웹사이트 출시 2021.3~2022.1 IT 벤처창업동아리(SOPT) 활동 2022.2~10 우아한테크코스 4기 2022.12~ 토스 프론트엔드 개발자..
토스 입사 후 7주간의 생활과 생각정리 그간의 회사생활 입사하고 7주가 지났다. 7주동안 54개의 PR을 올렸다. 진짜 시간 가는 줄 모르고 하루종일 문제를 풀었다. 현재 신규회원을 모으기 위한 서비스를 만들고 있다. 도메인은 정해져 있지 않고, 신규 회원을 모을 수 있다면 어떤 일이든 한다. 그러다보니 아이디에이션에도 많이 참여한다. 스타트업에서 일하는 기분이다. 토스는 수백개의 스타트업이 모인 조직이라고 들었는데, 진짜다. 각각의 팀이 스타트업 형태로 일한다. 그러면서 공동의 목표를 공유한다. 승건님이 말씀하시는 피자 두판의 법칙이란게 있는데, 한 팀의 인원이 8명이 넘으면 비효율, 불통이 생긴다는 것이다. 토스는 이런 가치를 지키기 위해서 조직을 나누고 나눠서, 소규모 스타트업 형태로 운영한다. 매력적이다. 데이터 기반 사고가 재밌다. ..
토스 & 우아한형제들 합격, 회사 선택 이유와 앞으로의 목표 서언 안녕하세요. 이번에 신입 프론트엔드 개발자 채용을 거쳐 토스(코어)와 우아한형제들에 합격했습니다. 프론트엔드 개발자로서 두 회사 모두 객관적으로 너무나 좋은 회사들이고, 저에게 과분한 기회가 찾아왔다고 생각합니다. 둘 다 엄청나게 가고 싶은 회사였기 때문에, 하나를 놓는다는게 여간 어려운 일이 아니었습니다. 이 글은 회사의 우열을 따지지 않으며, 저의 주관적인 선택 과정을 담습니다. 내적으로 이미 정했지만, 스스로 합리화하지 않으면 아쉬움이 떠나가지 않을 것 같아 명문화해 봅니다. 외부적인 기준을 비교하는 과정 저는 회사에 다녀본 적이 없었기 때문에 선택이 특히나 어려웠습니다. 처음에 두 회사를 두고 외부적인 기준을 비교했습니다. 지인들에게서 이 회사는 이래서 좋더라, 저 회사는 저래서 좋더라 하는..
3. 우아한테크코스에서 후회되는 점 시리즈 0. 우아한테크코스 회고 1. 우아한테크코스에서의 기술 성장 기록 2. 우아한테크코스에서의 자기 성장 기록 3. 우아한테크코스에서 후회되는 점 3. 우아한테크코스에서 후회되는 점 후회되는 점을 서술하고자 한다. 이후 삶에서 신경써야 할 가장 중요한 부분들이다. 1. 건강 건강을 많이 신경쓰지 못 했다. 반년 이상 아침을 굶었다. 일년 정도 운동을 하지 않았다. 확실히 힘을 몰아썼다는 느낌을 받는다. 이는 지속가능한 자기계발이 아니다. 롱런하기 위해서는 꼭 건강을 챙겨야 한다. 2. 일상의 루틴 나는 하나에 집중하면 나머지는 모두 미루는 경향이 있다. 청소, 빨래, 글쓰기, 독서, 친구와의 연락 등 미뤄온 것들이 너무 많다. 일상에 오직 하나만을 넣으려고 하기 때문에 다른 모든 것을 미루게 된다. ..
2. 우아한테크코스에서의 자기 성장 기록 시리즈 0. 우아한테크코스 회고 1. 우아한테크코스에서의 기술 성장 기록 2. 우아한테크코스에서의 자기 성장 기록 3. 우아한테크코스에서 후회되는 점 2. 우아한테크코스에서의 자기 성장 기록 다음으로 자기 성장 (기술 이외의 성장)을 서술하고자 한다. 1. 리더 의식 생각해보면 성인 이후로 리더 역할을 많이 했었다. 성향 상, 계획적이고, 효율성을 추구하고, 문제해결을 좋아하다보니까 집단을 주도할 수밖에 없었다. 문화예술동아리 회장, IT 벤처창업동아리 SOPT 웹파트장, (분대장) 등을 해왔다. 그러면서도 스스로를 리더라고 정체성을 부여한 적은 없었다. 나의 직함은 리더였고, 그 자리로서 해야할 일을 마땅히 해냈음에도 리더 의식을 가지진 않았다. 그렇기 때문에 은연 중에 구성원과 팀을 온전히 고려하지 ..
1. 우아한테크코스에서의 기술 성장 기록 시리즈 0. 우아한테크코스 회고 1. 우아한테크코스에서의 기술 성장 기록 2. 우아한테크코스에서의 자기 성장 기록 3. 우아한테크코스에서 후회되는 점 1. 우아한테크코스에서의 기술 성장 기록 우아한테크코스를 진행하며 기술적으로 정말 많이 성장했다고 생각한다. 어떤 부분이 부족했었고, 어떤 노력을 통해 얼마나 성장할 수 있었는지 서술하고자 한다. 1. JavaScript 성장 우테코 이전에 자바스크립트를 정말 못 했던 것 같다. 리액트 개발자로서 자바스크립트의 중요성은 익히 들어 알고 있었다만, 왜 중요한지 어떤 점을 잘 해야 하는지 알지 못 했다. spread operator, 불변성, Promise, nullish coalescing 등의 개념을 알고 사용할 줄 안다면 자바스크립트를 잘 하는 것이라고 ..
0. 우아한테크코스 회고 시리즈 0. 우아한테크코스 회고 1. 우아한테크코스에서의 기술 성장 기록 2. 우아한테크코스에서의 자기 성장 기록 3. 우아한테크코스에서 후회되는 점 우아한테크코스 회고 우아한테크코스 4기 프론트엔드 과정이 끝났다. 2022월 2월 8일부터, 11월 25일까지 약 10개월의 과정이었다. 매일 아침 10시부터 최소 밤 10시까지 공부했다. 공부 과정에는 기술 공부, 프로젝트 개발, 애자일 공부, 글쓰기, 리더 공부, 면접 준비 등이 포함된다. 고등학교 3학년 이후로 이렇게 열심히 한 적은 처음이었다. 인생에 고3 때처럼 노력하는 시기가 또 와야 한다고 생각하고 있었는데, 그게 우아한테크코스 기간이었다. 고등학교 때 2년의 공부를 통해 이전에 상상할 수 없는 대학교를 간 것 처럼, 올해 1년간의 공부를 통해..
혹시 무분별하게 Suspense 를 사용하고 계신가요? (react-query) 더보기 서언 React v18 부터 Suspense가 API call에 따른 Loading 상태를 표현할 수 있게 되었습니다. 그에 따라, react-query, swr 같은 data fetching library가 Suspense를 지원하고 있습니다. suspense 옵션만 true로 설정해주면, API 요청 훅이 알아서 내부 처리를 통해 Suspense를 동작시킵니다. 이로써 로딩을 선언적으로 보여줄 수 있게 되었고, ErrorBoundary 조합과 함께라면 컴포넌트는 Success 케이스만 표현하면 되었습니다. 이런 혁신에 대해서는 잘 인지하고 있었지만, Suspense의 위험성에 대해서는 인지하지 못 했습니다. 특히 저희 서비스는 잘못된 Suspense 사용으로 어플리케이션 로딩 성능 저하를 겪었..
A use case of Function Overloading in TypeScript (useRef, remove null/undefined) 서언 TypeScript에는 Function Overloading 기능이 있습니다. 이번에 Function Overloading의 강력함을 깨닫고, 이를 공유하고자 아티클을 씁니다. 함수 오버로드가 왜 필요한지 이해하고, useRef 예시와 저희 프로젝트에 적용해본 예시를 설명드리겠습니다. 타입스크립트에서 함수 오버로딩이 왜 필요한가? 자바스크립트는 인자의 개수 제한, 인자의 타입 제한이 없습니다. 코드 예시를 보겠습니다. function add(a, b, c) { if (b) { if (c) { return a + b + c; } return a + b; } return a; } console.log(add(1, 2, 3)); // 6 console.log(add(1, 2)); // 3 console...
ErrorBoundary로 Toast, ErrorFallback 등 공통적인 에러를 처리해보자 서언 현재 꼭꼭 서비스를 운영하고 있습니다. 안정적인 서비스 운영, 보다 나은 유저 경험을 제공하기 위해 (1) 섬세하고, (2) 빈틈 없는 에러 처리가 필수라는 생각이 들었습니다. (1) 섬세하다는 것은 상황에 맞는 에러를 적절히 보여 준다는 것을 의미하고, (2) 빈틈 없다는 것은 모든 API 요청에 에러 케이스를 고려한다는 것을 의미합니다. 그러면 고민이 심화됩니다. (1) 에러를 어떤 기준으로 분류하여 처리할 수 있을까? (2) 모든 요청에 에러를 붙인다면, 반복을 줄일 수 없을까? 이를 고민하여 나름대로 에러를 분류해보았고, ErrorBoundary(에러 경계) 라는 도구를 활용해 선언적이고 추상화된 에러 처리를 시도해보았습니다. 본 글은 에러 처리 전략, ErrorBoundary를 다룹니다. ..