2026 ~ 현재

enqor 앱 아이콘

enqor

1:1 전문가 상담 서비스

enqor

참가 인원
3명
개발 기간
2026.04 ~ 현재
담당
앱 및 서버 개발
주요 기술
Agora(스트리밍), NestJS(GraphQL), Expo

Highlights

Motivation

요즘은 고민이 생기면 ChatGPT 에게 먼저 물어봅니다. 그런데 정작 마음이 복잡할 때는 AI 특유의 영혼 없는 대화에 금세 지치고, 의료나 입시처럼 책임이 따르는 상담에서는 AI 의 답을 그대로 믿기도 어려웠습니다. 몇몇 대화는 아직 사람과 해야 합니다.

의사 같은 전문가부터 연애를 오래 해본 사람까지, 각자 자신 있는 분야로 다른 사람의 고민을 들어주고 수익을 만드는 자리가 필요하다고 봤습니다. 대화 플랫폼을 개발하기 위해 Align Networks 에 합류해 앱과 서버 개발을 맡고 있습니다. 다만, 엔코르는 사람이 직접 프로그래밍하지 않았습니다. 기획서와 디자인을 AI 에이전트가 읽을 수 있게 만들고, 에이전트가 내놓은 결과물을 검증하는 환경을 만드는 게 제 일이었습니다.

Architecture

안정적으로 통화가 연결된 경우만 초 단위로 비용 정산하기

엔코르의 핵심 기능은 영상·음성 통화입니다. 스트리밍은 Agora 를 써서 어려움이 없었지만, 정산 파이프라인은 직접 만들어야 하는 과제였습니다. 모바일은 통신 상태가 나빠지는 일이 잦은 만큼, 정상적으로 이루어진 시간만 정산해야 했고, 초 단위 청구까지 요구되었습니다.

핑으로 정의한 안정적인 통화

먼저 '안정적인 통화'가 무엇인지 정해야 합니다. 이는 서버와 클라이언트가 주고받는 핑으로 정의했습니다. 어느 한 참여자라도 핑이 3번 누락되면 연결에 문제가 있다고 판단하고 정산을 중단합니다. 7번 누락되면 통화가 끊어졌다고 판단하고 세션을 종료하게 만들었습니다.

다음 문제는 매초 정산이라는 요구사항입니다. 처음에는 전체 통화 시간에서 불안정했던 시간을 빼고, 통화가 끝난 뒤 데이터베이스를 한 번 업데이트할 생각이었습니다. 그런데, 요구사항이 생각 이상으로 복잡했습니다. 통화 중에 캐시(앱 안의 재화, '클랩')를 충전할 수 있어야 했고, 충전한 캐시로 서로 선물도 할 수 있으며, 통화 가능 시간이 20초 미만으로 줄면 통화가 곧 끝난다고도 알려줘야 합니다. 충전, 소비, 조회가 모두 실시간으로 이뤄져야 하므로 남은 캐시를 읽기 쓰기가 가벼운 어딘가에 저장하고 처리하는 게 간단하겠다고 판단했습니다.

통화 세션의 잔액

통화가 시작되면 발신자 캐시를 수정할 수 없게 만듭니다. 현재 캐시를 읽어 Redis 의 통화 세션에 복제해두면 이 값이 발신자가 쓸 수 있는 캐시의 원본이 됩니다. 매초 이 값을 줄여 정산하고, 충전이나 선물이 발생하면 이 값을 계속 업데이트합니다. 충전은 결제 기록을 남겨야 하므로 DB 에 추가로 남깁니다. 남은 통화 시간도 이 값을 바탕으로 계산해 클라이언트에 내려줍니다. 통화가 끝나면 DB 에 남은 잔액을 업데이트합니다. 충전·선물을 빼면 통화 한 건의 DB 조작은 시작과 끝 두 번뿐이라, 복잡한 로직을 직관적으로 구현할 수 있었습니다.

AI 의 응답을 사람 병목 없이 검증하기

기획팀이 작성한 파일은 PDF 로 된 기획서와, Figma 로 작성된 디자인 파일입니다. 사람이 읽고 수정하기에는 편하지만 에이전트에게 그대로 제공하면 어느 Figma 노드에 어떤 설명이 들어 있는지 알 수 없습니다. 그래서 Figma 노드와 PDF 페이지를 직접 짝지어 Markdown 으로 작성했고, 곳곳에 메모도 적어봤습니다.

기획서에서 코드까지

이렇게 완성한 약 800줄짜리 기획서를 가지고 AI 에이전트에게 프로젝트를 끝까지 완성하라고 했습니다. 30여 분 만에 프로젝트 하나가 나왔고, 실행해보니 그 결과는 엉망이었습니다. 어느 정도 예상은 했지만 실행조차 안 될 줄은 몰랐고, 겨우 고쳐 로그인 화면에 진입하니 Figma 에 정의된 디자인은 전혀 반영되어 있지 않았습니다. 로그인 같은 기능도 전부 모킹으로 구현된 순 엉터리 프로젝트였습니다.

이 문제를 고문님께 털어놓았는데, '하네스 엔지니어링'이라는 개념을 소개해주셨습니다. 인터넷에 검색해보니 'AI 가 올바른 행동을 할 수 있게 환경을 만드는 것'이라는 모호한 답변만이 나왔습니다. 개념이 완전히 이해되지는 않았지만 고문님 조언을 듣고 훅, 비판적 리뷰어, 테스터를 하나씩 세팅하다 보니 어느새 저만의 하네스가 완성되어 있었습니다.

하네스에서 가장 어려운 것은 '성공 조건'을 정의하는 일입니다. 예를 들어 Figma 에 선언된 디자인대로 퍼블리싱했는지 판정하려면, 그 디자인과 퍼블리싱된 화면이 일치하는지 평가하는 로직이 필요합니다. 처음에는 앱 화면을 캡처해 단순히 비슷한지만 검사했고, 독립적인 서브에이전트가 이 비교를 담당했습니다. 나쁘지 않았지만 그렇다고 좋은 결과물도 아니었습니다. 여기저기 아이콘이 다르고 텍스트 위치가 어긋났습니다. 무엇보다 앱 화면을 캡처해 Figma 와 대조하는 작업이 매우 느리고 토큰을 많이 소비했습니다.

웹으로 먼저 퍼블리싱하는 하네스

이 문제는 expo web 으로 해결했습니다. 먼저 구현하려는 화면을 expo web 으로 퍼블리싱하면, headless 브라우저를 열어 결과를 어렵지 않게 확인할 수 있습니다. 창 크기만 바꾸면 모바일·태블릿 해상도에서 깨지는 영역이 있는지도 바로 보입니다. 이렇게 웹에서 검증이 끝난 코드를 앱으로 옮기는 순서로 바꾸니 평가가 훨씬 싸졌습니다. Figma 와 웹으로 퍼블리싱된 화면이 얼마나 비슷한지는 비판적 에이전트가 판정하되, 아이콘을 직접 생성하지 못하도록 규칙을 넣었고, Figma MCP 에 문제가 생겨 동작하지 않는 경우 하네스가 아예 멈추도록 하는 preflight 절차도 추가했습니다. 그 결과 간단한 화면은 거의 완벽한 수준으로, 복잡한 화면도 70% 정도의 완성도로 나왔습니다.

Retrospective

이번 경험에서, AI 에게 좋은 자료와 환경을 주면 그만큼의 결과가 나온다는 것을 알았습니다. 그리고 AI 가 만들어낸 결과도 '어떻게' 검증하느냐보다는 '어디까지' 검증할지를 생각하는 방향이 옳다고 느꼈습니다.

금융, 우주 산업, 방위 산업처럼 사고 한 번이 참사인 도메인은 모든 코드를 전부 꼼꼼히 검증해야 할 것입니다. 하지만 이번 프로젝트처럼 대부분은 그렇지 않습니다. 개발자는 AI 가 지금 무슨 일을 하고 있고, 이번 일이 끝나면 어디까지 검증해야 하고, 어떤 파일들이 바뀌길 기대하는지 정도만 알면 충분하다고 생각합니다. 그 안에서도 단순한 작업을 AI 가 하고 있다면 몇 번 눌러보고 테스트를 마칠 수도 있고, 핵심 로직이면 설계까지 꼼꼼히 논해야 합니다.

개발자가 코드를 작성하는 사람에서 판단하고 책임지는 사람으로 바뀌었다는 것을, 이 프로젝트에서 확인했습니다.