블로그를 옮기며
블로그를 옮기며, 앞으로의 계획을 짜본다
블로그를 옮긴 이유부터
나는 원래 벨로그에서 테크 블로그를 운영했다.
취준생들이 많이 사용하는 플랫폼이기도 하고, 접근하기 쉬웠기 때문에 초반에는 꽤 만족하며 사용했다.
하지만 시간이 지나면서 몇 가지 아쉬운 점이 생겼다.
❌ UI 커스터마이징의 한계
벨로그는 기본적으로 제공되는 UI만 사용할 수 있다.
지금 당장 커스터마이징이 필요한 건 아니었지만, “바꾸고 싶어도 못 바꾼다”는 점이 아쉬웠다.
⚠️ 개인이 운영하는 플랫폼이라는 불안정성
벨로그는 개인이 운영하는 플랫폼으로 알고 있다.
그래서 혹시라도 서비스가 종료되거나, 장애가 발생하면 글들이 날아갈 수 있지 않을까 하는 불안이 있었다.
😅 그리고… 간지(?)가 없다
사실 이게 가장 솔직한 이유지 않을까 싶다 😅
개발자와 GitHub는 떼려야 뗄 수 없는 관계다. 코드, 버전 관리, 협업들이 모두 GitHub에서 이루어진다.
그런데 고민들은 velog에 올려 따로 운영하는 게, 왠지 흐름이 끊기는 느낌이었다.
개발자스럽게 블로그를 운영하고 싶다는 생각이 들었다.
그래서 블로그를 GitHub로 옮기기로 결심했다.
지금까지는
🛠️프로젝트를 진행하며 생긴 문제를 포스팅 했다.
지금까지 벨로그에는 주로 프로젝트를 진행하며 생긴 문제들을 해결하는 과정에 대한 포스팅을 주로 작성했다.
외부 API 병목 해결하기나, 싱글 코어 CPU GC 튜닝 시도하기 같이 트러블 슈팅이나,
기술적 도전에 관련된 포스팅을 주로 적었다.
😂 하지만 한계를 느꼈다.
하지만 점점 한계를 느끼기 시작했다.
DB 인덱싱, 쿼리 최적화, 비동기 처리 등 익숙한 주제들을 반복해서 다루다 보니 새로운 도전 없이,
익숙한 방식 안에서만 머물고 있다는 느낌이 들었다.
물론 그 과정에서 원리나 내부 동작도 깊이 있게 공부해왔지만,
새로운 기술을 공부하는 것은 점점 줄어들었다.
결국엔 쓰던 것만 쓰고, 하던 것만 하면서 성장이 정체되고 있다는 생각이 들었다.
이제부터는
⭐ ️NoSQL을 공부하려고 한다
지금까지는 MySQL을 메인 DB로 많이 사용해왔고 공부해 왔지만,
토큰 관리나 캐시 데이터 관리 등의 작업에서 Redis를 사용하면서도 NoSQL에 대해 공부가 부족했다는 걸 느꼈다.
단순히 캐시나 토큰 저장소로만 사용하는 데에 그치다 보니,
NoSQL이 왜 필요한지, 어떤 상황에 적합한지, 내부 구조는 어떻게 동작하는지에 대한 이해가 부족했다.
그래서 우선 Redis의 자료구조와 내부 동작 방식부터 공부해보고,
이후에는 MongoDB처럼 Document 기반의 NoSQL도 학습하고 적용해보려고 한다.
⭐ ️대규모 트래픽에 대해 공부해보려고 한다
나는 오버 엔지니어링을 싫어해 왔다.
서비스를 운영하며,
“이게 진짜 우리 서비스의 상황에 적합한 기술이야?”, “우리 서비스 트래픽에는 이정도로 충분하지 않아?”
라는 생각으로 개발을 진행해왔다. 물론, 이런 접근은 다양한 상황을 고려하는데 도움이 되었다.
하지만 트래픽이 많아지면 어떻게 될까? 라는 질문에 대한 고민이 부족했다.
현재 애플리케이션은 잘 동작하고 있지만,
사용자가 수천배로 늘어났을 때도 이 구조가 여전히 유효할까?, DB는 정말 이대로 괜찮을까?
이런 질문에 대한 답을 찾기 위해, 대규모 트래픽을 처리하는 방법에 대해 공부해보려고 한다.
마무리 하며
지금까지 그래왔듯, 블로그에 단순히 내가 공부한 내용만을 나열할 생각은 없다.
누가 이 블로그를 읽을지는 모르겠지만,
적어도 나 자신에게는, 내가 어떤 고민을 했고 어떤 선택을 했는지 기록하는 공간이 되길 바란다.