트랜잭셔널 메시징이란 “메시지를 데이터베이스 트랜잭션의 일부로 발행하는 것”을 의미한다. 애플리케이션 비즈니스 로직에 의해 데이터베이스를 수정하는 작업과 메시지 큐에 메시지를 발행하는 작업, 두 가지 작업을 원자적으로 수행하여 데이터 일관성을 보장하는 것이다. 이 글에서는 트랜잭셔널 메시징을 구현하는 두 가지 패턴을 소개한다. 이어 포스트그레스큐엘(PostgreSQL)을 이용하여 이를 더 단순하게 만드는 방법을 다룬다. 포스트그레스큐엘과 PGMQ를 함께 사용하면 데이터베이스 단일 트랜잭션으로 두 가지 작업을 묶을 수 있다.

메타 인지를 높이는 데 가장 효과적인 방법은 피드백을 이용하는 것이다. 예를 들면 개발자들은 프로그래밍 언어를 배울 때부터 피드백에 익숙해져 있다. 코드를 타이핑하는 순간 컴파일러가 바로 구체적인 피드백을 준다. 무엇이 잘못되었는지를 바로 인지하고 고친다. 한 줄을 작성해도 그 안에 컴파일러 간의 몇 번의 피드백이 담겨 있다. 피드백을 있는 그대로 수용하는 것만으로 성장으로 연결되지 않는다. 피드백을 어떻게 받아들이는지가 중요하기 때문이다. 이 글은 피드백 받는 당사자 입장에 피드백을 받아들이고 이를 통해 성장하는 법을 다룬다.

글을 시작하기 앞서, ‘테스트’라는 낱말이 매우 보편적으로 쓰이기 때문에 이 글에서 말하는 테스트가 무엇인지 정의할 필요가 있다. 이 글에서 ‘테스트’는 개발자가 코드로 작성하고 코드를 실행하여 자동으로 테스트를 수행하는 것을 뜻한다. 요즘은 테스트 코드를 작성하는 것 자체가 논쟁 대상이 되지 않을 정도로 많은 개발자들(조직)이 테스트에 관심을 가지고 테스트를 작성한다. 개발자가 만든 테스트 코드를 측정하는 방법으로 보통 테스트(코드) 커버리지를 사용한다. 커버리지 지표는 테스트 코드가 코드 베이스를 얼마나 실행하는지 백분율로 나타낸 것이다.

본인이 어떤 문제가 있는지 인지조차 없다면, 그 어떤 말을 들어도 스스로 변화를 만들 수 없다. 변화는 인지를 통한 깨달음에서 시작하기 때문이다. 안타깝게도 스스로 인지하는 일은 쉽지 않다. 소중한 것을 잃고 나서야 그것이 소중한 것이었음을 깨닫듯, 우리는 스스로가 아니라 외부에서 벌어진 사건을 통해 중요한 것을 인지할 때가 많다. 이번 글에서는 스스로 실천할 수 있는 인지적 활동을 소개하려고 한다.

‘테스트 주도 개발(Test-Driven Development, 이하 TDD)’은 자바(Java) 테스트 도구인 JUnit을 만든 켄트 벡이 만든 개발 방법으로, 빨강/초록/리팩토링이라는 사이클을 반복하는 것이 특징이다. TDD를 처음 접하는 사람들이 가장 놀라는 점은 작동하는 코드를 만들기 전에 실패하는 테스트를 먼저 작성한다는 것이다. 왜 처음에는 컴파일조차 되지 않을 수 있는 실패하는 테스트를 먼저 작성하는 것일까? 그럼으로써 무엇을 얻을 수 있을까?

간혹 학습을 많이 하는데도 불구하고 성장하지 못하고 제자리걸음인 사람이 있다. 나는 그 사람과 대화하면서 피드백 없이 혼자서만 학습을 오래, 그리고 많이했음을 알 수 있었다. 주로 책이나 인터넷 강의로 혼자 학습했지만 실무 경험은 거의 없었다. 어떻게 학습하는 것이 효과적일까? 결론부터 말하자면 ‘혼자’보다는 ‘함께’해야 한다. 이제부터 그 이유를 풀어보겠다.

프론트엔드를 해야 할지 백엔드를 해야 할지 모르겠어요. 개발을 막 시작하거나 몇 년 지나지 않은 주니어 개발자들과 대화를 하다 보면 심심치 않게 듣는 말이다. 그렇다고 꼭 경험이 적은 개발자만의 고민은 아니다. 경력이 많은 개발자들도 종종 이런 고민을 토로한다. 프랑스 철학자 장 폴 사르트르는 “인생은 BCD이다”라고 말했다. 태어나서(Birth) 죽는(Death) 순간까지 끊임없이 선택(Choice)하며 산다는 뜻이다. 삶은 선택의 연속이다. 그렇다면 어떻게 해야 더 나은 선택을 할 수 있을까?

지난 글에서는 글을 써야 하는 동기와 마음가짐, 태도를 주로 말했는데 이것만으로는 글을 쓰는 데 충분하지 않을 것이다. 그래서 이번 글에서는 구체적으로 내가 어떻게 글을 쓰는지 풀어보려 한다. 추상적이고 모호한 말을 늘어놓기보다는 쓰인 글을 바탕으로 구체적인 글쓰기 과정을 말하는 것이 이해하기 좋을 것 같아 ‘글쓰기가 어려운 당신에게(7년째 쓰는 개발자로부터)’를 어떻게 썼는지 설명하겠다. 글을 시작하기 앞서 이건 지극히 나만의 방법이라는 것을 밝힌다.

소프트웨어는 ‘사람’이 만든다. 그리고 ‘함께’ 만든다. 리뷰어로서 지난 몇 년을 뒤돌아 보니 이 사실을 잊고 있었다는 생각이 들었다. 의지가 앞서 내 생각을 강요했고 맥락을 제대로 나누지 못했으며, 묻지 않고 내 말만 하기 바빴다. 이런 방식으로는 내가 원하는 것을 얻을 수 없었다. 내가 원하는 것을 얻기 위해서는 ‘함께’해야 한다. ‘함께’의 핵심은 내 생각을 자제하고 다양성을 인정하며 변화의 기회를 주고 기다려 주는 것이다. 그리고 그 밑바탕에는 사람에 대한 존중이 있다. 물론 쉽지 않은 일이다. 그래서 문화를 만드는 것이 아주 어려운 것이다.

자신의 지식과 경험을 글로 표현하는 데 어려움을 겪고 있는 사람들이 많이 있다. 몇 년 전 어느 책 저자의 멘토링 수업에 참관한 적이 있었는데 거기에서도 비슷한 질문이 나왔었다. 사내 위키에 가이드 같은 것들은 쓰겠는데 인터넷처럼 불특정 다수에게 공개되는 글은 쓰는 것이 어렵습니다. 어떻게 하면 잘 쓸 수 있을까요? 나 스스로 글을 잘 쓴다고 생각해 본 적이 없기 때문에 이런 질문이 생경하다. ‘이렇게 써라’, ‘저렇게 써라’라고 말하는 것은 내 스타일도 아니거니와 나로서는 주제넘은 일이다. 그래서 2016년부터 7년간 내가 어떤 생각과 어떤 방식으로 글을 써 왔는지 2회에 걸쳐 풀어보려 한다.