🧠 env: “설정값, 그렇게 자주 불러와도 되는 줄 알았죠?” / 나: “아니였나요?”

🧩 배경 

우리 팀은 다양한 프롬프트 기반의 워크플로우를 설계하고 있고 그에 따라 문서 처리 파이프라인에서 임베딩 모델 호출이 핵심 요소로 들어간다(어딜 가나 마찬가지 아니겠냐만,,)

 

글로 설명하깅네 상황이 꽤 복잡하지만 아무튼 중요한 건! 우린 LLM 기반 파이프라인이 자주 바뀌는 상황에 놓여 있다는 것.

병렬 처리가 많은 만큼 모델 설정값 관리가 자연스러운 병목 포인트가 되었다.

 

전에 얼핏 선임님의 이야기를 들은 기억이 있는데..

 

이 문제를 "체감"한 시점:

문제를 "체감"한 시점은 단순히 성능 때문이 아니라, 로그 보다가 였다

 

같은 모델을 계속해서 다시 만들고 있다는 로그->반복->반복->또 반복->..->그래서 의심했고->파보게(?) 됐다

💭 고민의 내용

처음에는 단순히 "모델 응답 속도가 좀 느리네?" 정도로 느끼고 말았다.

근데 자세히 들여다보니... 문제는 훨씬 더 근본적인 데 있었다

• 매번 임베딩을 호출할 때마다 env 설정값을 불러옴
• 새 모델 객체 생성
• 즉, 같은 모델을 불필요하게 여러 번 만들고, 생성하고, 만들고, 를 반복하고 있었던 것이다...

물론 구조적으론 문제가 없지만 운영적인 측면에선 치명적인 자원 낭비가 아닐까?

 

하나의 문서를 적재할 때 평균적으로 10개 청크가 생기는데..

한 번 호출 시 날리는 문서 개수가 이천 개 정도...

그럼 적어도 이만 번.. 하나하나씩 만들고 또 만들고.. 으악🙀🙀

 

내가 짠 코드지만 슬슬 부끄러워지기 시작했다(ㅜㅜ)

"내가 이걸 왜 이렇게..?" 하는 자괴감 + 찝찝함..

 

 

🛠️ 해결을 위한 시도들 

1. 로직 분리부터 시작했다

envLoad~ 형태의 설정 로더를 만들고, 호출 시점과 생성 시점을 분리했다

 

2. 설정값을 기반으로 전역 모델 캐시 map을 만들었다

key: 모델이름, value: 모델 객체

심플하게!!!!!

 

3. 호출 전에 있는지 확인하고, 없으면 만들고 map에 저장하도록 구현

4. 그리고 테스트

호출 수만큼 모델 생성을 줄였더니 로그도, 속도도 눈에 띄게 개선됐다!! 

필요하지만 과다출력됐던 로그도 잡혔고 LLM 부분도 원활하게 처리되는 것을 확인할 수 있었다.

 

+) 구글링

단순 최적화가 아니라 메모리 관리 관점에서도 모범 구조에 가까운 것 같다..!

 

 

📈 변화 

• 청크 적재 과정에서 불필요한 설정 재생성이 0으로 줄었다!!🥳🥳
• 다중 모델 호출이 동시 발생하더라도 효율적으로 처리된다
• 코드 가독성도 좋아졌고 로그 보기도 편함
• 나중에 설정 구조 바꾸기도 편함
• 무엇보다도 "이게 아닌데..", "더 좋은 방법이 있을 것 같은데.." 싶던 찝찝함으로부터 해방!! 🥳🥳 🥳🥳

 

📌 회고 & 다음 목표

이번 경험을 통해 얻은 가장 큰 인사이트는 이거다:

"작동은 한다"와 "제대로 작동한다"는 정말 다르다는 점!!

 

초반엔 잘 돌아가는데 의의를 뒀는데(그래서 그냥 넘겼다)

두 번 세 번 N번 뜯어보니 작은 설계 미스가 계속된 성능 낭비를 만들어내고 있었다

 

나는 로직을 만든 거지, 성능 낭비를 만들 생각은 전혀 없었기에, 이 부분은 바로잡고 가는 것이 맞았다.

 

앞으로는 다음을 잘하겠다:

1. 자주 호출되는 컴포넌트는 무조건 캐시 여부 + @(추가 좋은 방안들)을 고민하기

2. 설정 로더/팩토리 등을 코드 구조상 명시적으로 분리하기

3. (추후 목표) 캐시 map에 대해 TTL, cold-start logging 등 기능 추가를 고려해 보기

 

3번은 gpt가 추천해 준 방안이다 ㅎㅎ 나중에 공부해 보면 좋을 것 같아서 기록해 둔다

 

아무튼, 오늘 하루도 수고많았ㄷ ㅏ나자신!ㅎㅎ

성능도 잡고 구조도 좀 정돈되었고 코드도 예뻐졌다

이 정도면 아주 잘했다 😊