소프트웨어가 아닌, 사용자를 먼저 코딩해야 하는 이유

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

최근 개발 생산성이 무섭게 오르고 있습니다. Cursor나 Copilot 같은 도구 덕분에 우리는 소위 '바이브 코딩(Vibe Coding)'이라 불리는, 믿을 수 없는 속도로 기능을 구현하는 시대를 살고 있죠. 하지만 솔직히 고백하자면, 저는 가끔 이 속도감이 무섭습니다. 코드가 쏟아져 나오는 속도만큼, 우리가 만드는 소프트웨어의 '품질'도 함께 올라가고 있을까요? 여기서 말하는 품질은 단순히 버그가 없는 상태를 말하는 게 아닙니다.

개발자라면 한 번쯤 들어봤을 유명한 밈이 있습니다. QA 엔지니어가 바(Bar)에 들어가 맥주를 주문합니다. 1잔, 0잔, 심지어 -1잔을 주문해보며 시스템을 테스트하죠. 아무 문제 없었습니다. 그런데 실제 손님이 들어와서 묻습니다. "화장실이 어디죠?" 그 순간 바가 폭발합니다.

우리는 맥주 주문 모듈을 완벽하게 만들었고, 단위 테스트(Unit Test)와 E2E 테스트까지 통과시켰을지 모릅니다. 하지만 정작 맥주를 마신 사람이 겪게 될 생리적 현상, 즉 '화장실'이라는 맥락은 놓쳤습니다. 이것이 바로 우리가 겪는 딜레마입니다. 기능은 완벽한데, 사용자는 떠납니다. 왜 그럴까요? 개발자가 사용자의 삶을 코드만큼 깊이 이해하지 못했기 때문입니다.

풀링포레스트에서도 이 지점을 치열하게 고민하고 있습니다. 우리는 LLM(거대언어모델)이 인터넷상의 방대한 데이터를 통해 인간의 행동 패턴을 학습했다는 점에 주목해야 합니다. 그렇다면, 소프트웨어를 코딩하기 전에 '사용자'를 먼저 코딩해보면 어떨까요?

저는 최근 팀원들에게 /src 폴더를 만들기 전에 /users 폴더를 먼저 정의하자고 제안합니다. 단순히 텍스트로 된 페르소나 문서가 아닙니다. LLM 에이전트가 실행할 수 있는 '살아있는 사용자'를 정의하는 것입니다. 예를 들어 group1/user.md에는 그들의 하루 일과와 배경을, happy-paths/requirement.flow.md에는 그들이 우리 서비스를 통해 얻고자 하는 진짜 목적을 자연어나 의사 코드(Pseudocode)로 적습니다.

이 방식은 기존의 TDD(테스트 주도 개발)와는 출발점이 다릅니다. TDD는 기능을 검증하지만, '사용자 코딩'은 가치를 검증합니다. 우리가 정의한 '에이전트 사용자(Agentic User)'를 시뮬레이션 환경에 풀어놓고, 그들이 우리 소프트웨어와 상호작용하게 만드는 것이죠.

개발자인 우리는 에이전트에게 "이 기능을 만들어"라고 지시하는 대신, "이 사용자를 만족시켜 봐"라고 요청하게 됩니다. 에이전트 사용자가 버튼을 클릭하고, 정보를 읽고, 흐름이 막히면 불평을 쏟아내게 하세요. 그 피드백을 바탕으로 다시 소프트웨어를 수정합니다. 이 과정을 반복하다 보면 불필요한 기능은 깎여나가고, 사용자에게 꼭 필요한 본질만 남게 됩니다. 그것이 바로 '단순함'이라는 궁극의 품질입니다.

전통적인 페르소나나 사용자 스토리와 무엇이 다르냐고 물으실 수 있습니다. 가장 큰 차이는 '실행 가능성'입니다. 종이 위의 페르소나는 말이 없지만, LLM으로 코딩된 페르소나는 실제로 우리 앱을 사용합니다. 인간 개발자가 미처 생각하지 못한 "화장실은 어디죠?" 같은 질문을 에이전트가 던져줄 수 있다는 뜻입니다.

우리는 이제 코드를 짜는 기계가 아니라, 사용자를 설계하는 아키텍트가 되어야 합니다. 소프트웨어를 빌드하기 전에 사용자를 먼저 빌드하십시오. 에이전트 사용자를 정교하게 만들수록, 실제 사용자가 느끼는 소프트웨어의 품질은 비약적으로 상승할 것입니다. 기술이 발전할수록 결국 다시 중요한 것은 '사람'에 대한 이해라는 사실이 참 아이러니하면서도 흥미롭지 않나요?

오늘 여러분의 리포지토리에는 사용자를 위한 코드가 있나요, 아니면 기능만을 위한 코드가 있나요?