머지않아 2025년은 끝나겠지만 - 10월 회고록

코헤·2025년 11월 3일

회고록

목록 보기

3/3

시작하며

티스토리부터 velog까지, 월간 회고를 시작한 지 벌써 4개월째다.
사실 좋은 이야기만 적진 않았다. 그래도 회고를 시작하고 나서 한 달마다 내 삶에 어떤 밀도가 생겼는지 기록하다 보니, 언젠가 이 글들이 나에게 도움이 되는 날이 오지 않을까 싶었다.
이렇게 오랫동안 지속해준 나 자신에게 그리고 응원해준 모든 분들께 정말 고맙다는 말을 하고 싶다.

💻 개발/프로젝트

TdFinder exe 파일 배포 (10/4)

이전에 만든 TdFinder가 스크립트 형식이라 Python을 모르면 사용할 수 없다는 큰 결점이 있었다. 이를 개선해서 exe 파일로 만들어 배포했다.
지금은 퇴사한 상태라 제대로 된 성과는 알 수 없지만, 새로운 배포 방식을 알게 되어 뜻깊었다. 간단한 exe 파일이라면 필요할 때마다 하나씩 만들어볼까 싶다! OCR 변환이나 PDF화 같은 것들이 약간 번거롭긴 했어서...ㅎㅎ

모각작

사실 모각작을 하면 빡!! 집중!!! 하는 모습은 보기 힘들다..

거의 그냥 미치기 일보직전으로 엉엉 울면서 "나 이거 못하겠어"라고 징징대는 모습을 더 많이 보여준다..
그럼에도 불구하고 모각작을 하는 이유는?
✅ 나는 혼자서는 도저히 집중을 못한다
✅ 누군가 나를 감시한다는 느낌에서 집중하게 된다
놀랍게도 미치기 일보직전에서 엉엉 우는 상태가 내가 집중하는 모습이다...
그렇다. 🫠

📚 학습/성장

SRE 특강 (10/5, 10/6) - 멜로나님, 리유님과 함께

추석 때 시간이 좀 뜨게 되자 SRE 특강을 열어주셨다 (짜잔)

데이터 엔지니어링이 뭔지, 로그 파이프라인은 어떻게 구축하는지, 그리고 고가용성 아키텍처가 왜 필요한지에 대한 이야기들에 대한 내용이다

MSA 설계와 목표 설정의 중요성
AWS를 제대로 공부해야 하는 이유
로그 파이프라인과 메시지 큐 (RabbitMQ vs Kafka)
DNS와 로드밸런서의 역할
고가용성 아키텍처 (최소 3대 구성)

1. 데이터 엔지니어링, 그게 뭔데?

데이터 엔지니어링은 결국 데이터를 처리하는 것이다.
데이터 엔지니어가 하는 일은 로그 파이프라인을 통해 빅데이터를 처리하는 것.
그리고 MSA는 기초 이론을 확실히 알아둬야 한다는 걸 다시 한번 느꼈다.

2. 모놀리스에서 MSA로

옛날 방식은 모놀리스였다.
서버 하나에 모든 게 몰려 있고, 포트 하나 열어서 80이나 443으로 들어오면 끝.

[ FE (HTML, JS) ] → [ API 서버 ] → [ DB ]

프론트엔드가 있으면 HTML이 있어야 하고, JS 파일도 있어야 한다.
그리고 API를 호출하면 DB를 조회해서 리턴하는 구조.

인터페이스는 규격만 정해두고 구현은 나중에 할 수 있게끔 하는 거다.
근데 인터페이스 없이 그냥 만들면 보안상 문제가 생긴다.

3. AWS, 왜 필요한 걸까?

AWS를 잘 하기 위해서 공부해야 한다는 걸 깨달았다.
AWS는 안정적이고 신뢰성 있게 서비스를 하기 위해 필요하다.
규모가 커지면 대용량 인프라를 직접 만들기가 너무 어렵다.

앞으로 AWS에 대한 학습이 필수적이라는 걸 느낀 시간이었다.

4. MSA 구조 설계의 중요성

MSA 구조를 만들 때는 설계부터 어떻게 할 것인지, 어디까지 할 것인지, 우리 회사의 목표는 뭔지 그런 것들을 숙지해야 한다.
의논하면서 그림을 그려 나갈 수 있어야 한다.

로그가 중요한 이유

로그는 서버에서 남기는 경우도 있고, 클라이언트에서 남기는 경우도 있다.
서버 로그는 보통 파일로 남는다.

5. 메시지 큐와 검색 엔진

메시지 큐 선택 기준

양이 적을 때: RabbitMQ를 쓴다
양이 많을 때: Kafka를 쓴다

검색 엔진 (Elasticsearch)

검색 엔진에 데이터를 때려 넣고, DB처럼 사용할 수도 있다.
요즘 사람들은 다 미쳤고, 최근 몇 년간 신입들한테 다 필요하다고 하면 빅데이터 플랫폼을 구축해야 한다.

6. 고가용성 아키텍처란?

MSA는 마이크로서비스 설계를 해야 하는 것이고, 고가용성 아키텍처라고 부른다.

왜 최소 3대일까?

보통 3대로 한다.
한 대가 망가졌을 때 나머지 두 대가 돌아갈 수 있는 상태여야 하기 때문이다.

MySQL을 직접 설치해보면 최소 3대를 요구한다.
Elasticsearch나 이런 것들도 다 보통은 한 대로 할 수 있지만, 도큐먼트를 읽어보면 권장하는 건 최소 3대다.

7. DNS와 로드밸런서

DNS의 역할

DNS는 IP 주소를 매핑한 것으로 내비게이션 역할을 한다.
DNS를 제공해주는 곳은 한국에서는 대표적으로 통신사가 있다.

한국의 DNS는 고가용성을 만들어 놓고, 최소 3대씩 구성해놓는다.

로드밸런서

로드밸런서는 여러 곳에 전달을 해주는 것이다.
회사가 있으면 한 대에서 여러 대로 이루어진 서버가 있고, 로드밸런서를 하는 게 쿠버네티스 쪽이 유리하다.

📚 학습/성장 - 난노콘 참석 (10/18, 신촌)

난노콘에서는 발표 세션과 모닥불 토론이 진행됐다.

📢 발표 세션

〈BDL을 소개합니다〉
〈React에서 불필요한 웹소켓 재연결을 줄이는 방법〉
〈음악을 이렇게 다루면 않되〉 - integraldx
〈추상대수와 프로그래밍 사이의 관계〉 - 김지현

🔥 모닥불 주제 목록
기술 영업하는 법 / 모티베이션 유지하는 법 / 스터디 운영 잘하는 법 / GraphQL 좋은가 나쁜가 / 이직 스킬 뭐배울까 / 기술 문서 잘 쓰는 법 / 협업 잘하는 법 / AI. 필수? 필요악? 절대악? / 일만 해선 성장이 안되는 거 같은데 어떻게 해야 할까요? / 일정 잘 지키는 법

이 중에서 나는 "기술 문서를 잘 쓰는 법"과 "일정을 잘 지키는 법"에 대한 발표를 했다.

🤔 기술 문서를 왜 쓰는가?

먼저 "기술 문서를 왜 적는지"부터 이야기를 시작했다.

문서를 쓰는 이유, 사람들이 문서를 안 읽는 이유, 그리고 불확실성에 대응하는 방법까지 고민해봤다.

📝 기술 문서 작성 가이드라인이 필요하다

회사의 기술 문서가 오픈되면 그게 오픈 소스나 마찬가지 아닐까?

오픈 소스 차원에서 문서 작성 가이드라인이 나오면 좋겠다는 생각이 들었다. 기술 문서를 어떻게 적을지에 대한 표준이 있으면 모두가 편할 텐데 말이다.

⏰ 일정을 잘 지키려면?

일정을 잘 지키려면 불확실성을 이해해야 한다.

불확실성에는 두 가지 유형이 있다:
1. 일 자체에서 오는 불확실성 - 직접 해봐야 알 수 있는 것
2. 실행하는 과정에서의 문제 - 내가 통제할 수 있는 부분

첫 번째는 사실 우리가 통제할 수 있는 부분이 아니다.

우리가 할 수 있는 건 두 번째를 최대한 잘 지키면서도 불확실성에 잘 대응하는 것이다.

✅ 내가 통제할 수 있는 부분 파악하기

일정을 잘 지키는 법은 명확하다.

불확실한 변인은 제외하고
내가 통제할 수 있는 부분이 무엇인가를 먼저 파악하기
내가 할 수 있는 범위에 대한 파악도 중요하다

오픈 API를 쓰는 이유도 비슷하다. 변인을 제외하고, 내가 통제할 수 있는 요소가 많아질수록 일정을 지킬 수 있는 방법론도 많아진다. 결국 불확실성을 줄이는 것이 핵심이다.

😩 사람들은 왜 문서를 안 읽을까?

국비 학원 다닐 때 프로젝트를 하면서 가장 힘들었던 건, 사람들이 문서를 너무 안 읽는다는 것이었다.

결국 네 명을 다 붙잡고 내 모니터 하나만 바라보게 한 다음에, "한글을 읽어볼까? 이게 이거 맞아?" 하나씩 확인하는 식으로 진행했다.

문서를 잘 읽게 하려면, 그리고 문제를 잘 해결하려면 결국 권력이 있어야 한다는 씁쓸한 결론에 도달했다.

💡 기술 문서를 잘 읽게 하는 방법

1) 용어를 알고 있어야 한다

기술 문서를 잘 읽게 하기 위해서는 용어들을 알고 있어야 한다. 용어를 모르면 문서를 읽어도 이해가 안 된다.

2) 벌금 시스템?

극단적으로는, 기술 문서를 안 읽으면 벌금을 물게 해야 한다는 생각도 들었다. (물론 반쯤 농담이지만...)

3) 권력 관계에 대한 물음

결국 기술 문서를 잘 읽게 하기 위해서는 권력 관계에 대한 물음을 던져야 한다.

누가 왜 이 문서를 읽어야 하는가? 읽지 않으면 어떤 불이익이 있는가?

난노콘에서 나온 말 중 가장 와닿았던 건, "헤맨 만큼의 내 길이 만들어진다"는 말이었다.

기술 문서와 일정 관리에 대해 고민하고 발표하면서, 내가 겪었던 시행착오들이 결국 내 길이 되고 있다는 걸 느꼈다.

흔들릴 줄 알아야 부러지지 않는다.

👥 네트워킹/만남

명함 교환

원더님이 만든 모임에 부모임장으로 참여했다!
개발자들끼리 개인 명함을 내밀 수 있도록 만든 모임이었는데, 각자 명함을 만들어서 공유하는 시간을 가졌다.
나는 너무 귀여운 명함을 만들었고 🎨, 이 과정에서 내 캐릭터를 확실히 알 수 있었다.
링크드인 공유할 때 매번 번거로웠는데, 명함 하나로 깔끔하게 정리되니까 짱 좋았다~~ 귀여웠어!