개발 세계에서 제가 자주 듣는 문장이 하나 있습니다: "배우기 위해 프로젝트를 만들어라". 문제는 대부분의 포트폴리오 프로젝트가 그 이면에 실제적인 고통(pain point) 없이 탄생한다는 점입니다. 그리고 실제적인 고통이 없다면, 깊이 파고들 동기, 어려운 문제를 해결할 동기, 그리고 막혔을 때 포기하지 않을 동기가 부족해집니다.

Quita는 다르게 태어났습니다. 진정한 필요성으로부터 탄생했습니다.

아무도 간단하게 해결하지 못한 문제

저는 인생의 더 격동적이었던 시기에 쌓인 부채를 안고 몇 년을 보냈습니다. 마침내 이를 해결할 재정적 여건이 되었을 때, 저는 무엇이 미결제 상태인지, 누구에게 빚이 있는지, 그리고 법이 소비자로서 저에게 무엇을 보장하는지 이해하기 위해 찾아 나섰습니다.

제가 발견한 것은 미로였습니다.

정보는 존재했습니다 — Banco Central(중앙은행), Consumidor.gov.br, 그리고 법령에 말이죠. 하지만 그 정보에 접근하고 사용하는 경로는 누구나 포기하고 싶을 정도로 혼란스러웠습니다. 검색을 통해 찾는 거의 모든 것은 법률 사무소나 유료 컨설팅 업체로 연결되었습니다. 이론적으로는 시민 스스로 할 수 있는 일을 수행하기 위해 비용을 청구하는 서비스들이었습니다.

저는 생각하기 시작했습니다: 정보에 접근할 수 있고 기술에 어느 정도 익숙한 나조차도 어려움을 겪었다면, 그렇지 않은 사람들에게는 어떤 일이 벌어질까?

브라질은 수십 년간 과잉 부채(superendividamento)의 역사를 가지고 있습니다. 수백만 명의 사람들이 단순히 돈이 없어서가 아니라, 무엇을 해야 할지, 어디서부터 시작해야 할지, 어떤 권리가 있는지에 대한 명확한 안내가 없어서 채무를 재협상하지 못하고 있습니다.

그 지점에서 Quita가 의미를 갖기 시작했습니다.

Quita란 무엇인가

Quita는 채무가 있는 시민을 위한 디지털 어시스턴트입니다.

이 서비스는 사용자가 금융 시스템에 등록된 모든 부채를 통합하는 문서인 Banco Central의 Registrato를 통해 금융 보고서를 얻는 것부터, 금융 기관이 법적으로 답변해야 하는 플랫폼인 Consumidor.gov.br에 제출할 구조화된 의견서를 생성하는 것까지 안내합니다.

주요 흐름은 다음과 같습니다:

1. 사용자가 Registrato PDF를 업로드합니다.
2. 시스템이 문서에 포함된 부채를 자동으로 추출합니다.
3. 부채에 대한 인사이트(금액, 기관, 상태 등)가 생성됩니다.
4. 이 데이터를 기반으로, Quita는 AI를 통해 책임 기관에 즉시 보낼 수 있는 근거 있는 규제 민원(regulatory complaint)을 생성합니다. 목표는 사용자를 대신해 부채를 해결하는 것이 아닙니다. 사용자에게 명확한 정보를 제공하고, 스스로 권리를 행사할 수 있는 구체적인 도구를 제공하는 것입니다.

기술 스택 (Technical Stack)

이 프로젝트는 생산성과 신뢰성에 초점을 맞추어, 현대적이고 의도적으로 간결한 스택으로 구축되었습니다.

백엔드 (Backend)

• Java 21
• Spring Boot 4
• JWT 인증을 포함한 Spring Security
• PostgreSQL
• Flyway (마이그레이션)
• Maven

프론트엔드 (Frontend)

• Next.js
• TypeScript

인공지능 (Artificial Intelligence)

• Google Gemini (규제 민원 생성)
• OpenAI (폴백(fallback) 계층 및 실험용)

인프라 (Infrastructure)

• Railway (백엔드 및 데이터베이스 호스팅)
• Vercel (프론트엔드 호스팅 — 배포 중)

기타

• PDF 추출 및 처리

- LGPD 준수: PDF는 메모리 내에서 처리되며 추출 후 삭제됩니다

모든 것을 바꾼 접근 방식: 명세 기반 개발 (Specification-driven development)

이 여정에서 강조하고 싶은 기술적 교훈이 있다면, 그것은 특정 기술에 관한 것이 아닙니다.

바로 프로세스에 관한 것입니다.

Quita의 상당 부분은 SDD(Software Design Documents, 소프트웨어 설계 문서)를 통해 구축되었습니다. 코드 한 줄을 쓰기 전에, 저는 의도를 먼저 작성했습니다. 시스템이 무엇을 해야 하는지, 왜 해야 하는지, 제약 조건은 무엇인지, 흐름은 어떠해야 하는지, 경계 조건(edge cases)에서의 예상 동작은 무엇인지를 정의했습니다.

이 습관은 제가 구축한 결과물의 품질을 변화시켰습니다.

구현하기 전에 명세를 정의하면, 떠오르는 질문의 성격이 달라집니다. 사용자에 대해, 리스크에 대해, 그리고 무언가 잘못되었을 때 어떤 일이 발생하는지에 대해 자문하게 됩니다. 모호함이 버그가 되기 전에 이를 발견하게 됩니다.

AI는 코드 생성기가 아닌 분석 파트너로서 이 과정에 참여했습니다. 저는 사양(specification)을 제시하고 다음과 같이 함께 질문했습니다: 이 부분이 명확한가요? 제가 놓친 케이스가 있나요? 이 맥락에서 이 결정이 타당한가요?

많은 순간, 작업은 프로그래밍보다 사고하는 것에 더 가까웠습니다.

현재 작동하고 있는 것들

백엔드(backend)는 Railway에서 프로덕션(production) 환경으로 운영 중입니다. 핵심 기능(core functionalities)은 모두 검증되었습니다:

• JWT 등록 및 인증
• Registrato 업로드 및 처리
• 부채 자동 추출
• 인사이트(insights) 생성
• Gemini를 통한 민원(complaint) 생성
• 민원을 PDF로 내보내기

프론트엔드(frontend)는 통합의 마지막 단계에 있으며, Vercel에 배포될 예정입니다.

앞으로의 계획

다음 단계는 첫 번째 공개 기능 버전(public functional version)입니다. 완전한 웹 인터페이스, 프로덕션 환경의 백엔드 통합, 그리고 실제 사용자가 접근 가능한 전체 플로우(flow)를 포함합니다.

그 이후의 계획은 다음과 같습니다:

• 신규 사용자를 위한 가이드형 온보딩(onboarding)
• 지원되는 문서 유형의 확장
• 민원 생성 모델의 고도화

- 수익화(monetization) 가능성 검토

이 프로젝트가 나에게 가르쳐준 것

가상의 프로젝트는 문법(syntax)을 가르쳐줍니다. 실제 프로젝트는 엔지니어처럼 생각하는 법을 가르쳐줍니다.

그 차이는 실제 문제가 만들어내는 압박감에 있습니다. 도움을 받을 수 있는 누군가가 반대편에 있다는 것을 알게 될 때, 결정에는 무게가 실립니다. 단계를 건너뛰지 않게 됩니다. 해피 패스(happy path)에서만 작동하는 솔루션은 받아들이지 않게 됩니다.

그리고 아마도 이 여정에서 얻은 가장 솔직한 교훈은, AI가 소프트웨어 엔지니어링(software engineering)을 대체하는 것이 아니라 증폭시킨다는 점일 것입니다. 당신이 무엇을 만들고 싶은지 알고, 문제에 대해 명확성을 가질 때 AI는 가속화합니다. 하지만 그렇지 못할 때, AI는 단지 혼란을 더 빠르게 생성할 뿐입니다.

Quita는 아직 완성되지 않았습니다. 하지만 그 어느 때보다 완성에 가까워졌습니다.

그리고 이 프로젝트는 실제 기술을 사용하여, 실제 사람들을 위해, 실제 문제를 해결하기 위해 구축되었습니다.