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을 선명하게 하고, 회사 안에서 해야할 일을 적극적으로 찾고 있다. 회사 입사할 때 해야할 일이 많아 보였고, 회사의 가능성이 너무 좋았는데 기대했던대로 회사가 성장하고 있다. 시스템을 잡아가는 과정, 조직이 성장하는 과정에서 많이 배우고, 그 안에서 내가 해야할 일도 적극적으로 찾아서 해야지.

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

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 상태 관리 라이브러리
• 권한별 로그인, 라우터 처리
• 파일 업로드

레거시 코드 이사하기

지금 운영하고 있는 서비스를 새로 만든 admin 프로젝트에 합치는 작업을 했다.

• redux + redux-saga 사용하고 있는 코드에서 redux를 걷어내고 react-query를 사용해 api 호출을 하고, 상태관리 라이브러리는 zustand라는 것을 도입했다.
• react-bootstrap을 사용하던 UI를 antd로 바꿨다.
• 권한이 추가되어 권한에 따라 다른 로그인 화면을 보여주고 메뉴, 라우터에도 권한을 적용했다.

로그인을 했는데 페이지가 안보이네요?

로그인을 하고 랜딩페이지에 들어갔는데 하얀 화면이 뜨고 아무것도 안 나오는 버그가 있었다.

라우터에 해당 url이 없을 때 나오는 화면이었다. 라우터를 권한 별로 처리를 했는데 왜 화면이 안나오지?

기존 코드에서는 로그인했을 때 토큰을 lcoalStorage에 저장하고, 토큰 정보를 디코딩해 Role을 얻어 낸 다음, role을 키로 routerList 객체를 불러온다.

원인을 찾아보니 로그인하기 전 라우터가 role이 없는 상태로 셋팅이 되는데, 로그인을 해도 리렌더링이 일어나지 않아 계속 role이 없는 상태의 라우터만 있기때문이었다.

문제를 해결하려면 로그인 후에 리렌더링을 일으키는 액션이 필요했다. toggle state를 만들어서 로그인을 할 때마다 상태를 바꿀까, 정보를 가져오는 api를 호출할까 등의 방법을 고민하다가 결국 zustand라는 상태관리 라이브러리를 도입하기로 했다.

앞으로 더 다양한 도메인이 추가되고, 권한처리도 복잡해질텐데 상태관리 라이브러리를 쓰는게 편할 것 같다는 판단과 컴포넌트를 잘게 쪼개다보니 3단계 이상 데이터를 드릴링하는 경우도 많고, 새로고침할 때 사용자 정보를 가지고오는 api를 호출하는 로직이 거의 모든 페이지에 들어있어, 너무 자주 호출을 하는 문제가 있었기 때문이다.

zustand를 선택한 이유는 redux 보다 코드량이 현저히! 짧기 때문이었다. zustand를 적용하니 위의 버그는 당연히 사라졌고, 사용자 정보를 관리하니 라우터나 메뉴, 헤더의 처리가 훨씬 간편해졌다.

리팩토링 2판 스터디 마무리

2달정도 했던 리팩토링 2판 읽기 스터디를 마무리했다.

스터디 진행방법은 시간을 정해 각자 읽고 싶은 부분을 읽고, 정리하고, 다른 사람들에게 간단히 설명하는 방식이었다.

이 책을 선정한 이유는 매일 하는 코드리뷰와 리팩토링을 더 잘하기 위해, 안 좋은 코드의 예는 구체적으로 어떤 것이 있는지를 알고 싶어서였고, 책 내용을 바로 적용해볼 수 있을거라는 기대 때문이었다.

우선 진행방식에 대해 이야기하자면 개인적으로는 집중해서 읽고, 다른 사람에게 설명하기 위해 내용을 정리하면서 읽고, 설명하면서 또 내용을 한 번 더 정리할 수 있어서 효과적이었다. 다른 사람들의 설명을 듣는 것은 내용을 이해한다기보다 이런 내용이 있구나~하고 옅게 점을 찍고, 나와 같은 부분을 읽었을 때 다른 부분을 인식하는데에 더 의미가 있었던 것 같다.

책을 읽고나서 Pull reqeust 하기 전에 한 번 더 코드를 읽어보고 리팩토링을 하려고 신경쓰고 있고, 목적과 기능이 잘 드러나는 이름을 짓기 위해 노력하고 있다. 그리고 여러 기능이 섞여있는 함수는 각각 기능을 분리하려고 하고 있다.

다음 이 책을 펼 때는 조금 더 많은 부분이 보여서, 더 많이 익힐 수 있으면 좋겠다.

조금 긴 휴식

9월은 체력도 의욕도 없어서 따로 시간내서 공부를 하지 않았다. 일주일에 한 개씩 개발 글쓰기로 정했는데 한달동안 한 개 썼다. 하하하하하 그럴 수 있지.

그동안 푹 쉬고, 아무것도 안 하면서 지겨움도 느끼고, 약도 챙겨먹으면서 체력도 보강했더니 10월 중순인 지금은 다시 의욕도 생기고, 퇴근하고 남은 에너지도 있다. 9월의 휴식 덕분에 또 앞으로 나아갈 힘이 솟아나고 있다.

지금까지는 성장이라는 단어에 신물이 나는... 뭘하고 싶은지 모르는... 뭐가 필요한지도 모르는... 어디서부터 손을 대야할지 모르는... 혹은 알고싶지 않은..? 그런 상태였다. 하지만 아무것도 안 하는 게 슬슬 지겹고, 무능력하고 못하는 건 또 싫으니까 또 무언가를 해가겠지.

GPM Admin 프로젝트

GPM은 pixel이라는 페이스북의 분석툴을 입력하고 관리하는 백오피스다. 레거시 없이 새로 빌드해 7월 중순부터 지금까지 약 6주정도 개발을 했다.

폴더 구조에 대한 고민

POC 기간부터 폴더 구조에 대한 고민이 많았다. 나는 아토믹 디자인 패턴에서 발전시켜 나가려고 했는데 한계가 있었고, 회사에 있던 기존 구조를 따라서 작업을 하다 아래의 구조로 정착하게 되었다.

공통으로 사용하는 로직은 최상단에서 관리하고, features라는 하위 폴더 안에 각 도메인에 관련된 로직을 작성하는 방식이다. 이렇게하면 도메인이나 기능이 추가될 때 확장하기 쉽고, 도메인간 결합도가 낮아져 유지 보수가 쉬울거라고 판단했다. 이렇게 작업을 해보니 더 직관적이었고, 리팩토링이나 추가 기능을 구현할 때도메인은 전혀 상관하지 않고 해당 폴더 내부에서만 작업할 수 있었다. 꽤 마음에 드는 구조라 회사 프로젝트나 개인프로젝트나 당분간은 이 구조로 작업할 것 같다.

https://github.com/alan2207/bulletproof-react?fbclid=IwAR0Q3gck2B9CZyPaU5bEsA96NADfd0AA1t79uc_ZvN1C80JuAAN1w3ScvsQ

├── assets
├── components
│   ├── Elements
│   ├── Form
│   └── Head
│   └── Layout
├── features
│   ├── auth
│   │   ├── api
│   │   ├── components
│   │   ├── routes
│   │   ├── types
│   │   ├── hooks
│   │   └── index.ts
│   ├── comments
│   ├── teams
│   └── user
├── hooks
│   └── useHooook.ts
├── lib
│   ├── auth.tsx
│   ├── axios.ts
│   ├── react-query.ts
├── store
├── types
└── utils
    ├── format.ts
    ├── lazyImport.ts
    └──  storage.ts

react query 도입

api 요청은 일반적으로 redux middleware를 이용했는데 이번에 react-query를 도입했다.
사용해보니

• 미들웨어를 사용했을 때 보다 로직이 많이 줄어든다
• loading, error 등의 상태 처리가 용이하다
• redux를 쓰지 않고도 서버에서 받아온 데이터를 여러 컴포넌트에서 사용할 수 있다
  단점은
• click이벤트 등을 이용해 refetch를 할 때 useEffect를 이용해야 한다

자세한 사용기는 따로 포스팅을 할 예정이다!

redux 안 쓰기

api 호출을 제외하고 공통 상태 관리를 할 필요 없을 것 같아 이번 프로젝트에서 리덕스를 안 쓰기로 했다. redux로 주로 처리하던 로그인에서 애를 많이 먹었는데 어찌어찌 처리를 했다.(어찌를 다시 확인하기)

내가 작업한 컴포넌트에서 다른 도메인으로 분리해놓은 두 가지를 한 모달에서 사용하는 케이스가 있어서 최상위 컴포넌트에 서로 공유하는 데이터를 넣어두고 props로 전달하며 구현을 했는데 context 사용했으면 어땠을까요라는 피드백을 뒤늦게 받았다. 상태관리 라이브러리를 무조건 쓰면 안된다는 컨셉이라고 생각을 했기 때문에 리덕스의 필요성만 간절히 느끼며 작업을 했는데....그런게 아니었다....context는 생각도 못했다. 리덕스를 사용하지 않았지만, 사용하지 않았기 때문에 오히려 리덕스와 상태관리, context 등등에 대한 전반적인 이해가 부족하다고 느꼈다. 요즘 왜 리덕스가 미움을 받는지, 다른 새로운 상태 관리 라이브러리는 무엇이 있는지, 왜 나왔는지에 대해 공부할 예정이다.

JIRA

JIRA를 이용한 스프린트 애자일 방식으로 프로젝트를 진행했다. 프로젝트를 하며 스스로 가장 발전한 부분이 이 부분이라고 생각한다. 집중이라는 스프린트의 컨셉을 이해하고, 잘 실행했다고 생각한다. 티켓을 잘게 쪼개서 작업하니 내가 해야할 것, 하고 있는 것을 직관적으로 파악하고, 그것에 집중할 수 있었다. 작업하는 중에 다른 수정 사항이 보이면, 바로바로 처리하고 싶은 욕구가 생겼지만 티켓을 새로 만들고 하던 작업을 마친 다음 작업을 하는게 효율이 훨씬 좋았다. 그리고 PR했을 때 리뷰어들이 코드를 파악하기도 수월하다. 일하는 방식에 익숙해지고 있는중이다. 추가적으로 애자일 방식이 뭔지 공부가 필요하다.

코드 리뷰와 리팩토링 그리고 페어 프로그래밍

프로젝트 중 가장 힘들고! 가장 보람있었던 것이! 페어 프로그래밍을 통한 리팩토링이었다. 우리의 페어 프로그래밍의 목적은 각자 다른 코딩 스타일을 맞춰 앞으로의 프로젝트에서도 일관된 스타일을 유지하고, 리팩토링을 통해 코드 품질을 높이기 위해서였다. 내가 짠 코드를 상대에게 이해시키고, 나와 생각이 다른 부분을 맞춰가고, 내가 고수하던 스타일을 버리는 과정이 쉽지는 않았지만, 다른 관점, 다른 방식을 많이 배울 수 있었고, 리팩토링을 통해 더 나은 결과물을 만들 수 있었다. 다만 과정이 힘들어서 좀 더 즐겁게 할 수 있는 다른 방식이 있는지는 궁금하다. 그리고 antd 사용법을 통일하거나 사용하는 방법이나 랩핑 레벨 등을 맞추고 싶었는데 못해서 아쉽다.

맥락에 대하여

맥락없이 일하고 있다는 것을 요즘 많이 느낀다. 분명 1주일 스프린트 단위로 일을 잘 쳐냈는데 릴리즈가 많이 늦어졌다. 구현은 2~3주 만에 빨리했는데...? 전체 프로젝트 일정에 대한 인식이 없었다고 생각한다. 그리고 벌써 일한지 두 달인데 회사 도메인이나 프로덕트에 대한 이해가 많이 부족하다. 나는 아직 신입이니까라는 생각으로 깊이 이해하려고 하지 않았던 것 같다. 또 반성... 일을 할 때 전체 맥락을 항상 생각하면서 일하기!!!

공부 + 읽은 것

리팩터링 2판

리팩터링 말만 많이 듣고, 하는 시늉만 했지 왜 하는건지 어떻게 하는 건지는 잘 몰랐다. 그걸 알기 위해 주 2회 스터디를 하고 있다. 이번 달에는 리팩터링이 무엇인지, 왜 하는지에 대해서 그리고 코드의 어떤 부분을 리팩토링 해야하는지에 대해 읽었다. (ch 1,2,3)

왜 개발자 일의 8할이 이름짓기인지 이해했다. 피알하기 전에 리팩토링을 하자는 원칙을 세우고 실천중인데 자꾸 까먹는다..^^;

브라우저 101

자바스크립트와 브라우저 작동 방식을 더 잘 이해하기 위해서 듣고 있는 강의다. 강의 내용은 내 목적에 부합하는데 진도가 너무 안 나간다. 어쨌든 이번 달에는

• web api
• 이벤트
• crp에 대해 공부하고 정리했다.

다음 달 목표

• 정산 프로젝트 화이팅
• browser 101 강의 다 듣기
• 운동 일주일에 3번 꼭하기
• 운전면허 따기
• 리팩토링 부지런히 읽기