제목
내년에도 직접 '로직'만 짜고 있다면, 당신의 백엔드 커리어는 이미 끝났습니다
본문
솔직히 고백하자면, 불과 2년 전까지만 해도 저는 'AI가 개발자를 대체한다'는 말을 콧방귀를 뀌며 무시했습니다. 스타트업 야생에서 구르며 밤새워 스파게티 코드를 리팩토링하고, 터져 나가는 트래픽을 온몸으로 막아내던 저에게 AI는 그저 흥미로운 장난감처럼 보였기 때문입니다. 하지만 최근 규모 있는 기업으로 이직해 더 복잡하고 거대한 시스템을 마주하면서, 그리고 Seer와 같은 도구가 등장하는 흐름을 보며 등줄기에 식은땀이 흐르는 것을 느꼈습니다. 우리가 알던 전통적인 백엔드 개발, 즉 비즈니스 로직을 한 줄 한 줄 짜서 API를 만드는 시대는 저물어가고 있습니다. 이제 우리는 코드를 작성하는 사람(Coder)이 아니라, AI와 결정론적 시스템을 조율하는 설계자(Architect)가 되어야만 생존할 수 있는 시점에 와 있습니다.
제가 겪었던 뼈아픈 실패담을 하나 들려드리겠습니다. 얼마 전 사내 업무 자동화를 위해 LLM을 활용한 에이전트 시스템을 구축하려 했습니다. 당시 저는 자신만만하게 LangChain을 끌어와 모든 처리를 하나의 거대한 '지능형 에이전트'에게 맡겼습니다. 결과는 처참했습니다. 에이전트는 툭하면 환각(Hallucination) 증세를 보이며 엉뚱한 데이터를 DB에 집어넣으려 했고, 디버깅은 불가능에 가까웠습니다. 어디서부터가 결정론적인 로직이고, 어디서부터가 LLM의 확률적 추론인지 경계가 모호했기 때문입니다. 팀원들에게 "이거 왜 안 돼요?"라는 질문을 받을 때마다 "AI가 오늘은 컨디션이 안 좋네요"라고 농담처럼 넘겼지만, 속으로는 막막함에 가슴이 타들어 갔습니다. 그때 깨달았습니다. 모든 것을 '대화형 에이전트'로 해결하려는 접근 자체가 아키텍처 관점에서 완전히 틀렸다는 사실을 말입니다.
최근 오픈소스로 공개된 Seer를 분석하며 무릎을 탁 쳤던 이유가 바로 여기에 있습니다. 이 도구는 명확한 철학을 가지고 있습니다. "워크플로우(Workflow)와 에이전트(Agent)는 본질적으로 다르다"는 것입니다. 워크플로우는 노드 기반의 결정론적 실행을 보장해야 하고, 에이전트는 메시지 기반의 동적인 대화를 처리해야 합니다. Seer는 이 둘을 억지로 섞지 않고 API 레벨에서부터 분리했습니다. UI/UX에서 이 둘이 다르다면, 백엔드 아키텍처인 API에서도 당연히 달라야 한다는 이들의 원칙은 저처럼 엔터프라이즈 환경에서 안정성을 고민하는 개발자에게 시사하는 바가 큽니다. 패턴 매칭이나 어설픈 변환 레이어로 퉁치는 것이 아니라, 근본적인 데이터 구조와 멘탈 모델을 분리함으로써 유지보수성과 확장성을 확보한 것입니다.
실제로 Seer를 로컬 Docker 환경에 띄워 테스트해보며 저는 생산성의 격차를 실감했습니다. FastAPI 기반의 백엔드와 Taskiq 워커가 유기적으로 돌아가는 구조 위에서, 저는 더 이상 복잡한 연동 코드를 직접 짜지 않았습니다. 시각적 편집기(Visual Editor)에서 드래그 앤 드롭으로 노드를 연결하고, GitHub 이슈 관리나 구글 워크스페이스 연동 같은 기능을 블록처럼 쌓아 올렸습니다. 중요한 것은 이 과정에서 AI가 코드 작성을 보조해주고, 개발자는 전체적인 흐름(Flow)과 보안 범위(Scope)를 통제하는 데 집중한다는 점입니다. 특히 '읽기 전용 인증 범위(read-only auth scopes)'와 같은 보안 장치는 기업 환경에서 외부 도구를 도입할 때 가장 큰 걸림돌인 보안 문제를 해결할 수 있는 실마리를 제공합니다.
앞으로 우리 백엔드 개발자의 역할은 단순히 CRUD API를 만드는 것에서 '오케스트레이션(Orchestration)'으로 빠르게 이동할 것입니다. Seer와 같은 도구들이 보여주듯, 결정론적인 비즈니스 로직과 확률적인 AI 에이전트를 얼마나 능숙하게 결합하고 제어하느냐가 개발자의 몸값을 결정하게 될 것입니다. 변화가 두려운 것은 저도 마찬가지입니다. 익숙한 코드 에디터보다 생소한 워크플로우 빌더 화면이 더 많아지는 미래가 어색하기도 합니다. 하지만 변화를 거부하고 도태되기보다, 이 새로운 도구들을 내 무기로 삼아 더 거대한 가치를 만들어내는 것이 8년 차 개발자로서, 그리고 앞으로 살아남을 엔지니어로서 가져야 할 태도라고 생각합니다. 지금 당장 여러분의 아키텍처를 점검해 보십시오. 혹시 확률과 로직을 한 바구니에 담고 있지는 않습니까?
