웹 에이전시 si 차이란 홈페이지나 앱을 만들어 주는 제작 전문 회사(웹 에이전시)와 기업의 업무 시스템을 설계해 구축하는 시스템 통합 사업(SI)이 어떻게 다른지를 묻는 말이다. 둘 다 돈을 받고 결과물을 만들어 준다는 점은 같아서 겉으로는 구분하기 어렵다. 이 기사는 두 방식의 뜻과 구조, 일하는 방식, 계약에서 어긋나는 지점, 상황별 선택 기준을 차례로 설명한다. 웹 에이전시의 뜻과 현실, 개발자와 채용, 순위나 포트폴리오를 어떻게 봐야 하는지도 함께 다룬다.
두 말이 가리키는 것과 만들어진 배경
웹 에이전시는 기획, 디자인, 퍼블리싱, 개발을 묶어 홈페이지·쇼핑몰·앱 같은 결과물을 만들어 주는 회사를 부르는 말이다. 에이전시라는 이름은 광고 대행에서 왔다. 브랜드를 보여 주는 얼굴이 되는 화면을 잘 만드는 일이 출발점이었고, 그래서 디자인과 기획 비중이 큰 곳이 많다. SI는 시스템 통합의 약자로, 회사 안의 회계·인사·재고·주문 같은 업무 흐름을 전산으로 묶어 설계하고 구축해 넘기는 사업이다. 화면보다 데이터와 업무 규칙, 기존 시스템과의 연결이 중심이다.
두 갈래가 따로 생긴 이유는 발주하는 쪽의 목적이 다르기 때문이다. 외부 고객에게 보이는 화면을 빠르게 내놓아야 하는 곳은 디자인과 기획에 강한 제작사를 찾는다. 내부 업무를 전산화하려는 곳은 요구사항을 문서로 정리하고 단계별로 검수하는 방식을 원한다. 다만 현장에서는 경계가 뚜렷하지 않다. 에이전시가 회원·결제·관리자 기능까지 만들기도 하고, SI 회사가 대외용 사이트를 만들기도 한다.
일하는 방식과 실제로 막히는 지점
일하는 방식에서 가장 크게 갈리는 것은 요구사항을 어디까지 문서로 확정하느냐다. SI는 요구사항 정의서와 설계 문서를 만들고 단계마다 승인을 받으며 진행하는 경우가 많다. 에이전시는 시안을 주고받으며 화면 중심으로 조율하는 경우가 많다. 앞의 방식은 범위가 분명한 대신 중간에 바꾸기가 번거롭다. 뒤의 방식은 유연한 대신 수정이 계속 이어져 범위가 불어나기 쉽다.
사람들이 자주 어긋나는 지점은 대체로 세 곳이다. 첫째는 범위다. 견적에 무엇이 들어 있는지 확정하지 않으면 나중에 추가 비용 문제로 번진다. 둘째는 산출물의 소유다. 소스코드와 디자인 원본을 받을 수 있는지, 저작권이 누구에게 있는지가 계약서에 없으면 업체를 바꿀 때 막힌다. 셋째는 완료 이후다. 오류 수정 기간, 유지보수 비용, 서버와 도메인 명의가 정리되지 않으면 납품 뒤에 곤란해진다.
웹 에이전시 현실을 말하는 글에는 일정 압박, 반복되는 수정 요청, 여러 프로젝트를 동시에 돌리는 구조에 대한 이야기가 많다. 익명 커뮤니티에서 보이는 웹 에이전시 디시 같은 글도 비슷한 맥락이다. 다만 이런 글은 개인의 경험이고 회사마다 사정이 달라 전체를 대표한다고 볼 수 없다. 발주하는 사람에게 쓸모 있는 읽는 법은 평가의 높낮이가 아니라 어떤 상황에서 문제가 생겼는지를 가려내 내 계약서에 같은 구멍이 없는지 확인하는 것이다.
상황에 따라 답이 달라진다
홍보용 홈페이지나 브랜드 사이트처럼 화면과 문구가 핵심이라면 에이전시 방식이 맞는 경우가 많다. 반대로 회원 등급, 결제 정산, 재고 연동, 내부 승인 절차처럼 규칙이 복잡하다면 설계 문서를 중시하는 SI 방식이 안전하다. 작은 사이트 하나에 큰 시스템 방식을 적용하면 비용과 기간이 과해지고, 복잡한 시스템에 시안 중심 방식을 적용하면 중간에 구조를 갈아엎게 될 수 있다. 개인 제작자에게 맡기는 방법과 내부 인력을 채용하는 방법도 선택지이며, 각각 비용 구조와 책임 범위가 다르다.
| 구분 | 웹 에이전시 | SI |
|---|---|---|
| 중심 | 화면·기획·디자인 | 업무 규칙·데이터·연동 |
| 진행 방식 | 시안을 주고받으며 조율 | 요구사항 정의서와 단계별 검수 |
| 유리한 경우 | 홍보 사이트, 쇼핑몰, 앱 화면 | 내부 업무 시스템, 복잡한 정산·연동 |
| 자주 생기는 문제 | 수정 반복, 범위 확대 | 변경의 번거로움, 문서 작업 부담 |
| 계약 때 확인 | 수정 횟수, 원본 제공 | 검수 기준, 유지보수 범위 |
흔한 오해와 확인 순서
웹 에이전시 순위를 찾는 사람이 많지만 공신력 있는 단일 기준으로 줄을 세운 순위는 없다고 보는 편이 안전하다. 업체마다 강점이 다르고 같은 업체라도 담당 팀에 따라 결과가 달라지기 때문이다. 웹 에이전시 포트폴리오도 마찬가지다. 완성된 화면만 보지 말고 그 작업에서 맡은 역할의 범위, 유지보수 여부, 비슷한 규모와 기능의 경험이 있는지를 물어봐야 한다. 규모가 크다고 품질이 보장되는 것도, 작다고 부실한 것도 아니다.
개발자와 채용에 관심이 있는 독자에게도 구분은 유용하다. 에이전시는 여러 고객의 사이트를 짧은 주기로 만들어 다양한 경험을 쌓기 쉽고, SI는 큰 시스템의 한 부분을 오래 맡는 경우가 많다. 어느 쪽이 낫다고 말하기보다 일하는 주기, 담당 범위, 야근 구조, 사용하는 기술을 지원 전에 직접 물어 확인하는 것이 맞다. 웹 에이전시 회사라는 이름만으로는 일하는 방식이 같지 않다.
맡기기 전에는 순서대로 확인하면 된다. 먼저 만들려는 것이 화면 중심인지 업무 규칙 중심인지 적어 본다. 다음으로 필요한 기능 목록과 우선순위를 정하고, 견적서에 포함된 범위와 제외된 범위를 문서로 확인한다. 소스코드 제공, 저작권 귀속, 하자 보수 기간, 유지보수 비용, 서버와 도메인 명의는 계약서의 해당 항목에서 직접 읽어 본다. 모호한 부분은 계약 전에 서면으로 답을 받아 두고, 계약서 해석이 어려우면 소상공인이나 중소기업을 지원하는 공공 상담 창구에서 안내를 받을 수 있는지 확인하면 된다.
· · · · · · · · · ·
스페셜타임스는 AI 기술의 도움을 받아 더 빠르고 다양한 뉴스를 독자에게 전달하기 위해 노력하고 있습니다.