Feeling

정산봇

정산은 우리팀의 큰 아젠다다. 정산 자동화를 위해 4달째 개발을 하고 있고, 개선을 하고 있다. 전체 목표에서 80프로 정도 진행된 상태다. 지금까지는 스프린트를 다 같이 진행하면서 일감을 나누어 개발했는데, 어쩌다보니 내가 정산 담당자가 되었다. 🙄 공식적?으로 담당자가 되니까 프로덕트에 대한 오너쉽이 생기고, 더 애착이 생긴다. 그래서 정산 플로우나 백엔드 로직에 대해 더 이해하려고 하고, 스스로 기획, 개발, UX에 대해 더 적극적으로 의견을 내게 되었다. 코드나 UI/UX에 미흡한 부분도 더 잘 보이고, 일도 더 밀도있게 하고 있다. 쉬지않고 계속 개발을 하는 느낌이라 지치기도 하지만 또 성장할 수 있는 기회라고 생각한다. 화이팅

요즘 참 재밌네. 출퇴근은 힘들지만...

출퇴근이 힘든 건 적응을 못하고있지만 그래도 요즘 공부가 순조롭고 재밌다. 회사 생활도 참 재밌다. 팀데이도 진행했고, 한달에 한 번 비타민카드 쓰기라는 팀 문화도 만들었다. 아래는 팀원들의 메시지. 요즘은 문서화에 신경을 많이 쓰고 있다. 프로젝트, QA, 배포 관련 문서화나 프로세스가 없는 상태여서 부족하지만 하나씩 만들어가는 중이다.

네?! 주니어같지 않다고요!?

이번달 면담 시간에 팀장님한테 주니어 같지 않다는 얘기를 들었다. 저번달 면담하면서 ‘문제 해결능력이 부족하다’라는 피드백을 들었다고 남겼는데 사실 그 뒤에 시간을 더 드릴걸그랬다는 말씀을 하셨다. 사수님의 의도는 뒷 부분이었기때문에 그런 말을 제가 했나요?!라고 놀라셨지만 나는 앞부분에 충격을 받았고, 그게 좋은 자극이 되었다고 말씀드렸다. 그랬더니 내 행동이 주니어 같지는 않아서 마냥 주니어 대하듯 대하지 않고 있나보다 라고 하셨다.

연륜때문인가.

사수님도 칭찬으로 말씀하셨고 나에게도 지금 시점에서 가장 의미있는 칭찬이라 기대치 팍팍 올려서 팍팍 키워달라고 했다. 팍팍크자

연륜의

주니어

한 권으로 읽는 컴퓨터 구조와 프로그래밍

을 읽고있다. 해야할 건 언제나 많지만 CS 지식을 쌓고싶다는 욕구와 동작원리를 알아가면 재밌으니까! 이번달에 다 읽고 정리하는게 목표였는데.... 몹시 더디다. 챕터당 블로그 글 한개씩 쓰는게 목표였는데 중간에 이해를 못하는 것도 있고, 글로 어떻게 정리를 할지, 어떤 내용을 엮어야할지 몰라 이것도 더디게 더디게 하고 있다. 그래도 조금 더 기계적인 관점으로 컴퓨터를 생각할 수 있게 되었다. 책만 쭉 읽고 정리하는건 능동적이지 못한 공부 방법이라고 해 우선 내용을 넣고, 필요한 부분은 더 찾아보고, 면접질문도 같이 보면서 공부를 하고 있다.

그럼에도 공부를 많이 못해 아쉽다

퇴근하면 체력이 없다는 핑계로 몰입해서 공부를 한지가 꽤 된 것 같다. 그래서 우선 가볍게, 재미있는것부터 하자는 생각으로 저 책을 읽고 있다. 그리고 정리하는 방법을 조금 바꿨는데, 노션을 적극적으로 활용하고 있다. 가볍게 읽은 블로그 글이나 몰라서 찾아본 것들을 노션에 우선 아무렇게나 적고, 미완이면 미완인 상태로 남겨둔다. 부족한 내용은 더 보충하고, 까먹으면 그냥 넘어가기도 하고, 정리를 다한 완성된 글은 블로그에 올리는 식으로 하고 있다. 메모처럼 쉽게 접근할 수 있어 오히려 더 많은 것을 남길 수 있게 되었다. 도구를 바꾸니 공부하는 방식이나 효율이 달라지는게 신기하다.

하지만 역시 몰입이나 밀도가 부족하니까 어딘가 허하고 부족한 기분이다. 이런 기분은 해서 채우는 수 밖에 없지 뭐...

Fact

• 하루 한개 회사 코드 개선하기
  • 순환참조 문제 발견 및 해결
  • 어떤 페이지의 어떤 테이블 칼럼 너비 조절
  • useColumnEdit hook 만들기 (테이블에서 수정할 때 수정/취소 모드를 바꾸는 훅)
  • 정산 spinner 개선 - cache 유지 때문에 스피너를 껐는데 그러니까 버벅거리게 느껴짐. 스피너를 돌릴 isLoading을 다르게 하기
• 알고리즘 문제
  • 뉴스 클러스팅 - 합집합, 교집합은 set으로
• 달달한 재택근무
• 프로젝트 구조 변경type 정의 → api 정의 → container → page에서 조립만
  • 이렇게 하면 불필요한 코드가 없어지고, 복잡도가 줄어듦!
  • 진짜 그런지에 유의할 것
  • function에 //** 로 주석 작성하기 - description, 설명, input, output
• 에 따라 작업 순서가 바뀌게 됨
• graphQL 사용한다!
• 버전관리
  • $ yarn version 하면 git에도 관리가 됨
  • 버전관리 방법 : 2.스프린트.핫픽스

Find

• URL에 #등의 특수문자는 인코딩해주기! - # → %23
• amplify 자동 배포가 안될 때 웹훅추가, reconnect
• typescript static readonly - readonly를 붙인 class 내부 property나 interface 구현체는 값 변경을 못함-
• https://www.tutorialsteacher.com/typescript/typescript-readonly
• react-query refetch는 enabled와 상관없이 동작한다. useEffect에 있는 경우 주의
• 같은 의미에는 같은 단어를 쓰기
• npm과 npx의 차이?npx는 npm 레지스트리에 올라가있는 패키지를 쉽게 설치하고 관리할 수 있도록 도와줌. npm을 통해 설치하는 모든 종류의 Node.js 기반 파일을 간단하게 설치하고 실행할 수 있게 도와줌.npx를 사용하는 경우
  • npm run script를 사용하지 않고 로컬에 설치된 패키지를 사용할 경우
  • 일회성 명령으로 패키지를 실행할 경우
  • gist-based script를 실행할 경우
  • npx란 무엇일까? 그리고 npm이랑 어떤 차이점이 있을까?
• 즉, npm = Package Manager(관리), npx = Pacakage Runner(실행)
• npx는 npm의 npm을 좀 더 편하게 사용하기 위해서 5.2.0 버전부터 새로 추가된 도구!
• useQuery의 결과값으로 useEffect 안에서 setState를 하면 무한루프를 돈다
  • 원인 ? setState ↔ useQuery 호출의 무한반복
  • 해결 ? useEffect array에 date가 아니라 isSuccess를 넣는다
• 상수는 곳곳에서 쓰이는 값을 한번에 바꾸기 위해서 쓰는 것!
• 타입 캐스트를 어디서 할지에 대해
• antd popconfirm에서 form submit을 하고싶을 때?
  • _`okButtonProps_={{ htmlType: 'submit', form: formName }}`

모든 것은 이직으로부터

올 2월 SI 프리랜서로 두 번째 프로젝트를 마치고 이직 준비를 시작했다. 이직을 결심한 이유는 역시 개발자로서의 성장이었다. 프로젝트를 진행하면서 내가 느낀 것은 ‘좋은 코드’를 짜기보다는 돌아가기만 하는 코드를 짜면 된다는 것이었다. 처음에는 내가 개발자라는 것 자체가 너무 좋았는데 점점 내가 그 정체성에 부끄러워지기 시작했다. 성장할 수 있는 많은 방법 중 내가 선택한 방법은 환경을 바꾸는 것이었고, 동료가 있고, 프로덕트의 지속적인 개선이 필요한 환경을 원했기 때문에 이직 준비를 시작했다.

이직을 위해 내가 필요한 것과 부족한 것, 채워야 할 것이 혼자서는 명확하지 않아 항해99 과정을 시작했고, 포트폴리오와 면접을 준비해 지금 우리 회사로 왔다. 지원한 회사중 가장 오고 싶었던 회사였기 때문에, 합격 연락이 오기 전에 다른 최종 합격한 다른 회사에 거절 의사를 전달도 했는데 다행히 곰이 그려진 명함을 받게 되었다.

우리팀은 올초부터 무에서 유를 창조하고 있는 중이었고, 프론트엔드 개발자로 그 과정을 함께하고 있다. GPM으로 시작해 파트너센터 스팩을 변경한 2.0을 오픈했고, 정산검수, 정산내역까지 쉬지않고 개발했다.

회사에서 개발자로 일하기

고미는 내 인생 첫 회사다. 그래서 개발자로서도 회사원으로서도 많은 것을 배우고 있다. 우선 개발자로서 회사의 도메인이나 프로덕트 구조나 구성에 대한 파악을 해야했고, 우리팀의 업무 흐름과 업무 방식(JIRA, 스프린트, slack,...)에 익숙해져야했다. 그리고 회사내의 개발팀으로서 우리가 해야할 일에 대한 고민을 함께 했고, 그 안에서 해야할 일을 찾고, 그것을 전달하고, 소통하는 방법도 배우고 있다.

지금까지는 막연하게 프로그래밍에 대해 많이 아는 사람이 실력 좋은 개발자라고 생각했는데, 지금은 회사에서 당면한 문제를 좋은 코드로 풀어 해결하는 사람이 좋은 개발자라고 생각한다. 일 잘하는 개발자에 대한 나름대로의 정의가 생겼고, lv1부터 한개씩 스테이지를 깨가고 있다고 생각한다.

좋은 동료

그 과정에서 동료들의 도움을 정말정말 많이 받고 있다. 그리고 같이 일하는 게 즐겁다. 같이 프로덕트를 만들어 가는 것도, 문제를 해결하는 것도, 좋은 코드를 위해 의견을 나누는 것도 다 즐겁다! 물음표로 이어지는 대화를 하고 퇴근을 할 때의 들뜸이란. 좋아하는 그들에게 나 역시 신뢰할 수 있고, 즐거운 동료가 되고 싶다. 그러기 위해 지금 부족한건 역시 실력일까..

뭘 공부해야하지?

항상 공부할게 명확했는데 올 4분기에는 길을 잃었다. 내가 뭘 알아야하는지, 어느 정도 알아야하는지를 몰라서 공부 방향을 잡기 위해 사수님에게도 물어보고, 유튜브도 보고, 블로그 글도 보고 했다. 해야할 게 많은데도 뭘 해야할지 모른다면 그건 모든 걸 한 번에 다 해야한다는 부담감때문인 것 같다. 나는 점을 찍는다는 말을 좋아한다. 한 번에 딥 다이브하는 것도 좋지만 그럼 맥락을 놓치기 쉽다. 간단히 훑고 지나가는 것만으로도 뇌에는 점이 찍히고, 그 점을 다른 상황에서 다시 만났을 때 다른 점과 엮이거나 더 잘 이해할 수 있다고 생각한다. 이론과 실전이 항상 상호작용해야한다는 것을 잊지말고, 당장 눈에 보이지 않는 지리멸렬한 시간을 인내심을 갖고 계속 쌓아가야하지 않을까. 우선 공부에 흥미를 붙이는게 우선인것 같아 내년에는 내가 제일 궁금한 걸 제일 보람있는 방식으로 시작할 예정이다. 1년치 목표를 월별, 분기별로 정해놓을까도 했는데, 언제든 바뀔 수 있기 때문에 처음 한 두달치만 정해서 시작!

정산 검수 개발 완료 및 정산 내역 개발

정산 알파는 감마와 델타를 지나 ‘정산 검수’로 기획이 바뀌었고, 드디어 개발을 완료하고 배포를 했다. 파일 업로드와 파일 다운로드 기능을 구현하면서 polling 요청과 blob, 파일 다운로드 로직에 대해 공부도 했다. 그리고 현업 사용자에게 이런 피드백을 받았다. 이후로 계속 개선중이다.

그리고 이어서 정산 내역을 개발했다. 내가 담당한 페이지는 정산 과정상 복잡한 과정이 없어서 비교적 빨리 스프린트를 마칠 수 있었다. 개발하는 속도가 빨라졌다는 걸 느낀다. 개발이 순조롭게 끝나서 배포를 마치고, 현업 피드백을 받아 반영하고 있다.

그 와중에 부끄러운 일이 있었는데 파일 업로드 상태를 받아오는 로직에서 polling을 처리해야 했는데 react-query에 기능을 제공하는데도 불구하고 useEffect를 이용해 처리를 했다. 문서를 보고했는데 폴링 요청이 제대로 안들어가 나름대로는 해결한거였는데 연차와 주말이 지나고 돌아오니 다른 분이 다시 손 본 다음 머지가 되어있었다. 일을 두 번하게 하는 팀원이라니 ㅠㅠ 시간에 맞추기 위해 우선 하고 넘기자는 생각이었는데, 시간이 조금 더 들더라도 제대로 처리해야겠다고 다짐했다.

그리고 QA 과정에서 꼼꼼하지 못했던 것도 반성... 꺼진 커밋도 다시보자.

회사일을 잘하는 건 어떤건가요? 지금 저에게 부족한건 어떤건가요?

라고 사수님께 여쭤봤다. 코딩 실력도 회사 일을 처리하는 능력도 늘지 않는 것 같아서 계속 고민을 했기 때문이다. 사수님의 답변은 회사 프로덕트에 관심을 갖고 끊임없이 개선을 해야한다. 개선점을 알아보려면 결국 input이 많아야한다. 자바스크립트 코어를 잡고 가려는 지금의 공부방향도 좋지만, 그것과는 별개로 변두리의 것들도 챙겼으면 좋겠다고 하셨다. 그리고 문제 해결 능력이 조금 아쉽다고 했다. 우선 돌아가는 것도 중요하지만 Best practice가 뭔지 많이 찾아보고 적용해봤으면 좋겠다고 하셨다.

스스로를 돌아보니 나는 회사에서 일정이 널널할 때는 회사 프로젝트를 보기보다는 리액트나 CS의 이론들을 찾아본다. 코어도 중요하지만 당장 코드에 적용할 수 있는 무언가는 아닐 수도 있다. 진짜 문제는 회사 태도를 대하는 자세라고 생각했다. 그래서 하루에 한개씩 개발이외에 수정사항 찾기를 하기로했다.

그래서 하루 한개 회사 코드 개선하기

면담 이후 하루 한개씩 회사 코드를 수정하기로 하고 실천했다. 변수 이름 변경, 예외 케이스 찾아서 처리하기, 코드에서 중복되는 부분을 없애기 위해 컴포넌트를 수정하거나, hook 만들어서 처리하기, strict mode에서 warning 나던 코드 개선하기, 스택 변경하고 나서 손길이 닿지 않은 부분 코드 수정하기 등등을 했다.

물론 할당량을 못 채운 날도 있었지만 회사 프로덕트를 대하는 자세가 달라졌다. 개발이 완료된 소스를 안중에 없었는데(

반성

) 프로젝트 전체를 과거가 아닌 현재로 인식을 하게 되었고, 이게 정말 최선일까? 더 좋은 방법이 없을까를 계속 고민하고 찾고 있다. 그리고 실질적으로 적용하고 개선할 수 있는 것들을 공부하니 공부에 좀 더 재미가 붙었다. 지금까지 했던 공부들은 물론 다 필요한 것이지만 눈에 보이는 결과물이 없어 재미도 없고, 보람도 없었기 때문이다. 눈을 크게 뜨고 프로젝트를 대하니 전보다 더 애정도 생긴다. 이 태도가 사실은 당연한 건데 이제라도 배운 것을 다행으로 생각하고 앞으로도 계속 유지할 것이다.

• 하루 한개 회사 코드 개선하기
  • settlement_index 없을 때 검증관련 버튼들 비활성화
  • 컴포넌트 내부에 있던 object 컴포넌트 밖으로 뺌 - 컴포넌트가 렌더링 될때마다 불필요한 객체 생성을 피하기위해
  • 업로드 취소 기능이 추가됐을 때, api에 반영되지 않은 예외케이스를 찾아서 추가했다
  • Layout의 Header 컴포넌트 extra 부분에 여러 컴포넌트가 들어갈 경우 간격 유지를 Row, Col 컴포넌트로 일일이 해줘야하는 것을 Header 내부에 Space 컴포넌트와 간격을 추가했다. → 모든 컴포넌트에서 헤더 내부 버튼 간격이 동일해지고, 레이아웃을 사용하는 곳에서 Row,Col을 줄필요가 없음
  • useTableData → useFetchPayload로 변경, keyword포함
  • React has detected a change in the order of Hooks called by VerificationTable. This will lead to bugs and errors if not fixed. For more information, read the Rules of Hooks: 에러 해결
    • 원인 : 조건문 안에서 hook을 쓰고 있었음. isLoading?:<Table column={tableCoumn(내부에서 useTranslation훅)}>
  • i18next로 변경하면서 관련 파일 수정
  • GPM table key 에러 수정
  • 권한 라우터 수정

조직 개편과 개발실 이사, 그리고 삶의 질 개선

회사가 시리즈B 투자를 받으면서 본격적으로 성장할 준비를 하고있다. C Level 임원진을 구성하고, 지금 업무를 좀 더 체계적으로 하기 위해 조직 개편도 했다. 채용도 더 많이 늘릴 예정이라고 한다. 개발실은 당장 개편의 영향을 받은 것은 아니라서 하는 일에서 달라진건 없다. 다만 사수팀이 팀장님!이 되셨고, 우리 파트너센터의 R&R을 선명하게 하고, 회사 안에서 해야할 일을 적극적으로 찾고 있다. 회사 입사할 때 해야할 일이 많아 보였고, 회사의 가능성이 너무 좋았는데 기대했던대로 회사가 성장하고 있다. 시스템을 잡아가는 과정, 조직이 성장하는 과정에서 많이 배우고, 그 안에서 내가 해야할 일도 적극적으로 찾아서 해야지.

인원이 늘어나면서 사무실이 좁아져 내년 초 이사전까지 개발실은 위워크로 이사를 했다. 회사 여기저기서 들리던 웃음소리가 사라져 적막한데 차분한 분위기나 시설은 좋다. 강남역으로 이사한 덕에 출퇴근 시간이 십분정도 줄었는데 아침저녁으로 큰 차이다. 퇴근 후에 조금 더 여유가 생겼다. 계속 여기 있으면 좋겠는데 과연...

Udemy에서 진행한 '프론트엔드 개발자 성장 가이드(장현석, 임동준)' 영상을 보고 정리한 글입니다.

📄 내용 정리

프론트엔드 개발자란?

• HTML은 WEB으로 연결된 문서로 브라우저 위에서 동작하는 문서이며, 다양한 기기 위에서 동작한다.
• FE 개발 범위 : Backend For Fronted, 백오피스, 대시보드, 차트, UI 개발, 퍼블리셔, 코어, 모듈, 라이브러리, 디자인 시스템, 모바일
• 필수 역량 : 1. HTML 2.javascript 3.CSS 4.브라우저 5.네트워크

학습의 주도권 가져오기

• 오늘은 JavaScript 호이스팅에 대해서 공부해야지 vs 오늘은 땡땡 자바스크립트 책 1페이지부터 400페이지까지 읽어야지
• 책이나 강의를 끝내는 것을 목적으로 공부하는 것은 학습의 주도권을 뺏긴 것이다
• 책이나 강의 : 블로그 글을 쭈루룩.. → 남이 공부한 것을 따라치고, 나열한 것이 진짜 공부인가?
• 내가 무엇을 공부해야 할지 모르는 상태 ㅠ
• 채용공고, 책 목차, 강의 목차 등 키워드 단위로 공부하기!
  • 추천하는 방법 온갖 책의 목차를 긁어보기 → 나만의 학습목차를 만들기 → 각 책에서 그 부분들을 읽고 정리하기

Input vs Output의 혼합

• 오늘은 Debounce, Throttle에 대해서 공부해야지 vs JavaScript를 이용해서 무한 스크롤을 만들어야지! 거기서 Debounce, throttle을 이용해봐야지.
• 클론코딩은 서비스, 디자인을 클론하는거지 코드를 클론하는 것이 아님
• Input + Output + Feedback

자기 객관화

• 함께 자라기 : 스터디, 해커톤, 학습 내역 체계화해서 정리하기
• 회사 지원하기
  • Top → Down
  • Botton → Up
  • 내가 공부할 키워드!

피드백 주도 성장

• 내 경험치와 점수를 어디서 얻지?
• 더 자주, 더 빨리, 더 꾸준히 받을 수 있는 피드백!!
• 테스트코드, 코드리뷰, 짝 프로그래밍, 커뮤니티 참여
• 문제 바깥에 있는 사람을 맥락을 파악해 문제를 빨리 해결할 수 있다
• 써먹을 수 있는 환경에서 공부해야

Q&A

• 좋은 개발자란? 문제를 정의하고, 문제를 해결하고, 해결을 공유
• 어떻게와 왜를 방황도 하면서 직접 찾아보기
• 업무와 연결되어 있는 공부를 하면 업무와 공부 실력이 함께 늘어갈거예요
• 작은 문제를 얼마나 탁월하게 해결하려 했는지가 중요

👩🏻‍🔧 어떻게 나에게 녹일까?

강의를 듣고 현재 학습 방식의 문제를 파악해봤다.

• 완강, 완독 목적의 공부
• 피드백이 부족
• input의 부족

지금 채우고 싶은 부분은 CS와 JavasScript에 대한 깊은 이해, 그리고 당장 회사일을 잘하고 싶다는 것이다. 사실 계속 방황하는 지점은 이 지점인데, 내가 채우고 싶은 부분과 회사 일의 접점이 지금 당장 눈에 보이지 않는다. 그래도 우선은 input을 늘리고 접점이 생길 때까지 해나갈 수 밖에 없다고 생각한다. 다만 일을 할 때 만난 문제를 탁월하게 해결하는 습관을 꾸준히 길러야겠다고 생각했다.

공부 방법에도 변화를 주려고 한다. 지금까지는 책을 처음부터 끝까지 읽거나, 강의를 끝까지 보는 형식이었는데 꾸역꾸역 해왔다. 하지만 남는게 끝냈을 때의 약간의 성취감뿐이라는 것을 인정해야겠다. 가고 싶은 회사의 채용공고와 면접 문제들을 자주 보면서 가장 궁금한 키워드들 위주로 공부를 하려한다. 목차가 흥미로운 책을 발견했는데, 한 번에 여러 주제가 아닌 하나의 주제로 다양한 자료들을 보면서 공부하고, 내용을 옮겨적는 포스팅이 아닌 공부한 것을 다시 정리하는 포스팅을 하려한다.

그래도 나는 피드백을 받기 좋은 환경에 있는데, 사수님에게 한달에 한번 면담을 하면서 조언을 구하거나 일에 대한 피드백을 받고 있고, 코드리뷰도 하고 있다. 내년에는 내가 해온 공부의 결과와 방향성에 대한 피드백을 주기적으로 인프런 멘토링을 통해 받으려고 한다. 그러려면 해온 결과물이 있어야하기 때문에 그 자체로도 동기부여가 될것이라고 생각한다.

그래서 지금 머리속의 계획을 정리하자면

1. ‘한 권으로 읽는 컴퓨터 구조와 프로그래밍’ 목차별로 공부하기
2. 일할 때 만난 문제를 탁월하게 해결하는 습관 기르기
3. 사수님에게 피드백 적극적으로 요청하기
4. 한달에 한번 멘토링 받기 - 멘토링을 위한 준비 열심히 하기

• URL에 #등의 특수문자는 인코딩해주기! - # → %23
• amplify 자동 배포가 안될 때 웹훅추가, reconnect
• typescript static readonly - readonly를 붙인 class 내부 property나 interface 구현체는 값 변경을 못함
• https://www.tutorialsteacher.com/typescript/typescript-readonly
• react-query refetch는 enabled와 상관없이 동작한다. useEffect에 있는 경우 주의
• 같은 의미에는 같은 단어를 쓰기
• npm과 npx의 차이?npx는 npm 레지스트리에 올라가있는 패키지를 쉽게 설치하고 관리할 수 있도록 도와줌. npm을 통해 설치하는 모든 종류의 Node.js 기반 파일을 간단하게 설치하고 실행할 수 있게 도와줌.npx를 사용하는 경우
  • npm run script를 사용하지 않고 로컬에 설치된 패키지를 사용할 경우
  • 일회성 명령으로 패키지를 실행할 경우
  • gist-based script를 실행할 경우
  npx란 무엇일까? 그리고 npm이랑 어떤 차이점이 있을까?
• 즉, npm = Package Manager(관리), npx = Pacakage Runner(실행)
• npx는 npm의 npm을 좀 더 편하게 사용하기 위해서 5.2.0 버전부터 새로 추가된 도구!
• useQuery의 결과값으로 useEffect 안에서 setState를 하면 무한루프를 돈다
  • 원인 ? setState ↔  useQuery 호출의 무한반복
  • 해결 ? useEffect array에 date가 아니라 isSuccess를 넣는다
• 상수는 곳곳에서 쓰이는 값을 한번에 바꾸기 위해서 쓰는 것!
• 타입 캐스트를 어디서 할지에 대해
• antd popconfirm에서 form submit을 하고싶을 때?
  • *okButtonProps*={{ htmlType: 'submit', form: formName }}

벌써 1년 6개월정도 경력의 2년차 개발자다. 두둥. 1년은 SI 개발을 했고, 지금은 스타트업에서 프론트엔트 개발자로 일하고 있다. 29살에 경력을 시작해, 첫 5개월은 개발을 한다는 자체가 기뻤다. 학원 출신이라 CS에 대한 갈증이 있었기 때문에 강의와 책을 통해 CS 공부를 조금씩했다. 그 때까지도 지금 개발 세계에서 펼쳐지고 있는 일들을 거의 몰랐다. 첫 프로젝트는 나름 만족스러웠다. SI는 악명이 높다지만 나는 운이 좋았는지 적당한 업무 강도, 적당한 환경이었기 때문이다.

그 다음으로 알만한 IT 회사의 외주 프로젝트를 했다. 그 때 엄청난 자극을 받았다. 나는 들어본적도 없는 들어본 도커나 AWS를 쓰고, 좋은 코드를 짜기 위해 노력하고, 스프린트를 진행하고, 회사 사옥도 좋았다. 지나다니는 사람들도 다 개발자고, 누군가의 책상 위에 GoLang 책이 놓여있었다. 내가 얼마나 뒤처져있는지 알았고, 내가 원하던 개발자는 이런거였구나 싶었다. 그래서 '프론트엔드 개발자로 회사에 취직하기'를 목표로 했다. 그 때부터 깃헙을 관리하고, 포트폴리오를 만들고, 프론트엔드 관련된 강의를 들으며 준비했고 다행히 지금 회사에 취직을 하게 되었다.

처음 3달동안은 팍팍 성장하는게 느껴졌다. 좋은 개발문화를 만들기 위해 노력하고, 코드리뷰도 받고, 회사 도메인에 대해 이해도 하고, 프로젝트 구조에 대해 고민하고, 어떤 기술 스택을 쓸지 공부하고... 그러면서 취업준비+재택근무 오래하다가 오랜만에 출근+통근 왕복 3시간+회사적응등등의 이유로 착실히 쌓인 피로가 터지면서 퍼져버렸다. 공부를 하지 않으면 불안한 마음이 늘 있었는데 그럴 마음 조차들지 않을만큼 피곤에 절어서 퇴근하면 자기 바빴고, 성장이라는 단어에 신물이 났다. 그렇게 일만하면서 회복하기를 또 한 두달.

그리고 지금이다. 퇴근하고 컴퓨터 앞에 앉을만큼 체력과 정신력이 생겼고, 성장하고 싶다는 욕구가 퐁퐁 솟아오르는데 이제 어떻게 해야할지 모르겠다.
지금 모르는 것을 나열해보면

• 성장이 뭐지
• 어떻게 해야하지
• 나는 지금 회사에서 일을 잘하고 있나
• 일을 잘한다는건 뭐지
• 일을 잘하려면 뭘해야하나
• 곧 3년차가 되는데 이대로 괜찮나
• 약속의 3년에 쓸만한 개발자는 뭘 어떻게 해야하지
• 연봉협상을 위해서 어필할게 지금 있나
• 이직을 한다고 했을 때 과연 가능한 수준인가
  ....이다.

뭐이렇게 모르는게 많아?

다시 정리해보면 나의 핵심 욕구는 성장하고 싶다와 일을 잘하고 싶다.
그런데 개발자로 성장하는 것과 일을 잘하는 것이 어떤 건지 모르겠다.
그래서 어떻게할지 모르겠다.

자바스크립트 강의를 쭉 들었고, 또 강의를 끊어는 놨는데 이게 맞나 싶어서 집중을 못하고 있다. 그래서 우선을 방향과 목표를 구체적으로 정하는게 좋을 것 같아 개발자 성장에 대한 글이나 영상을 보고 정리하려고 시작한 글이었는데...이렇게 글이 길어졌네.

덕분에 생각을 정리했으니 이제 몸을 움직일 차례다. 무브무브.

Fact

정산 시스템 - 델타

지난 달부터 하고 있는 정산 시스템이 베타를 지나 감마를 지나..델타 버전을 하고 있다. 이번달 중순까지 감마 버전 작업을 하고 있었는데 중간에 기획이 아예 바뀌었다.

기획이 바뀐 가장 큰 원인은 베트남측의 작업 플로우를 제대로 이해하지 못했기 때문이다. MISA라는 시스템을 어떻게 사용하고, 어떤 범위까지 업무에 활용하는지를 파악을 못하고, Misa를 배제하는 방향으로 개발을 하고 있었는데 Misa를 배제할 수 없는 상황에 Misa까지 우리 시스템에 녹이기에는 볼륨이 너무 커져서 한국의 정산 담당자의 플로우를 자동화하는 방향으로 기획을 수정하게 됐다.

새 기획에서는

• 파일 업로드 기능
• 파일 export 기능
• 업로드한 데이터 확인
• 데이터 확정 기능 을 구현했다.

그리고 정산 시스템을 개발하는 내내 도메인 이해를 하기 위해 노력을 많이 했다. 백엔드가 구현하는 비즈니스 로직이라도 전체 플로우를 이해하려고 했고, 회의하는 과정에서 질문도 많이 하고 의견도 많이 냈다.

백엔드와 프론트엔드 어떻게 개발하는지 서로 보기

스프린트 액션 아이템이었다. 프론트로 넘어오는 데이터가 어떤 과정을 통해서 넘어오고, 백엔드에서 보낸 데이터를 프론트에서 어떤 식으로 사용하는지를 이해하자는 취지였다.

현재 벡엔드는 nestJs라는 프레임워크를 사용하는데 타입스크립트를 기본으로 제공하고, express와 달리 아키텍처의 정의를 프레임워크가 제공하기 때문에 프로젝트의 구조나 코드가 비슷하다고 한다.

인상적이었던 부분은 세세한 구현은 implement layer에서 처리하고 service layer에서는 로직이 처리되는 흐름이 한 눈에 보이게끔 구현을 한 부분이었다.

Auth 리팩토링

처음에는 공통상태관리라이브러리를 사용하지 않다가 zustand를 쓰다가 unstatedNext를 도입하면서 auth 부분이 zustand 로직으로 구현되어 있었다. 그 부분을 unstatedNext로 리팩토링을 하면서 토큰 리프레쉬나 권한처리 부분을 같이 리팩토링했다.

자바스크립트 공부와 알고리즘 문제풀이

프로그래머스 lv1 문제를 끝내고 lv2 단계 문제를 일주일에 2~3개 정도 javascript로 풀고있다.

바닐라 자바스크립트로 간단한 게임을 만들었다. 구현을 끝내고 브라우저 101 강의를 들으며 강의를 보며 리팩토링을 했다. class와 contruct, 생성자를 사용해 리팩토링을 했고, this 바인딩과 컨텍스트에 대해 다시 공부했다.

실전 리액트 프로그래밍 속독 중

하루에 50 바닥씩 읽고 있다. 한번 훑고 정독하며 읽을 예정이다. 리액트 작동원리에 대해서 조금씩 배우고 있다.

Finding

• 컴포넌트에 대한 논의 -> container를 어느 레벨에서 부를 것인가? depth는? 데이터 전달은?
  1. Page level에서 container를 호출하고 모든 하위 컴포넌트에 props로 전달하는 방법.

      - 왜? 데이터를 한 방향으로 내려줘 단방향 흐름을 유지한다
      - 좋지 못함. 왜? 컴포넌트 레벨에서 컨테이너를 호출해도 단방향 흐름을 깨는건 아님, 데이터 수정이 있을 때마다 수정작업이 많아짐. 

  2. Page level에서 container를 호출하고, depth를 최대 2depth로 유지한다.

      - 왜? 수정과 관리가 편함
      - 좋지 못함. jsx파일이 너무 커져 찾기가 힘들어짐 -- JSX파일이 길어지는건 구조적으로 문제는 없지만, 가독성이 떨어짐

  3. 컴포넌트 랩핑은 최소한으로 하되 각 컴포넌트 레벨에서 container를 호출

      - 연관성이 높은 컴포넌트끼리 래핑해 가독성을 높이고, 컴포넌트 수정도 최소한으로 할 수 있다

• 컴포넌트, 다시 생각하기
• 웹팩 순환참조 에러
• this 바인딩
• 실행 컨텍스트
• 파일업로드
• react-query를 편하게 쓸 수 있는 훅을 만들었다.
• SPA가 가능한건 브라우저의 히스토리 API 때문!
• literal 대신 enum 사용

Feeling

this 바인딩을 이론은 많이 들어봤는데 게임을 만들면서 처음 해당 에러를 만났다. 역시 글로만 공부하는 것보다 직접 부딪히면서 배우는게 기억에 오래 남는다. 봐도봐도 막연했던 this와 실행 컨텍스트를 다시 공부하면서 좀 더 이해할 수 있었다.

좋은 코드를 짜는게 뭘까 고민을 하는데 팀원분을 따라해보기로 했다. 중복되는 로직이나 너무 긴 로직은 hook을 만들어 사용하시는데 재사용을 하지 않는 hook을 만들 필요가 있나 싶긴하지만 반복작업을 hook으로 처리하는 것을 실천하기로 했다.

가정 환경이 변화면서 일찍 퇴근하기 위해 일찍 출근을 한다. 아침 루틴이었던 강아지 산책이 저녁 루틴으로 들어갔다. 그덕에 일주일에 네세번은 하루에 3km 이상씩 걷고 있다. 발목을 다쳐서 달리기를 못하니까 걷기라도 열심히..컨디션과 체력에 도움이 되길 바라며!

12월에도 자바스크립트 공부를 계속 할 예정이다. 유데미에서 자바스크립트 강의를 사뒀다. 12월도 화이팅

정산, 이것이 애자일이다

10월의 메인은 정산이었다. 베타 버전을 최대한 빨리 만들어서 실 사용자의 피드백을 반영해 수정하기로 하고 개발을 진행했다. 상세한 기획과 정확한 요구사항을 정의하기 어려운 상황이었기 때문이었는데, 가장 큰 이유는 실제 사용자인 베트남 정산 담당자가 정산 시스템 개발 의도와 시스템 자체에 대해서 이해가 조금 부족했기 때문이었다. 담당자 입장에서는 지금까지 해 오던 방식이 있는데 아직 있지도 않은 시스템을 들이밀며 일하는 방식을 바꾸라고 강요당하는 식이었기 때문에 우선 핵심 기능을 빠르게 만들어 사용하게 하며 요구 사항을 반영하자는 의도였다.

베타 버전의 목표는 휴먼 에러를 최소한으로 줄이기 위해 데이터를 직접 입력하던 부분을 API로 땡겨와 수정을 할 수 있게끔하고, 정산 처리 과정을 담당자들이 따로 연락하지 않아도 시스템상에서 바로 확인해 처리할 수 있게하는 것이었다. 그걸 목표로 2주 일정으로 조금 타이트하게 개발을 진행했다. 타이트한 일정과 베타버전의 개발 범위를 잘 못 알아 나에게 베타버전의 일감 대부분이 몰리고, 다른 팀원들이 개발한건 사용하지도 못한 일이 있었다.

아무튼 베타 버전에 대한 피드백을 받았는데 시스템에 대한 사용상의 피드백이 아닌, 전달한 문서에 엑셀 업로드 기능이 필요하다고 했는데 그 기능이 없어서 사용할 수 없다는 뉘앙스의 피드백이 돌아왔다. 우리 입장에서는 개발한게 사용조차 하지 않았다는 것에 답답함을 느꼈고, 베트남 측에서는 피드백을 보냈는데 전혀 반영이 되지 않아 답답함을 느낀 것 같다. 격앙된 분위기에서 회의가 끝났고 베트남측 요구사항을 다시 반영해 감마버전을 개발하기로 했다.

이 과정에서 느낀 것은 역시 소통의 중요성...상대방의 의도를 정확히 파악해야 하고, 내 의도도 정확히 전달해야 한다. 그리고 그 과정에서 당연히 워딩과 뉘앙스를 신경써야 한다. 시스템, API, 데이터 같은 개발 용어 대신 이해하기 쉬운 단어를 써서 전달할 필요도 있다. 감마 버전이 그들에게 유용한 시스템이 되고, 그걸 전달하는 과정 역시 이번보다는 더 매끄러웠으면 좋겠다.

베타에 있던 많은 기능이 없어지고, 새로운 기능이 추가되어서 고생했던 시간이 좀 허무하기도 했는데, 팀원이 이게 바로 애자일이라는 이야기를 해주었다. 우리는 일주일 주기로 스프린트를 진행하고 매일 데일리 스크럼을 하는데, 애자일의 핵심은 프로토 타입을 빠르게 만들고 빠르게 바꿔가는 것이라고 했다. 그렇구나..! 앞으로도 프로토 타입이 두 세번 정도 크게 바뀔 수 있겠지만 원래 그것을 목적으로 한다는 걸 염두에 두고 개발해야겠다. 그리고 애자일 방법론에 대한 공부로 따로 필요할 것 같다.

도메인에 대한 이해와 회사 내에서의 정체성

지금까지 개발자는 개발을 하는 사람이라고 생각했지, 뭘 개발하는 사람이라는 정의가 없었다. 이번 정산 시스템을 만들고, 최근 우리 팀의 정체성과 로드맵에 대해 고민을 회의를 자주 하면서 그 부분에 대해 많은 생각을 하게 됐다.

회사에서 개발을 하는 이유는 결국 회사에 이익을 가져다주기 위해서다. 기존 시스템의 불편함을 개선해 내부 직원들의 업무 효율을 높이거나, 제공하는 데이터의 정확성과 다양성을 높이고, 비즈니스적으로 더 발전할 수 있는 것을 찾고 개발하는 것이라는 것이라는 생각을 하게됐다.

우리 회사에서처럼 막 확장을 시작한 회사에서는 시스템에 대한 개선 사항이 많다. 그러기 위해서는 회사의 도메인과 다른 팀들이 하는 일에 대해서도 파악해야 한다. 그리고 파트너사에게 제공할 수 있는 것에 대해서도 고민을 해야한다.

그러기 위해서 당장 내가 할 수 있는 일은 우선 주간 회의 때 공유하는 다른 팀의 업무 진행 상황에 대해 더 관심을 가지고, 개발 이외에 비즈니스나 마케팅, 광고 등에 관련된 책도 읽는 것이다.

회복

길었던 두달이었다. 아무것도 할 수 없었던 9월을 지나 10월에는 컨디션을 슬슬 회복했고, 다시 공부를 시작했다. 목표와 로드맵에 대해 고민하고 뭘 공부할지에 대해서도 어느 정도는 정했다. 우선은 스스로 간지러운 부분들을 긁어가고, 구글링 한것들 중에 골라서 깊에 파보기로 했다.

우선은 javascript로 게임을 만들고 있다.

• 할 시간을 만들기 위해 출근을 더 빨리해 퇴근 시간을 앞당겼다.
• 하는 이유는 자바스크립트의 기능과 동작원리를 더 잘 알고 싶어서, 그리고 어떤 회사들 과제 테스트로 나오는 문제들이니까 못하면 안된다고 생각해서다.
• 결과물은 게임프로젝트가 하나 나오고, 자바스크립트에 아는 것이 더 생길 것이다.
• 방법으로 우선 browser101의 과제 게임을 만들고, 게임을 만든 후에 코어 자바스크립트 강의를 들어 사용했던 개념을 다시 정립할 것이다.

두 달 동안 개발 공부는 안했다고 생각했는데, 일하는 방법과 회사 내에서의 정체성 등을 개발 외적인 부분에 대해 많이 배운 것 같다. 조급해하지말고 천천히 꾸준히 나아가야지.

MIL

• Henrry의 불편한 코드가 있으면 바로 개선하려고 하는 자세
• Intl
• 다국어처리
• Presentation-view 패턴
• unstated-next 상태 관리 라이브러리
• 권한별 로그인, 라우터 처리
• 파일 업로드