목록으로
ESSAY

열심히 안 살기로 했다.

2025년 4월 17일Velog 원본
4월 회고일기
열심히 안 살기로 했다.

이직 포기합니다.

뻥이야 정말 미안해!

요즘 채용/이직 시장이 그렇게 차갑고 별로라는데 그래도 꾸준히, 몇 번씩 면접을 봤던 나였기에 나는 내가 금방 잘 될 줄 알았다.

친한 동료들이 이름만 대면 알만한 회사로 척척 이직을 할 때 나 역시 금방 그렇게 될 줄 알았다. 하지만 인생은 그렇게 녹록지가 않다.

그래서 공부를 열심히 했다. 나름 한다고 했는데 뭐가 부족한 건지 이제는 잘 모르겠다. 화가 난다. 내 능력 부족에, 날 몰라주는 것 같은 이 사회에.

생각해보면 그래도 건실한 회사에 나름 (고마운)동료들의 인정(?)도 받으면서 회사 잘 다니고 있는데 나는 결핍만 생각했다.

“꾸준히 노력하면 잘 될 것이다, 노력은 배신하지 않는다.“ 이런 말들을 떠올리며 나는 나름대로 한다고 했는데,

  1. 내 노력이 진짜 부족했거나, 2. 그냥 운이 안 따라줬다.

그래서 이제 나는 잘 하려고 하지도 않을 거고, 힘 주지도 않을 거고, 그냥 되는대로 하고 되는대로 생각하고 웃고 이 순간을 즐기기로 했다.

문득 내가 가진 것들도 꽤나 많다는 것을 느꼈다. 그리고 변명일 수도 있지만 아직 내가 가진 것들이 완전히 무르익지 않은 게 티가 날지도 모른다. 그리고 결정적으로 적게 일하고 적당히 벌면 최고 아닌가?(많이는 아니라는 걸 알기 때문에 적당히로 타협할 줄 아는 어른이다.) 나는 나를 왜 이렇게 몰아세우는가.

인생을 살아가는데 각자 나름대로의 불패법칙이 있을 거라고 생각한다. 나는 나를 계속해서 몰아세우고 불안에 떨게 하여 내 스스로를 쉬지 않고 앞만 보게 만들어 미련하게 매달리게 해서 원하는 것을 성취한 바가 있기 때문에, 그래서 원하는 것을 손에 넣어봤기 때문에 그 방법이 불패라고 생각했다.

하지만 그렇게 나를 갈아서 얻는 것과 지금 이 순간을 충분히 음미하지 못하고 흘려보는 것의 기회비용에 대해서 조금 생각해 볼 필요가 있다.

업무 회고 (노잼 시기인 것 같아요.)

요즘 업무는, 일이 좀 루즈하다. 내가 미치도록 잘 해서 그런 건 아니고, 어느 정도 일이 손에 익었는데 여기서 일종의 플러스 알파를 안 해서 그렇다. 하려면 하겠는데 그냥 그 시간에 이렇게 글을 쓰거나 추리 미스터리 스릴러(요즘엔 진짜 별다줄인게, 이걸 줄여서 추미스라고 한다나 뭐라나🤷‍♀️) 소설책을 읽거나 일과 관련 없는 내 개인 사이드를 하거나 개발 책을 읽는다. 아니면 클라이밍🧗‍♀️

아 최근에는 Chat-GPT랑 영어로 맨날 떠든다. 다시 오랜만에 영어를 하려니까 어색하고 또 단어도 생각 안 나고 그러는데, 이 친구가 참 기똥찬 게 미국 태생(맞지? 유럽 출신 아니지?)이라 그런지 기가 막히게 잘 알아듣고 꽤나 피드백도 잘 준다. 3만원 주고 개발에도 써먹고 영어도 써먹고 너무 잘 활용하고 있어서 좋은데, 이러다가 나보고 3만원이 아니라 30만원을 내라고 할까봐 걱정이다. 그 때 되면 얘 없이 뭘 하기가 애매할 거 같은데... AI가 나보다 이제 글도 잘 쓸텐데... 10여년 전 학생 때는 작가가 되고 싶었던 적도 있는데 그 때는 AI가 이렇게 삶에 깊숙히 들어올 지 몰랐지 뭐.

내가 AI보다 잘하는 게 뭐가 있을까 생각해봤는데, 얘보다 무조건 화는 잘 낸다. AI는 일단 화를 내게 만들어졌을리가 없기 때문에,(얘가 화를 내는 날이 온다면 그건 아마도 진짜 지능을 갖게 되었을 때이므로 그 때는 인간으로 인정하게 될 지도 모른다.)

나는 일희일비를 정말 잘하는 사람이다. 잘 화났다가 잘 욱했다가 잘 웃었다가 잘 울었다가 잘 식었다가 하는 사람이라서 일단 이런 재능을 AI가 금방 따라잡기는 어려울 것이다. (*조증 아님)

오늘은 2025년도 04월 17일이다. (요즘에는 하루하루 짚어서 생각하지 않으면 어제가 오늘이고 오늘이 내일이 되는 매직에 빠져버린다.)

최근에는 회사에서 어떤 일을 하고 있나면, 이미 알고 있었지만 한껏 외면해왔던 결제 페이지 웹뷰의 사용성 문제에 대해 고민해보았다. 모바일에서 도와준다면 로그를 쌓아서 과연 웹뷰에서 스크립트 로드 시간이 얼마나 오래 걸리는지 파악해 볼 수 있을 것이다. (웹뷰 액티비티를 띄우고 모바일 인터페이스 통신이 된 시점까지의 시간을 유저가 흰 화면을 보는 시간이라고 간주) 국내에서도 종종 웹뷰의 느림 때문에 이슈가 올라오지만 이번 개선을 통해서 어쩌면 해외 유저들의 느린 3G 환경에서 웹뷰 사용성이 어마어마하게 올라갈 수도 있을 것이다. (그리고 그걸 기대한다. 🙏)

일단 클라에서 할 수 있는 가장 빠른 방법은 컴포넌트 dynamic import를 통해서 chunk 분리를 하는 건데, 라우터에 등록된 페이지 컴포넌트에 한해 홈 화면이나 로그인, 마이 페이지 메뉴 중에 자주 쓰이는 페이지를 제외한 나머지 페이지 컴포넌트에 대해 chunk 분리를 해보려고 한다. 그리고 이게 진짜 효과적으로 성능 개선이 되었는지는 로그를 통해 어느 정도로 모바일 웹뷰에서 스크립트 로드 시간이 단축되었는지로 판단해보고자 한다. (과연 유의미할 것인가? ㅎ)

리액트 컨버팅 작업은 얼추 마무리가 되어 가고 있고 애증의 테이블 UI 스켈레톤 작업을 했다. 처음에는 그냥 가볍게 박스 그리는 것만 했는데, 주변에서 헤더까지는 정적 데이터로 알고 있으니 미리 그려달라고 여러 군데서 요청 및 피드백이 오니까 외면하긴 좀 그래서 조금 만져봤다. 어떤 테이블 헤더는 Record<string, string> 타입인데, 어떤 테이블 헤더는 Record<string, { label: string; size: number }> 타입이라 타입이 통일이 안 돼서 좀 별론가 싶었는데, header field 타입을 string으로 확장해버리는 순간 IDE에서 테이블을 만들 때 header를 구조 분해 할당 하면 키 값이 자동 추론이 안 되는 문제가 있어서 타입을 따로 지정해주지 않고 타입스크립트에게 타입 추론을 맡겼다. 개인적으로는 그게 좀 더 안전하다고 느꼈다.

테이블 그릴 때 Tanstack Table 라이브러리를 사용하고 있는데, table을 만들 때 size 옵션을 줄 수 있다. 근데 tanstack table 내부에서 getSize로 컬럼 width 사이즈를 가져올 때 재계산을 한 값을 리턴해서 그런지 내가 옵션으로 준 사이즈 값이 아닌 값이 리턴되는 경우가 있어서 스켈레톤 UI랑 실제 데이터가 주입되어 렌더링이 완료된 UI 사이에 약간의 덜컥거림이 있어서 애를 먹었는데 size 값을 조금씩 조정해서 간극을 조정했다. 😂

Tanstack Table 공식문서: Column Sizing

타입스크립트 관련해 첨언하자면 요즘 타입스크립트 책을 읽고 있는데, 타입스크립트는 알면 알수록 어려운 듯. 그래도 끝까지 다 읽어서 상반기 안에 1회독 완료하고 싶다.

결론

꿈은 없고요. 행복하게 재밌게 살고 싶어요. 기회가 되면 우리 팀원이 추천해준 대로 독립 출판이나 한 번 해볼까봐요. 이런 미천한 글도 읽어줄 사람들이 있을지는 모르겠지만요.

fin.