AI 시대, 아키텍처는 여전히 의미가 있을까?

들어가며

오늘 사내 소프트웨어 아키텍처 기본 강의를 들었다. 비전공자로 인공지능 도메인에서 대학원과 현재 회사 경력까지 합하면 이제 전체 사회 경험의 절반 정도가 되어가고 있다. 여전히 IT에 대한 근본적인 이해가 부족하다고 느껴서 신청한 강의였는데, 막상 듣고 보니 강의 내용보다 머릿속에서 더 많은 질문들이 소용돌이쳤다.

AI 에이전트 개발에 best practice는 무엇일까?

이 질문이 자꾸 머릿속에 맴돌았다. 실제 코드가 돌아가기 전에, 그리고 실제 그 서비스의 도메인을 충분히 이해하기 전에 "이것이 best practice다"라고 판단할 수 있을까?

결정론적 세계의 종말

전통적인 소프트웨어 아키텍처는 통제와 예측을 위한 것이었다. 입력 A를 넣으면 반드시 출력 B가 나와야 하는 '결정론적 시스템'을 견고하게 만들기 위해 우리는 수많은 패턴을 배우고 설계 리소스를 쏟아부었다.

하지만 지금 우리가 다루는 핵심 엔진(LLM)은 확률론적이다. 같은 입력을 넣어도 상황에 따라, 모델의 컨디션에 따라 다른 출력이 나올 수 있다.

이런 불확실성을 가진 엔진을 시스템의 심장부에 통합해야 하는 상황에서, "완벽한 설계 후 구현"이라는 기존의 방법론은 무력해진다.

그렇다면 기존 방식의 아키텍처링이 여전히 의미가 있을까?

더군다나 몇 개월이면 기술의 수준이 완전히 달라지는 도메인에서, 정답이라고 생각한 것이 정말 정답일까? 솔직히, 빅테크 기업들이 쏟아내는 에이전트 white paper나 가이드 문서들이 실제 개발자들에게 미치는 영향력은 극히 미미할 것 같다는 생각이 든다.

새로운 아키텍처의 단면: AGENT.md

이미 현업에서는 흥미로운 변화가 일어나고 있다. 거창한 아키텍처 문서 대신, AI 코딩 도구(Cursor, Claude Code 등)를 제어하기 위한 .rules.md, AGENT.md, SKILL.md 같은 파일들이 그 역할을 대체하고 있다.

잘 설계된 서비스라면, 이러한 마크다운 파일 몇 개로 AI에게 "우리 서비스의 아키텍처는 이것이니, 이 규칙 안에서 놀아라"라고 가이드할 수 있다.

복잡한 이론보다는 차라리 LangChain Docs를 MCP(Model Context Protocol)로 만들어 AI에게 먹이고, 즉시 실행 가능한 코드를 뽑아내는 것이 더 현실적인 도움을 준다. 어쩌면 이것이 AI 시대의 실질적인 아키텍처 문서가 아닐까?

코드의 '품질'보다 '증명'이 중요한 시대

최근 인상 깊게 본 글이 있다. Simon Willison은 이렇게 말했다:

"Your job is to deliver code you have proven to work."
(당신의 일은 동작이 증명된 코드를 제공하는 것이다.)

그리고 Addy Osmani는 이렇게 정리했다:

"If you haven't seen the code do the right thing yourself, it doesn't work."
(직접 코드가 제대로 동작하는 것을 보지 못했다면, 그 코드는 동작하지 않는 것이다.)

AI 시대에는 **"코드를 얼마나 깔끔하게 잘 짰느냐"보다 "이 코드가 의도대로 동작함을 증명할 수 있느냐"**가 더 중요해졌다. 어쩌면 이건 상당히 급진적인 발상 전환일 수도 있다.

나도 변하고 있다

작년까지만 해도 나는 AI가 생성한 코드를 라인 바이 라인으로 다 검토하고, 수정하고, 판단했다. 하지만 올해는 조금 다른 접근을 시도하고 있다. AI 에이전트의 자율성을 높이고, 나는 설계자이자 관리자의 역할로 이동하려 한다.

그러다 문득 이런 생각이 들었다.

내가 지금 하고 있는 이 일이 아키텍트의 업무인 건가?

AI에게 코드 작성을 맡기고, 나는 전체적인 구조와 방향을 잡아주며, 결과물이 의도대로 동작하는지 검증한다. 그렇다면 오히려 AI 시대에 아키텍트의 역할이 더 중요해진 걸까?

AI 아키텍트에게 필요한 역량

"AI 시대에 아키텍처는 필요한가?"

답은 **"YES, 하지만 역할이 완전히 달라졌다"**이다.

우리는 이제 코드를 직접 쌓아 올리는 '건축가'가 아니라, 뛰어난 능력을 가졌지만 통제가 필요한 AI 인부들을 지휘하는 **'현장 소장'**이 되어야 한다. AI 아키텍트에게 필요한 역량은 UML을 그리는 능력이 아니다:

1. Context Engineering

AI가 맥락을 잃지 않도록 정보를 구조화하는 능력. AGENT.md나 MCP 같은 도구를 활용해 AI가 우리 서비스의 맥락을 이해하도록 만드는 것.

2. Dynamic Evaluation (Evals)

정적인 코드 리뷰 대신, 결과물의 품질을 동적으로 평가하고 측정하는 시스템을 구축하는 능력. AI가 만든 코드가 의도대로 동작하는지 자동으로 검증하는 파이프라인.

3. Environment Setting

AI가 맘껏 뛰어놀되, 사고치지 않도록 가드레일과 샌드박스를 설계하는 능력. 보안, 비용, 성능 측면의 경계를 명확히 설정.

마치며

비전공자 출신으로서 기술의 깊이에 대한 목마름은 여전하다. 하지만 지금은 깊게 파는 것보다, 변화하는 파도 위에서 균형을 잡고 AI라는 강력한 엔진을 어떻게 우리 시스템에 안전하게 안착시킬지 고민하는 **'확률론적 엔지니어링'**이 필요한 시점이다.

나를 포함해서 이 분야의 많은 사람들이 정답을 찾아가고 있는 시대라고 생각한다. 명쾌한 결론은 없다. 어쩌면 지금 이 글을 읽는 분들도 비슷한 고민을 하고 계실 것 같다.

혹시 비슷한 고민을 하고 계신다면, 또는 다른 관점이 있으시다면 댓글로 나눠주시면 감사하겠습니다. 같이 정답을 찾아가는 과정이라고 생각하니까요.

참고 자료

• Your job is to deliver code you have proven to work - Simon Willison
• Code Review in the Age of AI - Addy Osmani