잘한 점
- 선례가 없는 영역이었던 LLM 서비스를 도전해서 서비스를 만들어냈고, 무사히 런칭까지 해냈습니다.
- 사용자 유치에 힘써 가입자 127명, 총 사용수 285건, 질문-답변 데이터 2619건의 데이터를 얻을 수 있었습니다.
- 처음 해보는 Flask를 활용해서 3개월 내에 서비스를 만들었습니다.
- 프로젝트 팀장으로서 중간에 팀원들의 기운이 늘어지는 문제를 알아채서, 팀원들의 흥미를 끄는 과제를 주었고 그 결과 팀원들의 프로젝트에 대한 흥미를 다시 느끼게 해주었습니다. (팀원들이 슬랙 채팅으로 어떻게 성능 개선을 해야할지 시간 가는줄 모르고 토론했습니다.)
- Google Analytics 도입은 사용자 데이터 수집, 분석, 시각화에 있어서 탁월했고, 서비스 개선 인사이트를 얻는데 많은 도움이 됬습니다. 실제 사용자 유치 이후엔 데이터를 어떻게 처리하느냐가 매우 중요함을 알게 되었습니다.
아쉬운 점
서비스 관점
서비스를 제공할 대상의 범위가 너무 넓다.
질문-답변 2619건의 데이터를 분석해보았습니다. 이를 분야로 분류하면 다음과 같습니다.
- 반도체
- 전기
- 플랜트 공정 설계
- 기획
- 바리스타
- 영업
- 행정
- IT
- 생명
- 치위생사
위 분야에서 제가 면접 질문의 적절함을 판단할 수 있는 분야는 단 하나, IT입니다.
첫 기획 당시에는 ChatGPT가 "그럴듯한" 면접 질문을 주기 때문에 많은 분야를 커버할 줄 알았었습니다. 물론, 어느 정도는 커버가 됩니다만, 개발자인 제가 적절한지 판단하기 쉽지 않았습니다. 그리고 적절하지 않은 면접 질문은 사용자의 이탈을 불러오게 됩니다.
예를 들어, 다음과 같이 직접적으로 불만을 표한 데이터가 있었습니다.
- 좀 더 질문다운 질문을 해주세요.
- 답답하구만
면접이 대체 언제 끝나는지 모르겠다.
- 그만좀 하세요
- 언제까지 해요 대체
- 제발 나가게 해주세요
- 면접이 얼마나 진행되는지 (남은 질문 수? 시간?)를 알 수 있으면 좋겠습니다.
이 사실은 위와 같은 사용자들의 피드백과 데이터로 알아낼 수 있었습니다.
서비스 런칭 전에는 미처 생각하지 못한 사실이었습니다. 이는 개발자인 저 자신은 로직을 알고 있지만, 사용자들은 확률적으로 출제된다는 로직을 모르기 때문에 생긴 문제였습니다.
답변 피드백이 도움이 안 된다.
런칭을 하고나서, 저 자신도 서비스를 여러 번 사용해봤습니다.
키워드, 자소서 등 입력 데이터를 적절히 주면 면접 질문도 쓸만하게 나왔습니다. 하지만, 답변 피드백은 도움이 되지 않았습니다.
답변의 장/단점을 ChatGPT가 분석해주는데, 대부분 답변의 구체성에 대해서만 평가할 뿐이었습니다.
제가 사용자라면, 모범답안이라던가 나올 수 있는 추가 꼬리 질문 같은 정보를 얻고 싶어했을 것 같았습니다.
자료가 수집된 게 없다.
저 자신도 서비스를 여러번 사용해봤을 때, 전 면접 준비용 자료가 있어서 서비스가 도움이 되었습니다. 하지만 없는 사람의 입장에서는 어떨까요?
그리고 면접 준비용 자료는 웹 상에 많이 흩어져있기 때문에 정리하는 것만으로도 벅찹니다. 따라서 자료만 잘 모아서 조회만 할 수 있게 해도 서비스의 트래픽을 늘릴 수 있을거라 생각합니다.
기술적 관점
플라스크는 배우긴 쉽지만, 관리하기 어려워진다.
플라스크는 최소한의 기능만 갖춘 웹 프레임워크입니다. 처음에는 개발이 쉬웠지습니다. 하지만 보안, DB 커넥션, 로깅, 테스트 구축 등 서비스가 복잡해질수록 점점 개발이 어려웠습니다. 한땀한땀 직접 구축하거나, 문서화가 부족한 라이브러리등을 이용할 수 밖에 없었습니다.
이는 기존 스프링 사용자였던 제겐 매우 불편한 상황이었습니다. 스프링은 훨씬 많은 기능을 제공하기 때문에, 스프링이었다면 더 편하게 개발할 수 있었을텐데라는 생각이 많이 들었습니다.
물론, 프레임워크에 너무 의존하는 것도 좋은 것은 아닙니다.
하지만 스프링은 플라스크보다 지원하는 기능이 많아, 서비스에 직접적인 영향을 줄 수 있는 비즈니스 로직에 더 집중할 수 있게 됩니다.
그리고 소마 프로젝트는 개발 기간이 3개월 남짓 밖에 안되기 때문에 개발속도가 중요했었습니다. 그래서 파이썬을 선택했었습니다.
하지만 이제는 시간에 쫓기지 않고 서비스를 유지보수 및 개선해야 합니다. 그래서 친숙하면서, 기능을 더 풍부하게 제공하고, 타입 시스템이 강제되어 더 유지보수에 유리한 스프링으로 전환하려 합니다.
ChatGPT의 여러가지 한계
1. 사용자 입력 데이터가 별로면 질문도 별로다.
- ㅇㅇ-> ㅇㅇ에 대해 설명해주세요
- sdf -> sdf에 대해 설명해주세요
위와 같이, "ㅇㅇ"나 "sdf" 같이 의미 없는 데이터를 사용자가 입력하면, ChatGPT가 제공하는 면접 질문 역시 의미가 없습니다.
2. ChatGPT는 상식,지식이 없다.
가장 큰 문제 중 하나입니다. 면접 연습 서비스는 면접 질문의 신뢰성이 가장 중요합니다. ChatGPT 는 말을 잘 지어내는 창의성은 뛰어날지라도, 상식 지식을 판단할 수 없는 능력이 없습니다.
신뢰성이 필요한데도 신뢰성이 떨어지는 서비스는 사용자의 이탈을 불러옵니다.
3. ChatGPT는 평가를 잘 못한다.
ChatGPT는 평가 역시 못합니다. 말을 지어낼 뿐이죠.
다음은 그 사례들입니다.
- 꼬리질문을 낼지 말지 판단하는 것. 판단이 랜덤입니다.
- 면접의 답변을 채점하는 것. 특히 수치화된 점수로 표현하는게 랜덤입니다.
ChatGPT Service를 대규모 아키텍쳐로 전환할 수 있는가
ChatGPT를 사용하는 서비스에 많은 사용자가 몰린다면 어떻게 될까요?
ChatGPT 3.5 기준으로 TPM은 18만, RPM은 25만이었습니다.
아무리 오토스케일링이 되어있더라도, 이러한 ChatGPT call이 서비스의 병목 지점이 되는 것입니다.
생각할 수 있는 방안은 3가지입니다.
1. LLM을 번갈아 쓰는 것 (라마 -> openai-> 클로드->라마 ...)
2. ChatGPT는 그대로 쓰되 모델만 번갈아 쓴다. (GPT 3.5 -> GPT 4.0 -> Text davinci->...)
3. B2B용 LLM API를 사용합니다.
방안 1은 Langchain 등 LLM 프레임워크를 쓰면 가능합니다. 단, 모든 모델의 TPM, RPM이 부족해질 경우엔 동일한 문제가 발생합니다.
방안 2는 불가능합니다. 다음은 참고 링크입니다.
https://community.openai.com/t/api-rate-limitations-api-speed/248374/20
방안 3의 경우, Azure api를 사용하면 됩니다. 제 기억상으론 300K TPM이었던 같습니다. 하지만 이 방법은 사업자 등록증이 있는 기업만 사용가능한 방법입니다.
결론
- 실시간으로 GPT를 call해서 면접 질문을 얻는 것보단, 미리 질문을 GPT로 생성한 후, 검수해서 질문을 미리 만들어 놓는게 좋다. => 질문의 퀄리티 향상, 질문 개수 확정 가능
- GPT는 데이터 구축, 연관 질문 생성에만 활용하자. 실시간 면접 질문 생성, 평가, 채점은 GPT로는 한계가 있으며, 성능 상 문제도 많음. => GPT 의존도 최소화
- GPT 의존도 최소화, 프로토타입 개발이 아닌 고도화 및 유지보수 방향 => 서버 개발은 지원하는 기능이 많으며 더 친숙한 스프링 선택. 데이터 구축에만 파이썬 활용.
