TSkaigi에서 들은 세션 중 특히 인상 깊었던 3개를 참가 메모로서 정리했습니다. TSkaigi에 가지 못한 분들이나, TypeScript × AI 에이전트의 최신 트렌드를 빠르게 캐치업하고 싶은 분들을 위한 내용입니다.

제 개인적인 메모(회장에서의 청강 기록)를 바탕으로 하고 있어, 발표 슬라이드의 코드까지 재현하지는 않았습니다. 각 세션을 「어떤 과제에 · 어떻게 대응하며 · 무엇을 배웠는가」의 입도로 정리했습니다. 자세히 알고 싶은 테마는 꼭 발표자의 자료를 찾아보시기 바랍니다.

선택한 3개 세션의 공통점은 「AI 에이전트를 개발 플로우의 어디에 둘 것인가」라는 설계의 질문이었습니다. 나열해 보면, 마침 「코드를 작성한다 · 리뷰한다 · 도구를 사용한다」의 3단계로 AI를 결합하는 설계가 이야기되고 있었습니다.

풀스택 TypeScript — tRPC × Drizzle로 코드 생성 없이 -
AI 리뷰 운영 — Codex 루프 + 품질 게이트 -
CLI 개발 — AI 에이전트가 사용하는 것을 전제로 설계한다

한마디로 말하면: 코드 생성이라는 단계를 없애면, AI가 돌려도 타입이 어긋나지 않는다.

풀 리뉴얼된 모 어뮤즈먼트 시설의 점포 정보 사이트 개발 사례입니다.

첫날부터 수백만 PV, 콜라보 발표 시 스파이크 액세스가 발생하는 특성을 가진 사이트를, tRPC + Drizzle ORM을 핵심으로 삼아 풀 TypeScript로 구축했다는 이야기였습니다.

tRPC는 서버의 타입을 익스포트(export)하여 클라이언트에 전달함으로써, 중간에 코드 생성(code generation)을 거치지 않고 요청/응답(request/response) 타입을 공유합니다.

Drizzle은 Prisma와 비교했을 때, 스키마를 DSL이 아닌 TypeScript로 정의하는 것이 큰 차이점입니다. SQL과 1대1로 대응하는 쿼리 빌더(query builder)로, ORM적으로도 작성할 수 있습니다. 런타임 의존성이 없어 서버리스(serverless) 환경과의 궁합도 좋다고 합니다.

특히 인상적이었던 것은, 코드 생성이라는 단계가 사라지는 것 자체가 AI와의 궁합 향상에 효과적이다라는 주장입니다.

AI가 「생성해야 할 절차를 스킵한다」거나 「생성된 행을 실수로 편집한다」와 같은 가능성이 제로가 되기 때문에, AI에게 맡겨 돌려도 타입이 어긋나지 않습니다. Hasura처럼 컨테이너를 띄워 GUI로 조작하는 계열의 스택은 이 점에서 상대적으로 AI와 궁합이 나빠지고 있다는 지적은 납득이 갔습니다.

• Aurora Serverless v2 + Aurora Data API 대응 (Drizzle의 강점)으로 개발 초기부터 운영 환경과 동등한 환경을 저비용으로 준비
• DB 결합 테스트에는 나중에 pglite (Wasm용 Postgres)를 도입. 처음부터 이것을 알았다면 Postgres 비대응 드라이버를 넣지 않아도 되었을 것이라는 반성
• Next.js를 Amplify Hosting에 올렸더니 DB에 직접 연결할 수 없어, 나중에 내부 API를 추가하게 됨. Node.js의 취약점 사례도 고려하여 인프라 레벨에서의 보안 담보는 전제로 가져가야 함

💡

꽂힌 한마디

「앱의 코드 품질이 AI로 밑바닥부터 올라가는 시대일수록, 인프라와 DB 선정이 핵심이 된다」

아키텍처를 유연하게 바꿀 수 있는 것이 풀스택 TypeScript의 강점이라는 정리도 납득이 가는 이야기였습니다.

한마디로 말하면: AI가 작성하는 시대, 리뷰를 멈추지 않는 메커니즘과 품질 게이트로 폭주를 억제한다.

GitHub의 2년 치 커밋을 집계했더니 구현량이 명확하게 급증해 있으며, 한 사람이 병행하여 다수의 태스크를 떠안는 것이 당연해지고 있습니다.

「리뷰할 시간은 없지만, 코드가 카오스가 되는 것은 피하고 싶다」 —— 이 딜레마에 대한 구현 해법 이야기입니다.

발표자가 만들고 있었던 것은, Codex에게 리뷰를 시키고 → Codex에게 수정을 시키는 루프를 지적이 없어질 때까지 반복하는 자체 스킬입니다. 요처의 궁리가 효과적이었습니다.

• 리뷰와 수정의 주고받음을 PR 코멘트에 남김 (나중에 프롬프트를 되돌아보며 개선할 수 있음 / 후속 AI가 참조할 수 있음)
• 수정은 별도 세션에서 실행하여 직전 작업의 바이어스(bias)를 배제
• 리뷰 관점은 「PR에 기재된 책임 범위 내에 있는가」 「과부족은 없는가」 「중복 구현이 발생하지 않았는가」 「잠재 버그 (severity 포함)」

Codex의 지적이 제로가 될 때까지 돌리면 버그는 거의 발생하지 않는 느낌이라고 하지만, 부작용으로 루프가 커지면서 구현이 비대해지는 문제가 발생합니다.

⚠️ 최대 20회 루프에서 중단하며, 심할 때는 15회까지 걸려 상당히 기다려야 한다는 생생한 숫자도 공유되었습니다.

비대화를 억제하기 위해 도입한 것이 파일/함수의 행 수, 인수의 수, 중첩 깊이, 안티 패턴(Anti-pattern) 탐지, 순환 복잡도(Cyclomatic Complexity) 등을 확인하는 품질 게이트(Quality Gate)입니다.

TS 주변 도구 약 20개를 묶어 탐지 관점은 약 120개, 규칙 ID(Rule ID)는 약 150개 미만. 도입 후, 원래 7~8 라운드가 소요되던 규모가 큰 프로젝트에서도 라운드 수가 약 절반으로 줄어들었으며, 본질적인 버그를 더 잘 잡아낼 수 있게 되었다고 합니다.

"OK/NG뿐만 아니라 퍼센트로 수치가 나오기 때문에 현재 구현의 좋고 나쁨을 알기 쉽다", "타입(Type)이 있기 때문에 품질 보증의 역할이 살아난다"라는 말에, TypeScript × AI 시대의 품질 보증 방향성이 응축되어 있다는 인상을 받았습니다.

💡

가슴에 와닿은 한마디

"사양(Specification)과 규칙을 문서 및 PR 기술에 상세히 남겨두면, 구현은 어떻게든 된다"

AI가 작성한다는 전제에 서면, 설계 판단의 언어화와 이를 구조적으로 체크하는 메커니즘이 코드의 세부 사항보다 더 높은 가치를 갖게 된다—AI 시대 개발의 무게 중심 이동을 상징하는 이야기였다고 생각합니다.

한마디로 말하면: 사용자는 인간이 아니라 AI. CLI의 UX도 "AI가 해석하기 쉬운가"를 기준으로 다시 설계한다.

"AI 에이전트가 CLI를 사용하는 시대"를 정면으로 포착한 세션입니다.

Google Workspace CLI의 기본값이 JSON 출력이며, 이제는 인간이 직접 사용하는 것을 상정하지 않은 설계로 되어 있다—라는 상징적인 예가 인상적이었습니다.

이 전제를 두면 설계가 바뀝니다. 인간에게는 번거로운 조작이라도, 사양만 확실히 공유된다면 AI는 능숙하게 다뤄줄 것입니다. 따라서 "인간이 사용하기 편한가"보다 "AI가 해석하기 쉬운가"에 최적화할 여지가 생긴다는 정리였습니다.

기능은 3가지 축으로 준비하는 것이 좋다고 제안되었습니다.

긴급 탈출구(Emergency Hatch)의 사고방식은 특히 신선했습니다. CLI 설계자가 모든 유스케이스를 미리 준비하는 것이 아니라, 마지막 자유도를 남겨두면 AI가 채워줄 것이라는 결단입니다.

• JSON 출력뿐만 아니라, 스키마(Schema)를 반환하는 옵션을 준비 (보완 기능이 작동함)
• --help로 사전 컨텍스트(Context)를 제공하고, 에이전트 스킬의 정의도 세트로 제공
• 자기 진단용 doctor 명령어와, 인터페이스로서의 (로그의 위치를 모르면 AI가 곤란해하므로) log 명령어
• 에러 메시지는 What(무엇이 일어났는가)뿐만 아니라, Why(왜 일어났는가)와 How(어떻게 해야 하는가)까지 포함

런타임은 Bun을 채택했습니다. 단일 바이너리 빌드, TS 런타임 + 패키지 매니저를 겸하는 간편함이 이유였습니다. 최근 Node.js의 진화로 상대적으로 희석된 부분도 있지만, 경험과 취향에 따라 채택을 계속하고 있다고 합니다.

이 세션에서 가장 기억에 남은 것은 변화의 속도에 대처하는 자세였습니다.

Claude Code 무제한 플랜 대응으로부터 아직 1년, 런타임 언어의 재작성이 6일 만에 머지(Merge)되는 세상에서, "1년 뒤에 어떻게 될지는 모른다". 그러므로 질문을 바꾸어, **"1년 뒤에도 변하지 않는 것은 무엇인가"**를 생각한다—인터페이스부터 기능·데이터 조작에 이르는 흐름, 품질, 데이터의 중요성.

AI와 함께 CLI를 만들면, 자신 내부의 암묵적인 설계론을 프롬프트(Prompt)로서 외부화하는 것이 강제됩니다. 그 프롬프트와 디스커션(Discussion)이 다시 다음 설계를 낳고, 재학습이 계속 순환합니다.

💡

가슴에 와닿은 한마디

"CLI는 Web 프로덕트보다 작기 때문에, 도그푸딩(Dogfooding)의 고속 사이클을 돌릴 수 있다"—작은 설계 실험장으로서의 CLI라는 관점이 가장 상쾌한 이야기였습니다.

솔직히 말하자면, 이번에 들은 내용 중 피부로 메리트를 체감할 수 있었던 세션은 거의 없었습니다.

이론적으로 이해한 것도 있고, 본 기사에서 깊게 다루지 않은 "Better Auth 이행 — '타입과 런타임'의 SSOT가 config로 쏠린다"와 같이 이론 자체를 제대로 소화하지 못한 것도 있습니다.

어느 쪽이든, 제 안에서 "이것이 효과가 있다면 내가 얼마나 기쁠 것인가"라는 실감이 남지 않습니다. 이는 제 개발 경험의 부족이 원인이라고 생각합니다.

한편으로는 명확하게 느낀 점도 있었습니다.

저는 현재 출시된 기존 시스템에 중간부터 참여하여 개수를 진행하는 업무를 하고 있습니다. 그 과정에서, AI에게 구현을 맡겨 개발을 진행하는 것이 당연해진 지금, 제 업무의 비중이 구현 그 자체에서 설계 판단이나 상위 레이어(Upper Layer)로 옮겨오고 있다는 체감을 하고 있습니다.

코드를 한 줄씩 직접 쓰는 시간은 줄어들고, 대신 다음의 시간이 명확하게 길어졌습니다.

시스템 전체의 설계를 파악하고, 어디에 어떤 처리를 추가할지 판단하는 시간****AI가 내놓은 아웃풋(Output)을 읽고 의도대로인지 확인하는 시간

이것은 기술을 배우지 않아도 된다는 뜻이 아닙니다.

AI에게 어떻게 구현하게 할지 방침을 정할 때, "이쪽이 더 나을 것 같다"라는 체감을 가지고 있으면 판단이 한 단계 빨라진다고 느꼈습니다. 반대로 말하면, 제 안에 비교 대상이 없으면 AI가 내놓은 안을 평가할 축을 가질 수 없습니다.

이번에 소개한 CLI 설계의 3가지 축이나, 코드 폴리스(Code Police)와 같은 품질 게이트(Quality Gate)에 관한 이야기도, 스스로 유사한 판단을 한 번이라도 거쳐 보았다면 "이 부분은 이렇게 판단하면 된다"라고 즉시 손이 움직였을 것입니다.

그렇기에, 인풋(Input)만으로 끝내지 않고, 실제로 사용해 보며 다른 기술과 비교하는 경험을 늘리는 것이 앞으로의 개발에 그대로 직결될 것이라고 생각합니다.

이번에 와닿지 않았던 이야기도, 제가 한 번 빠져서 고생해 본다면 다음에 같은 이야기를 들었을 때 "아, 이거구나"라며 연속성 있게 흡수할 수 있을 것입니다. 다음에 참여할 때는 끌어낼 수 있는 수(手)가 더 늘어나 있으면 좋겠습니다.