주의사항

블로그 주인장이 LLM 툴을 이용하고 있기 때문에 대충 자동생성한 글로 대충 날먹하려는 심보가 보일 수 있습니다. 특히 글의 문체가 들쭉날쭉한 점은 주인장 본인도 영 아니지 않나 싶긴 합니다만, 일일이 고치기도 쉽지 않은 노릇이라, 별 수가 없죠 뭐…

개요

회사에서 쓸 수 있는 조건을 맞추고자 로컬 LLM 모델을 가지고 이것저것 해 봤지만, 결론적으로 내가 원하는 수준의 성능을 맞추는 데 어려움이 있어서 여전히 회사 랩탑에선 자동완성 없이 사용하게 되었다.

삽질만 잔뜩 하고 결과물이 맘에 안들게 나와서 분통이 터지지만, 일단 이 시점에서 한번 정리를 하고 넘어가는 게 좋겠다는 생각에 포스팅으로 정리해본다.

응답속도는 아주 중요하다

애플 M1 Pro 정도로는 아예 쓸모없는 응답속도를 보여주었다. 최대한 작은 CodeGemma-2b-it 모델로 시도해도 응답시간이 7~8초 정도 걸려버리면 쓸 수가 없는 수준이다. 소프트웨어 개선으로 어떻게 할 수 없을 것 같은게, 같은 시스템을 GPU에서 돌리면 상용 서비스 수준의 응답시간 (대충 1초 미만)으로 내려오기 때문에, 대충 내가 뭘 어떻게 더 비벼볼 여지가 없겠다는 생각이 든다.

결론: 응답시간 3~4초 넘어가면 무쓸모

현재 코드만 볼 게 아니라 변경에 대응할 필요가 있다

내가 해보니까, 내가 필요로 하는 use case가 좀 갈리는 것 같다:

1. 그냥 코드가 주어졌을 때 주변 문맥을 파악해서 코드를 생성하기
2. 내가 코드를 변경하는 의도에 맞춰서 다른 변경을 자동으로 제안하기

기존 모델들은 대충 1번 사례에만 맞춰서 개발되었을 텐데, 2번 사례가 사실 더 쓸 일은 많다고 본다. 다만 코드 변경을 실시간으로 파악해서 거기에 맞춰 변경을 제안하려면 개발할 게 많아진다. 일전에 뜯어본 프로토콜 분석에서도 단순 현재 코드 외에도 최근 변경 내역이나, 현재 에러가 난 부분 같은 컨텍스트 정보도 함께 전달하는 것으로 보인다.

의외로 호출이 아주 빈번하지는 않더라?

어디까지나 mitmproxy에서 잡힌 패킷 기준이긴 하고, 희안하게 mitmproxy에서 통신을 잡지는 못했지만 자동완성이 표시되는 경우도 있어서 아리까리한 사안이긴 한데, 대충 호출 횟수가 한시간당 100번 미만 정도인 듯 싶었다.

이유를 짐작해 보자면…

• 그냥 내가 코드를 한시간 연속으로 집중해서 짜는게 아니라서 그런걸까? 헤헤
• 챗을 이용한 코드 생성이든, 입력중의 자동완성이든, AI를 사용할 일이 분당 1회 이상 빈번하게 발생하진 않는 것 같다. 당장 내 경우를 봐도 - 대충 2~3분 정도 내맘대로 막 짜다가 한두번 AI를 써서 정리를 한다거나 별 생각없이 할 수 있는 리팩토링 - 예를 들면 기존에 있던 테스트 케이스를 조금 변경해서 새 테스트 케이스를 만드는 작업 등 - 의 작업을 진행할 때 집중적으로 AI를 이용하는 식이란 말이지…

결론

걍 텍스트 생성은 충분히 빠른 LLM API를 쓸 수 있는 상황이 아니라면 그냥 안하는게… 근데 이렇게 하다 보니까 회사 차원에서 사내에서 사용가능한 LLM API를 제공하는 것도 좋은 방법이지 않나 싶다. 대충 작은 회사라면 그냥 사장님 계정으로 OpenAI 결제해서 쓰고, 중간규모 이상 정도에선 뭐 회사 사무실 한켠에 데탑이라도 한대 놓고 4090 두대쯤 설치한 다음에 70b 모델이라도 돌린다던가?

후일담: API mitm 그 이후…

패킷 덤프를 보니 connect-es라는 프로토콜이 보여서 그걸로 찾아보니 요 사이트에 대충 프로토콜이 설명되어 있다. 대충 첫 5바이트에 플래그랑 메시지 사이즈(=N)이 들어가고 다음 N바이트에 protobuf binary로 인코딩된 모델이 들어간다. streaming의 경우 플래그의 특정 bit가 set될 때까지 계속해서 메시지가 0개 이상 등장하고, 마지막 메시지의 경우 protobuf가 아니라 뜬금없는 JSON object로 error 정보를 제공한다 - 정도만 이해하면 된다.

사실 코드 작성에서 제일 번거로웠던 부분은 mitmproxy 설정이랑 메시지 프로토콜 얻어내는 부분이었지 그 외 부분은 아주 평이한 수준이었다.