(주간일지) 2025-11-17 ~ 2025-11-23

진짜 너무 바빠서 지난 주는 게시글만 생성해놓고 거의 못썼다...

이번 주도 바빴지만 ^_ㅠ 기억에 의거해서 해보는걸로..

---

11/18(화)

요즘 맡게 된 개발지원 업무가 생각보다 쉽지 않다.

처음 다뤄보는 영역이다 보니 오류 원인 파악부터가 만만치 않고, 최신 구조에서 돌아가는 모듈을, 캐시가 없는 이전 환경에 맞게 적용하는 작업이었다.

캐시 레이어가 존재하느냐 아니냐의 차이인데, 이게 생각보다 단순한 문제가 아니었다.

 

최신 버전에서는 캐시를 중심으로 데이터 흐름이 구성되어 있다 보니 그 위에서 돌아가는 비즈니스 로직 자체가 캐시 구조를 전제로 설계되어 있다.

반면, 이전 버전은 캐시가 없고 DB 중심으로 동작하는 구조다.

 

특히 아래 두 가지에서 오래 멈춰 있었다.. (결국 팀장님께 여쭤보고 결정했다)

1) 캐시 → DB 조회로 전환해도 되는가?

- 처음부터 캐시 기반으로 설계된 구조라, 조회 흐름을 DB 중심으로 바꿔야 할지 고민이 컸다.

- 캐시 도입을 하자니 변경 범위가 지나치게 커지고, 반대로 DB 중심으로 가자니 성능 기준을 다시 점검해야 했다.

2) 주기적 배치/데몬 로직이 서버에 부하를 줄 가능성
- 관련 비즈니스 처리를 일정 주기로 실행해야 하는데, 주기 실행 서비스가 단순해 보여도 결국은 서버 리소스를 소모한다.

- 부하 기준을 어디까지 허용할지, 어떤 빈도로 돌릴지 등 여러 판단이 필요했다.

무엇보다 어려운 건, 내가 수정한 코드가 해당 모듈을 도입하는 이전 버전 시스템의 기준이 된다는 점이다.

언제나 높은 스펙의 환경에서만 운영되는 시스템이 아니기에 더 많은 트레이드오프를 고려하게 된다.

---

11/23(일)

오늘은 그동안 기본적으로 알고 있다고 생각했던 CS를 다시 정리해보는 시간을 가졌다.

 

솔직히 예전엔 "CS가 그렇게까지 중요한가?" 하는 생각이 있었다.

실무에서는 당장 기능을 만들고 문제를 해결하는 게 더 급했고 이론적인 개념을 챙기지 않아도 개발은 어떻게든 돌아갔기 때문이다ㅎ......

그치만 경험이 쌓이면서 자연스럽게 시야가 달라졌다고 생각한다.

예전엔 그냥 지나쳤던 구조나 흐름들이 지금은 왜 병목이 되는지, 어떤 부분이 리소스를 잠식하는지 좀 더 명확하게 보인다.

- 특정 로직이 왜 그 지점에서 막히는지 - 어떤 선택이 메모리/네트워크/IO 등에 부담이 되는지 - 동시성, 트랜잭션, 캐싱 전략이 서로 어디에서 충돌하는지

이런 것들이 결국 CS 지식과 이어져 있다는 걸 최근 점점 더 체감하게 된다.

그리고 이런 배경 때문에 전공자와 비전공자의 차이가 드러나는 것 같기도 하다ㅠㅠ.

전공자라고 해서 모든 걸 알고 시작하는 건 아니지만, 적어도 주변에서 계속 오갔던 개념이나 용어들이 자연스럽게 누적된다.

정확히 설명은 못해도 어디선가 들어본 적 있는 개념이 머릿속에 남아 있는 것 같다.

 

단순히 '비즈니스 로직을 어떻게 구현할까?'를 넘어서 전체 구조 안에서 어떤 선택을 해야 하는지 고민해야 할 일이 많아졌다..

 

예전엔 "그냥 외워두면 좋아~" 정도로 여겼던 개념들이 이제는 실제 코드 판단 기준을 바꾸고 있기 때문에,

이 시점에 다시 CS를 정리해두는 일이 앞으로 더 중요한 기준이 될 것 같다는 생각이 들었다.

 

좋은 사이트는 공유!

1) https://gyoogle.dev/blog

2) https://github.com/JulSaMo/CS-start/tree/main