4월 1주차 내맘대로 Weekly Insights
4월 1주차, 한 주 동안 개인적으로 흥미롭게 본 인사이트들을 소개합니다 :)
면접관이 물었다. 만일 스택이 매우 커질 수 있다면 힙은 불필요할까?
“스택만 무한히 크면 힙이 필요 없지 않나요?”라는 질문은 얼핏 들으면 그럴싸하다.
하지만 이 영상은 단순한 질문을 통해 스택과 힙이 ‘왜’ 존재하는지를 다시 생각하게 해준다.
단순히 메모리 구조 차이만이 아니라, 객체의 생명 주기, 메모리 관리 방식, 호출 흐름 등 여러 개념들이 뒤엉켜 있다.
자칫 흐릿했던 개념들이 선명해지는 느낌이랄까.
면접에서 이런 류의 질문을 받는다면, 단답형보다는 시스템 관점에서 설명할 수 있어야겠다는 생각이 들었다.
나 자신에게도 좋은 개념 체크 포인트가 되었고, 앞으로 JVM 공부할 때 다시 꺼내볼 것 같다.
이런 질문 하나가 사고를 깊게 만들어준다는 점에서 꽤 인상 깊었다.
캐시를 적용하기까지의 험난한 길 (TPS 1만 안정적으로 서비스하기)
캐시를 도입하는 게 무조건 성능을 올려준다는 믿음은 위험하다.
이 글은 토스팀이 실제 트래픽 환경에서 겪은 수많은 고민과 삽질을 솔직하게 담고 있다.
단순히 Redis를 붙인다고 해결되는 문제가 아니라, 어떤 데이터를 캐싱할지, TTL은 어떻게 정할지, 일관성은 어떻게 유지할지… 수많은 선택이 필요하다는 걸 보여준다.
그리고 그 선택의 무게가 결코 가볍지 않다는 것도.
사이드 프로젝트에서도 캐시를 붙여야 할 일이 종종 있는데, 이 글 덕분에 조금 더 신중해졌다.
“캐시는 성능을 높이는 게 아니라 문제를 늦게 드러나게 할 뿐이다”라는 말이 기억에 남는다.
빠른 것보다 정확한 게 먼저라는 사실을 다시 새기게 된다.
Spring 기반 멀티모듈 프로젝트 환경변수 설정 방법
멀티모듈 구조에서 설정 파일 다루는 건 생각보다 귀찮고 복잡하다.
공통 설정과 모듈별 설정을 어떻게 분리할지, 환경별 설정은 어디까지 나눠야 할지 고민할수록 꼬이기 쉽다.
카카오페이의 사례는 이런 혼란을 구체적인 구조와 함께 정리해줘서 참고하기 정말 좋았다.
특히 core, infra, api 같은 모듈 분리와 프로퍼티 주입 방식은 그대로 따라 해도 될 만큼 실용적이다.
지금 사이드 프로젝트도 멀티모듈 구조인데, 슬슬 환경설정에서 머리가 아파지기 시작한 참이었다.
이 글 덕분에 미리 길을 정리할 수 있었고, 나중에 삽질을 줄일 수 있을 것 같다.
빌드할 때마다 profile 꼬여서 디버깅하던 날들이 떠오른다…
LLM 시스템을 평가하는 방법
LLM 기반 시스템을 만들면서 종종 드는 생각이 있다. 이 결과가 “좋은 답변”이라는 걸 누가 판단할 수 있을까? 정답이 명확하지 않은 세계에서 품질을 어떻게 정량화할 수 있을까? 이 글은 그런 의문에 대한 매우 실용적이고 구조화된 해답을 제시한다.
핵심은 단순하다. LLM은 비결정적이고 예측 불가능한 시스템이기 때문에, 평가 지표 없이는 발전도, 신뢰도 없다. 따라서 Ground Truth 기반의 정확한 기준부터, Answer Relevancy, Coherence, Contextual Relevance 같은 세부 지표까지 꼼꼼히 설계해야 한다. 그 지표들이 시스템 튜닝의 방향이 되고, 릴리즈 전/후에도 일관성 있게 품질을 유지할 수 있게 만든다. 개발자 입장에서는 귀찮고 복잡한 작업이지만, 결국 사용자와 신뢰를 이어주는 유일한 수단이 된다.
나도 LLM을 활용한 시스템을 만들면서 종종 ‘그럴듯한 결과’에 만족했던 적이 있다. 하지만 이 글을 읽고 나서야 그런 감상적인 기준이 얼마나 위험할 수 있는지 깨달았다. 앞으로는 결과를 만들기보다, 먼저 ‘어떻게 평가할 것인가’를 묻는 습관을 들여야겠다는 생각이 든다.
우리 회사, 망할 팔자인가
“성과란 무엇인가, 어떻게 측정되어야 하는가?”라는 질문을 던지는 글이다.
이 글은 ‘무엇을 했는가’보다 ‘어떤 차이를 만들었는가’에 집중해야 한다고 말한다.
가치 창출 중심의 관점에서, 숫자로 환원되지 않는 성과를 측정하려면 설문조사나 감성 분석처럼 정성적인 지표도 적극적으로 활용해야 한다.
결국, 계량화가 어렵다고 피하지 말고 오히려 더 집요하게 측정할 방법을 찾아야 한다는 이야기다.
이건 나도 회사를 다니면서 한 번쯤 고민했던 주제다.
신규 서비스 런칭과 기존 서비스 유지보수 중 어떤 게 더 ‘성과’인가?
귀찮고 복잡하더라도, 이런 질문에 답하려면 결국 ‘측정’이 필요하다는 데 공감이 갔다.
데이터가 독이 될 때
이 글은 ‘분석 마비’에 대해 이야기한다.
선택지가 많아지고, 데이터가 쌓일수록 오히려 불안과 압박이 커져서 결정을 내리기 어려워진다.
데이터에 갇히지 말고, 지금 가능한 최선을 빠르게 실행하면서 작게 실험하고, 자주 피드백을 받아야 한다.
핵심에 집중하는 것이 분석 마비를 극복하는 방법이라는 메시지가 명확하다.
이걸 보면서 에자일 방법론이 떠올랐다.
핵심 기능만 빠르게 개발해서 빠르게 실패하고, 그걸 발판 삼아 다시 나아가는 것.
완벽한 결정보다 빠른 실천이 중요하다는 걸 다시 느꼈다.