구축이 끝나고 남은 건…

오래 운영되던 시스템의 로깅을 Kafka 기반으로 다시 구축했다. 운영만 하던 파이프라인을 직접 설계하고 세우는 일이었다. 구축이 끝나고 돌아보니, 정작 기억에 남은 것은 어떤 브로커 토폴로지를 골랐는가가 아니었다. 배운 것은 대부분 설계 바깥에 있었고, 크게 세 가지로 갈렸다.

이 글은 그 세 가지를 정리한 것이다. 화려한 결정처럼 보이지 않아서 넘기기 쉽지만, 장애가 나고 안 나고는 대개 이쪽에서 갈린다.

시스템을 보는 눈

로그를 먼저 흐르게 만든다

인프라를 세우다 에러를 만나면, 결국 기댈 곳은 로그 하나다. 로그는 그 순간의 단일 진실 원천이다. 그런데 로그를 “나중에 제대로 모으자”고 미루면, 정작 급할 때 볼 것이 없다. 그래서 로깅 파이프라인과 대시보드를 가장 먼저 만들었다.

디버깅은 추측이 아니라 로그를 읽는 일이고, 읽을 로그가 없으면 추측만 남는다. 믿을 수 있는 로깅 시스템 구축은 기능이 아니라 전제다.

개발하는 내가 첫 운영자다

개발하는 동안 계속 되물어야 하는 질문이 있다. 이걸 운영할 때 쉽고 정확하게 할 수 있는가.

재기동은 한 줄로 되는지, 상태는 어디서 보는지, 실패했을 때 무엇이 남는지. 이 질문을 개발 단계에서 던지지 않으면, 그 비용은 새벽에 깨어난 누군가에게 청구된다.

운영자의 관점은 개발이 끝난 뒤 얹는 것이 아니라, 설계하는 내내 함께 들고 있어야 하는 것이다.

교과서의 정답과 우리 환경의 정답은 다르다

Kafka의 교과서는 무유실을 우선한다. 그러나 우리 환경은 그렇지 않다. 거래 로그가 잠깐 밀린다고 코어 거래까지 멈춰서는 안 됐다. 그래서 “일반적으로 옳은 것”을 그대로 쓰는 대신, 우리 우선순위부터 정했다. 코어에 무영향, 그다음 DB에 무영향, 마지막이 무유실. 이 순서가 정해지자 Kafka의 기본값 몇 개를 의도적으로 뒤집을 수 있었다.

도구의 기본값은 도구가 상정한 환경의 최적일 뿐이고, 우리 환경의 최적은 직접 비교하고 테스트해서 찾아야 한다. 시스템을 이해한다는 건 이 차이를 아는 것이다.

일하는 방식

귀찮은 일은 미룰수록 어려운 일이 된다

재기동 스크립트를 만들고, 흩어진 로그를 모아 롤링 정책을 설정하고, 폴더 구조를 정리하는 일. 중요해 보이지 않기에 “일단 중요한 것부터 하고 나중에”로 미루기 쉽다. 그런데 그 “나중”은 잘 오지 않는다. 미룬 것들은 사라지지 않고 쌓이고, 쌓이면 성격이 바뀐다. 처음엔 귀찮은 일이었던 것이, 나중엔 하기 어려운 일이 된다.

지저분해진 폴더에서 파일을 못 찾는 상황, 점점 손대기 무서워지는 구조는 대부분 여기서 시작된다. 그래서 생각났을 때, 바로 해 두는 편이 싸다.

귀찮은 단계에서 멈춰야, 어려운 일로 자라지 않는다.

디테일이 전부 - 장애를 가르는 건 설정 한 줄이다

message.max.bytes 같은 설정이 기본 프로퍼티 파일에 주석으로 적혀 있는 데는 이유가 있다. 그만큼 중요하기 때문이다.

이 한 줄을 그냥 넘겼다가 크게 데일 뻔했다. 대용량 로그 한 건이 약 2MB였는데, 기본 한도를 넘겨 그 메시지가 파이프라인을 통째로 막았다. 개발 단계라 다행이었다. 원인을 로컬 컨테이너로 재현해보고 나서야, 이 한도가 프로듀서, 브로커, 토픽, 컨슈머 네 곳에서 함께 맞춰져야 한다는 걸 알았다.

“다음에 다시 볼 것”이라는 말은 대개 거짓말이다. 그 다음은 장애 보고서로 온다.

‘빠른 검증’과 ‘제대로’ 사이의 조율, 그리고 소통

“한 바퀴 빠르게 PoC로 검증”과 “처음부터 제대로”는 늘 부딪힌다. 정답은 없다. 무엇을 검증하려는 단계인지에 따라 매번 다르게 저울질해야 한다. 문제는 이 저울질을 혼자 마음속에서만 하면, 옆 사람에게는 그냥 “왜 이렇게 대충 해”나 “왜 이렇게까지 꼼꼼해”로 보인다는 것이다. 같은 코드도 지금이 어느 단계인지 합의되지 않으면 오해가 된다.

속도와 완성도의 조율은 기술 판단이면서 동시에 소통의 문제다.

남기는 방식

맥락을 문서로 남겨야 같은 위치와 방향을 본다

구축은 결정의 연속이고, 결정에는 맥락이 있다. 왜 이렇게 했는지, 무엇을 포기했는지, 다음에 갚아야 할 빚(기술 부채든, 위에서 말한 귀찮은 일이든)이 무엇인지. 이 맥락을 남기지 않으면 며칠만 지나도 나조차 잊는다. 그래서 문서로 적어 우선순위로 세우고, 하나씩 갚아 나가는 과정을 남겼다. 운영 노하우는 그렇게 차곡차곡 쌓였다.

여기에 한 가지가 더 있다. 구축 과정에서 AI의 도움을 많이 받았는데, AI 세션은 대화가 끝나면 맥락째 휘발된다. 그래서 AI 시대의 문서화가 어때야 하는지 찾아보고, 옵시디언[1]에 진행 상황을 일자별 진행일지, 해야 할 것, 한 것으로 나눠 남겼다. 그리고 그 문서를 다음 세션의 AI에게 다시 읽혔다. 덕분에 세션이 바뀌어도 나와 AI가 같은 위치에서 같은 방향을 보며 개발을 이어갈 수 있었다.

이제 문서는 사람만을 위한 것이 아니다.

결론

구축이 끝나고 남은 것은 아키텍처 다이어그램이 아니었다. 세 묶음이 남았다.

묶음	남은 것
시스템을 보는 눈	로그를 먼저 흐르게 해 두는 습관, 운영자의 시선, 우리 환경의 답을 찾는 태도
일하는 방식	귀찮은 것을 미루지 않는 규율, 설정 한 줄을 놓치지 않는 꼼꼼함, 단계를 합의하는 소통
남기는 방식	맥락을 문서로 남기는 습관

구축을 하며 기술 공부도 많이 했다. 강의를 듣고, 유튜브와 기술 블로그를 뒤지고, 책도 샀다. 그러나 그렇게 익힌 지식은 버전이 바뀌고 손을 놓으면 흐려진다.

반면 위 세 가지는 지식이 아니라 태도와 습관이다. 특정 설정값은 잊어도, 설정 한 줄을 흘려보내지 않는 감각은 다음 시스템으로 옮겨 간다.

그리고 그 태도는 맡은 것에 대한 책임이다. 그 시스템은 내 성장의 재료가 아니라 누군가 믿고 쓰는 것이다. 돈을 받고 하는 일인 이상, 철저히 그 시스템과 조직의 입장에서 세워야 한다.

참고 자료

[1] Obsidian — https://obsidian.md