
작은 오해가 만든 큰 비효율
토스에서 계좌를 연결할 때 앞으로 토스로 돈을 받고, 보내는 서비스를 사용할 것이라는 출금이체 동의를 해요. 그럼 은행에서 자동으로 문자가 오는데요. 
처음엔 아무 문제가 없을 것 같았지만, 은행 문자 속 '자동이체'라는 단어가 사용자에게 혼란을 줄 수 있다는 사실을 알게 됐어요. 사용자는 이 단어를 보고 "내 돈이 정기적으로 빠져나가는 건가?"라는 걱정을 하게 되죠. 사실 이 문자는 단순한 확인 절차일 뿐인데도, 사용자 입장에선 이 작은 단어 하나가 큰 불안으로 이어질 수 있었어요.
이 작은 오해 때문에 고객센터로 들어오는 문의가 급증했어요. 대부분은 "자동이체가 시작되는 건가요?"라는 질문이었죠. 사용자가 오해하지 않고, 토스 서비스를 편리하게 이용할 수 있도록 이 문제를 해결해야 했어요. 특히, 2019년부터 고객 문의 상위 3위 안에 들면서, 토스팀원들이 같은 안내를 반복해야 하는 비효율적인 상황이 계속되고 있었죠.



문제를 해결하는데 
프로덕트 디자이너가 아니고, 
플랫폼 디자이너가 한다고?
보통은 제품의 문제를 프로덕트 디자이너가 해결하지만, 이번엔 플랫폼 디자이너가 나섰어요. 플랫폼 디자이너는 디자인시스템만 만드는 게 아니라, 서비스 전반을 살피고 비효율을 찾아서 해결하는 데 중점을 둡니다. 이는 사용자뿐만 아니라, 토스 팀 전체가 효율적으로 일할 수 있도록 돕는 역할을 해요. 
토스팀원들의 비효율을 줄여주고, 사용자들에게 안심 경험을 줄 수 있는 화면으로 개선하기로 했어요.




문제 해결 과정

지금 보는 이 화면은 기존에 계좌 연결 후 보게 되는 화면이에요. 
이정도면 문자가 왔을 때 문자가 갈거라고 미리 안내도 해주고, 문자 내용을 보고 놀라지 말라고 해서 괜찮은 것 같은데 사용자들이 '자동이체'라는 단어에 왜 민감하게 반응하는지를 파악해야 했죠. 





1. 가장 먼저, 있는 그대로를 말하기
첫 번째로 중요했던 것은 사용자의 감정을 먼저 추측하기보다는, 사실 그대로를 전달하는 것이었어요. 토스는 따뜻하고 친근한 말투를 많이 쓰는데, 처음부터 '은행에서 문자가 와도 놀라지 마세요'라는 표현을 하면 오히려 사용자에게 불필요한 걱정을 줄 수 있었어요. 그래서 이번에는 사실 그대로를 전달하기로 했어요. "OO님이 출금이체 동의를 한 몇 개의 은행에서 문자가 발송될 것"이라고요.




2. 어려운 말은 더 자세하게 말하기
다음으로는 ‘자동이체’라는 단어를 쓰면서 더 친절하고 구체적으로 설명했어요. 그리고 감정에 대한 이야기를 했어요. ‘자동이체’ 라는 단어가 사용자에게 불필요한 걱정을 주고 있었기 때문에, 좀 더 명확하고 안전한 느낌을 주는 문구를 추가했죠. "이건 자동으로 돈이 빠져나가는 게 아니에요. 당신의 돈은 안전해요!"라고 말이죠. 또한, 자동이체가 무엇을 의미하는지도 상세히 설명했어요.
토스에서는 퍼널의 길이가 짧을수록 좋다는 러닝이 있었지만, 이번엔 그 러닝을 넘어 사용자에게 더 자세히 알려주는 것이 필요하다고 판단했어요. 내 돈이 빠져나갈 수도 있다는 불안을 안심시킬때는 너무 축약하기보다는, 사용자가 완전히 이해할 수 있도록 상세히 전달하는 것이 중요하다고 생각했거든요. 




3. 중간에 문자가 와도 다 읽을 수 있게 하기
마지막으로 문자 도착 시간에 집중했어요. 은행에서 문자가 발송되는 데는 최소 2초에서 최대 15분까지 걸릴 수 있어요. 사용자가 안내 화면을 보고 있는 동안 문자가 도착하면, 화면 상단에 푸시 알림이 안내 내용을 가려버리기 때문에 사용자가 내용을 볼 수 없어요. 그래서 제목과 전체 내용을 아래로 조금 내려서 문자메세지가 와도 끊김 없이 모든 내용을 볼 수 있는 디테일을 추가했어요.





결과와 배운 점
이렇게 만든 디자인을 바로 구현해서 문의량을 측정해기로 했어요. 
그 결과는 놀라웠어요. 이전에는 월평균 3,173건이던 문의가 무려 446건으로 줄어들었죠. 이 숫자는 단순한 통계 이상의 의미를 가지고 있어요. 플랫폼 디자이너가 토스팀의 효율성을 높이는 데 얼마나 큰 기여를 할 수 있는지 보여주는 사례였어요. 
마지막으로, 사용자에게 신뢰를 줄 수 있는 디자인이야말로 가장 중요한 디자인이라는 점을 강조하고 싶어요. 때로는 설명이 조금 길어지더라도 사용자가 충분히 이해할 수 있게 하는 것이 중요해요. 감정을 먼저 읽기보다는 사실 그대로를 전해주는 것이 가장 첫번째로 알려줘야 큰 안심을 줄 수 있고, 그 결과 서비스 전체에 긍정적인 영향을 미칠 수 있답니다.






작은 오해가 만든 큰 비효율
토스에서 계좌를 연결할 때 앞으로 토스로 돈을 받고, 보내는 서비스를 사용할 것이라는 출금이체 동의를 해요. 그럼 은행에서 자동으로 문자가 오는데요. 
처음엔 아무 문제가 없을 것 같았지만, 은행 문자 속 '자동이체'라는 단어가 사용자에게 혼란을 줄 수 있다는 사실을 알게 됐어요. 사용자는 

플랫폼 디자이너가 고객문의량 상위 3위에 들었던 비효율 문제를 해결했던 방법을 알려드릴게요.

비효율이 있는 곳엔 플랫폼 디자이너가 있다 

배경
토스 디자인 시스템에서 가장 많이 사용하는 컴포넌트는 테이블이에요. 테이블은 크게 두 가지를 고려해야 하는 복잡한 컴포넌트예요. 테이블을 구성하는 최소 단위인 셀, 그 셀들을 합쳐 만든 표. 각각을 사용하는 경우의 수를 고려하면 구현 난이도는 무한대로 높아져요. 
우리가 흔히 표를 만들 때 쓰는 엑셀은 말 그대로 표를 만들기 위해 만들어진 에디터 솔루션이기 때문에, 셀과 표를 처음부터 고려해서 만들어졌어요. 하지만 우리가 사용하는 대개의 디자인 에디터 툴들은 테이블 만을 위해 만들어진 솔루션이 아니기 때문에 컴포넌트 기능과, 테이블 제작 사용성 두가지 모두를 한번에 고려하여 반영 하는데에 한계가 있습니다. 그래서 토스의 초기 테이블은 (이하 테이블 1.0) 최소 구성 단위인 셀 형태의 컴포넌트로 구성되어 있었어요.


문제
테이블 컴포넌트는 표를 구성하는 작은 단위의 셀을 의미 하기도 하고. 큰 덩어리인 표 단위를 의미하기도 해요. 
TDS의 테이블 컴포넌트 역시 이를 모두 커버하기 위해 셀 단위의 기능과, 표 단위의 제작 사용성 솔루션이 필요로 했어요. 토스 팀에서는 제품에서 사용하는 형태에 따라 테이블 컴포넌트가 가지고 있어야 할 기능과 요구 되는 사항들은 천차만별로 달라서 여기에 다 쓸 수 없을 정도로 다양한 케이스를 다뤄야 했죠. 저희 팀은 그런 셀의 경험을 개선하는 것만으로도 정신이 없었어요. 


이렇게 셀의 기능이 대부분 채워갈 무렵, 자연스럽게 표 제작에 대한 사용성 관련한 문제들이 수면 위로 드러나기 시작 했어요. 테이블을 구성하는 최소 구성단위인 셀 기능만 포함 된 컴포넌트로 패턴 단위의 표를 만드려면 이런 과정을 거쳐야 했어요. 





우리는 이미 표를 만들기 위해 사용하는 엑셀과 같은 툴에 익숙해져있으니, 보기만 해도 너무 불편하다는 걸 느끼실 거예요. 실제로 PC 화면을 디자인하는 분들도 많은 피드백을 주셨고요.
👤 테이블을 내가 왜 이렇게 만들어야 하나…
👤 하나하나 쌓아 만드는거 너무 짜친다… 현타 온다
👤 다 모르겠고 누가 만들어 놓은거 복붙 해서 쓰는게 편해요


가설
하지만 앞에서 말씀 드렸듯이, 디자인 툴은 테이블을 만들기 위해 제작 된 에디터가 아니기 때문에 문제를 해결 하는데에는 기술적인 한계가 존재 했어요. 그래서 처음에는 지금 메이커들이 겪고 있는 문제 중 치명적인 비효율을 만드는 요소들을 제거 하는 것 부터 시작하자! 하고 반복되는 문제 패턴을 찾았죠. 예를 들면 이런 것들이 있었어요.
간단한 표를 구성하기 위해 필요한 툴과 관련된 사전 지식들
fixed ↔ fill ↔ fit-content
표를 만들고 난 후에도 필요에 따라 잦은 데이터 수정이 필요한 컴포넌트의 특수성
각 셀 마다 가지고 있는 패널 설정을 찾아 수정하는 과정이 번거로움 
열, 행 구성에 따라 제작 된 표는 추후 수정이 어려움

위와 같은 문제들을 테이블 베타라는 이름의 솔루션으로 개선하고 난 후, 단순한 리스트형 테이블을 쉽게 만들 수 있게 되었지만 아무리 이전보다 나아졌다고 해도, 툴에 종속되어 해결 된 솔루션이라 매우 제한적인 해결방법으로 도출 되어 제작 사용성을 완전히 해결했다고 보기 어려웠어요. 여전히 테이블 만을 위해 제작 된 솔루션들의 경험과 비교하여 생각한다면 불편하다고 생각할 수 밖에 없었죠.
이제는 컴포넌트의 경험을 개선하는 것을 넘어서, 디자이너분들이 실제로 어떻게 사용하는지 과정 전체에 대한 이야기를 듣고, 본질적인 사용 방식을 개선해야 겠다는 생각이 들었어요. 그래서 작업 방향을 잡기 위해 디자이너분들을 찾아가 심층 인터뷰를 하면서 테이블을 사용하시는 행태를 꼼꼼하게 조사했어요. 
이를 위해 가용 가능한 개발 리소스를 확보하고 설문+UT를 통해 3가지 방향성을 도출 했어요.

제로 베이스의 제작을 하지 않아도 되게 만든다
표 자체를 완성하는 환경을 쉽게 한다
잦은 수정이 일어나는 상태를 쉽게 수정하게 한다



UT, POC를 통해 차츰 방향성을 잡아 가면서 메이커들과 이격을 줄이는 작업들이 병행 되었어요. 


이렇게 정밀 진단을 통해 꼭 해결해야하는 큰 맥락을 설정해보니, 툴의 한계를 벗어나 빌더 수준의 완전히 새로운 형태의 제작이 필요하다는 판단을 하게 되었어요. 문제 해결의 한계를 만들고 있는 툴의 환경을 벗어나 사고 하고 해결책을 찾아야겠다 생각 했죠. 하지만 툴을 벗어나 해결책을 찾더라도 결국 툴 내부에 솔루션을 심어야 했기 때문에 완전히 환경을 벗어나긴 어려웠고 이에 우리는 크롬 플러그인을 활용하여 프레이머라는 툴 내에 붙여 활용 할 수 있는 방법을 찾아 활용해 보게 되었어요.



해결책
컴포넌트 단위의 솔루션이 아닌 에디터를 만드는 수준의 솔루션을 설계해야 하는 상황이었지만 완전히 바닥부터 시작하기엔 우리에게 주어진 시간이 많지 않았기 때문에 리소스를 효율적으로 쓰는 것이 가장 중요했어요.

메이커 리소스 및 물리적인 작업 환경 확보하기
한명의 개발자로 문의 대응과 테이블 혁신까지 이뤄내야 했기 때문에 응급 상황 제외 문의 최대한 손 떼고, UXE Assistant + Platform designer 조합으로 개발 구조체를 변경하지 않는 선의 간단한 대응을 모두 위임하는 등 한명의 개발자로 테이블 2.0을 만들어야 하는 상황에 필요한 물리적인 환경을 구축 하는데 신경 썼어요.

빠르게 도달 할 수 있는 방법 시도 하기
문제를 해결 하기 위해 방향성이 설정 되었다면 이제 달려나가야겠죠? 제로 베이스에서 시작하기에 리소스 및 시간이 턱 없이 부족 하다면 기반이 되어줄 타 제품을 찾아보고 무료 소스를 적극 차용하는 것도 좋은 방법이 될 수 있어요. 테이블만을 고민하고 솔루션을 구축해온 AG grid 라는 제품을 차용해 유료 기능을 제외한 무료 기능들을 가져와 뼈대를 만들고, 이후 필요한 기능들을 직접 개발 하면서 2.0의 모습을 갖춰나갔어요. 토스에서 필요한 기능들과 프레이머라는 환경을 고려해야 했기에 거의 새로 만드는 수준 이었지만 AG grid를 통한 뼈대를 구축하는 과정이 문제 해결 속도를 높이는데 큰 도움이 되었어요.


빠르게 검증하기
테이블 베타를 통해 성공적인 임팩트를 도모하지 못했던 것은 제작 과정에서의 검증을 놓쳤기 때문이라 생각했기 때문에 주어진 기간이 매우 짧아 검증할 시간이 충분하지 않더라도 실패를 줄이기 위해서는 무조건 진행하기로 했어요. 주 단위로 스프린트를 구성하여 스펙 구현 과 메이커 UT를 동시에 진행 하면서 제품을 실시간으로 깎아 나갔어요. 이 과정에는 한몸이 된 것처럼 밀도 있는 커뮤니케이션이 필수적이에요. 이 과정들을 통해 해결 해야하는 문제가 클 수록 투자 해야할 시간이 길어져 자칫 늘어질 수 있는 호흡을 잡아주는 역할도 할 수 있어요.




결과
그렇게 충분하지 않았던 리소스로 엄청난 효율을 추구하며 만들어낸 결과, 테이블 1.0과 비교했을 때 완전히 다른 방법으로 개선된 2.0이 나왔죠. 테이블2.0은 표 제작 및 생성 하는데 필요한 사용성을 개선 대부분 개선 할 수 있었어요. 특히 잦은 벨류 수정이 필요했던 케이스를 대응 할 수 있어 큰 반응이 있었어요. 
첫 배포 이후에도 필요로한 추가 기능들을 지속적으로 배포 하면서 테이블을 제작하는데 필요로한 기능들을 대응 했어요.










PD분들의 반응도 열광적이었어요.





적용해보기
문제의 근원을 해결하기 위해 시도했던 다양한 시도들을 통해 우리는 아래와 같은 러닝을 얻게 되었어요.
Question every assumption : 근본적인 해결을 위해 다시 사고하는 과정이 느려보여도 가장 빠른 해결책이 될 수 있어요
특히 시스템 관련해서 컴포넌트와 관련한 문제를 마주 하다보면 당장 산재한 문제들을 빠르게 해결하기 위해 정신 없이 1:1 대응 형태로 문제 해결을 하게 되는데요. 느리더라도 문제를 해결 하기 위해 근원적인 물음들을 제기 하면서 근본적인 문제를 해결을 위한 사고 과정에 시간을 투자 해보세요. 이 문제가 진짜 문제인지, 이 해결 방법으로 해결 할 수 있는 문제는 무엇인지 등 당연 했다고 생각한 것들에 질문하고 처음부터 다시 사고 하는 과정을 거치다 보면 근본의 가정까지 파고들어가 사고 할 수 있어요. 이렇게 느리지만 가장 빠른 해결책을 찾는 과정을 통해 여러 문제를 혁신적으로 해결 할 수 있을거에요. 한번의 시도에 완벽한 해결을 만들 수 없기 때문에 이 과정을 반복하는 것을 추천 드려요. 
Ask for feedback : 성장하는 시스템은 주요 원동력은 피드백이다
잘 만들어진 시스템은 잘 사용 되는 시스템이에요. 그렇기 때문에 메이커들의 솔직하고 주기적인 피드백이 중요해요. 시스템은 이를 사용하는 메이커들의 피드백을 통해 성장하고 고도화 되는 성장형 솔루션이어야 합니다. 때문에 우리는 시스템을 제작 하는 과정도 중요 하지만 의도 한대로 잘 작동 하고 있는지 지속적인 트래킹 하는 과정을 필수로 진행하고 있어요. 
사용자가 늘 적극적으로 피드백을 주지 않을 때에는 시스템이 의도대로 잘 작동하고 있구나 안심하지 말고 직접 찾아 다니면서 집착적으로 피드백 받고 문제를 발굴 하는 것도 중요해요. 시스템을 만드는 과정이 벅차서 이 부분을 놓치게 되면 언젠가 눈덩이처럼 커져버린 문제를 마주하게 될지도 몰라요. 
Focus on Impact : 혁신적인 임팩트를 생산 하기 위한 집중과 물리적인 확보는 반드시 필요하다
해야할 일은 사라지지 않고 문제는 늘 많은데 어떻게 혁신적인 임팩트를 생산 할 수 있을까요? 모든 문제를 해결 할 수 없다는 것을 인지하고 해결 하고자 하는 문제에 집중하여 몰입하는 과감한 투자가 필요해요. PC 시스템 팀에서는 PC TDS가 해결해야 하는 문제들 중 테이블과 관련한 문제가 가장 큰 이슈이자 풀기 어려운 숙제라고 판단했고, 2.0 이라는 솔루션을 만들어내기 위해서 매일 대응 하고 있는 시스템 운영 및 대응, 신규 컴포넌트 생산과 같은 업무를 줄여 리소스를 물리적으로 확보 하고자 했어요. 
완전히 끊어내고 몰입할수 있는 환경이라면 가장 좋겠지만, 시스템 팀은 토스 전 조직 대상으로 움직이는 팀이기 때문에 완전히 업무를 중단하기 어려웠어요. 하지만 테이블2.0을 만들어 내려면 리소스 확보가 꼭 필요했습니다 개발자가 1명 이었으니까요. 어려운 환경에 있더라도 방법은 어떤 형태로든 찾을 수 있습니다. 많은 일을 한꺼번에 처리하긴 어려워요. 집중 할 수 있는 환경과 기간을 설정하고 과감한 시도를 통해 문제를 해결 해보세요!

눈 앞의 문제들을 해결했음에도 여전히 불편함이 남아있다면, 본질적인 문제를 다룰 수 없을지 확인해보세요. 너무 당연했던 전제를 바꿀 수 있다고 상상해보면 완전히 다른 해결책이 떠오를 거예요.



배경
토스 디자인 시스템에서 가장 많이 사용하는 컴포넌트는 테이블이에요. 테이블은 크게 두 가지를 고려해야 하는 복잡한 컴포넌트예요. 테이블을 구성하는 최소 단위인 셀, 그 셀들을 합쳐 만든 표. 각각을 사용하는 경우의 수를 고려하면 구현 난이도는 무한대로 높아져요. 
우리가 흔히 표를 만들 때 쓰는 엑셀은 말 그대로 표

토스 디자인 시스템에서 가장 많이 사용하는 컴포넌트인 테이블 컴포넌트. 문제의 근원을 해결하기 위해 시도했던 다양한 시도와 러닝을 소개합니다.

문제의 근원을 해결 하기 위한 다양한 시도


저번 아티클에서 메뉴 컴포넌트 추가를 위해 가설을 세우고 실험했던 과정을 소개해 드렸어요. 이 방법으로 유용성이 검증되어 빠르게 새 컴포넌트를 결정해 출시할 수 있었답니다.
1편 보고 오기 >

문제
그러나 점차 새 컴포넌트가 대응할 수 없는 케이스들이 발견 되기 시작했어요. 컴포넌트를 사용할 수 있게 된 뒤 많은 디자

디자인 시스템은 제품의 어느 단계까지 기여할 수 있을까요? 더 이상 다른 것에는 신경쓰지 않아도 되는 Menu 컴포넌트를 만들었던 3가지 방법을 소개할게요.

토스 디자이너가 제품에만 집중할 수 있는 방법



이 화면은 토스 앱에서 여러 가지 옵션을 선택하는 방식이었어요.
어떤 문제가 있는지 느껴지시나요?
1️⃣ 잘 모르겠다.
2️⃣ 알 것 같다.

1번, 2번, 선택 안 하신 모든 분들! 어떤 문제가 있는지 알려드릴게요. 



바로 ‘물리적 거리 사용성’인데요
화면 위에서 버튼을 누른 후 아래에서 올라오는 바텀시트의 버

플랫폼 디자이너가 디자인 시스템에 새로운 컴포넌트를 만들 때 생기는 의심을 확신으로 만든 과정을 들려드릴게요.

이런 것도 컴포넌트로 만들어도 될까?

토스에는 디자인 플랫폼 팀이 있고, 그 안에 플랫폼 디자이너라는 직군이 있어요. 플랫폼 디자이너는 무슨 방법을 써서라도 메이커의 디자인 작업 과정의 비효율을 효율화하는 사람이에요. 디자인 시스템을 만들기도 하고, 디자인 툴을 바꾸기도 했죠.
오늘 소개해드릴 프로젝트는 툴을 바꾸면서 새로운 환경에 맞게 작업 과정을 효율화했

수많은 가짓수들을 단순히 더하기로 추가하는 것이 아니라 곱하기로 확장하면서 극단적인 효율과 심미성까지 챙겼던 과정들을 플로우차트 제작 프로젝트를 예시로 소개해드릴게요.

플랫폼 디자이너가 효율을 만들어내는 법



토스 채용 꿀팁, 면접관들이 직접 말합니다!
 "Next.js, 단순 사용 경험이 아니라 '왜' 사용했는지가 중요하다?"
 "이력서와 면접에서 어떤 점을 강조해야 할까요?"
 "Github 커밋 잔디 심기, 기술 블로그 TIL 작성보다 더 중요한 것이 있다고?"
토스의 문동욱 님과 이성준 님이 채용 과정에 대한 솔직한 이야기부터 실질적인 꿀팁까지, 지원한다면 꼭 알아야 할 정보를 모두 모았습니다. 절대 놓치지 마세요!

타임스탬프
00:00 인트로
00:50 기술 스택, 단순 사용 경험이 아닌 ‘왜’를 강조하라
03:55 Github 활동, 잔디 심기보다 '이것'을 확인합니다
06:34 '이 사람을 뽑아야겠다!' 생각이 든 순간은!?
10:19 개발자는 기술 블로그가 있어야 된다?
14:07 재지원? 오히려 그릿(Grit)의 신호일지도

출연진
박서진, 토스 Head of Frontend
문동욱, 토스 Frontend Developer
이성준, 토스 Frontend Developer

다른 모닥불 회차 보러가기
EP.5 토스 개발자는 개발만 잘해도 될까?
EP.6 프론트엔드 개발에서 Next.js, 꼭 써야 할까?
EP.7 개발자 리더로서 성장당한 썰




토스 채용 꿀팁, 면접관들이 직접 말합니다!
 "Next.js, 단순 사용 경험이 아니라 '왜' 사용했는지가 중요하다?"
 "이력서와 면접에서 어떤 점을 강조해야 할까요?"
 "Github 커밋 잔디 심기, 기술 블로그 TIL 작성보다 더 중요한 것이 있다고?"
토스의 문동욱 님과 이성준 님이 채용 과정에 대한 솔직한

토스 채용 꿀팁, 면접관들이 직접 말합니다!

토스의 문동욱 님과 이성준 님이 채용 과정에 대한 솔직한 이야기부터 실질적인 꿀팁까지, 지원한다면 꼭 알아야 할 정보를 모두 모았습니다. 절대 놓치지 마세요!

Next.js 그만 쓰세요! 면접관이 진짜 원하는 것!? | 모닥불 EP.8

요즘은 LLM(Large Language Model)의 시대입니다. 2022년에 ChatGPT가 처음 서비스된 이후로, 하루가 다르게 더 빠르고, 더 정확하고, 심지어 이미지나 비디오, 음성 등을 이해하고 생성하는 모델들이 등장하고 있습니다. 아래 그림처럼, 2024년 들어서 상용 LLM과 오픈소스 LLM이 경쟁적으로 등장하며, 시장을 빠르게 변화시키고 있습니다.


토스증권 역시 이런 흐름에 발맞춰, LLM을 활용한 서비스 혁신에 적극 나서고 있습니다. 투자 데이터를 이해하고 고객들에게 보다 나은 금융 서비스를 제공하기 위해, 우리는 자체적으로 LLM 모델을 학습시키고 이를 서비스에 적용하려는 데 집중하고 있습니다.
구슬이 서 말이라도 꿰어야 보배라는 말처럼, 좋은 LLM을 학습시키는 것도 중요하지만 이걸 서비스에 적용하지 못하면 큰 의미가 없습니다. 하지만 일정 수준의 이상의 성능을 지원하는 LLM을 서비스에 적용할 때 크게 두 가지의 어려움이 있습니다.
첫 번째는 속도의 문제입니다. 중간 사이즈의 LLM인 Llama3 8B 모델을 일반적인 Transformers 패키지를 사용해서 추론하면, 단순한 질문에도 수십 초씩 기다려야 합니다. 따라서, 서비스에 적용할 만큼의 성능을 확보하기 위해서 추론 속도를 빠르게 만들 필요가 있습니다.
두 번째는 사용성의 문제입니다. 어떤 모델이 우리 서비스에 더 적합한지 판단하려면, 다양한 모델을 서비스에 적용하면서 각기 다른 상황에 맞게 테스트해야 합니다. 하지만 학습된 모델을 서빙하기 위해서 개발자는 많은 정보를 알아야 됩니다. 예를 들어, 모델 코드를 컨테이너화하기 위해 필요한 Docker 이미지 빌드 방법이나, 서버를 Kubernetes에 배포하기 위해 필요한 manifest 작성법 등이 있습니다. 이런 허들 때문에 여러 모델을 서빙해서 A/B 테스트로 비교하기 어렵습니다.
이번 아티클에서는 토스증권이 어떻게 LLM의 추론 속도, 모델 서빙 방법을 더 효율적으로 개선했는지 알려드리겠습니다.

문제 1. LLM을 우리 인프라에서 그냥 돌리면 너무 느려요
ChatGPT, Claude, Gemini 등 다양한 LLM 서비스를 사용해보셨나요? 이런 서비스는 속도가 상당히 빠릅니다. 특히 최신 모델들은 그 성능도 대단하지만, 2~3 문단으로 구성된 긴 글을 쓰는데 수 초 정도면 충분합니다. 하지만, 그에 준하는 성능을 보인다고 알려진 Llama3 70B, Mixtral 8x22B 등의 모델들을 써보면, GPU를 사용하더라도 비슷한 양의 토큰을 생성하는 데 수 분, 길게는 수십 분이 걸리는 경우도 있습니다.
이런 모델들이 느린 이유는 autoregressive 모델의 특성 때문입니다. Autoregressive 모델이란, 이전 모델의 결과물을 입력으로 이용해서 다음 모델 결과를 생성하는 모델을 의미합니다. 즉, 각각의 토큰을 순차적으로 생성해야 하기 때문에 속도가 느립니다. 예를 들어, 안녕하세요. 토스 테크 블로그입니다. 라는 문장은, 안녕하세요. -> 토스 -> 테크 -> 블로그입니다.  라는 순서대로 생성합니다.

이런 본질적인 구조를 개선할 수는 없지만, cache를 이용해서 속도를 빠르게 만들 수 있습니다. LLM 학습에는 Key-value cache(KV cache)를 사용하는데요, 일반적인 캐시와 동일하게 중복 계산을 줄이는 방법입니다. Transformer의 구조상 여태까지 입력으로 들어온 토큰들을 이용해서 self attention을 구성합니다. 위의 예제에서, 테크 라는 단어를 생성할 때 필요한 attention의 key와 value는 안녕하세요. 와 토스 입니다. 블로그입니다. 라는 단어를 생성할 때 필요한 토큰은 안녕하세요. , 토스, 테크 입니다.
앞의 두 토큰이 겹치기 때문에, 이 토큰을 가지고 계산해 둔 attention은 캐싱해서 계산량을 줄일 수 있습니다. 이를 KV cache라고 하며, 이를 통해 추론 속도를 O(n^3) → O(n^2)까지 개선할 수 있습니다. 추가적으로, KV cache를 조금 더 메모리 효율적으로 하는 paged KV cache나, CUDA를 더 효율적으로 사용하는 kernel fusion과 같은 방법들이 있습니다.
이런 다양한 개념들을 적용해서, 추론 속도를 빠르게 해주는 tensorrt-llm, vllm, lmdeploy, tgi 등 오픈소스가 여럿 있습니다. 이들 중 어떤 것이든 사용하면, 기존의 transformers 패키지를 그대로 사용했을 때보다 체감상 훨씬 빠른데요, 우리에게 가장 적합한 오픈소스를 어떻게 찾을까요?
오픈소스를 비교할 때 토스증권은 크게 세 가지 항목을 고려했습니다: 정량적 지표, 사용성, 지원하는 모델 종류. 이런 지표를 고려해서 토스증권의 상황에 가장 맞는 오픈소스를 선택했습니다. 각 항목에 대한 자세한 설명은 아래를 참고해주세요.
정량적 지표
Token per Second (TPS). 초당 토큰 생성 숫자로, generative model 특성상 매 요청마다 생성해야 하는 토큰의 숫자가 매우 다릅니다. 따라서 초당 request 처리 숫자는 변동성이 커서 정확한 비교가 어렵고, 비교 가능한 단위인 토큰 숫자로 비교했습니다.
Time to First Token (TTFT). 첫 번째 토큰이 생성되기까지 걸리는 시간(초)입니다. 일반적으로 GPU inference를 할 때에는 warm-up 시간이 있어서 첫 토큰을 생성하는 게 오래 걸립니다. 이 지표를 통해, 각 프레임워크 별로 warm-up 시간을 얼마나 단축시켰는지 측정합니다.
사용성
학습한 모델을 얼마나 적은 단계로 서빙까지 할 수 있는지를 의미합니다. 예를 들어, ONNX와 같이 컴파일 과정을 거쳐야 하는 것은 사용성이 좋지 않다고 판단했습니다.
지원하는 모델 종류
자주 사용되는 LLM architecture를 지원하는지를 확인했습니다. 흔히 pretrained 모델로 자주 채용되는 Llama, Gemma, Mixtral, Qwen 등을 모두 지원하는지 평가했습니다.



위 표는 토스증권에서 직접 각 오픈소스를 실험한 결과입니다. 여러 아키텍처에 대해서 테스트해봤을 때, 종합적으로 정량적 지표 면에서 빠른 편에 속하면서, 사용성도 편하고, 다양한 모델을 지원하는 vllm을 선택했습니다.
또한 vllm을 서빙할 프레임워크로는 Triton Inference Server(TIS)를 선택했는데요. 가장 범용적으로 많이 사용되고 dynamic batching, continuous batching 등 throughput을 올려줄 수 있는 다양한 기능도 제공해주기 때문입니다. 또한, vllm을 사용하기 위한 backend도 직접 오픈소스로 제공하는 장점이 있습니다.
적합한 오픈소스를 찾고 적용하면 LLM의 추론 속도를 큰 폭으로 높일 수 있습니다. 하지만, 여전히 이 모델을 서비스로 만들기까지는 여러 난관이 가로막고 있습니다. 다음 단락에서, 어떻게 하면 모델을 쉽게 서빙하고 운영할 수 있는지 설명드릴게요.

문제 2. K8S에서 서버를 띄우는 것이 어려워요
토스증권에서는 Kubernetes(K8s)라는 오픈소스 플랫폼을 이용해서 여러 서비스들을 관리하고 있습니다. LLM도 예외는 아닌데요. K8s가 매우 편리하고 다양한 장점이 있는 도구임은 사실이지만 처음 접하는 사용자는 배워야할 것들이 상당히 많습니다.
예를 들어, 단순히 hello world를 출력하는 간단한 서버를 띄울 때에도, 배포용 Helm Charts를 작성해야 합니다. 여기에는 서버 코드가 들어있는 Docker 이미지와, 이를 실행시키는 데 필요한 명령어가 들어있는 deployment, 외부에서 서버로 트래픽을 연결시키는 virtualservice, service 등 여러 파일(manifest)들이 필요하며, 각각에 대해서 어느 정도 이해해야 합니다.
게다가 토스증권에서 선택한 vllm과 이를 잘 띄워주는 Triton을 사용하려면 더 많은 지식과 경험이 필요합니다. 모델을 vllm + Triton에서 구동할 수 있게 필요한 서버 코드, 생성 모델을 실행할 때 필요한 configuration(사용할 KV cache의 크기, GPU의 숫자, 모델이 생성 가능한 최대 길이 등) 등을 정의해주어야 하며, 이런 코드를 Docker 이미지로 빌드할 수 있어야 합니다.
즉, 하나의 모델을 잘 학습했더라도 실제 서비스로 내보내기 위해서는 모델뿐만 아니라 vllm, Triton, Docker, K8s에 대한 전반적인 지식이 필요한 셈이죠. 특히나, 모델을 적용할 서비스와 모델러의 숫자가 늘어날수록 이런 학습 비용은 더더욱 증가하게 됩니다.
전체적인 배포 플로우를 도식화하면 아래와 같은데요. 먼저 LLM inference 코드를 작성하고, 이를 Docker 이미지로 빌드합니다. 그리고 서버 구동에 필요한 yaml 파일들을 작성한 뒤, ArgoCD라는 툴을 이용해서 K8s에 배포합니다.

토스증권에서는 이 문제를 각각 나눠서 해결했습니다. 공통화된 라이브러리와 코드를 작성해서 여러 서비스가 하나의 Docker 이미지를 공유하게 구성했고, 이전과 다르게 K8s, Helm Charts, ArgoCD에 대한 지식이 거의 없더라고 쉽게 모델을 서빙할 수 있게 배포 과정을 개선했습니다.
먼저 LLM Inference 코드는 Triton에서 제공해주는 vllm_backends라는 오픈소스를 활용했습니다. vllm의 구성(configuration)과 모델 경로를 단 하나의 파일로 정의하면, Triton 서버에서 간단히 실행할 수 있게 돕습니다. 
이를 바탕으로, 토스증권의 인프라에 맞도록 model registry를 구성하고, 필요한 configuration를 변수화해서, 하나의 Docker 이미지를 여러 서비스가 공유할 수 있도록 최적화했습니다. 이제 모델러들이 별도의 Docker 이미지를 빌드하지 않고도,다양한 모델, 다양한 구성으로 LLM 서버를 구동할 수 있습니다. 
마지막으로 저희 팀에서는 Kserve라는 패키지를 도입해서 배포 과정을 더욱 간소화했습니다. Kserve는 Kubeflow 위에 올라가는 서버리스 플랫폼으로, 머신러닝 모델을 쉽게 배포하고 관리할 수 있게 도와줍니다. 이로써 복잡한 MLOps 작업 없이, 모델러들이 yaml 파일 하나만 작성하면 서비스를 배포할 수 있게 만들었습니다. 
여기까지 해서, LLM 서버를 띄우는 과정이 간소화되었습니다. 기존처럼 MLOps 지식이 필요하거나, 많은 단계를 거쳐야 하지 않고, 아래와 같은 형태의 yaml만 작성하면 모델을 서빙할 수 있는 형태로 바뀌었습니다. 학습시킨 모델의 이름을 넣어주고, 몇 가지 configuration(GPU 몇 개 사용할지 등)을 입력해서 yaml 파일을 만든 뒤, 이걸 제출하면 바로 서버를 띄울 수 있습니다.
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: huggingface-llama3
spec:
  predictor:
    volumes:
      - name: shmdir
        emptyDir:
          medium: Memory
          sizeLimit: "64G"
    triton:
      name: triton-vllm
      image: PRIVATE_IMAGE  # 공용으로 사용하는 Docker 이미지
      command:
        - ./SOME_SCRIPT.sh meta-llama/Meta-Llama-3-8B-Instruct  # configuration (모델 명 등)
      volumeMounts:
        - mountPath: /dev/shm
          name: shmdir
      resources:
        requests:
          nvidia.com/gpu: "1"  # 사용하고자 하는 자원 (gpu 숫자)

이제 서버를 띄웠으니, 내가 만든 서버가 잘 동작하는지, latency나 throughput이 줄어드는지 등을 체크해봐야합니다. Kserve + Triton을 사용하면 정형화된 형태로 로그를 남기기 때문에, 별다른 노력 없이 대시보드에 새로 생성된 서버를 추가할 수 있습니다. 
아래 그림처럼, TPS나 latency를 그라파나에서 시각적으로 확인이 가능하며, 알림 설정도 쉽게 해서 오류가 발생했을 때 즉각적으로 대처할 수 있습니다.






이제 새로운 pretrained 모델이 나오거나, 간단하게 학습해 본 모델을 쉽게 서빙해서 테스트할 수 있는 환경이 갖춰졌습니다. 이를 통해서, 기존에는 쉽게 하기 힘들었던 Llama 70B와 우리 모델의 성능 벤치마크도 가능해졌고, 큰 모델을 이용해서 양질의 데이터 구축도 쉽게 할 수 있게 되었습니다.
LLM 기술은 단순히 더 나은 모델을 만드는 것을 넘어, 실제 서비스에 어떻게 연결하느냐에 따라 그 가치가 결정됩니다. 토스증권의 사례는 이러한 기술적 과제를 실용적으로 풀어나가는 다양한 방향성 중에 하나입니다. 여러분도 자신만의 환경과 목표에 맞는 최적의 방법을 찾아가며, LLM의 가능성을 확장해 나가길 바랍니다.



요즘은 LLM(Large Language Model)의 시대입니다. 2022년에 ChatGPT가 처음 서비스된 이후로, 하루가 다르게 더 빠르고, 더 정확하고, 심지어 이미지나 비디오, 음성 등을 이해하고 생성하는 모델들이 등장하고 있습니다. 아래 그림처럼, 2024년 들어서 상용 LLM과 오픈소스 LLM이 경쟁적으로 등

구슬이 서 말이어도 꿰어야 보배라는 말처럼 좋은 LLM을 학습시키는 것도 중요하지만, 이걸 서비스에 적용하지 못하면 큰 의미가 없습니다. 하지만, 어느정도의 성능 이상을 지원하는 LLM을 서비스에 적용하는 것은 크게 두 가지의 어려움을 가지고 있습니다.

LLM 쉽고 빠르게 서빙하기

새로운 기능을 개발하다 보면 이런 순간이 찾아와요. 모니터에는 수십 개의 탭이 열려있고, 팀 내부 도구 사용법을 찾아보려는데 문서가 어디 있는지조차 기억나지 않죠. 결국 동료에게 메시지를 보내고 답장을 기다리면서 개발 흐름이 끊기고 맙니다. 익숙한 상황이죠?
토스 프론트엔드 챕터도 비슷한 문제를 경험하고 있었는데요. 이 문제를 조금 다르게 풀어 봤습니다. 문서를 더 잘 써서 방문하게 하는 대신, 문서가 직접 찾아가는 방식으로요.
문서의 경로의존성 깨기
문서의 경로의존성은 사용자가 원하는 정보를 찾기 위해 정해진 경로를 따라가야 하는 제약을 뜻해요. 기존의 기술 문서는 생산자 입장에서 구조화되어 있어서 사용자 입장에서 원하는 정보를 찾으려면 여러 번의 탐색, 혹은 검색이 필요하죠. 이런 문서의 경로의존성을 깨기 위해 먼저 개발자들이 어떻게 일하는지 관찰하고, 인터뷰했어요. 
개발자들이 지식을 얻기 위해 주로 사용하는 방식은 “질문하기”였어요. 옆에 있는 동료에게 물어보거나, 사내 메신저 채널에 질문을 던지는 거죠. 자연스럽고 공감되는 행동이었어요. 그래서 이런 개발자의 행동을 존중하는 방식으로 문서의 형태를 바꿔보기로 했습니다.
질문하기의 가장 큰 장점은 원하는 정보를 즉각적으로 얻을 수 있다는 거예요. 방대한 문서를 검색하고 읽는 것보다 동료에게 직접 물어보는 것이 시간과 노력 면에서 훨씬 효율적이에요. 개발자들이 문서를 더 적극적으로 활용하게 하려면, 이러한 즉각성이 문서에도 필요하다고 생각했어요. 마치 대화하듯이 문서에 질문을 던졌을 때 맥락에 맞는 답변을 바로 받을 수 있다면, 문서는 더욱 강력한 도구가 될 거예요.
그렇게 탄생한 도구가 바로 ‘박씨’에요.
박씨: 질문하면서 문서 읽기
특징: 질문하면 문서 내용을 기반으로 답변해줘요. 일의 흐름이 끊기지 않고 바로바로 정보를 얻을 수 있어요.
위치: IDE(VSCode, Cursor)와 사내 메신저에 있어요.
효과: "문서 찾기"가 아닌 "대화하듯 물어보기”로 지식을 얻을 수 있어요.
재밌는 점: 박씨는 프론트엔드 챕터 헤드 서진님의 페르소나를 따서 만들어 졌어요.


박씨는 LLM이 더 정확하고 신뢰할 수 있는 답변을 만들어내기 위해 개발된 RAG(Retrieval-Augmented Generation) 기반 챗봇이에요. 기존 문서들을 바탕으로 믿을 수 있는 정보를 답변하고, 그 출처를 함께 제공해요. 박씨를 사용하면 문서를 탐색하거나 키워드로 검색할 필요 없이, 궁금한 점을 자연스럽게 물어보면서 필요한 정보를 얻을 수 있어요. 동료에게 물어보는 것보다 더 정확하고, 누구에게나 일관된 답변을 제공한다는 장점이 있죠.
박씨가 좋은 품질의 답변을 하려면 탄탄한 기반 지식이 필요해요. 그래서 저희는 문서의 양과 질을 모두 높이는 것에도 많은 공을 들이고 있어요. 하지만 테크니컬 라이터와 소수의 개발자들만으로는 충분한 문서를 만들기 어려웠어요. 이 시스템이 확장성을 가지려면 누구나 자신의 지식을 쉽게 문서화할 수 있어야 했죠. 그래서 실록봇이라는 문서 자동화 도구를 만들었답니다.
실록봇: 대화를 바로 문서화하기
역할: 사내 메신저 대화 속 중요 정보를 쉽게 문서화해요.
작동방식: 대화 스레드에 실록봇 이모지를 붙이거나 봇을 호출하면 AI가 대화를 분석하고 요약해서  PR을 올려요.
효과: 사람이 시간을 내서 문서를 따로 작성하는 것이 아니라, 실제 문제 해결 과정에서 자연스럽게 그리고 자동으로 기록할 수 있어요.

실록봇은 팀 내에서 오가는 중요한 대화를 요약해서 자동으로 문서화 해줘요. 사실 개발자들은 사내 메신저에서 질문에 답하거나 대화하며 항상 지식을 교류하고 있더라구요. 그런 대화가 메신저에서 일어나기 때문에 빠르게 휘발되고, 반복적으로 같은 질문이 올라오는 게 아쉬웠어요. 실록봇은 메신저에서 일어나는 대화를 요약해서 문서 리포지토리에 PR을 만들어요. 메신저에 남긴 유용한 메시지나 논의 스레드를 최소한의 노력으로 기록할 수 있게 된 것이죠.
예를 들어, 어떤 버그를 해결하기 위해 나눈 대화가 도움이 됐다고 생각한 팀원이 실록봇을 호출해요. 그러면 그 대화는 바로 문서가 되고, 이렇게 만들어진 정보는 박씨가 학습해요. 덕분에 팀원들은 같은 질문을 반복할 필요 없이 실록봇이 모은 정보와 박씨를 사용해 쉽게 해결책을 찾을 수 있어요. 문서를 위한 문서 작성이 아니라, 지식이 공유되는 순간에 자연스럽게 문서가 만들어지는 거예요.
지식이 흐르는 팀
박씨와 실록봇 덕분에 이제 토스 프론트엔드 챕터는 특정 팀원에게 지식이 몰려있거나, 같은 질문이 반복되는 문제가 줄었어요. 필요한 순간에 필요한 정보가 제공되면서 팀 내 지식이 자연스럽게 흐르는 환경이 되었답니다. 그리고 이런 환경이 팀의 생산성과 효율성을 높이고 있어요. 개발자의 행동을 관찰하고, ‘기술 문서’를 정적인 정보 모음이 아니라 개발자의 학습과 문제 해결을 도와주는 시스템으로 접근했던 것이 유효했어요.
테크니컬 라이팅도 함께 진화하고 있는데요. 이전에는 공급자 관점에서 정보를 구조화하고 특정 기능을 효과적으로 설명하는 것에 초점을 맞췄다면, 지금은 개발자가 문서를 잘 사용할 수 있는 시스템을 만드는 데 집중하고 있어요. 결국 테크니컬 라이팅의 본질은 ‘어떻게 문서로 개발자의 문제 해결을 도와줄 수 있을까’이기 때문이에요.
토스 프론트엔드 플랫폼 팀은 지식을 공유하고, 접근하기 좋은 학습 인프라를 만드는 여정에 함께하실 분을 기다리고 있어요. AI 기반 문서화 시스템을 더욱 발전시키고, 코드와 자연스럽게 연결되는 문서 자동화 시스템을 만들고, 사내 메신저를 비롯한 여러 플랫폼과 잘 어우러지는 문서 생태계를 구축하는 일들이 기다리고 있어요.
개발자들이 더 효율적으로 일할 수 있는 환경을 만들어서 개발자 경험을 한 단계 높이는 일에 관심 있으신가요? 그렇다면 Frontend Platform Engineer에 지원해 주세요! 함께 더 나은 개발 문화를 만들어가요.



새로운 기능을 개발하다 보면 이런 순간이 찾아와요. 모니터에는 수십 개의 탭이 열려있고, 팀 내부 도구 사용법을 찾아보려는데 문서가 어디 있는지조차 기억나지 않죠. 결국 동료에게 메시지를 보내고 답장을 기다리면서 개발 흐름이 끊기고 맙니다. 익숙한 상황이죠?
토스 프론트엔드 챕터도 비슷한 문제를 경험하고 있었는데요. 이 