본문으로 건너뛰기

· 약 6분

01. 운동

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

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

02. Mandalart

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

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

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

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

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

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

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

정보

'아마존의 (6-page-memo)'는 이미 너무 유명해서 잘 알려지기도 했는데요.

저희는 미팅을 하기 전에, 6장의 정리된 메모를 다같이 읽고 미팅을 시작하거든요.

미팅을 시작하면 처음 30분은 조용하죠. 그냥 조용히 읽는거에요.

각자 종이에 필기도 하고요. 30분이 지나면 토론 시작이에요.

파워포인트로 피티를 만드는 것보다 훨씬 낫습니다.

파워포인트의 본질은 남을 설득하는 거에요. . 무언가를 파는거죠. 팀원들끼리는 서로 아이디어를 '팔려고' 하면 안돼요. 본질을 이해하려고 노력하고, 문제를 해결하려는 태도를 가져야하죠

파워포인트의 또 다른 문제는 '만드는 사람'은 쉽고, '읽는 사람'은 어렵다는 거에요

저희가 쓰는 '6장의 글'은 정반대에요. 좋은 자료를 만들기 위해서 2주 이상이 걸릴 수도 있어요. 자료를 만들기 무진장 어렵죠.

글을 쓰고, 다시 쓰고 수정하고 또 쓰고... 사람들과 이야기를 하며 문제를 파악하고, '쓰는 사람'에게는 정말 힘든 일이에요.

하지만 글을 '읽는 사람'들은 쉽게 이해할 수 있죠.

6장의 잘 준비된 글을 읽으면서, 그 글 옆에 이런저런 질문들을 필기를 해둬요. 글을 다 읽으면, 질문에 대한 답이 벌써 나오거든요. 많은 시간을 절약할 수 있죠.

저희가 말하는 글은 정말 제대로 된 글을 쓰는 것을 말해요. 문단, 핵심 문장, 동사, 명사 모두 고려되어야 해요.

파워포인트와는 다르죠. 파워포인트는 몇개 '불렛포인트'만 떡하고 던지니까요. 그렇게 자신의 논리를 있어보이게 만들 수 있어요.

하지만, 글을 쓰면 허점이다 보이죠 그래서 더 열심히 미팅을 준비하게 되는 것 같아요. 그리고 과정에서 사고를 더 깊게 하고요.

그렇게 준비된 미팅이면, 미팅 준비자에게 뭔가를 물어볼 필요가 없어요.

이미 시작할 때 부터 모든 생각이 준비가 되있으니까요 장기적으로 시간을 아끼는 방법이에요.

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

· 약 9분

0. 24년 목표

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

1. 주식

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

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

"초수익 성장주 투자"

챔피언의 공통점

힘들게 번 돈을 투자하기 전에 그 돈을 잃지 않는 방법부터 생각해야 한다. 내가 지금까지 배운 점이 하나 있다면, 리스크 관리가 주식시장에서 꾸준한 성공을 거두는 데 가장 중요한 요소라는 것이다. 여기서 '꾸준한'이라는 단어에 주목하라.

누구라도 올바른 때, 올바른 곳에 있으면 단기적으로 성공할 수 있다. 그러나 프로와 아마추어, 시대를 초월한 전설과 일회성 기적을 가르는 것은 일관성이다.

타당한 원칙은 명확성을 제공한다.

성공은 특정한 날이나 달 또는 분기에 거둔 수익이 아니라, 장기적으로 지켜내는 수익으로 좌우된다. 타당한 리스크 관리 원칙을 준수하면 수익을 지킬 수 있다.

"손실은 일찍 줄이고, 수익은 최대한 키워라" 손절이 성공의 핵심이다.

오랫동안 매매를 하다 보면 새로운 기법을 습득하는 과정에서 관점을 읽기 쉽다. 주의하지 않으면 기본적으로 근본적인 원칙들이 의식 또는 보다 은근하게는 무의식 속에서 부수적인 것으로 보일 수 있다. 리스크 관리의 기본적인 요소는 실력을 키운 다음에 버려도 되는 보조적 수단이 아니다. 오히려 머릿속에서 계속 새롭게 되새기면서 완벽하게 다듬어야 한다.

성공의 핵심 요소는 다른 사람보다 기본을 잘 지키고 그 일을 계속하는 것이다. 뛰어난 성과는 근본적인 원칙의 확고한 토대 위에서 이뤄진다.

큰 오류를 피하라

경제학자들은 수익 종목을 너무 빨리 처분하고 손실 종목을 너무 오래 갖고 있는 경향을 '처분 효과'라 부른다.

  • 투자자들은 보유 주식이 큰 수익을 얻을 때까지 가능성보다 큰 손실이 날 때까지 둘 가능성이 높다. 즉, 손실 종목을 너무 오래 갖고 있는 반면, 수익 종목을 너무 빨리 판다.
  • 주가가 오른 종목보다 내린 종목을 추가로 매수할 가능성이 높다. 투자자들은 주가가 하락했을 때 선뜻 베팅을 늘린다.
  • 투자자들은 적은 손실보다 적은 수익을 취할 가능성이 높다.

비자발적 장기 투자자가 되지 마라

투자자들은 실수를 인정하기 싫어서 합리화한다. 그들은 맞았을 때는 '트레이더'가 되었다가 틀렸을 때는 '장기 투자자'가 된다. 그들은 주가가 예상과 다르게 움직이면서 손실이 쌓이기 시작하면 갑자기 장기 보유를 결심한다. '비자발적 장기 투자자'가 되는 것이다.

카지노 방문

꾸준하게 수익을 내는 사람은 포지션이 강해질 때 베팅을 키우고, 확률이 불리할 때 발을 뺀다. 반면 꾸준하게 손실을 내는 사람은 기적을 바라고, 패배의 스릴을 즐기면서 모든 큰 판에서 씁쓸한 결말을 맞을 때까지 버틴다.

손실을 제한하면 절제력이 부족한 대다수 투자자를 앞지를 수 있다. 최고의 투자자는 실수를 인식하고 담담하게 손절한 후 다른 거래에 집중한다. 그래서 그들은 다음 기회를 위한 자금을 보존한다.

시장의 모든 움직임에 동참할 필요가 없다. 엄격한 기회주의자가 되어라. 까다로운 태도로 아주 신중하게 진입 지점을 골라라. 행동하기 전에 확률이 유리해질 때까지 기다려라. 인내심과 절제력을 발휘하면 당신보다 절제력과 실력이 부족한 사람들로부터 이득을 취할 수 있다.

재난을 보장하는 관행

재산이 사라지는 것을 보면서도 손절을 통해 스스로를 보호하지 않는 것도 좋지 않은데, 손실이 나는 투자에 더 많은 돈을 넣는 것은 더 나쁘다. 나쁜 포지션에 아까운 돈을 던지는 행위는 빈곤으로 가는 가장 빠른 길 중 하나다. 우리는 이를 '물타기'라 한다. 주식 중개인들은 종종 손실이 난 종목을 더 사라고 고객을 꼬드긴다. 자신이 한 부실한 추천을 합리화하는 데 있다. 그들은 물타기를 하면 매수 단가가 낮아진다고 말한다. 물타기를 하면 주가가 계속 하락했을 때 손실이 2배로 커지는 것을 제외하면 얻은 것은 하나도 없다. 손실을 끌어안고 있으면서 계속 늘어나게 만들거나 물량을 늘리는 행위는 아마추어들이나 하는 자기 파괴적인 행동이다.

고성장주를 정확한 지점에서 매수한 후에 주가가 하락한다고 해서 더 매력적으로 변하는 것은 아니다. 오히려 매력이 떨어진다. 많이 떨어질수록 덜 매력적이다. 주가가 긍정적으로 반응하지 않는다는 사실은 시장이 해당종목을 무시한다는 적색경보다.

· 약 4분

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% 할인행사를 하고 있어서 구매하고자 한다. 이번에는 진짜 열심히 공부해서 좋은 성적 받아야지!

· 약 1분

0. 와인 앱

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

1. 주식 스터디

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

2. 문렌더 키보드

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

· 약 2분

0. 일상

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

· 약 1분

0. 주식스터디

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

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

1. smartfarm

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

2. 자기계발 모임

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

· 약 15분

01. 습관의 힘

아주 작은 습관의 힘

Chapter 06 환경이 행동을 결정한다

환경은 인간의 행동을 형성하는 보이지 않는 손이다. 우리 모두가 성격이 다르긴 해도 특정한 행동들은 특정한 환경 아래서 반복적으로 일어나곤 한다. 교회에서는 속삭이며 대화를 나누고, 어두운 길에서는 주변을 살피며 방어적인 태도로 행동한다. 이처럼 일반적인 변화 대부분이 내적이 아닌 외적 환경에 따라 일어난다. 우리는 주위를 둘러싼 세계 때문에 변화한다. 습관은 모두 맥락을 따른다.

우리가 매일 하는 많은 행동들은 목적이나 선택에 따른 것이 아니라 대부분 확실하게 눈에 보이는 선택지라는 이유로 실행된 것이다.

인간은 감각신경 체계로 인지한다. 하지만 인간의 온갖 감각 능력들 중 가장 강력한 것은 시각이다. 이런 이유에서 우리가 '보는' 것에 작은 변화가 일어나면 우리가 '하는' 일에 큰 변화가 일어날 수 있다. 따라서 생활 및 직장 환경에 생산적인 신호들을 채우고 비생산적인 신호들을 제거하는 것은 매우 중요하다.

어떤 습관을 삶의 큰 부분으로 만들고 싶다면 그와 관련된 신호를 자주 인지할 수 있는 환경을 만들어라. 지속적인 행위 대부분은 대개 다양한 신호들을 갖는다.

환경 디자인은 우리가 자신을 통제할 수 있게 해주고, 자기 삶의 설계자가 되도록 만들어준다.

왜 집보다 스타벅스에서 공부가 더 잘 될까

습관을 촉발하는 신호는 처음에는 매우 특정한 것일 수 있다. 하지만 시간이 지나면 우리의 습관은 한 가지 촉매에 따른 것이 아니라 행동을 둘러싼 전체 '맥락'과 연결되기 시작한다. 예를 들어 사람들은 집에 혼자 있을 때보다 사회적 상황에서 술을 더 많이 마신다.

이처럼 우리의 마음은 습관을 집, 사무실, 체육관같이 그 행위가 일어나는 장소들에 연결한다. 각각의 장소는 특정 습관이나 일상 행위들에 연결되고 강화된다. 우리는 책상, 주방 조리대, 침실에 놓인 용품들과 특정한 관계를 맺는다.

우리는 특정한 맥락에 특정한 습관을 연결시킴으로써 스스로 훈련할 수 있다. 불면증과 관련된 한 가지 연구에서 과학자들은 불면증 환자들에게 피곤할 때만 침대에 누우라고 지시했다. 이들은 졸릴 때까지 다른 방에 가서 앉아 있어야 했다. 시간이 지나자 이들은 침대를 수면 행위와 연결시키기 시작했고, 침대에 누웠을 때 빨리 잠들 수 있었다.

맥락의 힘은 행동을 변화시키는 중요한 전략을 하나 더 알려준다. 새로운 환경에서는 습관을 바꾸기가 쉽다는 것이다. 우리가 현재의 습관을 계속 이어가도록 몰아가는 촉매들과 신호들에서 탈출하게 도와주기 때문이다. 색다른 커피솦, 공원 벤치, 평소 거의 이용하지 않는 방구석 자리 등 새로운 장소로 가서 새로운 습관을 만들어보라.

가능하다면 한 가지 습관이 일어나는 맥락을 다른 것과 섞지 않도록 하라. 맥락들을 섞기 시작하면 습관들도 뒤섞인다. 그러면서 그중 더 쉬운 일을 하게 된다.

Chapter 09 왜 주위 사람에 따라 내 습관이 변할까

우리의 행동을 결정하는 세 집단

다른 사람들과 협력하고 유대 관계를 맺으면 안전이 보장되고 짝짓기 가능성이 높아지며, 자원에 대한 접근성도 높아진다. 찰스 다윈은 "역사적으로 볼 때 타인과 협력하고 가장 효율적으로 임기응변하는 법을 배운 사람이 승리했다."라고 썼다.

아주 어린 시절의 습관은 '선택하는 것'이 아니라 '모방한 것'이다. 우리는 일반적으로 친구, 가족, 교회 또는 학교, 지역사회와 국가로부터 넘겨받은 대본을 따른다. 이런 집단에는 각자의 가치관과 기준들이 존재한다. 언제 결혼을 해야 하는지, 결혼을 할지 말지 등에 대한 기준들이다.

이런 사회적 규범들은 보이지 않는 규칙으로 작용해 매일의 행동을 이끈다. 우리는 이것들을 마음속 가장 중요한 곳에 두지는 않더라도 늘 염두에 두고 산다. 종종 우리는 생각하거나 의문을 품지 않고, 어떨 때는 기억해내지 않고도 자기 문화에 있는 습관을 따른다.

집단을 따르는 것은 대부분 부담스럽게 느껴지지 않는다. 모두 어딘가에 소속되길 원한다.

우리는 특히 다음 세 집단의 습관을 모방한다.

1. 가까운 사람을 모방한다.

가까운 사람들은 우리의 행동에 가장 강력한 영향을 끼친다.

우리는 주변 사람들의 습관을 보고 배운다. 부모님이 논쟁에 대처하는 방식, 또래들이 다른 사람들과 시시덕거리는 방식, 동료 직원들이 결과를 얻어내는 방식등을 모방한다.

우리는 가까운 사람일수록 그 사람의 습관을 모방하기 쉽다. 1만 2,000명을 32년간 추적 조사한 획기적인 연구에 따르면 "비만이 될 확률은 친구가 비만일 경우 57퍼센트로 증가했다."

더 나은 습관을 세우는 가장 효율적인 방법 중 하나는 자신이 원하는 행동이 일반화된 집단에 들어가는 것이다. 매일 어떤 습관을 행하는 사람들을 보고 있으면 그 습관을 새로이 습득하기 쉽다.

우리를 둘러싼 문화는 무엇이 '일반적'인지에 관한 기대치를 설정한다. 따라서 어떤 습관을 들이고 싶다면 그런 습관을 지닌 사람들 사이에 있어라. 그러면 함께 성장할 것이다.

습관을 매력적으로 만들고 싶다면 자신이 원하는 행동이 일반적인 집단, 자신과 공통점을 가지고 있는 집단으로 들어가라.

무리에 소속되는 것보다 더 동기를 지속시키는 것은 없다. 그것은 개인적으로 추구하는 것을 공통의 것으로 바꿔준다. 무리에서 정체성이 공유되면 나의 개인적인 정체성도 강화된다. 따라서 목표를 달성한 뒤에도 집단의 일원으로 남아 있는 것이 습관을 유지하는 데 중요하다. 새로운 정체성을 끼워 넣고 행동을 장기적으로 지속하는 걸 돕는 건 우정과 커뮤니티다.

2. 다수를 모방한다

어떻게 행동해야 하는지 확실하지 않을 때 우리는 집단을 보고 행동 방향을 찾는다. 계속해서 주변 환경을 살피고 의문을 품는다. '다른 사람은 어떻게 하고 있지?' 사람들이 아마존, 옐프, 트립어드바이저의 리뷰를 확인하는 이유는 가장 좋은 것을 모방하고 싶어서다. 이는 대부분 영리한 전략이다. 다수가 증거로 보여주기 때문이다.

하지만 여기에는 문제가 있다. 집단이 하는 일반적인 행동은 종종 개인이 욕망하는 행동을 제압한다. 예를 들어 어느 집단에서 효율적으로 땅콩을 쪼개는 방법을 습득한 침팬지는 그보다 덜 효율적인 방법을 사용하는 새로운 집단을 옮겼을 때, 그 무리에 섞이기 위해 전에 사용하던 훨씬 나은 방법을 사용하지 않는다.

인간 역시 마찬가지다. 우리는 집단의 규범을 따라야 한다는 어마어마한 내적 압력을 받는다. 무리의 일원이 되는 건 종종 논쟁에서 이기는 것, 똑똑해 보이는 것, 진실을 찾아내는 것보다 보상이 훨씬 크다. 대부분 우리는 홀로 옳은 길을 따르기보다 집단과 함께 잘못되는 길을 선택한다.

우리가 속한 문화와 다른 방향으로 달리려면 또 다른 노력이 필요하다. 습관을 바꾸는 것이 무리에 도전하는 일이 될 때 변화는 매력적이지 않다. 반대로 습관을 바꾸는 것이 무리와 합치될 때 변화는 무척이나 매력적인 것이 된다.

3. 유력자를 모방한다.

성공한 사람의 행동을 모방하려고 하는 것은 성공을 욕망하기 때문이다. 일상의 많은 습관들은 자신이 찬탄하는 사람들을 모방한 것이다. 자기가 속한 산업에서 가장 성공한 회사의 마케팅 전략을 모방하고, 가장 좋아하는 제빵사의 조리법대로 음식을 만든다. 상사의 대화법을 흉내 낸다. 자신이 선망하는 사람을 모방한다.

그렇게 해서 지위가 높아진 사람들은 인정과 존경, 타인의 칭찬을 즐긴다. 우리는 어떤 행동이 인정, 존경, 칭찬을 가져다준다면 그 행동에 매력을 느낀다. 또한 우리는 자신의 지위를 낮출 만한 행동들을 피하고 싶어 한다. 울타리를 손질하고 잔디를 깎는 것은 이웃에게 게으른 모습을 보이지 않고 싶어서다. 우리는 계속해서 다른 사람들이 자신을 어떻게 생각할지 궁금해하고, 그 대답에 근거해 행동을 수정한다.

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

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

· 약 4분

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이 가능한지, 자동으로 수확할 수 있는지 고민해야 한다.
  • 자연에너지를 충분히 활용하지 않는다면 전기에너지가 많이들어 부담이 될 것 이다.
    • 태양광, 바람, 실외 온도를 충분히 활용해야 한다.
  • 병충해 중 충해는 어떻게든 생기기에 대비를 해야한다.

· 약 5분

0. 스마트 팜

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

꿈보다 목표가 중요하다

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

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

1. 목표와 원칙

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

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

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

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

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

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

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

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

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

· 약 3분

0. 일상

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

1. 회사

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

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

· 약 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

3. 공부

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

· 약 4분

0. 와인

와인그래프 티타임

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

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

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

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

1. 멘토링

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

2. 스마트 팜

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

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

· 약 4분

0. 와인

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

WSET Level 2

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

점수항목
85% 이상Pass with distinction(최우수 합격)
70% ~ 84%Pass with merit(우수 합격)
55% ~ 69%Pass(합격)
45% ~ 54%Fail(불합격)
44% 이하Fail unclassified(불합격 (미 분류 대상))

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

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

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

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

와인 앱 출시

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

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

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

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

1. 멘토링

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

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

2. 새로운 프로젝트

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

· 약 3분

1. 와인앱 출시

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

img

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

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

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

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

· 약 6분

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…
  1. 기타 질문
  • production, beta, alpha, userid 같은 것 들도 비즈니스 로직이 아닌가?
    • 회사의 정책이고 자주 변하는게 아니기 때문에 common에 개념이 들어가도 되지 않을까?

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

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

결론

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

· 약 3분

0. 와인 마지막 수업

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

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

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

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

· 약 2분

1. 멘토링

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

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

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

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

· 약 11분

0. 일상

와인 자격증 시험을 쳤다.

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

사이드 프로젝트

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

자기계발

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

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

part 1 아주 작은 습관이 만드는 극적인 변화

Chapter 02 정체성, 사람을 움직이는 가장 큰 비밀

습관을 바꾸기가 어려운 것은 두 가지 이유 때문이다. 첫째, 변화하고자 하는 대상이 잘못되었다. 둘째, 변화의 방식이 잘못되었다. 이 챕터에서는 첫 번째에 대해 이야기할 것이다. 변화가 일어날 수 있는 수준은 세 개의 층으로 이뤄져 있다.

첫 번째 층은 '결과'를 변화시키는 것이다. 살을 뺀다던가 책을 낸다거나 챔피언십을 따낸다는 하는 것이다. 우리가 세운 목표 대부분은 이 단계와 연관되어 있다.

두 번째 층은 '과정'을 변화시키는 것이다. 이 층은 우리의 습관과 시스템을 변화시키는 데 맞춰져 있다. 매일 체육관에서 새로운 운동을 해본다든가, 작업 흐름을 개선하고자 책상에 널린 잡동사니들을 정리한다든가 하는 것이다. 우리가 세운 습관 대부분이 이 단계와 연관되어 있다.

세 번째 층은 '정체성'을 변화시키는 것이다. 이 층은 우리의 믿음을 변화시키는 데 맞춰져 있다. 세계관, 자아상, 자신과 타인에 대한 판단같은 것들이다. 우리가 가지고 있는 믿음, 가설, 편견들 대부분이 이 단계와 연관되어 있다.

결과는 우리가 얻어낸 것이며, 과정은 우리가 해나가는 것이다. 그리고 정체성은 우리가 맏고 있는 것이다.

많은 사람들이 자신이 얻고자 하는 것에 초점을 맞춰 습관을 변화시키려고 한다. 그러나 이런 태도는 결과 중심의 습관을 형성한다. 그러나 지속하기 위해서는 정체성 중심의 습과능ㄹ 세워야 한다. 이는 내가 어떤 사람이 되고 싶은지에 집중하는데서 시작한다.

우리는 뭔가를 개선하고자 할 때 정체성 변화를 생각하지 않는다. 그저 이렇게 생각할 뿐이다. "날씬해지고 싶어(결과). 이번 다이어트를 계속하면 날씬해질 거야(과정)." 목표를 정하고, 그 목표를 이루기 위해 자신이 해야 할 행동만 생각한다. 자신을 움직이게 하는 '믿음'에 대해서는 생각하지 않는다. 스스로를 바라보는 방식을 바꾸지 않고는 아무것도 변하지 않음을 깨닫지 못한다.

나에게 적합하지 않은 행동은 오래 유지되지 않는다. 돈을 많이 벌지만 내가 버는 것보다 쓰는 걸 더 잘하는 사람이라면 계속 돈을 쓰는 쪽으로 이끌릴 것이다. 더 건강해지고 싶은데, 뭔가를 성취하는 것보다 편안함을 우선시하는 사람이라면 운동보다는 쉬는 쪽으로 이끌릴 것이다.

근본적인 믿음이 변화하지 않는다면 습관을 바꾸기란 무척이나 어렵다. 새로운 목표와 계획을 세웠지만 자신이 어떤 사람인지 변화하지 않았다면 말이다.

본질적인 동기가 최종적인 결과로 나타나는 것은 습관이 정체성의 일부가 될때다. "나는 이런 것을 '원하는' 사람이야."라고 말하는 것은 "나는 '이런' 사람이야"라고 말하는 것과는 매우 다르다.

자신의 어떤 모습에 자부심을 가질수록 그와 관련된 습관들을 유지하고 싶어진다.

진정한 행동 변화는 정체성 변화에 있다. 우리는 무언가가 되고 싶어 그와 관련된 습관을 시작한다. 하지만 그 습관을 꾸준히 해나가는 건 오직 그것이 자기 정체성의 일부가 될 때뿐이다.

어느 날 너무 바쁘거나 지치거나 부담되어서, 또는 수백 가지 다른 이유로 우리는 습관을 유지하기가 힘들어진다. 하지만 장기적으로 그 습관을 유지하지 못하는 진짜 이유는 자신의 자아상과 반대이기 때문이다. 이것이 어떤 한 가지 모습의 정체성에 집착하면 안되는 이유다. 자신이 바라는 최고의 모습이 되려면 자신의 믿음들을 끊임없이 편집하고, 자기 정체성을 수정하고 확장해야만 한다.

인생을 바꾸는 두 가지 질문

정체성은 습관에서 나온다. 우리는 어머니 배 속에서부터 어떤 정체성을 가지고 태어나진 않는다. 정체성은 경험을 통해 습득되고 익숙해진다.

엄밀히 말하면 습관은 정체성을 만들어나간다.

행위를 반복해나갈수록 그 행위와 연관된 정체성은 강화된다. '정체성'이라는 말은 '실재하다'라는 의미의 라틴어와 '반복적으로'를 뜻하는 'identidem'에서 파생되었다. '반복된 실재'라는 말이다.

나 자신의 정체성이 지금 당장 무엇이든 간에 우리는 오로지 그것을 믿는다. 정체성에 대한 증거를 가지고 있기 떄문이다.

자주 반복하는 행동도 습관이 되며, 대개 그런 반복이 습관 형성에 매우 중요한 요소가 된다. 삶에서의 경험 하나하나는 자아상을 조정한다. 그렇지만 공을 한 번 찼다고해서 누구나 스스러를 축구하는 사람으로 여기진 않는다. 하지만 이런 행위를 반복해나가면 증거가 서서히 쌓이고, 자아상이 변화하기 시작한다.

한 번의 특별한 경험은 그 영향력이 서서히 사라지지만, 습관은 시간과 함께 그 영향력이 더욱 강화된다. 즉, 습관은 정체성을 형성하는 가장 큰 증거가 되는 것이다. 이런 관점에서 습관을 세운다는 것은 자기 자신을 만들어나가는 과정이기도 하다.

이는 점진적인 빈화다. 아주 작은 노력 하나, 완젼히 변화하겠다는 결심하는 것만으로 우리는 변화하지 않는다. 우리는 조금씩, 매일매일, 하나하나씩 변화한다. 자아는 아주 미세하게 지속적으로 진화해나간다.

· 약 20분

0. 일상

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

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

part 1 아주 작은 습관이 만드는 극적인 변화

Chapter 01 평범했던 선수들은 어떻게 세계 최고가 되었을까?

매일 1퍼센트씩 달라졌을 뿐인데

어떤 중요한 순간은 과대평가되는 반면, 매일의 사소한 진전들은 과소평과되기 쉽다. 흔히 우리는 대단한 행위가 있어야만 성공할 수 있다고 확신한다. 살을 빼고, 회사를 설립하고, 책을 쓰고, 챔피언십을 따내는 등 어떤 목표들을 이루려면 어마어마한 개선이 있어야 한다고 생각하며 자신을 압박한다.

1퍼센트의 성장은 눈에 띄지 않는다. 가끔은 전혀 알아차리지 못할 때도 있다. 하지만 이는 무척이나 의미있는 일이다. 특히 장기적인 관점에서는 더욱 그렇다. 지극히 작은 발전은 시간이 흐르면 믿지 못할 만큼 큰 차이로 나타날 수 있다.

우리는 작은 변화들을 무시한다. 그 순간에는 그리 중요하게 보이지 않기 때문이다. 결과는 당장 눈에 보이지 않는다. 그렇다 보니 우리는 쉽게 이전의 일상으로 돌아간다.

불행히도 변화는 느리게 일어난다. 우리는 곧 나쁜 습관으로 돌아간다. 오늘 정크푸드를 먹었다 해도 체중계 바늘이 바뀌진 않는다. 오늘 밤늦게까지 일하고 가족을 소홀히 한다 해도 가족은 우리를 이해해준다. 오늘 할 일을 내일로 미뤄도 대개는 제시간에 끝마치게 된다. 결심은 잊히기 쉽다.

지금 당장 어떤 방법이 성공적이든 성공적이지 않든 그것이 중요하진 않다. 중요한 건 우리가 가지고 있는 습관이 성공으로 가능 경로에 있느냐는 것이다. 현재 일어난 결과보다 지금 어디에 서있느냐가 훨씬 더 중요하다.

결과는 그동안의 습관이 쌓인 것이다. 순자산은 그동안의 결제적 습관이 쌓인 결과다. 몸무게는 그동안의 식습관이 쌓인 결과이고, 지식은 그동안의 학습 습관이 쌓인 결과다. 우리는 우리가 반복해서 했던 일의 결과를 얻는다.

자신의 인생이 어디로 갈지 궁금한가? 자잘한 발전과 퇴보를 그래프로 그려보고 매일의 선택이 10년, 20년 후를 어떻게 그려나가는지 확인해보라. 당신은 매달 버는 것보다 덜 쓰는가? 매주 체육관에 가는가? 매일 책을 읽거나 새로운 것을 배우고 있는가? 이런 작은 분투가 우리의 미래를 규정한다.

시간은 성공과 실패 사이의 간격을 벌려놓는다. 우리가 어디에 시간을 들였든 그것은 복리로 증가한다.

낙담의 골짜기를 견뎌라

앞에 있는 테이블에 얼음덩어리가 하나 있다고 해보자. 현재는 영하 4도 정도지만 방은 서서히 따뜻해지고 있다. 영하 4도, 영하 3도, 영하 2도, 영하 1도, 아직 테이블에는 얼음덩어리가 있다. 0도가 된다. 얼음이 녹기 시작한다. 온도는 그전까지도 계속 올랐지만 변화가 없어 보였다. 그러나 영하 1도에서 1도가 더 오르자 거대한 변화가 나타나기 시작한다.

이처럼 중대한 돌파구의 순간이란 대개 이전의 수많은 행위들이 쌓이고 쌓인 결과다. 이런 것들이 잠재돼 있던 힘을 발휘해 주요 변화를 일으킨다. 이런 패턴은 어디서나 나타난다. 암 종양은 80퍼센트 성장할 떄까지 발결되지 않고 퍼져나가다가 한 달 만에 신체 전체를 점령한다. 대나무는 처음 5년간 땅속 광범위한 지역에 걸쳐 뿌리를 내리는 동안에는 거의 눈에 띄지 않지만 이후 6주 만에 지상 30미터 높이로 자란다.

습관 역시 대부분 중대한 한계점에 도달해서 새로운 성과를 보이기 전까지는 아무 차이가 없는 것처럼 보인다.

꾸준한 습관을 세우기 어려운 이유는 어렷 있지만 이런 과정의 어려움도 그중 하나다. 변화는 극히 작고 눈에 보이는 결과는 없으니 쉽게 그만두는 것이다. 의미있는 차이를 만들어내고 싶다면 정체기, 그러니까 여기서 '잠재력 잠복기'라고 부르는 기간을 돌파할 때까지 습관을 유지해야 한다.

마침내 잠재력 잠복기를 돌파하고 나면 모르는 사람들은 하룻밤 사이에 성공했다고 말할 것이다. 세상은 그 모든 과정이 아니라 가장 극적인 사건만 본다. 하지만 자신은 얼마나 오랫동안 그 일을 해왔는지 안다. 한 발자국도 나아가지 못한 것 같을 때도 계속 밀어붙여서 결국에는 오늘이 만들어졌음을 안다.

목표 따윈 쓰레기통에 던져버리기

흔히 몸매를 가꾸든, 회사를 운영하든, 걱정을 덜하고 더욱 편안하게 지내는 것이든 원하는 것을 얻으려면 구체적이고 실행 가능한 목표를 세워야 한다고 말한다.

나 역시 습관에 대해 오랫동안 이런 관점에서 접근했다. 습관 하나하나는 곧 도달해야 할 구체적인 목표였다. 하지만 그런 목표들 중에서 성공한 것은 극히 일부였고 대부분 실패했다. 나는 내가 얻어낸 결과들이 처음에 세웠던 목표와는 거의 관계가 없고, 사실 모든 것은 시스템에 달려 있다는 것을 깨달았다.

시스템과 목표의 차이는 무엇일까? 목표는 우리가 얻어내고자 하는 결과이며, 시스템은 그 결과로 이끄는 과정이다.

  • 감독의 목표는 챔피언십을 획득하는 것이다. 그렇다면 시스템은 선수들을 선발하는 방식, 코치들을 다루는 방식, 실행하는 방식이다.
  • 기업가의 목표는 수백만 달러짜리 사업을 세우는 것이다. 그렇다면 시스템은 제품이나 서비스에 대한 아이디어를 테스트하는 법, 직원을 고용하는 법, 마케팅 캠페인을 하는 법이다.

이제 흥미로운 질문을 해보자. 목표를 완전히 무시하고 오직 시스템에만 집중한다면 그래도 성공할까? 예를 들어 당신이 야구 코치인데 챔피언십을 획득하겠다는 목표를 생각하지 않고 팀에 매일 어떻게 연습할 것인지에만 집중한다면 그래도 결과를 낼 수 있을까?

나는 '그렇다'고 생각한다.

어떤 스포츠든 목표는 최고의 점수를 달성하는 것이다. 하지만 그렇다고 해서 경기 내내 점수판만 응시하는 건 말도 안되는 것이다. 실제로 승리할 유일한 방법은 매일 더 나아지는 것 뿐이다.

미국 프로 미식축구 대회 슈퍼볼 3회 우승자 빌 윌시는 말했다. "점수를 신경쓰는 건 점수뿐이다." 이는 삶의 다른 영역도 마찬가지다. 더 나은 결과를 내고 싶다면 목표를 세운는 일은 잊어라. 대신 시스템에 집중하라.

목표가 무용지물이라는 말일까? 물론 아니다. 목표는 방향을 설정하는 데 필요하며 시스템은 과정을 제대로 해나가는 데 필요하다. 그러나 목표를 생각하느라 너무 많은 시간을 들이고 시스템을 고안하는 데는 시간을 투자하지 않을 때 문제가 발생한다.

문제 1. 성공한 사람도, 성공하지 못한 사람도 목표는 같다.

목표 설정에 집중하다 보면 심각한 승자 편향적 사고에 매몰될 수 있다. 우리는 승리한 사람들에게 집중한다. 야심 찬 목표가 그들의 성공을 이끌었다고 추측하는 실수를 범하고, 누구나 목표를 가지고 있지만 모두가 성공한 것은 아니라는 사실을 간과한다.

올림픽에 출전한 선수는 모두가 금메달을 원한다. 입사 지원자 모두가 구직을 바란다. 성공한 사람도, 성공하지 못한 사람도 목표는 같다. 목표는 승자와 패자를 가르는 차이가 될 수 없다. 목표는 늘 거기에 있었다. 결과에 차이가 생긴 건 지속적으로 작은 개선들을 만들어내는 시스템을 시행한 것, 그뿐이었다.

문제 2. 목표 달성은 일시적 변화일 뿐이다.

지저분한 방 안에 있다고 생각해보라. 방을 치우리고 목표를 세운다. 그리고 당장 청소하는 데 필요한 에너지를 끌어올려 방을 치웠다. 하지만 대충대충 청소하거나 뭐든 잘 버리지 못하는 사람이라면 방은 또 지저분해질 것이다. 이렇듯 계속 같은 결과가 나타난다는 것은 이런 결과의 배경이 된 시스템을 바꾸지 못했기 때문이다. 원인을 다루지 않고 증상만 치유한 것이다.

목표를 달성하는 것은 우리 인생의 '한순간'을 변화시킬 뿐이다. 이는 '개선'과는 다르다. 진짜로 해야할 일은 결과를 유발하는 시스템을 바꾸는 것이다. 결과 수준에서 문제를 해결하려고 하면 이는 임시방편일 뿐이다. 결과 수준에서 문제를 해결하려고 하면 이는 임시방편일 뿐이다. 영원히 개선하고자 한다면 결과가 아니라 시스템 단계에서 문제를 해결해야 한다.

문제 3. 목표는 행복을 제한한다.

목표 뒤에는 이런 가정이 내포되어 있다. '목표에 도달하면 행복해질 거야.' 목표를 우선으로 생각하는 태도의 문제는 다음 표지판에 도달할 때까지 행복을 계속 미룬다는 것이다. 수년동안 나에게 행복이란 미래에 있는 것이었다. 근육을 10킬로그램 증량하기만 하면, 내 사업이 <뉴욕 타임즈>에 실리면 그제야 행복해지고 쉴 수 있을 거라고 여겼다.

게다가 목표는 '이것 아니면 저것'이라는 양자택일적 갈등을 만들어낸다. 목표를 달성하면 성공하는 것이고, 달성하지 못하면 실패하는 것이라고 말이다. 이는 오판이다. 실제 삶의 행로는 우리가 마음속으로 정해놓은 여정과 정확히 일치하지 않는다. 성공으롤 가는 길은 수없이 많다. 굳이 하나의 시나리오에만 자신의 길을 맞출 이유는 없다.

시스템 우선주의는 그 해독제를 제공한다. 결과가 아니라 과정을 좋아하게 되면 '이제 행복해져도 돼'라고 말할 시기를 기다리지 않아도 된다. 시스템이 작동하고 있다면 어느 때건 만족할 수 있기 때문이다. 시스템은 우리가 처음 상상했던 한 가지 결과가 아니라 다양한 형태로 성공할 수 있게 해준디ㅏ.

문제 4. 목표와 장기적 발전은 다르다.

목표 중심적 사고방식은 '요요 현상'을 불러올 수 있다. 달리기 선수들은 경기가 있으면 몇 달 동안 열심히 운동한 끝에 결승선을 통과한다. 그리고 당분간은 훈련을 멈춘다. 이미 끝난 경기는 더 이상 동기를 자극하지 않는 것이다.

목표 설정의 목적은 게임에서 이기는 것이다. 반면 시스템 구축의 목적은 게임을 계속 해나가는 것이다. 장기적으로 발전하기 위해서는 목표 설정보다는 시스템을 구축해야 한다. 성취하는 것이 아니라 계속해서 개선하고 발전해나가는 순환 고리를 만드는 것이다. 즉, '과정'에 전념하는 것이 '벌전'을 결정한다.

바보야, 문제는 시스템이야

습관을 바꾸기가 어렵다면 우리 자신이 문제가 아니다. 문제는 우리의 시스템이다. 나쁜 습관은 그 자체로 계속 반복되는데, 이는 우리가 변화하고 싶지 않아서가 아니라 변화할 수 없는 나쁜 시스템을 가지고 있기 때문이다.

목표를 높이지 마라. 시스템의 수준을 낮춰라. 하나의 목표가 아니라 전체적인 시스템에 초점을 맞추는 것이 이 책의 핵심 주제다. 아주 작은 습관도 모여 놀라운 결과를 이뤄낸다.

습관은 작지만 강하다. 정기적인 실행 또는 일상적인 행동들은 작고 실행하기 쉬울 뿐만 아니라 강력한 힘을 내는 근원이다. 시스템의 한 구성 요소로 종합적 성장을 이끈다.

· 약 14분

0. 근황

  1. 일기쓰는 습관
  • 8월 초에 글을 거의 쓰지 못했는데 반성하고 있다. 아주 적은 글이라도 조금씩 작성하면서 습관을 들여야 했는데 그것조차 쉽지 않았다. 당연히 게으름 때문.. 아직 일기를 쓴다는게 익숙치 않은 것 같다. 마치 운동을 하는 것 처럼. 최근 습관에 대한 책을 읽고 있는데 이를 기반으로 일기 쓰는 습관을 가지도록 노력해 볼 생각이다. 좋은 습관을 기르고 싶은데 자주 실패한다면, 습관의 힘을 잘 모르겠다 라고 생각하는 사람이라면 "아주 작은 습관의 힘" 매우 강추!
  1. 휴식
  • 휴식이 너무 필요한 것 같아서 금, 월 휴가를 신청하고 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를 맞춰야 하는 수고도 당연히 필요하다. 귀찮다는 이유로 이를 하지 않는다면 문제가 생겼을 때 항상 본인이 해결해야한다. 남들이 이 문제를 해결해주길 기대해서는 안된다. 해당 히스토리는 본인의 머릿속에 있고 다른 사람들이 이를 해결하기 위해서는 엄청나게 많은 시간이 소모될 것이며 본질적인 문제를 해결하는게 아닌 동작하도록 만 코드를 짤 것이 뻔하기 때문이다.

· 약 4분

0. 근황

  1. 와인앱
  • 와인앱은 지금 거의 중단상태다. 다른 우선순위 높은 것들이 너무 많이 나오고 있기 때문이다. 하지만 끝까지 만들기는 할꺼다! 무조껀!
  1. 와인 자격증
  • 와인 자격증은 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~ 🎉

img

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

· 약 14분

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 를 활용하는 방법도 있지만 이게 훨씬 깔끔하다.

jest.ci-config.ts
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;
coverage.yml
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. 아주 작은 습관의 힘

목표 따윈 쓰레기통에 던져버리기

흔히 원하는 것을 얻으려면 구체적으로 실행 가능한 목표를 세워야 한다고 말한다.

나 역시 습관에 대해 오랫동안 이런 관점에서 접근했다. 습관 하나하나는 곧 도달해야 할 구체적인 목표였다. 하지만 그런 목표들 중에서 성공한 것은 극히 일부였고 대부분 실패했다. 나는 내가 얻어낸 결과들이 처음에 세웠던 목표와는 거의 관계가 없고, 사실 모든 것은 시스템에 달려 있다는 것을 깨달았다.

시스템과 목표의 차이는 무엇일까? 목표는 우리가 얻어내고자 하는 결과이며, 시스템은 그 결과로 이끄는 과정이다.

  • 감독의 목표는 챔피언십을 획득하는 것이다. 그렇다면 시스템은 선수들을 선발하는 방식, 코치들을 다루는 방식, 실행하는 방식이다.
  • 기업가의 목표는 수백만 달러짜리 사업을 세우는 것이다. 그렇다면 시스템은 제품이나 서비스에 대한 아이디어를 테스트하는 법, 직원을 고용하는 법이다.
  • 악기 연주자의 목표는 새로운 곡을 연주하는 것이다. 그렇다면 시스템은 '몇 번 연습할 것인가, 어떻게 틀을 깨고 다른 방식으로 연주할 것인가, 배운 내용을 어떻게 나만의 것으로 소화할 것인가'가 된다.

이제 흥미로운 질문을 해보자. 목표를 완전히 무시하고 오직 시스템에만 집중한다면 그래도 성공할까? 나는 '그렇다'고 생각한다. 어떤 스포츠든 목표는 최고의 점수를 달성하는 것이다. 하지만 그렇다고 해서 경기 내내 점수판만 응시하는 건 말도 안되는 짓이다. 실제로 승리할 유일한 방법은 매일 더 나아지는 것뿐이다.

더 나은 결과를 내고 싶다면 목표를 세우는 일은 잊어라. 대신 시스템에 집중하라. 목표가 무용지물이라는 말은 아니다. 목표는 방향을 설정하는 데 필요하며 시스템은 과정을 제대로 해나가는 데 필요하다. 그러나 목표를 생각하느라 너무 많은 시간을 들이고 시스템을 고안하는 데는 시간을 투자하지 않을 때 문제가 발생한다.

문제 1. 성공한 사람도, 성공하지 못한 사람도 목표는 같다.

올림픽에 출전한 선수 모두가 금메달을 원한다. 입사 지원자 모두가 구직을 바란다. 성공한 사람도, 성공하지 못한 사람도 목표는 같다. 목표는 승자와 패자를 가르는 차이가 될 수 없다.

목표는 늘 거기에 있다. 결과에 차이가 생긴건 지속적으로 작은 개선들을 만들어내는 시스템을 시행한 것, 그뿐이였다.

문제 2. 목표 달성은 일시적 변화일 뿐이다.

지저분한 방이 있다고 생각해보라. 방을 치우기로 목표를 세운다. 그리고 당장 청소하는 데 필요한 에너지를 끌어올려 방을 치웠다. 하지만 대충대충 청소하거나 뭐든 잘 버리지 못하는 사람이라면 방은 또 지저분해질 것이다. 계속 같은 결과가 나타난다는 것은 이런 결과의 배경이 된 시스템을 바꾸지 못했기 때문이다. 원인을 다루지 않고 증상만을 치유한 것이다.

목표를 달성하는 것은 우리 인생의 '한순간'을 변화시킬 뿐이다. 이는 '개선'과는 다르다. 우리는 결과를 바꿔야 한다고 생각하지만 사실 그 결과는 문제가 아니다. 진짜로 해야 할 일은 결과를 유발하는 시스템을 바꾸는 것이다. 결과 수준에서 문제를 해결하려고 하면 이는 임시방편일 뿐이다. 영원히 개선하고자 한다면 결과가 아니라 시스템 단계에서 문제를 해결해야 한다.

문제 3. 목표는 행복을 제한한다.

목표 뒤에는 이런 가정이 내포되어 있다. '목표에 도달하면 행복해질 거야' 목표를 우선으로 생각하는 태도의 문제는 다음 표지판에 도달할 때까지 행복을 계속 미룬다는 것이다. 나는 수없이 이런 함정에 빠져 내가 뭘 하는지 잊곤 했다. 수년 동안 나에게 행복이란 미래에 있는 것이었다.

목표는 '이것 아니면 저것'이라는 양자택일적 갈등을 만들어낸다. 목표를 달성하면 성공하는 것이고, 달성하지 못하면 실패하는 것이라고 말이다. 실제 삶의 행로는 우리가 마음속으로 정해놓은 여정과 정확히 일치하지 않는다. 성공으로 가는 길은 수없이 많다. 굳이 하나의 시나리오에만 자신의 길을 맞출 이유는 없다.

시스템 우선주의는 그 해독제를 제공한다. 결과가 아니라 과정을 좋아하게 되면 '이제 행복해져도 돼'라고 말할 시기를 기다리지 않아도 된다. 시스템이 작동하고 있다면 어느 때건 만족할 수 있기 떄문이다. 시스템은 우리가 처음 상상했던 한 가지 결과가 아니라 다양한 형태로 성공할 수 있게 해준다.

문제 4. 목표와 장기적 발전은 다르다.

마지막으로 목표 중심적 사고방식은 '요요 현상'을 불러올 수 있다. 달기기 선수들은 경기가 있으면 몇 달 동안 열심히 운동한 끝에 결승선을 통과한다. 그리고 당분간은 훈련을 멈춘다. 이미 끝난 경기는 더 이상 동기를 자극하지 않는 것이다.

특정한 목표를 이루기 위해 노력했다면, 그것을 달성한 뒤에 무엇이 남아 우리를 앞으로 나아가게 할까? 이 때문에 많은 사람이 목표를 달성하고 나면 과거의 습관으로 쉽게 돌아가곤 한다.

목표 설정의 목적은 게임에서 이기는 것이다. 반면 시스템 구축의 목적은 게임을 계속 해나가는 것이다. 장기적으로 발전하기 위해서는 목표 설정보다는 시스템을 구축해야 한다. 성취하는 것이 아니라 계속해서 개선하고 발전해나가는 순환 고리를 만드는 것이다. 즉, '과정'에 전념하는 것이 '발전'을 결정한다.

4. 와인 앱

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

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

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

· 약 16분

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-07 실력을 키울 생각이 없으면 포기하라

꿈보다 목표가 중요하다

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

오늘 밤은 그냥 보여주는 것뿐이다.

내 일은 오늘 밤에 끝나는 게 아니다. 벌써 3개월 전에 끝났다. 오늘 밤은 그냥 보여주는 것뿐이다.

'내가 잘하지 못함에도 계속하고 있는 일은 무엇일까?' 한 달에 한 번, 분기에 한 번, 이 질문을 스스로에게 던질 때 당신과 나는 한 걸음 앞으로 나갈 수 있게 될 것이다.

3-08 생각을 쉬게 하라

상상력을 펼쳐라

우리가 매일 정신적으로 지치는 중요한 이유들 중 하나는, 너무 이성적으로 살아가려고 노력하기 때문이다. 언제나 우리는 '옳고 합리적이고 타당한 것'을 찾는 데 익숙하게 골몰한다. 그러다 보니 정신은 '딴 짓을 할 시간'을 전혀 갖지 못한다. 지치는 건 당연하다. 지치고 피곤할 때는 테트리스를 하라. 그리고 딴 생각. 내가 할 수 있는 가장 말도 되지 않는 생각을 떠올리며 웃어라.

타인을 비난하지 마라

정신건강을 위한 또다른 습관으로 '공개적인 비난을 삼가할 것'을 주문한다. 타인을 비난하는 것은 우리가 가장 중독되기 쉬운 나쁜 습관이다. 내가 내밷은 부정적인 말은 누군가의 하루를 망치거나 그의 마음에 깊이 상처를 내는 데서 그치지 않는다. 상대를 비난하는 순간, 내 마음과 시간에도 상처가 생겨난다. 다만 우리는 그것을 의식하지 못할 뿐이다.

"타인을 공격할 때마다 우리는 한 명 한 명 내 목숨을 구해줄 수도 있는 귀한 사람들을 잃는다. 세상에 그것보다 더 큰 상처와 실패는 없다. 낯선 사람을 따뜻하게 맞이하라. 그난 변장을 한 채 자신을 찾아온 천사일지도 모르니까 말이다."

3-09 아무것도 하지 않는 즐거움을 찾아라

팀 크라이더의 이야기

바쁜 사람은 뭔가 중요한 일을 하는 사람처럼 보인다. 그래서 그에 대한 반응 역시 축하의 의미다. 바쁘다면서 탄식하는 사람들은 자진해서 바쁜 경우가 대부분이다. 그들이 바쁜 이유는 바쁨에 중독되어 있으며 바쁘지않게 될까봐 몹시 두려워한다. 내가 아는 거의 모든 사람이 바쁘다. 그들은 일하지 않을 때는 불안과 죄책감을 느낀다. 바쁨은 인생에 필수적이거나 불가피한 상태가 아니다. 그것은 자신이 선택한 상황이며 묵묵히 따라야만 가능하다.

물론 모두가 바쁜건 사실이다. 하지만 우리는 스스로에게 질문을 던져야 한다. '나는 지금 정확히 무슨 일을 하고 있는가?'라고. 정신없이 바빠 회의에 늦고, 전화기에 대고 소리 지르지만 정녕 말라리아를 없애거나 화석 연료의 대체 에너지를 개발하고, 아름다운 작품을 만드느라고 바쁜 것인가? 바쁨은 존재의 확인이자 공허함을 막아주는 울타리 역할을 한다.

세상에 몰입하지 않은 채로 글의 소재를 찾기는 힘들지만, 세상에서 벗어나지 않으면 소재에 대해 깊이 생각해보고 가장 잘 표현할 수 있는 방법을 찾을 수 없다.

제한된 시간을 가장 훌륭하게 투자하는 방법은 사랑하는 사람들과 보내는 것이라는 사실을 알고 있다. 인생은 바쁘게 살기에는 너무 짧다.

3-10 단 하나의 결단

우리는 나이가 들어서까지 어리석으면 안되며, 좌절해서도 안된다. 뭔가 잘 안풀릴 때는 처음부터 다시 점검하고, 나보다 더 현명하고 지혜로운 사람에게 조언을 얻어야 한다. 소머 코치는 "승자가 되려면 가장 쉬운 것부터 시작하라"고 말한다. "반드시 천천히 하라, 서두르지 마라"고도 말한다. 가장 쉬운 것부터 시작했음에도, 천천히 서두르지 않고 연습했음에도 성과가 지지부진하다면, 소머의 '단 하나의 결단'에 대한 조언이 강력한 효과를 발휘할 것이다.

친애하는 팀에게.

눈에 보이는 발전이 없을 때 나타나는 좌절감은 탁월함을 향해 나가는 과정에서 필수불가결한 일입니다. 좌절감을 느끼지 못하는 사람은 아무것도 배우지 못하니까요. 탁월함을 추구하는 게 쉽다면 누구나 할 수 있을 겁니다. 그러니 괴로워할 일이 아닙니다. 제대로 된 길을 가고 있는지를 점검하는 좋은 기회입니다.

우리가 샐패하는 건 좌절감 때문이 아닙니다. '조급함' 때문이죠. 좌절감과 싸우는 동안 조급함을 느끼기 때문에 대부분의 사람들이 목표 달성에 실패합니다. 우리가 알아야 할 것은 우리가 걷고 있는 탁월함의 길이 곧장 뻗은 '직선'이 아니라는 것입니다. 우리는 한지점에서 다른 한 지점으로 가장 빨리 가는 직선을 그리기 위해 조급함과 초조함을 안고 삽니다. 하지만 비범한 성과는 이 직선 위해서는 만날 수 없습니다. 가장 빨리 결승선을 통과하는 사람은 가장 많은 거리를 뛰어온 사람이기 때문입니다. 우리가 좌절감, 초조함, 조급함을 극복하는 비결은 간단합니다. 일터에 가서 일을 하고, 집에 가서 휴식을 취하는 것입니다. 그러면서 일단 결심을 한 것은 절대 그 생각을 의심하거나, 바꾸지 않는 것입니다. 타협하지도 말고요.

눈에 띄는 진전이 없다는 것은 아마도 많은 것을 생각하고 행했기 때문일 겁니다. 다시 말해 집중해야 할 대상이 많아져서 집중을 하지 못하는 역설적 상황을 맞았기 때문일 겁니다.

명심하세요, 드라마 같은 일은 벌어지지 않습니다. 길을 걷다가 작게 튀어나온 돌부리에 발이 걸렸다고 해서 자책할 일도 아니고, 뭔가 새로운 일이 생길 것이라고 기대할 일도 아니라는 겁니다. 당신의 심플하지만 단단한 루틴과 습관을 계속해 나가야 합니다. 그러면 당신의 자세와 걸음걸이를 살펴보며 현명한 조언을 해주는 사람이 나타날 수 있습니다. 아마 목표를 이루는 데 필요한 행운은 여기까지일 겁니다. 발전과 성과가 없다고 해서 자꾸만 자세를 바꾸고, 생각을 고치고, 이것저것 다 해보는 사람에겐 좋은 조언자가 나타나지 않습니다. 너무 변화무쌍하니까요. 정해진 일정 같은 건 잊어버리세요. 시간은 필요한 만큼 걸릴 겁니다.

일련의 작은 중간 목표가 아니라 장기적인 목표를 이루기 위해 노력한다면 당신이 결정하고 지켜야 할 일은 한 가지뿐입니다. 명확하고 단순하면서 직설적이죠. 매 단계를 거칠 때마다 궤도를 벗어나지 않기 위해 작은 결심들을 하고 또 하는 것보다, 단 하나의 큰 결단을 유지하는 게 훨씬 쉽습니다. 작은 결심을 계속 하는 경우에는 당신이 선택한 목표를 무심코 벗어나서 표류할 기회가 너무 많아집니다.

'단 하나의 결단'은 우리가 가진 것들 중에서 가장 강력한 힘을 발휘하는 도구입니다.

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 했을 때

· 약 4분

0. 일상

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

1. WSET 와인수업

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

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

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

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

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

· 약 7분

0. 일상

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

1. 와인앱 근황 mlkit

  • 와인앱은 mlkit을 이용해서 와인 상품명을 읽어들이는 작업을 진행중이다. 생각보다 인식률이 좋아서 나름 만족한다.
  • 카메라 layout을 대폭 축소시키고 인식시킨 글자를 클릭해서 검색하도록만 하면 1차 mvp는 끝난다! 할께 많네..

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

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

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

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

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

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

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

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

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

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

· 약 6분

0. 일상

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

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

1. 당근의 방식

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

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

2. 시작에 대한 두려움

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

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

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

· 약 3분

오랜만에 일기를 쓴다.

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-actioncodecov를 제거했다. compressed-size-action는 ci 시간이 너무 오래걸려서 효용이 없는 것 같아 제거했고 codecov는 codecov에 code read permission을 주는게 너무 크리티컬해서 제거했다. 하지만 codecov가 해주는 코드 커버리지를 pr에서 보여주는 작업은 꼭 붙히고 싶은게 괜찮은게 있을지 찾아봐야한다. 간단하게 찾아봤을 때 jest-coverage-report 괜찮은 것 같다. test result.json만 들고가는 것 같다.

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

· 약 9분

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과 연동시키고 온콜이 필수적으로 필요할 것 같아요.

· 약 8분

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

타이탄의 도구들

21 다수를 경계하라

"인간은 절대적으로 분명하거나, 본인의 생계와 안위에 대한 직접적인 폭력 위협이 있을 때가 아니고서는 좀처럼 높은 수준의 합의에 도달하지 않는다." 내 의견이 많은 사람들과 같을 경우에는, 그것이 진짜 내 것인지 의심해봐야 한다. 무의식중에 타인의 의견을 따른 건 아닌지, 어떤 허영심이 작용한 것은 아닌지 따져봐야 한다. 인터넷을 보라. 얼마나 많은 집단들이 근거도 없는 맹신을 쫓아 유령처럼 떠돌아다니는지를.

"다수가 합의와 의견 조율을 거쳐 만들어낸 것들 중 형편없는 것을 골라보라. 일단 다수는 합의할 때만 아우성을 칠 뿐, 합의 결과가 나오면 곧바로 시들해지기 때문에 시간이 흐를수록 그냥 방치되는 것들이 많다."

23 스스로를 향해 걸어라

어떤 상황이든 우리는 3가지 선택이 가능하다.

'바꾸거나', '받아들이거나', '떠나거나'다.

바꾸고 싶은데 바꾸지 않는 것, 떠나고 싶은데 떠나지 않고, 그렇다고 받아들이지도 않는 것은 좋은 선택이 아니다. 불행은 대부분 그런 몸부림과 혐오감 떄문이다. 나발이 마음속으로 가장 많이 외치는 말은 '받아들여라!'다.

받아들인다는 것은 뭔가 정체되어 있는 느낌이다. 하지만 그는 고개를 젓는다. 뭔가를 바꾸고, 어딘가로 떠나기에는 시간이 너무 없다는 것이다. 우리가 하는 그 어떤 일도 지속되지 않는다. 언젠가 우리도, 우리가 한 일도, 생각들도 사라질 것이다. 그러니 그냥 앉아서, 나를 중심에 놓고 조금씩 눈만 돌리는 게 가장 행복한 자세다.

무엇인가를 받아들인다는 것은 어딘가를 향해 떠날 때 필요한 모든 짐을 내려놓는다는 뜻이다. 그만큼 가볍게 살 수 있다는 의미다.

행복은 자신을 중심에 놓는 행동이다. 중심에 앉아 해답이 가능하고 간단한 것들에 대해서만 집중해 노력한다. 고정된 시각이 아니라 다양한 것들에 대해서만 집중해 노력한다. 고정된 시각이 아니라 다양하고 풍부한 프레임으로 세상을 바라보는 사람은 불행해지지 않는다.

24 무엇을 하든, 진짜 모습으로 하라

영원히 변하지 않는 것을 찾아라

옳은 사람들은 어느 날 갑자기 그렇게 훌륭해진 것이 아니다. 그들은 매일 정도를 넘어서는 걸 거부해왔기 때문이다. 빠르게 변하는 시대에서 가장 소중하고 값진 것은 무엇일까? 영원히 '변하지 않는 것'이다. 시대가 아무리 변해도 변하지 않는 것, 그걸 가진 사람이 성공한다. 그것은 곧 자신만의 '원칙'이다. 일관적인, 타협하지 않는 불굴의 원칙이 있는 사람은 실패하지 않는다. 실패해도 오래 가지 않는다.

25 마라에게 차를 대접하라

명상 도중에 모욕을 당했던 일 때문에 화가 솟구치면 곧바로 속으로 '아, 분노의 감정이 찾아왔군' 하고 말하면서 그 존재를 의식적으로 알아차리고 나면 금세 다시 집중할 수 있다. 맞서 싸우지 않고 부정적인 감정에 이름을 붙이고 바라만 보면, 그것들에 우리는 휘말리지 않는다. 감정과 싸우기 시작하면 상황을 계속해서 악화시킬 뿐이다. 이름 붙이고, 알아차리고, 바라보는 것. 그것이 우리에게 가장 필요한 지혜이자 최선의 공격이자 최선의 방어다.

26 디로딩 타임을 가져라

디로딩은 '내려놓는', '뒤로 물러나는', '부담을 제거하는'등의 뜻을 갖고 있다. 즉 촘촘하게 짜인 계획과 일에서 잠시 물러나 컨디션을 조절하고 회복하는 행동을 디로딩이라 할 수 있다. 디로딩 주간을 가지면 삶의 과부하들을 지혜롭게 예방하고, 더 나은 삶을 위한 속도를 내는 데 큰 도움을 얻을 수 있다.

더 큰 성공을 하지 못하는 이유는 더 큰 성공의 그림을 그려볼 시간이 없기 때문이다. 작은 성과들을 차곡차곡 쌓아가되, 이것들을 꿰어 빛나는 보배로 만들 수 있는 큰 생각을 할 시간을 의도적으로 내야 한다.

27 '좋다!'의 힘

상황이 나빠져도 당황하지 마라. 좌절도 하지 마라. 그저 상황을 바라보면서 '좋아!'라고 말하라.

상투적인 조언을 하려는 것이 아니다. 항상 웃고 긍정적인 사람인척하려는 것도 아니다. 그런 사람은 현실을 간과한다. 긍정적인 태도가 문제를 해결해줄 것이라고 생각하지만 그것은 불가능한 일이다. 이는 문제를 깊이 생각해보고자 하는 자세가 아니기 때문이다.

'좋아!'라고 외치는 건 해결책에 초점을 맞추는 자세다. 갖가지 문제, 실패, 장애물을 미리 알고 받아들이는 자세를 갖게 한다. 이 자세만이 우리를 앞으로 나가게 한다.

'좋아!'라고 외치며 기꺼이 받아들여라. 그리고 '좋아!'라고 외치며 앞으로 나가라.

· 약 15분

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 level2 level3 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 분해 예제: 온라인 음식 주문 업무

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

img

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

결론

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

· 약 14분

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. 타이탄의 도구들 읽고

타이탄의 도구들

'열정을 쫓아라!'는 끔찍한 최면이다

아무리 힘들고 어려워도 열정만 있으면 원하는 삶, 원하는 직업을 찾을 수 있다는 것은 무지의 소치라고 비판한다. "직업 만족의 가장 큰 조건은 '가슴이 뛰느냐'가 아니다. '정신이 참여할 수 있느냐'가 결정한다. 열정은 삶과 아무 상관이 없다. 지금 하고있는 일이 다양한 관점을 제시하고, 좋은 피드백을 주고, 자립심을 발휘하게 하며, 더 큰 세상에 자신이 기여하게 만드는지와 같은 이성적인 측정 기준이 중요하다. 지금, 당장, 실제로 의미가 있는가? 세상을 더 나은 곳으로 만드는가? 내가 개발해 온 기술을 적극 활용할 수 있는가? 열정은 아무것도 아니다."

2년의 시간을 앞으로 어떻게 살아갈지 생각하는 데 쓰는 사람은 분명 뭔가 의미 있는 삶을 만들어낼 것이다. 궁지에 몰려, 시간에 쫓겨 열정 따위를 마법처럼 외치며 괴롭게 살아가는 일은 최소한 없을 것이다.

2장 > 13 가장 중요한 문제에 집중하라

노동의 고됨과 지루함, 고통에 대해 자주 호소하는 사람은 성공할 수 없다고 단언한다. 무엇을 선택했든 간에, 일이 어렵지 않고 괴롭지 않은 사람은 지구상에 한 명도 없다. 다만 그 사실을 받아들여 좀 더 괴롭고 덜 힘들 수 있는 길을 만들려 하는 사람은 성공하고, 그 사실을 받아들이지 못하고 괴로워하는 사람은 실패할 뿐이다.

'가장 효율적인 노동자는 하루를 일거리로 가득 채우지 않으며 편안함과 느긋함에 둘러싸여 일한다. 일을 많이 하는 사람은 열심히 하지 않는다.' 일정으로 꽉찬 달력을 갖는 게 우리의 목표인가? 핵심에 집중하려면 소로의 말처럼 일을 많이 하지 않아야 한다. 느긋하게 하는 사람이 무엇이든 열심히 한다.

인생은 주어진 50문제를 다 풀어야 하는 시험이나 숙제가 아니다. 가장 중요한 것을 골라내 열심히 답을 찾는 사람에게 신은 더 큰 기회를 주어왔다는 사실을 기억하라.

찾아보기 힘든 것을 만들고 있는가?

충분한 시간을 가진 사람은 아무도 없다. 짧고 짧은 시간을 살아가는 지혜를 얻으려면 케반은 먼저 '생산성'에 매몰되지 말 것을 충고한다. "생산성은 로봇에게나 필요하다. 인간의 모든 시간은 질문하기, 창의성 발휘하기, 경험하기로 해치워야 한다." 생산성이 높은 사람과 기업은 흔해빠졌다. '얼마나 많은 것을 만들 것인가?'를 지나 '얼마나 희소한 가치가 있는 것을 만들 것인가?'의 시대로 이동한 인류에게 케빈은 다음과 같이 조언한다.

성공하려면 자신만의 자리를 만들어야 한다. 존재하지 않았던 새로운 자리에 대한 질문과 창의성과 경험을 만들어내야 한다. 대표적인 인물이 예수다. 물론 매우 힘든 일이다. 하지만 그것만이 우리에게 남아 있는 유일한 성공이다.

규율이 곧 자유다

자유의지를 드높이고 성과를 끌어올리려면 일관된 규칙이 필요하다. 자유로운 의사결정을 한다는 명목으로 끊임없이 '이제 뭘 해야 하지?' '아침으로 뭘 먹지?'등을 고민하는 건 오히려 사람을 무기력하게 만들 수도 있기 때문이다. 단순하면서 규칙적인 계획이 더 많은 자유와 성취를 안겨준다. 규칙과 통제가 있어야 주체성과 자유가 더 크게 느껴진다.

둘은 하나이고, 하나는 아무것도 아니다

"있지 않은데 필요로 하는 것보다는, 있는데 필요로 하지 않는 편이 낫다" 최악의 상황에 대비해 우리는 하나 이상의 계획을 갖고 있어야 한다. 하나가 고장 나서 전체가 멈취버리는 일은 늘 생겨난다.

모든 것을 기록하라

"자신을 더 많이 알리는 데 시간을 낭비하지 마라. 그 시간에 더 많이 알릴 수 있는 '능력'을 키워라. 단순히 잘하는 사람이 아니라 위대한 사람이 되려고 노력해야 한다."

가장 오래 사랑받은 것을 찾아라

우리가 큰 성공을 하지 못하는 이유는 '경쟁자'에게 너무 많은 신경을 쓰기 때문이라고 릭은 말한다. "경쟁자가 아니라 위대한 사람의 영감을 활용해야 한다. 경쟁자 따위가 당신을 조종하게 만들지 마라. 우리는 더 좋은 노래를 만들려면 미술관에 가서 수백 년을 사랑받은 그림을 봐야 한다. 불멸의 소설을 읽고 지금 봐도 전혀 촌스럽지 않은 영화를 보고, 인류가 위안과 평화를 얻어온 시를 읽어야 한다. 위대한 작품에 당신의 몸과 마음을 푹 담가야 한다. 지금 유행하는 노래보다는 역사적으로 가장 훌륭한 평가를 받은 노래를 들어야 한다."

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

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

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

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

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

· 약 16분

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • 코드 수정해야할 일이 있을 때 빠르게 해당 파일을 찾아갈 수 있도록 개발해야 한다.
    • 주관적인 생각이나 소수의 집단이 알고 있는 철학이나 방법론을 적용한 폴더링은 피해야한다. -> 이것을 판단할 수 있는건 새로운 누군가가 코드를 작성했을 때 코드리뷰로 잘못된 폴더에 코드를 작성했다고 알려주는 것, 새로운 누군가가 새로운 파일을 만들었을 때 어느 폴더에 넣어야 하는지 창의적, 추론을 하면서 폴더에 집에 넣는 상황이 발생하는 것이다.
  • 단편적으로 생각해서, 현재 상황을 기반 또는 프로젝트에 대한 이해도가 높은 상태에서 폴더 구조를 짠다면 주관이 많이 반영된것이기 때문에 경계하자. 코드는 쓰는 시간보다 찾고 읽는 시간이 훨씬 많다. 빨리 찾고 읽을 수 있도록 배치해야한다.

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

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

· 약 14분

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위 한국의 인공지능 기업들의 생존전략" 영상 요약

영상요약

https://www.youtube.com/watch?v=rhTwR9vdApQ

Tortoise에서 발표한 글로벌 국가별 AI 랭킹에 따르면 한국은 2023년 6위를 달성했다고 한다.

네이버 클라우드: 생성형 AI는 hype이 아니라 10~15년 사이에 오는 주기에 있다고 말하고 있다. 기존에는 복잡한 과정을 통해서 어디에 있는지 알아야되고 복잡하게 써있는걸 이해할 수 있어야 했는데 생성형 AI는 말한마디에 알려주고 이해도가 떨어지면 이해도에 맞춰서 알려주고. 정보를 주는 것 뿐 아니라 나 대신 일을 해줄 수 있는 지경이다. 생성형 AI는 언어모델에서 시작되었는데 앞에 봤던 글자들을 보고 그 다음에 오는 글자가 어떠한 것인지를 확률적으로 맞추는 것을 부단히 노력한 결과물이다. '동해물과 백두산이'한 다음에 '마'가 나와야 하는걸 아는 확률적인 모델이다. 처음에 Open AI GPT 3가 나왔을 때 그래도 애는 글을 잘쓰는 것 같아. 그래도 추론은 하지 못한다. 그런게 일반적인 인식이였습니다. 현재 생성형 AI는 추론을 꽤 잘 합니다.

왜 한국어 초대규모 AI가 필요한가?

AI 주권이라는 걸 3년전 부터 이야기 했고 생성형AI 시장이라는게 GDP랑 연결이 된다. 만약 좋은 AI를 가지고 있지 않으면 외산 AI를 사용하게 될 것이고 무료로 그들이 공급할 리가 없습니다. 어떤 기업이라도 그렇게 하겠지, 뭐 나쁜게 있어? 하실 수 있지만 그게 만약 우리나라 기업이 아니면 문제가 됩니다. 우리나라 생산활동의 대부분을 어떤 외산 AI를 사용한다면 우리는 그들에게 우리나라 GDP의 4% 수준의 비용을 지불하게 됩니다. 이건 조용하게 당하는 AI 식민지가 될 확률이 높다고 봤고요. 이런 문제는 대부분의 나라들이 자각하고 있다. 영국과 이스라엘도 자체 AI를 만든다고 선언했다.

eo: 처음에는 굉장히 회의적인 목소리가 많았다. 조금있으면 언어적인 장벽이 허물어질꺼다. 돈만 쓰는거 아니냐, 경쟁력이 있겠냐 등등. 하지만 AI가 모든 영역에 거쳐 인간의 삶을 근본적으로 변화시킬 것이기 때문에 다른 국가들도 이럴 때일수록 자체 AI 인프라 가술을 갖춰야한다고 말하고 있다.

뤼튼: 인터넷 시대의 프론트 엔드는 이런 검색 화면이 우리의 첫 화면을 차지했습니다. 이런 인터넷과 모바일의 프론트엔드를 대체할 대화형 AI 프론트엔드가 되어 사람들의 첫 화면으로 자리잡고자 합니다.

질의응답

1. 생성형 AI 시대가 되면서 검색이 어떻게 달라질 수 있는가?

인터넷이 나온 이래에 가장 큰 어플리케이션이 검색이다. 시장규모로 봤을 때. 1994년에 야후가 검색엔진을 만든 이래로 30년동안 검색 결과 화면이 링크의 나열이다. 어떻게 보면 프로덕트의 혁신이 딱히 없던 영역이다. 물론 검색창 뒤에 있는 기술은 엄청나게 발전했지만 사람들이 원하는건 링크의 나열이 아니라 사실 링크 뒤에 있는 답이다. 정보인데, 어떻게 하면 정보를 더 앞단으로 끌어와서 질문을 하는 순간 답을 바로 줄수 있을까? 이걸 해결하는게 저는 궁극의 검색이라고 생각하는데 이걸 해낼 수 있는 기술이 딱히 없다가 거대 언어모델이 이걸 할 수 있게 도와준거 같다. 한편으로 검색이 생성형 검색으로 완전히 대체될 것인가 한다면 개인적으로 그렇게 생각하지는 않는다. 내가 직접 탐색해보고 싶은 니즈도 있기 때문이다. 링크의 나열 검색과 답을 바로 얻는 생성형 검색이 같이 있는게 가장 이상적인 형태라고 생각한다.

2. 정교하게 잘 쓴다는 정도가 아니라 회사에서 생각하는 프롬프트 엔지니어링이라는게 어떤것인가?

GPT 3 이후에 나왔던 퓨샷 패러다임에 있어서 기존에 특정 목적의 인공지능 모델을 학습할 때 천 개 또는 만 개 이상의 라벨링된 데이터가 있어야 학습할 수 있었는데 이제 적은양의 모델만으로도 어느정도 수준을 낼 수 있는 모델을 만들 수 있다는 것이 가장 큰 장점이였다고 생각한다. Chat GPT 이후에 모델이 너무 똑똑해 지면서 프롬프트 엔지니어링 난이도도 쉬워졌다.

사람들이 자연어로 말을 걸면서 답을 얻어내는 건데 말을 거는 상대가 똑똑해질 수록 개떡같이 말해도 찰떡같이 알아듣는 일들이 일어나는 것 같다. 예전에는 '정보 검색사'라고 해서 검색엔진에 검색했을 때 답을 찾기가 너무 어려우니 검색 스킬을 가진 사람들이 자격증이 있고 직업이 있었는데 그런데 지금은 많이 없어졌다. 웬지 5~10년이 지나면 모델 자체가 개떡같이 말해도 찰떡같이 알아들음으로 인해서 프롬프트 엔지니어링 영역이 덜 중요해지지 않을까 생각이 있다. 그때 그 영역을 대체하게 될 건 사용자 경험을 잘 챙길 수 있는 것들이 이걸 대체하게 될 것 같다.

지금 프롬프트를 잘 쓰는 것도 두 가지 측면이 있는 것 같다. 어쨌든 자연스러운 인간이 이해할 수 있는 언어로 수렴할 것이고 지금은 첫 사이클을 돌고 있는 것이기 때문에 인공적인 부분이 있는 거라고 생각한다. 점점 더 자연어로 수렴하려면 사람들이 AI에게 일을 시킬 때 어떤 언어로 어떤 식으로 일을 시켜야 하는지 알아야 되는데 지금 첫 사이클이라 이 부분에 대한 정보가 많이 없으니까 지금은 억지로 프롬프트 엔지니어링을 많이 해야하는 상황이다. 사람들이 이런 식으로 일을 시킬 때 이런식으로 말하는구나 라는걸 알면 그게 학습에 사용되면서 이상하게 이야기해도 좋은 아웃풋이 나오는 방식으로 발전될 것이다.

마무리

AI 업계에 계신 분들이 AI 라는 파도와 글로벌 전쟁이라는거에 심각하게 받아들이고 있었다. 뭔가 신기한게 나왔다고 치부해버리기에는 인간 삶에 너무나도 근본적인 변화가 일어나고 있는 것이기 때문에 이 부분에 대해서 자체적인 역량과 성공사례를 만들어내지 못한다면 많은 부분 사회에서 비효율이 발생할 것이다.

Chat GPT가 과거에 학습한 걸 바탕으로 결과를 보여주는 거라면 Auto GPT는 인공지능에 목표를 주고 일을 시키는 것이다. 예를 들어 지난 주에 세계에서 가장 많이 투자받은 스타트업 10개를 찾아서 어떤 회사들이 투자받았고, 그 회사들이 왜 투자받았는지를 리스트업 해줘 라고 명령하면 5분정도 만에 해준다. 1불~5불정도 든다. 이런 조사 수십개를 동시에 수행하기도 한다. 숙련된 사람이 리서치해서 큐레이션도 하고 다듬어야 하는 일들을 수십명이 해야하는 일들을 AI가 몇 천원주면 해줄 수 있는 세상이 되었다.

· 약 3분

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

1. 배려하기

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

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

2. 타이탄의 도구들

행복은 거절의 기술이다.

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

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

· 약 11분

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가지 질문

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

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

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

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

텅 빈 공간에 홀로 서라

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

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

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

· 약 10분

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이 비어있지 않도록 해보자.

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

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

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

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

· 약 2분

1. 나는 나의 길을 가야지

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

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

· 약 8분

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

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

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

안테암불로가 되어라

'타인의 밑'에 있는 경험은 우리에게 많은 걸 가르쳐줄 수 있다. 무작정 다른 사람에게 복종하고 아첨을 하라는 것이 아니다. 그저 다른 사람들이 잘 될 수 있는 도움을 자발적으로 제공하라는 것이다. 내 위에 있는 사람들을 위해 길을 열어주는 것이 곧 나를 위한 길을 만들어가는 것임을 명심해야 한다.

당신이 사회생활을 시작한 젊은이라면 다음 세 가지를 진지하게 숙고해야 한다.

  1. 당신은 당신이 생각하는 것만큼 유능하거나 중요한 인물이 아니다.
  2. 당신은 태도를 조금 바꿀 필요가 있다.
  3. 당신이 안다고 생각하는 사실들, 혹은 책이나 학교에서 배운 것들은 대부분 시대에 뒤떨어지거나 잘못된 것들이다.

중요한 건 태도다. 항상 타인을 섬기겠다는 자세를 가진 사람이 성공 못하는 경우는 거의 보지 못했기 때문이다. 나아가 안테암불로의 자세는 위기에 처했을 때 모욕감 없이 자존심을 굽힐 수 있게 해주고, 편견 없이 모든 유용한 조언들을 스폰지처럼 흡수하게 해준다.

안테암불로는 누군가가 가고자 하는 방향을 미리 읽어내 그들이 짐을 효율적으로 꾸릴 수 있도록 도와주는 역할임을 기억하자. 그들이 다른 일에 얽매이지 않고 자신의 강점에만 집중할 수 있게 이끄는 길라잡이 역할을 한다는 걸 잊지 말자. 이런 역할을 지속하다보면 자연스럽게 자신의 아이디어를 개발하는 데 필요한 크리에이티브와 디테일한 전술들을 몸에 배게 할 수 있다. 캔버스 전략의 핵심은 다른 사람을 도움으로써 궁극적으로 자기 자신에게 도움이 되는 것을 얻는 것이다.

당신이 만나는 모든 사람에 대해, 그들을 도울 수 있는 방법이나 그들을 위해서 할 수 있는 일을 궁리하는 동안 당신의 다양한 해결책을 검증할 수 있다. 없어서는 안 될 사람이라는 평판을 얻게 된다.

모두가 자신의 공을 인정받고 싶어 할 때 당신은 안테암불로의 길을 가라. 모두가 부당한 대우를 받고 있다고 분노할 때 안테암불로의 길을 가라.

이책에 등장하는 타이탄들은 다음의 5가지 조언을 20~30대 비즈니스맨들에게 전한다.

첫째, 상사에게 넘겨줄 수 있는 아이디어를 찾아낸 사람은 누구보다 한 걸음 앞서간다. 둘째, 아이디어가 뛰어난 사람, 장래가 유망한 인재들을 서로 연결해준다. 셋째, 아무도 하고 싶어 하지 않는 일을 찾아서 그 일을 한다. 넷째, 비효율, 낭비, 중복이 많은 곳을 맨 먼저 찾아낸다. 그러면 나와 내 조직이 새로운 분야로 진출하는 데 필요한 자원을 확보할 수 있다. 다섯째, 자신의 아이디어를 기꺼이 공유한다.

안테암불로의 역할을 자발적으로 받아들이면, 대부분의 사람들이 자존심 때문에 그 진가를 깨닫지 못하고 있는 많은 가치들을 발견할 수 있게 된다.

"위대한 사람은 언제나 순종할 준비가 되어 있다. 자신의 지휘 능력은 나중에 언제든 증명할 수 있기 때문이다."

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

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

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

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

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

· 약 3분

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

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

2. spring 이냐 flutter냐

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

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

· 약 2분

1. WST 신청

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

img

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

2. 크로스핏 끝

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

· 약 2분

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

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

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

· 약 5분

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 공식 문서 이번주에 정독 해야겠다.

· 약 8분

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만 적게 되는데 지금 이일을 하는게 맞을지 진짜 임팩트가 있는 일인지 충분히 검토하고 진행하는게 필요하다. 일을 위한 일을 해서는 안된다. 멀리 바라보는 연습은 진짜 중요한 것 같다.

감정적이면 안좋다.

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

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

· 약 2분

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)

· 약 3분

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

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

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

아무튼 올해 목표!

[취미]

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

[회사]

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

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

2. Flutter와 Dart

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

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

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

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

· 약 10분

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)로 프레임워크를 바꾸려고 준비중이다. 이런거에 조금은 지치지 않았나싶다.

· 약 6분

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

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

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

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

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

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

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

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

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

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