HTTP Proxy 및 Traffic Capture
Client의 HTTP 요청을 FlowTool Proxy가 받아 Target Application으로 전달하고, Target의 응답을 다시 Client에게 반환합니다.
이 과정에서 Request와 Response 정보를 Capture하여 하나의 HTTP 통신 기록으로 관리합니다.
프로젝트 · 2026.05 — 2026.07
FlowTool
HTTP Proxy를 통해 Request/Response 데이터를 Capture하고, 저장된 통신 흐름을 Dashboard에서 조회할 수 있는 개발자용 디버깅 도구
Node.jsExpress.jsTypeScriptReactVitePostgreSQLPlaywrightMCPCodexGitGitHub
담당 역할기획 · 시스템 구조 설계 · 요구사항 정의 · 구현 검증 · 프로젝트 관리
처리 규모—
성능 개선—
01 / 프로젝트 개요
FlowTool은 개발 중인 애플리케이션의 HTTP Request/Response 흐름을 Proxy를 통해 수집하고, 저장된 통신 데이터를 Web Dashboard에서 조회할 수 있도록 만든 개발 지원 도구입니다.
Express 기반 Proxy/Backend에서 요청과 응답 정보를 수집해 PostgreSQL에 저장하고, React Dashboard에서 Capture 목록과 상세 데이터를 확인할 수 있도록 구현했습니다.
HTTP 흐름을 가시화하는 기능뿐 아니라, Codex와 MCP를 활용해 요구사항 정의 → 구현 → 자동 검증 → 작업 기록으로 이어지는 AI Agent 기반 개발 프로세스를 함께 실험했습니다.
02 / 해결하려던 문제
애플리케이션 간 HTTP 통신에서 문제가 발생하면 로그와 소스 코드를 각각 확인하며 요청 값, 응답 값, 상태 코드 등을 추적해야 했습니다.
FlowTool에서는 HTTP 통신을 하나의 Capture 단위로 저장하고 조회하여 다음 정보를 한곳에서 확인하는 것을 목표로 했습니다.
- 요청 Method / URL / Query Parameter
- Request Header / Body
- Response Status / Body
- 요청 처리 시간
- 오류 정보
이를 통해 “어떤 요청이 전달되었고 어떤 응답이 돌아왔는지”를 통신 단위로 추적할 수 있는 환경을 구현했습니다.
03 / 주요 기능
Capture Log 저장
Capture한 HTTP 데이터를 PostgreSQL에 저장합니다.
요청 URL과 Method뿐 아니라 Query, Header, Request Body, Response Status, Response Body, 오류 정보 등 HTTP 흐름을 분석하는 데 필요한 정보를 함께 관리합니다.
Capture 목록 조회
저장된 HTTP Capture 기록을 Dashboard에서 목록 형태로 조회할 수 있습니다.
여러 HTTP 요청 중 분석할 대상을 빠르게 식별하고 상세 화면으로 이동할 수 있도록 구성했습니다.
Capture 상세 조회
개별 Capture의 상세 화면에서 요청 정보, Query Parameter, Request Header, Request Body, Response 정보, Response Body, Error Message를 확인할 수 있습니다.
정상 데이터뿐 아니라 Loading, 데이터 없음, 404, API 오류 상태도 구분하여 처리했습니다.
자동 검증
Backend Verification Script와 Playwright를 이용해 주요 동작을 검증했습니다.
특히 목록 조회 → 상세 진입 → 새로고침 → 존재하지 않는 Capture 조회 → API 오류와 같은 사용자 흐름을 실제 브라우저 시나리오로 확인했습니다.
04 / 시스템 구조
등록된 아키텍처 이미지가 없습니다.
구조 설명
FlowTool v1은 Proxy → Capture 저장 → Query API → Dashboard 구조로 구성됩니다.
Client의 요청은 FlowTool Proxy를 거쳐 Target Application으로 전달됩니다. Proxy는 Target의 응답을 다시 Client에게 전달하는 동시에 HTTP Request/Response 정보를 Capture하여 PostgreSQL에 저장합니다.
React Dashboard는 저장된 데이터에 직접 접근하지 않고 Express Backend의 조회 API를 통해 Capture 목록과 상세 정보를 조회합니다. 따라서 HTTP 요청의 실제 전달 흐름과 Capture 데이터의 조회 흐름을 분리해 볼 수 있습니다.
v1의 구현 범위는 Proxy 기반 Capture까지이며, Spring Starter·Node SDK를 통한 애플리케이션 직접 연동 구조는 포함하지 않았습니다.
05 / 주요 기술적 결정
애플리케이션을 수정하는 SDK보다 Proxy 방식을 먼저 선택
고민
HTTP 데이터를 수집하기 위해 애플리케이션 내부에 Capture 코드를 삽입하는 SDK 방식과 외부 Proxy를 통과시키는 방식을 검토했습니다. SDK는 실제 서비스에 자연스럽게 적용할 수 있지만, 언어와 프레임워크별 구현이 필요해 초기 개발 범위가 크게 증가했습니다.
결정
v1에서는 HTTP Proxy 방식으로 범위를 제한했습니다.
이유
- 하나의 구현으로 서로 다른 애플리케이션의 HTTP 통신을 확인할 수 있음
- HTTP Request/Response Capture라는 핵심 아이디어를 빠르게 검증할 수 있음
- SDK 설계 전에 데이터 구조와 Dashboard의 필요성을 먼저 검증할 수 있음
Proxy 방식의 동작 가능성과 함께 대상 애플리케이션의 요청 경로를 Proxy로 변경해야 하는 한계도 확인했습니다. Spring Starter와 Node SDK는 이후 확장 과제로 분리했습니다.
NestJS가 아닌 Express.js 선택
고민
Backend Framework로 구조화 기능이 강한 NestJS와 상대적으로 단순한 Express.js를 검토했습니다. v1은 복잡한 비즈니스 도메인보다 HTTP Capture, 저장, 조회라는 제한된 기능을 빠르게 검증하는 것이 우선이었습니다.
결정
Express.js + TypeScript를 선택했습니다.
이유
- MVP 규모에서 필요한 구조를 직접 통제하기 쉬움
- 불필요한 Framework 추상화를 줄일 수 있음
- Proxy와 Middleware의 HTTP 처리 흐름을 비교적 직접적으로 다룰 수 있음
- AI Agent가 생성한 코드를 리뷰할 때 실행 흐름을 단순하게 유지할 수 있음
기능 확장성보다 HTTP 처리 흐름의 명확성과 MVP 구현 속도를 우선한 결정이었습니다.
단일 Prompt가 아닌 문서 기반 AI 개발 프로세스 구성
고민
Codex에 개별 기능 구현을 반복적으로 요청할 때 Prompt만으로 작업 맥락을 유지하면 세션마다 요구사항이나 구현 기준이 달라질 수 있었습니다. 구현 성공 여부와 작업 결과가 체계적으로 남지 않으면 AI가 만든 코드를 신뢰하기도 어려웠습니다.
결정
요구사항과 작업 절차를 역할별 문서로 분리하고, 구현 이후 자동 검증과 기록을 남기는 프로세스를 구성했습니다.
사용한 문서
- StartTask — 작업 시작 규칙
- CurrentRequirement — 현재 구현 범위
- Progress — 전체 진행 상태
- JournalGuide — 개발 기록 기준
- EndTask — 작업 종료 및 검증 절차
이유
AI Agent의 생산성을 단순 코드 생성량이 아니라 재현 가능한 작업 절차와 검증 가능한 결과로 관리하기 위해서였습니다. 좋은 Prompt 하나보다 요구사항·검증·기록이 연결된 Process가 결과의 일관성을 높인다는 점을 경험했습니다.
06 / 트러블슈팅
Dashboard 조회 요청까지 Capture되어 분석 대상과 관리 트래픽이 혼재
HTTP 데이터를 많이 수집하는 것보다 어떤 데이터를 관찰 대상으로 정의할 것인지 경계를 설정하는 것이 Observability 도구에서 중요하다는 점을 확인했습니다. 현재 범위에서 해결하지 않은 문제를 구현한 것처럼 처리하지 않고 제한사항과 후속 과제로 명시하여, v1의 완료 범위를 명확히 관리했습니다.
정상 응답만 확인하던 상세 화면을 실패 시나리오까지 검증
정상 흐름 하나를 확인하는 것과 기능 전체가 검증된 것은 다르다는 점을 경험했습니다. 특히 AI Agent가 구현한 코드에서는 결과 코드를 그대로 신뢰하기보다 Build → API 검증 → DB 확인 → 실제 사용자 시나리오처럼 여러 계층의 검증 방법을 조합하는 것이 효과적이었습니다.