최근 프론트엔드 생태계를 본격적으로 파고들면서, 컴포넌트 구조와 상태 흐름을 따라가는 것만으로도 벅찰 때가 많았습니다. 기능 구현에 급급해서 코드를 짜다보면(+ AI 딸깍), 전체적인 퍼널이 어떻게 이어지는지 한눈에 파악하기 어려웠습니다. 그러다 우연히 토스 테크 블로그에서 흥미로운 글을 발견해 공유하고 싶어 이 글을 작성하게 되었습니다.
토스 테크 블로그 - AST로 Outdated없는 퍼널 문서 만들기
이 글의 핵심은 "코드를 단순히 실행되는 텍스트가 아니라, 조작 가능한 데이터로 바라본다."라는 것이었습니다. 그냥 노드들을 연결해서 시각화하면 되는거 아니야?라고 생각할 수 있지만, 만약 토스 같이 많은 퍼널을 갖고 있는 경우에는 시각화한 그래프가 거대한 거미줄처럼 어지러울 것입니다. 그래서 토스 팀은 소스 코드를 파싱해 AST(추상 구문 트리)로 변환한 뒤, router.push(), router.replace() 같은 Navigation 관련 노드만 뽑아내어 Mermaid 다이어그램으로 플로우 차트를 자동 생성하게 만들었습니다. 자세한 내용은 글을 직접 읽어보시면 좋을 것 같습니다. 잘 정리되어있습니다.
사실 저는 AST라는 개념 자체를 처음 들어봐서, 이 글의 기술적인 내용이 담긴 본문을 읽기도 전에 CST/AST의 개념부터 다시 공부했답니다.
CST(구문 트리)와 AST(추상 구문 트리)의 개념은 컴파일러 이론에 가깝습니다. 코드를 의미 있는 최소 단위로 쪼개는 '토큰화(Lexing)'와 이를 문법 규칙에 맞게 조립하는 '파싱(Parsing)' 과정을 거치게 되는데요. 이때 괄호나 세미콜론 같은 껍데기를 다 떼어내고, 내 코드의 '의미와 의도'만 뼈대로 남긴 것이 바로 AST입니다.
조금 더 와닿게 예를 들어보겠습니다. 우리가 작성한 const sum = 1 + 2; 라는 코드는 컴퓨터의 눈(파서)을 거치면 단순한 문자열이 아니라 아래와 같은 거대한 JSON 객체 트리가 됩니다.

VariableDeclaration (const 변수를 선언할 거야)
Identifier: sum (변수 이름은 sum 이고)
BinaryExpression (값은 + 연산을 할 건데)
Left: 1 (왼쪽엔 1)
Right: 2 (오른쪽엔 2가 있어)
이처럼 코드가 트리 형태의 데이터로 변환되면 조작이 무궁무진해집니다. 놀랍게도 제가 무심코 쓰던 Babel, ESLint, Prettier가 전부 코드를 이런 AST 객체로 변환해서 읽고, 에러를 찾고, 형식을 맞춘 뒤 다시 코드로 뱉어내는 원리로 돌아가고 있었습니다. 토스 팀 역시 이 원리를 이용해, 수만 개의 노드 중 type이 함수 호출(CallExpression)이고 이름이 router.push인 노드만 찾아내어 시각화를 해낸 것입니다.
이 신선한 충격을 슬랙에 공유했더니, Kevin 테커 디렉터님께서 '의사결정 테이블(Decision Table)'에 관한 좋은 글을 인사이트로 남겨주셨습니다.

토스의 AST 시각화가 '이미 짜여진 복잡한 결과물(코드)'의 흐름을 뼈대만 추려 보여주는 기술이라면, 의사결정 테이블은 애초에 '원인(요구사항)의 흐름'을 탄탄하게 설계해서 빈틈을 없애주는 베이스캠프 같은 기법이었습니다. 둘 다 로직의 복잡도를 낮추고 개발자의 뇌절을 막아준다는 점에서 결이 통했습니다.
지금 당장 토스처럼 AST 파서를 직접 구현해 자동화 시스템을 만들 수준은 아니긴 합니다. 하지만 코드를 대하는 시야가 달라졌습니다. 앞으로 복잡한 분기 처리를 할 때는 의사결정 테이블을 먼저 그려볼 것이고, 제가 짠 코드가 내부적으로 어떤 트리 뼈대를 가질지 한 번 상상하며 구조화하는 연습을 해야될 것 같습니다.
토스의 글을 언급해주신 덕에 처음 봤는데, 퍼널 문서도 만들어서 개발자도 흐름을 쉽게 파악하고, 개발 외에 제품에 기여하는 사람들이 퍼널을 직관적으로 파악하고, 비즈니스 흐름을 볼 수 있다는 점에서 인상적이네요.
글을 읽으면서 제 방식대로 개요화 해보았습니다. 물론 내용은 같아요.
1. AST를 이용, Typescript 코드를 트리 구조로 변환
2. 네비게이팅이 이루어지는 구조 찾기 (재귀적으로 커스텀 훅 내의 네비게이팅도)
3. 네비게이팅이 이루어지는 조건 찾기 (부모 조건문)
4. 이를 다이어그램의 노드로 만들어 연결
복잡한 현실세계에서의 문제를 다루다 보면 비즈니스 로직은 끝없이 복잡해지곤 합니다.
AI를 활용할 때 생산성을 높이기 위해 선언형으로 해결할 수 있다면 좋겠지만 그렇지 않은 문제가 더 많고,
코드를 "읽는" 것 조차 피로를 느끼는 시대에 어쩌면 나쁘지 않은 방법일 수도 있겠다 싶어요.
이런 행위가 의미 있고, 존중 받는 환경에서 일하는 것도 축복일 것 같습니다.
좋은 글 잘 봤어요 !