제작은 저렴해지고, 이해는 비싸졌다: Proud Tech Summit 2026이 보여주는 프로토타입과 생산 사이의 경계

저는 Starian와 Softplan에서 주최한 Proud Tech Summit 26 온라인 생중계를 따라갔습니다. 이 행사는 소프트웨어 엔지니어링, 레거시 시스템, 프로덕션 환경에서의 에이전트 사용 및 데이터 아키텍처에 초점을 맞춘 약 8시간 분량의 발표로 구성되었습니다.

이 행사는 인터넷을 지배하는 일반적인 인공지능(AI) 이야기에서 벗어났습니다. 채팅의 완성된 시연 대신, 강연들은 실제 문제들을 보여주었습니다: 레거시 관계형 데이터베이스, 작동이 멈추는 통합 시스템, 세금 규정, 그리고 모델을 실제로 고객과 함께 구동시키는 작업 등입니다.

제가 하루 동안 따라간 강연들은 다음과 같습니다:

• Carla Souza, Guilherme Brasil 및 Luis Fausto (Starian 및 Softplan): 기업에서의 AI 개방성과 성숙도.
• Lucas Leung (Oracle Brazil): 포뮬러 1에서 Oracle RedBull Racing을 활용한 시뮬레이션.
• Jean Roloff (Checklist Fácil / Starian): Working Backwards와 SDD를 이용한 Orbit 구축.
• Pedro Escobar (Softplan): 에이전트 거버넌스 및 Softflow 프레임워크.
• Rafael Gomides 및 Amanda Aragão (1Doc / Softplan): 지방 자치 단체에서의 WhatsApp을 통한 공공 서비스 제공.
• Diogo Noschang (Starian): MCP 서버를 이용한 기업 데이터의 거버넌스 및 보안.
• Alexandre Messina (Lovable / VibeLabs): 빠른 프로토타이핑과 Vibe Coding.

세 가지 프롬프트 테스트와 77%가 막힌 지점

개회에서 Carla Souza는 명확한 불균형을 지적했습니다. 도구 구축 속도는 급격히 빨라졌지만, 비즈니스 규칙을 이해하고 시스템을 검증하는 데 필요한 시간은 여전히 인간의 영역이라는 것입니다.

Guilherme Brasil은 동일한 LLM 모델을 사용해 이를 시연했습니다. 그는 숫자 5, 10, 15, 25, 50이 포함된 행사 개막 연설문 32단어 분량을 요청했습니다. 이 단순한 요청에 모델은 성과와 미래에 대한 공허한 기업 슬로건을 생성했습니다. 하지만 그가 실제 맥락(행사 5회차, 회사 창립 10년, 딸 15세, 결혼 25년 차, 나이 50세)을 제공하자, 출력물은 직접적이고 유머러스한 글로 바뀌었습니다. 모델 자체는 변함없었습니다. 단지 입력으로 제공된 맥락에만 차이가 있었던 것입니다.

Luis Fausto는 Gartner와 McKinsey의 데이터를 인용하며 시장의 현재 단계에 대해 이야기했습니다. 기업 중 약 77%가 여전히 초기 테스트 및 개념 증명(PoC)에 갇혀 있는 반면, 단지 23%만이 에이전트 시스템을 실제 운영 환경에 배포하는 데 성공했다고 합니다.

이러한 병목 현상의 원인은 순수하게 운영적인 측면이라고 지적되었습니다. 에이전트가 실제로 운영 환경에서 작동하려면 정의된 책임자, 명확한 서비스 수준 협약(SLA) 규칙, 그리고 오류 발생 시 롤백(rollback) 메커니즘이 필요합니다.

Orbit: 3주, PR/FAQ 및 SDD

Jean Roloff는 Starian의 에이전트 플랫폼인 Orbit을 3주 만에 개발한 과정을 이야기했습니다.

코드를 작성하기 전에 팀은 Amazon의 Working Backwards 접근 방식을 사용했습니다. 제품이 완성된 것처럼 출시 보도 자료(Press Release)와 자주 묻는 질문(PR/FAQ)을 작성했습니다. 목표는 편집기를 열기 전에 고객의 문제점과 기대되는 결과를 맞추는 것이었습니다.

Jean Muller Roloff apresentando a metodologia Working Backwards no Orbit.
Jean Muller Roloff (Starian)가 Working Backwards 및 PR/FAQ 방법론을 Orbit에서 설명하는 모습.

에이전트 기반 구축을 위해 팀은 명세 주도 개발(SDD, Specification-Driven Development) 방식을 채택했습니다. 개방형 프롬프트 대신 데이터 계약, 인터페이스 및 단위 테스트를 먼저 정의한 후 AI가 파일을 생성하도록 트리거했습니다. 이 프로젝트는 90% 이상의 테스트 커버리지를 가진 20만 줄이 넘는 코드를 달성했습니다.

팀은 또한 전체 아키텍처에 계획된 15개의 마이크로서비스를 한 번에 올리는 것을 피했습니다. 대신, 신고 분류(triage)에 초점을 맞춘 '안전 연락(Contato Seguro)' 제품의 특정 부분을 격리하여 실제 데이터를 수집하기 위해 프로덕션에 배포한 후 다른 모듈로 확장했습니다.

Softflow: 220명의 개발자와 네 개의 수동 게이트

Softplan에서 문제는 AI 사용 부족이 아니라, 220명이 넘는 엔지니어들 사이에 분산된 개별 스크립트와 프롬프트의 출현이었고, 이는 코드베이스의 공동 유지보수를 복잡하게 만들었습니다.

Pedro Escobar는 Orchestrator-Workers 패턴 기반의 11단계 프레임워크인 Softflow를 발표했습니다. 이 흐름의 핵심은 필수 중지점(gates)으로, 개발자가 생성된 내용을 검증할 때까지 프로세스가 멈추게 합니다.

Pedro Escobar detalhando subagentes por contexto na Softplan.
Pedro Escobar (Softplan)이 코드 검토를 기반으로 컨텍스트별 서브 에이전트 분할을 발표하는 모습.

이 흐름은 네 가지 주요 단계에서 검증을 구성합니다:

1. 게이트 1 (명세서 작성, Especificação): 에이전트가 작업 항목을 읽고 공식적인 기술 명세서(SDD)를 작성합니다. 이 명세서 승인 전에는 어떠한 코드도 생성되지 않습니다.
2. 게이트 2 (검토 결과 도출, Achados de Revisão): 전담 서브에이전트들이 보안, 성능 및 아키텍처 문제를 추적하며 diff를 분석합니다. 개발자는 무엇을 수정할지 또는 폐기할지를 개별적으로 결정합니다.
3. 게이트 3 (병합 요청, Merge Request): 에이전트가 브랜치를 구성하고 테스트 스위트를 실행하지만, 리포지토리에서의 병합 승인은 여전히 수동입니다.
4. 게이트 4 (종료): 비즈니스 요구사항이 충족되었는지 사람이 확인한 후에 항목을 종료합니다.

실시간 시연에서 Escobar는 IBM Jazz RTC와 같은 레거시 통합의 버그를 해결하는 과정을 보여주었습니다. 이 버그는 API가 담당자 필드를 공백으로 반환하는 문제였습니다. 에이전트는 MCP를 통해 호출하여 작업 항목들을 검사하고 수정 사항을 적용했습니다. MR(Merge Request)을 열기 전에, 한 검토 서브에이전트가 로그 라인 하나에 연관된 단위 테스트가 없다는 점을 지적했습니다. 현장에서 조정이 이루어졌고 병합은 녹색 스위트와 함께 진행되었습니다.

1Doc: WhatsApp을 통한 공공 서비스 제공 및 운영 통제

Rafael Gomides와 Amanda Aragão의 발표는 WhatsApp을 통한 지방 정부 민원 처리 채널(Limeira 지역 LIA 사례 및 Florianópolis 지역 TIA 사례)에 관한 것이었습니다.

공공 서비스를 WhatsApp에 배치하는 것은 앱의 도달 범위를 활용하지만, 아키텍처 측면에서 실질적인 과제를 제기합니다:

Rafael Gomides apresentando contratos de leitura na 1Doc.
Rafael Gomides (1Doc)가 레거시 시스템에 대한 읽기 계약 아키텍처를 설명하는 내용.

일상 대화에서 사람들은 메시지를 잘라 보내거나(truncated), 음성 파일을 보내고 주제를 바꿉니다. 이는 행정 절차 개시 과정에 직접적으로 들어맞지 않습니다. 이 솔루션은 채팅 내부에 양식을 만들고, 복잡한 사례는 현장 채널로 직접 전달하도록 에이전트를 프로그래밍하는 것을 포함합니다.

또 다른 지점은 보안입니다. 전화번호가 시민을 법적으로 식별하지 못하기 때문입니다. 증명서 발급이나 체납액 조회와 같은 경우, 1Doc은 접근 방식을 분리했습니다. 즉, 시민이 임시 링크를 클릭하여 공식 웹 플랫폼에서 인증하며, WhatsApp 채팅에 비밀번호를 전송하거나 개인 데이터를 저장할 필요가 없습니다.

게다가, 지방자치단체의 절차 개시는 메시징 앱의 안정성에 의존하지 않습니다. 등록은 사용자에게 어떤 알림을 보내기 전에 데이터베이스에 트랜잭션 방식으로 저장됩니다.

비용 및 위험 관리를 위해, 지자체는 특정 서비스를 필요할 때 비활성화하는 버튼과 계약 할당량의 50%, 70%, 90%, 100%에서 자동 경고가 발생하는 잠금 기능을 갖추고 있습니다. 한도에 도달하면 AI가 비활성화되고 요청은 표준 대기열로 돌아갑니다.

MCP 서버: 쓰기 권한 없이 IA를 데이터베이스에 연결하기

Diogo Noschang은 AI 모델이 기밀 데이터를 노출하거나 데이터베이스에 부적절한 변경을 일으킬 위험 없이 기업 데이터베이스를 조회할 수 있도록 하는 문제에 대해 논했습니다.

레거시 은행들은 수십 년간의 암묵적인 규칙과 약어 이름의 테이블들을 축적하고 있으며, 모델 언어가 순수한 스키마만 받으면 이를 잘못 해석합니다.

Starian에서는 모델과 회사 데이터베이스 사이에 Python 서버인 Model Context Protocol (MCP)를 배치하는 선택을 했습니다:

분리는 두 가지 수준에서 작동합니다:

1. 논리 계층 (MCP 서버): Python 서비스가 질문 매개변수를 검증하고, SQL 주입 시도를 차단하며, 지나치게 광범위한 요청(예: 필터 없이 전체 테이블을 나열하려는 쿼리)은 거부합니다.
2. 물리 계층 (데이터베이스): MCP가 기업 데이터베이스에서 사용하는 연결 사용자는 SELECT에만 제한된 권한을 가집니다. INSERT, UPDATE 또는 DELETE 부여가 없어 모델 오류가 발생하더라도 프로덕션 레코드 수정이 불가능합니다.

서버는 또한 요청 기반으로 컨텍스트를 로드합니다: 매 상호 작용마다 전체 데이터베이스 스키마를 주입하는 대신, MCP는 특정 메트릭에 응답하는 데 필요한 도구만 제공합니다. Projuris Empresa의 Starian Performance 360 프레임워크의 경우, 시스템은 Jira, SonarQube, GitLab 및 Windsurf를 교차 조회하여 통합하고, 적격 흐름(vazão qualificada)에서 27.3% 증가와 재작업률(taxa de retrabalho) 17.6%를 기록했습니다.

Red Bull Racing: OCI에서의 시뮬레이션

Lucas Leung의 발표에서는 Oracle RedBull Racing이 포뮬러 1에서 고성능 컴퓨팅을 사용하는 내용을 다루었습니다.

레이스 주말 동안, 팀은 Oracle Cloud Infrastructure (OCI)에서 실행되는 500개 이상의 ARM CPU를 갖춘 클러스터를 사용합니다. 노란 깃발이나 세이프티 카 상황에서는 시스템이 초당 최대 백만 개의 몬테카를로 시뮬레이션 피크를 발생시켜, 피트 스톱을 할 가치가 있는지 평가하기 위해 약 6백만 개의 시나리오를 생성합니다.

이 구조는 Max Verstappen의 마이애미 GP 전략을 뒷받침했습니다. 당시 드라이버는 하드 타이어로 9번째 그리드로 출발하여 깨끗한 공기 속에서 초기 스틴트를 늘린 후, 레이스 막바지에 미디엄 타이어를 장착해 우승하는 결과를 얻었습니다. 피트월에서의 결정은 이러한 실시간 확률 계산에 의해 직접적으로 안내되었습니다.

Lovable 및 Vibe Coding: 빠른 프로토타입 대 레거시 시스템

Alexandre Messina는 Lovable의 여정과 Vibe Coding 흐름을 소개하며, 자연어 명령으로부터 작동하는 인터페이스를 생성하는 과정을 보여주었습니다.

언급된 예시 중에는 Amicci의 Amosview가 있었는데, 이는 운영 전문가가 내부 병목 현상을 해결하기 위해 2일 만에 구축한 샘플 관리 시스템이었습니다. 이 과정은 IT 팀의 요청에 의존하지 않았습니다. 제품 아이디어를 검증하거나 개념 증명(PoC)을 설계하거나 간단한 부서별 도구를 만드는 데 있어, 이러한 접근 방식의 속도는 명확합니다.