늦다 못해 숙성되어버린 한 해 회고

서론

뒤늦게 회고글을 작성한다.

2023년엔 좀 더 바쁘게 살기 위해, 그 바쁨 속에서 유의미한 결과물을 만들어 내기 위해,

마냥 바쁘기만 했던 2022년과 2023년 2월까지를 되돌아보겠다.

또한, 대부분 실무와 관련된 이야기겠지만 중간중간 실무 외 얘기도 섞어서 적어두었다.

소개

나를 소개하며 2022년의 주요 활동 소개

응애 개발자(걸음마 중)

게임회사에 입사하여 인턴 기간을 제외하고 어느덧 10개월이 되었다.

지원 당시 자기소개서를 보면 백엔드 개발자가 되고 싶어 대용량 트래픽이 어쩌고 구구절절 적혀 있는데 지금 보면 실무를 1도 모르고 하는 소리가 그저 귀엽다.

최종 합격 후 멘토님께서 “무슨 스택을 할 지도 모르는데 덜컥 붙었다고 가는 건 성급한 결정이다”라고 말씀하시면서 많은 우려를 하셨었는데, 지금 생각해 보면 그분의 말이 맞았을지도 모르겠다.

내가 어떤 팀에 배정될 지 전혀 몰랐었는데 어찌 됐건 덜컥 합격한 회사에서 일하고 있고, 의도한 것은 아니지만 백엔드뿐 아니라 프론트 엔드, 데브옵스(아주 살짝)도 함께 하고 있다.

여러 세부직군을 병행하며 느낀 것은 난 그냥 개발 자체를 좋아하는게 확실하다. 다만, 요즘 들어 백엔드에만 집중하고 싶다는 생각이 많이 든다.

너무 방대한 스택을 병행하며 프로덕트를 찍어내는 것에만 몰두하다 보니 방향성(커리어)을 잃어가는 느낌이랄까..

하나의 세부직군만 해도 공부할 것은 산더미인데 이거 조금 저거 조금 하는 느낌?

게임회사 특성상 어쩔 수 없는 것 같기도 한데, 어찌됐건 늘 그래왔듯 지금 포지션에서 아주 적극인 스탠스로 성과에 기여하고 있다. 그리고 위에서 언급한 불안함을 해소하기 위해 업무 외 시간에 스터디를 병행하며 백엔드 스택을 깊게 공부해보고 있다.

2022년 주요 활동 소개

대부분 직장인이라면 하루 중 가장 많은 시간을 회사에서 보낼 것이다. 나 또한 마찬가지인데 크게 회사와 회사 외를 구분하여 주로 활동했던 것들을 말하겠다.

1. 회사

인턴 기간부터 조금씩 개선해오던 서비스의 볼륨이 커졌고 TF 팀처럼 기획자+PM+개발자가 마치 한 팀이 되어 사용자를 더욱 많이 유치하기 위해 노력하고 있다.
많은 사용자 유입을 위해 큼지막한 서비스를 연동해야 하는 기능이 필요했는데, 이 기능 구현을 혼자 도맡아서 했고 메시지 큐를 이용해 성공적으로 구현하였다.
기술 블로그를 개발해야 하는 기획이 나왔고, 스터디 프로젝트로 좋아요/댓글/포스팅 구현을 하고 있던 터라 기능을 도맡아 개발하여 서비스했다.
배울 점이 많은 리더를 만났다. 다방면으로 정말 많이, 깊게 알고 계시고 대화를 할 때 항상 의견 제시, 그에 대한 논리적 이유를 연이어 말씀해 주셔서 마음이 편안하다.
사내 촬영 콘텐츠에 정말 많이 출연했다. 아직은 사내에만 공개된 콘텐츠라 공개할 수 없지만 훗날 공개된다면 재밌을 것 같다.
1년이 지나서야 “회사 일에 욕심내지 않는 게 좋아요”라는 말을 이해하기 시작했다. 적당히 힘을 뺄 줄도 알아야 롱런할 수 있었다.
회사 업무를 하다 도저히 해결되지 않는 로직이 있어서 개발바닥 톡방에 질문을 남겼는데 호돌님께서 zoom 미팅을 열어 직접 가이드해주셨다.

2. 대외활동

연초에 쉴 새 없이 스터디를 했다. 클린코드, 블로그 만들기 등을 했고 지금은 CS 지식에 기반한 개발 토론(?)을 하고 있다.
넥스터즈 21기를 팀장으로 이수했다.
이어서 넥스터즈 22기 회장이 되어 지금 넥스터즈 22기의 전반적인 운영 기획 협력 제안 등을 하고 있다.
넥스터즈 회장을 하면서 가장 기억에 남는 게 지원자 면접인데 개발자로서 정말 많이 반성했다.
우물 안 개구리가 밖을 나갔더니 또 우물이 있고, 그 우물을 계속 빠져나가며 고수는 많다는 걸 깨달았다.
아무튼 정말 많은 동기부여가 되었고, 넥스터즈 운영이 끝나면 정말 미친 듯이 공부해야지!!라는 생각과 계획을 세웠다.

블로그 포스팅에 강제성을 부여하기 위해서 글또 8기에 참여하고 있다.
유니톤이라는 해커톤에 스탭으로 참여했다. 똑같은 시간인데도 상대적으로 우수한 퀄리티를 뽑은 팀을 보며 대단하다는 생각이 들었다. (심지어 고등학생팀)

3. 그 외

승친소(내 친구 소개하는 자리)를 번개로 진행했고, 서로 그룹이 다른 친구들이 모여 수다를 떨었다. 거의 번개로 모집했는데 많은 친구들이 참여해 줘서 재밌었다!!
넥스터즈 회장을 할 때 운영 업무로 개인 공부할 시간이 전혀 없어서 압박감에 번아웃이 왔었다.
회사 및 대외활동에서 정말 좋은 사람들을 많이 만났다.
Chatgpt와 관련된 확장 프로그램 오픈소스에 컨트리뷰터가 되었다. (고작 한 줄이지만 ^_^)

기술 스택과 프로젝트 경험

회사 내 개발과 기술스택 경험

백엔드

1. Redis Cache
잦은 외부 API 호출이 발생하는 부분이 있었는데 속도 개선을 위해 Redis를 도입하였다.

처음엔 한 프로젝트에서만 사용했고 이후 내가 담당하고 있는 프로젝트에서도 Redis를 사용하여 속도 개선을 하려 했다.

오매.. 근데,, 먼저 쓰고 있던 프로젝트와 소스코드가 동일한데도 불구하고 두 프로젝트에서 캐시를 읽지 못하는 문제가 발생했다..

확인해 보니 캐시에 데이터를 저장할 때 package가 함께 등록되고 있었고, 읽어 올 땐 이 package가 일치하지 않으면 읽어지지 않는 문제였다..

테스트 환경에선 당연히 한 프로젝트에서만 테스트하니까 잘 작동됐고 두 프로젝트가 동시에 작동하는 환경으로 올리니까 저런 문제가 발생했다.

이슈 발견은 다른 팀원이 화들짝 놀라 내게 전달해 주셨고, 예상치 못한 이슈에 새삼 기분이 좋았다. 아무튼 이후 package를 검사한다는 부분을 캐치하고 RedisTemplate을 직접 구현하여 이 부분을 해결할 수 있었다.

그리고 이 Template은 팀 내 Redis Cache를 사용하기 위한 공통 라이브러리처럼 쓰이고 있다

2. Amazon SQS

혼자 프로젝트를 진행했던 부분이었는데, 클라이언트의 요청을 큐에 적재하고 그 큐에서 로직을 처리하는 부분이었다.

구현하고자 하는 서비스에 적합한 메시지 큐가 무엇인지 Kafka, RabbitMQ, SQS에 대해 조사했고 사실 거창한 기능은 필요 없이

서버가 죽어도 클라이언트의 요청값만 소실되지 않도록 보관하고, 그룹에 따라 처리하면 되는 요구사항이라고 판단했기에 SQS를 선택했다.

특정 그룹에서 에러가 발생하면 재시도를 요청하고 해당 그룹에 쌓이는 다른 큐는 처리가 되지 않는 구조이기에 내가 구현하고자 했던 방향과 일치했다.

결과적으로 SQS FIFO를 이용해 원하는 요구사항에 적절히 구현했다.

다만, 팀 방향성에 따라 정말 러프하게 구현되었고 더 이상 서비스 규모가 커질 일이 없기에 최대한 모놀리틱 하게 구현되었다.

오버엔지니어링과 내 개발 욕심 그 사이 어딘가에서 타협점을 찾았다. (욕심대로 갔다면 요청 규모에 비해 엄청난 산이 되었을 듯)

3. ArgoCD, k8s, kibana

내가 입사했을 때 GitLab을 이용한 배포 파이프라인을 처음 직접 구성했고, CI에서 빌드부터 ECR 푸시까지 진행했다.

이맘때쯤 시스템 담당자분이 k8s를 써보자!! 라며 강력하게 의견을 내셨던 것으로 기억하는데 이후 ECR에 푸시된 도커 이미지 파일을 k8s에 올리는 것까지 진행된 것으로 안다.

이후 argoCD라며 신문물을 접했는데 컨테이너를 관리하는 데 있어 정말 편리했다. 이후 수동 배포를 하게 되면 매니패스트 파일을 통해 ECR 이미지를 직접 수정해야 했는데

런덱이라는게 또 도입되면서 상위 보고부터 배포까지 한 큐에 자동으로 되었다. 뭔가 거대한 서비스들이 이런 부품들이 끼워지면서 편리한 배포 파이프라인, 자동 결재, 배포 모니터링이 되는 게 너무나 신기했다.

그리고 서비스가 운영되면서 각종 라이브 이슈들이 자잘하게 터졌는데, 이를 모니터링하기 위해 사내 로그를 적재하는 서비스를 연동하고 Kibana를 통해 이 로그를 열람할 수 있었다.

아직 Kibana를 다루는데 영 서툴지만 쓰다 보면 적응되어 잘 쓸 수 있을 것 같다.

프론트엔드

1. Vue2

리팩토링 과정을 거치면서 Vue3로 넘어가려 했으나 사용 중인 패키지들이 Vue3로 호환되지 않는 것들이 있어서 엄청난 난항을 겪고,

다시 Vue2로 돌아와 유지보수를 하고 있다. 이제 Vue2를 사용하는 것이 능숙해졌고, scss 작업도 어느 정도 수월해졌다.

처음엔 프레임워크 사용 자체가 서툴렀다면 이젠 컴포넌트를 어떻게 잘 분리해서 재사용성을 높일지에 대한 고민을 하는 것 같다.

즉 초반엔 단순히 구현에만 초점을 맞췄더라면 이젠 구현과 동시에 확장성, 유지보수성을 고려하여 구현하는 단계에 이르렀다.

하지만 과거에 특정 컴포넌트를 직접 구현한 담당자가 아니면 손대기가 힘든 코드들을 보며 눈앞이 캄캄해지기도 한다.

2. package-lock.json

이젠 Vue로 만들어진 컴포넌트를 유지보수 할 수 있는 능력까지 생겼다.

나는 프엔 개발자인가 백엔 개발자인가 말하는 감자인가..

아무튼 컴포넌트에 기능 추가를 하고 배포 이후에 해당 컴포넌트를 쓰는 프로젝트에서 업데이트를 시켜줬더니 이게 웬걸..

해당 컴포넌트를 쓰는 부분이 펑펑 터졌다. 로컬에선 매우 잘돼서 개발환경으로 올렸는데 몹시 당황스러웠다.

알고 보니 package.json에서 버전업을 했지만 package-lock.json에서는 버전업이 되지 않았던 문제였고.. static 하게 버전이 박혀있었던 것…^^

예전에 삼성리서치 오픈소스 프로젝트를 하면서 package-lock.json을 살리냐 죽이냐(ignore)로 얘기가 오갔던 적이 있는데 그때 package-lock.json에 대한 개념을 얼추 알고 있었어서 이번에 나름 빠르게 대처할 수 있었다.

이게 상황을 자세히 설명하면 좀 복잡한데 Gitlab Container Registry에 CI에서 돌아갈 latest 이미지를 등록하다가 궤변이 발생한 거라, 해당 이미지를 쓰기 위해 CI를 돌리지 않으면 확인이 힘들었다..

이후 그냥 npm install -f로 하자!! 는 팀원에게 package-lock.json 기능을 다시 설명함과 동시에 이 녀석을 꼭 살려두어야 한다고 말했고, 모두가 납득하였다.. 녀석.. 구사일생했다.

프로젝트 경험

여러 프로젝트를 진행했지만, 내용이 너무 길어지고 루즈해질 것 같아 큼지막한 친구들로만 작성했다.

권한 관리 시스템

RBAC 방식을 쓰고 있다

사내에 엄청나게 많은 게임들이 존재하고 하나의 게임을 운영하는 데 있어 정말 많은 직군의 인원이 투입되고 있다.

그리고 그 직군에도 많은 직책이 존재하고, 각 직책별 또는 사람 별로 갖고 있는 권한이 다르다.

이러한 특정 권한을 관리하고 부여하고 통제하는 시스템이 가칭 “권한 관리 시스템”이다.

2022년 초기엔 C#에서 Java로 컨버팅을 했고, 많은 시행착오를 거치며 사내에 흩어져있는 엄청나게 많은 권한 체계를 통합하고 있다.

기존엔 2개의 거대한 권한 체계 통합을 위해 만들어졌으나 이를 점점 확장하여 어느덧 50개에 육박하는 권한 시스템을 통합했고 점점 더 많은 서비스를 통합하고 있다.

1. 개발자, 기획자, 사용자의 이해관계 차이

백엔드뿐 아니라 프론트엔드 작업도 함께 하고 있으며 대부분의 과정을 기획자와 함께 진행하고 있다.

해당 서비스의 실제 사용자를 회의에 초대하여 회의를 진행한 경우도 있는데, 개발 중심적, 기획 중심적인 사고를 통해 사용자의 불편함을 간과하는 경우도 종종 있었다.

모두의 입장이 이해가 되기도 하고 이 부분 조율이 정말 어려운데, 완벽한 서비스(사용자 측면, 개발자 측면 등)를 만들기 위해서는 그만큼 많은 시간과 설계가 필요하다.

하지만 실무는 데드라인이 정해져 있고, 효율적인 업무를 해야 한다.

이 과정에서 서로의 입장 차이가 발생하게 되고 위와 같은 상황이 종종 벌어지는 것 같다.

예를 들어, 사용자 입장에서는 별 것 아닌 것처럼 느껴지는 특정 기능 추가를 위해, 코드 레벨에서는 엄청난 변경이 필요한 부분이 발생할 수 있다.

추후 새로운 기능이 도입되더라도 유지보수에 용이한 코드를 지금 작성하려면 주어진 데드라인 내에 하기가 힘든 경우도 있을 것이고,

이미 레거시인 시스템에 새로운 코드를 추가하고 기존 코드를 많은 부분 고쳐야 한다면…

지옥과도 같을 것이다.. 심지어 테스트 코드도 없다면..?

뭐 위 상황에서 정답이 있겠냐만은,

사용자, 기획자, 개발자 모두의 상황을 놓치지 않기 위해 입장을 고려하고, 회의에서 아주 적극적인 의견을 내세워 프로덕트에 반영하고 있다.

너무 개발 편의성 쪽으로 치우쳐 개발된다면 사용자는 그 서비스를 쓰지 않을 것이고..

너무 사용자 쪽으로 치우친다면 데드라인 내 개발을 할 수 없는 상황이 생길 것이다..

이 상황에서 적절한 타협점을 찾는 것, 그 타협점을 위해 다양한 의견 제시도 회의 참여자의 책임이라고 생각된다.

2. 테스트 코드의 부재

서비스 규모가 점점 커지면서 기능의 수정이 생기는 경우 영향도를 모두 점검해야 한다.

약간의 수정으로 사이드 이펙트가 생길지 확인하는 과정인데, API 하나의 기능을 수정하기 위해선 해당 API를 사용 중인 곳을 모조리 확인하고 변경했을 때 문제가 없는지 직접 확인해야 한다..

데드라인이 주어진 이슈를 처리하는 기간으로만 산정되다 보니 테스트 코드를 작성하기가 몹시 어려웠다..

나와 함께 협업해 본 사람들이라면 알겠지만, 이러한 문제 요소가 생기기 전에 미리 파악하고 건의하는 성격이다. 물론 이번에도 그랬었는데,

실무에선 항상 이상적인 결과가 있지 않는다는 것을 많이 알게 되었다. 실무자와 조직장과 결정권자의 이해관계 차이랄까.. 꽤 복잡한 문제가 있었다.

아무튼 안타깝기도 하고, 걱정도 되는데, 며칠 전 동료와 테스트 코드를 슬슬 작성해야 하지 않겠냐는 의견을 다시 말씀드렸고 동료도 작성해야 할 것 같다는 공감을 해주셨다.

조만간 테스트 코드를 차츰차츰 작성하지 않을까 라는 기대를 해본다.

블로그 기능 구현

티스토리 블로그는 아니고, 사내에서 어떤 플랫폼 페이지를 만들었는데, 그 페이지에 기술 블로그 탭이 존재한다.

특정 담당자가 정해진 상황은 아니었는데 마침 이때 Java로 블로그를 설계 및 구현하는 스터디를 리드할 때라 자진해서 담당하게 되었다.

결과적으론 성공적이었다. 아직까지도 특별한 이슈 없이 잘 작동하고 있다.

1. 설계

화면 기획만 나와있던 상황이라 DB 설계, 기능 설계 등 모든 것을 직접 해야 했다.

대표적인 기능은 좋아요, 댓글, 댓글의 댓글(답글), 글 쓰기 정도였다.

난 이미 이 부분에 대해서는 스터디를 통해 많은 고민을 해봤던 부분이라 머릿속에 대강 그려졌었다.

팀원과 초기 논의 과정에서 다양한 의견이 제시되었으나 결과적으로 내가 제시한 DB 설계가 채택되었고 이대로 구축되었다.

2. 구현

위에서 언급한 권한 관리 시스템은 JPA Entity 매핑 없이 진행했었고, (당시에 이 부분을 굉장히 아쉽게 생각했었다)

이 기술 블로그에서는 JPA Entity 매핑까지 고려해 설계할 수 있었다.

당연히 개발 난이도는 아주 약간 올라가긴 했지만 하고 싶던 부분이어서 평소보다 한 3배 정도 즐겁게 구현했던 것 같다.

3. 프로젝트 인계

이후에 이 프로젝트는 타 부서에서 관리하도록 넘어간다는 얘길 들었다.

더 이상 코드에 대한 유지보수도 하지 않으며, 타 부서에서 관리하는 것으로 알고 있다.

모든 부분을 내가 구현하진 않았지만 내 자식을 떠나보내는 것 같아 한편으론 마음이 적적했다..

오픈소스 컨트리뷰터

쓸까 말까 정말 많이 고민했다. 사실 별 것 아닌 번역 오타 수정 정도였기 때문이다.

그럼에도 불구하고 이걸 쓰는 이유는, 오픈소스 주인장이 갑자기 해당 프로젝트는 다른 곳에서 인수되었다며 PR, 이슈 접수 응대를 멈췄기 때문...

기여 당시 6,000 Star 정도였던 것 같은데 어느덧 10k를 넘어가는 아주 핫한 프로젝트다.

아무튼 번역 기여 이후에 ChatGPT의 Stop generating 기능을 AbortController로 구현했는데, PR을 올리지도 못했다..

적어도 SNS에 공유해 주거나 README에 확실하게 표시를 해두면 좋을 텐데,, 아직까지도 fork 수가 늘어나도 이슈 접수, PR 접수가 되고 있다.

README에 한 줄로 표기되어 있으나, 아직까지 PR과 이슈가 접수된다는 건 잘 보이지 않는다는 뜻..

이 이슈에서는 나와 비슷한 의견을 제시한 유저도 있었다.

뭐, 언어가 typescript이고 frontend 영역에 가깝지만 어쨌든 흥미를 갖고 의미 있는 기여를 하고 싶었는데 냅다 문을 닫아버려서 상당히 당황스러웠다..

셀프 피드백과 목표

회사

피드백

매사에 정말 적극적으로 참여했다고 생각하고, 인정받기도 했다.

다만, 오버스펙으로 설계를 하는 경우가 간혹 있었다.

이 원인은.. 개인 공부를 통해 대용량 트래픽이 터지는 상황의 설계를 학습하다 보니 현실적으로 어느 정도 선에서 이게 오버엔지니어링인지 아닌지 판단하는 능력이 없었기 때문이다..

그래서 처음엔 “A 상황도 고려해야 하지 않을까요?”, “B 상황도 고려해야 하지 않을까요?”처럼 트래픽이 터져 나오는 상황을 고려해 많은 의견을 제시하기도 했다.

물론 맞는 말이겠지만, 현실적으로 그런 트래픽 상황은 당장 생기지 않는다는 점에서 이는 오버엔지니어링이 되어 버렸다.

이젠 어느 정도까지 설계를 하고 이렇게 설계한 이유에 대해 결정권자를 어떻게 설득해야 하는지 어느 정도 감이 잡힌 상태라 같은 실수는 반복하지 않겠지만,

이와 별개로 현재 도메인에 대한 아쉬움이 남기도 했다.

이 아쉬움이, 훗날 이직을 하는데 가장 큰 이유가 되지 않을까란 생각이 들었다.

목표

1. 테스트 코드 작성

많은 부분 논의가 필요하겠지만, 테스트 코드를 반드시 작성해야 한다고 생각한다.

이유는 이미 위에 충분하게 적어 놔서 생략하고, 새로운 기능에 대한 테스트코드는 바로바로 작성하고

기존에 작성되지 않은 기능에 대한 테스트는 차츰 작성해 나가고 싶다.

2. 코드 리팩토링

정말 곪은 부분이 많다고 생각한다.

앞으로도 꾸준하게 기능 수정과 추가에 대한 이슈가 접수될 텐데, 곪은 부분을 계속해서 자극하다 보면 언젠가 터지기 마련이다.

해당 코드를 구현한 담당자가 아니더라도, 해당 도메인에 대한 큰 지식이 없더라도 새로운 사람이 와서 이 코드를 봤을 때 수정하기 용이하도록 코드를 리팩토링 하는 것이 내 작은 목표이다.

3. 성과 기여

매 년 성과평가를 할 텐데, 내가 목표한 등급의 허들이 생각보다 높다는 것을 알게 되었다.

열심히 안 한 것은 아니지만, 업무라는 것을 어떤 관점에서 바라보냐에 따라 다른 것 같다.

단순히 하나의 프로젝트 관점에서는 적극적으로 열심히 하는 개발자였던 것 같고, 좀 더 넓게 봐서 팀 성과, 좀 더 크겐 실 성과에 어떻게 기여를 할 수 있는지 고민을 하려면,

내가 속한 조직의 공동 목표를 알아야 하고, 단순히 조직장이나 결정권자가 제시하는 의견을 개발자의 시야로 바라볼 것이 아니라 전체 도메인과 프로세스를 이해한 상태에서 바라보고 의견을 제시하여 구체화하고 개진해야 한다는 것을 알게 되었다.

그리고 연 단위 성과 평가는 주니어 시니어 할 것 없이 모두 상대평가로 이뤄진다는 것도 처음 알았다..

이 얘길 듣고 엄청난 벽을 느꼈는데, 불가능하단 생각은 들지 않아서 꾸준히 자기 객관화와 발전을 거듭하면 빠른 시일 내 달성할 수 있겠다는 생각이 들었다.

결론은, 이루지 못했던 목표를 다시 도전하는 것이다.

대외활동

피드백

이제 넥스터즈 22기 종료까지 단 1주일이 남았다. 물론 이후에도 운영진 인수인계를 위해 한 달 반 가량 더 일해야겠지만,

운영 측면에서 참 많이 배웠고 다양한 회사의 개발자를 만날 수 있어서 너무도 좋았고, 내가 우물 안 개구리라는 점을 깨닫게 해 줘서 더욱 좋았다.

매 번, 내가 머물러 있는 우물 밖을 효과적으로 보여주는 것은 회사보단 대외활동인 것 같다.

매 대외활동마다 하나의 우물을 벗어나는 것 같아 좋지만, 한 편으론 머무른 우물을 벗어나며 새로운 벽을 마주하는 느낌은 늘 위기와 압박으로 느껴진다.

물론 이 느낌이 스스로를 더 바쁘게 움직이게 해주는 일종의 채찍 역할을 해줘서 멈출 수 없는 것 같다.

목표

1. 사이드 프로젝트

아직 자세한 시장조사는 하지 않았지만 나름 시장성도 있는 것 같고, 재미난 도메인이라 개발을 통한 즐거움도 있을 것 같다.

연합동아리를 통해 개발을 할지, 아니면 어디에도 속하지 않고 팀을 꾸려 진행할지는 모르지만,

2023년도엔 이 프로젝트를 시작해보고 싶다.

2. 스터디

넥스터즈가 끝나면서 드디어 개인 공부 시간이 여유롭게 생긴다.

그동안 운영 준비, 미팅 등으로 일정이 촉박했는데 맘 편하게 진행할 수 있어서 너무 좋은 것 같다.

하지 못했던 책을 정독하고, 보고 싶었던 강의를 주말과 퇴근 후에 얼른 보고 싶다.

3. 회장&대표 안 하기

넥스터즈 회장은 어느덧 내 생에 여덟 번째 리더 자리였다.

운영이던 업무던 불문하고 개선 사항이 보이면 개선하고 싶고, 불편함을 지나치지 못하는 성격이라 늘 이런 자리를 도맡아 해왔다.

물론 이런 자리를 통해 얻는 것도 굉장히 많지만, 그만큼 포기해야 하는 것들도 많다.

이젠 이런 자리에 시간을 쏟기보단 내 개인 능력 향상을 위해 시간을 쏟고 싶다.

기타

목표

1. 블로그 포스팅 2주에 하나씩 하기

2. 티스토리 블로그 UI 커스터마이징

오픈소스 프레임워크를 pull 받아 현재 진행 중인데 새로운 영역이다 보니 정말 새롭기도 하고,

vue2와 또 다른 느낌의 개발이라 아직은 난항을 겪고 있다.

구체적인 디자인이 있는 것은 아니지만 기존에 칙칙한 느낌의 UI에서 좀 꾸민 느낌의 UI로 바꾸고자 한다.

물론 써 내려가는 게시글의 주제나 내용의 퀄리티도 중요하지만, 보기 좋은 떡이 되고 싶기도 해서이다.

마무리

주저리주저리 많은 글을 써 내려갔는데, 사실 실명 블로그이기도 하고 많은 지인 분들, 회사 동료들이 보고 계셔서 깊은 얘기는 적지 못한 부분도 있었다.

뭔가 공백 없이 대외적으로도 꾸준한 활동을 했지만, 그 결과를 보면 항상 만족스럽진 못했다.

이건 스스로에게 기대하는 허들이 높기도 해서 그렇다.

이 덕분에 계속 채찍질하며 달릴 수 있는 원동력이 되는 것 같기도 한데, 이번 넥스터즈 운영으로 개인 시간이 줄어들며 번아웃이 오기도 한 것처럼,

스스로 어떤 목표를 내려놓는 것도 중요하다는 것을 깨닫기도 했다.

아무튼,

긴 글 읽어주셔서 진심으로 감사드리며 2023년 회고글을 쓸 때쯤엔 기술적으로도 인간적으로도 커리어로도 많은 성장을 한 제가 되어 있으면 좋겠습니다.

감사합니다.

저작자표시 비영리 변경금지

'후기 > 경험' 카테고리의 다른 글

2023 상반기를 되돌아보자 (0)	2023.07.16
글또 8기 참여 (2)	2023.02.12
[스터디 회고] 게시판 구현하기 (0)	2022.06.01
[후기] 신입이 클린 코드 읽고 실무에 적용해보기 (2)	2022.03.12
프로그래머스 테크 피드 노젓기 (0)	2021.09.24

서론

소개