SI 프로젝트 포지션 한눈에 이해하기

SI 프로젝트 포지션 한눈에 이해하기

기준: 무엇을 책임지는지(Responsibility) · 무엇을 남기는지(산출물) · 누구와 일하는지(협업)

먼저 한 줄로 정리하면

구조를 이렇게 보면 헷갈림이 줄어듭니다.
PM 전체 일정/범위/인력/이슈를 “관리”하고 대외 창구가 된다
PL 개발팀을 “리딩”하며 요구를 구체화하고 개발이 되게 만든다
AA/TA/DA 시스템이 굴러가게 하는 “구조/기술/데이터 설계”를 책임진다
QA 산출물/코드 품질을 “기준대로” 보증한다
BA 비즈니스 관점에서 프로세스를 “설계”해 요구의 방향을 잡는다
Developer 실제 기능을 “구현”한다

실무 기준으로 보면
PM은 “프로젝트가 사고 없이 굴러가게” 만들고,
PL은 “개발이 제대로 나가게” 만들고,
AA/TA/DA는 “기술적으로 망하지 않게” 받쳐줍니다.

자주 나오는 오해
TA가 “설치만 하는 사람”으로만 잡히면 운영 이슈가 뒤늦게 터집니다.
DA가 “ERD만 그리는 사람”으로만 잡히면 마이그레이션/품질이 막판에 흔들립니다.

포지션별 역할을 쉽게 가공한 설명

PM (Project Manager)	프로젝트 ‘전체 운영’ 책임자 현업/외부팀과의 공식 창구로서 이슈를 모으고, 우선순위를 정하고, 최종 조율합니다. 주요 책임 범위·일정·비용·인력·리스크 관리 현장 업무 WBS 관리, 투입/TO 조정, 휴가/공수 관리, 주간보고/회의 운영, 의사결정 에스컬레이션
PL (Project Leader)	개발팀이 ‘실제로 개발이 되게’ 만드는 리더 PM을 보좌하면서, 요구사항을 개발 가능한 수준으로 구체화하고 화면/기능 흐름을 정리합니다. 개발자에게 작업 방향과 기준을 주고 일정이 흐트러지지 않게 관리합니다. 주요 책임 개발 리딩, 요구 분석 구체화, 개발 일정/리스크 관리 현장 업무 화면설계, 기능 정의, 개발 우선순위/작업 분배, 기술 이슈 1차 해결(고급기술 포함)
AA (Application Architect)	개발이 ‘같은 규칙으로’ 만들어지게 하는 설계자 공통 로직, 개발 표준, 프레임워크 구조를 잡아 “팀 전체가 동일한 방식으로 개발”하도록 만듭니다. 주요 책임 공통모듈/프레임워크, 개발 표준, 코드 구조 원칙 현장 업무 공통 라이브러리, 예외/응답 규칙, 로깅/트랜잭션 정책, 코드리뷰 가이드
TA (Technical Architect)	시스템이 ‘실제로 돌아가게’ 만드는 인프라/플랫폼 설계자 OS·WEB·WAS·DB 설치뿐 아니라, 네트워크/보안 경계, 계정/권한, 배포 방식, 운영 관점까지 포함해 기반을 책임집니다. 주요 책임 인프라 구성, 미들웨어 설치/구성, 네트워크/보안/성능 기반 현장 업무 환경 구축(DEV/STG/PRD), 배포 구조, 모니터링/로그, 백업/복구, 성능 튜닝 협업
DA (Data Architect)	데이터가 ‘깨끗하고 일관되게’ 쌓이도록 설계하는 담당 데이터 표준과 구조(모델), 품질 규칙을 정의하고, 이관/마이그레이션까지 책임집니다. 주요 책임 데이터 표준/모델/품질, 마이그레이션, DB 설계 현장 업무 ERD/정규화, 코드/용어 표준, 인덱스/쿼리 설계, 이관 검증(건수/정합성)
QA (Quality Assurance)	산출물과 결과물이 ‘기준에 맞는지’ 확인하는 품질 보증 문서(산출물)와 소스코드가 표준과 요구사항에 맞는지 점검하고, 결함이 줄어들게 프로세스를 관리합니다. 주요 책임 품질 기준/체크리스트, 리뷰/점검, 결함 관리 현장 업무 산출물 검수, 코드 품질 점검, 테스트 결과 확인, 지표(결함/진척) 관리
BA (Business Architect)	기술이 아니라 ‘업무(비즈니스) 흐름’으로 설계하는 역할 현업 관점에서 프로세스와 규칙을 정리해 “무엇을 왜 바꾸는지”를 설계합니다. 주요 책임 업무 프로세스 설계, 요구 정합성, 정책/규칙 정의 현장 업무 As-Is/To-Be, 업무 규칙 정리, 사용자 시나리오, 변경 영향도 분석
Developer (개발자)	정의된 요구를 ‘실제 코드’로 구현하는 실행자 프로그램 정의가 완료되는 시점부터 본격 투입되며, 설계/가이드에 따라 기능을 개발하고 결함을 수정합니다. 주요 책임 기능 구현, 단위 테스트, 버그 수정, 기술 부채 최소화 현장 업무 화면/API 구현, 테스트, 코드리뷰 반영, 배포 대응, 운영 이슈 지원

프로젝트에서 실제로 “누가 무엇을 잡는지” 예시

같은 이슈라도 담당이 이렇게 나뉩니다.
“요구가 바뀌었어요” → PM(범위/일정 조정) + BA(업무 영향) + PL(개발 반영 계획)
“공통 로그인/권한이 애매해요” → AA(공통 구조) + TA(보안/인증 연계) + PL(화면/요구 구체화)
“오픈 전 성능이 불안해요” → TA(환경/미들웨어/모니터링) + DA(쿼리/인덱스) + PL/개발자(코드 병목)
“산출물이 기준과 달라요” → QA(기준/검수) + PM(조치 일정) + 해당 작성자(수정)

핵심은 “역할이 겹치는 지점”에서 충돌이 나기 쉽다는 점입니다. 그래서 초반에 책임 경계를 간단히 합의해두면 후반 커뮤니케이션 비용이 크게 줄어듭니다.

요약

• PM 프로젝트 전체 관리 + 대외 커뮤니케이션
• PL 개발 리딩 + 요구 구체화 + 개발 일정 관리
• AA 공통 구조/표준/프레임워크로 개발 일관성 확보
• TA 인프라/플랫폼 기반 구축 + 운영 가능성까지 확보
• DA 데이터 표준/모델/품질 + 이관까지 책임
• QA 산출물/코드 품질 기준 수립 및 보증
• BA 비즈니스 프로세스 설계 + 정책/규칙 정리
• Developer 실제 구현 및 테스트/수정

운영 환경에서는 역할 정의가 문서보다 “업무 흐름에서 실제로 작동하는지”가 중요합니다. 역할을 정리할 때는 책임(최종 결정권)과 실행(실무 처리)을 분리해 두면 훨씬 깔끔해집니다.