글또 8기에 대한 회고

 

 

 

 

회고에 대해 작성하는 것은 어색하다. 오늘까지만 하더라도 sonarqube , 동시성 등 어떤 주제로 글을 써야하지 고민을 하다, 오늘이 마지막 글또 제출임을 알게되어 회고록을 뒤늦게 작성하게 되었다. 2023.02.08 일에 글또 8기 다짐글 (https://catchdream.tistory.com/247) 을 쓴지가 벌써 6개월이 지나다니.. 시간이 정말 빠르게 흐르는구나를 느끼기도 하면서 나 자신에 대해 반성하게 되는 순간들도 많았다.

글또를 시작하기 전, 나는 어떤 마음이었을까?

 

 

 

8기 글또의 시작과 작성한 글들

나의 글또 다짐글은 정말 그게 최선이었을까? 로 시작한다. 간단한 API 기능 구현 하나라도, 관성적으로 개발을 진행하지는 않았는지, 내가 선택한 기술이 정말 최선의 선택이었는지 그에 대한 side-effect 는 고려하였는지 등 이때까지의 마음가짐을 되돌아보면서 다짐했다. 그리고 이런 구체적인 노력으로 기술에 대한 글을 작성하면서 업무와 공부가 어우러지는 선순환 구조를 기대하였다.

 

다른 하나는 다른 사람들과 공유할 수 있는 블로그 글들을 작성해보고 싶었다. 어떤 업무에 대해 근거와 논리만 있는 업무일지의 성격들보다는 하나의 주제를 선정하고 다른 사람에게도 도움이 될 수 있는 컨텐츠 성격의 글들을 작성해보고 싶었다. 

그리고 나는 8기의 글또를 진행하면서 아래의 글들을 작성하였다.

 

글또 8기 다짐글
분산트랜스코딩으로 알아보는 Boss-Worker 아키텍처
대규모 채팅 아키텍처는 C10K 문제를 어떻게 해결할까?
FFmpeg 으로 h.264, h.265 Encoding 성능 테스트
영상의 Quality 와 av1 Encoding 성능테스트
Golang 2차원 배열 문제를 통한 array, slice 의 개념정리
AV1, H.265 트랜스코딩 테스트
애플리케이션 로그에 장애 흔적이 없다면?(+VI 활용편)
Golang 에서 Map 과 같은 참조타입을 다룰 때 주의해야할 점

 

 

KPT (Keep, Problem, Try)

---

글또에서 추천하는 회고의 방법(https://zzsza.github.io/diary/2023/06/05/how-to-retrospect/) 중 KPT 방법을 통해 그간 잘해왔던 점과 문제점, 그리고 앞으로 시도해볼 점을 생각해보았다.

 

잘했던 점??

하나의 글을 정성스레 써봤던 경험

블로그 글들은 원래 꾸준히 써보긴 했었지만 이렇게 장기적으로 고민해본적은 없었던 것 같다.

오히려 2주에 하나의 글이라는 주기가 생기면서, 소소한 주제들을 그때그때 빠르게 적기보다는 2주동안 어떤 글을 써야하지? 라는 고민과 글의 퀄리티를 고민하면서 써보았다.

그렇기 위해 글감을 모아보고, 내가 어떤 글을 써보고 싶은지 생각해보고, 업무를 진행하다 다뤄보고 싶은 주제를 만나면 괜시리 반가운 마음도 들었었다. 내가 알게된 지식을 기록하기보다는, 글을 써보려고 노력했다는 점? 그 점은 충분히 도움이 많이 되었다.

 

테스트 결과를 기준으로 한 글을 써보았던 경험

이전에는 개발에 대한 생각과 그에 대한 근거를 Reference 나 다른 곳에서 내용을 찾는 과정만 진행했었다.

그렇기에 테스트와 샘플코드도 다른 사람의 자료를 바탕으로 이해하고, 실제 업무에 적용하고 있었다.

하지만 이번 글쓰기를 통해, 실제 글을 쓰기 위한 테스트를 진행해보기도 하고, 간단한 샘플코드도 작성해보는 경험을 했다.

책 또는 블로그에 쓰여진 내용이 정말로 맞는지 내가 실제로 코드를 짜보고 성능을 테스트해보는 경험을 하고, 이를 글로 정리한 부분은 나에게 커다란 도움이 되었다.

어떤 생각에 대한 검증이 필요할 때 그에 대한 레퍼런스를 찾는 노력도 중요하지만 직접 테스트를 해보고, 그에 대한 바탕으로 논리를 펼쳐나가는 것도 중요한 능력이라 생각된다.

 

 

어려움을 느껴서 개선하고 싶은 것??

레퍼런스 참고 능력

아직은 하나의 글을 쓰기 위해 다양한 자료들을 참고하는 능력이 부족하다고 생각한다. 물론 그만큼 시간을 들이붇고, 자료를 가려내고 글을 쓰는 연습이 필요하다고는 알지만 이를 실천하는게 부족했다. 내가 알고 싶어하는 것이 어떤 것인지, 나와 비슷한 궁금증과 고민을 바탕으로 쓴 글이 있는지, 이를 업무에 적용하려면 어떤 방법이 있는지 등 보다 다양한 채널에서 레퍼런스를 찾고 이를 나의 것으로 만드는 노력이 필요했다. 그리고 이미지, 도표 등도 직접 만들어가면서 나의 글을 만들어보는 능력들도 아쉬웠다.

 

주제 선정

아직은, 나의 블로그 글들이 나의 업무와 밀접하게 연관이 있다. 내가 업무를 진행하면서 새로 알게된 사실들이나, 문제에 직면했을 때 어떤 방식으로 접근했는가 등을 보다 보편적인 주제로 추상화하여 글을 썼다. 내가 바라는 것은 업무와 관련된 내용을 글로 옮기는 것도 너무 좋지만, 내가 관심있어하는 주제, 개발자로서 내가 잘하는 것에 대한 보다 심층있는 전문성있는 글을 써보고 싶다.

물론 아직 업무를 진행하면서 10년 뒤의 나의 모습, 10년차의 개발자로서의 나의 모습, 나는 어떤 역량을 가진 개발자일까에 대한 생각은 아직 확립이 되어있지는 않지만 나의 색깔을 녹여낼 수 있는 글들을 많이 써보고 싶다는 희망이 있다.

 

구체적으로 시도할 내용

꾸준한 글쓰기와 레퍼런스 참고

글또 9기에 다시 참여할 수 있다면 나는 다시 재참여를 하고 싶다. 2주정도의 주기를 통해 보다 퀄리티 있는 글쓰기 연습이 도움이 되고 있기 때문이다. 다만 내가 집중하고 싶은 것은 보다 깊이 알기이다. 하나의 주제에 대해 몇개 정도의 블로그 글들만 쭉 살펴보고, 한 권의 책정도만 살펴보는 정도가 아니라 깊이 탐구하고 연구해보는 습관을 길러보고 싶다. 그렇기 위해서는 내가 좋아하는 주제를 선정해야할 것이다. 나는 앞으로 어떤 개발자가 될 것인가. 어떤 것을 잘하는 개발자가 될 것인가에 대해 이번 글또 9기 전까지 탐구해보고 고민해볼 것이다.

나는 스프링을 잘하는 개발자, 나는 golang 을 잘하는 개발자 처럼 어떤 Langage 와 Tool 을 잘 활용하는 능력도 중요하지만 Language 와 Tool 을 잘쓰는 것만으로는 비즈니스 가치를 만들어낼 수는 없다. 내가 주로 어떤 도메인에 종사하고 싶은 건지, 그 도메인에서는 어떤 기술이 비즈니스 가치를 창출하는지, 다른 경쟁사들의 기술적 수준은 어떠한지 등 이러한 고민과 생각을 확립해나가고 싶다. 그리고 나에게 적합한 도메인을 찾았을 때, 그에 대한 전문성을 함양하고 싶다. 

 

 

 

개발자로서의 나는?

---

개발자로서의 나는 현재까지는 성장하고 있는 중이라 생각된다. 1년 전, 한달 전과 비교했을 때 분명 어제의 나보다는 오늘의 나가 보다 명확한 개발을 하고 있기 때문이다. 이러한 성장은 내가 앞으로 가야하는 방향과 이정표가 확실했을 때 가능하다고 생각한다. 내가 나아가야할 방향을 잃어버리면 우리는 헤메게 되고, 눈앞의 업무만 처리하는 관성적인 개발을 진행할 수 있기 때문이다. 그렇기 때문에 지금 회고하는 나 자신의 고민을 게속해서 고민하며 그에 대한 답을 내리는 노력을 할 것이다.