AI 시대 개발자가 알아야 할 아키텍처 언어 8가지

AI가 코드를 작성해주는 시대가 되면서 개발자의 역할은 조금씩 바뀌고 있다.

이제 개발자가 늘 물어야 하는 질문은 단순히 “어떻게 구현할까?”가 아니다. 오히려 더 중요한 질문은 이것에 가깝다.

이 시스템은 무엇 때문에 이런 구조가 되어야 하는가?

예를 들어 면접이나 실무 회의에서 이런 요청을 받았다고 해보자.

인기 콘서트 티켓 예매 시스템을 설계해보세요.

많은 개발자는 곧바로 기술을 떠올린다.

• Redis를 써야 하나?
• Kafka를 붙여야 하나?
• 좌석 중복 예매를 막으려면 분산 락이 필요할까?
• 트래픽이 몰리면 오토스케일링을 어떻게 해야 할까?

이 고민들이 틀렸다는 뜻은 아니다. 다만 출발점으로는 너무 빠르다. 아키텍처 설계는 특정 기술을 고르는 일에서 시작하지 않는다. 먼저 요구사항을 구조에 영향을 주는 설계 언어로 바꿔야 한다.

이 글은 코딩하는기술사님의 영상 AI 시대, 개발자가 알아야 할 아키텍처 용어 8가지를 바탕으로, 개발자가 AI 시대에 익혀야 할 아키텍처 언어를 정리한 글이다.

AI에게도 모호한 지시는 모호한 결과를 만든다

AI에게 이렇게 요청했다고 해보자.

캐시 좀 넣어줘.
성능 좋게 만들어줘.
안 죽게 해줘.

AI는 무언가를 만들어줄 수 있다. 하지만 이 요청에는 기준이 없다. 어느 구간의 성능을 좋게 해야 하는지, 어느 정도의 가용성을 목표로 하는지, 어떤 제약 안에서 설계해야 하는지 알 수 없다.

반면 다음처럼 요청하면 완전히 달라진다.

우리 시스템의 아키텍처 드라이버는 티켓 오픈 직후의 대량 트래픽, 좌석 중복 판매 방지, 기존 PostgreSQL 사용 제약이다.
품질 속성은 피크 시간 P95 응답 시간 1초 이내, 오픈 직후에도 서비스 가용성 유지다.
좌석 조회 성능을 개선하기 위한 아키텍처 텍틱을 제안하고, 각 대안의 트레이드오프를 비교해줘.
단, 가용성을 크게 떨어뜨리는 방안은 제외해줘.

같은 AI를 쓰더라도 결과의 품질이 달라진다. AI는 이미 수많은 소프트웨어 설계 문서, 아키텍처 패턴, 품질 속성, ADR 같은 자료를 학습했다. 그래서 우리가 정확한 설계 언어를 사용할수록 AI도 더 정확하게 일할 수 있다.

결국 AI 시대의 개발자에게 필요한 능력은 “프롬프트를 예쁘게 쓰는 기술”이 아니라, 문제를 아키텍처 언어로 번역하는 능력이다.

1. 아키텍처 드라이버: 설계를 움직이는 핵심 요인

아키텍처 드라이버는 시스템의 구조와 중요한 설계 결정에 큰 영향을 미치는 핵심 요인이다.

대표적으로 다음이 포함된다.

• 핵심 기능
• 품질 속성
• 제약 사항

중요한 점은 모든 요구사항이 아키텍처 드라이버는 아니라는 것이다.

티켓 예매 시스템에서 다음 요구사항은 아키텍처 드라이버가 될 수 있다.

• 티켓 오픈 직후 수십만 명이 동시에 접속한다.
• 같은 좌석이 두 명 이상에게 판매되면 안 된다.
• 기존 PostgreSQL을 사용해야 한다.
• 기존 결제 시스템과 연동해야 한다.
• 앞으로 여러 공연에 재사용할 수 있어야 한다.

이 요구사항들은 시스템 구조에 직접적인 영향을 준다. 데이터 저장 방식, 락 전략, 캐시 전략, 대기열, 결제 상태 관리, 장애 대응 방식까지 바꿀 수 있다.

반면 다음 요구사항은 중요하더라도 아키텍처 드라이버라고 보기 어렵다.

• 관리자 화면에 매출 조회 메뉴를 추가한다.
• 회원 등급을 3단계에서 5단계로 늘린다.
• 결제 수단을 하나 더 추가한다.

이런 요구사항이 쉽다는 뜻은 아니다. 다만 시스템의 큰 구조를 바꾸지 않고도 수용할 수 있다면 아키텍처 드라이버는 아니다.

아키텍처 설계의 첫 단계는 요구사항 목록을 그대로 구현 항목으로 나누는 것이 아니다. 그중에서 시스템 구조를 실제로 밀어붙이는 요인이 무엇인지 식별하는 것이다.

2. 품질 속성: 기능이 얼마나 잘 동작해야 하는가

기능 요구사항은 시스템이 무엇을 해야 하는지를 말한다.

사용자는 좌석을 선택하고 결제할 수 있다.

반면 품질 속성은 그 기능이 얼마나 잘 동작해야 하는지를 말한다.

티켓 오픈 직후에도 좌석 조회 요청의 95%는 1초 이내에 응답해야 한다.
월간 가용성은 99.9% 이상이어야 한다.
피크 시간 초당 5,000건의 요청을 처리할 수 있어야 한다.

품질 속성은 흔히 비기능 요구사항이라고도 부른다. 성능, 가용성, 확장성, 보안성, 유지보수성 등이 여기에 해당한다.

여기서 핵심은 품질 속성을 측정 가능한 형태로 바꾸는 것이다.

나쁜 요구사항은 대개 이렇게 생겼다.

• 빠르게 만들어주세요.
• 안정적으로 만들어주세요.
• 사용자 친화적으로 만들어주세요.
• 트래픽이 많아도 잘 버티게 해주세요.

이런 표현은 기준이 없다. 무엇을 만족해야 성공인지 알 수 없다. 좋은 품질 요구사항은 다음처럼 검증 가능한 형태여야 한다.

• 피크 시간 P95 응답 시간 1초 이내
• 월간 가용성 99.9%
• 티켓 오픈 직후 10분 동안 초당 5,000건 요청 처리
• 좌석 중복 판매 0건
• 장애 발생 시 3분 이내 자동 복구

측정 가능한 기준이 있어야 설계 대안을 비교할 수 있다. 그리고 AI가 만든 결과물도 검증할 수 있다.

3. 아키텍처 텍틱: 품질 속성을 달성하기 위한 전략

아키텍처 텍틱은 특정 품질 속성을 달성하거나 개선하기 위한 설계 전략이다.

성능을 높이기 위한 텍틱은 이런 것들이다.

• 캐시
• 병렬 처리
• 비동기 처리
• 데이터 사전 계산
• 읽기/쓰기 분리

가용성을 높이기 위한 텍틱은 다음과 같다.

• 이중화
• 페일오버
• 헬스 체크
• 서킷 브레이커
• 재시도와 타임아웃

보안을 높이기 위한 텍틱도 있다.

• 인증과 인가
• 암호화
• 감사 로그
• 입력 검증
• 권한 분리

하지만 하나의 텍틱이 하나의 품질 속성에만 영향을 주는 것은 아니다. 캐시는 성능을 높일 수 있지만 데이터 일관성을 해칠 수 있다. 재시도는 일시적 장애에는 강해지지만, 잘못 설계하면 중복 처리나 부하 증폭을 만들 수 있다.

그래서 텍틱은 항상 트레이드오프와 함께 봐야 한다.

4. 아키텍처 스타일: 시스템 전체의 골격

아키텍처 스타일은 시스템 전체를 어떤 방식으로 구조화할 것인지에 대한 큰 틀이다.

대표적인 예시는 다음과 같다.

• 레이어드 아키텍처
• 클라이언트-서버
• 이벤트 드리븐 아키텍처
• 마이크로서비스 아키텍처
• 파이프 앤 필터

아키텍처 텍틱이 특정 품질 속성을 개선하기 위한 전략이라면, 아키텍처 스타일은 시스템 전체의 골격을 결정한다.

예를 들어 마이크로서비스 아키텍처를 선택하면 서비스별 독립 배포와 확장에는 유리하다. 하지만 네트워크 통신, 분산 트랜잭션, 장애 추적, 운영 복잡도는 증가한다.

아키텍처 스타일은 한번 정하면 바꾸기 어렵다. 그래서 유행하는 스타일을 고르는 것보다, 현재 시스템의 아키텍처 드라이버와 품질 속성에 맞는지를 먼저 따져야 한다.

5. 아키텍처 패턴: 반복되는 문제에 대한 검증된 해법

아키텍처 패턴은 반복적으로 등장하는 설계 문제에 대한 검증된 해결 방식이다.

예시는 다음과 같다.

• Cache Aside Pattern
• Circuit Breaker Pattern
• CQRS
• Saga Pattern
• API Gateway Pattern
• Event Sourcing

아키텍처 스타일과 패턴은 문맥에 따라 혼용되기도 한다. 그래도 대략적으로는 이렇게 구분할 수 있다.

구분	의미	예시
아키텍처 스타일	시스템 전체 구조	레이어드, 이벤트 드리븐, 마이크로서비스
아키텍처 패턴	특정 문제에 대한 해결 방식	Cache Aside, Saga, CQRS
아키텍처 텍틱	특정 품질 속성을 달성하기 위한 전략 수단	캐시, 이중화, 재시도, 병렬 처리

캐시를 예로 들어보자.

“성능을 위해 캐시를 사용한다”는 것은 텍틱이다. “Cache Aside 패턴으로 캐시를 구성한다”는 것은 패턴이다. 이 캐시 전략이 시스템 전체 구조와 데이터 흐름에 영향을 준다면 더 큰 아키텍처 결정이 된다.

패턴은 설계 문제를 빠르게 설명하고 공유할 수 있는 언어다. 하지만 패턴 자체가 정답은 아니다. 항상 현재 시스템의 맥락과 품질 속성에 맞는지 검토해야 한다.

6. 트레이드오프: 얻는 것과 잃는 것

아키텍처 설계에서 공짜 선택은 거의 없다. 어떤 장점을 얻으면 대개 그에 따른 비용이나 단점도 생긴다. 이것이 트레이드오프다.

예를 들어 캐시를 도입하면 다음을 얻을 수 있다.

• 응답 속도 향상
• 데이터베이스 부하 감소
• 읽기 처리량 증가

하지만 다음을 감수해야 한다.

• 데이터 일관성 문제
• 캐시 무효화 비용
• 캐시 장애 대응
• 운영 복잡도 증가

마이크로서비스도 마찬가지다. 서비스별 독립 배포와 개별 확장에는 유리하지만, 네트워크 복잡도와 분산 트랜잭션 문제, 관측성 비용, 운영 난이도는 올라간다.

아키텍처는 멋진 기술을 고르는 일이 아니다. 우리 상황에서 무엇을 얻고, 무엇을 감수할지 결정하는 일이다.

좋은 아키텍트는 “이 기술이 좋은가?”보다 “우리의 드라이버와 품질 속성을 고려했을 때 이 트레이드오프를 감수할 수 있는가?”를 묻는다.

7. 아키텍처 디시전: 대안 중 하나를 선택하는 일

아키텍처 디시전은 여러 설계 대안과 트레이드오프를 비교한 뒤 내리는 중요한 설계 결정이다.

예를 들어 좌석 조회 성능을 개선하기 위해 다음 대안을 검토할 수 있다.

대안 1. 캐시 없이 DB 직접 조회

구조는 단순하다. 캐시 불일치 문제가 없다. 하지만 티켓 오픈 직후 대량 트래픽이 몰리면 DB 부하가 급격히 증가할 수 있다.

대안 2. 로컬 캐시 사용

네트워크 호출 없이 빠르게 응답할 수 있다. 하지만 서버 인스턴스가 여러 대라면 인스턴스 간 캐시 불일치 문제가 생길 수 있다.

대안 3. Redis 공유 캐시 사용

여러 인스턴스가 같은 캐시를 공유할 수 있고 DB 부하를 줄일 수 있다. 하지만 Redis 운영 비용, 네트워크 호출 비용, 캐시 일관성 문제가 생긴다.

이런 대안들을 비교한 뒤 “우리 시스템에서는 Redis 공유 캐시를 사용한다”라고 결정하는 것이 아키텍처 디시전이다.

중요한 것은 결정 자체보다 결정의 근거다.

• 왜 이 대안을 선택했는가?
• 어떤 대안을 버렸는가?
• 무엇을 얻고 무엇을 감수하기로 했는가?
• 감수한 위험은 어떻게 완화할 것인가?

이 질문에 답할 수 있어야 좋은 아키텍처 결정이다.

8. ADR: 아키텍처 결정을 기록하는 문서

ADR은 Architecture Decision Record의 약자다. 중요한 아키텍처 결정을 기록하는 문서다.

ADR에는 보통 다음 내용이 들어간다.

• 어떤 문제가 있었는가
• 어떤 맥락과 제약이 있었는가
• 어떤 대안들을 검토했는가
• 최종적으로 무엇을 선택했는가
• 왜 그 선택을 했는가
• 어떤 결과와 트레이드오프가 예상되는가

아키텍처 결정은 시간이 지나면 이유가 사라진다. 코드에는 결과만 남고 맥락은 사라진다.

나중에 누군가는 이렇게 묻게 된다.

왜 굳이 Redis를 썼지?
왜 이 부분은 이벤트 기반으로 만들었지?
왜 DB를 나누지 않았지?
왜 이 구조가 이렇게 복잡하지?

ADR은 이런 질문에 답하기 위한 기록이다. 아키텍처는 코드만으로 설명되지 않는다. 중요한 결정일수록 그 결정의 이유를 문서로 남겨야 한다.

설계 사고 흐름으로 연결하기

이 8가지 용어는 따로 외우는 단어장이 아니다. 실제 설계에서는 하나의 흐름으로 연결된다.

1. 비즈니스 목표와 요구사항을 듣는다.
2. 그중 아키텍처 드라이버를 식별한다.
3. 드라이버를 핵심 기능, 품질 속성, 제약 사항으로 나눈다.
4. 모호한 품질 요구사항을 측정 가능한 기준으로 바꾼다.
5. 가능한 아키텍처 텍틱, 스타일, 패턴을 탐색한다.
6. 각 대안의 트레이드오프를 비교한다.
7. 현재 상황에 맞는 아키텍처 결정을 내린다.
8. 그 결정을 ADR로 기록한다.

이 흐름은 항상 직선으로만 진행되지는 않는다. 대안을 검토하다가 다시 드라이버를 수정할 수도 있고, 품질 속성을 재정의할 수도 있다. 고객과 다시 협의해야 할 수도 있다.

그래도 중요한 원칙은 같다. 기술 선택부터 시작하지 않는다. 요구사항을 설계 언어로 번역하고, 그다음 기술을 선택한다.

티켓 예매 시스템 요구사항을 다시 해석해보자

고객이 다음과 같이 말했다고 해보자.

공연과 좌석을 조회하고 원하는 좌석을 선택해서 결제할 수 있어야 합니다.
평소에는 한산하지만 티켓 오픈 직후에는 수십만 명이 동시에 몰릴 수 있습니다.
같은 좌석이 절대로 두 명 이상에게 팔리면 안 됩니다.
사람이 몰려도 서비스가 다운되지 않았으면 좋겠습니다.
사용자가 너무 오래 기다리지 않았으면 좋겠습니다.
기존 결제 시스템과 연동해야 합니다.
데이터베이스는 기존 PostgreSQL을 사용해야 하고, 인프라는 AWS 기반이어야 합니다.
앞으로 다른 공연에도 이 시스템을 계속 사용할 예정입니다.

이 요구사항을 바로 Redis, Kafka, 분산 락 같은 기술로 번역하면 설계가 흔들릴 수 있다. 먼저 아키텍처 드라이버를 식별해야 한다.

핵심 기능

• 공연 조회
• 좌석 조회
• 좌석 선택
• 결제
• 예매 확정

품질 속성

• 티켓 오픈 직후 대량 트래픽 처리
• 좌석 중복 판매 방지
• 서비스 가용성 유지
• 사용자의 대기 시간 최소화
• 향후 여러 공연에 대한 확장성

제약 사항

• 기존 PostgreSQL 사용
• 기존 결제 시스템 연동
• AWS 인프라 사용

그리고 모호한 요구사항은 다시 질문해야 한다.

• “서비스가 다운되지 않는다”는 것은 어느 수준의 가용성을 의미하는가?
• 피크 트래픽은 초당 몇 요청으로 가정할 것인가?
• 사용자가 “너무 오래 기다린다”의 기준은 몇 초인가?
• 좌석 중복 판매는 절대 0건이어야 하는가?
• 결제 실패 시 좌석 점유는 몇 분 동안 유지할 것인가?
• 대기열을 허용할 수 있는가?
• 좌석 조회와 좌석 선점의 일관성 기준은 어떻게 둘 것인가?

이 질문들이 정리되어야 그다음에야 설계 대안을 비교할 수 있다.

예를 들어 다음과 같은 대안들이 나올 수 있다.

• 좌석 조회에 캐시를 둘 것인가?
• 좌석 선점에는 DB 락을 쓸 것인가, 분산 락을 쓸 것인가?
• 결제 완료 전 좌석을 임시 점유할 것인가?
• 대기열을 둘 것인가?
• 이벤트 기반으로 예매 확정 처리를 분리할 것인가?
• PostgreSQL의 트랜잭션을 어디까지 신뢰할 것인가?
• 읽기 트래픽과 쓰기 트래픽을 어떻게 분리할 것인가?

그다음 각 대안의 트레이드오프를 비교하고, 현재 상황에 맞는 아키텍처 결정을 내린다. 마지막으로 그 결정을 ADR에 기록한다.

개발자는 이제 구현자만이 아니다

AI가 코드를 더 잘 작성할수록, 개발자에게 더 중요해지는 능력은 판단력이다.

• 어떤 요구사항이 구조를 바꾸는가?
• 어떤 품질 속성이 중요한가?
• 무엇을 측정 기준으로 삼을 것인가?
• 어떤 텍틱과 패턴을 선택할 것인가?
• 어떤 트레이드오프를 감수할 것인가?
• 왜 이 결정을 했다고 설명할 수 있는가?

이 질문에 답할 수 있어야 한다.

AI 시대의 개발자는 단순히 코드를 많이 쓰는 사람이 아니라, 문제를 구조화하고, 설계 기준을 세우고, AI에게 정확한 언어로 일을 시킬 수 있는 사람이 되어야 한다.

그러기 위해 필요한 것이 아키텍처 용어다. 용어를 외우기 위해서가 아니다. 더 정확하게 생각하고, 더 정확하게 협업하고, 더 정확하게 AI를 활용하기 위해서다.

마무리

아키텍처 설계는 기술 선택의 문제가 아니다. 비즈니스 요구사항을 구조적 판단으로 바꾸는 과정이다.

이때 개발자가 알아야 할 핵심 용어는 다음 8가지다.

1. 아키텍처 드라이버
2. 품질 속성
3. 아키텍처 텍틱
4. 아키텍처 스타일
5. 아키텍처 패턴
6. 트레이드오프
7. 아키텍처 디시전
8. ADR

이 용어들은 각각 따로 존재하지 않는다. 요구사항에서 드라이버를 찾고, 품질 속성을 구체화하고, 텍틱과 패턴을 탐색하고, 트레이드오프를 비교한 뒤, 아키텍처 결정을 내리고, ADR로 기록하는 하나의 흐름으로 연결된다.

AI가 구현을 도와주는 시대일수록 개발자는 더 좋은 질문을 던져야 한다. 그리고 좋은 질문은 좋은 설계 언어에서 나온다.

결국 AI 시대의 개발자에게 필요한 것은 “코드를 대신 써줄 도구”를 잘 쓰는 능력만이 아니다. 무엇을 왜 만들어야 하는지 설계 언어로 정의하는 능력이다.

참고 자료

• AI 시대, 개발자가 알아야 할 아키텍처 용어 8가지 — 코딩하는기술사