“오늘은 써야지”를 여섯 번 되뇌며, 세 번 썼다.

 

‘오늘은 써야지.’
이 말을 되뇌이며 블로그에 글을 올린 게 이번 글 포함해서 어느새 3번째 글이다.
총 6주의 시간 동안, 주말이 되면 늘 다짐처럼 '오늘은 써야지…'라고 혼잣말을 하며 글을 썼던 것 같다.

하지만 3주는 결국 업로드하지 못했다.
왜 못 썼을까? 라고 질문을 한다면,

단순히 귀찮아서가 아니다. 기술 블로그를 쓴다는 건 누군가에게 도움되는 정보를 정리하고, 읽는 사람에게 인사이트를 주어야 한다는 부담이 있어였다.
‘그 정도는 써야 하지 않나’ 하는 완벽주의가 책상에 앉는 걸 더 어렵게 만들었다.

사실 이 블로그 챌린지에 앞서 있었던 특강에서 “완벽주의를 버리고, 일단 써보자”는 조언이 있었다.
나도 그 말에 고개를 끄덕였지만, 실제로 실행하는 건 또 다른 문제였다. 하루키의 말처럼 ‘일단 앉는 것이 중요’하다고 하지만 , 막상 앉고 나면 정리하고 마무리하는 게 가장 고역이었다.

현재 나는 회사에서 Salesforce 플랫폼 기반의 개발 업무를 하고 있다.
'세일즈포스 개발자입니다'라고 하면, 보통 CRM 설정이나 노코드 툴만 다루는 것으로 생각할 수 있지만, 실제 업무를 해보면 그렇지 않다.
트랜잭션, 동시성 이슈, 외부 시스템 연동 등 결국 모든 개발의 본질은 비슷하다.

 

특히 블로그 글쓰기 3주 차 주제였던 ‘트랜잭션’을 다루면서, 회사에서 실제로 겪었던 경험이 떠올랐다.
Mulesoft를 활용해 Oracle과 PostgreSQL이라는 이기종 데이터베이스를 연동하던 중, 분산 트랜잭션 문제에 직면했다.
(참고로 Mulesoft는 JTA 기반의 트랜잭션 매니저를 사용하며, Bitronix가 여러 데이터소스 간 트랜잭션을 관리한다.)

이슈는 트랜잭션 커밋 타이밍이 어긋나면서 두 번째 PostgreSQL 데이터베이스에서 다음과 같은 에러가 발생했다:

"transaction is marked as rollback-only"

첫 번째 데이터소스에서는 트랜잭션이 정상적으로 처리됐지만, 두 번째 쪽에서 예외가 발생한 후 전체 트랜잭션이 롤백되면서 이 에러가 발생했다. 이슈를 해결하기 위해 Bitronix의 트랜잭션 매니저 설정과 커넥션 풀 동작 방식, 트랜잭션 경계를 면밀히 검토해야 했다. 결국 GitHub에서 Java 소스를 직접 분석하며 트랜잭션 흐름을 추적한 끝에 문제의 원인과 해결책을 파악할 수 있었다. 이 경험을 통해 트랜잭션을 단순히 개념으로 이해하는 것과 실제 상황에서의 복잡한 작동 방식을 체감할 수 있었다.

 

 

이쯤에서 인용하고 싶은 말이 있다.

“If you're thinking without writing, you only think you're thinking.”
— Leslie Lamport

 

사실 트랜잭션 주제를 받았을 때, 글을 썼어야 했다. 

머릿속으로 이슈와 해결책을 정리만 하고 '오늘은 써야지…'라고 미루다 보니 그 느낌이 머릿속에만 맴돈 상태였다. 지금 하는 일을 정리하고, 경험을 언어화하는 능력. 그건 단순히 기록이 아니라, 생각을 명확히 하는 행위이자, 더 나은 개발자가 되기 위한 필수적인 훈련이라고 느낀다.

 

마치며..

지금까지 6주간 한 활동이 궁금할 수 있다. 그전에 나는 항해플러스 백엔드 과정에 참여하면서 해당 활동을 알게 되었다. 

 

그래서 항해플러스를 소개하고 마치도록한다.

항해플러스는 시니어 개발코치님들과 함께 멘토링을 통해 동료들과의 협업을 통해 실무 역량을 강화하는 10주간의 몰입형 프로그램이다.

내가 문제로 겪었던 트랜잭션부터 동시성 처리, 클린 아키텍처, CI/CD, 장애 대응 등 실무에서 마주치는 다양한 주제를 다루며, 실제 프로젝트를 통해 경험을 쌓을 수 있다.

백엔드 주니어 개발자로서 성장의 한계를 느끼고 있다면, 시니어 코치진과 함께 10주 몰입을 통해 도약하세요.

hanghae99.spartacodingclub.kr

항해 플러스, 도전을 넘어 개발자 커리어 도약으로

 

지원 페이지 > 서류합격시 결제페이지 하단 코드 >  를 입력하시면 20만원 할인 적용됩니다.