국내 금융·공공 SI 프로젝트에서 AA, TA, DA가 반드시 필요한 이유

개발자만 늘린다고 프로젝트가 빨라질까?

국내 금융·공공 SI 프로젝트에서 AA, TA, DA가 반드시 필요한 이유

국내 SI 프로젝트를 하다 보면 이런 이야기를 자주 듣는다.

"예산이 없어서 AA는 빼고 갑시다."

"TA는 개발자가 같이 하면 되죠."

"ERD는 개발하면서 만들면 됩니다."

처음에는 비용을 절감하는 것처럼 보인다.

하지만 프로젝트가 끝날 무렵에는 대부분 이런 말을 하게 된다.

"환경이 아직 안 나왔습니다."

"DB가 또 변경되었습니다."

"개발 규칙이 없어서 전부 수정해야 합니다."

"일정이 한 달 밀렸습니다."

신기한 것은 개발자가 부족해서 일정이 밀리는 경우보다, 초기 준비가 안 되어 일정이 밀리는 경우가 훨씬 많다.

특히 금융권과 공공 프로젝트에서는 더욱 그렇다.

프로젝트는 개발부터 시작하지 않는다.

프로젝트는 코딩부터 시작하는 것이 아니다.

순서는 항상 다음과 같다.

text

요구사항
    ↓
아키텍처 설계
    ↓
인프라 구축
    ↓
DB 설계
    ↓
개발환경 구축
    ↓
개발 시작

그런데 현실에서는 이렇게 진행되는 경우가 많다.

text

프로젝트 시작
    ↓
개발자 투입
    ↓
"환경이 아직 안되었습니다."
    ↓
대기
    ↓
회의
    ↓
또 대기

한 달이 지나도 개발을 못하는 경우도 흔하다.

AA (Application Architect)

역할

AA는 개발자가 개발만 할 수 있도록 길을 만들어주는 사람이다.

쉽게 말하면

프로젝트의 개발 표준을 만드는 역할이다.

초기 투입 시 해야 하는 일

개발 프레임워크 선정

예)

Spring Boot
Vue
React
공통 라이브러리

프로젝트 구조 정의

예)

text

controller
service
repository
domain
dto
config
common

공통 개발 규칙

예)

네이밍 규칙
DTO 규칙
Exception 처리
Logging
Validation
Response Format
REST API 규칙

Git 전략

예)

text

main

develop

feature/*

또는

Git Flow

Trunk Based

브랜치 전략 수립

형상관리 정책

Commit Message
Code Review
Merge Rule

공통 라이브러리 제작

예)

text

공통 Exception

공통 Logging

공통 Security

공통 Response

공통 Util

공통 Swagger

개발환경 구축

IntelliJ 설정
VSCode 설정
Formatter
Checkstyle
SonarQube
Docker
Local 실행

개발 가이드 작성

프로젝트 초기에 반드시 작성해야 하는 문서

예)

text

개발 표준서

코딩 컨벤션

API 개발 가이드

DB 사용 가이드

배포 가이드

Git 가이드

AA가 없으면 생기는 문제

대표적으로

사람마다 프로젝트 구조가 달라진다.

text

홍길동

controller
service

----

김철수

api
biz

----

이영희

rest
logic

프로젝트가 하나인데

프로젝트가 세 개처럼 된다.

Exception 처리 방식이 모두 다르다.

java

throw

return

null

Optional

전부 다르다.

API 응답 형식이 모두 다르다.

java

A

{
 result
}

B

{
 data
}

C

{
 success
}

프론트가 가장 힘들어진다.

TA (Technical Architect)

역할

TA는

개발자가 개발할 수 있는 환경을 만들어주는 사람이다.

금융권에서 가장 많이 하는 일

서버 구축

WAS
WEB
DB
Cache

네트워크 구성

DMZ
내부망
업무망

방화벽 신청

금융 프로젝트에서는

방화벽 신청만 며칠에서 몇 주가 걸리는 경우도 많다.

예)

text

개발 WAS

↓

DB

↓

외부 API

↓

SMTP

↓

Redis

↓

Kafka

모든 포트를 신청해야 한다.

SSL 인증서

인증서 적용
TLS 설정

서버 계정 생성

text

DEV

SIT

UAT

PRD

CI/CD 구축

예)

text

Jenkins

GitLab CI

ArgoCD

로그 서버

ELK
OpenSearch

모니터링

Prometheus
Grafana

배포 자동화

Docker

Kubernetes

보안 설정

금융권은 특히 중요하다.

TA가 없으면 생기는 문제

개발자가 서버를 기다린다.

text

이번 주 안됩니다.

다음 주 가능합니다.

방화벽 때문에 API 테스트를 못한다.

text

API 개발 완료

↓

테스트 불가

↓

방화벽 대기

실제 금융권에서 가장 흔한 일정 지연 원인 중 하나다.

서버마다 설정이 다르다.

text

DEV

Java17

------

SIT

Java21

빌드가 안 된다.

운영 배포 시 오류

운영에서만 발생하는 문제가 생긴다.

DA (Data Architect)

역할

DA는

데이터의 기준을 만드는 사람이다.

초기 해야 하는 일

ERD 작성

논리 모델

물리 모델

Naming Rule

예)

sql

TB_MEMBER

TB_ORDER

TB_PAYMENT

컬럼 규칙

sql

REG_DT

UPD_DT

USE_YN

DEL_YN

PK 규칙

Index 규칙

Meta 관리

금융권에서는 매우 중요하다.

예)

sql

회원번호

설명

길이

암호화 여부

PII 여부

코드 관리

공통 코드

은행 코드

국가 코드

상품 코드

SQL 가이드

성능 검토

DA가 없으면

같은 데이터인데 이름이 다르다.

sql

USER_ID

MEMBER_ID

LOGIN_ID

ACCOUNT_ID

사실은 모두 같은 의미다.

컬럼이 계속 늘어난다.

중복 컬럼이 생긴다.

Join가 복잡해진다.

성능이 계속 떨어진다.

Index가 없다.

개인정보 관리가 안 된다.

금융에서는 치명적이다.

현실에서 가장 많이 발생하는 악순환

text

AA 없음
    ↓
개발 규칙이 없음
    ↓
개발자마다 코드 스타일이 다름
    ↓
통합 시 대규모 수정
    ↓
일정 지연

TA 없음
    ↓
방화벽 미신청
    ↓
서버 미구축
    ↓
API 테스트 불가
    ↓
개발 대기
    ↓
일정 지연

DA 없음
    ↓
ERD 변경 반복
    ↓
테이블 수정
    ↓
API 수정
    ↓
화면 수정
    ↓
테스트 재수행
    ↓
일정 지연

결국 일정이 밀리는 이유는 개발 속도가 느려서가 아니라, 개발을 시작하기 위한 기반이 준비되지 않았기 때문인 경우가 많다.

프로젝트 비용은 줄일 수 있지만, 준비 과정은 줄일 수 없다

국내 금융·공공 SI 프로젝트에서는 예산과 일정 때문에 AA, TA, DA를 생략하거나 개발자가 겸임하는 경우가 적지 않다. 하지만 이러한 결정은 초기에는 비용 절감처럼 보일지 몰라도, 개발 지연, 반복 수정, 품질 저하, 운영 장애라는 더 큰 비용으로 되돌아오는 경우가 많다.

AA는 개발의 기준을 만들고, TA는 개발이 가능한 환경을 준비하며, DA는 데이터의 기준을 세운다. 이 세 가지 축이 갖춰져야 개발자는 비로소 기능 구현에 집중할 수 있다.

프로젝트의 성공은 뛰어난 개발자를 많이 투입하는 것만으로 결정되지 않는다. 좋은 개발자가 하루라도 빨리 개발을 시작할 수 있는 환경을 만드는 것, 그리고 모든 팀원이 같은 기준으로 움직일 수 있도록 만드는 것이 성공 확률을 크게 높인다.

국내 SI 현장의 경험을 돌아보면, 일정을 지키는 프로젝트의 공통점은 개발자가 많아서가 아니라 AA·TA·DA가 초기에 해야 할 일을 제때 끝낸 프로젝트였다는 점이다. 프로젝트 규모가 작더라도 이 역할을 완전히 생략하기보다는, 기간과 투입률을 조정해 핵심 산출물을 먼저 마련하는 것이 결과적으로 가장 현실적이고 비용 효율적인 선택이다.

금융권 5개월 프로젝트 현실적인 투입 계획 예시

가정

기간 : 5개월 (약 20주)
개발인원 : 10~20명
Spring Boot + Vue
금융권 신규 구축

기간	AA	TA	DA
착수 ~ 2주	100%	100%	100%
3~4주	100%	100%	100%
2개월차	100%	50~80%	50~70%
3개월차	100%	30~50%	40~60%
4개월차	100%	30%	30~40%
5개월차	100%	50% (배포지원)	30% (데이터 검증)

AA 업무 일정

1개월차 (설계 및 환경 구축)

개발 표준서 작성
개발 가이드
공통 Framework 구축
Git 전략
Branch 정책
Exception 정책
Logging 정책
API 규격
공통 Response
공통 Util
Swagger
JWT/OAuth 구조
Batch 구조
Scheduler 구조
CI/CD 협의
코드리뷰 시작

2개월차

본격적인 개발 시작

AA는

개발자 문의 대응
공통 기능 개발
공통 라이브러리 개선
코드 리뷰
설계 변경 검토
성능 검토

거의 매일 발생한다.

3개월차

개발이 절반 정도 완료되는 시기

AA는

개발 표준 준수 확인
코드 품질 관리
Merge 충돌 해결
성능 개선
API 변경 검토

4개월차

통합 테스트

AA는

장애 대응
공통 버그 수정
배포 검토
Framework 수정
운영 이관 준비

5개월차

오픈 준비

AA는

배포 지원
운영 장애 대응
성능 튜닝
산출물 정리
기술 이전

사실상 프로젝트 종료일까지 참여한다.

TA 업무 일정

TA는 초기에 가장 바쁘다.

1개월차

거의 매일 일이 있다.

서버

WEB
WAS
DB
Redis
Kafka

네트워크

VLAN
Load Balancer
DNS

방화벽

금융권에서 가장 오래 걸리는 업무

예)

text

개발망

↓

검증망

↓

계정계

↓

정보계

↓

외부기관

↓

금결원

↓

공동망

각각 신청한다.

계정 생성

개발계정
운영계정
Jenkins
GitLab

인증서

SSL

전자서명

기관 인증

CI/CD

Jenkins
Nexus
Docker Registry

로그

ELK

Grafana

Prometheus

2개월차

방화벽 추가
서버 증설
성능 테스트 환경
장애 대응

3개월차 이후

주요 업무는

운영 배포
서버 튜닝
장애 대응
성능 개선

정도가 된다.

DA 업무 일정

1개월차

가장 중요한 시기

ERD
테이블
컬럼
PK
FK
Meta
Domain
Code
용어사전

2개월차

개발하면서

컬럼 추가
Index 추가
SQL 검토
Naming 검토

3개월차

성능 검토
실행계획
Index 튜닝
SQL 리뷰

4개월차

데이터 검증
Migration
개인정보 검토

5개월차

운영 데이터 점검
최종 메타 정리
인수인계

현실적인 공수(M/M) 예시

역할	투입 형태	총 공수(M/M)
AA	프로젝트 전 기간 상주	5.0 M/M
TA	초기 집중 + 후반 지원	2.5~3.0 M/M
DA	초기 설계 + 중반 검토 + 마무리	2.5~3.0 M/M

즉, 5개월 프로젝트라면 AA 1명은 프로젝트 시작부터 종료까지 상주하고, TA와 DA는 초기 100% 투입 후 중반에는 30~70% 수준으로 참여하며, 통합 테스트와 오픈 시점에 다시 투입률을 높이는 형태가 금융권 SI에서 가장 흔한 운영 방식입니다.

개인적으로 추천하는 운영 방식

실무에서 프로젝트가 흔들리는 이유는 개발자가 부족해서보다 초기 기술 리더십이 부족해서인 경우가 많습니다. 그래서 금융권 프로젝트라면 다음 구성이 가장 안정적입니다.

AA : 프로젝트 전 기간(5개월) 상주하여 기술 표준, 공통 모듈, 코드 품질, 기술 의사결정을 지속적으로 담당
TA : 착수~2개월은 100% 투입, 이후에는 운영환경·배포·성능 이슈에 대응하는 형태로 유연하게 참여
DA : 초기 데이터 표준과 ERD를 확정하고, 개발 중 변경 관리와 성능 검토를 수행하며 오픈 직전 데이터 품질을 최종 검증

이 구성이 초기 비용은 조금 더 들더라도, 개발 대기 시간과 반복 수정, 통합 테스트 단계의 대규모 재작업을 크게 줄여 결과적으로 일정과 품질을 동시에 확보하는 데 가장 효과적인 방식입니다.

국내 금융·공공 SI 프로젝트에서 AA, TA, DA가 반드시 필요한 이유

중년개발자

개발자만 늘린다고 프로젝트가 빨라질까?