토스뱅크는 기술로 은행산업의 변화를 만들어 내기 위해 끊임없는 도전을 이어왔어요.
출범 단 2년 반 만에 1,000만 은행이 될 수 있었던 것은 이러한 기술혁신을 위한 시도가 있었기 때문인데요.
지난 8월 9일 토스뱅크의 첫번째 테크 밋업 Tech.nic에서 토스뱅크가 다른 은행과는 다른 기술 환경을 갖추기까지의 과정, 마주한 문제를 임팩트 있게 해결해 나간 노하우를 소개했습니다.
토스뱅크만의 일하는 방식과 성공 방정식, 그리고 앞으로의 도전 방향성까지 "은행을 바꾸는 은행"이 되기 위한 토스뱅크만의 과정이 궁금하시다면 앞으로 Tech.nic에서 소개드릴 이야기에 집중해주세요!
토스뱅크 전월세대출과 이동제를 개발하면서 마주했던 어려움과 해결방법, 그리고 토스뱅크만의 새로운 운영툴을 소개드릴게요.
우선 시작하기에 앞서, 전월세대출을 간단히 설명드릴게요. 전월세대출은 한국주택금융공사(HF), 서울보증보험(SGI) 등과 같은 대외기관과 연계하여 주택을 빌릴 때 필요한 자금을 대출받는 상품입니다.
전월세대출 흐름
먼저, 전월세대출을 실행하기까지의 흐름을 설명드릴게요.
고객은 가심사 결과를 확인하기 위해 체크리스트에 계약정보, 연소득, 혼인 여부, 주택 보유 수 등을 입력합니다.
모든 절차는 고객에게 ‘약관 및 개인(신용)정보 처리 동의서’ 를 받고 진행됩니다.

이후, 대외기관과 신용정보원에서 받아온 정보 등을 토대로 산출된 가심사 결과를 확인하고

산출된 상품 중 신청하고자 하는 상품을 선택하고, 서류 제출 과정을 거치게 돼요.
사용자의 인증이 필요한 경우는 인증을 완료한 후 진행됩니다.

이후, 이미지로 제출해야 하는 서류 제출까지 완료하면 운영 검토 및 처리 과정에 진입합니다.
운영 검토 및 처리 과정에는 제출된 서류 확인 및 추가 제출 요청 / 주택 수 확인 / 목적물 조사 / 소득 산출 / 보증 신청 등과 같은 많은 업무들이 있는데요.
운영 프로세스가 완료되면 고객은 본심사를 거쳐 마침내 전월세대출을 실행할 수 있게 됩니다.

하지만, 운영 검토 및 처리 과정에는 몇가지 어려움이 있었는데요. 모든 과정을 사람이 판단해야 하는 것이었어요.
운영 수기 프로세스
전월세대출은 고객의 소득구분(근로/사업/기타/무소득)에 따라 수집해야 하는 서류가 달라지고, 추가로 받아야 하는 서류가 있을 수 있어요. 예를 들면, 근로자의 경우는 재직증명서, 사업자의 경우는 연말정산용 사업소득 원천징수영수증과 같은 서류를 추가로 받아야 할 수도 있죠.

소득 산출 또한 수집된 서류에 따라 케이스가 나뉘고, 1명의 고객은 N개 이상의 소득 산출 케이스에 해당할 수 있어요.
많은 케이스를 사람이 수기로 판단하는 과정이 비효율적이고, 휴먼 에러가 발생할 가능성이 크다고 생각했어요. 필요한 자료를 수집하고, 고객에게 추가자료를 요청 후 소득을 산출하는 과정을 최대한 자동화하기로 했습니다.
자동화와 검증
자동화하기 위해 가장 먼저 한 일은 발생 가능한 케이스를 정의하고, 테스트 코드를 작성하는 것이었어요.
추가 제출이 필요한 서류를 판단하는 것과 소득 산출 케이스는 40가지가 넘었는데요. 비즈니스 로직을 구현하고, 검증을 위해 약 270개의 테스트 케이스를 작성했습니다.

하지만 전월세대출을 테스트하는 토스뱅크 팀원은 모두 직장인으로 분류되는데요
어떻게 사업자, 프리랜서, 기혼, 미혼, 무소득 청년과 같은 케이스를 검증할 수 있었을까요?
다이내믹 스크래핑
다이내믹 스크래핑을 활용했습니다.
다이내믹 스크래핑이란, PO/PM/QA/DA/디자이너/FE/BE 등 누구나 사업자, 프리랜서, 기혼, 미혼, 청년이 될 수 있도록 만든 기능이에요.
여신 트라이브에서 독립적으로 구현한 어드민으로 커스텀한 서류를 만들고 테스트 환경에서 적용할 서류를 선택할 수 있어요. 예를 들면, 사업자가 아니지만 사업자등록증명A(1개의 사업장), 사업자등록증명B(2개의 사업장)과 같은 서류를 정의해놓고 선택할 수 있죠.

적용하고 나면 고객이 앱에서 접하는 프로세스 그대로 재현할 수 있는데요. 
몇가지 경우를 소개해드릴게요.
첫번째, 미혼인 사람이 기혼으로 서류를 커스텀한 경우에요. 기혼이라면 배우자의 주택 수 또는 서류 수집을 위해 동의가 필요한데요. 이런 과정을 재현할 수 있어요.

두번째, 근로소득자가 아닌데 근로소득을 선택했거나, 사업소득자가 아닌데 사업소득을 선택한 경우 서류 수집 과정에서 부결 처리되는 과정이에요.

이렇게 다이내믹 스크래핑으로 정상, 실패 그리고 소득 관련 데이터가 음수로 오는 경우, 데이터가 비정상적으로 들어오는 경우까지 검증할 수 있었어요.
구현
다이내믹 스크래핑까지 포함된 서류 수집 과정을 어떻게 구현할 수 있을까요? if-else로 구현해볼게요.


fun main(args: Array<String>) {
    if (고객_근로소득) {
        서류_스크래핑()
        return 응답
    }

    if (고객_사업소득) {
        서류_스크래핑()
        return 응답
    }

    if (고객_기타소득) {
        서류_스크래핑()
        return 응답
    }

    if (고객_무소득) {
        서류_스크래핑()
        return 응답
    }

    if (배우자_근로소득) {
        서류_스크래핑()
        return 응답
    }

    if (배우자_사업소득) {
        서류_스크래핑()
        return 응답
    }

    if (배우자_기타소득) {
        서류_스크래핑()
        return 응답
    }

    if (배우자_무소득) {
        서류_스크래핑()
        return 응답
    }

    if (더미_스크래핑) {
        서류_스크래핑()
        return 응답
    }
}

fun main(args: Array<String>) {
    if (고객_근로소득) {
        서류_스크래핑()
        추가제출필요서류판단_근로소득()
        return 응답
    }

    if (고객_사업소득) {
        서류_스크래핑()
        추가제출필요서류판단_사업소득()
        return 응답
    }

    if (고객_기타소득) {
        서류_스크래핑()
        추가제출필요서류판단_기타소득()
        return 응답
    }

    if (고객_무소득) {
        서류_스크래핑()
        추가제출필요서류판단_무소득()
        return 응답
    }

    if (배우자_근로소득) {
        서류_스크래핑()
        추가제출필요서류판단_근로소득()
        return 응답
    }

    if (배우자_사업소득) {
        서류_스크래핑()
        추가제출필요서류판단_사업소득()
        return 응답
    }

    if (배우자_기타소득) {
        서류_스크래핑()
        추가제출필요서류판단_기타소득()
        return 응답
    }

    if (배우자_무소득) {
        서류_스크래핑()
        추가제출필요서류판단_무소득()
        return 응답
    }

    if (더미_스크래핑) {
        서류_스크래핑()
        추가제출필요서류판단_더미스크래핑()
        return 응답
    }
}

기능은 의도한대로 동작할거에요. 하지만, 새로운 케이스가 추가되거나 특정 케이스의 수정이 필요한 경우 유지보수가 힘들고, 코드가 굉장히 길어질 것 같아요.
하나의 구현체가 근로소득과 같은 자신의 케이스만을 담당하고, 알맞은 구현체로 라우팅 할 수 있다면 좋을 것 같은데요. 그래서 상속이 아닌 composition과 전략 패턴을 활용했습니다.


resolver로 해당 유저가 다이내믹 스크래핑, 근로소득, 사업소득 등 어떤 Service의 scraping() 로직을 타야하는지 라우팅하고, 알맞은 Service가 동작할 수 있도록 했어요. 새로운 케이스가 추가되면 그것에 맞는 새로운 Service 구현체만 만들면 되도록 만들었죠.
이렇게 수집된 서류들의 확인은 어디서 하도록 했을까요?
자동 운영 프로세스 LUMOS
전월세대출의 운영 검토 및 처리 과정에서 다루어야 하는 많은 업무들이 있다고 설명드렸었는데요.
여신을 밝힌다는 의미인 저희만의 새로운 어드민 LUMOS(Loan Universal Management Operating System)을 소개드릴게요.

LUMOS에서 처리하는 몇가지 화면을 같이 볼까요?

첫번째, 고객이 제출한 서류를 확인하는 화면이에요. 왼쪽 사이드 바에는 제출했거나 제출이 필요한 서류들이 동적으로 노출되고 체크 표시로 제출 여부 구분할 수 있어요. 운영 담당자가 확인했는지 여부를 직접 체크할 수도 있습니다.

두번째는 고객이 제출한 서류로 산출된 소득을 확인하는 화면이에요. 소득 산출 또한 모두 자동화했어요.

세번째, 알림 또는 LMS 발송 여부와 발송된 내용을 확인할 수 있는 화면이에요. 재발송도 가능하고, 필요하면 직접 작성한 내용을 고객에게 발송할 수도 있어요.

마지막, 이미지 조회입니다. 고객이 제출한 이미지를 조회할 수 있고, 개인정보를 마스킹하거나 필요없는 이미지를 삭제할 수도 있어요. 추가로 고객이 임대차계약서 카테고리에 계약금 영수증을 제출한 경우, 계약금 영수증을 계약금 영수증 카테고리로 이동시키는 기능도 제공해요.
이것의 성과로 내부와 외부에서 좋은 의견을 들을 수 있었습니다.

지금까지 전월세대출의 실행 전까지의 과정을 소개해드렸는데요, 다음으로 전월세대출 이동제의 실행 과정을 설명드릴게요.
전월세대출 이동제 실행
전월세대출 실행일에 대출이 잘 실행되는 것은 너무나도 중요한 일이에요.
하지만, 전월세대출 이동제 즉, 대환 과정에는 많은 종류의 자금 이체가 포함되어 있는데요.
다양한 자금 이체가 모두 성공하고 대환이 완료되면 좋겠지만, 실패할 가능성이 있기 때문에 롤백과 재시도 전략을 수립해야 했어요.

몇가지 케이스를 생각해볼까요?
보증료와 인지세를 납부하고, 상환총액 이체까지 성공해 대환이 완료되는 경우
보증료와 인지세를 납부하고, 상환총액을 보유기관에 이체, 고객이 부분상환을 해 돌려줘야 하는 돈이 있는 경우
첫번째 케이스를 조금 더 자세히 볼게요.

보증료 이체를 시도하다가 실패
보증료 이체는 성공했지만, 인지세를 이체하다가 실패
보증료와 인지세 이체는 성공했지만, 상환총액(대출잔금 + 중도상환수수료 + 대출이자 + 기타비용 등)을 이체하다가 실패
위와 같은 경우가 발생할 수 있을 것 같아요.

고객이 보유기관 대출을 부분 상환해서 고객에게 입금해줘야 하는 경우
고객이 증액을 해서 임대인에게 추가 이체해야하는 경우
조금 더 디테일하게 들어가보면 이런 경우까지 있을 수 있습니다.
고객이 부분상환도 하고, 증액도 했다면 2가지가 섞여있을 수도 있죠.
대환 과정에는 보유기관에 기존 대출이 잘 상환됐는지 확인해야 하는 절차도 포함되어 있는데요. 이때 보유기관이 정상 응답을 주지 않는 경우도 있을 수 있어요. 이 경우 보류 상태에 빠지게 됩니다.
고객의 액션으로 시작되는 전월세대출 이동제의 실행 파이프라인을 어떻게 재시도 가능하게 만들 수 있을까요?
구현
위에서 했던 것처럼 if-else로 한번 만들어볼게요.
fun 이체_요청() {
    val 보증료이체여부 = false
    if (보증료이체여부.not()) {
        val result보증료이체 = 보증료이체()

        if (result보증료이체.success) {
            val result인지세이체 = 인지세이체()

            if (result인지세이체.success) {
                val result가상계좌이체 = 가상계좌이체()

                if (result가상계좌이체) {

                } else {
                    val result인지세반환 = 인지세반환()
                    if (result인지세반환.success) {
                        val result보증료반환 = 보증료반환()
                        if (result보증료반환.success) {
                            실행대기()
                        }
                    }
                }
            } else {
                val result보증료반환 = 보증료반환()
                if (result보증료반환.success) {
                    실행대기()
                }
            }
        } else {
            실행대기()
        }
    }
}
기능은 의도한대로 동작하게 만들 수는 있을 것 같아요. 하지만, 아까보다 훨씬 더 depth가 깊어지고, 수정이 필요하다면 side-effect가 발생할 가능성이 큰 것 같아요. 가독성도 떨어지죠. 
보증료 이체, 인지세 이체, 상환총액 이체를 독립적인 구현체로 만들고, 저희가 정의한 순서대로 처리되도록 해서 다음 단계로 이어질 수 있도록 만들면 좋을 것 같은데요.

상태를 정의해보자면 위와 같은 여러 상태들이 있을 것 같아요.


이 상태들을 나름의 순서를 만들어 나열해보면 위와 같이 나열할 수 있는데요.

결론적으로 복잡한 if-else를 제거하고, 상태들이 순서대로 잘 진행되도록 구현하기 위해 전략 패턴과 상태 패턴 그리고 사가 패턴을 적용했습니다.

전월세대출의 대환 프로세스를 총괄하는 오케스트레이터가 있고, 오케스트레이터는 현재 대환 진행 상태가 자금 이체를 필요로 한다면 독립적으로 존재하는 송금 서버에게 자금 이체를 요청합니다.
송금 서버는 자금 이체 결과를 카프카 메시지로 발행하고, 그 메시지를 다시 오케스트레이터가 consume 해요.
consume한 오케스트레이터는 현재 대환 프로세스가 어디까지 진행되었는지 알고 있기 때문에 진행해야 하는 다음 상태를 처리하게 됩니다.

대환 프로세스에는 자금 이체가 필요하지 않은 단계도 있는데요.
자금 이체가 필요하지 않은 경우는 Orchestrator가 다른 마이크로 서버와의 통신 등과 같은 처리로 다음 단계로 진행해요.

위에서 상환 결과 조회 응답이 정상이 아니라면 보류 상태에 빠진다고 설명드렸었는데요.
이 경우 고객의 재시도로 대환 프로세스가 다시 시작될 수도 있을텐데요. 저희는 굳이 고객이 직접 재시도 하지 않고도 대환 프로세스가 완료될 수 있도록 배치로 보류 상태에 빠진 대상의 상환 결과 조회를 재시도하고, 정상 응답이 오면 대환 프로세스가 완료될 수 있도록 했어요.
오케스트레이터의 롤백과 재시도가 가능한 프로세스로 고객의 전월세대출 이동제 실행은 성공적으로 완료됩니다.
기술적 노력과 성과
고객의 대출을 안정성 있게 실행하고, 유지보수 및 변경에 빠르게 대응하기 위해 여러가지 디자인 패턴을 적용했습니다. 또한, 전월세대출 이외 상품은 소득 산출과 같은 로직이 계정계에 존재했기 때문에 수집된 서류는 모두 계정계로 전달되어 채널계와 계정계에 모두 존재했었는데요. 계정계 모놀리틱으로부터 독립하고 관리 포인트를 줄이기 위해 서류와 소득 관련된 로직을 마이크로 서비스로 구현했습니다. 결과적으로, 내외부적으로 긍정적인 반응을 얻을 수 있었습니다.
지금까지 토스뱅크에서 전월세대출과 대환 프로세스를 만들면서 겪은 어려움을 해결한 방법을 공유드렸는데요. 
저희는 지금도 이전으로 돌아갈 수 없는 새로운 은행 경험을 제공하기 위해 노력하고 있습니다.
앞으로도 지켜봐주시고, 저희와 함께 은행의 혁신을 만들어 나갈 분들을 기다립니다.
감사합니다.


토스뱅크는 기술로 은행산업의 변화를 만들어 내기 위해 끊임없는 도전을 이어왔어요.
출범 단 2년 반 만에 1,000만 은행이 될 수 있었던 것은 이러한 기술혁신을 위한 시도가 있었기 때문인데요.
지난 8월 9일 토스뱅크의 첫번째 테크 밋업 Tech.nic에서 토스뱅크가 다른 은행과는 다른 기술 환경을 갖추기까지의 과정, 

토스뱅크에서 전월세대출과 대환 프로세스를 만들면서 겪은 어려움을 해결한 방법을 공유합니다.

다이내믹 스크래핑과 전월세대출 이동제의 실행

토스뱅크는 기술로 은행산업의 변화를 만들어 내기 위해 끊임없는 도전을 이어왔어요.
출범 단 2년 반 만에 1,000만 은행이 될 수 있었던 것은 이러한 기술혁신을 위한 시도가 있었기 때문인데요. 
지난 8월 9일 토스뱅크의 첫번째 테크 밋업 Tech.nic에서 토스뱅크가 다른 은행과는 다른 기술 환경을 갖추기까지의 과정, 마주한 문제를 임팩트 있게 해결해 나간 노하우를 소개했습니다.
토스뱅크만의 일하는 방식과 성공 방정식, 그리고 앞으로의 도전 방향성까지 "은행을 바꾸는 은행"이 되기 위한 토스뱅크만의 과정이 궁금하시다면 앞으로 Tech.nic에서 소개드릴 이야기에 집중해주세요!
토스뱅크에서 최근에 전세대출 상품을 개발하면서 기존 DevOn 프레임워크에서 벗어나 Spring과 Kotlin 환경에서 전환 작업을 진행했습니다. 다시 말하면 계정계 MDD(Model Driven Development)환경이 아니라 독립된 서버에서 운영할 수 있는 MSA 환경으로 개발했습니다.
기존 프로세스 중에서 여신 심사 프로세스를 전환했는데요. 이 프로세스 중에 대외기관을 통해 신용정보를 가져오는 기능의 운영이 가장 유연해진 것 같아 개선한 경험을 소개합니다.

기존 문제점
이번 MSA 전환 작업에서 코드와 개발 환경을 마이그레이션하면서 기존 시스템의 불편한 점도 많이 발견했는데요. 여기서 몇 가지 문제를 소개드릴게요.
먼저 기존 프로세스는 어떻게 구성되어 있을까요? 신용 정보 조회는 여신 프로세스에서 고객이 금융권에 들어와서 대출 가능 여부 및 한도를 결정하는 중요한 정보 중 하나인데요. 신용 정보 조회를 위해서 다양한 기관과 여러 서비스를 이용하고 있어요. 또 대외기관의 데이터는 실시간 비동기 방식으로 요청해서 받아와 활용하고 있었습니다.

아래 그림은 많은 금융기관에서 사용하고 있는 채널과 계정계 사이 통신 방식을 간략히 나타내고 있어요.
토스뱅크는 앱으로 신용조회가 진행하면, MCI(Multi Channel Integration)를 통해 계정계로 “신용정보를 조회해주세요”라는 요청을 보내요. 계정계는 해당 요청을 받아 FEP(Front End Processor) 서버를 이용해서 대외기관과 연계를 수행해요. 요청에 대한 응답 역시 대외기관에서 FEP를 거쳐 계정계에 데이터를 적재하는 방식으로 처리하고 있어요. 

여러 서비스에 요청을 보냈다면 응답을 확인하는 것도 중요한데요. 요청이 끝나면 채널에서는 계정계로 신용정보조회가 모두 종료되었는지 확인 요청을 보내요. 계정계는 오라클을 조회해서 최종 결과값을 채널로 제공하고요. 많은 금융권에서 일반적으로 사용하고 있는 방법이에요.
프로세스 자체는 잘 돌아가고 있지만 어떤 부분이 아쉬울까요? 몇 가지 아쉬운 점을 소개해드릴게요.

문제 #1: 채널에서 계정계로 불필요한 호출
채널에서 응답 확인을 위해 지속적으로 MCI를 거쳐 계정계를 호출하고 있었어요. 계속 호출할 수 없기 때문에 최대 80번까지만 호출해요. 대부분의 경우 몇 초 내외로 처리되지만, 타임아웃이 발생하면 MCI 호출이 급증하게 되죠. 
대외기관의 응답에 따라 불필요한 계정계 호출이 많이 발생하고. 또 이렇게 거래가 많이 쌓이면 어느 거래에서 정확히 오류가 발생하는지 특정하기 어려운 상황이었어요. 항상 오류 확인 및 모니터링을 위해 개발자가 데이터베이스를 직접 조회했습니다. 

문제 #2: 심사에 불필요한 데이터를 오라클에 적재
두 번째는 데이터베이스에 불필요한 데이터가 적재되고 있었어요. N개의 서비스 응답 성공 여부가 전부 N개의 테이블에 적재하고 있었어요.
처음 토스뱅크 오픈 시점에는 각 기관별 응답 여부를 하나의 테이블에 하나의 행(Row)으로 관리했습니다. 그러나 여러 개의 전문이 동시에 응답이 도착하면, 비관적 락을 사용하기 때문에 동시성 이슈가 발생하는 경우가 있어서 이런 시스템이 만들어졌어요.

토스뱅크의 해결 방법
그래서 토스뱅크는 이런 문제를 어떻게 해결했을까요? 토스뱅크는 KCB, NICE 등 각 기관에서 보내는 응답을 저장합니다. 각 기관에서 필요한 데이터가 모두 저장됐으면, 최종으로 통합 관리하는 테이블에 모든 데이터를 저장하는 구조를 설계했어요. 
비동기 방식의 통신에서 모든 전문이 잘 들어왔는지 확인하는 과정은 중요하지만, 각 전문별 응답 값은 심사에 영향을 미치는 정보가 아니고, 단순히 응답 확인만을 위해 저장되는 데이터였기 때문에 이런 설계가 가능했어요.


해결 방법 #1: Redis 도입

토스뱅크에서는 여러 개의 전문을 한 번에 요청하고 있어요. 요청한 전문에 대한 응답은 모두 비동기로 수신되고요. 그래서 지금 전문 수신 프로세스는 동시에, N개의 전문을 수행할 수 있는 형태에요.
대외기관에서 신용조회한 특정 전문 응답이 들어오면 Redis에 수신이 완료되었다는 정보를 저장해주어요. 메모리에는 고객을 특정할 수 있는 Key 값, 전문이름, 그리고 전문에 대한 응답 정보를 넣어주어요. 
응답 정보를 넣어줄 때마다 지금까지 Redis에 저장한 전문 응답 개수와 우리가 요청한 전문 개수를 아래와 같이 비교해서 요청 정보가 모두 수신되었는지 확인을 해요.
private fun isComplete(size: Int) =    size == CreditBureauType.getOnlineTelegramSize()
마지막 전문이 응답된 시점에 모든 신용조회가 완료된 것으로 판단하고 심사에 필요한 정보를 테이블에 적재하고 신용정보 조회 단계를 종료합니다.
Redis가 가지는 특징 중 하나인 인메모리 저장 방식은, 하드디스크가 아닌 주기억장치인 RAM에 데이터를 저장하는 방식이에요. 그래서 데이터를 빠르게 읽고 쓸 수 있다는 장점이 있죠. Redis는 이러한 인메모리 장점을 살려 메모리를 임시 저장소로 활용하는 캐싱 전략을 많이 사용됩니다. 이번 토스뱅크 전세대출에서도 각 전문의 응답 데이터는 심사에 불필요한 데이터라고 판단하여 Redis를 도입하기로 했습니다. 
해결 방법 #2: 카프카를 이용한 응답 전달
신용정보 조회 단계가 완료되었으니, 완료되었다는 정보를 채널에서 폴링하던 방식은 아래처럼 개선했어요.
기존에는 계정계가 직접 채널에 알려주지 않아 그림과 같이 응답 완료가 될 때까지 채널에서 주기적으로 전자금융서비스(API)를 호출해서 확인했어요.

하지만, 전세대출에서는 응답이 완료되면 Kafka 이벤트를 발행하여 불필요한 호출이 지속적으로 발생하지 않도록 개선했어요.  Kafka를 도입한 이유 중 하나는 일반적으로 응답받는데 시간이 꽤 걸리는 경우 비동기 하게 Kakfa 로 응답을 받을 수 있기 때문이에요.

해결방법 #3: 새로운 MSA 구조
지금까지 전세대출에서 신용정보를 조회하는 과정에서 개선한 점에 대해서 디테일하게 설명 드렸어요. 이제 앞서 설명드린 개선점이 반영된 최종 전세대출 MSA 구조와 이전과 달라진 점을 설명해드릴게요.
기존 구조는 채널에서 MCI를 통해 계정계 Monolithic 서버를 호출하고, FEP 솔루션을 활용하여 대외기관에 전문을 주고받는 구조였어요. 새로운 구조는 전세대출 MSA를 통해 채널에서 MSA전세대출 심사 서버를 RestFul API로 호출하고 대외기관에 전문을 fep-gateway로 주고받는 구조로 개선되었습니다.
변화된 부분 중 몇가지를 자세히 살펴보면 다음과 같아요.
기존에는 모든 정보를 오라클 RDBMS에서 관리하였으나, 전세대출에서는 원장성 정보가 아닐 때는 Redis를 활용할 수 있도록 개선되었고요,
응답값 확인을 위해 채널에서 수많은 조회 요청을 하는 방식이 아니라, 완료 시점에 메시지를 발행하는 이벤트 드리븐 방식으로 바뀌었어요.

개선 효과
구조를 전환하면서 어떤 점이 개선됐는지 알려드릴게요.
MSA는 단일 책임 원칙을 중시해요. 그래서 전세대출 서버는 전세대출만을 담당하고 있어요. 다양한 상품을 함께 관리하던 과거 프로그램에 비해 로직이 간소화됐고, 필요한 내용만 확인할 수 있어 유지 보수에 용이해졌어요. 그리고 기존에는 계정계와 채널 서버가 분리되어 업무가 명확히 나누어져 있었는데요. 계정계 로직이더라도 MSA 환경에서 구현되어 해당 기술 스택을 만족하는 모든 서버 개발자가 기여할 수 있게 되었어요.
또 비용과 시간을 절약할 수 있었는데요. 레디스에 적재하는 응답데이터를 오라클 DB에 적재했다면 전세대출 상품에서만 하루 약 20만건의 데이터를 적재했을 거예요. 전세대출이 출시한지 곧 1년인데, 약 7300만건의 DB리소스를 절약해요. 시간 측면에서는 모놀리식 서버 로직에 비해 회당 0.6~0.7초 감소했어요. 외부정보가 하루에 20건 정도 수행되니 하루에 고객님의 시간도 많이 절약됐습니다.
마지막으로 가장 큰 장점은 장애가 발생했을 때도 영향도가 없다는 점이에요. 기존에는 DevOn 프레임워크에 계정계 서버가 돌아가는데요. 특정 장애가 발생하면 모놀리식 서버 내에 있는 개인여신, 개인사업자 여신은 모두 심사가 불가능한 상태가 됩니다. 하지만, 전세대출은 서버가 분리되어 있어 심사가 가능합니다.





토스뱅크는 기술로 은행산업의 변화를 만들어 내기 위해 끊임없는 도전을 이어왔어요.
출범 단 2년 반 만에 1,000만 은행이 될 수 있었던 것은 이러한 기술혁신을 위한 시도가 있었기 때문인데요. 
지난 8월 9일 토스뱅크의 첫번째 테크 밋업 Tech.nic에서 토스뱅크가 다른 은행과는 다른 기술 환경을 갖추기까지의 과정,

토스뱅크에서 대외기관을 통해 신용정보를 가져오는 과정을 개선한 경험을 소개합니다.

전세대출에서 대외기관 신용정보를 조회하는 방법



토스 채용 꿀팁, 면접관들이 직접 말합니다!
 "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에 지원해 주세요! 함께 더 나은 개발 문화를 만들어가요.



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