SI 프로젝트에서 TA 역할과 사전 준비 체크리스트

SI 프로젝트에서 TA 역할과 사전 준비 체크리스트

대상: SI 수행조직(개발/인프라/보안/운영) · 범위: 착수~오픈/전환 · 관점: 기술 의사결정과 품질·리스크 관리

TA는 무엇을 책임지는가

SI 프로젝트에서 TA(Technical Architect)는 “기술이 일정·비용·품질 목표를 만족하도록 설계와 실행을 연결”하는 역할을 맡습니다. 단순히 아키텍처 다이어그램을 그리는 사람이 아니라, 요구사항(특히 비기능)과 제약조건을 기술 표준과 구현 방식으로 번역하고, 개발·인프라·보안·운영이 같은 방향으로 움직이도록 의사결정 체계를 운영합니다.

실무 기준으로 보면 TA의 핵심 책임은 3가지로 정리됩니다.
1) 기술 선택과 구조를 결정하고(Decision),
2) 그 결정이 구현에서 지켜지도록 가드레일을 만들며(Guardrail),
3) 리스크를 조기 발견해 일정/품질로 번지기 전에 차단하는 것(Risk Control)입니다.

TA가 “결정”하는 것
플랫폼/프레임워크/버전 정책
통합 방식(API, 메시징, 파일 등)
데이터 흐름/트랜잭션 전략
배포/릴리즈 전략(Blue/Green, Canary 등)
표준(코딩, 로깅, 예외, 보안, 성능)

TA가 “보장”하는 것
비기능 요구사항(NFR) 충족 여부
개발-운영 인수 조건과 품질 기준
설계와 구현 간 일관성
장애/보안 사고에 대한 대응 가능성
기술부채의 통제(예외 승인/기한 관리)

단계별 TA 역할 정리

1) 제안/사전 진단(Pre-Sales 또는 착수 전)

• 요구 정리 고객의 목표/KPI, 범위(Scope), 제약(예산·기간·벤더)을 기술 관점으로 재정리
• 리스크 스캔 핵심 연계, 데이터 이관, 보안/규제, 성능 목표, 조직 역량(인력/운영) 리스크 식별
• 가정 명시 “되는 조건”을 문서화(예: 외부 시스템 접근 권한, 테스트 데이터 제공, 인프라 제공 일정 등)

2) 착수/요구사항(Init & Requirement)

• NFR 확정 성능/가용성/보안/확장성/관측성/운영성 요구를 측정 가능한 형태로 합의
• 의사결정 체계 ADR(Architecture Decision Record), 기술위원회(또는 아키텍처 리뷰 보드) 운영 룰 정의
• 표준·가드레일 코드/브랜치/릴리즈/로깅/예외/보안 체크 규칙을 “팀이 바로 쓰게” 제공

3) 설계(Architecture & Detailed Design)

• 상위 아키텍처 논리/물리 아키텍처, 배치, 네트워크 경계, 보안 영역, DR/백업 개념 정리
• 통합 설계 API 계약(스키마/버전), 인증/인가, 타임아웃/재시도, 멱등성, 장애 격리 전략
• 데이터 전략 모델링 원칙, 정합성/동시성, 배치/실시간, 이관/동기화 전략
• 운영 설계 모니터링 지표, 알람, 로그/트레이싱, 런북(장애대응 시나리오)까지 포함

4) 구현/테스트(Build & Test)

• 리뷰/코칭 핵심 모듈의 설계-코드 정합성 리뷰, 성능/보안 위험 코드 조기 제거
• 품질 게이트 정적분석, SAST/DAST, 취약점 스캔, 성능 기준(응답/처리량) 통과 조건 운영
• 통합 테스트 외부 연계/대용량/장애 주입(가능 시) 테스트 시나리오 정의 및 결과 판단

5) 전환/오픈(Cut-over & Go-live)

• 전환 리허설 이관 리허설, 롤백/보정 계획, 커트오버 타임라인, 책임자/연락 체계 확정
• 운영 인수 운영문서/런북/권한/모니터링 대시보드/알람 룰/백업·복구 테스트 결과 인계
• 안정화 오픈 이후 병목(쿼리/캐시/커넥션/스레드 등) 추적, 핫픽스 정책 관리

TA가 프로젝트 후반에 바빠지는 이유
많은 팀이 설계는 일찍 끝내지만, NFR의 “검증”은 뒤로 밀립니다.
TA는 설계서 작성보다, 오픈 직전의 성능/장애/보안 이슈가 “프로젝트 목표를 깨는지” 판단하는 역할이 더 큽니다.
그래서 착수 단계에서부터 NFR을 숫자와 테스트 방법으로 고정해두는 것이 중요합니다.

TA가 관리해야 하는 주요 산출물

의사결정 기록	ADR(결정 배경, 대안, 선택, 영향, 롤백) 기술 표준/금지 목록(버전/라이브러리/구성 원칙) 예외 승인(기간/조건/담당/상환 계획)
아키텍처 설계	논리/물리 아키텍처, 배치/네트워크 경계 통합 아키텍처(API/메시지/파일), 인증/인가 흐름 데이터 흐름(읽기/쓰기, 동기/비동기, 캐시)
NFR 정의/검증	성능 목표(응답/처리량/동시사용자), 자원 제한(커넥션/스레드) 가용성/DR(RTO/RPO), 백업/복구 절차와 테스트 결과 보안(암호화, 접근통제, 감사로그, 취약점 조치 기준)
운영 인수 패키지	모니터링 지표/알람 룰/대시보드, 로그 규약, 트레이싱(해당 시) 런북(장애 시나리오별 조치), 배포/롤백 절차, 권한 목록 운영 점검 체크리스트(일/주/월)

TA 사전 준비 상세 체크리스트

아래는 “착수 전에 준비하면 후반 이슈를 줄이는” 항목들입니다. 프로젝트마다 다르지만, 최소한 이 체크리스트로 빈칸을 없애두면 일정/품질 리스크가 크게 줄어듭니다.

1) 목표·범위·제약을 기술 언어로 고정

• 서비스 목표(KPI)와 장애 허용치(업무 중단 허용 시간, 데이터 손실 허용 범위)를 문장+수치로 정리
• 필수 연계 목록(시스템/담당/프로토콜/인증/테스트 가능 여부) 확보
• 기술 제약(표준 프레임워크, 특정 벤더, 온프레미스/클라우드, 네트워크 구간) 확정
• 성능 가정(피크 트래픽, 동시 사용자, 배치 규모, 데이터 증가율) 수치화

2) NFR 템플릿을 먼저 배포

NFR 합의는 “요구사항 목록”이 아니라 “검증 가능한 계약”입니다.
예: “빠르게”가 아니라 “피크 2,000 동시 사용자에서 p95 1.5초 이하”처럼 정의합니다.
테스트 방법(툴/시나리오/데이터/통과 기준/재시험 조건)까지 한 세트로 잠급니다.

• 성능: p50/p95/p99 기준, 처리량(TPS), 자원 사용률(상한), DB 커넥션/스레드 정책
• 가용성: 배포 중 다운타임 허용치, 무중단 여부, 장애 조치 절차, DR(RTO/RPO)
• 보안: 인증/인가 정책, 암호화 범위(전송/저장), 감사로그, 취약점 조치 SLA
• 관측성: 로그 레벨/구조, 추적 ID, 주요 메트릭, 알람 임계치, 런북 연결

3) 기술 표준(가드레일) 세트를 준비

• 코드 표준: 예외 처리, 에러 코드 체계, 공통 응답 포맷, 국제화/시간대 정책
• 로깅 표준: 필수 필드(요청ID/사용자/거래키), 민감정보 마스킹 규칙, 보관 정책
• API 표준: 버저닝, 스키마 호환성, 타임아웃/재시도, 멱등성 키, 페이지네이션
• 배포 표준: 브랜치 전략, 릴리즈 노트, 롤백 조건, DB 변경(마이그레이션) 절차

4) 기술 의사결정 운영(ADR/리뷰 보드) 준비

ADR 최소 항목
배경/문제 정의
고려한 대안 2~3개
선택한 옵션과 이유
영향(비용/일정/리스크)
롤백/대체 계획

리뷰 운영 룰
무엇을 언제 리뷰할지(상위/상세/핵심 모듈)
승인/반려 기준(성능/보안/NFR)
예외 승인 프로세스(기한/상환 계획)
회의체/의사결정자 명확화

5) 환경·접근·테스트 데이터 사전 확보

• 개발/스테이징/성능/운영 환경 구분과 네트워크 경계(접근 가능 구간) 확정
• 계정/권한: DB, 메시징, CI/CD, 모니터링, 레지스트리, 보안 장비 접근 권한 확보
• 테스트 데이터: 익명화 기준, 데이터 규모(성능 테스트용), 샘플링 정책 합의
• 외부 연계 테스트 가능 여부: 방화벽, 인증서, 샌드박스 제공 일정

6) 성능/장애/보안 “검증 계획”을 착수 전에 만든다

• 성능 테스트 시나리오(업무 흐름 기준)와 합격 기준을 사전에 합의
• 장애 대응 시나리오: DB 장애, 외부 API 지연/장애, 메시지 적체, 디스크 풀 등 “자주 터지는 것” 우선
• 보안 점검: 취약점 진단 범위/일정, 조치 우선순위(High/Medium/Low)와 예외 정책
• 릴리즈 전 “Go/No-Go” 체크리스트(통과 조건) 확정

7) 오픈/전환 사전 리허설 준비

• 커트오버 타임라인(분 단위)과 담당자/연락망, 의사결정자(최종 승인권) 지정
• 롤백/복구 계획: 되돌리는 기준, 데이터 보정 방식, 예상 소요 시간
• 운영 인수 조건: 런북/모니터링/권한/백업·복구 테스트 결과가 없으면 인수 불가로 명시

TA 사전 준비의 실전 포인트
운영 환경에서는 “설계가 맞다”보다 “문제 발생 시 10분 안에 감지하고 30분 안에 복구 가능한가”가 더 중요합니다.
그래서 TA는 관측성(로그/메트릭/알람)과 런북을 설계 범위에 포함시키고, 인수 조건으로 걸어두는 편이 안전합니다.

현장에서 자주 생기는 함정과 예방 팁

NFR이 문장으로만 존재한다

“빠르게/안정적으로/보안 준수”처럼 정성 표현만 남으면, 후반에 누구도 통과 여부를 판단하지 못합니다. TA가 초기에 숫자·시나리오·측정 방식을 고정해야 합니다.

연계는 ‘개발 가능’만 확인하고 ‘운영 가능’을 놓친다

인증서 갱신, 방화벽 변경 절차, 타임아웃/재시도 정책, 장애 시 대체 경로 같은 운영 관점 이슈가 나중에 폭발합니다. 통합 설계 단계에서 운영 시나리오까지 포함해 리뷰하세요.

표준은 있는데 팀이 사용하지 않는다

표준은 문서가 아니라 “개발 흐름에 박혀있는 장치”여야 합니다. 예: PR 템플릿, 린트/정적분석, CI 품질 게이트, 공통 라이브러리로 강제되는 규칙.

요약

• TA는 기술 결정자이면서, 결정이 구현에서 지켜지도록 가드레일을 운영하는 역할입니다.
• 착수 전에 NFR을 “검증 가능한 계약”으로 고정하고, 의사결정/표준/환경/검증 계획을 먼저 준비해야 합니다.
• 오픈 직전 리스크를 줄이려면 관측성·런북·인수 조건을 아키텍처 범위에 포함시키는 것이 실무적으로 가장 효과적입니다.

프로젝트에 맞춰 체크리스트를 더 촘촘히 만들고 싶다면, “업무 도메인(예: 금융/제조/공공)”, “구성(온프레미스/클라우드/혼합)”, “주요 연계 방식(API/ESB/메시지)”을 기준으로 항목을 확장하면 됩니다.