훈의 개발이야기

FE 개발이 날이 갈수록 복잡해지고 있다.React를 중심으로 하는 생태계가 빠르게 발전하면서 FE 개발자의 역할과 책임 또한 점점 넓어지고 있다. UI 컴포넌트 설계, 상태 관리, 스타일링, 테스트,브라우저와 성능 최적화, 디자인 시스템 등 깊이 파고들어야 할 주제들이 넘쳐나고 있다.  문제는 이렇게 FE 개발의 영역이 전문화되고 복잡해질수록,FE 개발자로서 커리어를 시작한 나와 같은 사람들은SW 개발에서 자연스럽게 놓치는 영역이 생긴다는 점이다. 특히 내가 FE개발자로서 놓치게 되었던 영역이 바로 '인프라와 운영'이다.  FE 개발자는 본래 브라우저 안에서 동작하는 코드와 사용자 인터페이스에 익숙하다.그렇다 보니 서버 환경이나 인프라에 대해서는 접할 기회가 많지 않다.그래서 프로덕션 환경에서 발생할 ..

최근 ChatGPT Pro 버전을 구독하고, 여러 가지 실험을 해보고 있다.특히 deep research 후기는 일상 블로그에 남겨두었으니 궁금하신 분은 참고해보시면 좋겠다.  GPT deep research 체험한다고 30만원 쓴 후기2월 3일 업데이트된 deep research 기능  무슨 기능인지는 여기서 보시고..https://news.hada.io/topic?id=19036 OpenAI, Deep Research 공개 | GeekNewsOpenAI가 ChatGPT에 도입한 새로운 에이전트형 기능 "심층 연구"인터ghoon99.tistory.com  그러던 중, 웹 기반 프론트엔드 개발자로서 문득 궁금한 점이 생겼다.  우리는 보통 React를 활용해 UI를 구성하면서 자연스럽게 선언형 / 함수형..

“어떤 것이 좋은 코드라고 생각하세요?” 개발자라면 한 번쯤은 들어봤을 만한 이 질문은,내가 개발을 시작할 때부터 지금까지 계속 이어져온 고민이기도 하다. 우리는 항상 더 나은 코드를 작성하려 애쓰지만, 무엇이 “좋은 코드”인지 쉽게 단정 짓기 어렵다.흔히 “좋은 코드”라고 하면 깔끔한 구조, 뛰어난 가독성, 높은 재사용성 등을 떠올리기도 한다.  사실 “좋음”이라는 것은 상황과 가치 판단에 따라 다르게 해석될 수 있는 상대적인 개념이 아닐까 싶다.이 글은 오랜 시간 동안 고민해왔던 바로 그 지점에서 시작되었다.  나는 좋은 코드가 맥락에 따라 달라질 수 있는 개념이라 생각하고,그 맥락에는 팀 내 멘탈 모델 공유가 큰 영향을 끼친다고 본다.  이 글에서는 좋은 코드의 맥락 의존성(상대성)과,좋은 코드를 ..

웹 서비스 개발 과정에서 프론트엔드 개발이라는 역할이 생긴 지 그리 오래되지 않았다.초기에는 간단한 웹 문서를 보여주는 수준에서 시작하여,이제는 거대한 애플리케이션을 개발하는 단계까지 많은 발전을 거쳤다.  프론트엔드의 발전과정에 대한 좋은 글이 있어 남겨둔다.https://yozm.wishket.com/magazine/detail/1289/ 시니어 개발자가 말하는, 프론트엔드 역사와 미래 | 요즘IT웹 프론트엔드는 웹 서비스 발전에서 막내 격으로 생긴 포지션입니다. 프론트엔드라는 영역이 갑자기 생겨난것은 아니지만 지금처럼 이렇게 선명하게 프론트엔드와 백엔드가 세분화된 배경에yozm.wishket.com 위 글에서도 언급하듯이 이렇게 최근에는 간단한 문서를 넘어 다양한 웹 서비스가 등장했고,React, ..

이 함수가 에러를 던진다는 사실을 어떻게 알릴까?  /** @throws {DuplicateNumberException} */  private checkDuplicateNumber(input: string): void {    if (new Set(input).size !== input.length) {      throw new DuplicateNumberException();    }  }최근 입력값 검증을 처리하는 모듈을 작성하면서 한 가지 생각이 떠올랐다. 내가 작성한 함수가 특정 상황에서 오류를 던질 수 있는데,이 함수를 사용하는 쪽에서도 오류가 던져질 수 있는 가능성을 명확하게 알 수 있도록 할 수는 없을까? 이 글은 이런 의문에서 시작되었다. throws 절에 대한 아이디어, Java의 Ch..

프론트엔드 개발을 하면서 백엔드에서 자주 논의되는 특정 개념들이 (ex. 의존성 주입 등)상대적으로 덜 등장하는 이유가 항상 궁금했다. 단순한 느낌일까, 아니면 실제로 그러할까? 이 글은 이러한 의문에서 출발했다. 마침 같은 주제에 대하여 다른 언어로 작성된 (각각 FE, BE를 대변하는 JS, JAVA) 코드들이 존재했고이 코드들에 대한 PR 리뷰/코멘트 의 양도 아주 많은 컨텐츠를 발견했다. 그래서 이것들을 간단한 방법으로 직접 데이터를 수집하여 분석해 보았다.혹시라도 이 데이터 활용에 대한 문제가 있을 경우 이 글은 삭제할 예정이다.  분석 과정우아한 테크코스에서 사용한 public 레포지토리 사용 https://github.com/woowacourse/java-racingcarhttps://git..

최근 "잘하는 개발자"란 어떤 사람일까?라는 질문을 받았다. 이 질문에 대해 처음에는 막연하게 생각했지만,시간이 지날수록 내가 만났던 개발자들 중 '잘한다'라고 느꼈던 사람들의 공통점을 떠올려보게 되었다. 또한, 실제 업무 환경에서 누구와 함께 일하면 좋을지,다수에게 도움이 될 사람은 어떤 특징을 가질지에 대해서도 고민해 봤다. 그 결과, 몇 가지 중요한 요소들을 정리할 수 있었고 나의 생각을 남겨보기로 했다.  본인의 색깔이 있는 사람잘하는 개발자는 자기 자신을 깊이 이해하고, 자신의 강점을 효과적으로 활용할 줄 아는 사람이다. 이들은 자신이 잘하는 것과 부족한 것을 명확히 알고 있으며,이를 바탕으로 조직 내에서 중요한 역할을 맡는다.  예를 들어, 비즈니스적 이해도가 뛰어나고 비개발 직군 팀원과의 소..

최근 토스 FE팀에서 진행한 4주 동안의 멘토링 프로그램을 마쳤다.지원 과정부터 멘토링 내용, 좋았던 점과 아쉬웠던 점, 그리고 그 외 이야깃거리를 가볍게 남겨보려고 한다.  지원 배경  6월 말, 종강을 맞이하고 간만에 누리는 대학생의 방학대학생으로서의 여름방학은 거의 2년 만인 듯하다. 딱히 방학 계획이 없었던 지라, 하루하루 빈둥거리며 방학 백수생활을 제대로 즐기고 있었다.그때 전 동료분께 한 소식을 전달 받았고 마침 6개월 동안 잠시 쉬었던 개발 재활치료도 할 겸 소문으로만 듣던, 토스의 일하는 방식을 직/간접 경험할 수 있는 기회가 되었으면 좋을 것 같아 신청하게 되었다.  프로그램 소개멘토링 소개 페이지 [토스 프론트엔드 멘토링] Frontend Accelerator 1기 | Notion프론트..

때는 2024년 1월, FE 개발자로서 다니던 회사를 퇴사 후 백수 생활을 즐기고 있었던 시절방구석에 박혀있던 클린아키텍처: 소프트웨어구조와 설계의 원칙이라는 책을 보게 되었다. 개발자라면 언젠가 한 번쯤은 읽어보겠지 라는 막연한 생각 + 들고 다니면 뭔가 멋져보이는 책이라 구매했던 것 같다. 들리는 말로는 주니어 때, 중니어(?) 때, 시니어 때 1번씩 보면 볼 때마다 새로운 맛을 느낄 수 있다더라 사실 이전부터 업무를 하면서 프로젝트 구조, 모듈 설계에 관심이 많았고,앞으로 선택의 순간이 찾아왔을 때 적절한 선택지를 제시하고 근거를 들고 싶어 한번 읽어보게 되었다.  책에 대한 내용은 생략하고 내가 직접 읽으며 "주니어" "FE 개발자" 관점에서 생각했던 것들, 질문들을 간략히 정리해 보았다.사실 책..