회사

작년 9월 회사에 합류해서 드디어 1년이 넘었다. 회사에는 딱 하나의 장기 프로젝트를 담당하고 있다. 유지보수가 아닌 새로운 서비스를 개발 프로젝트이다. 따라서 한창 진행 중인 프로젝트에 무엇인가 도입하고 변화를 주려는 시도는 무리가 있을 수 있었다. 아는 기술이라도 팀원들의 학습곡선을 고려해야 하며 일이 바쁜 시기에는 기술을 흡수하지 못해 오히려 기술 부채가 될 수도 있다.

그래도 필요한 선에서 기존의 레거시한 부분을 걷어내고 팀의 문제들을 해결할 필요가 있다고 생각했다. 오히려 초기 단계에 문제점을 잡아내고 팀의 생산성을 향상시키고 싶었다.

Tanstack-query

현재 진행하고 있는 프로젝트는 클라우드 모니터링 서비스며, 철저히 외부 API에 크게 의존하는 아키텍처이다. 그렇기 때문에 굳이 클라이언트 상태 관리를 할 필요성이 떨어진다. 그런데 AJAX 통신을 하여 받아온 응답을 다시 pinia에 전역으로 관리하는 구조를 현 프로젝트에서 지니고 있었다. 여기서 의문을 가졌는데

• 이미 server DB에 저장되어 있는 데이터인데 굳이 pinia저장소에 다시 저장해서 사용하는 것이 맞는건가?
• 서버에 있는 데이터들이 실시간으로 갱신되는데 반영이 직관적으로 가능한 것인가?
• 클라이언트 데이터와 서버 데이터의 경계이자 관심사 분리가 잘되는가?

무엇보다 위의 물음보다 내가 크게 신경쓰였던 부분은 바로 팀원들마다 컨벤션이 다른 점이였다.(현재 코드 컨벤션이 존재하지 않는다...)

// try / catch
async function fetchUserData(userId: string) {
  try {
    const response = await fetch(`/api/users/${userId}`)
    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`)
    }
    const data = await response.json()
    return data
  } catch (error) {
    console.error('Failed to fetch user:', error)
    throw error
  }
}
 
// promise 체이닝
function fetchUserData(userId: string) {
  return fetch(`/api/users/${userId}`)
    .then((response) => {
      if (!response.ok)
        throw new Error(`HTTP error! status: ${response.status}`)
      return response.json()
    })
    .catch((error) => {
      console.error('Failed to fetch user:', error)
      throw error
    })
}

통일되지 않은 컨벤션으로 인해 코드리뷰하는 것도 힘들기 마련이였다.

실제로 tanstack-query를 도입하면서 pinia에 의존된 서버 데이터를 분리하고, 코드 컨벤션도 composable(hook)으로 관리하면서 좀 더 선언적으로 통일하여 일관성을 지킬 수 있었다.

const useGetQueryData = (id: Ref<number>) => {
  const { data, isLoading, refetch } = useQuery({
    queryKey: ['유저 도메인', id],
    queryFn: async () => getApiData(unref(id)),
  })
 
  return { data, isLoading, refetch }
}

MSW

특정 기간에 서버가 자주 끊겼다. 짧은 시간 내에 복구되기는 했지만, 기한 내에 마무리해야 하는 시기에 꽤 오랜 시간 서버가 다운된 적이 있어 좀 프론트엔드 파트가 어려움을 겪었었다. 프론트엔드 개발자는 프로젝트 프로세스상 마무리 단계에 가장 바빠지는 위치라고 생각했기 때문에 이와 같은 문제를 해결하고 싶었다.

본질적으로 서버에서 문제를 해결해야 하는 것이 맞지만, 우리 팀이 아닌 인프라팀에서 관리하여 소통 비용의 문제도 있었고 인프라팀은 회사 전반적으로 모든 팀의 인프라를 관리해야 했기에 언제 문제를 해결해 주는지 알 수도 없었다. 그래서 프론트엔드 측면에서 문제해결을 하기 위해 MSW를 도입했다.

MSW는 브라우저와 네트워크 통신 사이의 서비스 워커를 이용하여 Proxy 서버처럼 동작하여 실제 API통신 하는 것처럼 동작한다. json.sever라는 라이브러리도 있었지만, 나는 js프레임워크의 호환성과 함께 node서버에서 테스트코드 작성을 위해 jest, vitest와의 궁합이 잘 맞기 때문에 MSW를 도입했다. (물론 아직 테스트코드 도입은 하지 않았다..ㅎㅎ)

기존 프로젝트의 코드를 수정하지 않고 mocking파일만 추가하면 되서 학습곡선은 높지 않았지만, 고려해야할 사항이 있었다.

• 개발환경에서만 필요한 Mocking파일이 build되는 문제
• 수동으로 Mocking을 on/off해야하는 문제

첫번째 문제는 간단히 webpack에서 간단한 설정을 해주었다.

chainWebpack: (config) => {
  config.plugin('copy').tap((args) => {
    args[0].patterns[0].globOptions.ignore.push(
      '**/mock/**',
      '**/mockServiceWorker.js',
    )
    return args
  })
  // ...생략
}

mock, mockServiceWorker를 포함하는 정적파일이 복사 되어 build되는 것을 방지 했다.

두번째 문제는 버튼을 하나 만들어서 해결했다.
tanstack-query의 devtool 버튼과 dark-mode 버튼에서 영감을 얻어냈다. 로컬스토리지에 현재 mocking상태를 저장하고, mocking상태를 스위칭하는 버튼 컴포넌트를 만들어 적용했다.

MSW를 도입한 결과 팀원들 모두 잘 사용하고 있었다. 서버가 끊기는 경우를 제외하고도 실제 DB에 데이터가 없는 경우, API가 개발이 완료되지 않은 경우에도 사용하기에 적합했다. 물론 서버 스펙이 바뀔 때마다 mocking파일들을 수정해 줘야 해서 관리해야 하는 코드도 늘어났다는 단점은 있지만, 팀에서 유용하게 사용하고 있다.

Eslint rule 적용

글 서두에 얘기했듯이 우리 팀은 컨벤션이 딱히 존재하지 않는다. 그러므로 발생하는 치명적인 문제가 하나 있는데 바로 코드리뷰였다. 리뷰어라면 리뷰이의 코드를 리뷰할 때 살펴볼 요소가 참 많다. 그런데 사소하게 변경되는 사항에 대해서도 리뷰하게 되면 골치가 아프다.

아직 전반적으로 eslint rule을 설정하지는 않았지만, 내가 첫번째로 주목한 점은 import문의 정렬이였다. 각각의 파일마다 import문이 정말 혼잡하다.

• import순서와 경로가 일관성이 없다.
• import내부의 순서 또한 일관성이 없다.
• 사용하지 않는 import문이 존재한다.

정리되지 않은 import문에 코드를 추가하거나 삭제하면 불필요한 commit diff가 생겨 머리가 아프다. 결국 조치를 취하기로 했다.

다행히 이를 지원하는 여러 플러그인이 있어서 이를 활용했다. eslint-plugin-import를 활용해 커스텀했다.

// AS-IS
import { ref, onMounted } from 'vue'
import '../styles/main.css'
import { useRouter } from 'vue-router'
import axios from 'axios'
import { UserService } from '../services/UserService'
import { formatDate } from './utils'
import Button from './components/Button.vue'
import { API_URL } from '../config/constants'
import Layout from '../components/Layout.vue'
 
// TO-BE
// Vue 관련 imports (최상단)
import { onMounted, ref } from 'vue'
import { useRouter } from 'vue-router'
 
// 외부 라이브러리 imports
import axios from 'axios'
 
// 내부 컴포넌트 imports
import Button from '@/components/Button.vue'
import Layout from '@/components/Layout.vue'
 
// 설정 imports
import { API_URL } from '@/config/constants'
 
// 서비스 및 유틸리티 imports
import { UserService } from '@/services/UserService'
import { formatDate } from '@/utils'

규칙을 제대로 적용하지 않으면 당연히 빨간 줄로 error가 표시되고 auto save --fix를 통해 저장시 자동으로 정렬하게끔 했다.

eslint rule을 적용하니 조금의 욕심이 생겨 husky를 사용하려고 시도 중이다. husky를 사용하려는 이유는 명확했다. 인프라팀에서 적용해 준 CICD는 그냥 자동배포만 해주는 상태이다. 즉, 에러가 나는 프로젝트라 해도 그대로 배포된다. CI에서 lint체크, type체크 등을 해주고 있지 않다. 배포 프로세스가 다른 팀에 관여되어 있으니 함부로 건들 수가 없었다.

그래서 git hook을 편하게 작성해주는 husky를 이용해 pre-commit단계에서 프로젝트의 정합성을 체크해 통과되어야만 commit이 되도록 시도중이다.

공통 컴포넌트에 대한 고찰

팀에서 공통으로 사용할 수 있는 컴포넌트를 만들었다. 팀원들이 사용할 수 있게 꼼꼼하게 만들었다고 생각했지만 실패했다.

지금까지 어떻게든 비슷한 UI구조를 가졌다면 하나의 공통 컴포넌트로 구조화하여 사용하곤 했었다. 그런데 실제 이렇게 운영한 결과, 팀원마다 사용하는 도메인에 적용하니 구조가 조금씩 달라져야 했다. 게다가 기획이란 언제든지 바뀌기 마련이고 이를 반영하게 되면 컴포넌트 하나에 무수히 많은 분기 처리를 해야 하며, 여러 인터페이스 타입을 수용해야 하는 보기 힘든 코드가 되어버렸다.

어떤 분의 블로그를 보고 좀 공감을 많이 했다. 그래서 UI구조에 맞는 공통의 컴포넌트를 구성하기보다 특점 도메인 데이터의 관점에 맞춰 컴포넌트를 구성하는 방향이 좋지 않을까 생각했다.

모든 기술에는 트레이드 오프가 있듯이 결과적으로 컴포넌트 파일이 많아지기는 했지만, 관심사에 맞게 분리하여 특정 도메인의 변경 사항에만 유연하게 대처할 수 있게 되었다.

협업에서의 태도

내가 생각하는 이상적인 팀이란 어떤 것일까 생각을 해 보았다. 🤔

내가 생각하는 이상적인 팀

• 큰 고민 없이 자유롭게 이야기를 꺼낼 수 있는 분위기
• 팀원들간에 사소한 사적인 농담 정도 던질 수 있는 분위기

결국 팀원들끼리 친밀도가 높아야 한다는 말이다. 사실 내가 속해있는 팀은 팀원들간에 그리 친한 분위기가 이니다. 조용하신 분들이 좀 계신다.(분위기가 나쁘다는 이야기는 아니다.)

아쉽기는 하지만 어쩔 수는 없었다. 그래서 나라도 사소한 것부터 시도했다. 일단 메신저에서 조금 더 말투나 리액션을 했다. 딱딱한 단답형의 말투와 ...으로 끝나는 말투를 조심했다. 개인적으로 이런 말투는 좀 힘 빠지고 공격적으로 보일 수 있다고 생각했다. 그래서 말끝에 이모지나 느낌표를 붙여 조금도 친근하게 다가가려 했던 것 같다. (상대방에 거부감이 없도록..?) 또한 남들의 말에 될 수 있으면 대답을 최우선하고 이모지를 꼭 남겼다.

Dan24에서 캡틴판교님의 세션을 들었는데, 캡틴판교님은 항상 코드리뷰할 때 하트 이모지를 남긴다고 말씀하셨다. 나름대로 좀 더 팀원들에게 애정을 갖고 부드러운 말을 전달하고 싶어서 그렇게 하신 것 같다. 코드 리뷰할 때는 더더욱 말투를 신경 쓰는 게 맞다고 생각한다. 특히 나보다 높은 연차의 분에게 리뷰를 남길 때는 더더욱 신경 썼다. 내 의견을 내더라도 내 의견이 맞는다는 식의 느낌을 주지 않게라던가, 확실히 고쳐야 하는 부분을 ~어떨까요? 라고 어미를 붙여 부드럽게 이야기했다. (물론 동기들에게도 같은 방식으로 했다..ㅋㅋ)

가는 말이 고와야 오는 말도 곱다고, 내가 지속적으로 신경 쓰니 그렇게 하지 않았던 팀원들도 최대한 상대방을 존중하려는 말투를 사용하려는 시도가 보여서 참 고마웠다. 🙇

1년의 경험이 나에게 도움이 되었는가?

위의 경험들은 내가 회사에서의 직접 문제를 찾고 주도적으로 해결했다. '현재 팀이 겪고 있는 문제를 해결하여 생산성을 높이고 시간 낭비를 하게 만들지 말자!' 이게 내가 일하면서 얻는 즐거움으로 다가오는 것 같다. 팀원들이 쉽게 적용하기 위해 간단한 예제 코드도 만들고 실제 브랜치를 파서 적용하고, 문서화를 진행하고 발표까지 싹 다 진행했다. '내가 이렇게 여러 기술이나 문화를 도입하면서도 이게 될까? 많이 사용할까?' 라는 생각을 했지만 팀원들이 실무에서 지속적으로 사용하는 모습을 보고 뿌듯하고 좋았다.

아직 사내에 도입하고 싶은 것들이 몇가지가 더 있다. 개발환경에서 빌드 속도가 너무 느려 webpack에서 vite로 번들러를 변경한다던지, 코드품질을 높이고 안정감을 높여주는 테스트 코드를 도입 한다던지 등이 존재하며, 꼭 이뤄내고 싶다.

대외활동 및 자기계발

회사 업무에서 벗어나 다양한 사람을 만나 시야를 넓히고 함께 인사이트를 얻어가고 싶었다.
올해 참 많은 대외활동을 했다.

사이드 프로젝트

작년 말 간단한 사이드 프로젝트를 진행했었다. 포텐데이라는 해커톤에서 진행했던 프로젝트인데, 기획자와 디자이너와 함께 협업할 수 있었던 것이 매력적이라 생각했다.

단 일주일의 시간만이 주어진 프로젝트라 휴가도 쓰고 회사 일을 마치고 나서 밤새워서 작업을 하기도 했다. 어느 정도 시간 내에 목표하고자 하는 기능을 토대로 개발할 수 있었고 팀원들은 추후에도 디벨롭하자고 얘기도 했던 터라 해커톤이 끝나고도 작업이 이어졌다.

결말을 먼저 이야기하자면 중도 하차했다. 그 이유에는 세가지가 있었는데

1. 프로젝트의 깊이가 회사 실무에 비해 깊지가 않았다.
2. 현업자로 구성되어 있어 프로젝트 진행이 뎌딘점이 있었다.
3. 프로젝트 구성원이 나가면 기간이 딜레이가 되었다.

위의 문제들로 고민이 있었고, 프로젝트가 정상적으로 지속되는 느낌을 받지 못해 기획자분에게 중도하차하겠다 말씀드렸다.

사이드 프로젝트에 대해 너무 단점들만 얘기한 거 같아, 장점을 이야기하자면...
회사 실무의 프로젝트보다는 내가 하고 싶은 프로젝트 도메인을 하고 보다 사용자 관점에서 생각하며 개발했던 터라 내 가슴을 뛰게 했고, 내가 구성하고 싶은 기술 스택을 마음대로 할 수 있어서 좋았던 점도 많았다. (실제 사용자유도를 했다면 더욱 유의미했겠지만..)

내 나름대로 좋은 경험이였다. 후기 링크

항해 플러스

사이드 프로젝트를 그만두려고 할 때쯤 현타가 좀 왔다... 성장을 위해 투자한 시간이 조금은 물거품이 되는 거 같았다. 그러다 항해 플러스를 알게 되었다. 취준이 아닌 현업자를 대상으로 하는 교육이라 조금 끌렸다. 그래서 냅다 신청했다.

교육을 들으면서 성장한 것도 맞지만 코치님들의 조언과 함께하는 동료들의 이야기에 조금 더 시야가 넓어졌다. 내가 어떻게 해야 할지 방향성을 찾아가는 느낌이랄까...? 가격은 좀 부담이 될 수 있지만 커리어를 고민하는 주니어분들이라면 해봐도 괜찮을 것 같다. 항해 플러스 후기글을 작성하기도 했는데 생각보다 많은 분이 연락주셔서 신기했다.

과정이 끝나고 mt를 가기도 했다.

이후 다음 기수를 위해 학습메이트로 활동했다. 참여자분들의 과제를 채점해 코치님들을 돕고 내가 맡고 있는 팀원분들에게 팁을 드리며 도움을 주는 활동이였다. 팀원분들이 해결해 나가고자하는 모습을 보면서,나때는 왜 저렇게 하지 못했을까?, 어떻게 저렇게 까지 생각할 수 있지? 생각하며 많이 배웠다. (18조 분들 너무 수고하셨습니다..! 🫡)

스터디

올해 총 3차례 스터디를 직접 주도하여 진행했다. 처음 스터디를 한번 열어볼까라고 생각하고 여러 스터디 후기를 찾아보면 스터디 도중에 이탈하고 무의미한 진행의 이야기가 줄을 이었다. (절망편...?) 그래서 스터디가 터지지만은 않기를 하고 기도했었다. 다행히도 3개의 스터디 모두 이탈자 없이 진행했다. (이게 절반은 성공이 아닐까??)

스터디에는 취준하는 분은 없고 모두 현업자였기 때문에 최대한 부담이 되지 않는 선에서 구성하려 애썼다. 그 덕에 모두가 잘 참여해 준 거 같다. 물론 후반부로 갈수록 힘이 떨어지는 걸 느끼기는 했지만 어떻게 할 수가 없는 부분인 거 같다...ㅜㅜ

올해 마지막으로 진행한 프없프(프레임워크 없는 프론트엔드) 스터디가 나름 기억에 남았다. 항해 플러스 과정을 같이한 동료들의 단톡방에 공지했고 고맙게도 제한된 인원을 넘어서 많은 분이 신청해 주셨다. 또 다 내가 좋아하는 분들이 신청해 주어 좋았다. github에 꾸준히 issue와 pr을 올리고 정리하였다. 그리고 무려 37개의 star를 얻었다. (눌러주신 분들 감사합니다...ㅠ)

사실 스터디란게 다 같이 으쌰으쌰하며 인사이트를 얻어가고자 하는 목표도 있지만, 결국 스터디도 내 하기 나름이다. 열정적인 스터디원들이라는 소스를 가지고 본인 의지에 따라 스터디의 질도 달라지는 것 같다. 개인적으로는 온라인으로 딱딱하게 벽 보듯이 이야기를 진행하는 것보다 오프라인으로 얼굴보고 진행하는 것이 더 재밌다. (온라인이면 캠이라도 켜야겠더라..)

컨퍼런스

올해 총 3개의 컨퍼런스에 다녀왔다. 스피커들의 생각과 경험을 들을 수 있는 건 너무나도 재밌는 일이다.

작년 제2회 테오콘에 다녀왔었다. 그곳에서 주니어 프론트엔드 개발자로서 많은 격려와 위로를 받을 수 있어 정말 좋은 경험이 되었기에 3회 테오콘에 스태프로 참여하여 내가 인사이트를 받은 것처럼 남들에게 인사이트를 줄 수 있는 무대를 내 손으로 기여할 수 있다는 생각에 자원하게 되었다.

이런저런 이슈가 있었지만 그래도 성공적으로 행사를 마칠 수 있었다. 주말 이틀을 반납했지만 많은 분들의 후기를 보니 뿌듯했다. 뒤풀이에서도 많은 분의 이야기를 들을 수 있어 좋았다.

긴 시간 동안 테오콘을 함께 만들어준 스태프들, 스피커분들 그리고 무엇보다 자리를 마련해준 테오에게 고맙단 말을 남겨본다!🙇‍♂️

또 얼마전에는 송도 DevFest에 다녀왔다. 초원이를 통해 민재님과 이야기할 기회를 얻었고, 민재님과 좋은 이야기를 주고받을 수 있었다. 마침 민재님의 발표가 있었고, 이를 보러 갈 겸 송도로 향했다.

민재님의 발표를 듣기에 앞서, 신원규님의 동료가 컨벤션을 자꾸 까먹는다면을 청강했는데 현재 내가 실무에서 고민하는 부분의 내용과 흡사해서 기억에 남았다...
리뷰어가 코드 컨벤션까지 리뷰하기는 너무나도 골치 아픈 일이 맞는 거 같다...ㅎㅎ

원규님의 발표를 마지막으로 드디어 민재님의 발표를 들었다. 사실 블로그에서 어느 정도 민재님의 개발자 커리어의 전반적인 이야기를 들을 수 있었지만, 직접 청강해서 듣는 이야기들이 더 생생하고 좋았다. 회사에서 실무적으로 어떤 일을 주도적으로 해봤다는 경험 이야기가 좋았다👍👍 좋은 발표 들을 기회를 주신 민재님께 감사했다.

마지막으로 빅테크에서 진행하는 컨퍼런스와는 인연이 멀었는데, 이번에 다행히도 당첨되었다. Dan2024는 이틀을 걸쳐 진행되는데, 나는 첫날이었다. 주변에 당첨된 지인이 없어서 혼자 외롭게 갔었다...ㅋㅋㅋ 찍어둔 사진이 많지는 않아서 아쉽다.

오픈소스

처음으로 오픈소스에 기여하게 되었다. 바로 es-toolkit이다. 평소에 오픈소스에 기여하고 싶다는 생각은 했으나 행동으로 옮기지 못했다. 메이저한 오픈소스같은 경우 기여하고 싶은 사람들이 너무 몰려서 기여할 소스 찾기가 어려웠고, 단순 번역이나 오타 수정같은 업무는 개인적으로 크게 의미가 있다고 생각을 하지 않았다.

그 와중에 toss에서 loadash보다 가벼우면서 호환성이 좋은 유틸 라이브러리를 만드는 것에 호기심이 생겼고, 마침 내가 평소에 알고 지내던 지인 개발자분이 es-toolkit에 기여한 것을 보고 팁을 얻어갔다.

나름대로 많은 기여를 하여 메인페이지에 contributor로 프로필 이미지가 딱 올라갔을 때, 뭔가 짜릿하면서 좋았다...
뭐든 처음이 어렵다고 처음 기여할 때까지만 해도 마음 졸이고 있었는데, 몇 번의 기여 끝에 아무렇지 않게 pr을 올릴 수 있게 되었다. pr을 올리면 실력 좋은 개발자분들이 봐주고 코멘트도 남겨주니 더 얻어갈 것이 많았던 것 같다.

블로그

취준 시절 나의 무기로 꾸준함을 면접에서 이야기하곤 했다. 하지만 이것 또한 옛말이 되어 버렸다. '블로그 글을 그래도 달에는 1개 정도씩은 어떻게서든 쓰자! 생각은 했는데 최근 생각이 바뀌었다.

개발자가 점점 많아져 블로그 또한 거의 반필수적으로 되었다고 할 수 있다. 따라서 무수히 많은 글이 쏟아지고 있는데 매력 없이 복붙한 글이나 잘못된 정보가 담겨있는 글도 참 많았다. 이제 경력을 쌓아가는데 글의 퀄리티를 높이는 것에 포커스를 맞추는 게 어떨까 했다.

그래서 무모하게 '달에 1개씩 써 내려가자!'는 글의 주제를 억지로 정하고 써 내려가서 퀄리티를 낮춘다고 생각했다. 꾸준히 쓰기보다는 내가 영감 있거나 재밌어하는 것이 생각나면 그때 작성하는 편이 더 좋아 보였다. 그래서 조금 더 애정을 가지고 내 생각을 담은 글들을 써 내렸고 그만큼 좋아해 주시는 분들이 늘었다.

커피챗

올해 처음 링크드인을 본격적으로 시작했다. 공부나 대외활동했던 블로그 글을 작성하고 홍보하는 느낌으로 나를 PR했던 거 같다. 활동하면서 DM으로 연락해 주시는 분들이 종종 계셨다. 그중 한 분이 커피챗을 요청해 주셨다. 요청해 주신 분은 같은 대학동문 후배분이셨다. 생애 첫 커피 챗이기도 했고 하던 일도 많던 거라 커피 챗 준비(?)가 덜 된 채로 화상으로 진행했다.

후배분은 이미 나보다 개발 커리어를 먼저 시작하셨고 학교에 없었던 개발 커뮤니티를 만들기 위해 노력하는 모습이 보였다. 학교 재학시절에도 개발 관련 커뮤니티가 딱히 존재하지도 않았고 지금도 눈에 띄는 모임도 없는 것 같았다. 다른 학교를 보면 선후배들끼리 서로를 끌어주는 일종의 커뮤니티가 있는 것 같아 참 보기 좋아서, 우리도 저런 게 있었으면 얼마나 좋을까...? 라는 생각을 가지고 있었다.

그래서 후배분이 활동들을 주도하시는 모습이 멋있었고 응원하게 되었다.

일상

운동

유퀴즈에 임시완이 나와 미생에 나왔던 내용 중 실제로 실천하고 있는 글귀로 체력을 먼저 길러라라는 내용이 있었다. 이 말에 공감이 갔다. 회사 일과 개인 시간 등을 활용하며 체력이 떨어져 나간다는 느낌을 많이 받았다. 특히 새벽까지 공부하고 출근할 때 참 힘들었다. 모든 것이 체력으로 귀결되었다.

올해 초 테니스를 시작했다. 운동을 꾸준히 하는 게 중요하다는 걸 알기에, 꾸준히 할 수 있는 건 그만큼 재미를 붙일 수 있는 거라고 생각해서 테니스를 선택했다. 요즈음 실내 테니스장도 많이 생겨 날씨에 크게 상관없이 할 수 있으며, 테니스란 운동 자체가 생각보다 체력을 키우는 데 도움이 많이 되었다.

그 외에도 클라이밍, 볼링도 하고 등산도 했다.

출사

원래 사진 찍는 걸 좋아한다. 취업 준비 기간에도 간간이 사진을 찍으며 직접 보정도 진행했었다. 풍경 사진 찍는 것도 좋지만 인물사진을 찍는 것에 더 흥미가 있었다. 이 사람이 이런 표정도 지을 줄 아는구나 하며 보정하는 재미가 있었다. (사람의 표정을 찾아내는 재미랄까..?)

하지만 올해 한 컷도 찍지 못했다. 못했다기보다는 안 했다는 표현이 더 맞겠다... 여러 이유가 있지만 당연히 여유가 없다. 일하고 공부하고 사진을 찍는 시간까지 내는 것은 괜찮지만, 보정하는 시간은 어느 정도 시간이 필요했다. 게다가 보정을 위한 툴들도 유료 결제(LinkedIn처럼 매달)를 진행해야 하는데 조금 부담이 되기도 했다. 아직은 할 것도 많고 이루고 싶은 것도 많아서 여유가 생기면 다시 한번 시도해 볼지 생각중이다.

쉬는 것도 충분히 쉬자.

9월부터 너무 바빴다. 많은 사람을 알게 되어 약속도 많고, 공부도 하고 테오콘도 준비하고 여유가 많지 않았다. 한편으로 같이 활동이 겹친 초원이가 더 많은 활동을 하는게 내 눈에 보여서인지, '초원이도 저렇게 열심히 사는데 나도 그래야지!'라는 마음에 더 열심히 달렸던거 같다..ㅋㅋㅋ 평소에 집에만 있으면 아쉬워하던 나였는데, 언제부턴가 집에서 틀어박혀 쉬고 싶다는 생각을 많이 했다. 그래서 연말에 약속을 많이 잡지 않았다.

집에서 좀 더 시간을 보내고 리프레쉬하는 시간을 가지며 다시 달리기 위한 에너지를 충전하고 있다.

독서

사실 내년 계획이다. 출퇴근의 반복이다보니 이 시간동안 유튜브나 sns를 바라보는 건 시간이 아깝다고 생각했다. 그래서 이 시간만이라도 미디어에서 벗어나 독서를 해볼까 생각했다.

무거운 종이책 대신 아이패드로 독서를 시작했는데, 개발도서 독서는 출근 시간에는 혼잡하고 퇴근시간에는 힘을 다 써버리니 머리에 잘 안들어 왔다. 보다 가볍게 읽을 수 있는 책이 좋을 거 같다. 내년부터 바로 구매하여 읽을 예정이다.(책 추천받습니다!)

요즘생각(이모저모..)

감흥이 없다.

연말이라 크리스마스가 되어가는 데, 딱히 감흥은 없다. 사실 이런 감정을 느낀건 좀 된 거 같다. 기념일이나 생일 등 그냥 스쳐지나가는 날로 머리에 박혔다.

예전에는 옷에도 관심이 많아 매번 계절이 바뀔때마다 무신사를 뒤지곤 했다. 근데 요즘은 잘 보지도 않고 출근을 위해 대충 꺼내 입곤 한다.

나이를 먹는다면 점점 특별한 날에 무뎌지고 편안한게 좋다더니 나 또한 그렇게 변하는 것 같다. 어머니께 이런 얘기를 했더니 무슨 애늙은이냐고 그러더라...ㅋㅋㅋ

결과가 과정을 미화한다.

유튜브에 최근 관심있게 보고 있는 입시 유튜버 미미미누의 all about 입시 콘텐츠가 있다. 메인 MC로 윤도영이라는 인강강사이자 입시상담사 분이 출연한다. 인강1타 강사로 유명하지만, 냉철하고 본인을 극T로 이야기해 캐릭터가 확실한 걸로도 유명하다.

하여튼 이 분이 상담해준 내용 중 이야기 해준 대목이 생각난다.

사람은 결국 결과로 증명하는 것 같다. 남들보다 노력하지 않는 과정에서 남들이 부러워할만한 최상의 결과를 낳더라도 남들이 기억하는 건 결과다. 주변 지인들에게 열심히 한다라는 말을 많이 듣곤 한다. 이제는 Show And Prove할 시기라고 생각한다.

공감하는 방식

나는 esfj다. f다 보니 감정적일거라는 얘기를 많이 듣는데, 만나는 상대방에 따라 반응은 다르게 해주는 편인거 같다.

예를 들어 내가 친하지 않은 바운더리에 있는 사람에게는 그 사람이 원하는 공감을 던져주는 편이다.
반면에 내가 친하다 생각하는 사람들에게는 그 사람이 원하는 공감보다는 조언이나 해결책 위주로 던져주는 것 같다.

내 사람이다라고 느꼈을 때 공감보다는 현실적인 방법을 알려주려고 한다. 나는 이게 나름대로 T적인 공감 방식이라고 생각한다.(물론 상황에 따라 다르다.)
현실적인 이야기를 해주는게 나름 대로 상대방을 생각해서 말해주는 것이니..? 그렇지 않을까?

피곤해 보여?

올해 참 많은 사람들을 만났는데 나를 보는 사람들마다 이런 한마디씩은 꼭 던지고 갔다.

실제로 한창 하고싶은게 많을 때 회사에서 늦게까지 남아 택시를 타고가곤 했다. 해커톤에서는 백엔드 이슈가 터져서 프론트단에서 해결하기 위해 밤을 새기도 했다.

피곤해보인다라는 말을 어떻게 보면 안좋게 받아들일 수도 있는데 생각해보니 뭐 그 만큼 열심히 살았다는 증거 아닐까? 실제로 나의 장점은 책임감이라 생각한다. 꼭 개발적인 것뿐만 아니라 내가 맡은 바에 밤을 새서라도 내 몫을 다했다. 그래서 "나 오늘도 열심히 살고 있구나?? 오히려 좋아!" 로 긍정적인 사고 전환을 하니 좋게 받아드려졌다..ㅎㅎㅎ(그래도 밤샘은 몸에 해롭다)

부담감 덜기

올해초 스터디에서 이런 고민을 털어 놓았다.

이 말을 들은 스터디원 중 한 분이 본인도 공감하며, 어떤 일을 할 때 잘해야 지라는 생각 보다는 그냥 하는거지라고 평범하게 마음가짐을 하고 진행한다고 했다. 잘해내야지라는 생각이 오히려 나에게 부담감을 가져다 주어 능률이 떨어질 수도 있기 때문에, 나 또한 이전 보다는 편하게 마음을 먹고 일을 진행한다. 일단 진행한다는 첫 걸음이 사실 중요한 거 아닐까?

스스로에게 엄격한게 문제인거 같다.

자유롭게 대화하는 커뮤니티

인사이트를 얻기위해 많은 오픈채팅방에 참여하고 있다. 좋은 질문들과 정보가 무수히 쏟아지고 있지만 개인적으로 사람이 너무 많고 익명이라 그런가 자연스럽게 대화에 끼지는 못한다. 최근에 지인이 본인이 알고 있는 개발자분들 위주로 편하게 대화를 나누고 이야기할 수 있는 방을 만드시는 것 같았다. 기회가 있다면 조만간 들어갈 예정이다.

위에 언급했던 대화방은 아니지만 함께 수료했던 항플 단톡방이 있는데, 함께 고생하고 친해졌던 사람들이라 물어보기가 수월했던 것 같다. (질문에 답해주신분들께 감사했다..🥹)

마치며

여러 활동들은 거치며 많은 사람들을 얻어가며 좋은 경험을 했다. 그 와중에 적극적이고 책임감있는 자세로 좋은 메시지들을 많이 받았다.

아직 하고싶은 것도, 배울 것도, 이뤄낼 것도 많은 시기기 때문에 꾸준하게 달려나갈 예정이다. 에너지 충전을 위해 연말에는 좀 쉬어가며 2025년을 맞이하길 준비하면서 글을 마친다. 긴 글을 읽어주셔서 감사합니다.