토스 기술블로그(toss.tech) 읽는 법: 1인 개발자가 2026년에 꼭 읽어볼 글과 배울 점

검색창에 “토스 기술블로그”를 치는 사람은 대개 둘 중 하나다. 토스에 지원하려고 회사 분위기를 살피는 사람이거나, 남이 실제로 부딪힌 문제와 해결 과정을 읽고 싶은 개발자다. 나는 뒤쪽이다. 혼자 제품을 만들다 보면 내 코드를 봐 줄 선배도, 장애 회고를 같이 할 동료도 없다. 그래서 큰 회사 엔지니어들이 공개한 회고를 읽는 시간이 거의 유일한 코드 리뷰처럼 느껴질 때가 있다.

이 주소에 있던 예전 글은 토스 테크를 몇 줄로 소개하고 끝나는 짧은 글이었다. 이번에 2026년 10월 19일 기준으로 toss.tech 메인, 카테고리, 시리즈 페이지와 RSS 피드를 직접 열어 보고, 최근 글을 하나씩 읽은 뒤 처음부터 다시 썼다. 아래에 소개하는 글은 모두 실제로 존재하는 글이고 링크를 걸어 두었다. 숫자는 각 글에 적힌 값을 그대로 옮겼다.

토스 테크(toss.tech)는 어떤 블로그인가

토스 테크는 토스를 만드는 비바리퍼블리카와 계열사(토스뱅크, 토스증권, 토스페이먼츠 등) 구성원이 직접 쓰는 공식 기술 블로그다. 구독 페이지에는 “토스 메이커들이 문제를 정의하고 해법을 찾아가는 이야기”라고 소개돼 있다. 이름은 기술 블로그지만 개발 글만 있는 곳은 아니다. 상단 분류가 Engineering, Design, Product 세 가지로 나뉘어 있고, 디자이너와 PO가 쓴 글도 꽤 많다.

처음 들어가면 글이 많아서 어디부터 읽어야 할지 막막하다. 나는 세 가지 길로 나눠서 본다.

• 카테고리: Engineering(인프라, 데이터, 프론트엔드, ML), Design, Product. 내 관심사 쪽 하나만 골라 최신순으로 훑는다.
• 시리즈: 한 주제를 여러 편으로 이어 쓴 묶음이다. 지금 메인에서 보이는 시리즈는 「토스페이먼츠 레거시 개편 이야기」, 「Simplicity 4」 제작기, 「토스 피플」, 「접근성 업무일지」다.
• RSS: toss.tech/rss.xml로 새 글을 받아 볼 수 있다. 최근에는 일주일에 몇 편씩 올라오는 편이라, 메인을 들락거리는 것보다 RSS 리더에 넣어 두는 쪽이 편하다.

1인 개발자가 토스 테크를 읽어야 하는 이유

토스는 금융 서비스라서 규모도, 규제도, 팀 크기도 1인 개발자와는 거리가 멀다. 그런데도 읽을 가치가 있는 이유는 글의 형식에 있다. 토스 테크 글은 대체로 “이런 문제가 있었고, 이런 가설을 세웠고, 이렇게 확인했고, 결과는 이랬다”는 순서를 지킨다. 결론만 적는 게 아니라 중간에 버린 선택지와 그 이유까지 적는 경우가 많다. 혼자 일하는 사람에게 가장 부족한 게 바로 이 “왜 그렇게 판단했는가”를 볼 기회다.

또 하나는 AI 관련 글의 밀도다. 2026년 하반기에 올라온 글을 보면 코딩 에이전트에게 팀 규칙을 지키게 하는 방법, 사내 LLM 벤치마크, AI 플랫폼 설계, AI 상담 서비스 디자인까지 AI를 실제 서비스에 붙이면서 생긴 문제를 다룬 글이 연달아 나왔다. 바이브 코딩으로 제품을 만드는 사람이라면 남의 시행착오를 미리 읽는 것만으로 꽤 많은 삽질을 줄일 수 있다.

AI로 제품 만드는 사람이 먼저 읽을 글 4편

1. AI가 팀 규칙을 지키도록 하는 방법

이 글은 토스뱅크 ML Engineer가 코딩 에이전트로 코드를 쓰면서 겪은 문제를 다룬다. AGENTS.md 같은 전역 지침 파일에 팀 규칙을 적어 두면 세션 초반에는 잘 지키는데, 대화가 길어지면 점점 무시한다는 관찰에서 시작한다. 글에서는 이 현상을 Lost in the Middle로 설명한다. 파일 읽기, 코드 작성, 테스트 결과가 쌓이면서 처음에 읽은 규칙이 컨텍스트 한가운데로 밀려나 버린다는 것이다.

흥미로운 건 해법이다. 규칙을 더 많이 적는 대신, 에이전트가 도구를 호출하며 반복하는 루프 안에 피드백 루프를 하나 더 넣는다. 린터가 코드를 고칠 때마다 경고를 돌려주듯, 세세한 규칙을 필요한 순간에 필요한 만큼만 꺼내 주는 방식이다. 예시로 든 규칙도 구체적이다. asyncio.gather 대신 asyncio.TaskGroup을 쓰라거나, trace id를 직접 만들지 말고 팀 공통 함수를 쓰라는 식이다.

CLAUDE.md나 AGENTS.md에 규칙을 계속 덧붙여 본 사람이라면 공감할 대목이 많다. 혼자 쓰는 프로젝트라도 “문제는 무엇을 알려주느냐가 아니라 언제, 몇 개를 알려주느냐”라는 이 글의 문장은 그대로 가져갈 만하다. Claude Code에서 훅과 지침 파일을 어떻게 나눠 쓰는지는 Claude Code 하네스 정리 글에 따로 적어 두었다.

2. 리더보드 1등 LLM, 토스에서도 1등일까? – Toss Benchmark 구축기

이 글은 공개 리더보드 점수와 실제 업무 성능이 다를 수 있다는 걸 데이터로 보여 준다. 같은 수학·코딩 문제를 영어 원문과 한국어 번역본으로 풀게 했더니 모델 사이의 순위가 바뀌었다는 표가 들어 있다. 토스가 LLM을 어디에 쓰는지도 표로 정리돼 있다. 커머스 카탈로그 생성, 카드 약관 분석, 광고 검수, 상담 에이전트, 장애 원인 조사까지 범위가 넓다.

1인 개발자에게 주는 교훈은 단순하다. 새 모델이 나왔다고 바로 갈아타기 전에, 내 서비스에서 실제로 쓰는 프롬프트 10~20개로 직접 비교해 보라는 것이다. 특히 한국어 서비스라면 영어 벤치마크 점수만 믿지 말아야 한다. AI 코딩 도구 비용을 비교할 때도 같은 원칙이 통한다. 요금표보다 내 작업량 기준으로 계산해 보는 게 정확하다는 이야기는 Cursor vs Claude Code 요금 비교에서 자세히 다뤘다.

3. 서비스 개발에 집중할 수 있는 AI 플랫폼 만들기

토스 AI Platform 팀의 글이다. 서비스 팀마다 모델 연동 코드, 권한 확인, 사용량 집계를 따로 만들면 같은 일을 반복하게 되니, 이걸 플랫폼이 맡도록 설계한 과정을 설명한다. 모델 사용 신청과 설정은 GenAI Portal이, 실제 호출은 LLM Gateway인 GenAI Gateway가, 사내 도구 호출 권한은 MCP Gateway가 맡는다.

규모는 다르지만 구조는 혼자 만드는 서비스에도 그대로 적용된다. 모델 호출을 코드 곳곳에 흩어 두지 말고 한 곳으로 모으고, 프로젝트 단위로 예산과 사용량 한도를 걸고, 모델 호출 권한과 도구 실행 권한을 분리하라는 것이다. 작은 서비스라면 API 키를 기능별로 나눠 발급하는 것부터 시작해도 된다. 어느 기능이 비용을 쓰는지 바로 보이고, 키 하나가 새어도 피해 범위가 줄어든다. MCP 서버를 붙일 때 권한을 어떻게 나눌지는 MCP 도입 실전 가이드에서 1인 개발자 기준으로 정리해 두었다.

4. 연 300시간을 아낀 AI 상담 서비스

토스뱅크 전세대출 팀 디자이너의 글이다. 개발 글은 아니지만 AI 기능을 붙이는 사람이라면 꼭 읽어 봤으면 한다. 처음에는 “궁금한 점 AI에게 물어보기” 배너를 누르면 빈 입력창이 열리는 구조였는데, 거의 아무도 누르지 않았다고 한다. 그래서 상담 문의 데이터를 다시 보고, 단계마다 사람들이 실제로 가장 많이 물었던 질문을 진입점에 보여 줬다. 그러자 인트로 화면의 AI 사용률이 약 5배, 심사 대기 화면은 약 2배 올랐다고 적혀 있다.

빈 입력창은 “무엇이든 물어보세요”가 아니라 “무엇을 물어야 할지 모르겠다”로 읽힌다는 것. 내 서비스에 AI 챗봇을 넣으려는 사람이라면 이 한 가지만 기억해도 첫 버전의 실패를 피할 수 있다.

코드 구조와 운영이 궁금할 때 읽을 글

App Router의 장점은 우리에게도 장점일까요?

토스뱅크 프론트엔드 개발자의 글로, Next.js Pages Router에서 App Router로 옮길지 검토한 끝에 “도입하지 않는다”는 결론을 낸 과정이다. 이런 글이 귀하다. 새 기술을 도입한 후기는 많아도, 직접 옮겨 보고 접은 이유를 자세히 쓴 글은 드물기 때문이다. 웹뷰 환경에서 스트리밍 렌더링을 실험했을 때 Chromium과 WebKit의 첫 콘텐츠 표시 시점이 크게 달랐다는 측정 결과, 스켈레톤 높이 때문에 생기는 레이아웃 이동 문제 같은 실무 디테일이 들어 있다.

유행하는 구조를 따라갈지 고민될 때, “그 장점이 우리 화면에서도 장점인가”를 측정해서 판단하는 태도를 배울 수 있다.

토스뱅크가 패키지를 관리하는 방식 #1, #2

두 편짜리 글이다. 1편은 사내 패키지를 ESM과 CommonJS 두 형식으로 내보내다가 생긴 문제, 즉 같은 패키지인데 React 컨텍스트가 둘로 나뉘는 Dual package hazard와 타입 누락 문제를 설명하고, Node.js 22.12.0부터 플래그 없이 require(esm)을 지원하게 된 걸 근거로 ESM-only로 전환한 이야기다. 2편은 패키지가 지켜야 할 기준을 안정성, 예측 가능성, 디버깅 편의성 세 가지로 정리한다.

npm에 작은 라이브러리를 올려 본 사람, 모노레포에서 공통 패키지를 쓰는 사람이라면 바로 써먹을 내용이다. 다만 글에서도 밝히듯 이건 사용처를 통제할 수 있는 사내 패키지라서 가능한 선택이다. 공개 라이브러리는 여전히 두 형식을 함께 제공해야 할 수 있다는 단서까지 같이 읽어야 한다.

쉼 없이 도는 테스트, 사람이 어디까지 돌봐야 할까요? – 토스닥터

토스 QA Platform 팀의 글이다. 토스 앱은 매주 새 버전을 내는데, 그때마다 사람이 손으로 누르던 스모크 테스트를 자동화한 도구 토스닥터의 두 번째 버전 이야기다. 사람은 Gherkin 문법으로 “무엇을 검증할지”만 쓰고, LLM에 Appium MCP를 붙여 실제 기기 화면을 보면서 코드를 생성한다. 요소를 찾을 때도 스크린샷과 보이는 요소 목록부터 쓰고, 안 되면 전체 화면 구조를 뒤지고, 그래도 안 되면 사람에게 묻는 3단계로 나눴다.

내가 가장 인상 깊게 읽은 부분은 검증 단계에서는 “비슷한 요소”로 통과시키는 걸 금지했다는 대목이다. 비슷한 걸 눌러서 통과시키면 거짓 성공이 다음 단계로 줄줄이 이어진다는 이유다. AI에게 테스트를 맡길 때 가장 무서운 게 이런 조용한 거짓 성공이라는 점은 내가 출시 직전 사후분석에서 겪은 “성공한 빈 응답” 문제와도 닿아 있다.

평균 CPU는 여유로운데, 커밋은 왜 느릴까?

토스증권 DBA 팀의 글로, 이 글을 쓰는 오늘(10월 19일) 올라왔다. 평균 지표는 모두 정상인데 Oracle 커밋 대기가 0.1초 넘게 이어지는 현상을 추적해 보니, NIC 인터럽트가 CPU 소켓 하나에 몰려 있었다는 이야기다. pidstat으로 프로세스가 어느 CPU에서 도는지 기록하고, /proc/interrupts를 30초 간격으로 두 번 읽어 차이를 구하는 방법이 그대로 나온다. 별도 도구 없이 할 수 있는 진단법이라 작은 서버를 운영하는 사람에게도 쓸모가 있다. “평균에 묻힌 문제는 평균으로 찾을 수 없다”는 교훈은 서버 규모와 상관없다.

결제와 레거시가 궁금하다면: 토스페이먼츠 레거시 개편 시리즈

「토스페이먼츠 레거시 개편 이야기」 시리즈는 20년 가까이 운영된 PG 시스템을 어떻게 바꿔 왔는지 여러 엔지니어가 나눠 쓴 묶음이다. 결제창 전면 재작성, 프론트엔드 SDK, Open API, 결제 원장, 정산 시스템, 대용량 데이터 조회, 설정 관리, 하이브리드 클라우드, 보안까지 주제가 이어진다.

1인 개발자가 PG사를 만들 일은 없지만, 결제를 붙이는 쪽에서 읽으면 얻는 게 많다. 특히 SDK와 Open API 편은 “가맹점 입장에서 바뀌지 않아야 하는 것”을 어떻게 지켰는지 다루기 때문에, 내 서비스의 API를 공개하려는 사람에게 좋은 참고가 된다. 한국에서 결제 수단을 고르는 과정은 한국에서 Stripe 대안 찾기에서 토스페이먼츠를 포함해 비교해 두었다.

개발자가 아니어도 배울 게 많은 Design·Product 글

토스 테크에서 의외로 가장 많이 배운 쪽은 디자이너들의 글이었다. 혼자 제품을 만들면 디자인과 기획도 내 몫이기 때문이다.

• 도메인 지식 없는 디자이너가 팀의 기준을 바꾼 방법: 해외송금에서 팀은 “수수료가 싸야 한다”고 믿었지만, 실제 송금 경험자를 인터뷰해 보니 더 큰 문제는 돈이 어디쯤 가고 있는지 모르는 불안이었다는 이야기다. 말로 설득이 안 되자 팀원이 직접 해외로 돈을 보내 보게 했다는 대목이 좋다. 고객 인터뷰를 어떻게 시작할지는 B2B SaaS 검증 글에서도 다뤘다.
• 사용자를 위해 일부러 어렵게 만드는 경험, 어디까지 괜찮을까?: 10대를 위한 잠금 저금통을 만들며, 팀 반응이 좋았던 “돼지저금통 부수기” 연출을 버린 이유를 설명한다. 만드는 사람에게 재미있는 인터랙션이 쓰는 사람에게는 실패의 낙인이 될 수 있다는 관점이다.
• 방해하지 않고, 눈에 띌 수 있을까: 클릭률이 낮던 추천 배너를 계좌 정보와 다른 층의 플로팅 카드로 분리하고, 스크롤하면 작아지게 만든 과정이다. 광고처럼 보이지 않게 하려고 그래픽과 컬러를 덜어냈다는 판단이 인상적이다.
• 9인조 다람쥐 아이돌을 데뷔시켰습니다: AI 이미지 도구로 캐릭터 시안을 대량으로 뽑되, 고정 문장과 빈칸으로 나눈 프롬프트 뼈대를 만들고, 최종 판단과 디테일 수정은 디자이너가 했다는 제작기다. AI로 에셋을 만드는 1인 개발자에게 현실적인 작업 흐름을 보여 준다.

토스 테크를 내 공부로 바꾸는 읽기 방법

좋은 글도 읽고 끝내면 남는 게 별로 없다. 내가 쓰는 방법은 이렇다.

1. RSS를 구독하고, 제목만 보고 고르지 않는다. 제목이 낯선 분야여도 첫 문단의 문제 정의만 읽어 본다. 데이터베이스 글처럼 보여도 진단 방법은 내 서버에 그대로 쓸 수 있는 경우가 많다.
2. “문제, 가설, 확인 방법, 결과”를 네 줄로 요약한다. 글마다 이 네 줄만 메모해 두면 비슷한 문제가 생겼을 때 다시 찾기 쉽다.
3. 버린 선택지를 따로 적는다. App Router 글처럼 “하지 않기로 한 것”에 진짜 판단 기준이 들어 있다.
4. 한 편을 골라 내 프로젝트 규모로 축소해 본다. AI 플랫폼 글을 읽었다면 내 서비스의 모델 호출을 한 파일로 모아 보는 식이다. 작게라도 해 보면 글이 내 경험이 된다.
5. 읽은 걸 짧게라도 글로 남긴다. 토스 테크 글 자체가 “남이 읽을 수 있게 정리하는 일”의 좋은 예시다. 내 블로그에 회고를 쓰는 습관은 검색 유입보다 나에게 먼저 도움이 된다. 이 부분은 AI 검색 시대의 블로그 전략에 더 적어 두었다.

자주 묻는 질문

토스 기술블로그 주소가 어떻게 되나요?

공식 주소는 toss.tech다. 새 글은 RSS(toss.tech/rss.xml)나 사이트의 구독 페이지로 받아 볼 수 있다.

입문자가 읽기에는 어렵지 않나요?

인프라나 데이터 글은 배경지식이 꽤 필요하다. 처음이라면 Design과 Product 분류의 글, 또는 App Router 글처럼 판단 과정을 따라가는 글부터 읽는 걸 권한다. 용어가 막히면 그 단어만 따로 찾아보면서 읽어도 충분하다.

토스 입사 준비에 도움이 되나요?

회사가 어떤 문제를 중요하게 보고 어떻게 의사결정을 하는지 알 수 있어서 도움이 된다. 「토스 피플」 시리즈에는 구성원들의 커리어 이야기도 있다. 다만 채용 절차나 조건은 블로그가 아니라 토스 채용 페이지에서 확인해야 한다.

다른 국내 기술 블로그와 무엇이 다른가요?

금융 서비스라서 규제, 보안, 정산처럼 다른 회사 블로그에서 보기 힘든 주제가 나온다는 점이 가장 다르다. 디자이너와 PO의 글 비중이 높은 것도 특징이다.

정리하면

토스 테크는 큰 회사 이야기라서 나와는 상관없다고 넘기기 쉽다. 그런데 막상 읽어 보면 AGENTS.md를 무시하는 코딩 에이전트, 아무도 안 누르는 AI 입력창, 평균에 숨은 병목처럼 혼자 제품을 만드는 사람도 똑같이 겪는 문제가 많다. 위에 소개한 글 중 지금 내 상황과 가장 가까운 한 편만 골라 읽고, 네 줄 요약을 남겨 보자. AI로 제품을 만들 때 쓰는 도구와 운영 방법은 1인 창업 AI 도구 가이드에 모아 두었다.