<div id="readability-page-1" class="page"><div><p>잊고 있었는데, 생각해보니 글또 시작 전에 <a href="https://sungjk.github.io/2020/11/15/get-comfortable-being-uncomfortable.html">Get comfortable with being uncomfortable</a>라는 글을 주제로 다짐글을 썼었네요. 글또 활동하면서 기대하는 점과 어떤 글을 쓸지에 대해 기록했었어요. 그때 작성했던 다짐글에 대한 회고를 시작으로 6개월 동안 썼던 글도 되돌아 보고, 글또 활동하면서 좋았던 점과 아쉬웠던 점에 대해서 이야기해볼까 해요.</p>

<p><img src="https://sungjk.github.io/images/profile/geultto.png" alt="geultto" title="geultto"></p>

<h3 id="다짐글-되돌아보기">다짐글 되돌아보기</h3>
<p>첫 번째. 회사, 사이드 프로젝트 또는 개발 공부를 하면서 경험했던 기술적인 이야기들이나 이슈를 적어보려 했었어요. Spring Webflux, 데이터 암호화, Kafka 그리고 2020년 회고에 적었던 사이드 프로젝트 이야기를 적었던게 생각나요. 경험했던 것들을 되도록 많이 기록해두고 싶었는데, 쉽지 않았던거 같아요. 예를 들어, 회사에서 Kafka를 많이 사용하다 보니 개인적으로 공부한 기록은 남겨두었는데, 사용하면서 겪었던 문제나 경험담에 대해 이야기를 하지 못한게 아쉽다는 생각이 들어요. 그래서 다음에는 관심과 필요에 의해 어떤 기술을 주제로 글을 쓸 때, 겪었던 문제나 힘듦 또는 좋았던 점들을 함께 써야겠어요. 다음에 똑같은 문제를 반복하지 않게 하는 회고와 포스트모템(Postmortem)이 될 수도 있고, 글을 읽는 누군가에게 조금이나마 더 도움이 되지 않을까 싶어서요.</p>

<p>두 번째. 개발자로서 요즘은 어떤 일을 하고 있고, 어떤 기술에 관심이 있는지 등 근황에 대한 이야기를 적어보려 했었어요. 이건 회고와는 다르게, 좀 더 가볍게 Chit Chat 정도로 생각했었어요. 아쉽게도? 이걸 주제로 한 글은 하나도 못 썼어요. 대개 이런 글은 블로그보다 트위터에 더 어울릴 것 같다는 생각이 들어요. 블로그 방문자의 대부분이 오가닉 서치(Organic Search)를 통해 유입되기도 하고, 블로그 성격과도 어울리지 않아서요. 그래서 회고와 스터디한 내용을 작성하는 것만으로도 충분할 것 같다는 생각이에요.</p>

<p>세 번째. 책을 읽고 나서 짧게라도 소감을 담은 독후감을 적어보려 했었어요. 기억의 농도는 날이 갈수록 옅어지잖아요. 행복한 순간뿐만 아니라 일상에서의 기록을 사진으로 남겨두는 이유는 이 옅어지는 기억의 농도를 그 순간이나마 짙게 만들기 위함이라고 생각해요. 어떤 순간에 들었던 생각과 느낌도 마찬가지라고 생각해요. 시간이 한참 흐른 뒤에 아무런 기록 없이 어린왕자에 대해 생각해보면 보아뱀, 여우, 장미꽃 등 흐릿한 이미지로만 가득했어요. 어린왕자가 여우를 만나면서 느꼈던 - 물리적인 것이 아닌 정신적인 측면에서 진정한 관계가 만들어질 수 있음을 깨닫는 - 느낌 같은건 없이 말이죠. 그래서 글또 활동 중에 읽었던 책들의 느낌을 기록하려 했었는데, 6개월 동안 작성한 독후감이 하나 밖에 없다는게 조금 아쉬웠어요. 최근에 읽었던 언카피어블 내용이 너무 좋아서 독후감을 쓰려고 했는데, 아직 독후감을 쓰는건 해야 할 숙제처럼 느껴져서 의도적으로 노력을 해야 되더라고요. 완성도 높은 독후감보다는 짧게라도 기록해보는 연습을 시작해봐야겠어요.</p>

<hr>

<h3 id="6개월-동안-썼던-글">6개월 동안 썼던 글</h3>
<p><img src="https://sungjk.github.io/images/2021/05/02/finish.png" alt="끝" title="끝"></p>

<p>글또는 시작할 때 10만원의 예치금을 걷고 나서, 2주에 한 번씩 글을 써야 되는데 한 번 빼먹을 때마다 1만원씩 차감되더라구요. 그리고 바빠서 글을 못 쓰는 경우를 대비해서 2번의 패스를 사용할 수 있었어요. 이왕 참여한거 한 번도 빠지지 말고 써야겠다고 다짐을 했는데, 어렸을 때부터 근성 있게 꾸준히 하는걸 잘해서 목표를 달성할 수 있었어요. 이 글이 5기 활동하면서 마지막으로 쓰는 글이 될 텐데, 꾸준히 썼다는 점에 대해서는 스스로 뿌듯하더라구요. 이뿐만 아니라, 그동안 썼던 글이 검색 엔진의 상위에 노출되거나 구독 중인 기술 블로그에 소개되어서 블로그 지표가 전체적으로 좋아졌어요.</p>

<ol>
  <li>2020.11.08. <a href="https://sungjk.github.io/2020/11/08/practical-modern-java.html">Practical 모던 자바</a></li>
  <li>2020.11.15. <a href="https://sungjk.github.io/2020/11/15/get-comfortable-being-uncomfortable.html">Get comfortable with being uncomfortable</a></li>
  <li>2020.11.28. <a href="https://sungjk.github.io/2020/11/28/data-encryption-entity.html">암호화 알고리즘과 Spring Boot Application에서 Entity 암호화</a></li>
  <li>2020.12.13. <a href="https://sungjk.github.io/2020/12/13/alfred-tips.html">귀차니즘을 해결해주는 Alfred</a></li>
  <li>2020.12.27. <a href="https://sungjk.github.io/2020/12/27/jeremy.html">제레미의 2020년 회고</a></li>
  <li>2021.01.10. <a href="https://sungjk.github.io/2021/01/10/kafka-consumer.html">Kafka Consumer 알아보기</a></li>
  <li>2021.01.23. <a href="https://sungjk.github.io/2021/01/23/kafka-producer.html">Kafka Producer 알아보기</a></li>
  <li>2021.01.29. <a href="https://sungjk.github.io/2021/01/29/platform-revolution.html">플랫폼 레볼루션</a></li>
  <li>2021.02.07. <a href="https://sungjk.github.io/2021/02/07/communicaton-and-prtemplate.html">커뮤니케이션 방식과 PR 템플릿 개선해보기</a></li>
  <li>2021.02.20. <a href="https://sungjk.github.io/2021/02/20/variance.html">가변성(Variance) 알아보기 - 공변, 무공변, 반공변</a></li>
  <li>2021.03.02. <a href="https://sungjk.github.io/2021/03/02/blame-vs-criticism.html">비난과 비판의 차이</a></li>
  <li>2021.03.07. <a href="https://sungjk.github.io/2021/03/07/jeremy-writing.html">더 나은 글쓰기를 위한 여정</a></li>
  <li>2021.03.20. <a href="https://sungjk.github.io/2021/03/20/refactoring-01.html">리팩터링 1 - Refactoring 1</a></li>
  <li>2021.03.31. <a href="https://sungjk.github.io/2021/03/31/refactoring-02.html">리팩터링 2 - Refactoring 2</a></li>
  <li>2021.04.17. <a href="https://sungjk.github.io/2021/04/17/refactoring-03.html">리팩터링 3 - Refactoring 3</a></li>
  <li>2021.04.17. <a href="https://sungjk.github.io/2021/04/17/refactoring-04.html">리팩터링 4 - Refactoring 4</a></li>
  <li>2021.04.17. <a href="https://sungjk.github.io/2021/04/17/refactoring-05.html">리팩터링 5 - Refactoring 5</a></li>
  <li>2021.05.02. <a href="https://sungjk.github.io/2021/05/02/geultto-5th.html">글또 5기를 마치며</a></li>
</ol>

<p><img src="https://sungjk.github.io/images/2021/05/02/kafka-consumer.png" alt="Kafka Consumer" title="Kafka Consumer"></p>

<p><img src="https://sungjk.github.io/images/2021/05/02/platform-revolution.png" alt="platform-revolution" title="platform-revolution"></p>

<p><img src="https://sungjk.github.io/images/2021/05/02/spring-boot-encryption.png" alt="spring-boot-encryption" title="spring-boot-encryption"></p>

<p><img src="https://sungjk.github.io/images/2021/05/02/alfred.png" alt="alfred" title="alfred"></p>

<hr>

<h3 id="글또-5기-되돌아보기">글또 5기 되돌아보기</h3>
<p>글또 활동하면서 유일하게 작성했던 독후감인 <a href="https://sungjk.github.io/2021/01/29/platform-revolution.html">플랫폼 레볼루션</a>에도 잠깐 비슷한 개념이 나오는데, 요즘 관심 있는 개념 중 하나가 아마존의 플라이 휠(Fly Wheel)이에요. 플라이 휠은 동력 없이 관성만으로 회전 운동을 하는 자동차 부품이에요. 처음에는 플라이 휠을 돌리기 위해 엄청난 추진력이 필요하지만, 한 번 가속도가 붙으면 알아서 돌아가요. 제프 베조스(Jeff Bezos)는 아마존을 어마어마한 회사로 성장시키기 위해 기업 경영에 이런 플라이 휠 개념을 적용했어요.</p>

<ol>
  <li>가격을 낮춰 고객을 모은다.</li>
  <li>고객이 늘면 물건을 팔려는 판매자들이 많아진다.</li>
  <li>규모가 커지면 고정 비용이 낮아지고 효율성이 높아진다.</li>
  <li>효율성이 높아지면 가격을 더 낮출 수있다.</li>
</ol>

<p><img src="https://sungjk.github.io/images/2021/05/02/amazon-flywheel.jpg" alt="amazon-flywheel" title="amazon-flywheel"></p>

<p>얘기만 들어보면 아주 이상적이고 당연한 이야기처럼 들리지만, 처음 플라이 휠을 돌리기 위해 엄청난 추진력이 필요한 것처럼 시작이 가장 어려운 법이에요. 이건 경영 뿐만 아니라 어떤 습관을 기르는데에도 똑같이 적용 된다고 생각해요. 차이가 있다면 시작할 때 가속을 얼마나 내느냐인데요. 저는 어떤 목표한 바가 있으면 작은 것부터 천천히 시작해보는 편이에요. 처음부터 엄청 가속을 내다보면 오래 가지 못하고 금방 지칠 수 있잖아요. 그래서 작은 것부터 성취해 보면서 나만의 루틴을 만들고, 이런 루틴이 모여서 플라이 휠처럼 Positive Cycle을 만들 수 있다고 생각해요. 이런 면에서 글또는 글쓰는 습관을 기르는데에 좋은 커뮤니티에요. 6개월은 어떤 습관을 만들기 위해 절대 짧은 시간이 아니잖아요. 글을 쓰기 위해 많은 에너지가 필요한건 사실이지만, 꾸준히 글을 쓰다 보면 생각을 정리하는 방법을 배울 수 있고, 잘 정돈된 글로 누군가에게 제안하거나 설득하는 능력도 기를 수 있어요. 내가 작성한 글이 누군가에게 공감을 받거나 누군가의 생각을 설득하는 경험을 한 번 해보면, 글을 더 잘 쓰고 싶다는 생각이 커지고 이 과정을 천천히나마 반복하게 되더라구요.</p>

<p><img src="https://sungjk.github.io/images/2021/05/02/feedback.png" alt="feedback" title="feedback"></p>

<p>저는 피드백을 받고 싶어서 글또에 참여했는데, 좋은 피드백을 주고 받기는 참 쉽지 않은거 같아요. 좋은 피드백에 대한 기준이 서로 다를 뿐만 아니라, 서로 관심 분야가 다르기도 하고 기술적인 글은 이해하기가 어려운 경우도 있기 때문이에요. 그래서 피드백을 어떻게 주면 좋을지 서로 의견을 나누어 보았는데요, 글을 제출할 때 각자 어떤 피드백을 받고 싶은지 적어주기로 했어요. 이건 코드 리뷰를 할 때에 비슷하게 느꼈던 점인데, 어떤 부분을 중점적으로 보면 좋을지 알려주면 리뷰어 입장에서 좀 더 구체적인 피드백을 줄 수 있더라구요. 그리고 항상 느끼는건데 피드백 문화에 정답은 없는거 같아요. 피드백을 자주 받고 싶은 사람도 있고, 아예 받기 싫은 사람도 있어서 모두의 의견을 존중하고 조율해야 할 필요가 있거든요. 끝으로, 피드백을 꼼꼼히 남기지 못했던 점은 반성하고 그동안 꼼꼼하게 피드백을 남겨주셨던 5기 구성원분들께 감사하다는 인사를 남기고 싶어요.</p>
</div></div>

coyled.com

Jeremy Kim

잊고 있었는데, 생각해보니 글또 시작 전에 Get comfortable with being uncomfortable라는 글을 주제로 다짐글을 썼었네요. 글또 활동하면서 기대하는 점과 어떤 글을 쓸지에 대해 기록했었어요. 그때 작성했던 다짐글에 대한 회고를 시작으로 6개월 동안 썼던 글도 되돌아 보고, 글또 활동하면서 좋았던 점과 아쉬웠던 점에 대해서 이야기해볼까 해요.
다짐글 되돌아보기
첫 번째. 회사, 사이드 프로젝트 또는 개발 공부를 하면서 경험했던 기술적인 이야기들이나 이슈를 적어보려 했었어요. Spring Webflux, 데이터 암호화, Kafka 그리고 2020년 회고에 적었던 사이드 프로젝트 이야기를 적었던게 생각나요. 경험했던 것들을 되도록 많이 기록해두고 싶었는데, 쉽지 않았던거 같아요. 예를 들어, 회사에서 Kafka를 많이 사용하다 보니 개인적으로 공부한 기록은 남겨두었는데, 사용하면서 겪었던 문제나 경험담에 대해 이야기를 하지 못한게 아쉽다는 생각이 들어요. 그래서 다음에는 관심과 필요에 의해 어떤 기술을 주제로 글을 쓸 때, 겪었던 문제나 힘듦 또는 좋았던 점들을 함께 써야겠어요. 다음에 똑같은 문제를 반복하지 않게 하는 회고와 포스트모템(Postmortem)이 될 수도 있고, 글을 읽는 누군가에게 조금이나마 더 도움이 되지 않을까 싶어서요.
두 번째. 개발자로서 요즘은 어떤 일을 하고 있고, 어떤 기술에 관심이 있는지 등 근황에 대한 이야기를 적어보려 했었어요. 이건 회고와는 다르게, 좀 더 가볍게 Chit Chat 정도로 생각했었어요. 아쉽게도? 이걸 주제로 한 글은 하나도 못 썼어요. 대개 이런 글은 블로그보다 트위터에 더 어울릴 것 같다는 생각이 들어요. 블로그 방문자의 대부분이 오가닉 서치(Organic Search)를 통해 유입되기도 하고, 블로그 성격과도 어울리지 않아서요. 그래서 회고와 스터디한 내용을 작성하는 것만으로도 충분할 것 같다는 생각이에요.
세 번째. 책을 읽고 나서 짧게라도 소감을 담은 독후감을 적어보려 했었어요. 기억의 농도는 날이 갈수록 옅어지잖아요. 행복한 순간뿐만 아니라 일상에서의 기록을 사진으로 남겨두는 이유는 이 옅어지는 기억의 농도를 그 순간이나마 짙게 만들기 위함이라고 생각해요. 어떤 순간에 들었던 생각과 느낌도 마찬가지라고 생각해요. 시간이 한참 흐른 뒤에 아무런 기록 없이 어린왕자에 대해 생각해보면 보아뱀, 여우, 장미꽃 등 흐릿한 이미지로만 가득했어요. 어린왕자가 여우를 만나면서 느꼈던 - 물리적인 것이 아닌 정신적인 측면에서 진정한 관계가 만들어질 수 있음을 깨닫는 - 느낌 같은건 없이 말이죠. 그래서 글또 활동 중에 읽었던 책들의 느낌을 기록하려 했었는데, 6개월 동안 작성한 독후감이 하나 밖에 없다는게 조금 아쉬웠어요. 최근에 읽었던 언카피어블 내용이 너무 좋아서 독후감을 쓰려고 했는데, 아직 독후감을 쓰는건 해야 할 숙제처럼 느껴져서 의도적으로 노력을 해야 되더라고요. 완성도 높은 독후감보다는 짧게라도 기록해보는 연습을 시작해봐야겠어요.
6개월 동안 썼던 글
글또는 시작할 때 10만원의 예치금을 걷고 나서, 2주에 한 번씩 글을 써야 되는데 한 번 빼먹을 때마다 1만원씩 차감되더라구요. 그리고 바빠서 글을 못 쓰는 경우를 대비해서 2번의 패스를 사용할 수 있었어요. 이왕 참여한거 한 번도 빠지지 말고 써야겠다고 다짐을 했는데, 어렸을 때부터 근성 있게 꾸준히 하는걸 잘해서 목표를 달성할 수 있었어요. 이 글이 5기 활동하면서 마지막으로 쓰는 글이 될 텐데, 꾸준히 썼다는 점에 대해서는 스스로 뿌듯하더라구요. 이뿐만 아니라, 그동안 썼던 글이 검색 엔진의 상위에 노출되거나 구독 중인 기술 블로그에 소개되어서 블로그 지표가 전체적으로 좋아졌어요.
2020.11.08. Practical 모던 자바
2020.11.15. Get comfortable with being uncomfortable
2020.11.28. 암호화 알고리즘과 Spring Boot Application에서 Entity 암호화
2020.12.13. 귀차니즘을 해결해주는 Alfred
2020.12.27. 제레미의 2020년 회고
2021.01.10. Kafka Consumer 알아보기
2021.01.23. Kafka Producer 알아보기
2021.01.29. 플랫폼 레볼루션
2021.02.07. 커뮤니케이션 방식과 PR 템플릿 개선해보기
2021.02.20. 가변성(Variance) 알아보기 - 공변, 무공변, 반공변
2021.03.02. 비난과 비판의 차이
2021.03.07. 더 나은 글쓰기를 위한 여정
2021.03.20. 리팩터링 1 - Refactoring 1
2021.03.31. 리팩터링 2 - Refactoring 2
2021.04.17. 리팩터링 3 - Refactoring 3
2021.04.17. 리팩터링 4 - Refactoring 4
2021.04.17. 리팩터링 5 - Refactoring 5
2021.05.02. 글또 5기를 마치며
글또 5기 되돌아보기
글또 활동하면서 유일하게 작성했던 독후감인 플랫폼 레볼루션에도 잠깐 비슷한 개념이 나오는데, 요즘 관심 있는 개념 중 하나가 아마존의 플라이 휠(Fly Wheel)이에요. 플라이 휠은 동력 없이 관성만으로 회전 운동을 하는 자동차 부품이에요. 처음에는 플라이 휠을 돌리기 위해 엄청난 추진력이 필요하지만, 한 번 가속도가 붙으면 알아서 돌아가요. 제프 베조스(Jeff Bezos)는 아마존을 어마어마한 회사로 성장시키기 위해 기업 경영에 이런 플라이 휠 개념을 적용했어요.
가격을 낮춰 고객을 모은다.
고객이 늘면 물건을 팔려는 판매자들이 많아진다.
규모가 커지면 고정 비용이 낮아지고 효율성이 높아진다.
효율성이 높아지면 가격을 더 낮출 수있다.
얘기만 들어보면 아주 이상적이고 당연한 이야기처럼 들리지만, 처음 플라이 휠을 돌리기 위해 엄청난 추진력이 필요한 것처럼 시작이 가장 어려운 법이에요. 이건 경영 뿐만 아니라 어떤 습관을 기르는데에도 똑같이 적용 된다고 생각해요. 차이가 있다면 시작할 때 가속을 얼마나 내느냐인데요. 저는 어떤 목표한 바가 있으면 작은 것부터 천천히 시작해보는 편이에요. 처음부터 엄청 가속을 내다보면 오래 가지 못하고 금방 지칠 수 있잖아요. 그래서 작은 것부터 성취해 보면서 나만의 루틴을 만들고, 이런 루틴이 모여서 플라이 휠처럼 Positive Cycle을 만들 수 있다고 생각해요. 이런 면에서 글또는 글쓰는 습관을 기르는데에 좋은 커뮤니티에요. 6개월은 어떤 습관을 만들기 위해 절대 짧은 시간이 아니잖아요. 글을 쓰기 위해 많은 에너지가 필요한건 사실이지만, 꾸준히 글을 쓰다 보면 생각을 정리하는 방법을 배울 수 있고, 잘 정돈된 글로 누군가에게 제안하거나 설득하는 능력도 기를 수 있어요. 내가 작성한 글이 누군가에게 공감을 받거나 누군가의 생각을 설득하는 경험을 한 번 해보면, 글을 더 잘 쓰고 싶다는 생각이 커지고 이 과정을 천천히나마 반복하게 되더라구요.
저는 피드백을 받고 싶어서 글또에 참여했는데, 좋은 피드백을 주고 받기는 참 쉽지 않은거 같아요. 좋은 피드백에 대한 기준이 서로 다를 뿐만 아니라, 서로 관심 분야가 다르기도 하고 기술적인 글은 이해하기가 어려운 경우도 있기 때문이에요. 그래서 피드백을 어떻게 주면 좋을지 서로 의견을 나누어 보았는데요, 글을 제출할 때 각자 어떤 피드백을 받고 싶은지 적어주기로 했어요. 이건 코드 리뷰를 할 때에 비슷하게 느꼈던 점인데, 어떤 부분을 중점적으로 보면 좋을지 알려주면 리뷰어 입장에서 좀 더 구체적인 피드백을 줄 수 있더라구요. 그리고 항상 느끼는건데 피드백 문화에 정답은 없는거 같아요. 피드백을 자주 받고 싶은 사람도 있고, 아예 받기 싫은 사람도 있어서 모두의 의견을 존중하고 조율해야 할 필요가 있거든요. 끝으로, 피드백을 꼼꼼히 남기지 못했던 점은 반성하고 그동안 꼼꼼하게 피드백을 남겨주셨던 5기 구성원분들께 감사하다는 인사를 남기고 싶어요.

글또 5기를 마치며

댓글