SI 프로젝트 킥오프 회의실. 발주사 담당자가 명함을 한 장씩 받는데, 직함이 다 낯섭니다.
"저는 이번 차세대 시스템 구축의 PM입니다." "결제·정산 파트는 제가 PL로 맡습니다." "전사 프로젝트 표준과 진척은 PMO에서 봅니다." "결제 솔루션 도입·연동은 저희 SE가 지원합니다." "기술 아키텍처는 TA, 애플리케이션 설계는 AA가 잡았고, DB는 DBA가 운영합니다."
신입 운영 담당자는 속으로 생각합니다. 이 사람들, 다 뭘 하는 거지? PM이랑 PMO는 같은 거 아닌가? AA랑 TA는 또 무슨 차이지?
문제는 단순히 용어를 모르는 게 아닙니다. 누가 무엇에 책임지는지를 모르면, 이슈가 터졌을 때 누구를 찾아가야 하는지를 모릅니다. "테이블 설계가 잘못됐다"를 PM에게 따져도, PM은 "그건 AA에게"라고 넘길 뿐입니다. 이 모듈은 SI/SM 현장에서 만나는 역할들의 책임 경계를 한국 현업 기준으로 정리해, 회의실에서 '누가 누구인지'를 읽어내는 눈을 만듭니다.
- 1PM·PL·PMO·SE·TA·AA·DBA가 각각 무엇을 책임지는지 자기 말로 설명할 수 있다
- 2PM(특정 프로젝트 실행)과 PMO(관리체계·지원·감독)의 차이를 구분해 말할 수 있다
- 3TA(기술 아키텍처)와 AA(애플리케이션 설계)의 책임 경계를 구분할 수 있다
- 4이슈가 발생했을 때 책임 역할을 찾아가는 판단(R&R 매핑)을 할 수 있다
- 5SI 프로젝트 조직도에서 보고 라인(누가 누구에게 보고하는가)을 읽을 수 있다
역할은 '직급'이 아니라 '책임 묶음'이다
이름표가 아니라 R&R로 본다
가장 흔한 오해는 역할을 직급으로 읽는 것입니다. "PM이 제일 높고 PL이 그다음" 식으로요. 현장의 진실은 다릅니다. 역할은 책임과 권한의 묶음(R&R, Role and Responsibility) 이고, 같은 역할이라도 프로젝트 규모에 따라 한 사람이 여러 역할을 겸하기도 합니다.
작은 프로젝트에서는 한 사람이 PM이면서 PL이고 AA이기도 합니다. 큰 프로젝트에서는 PM 아래 PL이 파트별로 여러 명, 그 아래 개발자가 수십 명, 옆에는 PMO가 표준을 챙기고, TA/AA/DBA가 가로로 기술을 받칩니다.
그래서 명함의 직함을 외우는 게 아니라, "이 역할은 무엇이 잘못되면 책임을 지는가" 를 묻는 게 핵심입니다. 일정이 밀리면 PM, 결제 파트 산출물이 안 나오면 결제 PL, 표준 양식이 엉망이면 PMO, 테이블 설계가 틀리면 AA — 이렇게 책임으로 사람을 찾습니다.
일곱 역할의 책임 — R&R 한눈에 보기
PM·PL·PMO·SE·TA·AA·DBA의 책임 경계
먼저 각 역할이 무엇을 책임지고, 무엇이 잘못되면 호출되는지를 표로 정리합니다. 이 표 하나가 이 모듈의 중심입니다.
| 역할 | 풀네임 | 한 줄 책임 | 무엇이 잘못되면 호출되나 | 보고 라인 |
|---|---|---|---|---|
| PM | Project Manager | 프로젝트 총괄 — 일정·범위·비용·리스크·인력 전체 | 일정 지연, 예산 초과, 범위 분쟁, 고객 불만 | 발주사 PM·임원 |
| PL | Part Leader | 특정 파트(결제·정산 등)의 개발·일정·인력 리드 | 담당 파트 산출물 미달, 파트 내 일정 지연 | PM |
| PMO | Project Management Office | 프로젝트 관리체계 — 표준·품질·진척·산출물 거버넌스 | 보고 양식 불일치, 진척 가시성 부족, 표준 미준수 | 발주사·사업 총괄 |
| SE | Solution Engineer | 특정 솔루션/제품(WAS·DBMS·메시징 등) 도입·구성·연동·지원 | 솔루션 설치/연동 실패, 제품 기능 미충족 | PL·TA |
| TA | Technical Architect | 기술 아키텍처 — 인프라·플랫폼·기술스택·연동 표준 | 시스템 구조 결함, 성능·확장성 문제, 기술 표준 부재 | PM·TA 총괄 |
| AA | Application Architect | 애플리케이션 설계 — 도메인·데이터 모델·앱 구조 | 잘못된 설계, 모델 정합성 문제, 모듈 경계 붕괴 | PM·TA |
| DBA | Database Administrator | DB 관리 — 물리 설계·성능 튜닝·백업·운영 | 슬로우 쿼리, 인덱스 누락, 백업 실패, DB 장애 | TA·운영(SM) |
읽는 법:
- 세로축(PM→PL→개발자) 은 실행의 위임 사슬입니다. PM이 큰 그림을 잡고, PL이 파트를 챙기고, 개발자가 만듭니다.
- 가로축(TA·AA·DBA) 은 모든 파트를 가로지르는 기술 받침대입니다. 이들은 특정 파트가 아니라 프로젝트 전체의 기술 품질을 봅니다.
- PMO 는 이 그림의 위·옆에서 "제대로 굴러가는가"를 감독·지원합니다.
그림: 세로축은 실행 위임, 가로축은 기술 받침대 — 이슈는 직급이 아니라 책임으로 찾는다.
TA와 AA — 가장 자주 헷갈리는 두 아키텍트
신입이 가장 많이 헷갈리는 짝이 TA와 AA입니다. 둘 다 '아키텍트'라 비슷해 보이지만, 보는 층이 다릅니다.
- TA(Technical Architect) 는 기술 기반을 봅니다. 어떤 WAS를 쓸지, DB는 무엇으로, 메시징은 카프카인지, 서버 구성과 네트워크·보안·연동 표준은 어떻게 — '무엇 위에서 돌아가는가' 의 설계입니다.
- AA(Application Architect) 는 애플리케이션 내부를 봅니다. 도메인을 어떻게 나누고, 데이터 모델(엔티티·관계)을 어떻게 잡고, 모듈 경계와 레이어 구조를 어떻게 — '무엇을 어떻게 만드는가' 의 설계입니다.
비유하면, 건물을 지을 때 TA는 지반·골조·배관·전기(인프라·플랫폼)를, AA는 각 층의 평면도와 동선(앱 구조·데이터 흐름)을 설계합니다. 그리고 DBA는 그중 상수도 시설(DB)을 전담해 유지·운영합니다. 같은 'DB' 단어가 나와도 — 데이터 모델 설계는 AA, 물리 설계·튜닝·운영은 DBA로 책임이 갈립니다.
PM과 PMO — 가장 중요한 구분
실행하는 PM, 감독·지원하는 PMO
이 모듈에서 반드시 가져가야 할 구분이 PM vs PMO입니다. 발음이 비슷하고 둘 다 'Project Management'가 들어가 같은 것으로 오해하기 쉽지만, 성격이 정반대에 가깝습니다.
| 구분 | PM (Project Manager) | PMO (Project Management Office) |
|---|---|---|
| 본질 | 특정 프로젝트의 실행 주체 | 프로젝트를 가로지르는 관리 조직/체계 |
| 범위 | 보통 한 프로젝트 | 여러 프로젝트(또는 사업 전체) |
| 책임 | 그 프로젝트의 일정·범위·비용·품질·리스크 | 표준 프로세스·산출물 양식·진척 가시성·거버넌스 |
| 관점 | "이 프로젝트를 성공시킨다" | "모든 프로젝트가 같은 표준으로 굴러가게 한다" |
| 권한 | 프로젝트 내 의사결정·자원 배분 | 표준 제정·진척 감독·리스크 경보·지원 |
| 비유 | 한 경기의 감독 | 리그 전체의 운영본부·심판진 |
| 산출물 예 | 프로젝트 계획서·WBS·주간보고 | 표준 템플릿·진척 대시보드·품질 점검 리포트 |
핵심 한 줄: PM은 '이 프로젝트를 끝낸다', PMO는 '프로젝트들이 제대로 굴러가게 만든다'.
PMO는 PM의 상사가 아닙니다. PM이 실행에 집중하도록 표준과 도구를 제공(지원) 하고, 동시에 진척·리스크를 객관적으로 점검(감독) 하는 역할입니다. 잘 굴러가는 조직에서 PMO는 PM의 적이 아니라 공통 인프라입니다. 다만 진척이 위험하면 PMO가 경보를 울리고 발주사에 보고하므로, PM 입장에서는 감시자처럼 느껴질 수도 있습니다.
같은 활동이라도 역할마다 책임의 무게가 다릅니다. 위 RACI 매트릭스는 그 무게를 네 글자로 구분합니다 — R(실행)·A(최종 책임·승인)·C(자문)·I(보고). 핵심 규칙은 한 활동의 A는 하나뿐이라는 것입니다. "누가 최종 승인하는가"가 흐려지면 모두가 관여하지만 아무도 책임지지 않는 공백이 생깁니다. 이슈를 직급이 아니라 책임으로 찾는다는 앞 절의 원칙이, 칸마다의 A·R로 구체화됩니다.
직접 해보기 — 조직도에서 역할 읽기
아래는 어느 차세대 시스템 구축 프로젝트의 명함 정보입니다. 각 사람에 대해 (1) 한 줄 책임, (2) 보고 라인(누구에게 보고하나), (3) 무슨 이슈가 터지면 이 사람을 찾나를 적어 보세요. 정답 감각은 ObserveBlock에 있습니다.
1. 김총괄 — "차세대 구축 PM"
2. 이결제 — "결제·정산 파트 PL"
3. 박표준 — "전사 PMO"
4. 최솔루션 — "결제 게이트웨이 솔루션 SE"
5. 정기술 — "TA"
6. 한설계 — "AA"
7. 송디비 — "DBA"
추가 질문: 만약 "결제 테이블 설계가 잘못됐다"는 이슈와 "결제 솔루션 연동이 끊긴다"는 이슈가 동시에 들어오면, 각각 1차로 누구를 호출해야 할까요?
각 명함의 책임·보고라인·호출 트리거를 매핑- 김총괄(PM) = 책임: 일정·범위·비용·리스크 총괄 / 보고: 발주사 PM·임원 / 호출: 일정 지연·예산·범위 분쟁
- 이결제(PL) = 책임: 결제·정산 파트 실행·일정·인력 / 보고: PM(김총괄) / 호출: 결제 파트 산출물 미달
- 박표준(PMO) = 책임: 표준·품질·진척·산출물 거버넌스 / 보고: 발주사·사업 총괄 / 호출: 보고 양식 불일치·진척 불투명
- 최솔루션(SE) = 책임: 결제 게이트웨이 솔루션 구성·연동·지원 / 보고: PL·TA / 호출: 솔루션 연동 실패
- 정기술(TA) = 책임: 인프라·플랫폼·기술스택·연동 표준 / 보고: PM·TA 총괄 / 호출: 구조·성능·확장성 결함
- 한설계(AA) = 책임: 도메인·데이터 모델·앱 구조 설계 / 보고: PM·TA / 호출: 설계·모델 정합성 문제
- 송디비(DBA) = 책임: DB 물리설계·튜닝·백업·운영 / 보고: TA·운영(SM) / 호출: 슬로우쿼리·인덱스·백업·DB 장애
- 동시 이슈 정답: "테이블 설계 잘못" → 1차 AA(한설계), "솔루션 연동 끊김" → 1차 SE(최솔루션, 필요시 TA 협의). 같은 결제 영역이라도 설계 결함과 운영/연동 결함은 책임 역할이 다르다
현장에서 자주 보는 함정
증상: 운영 담당이 "DB가 느리다"를 무조건 DBA에게 따집니다. DBA는 "쿼리·테이블 설계가 잘못된 거라 제 영역이 아니다"라고 합니다. 며칠이 가도록 책임 주체가 안 잡혀 이슈가 표류합니다. 또 다른 현장에서는 진척이 위험한데 PM은 "PMO가 관리하는 거 아니냐", PMO는 "실행은 PM 책임"이라며 서로 미룹니다.
원인: 책임 경계(R&R)가 명확히 합의되지 않았기 때문입니다. "DB가 느리다"는 한 문장이지만 — 데이터 모델 설계 결함이면 AA, 쿼리 로직이면 개발/AA, 물리 튜닝·인덱스·운영이면 DBA로 책임이 갈립니다. 증상을 원인 층위로 분해하지 않으면 엉뚱한 사람을 찾습니다. PM·PMO 핑퐁도 같은 뿌리 — "실행 책임은 PM, 표준·감독은 PMO"라는 경계가 문서로 합의되지 않은 것입니다.
해결 방향(이 트랙에서 깊어짐):
- 프로젝트 착수 시 R&R 표를 명문화해 "이 유형의 이슈는 이 역할"을 합의한다(이 모듈의 R&R 표가 그 출발점).
- 이슈를 받으면 먼저 원인 층위로 분해한다 — 설계인가, 연동인가, 운영인가. 층위가 정해지면 역할은 따라온다.
- PM↔PMO는 "실행 vs 거버넌스"로 선을 긋는다. PMO는 진척을 감독·지원하되 실행 의사결정은 PM이 한다.
- 한 사람이 여러 역할을 겸하는 작은 프로젝트라도, 모자(역할)를 의식적으로 바꿔 쓰며 어떤 책임으로 말하는지 분명히 한다.
역할 구분의 목적은 책임을 떠넘기기 위함이 아니라, 이슈가 가장 빨리 올바른 손에 도착하게 하기 위함입니다.
SI/SM 현장에서 당신이 어떤 자리에 있든, 이 역할 지도는 매일 쓰는 좌표입니다.
발주사(원청) IT 담당이라면, 협력사 조직도를 받아 누가 무엇에 책임지는지를 읽고, 이슈가 터졌을 때 PM에게 따질지·AA에게 설계를 물을지·DBA에게 운영을 물을지를 정확히 분기해야 합니다. 엉뚱한 사람을 잡으면 며칠이 새어 나갑니다. PM/PMO 자리에 있다면, 자기 역할의 경계를 알아야 "이건 내 결정, 저건 PMO 표준, 그건 TA 판단"을 구분해 불필요한 책임 분쟁과 의사결정 지연을 막습니다.
특히 한국 SI 현장은 다단계 하도급 구조가 흔해서, 한 명이 명함은 PL인데 실제로는 AA 역할까지 겸하거나, 발주사 PMO가 협력사 PM의 진척을 강하게 들여다보는 일이 잦습니다. 그래서 명함의 직함보다 실제 R&R을 확인하는 습관이 중요합니다 — 회의에서 "그 결정은 어느 분이 책임지시나요"를 자연스럽게 물을 수 있어야 합니다.
이 역할들을 알면, 협력사와 대등하게 대화하고("그건 TA 영역이니 TA님 의견을 듣겠습니다"), 책임 회피성 보고를 가려내며, 이슈를 가장 빠른 경로로 올바른 손에 넘길 수 있습니다. 관리 직무의 실력은 결국 사람과 책임을 정확히 연결하는 능력입니다.
관련 모듈로 더 깊이:
- SI·SM·SaaS·MSP 구조 — 이 역할들이 놓이는 SI·SM·하도급 산업 구조의 큰 그림
- SI 프로젝트 생애주기 — 이 역할들이 단계별로 어떤 순서로 움직이며 무엇을 산출하는지
- PMO 운영과 벤더 관리 — PMO가 여러 수행사를 어떻게 통합 관리·통제하는지
다음 모듈에서는 이 역할들이 어떤 순서로 움직이는지 — 분석·설계·개발·테스트·이행·안정화로 이어지는 SI 프로젝트 생애주기(생명주기)를 단계별로 따라가며, 각 단계에서 누가 무엇을 산출하는지 정리합니다.