0. 일상​

• 그냥그냥 사는중
• 일 이외는 없음. 집에오면 침대에 누워서 쇼츠.. 덜덜..

0. 동기부여​

• 요즘 왜이리 동기부여가 안되는지 모르겠다. 일을 하고, 자기계발하는데 동기부여가 안되니 귀찮고 지친다. 움직이는걸 찾아봐야 하나 싶다.

0. 꾸준함​

몇 일간 또 일기를 못썼다. 꾸준함은 정말 힘드네.. 그래도 책은 자주 읽고 있다. 내일부터 다시 꾸준히 해야지

1. 하버드 인생학 특강​

지금 읽고있는 책은 "하버드 인생학 특강" 이다. 여러 사례를 통해 "후회없는 삶을 사는 법"을 알려준다. 지금 읽고 있는 부분은 "사회생활 속에서 행복 찾기" 중 일에 대한 동기부여를 어떻게 가질 수 있는지 알려준다. 정말 재미있어서 챕터 1을 빨리 읽고 생각정리를 하고싶다.

2. 창업​

창업에 대한 꿈은 언제나 꾸었다. 항상 마음속에 담아두고 있고 언제나 조금씩 실행중이다. 혼자서는 늘어지는 것 같아 주말 오전에 창업에 관심있는 사람들끼리 모여서 각자 할 일 하고 아티클 공유하는 모임을 만들었다. 앞으로 주말을 더 일찍 가치있게 사용하길 기대한다.

0. "더 시스템" 완독​

마지막에 속도가 느려졌지만 어쨌든 다 읽었다.

이 책을 읽게 된건 https://jojoldu.tistory.com/ 블로그 글에서 추천받아서 읽었는데 매우 만족한다. 공감되는 내용은 물론이고, 읽은 내용을 나에게 적용하고 있다.

책 내용을 다시 복기할 겸 책 마지막에 정리된 내용을 남겨본다.

1. 집중력 다지기​

유튜브 쇼츠를 봐서인지 원래 그랬는지 모르겠지만 긴 글을 읽지 못하는 병에 걸린 것 같다. 이걸 고치고 싶어서 요즘 책이나 문서를 읽을 때 하나하나 곱씹으면서 읽고있다. 지금은 속도가 느리지만 점점 빨라지겠지.

액션 아이템​

• 느리지만 곱씹으면서 책을 읽기
• 출근하면 명상을 하고 1시간 이상 책을 읽기
• 항상 맑은 정신을 유지하기
• 유튜브와 인스타그램 하지 않기

2. 확장 가능하지 않은 일을 하라 (Do things that don’t scale)​

회사에서 전략지원팀 분이 발표하신 내용에 있던 레퍼러 인데 매우 재미있게 읽었다.

https://medium.com/delightroom/do-things-that-dont-scale-6876c5682a75

사이드프로젝트를 하다가 잘 안될 것 같아서, 혹은 런칭했지만 접속자 수가 적어서 접은 케이스가 종종 있었는데 내가 잘못하고 있었다는 걸 글을 읽으며 많이 깨달았다.

이런 좋은 글을 접하며 읽게 되는건 모두 주변에 뛰어나고 좋은 사람이 있어서이다. 사람은 주변 환경이 중요하다는 사실을 이런 사소한 것에서도 항상 느낀다.. 환경이 진짜 젤 중요하다.

3. 사이드프로젝트​

사이드프로젝트를 잘 하기 위해서는 관련 공부를 하고 좁은(뾰족한) 전략을 탄탄하게 세운뒤에 하기로 마음을 먹고 공부를 조금씩 하고 있다. 일단 PMF부터 공부하고 세워보자.

0. 인간은 속한 사회의 영향을 매우매우 많이 받는다.​

회사의 콥뎁팀 분이 2주전에 발표하신걸 듣지 못해서 이번에 다시 들었다. 사업기획과 관련된 내용들이였는데 너무 좋은 내용들이였고 관련 분야에 흥미도 매우 많이 느꼈다. 사이드 프로젝트를 진행 할 때도 많은 참고가 될 것 같았다. 누구나 알고 있듯이 그리고 어느 책에서도 언급되듯이 사람은 주변 영향을 매우 많이 받는다. 주변에 뛰어난 사람들이 많으니 나도 많이 성장하는 것 같다.

회사분이 정리하고 요약한걸 여기에 적어둘 수는 없겠지만 참고 자료들은 다음과 같다.

• https://sarahtavel.medium.com/the-hierarchy-of-marketplaces-introduction-and-level-1-983995aa218e
• https://medium.com/delightroom/do-things-that-dont-scale-6876c5682a75
• https://sarahtavel.medium.com/white-space-for-building-a-marketplace-how-to-find-your-competitions-vulnerabilities-and-79674aa4d399

나도 일단 사이드 프로젝트 PMF부터 정의를 다시 시작해야할 것 같다.

1. 잘 한 일​

• 사업기획 관련 자료 읽고 정리
• 충분한 숙면

2. 내일(06.10) 할 일​

• 사업기획 관련 자료 읽고 정리
• 충분한 숙면
• 사이드 프로젝트에 1시간 투자 : 항상 못하지만 이번에는 꼭!
• 운동 40분

0. 피부관리​

피부과에 가서 얼굴에 있는 점이랑 사마귀를 뺏다. 이제 슬슬 준비해야지..

1. 당근 테크 밋업​

큰 규모로 당근 테크 밋업을 진행한다고 해서 도우미 역할로 지원했다. 뽑힐지는 모르겠지만 ㅎㅎ 이런 경험이 처음이라 두근거리고 재미있을 것 같다. ㅎㅎ

2. UGC​

현재 진행중인 사이드 프로젝트가 유저의 참여와 기여가 매우 중요한 서비스이다. 당근도 동일한데 이렇게 유저가 참여하고 기여함으로써 콘텐츠를 구성하는 서비스를 UGC라고 한다는걸 이번에 처음 알았다. UGC는 User Generated Content 의 약자인데 몇 일 간 UGC 스터디를 해보려 한다. 데이터 수집이나 B2B 계약등으로 모을 수 있는 데이터가 한계가 있는 케이스도 있고 모은 데이터가 부정확한 케이스도 있어 UGC는 특정 분야에 있어 필수적인 요소가 되기도 한다. 특히 방대한 영역에 대한 부분 그리고 자주 변하는 데이터가 그렇다. 보통 이런 케이스는 지도 그리고 상가 들이다.

3. 잘 한 일​

• 없음..
• 명상
• 충분한 숙면

4. 내일 할 일 (진짜 해야함)​

• 책 1시간 읽기
• 명상
• 충분한 숙면
• 사용자 참여 서비스 리서치
• 사이드 프로젝트에 2시간 투자

0. 한 일이 없음​

• 가족끼리 카페에 가서 쉬다가 집에와서 잠만 잤음

1. 잘 한 일​

• 없음.. 잠만 잤음..

2. 내일 할 일​

• 책 1시간 읽기
• 명상
• 충분한 숙면
• 사용자 참여 서비스 리서치
• 사이드 프로젝트에 2시간 투자

0. 회식 그리고 귀향​

원래 내일 울산으로 내려가기로 했었는데, 강아지가 하늘나라로 가는 바람에 오늘 급하게 기차 시간을 변경해서 가게 되었다. 회식은 북경오리 딤딤덕이라는 가게에서 했다. 기차는 KTX로 2시간 20분 정도 걸렸는데, 정말 너무 피곤하고 불편했다.

1. 이쁜 말​

어떤 말이라도 기분 나쁘지 않게 이야기하면 공감이 되고 따르게 된다. 하지만 기분 나쁘게 이야기하면 옳은 말이라도 일단 반발심이 생긴다. 이래서 같은 이야기라도 어떻게 말하느냐에 따라 세상을 나의 편으로 만들 수도, 나의 적으로 만들 수도 있다. 기분 나쁘지 않게 이야기하는 것을 이쁘게 말한다고 보통 표현하는데, 이쁘게 말을 하려면 경험으로부터 배울 수 있다. 하지만 이쁘게 말하지 않아 적이 된 사람에게 피드백을 받기란 쉽지 않다. 크게 노력하지 않아도 이쁘게 말을 하는 방법은 대면으로 대화하거나, 말에 감정을 싣지 않는 것이다. 특히 개인적으로 예민하거나 기분이 나쁜 일이 있을 때, 나의 감정을 말에 담아서 이야기하는 사람은 최악이라고 생각한다.

2. 잘 한 일​

• 책 1시간 읽기
• 명상
• 아침 운동 40분
• 충분한 숙면

3. 내일 할 일​

• 책 1시간 읽기
• 명상
• 충분한 숙면
• 사용자 참여 서비스 리서치
• 사이드 프로젝트에 2시간 투자

0. 집에 있는 시간을 최소화​

9시 조금 안되어 출근한 것 같다. 어제 집에 일찍 들어가니 침대에서 헤어나오질 못했다. 현재 집은 책상과 침대가 같이 있고, 집이 구축 빌라일 뿐더러 보니 습기가 많고 햇빛이 많이 들지 않아 집에서 뭘 하는게 마음이 편하지는 않다. 이제부터는 출근하여 회사에서 최대한 시간을 보내던가 저녁먹고 회사 앞 카페에서 나의 시간을 보내다 집에 들어가 잠만 자는게 좋을 것 같다. 추가로 오늘도 최대한 회사에 있다가 집에 들어갔지만 해야할 일을 많이 했다는 느낌은 없어서 나의 시간 확보와 그 시간을 유용하게 사용하는 법을 계속 탐구해야할 듯 하다.

1. 책 구매​

ebook을 자주 읽는데 지금 읽는 책을 이번주에 다 읽을 것 같아 예전부터 관심있던 책 몇 권을 샀다. 싯다르타, 하버드 인생학 특강, 일류의 조건 세권을 샀는데 이제 인문학 책을 많이 읽어 보려 한다.

2. 잘 한 일​

• 책 1시간 읽기
• 명상

3. 내일 할 일​

• 충분한 숙면
• 책 1시간 읽기
• 사용자 참여 서비스 리서치
• 운동 30분 하기 (유산소 13, 근력 16)
• 아침 명상

0. 아침형 인간​

어제 11시 즈음 잠들어 6시50분 즈음 일어나 8시에 회사에 도착했다. 그 시간에도 지하철에 사람이 많아서 놀랐다. 자리가 부족했다 ㅠ 출근하여 코드리뷰하고 운동도 갔다왔다. 일찍 하루를 시작해서 좋았고 머리도 맑았다. 그런데 집에와서 보상심리인지 간식먹고 침대에 누워서 자버렸다. 그러면 안되는데.. 그래서 오늘은 조금 늦게 잠을 자도록하고 내일 부터 좀 더 자제력을 키워야할 듯 하다.

1. 낭랑이​

본가에 시츄를 키웠는데 오늘 하늘나라로 갔다. 낭랑아 거기서는 아프지말고 행복하렴

2. gpt 4o​

GPT 4o을 무료로 몇 개 사용할 수 있어서 사용중인데 3.5보다 퀄리티가 훨씬 좋다. 진짜 똑똑한 사람과 같이 일하는 기분이다. 물론 발산이나 창의력 그리고 세심함은 떨어져도 이외에는 너무 출중하다

3. 내일 목표​

• 사용자 참여 서비스 리서치
• 책 1시간 읽기 : 오늘 하지 못해서 내일은 꼭!
• 운동 30분 하기 (유산소 13, 근력 16)

0. 등산​

• 용마산 등산했다. 계단이 많아서 조금 힘이 들긴 했다.
• 가방이랑 물을 못 챙겨서 아쉽... 다음 번에는 잘 챙겨서 가야지
• 다음 등산할 곳은 불암산! 그다음은 도봉산 갈 것 같다. 지금까지 등반한 산 중에서 수락산이 가장 힘들었다.

1. 사이드 프로젝트​

• 원래 주식 관련 사이드 프로젝트를 진행중이였는데 토스증권이 너무 잘하고 있기도 하고 내가 작업한 것들도 빠른시일 내로 넘볼 것 같아서 몇 달 진행한 프로젝트를 접게 되었다. 토스증권 pc 오픈 된거 보고.. 좌절.. 너무 잘 만들었더라..
• 예전에 한 번 도전한 적 있는, 그리고 내가 파고들어 기존 시장을 뒤집을 수 있을만한.. 주류관련 플랫폼을 만들어 보려고 한다. 이번에는 잘되길..

2. 성공의 시작은 아침형 인간이 되는 것​

유튭을 보다가 아침에 일찍 일어나는게 중요하다는걸 영샹을 봤다. 나도 항상 어려워 하는건데 아침에 일찍 일어나는거 다시 도저어언~!

• 부자들이 매일 실천하는 6가지 습관
• 아침형 인간이 되는 비결

3. 내일 목표​

• 사이드 프로젝트 로드맵, 비전 정리, mvp todo 정리, 칸반보드 task 만들기
• 책 1시간 읽기
• 운동 30분 하기 (유산소 13, 근력 16)

1. eslint-plugin css sorting 만들기​

회사에서, 개인프로젝트에서 vanilla-extract.style 를 사용하고 있는데 css sorting이 되면 좋을 것 같아서 만들어보고 있다. 회사분이 좀 만들어 둔게 있어서 거기에 기능들을 추가하고 버그를 수정하여 개발중이다. 배포까지 했지만 실제 적용하니 spread-operator를 생각하지 못해서 제대로 파싱이 안되던가, vs의 recipe 를 고려하지 않아 깨지는게 있어서 고치는 중이다. 다음주 중에는 완성할 수 있을듯?!

2. 책 읽기​

회사분과 잡담을 했는데 한 분이 책을 읽는건 머리를 굴리기 위함이다 라고 이야기를 하셨는데 오! 싶었다. ai가 많이 침투해있고 많이 침투할 것 을 대비하기 위해 우리의 머리를 향상 시켜야 한다. 정리하고 요약하며 필요한 걸 뽑아내는 능력은 머리를 향상시켜야 능률이 올라간다. 책을 많이 읽자. 오늘부터 전자책을 넣어 다니는 작은 가방을 항상 들고 다니고 있다.

0. 다시 시작​

다시 일기 쓰는걸 시작한다. 1월 3일을 마지막으로 안썼는데 당시 이사 등 큰 문제들이 있어 스트레스를 엄청 받다보니 일기에 에너지를 쏟는게 너무 힘들어서 그만두었던것 같다. 그리고 깨진 나의 습관은 다시 돌아오는데 많은 시간이 들었다. 다시 돌아온 기념으로 앞으로 일기에 대한 마음가짐. 그리고 지금까지의 공백에 대한 이야기를 길게 적어보려고 한다.

일기에 대한 마음가짐​

일기는 적는 이유는 오늘 하루동안 한 일을 회고하는데 있다. 3자의 입장에서, 전쟁에서 싸우고 있는 병사의 입장이 아닌 전쟁을 지휘하는 지휘관의 입장에서 나의 하루를 바라보며 발전시킨다.

일기를 계속 쓰기위해 어떻게 해야할까?

1. 일기를 쓰는 허들을 낮춘다.

• 마크다운으로 일기를 쓰는건 사전작업? 과 제약이 너무 많다. (pc로 해야한다, git push & pull 해야한다)
• 겪은 일들과 그에 대한 생각을 이야기 하듯이 편하게 적어본다.

2. 일기를 쓰기 위한 동기부여를 준다. (일기 쓰는게 나에게 많은 도움이 된다는 것을 인식)
3. 규칙적인 삶. 그리고 매일 일기를 쓰도록 단련한다. 습관으로 자리잡도록 한다.

1. 그동안 있었던 주요한 일들​

다 적기엔 양이 있기도 하고 공개하고 싶지도 않아서 간략하게만 적어본다.

• 장한평역에서 군자역 부근으로 이사
  • 사유: 전세 -> 월세 (전세 보증금 못 받을까봐 이때 스트레스와 걱정이 엄청났다. -> 일기를 쓰지 못했던 이유)
• 결혼준비
  • 엄청 많은 일들은 안했지만 상견례도 하고, 웨딩 플래너와 상담도 받고 웨딩홀도 예약하고.. 등등 했다.
• 회사일
  • 회사에서 정말 중요한 프로젝트를 진행하기 위해 많은 일들을 했다.
• 와인 수업 & 자격증 WSET Level 3
  • 와인 WSET Level 3 수업을 3개월 듣고, 시험까지 쳤다. 결과는 3~4개월 걸린다던데 제발 합격하기를.. 실패하면 재시험 비용이 34만원 이다. 이런.. 씁.. 날강도..
• 주식
  • 전세에서 월세로 옮기고 남은 금액 모두를 주식에 몰빵했다. 이슈가 된 인튜이티브머신스에 투자해 한달에 1000만원 벌기도 했고 반도체, ai 등에 잘 못 들어가 -2000만원까지 찍은 적도 있었다. 아직 마이너스이긴한데 조금씩 회복중이다. 7월즈음 되면 +가 되지 않을까.. 희망회로를 돌려본다.
  • 대부분 미국주식을 하고 있는데 단타를 하게 되면 밤에 잠을 못자서 다음날 타격이 너무 크다. 스트레스도 너무 많이 받아서 힘이 든다. 배운점이 있다면.
    1. 성장가능할 만한 기업에 투자해라 (공부를 하고 투자해라)
    2. 객관적인 지표를 봐라. 커뮤니티에 선동되면 안된다
    3. 단타가 아니라 장타를 해라 (장타를 하지만 어느정도 수익을 본다면 반드시 익절을 해라)
    4. 분할 매수, 분할 매도를 지켜라. 익절을 할 때도 50% 익절 후 나머지는 시간을 두고 조금씩 익절해라.
    5. 아무리 좋은 종목이여도 많이 올랐다고 생각한다면 절대로 사지마라. 투자의 기본은 좋은 종목을 저가에 구매해 고가에 파는 것 이다. 좋은 종목을 고가에 구매한건 절대로 좋은게 아니다.
• 투자 사이드 프로젝트
  • 투자를 잘하기 위한 정보를 제공해주는 사이드 프로젝트를 하고 있다. 내가 사용할만한 서비스를 만들고, 뾰족한 부분을 만드는 중인데 재밌게도 하고 어렵게도 하다. 하지만 꿈이 창업인 만큼 열심히 해보려고 한다. 이걸로 돈을 벌어보고 싶다.

2. AI 시대가 오고 있다.​

chat gpt가 나오고 개발의 많은 부분에 chat gpt가 사용되고 있다. 나의 일자리도 위협받고 있다. 언젠가 나의 일의 대부분이 ai로 대체되겠지.. 동료분과 ai 이야기도 많이 나누고 있는데 다들 조금씩 걱정중이다.

• ai를 잘 활용해야한다.
• 기술서적이나 개발서적에 대한 중요도가 점점 떨어지고 있다. ai가 훨씬 더 잘한다. 코드 주면 리팩터링 알아서 해주고, 테스트코드도 다 짜준다. ai로만 코드가 작성되면 테스트코드도 필요없어질 것이다.
• 코드리뷰도 없어질 것이다. ai가 코드를 작성하고 리뷰까지 할 것 같다. (지금도 조금씩 도움을 받고 있는데 도움을 받는 영역이 점점 늘어날 것 이다.)

그래서 어떻게 해야하나?

• 커뮤니케이션 능력과 사고능력이 중요하다. 이런 능력들이 잘 융합되어 내가 필요로 하고 원하는 것들을 잘 정리할 수 있어야 한다. 정리만 잘해서 ai에게 주면 ai가 모든 작업들을 해줄 것 이기 때문이다. 그래서 인문학 책을 많이 읽어야 한다.
• 이과가 아닌 문과의 능력을 키워야 한다. 책을 많이 읽자

01. 운동​

매일 6~7시 기상하여 회사 도착하자마자 운동을 다녀오고 있다. 운동을 매일 아침에 하니 좋은점

• 하루가 피곤하지 않다. (에너지가 많아졌다.)
• 12시에 피곤하여 잠든다.
• 집중력이 올라갔다.
• 긍정적으로 변했다. (원래도 부정적이지는 않았는데 더 차분해진 것 같다.)

02. Mandalart​

야구선수 오타니 쇼헤이가 사용했다는 만달아트를 나도 작성해보았다. 목표를 조금 더 구체화하고 목표를 달성하기 위한 작은 목표들을 세울 수 있어서 좋았던 것 같다. 작은 목표들을 꾸준히 수행한다면 최종 목표가 이뤄지는 형태이다.

Mandalart에 대해 조금 설명을 하자면 mand(본질의 깨달음) + al(달성 및 성취) + art(기술) 의 합성어이다.

본래 8개의 목표를 중간 목표를 적는데 너무 많아서 5개로 줄여서 작성했다.

올해의 목표는 "후회하지 않고 살기" + "내년에 올해를 봤을 때 많은 일을 했다고 느끼기"이다.

03. 아마존의 (6-page-memo)​

아마존에서 미팅할 때 사용하는 6-page-memo는 링크드인의 글을 보고 알게되었는데 마침 필요한 상황(미팅을 준비할 일)이 있어 적용해보는 중이다.

링크드인의 글을 가져오면 다음과 같다.

6-page-memo를 작성하는 방법은 미디엄에 잘 설명된 글이 있어 참고할 수 있었다.

0. 24년 목표​

• 건강
  • 평일 1시간 운동하기
• 커리어
  • 하루 3시간 시간 투자하기
  • 기술서적 꾸준히 읽기(함수형, 단위 테스트, 개발 방법론)
  • 자기계발 서적 꾸준히 읽기(타이탄의 도구들, 그릿)
• 창업&수익
  • 하루 2시간 시간 투자하기
  • 주식공부
    • 차트공부
  • 머신러닝
• 기타
  • 와인취미
    • WSET Level3 최고등급으로 취득

1. 주식​

"초수익 성장주 투자" 책 완독했다.

책의 마지막 파트는 리스크 관리에 대한 내용이였고 여기에 매우 공감가는 내용들이 많아서 정리를 해보았다. 주린이라면 항상 궁금해하는 내용인 것 같다.

0. 키보드​

고민하다 문랜더 키보드를 구매했다. https://www.zsa.io/moonlander/ 다음주 화요일에 배송된다는데 너무 기대된다 ㅎㅎ

• black
• 저소음 적축

1. 이사​

집 만기가 2월 21일 이라 연장을 해야할지 이사를 해야할지 고민을 했는데 내후년에 집을 매매할 수도 있고, 자금이 필요할 것 같아 이사하기로 했다. 지금 살고 있는 집이 80% 대출로 살고 있는데 은행에 나가는 이자가 너무쎄고 (6.8% 까지 금리가 오른 적도 있었다.) 원금상환시 내야하는 돈도 아깝고, 보증금으로 큰 돈이 물려있다보니 부담이 되었다.

2000/70짜리 오랜된 빌라 투룸으로 계약을 했는데 나름 만족한다. 흠이라면 지하철역까지 8분 정도 걸어야 하는건데.. 그래도 가성비는 최고인 듯 하다.

2. 주식 스터디​

개발모임에서 진행하는 주식 스터디를 진행중인데 모두 처음 제대로 공부하는거라 주식을 정말 잘 아는 사람에게 조언을 듣고 싶어 당근 주식 모임에 가입했다. 그 분은 몇 십년 주식을 공부하고 해오고 계신데, 그 분은 기업분석 5%, 차트분석 15%, 경험 70% 라고 하셨다. 여기서 차트는 단순 오르락 내리락의 그림은 아니다.

지금 "초수익 성장주 투자" 책을 읽고 있는데 고수분의 말이 책에도 비슷하게 나오긴 한다. 책에서는 당연 기업분석을 다루긴 하지만 기업분석을 매우 다각도로 해야하고 추세도 중요하다고 했었다. 좋은 기업이라고 오르는게 아니라 주식에 큰 물결을 일으킬 수 있는 기관의 개입에 따라 주식이 오르고 떨어진다고 했다. 그래서 기관이 사기전에 매수하고 팔기전에 매도하는게 좋은데 그걸 알 수 없으니 좋은 기업을 기관이 구매할꺼니 기업분석을 통한 가치투자로 미리 구매를 하던가 오르기 시작하는 추세를 파악해서 매수하라고 책에서 이야기 한다.

모두 맞는 말이지만 직장인이라 차트분석을 하던가 경험을 쌓기는 어려워 기업분석을 통한 가치투자를 하는게 지금으로써 베스트가 아닌가 싶다.

3. 와인 자격증 WSET Level 3 도전​

WSET Level 2 자격증이 배송왔다! 나이스~ Level 3 도 하고 싶은데 가격이 비싸서 고민이였지만 얼리버드로 10% 할인행사를 하고 있어서 구매하고자 한다. 이번에는 진짜 열심히 공부해서 좋은 성적 받아야지!

0. 와인 앱​

오랜만에 와인 앱에 대해 글을 쓴다. popo 서비스를 종료했다. (playstore에서 내렸다.) 오랜만에 play console에 들어가보니 설치 사용자 수가 1명.. 처참한 설치율에 슬퍼하면서 내렸다.

1. 주식 스터디​

주식 스터디 첫 모임을 했다. 주식에 대한 기본 용어나 개념들을 익히는게 목적인데 잘 할지 모르겠다.

2. 문렌더 키보드​

이전에 nuphy 키보드에 관심이 생겼다고 했는데 이제 문랜더 키보드에 관심이 생겼다. ㅋㅋ 역시 안사길 잘했다. 문랜더는 인체공학 키보드가 사면 좋을 것 같은데 가격이 비싸서 고민이 된다.

0. 일상​

• 벌써 12월이다. 올해는 너무 빨리 지나간 듯하다.
• 와인 모임을 시작하려고 한다. 와인을 자주 접하면서 전문가가 되고 싶다는 욕심이 생겼다. (와인을 잘아는 사람들이 너무나 많다.)
• "아주 작은 습관의 힘" 책을 읽고 내가 들이고 싶은 습관이 형성된 집단에 들어가야겠다 생각이 들어 당근모임에서 자기계발 모임 2군데에 들어갔다.
• 주식 스터디 책을 4장까지 읽었는데 내가 왜 주식에서 돈을 읽고 있는지 잘 설명해주고 있었다. 저자는 내가 경험하고 내가 실패한 전략을 모두 경험했었다.
• 자기계발 모임으로 부터 목표에 대한 고민을 하게 되었고 그 와중에 유튜브에서 관련 영상을 찾았다. 간단하게 보긴 했는데 다시 봐야지. https://youtu.be/tpblKIvY6f8?si=XoUEoN9_ssBqseTK

0. 주식스터디​

주식 스터디를 진행하고 있다. 어떤걸 공부해야할지 몰라서 우선 책을 사서 보기로 했다.

책은 초수익 성장주 투자로 결정했고, 어제 chapter 2까지 읽었다.

1. smartfarm​

스마트팜에 대한 기본적인 공부는 끝났고 이제 본격적인 motion을 해야한다. 대략적인 로드맵이랑 smartfarm의 spec과 설계를 구체화해야 한다.

2. 자기계발 모임​

개발 스터디는 요즘 안하고 있고, 자기계발 모임을 2개 하고 있다. "타이탄의 도구들"과 "아토믹 해빗" 책 정리한 것들도 따로 뺄 예정이다.

01. 습관의 힘​

• GeekNews: https://news.hada.io/topic?id=9677&utm_source=slack&utm_medium=bot&utm_campaign=T04J76D4C
• 책: 아주 작은 습관의 힘 (Atomic habits)

회사 사무실 입구에 간식바가 있다. 간식바가 없다면 나는 살이 덜 쪘을까? 만약 내가 성장하고 싶다면, 좋은 습관을 들이고 싶다면 뛰어난 사람이 있는 그룹에 들어가거나 내가 들이고 싶은 습관을 꾸준하게 하고있는 그룹에 들어가야 한다는 것에 200% 동의한다.

자기개발을 꾸준히 하는 모임에 들어가고 싶은데 어떻게 들어갈 수 있을지.. 흠..

1. Nuphy air75 v2 키보드​

요즘 꽂힌 키보드가 있는데 Nuphy air75 v2 키보드다. https://nuphy.com/collections/keyboards/products/air75-v2 진짜 이쁘다.

나는 확실히 로우프로파일을 좋아한다. 키보드 누를 때 짧게 누르면서 손가락이 많이 움직이거나 힘이 들어가는걸 좋아하지 않는 것 같다. 그래서 매직키보드도 잘 사용하고 있다.

하지만 일시적인 소유욕인 것 같아서 12월에도 구매하길 원한다면 그 때 구매할 예정이다.

2. 스마트 팜​

• 엽채류 생산은 확실히 채산성이 안좋다. LED로 식물을 키우면 맛이 없다는 이야기도 있다.
• 채산성은 안좋지만 밤에도 빛을 쐬어주어 빠르게 자라기에 많은 양을 생산하면 된다는 이야기도 있다. 하지만 이럴 경우 판매경로를 제대로 뚫어 놓지 않는다면 손해를 보기 쉬울 것 같다.
• 식물을 키울 때 병은 거의 없지만 벌레는 어떻게든 생기게 된다. 이럴 때 마늘이 함유된 제품을 사용한다는 이야기도 있었다. 참고: https://youtu.be/UOU60rd77TU?si=X_DN4M_YpXMp70iV
• 과일을 키워야 할 것 같다. 한국은 과일이 비싸서 채산성이 괜찮다고 한다.
  • 스마트 팜의 경우 어떤 작물을 키워야 할 지 선택하는게 매우 중요한 것 같다.
• 과일의 경우 키우는데 시간이 오래 걸리기 때문에 수익이 빠르게 나지 않는다.
• 과일의 경우 대부분 나무에 열리기에 vertical farming이 가능할지 찾아봐야하고, 열매를 어떻게 자동으로 수확할 수 있을지도 고민이 필요하다.
  • 딸기는 vertical farming으로 잘 키우기는 하더라. 하지만 손으로 모든걸 수확한다.
• Aeroponics 기법의 경우 구멍이 자주 막히는 문제가 있다.
• 24평의 경우 전기비가 1달에 100만원 정도 들었다는 이야기를 들었다.

정리​

• 어떤 작물을 키울지가 매우 중요하다. (채산성, 수확 시간, 난이도 등을 고려해야 한다.)
• 엽채류는 채산성이 안좋지만 밤에도 LED를 쏴주면 빠르게 자라기에 단기간에 많은 량을 수확할 수 있다. 하지만 맛이 없다는 이야기도 있고, 판매로를 제대로 뚫어 놓지 않는다면 손해를 볼 수 있다.
• 과일은 채산성이 좋다. 하지만 키우는데 시간이 오래 걸리기에 수익이 빠르게 나지 않는다. 또한 vertical farming이 가능한지, 자동으로 수확할 수 있는지 고민해야 한다.
• 자연에너지를 충분히 활용하지 않는다면 전기에너지가 많이들어 부담이 될 것 이다.
  • 태양광, 바람, 실외 온도를 충분히 활용해야 한다.
• 병충해 중 충해는 어떻게든 생기기에 대비를 해야한다.

0. 스마트 팜​

예전에 "타이탄의 도구들"을 읽고 쓴 글을 읽다가. 꿈보다 목표가 중요하다는 글을 다시 읽게 되었다.

꿈보다 목표가 중요하다​

꿈은 일어나지 않을지도 모르는 일을 그냥 상상하는 것이다. 하지만 목표는 그걸 이루기 위한 구체적인 계획을 세우고 열심히 노력해 마침내 이루는 것이다. 내게 성공의 본보기가 되어주는 사람들은 모두 조직적인 목표를 갖고 이를 달성하기 위한 탁월한 계획을 세우는 사람들이다.

스마트 팜을 하려고 하는데 꿈만 꾸고 제대로된 목표를 정하지 않았었다. 이제 자잘한 목표를 정해보자. 그리고 하나씩 격파해 나가자.

1. 목표와 원칙​

• 진짜 이유가 있어야 좋은 전략이 나옵니다
• 레이달리오의 성공을 위한 원칙

목요일 아침에 위 영상을 보았고 간단히 정리해봤다.

원칙은 유사한 상황에서 반복적으로 발생하는 일을 처리하는 현명한 방법이다.

원칙에서 출발한 것이 아니라. 평생의 경험을 통해 원칙을 정하는 것. 대부분 실수를 하고 반성하는 것으로 부터. 내 삶의 원칙은 간단하지만 완벽하지는 않다. 저는 여전히 최선의 결정을 내리기 위해 고군분투하고 여전히 실수를 하고 항상 새로운 원칙을 배웁니다. 이것이 현실입니다.

다른 사람이 지시하는 삶을 살고 싶지 않다면, 스스로 무엇을 해야 할지 결정하고 그것을 할 수 있는 용기를 가질 필요가 있다.

역경은 항상 있고, 매일 결정을 내려야 한다. 움직임을 멈출 수도 없고, 충돌을 피할 수도 없다. 가능한 최선의 방법으로만 접근할 수 있다. 수백만 가지의 결정을 하게 될 것이다.

현실을 받아들이고 그것을 다루는 것에서 시작한다.

1. 목표는 명확하게 방법은 유연하게
2. '목표 계층도' 만들기
3. 거절을 연습하기
4. 남이 꺼리는 일을 기꺼이 하기
5. 사명과 목표, 그리고 전략을 시각화 해라

우리는 일을 하면서 당연히 실패를 맛볼 것이다. 그리고 실패로 부터 배우고 익히며 원칙을 정해 실패를 줄여나가야 한다. 원칙은 완벽하지 않으며 계속 수정해 나가야 한다. 원칙은 경험으로 부터 만들어진다. 우리가 회사에서 팀으로 일할 때 원칙을 정하는게 중요하다는 걸 알 수 있다. 이 원칙은 남이 정하는게 아니라 팀이 그동안의 경험을 바탕으로 정하는게 훨씬 좋을 것 같다는 생각도 있다.

목표는 명확해야하고 유연해야한다. 목표는 하나만 정하는게 아닌 해당 목표를 달성하기 위한 작은 목표들도 같이 만들어 시각화 해야 목표를 달성하기 쉬워진다. 그리고 이 목표와 벗어난 것들은 철저히 배척하고 하지 말아야 한다. 그래야 목표를 달성할 확률이 높아진다.

0. 일상​

• 회사 & 집 하고 있으며 집에 오면 유튜브만 보게 된다.
• 진짜 도파민을 위한 유튜브를 대부분 보긴하는데 어쩌다 성장에 도움이 되는 영상을 보기도 한다.
• 내가 좋아하는 채널들을 몇 개 소개하고자 한다.
  • B2CF | 비트카페: 해외 컨퍼런스나 인터뷰를 번역해서 올리는 채널이다.
    • 최근에 본 것 중 가장 재미있었던 것: 스티브잡스의 의사결정 방법 (직관 vs 데이터)
    • 역시 최고는 일론머스크 1: [일론 머스크] 쉬지 않고 계속해서 부를 축적하는 이유 (한영 자막)
    • 역시 최고는 일론머스크 2: [일론 머스크] 성공한 사람과 실패한 사람의 차이 (한영 자막)
  • World Knowledge Forum: 세계 지식 포럼에서 진행하는 강연들을 올리는 채널이다.
  • Project스노우볼
    • 최근에 본 것 중 가장 재미있었던 것: [일론 머스크] 쉬지 않고 계속해서 부를 축적하는 이유 (한영 자막)

적다보니 일론머스크 영상밖에 없네 ㅋㅋㅋ 자극을 받고 싶은가? 그럼 일론머스크의 영상을 봐라

1. 회사​

팀이 크게 4개로 나눠어져 있어 FE도 4개의 프로젝트를 진행하고 있었고, 최근에 이를 하나의 프로젝트로 만드는 과정을 진행중이라고 이야기 했었다.

지금은 하나의 레포로 옮기는 작업은 끝났고 각 프로젝트들에 퍼져 있는 코드들을 하나로 모으는 작업이 진행중이다. 나의 작업이 여러 프로젝트에 영향이 가서 조심스럽게 천천히 진행중인데 여기에 대한 이야기도 해보고 싶다. (아직 생각 정리중)

0. 와인​

• WSET Level 3 는 국비교육이 오픈되지 않아 내년에 신청할 것 같다.
• POPO는 4명이 설치했다가 지금은 2명만 설치되어 있다. IOS도 배포를 할지 고민중이다.

1. 스마트 팜​

• https://www.youtube.com/watch?v=OHFhVfsT_cs 영상을 시청했다.
• 댓글을 보고 흥미로운 정보를 발견했는데, 인공광은 태양광을 대체하지 못한다. 특정 식물이 필요로 하는 스팩트럼만 인공광으로 쏴주면 식물을 키울 수 있다. 하지만, 태양광은 식물이 필요로 하는 스팩트럼을 모두 가지고 있기 때문에 태양광이 더 효율적이다. 인공광은 태양광을 보완하는 역할을 한다. (특정 스팩트럼이 부족할 경우, 인공광으로 보완한다.) 라는 댓글이다.
• 태양광을 무시하고 실내나 지하에서 스마트팜을 하는 건 매우 비효율적인 방법인 것 같다. 스마트 팜이라도 태양광이 내부로 들어올 수 있어야 하고 스마트팜은 내부로 들어오는 태양광의 양을 조절하고 부족한 빛은 인공광으로 대체하도록 해야한다. 그게 아니면 전기 에너지도 너무 많이 들고, 식물이 필요로 하는 스팩트럼을 모두 제공하지 못한다.

2. HTTP Status 0​

서비스를 운영하면서 http status 0인 케이스가 여러번 있는데 해당 케이스에 대해 조사를 해봤다.

XMLHttpRequest의 스팩이 httpStatus의 초깃값이 0였다가 서버의 response header로 httpStatus가 업데이트됨. (status === 0로 throw되었다면 "요청에 실패함"으로 생각하면 됨)

다음 상황에서 발생​

1. 불법적인 교차 출처 요청( CORS 참조 )
2. 방화벽 차단 또는 필터링
3. 요청 자체가 코드에서 취소되었습니다.
4. 설치된 브라우저 확장 프로그램이 문제를 일으키고 있습니다. sentry에서 올라온 모든 status 0 에러는 3번 케이스인 "요청 자체가 코드에서 취소된 경우"로 XMLHttpRequest가 요청을 보낼때 request timeout 디폴트 0로 잡고 있는데 이때까지 request를 하지 않으면 status 0로 AxiosError를 throw해버림. (네트워크 연결이 잘 안된경우)

Reference​

• https://stackoverflow.com/questions/872206/what-does-it-mean-when-an-http-request-returns-status-code-0
• https://fetch.spec.whatwg.org/#concept-network-error
• https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/status

3. 공부​

• 밋코더 11월 신청을 했다. 공부에 소홀한 나를 이끄는 건 역시나 스터디..! 이번에 공부할 껀 "유닛 테스트" 와 "그릿" 책을 읽어볼 예정이다.
• 추가로 웹뷰간 통신 or 웹뷰 네이티브 간 통신에 대한 내용, 카드결제에 대한 내용들을 공부하고 정리해 볼 예정이다.

0. 와인​

와인그래프 티타임​

와인앱을 개발하며 여러 와인앱을 살펴봤는데 국내에서는 와인그래프가 가장 많은 database와 앱 사용성이 좋았다. 와인앱 개발하며 어려웠던 부분들이 많았는데 타 와인앱들은 어떻게 이 문제를 해결했는지, 그리고 있으면 좋을 것 같은 기능들을 왜 구현하지 않았는지? 어떤 제약이 있었는지 궁금하여 와인그래프에 티타임을 요청하여 가졌다.

주요 질문들은 다음과 같았다.

• web 서비스를 하지않는 이유는
• 가격정보를 노출하지 않는 이유는
• 대형마트와의 제휴는 진행중인지
• 와인 정보를 어떻게 모았는지
• BM

친절히 답변주셔서 와인시장에 대해 이해를 많이 할 수 있었다.

1. 멘토링​

어제 멘토링을 진행했는데 음.. 난 역시 누군가를 가르치는데 소질이 없다. 경험이 많이 없어서 그런걸 수도 있다. 다른 사람의 받아들이는 속도에 맞추고, 계획을 짤 때 멘티의 역량과 소화할 수 있는 걸 가정하고 짜야하는 것들.. 내가 처음에 생각한 것에서 계속 엇나가고 방향이 틀어진다. 멘티가 내가 설계한 것에 맞추는 방법과 멘티의 역량에 나의 설계를 계속 조절하면서 진행하는 방법이 있다는 것도 이번에 배웠다. 후자의 경우 나의 에너지가 엄청 소모된다ㅠ

2. 스마트 팜​

예전에 긱뉴스에 올라왔던 글인데 https://present.do/documents/64aa897810ab9a5ae55bae90?page=1 이걸 다시 봤고, 스마트팜을 하려면 sw, hw, infra, ml 진짜 모든 기술이 다 들어가야 할 것 같았다. 적어도 hw는 당연히 필수. 대학교때 아두이노, 라즈베리파이를 조금 만져봤었는데 다시 그 기억을 꺼내야할 때가 온 것 같다.

아직 개발은 안할꺼고 농사, 식물에 대한 공부를 해볼 생각이다. 이건 이론이 모두 준비된 상태에서 모두 설계를 마친 후 개발을 진행하는게 좋을 것 같다. 그게 아니면 엄청난 고난이 예상된다.

0. 와인​

와인은 이제 내 삶에 큰 부분을 차지하고 있다.

WSET Level 2​

WSET Level 2 결과가 발표되었다.

나는 80으로 Pass with merit를 받았다.

시험 본 후 2등급일 꺼라고 예상했었는데 역시나.. 하지만 공부시간 대비 결과는 만족스럽다. 미리미리 공부 할껄..

Level 3 수강할지 고민이다. 3개월 수강, 200만원 이라는 비싼 수강료가 부담되는데 와인은 계속 접해야만 실력이 늘고, Level 3 부터는 테이스팅 시험도 있어서 더 인정 받는것 같기도 해서다.

추가로 와인모임을 가져볼까도 생각중이다. 와인은 진짜 계속 접해야 실력이 늘고 이론도 안까먹는다.

와인 앱 출시​

드디어 popo가 playstore에 출시되었다. 링크

다운로드 수가 3명 뿐이지만 많은 사람들이 다운받는게 원하는 바는 아니여서 괜찮다. 혼자서 앱 만들어 출시해보는 경험이 무척이나 재미있었다.

앱 개발하기전 생각했었던 모든 기능들을 구현했고, 실제로 사용해보면서 불편한 점들을 수정하여 나 혼자 사용하기에 충분한 앱이 되었다는 점에서 만족한다.

별일이 없는 한 앱을 더 고도화하거나 추가 개발은 하지 않을 것이고, 예전부터 생각했었던 새로운 프로젝트를 시작해볼까 한다.

1. 멘토링​

지금 멘토링을 주 1회 1시간 하고 있는데, 괜히 멘토링을 시작한 것 같다. 시간과 에너지를 너무 쏟게 된다. 책임감도 상당해서 부담도 된다. 이걸 마지막으로 멘토링은 끝내야겠다.

나는 누군가를 가르치는데 소질도 없고 원하지도 않는 것 같다.

2. 새로운 프로젝트​

새로운 프로젝트를 시작해보려고 한다. 주제는 스마트팜이고 관련된 정보는 아직 없고 의욕만 있는 상태라 조금씩 정보를 모으고 구체화 해나가야 한다. 하루에 한시간씩 매일 시간을 투자할 계획이다.

1. 와인앱 출시​

와인 앱을 드디어 playstore에 올렸다. 아직 검토중이라 보이지는 않겠지만, 이건 빠른시일 내에 되겠지..

처음에는 추석 연휴때 올리려고 했으나 부족한 기능들이 생각보다 너무 많았고 배포를 위해 준비해야할 스크린샷등도 필요해서 미룰 수 밖에 없었다 ㅠㅠ

그래도 처음 앱을 기획했을 때의 모든 기능들이 포함되어 있어 만족한다. 처음부터 내가 사용하기 위해 만든 앱이기도 하고 실제 와인 매장에서 사용해 봤을때도 나름 유용했다.

이제는 이 앱을 계속 유지보수하여 다른 사람들도 편리하게 사용하게 만들지 아니면 새로운 프로젝트를 진행할지 고민이다. 와인 서비스의 핵심은 와인정보를 얼마나 자세히 많이 가지고 있느냐의 data 싸움이고 이건 내가 너무 불리하니 이걸 스스로 해결할지 아니면 다른 와인 서비스와 컨택하여 풀어나갈지 고민이 된다. 이게 어렵다면 새로운 프로젝트를 진행해야할 듯 하다. 이미 아이디어도 있고.

(유사 서비스를 탐색하다 와인그래프라는 한국 서비스를 발견했는데 정말 많은 와인정보를 가지고 있어서 놀랐다. 와인그래프와 티타임이라도 해볼까 생각중이다.)

0. 일상​

오랜만에 글을 쓴다. 글을 써야지 써야지 생각만하고 귀찮아서 미루게 되는데 쓰게 하는 습관을 들이던가 쓰게 만드는 나만의 규칙을 정해야겠다. 글을 쓰면서 나만의 회고도 되고 생각을 정리할 시간을 스스로에게 주는 것 같아서 도움이 된다.

와인이야기​

• 와인수업이 끝난지 꽤 되었다. 수업이 끝나고 와인을 마시거나 공부하는 시간을 따로 잡지 못했는데 시간이 지나면 잊혀질 것들이라 자주 와인을 접해보려는 노력을 하려한다. emart 가는 길에 한 병씩 사던가 일정이 없는데 코딩을 하고 싶지 않을 때 예전에 공부했던 책을 꺼내서 읽어보려 한다.

사이드 프로젝트​

• 와인 앱 만드는 사이드는 계속해서 하고 있다. 처음에 와인 데이터들을 firebase에 모두 업로드하고 조회했었는데 (firebase 하루 upload limit가 있어서 몇일에 걸쳐서 업로드 했다 ㅠ) firebase가 부분 문자열 검색이 되지 않아 결국 elasticsearch로 갈아탔다.
• elasticsearch를 docker로 띄우고 앞에 node server 띄우는 방식으로 해결했는데 내가 생각한 대로 잘 작동했다. flutter 코드랑 elasticsearch에 bulk로 데이터 넣을때 formatting하는 것까지 모두 chatGPT를 활용해서 진행했고 정말 빠르게 구현했다.
• 하지만 서버를 띄워야 한다는 부담이 존재하여 server를 사용하지 않고 앱안에 데이터를 저정하고 검색시 앱에 저장된 데이터에서 조회하는 식으로 변경해보려고 한다.

1. 폴더구조 세 번째(마지막) 논의​

회사에서 흩어진 프로젝트를 통합하면서 폴더구조를 정하고 있다. 두 번째 논의에서 대부분 다 정했으나 common에 대해 애매한 부분이 있어 내가 세 번째 논의를 발의했고 이 세번째 논의를 마지막으로 폴더구조에 대한 모든 팀원들의 생각을 맞추게 되었다. 앞으로 개발하다 보면 애매한 부분들이 생기고 다시 논의가 필요하겠지만 지금 상황에서 애매한 부분은 대부분 다 정리했다고 생각한다. 적어도 큰틀과 기준을 정했기에 추후에 생길 수 있는 애매한 부분도 많이 없어지지 않을까 생각한다.

이전 논의​

1. 첫 번째 논의
2. 두 번째 논의

아젠다​

아젠다: 두 번째 논의 후에도 찝찝함이 생기는데, 왜 찝찝함이 생길까? 찝찝함을 찾아서 없애보자!

1. common에 들어갈 수 있는 것​

코드를 액션과 계산으로 나누고 common에 들어가는건 계산만 넣어보자.

• 순수함수
• 외부 IO
• 변하지 않는 것

2. common 내 폴더 별 예시​

• util: 순수함수 (계산), web api
• service: bridge 한 번 wrapping 한 것
• style: animation
• hook: 비즈니스 로직이 포함되어 있지 않은 useBoolean, useIsTopEffect
• component: 당근 디자인시스템 공통 컴포넌트 (sprout), sprout에 아직 구현되어 있지 않은 컴포넌트
• svg, icon, css animation, calculate util, brand logo, image, etc…

3. 기타 질문

• production, beta, alpha, userid 같은 것 들도 비즈니스 로직이 아닌가?
  • 회사의 정책이고 자주 변하는게 아니기 때문에 common에 개념이 들어가도 되지 않을까?

common과 shared의 구분기준을 비즈니스 로직이냐 아니다도 좋지만 자주 변하는거 변하지 않는거로 생각했어요.

비즈니스 로직이 있으면 자주 변하기 때문에 shared에 들어가게 되고 common에 들어가는 것들은 자주 변하지 않는 것들이 들어가게 되는데 그런 관점에서 바라보면 production, beta, alpha는 거의 변하지 않는 것들이기 때문에 common에 들어가도 괜찮지 않을까 생각했어요.

결론​

• common에 들어가는건 side-effect가 없는 로직, 자주 변하지 않는 것들 (비즈니스 로직)
• shared에 들어가는건 액션, 자주 변하는 것들(비즈니스 로직)

0. 와인 마지막 수업​

오늘 와인 클래스 마지막 수업을 했다. 총 8회 2달간 매주 1회 수업을 들었는데 드디어 끝 ㅠㅠ 하지만 머릿속에 남는게 많이 없어서 심심할 때 다시 공부는 해야할 듯 하다. 마지막 수업은 맛있는 와인들을 먹었는데 스파클링 와인과 주정강화 와인이다.

세부 종류를 이야기 하자면, 스파클링 와인은 프로세코, 샴페인, 모스카토 디 아스티, 주정강화 와인은 피노 세리, 포트 와인이였다.

누구나 알 와인인 샴페인과 모스카토는 역시나 맛있었다. 특히 샴페인은 확실히 고급진 향과 맛이 났다. 향에서 2차 향이 듬뿍 났다. 수업들으면서 피노 쉐리 향이 독특하다고 해서 맛보고 싶었는데 나는 진짜 불호.. 맡기 힘든 향이 너무 강했고 먹었을 때 무맛인데 향이 덧 씐 느낌? 바디감이 가벼워서 물 같아서 이걸 술로 먹으면 최악이다 싶었다. 포트 와인은 요즘 인기가 많은데 와인 사러가면 포트와인 사러온 사람을 종종 만난다. 하지만 내 스타일은 아니였다. 술에서 시럽같은 단맛이 너무 나면서 알콜을 쎈... 노노~

샴페인 + 모스카토가 최강. 프로세코도 맛있었다. 음식없이 와인만 마실수도 있을 것 같았다. 산도가 딱 내가 좋아하는 정도로 익었었다.

1. 멘토링​

예전에 멘토링을 하고 이후로 안했었는데 오늘부터 다시 시작했다.

예전에 했었을 때는 돈은 많이 받는데 가르쳐주는게 많이 없다고 느껴서 죄책감이 들었다. 내가 더 노력하고 준비도 더 많이 하면 되겠지만 일을 하고 있는 입장에서 멘토링에 나의 노력과 시간과 열정을 그만큼 쏟기 쉽지 않았던 것 같다.

이번에 시작한 이유는 멘토링을 한 명만 하기도 하고(이전에는 두명이였다) 내가 가지고 있는 생각, 지식들을 이야기해주고 방향만 제대로 알려줘도 좋은 결과를 얻을 수 있을 것 같아서다.

대부분 취준생들이 고민을 가지고 불안감을 가지는게 기업들이 바라는 실력이 어느정도인지, 그리고 나의 실력은 어느정도인지 모르고 js, ts, react 공부는 했는데 이제 어떤걸 공부해야하는지 모르기 때문이라고 생각하는데 솔직히 이런건 취준생들이 가고자 하는 회사에 다니는 사람들에게 조언을 듣는것 만큼 좋은게 없다고 생각한다. (특히나 스타트업에서 구르다가 이직한 사람들에게 더 좋은 조언을 얻을 수 있다.)

0. 일상​

와인 자격증 시험을 쳤다.​

• 8월 26일(토) 11시 와인전문가 자격증 Level 2 시험을 쳤다.
• 전날 휴가를 쓰고 하루종일 공부하고 밤을 새서 쳤는데 그렇게 잘본것 같지는 않았다. 책을 모두 정리하고 문제에 나올만한 것들 다시 추리고 암기했는데도 어려웠다. ㅠㅠ 외국어로된 지역명이다 보니 머릿속에 저장이 잘 안된다. 포도 품종 20여개에 품종별 특징(향, 맛), 원산지만 외우는데도 힘들었다. 합격을 할 것 같은데 그렇게 좋은 점수로 합격할 것 같지는 않다 ㅠㅠ 미리미리 공부했어야 하는데..

사이드 프로젝트​

• 와인앱은 거의 홀드상태
• 스마트팜은 오픈채팅방에서 정보를 수집하고 있는 중이다. 하지만 국내 정보로는 한계가 너무 있어서 해외에서 정보를 수집해야할 것 같다. 오픈채팅방의 정보는 대부분 스마트팜 기기를 추천해주고 받기를 원하는 것들이다.

자기계발​

• 요즘 자기계발 진짜 안한다. 반성하자...
• 운동, 책, 개발, 일기, 등등.. 다시 여행을 한 번 가야하나

1. "아주 작은 습관의 힘" 읽고​

0. 일상​

• 오펜하이머 영화를 봤는데 진짜 재미있었다. 오펜하이머라는 사람의 전기를 다루는 영화였고 호불호가 있다고 들었는데 전쟁 영화를 생각하고 온 사람들은 실망할 영화였다. 극중 인물들의 연기가 압도적이였다. 인물의 고뇌나 심경을 강조하고 싶을 때 bgm으로 관중들까지 같은 감정을 느끼도록 만드는 연출은 진짜 압도적이였다.
• 요즘 개발 공부를 안하고 있다. geek-news나 github에 올라오는 trend를 살펴보고 좋은 문화, 문서화, 협업방법들, 새로운 서비스나 내가 속한 도메인의 동향들을 읽는데 더 흥미가 있다. 높은 생산성과 일을 잘하는데는 개발관련 지식은 지금 내가 가지고 있는 것 만으로도 충분 혹은 기존에 공부한 내용만 완벽히 이해하는 정도로도 충분하다고 생각했고 새로운 기술을 도입해야할 때 해당 기술을 공부하면 될꺼라 생각한다. 팀에 바로 도움이 되고 내가 속한 팀 그리고 회사에 도움이 되는건 협업, 문화, 문서화 그리고 내가 개발하고 있는 서비스에 대한 폭넓은 지식과 업계의 동향들을 익혀 전파하는게 훨씬 도움이 된다고 생각했기 때문이다. 기존의 틀을 부술 새로운 아이디어를 내면 더욱 좋을것이고 말이다.

1. "아주 작은 습관의 힘" 읽고​

0. 근황​

1. 일기쓰는 습관

• 8월 초에 글을 거의 쓰지 못했는데 반성하고 있다. 아주 적은 글이라도 조금씩 작성하면서 습관을 들여야 했는데 그것조차 쉽지 않았다. 당연히 게으름 때문.. 아직 일기를 쓴다는게 익숙치 않은 것 같다. 마치 운동을 하는 것 처럼. 최근 습관에 대한 책을 읽고 있는데 이를 기반으로 일기 쓰는 습관을 가지도록 노력해 볼 생각이다. 좋은 습관을 기르고 싶은데 자주 실패한다면, 습관의 힘을 잘 모르겠다 라고 생각하는 사람이라면 "아주 작은 습관의 힘" 매우 강추!

2. 휴식

• 휴식이 너무 필요한 것 같아서 금, 월 휴가를 신청하고 3박 4일 괌으로 휴가를 다녀왔다. 가서 스노쿨링과 스쿠버다이빙을 배웠는데 너무 재미있었다. 다음 번 여행갈 때 스노쿨링 할 수 있는지 를 우선적으로 볼 것 같기도 하다. 추가로 회사에서 프리다이빙 하는 그룹이 있어서 해당 그룹에 들어가 취미로 발전까지 시켜볼까 생각중.. 우선 와인 자격증부터 따고!

1. 폴더구조 두 번째 논의​

회사에서 폴더구조를 논의하고 있다고 이전에 적은 적이 있는데 이후 두 번째 논의를 했다. (논의를 한지 꽤 되었는데 정리를 최근에 했다.) 해당 논의를 하고 난 결론을 간단히 적어보려고 한다. 논의를 진행 할 때 네이버 클로바로 전부 녹음을 했고 논의가 끝난 후 모두 옮겨젹고 요약을 했다. 글을 적으면서 알게 된건 모두 생각이 다르다는 것 (물론 같은 생각을 한 것들도 많았다). 이렇게 논의를 여러번 해나가면서 좋은 결과를 만들길 기대한다.

1. 이랬으면 좋겠어​

팀원 A​

• 폴더구조에 대한 논의를 통일 시키지 않으면 앞으로 계속 혼란이 생길 것 같다.
• 한 사람이 다른 생각을 가지고 있으면 원레포로 작업하는게 오히려 고통이 더 따를 것 같다.
• 나중에 구분이 애매해지는게 별로
• 유지 보수성 측면에서 앞으로 의논을 최대한 덜 하는 방향으로 이야기 해보고 싶다.

[의견]

• 큰 단위의 통일을 시켜야 하는데 이걸 초반에 잡는게 현실적으로 힘들 것 같고 발생할 때마다 논의를 해야 한다.

팀원 B​

• 나중에 혼란이 생기는게 별로다.
• common과 shared의 기준이 애매하지 않았으면 좋겠다.

[의견]

• 사람마다 다르게 생길만한 요소가 있는것들은 정해버리면 좋을 것 같다.

팀원 C​

• common과 shared를 비즈니스 로직의 포함여부로 구분하고 애매한게 생기면 그때그때 이야기 해보자. 그게 많이 생기지는 않을 것 같다.

팀원 D​

• 혼란스럽고 헷갈리는게 없었으면 좋겠다. (지금도 앞으로도)

[의견]

• 사람마다 생각이 다른 부분들이 존재하기에 이것들을 매번 논의하고 합의를 보기 보다는 그냥 이렇게 하자!로 정해버리면 좋을 것 같다.

2. 중간 정리​

모두가 원하는거​

• 모두가 생각이 일치하는, 동의하는 구조를 만들어야함.
• 기준을 애매하게 정해버리면 안됨.
• 앞으로 논의를 최대한 덜 하는 방향이 되어야함.
  • 애매하게 정하면 혼란이 생겨서 매번 논의를 하고 고민을 하고 불필요한 논의만 많아짐

생각이 조금 다른거​

• 팀원 B, D: 애매한게 아예 없어져 버리면 좋겠다. 그게 지금 당장 결정되었으면 좋겠다. (지금 명확한 기준을 정해버리길 원함)
  • 그래서 "애매한건 그냥 이렇게 해버리자! 정해버리면 애매한게 사라지고, 매번 고민하거나 논의할 필요가 없어지지 않을까?" 로 의견을 냄
  • 애매한게 많이 생길 것을 우려함. 위에서 정의한 것들을 바탕으로는 논의를 많이 하더라도 애매한게 줄어들지 않을 것으로 생각함.
• 팀원 A, C: 애매한게 없어져야 하는건 동의한다. 지금 애매한걸 다 추려낼 수는 없을 것 같다. 애매한게 생각보다 많지 않을 것 같다. 애매한게 생기면 그 때 깊이 논의해보면 좋을 것 같다.
  • 팀원 A: 애매한게 많이 있을 수는 있겠지만 점점 애매한게 줄어들 것이다.
  • 팀원 C: 서로 생각하는 부분이 비슷할 꺼라고 생각한다. 그래서 애매한게 많이 없을 것이고 생기면 그 때 깊이 논의하면 점점 애매한게 줄어들 것이다.

3. shared, common 기준​

1) shared​

• page 내부에 있는 것들 중에서 다른 도메인에서도 사용되면 shared로 옮긴다.
• 여러 도메인에서 사용되는 것들 (component, util, hook, etc)
• 비즈니스 로직이 들어간 것

service​

• 외부에 의존적인 것들을 모아둔 것.
• 외부 라이브러리를 한 번 wrapping 한 것

2) common​

• 도메인, 비즈니스 로직들이 없는 것

4. 결론​

• 매번 고민하지 않도록 shared에 기본적으로 만들고 shared에서 common으로 파일을 옮기거나 추상화 시킬 때 깊게 논의하고 고민해보자. 그러면 매번 고민해야할 부분이 많이 없어질 것이다.

여기까지가 회의 내용을 정리한 것 이고 이후 내 생각을 적어보자면

• common과 shared를 구분하는 가장 큰 기준이 비즈니스 로직이다. 비즈니스 로직이 없다면 무조껀 common에 넣으면 되는 건가? 명확한 기준이 아니라 느낌적으로 common에 넣을지 안넣을지 정해버리는 일도 생길 수 있지 않을까?
  • -> 비즈니스 로직 말고 다른 기준은 필요 없는걸까?
• 저번 회의 때 비즈니스 로직을 가지고도 생각이 달랐었다.
  • -> 비즈니스 로직에 대한 정의를 다 같이 내려봐도 좋지 않을까?
• common과 shared에 대한 기준을 더욱 명확히 정하지 않는다면 (누구나 동의할만한, 누구나 쉽게 구분할 수 있도록) 아무리 논의를 많이 하더라도 기준은 애매모호하게 계속 남을 것 같다.
• 음.. common과 shared를 구분하는 기준을 비즈니스 로직으로 잡은게 문제였던 것 같다. common과 shared를 구분하는건 자주 변하는것 vs 자주 변하지 않는것 으로 삼아야 한다. 비즈니스 로직이 common에 들어가면 안되는 이유는 비즈니스 로직이 포함된 것들은 자주 변하기 때문이다.

2. 문서화: 팀원 모두의 생산성을 끌어올리는 방법​

https://news.hada.io/topic?id=10222

문서화의 중요성에 대한 글을 읽었는데 매우 공감가는 말들이라 들고왔다.

문서는 지식을 전달하는 좋은 방법

• 개발자가 익숙하지 않은 특정작업을 수행하는 경우에 특히 중요함.
• 문서가 부족하면, 개발자가 작업 수행 방법을 스스로 연구해야 하고, 실수를 하고 작업을 다시 수행하거나, 다른 팀이 질문에 답변할때까지 기다려야 하므로 작업 속도가 느려질 수 있음
• 이는 1시간 짜리 작업을 금방 2일짜리 작업으로 만들 수 있음
• 100명의 개발자가 이 일을 해야한다면, 문서 한페이지 누락으로 인한 비용은 개발자 한명의 연간 급여에 해당할 수 있음

다른 모든 조건이 같다면, 관련 지식이 많은 개발자가 더 생산적임

• 코드가 어떻게 동작하는지 알기 때문에 코드를 깊게 들여다 볼 필요가 없고
• 도구를 사용하는 방법을 알고, 피해야하는 함정을 알고 있음

다른 팀들(네이티브 개발자, FE 코어 개발자)과의 컴이 많이 필요한 것들은 문서화를 하지 않는다면 이후 다른 개발자들이 시간과 노력을 매우 많이 사용하게 될 것이다. 기존에 했던 논의, 버그, 검색등을 되풀이하는건 정말로 없어져야 한다. 문서화만 잘해도 엄청나게 많은 노력, 시간을 아낄 수 있지 않을까?

물론 스팩에 대한 문서화는 호불호가 있다. 매번 sync를 맞춰줘야하고 관리해줘야 하기에 불필요한 노동이기에 코드에 스팩을 녹이면 된다고 생각하는 사람도 있다.

물론 동의하는 부분도 있다. 하지만 그건 모든 팀원들이 해당 코드에 익숙할 때의 이야기다. 만약 다른 개발자(백엔드 개발자, 다른 프로젝트를 진행하며 코딩스타일이 완전히 다른 FE 개발자)의 경우에는 이해가 힘들 것이다. 코드에 히스토리를 남기게 되면 본인의 스타일로 만들 것이다. 하지만 문서는 누구나 알기 쉽게 쓰여야 하기 때문에 이는 안하느리만 못하다. 문서화를 굳이 할 필요가 없을만한 간단한 맥락, 특정 기능에 대한 히스토리는 주석으로 코멘트를 남기거나 해당 논의가 이루어졌던 스레드를 남겨보자.

하지만 특정 기능을 개발하면서 겪었던 트러블 슈팅이나 앱의 큰 기능에 대한 것들은 문서로 남겨야 한다. 게속 명세가 변한다면 sync를 맞춰야 하는 수고도 당연히 필요하다. 귀찮다는 이유로 이를 하지 않는다면 문제가 생겼을 때 항상 본인이 해결해야한다. 남들이 이 문제를 해결해주길 기대해서는 안된다. 해당 히스토리는 본인의 머릿속에 있고 다른 사람들이 이를 해결하기 위해서는 엄청나게 많은 시간이 소모될 것이며 본질적인 문제를 해결하는게 아닌 동작하도록 만 코드를 짤 것이 뻔하기 때문이다.

0. 근황​

1. 와인앱

• 와인앱은 지금 거의 중단상태다. 다른 우선순위 높은 것들이 너무 많이 나오고 있기 때문이다. 하지만 끝까지 만들기는 할꺼다! 무조껀!

2. 와인 자격증

• 와인 자격증은 8월 26일(토)에 신청했다. 같이 공부하는 사람들이 테이스팅을 너무 잘해서 주눅들기는 한데 Level 2 시험은 이론 공부라.. 나는 이론공부 열심히 해서 자격증은 가장 높은 등급으로 따고 싶다.
• 테이스팅 자신감 붙으면 Level 3도 도전 해봐야지 💪

1. vite bundle analyze ci 만들기​

rollup-plugin-analyzer 플러그인이 있는데 진짜 유용하다. 실수로 import 한 패키지가 있는지 확인도 유용하고 (dev 환경에만 들어가야 하는데 production에 포함되는지 확인도 가능) lodash 같이 tree-shacking 안되는 라이블러리가 포함되었는지도 확인이 가능하다.

하지만 vite-plugin-legacy과 같이 사용했을 때 vite-plugin-legacy 이후에 플러그인을 넣었을 때 작동하지 않는 문제가 있다. 파보지는 않았는데 legacy bundling된 이후에 if 문으로 다 건너 뛰어 버리는 것 같다. 그래서 vite-plugin-analyzer 이후에 vite-plugin-legacy가 돌도록 선언해줘야 한다.

return {
  plugins: [
    analyze({
      limit: 10,
      skipFormatted: false,
      summaryOnly: true,
      writeTo: (analyzeString) => {
        fs.writeFileSync('bundle-analyze.txt', analyzeString);
      },
    }),
    legacy(),
  ]
}

나는 결과를 pr comment로 받아보고 싶기 때문에 번들링 결과를 파일에 저장하고, 이 파일을 읽어 pr-comment로 달아줘야 한다.

파일을 읽고 인코딩한 후 pr-comment actions의 도움을 받아 코멘트에 값을 추가하면 된다~!!

- name: Read analyze report
  id: read-analyze-report
  run: |
    report=$(cat ./bundle-analyze.txt | sed '1,2d')
    report_encoded=$(echo "${report//$'\n'/%0A}")
    echo "::set-output name=report::$report_encoded"

- name: PR comment
  uses: thollander/actions-comment-pull-request@v2
  with:
    message: |
      <h2> :pencil: Bundle Analyze Report</h2>
      <strong>새로운 패키지를 추가했다면 꼭 확인해보세요 🙄 </strong><br/>
      번들사이즈가 큰 상위 10개 파일을 확인해볼 수 있어요.
      <br/>
      <br/>
      <details><summary><strong>분석결과 보기</strong></summary>

      ${{ steps.read-analyze-report.outputs.report }}

      </details>
    reactions: eyes, rocket
    comment_tag: execution
    mode: upsert

tada~ 🎉

2. Git commit 내역에서 committer 변경하기​

github 회사 계정과 개인 계정을 두개 관리하고 있어서 committer가 잘 못 올라간 적이 많았다. author는 바꾸기 쉬웠는데 committer는 바꾸기 어려웠는데 이번에 방법을 찾아서 기록한다.

git filter-branch --env-filter '
WRONG_EMAIL="변경전 이메일"
NEW_NAME="새로운 이름"
NEW_EMAIL="새로운 이메일"

if [ "$GIT_COMMITTER_EMAIL" = "$WRONG_EMAIL" ]
then
    export GIT_COMMITTER_NAME="$NEW_NAME"
    export GIT_COMMITTER_EMAIL="$NEW_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$WRONG_EMAIL" ]
then
    export GIT_AUTHOR_NAME="$NEW_NAME"
    export GIT_AUTHOR_EMAIL="$NEW_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags

참고: https://velog.io/@anjaekk/Git-push%ED%96%88%EB%8D%98-%EB%AA%A8%EB%93%A0-commit-author%EC%99%80-committer%EB%B3%80%EA%B2%BD

0. 일상​

• 당근에 온지 1주년이 되었다. 시간 엄청 빠르다. 1주년 회고도 써야겠다.
• "아주 작은 습관의 힘" 책을 읽고 있는데 그렇게 많이 도움이 되지는 않는다. 하지만 끝까지 읽어보려고 노력중
• 오늘 오후에 문화의 날 활동으로 레드와인 테이스팅을 한다. 7시에 와인수업도 있어서 오늘은 와인데이

1. NextJs Dockerfile​

인터넷에 올라오는 것들은 node_modules 사용하는게 대부분이라 yarn berry 사용하는 버전으로 만든거 기록용으로 저장. 누군가는 쓰겠지...

nextConfig의 output에 "standalone" 설정하는거 잊지말자

standalone에 대한 설명은 여기서: https://nextjs.org/docs/pages/api-reference/next-config-js/output#automatically-copying-traced-files

참고: https://github.com/vercel/next.js/blob/canary/examples/with-docker/Dockerfile

FROM node:18-alpine AS base

# Install dependencies only when needed
FROM base AS deps

RUN apk add --no-cache libc6-compat
WORKDIR /app

# Install dependencies based on the preferred package manager
COPY package.json ./
COPY yarn.lock ./
COPY .pnp.cjs ./
COPY .pnp.loader.mjs ./
COPY .yarnrc.yml ./
COPY .yarn ./.yarn
RUN yarn install --immutable

# Rebuild the source code only when needed
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/.yarn ./.yarn
COPY --from=deps /app/.pnp.cjs ./pnp.cjs
COPY . .

# Next.js collects completely anonymous telemetry data about general usage.
# Learn more here: https://nextjs.org/telemetry
# Uncomment the following line in case you want to disable telemetry during the build.
# ENV NEXT_TELEMETRY_DISABLED 1

RUN yarn build

# Production image, copy all the files and run next
FROM base AS runner
WORKDIR /app

ENV NODE_ENV production

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder /app/public ./public

# Automatically leverage output traces to reduce image size
# https://nextjs.org/docs/advanced-features/output-file-tracing
COPY --from=builder --chown=nextjs:nodejs /app/.pnp.cjs ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

RUN rm -rf ./.yarn/cache
COPY --from=builder --chown=nextjs:nodejs /app/.yarn ./.yarn/

USER nextjs

EXPOSE 3000

ENV PORT 3000

# CMD ["node", "server.js"]
CMD ["node", "-r", "./.pnp.cjs", "server.js"]

2. Jest Coverage Comment​

ci 단계에서 unit test coverage 측정할 때 codecov actions를 사용하는 경우가 많은데 그렇게 되면 내부 코드가 codecov 로 전송된다는 매우 큰 리스크가 있다. 이에 괜찮은 새로운 actions를 찾아 공유한다.

바로 요것이다. https://github.com/marketplace/actions/jest-coverage-comment

comment도 이쁘게 잘 달아준다.

step 1) 필요 패키지를 설치한다.​

yarn add -D jest-junit

step 2) ci용 jest.config 파일을 만든다.​

ci 스크립트에서 jest cli 를 활용하는 방법도 있지만 이게 훨씬 깔끔하다.

import type { Config } from 'jest';

import defaultConfig from './jest.config';

const config: Config = {
  ...defaultConfig,
  coverageReporters: ['json-summary', 'text'],
  reporters: [
    'default',
    [
      'jest-junit',
      {
        outputDirectory: './coverage',
      },
    ],
  ],
};

export default config;

name: Unit Test Coverage

on: [pull_request]

env:
  CACHED_DEPENDENCY_PATHS: ${{ github.workspace }}/.yarn/unplugged
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  DEFAULT_NODE_VERSION: "16.16.0"

jobs:
  coverage:
    runs-on: [self-hosted]
    steps:
      - uses: actions/checkout@v3

      - name: Set up Node
        uses: actions/setup-node@v2
        with:
          node-version: ${{ env.DEFAULT_NODE_VERSION }}

      - name: Install dependencies
        run: yarn install --immutable

      - name: Check Unit Test Coverage
        run: |
          mkdir -p coverage
          yarn test:unit --coverage --config=jest.ci-config.ts | tee ./coverage/coverage.txt && exit ${PIPESTATUS[0]}

      - name: Jest Coverage Comment
        id: coverageComment
        uses: MishaKav/jest-coverage-comment@main
        with:
          coverage-summary-path: ./coverage/coverage-summary.json
          title: Test Coverage
          summary-title: Coverage Report
          badge-title: Coverage
          hide-comment: false
          create-new-comment: false
          hide-summary: false
          junitxml-title: Test Suites Summary
          junitxml-path: ./coverage/junit.xml
          coverage-title: Coverage
          coverage-path: ./coverage/coverage.txt

만약 가져다 사용하는 사람이 있다면 runs-on은 아마 바꿔야할 듯하다. 나는 github enterprise로 self-host를 띄우기에 저렇게 설정하였다.

Check Unit Test Coverage step을 보면 mkdir -p coverage 는 tee command가 폴더가 없으면 파일을 만들지않기에 미리 만들어주는 것이다. tee ./coverage/coverage.txt 는 coverage script 돌고 나오는 마지막 summary table을 coverage.txt 파일에 입력시키는 명령어다.

3. 아주 작은 습관의 힘​

4. 와인 앱​

크롤링한 데이터를 전부 firestore에 업로드 하였다. firestore 사용량 제한이 있어서 한 번에 모두 업로드는 못하고 3~4일에 거쳐서 모두 업로드 했다. 총 28,523 개로 vivino, wine21 collection을 따로 해서 저장했다. 대략 55000 write를 했다.

참고로 firestore 의 경우 쓰기 2만/day, 읽기 5만/day, 삭제 2/day 까지 무료다. blaze 플랜으로 업그레이드하면 무료 사용량 초과한 만큼 비용이 발생한다.

이제 검색기능을 만들 차례다!

0. 일상​

• "타이탄의 도구들" 책은 거의 다읽었고 "아주 작은 습관의 힘" 책을 사서 보고있는 중이다. 이건 e 북으로 사서 리브2로 보는중. "타이탄의 도구들" 책은 또 한 번 읽고 싶다. 인생에 대한 생각과 행동을 많이 바꿔준 책이다.
• 아! 저번 일기 때 말한 테스트관련된 건 동료분들께 공유했고 원레포 통합되면 테스트를 적극 도입하기로 했다. 얏호~ 🥳

1. GitHub Enterprise로 옮기고 Actions 트러블 슈팅​

좋은점​

• public github보다 runner 성능이 좋아 엄청 빠르다.
• 인스턴스에 한 번 설치되면 인스턴스 날라가지 않는 이상 재설치가 필요없어져서 속도가 빠르다.
  • playwright는 테스트 돌리기전 browser를 설치해야하는데 public github에서는 크로미움 하나 설치하는데 30s 걸리는데 GHES에서는 4s 걸린다.
• 전체적인 속도는 1m 30s ~ 2m 30s -> 30s 로 줄어들었다.

안좋은 점​

• runner 개수가 한정되어 있어 여러 프로젝트가 actions를 동시에 돌리면 queue에서 오래 pending되는 경우가 많다.
• os에 영향을 받는 actions이 있다.
  • 사용중인 runner의 os가 Amazon Linux 2 인데 playwright 설치시 문제가 생겼다. BEWARE: your OS is not officially supported by Playwright; installing dependencies for Ubuntu as a fallback. ubuntu가 설치된 runner를 추가하여 문제를 해결했다.
• 새로운 actions를 사용하려면 인프라팀에 요청해서 actions를 동기화해주는 작업이 필요하다.

트러블 슈팅한 거​

• playwright 테스트가 예전에는 동작했는데 갑자기 실패하는 경우가 생겼다. 그런데 테스트나 설정의 문제는 아니였고 runner의 문제였는데(예전에 제대로 동작한 action을 재수행해도 에러가 났다) 인프라팀과 컴을 하면 문제를 파악할 수 있겠지만 시간이 걸려 docker를 도입하는 걸로 문제를 해결했다. 시간은 30s 에서 1m 로 늘어났지만 docker를 통해 안정적인 환경을 구축한 것에 만족한다.
• github actions 에서 docker 설치해서 돌리는게 매우 쉽다. 요렇게만 해주면 된다.

    jobs:
      test:
        container:
          image: mcr.microsoft.com/playwright:v1.32.1-jammy
  
• github action docker container 내에서는 github cache를 사용할 수 없다. cache가 저장되어 있어도 cache hit이 안된다. -> caching을 docker container 환경과 동일하게 맞추고 하니 된다.
• github action runner 내에서 직접 (chromium만 설치)browser를 설치하면 38s 걸리는데 docker install을 하면 모든 브라우저가 설치된 docker image인데도 47s 걸린다.

2. 타이탄의 도구들​

타이탄의 도구들 완독 🥳🥳🥳

3. VS Code 자동 import​

타입스크립트에는 파일에 대한 접근제어가 불가능하다. spring 같은걸 보면 상단에 package.* 같은걸 추가해서 패키지별 폴더별 접근이 가능하다. 해당 파일을 정말 추상화를 한거라 일부 파일에서만 가져다 사용하게 제한하고 싶은데 그게 안되어 여러 사람들이 무분별하게 가져다 사용할 수도 있고 여러 파일들이 같은 이름의 함수명을 가지고 있을 때 실수할 수도 있다.

완벽한 해결책은 아니지만 어느정도 해결할 수 있는 방법을 찾았다.

vscode setting을 통해 autoImport를 막을 수는 있네요 https://github.com/microsoft/vscode/pull/153160

이를 구현하기 위한 TS Server option pr: https://github.com/microsoft/TypeScript/pull/49578

"typescript.preferences.autoImportFileExcludePatterns": [
  "__mocks__"
]

셋팅하지 않았을 때​

__mocks__ autoImportExclude 했을 때​

0. 일상​

요즘 여유가 없다. 인심은 곳간에서 나온다는 말이 진짜 맞다. 내가 항상 스트레스 받고 있으니 누군가를 이해하기도 이해하며 말하기도 힘들다. 너무 에너지가 소모되는 것 같다. 휴가를 쓰면서 리프레시를 좀 해야할 것 같다.

1. WSET 와인수업​

어제 첫 수업을 들었다. 국비지원은 출결체크가 너무 빡쎄다 ㅠㅠ 앱도 진짜 안좋아서 비콘으로 출결하려면 맨날 인증서 로그인해야한다 ㅠㅠ (출석전, 출석후) 그냥 카드로 출결체크하는게 젤 마음편한 것 같다.

2. 여름휴가나 다녀와야지~​

이전 일기에서 테스트에 대해 이야기 한적이 있는데 오늘 지하철을 타고 출근하다가 다시 고민에 빠졌다. 나는 테스트를 좋아하고 작성해야하는 중요성을 매우 잘 인지하고 있다. 그런데 요즘 내가 조금 바뀐 것 같다는 느낌이 들었다. 팀원들이 아무도 테스트코드를 작성하지 않으니 어느순간 나도 테스트코드 작성 안하는 것에 대해서 이질감을 안느끼기 시작한 것이다. 예전에는 테스트코드 작성안하면 매우 찝찝해 했고 두려웠는데 그게 없어지고 있는 거였다. 내가 지난 1년간 공들여서 들인 습관이 없어지고 있었다.

클린코더 라던가 소프트웨어 공학 책을 보면 항상 우리는 최고의 소프트웨어 품질을 위해 맞서 싸워야한다고 적혀있다. 하지만 현실은 그와 다르다면서 팀원들과 타협했고 이후에 스스로와도 타협을 해버렸다. 이러면 안되는데 이러면 진짜 안되는데 어떤게 옳은건지 알지만 타협을 한 번 해버리니 한도끝도 없이 늘어져 버렸다.

누군가를 설득시키기에는 너무 큰 노력이 필요하고 나도 매우 많은 에너지가 필요하다. 하지만 지금은 그럴 에너지가 없기에 재충전의 시간이 필요한 것 같다. 여름 휴가나 다녀와야지~

0. 일상​

• 써야지 하다가 안써벼렸다. 일기에 적는건 출퇴근하다가 일하다 쉬다가 머릿속에서 생각한 것들인데 이걸 타이핑하기가 너무 귀찮다 ㅋㅋ 생각하면 알아서 타이핑되면 좋겠다 ㅋㅋ

1. 와인앱 근황 mlkit​

• 와인앱은 mlkit을 이용해서 와인 상품명을 읽어들이는 작업을 진행중이다. 생각보다 인식률이 좋아서 나름 만족한다.

• 카메라 layout을 대폭 축소시키고 인식시킨 글자를 클릭해서 검색하도록만 하면 1차 mvp는 끝난다! 할께 많네..

2. 챕터 일감을 만들 때 어떤걸 고려해야 하나?​

챕터 일에는 3종류가 있다.

1. 지금 당장 중요해서 해야하는 일
2. 나중에 중요해서 토대를 닦는 일 혹은 나중에 크게 도움될 작은 변화들
3. 내가 하고싶은 일

당연하겠지만 1 > 2 > 3 순서로 중요하다. 특히 3은 팀원들과 논의도 해야한다. 내가 하고싶은 일이 정말로 도움이 되는지 장기적으로 바라봐야하며 현재의 문제를 해결할 수 있는 일인지도 검토해야 한다. 단순 욕구로 일을 해서는 안되고 객관적으로 바라보고 평가해야한다. 실무에서 개발하는 코드는 테스트배드가 아니다.

3. 팀에 변화를 일으키는건 영향이 크다. 우리는 ROI를 고려해야 한다.​

• 당근에 와서 내가 변화를 일으키려고 노력했던게 여러개 있다. 몇 개는 받아들여졌지만 (내가 담당하는 프로젝트 한정) 그렇지 못한것들도 많다. 가장 큰게 유닛테스트인데 여기에 대해 이야기 해보고자 한다. 프로젝트에 테스트를 도입하는건 매우 큰 변화다. 팀원들이 테스트에 대한 중요성은 알지만 경험이 없기에 보통 이런 변화를 별로 달가워하지 않는다. 왜냐하면 "우리 테스트코드를 짜기로 하자!" 정하게 되면 단순히 그렇게 따르는 것 보다 더 큰 노력이 필요하기 때문이다. 여기서 노력은 테스트에 대한 경험이 없기 때문에 따로 시간을 내어 공부하는 노력, 코드를 수정했는데 테스트 코드가 깨졌고 이걸 수정하기 위해 트러블슈팅하기 위한 노력등이다. "우리 디렉터리구조를 이렇게 가져가자!" 를 정하는 것과는 결이 다르다. 들이는 노력이 다르다. 그냥 그렇게 하면되는게 아니라 개인의 시간과 노력이 많이 들어가기 때문이다.

어쩌면 지금까지 테스트코드 없이 개발을 해왔고 거기에 대해 큰 문제가 없었기 때문에 중요성을 덜 느낄 수도 있다. 문제를 방지하기 보다는 빠르게 모니터링해서 고치는게 더 맞다고 생각하기 때문일 수도 있다. 하지만 테스트코드를 짜는게 그게 다는 아니라는걸 나는 알고 있어도 팀원들을 설득시키기 위해서는 너무나 많은 노력이 필요하다. 한 번에 설득시킬 수는 절대 없고 오랜기간 아주 오랜기간 동안 내가 테스트코드 짬으로써 좋은 경험을 자연스레 심겨줘야 한다.

주제가 잠깐 셌는데 테스트가 중요하다고 해서 그걸 밀어붙히는건 좋지 않다. 팀원이 말해준 ROI라는건 정말 중요하기 때문이다. 지금 테스트를 작성하지 못하는 팀원들이 테스트를 짠다면 ROI는 최악일 테니 말이다. 물론 시간이 지날수록 ROI가 좋아질테고 시도조차 하지 않는다면 절대로 테스트는 작성하지 않을테니 아예 작성하지 말자는 아니다. 조금씩 유닛테스트 부터 사이트이펙트가 없는 함수들 부터 조금씩 쌓아 나가야 한다. 테스트가 중요하고 좋다는걸 자연스럽게 느끼도록 해야한다.

아무튼.. 이런데 요즘 고민이 많다.

누군가는 이렇게 말할 수 있다. FE는 요구사항도 빨리 바뀌니 테스트코드를 짜지 않는게 좋을 것 같다. 빠르게 배포할 수 있으니 테스트코드를 짜는 것 보다 에러를 모니터링하고 빠르게 버그 fix하여 배포하는게 낫다. 솔직히 이렇게 말하는 사람들의 코드가 좋은걸 본적이 없다. 요구사항이 자주 바뀌는게 아닌 유틸함수도 테스트코드를 짜지 않으며 버그가 날까봐 개발을 많이 안하려 하거나 버그 fix는 코드를 개선하고 문제를 완벽히 고치는게 아니라 땜빵코드로 메꾼다.

0. 일상​

요즘 의욕이 너무 없다. 나태해진 걸까? 백엔드 공부, 와인 앱 만들기, FE 공부 등등 주말에 진짜 아무것도 안한다. ㅠㅠ 지금까지는 나의 성장과 미래에 대한 두려움이 있어서 주말에 공부를 안하면 큰일이 나는 줄 알았다. 강박도 있어서 어딜가든 가방에 노트북을 넣어다녔다. 그런데 요즘 나의 목표가 바뀐 것 같다는 생각이 든다. 뛰어난 개발자, 나의 커리어가 목표가 된게 아니라 세상을 바꾸고 싶다. 그래서 기술공부에 흥미가 떨어진 것 같다. "타이탄의 도구들"의 영향인걸까?

아이템도 있고 주제도 있는데 어떻게 시작할지 모르겠다.

1. 당근의 방식​

당근에 이제 1년정도 다니면서 당근의 방식을 나름 분석해보았다. 당근에서는 작은 실험들을 많이 한다. (토스에 비하면 적겠지만 팀의 규모나 리소스적인 측면에서 많이 한다고 생각한다.) 하지만 큰 변화를 주는 실험이나 기능들을 도입하지는 않는데 돌다리를 두드려보고 건너는 느낌이랄까? 아무래도 사용하는 유저수가 많다보니 작은 변화가 크게 받아들여 질까봐 조심히 하는 것 같다. 그래서 tf 생겼다가 없어지는 경우도 많고 신규 채용도 매우 보수적이다. it겨울도 있고해서 결과적으로 좋은 선택이였고 나도 이런 선택들이 좋아보인다. 서비스가 정체성을 잃어버리는 순간 유저들은 떠난다. 당근은 그 정체성을 잃어버리지 않기 위해 엄청 노력하고 약간은 보수적이게 된 것 같다. 그리고 새로운 기능들은 조금씩 작게 시도해보고 없애고 시도해보고 없애고 하는데 이러한 접근도 좋은 것 같다. 그래서 폭발적인 성장보다는 꾸준한 성장과 미래를 위한 토대를 탄탄하게 만드는 느낌이랄까? 처음에는 나도 별로라고 생각했는데 점점 이게 맞는 방식인 것 같다. 최근 그립랩스, 뱅크셀러드, liner 같은 서비스를 써보고 유튜브도 보고 했는데 기본에 충실하지 않은 서비스는 항상 안좋은 결과를 맞이한다고 느꼈기 때문이다.

liner 서비스를 pro level을 무료로 1주일 써봤는데 앱에 버그가 너무 많아서 삭제했다. 기존 메모나 하이라이팅을 저버리고 chat gpt 붙히면서 이상한 기능들을 만들고 버그가 엄청 생겼는데 (chrome extension 설치하면 인터넷 속도가 엄청 느려진다.) 기본적인 본인의 서비스를 제대로 관리안하는 느낌이였다.

2. 시작에 대한 두려움​

혹시 다음 영상을 보지 않았다면 꼭 봤으면 좋겠다.

• https://www.youtube.com/watch?v=dv7powwD-tQ
• https://www.youtube.com/watch?v=dqQ3E1eu2gY

"타이탄의 도구들"에서 봤던 내용들이 주마등처럼 스쳐지나갔다. 내가 옳다고 생각하는 일들을 절대로 포기하지 마라. 왜 나는 시작에 대해 항상 두려워 할까? 내가 옳다고 생각하는 일에 대해 혼자하기 두려워 주변사람들을 끌어들이려고 할까? 내가 옳다고 생각하는 일에 공감은 할 뿐 아무도 해결하려 노력하지 않는다. 나는 혼자서 시작할 용기가 필요하다. 세상을 바꾸거나 미래에 영향을 미치는 일들을 할 때는 혼자서 할 용기가 필요하다. 지금 나는 그 용기가 필요한 것 같다.

내가 옳다고 생각하지만 주변사람들이 불가능하다고 말하는 일들을 하는데 모든 시간과 노력을 미친듯이 쏟아부어야 한다.

오랜만에 일기를 쓴다.

1. VS Code (필수 단축키) 파일 생성, 폴더 생성 단축키​

• cmd+shift+p > Open Keyboard Shortcuts (JSON)
• 밑에 json 붙여넣기 하면 된다.

[
  {
    "key": "cmd+n",
    "command": "explorer.newFile",
    "when": "explorerViewletFocus"
  },

  {
    "key": "cmd+shift+n",
    "command": "explorer.newFolder",
    "when": "explorerViewletFocus"
  }
]

2. 회사 internal web 배포​

internal-web 배포를 드디어 했다. 배포는 했는데 아직 한 번도 사용을 해본적 없다. 과연될지.. cb 계정은 aws consolidated billing(통합결제 계정)으로 organization에서 관리하고 한 번에 결제가 가능 계정을 말한다.

내가 만든 기능은 github enterprise server 와 jira api server에 api를 날릴 수 있어야 하는데 가능할지 봐야한다.

3. GHES 이관​

보안을 위해 public github에서 github enterprise server로 repo를 이관했다. 이관했을 때 actions들을 전부 사용할 수 없어서 몇 개 요청드리기는 했는데 actions 속도는 진짜 빨랐다.

public github의 경우 actions를 돌리고 인스턴스를 초기화하는데 설치형의 경우 한 번 install이 되면 제거되지 않기 때문에 install 시간이 거의 없다 시피하여 속도가 엄청 빨랐다. 인스턴스 스팩이 좋은 것도 있지만 설치 시간이 없는게 젤 큰 이유같다.

하지만 내 마음대로 actions를 추가하고 테스트할 수 없다는게 큰 단점인데 ㅠㅠ 이건 내가 public github에서 테스트하여 문제없다는게 확실하면 설치 요청드리는 방법으로 해야한다. 기존 actions중 compressed-size-action와 codecov를 제거했다. compressed-size-action는 ci 시간이 너무 오래걸려서 효용이 없는 것 같아 제거했고 codecov는 codecov에 code read permission을 주는게 너무 크리티컬해서 제거했다. 하지만 codecov가 해주는 코드 커버리지를 pr에서 보여주는 작업은 꼭 붙히고 싶은게 괜찮은게 있을지 찾아봐야한다. 간단하게 찾아봤을 때 jest-coverage-report 괜찮은 것 같다. test result.json만 들고가는 것 같다.

역시 보안이 강화될 수록 개발자들은 힘들다ㅠ

1. 내부 툴 개발​

요즘 회사 내부 툴을 개발하고 있다. 누가 시켜서 한 건 아니고 일하면서 불편하고 비효율적인 부분들 자동화를 위해서 개발하고 있다. 처음에는 script cli로 개발했는데 불편한 점이 여러개였다.

1. script 실행시킬 때 해당 프로젝트로 가서 실행시켜야 한다.
2. 누가 script를 업데이트하면 다른 사람들이 모두 git pull을 받아야 한다.

1번은 어찌 해결할 수 있겠지만 2번이 문제였다. 그래서 웹서버를 만들 계획을 하게 되었다. 리소스는 좀 들겠지만 cli는 관리도 힘들고 처음에는 사용해도 점점 사용을 하지 않게되는데 웹서비스는 여러 기능들을 한 곳에 모아둘 수 있고 좀 더 직관적이기 때문이다.

지금 테스트계정으로 인프라 셋팅을 한 상태라 도메인도 못붙히고 http로 동작하고 있는데 나중에 계정도 변경하고 인프라셋팅도 전부 업데이트할 필요가 있다. 우선 vpn으로 연결해야만 접속가능하게 보안셋팅만 했다.

추가로 ec2에서 git clone을 못해서(github enterprise) ecr을 이용했는데 이부분에서 진짜 많이 배웠고 재미도 있었다. github action에서 next standalone mode로 docker image build하여 ecr에 등록하고 ec2에서 iam 계정으로 ecr 로그인하여 image pull 받아 돌리도록 했는데 이런 플로우를 처음으로 셋팅해서 트러블 슈팅도 많이했고 배운것도 많았다.

dockerfile 관련된 내용은 정리도 해보고 싶다. 웹에서 관련 내용 찾기도 너무 어려웠다 ㅠ

추가로 cd 과정에서 ecr 자동업로드 까지는 했는데 ec2에서 image 받아 돌리는건 아직 수동이라 이것도 자동화하는 작업이 필요하다.

2. 회사 Framework 논의​

회사 팀 내에서 Framework를 정하는 논의를 시작하기전 간단하게 정리해보았다.

1. 논의 항목​

1. CSR vs JAM Stack vs SSR 선택하기
2. Framework 선택하기 (이건 거의 정해진 것 같아요)

• CSR: vite
• JAM Stack, SSR: NextJs

2. CSR vs JAM Stack vs SSR​

• ReactNative는 논의에서 제외시켰어요. 현재 리소스에서는 불가능하다고 판단되어 논의 항목에 넣기에는 무리라고 생각해서에요. https://toss.im/slash-23/session-detail/A1-4
• 혹시 위 영상을 보지 않았다면 꼭 봤으면 좋겠어요. 지금 사용하지 않는 방법이지만 방법을 알고 있느냐 없느냐는 천지차이라 생각하기 때문이에요.

개선점 + 한계점​

• CSR
  • 현재 방식이라 따로 적지는 않을께요.
• JAM Stack
  • 토큰을 사용하지 않는 페이지 (비회원, 이벤트)들에 대해 미리 html을 만들어둬요.
  • 홈을 예시로 들면 비회원 홈에 이벤트 리스트들이 있고 이벤트 리스트들을 동적으로 관리한다고 했을 때 html을 만들때 api 찔러 이벤트 리스트를 받아와 html을 만들어두었기에 유저 입장에서 속도도 빠르고, client에서 api를 찌르지 않아도 되어요.
  • 크론잡처럼 배치로 서버를 돌려 html을 만들껀데 30분 주기로 설정할 수도 있고 서버를 돌리는 api를 만들어 api를 쏘면 빌드를 하도록 할 수도 있을 것 같아요.
• SSR
  • 모든 페이지들에 대해 html이 만들어진 후 렌더링이 될꺼라 유저 경험이 극도로 좋아져요.
  • 토큰 인증 방식이 먼저 개선되어야만 모든 페이지들에 대한 ssr이 가능해요.
    • 토큰 인증 방식이 개선되지 않는다면 토큰을 사용하지 않는 (비회원, 이벤트) 페이지들만 ssr이 가능해요.
  • 인증을 담당할 bff도 next server에 들어가면서 next가 엄청 많은 트래픽을 받게 될꺼에요. apiGateway보다 더 많은 트래픽을 받을꺼에요.
    • 이때 운영상 리소스가 많이 발생할꺼에요.
    • 문제가 발생하면 FE가 우선적으로 대응을 해야할껀데 이게 쉽지 않을 것으로 예상돼요.

리소스 & 리스크 분석​

이관 리소스 분석​

• CSR (1)
  • 기존에 사용하는 방식이라서 다른 방식을 측정하기 위한 기준점으로 정해볼께요.
• JAM Stack (3)
  • Framework(NextJs)를 새로 도입하고 이관하는 과정이 필요해요.
  • S3 + Cloudfront + Lambda(or EC2 or ECS) 인프라 셋팅과 구성이 필요해요.
  • (ECS로 돌린다고 했을 때 서버 관리를 위한 모니터링 툴(ArgoCD , Grafana)도 필요해요.)
    • 최대한 리소스 안드는 lambda or ec2가 좋을 것 같아요.
    • 서버쪽 인프라 구성과 동일하게 하려면 ecs로 해야겠지만..
• SSR (8)
  • Framework(NextJs)를 새로 도입하고 이관하는 과정이 필요해요.
  • S3 + Cloudfront + ECS 인프라 셋팅과 구성이 필요해요.
  • 서버 관리를 위한 모니터링 툴(ArgoCD, Grafana) 셋팅이 필요해요.
  • 로그를 쌓고 보기 위한 elastic logstash 셋팅이 필요해요.
    • 서버쪽과 동일한 구성으로 진행될 것 같아요.

운영 리스크​

• CSR (0)
  • AWS에 장애가 있지 않는 이상 없어요.
  • 정적인 리소스들이라 운영이 필요하지 않아요.
• JAM Stack (3)
  • 일정 주기마다 실행될 서버자원에 대한 모니터링이 필요해요. (아마 slack 알림정도)
  • 서버가 실행되지 않았거나 api를 쏘고 제대로 markup이 되지 못한 경우에 대한 작업이 필요해요.
    • 서버 자원이 죽더라도 유저에게 직접적인 문제가 발생하지는 않기에 리스크는 매우 적어요.
• SSR (10)
  • 실시간 모니터링이 필요해요.
  • 인프라팀이 도와주시겠지만 FE 자원이 지금보다 훨씬 많이 들 것 같아요.
  • 서버 배포에 문제가 생길 경우, 서버 운영에 문제가 생길 경우 slack과 연동시키고 온콜이 필수적으로 필요할 것 같아요.

1. "타이탄의 도구들"을 읽고​

1. 개발자 온보딩 가이드​

어느분이 "개발자 온보딩 가이드"라는 책을 요약해주셨는데 공감되는 문장 몇 개 들고왔다.

• 사이드 프로젝트는 “해결하고 싶은 문제” 가 있을 때 “이를 해결할 도구를 이용” 한다는 목표가 있어야 한다.
  • 어떤 것을 “배워야 해서” 라는 이유로 프로젝트를 하는 것은 추천하지 않는다 (동기부여가 별로 안됨)
• 기술 부채 ?
  • 이 용어를 남용하지 말라.
    • 내가 동의하지 않는 기술적 의사결정 or 별로 마음에 들지 않는 코드라고 ‘기술 부채’ 라고 부를 수는 없다.
• 설계
  • 문서를 작성하는 과정에서 불명확한 부분이 드러나기도 한다
  • 구현을 하다보면 계속해서 뜻밖의 일이 발생함.
    • 코드를 작성하면서 크게 달라 지는 부분이 있다면 설계 문서도 반드시 업데이트 해야 함.
  • 설계 시작 전 “문제 영역, 요구사항을 이해” 해야 한다
  • 문제를 정의 : 해결하고자 하는 문제를 정의 하고 이해하기
    • 이 과정에서 문제가 없거나 해결할 필요조차 없다는 것을 알 수도 있음
    • 내가 이해하는 문제가 이해관계자들이 바라보는 시선과 같은지 확인

2. 회사에서 폴더구조 정하기​

회사에서 4개의 프로젝트를 하나의 프로젝트로 합치는 작업을 시작하기 전 가장 중요한 폴더구조 정하는 논의를 했다. 아직 완벽하게 마무리가 된 건 아닌데 큰 틀은 정해져서 어떤 흐름으로 정하게 되었는지 기록하고자 한다.

1) 원칙​

이전에 내가 적은 폴더링에 대한 생각을 ppt로 발표했고 폴더링에 대한 큰 윈칙을 정해보았다.

1. 연관된 것은 같은 폴더에 두자 (연관된 == 도메인이 같은)
2. 모르는 사람도 헷갈리지 않는 구조를 만들자

2) common과 domains​

• 공통 로직&컴포넌트와 도메인에 종속된 로직&컴포넌트를 분리하자.
• 도메인은 어떻게 구분해야할까? 지금 프로젝트 구조인 payment, account, money, payment-card 그리고 home 이렇게 구분하는게 맞을까?
  • payment와 payment-card는 합치는게 맞을 것 같다.
  • domain 구분이 너무 애매하다. account뿐 아니라 escrow, kyc, address도 domain으로 올라가야하는게 아닐까? 전부다 구분하는게 좋을 것 같다.
• 만약 payment에서 account 에 구현되어있는 컴포넌트를 사용해야하는 경우가 생기면 어떻게 해야할까?
  • 그럴때 common으로 해당 컴포넌트를 옮기고 common에 있는걸 두 도메인에서 가져다 사용하면되지 않을까?
  • payment에서 account의 컴포넌트를 바로 참조하는건 어떨까?
  • 그렇게 되면 의존성이 꼬여서 나중에 찾아가기도 힘들고 유지보수하기도 어려울 것 같다. 공통되는게 생기면 상위로 올리는게 좋을 것 같다.

3) shared​

• common 폴더에서 여러 도메인에서 가져다가 사용하고 도메인로직이 들어간 컴포넌트와 아토믹한 컴포넌트를 분리하면 좋을 것 같다. 컴포넌트 뿐아니라 utils, hooks들도 common에 들어갈 것 같은데 이것들도 구분이 필요할 것 같다.
• common > cash-receipt, dialog 이렇게 폴더링이 되면 혼란이 있을 것 같다. common에는 비즈니스 로직이 들어가있지 않은 디자인 시스템 컴포넌트 그리고 delay, format같은 utils와 hooks들 만 넣고 shared에는 도메인 로직이 어느정도 들어간 컴포넌트와 hooks들이 들어가면 좋을 것 같다.
• api, recoil store, storage 들도 shared에 들어갈 것 같다.

4) services​

• 도메인 로직들이 포함되지는 않으나 여러 곳에서 사용되는 외부 라이브러리들을 wrapping하는 것들을 폴더로 모아두어도 좋을 것 같다. bridge, ga, sdk, sentry등이 들어갈 것 같다. 여기서 초기화나 wrapping을 한 번 할 것 같다.

5) domains와 pages​

• domains로 붙히는게 너무 애매하다. domains 하위에 있는건 page로 구분한 것이기 때문에 next의 아키텍쳐를 따라가서 pages로 붙히는건 어떨까?
  • domains로 붙히면 그 기준이 너무 애매해진다. 만약 domains로 한다면 지금처럼 payment, account, money, home 4개로 고정하는게 좋을 것 같다. 그게 아니면 path나 page를 기준으로 그룹핑을하고 폴더명은 pages로 정하는게 좋을 것 같다.

6) page 파일과 components​

• page의 폴더링은 path 구조와 동일하게 가져가는게 좋을 것 같다. 그리고 루트 path인 경우 폴더명을 index로 가져가자.
• page 파일과 그 파일을 구성하는 components들을 어디에 위치시키면 좋을까?
• page 파일은 정말 page initialize hoc 로직이나 meta 속성들만 정의되면 좋을 것 같다.
• components들은 따로 components 폴더에 모아두면 어떨까? 그리고 Page 컴포넌트는 이와 확실히 구분하여 index로 파일명을 지어도될 것 같다.
• 만약 components들에서 공통적으로 사용하는 컴포넌트라면 어디에 둬야할까? shared에 둬야할까?
• 상위 도메인 (pages)와 공통으로 쓰는게 아니기에 pages > payment 밑에 shared 폴더를 두고 사용하면 어떨까? 여기에는 components, hooks, utils 3개의 폴더만 들어가도될 것 같다.
• 추가로 shared는 첫 deps에만 두는게 좋을 것 같다. 아니면 폴더링이 매우 복잡해질 것 같다.

7) 기타​

• 폴더명을 복수형으로 사용하면 폴더명 지을 때 혼란이 있을것 같다. 일관되게 단수형으로 사용하면 좋을 것 같다.

8) 폴더 구조​

1 level	2 level	3 level

논의 이후 다시 고민해봐야 할 부분​

page 바로 하위로 들어가야하는건 어떤 것인가? 그 기준은 뭘까?​

• 처음에 정한 기준은 path 였다. www.abc.com/d/ 이런 경우 d가 page 바로 하위에 들어갈 것이다. d는 왜 도메인 뒤 첫 path일까? 만약 기존 e,f,g 가 첫 path인 경우 d가 기존 도메인과 성격이 너무 틀려서 새로운 상위 도메인으로 만든 것인가?

• 도메인을 상위 도메인, 하위 도메인으로 구분시켜보자 그리고 상위 도메인을 page 바로 하위로 두면 될 것 같다. 그럼 상위 도메인 하위 도메인 나누는 기준은 뭘까?

• 상위 도메인 폴더(page 폴더 바로 하위) 밑에 하위 도메인 컴포넌트들이 component 폴더 혹은 path(page)로 들어갈 것이고 그중 다른 상위 도메인에서도 가져다 사용하는 하위 도메인 컴포넌트들은 shared로 이동시키게 될 것이다.

• 만약 e 도메인의 flow에서 상위 도메인 d의 컴포넌트를 사용하는 경우에는 어떻게 해야할까? d 상위 컴포넌트 하위 컴포넌트 중 공통 컴포넌트로 사용할 컴포넌트를 shared로 올리면 된다.

• 그 반대도 동일하다. page가 없던 e 밑에 있던 하위 도메인 d가 page가 생기게 되면 d를 상위 도메인으로 올리고 d domain에서 공통 컴포넌트를 shared에 두어 e와 d에서 같이 사용하면 된다.

• 여기까지는 확실히 정리되었다. 다시 처음으로 돌아가자. 기존 domain과 성격이 다른 domain, 그리고 페이지가 새로 나온 domain을 상위 도메인이라고 부르는게 맞을까? 애매모호한 기준은 주관적이어서 점점 그 기준이 흐릿해지고 구조가 깨지기 시작한다. 우리는 그 기준을 확실히 정할 필요가 있다.

도메인은 뭘까? 그리고 상위 도메인, 하위 도메인은 어떻게 나누는가?​

참고: https://happycloud-lee.tistory.com/94

• 도메인은 사전적 의미로 '영역', '집합'입니다.
• DDD에서 말하는 Domain은 비즈니스 Domain입니다.
• 비즈니스 Domain은 유사한 업무의 집합입니다.
• 어플리케이션은 비즈니스 Domain별로 나누어 설계 및 개발될 수 있습니다.

DDD란?​

• 비즈니스 Domain별로 나누어 설계하는 방식입니다.
• DDD의 **핵심 목표는 "Loosely coupling", "High cohesion"입니다. (애플리케이션 또는 그 안의 모듈간의 의존성은 최소화하고, 응집성은 최대화)
• DDD는 Strategic Design과 Tactical Design으로 나눌 수 있습니다. Strategic Design은 개념 설계이고 Tactical Design은 프로그래밍하기 위한 구체적 설계라고할 수 있습니다.

Domain Model​

• Core Domain: 비즈니스 목적 달성을 위한 핵심 도메인으로 차별화를 위해 가장 많은 투자가 필요함
• Supporting Sub-Domain: 핵심 도메인을 지원하는 도메인
• Generic Subdomains: 공통 기능(메일, SSO 등) 도메인

Domain 분해 예제: 온라인 음식 주문 업무​

주문, 주문중계, 음식점업무, 배당대행의 최상위 도메인을 정의하고 각 도메인을 서브도메인으로 분해함. 서비도메인은 유사한 업무를 그룹핑한 것임.

• 상위 도메인
  • 회원, 주문, 음식, 결제
• 하위 도메인
  • 회원 : 회원 정보, 회원 포인트
  • 주문 : 배달 주문자, 배달 정보, 주문 정보, 배달 추적 정보, 배달 주소 정보
  • 음식 : 음식 정보
  • 결제 : 결제 정보

결론​

• 도메인은 유사한 업무의 집합으로 특정한 문제를 해결하기 위한 기능들의 집합이라고 생각할 수 있다.
• 상위 도메인 하위 도메인의 구분은 상위 도메인을 어떻게 정하느냐에 따라 달라진다. 비즈니스를 역할별로 쪼개면 상위 도메인이 된다.
• A 상위 도메인 플로우중 C 도메인이 있다고 생각해보자 (예를 들어 account 도메인의 로그인 플로우에서 kyc를 하는 화면이 있을 때 -> 이때 kyc를 도메인으로 부르는게 맞을까?) 도메인이라고 부를 수는 있지만 상위 도메인으로 불리기에는 애매하다. kyc는 account의 그룹에 포함시킬 수 있다. 하지만 다른 도메인 페이지에서도 사용된다면, 단지 컴포넌트가 아니라 페이지로 만들어진다면? 그래도 아니다. 상위 도메인은 정의와 같이 유사한 업무의 집단으로 구분해야한다.
• 정리하고 보니 기존 폴더 구조에서 page의 1 level의 정의가 모호하게 정한 것 같아서 다시 논의할 필요가 있을 것 같다.

1. 일상​

• 가르마 펌 했다. 가르마 펌은 처음인데 마음에 든다.
• 와인앱 ocr 을 하려고 했는데 와인병 라벨이 이미지가 있고 글자가 잘 안보이는게 너무 많아서 지금 고민이 많다.. mlkit 모듈만 사용해서 감싸는 어플리케이션 코드들은 커스텀이 많이 필요한 것 같다.

2. Web Vital 수집은 했는데 어떻게 이쁘게 볼 수 있지?​

성능에 대한 관심이 많아져 내가 관리하는 프로젝트 2개에 web-vital 수집하는 코드를 추가했다. 앞으로 성능 개선작업을 할 껀데 그 작업의 지표로 활용하고 싶어서이다.

최대한 무료로 하고 싶어서 찾아보는데 현재 가장 기본적인 ga에 로그 쌓는걸 해놓은 상태다. 하지만 이걸 어떻게 reporting 형식으로 받아볼 수 있을지는 모르겠다. web.dev에서는 bigQuery와 연동하라고는 하는데 bigQuery 권한도 없을뿐 더러 돈이 들어서 이건 논외로 둔 상태다. ga에서 table로 어느 정도 볼 수는 있는 것 같기도 한데 어떻게 레포트를 만들 수 있을지 조금 찾아봐야 한다. page speed insights는 단일 요청인데다. 내가 측정하려고 하는 건 실제 유저 사이드 페이지라서 매우 부정확하다. search Console을 활용할 수 있을지는 모르겠다. 일단 서비스가 검색엔진에 노출되면 안되는 거라 안될 것 같기도.. 그런데 ga 이벤트 연동만 시킬 수 있을지는 한 번 봐야한다.

web-vitals-report는 ga4 지원을 고려하고 있지 않다고 한다. 이슈 코멘트 보면 bigQuery 쓰라고 그러는 것 같다. (돈 벌기 위해..)

암튼 대안은 sentry의 performance monitoring web-vitals인데 일단 flag는 켜뒀는데 데이터 수집이 안되고있어서 다음 주 다시 살펴봐야 한다.

할 께 너무 많다. 임팩트 있는 것만 하고자 하면 정말 필요한 것만 작업하게 되고 고객뿐 아니라 개발자들도 제품에 대한 흥미가 떨어질 것이기에 자잘한 작업들.. 지금은 불필요해 보여도 나중에 도움이 될 만한 것들을 열심히 하는 중이다. 아무도 하지 않는 일들을 꾸준히 하다 보면 엄청난 시간도 아끼고 프로젝트와 서비스도 성숙해질 것이라 생각한다. 팀 내에서 나만 이런 작업들 을 하고 있는데 조금 슬프기는 하다. 그래도 모두가 중요하다고 생각 하는게 다르다고 생각하기에 불만은 없다. 다양한 관점과 흥미는 모든 영역에서 좋은 점수를 받게 할 꺼라 믿기 때문이다.

3. 타이탄의 도구들 읽고​

4. 탁월함은 습관이지만, 실패도 마찬가지​

긱뉴스를 보다 너무 공감되는 글이 있어서 들고 왔다. https://news.hada.io/topic?id=9677&utm_source=slack&utm_medium=bot&utm_campaign=T04J76D4C

[탁월한은 습관이지만, 실패도 마찬가지]

• 매일 조금씩 개선하면 위대한 결과로 이끌 수 있다는 얘기를 많이 들음
• 방치/무시와 작은 실수가 계속 쌓이면 부정적인 결과로 이어질 수 있음
• 내 삶을 되돌아보면, 실제로 궤도를 벗어난 일들은 점진적인 무시와 수많은 작은 잘못된 선택의 결과였음
  • 나는 하룻밤 사이에 과체중이 된 것이 아님. 장기적인 건강보다 즉각적인 만족을 선택한 수백 번의 순간을 통해서였음
  • 나는 하룻밤 사이에 관계를 망치지 않았음. 어려운 대화에 맞서고, 내 실수를 인정하거나, 누군가가 나보다 무언가를 더 잘하는 것을 인정하는 것보다 "편안함"을 선택한 수백 번의 순간을 통해서였음
• 나쁜 습관을 피하는 것은 좋은 습관을 기르는 것만큼 중요함
• 방치의 패턴을 인식하고 조기에 대처함으로써 더 큰 문제를 예방할 수 있음
• 우리의 성격은 오랜 과정의 새기거나 긁기의 결과다.
• 현명한 선택과 덕덕한 습관은 어려운 상황에서 옳은 일을 하는 것을 더 쉽게 만든다.
• 보잘것 없어 보이는 일들도 우리의 성격에 영향을 미칠 수 있습니다.

부정적인 습관을 고쳐보자. 1년 뒤 나의 삶은 몰라보게 달라질 것이라고 확신한다.

1. 만들면서 배우는 클린 아키텍처 요약 (1,2,3장)​

우리는 모두 낮은 개발 비용으로 유연하고 적응이 쉬운 소프트웨어 아키텍처를 구축하고자 한다. 그러나 불합리한 기한과 쉬워보이는 지름길은 이러한 아키텍처를 구축하는 것을 매우 어렵게 만든다.

어떤 지름길이 어떤 종류의 기술 부채를 만들고, 어떤 경우에 이러한 부채를 기꺼이 질 가치가 있는지 배운다.

'지름길 모드'는 '깨진 창문 이론'과 같다. 아키텍처의 '지름길 모드'를 끄고 싶다면, 적어도 추가적인 아키텍처 규칙을 강제하지 않는 한 계층은 최선의 선택은 아니다. 그리고 여기서 '강제한다'는 것은 시니어 개발자가 코드 리뷰를 한다는 의미가 아니라 해당 규칙이 깨졌을 때 빌드가 실패하도록 만드는 규칙을 의미한다.

아주 엄격한 자기 훈련 없이는 시간이 지날수록 품질이 저하되고 유지보수하기가 어려워지기 쉽다. 이러한 자기 훈련은 보통 프로젝트 매니저가 개발팀에 새로운 마감일을 설정할 때마다 조금씩 느슨해지기 마련이다.

새 프로젝트에거 가장 먼저 제대로 만들려고 하는 것은 패키지 구조다. 프로젝트에서 계속 사용할 괜찮아 보이는 구조를 잡는다. 그리고 나서 프로젝트가 진행될수록 점점 바빠지고 패키지 구조는 짜임새 없는 엉망진창 코드를 그럴싸하게 보이게 만드는 껍데기일 뿐이라는 점을 깨닫게 된다. 한 패키지에 있는 클래스들이 불러오지 말아야 할 다른 패키지에 있는 클래스들을 불러오게 된다.

계층으로 구성하기: 애플리케이션의 기능 조각이나 특성을 구분 짓는 패키지 경계가 없다. 애플리케이션이 어떤 유스케이스들을 제공하는지 파악할 수 없다. 특정 기능을 찾기 위해서는 어떤 서비스가 이를 구현했는지 추측해야 하고, 해당 서비스 내의 어떤 메서드가 그에 대한 책임을 수행하는지 찾아야 한다. 패키지 구조를 통해서 우리가 목표로 하는 아키텍처를 파악할 수 없다. 육각형 아키텍처 스타일을 따랐다고 추측할 수는 있다.

기능으로 구성하기: 패키지 간의 경계를 강화할 수 있다. 유스케이스를 구현한 코드는 클래스명만으로도 찾을 수 있게 됐다. 애플리케이션의 기능을 코드를 통해 볼 수 있게 만드는 것을 가리켜 로버트 마틴이 '소리치는 아키텍처'라고 명명한 바 있다. 왜냐하면 코드가 그 의도를 우리에게 소리치고 있기 때문이다. 그러나 기능에 의한 패키징 방식은 사실 계층에 의한 패키징 방식보다 아키텍처의 가시성을 훨씬 더 떨어뜨린다. 아키텍처 다이어그램에서 어떤 박스를 가리켰을 때 코드의 어떤 부분이 해당 박스를 책임지는지를 바로 알 수 있다면 좋을 것이다.

아키텍처적으로 표현력 있는 패키지 구조: 패키지 구조는 이른바 '아키텍처 - 코드 갭' 혹은 '모델 - 코드 갭'을 효과적으로 다룰 수 있는 강력한 요소다. 만약 패키지 구조가 아키텍처를 반영할 수 없다면 시간이 지남에 따라 코드는 점점 목표하던 아키텍처로부터 멀어지게 될 것이다. 이처럼 표현력 있는 패키지 구조는 아키텍처에 대한 적극적인 사고를 촉진한다. 많은 패키지가 생기고, 현재 작업 중인 코드를 어떤 패키지에 넣어야 할지 계속 생각해야하기 때문이다. 모든 구조와 마찬가지로 패키지 구조를 소프트웨어 프로젝트 내내 유지하기 위해서는 지켜야 할 규칙이 있다. 또한 패키지 구조가 적합하지 않아서 어쩔 수 없이 아키텍처-코드 갭을 넓히고 아키텍처를 반영하지 않는 패키지를 만들어야 하는 경우도 생길 수 있다. 완벽한 방법은 없다. 그러나 표현력 있는 패키지 구조는 적어도 코드와 아키텍처 간의 갭을 줄일 수 있게 해준다.

실제 코드 구조를 최대한 우리가 목표로 하는 아키텍처에 가깝게 만들어주는 육각형 아키텍처의 패키지 구조를 살펴봤다. 코드에서 아키텍처의 특정 요소를 찾으려면 이제 아키텍처 다이어그램의 박스 이름을 따라 패키지 구조를 탐색하면 된다. 이로써 의사소통, 개발, 유지보수 모두가 조금 더 수월해진다.

2. 폴더링에 대하여 마구잡이로 쓰는 나의 생각​

사람들은 기본이 중요하다라는걸 말하면서도 쉽게 넘어간다. 제대로 이해하지 않고 음~ 그렇구나 라고 알고 넘어간다. 소프트웨어 기술 서적을 읽을 때 항상 기본에 대한 글이 있는데도 빠르게 넘어가고 심화 부분과 기법들을 수록되어있는 장으로 넘어간다. 하지만 기본은 정말 중요하다.

소프트웨어 개발 서적에서 항상 나오는 말이 있다. "유지보수가 잘되는 소프트웨어를 개발해야한다." 대부분의 기술서적들이 유지보수에 대한 내용을 다룬다. 여기서 사람들은 SOLID를 배우고 의존성 주입을 배우고 아키텍처를 배운다. 이런 내용들은 매우 종요한 내용이라는 것에 매우 동의한다. 하지만 이것보다 중요하고 기본적인 것은 클린코드다. 유지보수하기 쉬운 소프트웨어의 기본 첫번째 조건은 알기 쉬운 변수명과 함수명 그리고 파일을 잘 분리하고 위치시키는 것이다.

본인의 코드를 두고 잘 고민해봤으면 좋겠다. 나는 지금 이 프로젝트를 개발한 당사자이지만 내가 아닌 다른 사람(혹은 1년후의 본인)이 프로젝트에 투입되었을 때 변수명, 함수명을 보고 어떤 변수이고 함수인지 알 수 있겠는가? 또는 새로운 기능이나 기존 기능을 수정해야하는 task를 받았을 때 수정해야하는 파일의 위치를 빠르게 찾아갈 수 있겠는가? 여기에 당당하게 그렇다고 말할 수 있는 사람은 많이 없을 것 같다. (본인이 작성한 코드를 사랑해서, 오랫동안 작업하여 편견에 휩싸여 대답하지는 않았는지 다시 돌아보길 바란다.)

누구나 알지만 쉽게 넘어가는 부분들을 매우 중요한 부분이라고 생각하고 행동해줬으면 좋겠다.

• 프로젝트를 처음 시작할 때 가장 먼저 하는것이 폴더 구조다.

• 새로운 요구사항 또는 이유로 폴더를 만들어야 할때

  • 내가 좋아보이고 알기 쉬운 구조로 만드는 것이 아닌 객관적이고 남들이 봤을 때 알기 쉽고 찾아가기 쉬운 폴더 구조를 만드는데 집중해야 한다. 이런 기준으로 폴더를 만들고 위치시켰으면 좋겠다. 문서를 읽거나 파일을 폴더에 배치시키거나 폴더를 찾아갈 때 창의적 혹은 추론하여 찾아가지 않도록. 폴더들이 "나 여기있어!" 소리치고 있도록. 이전에 개발한 개발자가 코드리뷰로 폴더 위치가 잘못되었다고 말하는 상황이 왔다면 잘못 작성되고 있는 것이다. 이는 주관적인 관점에서 폴더링을 한 것일 수도 있고 사람마다 관점에 따라 다르게 폴더링을 했다고도 할 수 있다.
  • 엄격한 자기 훈련이 필요한 상태는 시간이 지날수록 품질이 저하되고 유지보수하기 어려워지기 시작한다. 처음 설계한 개발자가 프로젝트에서 떠나버리면 여러 철학과 개념이 혼재된 카오스가 될 것이다.

• 우리가 해야할 일은

  • 코드 수정해야할 일이 있을 때 빠르게 해당 파일을 찾아갈 수 있도록 개발해야 한다.
  • 주관적인 생각이나 소수의 집단이 알고 있는 철학이나 방법론을 적용한 폴더링은 피해야한다. -> 이것을 판단할 수 있는건 새로운 누군가가 코드를 작성했을 때 코드리뷰로 잘못된 폴더에 코드를 작성했다고 알려주는 것, 새로운 누군가가 새로운 파일을 만들었을 때 어느 폴더에 넣어야 하는지 창의적, 추론을 하면서 폴더에 집에 넣는 상황이 발생하는 것이다.

• 단편적으로 생각해서, 현재 상황을 기반 또는 프로젝트에 대한 이해도가 높은 상태에서 폴더 구조를 짠다면 주관이 많이 반영된것이기 때문에 경계하자. 코드는 쓰는 시간보다 찾고 읽는 시간이 훨씬 많다. 빨리 찾고 읽을 수 있도록 배치해야한다.

• 위에서 기준을 계속 말했지만 반영되었으면 좋을 세부적인 부분 몇 개만 언급하면

  • 연관된 것은 같은 폴더에 두었으면 좋겠습니다.
    • 이전 회사에서는 components > dialog > SignUpDialog, WithdrawInfoCreateDialog, WithdrawEditCreateDialog, CashReceiptEditDialog 이런식이였습니다. 이렇게 폴더 구조를 짜면 코드를 위에서 끝까지 코드를 읽어가면서 내가 수정해야할 코드를 찾게 됩니다. 도메인(기능) 별로 묶여야 합니다. components > withdraw > WithdrawInfoSection, WithdrawInfoCreateDialog, WithdrawEditCreateDialog 연관된 것들 끼리 묶여있어야 찾기 쉽고, 관련 코드를 찾을 때 여러 폴더를 이동하지 않아도 됩니다. Dialog와 페이지가 props로 데이터를 주고 받기 때문에 멀리 떨어져 있는 파일들을 왔다갔다하면서 코드 수정해야합니다. 가까운 것은 가까이 위치시켜야합니다. 같이 코드수정을 해야하는 파일들은 같은 폴더에 위치시켜야 합니다.
  • 폴더링에 주간이 관여되지 않았으면 좋겠습니다.
    • 나만이 알고 있는 정보, 어느 블로그나 아티클을 보고 폴더링을 하거나 프로젝트에 대한 도메인 지식이 풍부한 상태를 기반으로 폴더링을 하게되면 프로젝트에 처음 들어온 사람이나 익숙치 않은 사람들은 창의력과 추론을 바탕으로 파일을 위치시키게 되고 이를 코드 리뷰에서 피드백이 꼭 필요하게 됩니다. 시간이 지날수록 품질이 저하되고 유지보수하기가 어려워지기 쉬워질 겁니다. 엄격한 훈련이 필요하지 않도록 폴더링을 해야합니다.

1. 와인 앱​

지금 6분간격으로 50개의 와인정보를 들고오는 스크립트를 짜서 배치로 돌리고 있다. 자주호출하면 ip blocking되더라..ㅠ 3~4일 정도 돌리면 모두 수집될 것 같은데 수집되고 나서도 데이터 정제과정이 많이 필요하다ㅠ 일단 모두 수집하고 정제 과정은 앱 개발과 병렬로 수행할 예정이다.

바코드로 와인정보를 가져오는 피처는 포기했다. 바코드로 정보와 상품정보 맵핑된 데이터 찾기가 쉽지 않다. 바코드 표준에 따른 meta 데이터 정보만 알 수 있다. 한국에서 생성된 바코드는 코리아넷에 검색하면 되는데 요거 api 신청은 돈이 들고 기업형으로 개방된 것 같아서 포기, 크롤링하고 싶어도 관련 정보 제공해주는 사이트를 찾기 힘들다. 모로가도 서울만 가면 된다고 라벨 검색을 할 수 있는 API가 있나 싶어 네이버 이미지 검색 API를 찾아봤는데 이건 이제 관리를 안하는지 업데이트된지 몇년된 것 같아서 포기. response도 빈약하다.

생각해보니 모바일기반 앱이기에 ocr을 하면 되겠다싶어 flutter package 검색해보니 유명한거 3개 정도 있어서 요거 사용하면 될 듯하다. label 읽어서 와인 명 검색하면 왠만한거 다 찾을 수 있을 것 같다. 바코드 처럼 빠르고 완벽하게 찾지는 못하겠지만 그래도 원하는 결과는 얻을 수 있을꺼라 생각도 들고 바코드 찾을 시간도 아꼈다. 추가로 장점 하나 더 말하자면 바코드는 병을 뒤집어서 스캔해야하는데 라벨 ocr은 바로 검색할 수 있어서 좋은 것 같다. 이걸 어떻게 빠르고 간편하게 할 수 있을지 ux는 많이 고민을 해봐야겠지만 말이다.

추가로 밑에 글쓴 EO 영상을 보고 크롤링하는걸 auto gpt를 이용해서 할 수 있지 않았을까? 생각도 든다.

2. EO "글로벌 6위 한국의 인공지능 기업들의 생존전략" 영상 요약​

오랜만에 글쓰는 것 같다. 벌써 목요일.. 어제는 회사 문화의 날이라 팀원들과 PC방가서 롤, 볼링을 하고 스테이크를 먹었다.

1. 배려하기​

남의 눈치를 안보고 편하게 살면 좋을 것 같지만 그렇지도 않다. 조금 눈치보고 노력하며 남을 배려하고 이쁘게 말하고 존중하는 커뮤니케이션을 하면 모두가 행복해진다.

요즘 나의 말이 기분나쁘게 들릴지도 모를 것 같다는 생각이 들어서 최대한 조심하고 이쁘게 말하려고 노력중이다.

2. 타이탄의 도구들​

행복은 거절의 기술이다.​

매일 하루를 시작할 때 '행복을 위해 집중해야 할 것은 무엇인가?'라는 질문으로 시작해보라. 단순한 이 문장이 얼마나 놀라운 진리인지를 점점 깨닫게 될 것이다. 행복에 집중하기 위해서는 '거절의 기술'이 필요하다. 원치 않는 부름에 응답하지 않는 것, 그것이 행복의 본질이다.

준비가 되어있지 않은, 무능한 상대에게 시간을 낭비하지 마라. 우리는 이런 사람들을 일일이 정중하게 대하느라 얼마나 많은 시간을 쓰고 있는가. "모든 사람에게 답변하지 않는다고 해서 죄책감을 느낄 필요는 없다. 오히려 시간을 낭비하기보다는 죄책감을 갖는 게 더 낫다. 우리가 끊임없이 뭔가를 거절해야 하는 이유는 그래야만 우리 삶의 질을 유지할 수 있기 때문이다. 어떤 요청을 받아들이면, 그 대가로 품질을 희생해야 한다. 하지만 품질만큼은 언제나 인생에서 사수해야 할 가치다."

1. 와인앱 근황​

앱 만들기전 와인 데이터가 많이 필요해서 여러 사이트에서 크롤링을 하고 있다. 최대 와인 사이트인 vivino에서 데이터를 긁어오려고 하는데 api를 너무 많이 쏴서 ip block을 당해버렸다. ㅠ api 20개씩 500 번 쏘고 있었는데 1000번째 부터 block된 것 같았다. ip 우회나 block이 풀릴때까지 기다려야할 듯 싶다.

api 한 번에 25개의 와인 정보를 긁어오기에 1000번 쏘면 25000 개의 와인 정보를 얻는다. 그런데 vivino에 등록된 와인이 12백만개 라고한다. 아마 빈티지가 달라도 다른 와인으로 취급하기 때문에 이렇게 수가 많을 것이다.

크롤링 코드는 chat-gpt로 만들었는데 진짜.. 생산성이 최소 10배는 올랐다. 나의 리소스가 10배는 덜 든것 같다. url 주면서 api 호출하는 코드짜줘, 받아온 html을 주면서 여기서 와인정보를 얻어 object로 만드는 코드짜줘, api를 병렬로 호출하는 코드를 짜줘, 파싱한 와인 정보를 파일에 저장시켜줘. 이렇게 말하면 내가 원하는 코드를 다짜준다. 물론 코드를 실제로 돌려보면서 살짝 튜닝은 한다. 하지만 튜닝 비용은 진짜 적고 chat-gpt가 짜주는 코드는 시간이 많이들고 많이 분석해야하는 일들이라서 매우 만족스럽다.

2. 타이탄의 도구들을 읽고​

22. 쓰고 또 써라​

글을 쓰면서 자료를 구한답시고 계속 인터넷을 들락날락거리는 사람은 한 줄도 못건진다. 모든 것에서 자유로울 때 우리는 우리 자신만의 고유한 글을 쓸 수 있게 된다. 벽에 부딪혀 실마리나 아이디어가 떠오르지 않을 때는 "기준을 낮춰라" 글쓰기에 관해 내가 얻은 최고의 조언은 '매일 허접하더라도 두 장씩 써라' 이다. '질' 보다 '양'이 선결되어야 한다. 양적 팽창은 질적 전이를 가져온다. 빠른 시간 내에 초고를 확보한 작자는 더욱 빠른 속도로 자신감을 그 위에 보태나간다.

23. 10배 크게 생각하라​

• 10퍼센트 큰 것을 목표로 한다는 것은 모든 사람과 경쟁하겠다는 뜻이다. 모두가 10퍼센트 큰 것을 목표로 삼기 때문이다. 10배 큰 것을 목표로 하면 그곳에는 당신뿐이다.
• 10배 큰 목표를 추구할 때는 '백지 상태'로 시작해야 한다. 문제 접근법이 완전히 달라야 한다.
• 10퍼센트가 아니라 10배 크게 생각하는 것은, 꼭 100배 더 힘들지는 않지만 보상은 100배 더 크다.

오늘도 대담하게 뛰어들었는가​

더 나은 사람이 되려면 우리는 실수와 한계를 드러내는 일에 두려움을 갖지 않아야 한다. 가장 많은 실수를 드러내는 사람이 '가장 열심히 노력하는 사람'이다. 그러니 그것들을 보여주는 건 자랑스러운 일이지, 부끄러워 할 이유가 아니다.

정신 없이 두들겨 맞을 것을 알면서도 대담하게 뛰어드는 것, 그것이 우리가 가져야할 단 하나의 삶이다. 인생을 바꿀 만한 커다란 용기는 '흠씬 두들겨 맞을 것이다'와 같은 '취약성'을 드러내고 감수할 때 생겨난다. 우리는 매일 두 개의 질문을 던져야 한다. '나는 오늘 대담하게 뛰어들었는가?' '나는 편안함 대신 용기를 선택하기 위해 어떤 취약성을 드러내고 감수했는가?' 강연이 끝났을 때 어지럽고 속이 울렁거리지 않으면, 그건 대담하게 뛰어들지 않았다는 뜻이다.

강력한 행동을 끌어내는 7가지 질문​

최악의 상황을 구체적으로 정의하라​

"행동이 항상 행복을 가져다주지는 않는다. 하지만 행동 없는 행복은 존재할 수 없다." 할 것인가, 말 것인가? 시도해야 하는가, 포기해야 하는가? 용감하든 그렇지 않든, 우리는 대부분 '하지 않는' 쪽을 선택한다. 고민하는 내내 '불확실하다'와 '실패할 것이다'라는 문장이 머릿속에서 무서운 경고처럼 떠다니기 때문이다. 그래서 우리는 아무것도 하지않는 '불행'을 선택한다.

리스크가 아니라 가능성을 선택하라​

"성공 하려면 높은 리스크를 감수해야 한다고 생각한다. 맞는 말이다. 그런데 정작 큰 리스크를 감수하겠노라 결정하고 대담하게 뛰어들면, 생각보다 큰 리스크는 별로 없다. 정작 리스크보다 더 많이 만나는 것은 인생을 바꿀 만한 잠재력, 즉 다양한 '가능성'이다. 그러므로 인생은 어떤 리스크를 선택할 것인지 결정되지 않는다. 어떤 가능성을 선택할 것인자, 더 큰 가능성을 놓치고 있는 것은 아닌지의 여부로 결정된다는 사실을 생생하게 알게 된다."

텅 빈 공간에 홀로 서라​

조시는 폭보다는 깊이에 초점을 맞춘다. '마이크로에서 매크로를 배운다'라고 이름 붙인 원칙을 자주 활용한다. 뭔가 작은 것에 집중하면 모든 영역에 적용할 수 있는 강력한 것을 얻을 수 있다고 믿는다.

처음 체스에 입문하는 사람은 통상 포석이나 행마를 위한 몇몇 방법을 기계적으로 암기하는 것에서 출발한다. 조시는 이를 두고 선생님에게서 시험지 답안을 훔치는 격이라고 말한다. "근본적인 원리나 전략을 배우는 것이 아니라 초보 친구들을 이길 수 있는 몇 가지 요령을 배우는 것에 불과하다." 조시는 내게 체스를 가르쳐줄 때도 게임의 거의 막판에 이르렀을 때 처할 수 있는 상황에서 시작했다. 이렇게 복잡함이 거의 사라진 상태에서 '빈 공간'의 힘을 통해 적을 추크추방으로 내몰 수 있는 전략에 집중할 수 있게 한다. "포석과 행마에는 수백가지 방법이 있다. 이를 가장 많이 알고 있는 사람이 챔피언이 되는가? 아니다. 챔피언이 되려면 아직 세상에 나타나지 않는 방법을 알아야 한다. 챔피언은 창조적인 전략이 결정하는데, 그것은 아무것도 가진 게 없을 때 스치듯 떠오른다." 가진 것이 없을 때, 자원 활용에 기대지 않을 때, 아무도 도움을 주는 사람이 없을 때 비로소 우리 내면의 커다란 상상력이 기지개를 컨다. 텅 빈 공간에 홀로 서라. 그러면 당신 내면의 거인이 당신을 자신의 어깨 위로 올려 놓을 것이다.

조시 웨이츠건은 체스 판을 텅 비워야 상대를 제압하는 결정적 전략을 얻을 수 있다는 것을 알았다. 체육관 청소나 도복의 옷매무새등 디테일을 꼼꼼하게 챙기는 사람이 챔피언이 된다는 사실도 잘 알고 있다. 마무리가 좋아야 새로운 것을 할 수 있고, 한 분야의 정상에 오르기까지의 과정에서 얻은 아주 작은 것들이 결국 전혀 다른 분야를 정복하는 탁월한 무기가 된다는 사실 또한 잘 알고 있었다.

6.20 ~ 21 팀 워크샵이 있어 놀고 왔다. 군필 5명이라 숙소 도착하자마자 탁구 토너먼트, 족구 토너먼트, 노래방, 와인 5병 테이스팅을 몇 시간만에 끝내고 각자 쉬었다. ㅋㅋ

1. toss slash 달리는 토스 앱에 React Native 엔진 더하기​

영상: https://toss.im/slash-23/session-detail/A1-4

회사 동료분이 공유해주신 내용을 보고 깨달은 바가 많았다. 회사 팀원들과 우리도 결국은 next로 가야하지 않을까? ssr을 해야하지 않을까? 항상 생각했던 것 같다. 이유는 UX 적인 이유로 첫 페이지로드를 최대한 빠르게 하고 싶은데 가장 큰 효과를 볼 수 있는게 ssr이라고 생각했기 때문이다.

하지만 영상을 보고 방향을 다시 재고해볼 필요가 있다는걸 알게 되었던 것 같다. next는 정말 리소스도 많이 들고 큰 변화이다. 이러한 변화를 충분히 검증하지 않고 진행했을 때 시간만 낭비될 수 있기 때문이다. toss에서는 이미 next를 사용하고 있다고 알고 있었는데 next를 운영했을 때 단점들이 많아서 rn으로 갈아탄 것 같았다.

next는 배포도 느리고 k8s와 docker를 사용해서 배포하고 fe 개발자가 k8s, s3, cloudfront, ecr, cks등의 cloud service와 argoCD, grafana등의 모니터링 툴도 관리해야한다. 그리고 이벤트 등이 있을 때는 미리 pod를 늘려두는 작업도 필요하다. 과연 이렇게 노력, 돈, 리소스를 투자할 정도로 가치있는 일일까? 더군다나 비용 감축을 하고 있어서 cloud service를 마음대로 사용할 수 없는 상황에서 말이다.

윗 영상을 통해 next가 아닌 다른 방향도 많이 고려해야함을 알게 되었던 것 같다. rn도 그 방법이고 next보다 좋은 방법일 수 있다는 것도.

우리도 차근차근 문제를 해결해나가야 한다. 그 방향은

• 사용자 경험
• 개발자 경험

두 가지 모두를 개선시킬 수 있는 방향으로 말이다. 필터링없이 내가 고민한 것들을 적어보자면 다음과 같다.

• 프로젝트 통합을 했을때 account, money, payment도 번들된 js를 분리해서 따로 배포하는 프로세스를 만들면 좋을 것 같아요. 하나의 프로젝트이지만 따로 번들링되고 따로 배포가 이루어지도록. 하나의 배포가 다른 곳에 영향을 주지 않도록
• esbuild를 조작하여 js를 shared js, 각 service별 js로 만들고 배포할 수 있도록 해보면 좋지 않을까?
• 1차적으로 저희 웹 성능을 측정해볼 필요가 있을 것 같네요. core-webvital 만 우선 측정해봐도..
• 이야기가 나왔듯이 두가지 모두 챙기면 좋을 것 같아요. 저희는 둘 모두 소홀히 하지 않았나 생각이드네요ㅠ
  • 사용자 경험
  • 개발자 경험
• ci, cd 속도도 더 줄일 수 있을지 고민해봐도 좋을 것 같아요. 지금 보면 compressed-size ci는 특수한 상황일 때 체크하도록 하면될 것 같아요. 지금은 제거하고 (payment, payment-card에 적용되어 있음)
• core-webvital 중 FCP, FID 시간을 측정하고 50% 이상 개선을 올해 목표로 삼아봐도 재미있을 것 같아요
• asset load 시간을 줄일것인가? 실행된 이후 첫 contents 가 보이기 까지의 시간을 줄일것인가?
• 어떻게 불필요한 api 요청을 줄이고 account-webclient 를 띄우고 토큰을 받아오는 과정을 간략하게 할 수 있을까?
• 각 서비스들의 공통 로직들을 따로 js로 만들어 서비스간 이동할 때는 공통 js를 로드하지 않도록하여 js asset download 시간을 줄일수도 있지 않을까.
• 어떻게 불필요한 api 요청을 줄이고 account-webclient 를 띄우고 토큰을 받아오는 과정을 간략하게 할 수 있을까? pc에서는 기존과 같이 account-webclient로 redirect하여 토큰을 받아오도록 하되 웹뷰에서는 각 서비스가 직접 토큰을 받아올 수 있도록 하면 좋지 않을까? (현 native처럼)
• ci 시간이 4분~5분 걸리는데 github-action 사용하지 않고 m1 머신사용하여 1분 이내로 줄이면 좋지 않을까? (e2e의 경우 action이 수행될 때 browser driver를 다운받기에 시간이 너무 많이 걸림. binary 파일이라 github-action caching도 안됨.. )
• 하지만 자체 ci 머신을 사용하면 node install, browser driver download등을 하지않음, 컴퓨팅 성능도 훨씬 좋음.
• next가 운영상에 어려움이 많고 토큰관련해서도 해결해야할 문제들이 많으니 JAM Stack을 이용하여 서버관리를 최소화 하자. 토큰없이 그릴 수 있는 것들을 최대한 그려서 index.html이 비어있지 않도록 해보자.
  • https://toss.tech/article/faster-initial-rendering

그냥 생각나는대로 아이디어를 적은거라서 토론과 정리가 필요하다. 하지만 이걸 시작으로 우리의 프로젝트&서비스가 조금은 더 유저에게 좋은 경험을 줄 수 있지 않을까 희망을 가져본다. 한 번에 큰 변화는 힘드니 조금씩 개선해 나가보자. 1년만 지나도 매우 큰 변화가 있을 것이다.

2. 소프트웨어 공학 공부뿐 아니라 툴, 방법들의 공부도 필요하다.​

소프트웨어 공학을 공부하는 주된 이유는 뭘까? 유지보수를 쉽게하기 위함이다. 이때의 유지보수는 오늘의 기능을 구현하며 내일의 요구사항을 쉽게 적용할 수 있는 것을 이야기한다. + 기능을 개발했을 때 사이드 이팩트가 없도록

사실 윗 방법이 지금까지 젤 중요하다고 생각했던 것 같다. 주변 software 책들을 보면 다 그런 책들이다. 클린코드, 클린코더, 테스트주도개발, 단위테스트, 오브젝트 등등... 그런데 이번에 성능을 좋게 만드는 툴이나 방법들을 공부하는것도 매우 중요하다는 것을 알게 되었던 것 같다. 소프트웨어 개발 공부는 큰 프로젝트에서 가장 큰 힘을 발휘한다. 하지만 성능을 좋게하는 툴이나 방법들은 언제나 큰 힘을 발휘하며 그 영향은 개발자 뿐 아니라 사용자들에게도 큰 영향을 끼치게 된다. 첫 페이지 로드가 5초에서 1초가 걸리고 ci, cd 시간이 50% 단축된다. 어느것이 더 좋기에 여기에 시간을 더 투자해라. 라고 말하기에는 둘 다 너무 중요하다. 이번에 소프트웨어 개발 공부뿐 아니라 성능을 위한 툴, 방법들을 공부하는것도 매우 중요하다는걸 깨달아서 관련 공부도 게을리 하지 않아야겠다고 다짐해썯ㄴ

1. 나는 나의 길을 가야지​

회사에 퇴사 예정이신 분이 두분이나 계신다. 이전 회사 카사에서 동료가 떠나는 슬픔을 너무나 많이 겪었기에 다음 회사를 선택할 때 퇴사율을 최우선적으로 보았다. 당근은 퇴사율이 낮다고 이미 소문이 나있었고, 당근페이의 경우 설립이후 1년동안 퇴사자가 없었다는 점이 너무 마음에 들어 입사를 했다. 이제 페이가 생긴지 2년이 좀 넘어가는 시점에서 퇴사자가 나올만 했는데 막상 맞닥들이니 마음이 싱숭생숭하다. 카사에서는 일주일에 한 명씩 퇴사해서 어지간해서는 동요가 안되는데 이번에는 조금 슬펐다. 당근에서 근무하면서 느꼈지만 당근은 절대 망하지 않을꺼고 이력서도 많이 들어와 채용도 카사보다 매우 쉬울 것이다. 그럼에도 같이 일한 동료, 같이 일을 하지 않았어도 같은 사무실에 있었던 동료가 떠나는 일은 슬프다.

이전에도 말했듯이 슬프다고 해결되는건 아니다. 나는 묵묵히 나의 길을 가면된다. 내가 옳다고 생각하는 길. 지금 내가 해야하는 일. 주변에 휩쓸려 내가 나의 삶의 주체가 되지 못한다면 항상 슬픔속에서 살기에 나는 나의 길을 가면된다.

1. 타이탄의 도구들을 읽고​

타이탄의 도구들 책은 꾸준히 읽고 있다. 각잡고 읽기에는 시간이 아까워서 출퇴근하거나 이동할 때 조금씩 읽는 중인데 시간도 잘가고 의미있게 시간을 사용하는 것 같아서 기분이 좋다.

이번에는 내가 가장 좋아하는 내용인 "안테암불로"에 대해 나와서 이야기 하고자 한다.

너무 주구절절 적은 것 같은데 하나의 내용도 빠트리지 않고 싶지않아 모두 옮겨오고 싶었다.

일을 하다보면, 혹은 스터디나 프로젝트를 하다보면 매사 불평인 사람들이 있다. 무엇이 마음에 안드는지 하루종일 불평한다. 밥을먹다가도 퇴사하고 싶다고 말하고 심지어 동료에게 언제 퇴사할꺼냐고 묻기까지 한다. 이야기를 할 때 누군가를 욕하거나 비난한다. 하고싶지는 않지만 누군가가 맡아야 할 프로젝트를 담당하면 사무실의 모든 사람들이 듣도록 싫은 티를 낸다.

이전 글에도 적었듯이 화를 내고 불평하는건 어떤 문제도 해결되지 않는다. 그시간에 해결방법을 찾거나 누군가를 설득시키는데 시간을 쏟아야 한다.

안테암불로에 대한 이야기도 이어지는 이야기라고 생각한다. 모든건 태도의 문제이다. 모두가 하기싫은 일을 담당하더라도 거기에서 얻거나 배울 수 있는게 분명있고 미래에 도움이 된다. 하지만 그런건 누가 가르쳐주지는 않는다. 내가 태도만 바꾼다면 거기서 얻을 수 있는걸 발견할 것이다. 나아가 하기 싫은 일을 줄이거나 없애기 위한 방법들을 생각해낼지도 모른다.

평생 누군가에 밑에 있거나 안테암불로로 살아가라는게 아니다. "중요한건 태도"라는걸 말하고 싶은 것이다.

1. 와인 전문가과정 Level2 결제​

• 목요일 퇴근하고 내일배움 지원 받아 와인 전문가과정 Level 2 결제를 했다. 내일배움 8만원 지원받아 99만원에 결제했는데 이게.. 좋은건지 잘 모르곘다. 어중간하게 지원해주는 것 같은... 내일배움 지원받지 않고 정식 수강을 하면 8만원을 추가로 내야하지만 지각, 결석에 대한 패널티도 없고 결석하면 2번 무료로 보강수업을 해준다. 하지만 내일 배움은 결석 3번부터 패널티가 엄청쎄서 8만원 보다 더 많은 금액을 토해내야한다. 그리고 출석시 정각에 출첵을 해야하고 강의가 일찍 끝나도 원래 강의 끝나는 시간에 맞춰서 퇴실해야하고 까먹고 입실, 퇴실시 앱으로 체크하지 않으면 결석처리된다. 추가로 보강수업은 없고 보강수업을 하려면 1회에 8만원을 추가로 내야한다. 이런... 모두 지각하지 않는 가정하게 금전적인 이득이 있어서 장단점이 확실하다. 아무튼 이제 진짜 시작..

2. spring 이냐 flutter냐​

spring도 공부하고 flutter도 공부하다 보니 어디에 힘을 더 줘야할지 모르겠다. spring은 재미있기도 하고 나의 미래에 도움이 많이 될 것 같아서 공부하는거고 flutter는 단순 사이드 프로젝트를 위해 공부하는건데 지금 상황으로는 사이드 프로젝트에 진심이다보니 놓기 쉽지않다.

수능 공부할 때 과목이 하냐였는가? 몇 개나 되는 과목을 같이 공부했는데 이걸 못할소냐 싶어 모두 공부하기로 마음을 먹긴했다. 하지만 이걸 잘 수행하기 위해서는 매주 할당량을 정해놓아야 할 것 같긴하다.

1. WST 신청​

어제 신청했긴한데.. 와인전문가 과정 Level2에 신청했다. 아직 결제를 하지는 않아서 진정한 신청은 아니지만.. 내일배움에는 신청을 했다. 비용이 거의 100 만원이라 조금 부담되긴 하는데 취미 생활에 대한 투자라 생각한다.

결제는 직접방문해서 해야하는데.. 너무 귀찮다 ㅠㅠ 내일이나 금요일 오후에 가야지..

2. 크로스핏 끝​

5회 무료 + 10회 크로스핏이 드디어 끝났다! 갈때마다 너무 힘들었던 크로스핏.. 드디어 끝! 우연히 오늘 회사와 헬스장이 제휴를 맻어 싼 가격으로 등록할 수 있다고 공지가 떳다! 유후~ 1년 24만원.. 진짜 너무 싸서 내일 회사 동료분과 등록을 하러갈까 생각중이다. 운동은 정말 꾸준하게 해야한다! 안하면 활력도 없어지고 체력도 떨어진다. 이제 운동이 필수인 나이...ㅠ

1. 이성적으로 생각하고 말하기​

누군가의 참여나 동의를 구할 때 감정적으로 호소하는 경우가 있다. 웅변을 할 때 이런걸 배우기도 하고 연설을 할 때 이런 경우도 있다. 하지만 감정적으로 호소했을 때 다른 사람들 역시 감정적으로 동의하고 참여하게 된다. 그리고 이 감정은 식기 마련이다.

정말 오랫동안 이어 나가고 싶다면 감정적인 것 보다 이성적으로 설득하고 동의를 구하는게 좋지 않을까 생각한다. 그리고 선택하는 입장에서도 내가 감정적이지는 않았는지 정말로 좋은 선택인지 여러 방면으로 검토하고 선택해야 한다.

1. 성급함을 줄이는 연습​

요즘 Flutter 공부에 진심이다. dart 강의는 모두 들었고 flutter 강의를 25%정도 들은 상태인데 이런 강의를 듣다보면 빨리 코드를 짜고 싶어 손이 먼저 나가는 경우가 많다. 나도 그게 매우 심해서 강의를 제대로 다 듣지도 않고 프로젝트 만들어서 돌리는데 그러면 안된다. 나는 요즘 이것을 참는 연습을 하고 있다. 아직 스팩정리도 되지 않았는데 손부터 나가 코드를 작성한다던가 아직 완성도 안되었는데 공개를 한다던가 이런 조급함과 성급함이 몸에 베여있는 나는 무언가를 제대로 마치거나 완성시킨게 많이 없다. 그래서 이런걸 줄이고 싶어서 참는 연습을 하고 있다. 나의 욕구와 싸우는 중이다. 침착하게 꼼꼼하게 생각하고 행동하자!

이런 대표적인 기업이 애플이 아닌가 싶다. 애플은 제품을 낼때 절대로 성급하게 내지 않는다. 완성되지 않았다던가 부족한 부분이 있다면 절대로 출시하지 않는다. 이번 비전프로도 마찬가지다 부족한게 많아도 출시하면 많은 사람들이 구매할꺼고 거기서 많은 피드백을 받아 개선시킬 수 있겠지만 자신만의 기준을 세우고 그걸 넘지 않으면 프로젝트를 없애버리기 까지한다. (애플카, 폴더블.. 등) 이런 애플의 디테일에 많은 사람들이 감동하고 찬양하는 것 같다. 조금 무겁더라도 동작하는 기능이 조금 없더라도 다른게 완벽하니깐.. 생각하지 못한 부분들까지 많이 신경을 쓰니깐.

이런걸 보면 요즘 스타트업 마인드랑은 확실히 다르다. 요즘 스타트업들은 빠르게 출시하고 반응을 보고 빠르게 개선하는걸 장려하고 그런 사람들을 채용하려고 한다. 그게 성공할 수 있는 방법이라고 생각한다. 그런데 애플은 완전히 다른 길을 가는데 성공한걸까? 왜 스타트업의 빠른 출시 빠른 테스트 빠른 개선을 하는 린 형식의 방법을 만들떄 애플의 레퍼런스를 참고하지 않았을까? 그것도 세계 최고&최대 기업을 말이다. 당시에는 애플이 이렇게 큰 기업이 아니여서 그랬을까?

2. Flutter​

요즘 Flutter를 공부하고 있다. 예전에는 무조껀 react-native를 공부했을텐데 flutter 추천해주신 동료분의 말을 듣고 비교영상까지 보고나니 flutter가 진짜 좋다는걸 많이 느낀다. react-native는 js와 native가 bridge로 소통하여 native component를 그리고 제어하는 반면 flutter는 게임 엔진같은 rendering 엔진이 native에 embed되어 canvas같이 컴포넌트를 그린다. 그래서 native와 커뮤니케이션 하는 시간이 없고 os에 따라 다르게 동작하지 않는 장점이 있다. 그리고 vscode 개발경험이 너무 좋다. google pay 앱이 flutter로 만들어 졌다는 소식도 내가 flutter를 선택한 이유이기도 했다.

혹시나 multi-platform 앱 개발을 해야한다면 fe 개발자 이거나 js&react에 익숙하더라도 flutter로 개발해보길 추천한다. flutter architecture 공식 문서 이번주에 정독 해야겠다.

1. cli 개발​

회사에서 배포준비 과정을 자동화하기 위해 cli 툴을 개발했다. 오늘 기능은 거의 완성했고 남은 작업은 테스트랑 빌드해서 라이브러리로 만드는 것이다. 나름 재미있었는데 새로 사용해보는 라이브러리들이 재미있었다.

• Inquirer: A collection of common interactive command line user interfaces.
• listr: Terminal task list
• ink : 🌈 React for interactive command-line apps

이렇게 3개 사용했는데 ink 하나만으로 원하는거 다 할 수 있다. Inquirer이랑 섞어써도 좋은 것 같기도.. Inquirer는 interactive 한거에 최적화 되었고 ink는 react 컴포넌트를 ternimal에 그려주는데 할 수 있는게 엄청 많고 이쁘게 꾸밀 수도 있다.

나는 처음에 Inquirer로 대부분 구현을 한 상태라 ink로 모두 만들지는 못했고 섞어서 사용했다. interactive한 부분은 Inquirer를 사용했고 Summary나 Table 같이 보여줘야할 내용들은 ink를 사용했는데 자유도가 높아서 진짜 이쁘게 만들 수 있다.

그런데 ink 단점이 최신 버전들은 esm을 강제화해서 이전 버전들을 사용한게 살짝 흠이다. github sdk, jira sdk들이 esm을 지원하지 않다보니 허허.. 그래도 재밌게 개발했고 다음주에 팀에 공유하고 빨리 실 사용해보고 싶다 ㅎㅎ

ink 사용시 팁이 있다면 이전에 render된걸 지우고 싶지 않다면 cleanup을 한 후에 다른걸 render하면 된다.

const { cleanup } = render(<Summary1 />);
cleanup();
const { cleanup } = render(<Summary2 />);

2. 타이탄의 도구들을 읽고​

이제 사회생활에 물들었는지 타이탄의 도구들 책을 읽고 공감되는게 너무나 많다.

'강력한 의견과 침착한 태도를 가져라' 성공의 가장 큰 적은 '합의'다. 강력한 의견과 확신을 키우는 동시에 우리는 침착한 태도와 평정을 유지할 수 있어야 한다.

성과를 내는 날을 그렇지 못한 날보다 많이 만들 것​

• 내 목표는 빨리 실패하지 않는 게 아니다. 장기적으로 성공하는 것이다. 이 둘은 하늘과 땅만큼 서로 다르다.

최고 중에 최고로 평가받는 사람들도 내가 만나보니 별 것 없었다. 단 한가지 규칙만 배우면 충분하다. '성과를 내는 날을 그렇지 못한 날보다 많이 만들 것.'

예전 수능공부할 때 강사님이 말씀해주신게 있는데 공부를 할때 최고점을 목표로 하는게 아니라 최저점을 올리도록 공부해야한다는 것이였다. 운이 좋아 찍은게 맞았다던가 내가 공부했던 내용이 나와 좋은 점수를 받는게 중요한게 아니라 꾸준하게 모든것 들을 공부하여 어느것이 나오더라도 문제를 풀 수 있도록 나의 최저점을 올리는게 중요하다.

방향만 맞다면 천천히 가보자.​

내가 지금 무엇을 해야할지 생각하지 마십시오. '내가 지금 뭘 하고 있는 거지?'라고 틈틈이 질문을 던져야 합니다. 이상 신호를 감지하고 멈출 줄 아는 것. 그리고 좋은 신호를 얻기 위해 2분 정도 기다려줄 줄 아는 것. 그것이 곧 우리가 추구해야 할 성공입니다. "우리는 천천히 해도 충분하다. 우리가 저지른 실수들은 대부분 나태함 때문이 아니다. 야심과 욕심 때문이다."

일을 할 때 매 순간순간마다 질문을 던져야 한다. 내가 하고 있는게 잘하고 있는지. 이렇게 질문을 던지게 되면 전투가 아닌 전쟁을 보게되고 멀리서 나를 바라보게 된다. 나같이 급한 사람은 항상 매순간순간 내가 뭘 해야할지, todo-list만 적게 되는데 지금 이일을 하는게 맞을지 진짜 임팩트가 있는 일인지 충분히 검토하고 진행하는게 필요하다. 일을 위한 일을 해서는 안된다. 멀리 바라보는 연습은 진짜 중요한 것 같다.

감정적이면 안좋다.​

화를 내고 속상해하는 것은 백해무익하다. 그 시간에 '대안'을 찾는 것. 왜 그런 일이 일어났는지에 대한 질문을 통해 뭔가 배우고 얻어야 한다는 것이 매트의 지론이다. 그래서 나는 부정적인 감정에 휩싸일 때면 재빨리 '매트라면 어떻게 생각할까?'라는 질문을 던지면서 빠져나온다.

진짜 많이 느끼는건데 감정적인 사람은 여러모로 안좋은게 많은 것 같다. 문제가 생겼을 때 울고 속상해 하는것 보다. 이제 어떻게 해야할지 그 대안을 찾는게 훨씬 도움이 된다. 부정적인 생각보다는 어떤게 문제였는지 곱씹어보고 해결방안을 강구해야한다. 이전 회사 다닐때 사람들이 엄청 퇴사하고 회사가 망하기 직전까지 갔었다. 그때 힘들어하고 나의 결정을 후회하고 슬퍼하기 보다 앞으로 내가 어떻게 해야 문제를 해결할 수 있을지 고민했던게 훨씬 도움이 되었다.

1. 나는 많은게 귀찮다.​

나는 게을러서 손으로 하는걸 귀찮아 한다. 특히 단순노동, 반복작업등을 매우 싫어하는데 이런게 있을 때마다 자동화를 하려고 많이 노력한다.

대표적인게 테스트이고 여기서 테스트는 e2e 테스트이다. 배포하고 알파에서 기존기능들 잘 동작하는지 체크하는 작업이 너무 귀찮다. 배포할 때마다 배포태그 따기 -> jira ticket 만들기 -> slack 에 배포요청하기 이 3step을 진행하는데 이게 너무 귀찮아서 명령어 하나로 자동화가 되도록 작업중이다.

작업하게 되면 github js sdk, jira js sdk, slack js sdk를 모두 접하게 되는데 신선한 경헙이다 ㅎㅎ 단순 기능뿐 아니라 터미널에서 1,2,3 이렇게 선택해서 할 수 있는것도 만들 예정인데 재밌을 것 같긴한데.. 빨리 완성됐으면 ㅎㅎ

https://github.com/romkatv/powerlevel10k 초기에 설정하는 것 처럼 하고 싶다.

• tag을 입력해주세요.
• loop > 배포할 project를 선택해 주세요. (1,2,3,4, end)
• 배포 담당자를 선택해주세요. (1,2)

1. 올해 목표를 세워보자.​

한 해 목표는 보통 새해 첫 날에 세우기 마련인데 나는 좀 늦게 정하게 되었다. 그때는 하고싶은게 뚜렷하지 않았기 때문이다. 그냥 일이나 열심히 해야지~ 돈이나 모아야지~ 생각했던 것 같다.

저번달 회사 문화의 날에 와인 시음을 해보고 급 관심을 가지게 되었다. 집에가서 유튜브 영상도 찾아보고 오늘 와인 책까지 사게 되었다. 와인 테이스팅 코스 책인데 추천도 많이 했고 그림이 많아 이해하기 쉬워 보였다.

아무튼 올해 목표!

[취미]​

1. WSET Level 2 따기
2. 와인관련 앱 개발하기 (혼자서)

[회사]​

3. web-client project들 모두 하나로 합치기

단 몇 일만에 정해버린 올해 목표지만 지금은 의욕이 넘친다. 가보자고~

2. Flutter와 Dart​

앱을 만들어보고 싶다고 회사 동료분께 이야기하자 Flutter를 추천해주셨다. 객체지향 쓰는게 마음에 들기도 했고 빠르게 배워서 개발할 수 있다길래 기대되었다. 이전에는 RN을 사용했는데 이게... native 기능을 사용하려면 쉽지 않고 버벅이는게 눈에 보였다. 그런데 Flutter는 조금 낫지 않을까? 생각이 드는데 이건 개발해봐야 알 것 같다.

니꼴라스 선생님 강의 Dart, Flutter 신청완료!

3. 일찍 자고 일찍 일어나자​

규칙적인 생활을 하지 않으니 깨어있는 시간을 잘 사용하지 못하는 것 같다. 개인적으로 낭비되는 시간을 매우 싫어하기에 일찍자고 일찍 일어나는걸 실천해야하는데... 마음대로 되지가 않는다 ㅠ

1. "타이탄의 도구들"을 읽고​

지금 읽고 있는 책에 내가 겪은 고민들에 대한 내용이 나오다 보니 매우 공감하며 읽게 된다.

"트랜드는 중요하지 않다. 미래의 삶에 가장 중요한 역할을 하는건 '사명감'이다."

어떤 트랜드가 생겨나면 곧장 엄청난 사람들이 몰려든다. 그리고 많은 사람들이 몰리면 경쟁은 치열해지는 반면 차별화는 약해진다. 따라서 1등을 차지하지 못하면 트렌드는 의미가 없다. 망한다는 건 '특정 트렌드의 n번째 순위'를 기록하면서 사라진다는 뜻이다. 트랜드를 탐색하는 시간을 대신해 우리는 '사명'을 찾아야 한다. 사명이란, 다른 사람들이 해결하지 못한 문제를 찾아내는 것이다. 다른 사람들은 엄두도 내지 못하는 문제를 해결하는 노력이다.

자신의 일과 사업, 아이디어를 시작하고자 하는 사람들이 스스로에게 던져야 할 두 개의 질문은

• 첫째, 내가 매일 떠올리는 문제들 중 아직 아무도 해결하지 못한 것은 무엇인가?
• 둘째, '아직 아무도 세우지 않은 멋진 회사에 대한 아이디어는 무엇인가?'

최근에 시작한 프로젝트가 딱 트렌드를 쫓아 만들었던 것 같다. 최근 유행하는 아이디어에 타겟만 살짝 바꿔서 만들고 있다. 그런데 이런 유행이나 트랜드는 언젠가 식기 마련이고 다른 서비스와의 차별성은 점점 모호해질 것이다. 책에서 말했듯 1등이 아니면 사라질 것이 자명했다.

"타이탄의 도구들" 책이 아닌 서점을 둘러보다 잠깐 들어 읽었던 책에 이런 문장이 있었는데 기억에 남는다.(무슨 책인지는 기억이 안난다.)

사업을 할때는 역사적으로 꾸준하게 사랑받아 왔던걸 해야한다. 시간이 지나고 유행이 바껴도 변하지 않는걸 해야한다. 오랜세월 꾸준하게 사랑을 받아온 클래식같은..

사실 윗 문장은 그냥 그 책이 말했던 느낌만 담아 각색했다. 정확한 문장은 기억안나는데 말하고자 했던건 위와 비슷했다

2. fe 개발자가 spring boot를 공부하고 느낀점​

요즘 스프링을 공부하고 있다. 스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술 완강했고 스프링 핵심 원리 - 기본편는 60% 정도 들었다.

스프링을 공부하게된 이유를 말해보자면. 소프트웨어 공학 관련 저서들을 읽어 보면 대부분 백엔드 중심으로 쓰여졌다. 그래서 이를 프론트코드에 적용하려 노력해보지만 힘들기도 했고 참고할 만한 코드도 없다보니 흉내내서 개발하는 느낌이였다. 클린한 것 처럼 보이는 코드, solid를 꾸역꾸역 적용한 코드, 어디서 본 아키텍처를 흉내내어 적용한 코드를 작성했다. 책에서 소개된 개념과 방법들을 사용하기는 어려웠고 그 개념과 철할을 프론트 코드에 녹이려는 노력만 하게 되었던 것 같다. 이런 과정에서 저자가 말하려는 내용들, 그리고 널리 알려진 클린 아키텍처나 방법론들을 더욱 잘 이해하기 위해서 백엔드를 공부하게 되었다. 물론 이런 이유만 있는건 아니다. 혼자서 사이드 프로젝트를 만들고 싶기도 했고 백엔드 직군으로 전향 해보고 싶은 니즈도 조금은 있다.

스프링이 어떤건지는 "스프링 입문" 강의 하나로도 대부분 알게 되었던 것 같다. 스프링 빈과 의존관계 그리고 AOP는 충격이였다. 클래스 위에 annotation을 달아주는 것 만으로 스프링 컨테이너에 빈으로 등록되고 Configuration을 수정하는 것만으로 의존성을 자유롭게 주입하고 조립할 수 있었다. solid를 프론트에서 적용하면서 들었던 의문들... 의존성 역전원칙이 프론트에서 그렇게나 힘들었는데 스프링 사용하면 configuration만 수정하면 되었다. 너무나 쉬웠다. 그냥 스프링이 다해줬다. 프론트는 그런 라이브러리나 프레임워크가 없다. 그런걸 구현하려면 개발자가 코딩해야 했다. 그리고 관례적인 기법도 아니기에 여러 팀원들과 함께 개발하는 프로젝트라면 쉽지 않은 선택일 것이다.

스프링은 코드를 잘 설계할 수 있도록 발전 되었다면 react를 사용하는 프론트엔드 개발자는 dom을 만들고 js로 함수를 만들고 dom과 js를 직접 이어줘야 한다. 프레임워크가 해주는건 알아서 잘 렌더링해주고(변경이 많아도 모아서 한번에 렌더링 시킨다던가) 컴포넌트 라이프 사이클에 따른 훅을 제공해주는 것 뿐이다. 잘 설계하고 좋은 코드를 만들도록 발전한게 아닌 성능적인 부분을 개선시키기 위해 발전되었다. 아직 프론트 기술이 성숙하지 못했기 때문인 것 같기도하고 (관례적인 방식 같은게 없다. - service, controller, repository 같은..) 있어도 빠르게 바뀌고 누군가가 비판하며 새로운 걸 내고, 기존의 라이브러리 혹은 프레임워크가 업그레이드 되는게 아닌 deprecate 되어버리고 새로운게 나와버린다. 그래서 코드레벨에서 유지보수하게 잘 만들 수 있도록 발전되기는 커녕 다른 프레임워크에 먹힐까봐, 자리를 빼앗길 걱정에 성능을 개선하고 조금이라도 많은 기능을 개발하기에 급급한 것 같다는 생각이 든다.

김영한 선생님이 워낙 쉽게 가르쳐주시고 실무 경험 위주고 가르쳐 주셔서 좋았고, 백엔드 취준생의 느낌으로 공부하다 보니 재미도 있었던 것 같다. spring 재밌네.

Meet-Coder-Study/posting-review 에 오늘 올린글인데 긁어왔다 ^^

추가로 백엔드 엔지니어 분께서 코멘트를 남겨주셨는데

자바/스프링 공화국의 문제인거 같긴해요.. ㅋㅋㅋ

Spring Boot가 불편해보인다는건 없었을까요?? ㅋㅋㅋ 좋은점들만 적어주신거 같아서 ㅋㅋㅋ

어쩌면 나는 새로운 프레임워크나 라이브러리가 빠르게 나오고 바뀌는데 조금은 지쳐 spring에 대한 좋은점만 보였던 것 같기도 하다. 최근에 진행하던 프로젝트에서 e2e 라이브러리를 선택할 때 cypress에서 playwright로 바꾸고, css 라이브러리도 stitches를 사용했다가 emotion을 사용했다가 이제는 module css, module scss로 바꾸려고 계획하고 있고 web-client 프로젝트들을 cra (webpack)을 사용하다 vite로 바꿨고 이제는 ssr(next)로 프레임워크를 바꾸려고 준비중이다. 이런거에 조금은 지치지 않았나싶다.

1. "타이탄의 도구들"을 읽고​

명상을 하는 이유는 명확하다. 현재 상황을 직시하고, 사소한 일에 예민하게 반응하지 않고, 침착한 태도를 유지하는데 도움이 되기 때문이다.

• 나는 생각한다. 결정을 내릴 때 좋은 원칙들을 갖는 것, 그리고 나와 다른 사람들을 위해 좋은 질문들을 갖는 것.
• 나는 기다린다. 장기적인 계획을 기획할 수 있는 것. 멀리 보고 게임을 즐기는 것, 그리고 에너지를 낭비하지 않는 것.
• 나는 금식한다. 어려움과 시련을 견딜 수 있는 것. 나 자신을 온전히 회복해 큰 고통에도 관용과 평정을 잃지 않는 것.

사람들 중에 감정적이고 빠르게 의사결정을 하는 사람이 있다. 좋은게 좋은거라고 생각하고 이해하지 않고 넘어가는 사람이 있다. 하지만 이런 식으로 하는 의사결정은 그 과정중에 실패하게 된다. 감정적이였기에 이성이 돌아오고 다시 생각하는 기회가 왔을 때는 후회할 수도 있고 놓친 부분으로 인해 힘든 상황이 생길 수 있다. 이해하지 않고 넘어갔기에 다른 기회가 생기거나 문제가 생겼을 때 기회를 잡지 못하고 문제를 해결하지 못할 상황이 생길 수 있다.

주변 똑똑한 사람들을 보면 침착하고 여유롭다. 작은 전투를 보는게 아니라 지휘관으로써 전쟁을 본다. 내가 생각하지 못했던 부분을 캐치하고, 끊임없이 질문하여 정말로 옳은 방향인지 결정한다.

2. 사이드 프로젝트를 여러 번 하면서 느낀 점​

사이드 프로젝트를 여러 번 하면서 느낀 점은 주제선정이 매우 중요하다는 점이다. 주제를 제대로 정하지 못하면 프로젝트를 진행하다가 이게 정말 옳은가? 라는 질문에 사로잡히게 된다. 나의 소중한 시간과 에너지는 낭비되고 같이 하는 팀원들 때문에 어쩔 수 없이 프로젝트에 참여해서 끌려다니게 될 뿐이다.

프로젝트 주제는 오랜시간 고민하고 질문하여 정해야한다. 빨리 개발해야하기 때문에 빨리 정해야 한다던가 유명 스타트업 시작 이야기를 들며 여러 아이디어롤 빠르게 돌려봐야한다는 망상에서 벗어나야 한다. 여러 아이디어들도 정말 괜찮은지 여러번 질문하고 의심하며 정했을 것이다. 지금 프로젝트를 진행중이라면 감정적으로, 유행에 따라서, 빨리빨리로 주제를 정하지는 않았는지 의심해 볼 필요가 있다. 만약 그렇다면 프로젝트 진행중에 엎어지거나 프로젝트가 완성되더라도 이어나갈 가능성이 거의없다고 생각한다.

이런 이야기를 바탕으로 사이드 프로젝트를 처음에 시작할 때는 혼자 시작하는게 맞는 것 같다. 여러명이서 시작하게 되면 혹여나 잘못 진행되어 피봇해야할 상황이 생겨도 그게 쉽지 않다. 누군가는 원망하는 사람이 생길 것이다. 혼자서 아이디어와 생각을 철저히 의심하고 질문하며 정한 후 검증되었을 때 팀원들을 모집하는게 맞다.

사이드 프로젝트는 개발하는게 아니다. 프로덕트를 만드는 것이고 그게 개발의 결과물이 아닐 수도 있다. 사이드 프로젝트는 처음에 시작할 때 개발을 하는건 정말 나중에 해야하는 거라고 말하고 싶다. 처음에는 노션이나 간단한 공유 페이지로 끝내고 유저가 모이고 검증이 완료되면 개발을 시작하여 제대로된 결과물을 만들어야 한다. 개발에 필요한 시간과 노력 그리고 에너지를 함부로 낭비했다가 일찍히 나가 떨어질 수 도 있다.