벌써 8월 마지막 주네요. 한 달 동안 블로그에 회고를 쓰다 보니, 처음 의도와는 달리 글이 자꾸 '공유용'으로 흐르더라고요. 그래서 이번 주까지만 블로그에 올리고, 9월부터는 감정과 생각을 더 솔직히 남기려고 개인 노션으로 옮기기로 했습니다. 다만 강제성이 사라질까 걱정했는데, 마침 유레카 3기 주간 회고 공유 모임이 열려서 그 힘으로 꾸준히 이어가 보려 합니다.
대신, 블로그에는 월간 회고를 작성해 보며 한 달을 돌아보는 시간을 가져볼 생각입니다! 그럼, 제 마지막 블로그 주간 회고글인 8월 넷째 주에 대해서 작성해 볼게요~ (이 생각은 또 변할 수도..?)
시작하며
일단, 이번 주는 회고글을 쓰기가 쉽지 않을 거 같습니다. 셋째 주까지는 매일 일기를 써서 참고가 잘 됐는데, 이번에는 유레카 3기 교육을 듣느라 지하철에서도 꾸벅꾸벅, 집 오면 그대로 뻗어버려서 기록을 못 했거든요. 그래서 손이 잘 안 움직이네요 ㅋㅋ 그래도 기억을 더듬어 한 번 적어보도록 하겠습니다.
밀린 블로그글 작성 (3개)
8월 2~3주 차에 했던 오픈소스 기여 경험을 블로그 글로 정리했는데, 두 편을 쓰다 보니 생각보다 시간이 오래 걸렸다. 여기에 1주 밀린 회고글까지 메우려다 보니, 이번 주 화요일까지는 거의 블로그 작업만 달린 느낌?
그래도 쓰면서 깨달은 건, "내가 Micrometer의 `MetricsDSLContext`를 꽤 깊게 파고들었구나"라고 생각이 들었다. 무려 2년 전 이슈까지 거슬러 올라가서 읽고 줄줄이 이슈 트래킹을 했으니, 이를 바탕으로 올린 이슈만 봐도 조사 진짜 많이 했다는 생각이 들었다.
이슈를 생성할 당시에는 "이건 내가 해결할 문제는 아니고 현상 정리와 버그 제보만 하자!"라는 생각으로 마무리했는데, 지금 이 글을 쓰면서 그 생각이 바뀌어 "내가 한번 해결해 보려고 시도라도 해보자!"로 바뀌었다. 이와 관련해서는 직접 해결 시도를 해본 결과를 바탕으로 따로 블로그글을 작성해 볼 생각이다.
결국 이번 주도 소제목은 '블로그 작성'인데 내용은 또 오픈소스 얘기만 한 것 같지만... 그만큼 8월에 가장 의미 있었던 활동이었다.
[디버깅 팀] 책 읽기 (Debugging Teams)
이번 주에 [디버깅 팀]을 읽기 시작했다. 이 책은 아직 영문판밖에 안 팔지만, 오픈소스 기여모임에서 번역작업을 진행해 주셔서 읽어 보게 되었다. (오픈소스 기여 경험에다가 책까지 추천받는 정말 좋은 모임..)
제 커뮤니케이션에 부족한 점이 있다는 걸 깨닫고, 이를 개선하기 위해 공부하던 중 Debugging Teams
제 커뮤니케이션에 부족한 점이 있다는 걸 깨닫고, 이를 개선하기 위해 공부하던 중 Debugging Teams (https://lnkd.in/gUcKzc4A) 라는 책을 접해 읽어보게 되었습니다. 개발자로서 커뮤니케이션과 팀 매니
kr.linkedin.com
2장까지는 정말 재밌게 읽었는데, 3장부터 리더십/안티패턴 이야기가 본격적으로 나오면서 지금 내 관심사와는 약간 거리가 있어 속도가 확 떨어졌다. 그래서 현재는 3장 중반 정도까지 읽었는데 그럼에도 불구하고 2장까지의 내용이 너무 좋아서 강력 추천하고 싶다. 솔직히 지난주에 읽었던 [함께 자라기]보다 개인적으로 더 잘 맞았다.
인상 깊었던 부분을 짧게 요약해 보면 다음과 같다.
- 겸손, 존중, 신뢰 (HTR) : 개인이 팀 협업을 위해 갖춰야 할 태도를 제대로 짚어준다.
- 팀 문화는 함께 만들고 함께 지킨다 : 누군가 정해주는 규칙을 따르는 게 아니라, 구성원이 같이 합의하고 유지한다는 관점이 특히 좋았다.
물론 현실에서 이 가치관을 그대로 적용하기는 쉽지 않겠지만, 다음 프로젝트에서는 시작부터 팀 문화를 모두가 참여해 만드는 경험을 해보고 싶다. 그리고 나부터 먼저 겸손하고, 상대를 존중하며 각자가 맡은 역할을 잘 마무리할 것이라 신뢰해야 한다고 생각했다.
지금까지 진행했던 프로젝트를 돌이켜보면 나는 팀 프로젝트에서 존중은 했지만, 겸손과 신뢰가 많이 부족했다고 생각한다. "상대가 끝까지 못 할 수도 있다"는 전제를 깔고 내가 다 떠안는 패턴이 반복됐다. 그러다 보니 "차라리 혼자가 편하다"는 생각으로 2024년부터 진행한 프로젝트에서는 혼자서 다 해낼 수 있다는 마인드로 밀어붙였던 것 같다. 이는 결국 프로젝트 곳곳에 정말 많은 포기의 흔적을 남겼고 현재는 새로 같이하는 팀원과 함께 팀 문화부터 다시 잡아가고 있다.
이번 독서는 그 습관을 다시 보게 해 줬다. 신뢰를 선행하고, 필요한 건 명확한 약속·가시화·피드백 루프로 보완하자. 다음 협업에서는 일을 가져오기 전에 신뢰부터 세우는 연습을 해볼 것. 이게 바로 내가 디버깅 팀을 읽으며 나와한 약속이다. 이번 하반기부터는 꼭 약속을 지키려고 노력해 봐야지.
로그 모니터링 도입을 위한 Logback 학습
진행 중인 프로젝트에 모니터링 자동화를 붙이고 싶다는 생각이 들었다. 지금은 Micrometer–Prometheus–Grafana 조합으로 메트릭 대시보드만 운영 중이고, Slack/이메일 알림은 따로 없다. 로그도 서버에 직접 접속해야만 볼 수 있는 구조라, 접속 없이 대시보드에서 확인하고 문제 발생 시 메신저로 자동 알림이 오도록 파이프라인을 꾸리고 싶다는 생각으로 이번 학습을 진행하게 되었다.
이렇게 되면 문제 상황을 더 빨리 파악하고 대응 시간을 줄일 수 있을 것 같다. 그래서 먼저 Spring Boot에서 로그가 어떻게 저장, 전달되는지를 살펴봤다. Spring Boot에서 사용하는 기본 로그 구현체는 SLF4J의 구현체인 Logback이었고, 지금까지 내가 서버에 로그를 쌓는 데 사용한 것도 Logback이었다. 그래서 일단 Logback을 바탕으로 "빠르게 로그를 대시보드에서 봐보자" 목표를 잡았다.
결국 Spring Boot에서의 로그 관련 핵심은 애플리케이션에서 모니터링이 필요한 로그를 예쁜 형식(기계가 읽기 좋은 포맷)으로 로그를 내보내고, 그걸 수집기 → 저장소 → 대시보드/알림 순서로 흘려보내는 것이다. Spring Boot에서는 JSON 형식으로 로그를 변환해 주는 기능까지도 제공해주고 있었고 그 내용을 바탕으로 Grafana Alloy와 연동해 로그수집 -> Loki 저장 -> Grafana 조회 흐름을 구축해 보자고 결정하게 되었다.
Logging :: Spring Boot
By default, Spring Boot logs only to the console and does not write log files. If you want to write log files in addition to the console output, you need to set a logging.file.name or logging.file.path property (for example, in your application.properties)
docs.spring.io
최종 목표는 Slack/이메일 알림까지 연동해, 알림을 받는 즉시 대응할 수 있는 운영 시스템을 만드는 것이 목표입니다. 구현이 마무리되면 과정을 블로그에 정리해 보겠습니다.
아마 중간중간 메모도 남길 것 같아요. 요즘은 '중간 생각'을 기록하는 게 중요하다고 느껴서, 실제 코드 작성에서도 초기 코드와 시행착오도 커밋으로 그대로 남겨 두려 하고 있습니다. 당시에 어떤 판단으로 코드를 썼는지 나중에 추적할 수 있도록요. 모니터링 설계 과정에서도 처음 설계했던 방향과 이후에 어떻게 바뀌었는지를 비교해 보면서 얻어가는 게 분명히 있을 것이라고 생각합니다!
[객체지향의 사실과 오해] 완독
8월 12일, 지하철에서 읽으려고 샀던 책을 3주 만에 완독 했다. 260쪽이라 부담이 적어 생각보다 금방 읽혔다. 읽는 내내 내 코딩 습관을 점검할 수 있었고, 특히 유스케이스 기반으로 객체지향 설계를 전개하는 마지막 파트가 크게 도움이 됐다. 다 읽고 바로 후속서 [오브젝트]를 주문했다. 앞으로는 [오브젝트]에서 직접 코드로 실습하고, 부족한 부분은 [객체지향의 사실과 오해]로 돌아가 개념을 보강하는 방식으로 객체지향 패러다임을 몸에 익혀 보려 한다. 백엔드를 하면서 객체지향 패러다임에 대한 학습이 조금 늦었다는 생각도 들지만, 지금이라도 시작해서 꾸준히 관련 책을 읽고, 실습으로 체화해보려고 합니다.
이번 주에 짧게 [오브젝트]를 읽으며 극장 티켓 판매 예제를 따라 코딩해 봤다. 먼저 내가 구현해 보고, 이어 책의 구현과 대조하면서 내 방식의 문제를 하나씩 체크했다. 이렇게 하니 내 약점이 선명해졌고, 앞으로도 이 방식으로 [오브젝트]를 읽어가야겠다고 결심했다. 그리고 이 공부법에 이름도 붙여봤는데, 바로 간접 코딩 리뷰다. ㅋㅋ.
마무리하며
이번 주는 사실 아침 7시에 일어나서 선릉 멀티캠퍼스에 오느라 너무 힘들었던 일주일이었다. 고등학교 이후로 이렇게 규칙적으로 생활해 본 게 오랜만이라 그런가? 아직 몸이 적응하지 못하고 삐걱대는 느낌이 강하게 들었다. 보통 습관이 들려면 한 달 정도 꾸준히 하면 된다는데, 이제 1주 정도 지났으니 앞으로 9월까지는 이 규칙적인 패턴에 적응하는데 더 초점을 맞춰야겠다고 마음을 먹었다.
마지막으로 블로그에 가장 하고 싶은 말은
"맨날 피곤하고 힘들긴 하지만 나중에 돌아봤을 때 후회가 남지 않고 싶다."
이다.
'일상' 카테고리의 다른 글
| 천천히 배운 4년, 빠르게 배운 석 달 (0) | 2026.07.18 |
|---|---|
| 9월 회고 : 겸손하게 천천히 나아가기 (0) | 2025.09.28 |
| 축제 현장 속으로 - 2025에 참여한 축제 (0) | 2025.09.11 |
| 8월 2~3주차 회고 : 오픈소스에 빠지다 (1) | 2025.08.26 |
| 폭풍같이 지나간 8월 첫째 주 (유레카, KT 에이블 스쿨, 코테, etc..) (3) | 2025.08.11 |
