자유/잡담

모닥글 스터디 회고

Chipmunks 2026. 5. 18.
728x90

지난 한 달 간 블로그 글쓰기 스터디를 했습니다.

스마일게이트에서 주관하는 모닥랩 프로그램이었습니다!

 

2주마다 기술 블로그 글을 작성합니다.

초안을 작성하고 피드백을 주고 받고 기술을 정리할 수 있는 시간을 가졌습니다.

 

위 경험을 회고해 보고자 합니다.

 

시작 전 - 좋은 글이란 무엇일까?

시작 전에 의견을 모았습니다.

각자 좋은 글이란 무엇이고, 어떤 글을 쓰고 싶은가를 이야기 나눴어요.

 

 

글을 쓰는 본질은 단 한 가지 입니다.

독자에게 온전히 전달하기 위함인데요.

어떤 독자가 보았으면 좋은지, 그 독자를 위해 어떤 목적이 좋을지 정하는 게 중요했습니다.

그게 뒷받침 되어야 독자에게 맞는 좋은 글을 작성할 수 있기 때문입니다.

 

개인적으로 단순 메모 형식의 글을 지양하고자 했어요.

독자가 불분명하기 때문이에요.

독자에게 흥미를 돋게 글을 구성하고 전달하는 경험을 쌓고 싶었어요.

 

또한 어려웠던 기술 문제를 어떻게 해결했는지 정리하고자 했어요.

실무에선 책이나 이론처럼 한 가지 문제만 발생하지 않았어요.

여러가지 문제가 복합적으로 발생했는데요.

 

시간이라는 자원이 한정적이기에,

어떤 문제를 최우선으로 해결할지, 어떻게 해야 일정 안에 해결할 수 있을지

판단하는 것이 중요했었어요.

 

그 과정 속에서 무엇을 얻고, 무엇을 포기할지, 또 장기적으로 어떻게 대응할지

'기술관점의 기획'을 할 수 있는 귀중한 경험이었습니다.

 

대학생과 같은 현업 개발자에게 이 기술을 선택할 때의 배경과 선택 근거를 최대한 녹이려고 노력했습니다.

해당 코드와 정확한 수치 같은 민감 정보는 표현할 수 없었지만,

비슷한 상황을 재연하고 어떻게 해결했는지를 적었습니다.

 

2026.04.18 - [Spring/문제 해결 사례] - Spring Kafka 트랜잭션 + 비동기/재시도 = 반드시 터진다 (Fencing & Timeout 실무 장애 분석)

 

Spring Kafka 트랜잭션 + 비동기/재시도 = 반드시 터진다 (Fencing & Timeout 실무 장애 분석)

TL; DRKafka 트랜잭션은 같은 transactional.id에 단 하나의 producer만 허용한다.비동기 처리나 재시도로 producer가 하나 더 생성되는 순간, 기존 트랜잭션은 fencing으로 즉시 죽는다. 1. 장애 상황아침에 출

itchipmunk.tistory.com

2026.04.26 - [Spring/문제 해결 사례] - Spring Batch는 왜 내 MariaDB에 데드락을 뿌렸나 — SERIALIZABLE 기본값과 동시 실행의 함정

 

Spring Batch는 왜 내 MariaDB에 데드락을 뿌렸나 — SERIALIZABLE 기본값과 동시 실행의 함정

TL;DRSpring Batch의 JobRepository는 기본적으로 SERIALIZABLE 격리 수준으로 메타 테이블에 접근한다여러 Job을 동시에 실행하면 BATCH_JOB_INSTANCE 등 메타 테이블과 서비스 테이블에서 갭락 경합이 발생해 데

itchipmunk.tistory.com

 

피드백

기술 상황을 표현할 때 독자에게 불필요한 문구와 상황까지 표현하려는, 안좋은 습관이 있었습니다.

이를 AI의 도움으로 불렛 포인트나 명확하게 표현하도록 변환하여 글을 작성했습니다.

 

[ 첫 번째 글 회고 ]

1. 좌우 시선이 분산되는 글의 형식에 피드백을 받았습니다.

정렬을 가능하면 좌측으로만 정렬하도록 수정했습니다.

 

2. 예전 메모를 검토했을 때 초안과 문제 상황이 달랐습니다.

스레드 문제가 아닌 트랜잭션 경계에 대한 문제로 다시 분석을 해야 했습니다.

수정 과정에서 글의 퀄리티가 낮아지는 현상이 발생했어서 아쉬운 점이 있었습니다.

 

[ 두 번째 글 피드백 ]

1. DELETE -> INSERT 구조가 안티패턴인 이유가 포함되면 좋겠다는 피드백을 받았습니다.

해당 패턴이 격리 수준 기본값인 SERIALIZABLE 일 때 왜 치명적인지 포함했습니다.

Serializable 격리 수준, 갭락에 대한 설명이 있는 곳 이후에 위치시켜, 안티패턴인 이유에 대해서 기술했습니다.

 

2. 예시 코드를 포함하면 좋겠다는 피드백을 받았습니다.

어떤 SQL 코드였는지 예시 코드를 첨부해서 흔히 실수할 수 있는 부분을 짚었습니다.

예시 코드가 없는 기존과 다르게 더욱 이해하기 쉬웠을 것으로 기대했습니다.

 

스터디를 마치며

예전에 풀기 어려웠던 기술 문제를 정리하는, 좋은 계기가 되었습니다.

언젠가 블로그로 정리해야지 미뤘던 과업을 수행할 수 있었네요.

또 다른 직군이라도 열심히 글을 검토해주고 피드백을 달아주었던 스터디장인 앤디님한테도 감사의 인사를 드립니다.

 

앤디님 블로그 : https://kimkyuhoi.github.io/

 

댓글