저녁 업무를 마치고 블로그에 글 한 편을 올리면 인스타그램에도 올려야 한다는 생각이 듭니다. 글을 복사해 붙여 넣으면 분량이 너무 길고 사진은 가장자리가 잘려 보입니다. 결국 카드뉴스를 처음부터 다시 만들게 되어 퇴근이 늦어집니다.

블로그와 인스타그램처럼 글을 올리는 통로를 채널이라고 부릅니다. 채널마다 이미지 크기와 분량, 말투가 달라서 같은 내용을 그대로 옮길 수 없습니다. 견적서에서 채널별 규격 설계라는 말을 보고 카드뉴스부터 만들면 되지 않느냐고 생각하셨다면 그 이유를 아래에서 풀어 드립니다.

블로그 글 한 편을 인스타그램에 올리려면 어떤 일이 더 생깁니까?

블로그에 글을 올린 뒤에도 인스타그램용 작업이 따로 남습니다. 글 전체를 옮기지 않고 인스타그램에 맞게 바꾸는 작업은 다음과 같습니다.

1. 글에서 독자에게 맞는 핵심 서너 가지를 선별합니다.

2. 카드의 크기를 정하고 그 크기에 맞춰 이미지를 만듭니다.

3. 긴 문장을 카드 한 장에 들어갈 길이로 줄입니다.

4. 줄인 글 끝에 원문으로 이어지는 「더 보기」 링크를 붙입니다.

작업 하나하나는 어렵지 않지만 글을 올릴 때마다 반복되면 퇴근 뒤 시간이 그 작업에 쓰입니다. 상담과 거래처 응대처럼 본업에 쓸 시간이 그만큼 줄어듭니다.

카드뉴스는 사진과 짧은 문장을 넘겨 보는 인스타그램 게시물입니다. 카드뉴스는 만들기 전에 크기부터 정해야 합니다. 규격에 맞는 크기로 만들어야 이미지가 잘리지 않고 화질도 유지되기 때문입니다.

채널마다 분위기와 요구 조건이 달라서 같은 콘텐츠를 여러 채널에 똑같이 올리는 방식은 맞지 않습니다. 블로그에서는 긴 글이 읽히지만 인스타그램에서는 카드 한 장에 담긴 짧은 문장이 기준이 될 수 있습니다.

채널별 규격을 먼저 정해 두면 하루가 어떻게 달라집니까?

규격은 이미지가 들어갈 칸의 크기와 형식에 관한 기준입니다. 규격을 먼저 정해 두면 올릴 때마다 크기를 다시 확인하던 일이 사라지고 하루가 이렇게 달라집니다.

1. 시간: 카드 크기와 장수를 그때그때 고민하던 시간이 줄어듭니다.

2. 꾸준함: 바쁜 주에도 같은 구성의 게시물을 올릴 수 있습니다.

3. 채널 확장: 인스타그램 밖의 채널이 늘어도 그 채널의 규격만 더하면 됩니다.

4. 비용: 카드뉴스를 손으로 만들던 직원이나 외주의 시간과 인건비 부담이 줄어듭니다.

규격 없이 직접 하는 하루는 글을 쓰고 카드를 만들었는데 크기가 맞지 않아 다시 만드는 일로 이어지기 쉽습니다. 규격이 있는 하루는 정해 둔 크기와 구성에 맞춰 한 번에 만드는 일로 끝납니다.

브랜드 규격이 게시물마다 달라지는 문제도 같은 방식으로 줄어듭니다. 첫 장에 무엇을 넣을지와 문장을 얼마나 줄일지가 정해져 있으면 다른 날에 만든 게시물도 같은 회사의 것으로 보입니다.

카드뉴스를 만들어 주면 되는데 고객은 처음에 무엇을 정해야 합니까?

버튼 하나로 카드뉴스가 만들어지는 흐름은 가능합니다. 다만 그 버튼이 어떤 기준으로 만들지는 처음에 한 번 정해야 하고 고객이 정하실 것은 다음과 같습니다.

1. 블로그 글에서 인스타그램으로 옮길 핵심을 무엇으로 삼을지 정합니다. 독자에게 맞는 서너 가지를 고르는 기준입니다.

2. 카드를 몇 장으로 구성하고 첫 장에 무엇을 넣을지, 문장은 얼마나 짧게 쓸지 정합니다.

3. 게시물을 올리기 전에 직접 보고 승인할지, 자동으로 올릴지 정합니다.

정한 기준은 채널별 콘텐츠 규격 정의서에 적힙니다. 정의서는 채널마다 카드 장수와 첫 장에 넣을 내용, 문장 길이를 적은 문서입니다.

기준을 정하지 않고 카드뉴스만 만들면 게시물마다 장수와 문장 길이가 달라집니다. 만든 사람이 바뀌어도 같은 기준으로 게시물이 나오게 하려면 정의서가 카드뉴스보다 먼저 있어야 합니다.

규격 정의서는 카드뉴스를 늦추는 절차가 아니라 카드뉴스를 같은 모양으로 반복해서 만들 수 있게 하는 기준입니다.

어떤 고객께 잘 맞습니까?

블로그에 쓴 글을 인스타그램에도 올려야 하는데 매번 손이 많이 가는 고객께 맞습니다. 구체적으로는 다음과 같은 상황입니다.

1. 인스타그램 게시물을 직접 올리고 있어 글 하나를 올리는 데 시간이 많이 드는 고객

2. 블로그 글을 인스타그램용으로 다시 가공하느라 같은 내용을 두 번 작업하는 고객

3. 게시물마다 카드 모양과 문장 규칙이 달라져 브랜드가 일정하게 보이지 않는 고객

학원이나 시공 회사처럼 수업 소식과 시공 사례를 알려야 하는 곳이면 글이 쌓일수록 이 부담이 커질 수 있습니다. 반대로 인스타그램을 거의 쓰지 않고 블로그만 운영하신다면 채널별 규격이 당장 필요하지 않을 수 있습니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없고 다음 기준에 따라 범위가 달라지므로 상담 뒤 견적으로 안내합니다.

1. 글을 올릴 채널이 인스타그램 하나인지 여러 곳인지

2. 카드 장수와 첫 장 구성, 문장 길이에 관한 기준이 이미 있는지

3. 로고와 색 같은 브랜드 기준이 이미 있는지

4. 올리기 전에 보고 승인할지 자동으로 올릴지

5. 글과 사진이 어디에 보관되어 있는지

채널과 기존 기준, 브랜드 자료, 승인 방식, 글과 사진의 위치를 알려 주시면 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의하신 뒤의 순서는 다음과 같습니다.

1. 문의를 남기시면 접수합니다.

2. 올리시는 채널과 글의 종류를 상담합니다.

3. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

4. 진행하시기로 하면 채널별 콘텐츠 규격 정의서를 작성하고 그 문서에 맞춰 카드뉴스를 만드는 장치를 개발합니다.

5. 장치와 계정을 고객에게 넘겨드립니다.

그래서 블로그 글을 인스타그램에 올리는 방식을 바꿔야 합니까?

인스타그램에 올린 카드의 이미지가 잘려 보이거나 글이 길어 끝까지 읽히지 않는다고 느끼신다면 올리는 방식을 알아볼 만합니다. 카드뉴스를 만드는 사람이 바뀔 때마다 장수와 말투가 달라진다면 규격을 문서로 남기는 일도 함께 검토할 수 있습니다.

엔소프 컴퍼니는 블로그 글을 인스타그램에 그대로 올리지 않도록 채널별 규격에 맞춘 카드뉴스 제작을 AI 에이전트로 개발해 드립니다

블로그 글을 인스타그램에 그대로 올리기 어려워 카드뉴스를 다시 만들고 계시다면 채널별 규격을 정하는 일부터 시작할 수 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 정하신 규격대로 카드뉴스를 만드는 AI 에이전트를 개발해 드립니다. AI 에이전트는 정해 둔 일을 사람 대신 수행하는 프로그램입니다. 어디까지 맡길지는 고객이 정하시면 됩니다.

기획부터 개발까지 엔소프 컴퍼니 한 곳에서 진행하므로 규격을 정하는 곳과 카드뉴스를 만드는 곳을 따로 조율하실 필요가 줄어듭니다. 완성된 모습은 이렇습니다.

1. 카드 구성 장수와 첫 장 원칙, 문장 규칙이 정의서에 적히고 그 규칙대로 카드뉴스 이미지가 만들어집니다.

2. 블로그에 쓰신 같은 글과 사진이 인스타그램 카드뉴스와 게시물로 이어져 따로 만들지 않아도 됩니다.

3. 게시물을 미리 보고 승인하는 관리 화면이 있어 올리기 전에 확인하실 수 있습니다.

4. 고객 브랜드에 맞춘 템플릿이 만들어져 게시물마다 모양이 달라지지 않습니다.

네 가지를 한 번에 맡기실 필요는 없고 규격 정의서부터 시작하셔도 됩니다. 카드뉴스를 손으로 만들고 채널마다 다시 가공하던 직원의 시간과 인건비 부담이 줄어듭니다.

프로젝트를 마치면 채널별 콘텐츠 규격 정의서와 카드뉴스를 만드는 장치, 게시물을 만들어 올리는 장치, 승인과 발행을 관리하는 화면을 계정과 함께 넘겨드립니다.

지금 블로그 글을 인스타그램에 어떻게 옮겨 올리고 계신지 알려 주시면 됩니다.

프로젝트 문의하기

견적서 한 장은 워드프레스를 권하고 다른 한 장은 Webflow를 권하는 일이 있습니다. 워드프레스는 홈페이지를 만드는 데 쓰는 소프트웨어이고 Webflow(웹플로우)는 홈페이지를 만들고 운영하며 키우는 데 쓰는 서비스입니다. 둘은 종류가 달라서 이 글은 사이트를 만드는 방식의 종류라는 뜻으로 구축 방식이라고 부릅니다.

금액과 일정은 나란히 놓고 비교할 수 있어도 구축 방식이 다른 까닭은 견적서만 읽어서는 알기 어렵습니다. 어느 쪽이 맞는지는 사이트로 하는 일과 사이트를 얼마나 자주 수정하는지(수정 주기)에 따라 판단할 수 있습니다. 그래서 금액 비교보다 개발사에 어떤 질문을 더 하느냐가 판단을 좌우합니다.

서로 다른 구축 방식을 권하는 견적서는 어느 한쪽이 틀린 것입니까?

한쪽이 틀렸다고 단정할 수 없습니다. 사이트로 하는 일이 다르면 맞는 구축 방식도 달라지기 때문입니다. 학원 소식을 자주 올리는 사이트와 시공 사례만 보여 주는 사이트는 필요한 수정 횟수가 서로 다릅니다.

개발사 두 곳에 같은 요청을 했어도 전달한 내용이 조금씩 다르면 추천도 달라질 수 있습니다. 한 곳에는 회사 소개 사이트라고만 말하고 다른 곳에는 소식을 자주 올릴 계획까지 말한 경우가 그렇습니다. 견적을 요청할 때 각 개발사에 전달한 내용을 다시 확인하면 추천이 달라진 이유가 보이기도 합니다.

개발사마다 다뤄 본 구축 방식이 다를 수도 있습니다. 개발사가 익숙한 방식을 기준으로 설명하는 일은 자연스럽습니다. 다만 추천한 방식이 고객 사이트에 맞는 이유까지 들어야 다른 견적서와 비교할 수 있습니다.

구축 방식의 이름보다 추천 이유를 알아야 견적서를 서로 비교할 수 있습니다. 추천 이유가 사이트로 하는 일과 이어지지 않으면 비교할 근거가 부족합니다. 개발사도 사이트로 하는 일을 더 들으면 추천 이유를 구체적으로 설명할 수 있습니다.

워드프레스와 Webflow는 무엇이 달라서 견적 항목이 다릅니까?

워드프레스와 Webflow는 사이트를 올려 두고 관리하는 책임이 놓이는 곳이 다릅니다. 워드프레스를 직접 설치해 운영하는 쪽이 호스팅과 도메인을 별도로 마련해야 합니다. 호스팅은 사이트 파일을 인터넷에 올려 두는 공간이고 도메인은 사이트 주소입니다.

Webflow는 호스팅과 보안, 업데이트가 서비스에 기본으로 포함되어 있어 직접 관리할 부담이 줄어드는 구성입니다. 보안은 외부의 공격으로부터 사이트를 지키는 일이고 업데이트는 프로그램을 새 버전으로 바꾸는 일입니다. 포함되는 범위는 이용하는 구성에 따라 다를 수 있으므로 개발사에 확인할 항목입니다.

워드프레스는 오픈소스 소프트웨어입니다. 오픈소스는 만든 내용이 공개되어 누구나 커뮤니티의 협업을 바탕으로 자유롭게 쓰고 수정할 수 있는 방식을 말합니다. 소프트웨어를 자유롭게 쓸 수 있는 것과 사이트 제작 작업의 범위는 별개입니다. 그 작업이 견적서 어느 항목에 속하는지는 개발사에 물어볼 수 있습니다.

두 방식을 권하는 견적서는 비용 항목의 구성이 서로 다를 수 있습니다. 호스팅과 보안, 업데이트를 누가 맡는지가 방식마다 다르므로 담당부터 확인해야 견적서를 비교할 수 있습니다. 담당이 같은 기준으로 적히지 않았다면 금액 차이만으로 어느 쪽이 유리한지 판단하기 어렵습니다.

견적서를 앞에 두고 개발사에 무엇을 더 물어야 합니까?

개발사 한 곳마다 같은 질문을 같은 순서로 물으면 답을 나란히 비교할 수 있습니다. 고객이 그대로 사용할 수 있는 질문은 다음과 같습니다.

1. 저희 사이트로 하려는 일에 추천하신 구축 방식이 맞는 이유는 무엇입니까?

2. 글과 사진을 개발자 없이 직원이 직접 수정할 수 있습니까?

3. 호스팅과 도메인은 누구 명의로 누가 마련하고 프로젝트 종료 후 누가 관리합니까?

4. 다른 구축 방식으로 바꾸면 견적의 어느 항목이 달라집니까?

5. 사이트를 넘겨받을 때 계정과 관리 권한은 어떻게 받습니까?

질문 2의 답은 소식 글을 올릴 때마다 개발사에 요청해야 하는지 직원이 직접 올릴 수 있는지를 알려 줍니다. 직접 수정할 수 있다면 어디까지 직원이 하고 어디부터 개발사에 요청하는지도 물어볼 수 있습니다. 답에 따라 수정할 때마다 필요한 일정과 연락 횟수가 달라집니다.

질문 3과 질문 5는 프로젝트 종료 후의 관리와 이어집니다. 호스팅 계정이나 도메인이 개발사 명의로 되어 있으면 사이트를 다른 곳으로 옮기거나 담당 개발사를 바꿀 때 개발사의 협조가 필요할 수 있습니다. 고객 명의라면 고객이 직접 관리 권한을 가집니다.

추천 이유와 수정 담당, 관리 담당을 같은 질문으로 물으면 개발사별 답을 같은 기준으로 읽을 수 있습니다. 답은 말로만 듣지 않고 문서나 메일로 받아 두면 견적서와 나란히 놓고 비교할 수 있습니다. 문서로 받은 답에 계정 명의가 적혀 있으면 프로젝트 종료 후에 확인할 내용도 분명해집니다.

개발사에 묻기 전에 사이트로 하는 일과 수정 주기는 어떻게 적어 둡니까?

문장 몇 줄이면 됩니다. 사이트로 하는 일과 수정 주기, 나중에 붙일 기능을 적어 두면 개발사마다 같은 정보를 받게 됩니다. 정보가 같아야 추천이 달라진 이유를 구축 방식의 차이로 읽을 수 있습니다.

1. 사이트로 하는 일: 회사 소개만 하는지 문의 접수나 예약까지 받는지 적습니다.

2. 수정 주기: 소식 글과 사진을 얼마나 자주 올리는지 적습니다.

3. 수정 담당: 직원이 직접 수정하는지 개발사에 요청하는지 적습니다.

4. 나중에 붙일 기능: 예약처럼 나중에 더할 기능이 있는지 적습니다.

업종마다 적는 내용이 다릅니다. 학원은 수강 안내와 소식을, 병원은 진료 안내와 공지를, 제조 회사는 제품 소개를, 시공 회사는 완료 사례를 올리는 경우가 있습니다. 올리는 내용이 달라지면 수정 주기도 달라집니다.

직원이 직접 자주 수정할 계획이라면 수정 담당 질문의 답이 구축 방식을 판단하는 핵심 기준이 됩니다. 수정이 드물다면 호스팅과 보안, 업데이트를 누가 맡는지가 더 큰 기준이 됩니다. 적어 둔 내용을 받은 개발사가 추천 이유를 다시 설명하면 견적서마다 다른 추천을 같은 기준으로 비교할 수 있습니다.

비용은 무엇에 따라 달라집니까?

비용은 사이트의 범위에 따라 달라지며 범위를 정하는 기준은 다음과 같습니다.

1. 사이트로 하는 일: 소개 위주인지 예약이나 결제 같은 기능이 필요한지

2. 수정 주기와 수정 담당: 직원이 직접 수정하는지 개발사에 요청하는지

3. 호스팅과 도메인: 마련과 관리를 누가 맡는지

4. 화면 분량: 만들어야 할 쪽 수와 디자인 범위

5. 기존 자료: 옮겨야 할 글과 사진이 있는지

사이트로 하는 일과 수정 주기, 호스팅과 도메인 담당, 화면 분량, 옮길 자료를 알려 주시면 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의 이후의 진행 순서는 다음과 같습니다.

1. 문의를 남기시면 접수합니다.

2. 상담에서 사이트로 하는 일과 수정 주기를 듣습니다.

3. 상담 내용에 맞는 구축 방식을 추천하고 범위와 견적을 안내합니다. 견적을 보고 진행할지는 고객이 정하시면 됩니다.

4. 진행하시기로 하면 사이트를 제작합니다.

5. 완성한 사이트와 계정을 고객에게 넘겨드립니다.

그래서 워드프레스와 Webflow 가운데 무엇으로 정해야 합니까?

추천 이유가 고객이 적은 사이트 목적과 수정 주기로 이어진다면 그 개발사의 견적서는 비교 대상으로 둘 만합니다. 호스팅 관리와 계정 인계를 묻는 질문의 답도 문서로 남아 있어야 합니다. 답이 비어 있다면 질문을 더 한 뒤에 정해도 서두를 이유는 없습니다.

엔소프 컴퍼니는 견적서마다 다른 워드프레스, Webflow 추천에 맞춘 사이트 구축과 반복 업무 자동화를 AI 에이전트로 개발해 드립니다

엔소프 컴퍼니는 사이트로 하는 일과 수정 주기를 듣고 워드프레스와 Webflow를 포함해 맞는 구축 방식을 추천합니다. 고객이 원하실 경우 추천한 방식으로 사이트도 개발해 드리며 어디까지 맡길지는 고객이 정하시면 됩니다. 기획부터 개발까지 한 곳에서 진행하므로 업체를 따로 조율하는 부담이 줄어듭니다.

사이트를 연 뒤에는 소식 글을 올리고 문의를 종류별로 나누는 일이 직원에게 남습니다. AI 에이전트는 고객이 정한 기준대로 이런 반복 업무를 사람 대신 수행하는 프로그램입니다. 고객이 원하시면 엔소프 컴퍼니가 그 일을 수행하는 AI 에이전트를 개발해 드립니다.

1. 고객이 정한 주제의 소식 글이 검색엔진이 읽을 수 있는 형식으로 사이트에 올라갑니다.

2. 문의와 신청이 들어오는 대로 종류별로 나뉘어 담당 직원 앞에 모입니다.

3. 직원이 쓰시는 업무 프로그램은 바꾸지 않고 사이트와 연결하므로 한 번 입력한 문의 내용을 다른 곳에 다시 적을 필요가 없습니다.

소식 글을 사이트에 공개하기 전에 담당 직원이 확인하고 승인하는 방식으로 시작하셔도 됩니다. 한 번에 다 맡기실 필요는 없고 하나부터 시작하셔도 됩니다. 소식 글을 올리고 내용을 옮겨 적던 직원의 시간과 인건비 부담이 줄어듭니다.

프로젝트를 마치면 배포된 웹사이트와 글을 수정하는 관리 화면, 계정을 넘겨드립니다. 배포란 완성한 사이트의 주소를 열면 방문자가 화면을 볼 수 있는 상태로 만드는 일입니다. 소식 글 올리기와 문의 분류를 맡기셨다면 그 일을 수행하는 AI 에이전트와 계정도 넘겨드립니다.

사이트에서 하시려는 일과 한 달에 글과 사진을 몇 번쯤 수정하시는지 알려 주시면 됩니다.

프로젝트 문의하기

저녁 업무를 마치고 나서야 AI 에이전트 관리 화면을 여는 날이 있으신가요? 몇 달 전에 도입했는데 화면에는 처리 목록만 길게 쌓여 있고 효과가 있는지는 판단이 서지 않습니다. 어느 숫자를 보고 판단해야 하는지 도입할 때 아무도 알려 주지 않았기 때문입니다.

AI 에이전트 도입 효과는 도입 전에 적어 둔 숫자와 도입 뒤의 숫자를 비교해야 판단할 수 있습니다. 비교할 도입 전 숫자는 AI 에이전트를 켜기 전에 적어 두어야 하고 도입 뒤에 볼 숫자는 그때 함께 정해 두면 됩니다.

효과를 확인하는 기준 없이 도입하면 어떤 일이 따라옵니까?

도입 전의 숫자가 없으면 도입 뒤에 어떤 숫자를 보아도 비교할 대상이 없습니다. 화면에 처리 건수가 쌓여 있어도 그 건수가 이전보다 나은 것인지 알 수 없습니다. 그래서 효과를 묻는 질문에 직원마다 다른 답을 하게 됩니다.

기준 없이 도입을 마친 뒤에는 다음과 같은 상황이 생길 수 있습니다.

1. 효과를 물으면 직원의 인상으로 답을 듣게 됩니다.

2. 월 사용료나 개발비가 계속 나가는데 계속 쓸지 줄일지 정할 근거가 없습니다.

3. 에이전트가 처리한 일을 사람이 다시 확인하는 시간이 얼마나 되는지 기록한 사람이 없습니다.

세 가지 상황이 겹치면 에이전트를 계속 쓸지 정하는 회의가 길어질 수 있습니다. 숫자를 찾는 데 시간을 쓰다 보면 정작 판단은 다음 회의로 넘어갑니다. 그 시간은 고객이 본업에 쓰실 시간에서 빠져나갑니다.

AI 에이전트는 반복되는 일의 부담을 덜려고 도입합니다. 효과를 확인하는 데 더 많은 시간이 든다면 도입한 목적과 어긋납니다.

효과를 확인하는 기준이 있으면 판단이 어떻게 달라집니까?

회의에서 오가는 말이 느낌에서 숫자로 바뀝니다. 지난달과 이번 달에 같은 항목을 나란히 놓고 보기 때문에 좋아졌는지 그대로인지가 바로 확인됩니다.

기준이 있는 하루는 다음과 같이 달라집니다.

1. 회의 자료에 같은 항목이 같은 순서로 올라와 지난달과 이번 달을 비교할 수 있습니다.

2. 에이전트를 계속 쓸지 맡길 업무를 늘릴지 멈출지를 같은 기준으로 정할 수 있습니다.

3. 담당 직원이 바뀌어도 무엇을 보아야 하는지가 문서에 남아 있습니다.

효과를 확인하는 데 쓰는 시간도 달라집니다. 숫자를 여기저기서 찾는 대신 정해 둔 항목만 열어 보면 됩니다. 그 시간은 본업과 상담에 쓰실 수 있습니다.

기준 숫자가 정해져 있으면 효과가 있는지를 회의에서 숫자 몇 개로 이야기할 수 있습니다. 비용을 줄이는 쪽으로 판단하든 맡기는 업무를 넓히는 쪽으로 판단하든 근거는 같은 숫자입니다.

숫자가 기대에 못 미칠 때도 기준이 있으면 어느 업무에서 막혔는지 알 수 있습니다. 막힌 업무만 맡기는 범위에서 빼거나 규칙을 바꾸는 판단이 가능해집니다.

AI 에이전트를 도입하면 고객이 직접 하실 일은 무엇입니까?

AI 에이전트를 켜면 알아서 일해 주니 고객은 결과만 받으면 된다고 기대하실 수 있습니다. 일은 에이전트가 수행하지만 그 일이 효과를 냈는지 판단하는 기준은 도입 전에 고객이 한 번 정하는 일입니다. 기준이 정해지고 나면 이후에는 같은 항목을 같은 방식으로 확인하시면 됩니다.

고객이 정하실 기준은 세 가지입니다.

1. 도입 전 숫자를 적어 두는 일: 에이전트가 맡을 업무의 처리 건수와 사람이 그 업무에 쓰는 시간, 일을 잘못 처리한 비율(오류율)을 에이전트를 켜기 전에 기록합니다. 매출이나 문의처럼 사업 성과를 보여 주는 숫자도 함께 적습니다.

2. 주 지표 하나를 정하는 일: 주 지표는 효과를 판단하는 기준 숫자입니다. 에이전트가 맡은 핵심 업무를 실제로 끝냈는지 보여 주는 숫자로 정합니다. 학원의 상담 접수를 맡겼다면 끝까지 처리된 접수 건수가 해당됩니다.

3. 사람에게 넘기는 비율을 보조로 보는 일: 에이전트가 일을 사람에게 넘기는 비율은 에이전트가 혼자 감당하지 못하는 정도를 보여 줍니다.

건당 비용은 에이전트가 일을 끝내기까지 드는 전체 비용을 기준으로 따집니다. 월 사용료만 건수로 나눈 값과는 다를 수 있습니다.

도입 전 숫자를 아직 다 측정하지 못했다면 시범 운영은 해도 됩니다. 다만 도입 전 숫자가 갖춰지기 전에는 투자 효과가 있다고 단정해서는 안 됩니다. 시범 운영 기간에 얻은 숫자는 비교 기준으로 쓸 수 없기 때문입니다.

도입 효과를 숫자로 확인하는 방식은 어떤 고객께 잘 맞습니까?

도입 전이든 도입 뒤든 맡긴 업무가 무엇인지 한 문장으로 말씀하실 수 있다면 적용할 수 있습니다. 숫자를 확인하는 방식이 특히 잘 맞는 고객은 다음과 같습니다.

1. 도입을 앞두고 있어 도입 전 숫자를 적을 시간이 아직 있는 고객

2. 이미 도입했지만 회의에서 효과를 묻는 질문에 답할 숫자가 없는 고객

3. 월 사용료나 개발비를 계속 낼지 판단해야 하는 고객

업종은 가리지 않습니다. 병원이라면 예약 문의 처리를, 제조 회사라면 거래처 주문 확인을, 시공 회사라면 견적 요청 접수를 주 지표의 대상으로 삼을 수 있습니다.

AI 에이전트를 아직 도입하지 않으셨더라도 지금 직원이 그 업무에 쓰는 시간을 기록해 두면 도입 전 숫자가 됩니다.

숫자를 확인하는 화면을 만드는 비용은 무엇에 따라 달라집니까?

정해진 가격표는 없습니다. 숫자를 한 화면에 모아 보여 주는 관리 화면을 대시보드라고 부르는데 다음 다섯 가지에 따라 범위가 달라지므로 상담 뒤 견적으로 안내합니다.

1. 확인할 숫자가 몇 가지인지: 주 지표 하나만인지 보조 숫자까지인지

2. 숫자가 지금 어디에 쌓여 있는지: 한곳에 있는지 여러 프로그램에 나뉘어 있는지

3. 숫자를 보는 사람이 누구인지: 직원마다 볼 수 있는 범위가 다른지

4. 정해 둔 범위를 벗어난 숫자를 담당 직원이 확인하는 규칙이 필요한지

5. 매달 만드는 보고서를 자동으로 만들지

다섯 가지만 알려 주시면 범위를 잡을 수 있습니다. 숫자가 아직 정리되지 않았더라도 어디에 쌓여 있는지만 말씀해 주시면 상담을 시작할 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의하신 뒤의 순서는 다음과 같습니다.

1. 문의를 남기시면 확인하려는 숫자와 그 숫자가 쌓인 곳을 여쭙니다.

2. 상담에서 비용 기준 다섯 가지를 확인합니다.

3. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

4. 진행하시기로 하면 지표 정의 문서와 대시보드를 만듭니다.

5. 완성된 장치와 계정을 고객에게 넘겨드립니다.

그래서 AI 에이전트 도입 효과를 숫자로 확인할 준비를 해야 합니까?

에이전트가 맡은 업무의 처리 건수를 지금 직원이 집계할 수 있다면 알아볼 만합니다. 집계가 되지 않는다면 숫자를 모으는 방법부터 상담하는 것이 순서입니다.

어떤 업무를 맡길지 아직 정해지지 않았다면 기준 숫자는 그 업무가 정해진 뒤에 정해도 됩니다. 맡길 업무가 정해져야 그 업무를 끝냈는지 보여 주는 주 지표도 정해지기 때문입니다.

엔소프 컴퍼니는 AI 에이전트 도입 효과를 확인하는 운영 대시보드와 숫자 모으기 자동화를 AI 에이전트로 개발해 드립니다

AI 에이전트를 도입했는데 효과를 판단할 숫자가 없어 막막하시다면 보고 싶은 숫자를 정하는 일부터 시작할 수 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 주 지표와 보조 숫자의 정의를 문서로 남기고 그 문서를 기준으로 운영 대시보드를 개발해 드립니다. 어디까지 맡길지는 고객이 정하시면 됩니다.

기획부터 개발까지 엔소프 컴퍼니 한 곳에서 진행하므로 지표를 정하는 곳과 화면을 만드는 곳을 따로 조율하실 필요가 줄어듭니다. 숫자를 옮겨 적는 일은 업무 자동화로 이어서 개발합니다. 완성된 모습은 다음과 같습니다.

1. 효과를 판단하는 주 지표와 보조 숫자의 뜻이 지표 정의 문서에 적혀 있어 담당자가 바뀌어도 같은 기준으로 봅니다.

2. 쓰시는 프로그램은 그대로 두고 사이만 이어져 같은 숫자를 두 곳에 옮겨 적는 일이 없어집니다.

3. 매달 손으로 만들던 보고서가 정해 둔 양식대로 자동으로 만들어집니다.

4. 숫자가 정해 둔 범위를 벗어나면 담당 직원이 확인하도록 규칙을 정의하고 이상 감지 규칙 정의서로 남깁니다. 직원마다 볼 수 있는 숫자의 범위도 나누어 설계합니다.

네 가지를 한 번에 하실 필요는 없고 주 지표 하나를 보는 화면부터 시작하셔도 됩니다. 숫자를 옮겨 적고 보고서를 만들던 직원의 시간과 인건비 부담이 줄어듭니다.

프로젝트를 마치면 지표 정의 문서와 동작하는 대시보드, 이상 감지 규칙 정의서를 넘겨드립니다. 자동화를 맡기셨다면 동작하는 자동화 시스템과 계정도 함께 넘겨드립니다.

AI 에이전트에게 맡기려는 업무 하나와 그 업무를 지금 직원이 하는 데 걸리는 시간을 알려 주시면 됩니다.

프로젝트 문의하기

한 개발사는 Framer(프레이머)로 사이트를 만들자고 하고 다른 개발사는 Webflow(웹플로)를 권합니다. 두 서비스는 화면을 보며 조립해 사이트를 공개하는 사이트 제작 서비스라서 첫 화면 시안은 둘 다 보기 좋게 나옵니다. 그래서 시안만 보고는 어느 쪽에 글을 쌓아야 할지 판단하기 어렵습니다.

블로그를 꾸준히 쓸 회사의 사이트는 공개한 날보다 글이 쌓인 뒤의 모습이 더 중요합니다. 글 목록이 길어지면서 글마다 모양과 주소가 달라지는 일은 시안에 나오지 않기 때문입니다.

글이 쌓인 뒤 사이트에서는 어떤 일이 생깁니까?

글을 올릴 때마다 담당 직원이 제목 크기와 사진 위치를 새로 맞추고 있다면 글이 늘수록 그 시간도 늘어납니다. 학원이 입시 소식을 올리고 병원이 진료 안내 글을 올리는 사이트에서 생길 수 있는 상황입니다.

담당자가 바뀌면 차이가 더 눈에 띕니다. 앞 담당자가 올린 글과 새 담당자가 올린 글은 제목 크기가 다르고 글 주소를 짓는 규칙도 다릅니다. 글 목록에서 보면 같은 회사의 글인데 서로 다른 사이트의 글처럼 보입니다.

시안은 첫 화면 위주로 그려지는 경우가 있어 글 목록 화면과 글 한 편의 화면은 시안에 없을 수 있습니다. 시안에 없는 화면은 개발 중에 정해지므로 글 한 편의 모양이 개발자의 판단에 맡겨질 수 있습니다.

블로그를 꾸준히 쓸 회사는 글 한 편을 올리는 순서를 기준으로 두 서비스를 비교할 수 있습니다. 글을 쓰는 사람이 입력하는 항목과 입력한 뒤에 만들어지는 페이지가 그 순서에 들어갑니다. 두 서비스의 차이는 글을 올리는 순서에서 드러납니다.

Framer에서는 글 묶음과 검색용 정보를 어떻게 다룹니까?

Framer에서는 블로그와 자료실, 디렉터리(업체나 인물을 모아 둔 목록)처럼 같은 모양으로 반복되는 글 묶음을 각각 컬렉션으로 정의해 둡니다. 컬렉션은 같은 항목을 가진 글을 모아 둔 묶음입니다. 글을 입력하고 관리하는 기능은 CMS(콘텐츠 관리 시스템)라고 부릅니다. 병원이라면 진료 안내와 칼럼을 서로 다른 컬렉션으로 둘 수 있습니다.

Framer에서는 편집자가 글을 새로 발행해도 디자인해 둔 템플릿이 페이지 모양을 일정하게 유지해 줍니다. 템플릿은 글 한 편의 화면을 미리 짜 둔 틀입니다. 편집자는 제목과 본문을 입력하고 모양은 틀이 정하므로 담당자가 바뀌어도 글 모양이 같은 틀에서 나옵니다.

검색엔진이 글을 읽을 때 쓰는 정보도 글마다 입력할 수 있습니다. Framer에서는 글마다 메타데이터와 깔끔한 주소를 지정할 수 있습니다. 그래서 컬렉션 글처럼 입력한 내용으로 만들어지는 페이지도 검색에 대비할 수 있습니다. 메타데이터는 검색 결과에 보이는 제목과 설명 문구 같은 글 정보이고 깔끔한 주소는 글 주소를 알아볼 수 있는 글자로 정하는 것입니다.

입력 기능이 있다는 것과 구글이 글을 읽었다는 것은 별개입니다. 구글 서치콘솔은 구글이 사이트의 검색 상태를 보여 주는 서비스입니다. 시험 글 한 편을 올린 뒤 서치콘솔의 URL 검사에 글 주소를 넣으면 구글이 그 글을 읽었는지 확인할 수 있습니다. 검색 순위와 노출 시점은 이 확인으로 알 수 없습니다.

같은 항목을 Webflow에서도 확인하면 두 서비스를 같은 기준으로 비교할 수 있습니다. 확인할 항목은 글 템플릿과 글마다 입력하는 제목, 설명, 주소입니다.

두 서비스는 어떤 순서로 비교하면 됩니까?

Webflow는 요금제 등급에 따라 CMS 컬렉션 개수에 상한이 있고 가장 높은 등급이 100개입니다. 상한에 닿으면 새 글을 쓸 수 없게 되지만 이미 게시된 사이트가 깨지지는 않습니다.

컬렉션 개수가 문제가 되는지는 글 묶음 종류가 몇 개인지에 달려 있습니다. 블로그 하나만 운영하는 회사와 블로그와 자료실과 업체 소개 목록을 함께 두는 회사는 필요한 컬렉션 개수가 다릅니다.

비교는 다음 순서로 할 수 있습니다.

1. 쓰려는 글 묶음의 종류를 적고 종류마다 컬렉션이 하나씩 쓰인다고 가정해 필요한 개수를 셉니다.

2. 두 서비스에 같은 시험 글 한 편을 올려 글 목록 화면과 글 한 편 화면의 모양을 나란히 봅니다.

3. 시험 글에 제목과 설명과 주소를 입력하고 서치콘솔 URL 검사로 구글이 읽었는지 봅니다.

시험 글은 실제로 올릴 글과 같은 길이와 같은 사진 수로 만들 때 비교가 정확해집니다.

비교 전에 글 묶음과 올리는 사람은 어떻게 정리해 둡니까?

글 묶음 종류와 올리는 사람과 올리는 주기를 적어 두면 두 서비스를 비교할 기준이 생깁니다.

1. 글 묶음 종류: 블로그만 두는지 자료실이나 소개 목록도 두는지 적습니다.

2. 올리는 사람: 직원이 직접 올리는지 외부 업체가 올리는지 적고 담당자가 바뀔 수 있는지도 적습니다.

3. 올리는 주기: 매주 올리는 글과 가끔 수정하는 글을 나누어 적습니다.

학원이라면 수업 소식과 강사 소개와 수강 후기를 서로 다른 글 묶음으로 둘 수 있습니다. 수업 소식은 자주 올라오고 강사 소개는 가끔 수정되므로 묶음마다 주기가 다릅니다.

글 한 편마다 입력할 항목도 미리 적어 둘 수 있습니다. 제목과 요약, 대표 사진, 글 주소, 검색 결과에 보일 설명 문구가 그 항목입니다.

글 묶음 종류가 적고 올리는 주기도 길다면 어느 쪽을 골라도 부담이 작을 수 있습니다. 반대로 글 묶음 종류를 계속 늘릴 계획이라면 처음부터 종류를 센 표가 비교에 쓰입니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없고 아래 기준에 따라 범위가 달라지므로 상담 뒤 견적으로 안내합니다.

1. 글 묶음 종류가 몇 개인지

2. 글 한 편에 입력할 항목이 몇 가지이고 검색용 정보까지 넣을지

3. 새 사이트를 만드는지 기존 사이트의 글을 옮기는지

4. 글을 올리는 사람이 몇 명이고 그 사람이 바뀔 수 있는지

5. 글을 쓰고 올리는 일을 AI 에이전트에 맡길지

이 몇 가지를 알려 주시면 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의 뒤의 순서는 아래와 같습니다.

1. 사이트로 하려는 일과 수정 주기를 문의로 남깁니다.

2. 남기신 내용을 바탕으로 상담합니다.

3. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

4. 진행하기로 하면 사이트를 제작합니다.

5. 프로젝트를 마치면 사이트와 글이 올라가는 장치와 계정을 고객에게 넘겨드립니다.

그래서 블로그를 꾸준히 쓴다면 Webflow를 고르면 됩니까?

Webflow가 맞다고 정할 근거는 없으며 시험 글을 올릴 사람이 어느 편집 화면을 더 편하게 쓰는지가 마지막 기준이 됩니다. 글 묶음 종류가 적고 올리는 사람이 정해져 있다면 두 서비스 모두 시험 글로 비교해 볼 만합니다. 글 묶음 종류를 늘릴 계획이 있다면 Webflow 쪽 컬렉션 개수를 먼저 세어 볼 수 있습니다.

엔소프 컴퍼니는 블로그를 꾸준히 쓸 회사의 Framer와 Webflow 선택에 맞춘 사이트와 글 발행을 AI 에이전트로 개발해 드립니다

블로그를 꾸준히 쓸 회사에 Framer와 Webflow 중 어느 쪽이 맞는지 정하기 어려우시면 글을 올리는 주기부터 정리하시면 됩니다. 고객이 원하실 경우 엔소프 컴퍼니는 사이트로 하는 일과 업데이트 주기를 듣고 Framer와 Webflow를 포함해 맞는 구축 방식을 추천합니다. 추천한 방식으로 사이트도 개발해 드립니다. 글 목록 화면과 글 한 편 화면까지 기획 단계에서 정하므로 개발 중에 글 모양이 정해지는 일이 줄어듭니다.

글이 꾸준히 쌓이는 사이트에는 글을 쓰고 올리는 반복 업무가 남습니다. AI 에이전트는 글 주제와 올리는 순서를 고객이 정해 두면 그대로 글을 만들고 올리는 프로그램입니다. 고객이 정한 주제의 글을 AI 에이전트가 만들어 검색엔진이 읽을 수 있는 형식으로 올리면 글마다 처음부터 쓰지 않아도 글이 쌓입니다.

올리기 전에 보고 승인하는 방식도 가능하며 사이트 구축과 글 발행을 한 번에 맡기실 필요는 없습니다. 한쪽부터 시작하셔도 됩니다. 글마다 제목과 설명, 주소를 입력하던 직원의 시간과 인건비 부담이 줄어듭니다. 담당 직원이 바쁜 주에도 정해 둔 주제의 글이 올라가므로 블로그로 하는 홍보가 중간에 멈추는 일도 줄어듭니다.

프로젝트를 마치면 배포된 웹사이트와 콘텐츠 관리 환경, 계정을 넘겨드립니다. 배포는 완성한 사이트를 방문자가 볼 수 있게 인터넷에 올리는 일이고 콘텐츠 관리 환경은 글과 사진을 입력하는 관리 화면입니다. 글 발행을 맡기셨다면 글이 올라가는 장치도 함께 받으실 수 있습니다.

블로그로 하려는 일과 글을 올리는 주기를 알려 주시면 됩니다.

프로젝트 문의하기

월말 저녁에 직원이 한 화면의 숫자를 다른 표에 다시 옮겨 적고 있는 모습을 보신 적이 있으실 것입니다. AI 에이전트가 그런 일을 줄여 준다는 말에 기대가 생기지만 회사 전체를 바꾸는 큰 일이 될까 걱정도 따라옵니다. 큰 비용을 들여 도입한 시스템을 직원이 쓰지 않게 될까 걱정되시는 것은 자연스럽습니다.

AI 에이전트는 회사 전체에 한꺼번에 도입하지 않고 업무 한 가지에 먼저 도입하는 방법이 있습니다. 바뀌는 업무가 한 가지이면 결과가 기대와 다를 때 확인할 범위도 좁아집니다.

AI 에이전트는 무엇이고 업무 한 가지로 시작한다는 것은 무슨 뜻입니까?

AI 에이전트는 맡은 일을 어떤 순서로 처리하고 어떤 프로그램을 쓸지 AI가 스스로 정하며 수행하는 시스템입니다. 맡길 업무와 범위는 고객이 정하고 AI 에이전트는 정해진 업무를 수행합니다. 직원이 하던 확인과 입력 같은 반복 일을 맡는다고 생각하시면 됩니다.

정해진 순서대로만 움직이는 자동화도 있습니다. 순서를 사람이 미리 정해 두고 AI와 프로그램이 그대로 따라 움직이는 방식이며 AI 에이전트와는 순서를 정하는 주체가 다릅니다. 업무 순서가 단순하면 순서를 미리 정한 방식으로 충분할 수 있습니다. 가능한 한 가장 단순한 방법을 먼저 찾고 꼭 필요할 때만 복잡하게 만드는 순서가 바람직합니다.

중소기업은 가치가 큰 업무 한 가지에 AI 에이전트를 먼저 적용하는 집중 시범 도입부터 시작할 수 있습니다. 집중 시범 도입은 회사 전체의 업무 방식을 바꾸기 전에 업무 한 가지에서 AI 에이전트가 제대로 움직이는지 확인하는 방식입니다.

기업 AI 시범 사업이 실패한다는 MIT 보고서 결론을 접하셨을 수 있습니다. 다만 보고서 스스로 결론이 공식 기업 보고가 아닌 개별 인터뷰에 바탕을 둔 대략적 수준이라고 밝히고 있습니다. 보고서 결론은 참고할 수 있지만 시작 규모를 정하는 근거로 쓰기에는 한계가 있습니다.

회사 전체에 도입할 때와 업무 한 가지로 시작할 때 하루는 어떻게 다릅니까?

회사 전체에 도입하면 여러 부서의 업무가 한꺼번에 바뀌지만 업무 한 가지로 시작하면 담당 직원의 업무만 바뀝니다. 회사 전체에 도입할 때 따라오는 일은 다음과 같습니다.

1. 여러 부서의 업무 방식을 한꺼번에 새로 정해야 합니다.

2. 직원 여러 명이 같은 시기에 새 방식에 적응해야 합니다.

3. 결과가 기대와 다를 때 어느 업무가 원인인지 확인하기 어렵습니다.

부서별 범위가 정해지기 전에는 비용 범위를 예상하기 어려울 수 있습니다. 직원이 새 방식을 쓰지 않으면 도입한 시스템의 결과도 확인할 수 없게 됩니다.

업무 한 가지로 시작하면 하루가 이렇게 달라집니다.

1. 시간: 새 방식에 적응하는 직원이 담당 직원으로 한정되어 다른 직원의 업무 시간은 그대로입니다.

2. 꾸준함: 정해 둔 기준대로 같은 업무를 반복 수행하므로 담당 직원이 바뀌어도 처리 기준이 유지됩니다.

3. 확장: 업무 한 가지의 결과를 기록으로 확인한 뒤에 다음 업무를 고를 수 있습니다.

4. 비용: 도입 범위가 업무 한 가지로 정해져 있어 비용 범위를 업무 단위로 확인할 수 있습니다.

업무 한 가지로 시작하면 바뀌는 범위와 비용 범위를 업무 단위로 확인할 수 있습니다.

우리 회사에는 어떤 업무가 맞습니까?

처리 순서를 말로 설명할 수 있고 반복 횟수가 많은 업무가 첫 후보입니다. 후보 업무는 다음 세 가지로 고릅니다.

1. 같은 순서로 반복됩니다. 학원의 상담 신청 접수나 시공 회사의 견적 요청 접수가 예입니다.

2. 처리 순서를 말로 설명할 수 있습니다. 처리할 때마다 판단 기준이 달라지는 업무는 첫 업무로 맞지 않을 수 있습니다.

3. 결과를 숫자로 확인할 수 있습니다. 처리 시간이나 처리 건수가 숫자의 예입니다.

쓰시는 프로그램이 둘 이상이고 직원이 프로그램 사이를 오가며 같은 내용을 입력하는 업무가 있다면 후보로 올려 볼 수 있습니다. 반대로 한 달에 몇 번 되지 않는 업무는 개발에 쓰는 비용에 비해 줄어드는 직원 시간이 작을 수 있어 첫 업무로 맞지 않을 수 있습니다.

후보에 들어가는지 판단하기 어려울 때는 담당 직원이 업무 한 건에 쓰는 시간을 일정 기간 적어 보는 방법이 있습니다. 적어 둔 시간은 후보 업무끼리 비교하는 자료가 되고 도입 후 비교할 기준으로도 쓸 수 있습니다.

고객은 도입하기 전에 무엇을 정하면 됩니까?

AI 에이전트가 업무를 수행하는 방식도 처음에 고객이 기준을 한 번 정해 두는 일에서 시작합니다. 정할 기준은 맡길 업무와 성과 기준, 확인 지점입니다.

1. 맡길 업무 한 가지와 맡기지 않을 범위를 정합니다.

2. 도입 전에 무엇을 성과로 볼지 숫자로 정합니다.

3. 결과를 담당 직원이 확인하고 승인하는 지점을 정합니다.

맡기지 않을 범위를 정해 두는 이유는 AI 에이전트가 처리할 일과 직원이 계속 처리할 일을 분리하기 위해서입니다. 범위가 분명하면 직원도 자기 업무에서 무엇이 달라지는지 미리 알 수 있습니다.

돈이나 고객 자료에 닿는 업무라면 담당 직원이 결과를 확인하고 승인한 뒤에 확정하는 방식으로 시작할 수 있습니다. 결과를 믿을 수 있는지 확인된 뒤에 승인 단계를 줄일지 고객이 정하시면 됩니다.

한 번 정한 기준은 도입한 뒤에도 바꿀 수 있습니다. 사업이 달라지면 맡기는 범위와 성과 기준을 다시 정하시면 됩니다.

도입한 뒤에는 무엇으로 성과를 확인합니까?

도입 전에 정해 둔 성과 기준 숫자를 도입 후에 같은 방법으로 측정해 비교합니다. 기준이 없으면 도입 후 숫자만 남아 좋아졌는지 판단할 수 없습니다.

도입 전에 측정할 수 있는 성과 기준을 정해 두면 도입한 뒤 같은 기준으로 결과를 확인할 수 있습니다. 확인된 가치는 다음에 어느 업무에 AI를 쓸지 우선순위를 정할 때도 참고가 됩니다.

도입한 뒤 확인할 항목은 처리 시간과 수정 건수, 직원 의견입니다.

1. 처리 시간: 업무 한 건을 처리하는 데 걸린 시간을 도입 전 기록과 비교합니다.

2. 수정 건수: 담당 직원이 결과를 확인하다 수정한 건이 있는지 봅니다.

3. 직원 의견: 담당 직원에게 업무가 달라진 점을 직접 묻습니다.

성과 기준에 도달하지 않았다면 맡긴 업무 범위나 처리 규칙을 수정해 다시 측정합니다. 다시 측정한 결과를 보고 같은 업무를 유지할지 다른 업무로 바꿀지 고객이 정하시면 됩니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없고 다섯 가지 조건에 따라 범위가 달라지므로 상담 후 견적으로 안내합니다.

1. 처리 단계: 맡길 업무의 처리 단계가 얼마나 많은지

2. 쓰시는 프로그램: 서로 연결해야 하는 프로그램이 얼마나 되는지

3. 자료 상태: 업무에 쓰는 자료가 정리되어 있는지 새로 모아야 하는지

4. 확인 지점: 결과를 담당 직원이 승인하는 단계를 둘지

5. 화면: 담당 직원이 쓸 관리자 화면이나 입력 폼이 필요한지

다섯 가지를 알려 주시면 업무 한 가지에 필요한 개발 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의에서 인계까지 다섯 단계로 진행됩니다.

1. 문의: 맡기려는 업무 한 가지와 지금 쓰시는 프로그램을 남기십시오.

2. 상담: 업무의 처리 순서와 성과 기준을 상담합니다.

3. 범위와 견적 안내: 상담 내용에 맞춰 개발 범위와 견적을 안내합니다. 견적을 보고 진행할지는 고객이 정하시면 됩니다.

4. 제작: 정한 범위대로 시스템을 제작합니다.

5. 인계: 시스템이 동작하는 장치와 계정을 고객에게 인계합니다.

그래서 지금 AI 에이전트를 도입할 준비가 되어 있습니까?

직원이 반복하는 업무가 있고 그 업무의 처리 시간이나 건수를 지금 기록하고 있다면 업무 한 가지로 시작할 조건이 갖춰진 상태입니다. 결과를 확인하고 승인할 담당 직원이 정해져 있는지도 살펴보실 만합니다.

엔소프 컴퍼니는 AI 에이전트 도입을 업무 한 가지로 시작하려는 고객께 맞춘 업무 자동화를 AI 에이전트로 개발해 드립니다

AI 에이전트를 회사 전체에 도입하기 전에 업무 한 가지부터 시작하고 싶으시다면 그렇게 시작하는 방법이 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 업무 한 가지를 수행하는 AI 에이전트를 업무 자동화로 개발해 드립니다. 어느 업무까지 맡길지는 고객이 정하시면 됩니다.

개발은 대상 업무 확정과 처리 규칙 정의에서 시작해 프로그램 연결과 실제 데이터로 하는 확인까지 엔소프 컴퍼니 한 곳에서 진행합니다. 완성된 모습은 이렇습니다.

1. 지금 쓰시는 프로그램을 바꾸지 않고 서로 연결해 두 곳에 옮겨 적던 내용이 한 번만 입력됩니다.

2. 신청과 접수는 들어오는 대로 종류별로 분류되어 담당 직원 앞에 모입니다.

3. 월말마다 손으로 만들던 정산표와 보고서가 정해 둔 양식으로 작성됩니다.

4. 직원이 결과를 확인하고 승인하는 관리자 화면과 입력 폼이 필요하시면 업무에 맞춰 개발합니다.

네 가지를 한 번에 맡기실 필요는 없고 업무 한 가지로 먼저 시작하셔도 됩니다. 옮겨 적고 분류하고 보고서를 만들던 직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 동작하는 자동화 시스템과 운영 절차 문서, 계정을 고객에게 넘겨드립니다.

월말이나 접수 마감 때 직원이 같은 내용을 두 번 입력하는 업무가 있다면 그 업무의 이름을 알려 주시면 됩니다.

프로젝트 문의하기

대시보드를 만들어 달라고 의뢰했는데 개발사에서 가장 먼저 받은 문서가 지표 정의 문서였다면 당황스러우실 수 있습니다. 대시보드는 매출이나 재방문 건수 같은 숫자를 한 화면에 모아 보여 주는 관리자 화면입니다. 그 숫자 하나하나를 지표라고 부릅니다. 화면 비용을 내는데 문서가 먼저 나오니 견적서에 불필요한 항목이 붙었다고 느끼실 수 있습니다.

그러나 큰 비용을 들여 완성한 대시보드를 직원이 열지 않는 일은 화면의 모양보다 숫자의 뜻이 정해지지 않은 데서 생기기도 합니다. 견적서에서 낯설게 보이던 지표 정의 항목은 직원이 열지 않는 이유와 이어져 있습니다.

대시보드가 완성됐는데 회의 때는 왜 다시 표 문서를 엽니까?

영업팀이 화면에 나온 이번 달 매출을 말하면 재무팀이 가진 표 문서의 매출과 숫자가 다릅니다. 영업팀은 주문을 받은 날을 기준으로 더했고 재무팀은 돈이 들어온 날을 기준으로 더했기 때문입니다. 어느 쪽도 계산을 틀리게 한 것은 아닙니다.

숫자가 다르면 회의의 첫 시간은 어느 숫자가 맞는지 확인하는 데 쓰입니다. 직원은 화면보다 익숙한 표 문서를 다시 열고 부서마다 가진 표를 서로 대조합니다. 그러는 동안 대시보드를 열어 보는 사람은 점점 줄어듭니다.

대표님 입장에서는 화면을 만드는 데 큰 비용이 들었는데 회의 모습이 달라지지 않은 셈입니다. 화면이 주문과 입금 기록을 정확히 가져와 보여 주고 있어도 상황은 같습니다. 주문일과 입금일 가운데 무엇을 매출이라 부를지가 정해지지 않았기 때문입니다.

직원이 대시보드를 열지 않는 원인이 화면 구성에 있는지 숫자의 뜻에 있는지는 회의에서 어느 자료를 먼저 펼치는지로 구분됩니다. 대시보드가 있는데도 표 문서를 먼저 연다면 숫자의 뜻이 원인일 수 있습니다. 이때 화면 디자인만 바꾸면 같은 다툼이 다시 생길 수 있습니다.

개발사는 왜 화면보다 지표 정의 문서를 먼저 내밉니까?

지표 정의 문서는 같은 지표가 보고서마다 다른 숫자로 나오지 않도록 기준을 한 곳에 모아 둔 문서입니다. 매출을 주문일로 더할지 입금일로 더할지가 적혀 있지 않으면 영업팀과 재무팀이 각자의 기준으로 계산합니다. 화면을 먼저 만들면 한쪽 기준만 화면에 담기고 다른 부서는 자기 표 문서를 계속 씁니다.

문서에는 지표를 쉬운 말로 풀어 쓴 정의와 계산 공식이 들어갑니다. 소수점 아래를 어떻게 반올림할지와 매일 계산할지 매주 계산할지도 함께 적습니다. 매출이라면 취소된 주문을 뺄지 말지도 문서에서 정해집니다.

지표마다 그 뜻에 책임지는 사업 쪽 담당자가 한 명 있어야 합니다. 매출의 기준은 영업과 재무를 아는 사람이 정할 일이기 때문입니다. 개발사는 정해진 기준을 계산식으로 옮겨 화면에 구현합니다.

지표 정의를 하나로 통일해 두면 회의가 시작되기 전에 숫자를 두고 벌이는 다툼의 상당 부분이 사라질 수 있습니다. 직원이 화면을 믿고 열어 보려면 숫자의 뜻이 먼저 같아져야 합니다. 지표 정의 문서가 화면 제작보다 앞에 놓이는 까닭입니다.

표의 칸 이름을 설명한 문서가 있으면 지표 정의 문서는 없어도 됩니까?

칸 이름을 설명한 문서와 지표 정의 문서는 적는 내용이 서로 다릅니다. 칸 이름을 설명한 문서는 데이터 사전이라고 부르며 저장된 자료의 칸마다 이름과 담긴 내용을 적습니다. 예를 들어 주문 기록에 금액 칸과 날짜 칸이 있다는 사실을 알려 줍니다.

지표 정의는 그 칸들로 숫자를 어떻게 계산할지 적은 문서입니다. 금액 칸과 날짜 칸이 있어도 매출을 날짜 기준으로 더할지 환불을 뺄지는 칸 설명서에 나오지 않습니다. 계산 방식은 지표 정의 문서에만 적힙니다.

칸 설명서만 있고 지표 정의가 없으면 화면에 올릴 숫자의 기준을 개발자가 임의로 정하게 됩니다. 그렇게 만든 화면은 개발자가 짐작한 기준으로 계산되므로 부서의 기준과 어긋날 수 있습니다. 어긋난 숫자는 앞서 본 회의 장면을 다시 만듭니다.

자료 칸 설명서와 지표 정의 문서는 서로 대신할 수 없으므로 견적서에서 각각 따로 확인할 항목입니다. 칸 설명서는 있는데 지표 정의가 없는 경우도 있고 그 반대도 있습니다. 어느 쪽이 빠져 있는지는 항목 이름만으로 알기 어려워 내용을 물어봐야 합니다.

지표 정의 문서를 받은 뒤 대시보드는 어떤 순서로 만들어집니까?

화면을 만드는 일은 지표를 정하고 숫자를 모으는 방법을 설계한 다음 단계입니다. 순서는 다음과 같습니다.

1. 핵심 지표(KPI)와 위계를 정합니다. 핵심 지표는 회사가 가장 먼저 보는 숫자이고 위계는 그 숫자 아래에서 원인을 설명하는 숫자를 나누는 일입니다.

2. 숫자를 모으는 방법을 설계합니다. 주문과 방문 기록처럼 여러 곳에 쌓이는 자료를 대시보드로 모읍니다.

3. 대시보드 화면을 설계하고 구축합니다. 정해진 지표를 화면에 배치하고 실제로 동작하게 만듭니다.

4. 이상 감지와 알림 규칙을 정합니다. 숫자가 정해 둔 범위를 벗어나면 담당자에게 알리는 규칙입니다.

위계가 정해지면 화면 첫 장에 먼저 볼 숫자만 놓을 수 있습니다. 직원은 많은 숫자 앞에서 무엇부터 읽을지 고민하지 않아도 됩니다.

이상 감지 규칙은 지표 정의가 있어야 만들 수 있습니다. 어느 범위를 벗어난 숫자를 알릴지는 그 지표를 어떻게 계산하는지에 따라 달라지기 때문입니다. 규칙이 없으면 문제가 생긴 뒤에야 알게 되는 일이 이어질 수 있습니다.

화면 구축은 지표 정의 다음 단계이므로 견적서에 화면 항목만 적혀 있다면 지표를 누가 정하는지가 아직 비어 있다는 뜻일 수 있습니다. 화면이 먼저 완성되고 지표 정의가 나중에 따라오면 완성된 화면을 다시 수정해야 할 수 있습니다.

견적서에 지표 정의와 이상 감지 규칙 항목이 있는지는 어떻게 확인합니까?

항목 이름을 찾는 데서 끝내지 않고 각 항목이 어떤 결과물로 남는지 물어보면 됩니다. 견적서에는 「지표 체계 정의」나 「이상 감지 규칙 정의」 같은 이름으로 적힐 수 있습니다. 이름이 비슷해도 어디까지 포함하는지는 개발사마다 다를 수 있습니다.

개발사에 다음 세 가지를 물어보시면 됩니다.

1. 지표 정의 항목이 있는지 묻습니다. 없다면 화면에 올릴 숫자의 기준을 누가 어떻게 정하는지 함께 묻습니다.

2. 지표 정의가 문서로 남는지 묻습니다. 지표마다 담당자 이름이 적히는지도 문서를 보면 알 수 있습니다.

3. 이상 감지 규칙이 어디까지인지 묻습니다. 알릴 범위의 기준과 알림을 받을 사람까지 정하는지 화면 표시만 하는지에 따라 범위가 달라집니다.

답변이 모호하면 견적서의 범위가 화면 제작까지일 수 있습니다. 그때는 지표 정의와 이상 감지 규칙을 다른 방식으로 정할지 개발사와 이야기해 볼 수 있습니다.

견적서 항목의 이름보다 그 항목을 마쳤을 때 어떤 문서와 규칙이 남는지가 업체를 비교하는 기준입니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없고 다음 네 가지에 따라 범위가 달라지므로 상담 후 견적으로 안내합니다.

1. 보려는 지표의 개수와 지표 사이의 위계: 먼저 보는 숫자와 그 아래 숫자가 얼마나 많은지

2. 숫자가 쌓여 있는 곳의 수와 형태: 주문 시스템에 있는지 표 문서에 흩어져 있는지

3. 이상 감지와 알림 여부: 알림을 둘지와 누구에게 알릴지

4. 보는 사람별 범위: 직원마다 볼 수 있는 지표를 나눌지

보려는 지표와 숫자가 쌓인 곳, 알림 여부, 보는 사람의 범위를 알려 주시면 견적 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의 후 순서는 다음과 같습니다.

1. 문의를 남기시면 지금 보려는 숫자와 숫자가 쌓인 곳을 중심으로 상담합니다.

2. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

3. 진행하시기로 하면 지표를 정한 뒤 대시보드를 제작합니다.

4. 숫자가 모이는 장치와 계정을 고객에게 넘겨드립니다.

그래서 대시보드 견적서에서 지표 정의 항목을 확인할 만한 때는 언제입니까?

같은 지표의 숫자가 부서마다 다르게 나온 적이 있다면 지표 정의 항목을 확인할 만합니다. 회의 전에 표 문서를 대조하는 시간이 따로 드는 회사도 마찬가지입니다. 이런 회사라면 지표 정의 항목이 어디까지 포함되는지 개발사에 물어보시면 됩니다.

반대로 보는 지표가 적고 숫자가 한 곳에서만 나온다면 지표 정의 문서는 짧게 끝날 수 있습니다. 짧은 문서라도 매출 같은 숫자의 기준이 적혀 있는지는 물어볼 수 있습니다.

엔소프 컴퍼니는 아무도 보지 않는 대시보드에 맞춘 지표 정의와 업무 자동화를 AI 에이전트로 개발해 드립니다

큰 비용을 들여 만들고도 아무도 보지 않는 대시보드가 걱정이시라면 지표를 정하는 단계부터 시작하는 방법이 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 지표 정의 문서와 이상 감지 규칙 정의서, 관리자 화면 구축을 한 곳에서 개발해 드립니다. 이 가운데 어디까지 맡기실지는 고객이 고르시면 됩니다.

대시보드에 들어갈 숫자를 직원이 직접 옮겨 합치고 있다면 그 일은 AI 에이전트가 수행하도록 업무 자동화로 개발해 드립니다. AI 에이전트는 고객이 정한 기준대로 숫자를 옮기고 합치는 반복 업무를 사람 대신 수행하는 프로그램입니다. 완성된 모습은 다음과 같습니다.

1. 주문 시스템과 회계 프로그램은 그대로 두고 사이만 이어져 같은 숫자를 두 곳에 옮겨 적는 일이 없어집니다.

2. 회의 전에 직원이 손으로 합치던 월 매출표와 보고서가 정해 둔 규칙대로 자동으로 만들어집니다.

3. 영업팀과 재무팀에서 들어오는 숫자는 정해 둔 지표 기준에 맞춰 종류별로 나뉘어 대시보드에 모입니다.

4. 직원이 숫자를 확인하는 관리자 화면과 입력 폼이 필요하시면 함께 개발합니다.

네 가지를 한 번에 하실 필요는 없고 월 매출 보고서 하나부터 시작하셔도 됩니다. 숫자를 옮기고 합치던 직원의 시간과 인건비 부담이 줄어듭니다.

프로젝트를 마치면 지표 정의 문서와 숫자가 모이는 장치, 동작하는 대시보드, 이상 감지 규칙 정의서를 넘겨드립니다. 자동화를 맡기셨다면 동작하는 자동화 시스템과 계정도 함께 넘겨드립니다.

대시보드로 가장 먼저 보고 싶은 숫자 하나와 그 숫자가 지금 어디에 쌓여 있는지 알려 주시면 됩니다.

프로젝트 문의하기

사이트를 연 지 한참 지난 어느 날 카드 명세서에 처음 보는 결제 항목이 올라와 있습니다. 호스팅은 사이트 파일을 올려 두고 방문자에게 보여 주는 공간을 빌리는 서비스입니다. 호스팅 업체에서 온 청구일 수도 있고 직원을 편집자로 추가한 뒤 붙은 요금일 수도 있습니다.

워드프레스는 웹사이트를 만들고 글과 사진을 수정하는 프로그램이고 Framer(프레이머)는 웹사이트를 만드는 서비스입니다. 두 방식은 같은 사이트를 만들어도 매달 돈이 나가는 곳이 서로 다릅니다. 처음 낸 제작비만 비교하면 매달 나가는 돈의 차이가 보이지 않습니다.

사이트를 연 뒤 처음 보는 결제가 생기는 일은 어떤 모습입니까?

제작비를 낸 업체와 이용료를 받는 업체가 서로 다른 회사일 때 처음 보는 결제가 생깁니다. 직접 설치해 운영하는 워드프레스를 이 글에서는 설치형 워드프레스라고 부르겠습니다. 설치형 워드프레스는 필요한 프로그램 조건을 갖춘 호스팅 업체를 따로 구해야 합니다.

학원 원장이 설치형 워드프레스로 사이트를 열었다면 제작비 영수증과 호스팅 이용료 청구서가 서로 다른 곳에서 옵니다. 청구서가 따로 오는 것은 호스팅을 별도로 계약했기 때문입니다. 제작비를 한 번 냈다고 해서 사이트를 올려 둘 공간까지 해결된 것은 아닙니다.

워드프레스닷컴(WordPress.com, 워드프레스를 호스팅까지 묶어 파는 서비스)은 무료 요금제에도 호스팅이 들어 있어 별도 호스팅 계약이 필요 없습니다. 같은 워드프레스라는 이름이어도 설치형인지 워드프레스닷컴인지에 따라 호스팅 계약이 필요한지가 달라집니다. 업체가 워드프레스를 권할 때 어느 쪽을 뜻하는지 먼저 물어볼 이유가 여기에 있습니다.

병원 원장이 Framer 가격표에서 월 단위로 적힌 금액을 보고 매달 결제되는 줄 알았다고 해 보겠습니다. 실제 청구는 결제할 때 고른 주기에 따라 이루어집니다. 그래서 명세서에 결제가 찍히는 시점이 가격표의 표시와 다를 수 있습니다.

방식마다 돈을 받는 곳이 왜 다릅니까?

사이트를 만드는 프로그램과 올려 두는 공간, 관리하는 사람이 방식마다 서로 다른 곳에 있기 때문입니다. 설치형 워드프레스에서는 공간을 호스팅 업체가 맡고 프로그램을 관리하는 일은 운영자가 맡습니다. 운영자는 사이트를 실제로 관리하는 직원이나 외부 업체를 말합니다. 그래서 돈이 나가는 곳이 업체 청구서와 사람의 시간으로 나뉩니다.

설치형 워드프레스는 새 버전이 나오면 운영자가 계속 업데이트해야 합니다. 워드프레스 공식 문서는 업데이트 전에 백업해 두라고 안내합니다. 백업은 사이트 내용을 따로 복사해 두는 일입니다. 운영자가 직원이면 그 근무 시간이 쓰이고 외부 업체이면 업체에 지급하는 비용이 생깁니다. 설치형 워드프레스에서는 호스팅 이용료와 업데이트 담당이 매달 돈이 나가는 곳입니다.

Framer에서는 요금제 안의 조건이 돈이 나가는 곳이 됩니다. 편집자를 추가하면 한 명마다 월 요금이 붙고 보기만 하는 사용자는 무료입니다. 직원 여러 명이 사이트를 수정하려면 편집자 수만큼 월 요금이 늘어납니다.

대역폭은 방문자가 사이트를 볼 때 오가는 자료의 양을 말합니다. Framer는 대역폭 같은 한도를 넘겨도 한 달은 허용합니다. 그다음에는 요금제 업그레이드를 요구합니다. Framer에서는 결제 주기와 편집자 수와 사용 한도가 매달 돈이 나가는 곳입니다.

견적서를 받으면 돈이 나가는 곳을 어떻게 확인합니까?

견적서에 적힌 첫 비용과 별도로 호스팅, 업데이트, 편집자 수를 누가 맡는지 업체에 물어 확인할 수 있습니다. 업체에 묻는 말은 이렇습니다.

1. 호스팅 이용료를 어느 업체에 누구 이름으로 내는지 묻습니다.

2. 새 버전이 나올 때 업데이트와 백업을 누가 하는지 묻습니다.

3. 편집자가 몇 명 필요한지와 사용 한도를 넘기면 어떻게 되는지 묻습니다.

호스팅 질문과 업데이트 질문은 설치형 워드프레스에 필요하고 편집자 질문은 Framer에 필요합니다. 결제 명의를 묻는 이유는 사이트를 넘겨받은 뒤에도 청구서가 어디로 오는지 알기 위해서입니다. 답은 문서로 받아 두시면 담당자가 바뀐 뒤에도 확인할 수 있습니다.

사이트로 하는 일과 수정 주기는 어떻게 적어 둡니까?

사이트로 손님에게 무엇을 하게 할지와 한 달에 몇 번쯤 수정할지를 문장으로 적어 두시면 됩니다. 회사 소개만 하는 사이트와 상담 신청을 받는 사이트는 필요한 관리가 다릅니다. 적어 둔 내용이 있으면 업체가 어느 방식에서 어떤 항목이 매달 나가는지 설명하기 쉽습니다.

시공 회사가 공사 사례를 자주 올린다면 글을 올리는 직원이 여럿 필요할 수 있습니다. 학원처럼 공지를 직원이 직접 올린다면 직원 수만큼 편집 권한이 필요합니다. 이 인원이 Framer에서는 편집자 요금과 이어집니다.

행사 안내처럼 방문자가 한꺼번에 늘어나는 시기가 있다면 그 시기도 적어 둡니다. 방문자가 늘면 사용 한도에 가까워질 수 있기 때문입니다. 수정을 직원이 직접 할지 업체에 맡길지도 함께 적어 두시면 됩니다.

글과 사진을 수정하는 일을 직원이 맡으면 직원의 시간이 쓰입니다. 업체에 맡기면 업체에 지급하는 비용이 매달 나가는 곳이 됩니다. 어느 쪽인지 정해지지 않았다면 정해지지 않았다고 적어 두셔도 됩니다.

비용은 무엇에 따라 달라집니까?

비용은 사이트로 하는 일과 수정 주기, 수정하는 사람, 지금 쓰는 사이트 여부에 따라 달라집니다.

1. 사이트로 하는 일: 회사 소개만 하는지 상담 신청이나 예약을 받는지

2. 수정 주기: 소식과 사례를 얼마나 자주 올리는지

3. 수정하는 사람: 직원이 직접 하는지 업체에 맡기는지와 편집자 수

4. 지금 쓰는 사이트: 새로 만드는지 이미 있는 사이트를 옮기는지

사이트로 하는 일과 수정 주기, 수정하는 사람, 지금 사이트 상황을 알려 주시면 제작 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의를 남기시면 상담이 먼저 열립니다. 순서는 이렇습니다.

1. 고객이 문의 양식에 사이트로 하려는 일과 수정 주기를 남깁니다.

2. 엔소프 컴퍼니가 내용을 듣고 상담합니다.

3. 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

4. 진행하시기로 하면 사이트를 제작합니다.

5. 완성한 사이트와 계정을 고객에게 넘겨드립니다.

그래서 매달 나가는 돈을 기준으로 방식을 정해도 됩니까?

직접 수정할 직원이 여럿이거나 업데이트를 맡을 담당이 없다면 매달 나가는 돈의 구조를 비교해 볼 만합니다. 방문자가 몰리는 시기가 있는지도 비교 기준이 됩니다.

엔소프 컴퍼니는 매달 나가는 사이트 비용 구조에 맞춘 웹사이트 구축과 글 올리기를 AI 에이전트로 개발해 드립니다

워드프레스와 Framer 가운데 어느 쪽이 맞는지 매달 나가는 돈 때문에 정하기 어려우실 수 있습니다. 그럴 때는 사이트로 하는 일과 수정 주기를 먼저 정하는 방법이 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 그 내용을 듣고 워드프레스와 Framer를 포함해 맞는 사이트 제작 방식을 추천합니다. 정하신 방식으로 사이트도 개발해 드리며 기획과 디자인, 개발, 배포까지 한 곳에서 진행하므로 업체를 따로 조율하는 부담이 줄어듭니다.

사이트를 연 뒤에는 소식과 안내 글을 올리고 문의를 분류하는 일이 직원에게 남습니다. AI 에이전트는 정해 둔 기준대로 일을 사람 대신 수행하는 프로그램입니다. 고객이 원하시면 그 일을 AI 에이전트가 수행하도록 개발해 드립니다. 완성된 모습은 이렇습니다.

1. 고객이 정한 주제의 공지와 소식 글이 사이트에 올라가므로 글을 올리던 직원이나 외부 업체의 일이 줄어듭니다.

2. 상담 신청과 문의가 접수되는 대로 종류별로 나뉘어 담당 직원에게 전달됩니다.

3. 쓰시던 프로그램은 그대로 두고 이어져 같은 내용을 두 번 옮겨 적는 일이 없어집니다.

세 가지를 한 번에 맡기실 필요는 없고 하나부터 시작하셔도 됩니다. 올리기 전에 보고 승인하는 방식도 고르실 수 있습니다. 글을 올리고 문의를 나누던 직원의 시간과 인건비 부담이 줄어듭니다.

프로젝트를 마치면 배포된 웹사이트와 콘텐츠 관리 환경, 계정을 넘겨드립니다. 배포는 완성한 사이트를 인터넷에 공개하는 일이고 콘텐츠 관리 환경은 직원이 글과 사진을 직접 수정하는 관리 화면입니다. 자동화를 맡기셨다면 글이 올라가고 문의가 나뉘는 장치도 함께 받으실 수 있습니다.

사이트로 하려는 일과 수정을 직원이 할지 업체에 맡길지를 알려 주시면 됩니다.

프로젝트 문의하기

저녁 업무를 마치고 나서야 블로그 창을 여는 날이 있으십니까? 낮에는 손님 응대와 직원 지시로 시간이 지나가고 밤이 되어서야 글 한 편을 쓰기 시작합니다. 이런 날이 이어지면 AI 에이전트를 도입해 일을 맡기고 싶어지는 것이 자연스럽습니다.

다만 AI 에이전트 도입은 프로그램을 고르는 일보다 맡길 업무를 정리하는 일에서 시작합니다. 어떤 일을 어떤 순서로 처리하는지 적혀 있어야 AI 에이전트에게 맡길 수 있기 때문입니다. 이 글은 AI 에이전트가 무엇인지부터 설명합니다. 이어서 우리 회사에 맞는지와 도입 방법, 도입한 뒤의 확인 방법을 순서대로 설명합니다.

AI 에이전트는 무엇이고 업무 정리와 어떤 관계입니까?

AI 에이전트는 AI가 일의 진행 과정과 도구 사용을 스스로 정하는 시스템입니다. AI 모델 개발사 Anthropic(앤트로픽)은 AI 에이전트와 워크플로를 구분합니다. 워크플로는 사람이 정해 둔 순서에 따라 AI와 도구가 움직이는 방식입니다.

문의 접수를 예로 들면 차이가 보입니다. 접수 내용을 종류별로 나누고 담당자에게 전달하는 순서를 사람이 정해 두었다면 워크플로입니다. 순서까지 AI가 스스로 정하면 AI 에이전트입니다. 어느 쪽이든 맡길 범위는 회사가 정하고 처리 기준은 회사가 알고 있어야 합니다.

Anthropic은 가능한 한 가장 단순한 해법을 찾고 복잡성은 필요할 때만 늘리라고 권합니다. 업무 순서가 글로 적혀 있으면 단순한 방식으로 충분한지 먼저 확인할 수 있습니다. 업무 순서가 글로 적혀 있지 않으면 어느 방식이 맞는지 판단할 근거가 없습니다.

업무 정리는 AI 에이전트 도입 전에 하는 일입니다. 직원이 어떤 자료를 받아 무엇을 확인하고 누구에게 전달하는지 순서대로 적어 두는 것이 그 내용입니다. 학원이라면 수강 문의 접수에서 안내까지, 시공 회사라면 견적 요청에서 현장 일정 확인까지가 범위가 됩니다. 어디까지 맡길지는 대표님이 정하시면 됩니다.

우리 회사 업무는 AI 에이전트에 맡길 만합니까?

순서를 글로 적을 수 있고 되풀이되는 업무가 AI 에이전트에 맞습니다. 직원의 시간을 많이 쓰는 반복 업무로는 다음 세 가지가 있습니다.

1. 같은 내용을 두 곳 이상에 옮겨 적는 일

2. 매달 정산과 보고서를 직접 만드는 일

3. 신청과 접수를 종류별로 나누는 일

옮겨 적기와 보고서 작성, 접수 분류는 받는 자료와 처리 기준이 정해져 있으면 AI 에이전트에게 맡길 수 있습니다. 처리 기준이 직원마다 다르면 기준부터 맞춰야 하고 그 기준을 글로 적는 일이 업무 정리입니다. 반복 업무에 쓰는 시간만큼 손님 응대와 상담에 쓸 시간이 줄어듭니다.

SAS(사스) 조사에서는 초기 단계에 머문 중소기업이 시험 도입을 넘어 넓혀 가려면 탄탄한 데이터 기반과 실행 규율이 더 필요하다고 나왔습니다. 데이터 기반은 업무 자료가 어디에 어떤 형태로 있는지 알고 있는 상태를 말합니다. 실행 규율은 정해 둔 순서를 지키는 습관을 말합니다. 업무 정리에서 자료 위치와 순서를 적어 두면 두 가지에 가까워집니다.

다음 상황에 해당하는 대표님께 잘 맞습니다.

1. 같은 내용을 두 번 옮겨 적는 직원이 있는 대표님

2. 매달 정산과 보고서 작성에 직원의 시간이 쓰이는 대표님

3. 쓰시는 프로그램은 바꾸지 않고 사이만 잇고 싶은 대표님

업무가 드물게 생기거나 처리 기준이 적혀 있지 않다면 업무 정리를 먼저 마치고 AI 에이전트 도입 여부를 대표님이 판단하실 수 있습니다. 그때는 반복 횟수와 처리 기준이 눈에 보이므로 도입 여부를 직접 비교하기 쉽습니다. 도입 시점은 대표님이 정하시면 됩니다.

업무를 맡기고 나면 하루가 어떻게 달라집니까?

먼저 달라지는 것은 직원이 옮겨 적고 나누고 만들던 시간입니다. 맡긴 업무가 정해 둔 기준대로 수행되면 변화는 다음 네 가지로 나타납니다.

1. 시간: 옮겨 적고 분류하던 시간이 줄어 손님 응대와 상담에 쓸 수 있습니다.

2. 꾸준함: 담당 직원이 자리를 비운 날에도 정해 둔 기준대로 접수가 나뉩니다.

3. 창구 확장: 신청과 문의가 들어오는 창구가 늘어도 적어 둔 기준을 같은 방식으로 적용할 수 있습니다.

4. 비용: 옮겨 적고 보고서를 만들던 직원의 인건비 부담이 줄어듭니다.

직접 하는 하루는 접수 내용을 옮기고 종류별로 나눈 뒤 월말에 보고서를 만드는 흐름입니다. 맡긴 하루에는 대표님이나 담당 직원이 결과를 확인하는 일로 바뀝니다. 업무 순서와 처리 기준이 글로 적혀 있어야 AI 에이전트가 같은 기준으로 일을 수행할 수 있습니다.

병원이라면 예약 변경 내용을 두 곳에 입력하던 시간이 줄어듭니다. 제조 회사라면 거래처 발주서를 종류별로 분류하던 시간이 줄어듭니다. 줄어드는 시간은 업무마다 다르므로 맡길 업무를 정한 뒤에 비교하셔야 합니다.

도입 전에 한 업무에 직원이 쓰는 시간을 기록해 두면 비교 기준이 생깁니다. 업무를 시작한 시각과 마친 시각을 직원이 적는 정도로 충분합니다. 이 기록은 도입한 뒤 결과를 확인하는 절에서 다시 쓰입니다.

도입하려면 대표님은 무엇을 먼저 정하시면 됩니까?

대표님이 하실 일은 처음에 기준을 한 번 정하는 것입니다. 버튼 하나로 알아서 움직이는 모습을 기대하실 수 있지만 그 버튼이 따르는 기준은 회사 업무에서 나옵니다. 정할 기준은 다음 세 가지입니다.

1. 맡길 업무 한 가지를 고릅니다.

2. 그 업무의 순서와 처리 기준을 글로 적습니다.

3. 사람이 확인하고 승인할 단계를 정합니다.

업무는 직원이 되풀이하는 일 가운데 시간이 많이 드는 일이 후보가 됩니다. 순서에는 무엇을 받아 무엇을 확인하고 누구에게 전달하는지가 들어갑니다. 예외도 함께 적습니다. 금액이 큰 건이나 처음 거래하는 곳의 건처럼 사람이 직접 보아야 하는 상황을 미리 적어 두는 것입니다.

사람이 확인하는 단계는 결과를 반영하기 전에 보고 승인하는 방식으로 둘 수 있습니다. 믿고 맡기는 방식으로 둘 수도 있습니다. 어느 쪽으로 시작할지는 대표님이 고르시면 됩니다.

개발사는 대표님이 정한 범위를 문서로 남기고 그 문서를 기준으로 개발합니다. 문서에 적히지 않은 업무는 개발 범위에 들어가지 않을 수 있습니다. 처음에 업무 한 가지로 시작하면 결과를 비교할 대상이 분명합니다.

정해 둔 기준은 업무가 바뀌면 다시 수정하실 수 있습니다. 수정할 때는 바꾼 내용을 문서에 남겨 두어야 개발 범위와 어긋나지 않습니다.

도입한 뒤에는 무엇을 보고 결과를 확인합니까?

적어 둔 업무 순서와 처리 결과를 나란히 놓고 비교하면 됩니다. 결과가 쌓이는 기록 문서나 관리자 화면에서 다음 네 가지를 봅니다.

1. 접수된 건수와 처리된 건수가 같은지

2. 종류별로 나뉜 결과가 적어 둔 기준과 맞는지

3. 사람이 확인하기로 한 예외 건이 담당 직원에게 전달됐는지

4. 업무에 쓰이는 직원의 시간이 도입 전 기록보다 줄었는지

처음에는 짧은 간격으로 보다가 결과가 기준대로 나오면 간격을 늘릴 수 있습니다. 확인 간격은 업무의 중요도와 건수에 따라 대표님이 정하시면 됩니다.

결과가 기준과 다르면 먼저 적어 둔 기준에 빠진 예외가 있는지 확인합니다. 예외를 기준에 추가하고 문서에 남기면 같은 상황이 다시 생겼을 때 같은 방식으로 처리하도록 수정할 수 있습니다. 기준을 적지 않은 업무는 무엇과 비교할지 정해져 있지 않아 이 확인이 어렵습니다.

확인은 도입 뒤에 새로 만드는 일이 아니라 업무 정리에서 적어 둔 순서와 기준을 다시 열어 비교하는 일입니다. 담당 직원이 바뀌어도 같은 문서를 기준으로 확인할 수 있습니다. 확인에서 나온 수정 사항은 문서에 이어서 남기시면 됩니다.

비용은 무엇에 따라 달라집니까?

맡길 업무의 범위와 정리 상태에 따라 비용이 달라집니다. 정해진 가격표는 없고 아래 다섯 가지 기준으로 견적 범위를 안내합니다.

1. 맡길 업무가 한 가지인지 여러 가지인지

2. 업무 순서와 처리 기준이 글로 적혀 있는지: 적혀 있지 않으면 업무 정리 단계가 범위에 들어갑니다

3. 연결할 프로그램이 몇 가지인지와 서로 자료를 주고받을 수 있는지

4. 직원이 결과를 확인하는 관리자 화면이나 입력 폼이 필요한지

5. 사람이 승인하는 단계를 둘지

이 다섯 가지를 알려 주시면 견적 범위를 안내할 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의하신 뒤의 순서는 다음과 같습니다.

1. 문의: 프로젝트 문의하기에서 맡기고 싶은 업무를 남기시면 됩니다.

2. 상담: 비용 기준 다섯 가지를 중심으로 업무 내용을 듣습니다.

3. 범위와 견적 안내: 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보고 진행할지는 고객이 정하시면 됩니다.

4. 제작: 정한 범위를 문서로 남기고 그 문서를 기준으로 만듭니다.

5. 장치와 계정 인계: 프로젝트를 마치면 동작하는 장치와 계정을 넘겨드립니다.

그래서 AI 에이전트 도입을 지금 시작해야 합니까?

맡기려는 업무 한 가지를 직원 여러 명에게 순서대로 설명해 달라고 했을 때 설명이 같다면 AI 에이전트 도입을 알아보실 만합니다. 설명이 서로 다르다면 업무 정리에서 기준을 맞추는 시간이 먼저 필요합니다.

엔소프 컴퍼니는 AI 에이전트 도입 전 업무 정리에 맞춘 기획·설계와 업무 자동화를 AI 에이전트로 개발해 드립니다

AI 에이전트 도입 전에 업무 정리가 막막하시다면 기획·설계에서 시작하는 방법이 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 맡길 업무의 목표와 처리 규칙, 예외 규칙, 필요한 화면을 문서로 남깁니다. 그 문서를 기준으로 개발하며 문서는 다른 개발사에 그대로 전달할 수 있는 형태입니다.

이어서 AI 에이전트가 업무를 수행하는 업무 자동화도 개발해 드립니다. 대상 업무 확정과 처리 규칙 정의에서 시작해 프로그램 연결과 실제 자료로 하는 확인까지 엔소프 컴퍼니 한 곳에서 진행합니다. 완성된 모습은 다음과 같습니다.

1. 쓰시는 프로그램은 그대로 두고 사이만 이어져 같은 내용을 두 번 옮겨 적는 일이 없어집니다.

2. 문의와 신청이 들어오면 업무 정리에서 적어 둔 기준에 따라 종류별로 나뉩니다.

3. 월말마다 직원이 만들던 정산표와 보고서가 정해 둔 양식대로 작성됩니다.

4. 직원이 결과를 확인하는 관리자 화면과 입력 폼이 필요하시면 함께 개발합니다.

네 가지 가운데 업무 정리를 마친 한 가지만 먼저 맡기셔도 됩니다. 정리한 업무를 AI 에이전트가 수행하면 그 업무에 쓰던 직원의 시간과 인건비 부담이 줄어듭니다.

프로젝트를 마치면 요구사항 정의서와 화면 설계서, 데이터 구조 정의서를 넘겨드립니다. 요구사항 정의서에는 고객이 맡기기로 정한 업무가 기능으로 적히고 화면 설계서에는 직원이 결과를 확인하는 화면이 그려집니다. 데이터 구조 정의서는 칸의 이름과 칸 사이의 연결을 적은 문서입니다. 업무 자동화를 맡기셨다면 동작하는 자동화 시스템과 계정도 넘겨드립니다.

지금 직원이 되풀이하는 업무 한 가지와 그 업무를 처리하는 순서를 알려 주시면 됩니다.

프로젝트 문의하기

소개 페이지만 있는 학원 사이트를 열고 얼마 뒤 수강 예약을 받고 싶어졌다고 해 보겠습니다. 개발사에 문의했더니 예약은 별도 작업이라는 답이 오고 결제와 회원 전용 자료까지 원하시면 사이트를 만든 방식부터 다시 보자는 말이 이어집니다. 사이트는 멀쩡한데 기능을 추가하려는 순간 일이 멈춘 것처럼 보이는 상황입니다.

이런 상황은 구축 방식에 따라 기능이 추가되는 길이 달라서 생깁니다. 구축 방식은 사이트를 만드는 방식의 종류를 가리키는 말입니다. 워드프레스(글과 사진을 관리 화면에서 수정하는 사이트 제작 프로그램)와 Next.js(개발자가 코드를 작성해 사이트를 만드는 방식)는 기능이 추가되는 길이 서로 다릅니다.

수강 예약을 받으려는 순간 사이트에서 어떤 일이 생깁니까?

예약 기능은 소개 페이지와 달리 신청 내용을 저장하고 담당 직원에게 전달해야 하는 기능입니다. 글과 사진을 보여 주던 사이트에 새 기능이 더해져야 하므로 처음 요청 범위에 없었다면 추가 작업으로 따로 논의하게 됩니다.

결제는 예약보다 한 단계 더 나아갑니다. 손님이 낸 금액과 예약 내역이 서로 맞아야 하고 취소나 환불 같은 예외도 정해져 있어야 하기 때문입니다. 결제 기능이 추가되면 예약 기능과 이어지는 방식도 함께 점검해야 합니다.

회원 기능은 예약과 결제 양쪽에 영향을 줍니다. 로그인한 회원에게만 수강 내역이나 자료를 보여 주려면 누가 무엇을 볼 수 있는지 정해야 하기 때문입니다. 회원 기능을 가장 나중에 요청하더라도 먼저 만든 예약과 결제 화면을 다시 살펴야 할 수 있습니다.

기능이 하나씩 늘 때마다 같은 질문이 생깁니다. 새 기능이 지금의 구축 방식에 어떻게 추가되며 기존 화면과 어떻게 이어지는지입니다. 예약·결제·회원 기능이 추가되는 방식은 워드프레스와 Next.js가 서로 다릅니다.

워드프레스와 Next.js는 기능이 추가되는 방식이 어떻게 다릅니까?

워드프레스는 플러그인을 더하는 방식으로 기능이 추가되고 Next.js는 로그인 상태 유지처럼 회원 기능의 일부를 개발자가 직접 처리해야 합니다. 플러그인은 워드프레스의 기본 기능을 넓히는 코드 묶음이며 예약·결제·회원 기능이 이런 방식으로 추가됩니다. 이미 만들어진 플러그인을 쓰는 방식이므로 필요한 기능이 있는지 먼저 찾아볼 수 있습니다.

원하는 동작이 만들어진 플러그인에 없을 때도 길이 있습니다. 워드프레스 개발자 핸드북은 직접 플러그인을 만드는 일도 워드프레스에 기능을 더하는 일로 설명합니다. 맞는 플러그인이 없다면 개발사가 새 플러그인을 만들어 더하는 방법이 가능한지 물어볼 수 있습니다.

Next.js 공식 문서는 로그인 같은 회원 기능을 직접 만들기보다 인증 라이브러리를 쓰기를 권합니다. 인증 라이브러리는 로그인 기능을 미리 만들어 둔 코드 묶음입니다. 그래서 Next.js로 회원 기능을 추가할 때는 어떤 인증 라이브러리를 쓸지 개발사가 정해야 합니다.

로그인한 뒤의 상태를 이어 가는 일은 개발자의 몫으로 남습니다. 이 일을 세션 관리라고 부르며 회원이 페이지를 옮겨 다녀도 로그인 상태가 이어지게 하는 일입니다. Next.js 공식 문서는 세션 관리를 개발자가 직접 처리해야 하는 부분으로 설명합니다.

회원이 볼 수 있는 자료인지 확인하는 일도 설계 대상입니다. Next.js 공식 문서는 이 확인을 페이지 입구 한 곳에만 두지 말고 자료를 읽어 오는 코드 가까이에서도 하라고 안내합니다. 수강 내역처럼 회원마다 다른 자료가 있는 사이트라면 자료를 읽는 곳마다 권한 확인이 들어가도록 개발해야 합니다.

기능이 늘어날 때 어느 쪽이 덜 어려운지 어떻게 판단합니까?

추가할 기능을 먼저 적고 기능마다 각 구축 방식에서 어떻게 추가되는지 개발사에 물어보면 판단할 수 있습니다. 같은 질문을 두 방식에 하면 답의 구체성이 비교 기준이 됩니다. 순서는 다음과 같습니다.

1. 앞으로 추가할 기능을 예약과 결제, 회원 순으로 적습니다. 지금 필요하지 않아도 가능성이 있는 기능까지 적어 둡니다.

2. 개발사에 기능마다 어떻게 추가하는지 묻습니다. 워드프레스라면 쓸 플러그인과 맞는 플러그인이 없을 때의 대안을 확인하고 Next.js라면 회원 기능에 쓸 인증 라이브러리와 로그인 상태 유지 방식을 확인합니다.

3. 같은 기능을 다른 구축 방식으로 만들면 무엇이 달라지는지도 묻습니다. 한 가지 방식만 권하는 개발사라면 그 이유를 듣고 사이트로 하는 일과 맞는지 비교합니다.

개발사가 기능마다 구체적인 방법을 말하지 못한다면 기능 추가를 요청할 때 범위 논의가 길어질 수 있습니다. 반대로 기능별 방법과 대안을 설명한다면 나중에 추가 요청이 생겨도 무엇을 확인해야 할지 알 수 있습니다.

예를 들어 병원이 진료 예약만 받는다면 예약 기능 하나로 충분한지가 질문의 중심입니다. 회원 전용 진료 안내까지 필요하다면 회원 범위와 권한 확인이 질문에 더해집니다. 어느 쪽이 덜 어려운지는 추가할 기능의 종류와 사이트를 수정하는 주기로 판단합니다.

사이트로 하는 일과 수정 주기는 어떻게 정리해 두면 됩니까?

사이트로 하는 일은 손님에게 보여 주는 일과 손님에게서 받는 일로 나누어 적으면 됩니다. 수정 주기는 직원이 직접 글을 수정하는 빈도와 개발자에게 기능 변경을 맡기는 빈도로 나누어 적습니다.

1. 손님에게서 받는 일: 예약 신청과 결제, 회원 가입 가운데 지금 필요한 것과 나중에 필요할 것을 구분합니다.

2. 직원이 직접 수정하는 내용: 공지와 수강 안내, 가격표 같은 글과 사진을 적습니다.

3. 개발자에게 맡길 변경: 예약 방식 변경이나 결제 수단 추가처럼 기능이 바뀌는 일을 적습니다.

Next.js는 완성한 사이트를 방문자가 볼 수 있게 인터넷에 올리는 일, 곧 배포를 여러 방식으로 할 수 있습니다. 올릴 곳을 고를 여지가 있으므로 지금 쓰는 서버나 계정이 있다면 미리 알려 주시면 개발사가 맞는 방식을 제안할 수 있습니다.

회원 정보가 필요하다면 직원이 어느 회원 정보까지 볼지도 정해 두시면 좋습니다. 권한 확인의 범위가 거기서 정해지기 때문입니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없고 아래 기준에 따라 범위가 달라지므로 상담 뒤 견적으로 안내합니다.

1. 추가할 기능의 종류: 예약만 받는지 결제와 회원까지 필요한지

2. 기능을 추가할 시점: 처음부터 만드는지 사이트를 연 뒤에 추가하는지

3. 회원마다 보는 자료가 다른지: 회원 구분과 권한 확인이 필요한 범위

4. 직원이 직접 수정하는 내용의 양: 글과 사진 수정만인지 기능 변경도 있는지

5. 운영 중인 사이트가 있는지: 새로 만드는지 지금 사이트에 기능을 더하는지

이 몇 가지를 알려 주시면 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의 뒤의 순서는 다음과 같습니다.

1. 문의를 남기시면 사이트로 하려는 일과 수정 주기를 중심으로 상담합니다.

2. 상담 내용에 맞는 구축 방식을 추천하고 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

3. 진행하시기로 하면 정해진 범위대로 사이트를 제작합니다.

4. 프로젝트를 마치면 사이트와 계정을 고객에게 넘겨드립니다.

그래서 워드프레스와 Next.js 중 무엇을 먼저 비교해 봐야 합니까?

필요한 기능이 예약이나 회원처럼 이름이 정해진 기능이고 직원이 글을 직접 수정하는 일이 많다면 워드프레스의 플러그인 방식을 먼저 비교해 볼 만합니다. 회원마다 보는 자료가 달라 권한 확인을 사이트에 맞게 설계해야 하거나 사이트를 올릴 곳을 직접 고르고 싶다면 Next.js를 먼저 비교해 볼 만합니다.

엔소프 컴퍼니는 기능을 나중에 추가할 사이트에 맞춘 웹사이트 구축과 반복 업무 자동화를 AI 에이전트로 개발해 드립니다

기능을 나중에 추가할 사이트의 구축 방식이 고민이시라면 사이트로 하는 일과 수정 주기를 먼저 들려 주시면 됩니다. 엔소프 컴퍼니는 그 내용을 듣고 워드프레스와 Next.js를 포함해 맞는 구축 방식을 추천합니다. 고객이 원하실 경우 추천한 방식으로 사이트를 개발해 드리며 기획과 디자인, 개발, 배포는 한 곳에서 진행합니다.

예약 기능을 붙인 뒤에는 접수된 수강 신청을 직원이 확인해 종류별로 나누고 예약 명단에 다시 입력하는 일이 생길 수 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 이 예약 접수 업무를 AI 에이전트가 수행하도록 개발합니다. AI 에이전트는 고객이 정한 규칙에 따라 접수와 분류를 사람 대신 맡는 프로그램이며 어디까지 맡길지는 고객이 정하시면 됩니다.

예약 접수에 AI 에이전트를 붙이면 달라지는 점은 다음과 같습니다.

1. 학원에서 쓰시던 예약 명단과 회계 프로그램은 그대로 두고 새 예약 기능과 연결되어 신청 내용을 다시 입력하는 일이 없어집니다.

2. 예약 신청과 결제 문의는 도착하는 대로 종류별로 나뉩니다.

3. 월별 수강료 정산표와 예약 현황 보고서는 정해 둔 양식에 맞춰 자동으로 작성됩니다.

세 가지를 한 번에 맡기실 필요는 없고 예약 접수 분류 하나부터 시작하셔도 됩니다. 접수를 나누고 정산표를 만들던 직원의 근무 시간과 인건비 부담이 줄어듭니다.

프로젝트를 마치면 배포된 웹사이트와 글과 사진을 수정하는 관리 화면, 사이트를 만든 코드와 계정을 넘겨드립니다. 자동화를 맡기셨다면 그 일을 수행하는 장치도 함께 받으실 수 있습니다.

사이트로 하려는 일과 얼마나 자주 수정하시는지 알려 주시면 됩니다.

프로젝트 문의하기

AI 에이전트에게 일을 맡기고 퇴근하는 저녁이 있습니다. 맡긴 일 가운데 되돌릴 수 없는 일이 섞여 있지는 않은지 마음에 걸리신 적이 있으신가요? AI 에이전트는 정해 둔 일을 사람 대신 수행하는 프로그램입니다.

AI 에이전트에게 맡길 일은 실행한 뒤 되돌릴 수 있는지와 돈, 자료, 권한에 닿는지로 구분할 수 있습니다. 영향이 큰 일에는 실행하기 전에 사람이 승인하는 단계를 둡니다.

AI 에이전트 사고는 어디서 시작됩니까?

보안 비영리 프로젝트 OWASP는 AI 에이전트 사고의 뿌리에 세 가지 가운데 하나 이상이 있다고 정리합니다. 기능이 너무 많은 것과 권한이 너무 넓은 것, 자율권이 너무 큰 것입니다. 각각의 뜻은 이렇습니다.

1. 기능이 너무 많다는 것은 AI 에이전트가 쓸 수 있는 기능이 맡긴 일보다 많다는 뜻입니다.

2. 권한이 너무 넓다는 것은 AI 에이전트에 열어 준 문서와 계정의 범위가 맡긴 일보다 넓다는 뜻입니다.

3. 자율권이 너무 크다는 것은 사람이 확인하지 않아도 AI 에이전트가 스스로 실행하는 일이 많다는 뜻입니다.

OWASP가 자율권이 지나친 대표 사례로 드는 것은 문서 삭제 기능입니다. 사용자에게 확인하지 않고 삭제를 그대로 실행하는 기능입니다. 지우는 기능이 있다는 사실보다 확인 없이 실행한다는 점이 문제로 꼽힙니다.

학원에서 수강생 상담 기록을 정리하는 일을 AI 에이전트에게 맡겼다고 가정합니다. 정리 기능에 삭제 기능까지 열려 있고 삭제 전에 확인하는 사람이 없다면 기록이 지워질 수 있습니다. 지워진 기록을 되살릴 방법이 있는지는 그때가 되어서야 알게 됩니다.

사고의 뿌리는 AI 에이전트에게 맡긴 일보다 기능과 권한과 자율권을 넓게 열어 준 데 있습니다. 맡길 일이 정해지면 열어 줄 범위도 그 일에 맞춰 정할 수 있습니다. 범위를 정하는 사람은 고객이며 AI 에이전트는 정해진 범위 안에서 일을 수행합니다.

사람 승인 없이 맡기면 안 되는 일은 어떤 일입니까?

네 종류의 일입니다. 되돌릴 수 없는 결과를 내는 일, 돈이 오가는 일, 규제 대상 자료를 만지는 일, 권한을 바꾸는 일입니다. 종류마다 예를 들면 이렇습니다.

1. 되돌릴 수 없는 결과를 내는 일: 문서 삭제처럼 실행한 뒤에는 원래대로 돌릴 수 없는 일입니다.

2. 돈이 오가는 일: 결제와 환불, 입금 처리처럼 금액이 움직이는 일입니다.

3. 규제 대상 자료를 만지는 일: 병원 진료 기록처럼 법과 규정이 다루는 방법을 정해 둔 자료를 열거나 수정하는 일입니다.

4. 권한을 바꾸는 일: 직원이나 회원이 볼 수 있는 자료의 범위를 바꾸는 일입니다.

영향이 큰 행동은 실행되기 전에 사람이 승인하도록 통제를 두라고 OWASP는 권고합니다. 되돌릴 수 없는 일과 돈이 오가는 일, 규제 대상 자료를 만지는 일, 권한을 바꾸는 일은 사람 승인을 거치게 두는 것이 기준입니다. 승인 단계가 없으면 학원 상담 기록 삭제처럼 확인 없이 실행되는 일이 생깁니다.

반대로 읽기만 하는 일과 쉽게 되돌릴 수 있는 일은 승인 없이 자동으로 돌려도 됩니다. 접수된 문의를 읽어 종류별로 나누는 일이나 매출 숫자를 읽어 보고서로 만드는 일이 그 예입니다. 잘못 만든 보고서는 지우고 다시 만들면 되기 때문입니다.

우리 회사의 업무는 어느 쪽에 속합니까?

업무 목록을 펴 놓고 네 종류에 하나라도 속하는 일에 표시하면 승인 대상이 나옵니다. 학원은 수강료 환불 처리가 돈이 오가는 일에 속하고 병원은 진료 기록 열람이 규제 대상 자료를 만지는 일에 속합니다. 시공 회사는 직원별 접근 범위 변경이 권한을 바꾸는 일에 속합니다.

쇼핑몰이 주문 내역을 바꾸지 않고 읽기만 해서 매출을 정리하는 일은 어느 종류에도 속하지 않습니다. 표시한 일과 표시하지 않은 일이 섞여 있어도 AI 에이전트를 도입할 수 있습니다. 표시하지 않은 일은 자동으로 수행하게 두고 표시한 일은 승인 단계를 거치게 두면 됩니다.

이런 대표님께 구분이 필요합니다.

1. AI 에이전트를 도입하려는데 어디까지 맡겨도 되는지 판단이 서지 않는 분

2. 이미 쓰고 있는 AI 에이전트에 사람 확인 없이 맡겨 둔 일이 무엇인지 파악하지 못한 분

3. 직원이 반복하는 일을 넘기고 싶지만 돈이나 고객 자료에 닿는 일이 섞여 있는 분

맡길 일이 읽기와 보고서 작성뿐이라면 승인 단계를 둘 이유가 적습니다. 그럴 때도 열어 줄 자료의 범위는 맡길 일에 맞춰 정해 두시면 됩니다.

도입하려면 대표님은 무엇을 정하면 됩니까?

처음에 기준을 한 번 정해 두면 그 기준대로 AI 에이전트가 움직입니다. 정하실 것은 세 가지입니다.

1. 맡길 일 하나를 정합니다. 읽기만 하는 일처럼 쉽게 되돌릴 수 있는 일이 시작하기에 알맞습니다.

2. 그 일에 열어 줄 자료와 계정의 범위를 정합니다. 맡긴 일에 필요한 만큼만 여는 것이 기준입니다.

3. 사람 승인을 거칠 일과 승인할 직원을 정합니다.

맡길 일과 열어 줄 자료와 승인을 거칠 일은 도입하기 전에 고객이 정합니다. 정한 내용을 문서로 남겨 두면 담당자가 바뀌어도 같은 기준을 이어 쓸 수 있습니다.

읽기만 하는 일은 처음부터 자동으로 수행하게 두고 네 종류에 속하는 일은 승인을 거치게 두는 방식으로 시작할 수 있습니다. 맡기는 일이 한 가지라면 확인할 범위도 좁아집니다.

도입한 뒤에는 무엇을 어디서 확인합니까?

AI 에이전트가 수행한 일의 기록과 승인 기록에서 세 가지를 확인합니다. 기록이 남는 방식으로 도입해 두면 대표님이 직접 보실 수 있습니다.

1. 승인 대상으로 정한 일이 실제로 승인을 거쳤는지 승인 기록에서 봅니다.

2. 열어 준 자료와 계정의 범위가 맡긴 일에 필요한 만큼인지 AI 에이전트가 접근한 자료의 기록에서 봅니다.

3. 승인 없이 자동으로 도는 일이 읽기와 쉽게 되돌릴 수 있는 일뿐인지 수행 기록에서 봅니다.

기능을 추가하거나 새 일을 맡길 때는 열어 준 범위가 바뀔 수 있습니다. 그때는 새 일이 네 종류에 속하는지 다시 확인하고 속한다면 승인 대상 목록에 올립니다. 도입한 뒤에도 승인 기록과 열어 준 범위를 확인하는 일은 이어집니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없고 다음 다섯 가지에 따라 범위가 달라지므로 상담 뒤 견적으로 안내합니다.

1. 맡길 반복 업무가 몇 가지인지

2. 쓰시는 프로그램이 몇 종류이고 서로 연결해야 하는지

3. 사람 승인을 거칠 일이 업무에 얼마나 섞여 있는지

4. 담당 직원이 결과를 확인하는 관리자 화면과 입력 폼이 필요한지

5. 실제 데이터로 확인할 자료가 정리되어 있는지

다섯 가지를 알려 주시면 개발 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의에서 계정 인계까지 다섯 단계로 진행합니다.

1. 문의를 남기시면 맡기고 싶은 반복 업무를 중심으로 상담합니다.

2. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

3. 진행하시기로 하면 대상 업무와 처리 규칙을 확정하고 프로그램을 연결해 자동화를 제작합니다.

4. 실제 데이터로 동작을 확인합니다.

5. 프로젝트를 마치면 동작하는 자동화 시스템과 계정을 고객에게 넘겨드립니다.

그래서 AI 에이전트 도입 전에 맡길 일부터 구분해야 합니까?

맡길 일 가운데 돈이나 규제 대상 자료에 닿는 일이 섞여 있다면 도입 전에 구분해 둘 만합니다. 승인할 직원이 정해지지 않은 일은 실행 전 승인 단계가 비어 있는 상태입니다. 그런 일이 있다면 승인할 직원을 정하는 일을 먼저 하실 수 있습니다. 맡길 일이 읽기와 보고서 작성뿐이라면 구분에 드는 시간은 짧게 끝납니다.

엔소프 컴퍼니는 AI 에이전트에게 맡길 일과 사람이 승인할 일을 구분한 업무 자동화를 AI 에이전트로 개발해 드립니다

AI 에이전트에게 맡기면 사고가 날 수 있는 일을 미리 구분하기 어려우시다면 반복 업무를 하나씩 놓고 살펴보는 데서 시작할 수 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 맡기기로 정한 반복 업무를 수행하는 AI 에이전트를 개발해 드립니다. 승인을 거칠 일과 자동으로 수행할 일은 고객이 고르시면 됩니다.

승인이 필요한 일이 어느 것인지 아직 가려지지 않았다면 AX 진단(업무 자동화 전환 진단)에서 시작하는 방식도 있습니다. 엔소프 컴퍼니가 업무 과정을 따라가며 반복되는 구간을 찾고 자동화 가능 항목과 불가 항목, 비권장 항목을 구분해 보고서에 담습니다. 진단으로 시작하실지 개발로 시작하실지는 고객이 고르시면 됩니다.

개발은 업무 확정과 처리 규칙 정의에서 시작해 프로그램 연결과 실제 데이터로 하는 확인까지 엔소프 컴퍼니 한 곳에서 진행합니다. 완성된 모습은 이렇습니다.

1. 쓰시던 프로그램은 그대로 두고 연결되어 접수한 내용을 다시 입력하는 일이 사라집니다.

2. 매달 만들던 정산과 보고서가 정해 둔 형식으로 자동 생성됩니다.

3. 접수된 건이 읽기만 하는 일과 승인이 필요한 일로 나뉘어 담당 직원에게 전달됩니다.

4. 사람 승인을 거칠 일은 담당 직원이 결과를 확인하는 관리자 화면과 입력 폼을 필요하시면 함께 개발합니다.

네 가지를 한 번에 하실 필요는 없고 하나부터 시작하는 방식도 가능합니다. 접수 건을 하나씩 확인하며 분류하던 직원의 시간과 인건비 부담이 줄어듭니다.

프로젝트를 마치면 동작하는 자동화 시스템과 운영 절차 문서, 계정을 고객에게 넘겨드립니다.

지금 직원이 반복하는 일 가운데 돈이나 고객 자료에 닿는 일이 있다면 그 업무 하나를 알려 주시면 됩니다.

프로젝트 문의하기

견적서에 화면과 기능은 줄마다 이름이 있는데 손님 정보를 저장하는 방식에 관한 줄은 없거나 무슨 뜻인지 알기 어려울 수 있습니다. 쓰시던 엑셀 손님 명단을 사이트로 옮기는 일이라면 파일을 올리면 끝날 것 같습니다. 그런데 눈에 보이지도 않는 부분에 왜 비용이 붙는지 궁금하실 수 있습니다.

데이터 구조는 손님 정보를 어떤 칸으로 나누고 칸끼리 어떻게 연결할지 미리 정해 둔 설계입니다. 업체에 따라 견적서에는 데이터 구조 설계나 데이터 모델이라는 이름으로 적습니다. 완성된 사이트에서는 직접 보이지 않지만 손님 정보가 어떤 규칙으로 쌓이는지가 데이터 구조에서 정해집니다.

엑셀 명단을 그대로 사이트에 옮기면 어떤 일이 생깁니까?

옮긴 직후에는 아무 문제가 보이지 않습니다. 엑셀에 있던 이름과 연락처, 시공 내역이 사이트 화면에 그대로 나오기 때문입니다. 문제는 사이트를 쓰기 시작하고 같은 손님이 다시 찾아올 때 나타납니다.

지난해 욕실을 시공한 손님이 올해 사이트의 문의 폼으로 주방 시공을 문의합니다. 사이트가 이미 명단에 있는 손님을 알아보지 못하면 새 손님으로 한 줄을 더 만듭니다. 그러면 같은 손님이 명단에 두 줄로 남고 시공 내역도 줄마다 따로 쌓입니다.

연락처가 바뀌었을 때도 같은 일이 생길 수 있습니다. 손님이 새 번호를 알려 주면 영업 담당 직원은 사이트의 한 곳을 수정하지만 현장 담당 직원이 보는 다른 곳에는 예전 번호가 남을 수 있습니다. 그 결과 영업 담당은 새 번호로 연락하고 현장 담당은 예전 번호로 전화해 연결되지 않습니다.

학원과 병원에서도 같은 장면이 나옵니다. 학부모가 자녀를 여러 명 등록하면 학부모 정보를 여러 번 적게 되고 환자가 가족과 함께 예약하면 연락처가 여러 줄에 나뉘어 적힙니다. 사이트를 연 뒤에 알게 되면 이미 쌓인 자료를 합치는 작업이 따로 생깁니다.

엑셀에서는 괜찮던 명단이 사이트에서는 왜 문제가 됩니까?

엑셀에는 줄을 서로 구별하는 규칙이 없어서 직원의 눈이 그 역할을 해 왔기 때문입니다. 직원은 이름과 연락처를 보고 같은 손님인지 판단해 새 줄을 만들지 기존 줄을 수정할지 정했습니다. 그 판단은 직원의 습관으로 이어져 왔을 뿐 파일 안에는 적혀 있지 않습니다.

데이터베이스는 정보를 정해진 칸과 규칙으로 보관하는 저장 공간입니다. 데이터베이스에서는 각 줄을 서로 구별하는 고유한 값을 붙이는데 이 값을 기본키라고 부릅니다. 엑셀에는 이런 제약이 없어서 같은 손님이 두 줄이 되어도 파일에 그대로 저장됩니다.

사이트에서는 손님이 직접 정보를 입력하고 여러 직원이 같은 정보를 동시에 봅니다. 직원이 눈으로 확인하던 단계가 사라지므로 같은 손님인지 구별하는 규칙을 사이트에 미리 넣어 두어야 합니다. 그 구별 규칙을 적은 설계가 데이터 구조입니다.

데이터 구조는 정보를 어떤 칸에 어떻게 나누어 둘지 정한 설계일 뿐 손님 정보 자체를 담고 있지는 않습니다. 데이터 구조는 손님 정보가 아니라 정보를 넣을 칸과 규칙이어서 완성된 화면에서는 눈에 띄지 않습니다. 그래서 견적서에서도 결과물이 눈에 보이지 않는 항목으로 남습니다.

화면과 기능은 칸과 규칙 위에 만들어집니다. 그래서 개발사는 화면을 그리기 전에 칸부터 설계해야 하고 그 설계 시간에 비용이 붙습니다. 칸이 정해지지 않은 채 화면부터 만들면 칸이 바뀔 때마다 이미 만든 화면과 기능을 수정해야 합니다.

엑셀 명단은 사이트로 옮기기 전에 어떤 순서로 점검합니까?

엑셀 파일을 열어 열 이름을 하나씩 읽는 일부터 시작합니다. 열마다 무슨 정보를 담고 업무에서 누가 쓰는지 적어 두면 개발사와 이야기할 재료가 됩니다. 순서는 다음과 같습니다.

1. 열마다 담긴 정보를 적고 사이트에서도 필요한지 표시합니다.

2. 한 손님에게 여러 건이 붙는 열을 찾아 따로 표시합니다. 시공 내역이나 예약 기록이 그런 열입니다.

3. 손님 한 사람을 구별하는 기준을 정합니다.

4. 같은 정보가 여러 파일에 적혀 있는지 확인하고 원본으로 삼을 한 곳을 정합니다.

한 손님에게 여러 건이 붙는 열은 손님 칸과 시공 칸으로 나누고 시공 칸에 손님 번호를 적어 연결하는 방식으로 설계합니다. 이렇게 나누면 손님 정보는 한 곳에만 있고 시공은 몇 건이든 같은 손님에게 붙습니다.

구별 기준을 이름으로 정하면 이름이 같은 다른 사람이 한 손님으로 합쳐질 수 있습니다. 연락처로 정하면 번호가 바뀐 손님이 새 손님으로 등록됩니다. 그래서 이름이나 연락처와 별개로 손님마다 고유한 번호를 붙이는 방식을 쓰기도 합니다.

같은 정보가 여러 파일에 적혀 있다면 어느 파일이 최신인지부터 확인합니다. 스프레드시트에서는 한 곳에만 있어야 할 같은 데이터가 여러 곳에 입력되는 문제가 생깁니다. 영업 파일과 현장 파일처럼 파일이 나뉘어 있다면 연락처를 서로 비교해 보시면 됩니다.

이 점검에는 개발 지식이 필요하지 않습니다. 열마다 업무에서 쓰는지 판단할 수 있는 사람은 개발자가 아니라 명단을 매일 쓰는 직원이기 때문입니다. 점검한 내용을 개발사에 전달하면 개발사가 그 설명을 데이터 구조로 바꿉니다.

손님 정보를 누가 보고 수정하는지는 견적을 받기 전에 정해 두어야 합니까?

직원별로 볼 수 있는 손님 정보의 범위를 먼저 정해 두시면 개발사가 같은 조건으로 견적 범위를 잡을 수 있습니다. 예를 들어 영업 담당은 연락처와 거래 내역을 보고 현장 담당은 주소와 시공 일정만 보도록 나눌 수 있습니다. 보는 범위가 나뉠수록 칸마다 누가 볼 수 있는지 적는 설계가 늘어납니다.

손님이 탈퇴하거나 거래가 끝났을 때 기록을 어떻게 다룰지도 미리 정할 항목입니다. 정보를 지우면 지난 시공 내역과 정산 기록이 함께 사라지고 남기면 개인정보를 어디까지 보관할지가 문제가 됩니다. 업종과 내부 방침에서 나오는 결정이므로 고객의 업무를 기준으로 정하시면 됩니다.

엑셀에 쌓인 과거 자료를 어디까지 사이트로 옮길지도 정할 항목입니다. 옮길 범위가 넓어질수록 칸이 맞지 않는 오래된 자료를 하나씩 맞추는 작업이 늘어납니다. 최근 거래만 옮기고 나머지는 엑셀 파일로 보관하는 방식도 선택할 수 있습니다.

쓰고 있는 다른 프로그램과 오가는 정보가 있는지도 확인합니다. 회계 프로그램이나 예약 프로그램에서 손님 이름을 가져다 쓴다면 사이트의 칸과 그 프로그램의 칸이 서로 맞아야 합니다. 업무 규칙을 말로만 전달하면 개발사마다 해석이 달라질 수 있고 그러면 견적도 서로 다른 범위를 전제로 나올 수 있습니다.

받은 견적서에서 데이터 구조 설계 항목은 어떻게 확인합니까?

데이터 구조 설계나 데이터 모델이라는 줄이 있는지부터 보시고 있다면 그 줄이 어디까지를 포함하는지 물어보시면 됩니다. 줄 이름은 업체마다 다를 수 있으므로 이름보다 하는 일을 기준으로 확인하는 편이 정확합니다.

줄이 보이지 않는다고 설계가 없다는 뜻은 아닙니다. 기능 개발 같은 다른 줄에 포함되어 있을 수 있기 때문입니다. 포함되어 있다면 그 안에서 설계가 어디까지인지 개발사에 확인하시면 됩니다.

개발사에 물어볼 내용은 다음과 같습니다.

1. 데이터 구조 설계의 결과물이 문서로 남는지 묻습니다.

2. 문서에 칸의 이름과 칸 사이의 연결이 적히는지 묻습니다.

3. 기존 엑셀 자료를 옮기는 일이 범위에 들어 있는지 묻습니다.

4. 다른 개발사에 문서를 넘겨도 읽을 수 있는지 묻습니다.

문서가 남지 않으면 설계 내용이 개발자 한 사람의 기억에만 있게 됩니다. 담당자나 개발사가 바뀔 때 설계를 처음부터 다시 파악해야 합니다. 문서가 있으면 회원 기능이나 예약 기능을 추가할 때도 같은 칸 위에서 이어 만들 수 있습니다.

견적서에서는 데이터 구조 설계 항목이 있는지와 함께 결과물이 문서로 남는지를 물어보시면 됩니다. 엑셀 자료를 옮기는 일이 범위 밖이라면 그 작업을 누가 맡는지 개발사에 물어 두시면 됩니다. 그러면 추가 비용이 생기는 지점을 미리 알 수 있습니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없고 아래 기준에 따라 범위가 달라지기 때문에 상담 뒤 견적으로 안내합니다.

1. 옮길 엑셀 파일이 하나인지 여러 개인지

2. 같은 손님 정보가 여러 파일에 중복되어 있는지

3. 한 손님에게 붙는 정보의 종류: 시공 내역, 예약, 결제 등

4. 손님 정보를 보는 사람이 한 부서인지 여러 부서와 손님 본인까지인지

5. 과거 자료를 어디까지 옮기는지

엑셀 파일과 사용하는 부서만 알려 주셔도 상담에서 나머지 기준을 확인하며 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

견적을 받아 보고 진행 여부를 정하는 순서가 중간에 있습니다.

1. 고객이 문의를 남깁니다.

2. 엑셀 파일과 사용하는 부서, 사이트로 하려는 일을 중심으로 상담합니다.

3. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

4. 진행하시기로 하면 데이터 구조를 설계한 뒤 사이트를 제작합니다.

5. 프로젝트 종료 후에 만든 사이트와 계정을 고객에게 넘겨드립니다.

그래서 엑셀 명단을 옮기기 전에 데이터 구조 설계를 따로 확인해야 합니까?

손님이 사이트에서 직접 정보를 입력하거나 직원이 사이트에서 정보를 수정한다면 데이터 구조는 별도로 확인할 항목입니다. 여러 업체의 견적을 놓고 비교 중이라면 업체마다 데이터 구조 설계를 범위에 넣었는지 먼저 맞춰 보시면 금액 차이의 원인을 확인할 수 있습니다. 반대로 사이트에서 명단을 읽기만 한다면 설계 범위는 작아질 수 있습니다.

엔소프 컴퍼니는 엑셀 손님 명단을 사이트로 옮기는 일에 맞춘 데이터 구조 설계와 반복 입력 자동화를 AI 에이전트로 개발해 드립니다

엑셀 손님 명단을 옮길 때 눈에 보이지 않는 데이터 구조에 비용이 붙는 일이 걱정되신다면 기획·설계 단계부터 시작하는 방법이 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 서비스 정책과 요구사항, 화면, 데이터 구조를 한 곳에서 이어서 설계해 드립니다. 직원별로 볼 수 있는 범위 같은 권한과 예외 규칙도 정책으로 함께 다룹니다.

프로젝트를 마치면 요구사항 정의서와 화면 설계서, 데이터 구조 정의서를 넘겨드립니다. 데이터 구조 정의서는 칸의 이름과 칸 사이의 연결을 적은 문서이며 개발사에 그대로 전달할 수 있는 형태입니다.

사이트를 연 뒤에는 손님이 남긴 문의와 신청을 직원이 엑셀 명단에 다시 옮겨 적는 일이 남을 수 있습니다. 고객이 원하시면 이 반복 업무를 AI 에이전트가 수행하도록 업무 자동화로 개발해 드립니다. AI 에이전트는 정해 둔 기준대로 반복 업무를 사람 대신 수행하는 프로그램이며 맡길 범위는 고객이 정하시면 됩니다.

쓰시던 프로그램은 그대로 두고 사이만 잇기 때문에 같은 내용을 두 번 옮겨 적는 일이 없어집니다. 신청과 접수는 들어오는 대로 종류별로 나뉘고 매달 손으로 만들던 정산과 보고서는 자동으로 만들어집니다. 한 번에 다 하실 필요는 없고 설계만 또는 옮겨 적는 일 하나만 시작하셔도 됩니다.

옮겨 적고 분류하고 보고서를 만들던 직원의 시간과 인건비 부담이 줄어듭니다. 자동화를 맡기셨다면 프로젝트를 마칠 때 동작하는 자동화 시스템과 운영 절차 문서, 계정을 넘겨드립니다.

지금 쓰시는 엑셀 명단에 어떤 열이 있는지와 그 명단을 사이트로 옮기려는 이유를 알려 주시면 됩니다.

프로젝트 문의하기

개발사가 「Next.js로 하시죠」라고 권하는 동안 고객은 프로젝트 종료 후에 무엇이 자기 것으로 남는지 알기 어렵습니다. Next.js(넥스트제이에스)는 Vercel(버셀)이 만든 웹사이트 개발 도구 묶음이며 원본을 공개해 누구나 쓸 수 있게 한 오픈소스입니다. 사용 조건을 적은 라이선스는 MIT입니다.

Next.js의 사용 조건이 공개되어 있어도 개발사가 그 위에 새로 만든 사이트의 권리는 계약에서 따로 정해집니다. 사이트는 멀쩡히 열리는데 문구 하나를 바꾸려면 개발사에 연락해야 할 수 있습니다. 다른 개발사에 맡기려 해도 고객에게 넘겨줄 자료가 없는 상태가 될 수 있습니다.

프로젝트 종료 후에 내 사이트를 내가 열 수 없는 일이 생깁니까?

원본 파일과 계정이 개발사에만 있으면 사이트가 정상으로 열려도 고객은 그 사이트를 직접 움직일 수 없습니다. 개발자가 사이트의 동작을 적어 둔 원본 파일을 이 글에서는 코드라고 부르며 계정은 사이트가 올라가 있는 서비스에 들어갈 수 있는 이름과 비밀번호입니다.

수강 안내 문구와 시간표를 자주 바꿔야 하는 학원을 예로 들어 보겠습니다. 수정 요청을 개발사에 맡기면 됩니다. 하지만 담당 개발자와 연락이 어려워지거나 요청마다 조건이 붙으면 학원의 일정이 늦어질 수 있습니다.

다른 개발사로 옮기려 할 때도 같은 문제가 생깁니다. 새 개발사가 코드를 받지 못하면 사이트를 처음부터 다시 만들어야 할 수 있습니다. 사이트가 올라간 계정에 고객이 들어갈 수 없으면 새 개발사가 작업할 방법도 없습니다.

사이트의 인터넷 주소인 도메인과 사이트 파일을 보관하는 서버의 이용 계약이 개발사 이름으로 되어 있는 경우도 있습니다. 서버는 사이트 파일을 보관하고 방문자에게 보여 주는 컴퓨터입니다. 이 두 가지가 개발사 이름이면 프로젝트 종료 후에도 사이트의 열쇠를 개발사가 쥐고 있게 됩니다.

개발사가 만든 코드는 왜 자동으로 고객 것이 되지 않습니까?

세계지적재산권기구(WIPO)는 소프트웨어 개발 계약의 지식재산권 귀속을 설명합니다. 계약에 클라이언트에게 넘긴다는 정함이 없으면 개발자가 소유권을 자동으로 보유합니다. 지식재산권은 만든 사람이 결과물에 갖는 권리입니다. 그래서 권리를 넘긴다는 문구가 계약서에 있는지가 기준이 됩니다.

사이트를 올리는 방식도 계정과 함께 정해야 할 일입니다. 배포는 완성한 사이트를 방문자가 볼 수 있게 인터넷에 올리는 일이고 Next.js 공식 문서는 배포 방식을 네 가지로 제시합니다. 네 가지는 Node.js 서버와 Docker 컨테이너, 정적 내보내기, 각 플랫폼용 어댑터입니다.

Node.js 서버는 자바스크립트로 만든 사이트를 돌리는 서버입니다. Docker 컨테이너는 사이트 실행 환경을 하나로 포장한 꾸러미입니다. 정적 내보내기는 미리 완성한 화면 파일을 올리는 방식이며 어댑터는 특정 업체의 서비스에 맞추는 연결 부품입니다. 정적 내보내기는 기능이 제한된다고 공식 문서가 밝히므로 개발사가 어느 방식으로 올릴지는 계약 전에 물어볼 질문이 됩니다.

배포 방식마다 사이트가 올라가는 곳이 달라질 수 있어서 고객이 받을 계정의 종류도 달라집니다. 배포 권한은 사이트의 수정본을 인터넷에 올릴 수 있는 권한입니다. 이 권한이 누구 계정에 있는지에 따라 프로젝트 종료 후 사이트를 고객이 직접 수정할 수 있는지가 정해집니다.

코드의 권리는 개발사가 쓰는 도구의 이름이 아니라 계약서 문구로 정해집니다. Next.js가 공개된 도구여도 개발사가 새로 작성한 코드를 누가 갖는지는 정해지지 않습니다.

계약 전에 개발사에 무엇을 물어봐야 합니까?

계약 전에 물을 질문은 코드 권리와 계정 명의, 인계 자료 세 가지입니다. 질문은 같은 꼴로 한 줄씩 적어 개발사에 보내면 됩니다.

1. 개발사가 새로 작성한 코드의 권리를 고객에게 넘기는지 묻는 일입니다. 넘기는 시점이 대금을 치르는 시점인지도 묻습니다.

2. 사이트가 올라가는 계정과 도메인을 누구 명의로 만드는지 묻는 일입니다. 배포 권한이 고객 계정에 있는지도 확인합니다.

3. 프로젝트 종료 후에 인계 자료로 무엇을 어떤 방법으로 받는지 묻는 일입니다.

코드 권리 질문에서는 답의 표현을 구분해 들어야 합니다. 권리를 넘긴다는 답과 코드를 쓸 수 있게 해 준다는 답은 서로 다른 답이며 코드를 쓸 수 있게 해 준다는 답에는 수정과 이전에 제한이 따를 수 있습니다.

계정 명의 질문은 계정을 만드는 순서에서 차이가 납니다. 고객 이름으로 계정을 먼저 만들고 개발사를 초대하는 방식이 있고 개발사 계정에 사이트를 올린 뒤 나중에 옮겨 주는 방식도 있습니다. 어느 쪽인지 알아야 프로젝트 종료 후 고객이 받는 것이 계정 자체인지 계정 안의 사이트 파일뿐인지 알 수 있습니다.

인계 자료 질문의 답은 목록과 날짜로 받아야 비교할 수 있습니다. 코드와 계정 정보, 배포 방법을 적은 문서 가운데 무엇을 언제 받는지를 개발사가 직접 적어 줍니다. 그러면 견적서끼리 같은 기준으로 비교할 수 있습니다.

개발사의 답변은 어떤 문구로 계약서에 남깁니까?

말로 받은 답변은 프로젝트 종료 후에 기준으로 삼기 어려우므로 질문마다 한 문장씩 계약서에 적어 둡니다. 문장은 짧아도 됩니다.

1. 코드: 개발사가 새로 작성한 코드의 권리를 고객에게 넘긴다는 문장과 넘기는 시점
2. 계정: 사이트가 올라가는 계정과 도메인의 명의가 고객이라는 문장
3. 인계: 인계할 자료의 목록과 인계 날짜

Next.js 자체는 이미 공개된 도구이므로 코드 문구는 개발사가 새로 작성한 부분을 대상으로 적는 것이 자연스럽습니다. 개발사에 어디까지가 새로 작성한 코드인지 물어 두면 문구의 범위가 분명해집니다.

개발사가 문구를 거절하면 이유를 물어보시면 됩니다. 이유가 권리의 범위에 있는지 계정 구조에 있는지에 따라 조정할 수 있는 부분이 달라집니다.

질문마다 답변을 한 문장씩 계약서에 적어 두면 프로젝트 종료 후에 기준으로 쓸 문구가 남습니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없으며 아래 기준에 따라 범위가 달라지므로 상담 후 견적으로 안내합니다.

1. 사이트로 하는 일: 회사 소개인지 예약이나 주문을 받는지
2. 업데이트 주기: 글과 사진을 얼마나 자주 수정하는지
3. 관리 화면: 고객이 직접 수정할 화면이 필요한지
4. 기존 사이트: 새로 만드는지 지금 사이트를 옮기는지
5. 인계 범위: 코드와 계정 외에 받고 싶은 자료가 있는지

이 몇 가지를 알려 주시면 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의 후 진행 순서는 다음과 같습니다.

1. 문의를 남기시면 사이트로 하는 일과 수정 주기를 중심으로 상담합니다.

2. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보고 진행할지는 고객이 정하시면 됩니다.

3. 진행하시기로 하면 사이트를 제작합니다.

4. 제작이 끝나면 사이트를 인터넷에 올립니다.

5. 프로젝트를 마치면 사이트를 만든 코드와 계정을 고객에게 인계합니다.

그래서 개발사의 Next.js 제안은 받아들여도 됩니까?

세 가지 질문에 문서로 답이 나오는 개발사라면 Next.js든 다른 방식이든 같은 기준으로 견적을 비교할 수 있습니다. 답이 말로만 오가거나 코드의 권리를 넘기지 않는다는 답이 오면 따져 볼 일이 생깁니다. 프로젝트 종료 후 수정을 그 개발사에 계속 의뢰해야 하는지입니다.

글과 사진을 자주 수정하는 사이트라면 개발사를 거치지 않고 올릴 수 있는 배포 권한이 고객 몫인지가 기준입니다.

엔소프 컴퍼니는 Next.js 사이트의 코드와 계정 인계에 맞춘 웹사이트 구축과 반복 업무 자동화를 AI 에이전트로 개발해 드립니다

Next.js로 하자는 제안을 받고 프로젝트 종료 후 코드가 누구 것인지 모르겠다면 정리할 것이 두 가지 있습니다. 사이트로 하는 일과 업데이트 주기입니다. 고객이 원하실 경우 엔소프 컴퍼니는 그 내용을 듣고 Next.js를 포함해 맞는 구축 방식을 추천합니다. 정하신 방식으로 사이트도 개발해 드립니다. 구축 방식은 사이트를 만드는 방식의 종류입니다. 기획과 디자인, 개발, 배포까지 한 곳에서 진행하므로 업체를 따로 조율하는 일이 줄어듭니다.

사이트를 연 뒤에는 홈페이지로 들어온 문의와 신청을 직원이 분류하는 일이 이어질 수 있고 같은 내용을 기록 문서에 다시 옮겨 적는 일도 생깁니다. 고객이 원하시면 이 일을 AI 에이전트가 수행하도록 개발해 드립니다. AI 에이전트는 고객이 정한 기준대로 문의 분류와 기록 옮기기를 수행하는 프로그램입니다.

쓰시던 프로그램은 그대로 두고 연결하므로 같은 내용을 두 번 옮겨 적는 일이 사라집니다. 문의와 신청은 들어오는 대로 종류별로 나뉘고 매달 직접 만들던 보고서는 자동으로 만들어집니다. 사이트 구축과 자동화를 한 번에 맡기실 필요는 없고 한쪽부터 시작하셔도 됩니다. 옮겨 적고 분류하던 직원의 시간과 인건비 부담이 줄어듭니다.

프로젝트를 마치면 배포된 웹사이트와 글과 사진을 수정하는 관리 화면, 사이트를 만든 코드와 계정을 넘겨드립니다. 문의 분류를 AI 에이전트에 맡기셨다면 그 일을 수행하는 장치도 함께 받으실 수 있습니다.

Next.js를 권유받은 사이트가 어떤 일을 하는지와 한 달에 몇 번쯤 수정하는지 알려 주시면 됩니다.

프로젝트 문의하기

저녁 업무를 마치고 나서야 견적서를 확인하시는 날이 있으실 것입니다. AI 에이전트 견적을 비교할 때 가장 먼저 눈에 들어오는 숫자는 매달 내는 구독료일 수 있습니다. 그런데 비용 항목 한 줄이 무엇 때문에 생기는지 모르면 그 금액이 적절한지 판단하기 어렵습니다.

AI 에이전트는 고객이 정해 둔 일을 사람 대신 수행하는 프로그램이고 서버는 그 프로그램을 쉬지 않고 켜 두는 컴퓨터입니다. 구독료는 AI 에이전트 비용의 일부이고 AI 사용량과 서버 비용, 관리하는 사람의 노력이 더해져 비용 전체가 됩니다. 이 글은 그 구성을 이해하고 도입 여부를 판단하는 순서로 읽으시면 됩니다.

구독료 밖에서 AI 에이전트 비용은 무엇으로 생깁니까?

구독료 밖에서는 사용량 비용과 서버 비용, 관리하는 사람의 노력이 따로 생깁니다. 견적서의 비용 항목 한 줄이 어디에 속하는지 알면 개발사에 무엇을 물어볼지 분명해집니다.

1. 사용량 비용은 AI가 글을 처리한 양에 붙는 요금입니다. AI는 글을 토큰이라는 작은 조각으로 나누어 처리하며 토큰이 사용량을 측정하는 기본 단위입니다. 요금은 AI에 넣는 글과 AI가 내놓는 글 양쪽에 매겨집니다.

2. 서버 비용은 AI 에이전트를 돌리는 컴퓨터 자원에 드는 비용입니다. AI 사용료와 따로 생기는 항목입니다.

3. 관리하는 사람의 노력은 AI 에이전트를 실제 업무에 쓰는 동안 유지하고 결과를 확인하는 직원의 시간입니다. 청구서에 금액으로 나오지 않아도 비용 전체에는 들어갑니다.

대학 연구소인 스탠퍼드 디지털 경제 연구소가 소개한 연구가 있습니다. 연구는 AI 에이전트의 높은 비용이 AI가 내놓는 글보다 AI에 넣는 글에서 나온다고 밝혔습니다. 연구 조건 안에서 확인된 결과이며 실제 서비스 전부가 이 방식은 아닙니다. 맡길 업무에서 AI에게 읽힐 자료가 많다면 자료의 양을 개발사에 물어보시면 됩니다.

AI 사용료와 서버 비용이 견적서에 따로 적히는지는 개발사마다 다를 수 있습니다. 항목 한 줄이 사용량과 서버, 관리하는 사람의 노력 가운데 어디에 속하는지 물어보시면 비용이 생기는 이유를 알 수 있습니다.

청구액을 미리 예측하기 어렵다면 어떤 회사에 AI 에이전트가 맞습니까?

스탠퍼드 디지털 경제 연구소 연구에서는 같은 AI 에이전트가 같은 작업을 할 때도 비용이 크게 달라졌습니다. 연구는 청구액을 미리 예측하기 어렵다고 설명합니다. 실제 서비스 전부가 이 방식은 아니므로 도입을 검토하는 서비스의 청구 방식은 따로 확인할 필요가 있습니다.

다음 조건에 맞으면 AI 에이전트 도입을 알아볼 만합니다.

1. 같은 내용을 두 곳에 옮겨 적거나 접수를 손으로 분류하는 반복 업무가 있는 회사

2. 업무 한 가지로 시작해 청구액을 직접 확인해 볼 수 있는 회사

3. 도입한 뒤 결과를 확인할 담당 직원을 정할 수 있는 회사

학원이라면 수강 신청을 종류별로 나누는 일이, 시공 회사라면 상담 문의를 정리하는 일이 첫 후보가 됩니다. 병원이나 제조 회사에서는 매달 손으로 만드는 보고서가 맡길 만한 일일 수 있습니다.

매달 청구액이 같아야 예산을 세울 수 있는 회사라면 AI 사용료가 사용량에 따라 달라지는 구성인지 도입 전에 질문하시면 됩니다. 맡길 일이 아직 정해지지 않았다면 AI 에이전트를 고르기 전에 맡길 업무를 먼저 정하는 일이 앞섭니다.

도입할 때 고객이 처음에 정하는 일은 무엇입니까?

버튼 하나로 알아서 움직이게 하려면 그 전에 고객이 기준을 한 번 정하는 일이 필요합니다. 기준이 정해지면 개발사는 그 기준대로 AI 에이전트를 개발합니다. 정할 일은 세 가지이며 기술 지식이 없어도 답하실 수 있습니다.

1. 맡길 반복 업무 한 가지를 정합니다. 업무가 한 가지이면 청구액이 달라졌을 때 이유를 확인하기 쉽습니다.

2. AI 에이전트에게 읽힐 자료와 처리 기준을 고객이 정합니다. 읽힐 자료의 양이 사용량 비용으로 이어질 수 있기 때문입니다.

3. 결과를 처리하기 전에 직접 보고 승인할지 정합니다. 확인하는 방식에 따라 관리하는 사람의 노력이 달라집니다.

버튼 하나로 움직이는 AI 에이전트도 처음에 고객이 맡길 일과 처리 기준을 한 번 정하는 일에서 시작합니다. 기준이 한 번 정해지면 같은 설명을 처음부터 다시 하실 일이 줄어듭니다.

개발사에는 정하신 내용을 문서로 남겨 달라고 요청하실 수 있습니다. 문서에 적힌 범위를 보면 견적 항목이 어떤 일 때문에 생기는지 맞춰 보실 수 있습니다.

도입한 뒤에는 AI 에이전트 비용을 어떻게 확인합니까?

한 달 청구서를 맡긴 업무 한 가지 단위로 나누어 보면 청구액이 달라진 이유를 확인하기 쉬워집니다. 총액 한 줄만 보면 무엇 때문에 달라졌는지 알기 어렵습니다. 업무 단위로 나누면 사용량과 서버 비용, 관리하는 사람의 시간을 각각 대조할 수 있습니다.

1. 사용량 비용은 맡긴 업무의 처리 건수와 청구된 AI 사용료를 나란히 놓고 봅니다.

2. 서버 비용은 AI 사용료와 따로 청구되는지 청구서에서 항목이 구분되는지 봅니다.

3. 관리하는 사람의 노력은 담당 직원이 결과를 확인하는 데 쓴 시간을 기록하고 반복 업무에 쓰던 시간과 비교합니다.

같은 업무인데 청구액이 크게 달라졌다면 AI에게 읽힌 자료의 양이 늘었는지부터 확인합니다. 자료와 처리 기준을 바꾼 날짜를 함께 적어 두면 변화와 청구액을 맞춰 볼 수 있습니다.

확인한 결과 부담이 크게 느껴지면 맡긴 업무의 범위나 결과를 확인하는 방식을 조정할 수 있습니다. 어느 쪽을 조정할지는 고객이 정하시면 됩니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없고 아래 다섯 가지에 따라 범위가 달라집니다.

1. 맡길 업무: 반복 업무가 몇 가지이고 어떤 일인지

2. 연결할 프로그램: 쓰시는 프로그램이 무엇이고 몇 개인지

3. 읽힐 자료: 자료가 어디에 있고 이미 정리되어 있는지

4. 승인 방식: 결과를 처리하기 전에 직접 보고 승인할지

5. 화면: 관리자 화면이나 입력 폼을 새로 만들어야 하는지

맡길 업무와 연결할 프로그램, 자료, 승인 방식, 화면 유무를 알려 주시면 범위를 잡을 수 있습니다. AI 사용료가 매달 따로 생기는 구성인지는 상담에서 설명합니다.

문의하면 어떤 순서로 진행됩니까?

1. 문의를 남기시면 맡기려는 반복 업무를 중심으로 상담합니다.

2. 상담 내용에 맞춰 범위와 견적을 안내합니다.

3. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

4. 진행하시기로 하면 AI 에이전트를 제작합니다.

5. 프로젝트를 마치면 장치와 계정을 고객에게 넘겨드립니다.

그래서 구독료 비교만으로 AI 에이전트를 정해도 됩니까?

구독료 비교로 넘어가기 전에 확인할 두 가지가 있습니다. 사용료가 처리 건수나 자료의 양에 따라 달라지는 구성인지와 도입한 뒤 결과를 관리할 담당자가 정해졌는지입니다.

엔소프 컴퍼니는 구독료 밖의 AI 에이전트 비용까지 고려한 업무 자동화를 AI 에이전트로 개발해 드립니다

AI 에이전트 비용을 구독료만 보고 정하기 어려우시다면 맡길 반복 업무 한 가지를 먼저 정하는 방법이 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 그 업무를 수행하는 AI 에이전트를 개발해 드립니다. 구독료 밖의 비용을 따져 보신 뒤 어느 업무까지 맡길지는 고객이 고르시면 됩니다.

맡길 업무가 아직 정해지지 않았다면 기획·설계부터 시작하는 방식도 있습니다. 목표와 필요한 화면, 기능을 문서로 남기며 그 문서는 개발사에 그대로 전달할 수 있는 형태입니다.

엔소프 컴퍼니는 업무 확정과 처리 규칙 정의에서 시작해 프로그램 연결, 실제 자료로 하는 확인까지 한 곳에서 진행합니다. 완성된 모습은 다음과 같습니다.

1. 쓰시는 프로그램은 그대로 두고 사이만 이어져 같은 내용을 두 곳에 입력하는 일이 없어집니다.

2. 수강 신청이나 상담 문의는 도착하는 즉시 종류별로 분류됩니다.

3. 매달 직접 만들던 정산과 보고서가 자동으로 만들어집니다.

4. 담당 직원이 결과를 확인하는 관리자 화면과 입력 폼이 필요하시면 함께 개발합니다.

넷 가운데 필요한 한 가지만 먼저 맡기셔도 됩니다. 입력과 분류, 보고서 작성에 쓰던 직원의 시간이 줄어듭니다.

프로젝트를 마치면 동작하는 자동화 시스템과 계정을 고객에게 넘겨드립니다. 기획·설계를 맡기셨다면 요구사항 정의서와 화면 설계서를 넘겨드립니다. 요구사항 정의서에는 고객이 맡기기로 한 업무가 기능으로 적힙니다. 화면 설계서에는 담당 직원이 결과를 확인하는 화면이 그려집니다.

견적을 받기 전에 AI 에이전트에게 맡기고 싶은 반복 업무 한 가지를 알려 주시면 됩니다.

프로젝트 문의하기

영업 담당 직원이 회원 목록을 열었더니 다른 지점의 매출 금액이 그대로 보입니다. 같은 화면 아래쪽에는 대리점에 내주는 공급가까지 적혀 있습니다. 직원이 잘못 누른 것이 아니라 시스템이 사용자를 가리지 않고 같은 화면을 보여 주도록 만들어졌기 때문입니다.

견적서를 받으셨다면 이 문제를 다루는 줄이 따로 있는지 살펴볼 만합니다. 화면 몇 장을 더 그리는 일처럼 보여도 시스템을 만들기 전에 정해야 하는 일이기 때문입니다.

직원이 다른 지점 매출까지 보게 되는 일은 어떻게 생깁니까?

화면 하나를 여러 사용자가 함께 쓰도록 먼저 만들 때 생깁니다. 숨길 부분은 나중에 지우면 된다는 생각으로 시작하기 때문입니다.

도매 회사가 대리점용 주문 화면을 열어 주었다고 하겠습니다. 대리점 담당자가 로그인했는데 다른 대리점의 주문 금액이 같은 목록에 나옵니다. 대리점끼리는 거래 규모를 서로 알리고 싶지 않은데 본사가 만든 화면이 그 금액을 보여 줍니다.

학원에서도 같은 일이 생길 수 있습니다. 원장님이 보는 전체 수강료 매출과 강사가 보는 담당 반 출석표가 하나의 목록에서 출발했다고 해 보겠습니다. 강사에게 다른 반의 미납 내역까지 보이면 학부모 정보가 필요 이상으로 공유됩니다.

도매 회사와 학원 모두 숨기는 일이 사고 뒤에 시작됩니다. 숨기는 일을 나중으로 미루면 사용자가 이미 본 뒤에야 문제가 드러납니다. 한 번 본 정보는 되돌릴 수 없으므로 시스템을 만들 때 누가 무엇을 볼지 먼저 정해야 합니다.

화면에서 숨기는 것과 자료를 나눠 설계하는 것은 무엇이 다릅니까?

화면은 자료를 보여 주는 창이고 누가 어느 자료를 볼 수 있는지는 자료를 담는 틀에서 정해집니다. 그래서 창 모양만 바꾸는 것과 틀을 나누는 것은 다른 일입니다.

같은 자료를 쓰면서 사용자마다 보이는 줄을 제한하는 기능이 있습니다. 이 기능을 행 단위 보안이라 부르고 행은 표의 한 줄을 뜻합니다. 대리점 담당자에게 자기 대리점의 주문 줄만 보이게 하는 것이 한 예입니다.

그런데 줄을 제한하는 기능만으로는 칸을 가릴 수 없습니다. 어떤 줄을 볼 수 있는 사용자는 그 줄에 적힌 칸을 그대로 보기 때문입니다. 자기 대리점의 주문 줄에 공급가 칸이 들어 있으면 공급가도 함께 보입니다. 줄을 나누는 설계와 칸을 나누는 설계는 따로 필요합니다.

보안 분야에는 시스템이 사용자의 접근 권한을 제한해야 한다는 최소 권한 원칙이 있습니다. 직원에게 매출 화면을 먼저 열어 두고 숨길 것을 나중에 고르면 이 원칙과 순서가 반대가 됩니다. 파트너 밑에 또 다른 파트너가 있으면 누가 누구의 매출까지 볼지 정할 규칙도 늘어납니다.

견적서의 사용자 설계 항목은 무엇을 어디까지 하는 일입니까?

견적서에는 「멀티 사이드 사용자 설계 · 데이터 모델과 권한 경계 설계」처럼 적힐 수 있습니다. 이 글에서는 보는 범위 설계라고 부르겠습니다. 멀티 사이드 사용자는 직원, 파트너, 회원처럼 입장이 다른 사용자가 한 시스템을 함께 쓰는 것을 말합니다.

데이터 모델은 매출과 주문, 회원 같은 자료를 어떤 칸과 묶음으로 담을지 정한 틀입니다. 권한 경계는 누가 어느 자료까지 볼 수 있는지 정한 범위입니다. 파트너는 대리점처럼 대신 판매해 주는 거래처를 가리킵니다.

보는 범위 설계는 이런 순서로 진행됩니다.

1. 시스템에 들어오는 쪽을 직원과 파트너, 회원처럼 나눕니다.

2. 나눈 쪽마다 볼 수 있는 줄과 칸을 정합니다.

3. 나눈 쪽마다 화면을 따로 설계합니다. 회원용 화면과 파트너용 관리 화면, 자사 운영 화면이 여기에 해당합니다.

사용자를 나누는 일과 줄과 칸을 정하는 일이 빠진 채 화면만 사용자별로 그려져 있으면 앞에서 본 지점 매출 노출이 생길 수 있습니다. 견적서의 한 줄이 이 세 단계 가운데 어디까지를 뜻하는지 확인해야 하는 이유입니다.

견적을 받기 전에 직원·파트너·회원별로 무엇을 적어 두면 됩니까?

사용자 종류마다 봐도 되는 자료와 가려야 하는 자료를 한 장에 적어 두시면 견적서의 항목을 읽기 쉬워집니다. 적을 내용은 네 가지입니다.

1. 시스템에 들어오는 쪽: 직원만인지 파트너와 파트너 밑의 파트너, 회원까지 들어오는지 적습니다.

2. 쪽마다 봐도 되는 매출: 자기 매출만인지 아래 파트너의 매출까지인지 전체인지 적습니다.

3. 가려야 하는 칸: 공급가와 원가, 수수료처럼 줄은 보여도 칸은 숨겨야 하는 것을 적습니다.

4. 정산 연결 여부: 수수료를 계산해 지급하는 일이 같은 시스템에 들어가는지 적습니다.

받은 견적서에서는 사용자 설계에 해당하는 항목이 있는지 먼저 묻습니다. 항목이 있다면 사용자를 나누는 데까지인지 줄과 칸을 정하는 데까지인지 쪽마다 화면을 설계하는 데까지인지 묻습니다. 항목이 보이지 않으면 그 일이 다른 항목 안에 들어 있는지 묻습니다. 견적서에 사용자 설계 항목이 있는지와 그 항목이 어디까지인지를 묻는 것이 첫 확인입니다.

개발사가 설계 내용을 문서로 넘기는지도 함께 묻습니다. 문서가 있으면 담당자가 바뀌어도 누가 무엇을 보는지 다시 확인할 수 있습니다.

비용은 무엇에 따라 달라집니까?

정해진 금액은 없고 아래 다섯 가지에 따라 범위가 달라집니다.

1. 시스템에 들어오는 사용자의 종류: 직원만인지 파트너와 회원까지인지에 따라 화면 종류가 달라집니다.

2. 파트너의 단계: 파트너 밑에 또 다른 파트너가 있으면 볼 수 있는 범위를 나누는 규칙이 늘어납니다.

3. 가려야 하는 자료: 줄만 나누면 되는지 칸까지 나눠야 하는지에 따라 설계 범위가 달라집니다.

4. 정산의 포함 여부: 수수료 계산과 지급이 시스템에 들어가면 정산 규칙도 설계 대상이 됩니다.

5. 기존 자료의 이전: 이미 쓰는 시스템에 쌓인 자료를 옮겨야 하는지에 따라 범위가 달라집니다.

다섯 가지를 알려 주시면 범위를 잡아 견적을 안내할 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의 뒤의 순서는 다음과 같습니다.

1. 문의를 남기시면 위의 다섯 가지를 중심으로 상담합니다.

2. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

3. 진행하시기로 하면 사용자별 보는 범위를 설계하고 시스템을 제작합니다.

4. 프로젝트를 마치면 시스템과 계정을 고객에게 넘겨드립니다.

그래서 매출 화면을 처음부터 따로 설계해야 합니까?

직원 말고 파트너나 회원이 같은 시스템에 들어오고 사용자마다 보아야 할 매출이 다르다면 따로 설계할 대상입니다. 정산까지 같은 시스템에서 처리하려 하신다면 설계 범위가 넓어집니다.

반대로 시스템을 쓰는 사람이 모두 같은 자료를 봐도 된다면 설계할 범위는 작아집니다. 어느 쪽인지는 앞에서 적어 둔 사용자 종류와 가려야 하는 칸으로 판단하실 수 있습니다. 받으신 견적서가 있다면 그 안에서 사용자 설계 항목의 유무와 범위를 확인해 보실 만합니다.

엔소프 컴퍼니는 직원이 보면 안 되는 매출 화면에 맞춘 플랫폼 설계와 업무 자동화를 AI 에이전트로 개발해 드립니다

직원이 보면 안 되는 매출 화면 때문에 고민이시라면 사용자별 보는 범위를 먼저 설계하는 플랫폼 설계부터 시작할 수 있습니다. 플랫폼 설계는 직원과 파트너, 회원이 한 시스템 위에서 움직이게 하는 설계입니다. 고객이 원하실 경우 엔소프 컴퍼니는 이 설계에 맞춰 시스템을 개발해 드립니다. 기획부터 개발까지 한 곳에서 진행하므로 설계 담당과 개발 담당을 따로 조율하실 필요가 줄어듭니다.

설계에서는 시스템에 들어오는 쪽을 나누고 쪽마다 볼 수 있는 자료의 범위를 정합니다. 수수료 정산의 계산 규칙과 회원용 화면, 파트너용 관리 화면, 자사 운영 화면도 같은 설계에 들어갑니다. 취소와 환불, 분쟁처럼 예외가 생겼을 때의 처리도 함께 설계합니다.

시스템이 움직이기 시작하면 직원이 매달 정산과 매출 보고서를 손으로 만드는 일이 남을 수 있습니다. 고객이 원하시면 이 일을 AI 에이전트가 수행하도록 업무 자동화로 개발해 드립니다. AI 에이전트는 정해 둔 기준대로 반복 업무를 사람 대신 수행하는 프로그램입니다.

쓰시던 프로그램은 그대로 두고 연결하므로 같은 내용을 두 곳에 옮겨 적는 일이 없어집니다. 매달 손으로 만들던 정산과 보고서는 자동으로 만들어집니다. 자료를 옮기고 보고서를 만들던 직원의 시간과 인건비 부담이 줄어듭니다.

설계와 자동화를 한 번에 맡기실 필요는 없고 한쪽부터 시작하셔도 됩니다. 어디까지 맡길지는 고객이 정하시면 됩니다.

프로젝트를 마치면 사용자와 권한, 자료의 범위를 적은 정의서와 정산 계산 규칙을 적은 정의서를 넘겨드립니다. 사용자별 화면 설계서와 동작하는 시스템도 함께 받으실 수 있습니다. 자동화를 맡기셨다면 동작하는 자동화 시스템과 계정도 넘겨드립니다.

직원과 파트너, 회원이 각각 어떤 매출 자료를 보아야 하는지 알려 주시면 됩니다.

프로젝트 문의하기

Webflow(웹플로우)는 코드를 쓰지 않고 화면을 보며 사이트를 만드는 서비스입니다. 한 고객이 개발사에서 “Webflow로 만들면 직접 수정하실 수 있습니다”라는 설명을 듣고 사이트를 맡겼다고 해 보겠습니다.

사이트를 연 뒤 고객은 상담 시간 문구와 대표 사진을 직접 수정했습니다. 그런데 서비스 소개 구역을 하나 더 넣으려는 수정은 직접 할 수 없어 개발사에 다시 연락했습니다. 같은 설명 안에서 어떤 수정은 되고 어떤 수정은 되지 않은 것입니다.

개발자 없이 수정한다는 말은 어떤 수정에서 멈춥니까?

글과 사진 교체는 개발자 없이 할 수 있고 화면 구조 변경은 개발자가 필요한 수정입니다. 「직접 수정」이라는 한 말에 두 종류의 수정이 함께 담길 수 있어 고객이 듣는 범위가 실제와 다를 수 있습니다. 수정 목록을 글·사진 교체와 화면 구조 변경으로 나누면 범위가 분명해집니다.

글·사진 교체에는 상담 시간 안내 문구와 대표 사진, 버튼에 연결된 링크 주소를 수정하는 일이 속합니다. 학원이라면 수강 안내 문구와 강사 사진 교체가 여기에 해당합니다. 병원이라면 진료 시간 문구와 의료진 사진 교체가 같은 종류입니다.

화면 구조 변경에는 서비스 소개 구역을 하나 더 넣는 일과 사진과 글의 배치를 바꾸는 일, 글자 크기와 색의 기본 규칙을 바꾸는 일이 속합니다. 세 가지는 화면의 디자인이나 구조를 바꾸는 일이라는 점이 같습니다.

같은 사이트에서도 이번 달 수정은 글 교체이고 다음 달 수정은 구조 변경일 수 있습니다. 문구 수정이 주된 사이트와 새 화면을 자주 추가하는 사이트는 필요한 준비가 다릅니다. 그래서 사이트로 하는 일과 수정하는 빈도를 먼저 알아야 직접 수정의 범위를 판단할 수 있습니다.

왜 글과 사진은 직접 수정되고 화면 구조는 개발자가 필요합니까?

Webflow Editor(웹플로우 에디터)는 만들어진 사이트의 모습을 보면서 내용을 수정하는 화면이며 코드가 필요 없습니다. 에디터는 디자이너 화면(Designer, 사이트의 디자인과 구조를 만드는 작업 화면)을 열지 않고 쓸 수 있습니다. 그래서 코드를 모르는 직원도 글과 사진을 수정할 수 있습니다.

에디터는 주로 글과 이미지, 링크를 수정하는 데 쓰고 디자인이나 구조를 바꾸려면 디자이너 화면이 필요합니다. 개발사가 직접 수정을 설명할 때 에디터의 범위를 말하는지 디자이너 화면의 범위를 말하는지 물으면 설명의 뜻이 분명해집니다.

디자이너 화면에서 하는 수정에는 화면 구조를 다룰 수 있는 사람이 필요합니다. 그 사람을 직원으로 둘지 개발사에 요청할지에 따라 구조 변경에 걸리는 절차가 달라집니다.

구체적인 수정 항목이 에디터로 되는지는 항목마다 개발사에 확인해야 합니다. 확인 없이 진행하면 하려는 수정이 직접 할 수 없는 쪽에 속한다는 사실을 사이트를 연 뒤에 알게 될 수 있습니다.

직접 수정할 범위는 개발사와 어떤 순서로 확인합니까?

수정 목록을 먼저 적고 항목마다 에디터로 가능한지 개발사에 묻는 순서입니다. 새 사이트라면 지금 사이트에서 수정해 온 내용이 목록의 바탕이 됩니다.

1. 앞으로 수정할 내용을 목록으로 적습니다.

2. 목록의 항목을 글·사진 교체와 화면 구조 변경으로 나눕니다.

3. 글·사진 교체 항목은 에디터로 수정되는지 개발사에 확인하고 답을 문서로 받아 둡니다.

4. 화면 구조 변경 항목은 누가 어떤 방식으로 수정하는지 개발사에 묻습니다.

화면 구조 변경을 누가 맡는지 정해 두지 않으면 구조 변경이 필요한 날 수정이 멈출 수 있습니다. 개발사에 요청하는 방식이라면 요청 방법과 연락 창구도 목록 옆에 적어 둡니다.

답을 문서로 받아 두는 이유는 사이트를 연 뒤에 직접 수정의 범위를 두고 기억이 서로 다를 수 있기 때문입니다. 항목마다 에디터로 가능한지 적혀 있으면 고객은 수정이 필요할 때 개발사에 연락할지 직접 수정할지 바로 판단할 수 있습니다.

사이트에 새 수정이 필요해질 때마다 목록에 항목을 추가하고 같은 확인을 되풀이하면 직접 수정의 범위가 문서로 쌓입니다.

수정을 맡을 직원에게는 어떤 권한을 줍니까?

제한 좌석(Limited Seat, 역할이 제한된 사용자 자리)에는 마케터(홍보 담당)와 콘텐츠 편집자 역할만 줄 수 있고 디자인 권한은 없습니다. 글과 사진을 수정할 직원에게 제한 좌석을 주면 그 직원은 사이트의 디자인을 바꿀 수 없습니다. 수정 범위를 글·사진 교체로 한정하고 싶다면 직원에게 줄 권한을 개발사와 정해 둘 수 있습니다.

수정을 시작하기 전에 세 가지를 정해 둡니다.

1. 글과 사진을 수정할 직원의 이름과 역할

2. 화면 구조 변경을 개발사에 요청할 담당자

3. 수정한 내용을 확인할 사람

수정 담당자가 한 명이면 내용 확인이 간단하고 여러 명이면 수정할 수 있는 사람이 늘어납니다. 직원이 바뀌는 때에 대비해 수정 권한을 가진 사람의 목록을 문서에 남겨 둡니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없고 다음 다섯 가지에 따라 범위가 달라지므로 상담 뒤 견적으로 안내합니다.

1. 공개할 사이트의 수: 사이트 요금제(사이트를 공개할 때 내는 이용 요금)는 공개하는 사이트마다 따로 청구됩니다

2. 직접 올릴 글과 항목의 양: 요금제마다 한도가 있어 수정할 콘텐츠 규모에 맞는 요금제가 필요합니다

3. 수정할 직원의 수와 역할: 직원이 늘수록 권한을 나누는 범위가 넓어집니다

4. 화면 구조 변경이 필요한 빈도: 잦을수록 개발자가 맡을 범위가 커집니다

5. 사이트를 새로 만드는지 지금 사이트를 수정하는지

수정할 내용과 사이트 수, 수정할 직원 수를 알려 주시면 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

1. 문의를 남기시면서 사이트로 하는 일과 수정하는 빈도를 적어 주시면 됩니다.

2. 상담에서 수정 목록을 글·사진 교체와 화면 구조 변경으로 나눠 봅니다.

3. 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

4. 진행하시기로 하면 사이트를 제작합니다.

5. 프로젝트를 마치면 사이트와 계정을 고객에게 넘겨드립니다.

그래서 Webflow로 개발자 없이 사이트를 수정하는 방식을 알아봐야 합니까?

글과 사진 교체가 수정의 중심이고 화면 구조 변경은 간격을 두고 가끔 필요한 사이트라면 알아볼 만합니다. 화면 구조 변경 요청이 짧은 간격으로 이어지는 사이트라면 구조 변경을 요청할 창구가 정해진 상태에서 시작하는 편이 맞습니다.

엔소프 컴퍼니는 Webflow로 개발자 없이 수정하는 사이트와 반복 업무 자동화를 AI 에이전트로 개발해 드립니다

Webflow로 개발자 없이 사이트를 수정하고 싶은 고객이 정하신 수정 범위는 엔소프 컴퍼니가 문서로 남기고 그 문서를 기준으로 개발합니다. 엔소프 컴퍼니는 사이트로 하는 일과 업데이트 주기를 듣고 맞는 구축 방식을 추천합니다. 구축 방식은 사이트를 만드는 데 쓰는 서비스의 종류이며 고객이 원하실 경우 추천한 방식으로 사이트를 개발해 드립니다. 기획과 디자인, 개발, 공개까지 한 곳에서 진행합니다.

직접 수정하는 사이트에서도 소식 글을 올리고 문의를 종류별로 정리하는 일은 직원에게 남습니다. 고객이 원하시면 엔소프 컴퍼니는 직원이 에디터로 하던 소식 올리기와 문의 정리를 AI 에이전트가 수행하도록 개발해 드립니다. AI 에이전트는 정해 둔 기준대로 반복 업무를 사람 대신 처리하는 프로그램이며 맡길 범위는 고객이 정하시면 됩니다.

수정 담당 직원의 일은 이렇게 달라집니다.

1. 고객이 정한 주제의 글이 검색엔진이 읽을 수 있는 형식으로 사이트에 올라갑니다.

2. 문의와 신청이 들어오는 대로 종류별로 나뉩니다.

3. 쓰시던 프로그램은 그대로 두고 사이만 이어져 같은 내용을 두 번 옮겨 적는 일이 없어집니다.

올리기 전에 직접 보고 승인하는 방식도 가능하며 세 가지를 한 번에 맡기실 필요는 없고 하나부터 시작하셔도 됩니다. 글을 올리고 옮겨 적던 직원의 시간과 인건비 부담이 줄어듭니다.

프로젝트를 마치면 배포된 웹사이트와 콘텐츠 관리 환경, 계정을 넘겨드립니다. 배포는 완성한 사이트를 방문자가 볼 수 있게 인터넷에 올리는 일이며 콘텐츠 관리 환경은 글과 사진을 수정하는 관리 화면입니다. 소식 올리기와 문의 정리를 맡기셨다면 그 일을 수행하는 장치도 함께 받으실 수 있습니다.

사이트로 무엇을 하시는지와 얼마나 자주 수정하시는지 알려 주시면 됩니다.

프로젝트 문의하기

저녁 업무를 마치고 나서야 낮에 직원이 보낸 메시지를 열어 보게 됩니다. AI 에이전트에 손님 명단과 계약서 폴더를 연결해도 되는지 묻는 내용입니다. 일이 빨라진다는 설명은 이해되지만 회사 자료가 어디까지 읽히는지 알 수 없어 답을 내일로 미룹니다.

AI 에이전트는 고객이 정해 준 일을 사람 대신 수행하는 AI 프로그램입니다. 회사 데이터를 어디까지 열어 줄지 정하려면 두 범위를 따로 정해야 합니다. 하나는 고객이 AI 에이전트에 읽게 할 자료의 범위이고 다른 하나는 고객이 AI 에이전트에 맡길 행동의 범위입니다. 두 범위는 좁게 시작해서 필요가 확인될 때 넓혀 가면 판단하기 쉽습니다.

AI 에이전트가 회사 자료를 읽으면 어떤 문제가 생길 수 있습니까?

공격자가 AI 에이전트가 읽어 들일 수 있는 자료 속에 나쁜 지시를 심어 두는 공격이 있습니다. 미국 국립표준기술연구소(NIST)는 이 공격을 에이전트 하이재킹이라고 부릅니다. 이 공격이 성공하면 AI 에이전트가 고객의 의도와 다른 해로운 행동을 하게 됩니다. AI 에이전트가 읽는 자료가 공격의 통로가 된다는 뜻입니다.

예를 들어 거래처가 보낸 문서나 외부에서 내려받은 파일까지 읽도록 연결할 수 있습니다. 그러면 회사 밖에서 만든 글이 읽는 자료에 섞여 들어옵니다. 그 글에 나쁜 지시가 들어 있는지는 사람이 눈으로 읽어서 알아보기 어려울 수 있습니다. 읽게 할 자료를 정할 때는 회사가 직접 만든 자료와 외부에서 들어온 자료를 나누어 보는 편이 판단하기 쉽습니다.

OWASP(오와스프) 젠AI 보안 프로젝트는 비영리 보안 커뮤니티입니다. OWASP는 AI가 과도한 권한으로 해로운 행동을 하는 문제를 과도한 에이전시라고 부릅니다. 근본 원인으로는 기능이 너무 많은 상태와 권한이 너무 넓은 상태와 자율성이 너무 큰 상태를 꼽습니다. OWASP는 이 세 상태 가운데 한 가지 이상이 원인이라고 봅니다.

기능은 AI 에이전트가 할 수 있는 일의 종류이고 권한은 읽고 수정할 수 있는 자료의 범위입니다. 자율성은 사람이 확인하지 않아도 AI 에이전트가 스스로 진행하는 정도를 말합니다. 회사 데이터를 열어 주는 일은 AI 에이전트의 기능과 권한과 자율성을 얼마나 크게 줄지 정하는 일입니다.

우리 회사는 AI 에이전트를 도입해도 되는 상태입니까?

아래 세 가지에 답할 수 있다면 도입을 검토할 만한 상태입니다.

1. 맡길 일이 무엇인지 한 문장으로 말할 수 있습니다.

2. 맡길 일에 쓰는 자료가 어디에 보관되어 있는지 말할 수 있습니다.

3. 열지 않을 자료가 무엇인지 말할 수 있습니다.

학원이라면 학부모 연락처와 상담 기록이, 병원이라면 진료 기록이 열지 않을 자료의 후보입니다. 제조업이라면 도면과 단가표가, 시공업이라면 계약서와 견적 내역이 후보에 들어갑니다. 어떤 자료를 열지 않을지는 업종마다 다르고 같은 업종이어도 회사에 따라 달라질 수 있습니다.

반대로 회사 폴더 전체를 연결하고 싶다는 생각만 있고 맡길 일이 없다면 먼저 일의 범위를 정해야 합니다. 일의 범위가 없으면 열어 줄 자료도 정할 수 없어 연결 범위가 필요 이상으로 넓어지기 쉽습니다.

직원 한 명이 볼 수 있는 자료의 범위를 기준으로 삼으면 판단이 쉬워집니다. 신입 직원에게 보여 주지 않을 자료라면 AI 에이전트에게도 열지 않는 쪽으로 시작할 수 있습니다. 업무에 필요하다는 이유가 확인된 자료만 나중에 추가하면 됩니다.

도입할 때 고객은 무엇을 정하면 됩니까?

AI 에이전트는 연결하는 순간부터 임의로 움직이지 않고 고객이 처음에 정한 기준 안에서 일을 이어 갑니다. 그래서 고객이 하는 일은 기준을 한 번 정하는 것이며 기준은 아래 세 가지입니다.

1. 맡길 일 하나와 그 일에 필요한 자료의 범위를 정합니다.

2. 자료마다 읽기만 허용할지 수정까지 허용할지 정합니다.

3. 영향이 큰 행동을 정하고 그 행동은 실행 전에 사람이 승인하도록 정합니다.

OWASP는 AI 도구가 다른 시스템에서 받는 권한을 필요한 최소한으로 제한하라고 권고합니다. 권고의 예로 데이터베이스(회사 정보를 모아 둔 저장 공간)에 읽기 전용 접근만 주는 방식을 듭니다. 읽기만 허용한 자료는 AI 에이전트가 내용을 볼 수 있어도 바꿀 수 없습니다. 그래서 처음 연결은 읽기 전용으로 시작하는 쪽이 판단하기 쉽습니다.

OWASP는 영향이 큰 행동을 실행하기 전에 사람이 승인하는 사람 개입 통제도 권고합니다. 손님에게 메일을 보내는 일이나 자료를 삭제하는 일, 금액이 오가는 일이 영향이 큰 행동의 예입니다. 담당자가 내용을 보고 승인한 뒤에만 실행되도록 정해 두면 자율성이 큰 상태를 피할 수 있습니다.

자료를 읽기만 하는 일은 승인 없이 진행하고 밖으로 나가거나 자료를 바꾸는 행동만 승인을 거치게 할 수도 있습니다. 그러면 담당 직원이 행동마다 확인하는 부담이 줄어듭니다. 어느 행동까지 승인 대상으로 둘지는 회사의 사정에 맞춰 고객이 정하시면 됩니다.

처음 정한 기준은 AI 에이전트를 쓰면서 바꿀 수 있습니다. 읽기 전용으로 일정 기간 써 본 뒤 수정이 필요한 일만 추가로 허용하는 순서도 가능합니다.

도입한 뒤에는 무엇을 어디서 확인합니까?

도입한 뒤에는 AI 에이전트가 쓰는 계정에 연결된 자료 목록과 사람이 승인한 행동 내역을 정해진 날에 확인합니다. 확인은 담당 직원이 하고 대표는 결과만 보시는 방식으로 시작할 수 있습니다.

도입할 때 자료 목록을 계정 관리 화면에서 볼 수 있게 해 두면 처음 정한 범위와 같은지 비교할 수 있습니다. 처음에 없던 폴더가 목록에 늘어나 있다면 누가 왜 추가했는지 담당 직원에게 물어보시면 됩니다. 편의를 위해 연결이 하나둘 추가되는 일이 있으므로 정해진 날에 보는 방식이 필요합니다.

승인 내역에서는 어떤 행동을 누가 승인했는지와 승인 없이 진행된 행동이 없는지를 봅니다. 영향이 큰 행동으로 정한 종류가 승인 없이 실행되었다면 설정이 처음 기준과 다르다는 뜻입니다. 자료 목록과 승인 내역을 정해진 날에 보는 것만으로도 열어 준 범위가 처음 기준에서 벗어났는지 알 수 있습니다.

맡긴 일을 하나 더 추가할 때는 그 일에 필요한 자료와 승인 지점을 처음과 같은 순서로 다시 정합니다. 기존 일에 쓰던 권한을 그대로 겹쳐 쓰면 새 일에 필요하지 않은 자료까지 열려 있을 수 있기 때문입니다.

AI 에이전트의 동작이 이상해 보일 때 연결을 중단할 담당자가 누구인지도 미리 정해 둡니다. 담당 직원이 중단 방법을 알고 있으면 확인 결과에 따라 바로 조치할 수 있습니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없고 아래 다섯 가지에 따라 범위가 달라지므로 금액은 상담 뒤 견적으로 안내합니다.

1. 맡길 일이 몇 가지인지

2. 연결할 자료가 어디에 있는지: 한곳에 정리되어 있는지 여러 곳에 흩어져 있는지

3. 수정까지 허용할 일이 있는지: 읽기만 하는 일로 충분한지

4. 사람이 승인하는 지점이 몇 곳인지, 승인용 화면이 필요한지

5. 지금 쓰시는 프로그램이 몇 종류이고 서로 연결해야 하는지

다섯 가지를 알려 주시면 범위를 잡을 수 있습니다. 아직 정해지지 않은 항목은 상담에서 함께 확인합니다.

문의하면 어떤 순서로 진행됩니까?

문의하신 뒤의 순서는 이렇습니다.

1. 문의를 남기시면 위의 다섯 가지를 중심으로 상담합니다.

2. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

3. 진행하시기로 하면 정하신 자료 범위와 승인 지점에 맞춰 AI 에이전트를 만듭니다.

4. 프로젝트를 마치면 동작하는 시스템과 계정을 고객에게 넘겨드립니다.

그래서 AI 에이전트에게 회사 데이터를 열어 줘도 됩니까?

맡길 일 하나와 그 일에 필요한 자료의 범위, 사람이 승인할 행동을 말할 수 있다면 열어 줄 준비가 된 것입니다. 이 가운데 답이 정해지지 않은 항목이 있다면 연결을 서두를 이유는 없습니다.

한 가지가 더 있습니다. 손님에게 받은 개인정보 이용 동의서와 거래처와 맺은 계약서를 확인해 보시면 됩니다. 동의서와 계약서에 자료를 외부 서비스에 입력하는 것을 제한하는 문구가 있으면 그 자료는 열 수 없습니다.

엔소프 컴퍼니는 회사 데이터를 어디까지 열어 줄지에 맞춘 업무 자동화를 AI 에이전트로 개발해 드립니다

AI 에이전트에게 회사 데이터를 어디까지 열어 줄지 정하기 어려우시면 맡길 일부터 정하는 방법이 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 AI 에이전트를 개발해 드립니다. 이 AI 에이전트는 고객이 정한 반복 업무 하나에 필요한 자료만 연결합니다. 맡길 반복 업무와 열어 줄 자료는 고객이 고르시면 됩니다.

개발은 대상 업무 확정과 처리 규칙 정의로 시작합니다. 쓰시는 프로그램과의 연결과 실제 데이터로 하는 확인까지 엔소프 컴퍼니 한 곳에서 이어집니다. 완성된 모습은 이렇습니다.

1. 쓰시는 프로그램은 그대로 두고 맡긴 업무에 필요한 자료만 AI 에이전트와 이어집니다.

2. 손님 정보를 두 곳 이상에 따로 입력하던 일이 사라집니다.

3. 신청과 접수는 들어오는 대로 분류되고 매달 직접 만들던 정산과 보고서는 자동으로 만들어집니다.

4. 영향이 큰 행동을 담당 직원이 확인하는 관리자 화면과 입력 폼도 필요하시면 개발합니다.

네 가지를 한 번에 하실 필요는 없고 한 가지부터 시작하셔도 됩니다. 자료 입력과 분류, 보고서 작성에 쓰던 직원의 시간과 인건비 부담이 줄어듭니다. 그 시간은 손님 응대와 상담 같은 본업에 쓰실 수 있습니다.

직원과 거래처, 회원이 같은 시스템을 쓰면서 서로 다른 데이터를 보아야 한다면 플랫폼 설계가 이어집니다. 플랫폼 설계는 여러 참여자가 하나의 시스템 위에서 움직이게 하는 설계입니다. 엔소프 컴퍼니는 참여하는 쪽을 나누고 각자가 볼 수 있는 데이터의 범위를 설계해 드립니다.

프로젝트를 마치면 동작하는 자동화 시스템과 운영 절차 문서, 계정을 고객에게 넘겨드립니다.

AI 에이전트에게 맡기고 싶은 반복 업무 하나와 그 업무에 쓰는 자료가 지금 어디에 보관되어 있는지 알려 주시면 됩니다.

프로젝트 문의하기

새 사이트를 연 뒤에 AI 서비스에 우리 회사를 물었더니 옛 서비스 설명이 나옵니다. 이름이 비슷한 다른 회사 소개가 대신 나오기도 합니다. 브라우저로 열어 보면 새 사이트는 흠 없이 보이는데 답변만 어긋나 있습니다.

AI 서비스가 사이트 내용을 읽어 가는 프로그램은 사람과 다른 방식으로 사이트를 받아 갑니다. 이 글에서는 그 프로그램을 읽기 프로그램이라고 부릅니다.

새로 연 사이트가 AI 답변에서 빠지는 일이 실제로 있습니까?

오픈 전에 걸어 둔 접근 차단이 오픈 뒤에도 남아 있는 사이트가 있습니다. 차단은 사이트 주소 바로 아래에 두는 접근 범위 안내 파일(robots.txt)에 적습니다. 그 파일로 읽기 프로그램을 막아 두면 사이트 내용은 AI 답을 만드는 자료로 모이지 않습니다. 개발 중에 쓰던 설정을 그대로 옮겨 온 사이트라면 이런 상태일 수 있습니다.

주소가 바뀐 리뉴얼 사이트에서는 다른 일이 생깁니다. 사이트맵은 어떤 주소가 있는지 읽기 프로그램에 알려 주는 목록입니다. 사이트맵에는 옛 주소가 있고 페이지마다 붙여 둔 대표 주소는 새 주소라고 해 보겠습니다. 두 주소가 엇갈리면 읽기 프로그램은 어느 쪽을 믿을지 정하지 못합니다.

차단 설정과 주소 엇갈림은 사람이 사이트를 둘러볼 때 드러나지 않습니다. 오픈 날 화면과 문의 양식, 연락처가 정상으로 보이면 확인이 끝난 것처럼 느껴집니다. 그러나 차단 파일과 주소 목록은 화면 밖에 있으므로 화면만 봐서는 확인할 수 없습니다.

AI 답변에 옛 정보가 나오는 이유를 사이트 쪽 항목 하나로 단정할 수는 없습니다. AI 서비스 안에서 일어나는 일은 사이트 운영자가 볼 수 없기 때문입니다. 그래서 사이트 쪽에서 확인할 수 있는 항목부터 보는 편이 순서에 맞습니다.

화면이 멀쩡한데 읽기 프로그램에는 왜 비어 있습니까?

읽기 프로그램은 서버가 주소 요청에 처음 보내 주는 내용(첫 응답)을 받아 갑니다. 서버는 사이트 파일을 보관하다가 방문 요청이 오면 내용을 보내 주는 컴퓨터입니다. 첫 응답에 본문이 없으면 읽기 프로그램이 읽을 글도 없습니다.

화면을 브라우저에서 자바스크립트로 그리는 사이트가 있습니다. 자바스크립트는 브라우저 안에서 화면을 만들어 내는 프로그램 언어입니다. 이런 사이트는 사람에게 완성된 화면이 보여도 첫 응답에는 본문이 없을 수 있습니다. 사람 눈에 보이는 화면과 읽기 프로그램이 받는 첫 응답은 다를 수 있습니다. 서버가 완성된 글을 바로 보내 주는 방식이면 이 문제가 생기지 않습니다.

정해진 형식 정보는 사람이 읽는 화면과 별도로 같은 내용을 정해진 형식으로 적어 두는 일입니다. 회사 이름과 글쓴이, 발행일, 자주 묻는 질문 같은 항목이 여기에 들어갑니다. 읽기 프로그램은 이 항목들을 헷갈리지 않고 가져갑니다.

글의 제목 계층도 뼈대가 됩니다. 제목 계층은 큰 제목 아래 중간 제목 아래 작은 제목으로 단계마다 이어지는 순서를 말합니다. 그 순서를 건너뛰지 않는 것이 뼈대를 지키는 방법이고 읽기 프로그램은 그 뼈대를 그대로 읽습니다.

내 사이트가 읽기 프로그램에 어떻게 보이는지 어디서 확인합니까?

확인은 화면이 아니라 설정 파일과 페이지 소스에서 합니다. 개발을 몰라도 브라우저 주소창과 마우스 오른쪽 메뉴만 있으면 아래 다섯 항목을 볼 수 있습니다.

1. 사이트 주소 뒤에 /robots.txt 를 붙여 열고 사이트 전체를 막는 줄이 남았는지 봅니다.

2. 첫 화면에서 마우스 오른쪽 메뉴의 페이지 소스 보기를 열고 본문 문장 하나를 검색합니다.

3. 같은 페이지 소스에서 회사 이름과 발행일이 정해진 형식으로 적혀 있는지 봅니다.

4. 사이트 주소 뒤에 /sitemap.xml 을 붙여 열고 목록의 주소가 페이지의 대표 주소와 같은지 비교합니다.

5. 사이트 주소 뒤에 /llms.txt 를 붙여 열고 파일이 있는지 봅니다.

읽을 곳 안내 파일(llms.txt)은 읽기 프로그램에게 이 사이트에서 무엇을 읽으면 되는지 알려 주는 파일입니다. 접근 범위 안내 파일과 같은 자리에 두므로 차단 줄이 남았는지 보는 1번 항목과 함께 볼 만합니다.

페이지 소스에서 본문 문장이 검색되지 않으면 첫 응답에 본문이 없는 사이트일 수 있습니다. 그때는 개발사에 서버가 완성된 글을 바로 보내 주는 방식으로 바꿀 수 있는지 물어보시면 됩니다.

구글 검색 쪽 확인은 서치콘솔(구글이 사이트 상태를 보여 주는 도구)의 주소 검사 기능(URL 검사)에서 할 수 있습니다. 주소 하나를 넣으면 구글이 그 페이지를 읽은 상태를 볼 수 있습니다. 검색 결과에 실리는지는 구글이 정하므로 이 화면에서는 읽힌 상태까지만 확인합니다.

오픈 전에 개발사와 어떤 항목을 먼저 맞춰 둡니까?

오픈 전에 맞춰 둘 항목은 차단 해제 시점, 본문을 만드는 방식, 정해진 형식 정보에 넣을 내용, 대표 주소입니다. 네 항목은 화면 디자인 시안에는 나오지 않습니다. 그래서 고객이 먼저 물어보지 않으면 논의 없이 지나가는 경우가 있습니다.

1. 차단 설정을 언제 누가 풀고 풀린 것을 어떻게 확인하는지

2. 본문을 서버가 완성해서 보내는지 브라우저에서 그리는지

3. 정해진 형식 정보에 회사 이름과 글쓴이, 발행일, 자주 묻는 질문 가운데 무엇을 넣는지

4. 리뉴얼로 주소가 바뀔 때 사이트맵과 대표 주소를 어느 쪽에 맞추는지

차단을 건 사람과 푸는 사람이 다르면 해제 확인이 빠질 수 있습니다. 개발 기간에는 한 업체가 설정하고 오픈 때는 다른 업체가 사이트를 올리는 경우가 그런 예입니다.

본문을 만드는 방식은 사이트의 기본 구조와 이어져 있습니다. 그래서 오픈 뒤에 바꾸려면 작업 범위가 달라질 수 있습니다. 이 항목은 만들기 시작하는 단계에서 정해 두는 편이 부담이 작습니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없고 아래 기준에 따라 범위가 달라지므로 상담 뒤 견적으로 안내합니다.

1. 사이트를 새로 만드는지 지금 사이트를 수정하는지

2. 지금 사이트가 브라우저에서 화면을 그리는 방식인지 서버가 글을 완성해서 보내는 방식인지

3. 정해진 형식 정보에 넣을 글 종류와 항목이 얼마나 되는지

4. 주소가 바뀌어 사이트맵과 대표 주소를 정리해야 하는지

5. 오픈 뒤에 글을 계속 올릴 계획이 있는지

다섯 가지 가운데 아시는 것만 알려 주셔도 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의하신 뒤의 순서는 아래와 같습니다.

1. 문의를 남기시면 사이트 주소와 현재 겪고 계신 문제를 듣습니다.

2. 상담에서 위의 비용 기준을 하나씩 확인합니다.

3. 범위와 견적을 안내합니다. 견적을 보고 진행할지는 고객이 정하시면 됩니다.

4. 진행하시기로 하면 사이트를 제작합니다.

5. 프로젝트를 마치면 사이트와 계정을 고객에게 넘겨드립니다.

그래서 지금 사이트의 설정 파일부터 열어 봐야 합니까?

새 사이트를 연 뒤에 AI 답변에 옛 정보나 다른 회사 설명이 나온다면 다섯 항목을 한 번 열어 볼 만합니다. 막힌 곳이 나오면 그 항목을 개발사에 수정 요청하시면 됩니다.

다섯 항목에서 막힌 곳이 나오지 않았다면 사이트 쪽 원인은 일단 제외할 수 있습니다. 그때는 사이트 설정을 더 만지기보다 AI 서비스 쪽 사정을 따로 살펴보셔야 합니다.

엔소프 컴퍼니는 AI에게 빈 페이지로 읽히는 사이트에 맞춘 웹사이트 구축과 글 발행을 AI 에이전트로 개발해 드립니다

사람 눈엔 멀쩡한데 AI에게는 빈 페이지로 읽히는 사이트를 다시 만들려 하신다면 고객이 원하실 경우 엔소프 컴퍼니가 읽히는 구조부터 갖춰 개발해 드립니다. 엔소프 컴퍼니는 검색 최적화(SEO, 검색 결과에서 읽히기 쉽게 사이트를 맞추는 작업)를 기본으로 둡니다. 정해진 형식 정보와 읽을 곳 안내 파일을 포함해 검색엔진과 읽기 프로그램 양쪽이 읽을 수 있는 형태로 사이트를 만듭니다.

기획과 디자인, 개발, 공개까지 한 곳에서 진행하므로 업체별로 조율하는 부담이 줄어듭니다. 정보구조 설계와 기획에서 시작하므로 위에서 본 네 항목도 만들기 전에 정해 둘 수 있습니다.

사이트를 연 뒤에는 글을 계속 올리는 일이 남습니다. AI 에이전트는 정해 둔 일을 사람 대신 수행하는 프로그램입니다. 고객이 정하신 주제의 글을 AI 에이전트가 만들어 검색에서 찾기 쉬운 형태로 올리면 글마다 처음부터 쓰지 않아도 글이 꾸준히 쌓입니다. 학원이나 병원, 시공 회사처럼 안내 글이 계속 필요한 곳이면 이 방식이 맞는지 살펴볼 수 있습니다.

사이트 구축과 글 올리기를 한 번에 맡기실 필요는 없고 한쪽부터 시작하셔도 됩니다. 글을 쓰고 올리던 직원의 시간과 인건비 부담이 줄어듭니다.

프로젝트를 마치면 공개한 웹사이트와 글을 올리고 관리하는 화면, 계정을 넘겨드립니다. 글 올리는 AI 에이전트도 맡기셨다면 그 장치도 함께 받으실 수 있습니다.

지금 운영 중인 사이트 주소와 AI 답변에 나온 잘못된 설명 한 가지를 알려 주시면 됩니다.

프로젝트 문의하기

경쟁사 사이트를 열었더니 화면이 부드럽게 움직이고 여백까지 정돈되어 있어서 누가 만들었는지 알아본 적이 있으실 것입니다. 알아보니 디자이너가 Framer(프레이머, 화면을 디자인하듯 사이트를 만드는 서비스)로 만든 사이트였습니다. 그 디자이너가 우리 사이트도 같은 서비스로 만들자고 제안하면 시안만 보고 바로 승낙하고 싶어집니다.

Framer의 디자인 자유도를 얻는 만큼 고객이 포기하는 것이 있습니다. 포기하는 내용은 사이트를 만드는 날에는 보이지 않고 개발사를 바꾸거나 글이 늘어나는 때에 드러납니다. 만들기 전에 알아 두시면 시안만 보고 정하는 일을 피할 수 있습니다.

Framer로 만든 사이트를 다른 곳으로 옮기려 하면 무슨 일이 생깁니까?

Framer는 공개한 사이트를 HTML 파일(웹페이지를 이루는 기본 파일)로 내려받는 방법을 제공하지 않습니다. 그래서 고객이 따로 계약한 호스팅으로 사이트를 옮길 수 없습니다. 호스팅은 사이트 파일을 올려 두고 방문자에게 보여 주는 공간입니다. 사이트가 Framer 안에서만 운영된다는 뜻입니다.

예를 들어 학원을 운영하는 고객이 사이트를 만든 지 한참 뒤에 수정을 맡길 개발사를 바꾼다고 해 보겠습니다. 새 개발사는 사이트 파일을 받아 직접 마련한 호스팅에 올리려 하지만 받을 파일이 없습니다. 선택지는 Framer 안에서 계속 운영하거나 사이트를 새로 만드는 것입니다.

이런 상황에서는 사이트 파일보다 Framer 계정이 누구 이름으로 되어 있는지가 더 큰 문제가 됩니다. 계정이 개발사 이름으로 되어 있으면 프로젝트 종료 후에 고객이 사이트 관리 화면에 들어가지 못할 수 있습니다. 만들기 시작하는 날 Framer 계정 소유자 이름을 확인하시면 됩니다.

반대로 사이트를 한 곳에 두고 같은 서비스 안에서 계속 수정할 계획이라면 이전 제한은 일상에서 드러나지 않습니다. 제한이 드러나는 때는 개발사를 바꾸는 때와 회사 정책으로 호스팅을 직접 정해야 하는 때입니다. 개발사 교체와 호스팅 변경이 생기지 않을 사이트라면 이전 제한의 비중은 낮습니다.

Framer로 만든 사이트가 빠르게 열리는 일은 누가 관리합니까?

Framer는 사이트가 빠르게 열리도록 하는 속도와 최적화 기능 상당수가 Framer 자체 서버 설비에 의존한다고 밝힙니다. 사이트를 빠르게 보여 주는 일의 상당 부분을 개발사가 아니라 Framer가 맡는 구조입니다.

디자이너에게 Framer가 매력적인 점은 화면을 그리듯 배치와 움직임을 정해 곧바로 사이트로 만들 수 있다는 것입니다. 코드(웹페이지를 만드는 명령 문장)를 직접 작성하는 단계가 줄어들 수 있어 시안과 가까운 모양을 만들 수 있습니다.

그 편리함에는 대가가 있습니다. 속도와 최적화 기능이 Framer의 서버 설비에 의존하므로 개발사의 조정 범위가 좁아질 수 있습니다. 개발사가 직접 조정할 수 있는 범위는 Framer가 열어 둔 설정으로 한정될 수 있습니다.

방문자가 보는 공개 화면은 표준 형식의 파일로 이루어집니다. HTML과 CSS, JavaScript(웹페이지의 구조와 모양과 동작을 정하는 언어), 이미지 파일이 그렇습니다. 그러나 CMS(글이나 상품 정보를 입력해 두면 사이트에 보여 주는 관리 기능)에 쌓아 둔 내용은 다릅니다. 플러그인(기능을 추가하는 프로그램)을 거쳐야 CSV나 JSON이라는 데이터 파일로 꺼낼 수 있습니다.

병원이나 시공 회사처럼 안내 글과 사례 글을 계속 쌓는 사이트에서는 내용을 꺼내는 절차가 필요할 수 있습니다. Framer에서는 화면 디자인을 얻는 대신 사이트 파일과 속도 조정을 Framer에 맡기게 됩니다. 그런 사이트를 운영하실 고객은 만들기 전에 내용을 꺼내는 절차를 개발사에 확인하실 수 있습니다.

Framer로 만들지는 어떤 순서로 판단합니까?

사이트에 필요한 기능을 세 단계로 대조하면 Framer가 맞는지 판단할 수 있습니다.

1. 회원 로그인이 필요한지 확인합니다. 로그인이나 회원 기능은 Framer 안에서 직접 만들기보다 외부 플러그인을 추가하는 방식이 안내됩니다. Outseta, Gately, Thenty가 회원 관리용 플러그인의 예입니다.

2. 글과 페이지가 얼마나 늘어날지 예상합니다. Framer 무료 플랜은 요금을 내지 않고 쓰는 기본 이용 방식입니다. 무료 플랜에서는 CMS 컬렉션(글 종류별 묶음) 10개와 페이지 1,000개까지 쓸 수 있습니다. 규모가 커지면 요금제를 바꿔야 합니다.

3. 글을 자주 올릴 사이트라면 CMS 기능을 비교합니다. CMS 기능만 놓고 보면 Framer와 Webflow(웹플로우, 같은 종류의 사이트 제작 서비스)는 비슷합니다. 비교한 쪽은 Webflow가 약간 낫다고 평가했습니다.

세 단계에서 문제가 되는 항목이 없으면 Framer의 디자인 자유도를 쓰는 데 부담이 적습니다. 문제가 되는 항목이 있으면 다른 구축 방식과 비교합니다. 워드프레스(글을 쓰고 관리하는 화면이 갖춰진 웹사이트 제작 프로그램)와 Webflow가 비교 대상입니다. 비교한 뒤에도 Framer가 맞는 것으로 나올 수 있습니다.

예를 들어 수강생 전용 자료실이 있는 학원 사이트는 첫 단계에서 문제가 됩니다. 반면 시공 사례 몇 편과 문의 양식만 있는 회사 사이트는 세 단계를 지나도 문제가 되는 항목이 거의 없습니다.

디자인 시안이 마음에 들어도 구축 방식은 시안만으로 정하지 않습니다. 회원 로그인과 글 규모와 CMS 기능은 Framer를 정하기 전에 대조해 볼 항목입니다.

사이트로 하는 일과 업데이트 주기는 어떻게 적습니까?

사이트로 하는 일은 방문자가 사이트에서 하는 행동으로 적고 업데이트 주기는 누가 얼마나 자주 내용을 수정하는지로 적습니다. 두 내용이 적혀 있으면 개발사와 같은 기준으로 Framer가 맞는지 이야기할 수 있습니다.

1. 방문자가 사이트에서 문의하는지 예약하는지 가입하는지 구매하는지를 적습니다.

2. 수정하는 사람이 직원인지 개발사인지와 수정하는 주기를 적습니다.

3. 개발사나 호스팅을 바꿀 가능성이 있는지 적습니다.

예를 들어 진료 시간 안내만 가끔 수정하는 병원 사이트와 매일 소식을 올리는 제조 회사 사이트가 있습니다. 두 사이트는 같은 서비스를 써도 부담이 다릅니다. 올리는 글이 늘수록 CMS 기능과 규모 한도가 판단에 더 크게 작용합니다.

적으실 때는 지금 계획만이 아니라 앞으로 추가될 기능도 한 줄 넣어 두시면 좋습니다. 회원 기능이 필요한지는 기능이 추가될 때가 아니라 적는 단계에서 미리 드러납니다.

비용은 무엇에 따라 달라집니까?

사이트의 범위는 사이트로 하는 일과 규모, 업데이트 주기, 디자인 준비 상태에 따라 달라집니다.

1. 사이트로 하는 일: 회사 소개 위주인지 문의·예약·회원 기능까지 있는지

2. 페이지와 글의 규모: 처음 만들 페이지 수와 앞으로 늘어날 글의 양

3. 업데이트 주기와 담당자: 직원이 직접 수정하는지 개발사에 맡기는지

4. 디자인 준비 상태: 마음에 둔 참고 사이트나 시안이 있는지 새로 기획해야 하는지

5. 구축 방식: Framer로 만들지 다른 방식으로 만들지

사이트로 하는 일과 규모, 수정 주기를 알려 주시면 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의부터 인계까지 다음 순서로 진행합니다.

1. 문의를 남기시면 사이트로 하는 일과 수정 주기를 중심으로 상담합니다.

2. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

3. 진행하시기로 하면 기획과 디자인, 개발을 한 곳에서 제작합니다.

4. 프로젝트를 마치면 사이트와 계정을 고객에게 넘겨드립니다.

그래서 Framer로 만들어도 됩니까?

소개와 문의 접수가 중심이고 수정 담당과 주기가 정해져 있는 사이트라면 Framer의 디자인 자유도를 알아볼 만합니다. 개발사를 바꿀 계획이 없다면 이전 제한도 문제가 되지 않습니다. 회원 기능이나 큰 규모의 글 보관이 필요하다면 다른 구축 방식과 나란히 놓고 비교하실 수 있습니다.

엔소프 컴퍼니는 Framer의 디자인 자유도에 맞춘 사이트와 반복 업무 자동화를 AI 에이전트로 개발해 드립니다

Framer의 디자인 자유도가 마음에 드는데 무엇을 포기하는지 몰라 망설이실 수 있습니다. 그럴 때는 사이트로 하는 일과 업데이트 주기부터 정리하시면 됩니다. 엔소프 컴퍼니는 그 내용을 듣고 Framer와 Webflow, 워드프레스, Next.js 가운데 맞는 구축 방식을 추천합니다. Next.js는 개발자가 코드를 작성해 사이트를 만드는 방식입니다. 고객이 선택한 방식으로 사이트를 개발해 드리며 어디까지 맡길지는 고객이 정하시면 됩니다.

기획부터 개발까지 엔소프 컴퍼니 한 곳에서 진행합니다. 그래서 정보구조 기획과 화면 디자인, 개발과 공개를 업체별로 따로 조율하실 필요가 줄어듭니다.

사이트를 연 뒤에는 홈페이지로 들어온 문의와 신청을 직원이 분류합니다. 같은 내용을 기록 문서에 다시 옮겨 적는 일도 반복됩니다. 고객이 원하실 경우 엔소프 컴퍼니는 이 일을 AI 에이전트가 수행하도록 개발해 드립니다. AI 에이전트는 정해 둔 기준대로 반복 업무를 사람 대신 처리하는 프로그램입니다.

쓰시던 프로그램은 그대로 두고 사이만 잇습니다. 그래서 같은 내용을 두 번 옮겨 적는 일이 없어지고 문의와 신청은 들어오는 대로 종류별로 나뉩니다. 한꺼번에 맡기실 필요는 없고 옮겨 적는 일 하나부터 시작하셔도 됩니다. 옮겨 적고 분류하던 직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 배포된 웹사이트와 콘텐츠 관리 환경, 계정을 넘겨드립니다. 배포는 완성한 사이트를 방문자가 볼 수 있게 인터넷에 올리는 일입니다. 자동화를 맡기셨다면 동작하는 자동화 시스템도 함께 받으실 수 있습니다.

사이트로 하려는 일과 수정 주기를 알려 주시면 됩니다.

프로젝트 문의하기

저녁 업무를 마치고 나서야 챗봇이 낮 동안 답한 문의 목록을 여는 날이 있으신가요? 챗봇은 손님의 질문에 답을 마쳤지만 그 내용을 표 문서에 옮겨 적고 담당자에게 전달하는 일은 아직 남아 있습니다. 퇴근이 늦어지는 원인이 답변 뒤의 일이라면 AI 에이전트를 알아볼 만합니다.

AI 에이전트(스스로 업무를 수행하는 시스템)는 대답으로 끝나는 챗봇과 달리 답변 뒤의 업무까지 맡을 수 있습니다. 챗봇을 이미 쓰는 회사에 AI 에이전트가 따로 필요한지는 직원이 답변 뒤에 반복하는 업무가 있는지로 판단할 수 있습니다.

챗봇이 답한 뒤의 일은 누가 합니까?

챗봇이 답변을 마치면 그 문의를 처리하는 일은 직원에게 남을 수 있습니다. 답변은 바로 나가더라도 문의 내용이 담당자에게 전달되고 기록으로 남기까지는 사람이 움직여야 하기 때문입니다. 학원의 상담 문의와 병원의 예약 문의, 제조 회사의 견적 문의가 그런 예입니다.

직원이 챗봇 뒤에서 반복하는 일은 다음과 같은 모양입니다.

1. 직원이 챗봇이 받은 문의 내용을 표 문서에 다시 옮겨 적습니다.

2. 직원이 문의 종류를 읽고 맞는 담당자에게 전달합니다.

3. 담당자가 처리 결과를 기록하고 손님에게 후속 안내를 보냅니다.

옮겨 적기와 전달, 기록은 한 건이면 금방 끝납니다. 하지만 문의가 몰리는 날에는 직원의 본업 시간이 그 일에 쓰이고 손님 응대와 상담에 쓸 시간이 그만큼 줄어듭니다. 옮겨 적는 동안 직원의 본업은 잠시 멈춥니다.

바쁜 주에는 전달이 늦어지고 기록이 빠지기도 합니다. 전달이 늦어진 문의는 손님이 처리 결과를 기다리는 시간이 길어지는 일로 이어집니다. 손님에게는 답변이 나갔는지보다 문의가 처리됐는지가 더 중요한 때가 있습니다.

고객 회사에 반복 업무가 있는지는 직원에게 지난주 한 일을 물으면 확인됩니다. 챗봇 답변 뒤에 따로 처리한 문의를 종류별로 적어 달라고 하시면 반복되는 일이 눈에 보입니다. 챗봇을 도입한 뒤에도 직원의 반복 업무가 그대로라면 줄어든 일은 답변 한 단계뿐입니다.

AI 에이전트는 챗봇과 무엇이 다릅니까?

IBM(IT·AI 서비스 기업)은 AI 에이전트를 업무 흐름을 직접 설계하고 작업을 스스로 수행하는 시스템이라고 정의합니다. 문의 접수 업무라면 접수 내용을 읽고 맞는 담당자 앞으로 전달하는 일까지 AI 에이전트가 수행하도록 만들 수 있습니다. 어떤 업무를 맡길지는 고객이 먼저 정하고 AI 에이전트는 정해진 업무를 수행합니다.

IBM은 도구 사용과 기억과 추론을 에이전트와 챗봇을 구분하는 기준으로 듭니다. 세 기능이 없는 챗봇은 비에이전트형 챗봇(에이전트가 아닌 챗봇)이라고 부릅니다. 도구는 일을 하는 데 쓰는 프로그램이고 기억은 앞서 나눈 내용을 보관하는 기능이며 추론은 주어진 내용에서 다음에 할 일을 따지는 기능입니다. 쓰시는 챗봇에 세 기능이 있는지는 챗봇 제공 업체의 기능 설명서에서 확인할 수 있습니다.

Anthropic(AI 모델 개발사)은 에이전트를 AI가 작업 방식과 도구 사용을 스스로 정하는 시스템이라고 정의합니다. 사람이 미리 정해 둔 순서대로 AI와 도구를 움직이는 시스템은 에이전트와 구분합니다. 둘 다 AI를 쓰지만 작업의 순서를 정하는 쪽이 사람이냐 AI냐가 다릅니다.

챗봇과 AI 에이전트의 차이는 답변 뒤의 업무를 사람이 하느냐 시스템이 수행하느냐에 있습니다. 정해 둔 순서대로 움직이는 시스템도 업무를 처리하므로 어느 쪽이 맞는지는 업무의 성격에 따라 달라집니다. 반복되는 순서가 분명한 업무인지 상황에 따라 판단이 필요한 업무인지가 그 기준입니다.

우리 회사에는 챗봇으로 충분합니까 아니면 AI 에이전트가 맞습니까?

Anthropic은 AI를 쓸 때 가능한 한 가장 단순한 해법부터 찾고 필요할 때만 구조를 복잡하게 하라고 권고합니다. 챗봇이 문의에 답하고 있고 답변 뒤에 사람이 할 일이 없다면 지금의 구성이 가장 단순한 해법일 수 있습니다. AI 에이전트는 그 구성으로 해결되지 않는 업무가 남을 때 검토할 대상입니다.

Anthropic은 에이전트 방식이 작업 성능을 높이는 대신 응답 속도와 비용 부담이 생기는 경우가 많다고 설명합니다. 답변만으로 끝나는 업무까지 AI 에이전트로 바꾸면 손님이 답을 기다리는 시간과 이용 비용이 늘 수 있습니다. 그래서 AI 에이전트를 붙일 업무는 직원 시간이 크게 줄어드는 업무로 좁힐 수 있습니다.

AI 에이전트를 검토할 만한 회사는 다음 조건에 가까운 회사입니다.

1. 같은 작업을 매주나 매달 직원이 손으로 반복하는 회사입니다.

2. 도입한 시스템이 있는데 실제로는 쓰이지 않는 회사입니다.

3. 사람을 더 뽑을지 시스템을 만들지 판단이 서지 않는 회사입니다.

도입한 챗봇이 쓰이지 않는 데에는 챗봇과 업무 사이의 연결이 비어 있는 상황이 있을 수 있습니다. 챗봇이 받은 문의를 직원이 다른 화면에서 다시 입력해야 하면 직원이 챗봇 화면을 열지 않을 수 있습니다. 이런 상황은 챗봇과 업무 사이에 연결이 비어 있는지 먼저 확인할 수 있습니다.

반대로 손님의 질문이 정해진 몇 가지로 좁혀지고 답변 뒤에 사람이 할 일이 없다면 챗봇만으로 충분할 수 있습니다. 답변만으로 끝나는 업무에는 챗봇이면 되고 답변 뒤에 사람이 반복하는 업무가 있을 때 AI 에이전트를 알아볼 만합니다. 챗봇을 빼고 AI 에이전트를 고르는 문제가 아니라 업무마다 맞는 방식을 따로 판단하는 문제입니다.

AI 에이전트를 도입하면 고객은 무엇을 정해야 합니까?

고객이 처음에 정하실 일은 맡길 업무와 처리 기준과 사람이 확인하는 지점입니다. 기준이 한 번 정해지면 같은 업무를 수행할 때마다 설명을 처음부터 반복하실 필요가 없습니다. 버튼 하나로 알아서 움직이는 모습에 가깝게 만들려면 고객이 정하는 기준이 구체적일수록 맡길 업무의 범위가 분명해집니다.

고객이 정하실 내용은 다음과 같습니다.

1. 고객이 맡길 업무를 한 가지 정합니다. 직원이 답변 뒤에 반복하는 일을 골라 한 가지로 시작할 수 있습니다.

2. 고객이 문의를 어떤 종류로 나누고 누구에게 전달할지 처리 기준을 정합니다.

3. 고객이 처리 결과를 확정하기 전에 직접 보고 승인할지 믿고 맡길지 정합니다.

도입은 업무 한 가지로 시작해 범위를 넓히는 순서로 진행할 수 있습니다. 첫 업무의 처리 결과가 기준에 맞는지 확인한 뒤에 다음 업무를 추가하면 영향을 받는 업무가 한 가지로 한정됩니다. 업무를 늘리는 속도는 확인 결과를 보고 고객이 정하시면 됩니다.

기준을 정할 때 필요한 자료는 직원이 지금 쓰는 문의 기록과 챗봇의 답변 내용입니다. 이미 쌓인 기록을 종류별로 나눠 보면 어떤 문의가 어느 담당자에게 가는지 기준이 눈에 보입니다. 업무마다 예외가 있다면 예외도 기준에 함께 적어 둘 수 있습니다.

맡길 업무를 한 가지로 정하기 어렵다면 직원이 하루 동안 한 일을 시간 순서로 적어 보는 방법이 있습니다. 같은 일이 여러 번 반복되는 모습이 보이면 맡길 후보가 드러납니다. 후보가 여럿이면 직원 시간이 많이 드는 일부터 검토할 수 있습니다.

도입한 뒤에는 무엇을 보고 잘 쓰이는지 확인합니까?

도입 뒤 확인은 도입 전에 적어 둔 기록과 도입 뒤 기록을 같은 항목으로 비교하는 방식으로 진행합니다. 비교할 항목은 다음과 같습니다.

1. 직원이 같은 업무에 쓰는 시간을 도입 전에 적어 둔 기록과 비교합니다.

2. 처리 결과 목록에서 몇 건을 골라 문의 종류와 전달 대상이 정한 기준과 맞는지 읽어 봅니다. 바쁜 날에 빠진 건이 없는지도 같은 목록에서 확인합니다.

3. 손님이 답을 받는 시간이 도입 전보다 길어지지 않았는지 챗봇 대화 기록의 시각으로 확인합니다.

4. 반복 업무에 쓰던 인건비 부담이 줄었는지 직원의 근무 시간으로 비교합니다.

도입 전에 직원이 쓰던 시간을 적어 두어야 도입 뒤에 줄었는지 비교할 수 있습니다. 비교할 기록이 없으면 느낌으로만 판단하게 되어 결과를 설명하기 어렵습니다. 도입을 결정하기 전에 일정 기간의 기록을 미리 모아 두는 방법이 있습니다.

처리 결과를 직접 보고 승인하는 방식을 고르셨다면 승인 목록에서 직원이 수정한 건이 줄어드는지도 볼 수 있습니다. 수정한 건이 줄면 기준이 업무와 맞아 가고 있다는 신호일 수 있습니다. 수정이 계속 나오는 항목은 그 항목의 기준을 다시 정하는 근거로 쓸 수 있습니다.

승인 없이 맡기는 방식으로 바꿀지는 승인 목록의 수정 기록을 보고 고객이 정하시면 됩니다. 수정이 거의 나오지 않는 업무부터 믿고 맡기고 수정이 남아 있는 업무는 승인 단계를 유지하는 선택도 가능합니다. 처리 결과 목록과 승인 목록은 사람이 확인하는 관리자 화면에서 볼 수 있게 만들 수도 있습니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없고 AI 에이전트에 맡길 업무가 얼마나 넓은지에 따라 범위가 달라집니다. 범위를 정하는 기준은 다음과 같습니다.

1. 맡길 업무의 수: 문의 전달 한 가지인지 정산과 보고서까지 포함하는지

2. 연결할 프로그램의 종류: 쓰시는 챗봇 외에 서로 이어야 하는 업무 프로그램이 몇 가지인지

3. 처리 기준의 준비 정도: 기준이 이미 문서로 있는지 업무 흐름을 확인하는 일부터 필요한지

4. 사람이 확인하는 화면: 처리 결과를 보고 승인하는 관리자 화면이 필요한지

맡길 업무와 연결할 프로그램, 처리 기준, 승인 화면 필요 여부를 알려 주시면 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의에서 인계까지의 순서는 다음과 같습니다.

1. 문의를 남겨 주시면 쓰시는 챗봇과 직원이 답변 뒤에 반복하는 업무를 중심으로 상담합니다.

2. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보고 진행할지는 고객이 정하시면 됩니다.

3. 진행하시기로 하면 정해진 범위의 자동화를 제작합니다.

4. 프로젝트를 마치면 고객이 직접 쓰실 수 있도록 자동화 장치와 계정을 전달합니다.

그래서 지금 챗봇에 AI 에이전트를 더해야 합니까?

업무의 처리 기준을 문장으로 적을 수 있고 직원이 그 업무를 반복하고 있다면 알아볼 만합니다. 판단이 필요한 예외가 잦은 업무는 직원이 계속 맡고 기준이 분명한 업무부터 AI 에이전트에 맡기는 순서로 시작할 수 있습니다.

엔소프 컴퍼니는 챗봇이 답한 뒤의 업무에 맞춘 자동화를 AI 에이전트로 개발해 드립니다

쓰시는 챗봇이 대답만 하고 그 뒤의 업무가 직원에게 남아 있다면 AI 에이전트로 그 업무를 이어서 처리하게 만들 수 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 챗봇이 답한 뒤의 업무를 수행하는 AI 에이전트를 개발해 드립니다. 답변 뒤의 업무 가운데 어느 단계까지 맡길지는 고객이 정하시면 됩니다.

맡길 업무가 아직 정해지지 않았다면 AX 진단(업무 자동화 전환 진단)부터 시작하는 방식도 있습니다. 엔소프 컴퍼니가 업무 과정을 따라가며 반복되는 구간을 찾아 자동화할 수 있는 업무를 구분하고 실행 우선순위를 보고서에 담습니다. 진단부터 하실지 개발부터 하실지는 고객이 정하시면 됩니다.

개발은 대상 업무 확정과 처리 규칙 정의, 프로그램 연결, 실제 자료로 하는 확인까지 엔소프 컴퍼니 한 곳에서 진행합니다. 완성된 모습은 다음과 같습니다.

1. 쓰시던 챗봇과 업무 프로그램은 그대로 두고 서로 이어집니다.

2. 챗봇이 받은 문의를 표 문서에 다시 옮겨 적는 일이 사라집니다.

3. 챗봇이 받은 문의는 종류별로 나뉘어 맞는 담당자 앞으로 전달됩니다.

4. 문의 처리 내용을 모아 매달 손으로 만들던 보고서가 자동으로 만들어집니다.

네 가지를 한 번에 하실 필요는 없고 한 가지부터 시작하는 방식도 가능합니다. 옮겨 적고 분류하고 보고서를 만들던 직원의 시간과 인건비 부담이 줄어듭니다. 그 시간은 손님 응대와 상담에 쓰실 수 있습니다.

프로젝트를 마치면 동작하는 자동화 시스템과 운영 절차 문서, 계정을 고객에게 넘겨드립니다.

지금 쓰시는 챗봇이 답한 뒤에 직원이 옮겨 적거나 전달하는 일이 무엇인지 알려 주시면 됩니다.

프로젝트 문의하기

월요일 아침 회의 전에 노션을 엽니다. 프로젝트 페이지에서 진행 상황을 보고 고객 목록에서 새 문의를 확인하고 일정 보드에서 밀린 일을 찾습니다. 페이지마다 정리는 잘 되어 있는데 회사 전체가 지금 어떤 상태인지는 머릿속에서 직접 합쳐야 합니다.

노션으로 충분한지 별도 대시보드가 필요한지는 팀 규모만으로 정해지지 않습니다. 대시보드는 목표를 이루는 데 가장 중요한 정보를 그림과 표로 보여 주는 화면입니다. 노션이 어디까지 해 주고 어디부터 한계가 되는지 알면 도입 여부를 차분히 판단하실 수 있습니다.

노션은 잘 정리되어 있는데 왜 회의 전에 숫자를 다시 맞추게 됩니까?

고객이 시공 회사를 운영하신다고 해 보겠습니다. 영업 담당은 고객 목록에 문의를 적고 현장 팀장은 일정 보드에 공정을 올리며 경리 담당은 입금 내역을 별도 페이지에 남깁니다. 각자 맡은 페이지는 최신 상태로 유지하고 있습니다.

회의 전에 고객이 알고 싶으신 것은 진행 중인 현장 가운데 일정이 밀린 곳과 의뢰인 입금이 늦어진 곳입니다. 두 정보는 일정 보드와 입금 페이지에 나뉘어 있어서 직원에게 따로 물어야 맞출 수 있습니다. 답을 받아 한 장으로 합치는 동안 회의 시간이 다가옵니다.

팀이 작을 때는 고객이 업무를 직접 알고 계셔서 이런 확인이 필요하지 않습니다. 팀이 커지면 고객이 열어 본 적 없는 페이지가 생기고 현황을 맞추는 시간이 길어집니다. 팀이 커질수록 페이지마다 최신 상태인데도 회사 전체의 현황을 보여 주는 곳은 없는 상태가 됩니다.

학원도 같은 일을 겪습니다. 상담 신청과 수강생 출결, 수납이 각각 다른 페이지에 쌓이기 때문입니다. 원장이 이번 달 등록으로 이어진 상담이 얼마나 되는지 보려면 상담 페이지와 수납 페이지를 번갈아 열어 대조해야 합니다.

홈페이지를 운영 중이라면 한 가지가 더 있습니다. 홈페이지로 들어온 문의를 직원이 노션 표에 옮겨 적고 있다면 옮기는 시점에 따라 현황 숫자가 달라집니다. 같은 숫자를 두 곳에 적는 일이 늘수록 어느 쪽이 맞는지 따져 보는 일도 늘어납니다.

노션 데이터베이스를 연결했는데도 현황이 한 번에 모이지 않는 이유는 무엇입니까?

업무 종류마다 데이터베이스를 따로 만들어 두었기 때문일 수 있습니다. 데이터베이스는 노션에서 고객 목록이나 일정처럼 같은 형식의 정보를 표로 쌓아 두는 기능입니다. 고객 목록과 프로젝트, 입금 내역을 각각 만들었다면 서로 떨어진 표가 각각 생깁니다.

떨어진 표를 잇는 기능이 관계 속성(relation)입니다. 관계 속성은 서로 다른 데이터베이스의 항목끼리 관계를 표현하는 기능이어서 고객 항목에 그 고객의 프로젝트를 연결해 둘 수 있습니다. 연결해 두면 표를 오가며 찾는 수고는 줄어듭니다.

연결된 항목의 값을 읽어 오는 속성이 롤업(rollup)입니다. 롤업은 관계로 바로 연결된 페이지의 일반 속성과 수식만 읽을 수 있고 다른 롤업은 읽지 못합니다. 읽을 수 있는 범위가 한 단계로 정해져 있다는 뜻입니다.

고객에서 프로젝트로 이어지고 프로젝트에서 업무로 이어지는 구조를 생각해 보겠습니다. 고객별 지연 업무를 보려면 프로젝트에서 업무 숫자를 먼저 모으고 그 값을 고객 항목에서 다시 읽어야 합니다. 고객 항목은 프로젝트의 롤업 값을 읽지 못하므로 다른 방법이 필요해집니다.

숫자가 노션 밖에 있으면 사정이 더 달라집니다. 회계 프로그램이나 홈페이지 관리자 화면에 쌓이는 숫자는 노션 표에 옮겨 적어야 현황에 들어옵니다. 노션 안에서 바로 연결된 한 단계까지는 숫자를 모을 수 있지만 여러 단계로 이어진 숫자와 노션 밖의 숫자는 롤업만으로 모으지 못합니다.

대시보드가 필요한지는 어떤 순서로 판단합니까?

노션 안에서 먼저 대시보드를 만들어 보고 회의 질문에 답이 나오는지 확인하는 순서입니다. 노션도 대시보드를 지원하기 때문에 별도 개발 전에 가능한 범위를 직접 볼 수 있습니다.

노션은 여러 데이터베이스의 차트를 한 페이지에 모아 대시보드를 만들 수 있습니다. 대시보드 보기에는 차트와 표, 보드, 캘린더, 타임라인 같은 위젯을 한 화면에 배치할 수 있으므로 판단은 대시보드 보기로 어디까지 되는지 확인한 뒤에 시작합니다.

1. 회의에서 고객이 묻는 현황 질문을 종이에 적습니다. 진행 중인 건, 늦어진 건, 새로 들어온 문의 같은 질문입니다.

2. 질문마다 답이 들어 있는 데이터베이스를 표시합니다.

3. 노션 대시보드 보기에 위젯을 배치하고 질문마다 답이 나오는지 봅니다.

4. 답이 나오지 않는 질문은 원인을 적습니다. 숫자가 노션 밖에 있는지 연결 단계가 여러 겹인지 입력이 늦는지를 구분합니다.

노션 대시보드 보기로 회의 질문에 답이 나오는지 먼저 확인하면 별도 대시보드가 필요한지 근거를 갖고 판단할 수 있습니다. 질문 전부에 답이 나온다면 노션에서 멈춰도 됩니다.

원인이 입력이 늦는 데 있다면 대시보드보다 입력 담당과 입력 시점을 정하는 일이 먼저입니다. 원인이 노션 밖의 숫자나 여러 겹의 연결에 있다면 노션 화면을 다듬어도 풀리지 않을 수 있습니다.

대시보드에 올릴 숫자는 무엇을 기준으로 정합니까?

화면을 만들기 전에 정해 둘 것은 올릴 숫자의 종류와 숫자의 기준, 숫자를 보는 사람입니다. 노션 대시보드를 쓰든 별도 대시보드를 만들든 같은 순서로 정하시면 됩니다.

1. 올릴 숫자의 종류: 전략 대시보드는 사업 전체를 조망해 조직의 전반적인 상태를 한눈에 파악하게 해 주는 대시보드입니다. 대표용 화면을 이렇게 만들 생각이라면 부서별 세부 숫자보다 회사 전체를 대표하는 숫자를 고릅니다.

2. 숫자의 기준: 「진행 중」이 계약한 시점부터인지 착공한 시점부터인지를 적어 둡니다. 기준이 부서마다 다르면 같은 이름의 숫자가 서로 다른 값으로 보고됩니다.

3. 숫자를 보는 사람: 대표만 보는 숫자와 팀장이 보는 숫자, 직원이 보는 숫자를 나눕니다. 입금 내역처럼 일부 직원만 봐야 하는 정보가 있는지도 이때 확인됩니다.

「진행 중」 같은 말의 뜻을 먼저 정해 두어야 영업팀과 현장팀이 같은 숫자를 보고 회의합니다. 기준이 문서로 남아 있으면 담당자가 바뀌어도 숫자의 뜻이 달라지지 않습니다.

기준을 정하다 보면 지금 아무도 기록하지 않는 숫자가 드러나기도 합니다. 그 숫자를 새로 기록할지 화면에서 뺄지는 고객이 정하시면 됩니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없습니다. 아래 항목에 따라 범위가 달라지기 때문에 상담 후에 견적으로 안내합니다.

1. 올릴 숫자가 얼마나 많은지: 회사 전체 숫자만 보는지 부서별 상세까지 보는지

2. 숫자가 쌓이는 곳: 노션만인지 회계 프로그램이나 홈페이지 관리자 화면까지 포함하는지

3. 화면을 보는 사람: 대표만 보는지 팀장과 직원도 보는지, 사람마다 보는 숫자가 다른지

4. 이상 알림: 정해 둔 범위를 벗어난 숫자를 알아차리는 규칙이 필요한지

5. 숫자 기준의 정리 정도: 지표 정의가 이미 있는지 처음부터 정해야 하는지

이 항목을 알려 주시면 범위를 잡을 수 있고 견적은 그 범위에 맞춰 안내합니다.

문의하면 어떤 순서로 진행됩니까?

문의에서 인계까지 다섯 단계로 진행합니다.

1. 고객이 문의를 남깁니다.

2. 상담에서 현재 쓰시는 도구와 보고 싶은 숫자를 듣습니다.

3. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

4. 진행하시기로 하면 대시보드와 필요한 자동화를 제작합니다.

5. 프로젝트를 마치면 장치와 계정을 고객에게 넘겨드립니다.

그래서 노션으로 충분합니까 별도 대시보드가 필요합니까?

현황을 만드는 데 걸리는 시간이 현황을 보고 판단하는 시간보다 길어졌거나 문제를 회의에서야 알게 된다면 별도 대시보드를 알아볼 만합니다. 반대로 노션 대시보드 보기로 회의 질문에 답이 나오고 입력 담당이 정해져 있다면 노션만으로 충분합니다. 팀이 커지는 속도에 따라 그 판단은 달라질 수 있으니 분기마다 한 번씩 같은 질문으로 다시 살펴보시면 됩니다.

엔소프 컴퍼니는 한눈에 보이지 않는 운영 현황에 맞춘 대시보드를 AI 에이전트로 개발해 드립니다

페이지 정리를 다 했는데도 운영 현황이 대시보드 한 화면에 모이지 않는다면 숫자를 모아 옮기는 일을 사람이 계속 하고 있을 수 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 그 일을 AI 에이전트가 수행하도록 개발해 드립니다. AI 에이전트는 정해 둔 규칙대로 반복 업무를 수행하는 프로그램입니다. 어디까지 맡길지는 고객이 정하시면 됩니다.

운영 대시보드는 무엇을 보고 무엇으로 판단할지 지표부터 정의한 뒤 관리자 화면까지 개발하는 일입니다. 기획부터 개발까지 한 곳에서 진행하므로 지표 정의와 화면 제작을 업체별로 나눠 조율하실 필요가 없습니다.

매달 손으로 만들던 정산과 보고서는 정해 둔 규칙대로 자동으로 만들어지고 홈페이지로 들어온 신청과 접수는 들어오는 대로 종류별로 분류됩니다. 필요하시면 관리자 화면과 입력 폼도 개발합니다.

숫자를 옮기고 합치던 직원의 시간과 인건비가 줄어듭니다. 한꺼번에 하실 필요는 없고 보고서 하나부터 시작하는 방식도 됩니다.

프로젝트를 마치면 지표 정의 문서와 동작하는 대시보드, 이상 감지 규칙 정의서를 넘겨드립니다. 자동화를 맡기셨다면 동작하는 자동화 시스템과 계정도 넘겨드립니다.

지금 현황 회의 전에 손으로 합치고 계신 숫자가 무엇인지 알려 주시면 됩니다.

프로젝트 문의하기

개발사 견적서에 디자인 항목이 있는데 화면 설계 항목이 또 따로 있을 수 있습니다. 디자인이 곧 화면이라고 생각하셨다면 같은 일에 비용을 두 번 청구하는 것처럼 보입니다. 그래서 화면 설계는 빼고 디자인 시안부터 받아 보고 싶어지는 고객도 계십니다.

디자인 시안은 눈으로 바로 볼 수 있어서 마음에 드는지 판단하기 쉽습니다. 다만 화면에 무엇을 넣을지 정하기 전에 시안을 받으면 개발 도중에 시안을 다시 확인해야 하는 일이 생길 수 있습니다. 시안이 마음에 들어도 그 화면에 들어갈 내용이 정해지지 않았다면 확인할 일이 남아 있습니다.

디자인 시안부터 받으면 개발 도중에 어떤 일이 생깁니까?

학원을 운영하신다고 하고 수강 신청 사이트를 맡기면서 디자인 시안부터 받으셨다고 하겠습니다. 첫 화면 시안은 색과 사진이 마음에 들어 바로 승인하셨습니다. 그런데 수강 신청 화면에서 무엇을 어떤 순서로 물어볼지는 아직 정하지 않으신 상태였습니다.

개발이 시작되자 디자인 시안에 없는 화면이 필요해졌습니다. 학부모 정보를 입력하는 화면과 상담 예약 화면, 결제가 끝난 뒤의 안내 화면이 그 예입니다. 디자인 시안에는 첫 화면과 신청 화면만 있었으므로 나머지 화면은 디자인을 새로 요청해야 합니다.

신청 화면에 넣을 항목이 바뀌는 일도 있습니다. 항목이 늘면 화면 길이와 버튼 위치가 달라지므로 이미 승인한 시안을 다시 확인해야 합니다. 그 사이에 개발 일정이 늦어질 수 있습니다.

이런 장면에서 시안이 잘못 그려진 것은 아닙니다. 시안은 정해진 내용을 완성된 모습으로 보여 주는 것이고 무엇을 넣을지 정하는 일은 따로 필요했던 것입니다. 정해진 내용 없이 디자인 시안이 먼저 나오면 시안과 내용을 맞추는 일을 고객과 개발사가 개발 도중에 하게 됩니다.

디자인 시안과 화면 설계는 무엇이 다릅니까?

디자인 시안은 완성된 화면이 어떻게 보일지 보여 주는 움직이지 않는 이미지이며 업계에서는 목업이라고 부릅니다. 화면 설계는 화면의 뼈대를 낮은 완성도로 그린 설계도이며 업계에서는 와이어프레임이라고 부릅니다. 개발사가 영어 이름으로 말하더라도 같은 뜻으로 읽으시면 됩니다.

순서로는 화면 설계가 먼저이고 디자인 시안이 나중입니다. 뼈대가 나온 뒤에 완성된 모습을 그리는 순서입니다. 디자인 시안부터 받으면 화면 설계와 디자인 시안의 순서가 거꾸로 시작됩니다.

화면 설계는 페이지에 무엇을 어떤 순서로 넣을지가 아직 정해지지 않았을 때 그리는 것입니다. 넣을 내용과 순서가 정해지지 않았다면 화면 설계를 그릴 단계에 있는 것입니다. 그 단계를 건너뛰고 시안을 받으면 시안이 아직 없는 내용 위에 그려집니다.

디자인 시안은 제품의 시각 디자인이 맞는지 확인하는 데 씁니다. 화면 설계는 내용과 순서를 정하는 데 쓰고 디자인 시안은 모습을 확인하는 데 쓰므로 두 일은 목적이 다릅니다. 개발사가 두 일을 견적서에 따로 적는 데에는 이런 이유가 있을 수 있습니다.

견적서의 화면 설계 항목은 어떻게 확인합니까?

견적서에서 화면 설계라는 이름의 항목이 있는지 찾는 일부터 시작하시면 됩니다. 항목이 있든 없든 개발사에는 아래 순서로 물어보시면 됩니다.

1. 화면 설계 항목이 있는지 묻습니다. 디자인 항목 안에 화면 구성이 들어 있는지도 함께 묻습니다.

2. 화면 설계 항목이 있다면 어느 화면까지 포함하는지 묻습니다. 손님이 쓰는 신청 화면만인지, 직원이 신청 내역을 보는 관리자 화면까지인지 나누어 달라고 하시면 됩니다.

3. 화면 설계의 결과물이 무엇인지 묻습니다. 화면 설계서 같은 문서로 남는지 디자인 시안 안에만 있는지에 따라 나중에 개발사를 바꿀 때 쓸 수 있는지가 달라집니다.

화면 설계 항목이 있는지와 그 항목이 어느 화면까지 포함하는지가 견적서에서 확인할 핵심입니다. 항목이 없다면 디자인 견적이 화면 구성까지 포함하는지 답을 받아 두시면 됩니다. 포함한다는 답을 들으셨다면 어떤 문서로 확인할 수 있는지도 함께 물으시면 됩니다.

디자인과 화면 설계 견적이 나란히 있다면 항목마다 결과물이 무엇인지 비교하시면 됩니다. 두 항목의 결과물이 같은 시안이라면 같은 일이 두 번 적혔는지 개발사에 물어보셔도 됩니다.

질문은 견적서를 받은 뒤가 아니어도 됩니다. 견적서를 받기 전이라면 문의 단계에서 같은 순서로 물어보실 수 있습니다.

화면 설계를 시작하기 전에 어떤 내용을 알려 주시면 됩니까?

화면 설계는 초기 단계에서 회사 안의 의견을 모아 디자인 방향을 정하는 데 쓰입니다. 그래서 아래 내용을 알려 주시면 의견을 모으는 일이 빨라집니다.

1. 화면을 쓰는 사람입니다. 손님인지 직원인지, 둘 다인지 알려 주시면 됩니다.

2. 화면에서 하려는 일입니다. 예약이나 신청, 주문처럼 쓰는 사람이 끝내야 할 일을 말합니다.

3. 화면에 들어가야 할 내용입니다. 안내 문구나 접수 항목처럼 빠지면 안 되는 내용을 말합니다.

4. 화면을 보고 의견을 낼 사람입니다. 회사 안에서 누구의 확인을 거쳐야 하는지 알려 주시면 됩니다.

네 가지가 정해지지 않았어도 화면 설계를 시작하실 수 있습니다. 정해지지 않은 부분을 알려 주시면 그 부분은 화면 설계 과정에서 정하게 됩니다.

의견을 낼 사람이 여러 명인데 디자인 시안이 나온 뒤에야 각자 의견을 내면 시안을 다시 확인하는 일이 생길 수 있습니다. 뼈대를 그리는 단계에서 의견을 받아 두면 완성된 모습을 확인하는 단계에서 바뀌는 부분이 줄어듭니다. 이 과정에 필요한 시간은 화면의 종류와 양에 따라 다릅니다.

비용은 무엇에 따라 달라집니까?

금액은 조건에 따라 다르며 아래 항목이 범위를 정하는 기준입니다.

1. 필요한 화면의 종류와 양: 손님이 쓰는 화면만인지 관리자 화면까지인지

2. 화면을 쓰는 사람의 종류: 회원과 직원처럼 구분되는 사람이 많은지

3. 정리된 요구사항이 있는지: 만들 기능을 적은 문서가 이미 있는지

4. 화면 설계서를 어디에 쓸지: 개발까지 맡기실지 다른 개발사에 전달하실지

5. 참고할 기존 자료가 있는지: 지금 쓰시는 사이트나 서비스가 있는지

다섯 가지를 알려 주시면 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의에서 결과물 인계까지의 순서는 다음과 같습니다.

1. 문의를 남기시면 위의 다섯 가지를 중심으로 상담합니다.

2. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

3. 진행하시기로 하면 화면 설계를 비롯한 작업을 제작합니다.

4. 프로젝트를 마치면 만든 결과물과 계정을 고객에게 넘겨드립니다.

그래서 디자인 시안은 화면 설계 뒤에 받아야 합니까?

화면에 들어갈 내용과 순서가 이미 문서로 정해져 있다면 디자인 시안부터 받으셔도 됩니다. 화면에 들어갈 내용과 순서가 정해지지 않았다면 견적서에 화면 설계 항목이 있는지부터 물어볼 만합니다. 화면 설계서가 문서로 남으면 개발사를 바꾸더라도 같은 화면 목록으로 견적을 다시 받아 비교할 수 있습니다.

엔소프 컴퍼니는 디자인 시안 전에 필요한 화면 설계를 하고 반복 업무는 AI 에이전트로 개발해 드립니다

디자인 시안부터 받는 방식이 걱정되시는 고객께는 엔소프 컴퍼니가 기획·설계에서 정보구조와 화면 설계를 맡습니다. 기획부터 개발까지 한 곳에서 진행하므로 고객이 정하신 내용을 화면 설계서로 남기고 그 문서를 기준으로 개발합니다.

화면 설계에서 신청 화면과 접수 화면이 정해지면 접수된 내용을 분류하고 매달 보고서를 만드는 반복 업무도 눈에 들어옵니다. 고객이 원하실 경우 엔소프 컴퍼니는 이 반복 업무를 AI 에이전트가 수행하도록 개발해 드립니다. AI 에이전트는 고객이 정한 기준대로 접수 분류와 보고서 작성 같은 일을 사람 대신 처리하는 프로그램입니다. 접수 분류와 보고서 작성 가운데 무엇을 AI 에이전트에게 맡길지는 고객이 정하시면 됩니다.

신청 화면과 접수 화면이 정해진 뒤 자동화를 맡기시면 이렇게 달라집니다.

1. 쓰시던 도구는 그대로 두고 연결되어 같은 내용을 두 번 옮겨 적는 일이 없어집니다.

2. 신청과 접수는 들어오는 대로 종류별로 나뉩니다.

3. 접수 내역을 모아 매달 직접 만들던 보고서가 정해진 양식대로 자동으로 작성됩니다.

세 가지를 한 번에 다 하실 필요는 없고 하나부터 시작하셔도 됩니다. 옮겨 적고 분류하던 직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 요구사항 정의서와 화면 설계서를 넘겨드립니다. 요구사항 정의서는 만들 기능을 적은 문서이고 화면 설계서는 화면 구성을 그린 문서입니다. 자동화를 맡기셨다면 동작하는 자동화 시스템과 계정도 넘겨드립니다.

지금 만들려는 서비스에서 손님이 가장 먼저 쓰게 될 화면이 무엇인지 알려 주시면 됩니다.

프로젝트 문의하기

개발사가 워드프레스로 만들자고 권하면 안전한 선택처럼 들립니다. 워드프레스는 웹사이트를 만들고 글과 사진을 올릴 수 있게 해 주는 프로그램입니다. 조사 사이트 W3Techs를 2026년 10월 6일에 조회하면 전 세계 웹사이트의 40.1%가 워드프레스를 씁니다. 10곳 중 4곳이라는 숫자는 안심할 이유로 보입니다.

그런데 사이트를 공개한 뒤에 문제가 생기면 누구에게 연락할지 모르는 장면이 있을 수 있습니다. 개발사는 제작을 마쳤다고 답하고 직원은 글을 올리는 방법만 안다고 답합니다. 화면은 멀쩡히 열리는데 관리하는 사람이 없는 상태입니다.

워드프레스를 고른 뒤 관리 업무로 무엇이 남습니까?

워드프레스를 고르고 나면 관리 업무로 설치와 호스팅과 보안 갱신이 남습니다. 설치는 워드프레스 프로그램을 컴퓨터에 올려 사이트로 쓸 수 있게 만드는 일입니다. 호스팅은 사이트 파일을 보관하고 방문자에게 보여 주는 컴퓨터 공간을 빌려 쓰는 일입니다. 보안 갱신은 프로그램 제작사가 내놓는 보안 관련 새 버전을 적용하는 일입니다.

설치와 호스팅과 보안 갱신은 맡는 쪽이 서로 다를 수 있습니다. 설치는 개발사가 하고 호스팅은 고객이 따로 계약한 회사에 있으며 보안 갱신은 아무도 맡지 않은 상태가 생길 수 있습니다. 이런 상태에서는 사이트에 문제가 생겨도 연락할 곳이 한 군데로 정해지지 않습니다.

워드프레스를 많이 쓴다는 사실만으로는 관리 업무를 맡을 사람이 정해지지 않습니다. 사용 비율은 워드프레스를 쓰는 사이트가 그만큼 있다는 사실일 뿐 고객 사이트의 관리 담당은 알려 주지 않습니다. 관리 업무의 담당은 계약과 담당자 지정으로 정해집니다.

병원이 진료 안내 사이트를 공개했다면 진료 시간을 바꾸는 직원은 글만 수정할 뿐 보안 갱신까지 확인하지 않을 수 있습니다. 직원은 글 수정만 자기 업무로 알고 있기 때문입니다. 그러면 보안 갱신은 개발사도 직원도 자기 일로 여기지 않는 일이 됩니다.

관리 담당이 비어 있는 사이트는 왜 생깁니까?

계약이 사이트를 공개하는 데까지만 범위로 정하고 있으면 그 뒤 관리 업무는 누구의 일로도 적히지 않습니다. 개발사는 계약한 범위를 마쳤으므로 범위 밖의 일은 요청을 받아야 시작할 수 있습니다. 고객도 관리 업무가 있다는 사실을 모르면 요청하지 못합니다.

호스팅은 개발사가 아니라 고객 회사 이름으로 따로 계약하는 경우가 있습니다. 호스팅 요금 결제와 연장은 회사 직원이 맡게 되지만 그 직원은 사이트 내용을 모를 수 있습니다. 계약자와 결제 담당이 서로 다르면 요금 연장 시기를 아는 사람이 없을 수도 있습니다.

보안 갱신은 적용해도 화면이 달라지지 않을 수 있습니다. 그래서 사이트가 멀쩡히 열리는 동안에는 해야 할 일이 있다는 사실을 눈으로 확인하기 어렵습니다. 프로그램 제작사가 새 버전을 내놓으면 적용해야 하는 일이므로 사이트를 공개한 뒤에도 이어집니다.

담당 직원이 바뀌면 호스팅 계약자와 로그인 정보를 찾는 일부터 시작해야 합니다. 계약서에 적히지 않은 관리 업무는 누가 맡는지 알 수 없는 일로 남습니다. 담당 이름을 문서에 적어 두면 직원이 바뀌어도 찾아갈 곳이 생깁니다.

개발사에는 관리 업무를 어떻게 물어보면 됩니까?

설치와 호스팅과 보안 갱신을 한 항목씩 나누어 담당 이름을 물으면 답이 구체적으로 나옵니다. 아래 세 가지 질문으로 시작하실 수 있습니다.

1. 설치를 누가 하고 설치한 계정 정보를 누가 받는지 묻습니다.

2. 호스팅 계약자가 누구이고 요금을 누가 내는지 묻습니다.

3. 보안 갱신을 누가 얼마나 자주 적용하는지 묻습니다.

세 질문은 회사 이름이나 사람 이름으로 답이 나옵니다. 이름 없이 말로만 답이 온다면 담당과 적용 간격을 문서로 남겨 달라고 요청하실 수 있습니다.

관리 업무를 회사 직원이 맡기로 했다면 담당 직원의 이름을 문서에 적어 둡니다. 직원이 바뀔 때 로그인 정보를 어디서 넘겨받는지도 같은 문서에 적어 두시면 됩니다.

사이트로 하는 일과 수정 횟수에 따라 관리 업무는 어떻게 달라집니까?

직원이 관리 화면에 들어가는 횟수가 달라지면 관리 업무를 누가 언제 하는지도 달라집니다. 관리 화면은 직원이 글과 사진을 올리고 수정하는 화면입니다. 수정이 잦은 사이트와 드문 사이트를 비교하면 차이가 보입니다.

학원이 매주 시간표와 공지를 바꾸는 사이트라면 직원이 매주 관리 화면에 로그인합니다. 글을 올리는 직원이 여럿이면 누구에게 계정을 줄지도 정해야 합니다. 계정을 받은 직원이 바뀔 때 계정을 정리할 사람도 필요합니다.

제조 회사의 제품 소개 사이트처럼 수정이 드문 곳은 직원이 관리 화면에 들어갈 일이 적습니다. 그러면 보안 갱신을 적용하는 날을 따로 정해 두지 않을 때 적용 시기가 지날 수 있습니다. 직원이 사이트 상태를 볼 계기가 없기 때문입니다.

사이트로 하는 일은 회사 소개인지 예약 접수인지 시공 사례 게시인지처럼 방문자가 사이트에서 하는 일을 말합니다. 수정 횟수는 한 달에 글과 사진을 몇 번 바꾸는지를 말합니다. 사이트로 하는 일과 수정 횟수를 정리해 두면 관리 업무를 개발사에 요청할지 직원이 맡을지 판단할 기준이 생깁니다.

비용은 무엇에 따라 달라집니까?

금액은 사이트의 범위에 따라 달라지므로 상담 뒤 견적으로 안내합니다. 달라지는 기준은 아래와 같습니다.

1. 사이트로 하는 일: 회사 소개만 있는지 예약 접수까지 있는지

2. 수정 횟수: 글과 사진을 바꾸는 횟수

3. 글을 올리는 직원: 직원이 직접 올릴 관리 화면이 필요한지

4. 지금 쓰는 사이트: 새로 만드는지 운영 중인 사이트가 있는지

네 가지를 알려 주시면 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의부터 인계까지 다섯 단계로 진행합니다.

1. 문의를 남기시면 접수 내용을 확인합니다.

2. 상담에서 사이트로 하는 일과 수정 횟수를 듣습니다.

3. 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

4. 진행하시기로 하면 사이트를 기획하고 디자인하고 개발합니다.

5. 제작을 마치면 장치와 계정을 고객에게 인계합니다.

그래서 워드프레스 권유를 받아들여도 됩니까?

설치와 호스팅과 보안 갱신의 담당 이름을 개발사가 답하고 계약서에 적는다면 워드프레스를 검토할 조건은 갖춰진 것입니다. 답이 이름 없이 말로만 오면 담당이 문서로 정해질 때까지 계약을 미루는 방식도 있습니다.

받으신 견적서를 놓고 업체를 고르는 중이라면 같은 질문을 업체마다 하시고 담당 이름이 구체적으로 나오는지 비교하실 수 있습니다.

엔소프 컴퍼니는 워드프레스 설치 뒤 관리 업무에 맞춘 사이트 구축과 글 올리기를 AI 에이전트로 개발해 드립니다

워드프레스를 고른 뒤 관리 업무가 누구에게 남는지 불분명하다면 사이트를 기획하는 단계에서 담당을 적어 둘 수 있습니다. 고객이 원하시면 엔소프 컴퍼니가 사이트의 목적과 수정 횟수를 듣고 맞는 구축 방식을 추천합니다. 구축 방식은 사이트를 만드는 데 쓰는 프로그램의 종류이며 추천한 방식으로 개발해 드립니다. 기획과 디자인, 개발, 공개까지 한 곳에서 진행하므로 업체를 따로 조율하는 부담이 줄어듭니다.

사이트를 공개한 뒤에는 소식과 안내 글을 올리고 문의를 분류하는 일이 반복됩니다. AI 에이전트는 정해 둔 기준대로 반복 업무를 사람 대신 수행하는 프로그램입니다. 고객이 정한 주제의 글은 AI 에이전트가 만들어 사이트에 올립니다. 문의와 신청은 들어오는 대로 종류별로 나뉘며 올리기 전에 직접 보고 승인하는 방식도 고르실 수 있습니다.

한 번에 다 맡기실 필요는 없고 글 올리기나 문의 분류 가운데 하나부터 시작하셔도 됩니다. 글을 올리고 문의를 나누던 직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 공개한 웹사이트와 글을 올리고 관리하는 화면, 계정을 넘겨드립니다. AI 에이전트 개발을 맡기셨다면 글이 올라가는 장치도 함께 넘겨드립니다.

사이트로 하려는 일과 수정 횟수를 알려 주시면 됩니다.

프로젝트 문의하기

저녁 업무를 마치고 나서야 블로그 창을 여는 날이 많으실 것입니다. 주제를 고르고 글을 쓰고 사진을 올리고 나면 밤이 깊어 있습니다. 그렇게 올린 글이 AI 답변에는 한 번도 나오지 않으면 다음 글을 쓸 이유가 줄어듭니다.

ChatGPT처럼 질문을 받으면 웹의 글을 읽어 답을 만들어 주는 AI 서비스를 이 글에서는 AI 답변 엔진이라고 부릅니다. AI 답변 엔진은 글 전체를 통째로 읽지 않고 문단 단위로 잘라 다룹니다. 그래서 문단 하나만 분리해도 뜻이 통해야 그 문단이 답에 쓰이며 이 글에서는 그렇게 쓰이는 일을 인용이라고 부릅니다. 소제목과 문단 첫 문장을 어떻게 쓰느냐가 그 출발점입니다.

AI 답변에 나오게 하려고 글을 직접 수정하면 어떤 일이 따라옵니까?

글 한 편마다 소제목과 문단 첫 문장을 다시 읽고 수정하는 일이 따라옵니다. 이미 올린 글이 많을수록 같은 점검을 글 수만큼 되풀이해야 합니다. 새 글을 쓸 때도 같은 기준을 지키려면 쓰는 사람이 그 기준을 계속 기억해야 합니다.

수정할 내용은 다음 네 가지입니다.

1. 소제목을 손님이 실제로 묻는 질문으로 다시 쓰는 일

2. 소제목 바로 아래 첫 문장에 답을 쓰는 일

3. 문단 첫 문장의 「이것」·「이 방식」을 대상의 이름으로 바꾸는 일

4. 읽다가 멈추게 되는 문장의 문법과 흐름을 수정하는 일

문단을 분리하면 앞 문단에 있던 이름이 사라지기 때문에 문단 첫 문장에 대상의 이름을 쓰는 일이 필요합니다. 예를 들어 「이 방식은 신청이 간단합니다」라는 문장만 남으면 읽는 쪽은 어떤 방식인지 알 수 없습니다. 반대로 첫 문장에 방식의 이름이 들어 있으면 그 문단만 분리해도 뜻이 남습니다.

소제목을 질문으로 쓰고 바로 아래 첫 문장에 답을 쓰면 답을 찾는 쪽이 그 문단만 인용하기 쉬워집니다. 소제목이 「서비스 소개」처럼 짧은 이름뿐이면 문단이 어떤 질문에 답하는지 문단 안에서 알 수 없습니다. 질문 꼴의 소제목은 그 문단이 무엇에 답하는지를 문단 곁에 남깁니다.

네 가지를 글마다 수정하는 시간은 손님 응대와 상담에 쓸 시간에서 빠집니다. 바쁜 주에는 점검이 늦어지고 새 글은 예전 습관대로 올라가므로 수정할 글이 계속 늘어납니다.

글 발행을 자동화하면 하루가 어떻게 달라집니까?

소제목과 첫 문장의 기준이 글을 만드는 기준에 들어 있으면 새 글마다 같은 점검을 하지 않아도 됩니다. 글을 쓰고 올리는 일은 AI 에이전트가 수행합니다. AI 에이전트는 고객이 정해 둔 기준대로 글을 쓰고 올리는 일을 수행하는 프로그램입니다.

달라지는 점은 다음과 같습니다.

1. 시간: 소제목과 첫 문장을 다시 읽던 시간을 상담과 본업에 쓰실 수 있습니다.

2. 꾸준함: 바쁜 주에도 정해 둔 발행 주기에 맞춰 같은 기준으로 쓴 글이 올라갑니다.

3. 채널 확장: 원하시면 같은 글을 인스타그램 카드뉴스로도 올릴 수 있습니다. 카드뉴스는 사진과 짧은 문장을 넘겨 보는 게시물입니다.

기준을 문장 수정에 두는 이유는 프린스턴대 연구의 결과 때문입니다. 문법과 흐름만 수정하고 새 내용을 더하지 않은 글도 답에 쓰이는 분량이 28% 늘었습니다. 읽는 사람이 이해하기 어려운 문장은 기계도 이해하기 어렵다는 뜻으로 읽을 수 있습니다.

같은 연구에서 인용문을 더한 글은 41% 늘었고 통계를 더한 글은 31% 늘었습니다. 인용문과 통계를 함께 쓴 경우가 한 가지만 쓴 경우보다 5.5% 이상 높았습니다. 인용문과 통계는 고객이 직접 확인할 수 있는 자료여야 글에 쓸 수 있습니다.

프린스턴대 연구의 결과는 실험 조건 안에서 확인된 일이며 실제 서비스 전부가 이 방식은 아닙니다. 서비스마다 어떤 글을 인용하는지는 다를 수 있으므로 글 수정은 사람과 기계가 모두 이해하기 쉬운 문장을 만드는 일로 보시면 됩니다.

자동화를 맡겨도 고객이 직접 정하는 일은 무엇입니까?

버튼 하나로 알아서 글이 올라가는 모습은 처음에 기준을 한 번 정해 두었을 때 만들어집니다. 그 기준은 고객 회사의 주제와 말투, 소제목 규칙에 관한 결정입니다.

고객이 정하실 일은 다음 세 가지입니다.

1. 올릴 주제를 정하고 소제목을 손님의 질문으로 쓸지 정하는 일

2. 문단 첫 문장에 대상의 이름을 쓰는 규칙과 쓰지 않을 표현을 정하는 일

3. 글에 넣을 인용문과 숫자 자료가 있는 곳을 알려 주고 올리기 전에 직접 승인할지 정하는 일

처음에 기준을 한 번 정해 두면 새 글을 올릴 때마다 같은 설명을 다시 하지 않아도 됩니다. 올라온 글이 마음에 들지 않으면 기준을 수정하시면 되고 사업 방향이 바뀔 때도 같은 방식으로 수정하시면 됩니다.

전문 용어가 들어가는 업종이라면 용어를 쉬운 말로 바꾸지 않고 처음 나올 때 한 번 풀어 쓰도록 기준에 넣을 수 있습니다. 쉬운 말로 바꾸기만 하면 글에 담긴 사실이 줄어들기 때문입니다.

올리기 전에 직접 보고 승인하는 방식으로 시작하면 기준이 맞게 적용되었는지 첫 글부터 확인할 수 있습니다. 익숙해진 뒤에 자동으로 올리는 방식으로 바꿀지도 고객이 정하시면 됩니다.

어떤 고객에게 잘 맞습니까?

블로그에 글이 이미 쌓여 있는데 AI 답변에는 나오지 않은 고객에게 먼저 맞습니다.

1. 소제목이 「소개」·「안내」처럼 짧은 이름뿐인 글을 많이 올린 고객

2. 문단 첫 문장이 「이것은」·「이 방식은」으로 시작하는 글을 써 온 고객

3. 글을 수정할 직원을 따로 두기 어려운 고객

학원의 수업 안내, 병원의 진료 안내, 제조 회사의 제품 설명, 시공 회사의 사례 글처럼 손님이 질문하고 답을 찾는 글이 있다면 소제목과 첫 문장의 기준은 업종이 달라도 같은 방식으로 적용합니다.

반대로 한 달에 올리는 글이 적어 수정 시간이 부담되지 않는다면 자동화가 줄여 주는 시간도 그만큼 적습니다. 그럴 때는 소제목과 첫 문장을 몇 편에서 먼저 바꿔 보고 글이 늘어 부담이 생기면 자동화를 알아보는 순서도 가능합니다.

이미 운영하는 사이트가 있다면 그 사이트에 글을 올리는 방식부터 확인합니다. 사이트가 어떤 방식으로 만들어졌는지에 따라 글을 올리는 방법이 달라질 수 있어 상담에서 먼저 살펴봅니다.

비용은 무엇에 따라 달라집니까?

비용은 글을 올리는 주기와 글에 넣을 자료의 준비 상태에 따라 크게 달라집니다. 정해진 금액은 이 글에 적지 않으며 아래 기준으로 범위를 잡습니다.

1. 글을 올리는 주기: 정해진 요일에 올리는지 필요한 때에만 올리는지

2. 글의 종류: 질문에 답하는 글인지 서비스를 소개하는 글인지

3. 글에 넣을 자료: 정리된 자료가 있는지 새로 모아야 하는지

4. 올리기 전 승인: 직접 보고 승인하는지 자동으로 올리는지

5. 글을 올릴 사이트: 이미 있는 사이트인지 어떤 방식으로 만들었는지

주기와 글의 종류, 자료, 승인 방식, 사이트 상태를 알려 주시면 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

문의에서 인계까지는 다섯 단계로 진행됩니다.

1. 문의: 사이트의 문의 양식으로 지금 운영하는 사이트와 올리려는 글의 주제를 남깁니다.

2. 상담: 글 주기와 자료, 승인 방식을 이야기합니다.

3. 범위와 견적 안내: 상담 내용에 맞춰 범위와 견적을 안내하며 견적을 보고 진행할지는 고객이 정하시면 됩니다.

4. 제작: 진행하기로 하시면 소제목과 첫 문장 기준에 맞춰 글이 올라가는 장치를 만듭니다.

5. 인계: 장치와 계정을 고객에게 넘겨드립니다.

그래서 지금 소제목과 첫 문장부터 바꿔야 합니까?

글 한 편에서 문단 하나만 복사해 읽었을 때 무엇에 관한 이야기인지 알 수 없다면 소제목과 첫 문장부터 바꿔 볼 만합니다. 소제목이 손님의 질문이고 바로 아래 첫 문장이 답이며 문단 첫 문장에 대상의 이름이 있다면 지금 기준을 갖춘 글입니다. 그런 글이 많다면 서두를 이유는 없습니다.

수정한 글을 검색엔진이 읽었는지는 서치콘솔(구글이 사이트 운영자에게 제공하는 검색 상태 확인 서비스)의 URL 검사에서 확인할 수 있습니다. URL 검사는 글 주소를 넣으면 구글의 읽기 상태를 보여 주는 기능입니다.

엔소프 컴퍼니는 ChatGPT가 인용하지 않는 블로그 글에 맞춘 글 발행을 AI 에이전트로 개발해 드립니다

글은 계속 쓰는데 ChatGPT가 인용하지 않는 상황에서는 글마다 같은 점검을 되풀이하는 일이 부담으로 남습니다. 고객이 원하실 경우 엔소프 컴퍼니는 고객이 정한 소제목과 첫 문장 기준대로 새 글을 쓰고 올리는 AI 에이전트를 개발해 드립니다. 어디까지 맡길지는 고객이 정하시면 됩니다.

완성된 모습은 이렇습니다.

1. 고객이 정한 주제가 손님의 질문 꼴 소제목이 되고 그 바로 아래 첫 문장에 답이 있는 글이 올라갑니다.

2. 문단 첫 문장에는 「이것」 대신 대상의 이름이 들어가 문단 하나만 읽어도 뜻이 통합니다.

3. 글은 검색엔진이 읽을 수 있는 형식으로 발행됩니다.

4. 사이트는 처음 올릴 글이 준비된 상태로 시작합니다.

소제목과 첫 문장을 수정하고 글을 올리던 직원의 시간과 인건비가 줄어듭니다. 네 가지를 한꺼번에 시작하실 필요는 없고 한 가지부터 시작하는 방식도 됩니다.

프로젝트를 마치면 글이 올라가는 장치와 계정, 글 작성 가이드를 넘겨드립니다. 서치콘솔 연동과 지표 확인 방법도 안내해 드립니다.

지금 운영 중인 사이트 주소와 많이 읽히는 글 한 편을 알려 주시면 됩니다.

프로젝트 문의하기

퇴근 시간이 다가오면 직원은 같은 스프레드시트를 다시 엽니다. 어제 입력했던 서식을 열고 같은 내용을 또 옮겨 적습니다. 월말이 다가오면 정산과 보고서 작성에 쫓깁니다. 직원은 하루 종일 쉴 틈 없이 일하지만 본업은 뒤로 밀립니다.

직원이 매일 붙잡고 있는 반복 업무를 AI 에이전트에 맡겨도 될지는 업무마다 다릅니다. AI 에이전트는 사람이 정해 둔 규칙과 판단 기준에 맞춰 업무를 대신 처리하는 프로그램입니다.

직원이 같은 일을 매일 직접 하면 어떤 일이 따라옵니까?

단순 작업은 한두 건일 때는 사소해 보입니다. 하지만 매일 쌓이면 직원 한 사람의 하루를 채웁니다. 사무실에서 흔히 일어나는 반복 작업은 크게 세 가지입니다.

1. 데이터 중복 입력: 한 시스템에서 확인한 주문이나 문의를 다른 프로그램에 다시 옮겨 적는 일입니다.

2. 월말 정산 및 보고서 취합: 매달 마감 때마다 여러 자료를 모아 계산하고 정리하는 일입니다.

3. 신청과 접수 건 분류: 문의 창구로 들어온 요청을 확인하고 담당 부서로 나누는 일입니다.

전산 입력에 시간을 뺏길수록 손님 응대와 전문 상담에 투입할 시간은 줄어듭니다. 학원이라면 강사의 수업 연구가 밀리고 시공 회사라면 현장 일정 조율이 늦어집니다. 전문 역량을 발휘해야 할 핵심 인력일수록 단순 작업에 묶였을 때 손실이 커집니다.

사람이 일일이 옮겨 적다 보면 누락이나 오타 같은 실수가 생기기 쉽습니다. 시스템 간에 숫자가 어긋나면 어느 쪽이 맞는지 확인하느라 시간이 또 들어갑니다. 단순 업무가 늘어날수록 소요 시간뿐 아니라 확인하는 부담도 함께 커집니다.

정산이 늦어지면 보고서 제출도 밀립니다. 월말 일정이 흔들리면 경영진이 직접 현황을 재확인해야 합니다. 직원이 하루 중 같은 일을 몇 번이나 되풀이하는지 살펴보면 문제 크기가 보입니다.

자동화하면 직원의 하루가 어떻게 달라집니까?

기존에 쓰시던 프로그램을 그대로 쓰면서 시스템 간 데이터를 자동으로 넘기면 중복 입력이 사라집니다. 도입 후 현장은 이렇게 달라집니다.

1. 자료 전송 자동화: 같은 내용을 두 번 세 번 복사해 옮기는 일이 사라집니다.

2. 마감 부담 해소: 매달 손으로 붙잡고 있던 정산과 보고서가 정해진 일시에 자동으로 만들어집니다.

3. 실시간 접수 분류: 문의와 신청이 밀리지 않고 들어오는 즉시 담당자에게 전달됩니다.

4. 인건비 절감: 반복 업무에 쓰던 직원 시간이 줄어 인건비 부담을 덜 수 있습니다.

자동화 방식은 워크플로와 에이전트 두 가지입니다. 워크플로는 정해진 순서대로 규칙에 맞춰 움직이는 방식입니다. 에이전트는 상황을 보고 처리 순서와 쓸 프로그램을 스스로 판단해 정하는 방식입니다.

정산과 보고서에 바쁘던 직원은 고객 응대와 거래처 관리에 집중할 수 있습니다. 학원이라면 접수를 나누던 시간을 상담에 쓸 수 있습니다. 병원이라면 예약 내용을 옮겨 적던 시간을 환자 안내에 쓸 수 있습니다.

처음부터 모든 업무를 바꿀 필요는 없습니다. 가장 손이 많이 가는 업무 하나부터 시작해 안정시킨 뒤 다음 단계로 넓히는 편이 안전합니다.

AI 에이전트를 도입할 때 고객이 하실 일은 무엇입니까?

AI 에이전트가 현장에서 일하려면 처음에 일할 기준을 명확하게 세워야 합니다. 발주사에서 처음에 준비해 주실 사항은 세 가지입니다.

1. 대상 업무 선정: 직원이 어떤 순서와 흐름으로 해당 업무를 처리하는지 실제 과정을 공유합니다.

2. 예외 처리 규칙 정의: 특정 금액 이하는 바로 처리하고 초과 건은 관리자 확인을 거친다는 식입니다.

3. 결과 검증 기준 마련: 수기 정산서와 시스템 정산서를 대조할 기준을 잡습니다.

기준이 정리되면 개발사는 이를 공식 문서로 남기고 그 사양에 맞춰 시스템을 만듭니다. 범위가 문서로 남아 있어 나중에 무엇을 맡겼는지 분명하게 확인할 수 있습니다.

업무 기준이 한 번 문서화되면 직원이 바뀌어도 인수인계 부담이 줄어듭니다. 처리 규칙이 문서로 남아 회사의 자산이 됩니다.

도입 초기에는 시스템이 낸 결과와 직원이 작업한 기존 결과를 나란히 대조해 봅니다. 정산서라면 총합계가 맞는지 보고 신청서라면 분류가 맞는지 교차 검증하며 정밀도를 높여 나갑니다.

우리 회사에서는 어떤 업무부터 맡기면 맞습니까?

처음 맡길 업무는 반복 횟수가 잦고 규칙이 분명하며 사람이 직접 처리하는 업무입니다. 다음 세 가지로 후보를 점검해 보시면 됩니다.

1. 반복 횟수: 이번 주에 동일한 작업을 몇 번이나 되풀이했는지 봅니다. 횟수가 잦을수록 자동화 효과가 큽니다.

2. 규칙의 명확성: 처리 순서를 글로 설명할 수 있는지 봅니다. 절차가 또렷할수록 시스템 구축이 쉽습니다.

3. 병목 구간: 담당 직원이 자리를 비웠을 때 업무가 멈추는 곳을 찾습니다. 그 자리가 바로 사람이 직접 처리하는 단계입니다.

주관적 판단이 필요하거나 예외가 많은 업무는 처음 과제로 맞지 않습니다. 안정화까지 시간이 걸리므로 규칙이 분명한 업무로 먼저 시작하는 편이 낫습니다.

단순 입력과 출력이 고정된 작업은 워크플로만으로 충분합니다. 반면 문의 내용이 매번 다르고 처리 경로가 바뀌는 업무라면 AI 에이전트를 검토할 만합니다.

비용은 무엇에 따라 달라집니까?

업무 자동화는 기성품이 아니므로 정해진 단일 가격표가 없습니다. 기업마다 쓰는 프로그램과 업무 방식이 다르기 때문입니다. 실제 비용은 다음 다섯 가지 요소에 따라 정해집니다.

1. 맡길 업무의 수: 단일 업무 하나인지 여러 업무가 얽혀 있는지에 따라 다릅니다.

2. 연결할 프로그램 수: 회계·재고 프로그램, 스프레드시트, 메신저, 이메일처럼 이어야 할 프로그램이 많을수록 범위가 커집니다.

3. 규칙의 복잡도: 처리 규칙이 단순한지 여러 예외를 분기해야 하는지에 따라 달라집니다.

4. 전용 화면 필요 여부: 자료 입력이나 결과를 모니터링할 웹 화면이 필요한지 봅니다.

5. 자료의 정제 상태: 사내 자료가 한곳에 정돈되어 있는지 흩어져 있는지에 따라 달라집니다.

이 다섯 가지 현황을 알려 주시면 필요한 개발 범위에 맞춰 견적을 안내해 드립니다. 아직 정해지지 않은 부분은 상담에서 함께 확인하시면 됩니다.

문의하면 어떤 순서로 진행됩니까?

상담부터 최종 인수인계까지 프로젝트는 아래 순서로 진행됩니다.

1. 업무 현황 상담: 자동화하려는 업무 흐름과 현재 사내에서 쓰는 프로그램을 바탕으로 상담합니다.

2. 범위 정의와 견적 안내: 상담 내용을 토대로 개발 범위와 견적을 제안합니다. 견적을 검토하신 뒤 진행 여부를 결정하시면 됩니다.

3. 규칙 문서화와 제작: 업무 규칙을 문서로 정리하고 시스템을 제작합니다. 제작 중에는 가상 샘플이 아니라 실무 자료로 정상 동작을 확인합니다.

4. 인수인계와 매뉴얼 전달: 완성된 자동화와 관리자 계정 그리고 사용 문서를 넘겨드립니다.

그래서 반복 업무를 AI 에이전트에게 맡겨 볼 만합니까?

같은 자료를 두 곳 이상에 옮겨 적거나 정산과 분류에 직원 시간이 계속 쓰인다면 검토할 만합니다. 규칙이 잡혀 있는 업무가 하나라도 있다면 그 업무를 후보로 두고 상담을 시작하셔도 좋습니다.

급하게 서두르실 일은 아닙니다. 순서가 정해진 업무는 워크플로로 시작하고 에이전트는 꼭 필요할 때만 더하시면 됩니다. 매번 달라지는 업무에서만 에이전트를 검토하시면 됩니다.

엔소프 컴퍼니는 직원이 매일 반복하는 일에 맞춘 업무 자동화를 AI 에이전트로 개발해 드립니다

직원이 같은 일을 매일 반복하고 계시다면 자동화할 수 있습니다. 엔소프 컴퍼니는 반복 업무를 AI 에이전트가 대신하도록 실무에 맞춰 개발해 드립니다. 가장 번거로운 업무 하나부터 시작하셔도 됩니다.

업무 흐름 확인부터 규칙 정리, 프로그램 연결, 실제 자료 확인까지 엔소프 컴퍼니가 한곳에서 진행합니다. 기획과 개발을 업체별로 따로 조율할 필요가 줄어듭니다.

도입 후에는 이런 점이 달라집니다.

1. 쓰시던 프로그램이 서로 이어져 같은 데이터를 다시 옮겨 적는 일이 사라집니다.

2. 매달 손으로 취합하던 정산과 보고서가 정해진 규칙대로 자동 생성됩니다.

3. 매일 들어오는 신청과 접수 건이 기준에 맞춰 스스로 분류됩니다.

4. 필요하시면 실무진이 작업 내용을 확인하고 승인하는 전용 화면도 함께 만들어 드립니다.

단순 반복 작업에 묶여 있던 직원 시간이 절약되어 인건비 부담이 줄어듭니다. 그 시간은 손님 응대와 상담 같은 본업에 쓰실 수 있습니다.

프로젝트를 마치면 실제로 동작하는 자동화와 사용 설명서, 계정 권한을 모두 넘겨드립니다.

직원이 매일 반복하느라 시간이 가장 많이 쓰이는 일이 무엇인지 알려 주시면 됩니다.

프로젝트 문의하기

저녁에 문의 답변을 마치고 나서야 주문 기록을 여는 날이 많으신가요? 낮에 상담 도구에서 나눈 대화를 회사 기록에 다시 옮겨 적다 보면 퇴근이 늦어집니다. 문의가 늘수록 이 시간도 함께 늘어납니다.

상담 솔루션은 손님의 문의를 받아 답하는 프로그램이고 월 이용료를 내고 빌려 쓰는 방식이 구독입니다. 연동은 상담 도구와 회사 내부 시스템을 서로 이어 두는 일입니다.

상담이 늘면 직접 하는 일에 어떤 일이 따라옵니까?

상담 도구를 구독해도 회사 기록과 이어져 있지 않으면 사람이 두 곳을 오가며 일해야 합니다. 상담 도구에는 대화가 쌓이고 회사 기록에는 주문과 회원 정보가 쌓이기 때문입니다. 두 곳에 쌓인 내용을 맞추는 일은 사람이 맡게 됩니다.

반복되는 일은 이렇습니다.

1. 상담에서 나온 내용을 주문이나 회원 기록에 옮겨 적는 일

2. 들어온 문의를 종류별로 나눠 담당자에게 전하는 일

3. 월말에 상담 내용을 모아 보고서로 만드는 일

세 가지 일은 하나씩 보면 짧습니다. 그러나 문의가 하루에 여러 번 들어오면 본업 시간에서 이 일이 차지하는 몫이 커집니다. 손님에게 직접 답해야 하는 일은 그만큼 뒤로 밀립니다.

학원이라면 수강 문의 내용을 원생 명단에 옮기는 일이 여기에 해당합니다. 시공 회사라면 견적 문의를 현장별로 나누는 일이 같은 꼴입니다. 업종은 달라도 같은 내용을 두 번 적는 구조는 같습니다.

바쁜 주에는 옮겨 적는 일이 밀리기도 합니다. 기록이 늦어지면 다음 응대 때 지난 상담 내용을 손님께 다시 물어야 할 수 있습니다.

상담 도구와 내부 시스템을 이어 두면 하루가 어떻게 달라집니까?

쓰시는 상담 도구를 바꾸지 않고 내부 시스템과 사이만 이어 두면 옮겨 적던 일이 줄어듭니다. 달라지는 점은 이렇습니다.

1. 시간이 달라집니다. 같은 내용을 두 번 옮겨 적는 일이 없어지고 그 시간에 손님과 직접 이야기하실 수 있습니다.

2. 꾸준함이 달라집니다. 신청과 접수가 들어오는 대로 종류별로 나뉘어 바쁜 날에도 분류가 밀리지 않습니다.

3. 비용이 달라집니다. 매달 손으로 만들던 정산과 보고서가 자동으로 만들어져 그 일에 쓰던 인건비가 줄어듭니다.

달라지는 것은 일하는 순서인데 지금은 상담을 마친 뒤에 기록하는 일이 따로 남습니다. 이어 두면 상담이 끝나는 시점에 기록할 일도 함께 줄어 있습니다.

이 변화는 상담량이 많은 고객일수록 체감하기 쉽습니다. 옮겨 적는 건수가 상담 건수만큼 늘기 때문입니다.

구독을 유지하는 선택과 연동을 더하는 선택은 서로 다른 일입니다. 구독을 그대로 두고 연동만 더하는 방법이 있습니다. 직접 만드는 쪽과의 비교는 연동 범위를 잡은 뒤에도 하실 수 있습니다.

구독할지 직접 만들지 고르려면 고객은 무엇을 정하시면 됩니까?

처음에 기준을 한 번 정해 두시면 그 뒤로는 매번 설명하지 않으셔도 됩니다. 정할 기준은 세 가지입니다.

1. 상담이 다른 회사와 차별되는 강점인지 모든 회사가 하는 운영 업무인지 구분합니다. 직접 만들지 구독할지 판단하는 출발점이 이 구분입니다.

2. 한 달에 들어오는 상담 건수를 확인합니다. 건수가 많지 않으면 구독이 경제적인 구간으로 봅니다.

3. 상담 내용을 어느 내부 시스템까지 이을지 범위를 정합니다.

첫 번째 기준에서 상담이 강점이라면 직접 만드는 쪽도 검토할 만합니다. 표준적인 운영 업무라면 구독을 먼저 살펴볼 만합니다.

세 번째 기준은 구독을 쓰든 직접 만들든 남습니다. 어느 쪽을 고르더라도 상담 내용이 회사 기록으로 가야 하기 때문입니다.

연동 범위가 좁으면 구독에 연결만 더해도 충분할 수 있습니다. 범위가 넓어져 여러 시스템에 걸치면 직접 만드는 쪽의 비용도 함께 비교할 만합니다.

어떤 고객께 연동이 잘 맞습니까?

상담 도구에는 만족하지만 그 안의 내용을 회사 기록으로 옮기는 데 시간을 쓰시는 고객께 잘 맞습니다.

1. 같은 내용을 두 곳 이상에 옮겨 적고 계신 고객

2. 매달 상담 기록으로 정산과 보고서를 손으로 만드는 고객

3. 신청과 접수를 수작업으로 분류하는 고객

반대로 상담 내용을 옮겨 적을 일이 없는 고객은 연동이 급하지 않습니다. 상담 도구 하나로 업무가 끝나는 회사가 그렇습니다.

도구 자체가 회사 일에 맞지 않으면 연동만으로는 해결되지 않습니다. 이때는 다른 구독 상품이나 직접 만드는 쪽을 비교하게 됩니다.

병원이나 학원처럼 예약과 상담이 한 흐름으로 이어지는 업종은 옮겨 적는 구간이 길어지기 쉽습니다. 제조나 시공 회사는 견적 문의를 현장과 거래처별로 나누는 일이 쌓이기 쉽습니다.

비용은 무엇에 따라 달라집니까?

연동 범위에 따라 작업량이 달라지므로 고정된 금액은 없습니다. 견적을 잡는 기준은 이렇습니다.

1. 이을 내부 시스템이 몇 개인지: 하나인지 여러 개인지

2. 자동으로 처리할 일이 무엇인지: 옮겨 적기, 접수 분류, 월말 보고서 가운데 어디까지인지

3. 관리자 화면이나 입력 폼이 따로 필요한지

이 세 가지만 알려 주시면 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

순서는 이렇습니다.

1. 문의를 남기시면 지금 쓰시는 상담 도구와 내부 시스템을 여쭙니다.

2. 위에서 정한 상담 구분과 상담 건수, 연동 범위를 중심으로 상담합니다.

3. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

4. 진행하시기로 하면 연결을 만들고 실제 데이터로 확인합니다.

5. 프로젝트를 마치면 만든 장치와 계정을 고객에게 넘겨드립니다.

그래서 지금 상담 솔루션을 직접 만들어야 합니까?

상담 내용을 두 곳에 옮겨 적는 일이 매일 반복된다면 연동 범위를 먼저 알아볼 만합니다. 그 일이 아직 드물다면 서두를 이유는 없습니다. 상담량과 연동 범위를 확인한 뒤에 구독과 직접 만들기 중에서 고르시면 됩니다.

엔소프 컴퍼니는 상담 솔루션 구독에 맞춘 내부 시스템 연동을 AI 에이전트로 개발해 드립니다

상담 솔루션을 구독할지 직접 만들지 고민하는 동안에도 상담 내용을 옮겨 적는 일은 매일 이어집니다. 고객이 원하실 경우 엔소프 컴퍼니는 이 일을 AI 에이전트가 수행하도록 개발해 드립니다. 쓰시는 상담 도구는 그대로 두고 사이만 잇습니다. 어디까지 맡길지는 고객이 정하시면 됩니다.

완성된 모습은 이렇습니다.

1. 쓰시는 상담 도구는 그대로 두고 회사 내부 시스템과 이어집니다.

2. 같은 내용을 두 번 옮겨 적는 일이 없어집니다.

3. 신청과 접수가 들어오는 대로 종류별로 나뉩니다.

4. 매달 손으로 만들던 정산과 보고서가 자동으로 만들어집니다.

옮겨 적고 분류하고 보고서를 만들던 시간이 줄어 인건비 부담도 가벼워집니다. 그 시간은 손님 응대와 본업에 쓰실 수 있습니다.

네 가지를 한 번에 다 하실 필요는 없습니다. 옮겨 적는 일 하나부터 시작하는 방식도 가능합니다. 필요하시면 관리자 화면과 입력 폼도 개발합니다.

프로젝트를 마치면 동작하는 자동화 시스템과 계정을 모두 고객에게 넘겨드립니다.

지금 상담 내용을 어디에서 어디로 옮겨 적고 계신지 알려 주시면 됩니다.

프로젝트 문의하기

회사 사이트를 새로 만들기로 하고 개발사 몇 곳에 물어보셨습니다. 한 곳은 워드프레스를 권합니다. 다른 곳은 Webflow를 권하고 또 다른 곳은 Next.js를 꺼냅니다. 이름은 늘어나는데 고르는 기준은 보이지 않습니다.

워드프레스, Webflow, Next.js는 사이트를 만드는 서로 다른 세 종류의 방식입니다. 같은 종류의 제품 세 개가 아닙니다. 종류가 다르면 사이트를 만드는 사람과 업데이트하는 사람도 달라집니다. 어느 종류가 맞는지는 사이트로 무엇을 하는지와 얼마나 자주 업데이트하는지, 두 질문의 답에 따라 달라집니다.

워드프레스, Webflow, Next.js는 각각 무엇입니까?

세 이름을 하나씩 풀어 보겠습니다.

1. 워드프레스: 서버(사이트 파일을 보관하는 컴퓨터)에 직접 설치해서 쓰는 CMS입니다. CMS(콘텐츠 관리 시스템)는 글과 사진을 관리 화면에서 올리고 바꾸는 프로그램입니다.

2. Webflow: 화면을 보며 사이트를 만드는 웹 빌더입니다. 코드를 거의 쓰지 않고 화면에서 디자인하는 서비스입니다. 호스팅(사이트를 인터넷에 열어 두는 서비스)과 CMS가 함께 들어 있습니다.

3. Next.js: 개발자가 코드로 사이트를 만드는 프레임워크입니다. 프레임워크는 코드를 짤 때 쓰는 기본 틀입니다. 글을 올리는 관리 화면이 따로 없어서 별도의 CMS를 붙입니다. 화면과 분리해 글 관리만 맡는 CMS를 헤드리스 CMS라고 부릅니다.

워드프레스와 Webflow는 직원이 관리 화면에서 글을 올릴 수 있습니다. Next.js는 화면이나 기능을 바꿀 때 개발자가 코드를 수정해야 합니다. 세 이름은 만드는 방식이 달라서 한 줄에 세우고 가격이나 성능을 비교하기 어렵습니다.

개발사마다 권하는 이름이 다른 까닭은 무엇입니까?

종류가 다르면 맞는 사이트도 다릅니다. 개발사마다 이 사이트를 어떻게 쓸지 다르게 짐작하면 권하는 이름도 달라집니다.

회사 소개와 문의 접수가 목적인 사이트를 예로 들어 보겠습니다. 직원이 글을 자주 올릴 것으로 짐작한 개발사는 관리 화면이 있는 방식을 권할 수 있습니다. 반면 거의 바꾸지 않을 것으로 짐작한 개발사는 가벼운 방식을 권할 수 있습니다. 사이트로 무엇을 하는지 개발사에 아직 알려 주지 않았는데 추천만 여러 개 받게 됩니다.

가격을 비교해도 같은 일이 되풀이됩니다. 종류가 다르면 견적서에 적힌 일의 범위도 달라질 수 있어 숫자끼리 비교하기 어렵습니다. 그러면 가장 낮은 숫자를 고를지 가장 익숙한 이름을 고를지만 남습니다.

결정이 미뤄지면 사이트를 여는 날짜도 함께 밀립니다. 담당자는 비교표를 다듬느라 사이트에 담을 내용을 정리할 시간을 잃습니다. 정작 필요한 준비는 시작하지 못하고 일정만 늦어집니다.

이름부터 정하면 확인하는 순서가 거꾸로 됩니다. 구축 방식을 먼저 정한 뒤에 그 방식으로 우리 일이 되는지를 따져야 하기 때문입니다. 일이 맞지 않으면 처음부터 다시 비교합니다.

구축 방식은 무엇을 보고 고릅니까?

기준은 구축 방식의 이름이 아니라 사이트를 쓰는 방식에 있습니다. 사이트로 무엇을 하는지와 얼마나 자주 업데이트하는지가 먼저 정해지고 이름은 그다음에 따라옵니다.

첫 번째 질문은 사이트로 무엇을 하는지입니다. 회사를 소개하거나 문의를 받는 사이트가 있고 상품을 팔거나 글을 쌓아 검색에서 발견되려는 사이트도 있습니다. 하는 일이 다르면 사이트에 필요한 기능도 달라집니다.

두 번째 질문은 얼마나 자주 업데이트하는지입니다. 일단 열면 거의 수정하지 않는 사이트가 있고 매주 글과 소식을 올리는 사이트가 있습니다. 자주 업데이트할수록 업데이트하는 직원이 쓰는 화면과 순서가 중요해집니다.

사이트로 무엇을 하는지와 얼마나 자주 업데이트하는지는 서로 다른 것을 묻습니다. 사이트로 하는 일은 사이트가 해야 할 일이고 업데이트 주기는 사이트를 관리하는 일입니다. 한쪽만 답하면 후보가 여전히 많이 남습니다.

하는 일과 업데이트 주기에 따라 어떤 방식이 맞습니까?

사이트로 하는 일과 업데이트 주기에 따라 먼저 살피는 종류가 달라집니다. 정답을 알려 주는 표가 아니라 검토를 시작하는 순서입니다.

1. 거의 바꾸지 않는 소개 사이트: 관리 화면이 꼭 필요하지 않을 수 있습니다. 가벼운 방식으로 충분한지 먼저 봅니다.

2. 직원이 매주 글을 올리는 사이트: 직원이 매주 글을 올려야 하면 관리 화면이 있는 CMS나 웹 빌더가 먼저 후보가 됩니다. 워드프레스와 Webflow가 여기에 해당합니다.

3. 회원 가입이나 결제처럼 복잡한 기능이 필요한 사이트: 개발자가 코드로 만드는 Next.js 같은 프레임워크도 검토 대상이 됩니다. 이때는 글을 올리는 관리 화면을 어떻게 붙일지도 함께 살핍니다.

사이트 종류별 구분은 검토의 출발점입니다. 예산과 일정, 이미 갖고 계신 자료까지 보고 최종 방식을 고르시면 됩니다.

사이트로 하는 일과 업데이트 주기는 어떻게 적습니까?

메모 한 장에 문장으로 적으시면 됩니다. 적을 것은 사이트로 하는 일과 얼마나 자주 업데이트하는지입니다. 구축 방식의 이름도 기술 용어도 필요하지 않습니다. 아래 순서로 적어 보시면 됩니다.

1. 사이트로 하는 일을 한 줄씩 적습니다. 회사 소개, 문의 받기, 상품 판매, 글 쌓기처럼 일상어로 씁니다.
2. 일마다 얼마나 자주 업데이트하는지 적습니다. 매주인지 가끔인지 거의 없는지만 적어도 충분합니다.
3. 업데이트하는 사람을 적습니다. 개발자가 아니라 직원이 직접 업데이트한다면 그 직원이 쓸 화면을 떠올려 봅니다.

일이 여러 개면 일마다 따로 적습니다. 회사 소개 부분은 가끔 업데이트하고 블로그 부분은 매주 업데이트할 수 있습니다. 이렇게 나누면 사이트 하나에서도 답이 둘이 나옵니다.

모르는 칸이 있어도 괜찮습니다. 모른다고 적어 두면 그 칸이 개발사와 먼저 이야기할 주제가 됩니다. 아는 척 채운 칸보다 모른다고 적은 칸이 나중에 일을 줄여 줍니다.

완성한 메모는 여러 개발사에 같은 모습으로 건넬 수 있습니다. 같은 메모를 받으면 개발사마다 짐작하지 않고 같은 기준으로 답합니다. 그래서 답을 나란히 놓고 비교하기 쉬워집니다.

개발사에 문의하기 전에 정해 둘 것은 무엇입니까?

메모를 적었다면 담당자, 자료 위치, 계정과 소스코드 소유자도 미리 정해 두시면 됩니다. 업데이트 주기는 업데이트하는 담당자가 정해져야 실제로 지켜집니다. 담당자를 적어 두면 개발사가 그 직원에게 맞는 관리 화면을 설명할 수 있습니다.

1. 글과 소식을 올릴 담당자를 정합니다.
2. 사진과 상품 정보가 어디에 있는지 적습니다. 자료가 모여 있는 곳(파일이나 프로그램 이름)도 함께 적습니다.
3. 사이트를 연 뒤 계정과 소스코드(사이트를 만든 파일 모음)를 누가 갖는지 개발사와 정합니다.

매주 올리겠다고 적고 담당자를 적지 못하면 그 주기는 계획으로만 남기 쉽습니다. 그때는 주기를 낮추거나 글 올리는 일을 맡길 방법을 먼저 찾습니다.

사진과 상품 정보가 흩어져 있으면 사이트에 올릴 때마다 같은 내용을 다시 옮겨 적게 됩니다. 어디에 있는지만 알아도 개발사가 연결 방법을 설명할 수 있습니다.

계정과 소스코드의 주인은 사이트를 연 뒤에 문제가 됩니다. 개발사 이름으로 만든 계정이면 개발사가 바뀔 때 고객이 관리 화면에 들어가지 못할 수 있습니다. 그래서 어떤 계정을 고객 이름으로 만들지 미리 적어 두시면 됩니다.

비용은 무엇에 따라 달라집니까?

사이트를 만드는 비용은 사이트로 하는 일과 업데이트 주기에 따라 달라집니다. 금액은 상담 뒤 견적으로 안내합니다.

1. 사이트로 하는 일의 수: 회사 소개와 문의 접수만인지, 판매나 회원 기능까지인지

2. 업데이트 주기와 업데이트하는 사람: 직원이 직접 업데이트할 관리 화면이 필요한지

3. 연결할 것: 쓰시는 프로그램이나 자료와 이어야 하는지

4. 지금 사이트가 있는지: 새로 만드는지, 있는 사이트를 바꾸는지

5. 글을 올리는 일을 자동화할지

이 다섯 가지를 알려 주시면 범위를 잡을 수 있습니다.

문의하면 어떤 순서로 진행됩니까?

메모에 적은 내용을 그대로 문의에 붙이셔도 됩니다. 순서는 이렇습니다.

1. 문의를 남기시면 하는 일과 업데이트 주기를 보고 상담합니다.

2. 사이트에 맞는 구축 방식을 안내하고 범위와 견적을 알려 드립니다. 진행할지는 고객이 정하시면 됩니다.

3. 진행하시기로 하면 사이트를 만듭니다.

4. 만든 사이트와 계정을 고객에게 넘겨드립니다.

그래서 워드프레스, Webflow, Next.js 중 무엇부터 고르면 됩니까?

이름이 아니라 사이트로 하는 일과 업데이트 주기부터 정하시면 됩니다. 워드프레스, Webflow, Next.js는 종류가 달라서 이름만 보면 서로 바꿔 쓸 수 있는 선택지처럼 보입니다. 하는 일과 업데이트 주기를 적어 두면 어느 종류부터 살필지가 보입니다.

이미 비교표를 만드셨다면 표 맨 위에 하는 일과 업데이트 주기를 적어 후보가 맞는지 확인해 보실 수 있습니다. 구축 방식이 이미 정해져 있고 잘 쓰고 계시다면 답을 따로 적지 않으셔도 됩니다.

엔소프 컴퍼니는 사이트 구축 방식 선택부터 반복 업무 자동화까지 AI 에이전트로 만들어 드립니다

개발사 세 곳이 워드프레스와 Webflow, Next.js를 제각각 권하는 까닭은 세 이름이 서로 다른 종류이기 때문입니다. 어느 종류가 맞는지는 사이트로 하려는 일과 업데이트 주기에 달려 있습니다. 사이트로 하는 일과 업데이트 주기가 정해지면 소식을 올리고 문의를 정리하는 일처럼 반복 업무를 확인할 수 있습니다. 고객이 원하시면 엔소프 컴퍼니는 확인한 반복 업무를 AI 에이전트가 수행하도록 개발해 드립니다. AI 에이전트는 정해 준 일을 사람 대신 수행하는 AI 프로그램이며 맡길 범위는 고객이 정하시면 됩니다.

고객이 사이트로 하려는 일과 업데이트 주기를 말씀해 주시면 맞는 구축 방식을 안내합니다. 정하신 방식으로 사이트도 개발해 드리며 기획과 디자인, 개발은 엔소프 컴퍼니 한곳에서 맡습니다.

자동화를 맡기시면 달라지는 점은 다음과 같습니다.

1. 소식과 안내 글이 고객이 정한 주제 순서대로 사이트에 올라갑니다.

2. 같은 내용을 두 곳에 옮겨 적던 일이 줄어듭니다.

3. 문의와 신청은 들어오는 대로 종류별로 나뉩니다.

승인 단계를 둘지는 고객이 고르시면 됩니다. 소식을 올리고 옮겨 적던 일을 AI 에이전트가 맡으면 인건비 부담이 줄어듭니다. 그 시간은 본업과 상담에 쓰실 수 있습니다.

프로젝트를 마치면 만든 사이트와 계정을 모두 고객에게 넘겨드립니다. 자동화를 맡기셨다면 그 장치도 함께 넘겨드립니다.

사이트로 하려는 일과 업데이트 주기를 알려 주시면 됩니다. 그 내용을 바탕으로 무엇부터 만들지 이야기를 시작하실 수 있습니다.

프로젝트 문의하기

여러 개발사에 「홈페이지 견적 부탁드립니다」라고 한 줄씩 보내 보신 적이 있으신가요? 며칠 뒤 돌아온 견적서는 항목도 범위도 제각각입니다. 같은 홈페이지를 부탁드렸는데 견적서마다 다른 일이 적혀 있습니다.

비교하기 어려운 까닭은 보낸 메일에 있습니다. 메일에 무엇을 적느냐에 따라 돌아오는 견적서가 달라집니다.

한 줄 메일을 보내면 견적서가 왜 제각각입니까?

메일에 없는 내용을 개발사마다 다르게 짐작하기 때문입니다. 「홈페이지」라는 말에는 회원 기능이 필요한지, 관리자 화면이 필요한지가 들어 있지 않습니다. 관리자 화면은 직원이 홈페이지 내용을 직접 수정하는 전용 화면입니다. 어떤 곳은 소개 페이지만 있다고 보고 어떤 곳은 회원과 관리자까지 있다고 봅니다.

짐작이 다르면 견적서에 적히는 일도 달라지는데 한 곳은 사진을 새로 준비한다고 적고 다른 곳은 이미 있다고 봅니다. 범위가 다른 견적서는 금액보다 포함된 일을 먼저 확인해야 정확히 비교됩니다.

반대로 메일에 필요한 내용이 들어 있으면 개발사들이 같은 일을 놓고 견적을 냅니다. 견적서끼리 비교하기 쉬워지고 빠진 일도 눈에 보입니다.

메일에는 무엇을 적으면 됩니까?

여섯 가지만 한 줄씩 적으시면 됩니다. 길게 쓰실 필요는 없습니다.

1. 만들려는 것: 「홈페이지」 대신 해결하고 싶은 일을 적습니다. 예를 들어 「방문자가 서비스를 보고 상담을 신청하게 하고 싶다」처럼 씁니다.

2. 쓰는 사람: 방문자만 쓰는지 회원과 직원도 쓰는지 적습니다. 예를 들어 「방문자가 예약하고 직원이 관리 화면에서 확인한다」처럼 씁니다.

3. 지금 쓰는 도구: 노션이나 구글시트, 슬랙처럼 지금 쓰는 도구와 쓰는 일을 적습니다. 새 홈페이지와 이어야 하는지 개발사가 판단할 수 있습니다.

4. 가진 자료: 고객 명단과 제품 사진, 소개 문구, 로고가 있는지와 어디에 있는지 적습니다. 없는 자료는 없다고 적습니다.

5. 업데이트 주기: 상품이나 공지를 자주 바꾸는지 거의 바꾸지 않는지 적습니다. 누가 바꾸는지도 한 줄 추가합니다.

6. 원하는 시점: 행사나 개업처럼 미룰 수 없는 날이 있으면 날짜와 이유를 적습니다. 정해지지 않았다면 정해지지 않았다고 적습니다.

여섯 가지를 적지 않으면 개발사가 빈칸을 스스로 채웁니다. 그 빈칸이 견적서마다 달라지는 부분입니다.

그대로 복사해 쓸 수 있는 메일은 어떤 모양입니까?

아래 틀에서 괄호 안만 채워 보내시면 됩니다.

안녕하십니까. 홈페이지 제작을 알아보고 있습니다. 아래 내용으로 견적을 부탁드립니다.

1. 만들려는 것: (해결하고 싶은 일 한 줄)
2. 쓰는 사람: (방문자, 회원, 직원 가운데 누가 쓰는지)
3. 지금 쓰는 도구: (이름과 쓰는 일)
4. 가진 자료: (있는 것과 없는 것)
5. 업데이트 주기: (얼마나 자주 누가 바꾸는지)
6. 원하는 시점: (날짜와 이유, 정해지지 않았다면 그대로)

같은 메일을 모든 개발사에 보내시면 견적서가 같은 출발점에서 나옵니다. 한 곳이 되물은 내용은 메일에 추가해 다른 곳에도 알려 주시면 됩니다.

비용은 무엇에 따라 달라집니까?

메일에 적은 여섯 가지가 그대로 견적 범위를 정하는 기준입니다. 금액은 상담 뒤 견적으로 안내합니다.

1. 만들려는 것: 소개만 하는 홈페이지인지, 예약이나 신청까지 받는지

2. 쓰는 사람: 방문자만 쓰는지, 회원과 직원이 쓰는 화면이 더 있는지

3. 지금 쓰는 도구: 새 홈페이지와 이어야 하는 도구가 있는지

4. 가진 자료: 사진과 문구가 준비되어 있는지, 새로 만들어야 하는지

5. 업데이트 주기: 직접 업데이트하실 수 있는 관리 화면이 필요한지

6. 원하는 시점: 미룰 수 없는 날이 있는지

여섯 항목이 적혀 있으면 개발사가 견적 범위를 산정하기 쉽습니다. 모르는 칸은 모른다고 적으시면 상담에서 함께 채웁니다.

문의하면 어떤 순서로 진행됩니까?

보내려던 메일을 그대로 문의에 붙이셔도 됩니다. 순서는 이렇습니다.

1. 문의를 남기시면 메일 내용을 보고 상담합니다.

2. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보고 진행할지는 고객이 정하시면 됩니다.

3. 진행하시기로 하면 홈페이지와 필요한 기능을 만듭니다.

4. 만든 것과 계정을 고객에게 넘겨드립니다.

그래서 견적 요청 메일에 만들려는 것과 쓰는 사람, 가진 자료까지 적어 보내야 합니까?

여러 개발사에 견적을 받아 비교하실 계획이라면 적어서 보내시는 편이 비교하기 쉽습니다. 모두 같은 출발점에서 견적서를 내기 때문입니다. 한 곳에만 문의하신다면 한 줄로 시작하셔도 됩니다. 빈칸은 상담에서 채울 수 있습니다.

엔소프 컴퍼니는 견적 요청 메일에 적은 반복 업무를 AI 에이전트로 개발해 드립니다

견적 요청 메일에 적을 항목을 정하다 보면 반복되는 일이 보입니다. 쓰시는 도구 사이에 같은 내용을 옮겨 적는 일이 있습니다. 문의가 올 때마다 직접 정리하는 일도 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 이 반복 업무를 AI 에이전트가 맡도록 개발해 드립니다. AI 에이전트는 정해 둔 기준대로 일을 맡아 하는 프로그램입니다. 메일에 적은 업무 가운데 무엇을 맡길지는 고객이 정하시면 됩니다.

맡기셨을 때 받으실 수 있는 모습은 이렇습니다.

1. 문의와 신청이 들어오는 대로 종류별로 나뉘어 한곳에 모입니다.

2. 매달 손으로 만들던 정산과 보고서가 자동으로 만들어집니다.

3. 자주 올리는 소식과 안내 글은 고객이 정해 두신 주제대로 올라갑니다.

4. 올리기 전에 직접 보고 승인하는 방식도 고르실 수 있습니다.

메일에 무엇을 적을지 아직 정해지지 않으셨다면 기획부터 시작하는 방식도 있습니다. 목표와 쓰는 사람, 필요한 화면을 문서로 남기면 어느 개발사에도 그대로 전달하실 수 있습니다.

접수와 보고서를 옮겨 적던 직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 요구사항 문서와 화면 설계서를 넘겨드립니다. 요구사항 문서는 만들 기능을 적은 문서이고 화면 설계서는 화면 구성을 그린 문서입니다. 자동화를 맡기셨다면 만든 장치와 계정도 모두 고객에게 넘겨드립니다.

문의에 견적 요청 메일의 내용을 적어 주시면 되고 다른 개발사에 보내신 메일을 엔소프 컴퍼니에 그대로 보내셔도 좋습니다. 메일에 적힌 내용을 바탕으로 무엇부터 만들지 상담합니다.

프로젝트 문의하기

저녁 업무를 마치고 나서야 블로그 창을 여는 날이 많으신가요? 주제를 고르고 글을 쓰고 사진을 찾아 올리고 나면 하루가 훌쩍 지나 있습니다. 인스타그램에 같은 내용을 다시 만들어 올리는 일까지 더하면 정작 해야 할 일은 뒤로 밀립니다.

글을 쓰고 올리는 일을 AI 에이전트가 대신하는 것이 자동 발행입니다. AI 에이전트는 정해 둔 기준대로 글을 쓰고 올리는 일을 맡는 프로그램이라고 보시면 됩니다. 이 글은 자동 발행이 하루를 어떻게 바꾸는지, 어떤 글이 올라가는지, 비용은 무엇에 따라 달라지는지 설명합니다.

글 한 편을 올리려면 어떤 일이 따라옵니까?

글 한 편은 쓰는 일 하나로 끝나지 않습니다. 올리기까지 이어지는 일이 여러 가지입니다.

1. 오늘 무슨 이야기를 쓸지 주제를 정합니다.

2. 글을 쓰고 읽기 좋게 다듬습니다.

3. 글에 넣을 자료와 사진을 찾습니다. 상품이나 수업 사진 같은 것들입니다.

4. 홈페이지 블로그에 올리고 인스타그램에는 같은 내용을 다시 만들어 올립니다.

한 번이라면 어렵지 않습니다. 그런데 매일이 되면 주제 선정, 글 작성, 자료 수집, 게시가 하루의 큰 부분을 차지합니다. 고객 응대와 상담, 본업에 쓸 시간이 그만큼 줄어듭니다.

바쁜 주에는 글이 한두 번 빠지기도 합니다. 블로그가 한동안 멈춰 있으면 찾아온 분께 회사가 쉬고 있는 것처럼 보일 수 있습니다.

자동 발행을 쓰면 하루가 어떻게 달라집니까?

글을 쓰고 올리는 일을 AI 에이전트가 맡으면 그 시간이 하루에서 빠집니다. 달라지는 점은 이렇습니다.

1. 글 쓰는 시간이 사라집니다. 학원 원장님은 수업 준비에, 병원 원장님은 진료와 상담에, 쇼핑몰 대표님은 상품 준비에, 제조 회사 대표님은 거래처 응대에 그 시간을 쓰실 수 있습니다.

2. 바쁜 날에도 글이 빠지지 않습니다. 시험 기간이든 성수기든 정해 둔 날에 글이 올라갑니다.

3. 블로그와 인스타그램이 함께 움직입니다. 같은 글이 카드뉴스로 이어져 따로 만들 일이 없습니다. 카드뉴스는 사진과 짧은 문장을 넘겨 보는 인스타그램 게시물입니다.

4. 글이 차곡차곡 쌓입니다. 검색에서 회사를 발견할 수 있는 글이 하나씩 늘어납니다. 발행한 글 목록과 글별 방문 수, 검색어, 문의가 들어온 경로를 확인하는 방법도 함께 안내합니다.

5. 글 쓰는 직원을 따로 채용하지 않아도 됩니다.

하루가 달라진다는 것은 글 쓰는 시간이 줄어든다는 뜻만은 아닙니다. 그 시간에 고객을 만나고 다음 일을 준비하는 것이 가능해진다는 뜻입니다.

AI가 사실과 다른 내용을 쓰면 어떻게 합니까?

제품 사양이나 안내 내용이 틀리게 올라가면 곤란합니다. 그래서 고객이 넘겨 주신 자료 안의 내용으로만 쓰도록 만듭니다. 자료에 없는 수치나 사양은 글에 넣지 않습니다.

올리기 전에 직접 보고 승인하는 방식으로 시작하시면 틀린 곳을 올라가기 전에 수정하실 수 있습니다.

자동 발행을 쓰면 대표님이 직접 하는 일은 무엇입니까?

버튼 하나만 누르면 글이 알아서 나온다고 오해하실 수 있습니다. 실제로는 처음에 기준을 한 번 정해 주시는 일이 있습니다. 그 기준이 정해지면 나머지는 AI 에이전트가 맡습니다.

1. 어떤 주제의 글을 올릴지 정합니다. 글에 쓸 자료와 사진이 어디에 있는지도 알려 주시면 됩니다.

2. 어떤 말투로 쓰고 어떤 표현은 쓰지 않을지 정합니다.

3. 올리기 전에 직접 보고 승인할지, 믿고 맡길지 정합니다.

기준이 한 번 정해지고 나면 매번 설명하지 않으셔도 됩니다. 올라온 글이 마음에 들지 않으면 기준을 수정하시면 다음 글부터 달라집니다. 사업이 바뀌면 기준도 함께 바꾸시면 됩니다.

비용은 무엇에 따라 달라집니까?

정해진 가격표는 없습니다. 아래 다섯 가지에 따라 범위가 달라지기 때문에 상담 뒤 견적으로 안내합니다.

1. 글을 얼마나 자주 올릴지: 매일인지 일주일에 몇 번인지

2. 어디까지 이어 올릴지: 홈페이지 블로그만인지 인스타그램 카드뉴스까지인지

3. 글에 쓸 자료가 어디에 있는지: 정리된 자료가 이미 있는지, 새로 모아야 하는지

4. 올리기 전에 직접 승인하실지

5. 글을 올릴 홈페이지가 이미 있는지: 없으면 홈페이지를 만드는 일도 범위에 들어갑니다

범위를 잡으려면 다섯 가지만 알려 주시면 됩니다. 글을 만들 때 AI를 어떻게 쓰느냐에 따라 매달 이용료가 생기는 구성도 있고 생기지 않는 구성도 있습니다. 어느 쪽이 되는지는 견적을 안내할 때 먼저 말씀드립니다.

프로젝트를 마치면 글이 올라가는 장치와 계정을 모두 고객에게 넘겨드립니다.

문의하면 어떤 순서로 진행됩니까?

문의하신 뒤의 순서는 이렇습니다.

1. 문의를 남기시면 위의 다섯 가지를 중심으로 상담합니다.

2. 상담 내용에 맞춰 범위와 견적을 안내합니다. 견적을 보시고 진행할지는 고객이 정하시면 됩니다.

3. 진행하시기로 하면 글이 올라가는 장치를 만듭니다. 말투와 주제 기준도 이때 함께 담습니다.

4. 장치와 계정을 고객에게 넘겨드립니다.

네이버 블로그만 쓰고 있다면 어떻게 합니까?

네이버 블로그에도 올릴 수는 있습니다. 다만 글을 자동으로 올리면 이상 활동으로 보고 계정이 제한될 수 있어 권해 드리지 않습니다. 오래 쌓아 온 블로그가 막히면 손해가 크기 때문입니다.

그래서 자동 발행은 회사 홈페이지의 블로그에 올리는 방식을 기본으로 합니다. 기존 네이버 블로그는 지금처럼 직접 운영하셔도 됩니다. 홈페이지가 아직 없으시면 홈페이지를 만드는 일부터 함께 상담하실 수 있습니다. 쇼핑몰 솔루션은 쇼핑몰을 만들고 운영하게 해 주는 서비스입니다. 쓰시는 솔루션에 게시판이 있다면 거기에 올릴 수 있는지도 상담에서 확인합니다.

홈페이지에 올린 글이 네이버 검색에서 어떻게 보일지는 검색 서비스가 정하는 일이라 미리 말씀드릴 수 없습니다.

어떤 분께 잘 맞고 어떤 분께는 맞지 않습니까?

글을 꾸준히 올려야 하는데 쓸 시간이 없는 분께 잘 맞습니다.

1. 상품이나 서비스, 수업을 알리는 글을 꾸준히 올려야 하는 분

2. 블로그를 열어 두고 한동안 올리지 못해 마음에 걸리는 분

3. 글 쓰는 직원을 따로 두기 어려운 분

반대로 글 쓰는 일이 즐거우신 분께는 자동 발행이 필요하지 않을 수 있습니다. 한 달에 올릴 글이 몇 편 되지 않는 경우에도 자동 발행의 이점이 크지 않습니다.

그래서 글 발행을 자동으로 바꿔야 합니까?

글 쓰는 일에 하루의 상당한 시간을 쓰고 있어 본업이 밀리고 있다면 알아보실 만합니다.

엔소프 컴퍼니는 블로그 글쓰기에 쓰던 하루를 AI 에이전트로 되찾아 드립니다

블로그 글 때문에 하루가 사라지는 까닭은 주제를 정하고 쓰고 올리는 일을 전부 사람이 하고 있기 때문입니다. 고객이 원하실 경우 엔소프 컴퍼니는 고객 회사에 맞춰 이 일을 AI 에이전트가 하도록 만들어 드립니다. 어디까지 맡길지는 고객이 정하시면 됩니다.

완성된 모습은 이렇습니다.

1. 고객이 적어 두신 주제에 자료와 사진이 이어져 블로그 글이 올라갑니다.

2. 같은 글이 인스타그램 카드뉴스로도 이어져 따로 만들 필요가 없습니다.

3. 올리기 전에 직접 보고 승인하실 수도 있고 믿고 맡기실 수도 있습니다.

4. 고객이 정해 두신 주제 목록대로 글이 올라갑니다.

글 쓰는 사람을 따로 두지 않아도 되어 인건비 부담이 줄어듭니다. 글을 쓰고 올리던 시간은 본업과 상담에 쓰실 수 있습니다.

하루에 글 쓰는 데 얼마나 쓰고 계신지 알려 주시면 됩니다. 그 시간을 되찾는 방법을 엔소프 컴퍼니가 함께 찾아 드립니다.

프로젝트 문의하기

SEO는 들어보셨고 최근에는 GEO라는 말도 들으셨을 겁니다. SEO와 GEO가 같은 말인지, 따로 비용이 드는 일인지 궁금하실 겁니다.

SEO는 무엇을 하는 일입니까?

SEO(검색엔진최적화)는 구글 같은 검색 결과 목록에서 내 페이지가 위에 오르게 하는 일입니다. 이용자는 목록에서 페이지를 눌러 사이트로 들어옵니다.

글 제목에 이용자가 검색하는 말을 넣고 사이트 메뉴를 정리하는 일이 SEO입니다. 지금까지 홈페이지나 블로그를 관리하며 해 오신 작업도 SEO에 해당합니다. SEO의 성과는 검색 결과 화면에 내 페이지가 어떻게 보이는지로 확인합니다.

SEO 상태는 구글에 회사 이름을 검색해 보시면 바로 알 수 있습니다. 내 사이트가 결과에 나오지 않는다면 SEO 작업이 필요한 상태입니다.

GEO는 무엇을 하는 일입니까?

GEO(생성형 엔진 최적화)는 AI가 만든 답변 안에 내 글의 내용이 쓰이게 하는 일입니다. 이용자는 답변을 읽고 나서 사이트에 오지 않을 수도 있습니다.

AI가 답을 새로 만들어 내기 때문에 이름에 생성형이라는 말이 들어갑니다. SEO는 목록에 오르는 일이고 GEO는 답변 안에 쓰이는 일입니다.

이용자가 ChatGPT나 제미나이 같은 AI 서비스에 질문을 입력하면 답 하나가 바로 나옵니다. 그 답에 어떤 사이트의 글이 쓰였는지는 화면에 다 나오지 않을 수 있습니다. 이용자가 답만 보고 필요한 정보를 얻었다고 느끼면 사이트를 따로 찾지 않습니다.

GEO를 하려면 SEO도 함께해야 합니까?

GEO를 하려면 SEO도 함께하는 편이 맞습니다.

AI 서비스 중에는 답을 만들기 전에 검색으로 출처를 모으는 서비스가 있습니다. 이런 서비스에서는 검색 결과에 나오지 않는 페이지가 출처 후보에 오르기 어렵습니다. 서비스마다 방식이 달라서 모든 서비스가 그렇다고 말할 수는 없습니다. 검색으로 출처를 모으는 서비스에 내용이 쓰이게 하려면 SEO 없이 GEO만 먼저 할 수는 없습니다.

GEO를 다룬 2024년 학술 논문이 있습니다. 이 논문의 실험은 구글 검색 상위 5개 글만 AI에 출처로 주고 답을 만들게 했습니다. 실제 서비스 전부가 실험과 같은 방식으로 답을 만든다는 뜻은 아닙니다. 다만 검색 순위가 높은 글이 AI 답변의 재료가 되는 방식이 실제로 있다는 사례입니다. 그래서 지금 해 둔 SEO 작업이 GEO의 바탕이 됩니다.

AI 크롤러는 AI 서비스가 웹페이지 내용을 자동으로 수집하는 프로그램입니다. AI 수집 설정은 AI 크롤러가 내 사이트를 읽게 허용하는 작업이지만 설정만으로는 충분하지 않습니다. 검색으로 출처를 모으는 서비스는 검색 결과에 나오지 않는 페이지를 찾기 어렵기 때문입니다.

GEO 성과는 왜 숫자로 확인하기 어렵습니까?

검색 노출과 클릭은 서치콘솔에서 숫자로 나옵니다. 서치콘솔은 구글이 사이트 운영자에게 검색 성과를 보여주는 화면입니다.

같은 질문에도 AI 답변은 매번 달라집니다. 그래서 내 글이 답변에 쓰였는지를 정확히 측정하기 어렵습니다. 답변에 쓰인 횟수는 서치콘솔 같은 하나의 화면으로 확인하기 어렵습니다.

GEO를 맡기실 때는 개발사에 성과를 무엇으로 보고하는지 물어보시면 됩니다. 검색 순위와 클릭 수는 서치콘솔 숫자로 받아 볼 수 있지만 AI 답변에 쓰인 횟수는 같은 방식으로 받기 어렵습니다.

예전 SEO 방법을 GEO에도 그대로 쓸 수 있습니까?

논문 실험의 결과를 보면 일부는 효과가 없었지만 일부는 그대로 쓸 수 있습니다. 키워드(검색어)를 인위적으로 반복하는 방법은 AI 답변 노출에 거의 도움이 되지 않았습니다.

같은 실험에서는 글에 출처를 밝히고 인용문과 통계를 넣은 경우에 AI 답변에서 더 잘 노출됐습니다. 쉬운 문장으로 쓰고 문장을 매끄럽게 수정한 글도 노출이 늘었습니다. 모두 실험 조건에서의 결과라서 실제 서비스에서는 달라질 수 있습니다.

지금 쓰고 있는 글쓰기 방식을 모두 버릴 필요는 없습니다. 이용자가 읽기 편하게 쓰는 방식은 검색과 AI 답변 양쪽에서 쓸 수 있습니다.

그래서 SEO와 AI 수집 설정을 함께 시작해야 합니까?

SEO를 해 오셨다면 그 위에 AI 수집 설정을 더하는 순서가 맞습니다. SEO를 해 두지 않았다면 검색 결과에 나오는 작업을 먼저 시작하시면 됩니다. 검색 결과에 먼저 나오게 하고 그 위에 AI 수집 설정을 더하는 순서입니다.

서치콘솔 숫자는 SEO 변화를 비교하는 기준이 됩니다. 작업을 시작하기 전의 숫자를 기록해 두면 작업 뒤에 무엇이 달라졌는지 확인할 수 있습니다.

엔소프 컴퍼니는 SEO와 AI 검색을 함께 고려한 글 발행을 AI 에이전트로 개발해 드립니다

검색 결과 목록에 오르는 글과 AI 답변에 쓰이는 글은 같은 글일 수 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 글을 올리는 AI 에이전트를 개발해 드립니다. 올라가는 글은 검색 결과 목록과 AI 서비스가 모두 읽을 수 있는 형태입니다. AI 에이전트는 글 발행처럼 맡은 일을 스스로 이어 가는 AI 프로그램입니다.

고객이 주제를 정하면 AI 에이전트가 글을 만들어 올립니다. 상품 정보나 제품 사진 같은 고객의 자료를 바탕으로 하며 제목과 설명, 내부 링크, 구조화 데이터도 함께 넣습니다. 내부 링크는 사이트 안의 다른 글로 이어 주는 링크를 말합니다. 구조화 데이터는 글의 종류와 내용을 검색엔진과 AI에 알려 주는 표시 정보입니다.

같은 글은 인스타그램 카드뉴스로도 이어지고 서치콘솔 숫자는 정해진 날에 보고서로 모아 드립니다. 다만 카드뉴스와 보고서는 필요한 것만 고르실 수 있고 한 번에 모두 하실 필요는 없습니다.

글을 쓰고 올리던 직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 글이 올라가는 장치와 계정을 넘겨드리며 콘텐츠 작성 가이드와 초기 콘텐츠도 받으실 수 있습니다. 서치콘솔 연동과 지표 확인 방법은 안내해 드립니다.

지금 사이트에 SEO를 어디까지 해 두셨는지 알려 주시면 됩니다. 엔소프 컴퍼니가 그 SEO 작업 위에 AI 검색용 작업을 더하는 방법을 제안해 드립니다.

프로젝트 문의하기

견적서를 받아 보니 로그인에 별도 항목이 붙어 있습니다. 로그인 화면은 버튼 하나인데 왜 줄이 늘어나는지 궁금하실 겁니다. 그 줄은 화면 뒤에서 아이디와 비밀번호를 확인하고 회원별로 볼 수 있는 자료를 나누는 작업입니다.

로그인 버튼은 화면에서 보이는 부분입니다. 버튼이 실제로 동작하려면 화면 뒤에서 일을 처리할 서버가 있어야 합니다. 서버는 앱의 요청을 받아 정보를 저장하고 처리하는 컴퓨터입니다.

로그인 확인은 입력한 아이디와 비밀번호가 회원 본인의 것인지 보는 일입니다. 반면 회원 권한은 로그인한 회원이 볼 수 있는 화면과 자료의 범위를 나누는 일입니다. 이 글에서는 둘을 합쳐 「로그인과 회원 권한」이라고 부릅니다.

견적서에는 로그인과 회원 권한이 어떻게 적혀 있습니까?

엔소프 컴퍼니의 견적서는 로그인과 회원 권한을 비즈니스 서버 구축 항목 아래에 적습니다. 비즈니스 서버는 회원 정보와 주문 같은 자료를 저장하고 로그인 같은 처리를 맡는 서버입니다. 견적서의 정식 이름은 「비즈니스 서버의 인증·권한 경계 설계」이며 인증은 로그인 확인이고 권한 경계는 회원 권한입니다.

비즈니스 서버 구축 항목에는 API, 데이터, 인증이 들어 있으며 한 서버 안에서 함께 동작합니다. API는 화면과 서버가 자료를 주고받는 통로이고 데이터는 회원 정보와 주문 같은 자료가 쌓이는 곳입니다. 인증은 API라는 통로와 데이터에 누가 들어올 수 있는지를 확인하고 나누는 작업입니다.

견적서에는 인증이 한 줄로 적히는데 인증 줄에는 로그인 화면 외에 화면 뒤에서 하는 작업이 모두 들어갑니다. 비밀번호 확인, 회원별 접근 범위 설정, 비밀번호 찾기가 화면 뒤 작업의 예입니다.

그래서 견적서는 화면 디자인과 비즈니스 서버를 다른 줄에 적습니다. 화면 디자인 줄은 눈에 보이는 부분이고 비즈니스 서버 줄은 보이지 않는 곳에서 처리하는 작업입니다.

로그인 버튼을 만들어 달라는 요청은 무엇으로 이어집니까?

로그인 버튼을 만들어 달라는 요청은 화면 뒤의 세 가지 작업으로 이어집니다. 비밀번호 확인, 접근 범위 설정, 로그인 실패 안내이며 모두 비즈니스 서버가 맡는 일입니다.

서버는 입력된 아이디와 비밀번호를 저장된 자료와 비교합니다. 일치하면 그 회원이 볼 수 있는 화면과 자료를 구분합니다. 일치하지 않으면 다시 입력하도록 화면에 알립니다.

회원마다 볼 수 있는 화면과 자료가 다르면 회원 권한도 함께 설계해야 합니다. 일반 회원이 관리자 자료를 볼 수 있으면 안 됩니다. 그래서 회원마다 보이는 자료가 다른 서비스는 로그인 확인과 회원 권한을 함께 설계합니다.

로그인과 회원 권한 설계에는 왜 별도 작업이 붙습니까?

로그인 화면은 서비스마다 비슷해 보입니다. 그러나 화면 뒤 작업은 서비스마다 요구가 다릅니다. 회원 등급이 몇 개인지와 관리자 화면이 따로 있는지에 따라 접근 범위가 달라집니다.

SSO는 한 번 로그인하면 여러 서비스를 이어서 쓰게 하는 방식입니다. 다단계 인증은 비밀번호 외에 확인 절차를 하나 더 거치는 방식입니다. SSO나 다단계 인증이 요구사항에 들어가면 설계할 부분이 늘어납니다.

엔소프 컴퍼니의 견적서에서 로그인에 별도 줄이 붙는 이유는 요구사항마다 설계가 달라지기 때문입니다. 로그인 화면이 같아 보여도 회원 확인과 접근 범위는 요구사항마다 새로 설계해야 합니다.

로그인과 회원 권한 설계를 빼면 무엇이 멈춥니까?

비밀번호 찾기를 설계에 넣지 않으면 비밀번호를 잊은 회원이 계정을 스스로 되찾지 못합니다. 이 경우 회원은 계정을 다시 만들거나 직접 문의해야 합니다.

로그인 시도 횟수를 제한하지 않으면 비밀번호를 무작위로 계속 입력하는 공격을 막지 못합니다. 로그인 시도 횟수 제한은 비밀번호 무작위 입력 공격을 막기 위한 별도 설계입니다.

로그인과 회원 권한 설계가 없으면 다단계 인증을 넣을 곳도 없습니다. 다단계 인증이 있으면 비밀번호가 알려져도 추가 확인을 통과해야 로그인이 됩니다.

견적서는 비밀번호 찾기와 시도 횟수 제한, 다단계 인증을 화면 디자인과 따로 적습니다. 세 가지 모두 로그인과 회원 권한 설계 안에서 함께 설계하는 작업이기 때문입니다. 비밀번호 찾기와 시도 제한, 다단계 인증이 빠지면 계정을 지킬 방법이 줄어듭니다.

견적서의 로그인 항목에서 무엇을 확인해야 합니까?

견적서에서 확인할 것은 두 가지입니다. 비즈니스 서버 항목에 인증이 들어 있는지와 인증에 비밀번호 찾기와 시도 제한이 들어 있는지입니다.

항목 이름이 달라도 같은 작업일 수 있습니다. 이름보다 항목 안에 적힌 작업 내용을 먼저 보시면 됩니다.

인증 항목이 있다면 포함 범위를 물어보시면 됩니다. 로그인 화면만 포함하는지 비밀번호 찾기와 시도 제한까지 포함하는지가 다릅니다. 다단계 인증이 필요하다면 이때 함께 물어보시면 됩니다.

인증 항목이 없다면 그 이유를 물어보시면 됩니다. 로그인 화면만 만들고 서버 쪽 작업은 다른 계약으로 두었을 수 있습니다. 그렇다면 서버 작업을 어느 단계에서 추가할지 확인하시면 됩니다.

그래서 견적서에서 로그인과 회원 권한 항목을 먼저 확인해야 합니까?

화면 시안을 먼저 받으셨다면 계약 전에 로그인과 회원 권한 항목을 확인해 볼 만합니다. 시안에는 로그인 화면만 보이고 화면 뒤 작업은 보이지 않기 때문입니다.

비밀번호 찾기와 시도 제한이 빠진 채 계약하면 계약 후에 별도 작업으로 추가해야 합니다. 그러면 일정과 비용을 다시 협의해야 할 수 있습니다.

시안은 눈으로 볼 수 있지만 화면 뒤 작업은 견적서에 적힌 내용으로만 확인할 수 있습니다. 화면 시안보다 먼저 견적서에 로그인과 회원 권한 작업이 적혀 있는지 확인하시면 됩니다.

엔소프 컴퍼니는 로그인 뒤에 이어지는 회원 운영을 AI 에이전트로 개발해 드립니다

로그인을 만들고 나면 가입 접수와 회원 문의 응답, 숫자 확인이 매달 되풀이됩니다. 고객이 원하실 경우 엔소프 컴퍼니는 이 반복 업무를 처리하는 AI 에이전트를 개발해 드립니다. AI 에이전트는 고객이 정한 순서대로 회원 업무 같은 반복 일을 처리하는 AI 프로그램입니다.

먼저 가입과 문의로 쌓이는 회원 정보는 쓰시던 표나 문서에 자동으로 모입니다. 같은 내용을 두 곳에 다시 적을 필요가 없습니다.

회원 문의와 신청은 종류별로 나뉘어 담당자에게 모입니다. 매달 가입자와 이용 숫자는 보고서로 묶여 나옵니다.

어떤 일부터 맡기실지는 고객이 정하시면 되고 한 가지만 시작하셔도 됩니다. 가입 내용을 옮겨 적고 보고서를 만들던 직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 스토어 등록을 마친 앱과 비즈니스 서버, 계정을 고객에게 넘겨드립니다. AI 에이전트 개발을 맡기셨다면 완성된 AI 에이전트도 받으실 수 있습니다.

로그인을 만드신 뒤에 직접 처리하실 회원 업무가 있다면 엔소프 컴퍼니에 알려 주시면 됩니다.

프로젝트 문의하기

에이전틱 AI라는 말을 최근 회의나 기사에서 보셨을 겁니다. 에이전틱 AI가 챗봇이나 자동화 프로그램과 어떻게 다른지는 못 들으셨을 수 있습니다. 고객이 이미 쓰고 계신 프로그램과 같은 것인지 궁금하실 겁니다.

에이전틱 AI는 무엇이고 챗봇과 어떻게 다릅니까?

에이전틱 AI는 특정 목표를 최소한의 감독으로 스스로 달성하는 인공지능 시스템입니다.

한 번 지시하면 그 뒤 과정은 AI가 스스로 진행합니다. 에이전틱은 독립적으로 목적을 가지고 스스로 판단해 움직인다는 뜻의 말입니다. 에이전틱 AI는 사람이 판단하는 방식을 따라 문제를 푸는 프로그램, 곧 AI 에이전트로 이루어집니다.

기존 AI 모델은 미리 정해 둔 규칙 안에서 움직입니다. 규칙을 벗어난 상황에서는 사람이 다시 개입해야 합니다. 에이전틱 AI는 목표를 향해 스스로 판단하고 방식을 바꿉니다.

챗봇에 쓰이는 거대언어모델(LLM)은 방대한 글을 학습한 AI입니다. 사람의 말을 이해하고 문장을 만듭니다. LLM 혼자서는 다른 프로그램이나 데이터베이스와 직접 연결할 수 없습니다. 데이터베이스는 자료를 모아 두는 저장소입니다. LLM 혼자서는 직접 연결할 수 없는 프로그램과도 에이전틱 AI는 연결해서 일합니다.

에이전틱 AI는 어떤 업무에 맞습니까?

에이전틱 AI는 장기적인 목표를 유지하면서 움직입니다. 여러 단계로 이루어진 문제 해결 과정을 관리하고 진행 상황도 중간에 계속 추적할 수 있습니다. 먼저 검토할 업무는 순서가 정해진 반복 업무입니다.

고객의 회사에도 매주 비슷한 순서로 되풀이하는 업무가 있을 수 있습니다. 주문을 확인하고 재고를 점검하는 일이 그런 예입니다. 고객 문의에 답을 보내는 일도 같은 순서로 되풀이됩니다. 주문 확인과 재고 점검과 문의 답변은 단계마다 사람이 새로 판단할 일이 적습니다.

반대로 매번 상황이 달라져 사람의 판단이 꼭 필요한 업무도 있습니다. 거래처마다 조건이 다른 협상이 그렇습니다. 데이터가 흩어져 있거나 기록조차 없는 업무도 마찬가지입니다. 협상이나 기록이 없는 업무는 에이전틱 AI에 그대로 맡기기 어렵습니다.

또 하나의 기준은 지금 쓰시는 업무 프로그램끼리 데이터를 주고받을 수 있는지입니다. 주문 프로그램과 재고 프로그램이 서로 연결되어 있지 않으면 에이전틱 AI는 둘 사이를 오갈 수 없습니다. 프로그램끼리 데이터를 주고받는 연결이 먼저 있어야 에이전틱 AI가 목표를 스스로 수행할 수 있습니다.

고객의 회사는 에이전틱 AI를 어떻게 도입합니까?

도입 전에 먼저 할 일은 지금 반복하는 업무를 하나씩 기록하는 일입니다. 어느 구간에서 같은 작업을 되풀이하는지 표시합니다.

업무를 기록한 다음에는 에이전틱 AI에 맡길 업무와 사람이 할 업무를 나눕니다. 판단이 계속 바뀌는 업무는 사람 몫으로 남깁니다. 순서가 일정한 업무는 에이전틱 AI에 맡길 후보가 됩니다.

맡길 후보를 한 번에 모두 도입할 필요는 없습니다. 시간이 많이 드는 반복 업무부터 순서를 정하는 방식이 있습니다. 작은 범위에서 먼저 써 보시고 다음 업무로 넓혀 갑니다.

도입 전에 업무 프로그램끼리 데이터가 오가는지도 확인합니다. 한 프로그램에 입력한 내용을 다른 프로그램에 손으로 옮겨 적고 있다면 연결이 없는 것입니다. 연결이 없으면 연결부터 만든 다음에 도입합니다.

고객은 에이전틱 AI를 도입한 뒤에 무엇을 확인해야 합니까?

도입 뒤에는 처음 맡긴 목표를 실제로 달성하는지 담당자가 확인합니다. 목표를 이루는 방식이 바뀌었는지도 함께 보는데 방식이 바뀌면 결과를 예측하기 어려워질 수 있습니다.

사람이 다시 개입해야 하는 상황이 무엇인지도 미리 정해 둡니다. 예상하지 못한 상황에서 에이전틱 AI가 멈추는지를 확인합니다. 잘못된 판단을 그대로 진행하지 않는지도 봅니다. 사람이 개입할 상황을 알아 두면 담당자가 무엇을 지켜봐야 하는지 분명해집니다.

프로그램 사이의 연결이 꾸준히 동작하는지도 주기적으로 확인합니다. 연결이 끊기면 에이전틱 AI가 목표를 수행하다 중간에 멈출 수 있습니다. 그래서 연결 상태를 담당자가 정기적으로 살펴보는 절차가 필요합니다.

마지막으로 도입 결과를 정기적으로 검토하는 날을 따로 정합니다. 업무가 달라지면 에이전틱 AI에 맡긴 목표도 함께 바뀌어야 합니다. 검토하는 날이 없으면 상황이 바뀌어도 에이전틱 AI는 예전 목표대로 움직입니다.

그래서 에이전틱 AI를 지금 도입해야 합니까?

반복 업무의 순서가 정해져 있고 업무 프로그램끼리 데이터가 오간다면 도입을 알아볼 만합니다. 매번 상황이 달라 사람의 판단이 중심인 업무라면 도입을 서두를 이유가 없습니다.

먼저 반복 업무를 적어 보시면 도입할 업무가 있는지 알 수 있습니다. 반복 업무를 적어 두면 어떤 프로그램끼리 연결해야 하는지도 함께 드러납니다.

에이전틱 AI는 순서가 정해진 반복 업무와 서로 연결된 프로그램이 있을 때 먼저 맞습니다.

엔소프 컴퍼니는 시키면 알아서 일하는 AI 에이전트를 고객의 반복 업무에 맞춰 개발해 드립니다

시키면 알아서 일하는 AI가 회사와 무슨 상관인지는 반복 업무 하나만 떠올려도 알 수 있습니다. 매주 같은 순서로 되풀이되는 그 일을 에이전틱 AI에 맡길 수 있는지 검토할 수 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 그 일을 맡는 AI 에이전트를 개발해 드립니다.

쓰시던 업무 프로그램은 그대로 두고 서로 연결할 수 있습니다. 같은 내용을 두 번 옮겨 적는 일을 줄일 수 있습니다.

주문 확인이나 재고 점검, 문의 접수처럼 순서가 정해진 일부터 맡기는 방식도 가능합니다. 한 번에 모두 맡기실 필요는 없고 하나부터 시작하실 수 있습니다. 처리 결과를 확정하기 전에 직접 보고 승인하실 수도 있고 믿고 맡기실 수도 있습니다.

반복 업무에 쓰던 직원의 시간과 인건비가 줄어듭니다. 그 시간에 직원은 사람의 판단이 필요한 일을 맡게 됩니다.

프로젝트를 마치면 고객이 선택하신 범위의 동작하는 시스템과 계정을 넘겨드립니다.

엔소프 컴퍼니는 고객의 업무를 에이전틱 AI에 맡길 수 있는지 살펴 드립니다. 고객의 회사에서 가장 많은 시간이 드는 반복 업무를 알려 주시면 됩니다.

프로젝트 문의하기

임대 쇼핑몰로 사업을 시작하셨고 매출이 꾸준히 늘고 있습니다. 그러면 자체 쇼핑몰로 옮길 시점이 궁금해집니다.

그런데 그 판단을 매출 숫자 하나로는 내리기 어렵습니다. 지금 쌓인 회원 데이터와 운영 여건을 함께 봐야 합니다.

왜 매출이 늘면 이 고민이 생깁니까?

매출이 늘면 임대 플랫폼의 수수료 부담과 트래픽 의존이 함께 커집니다. 트래픽은 쇼핑몰을 찾아오는 방문자 수를 말합니다. 전환 고민은 회원 데이터 활용, 매출 대비 운영 비용, 브랜드와 콘텐츠 확장 필요에서 시작됩니다.

회원 데이터를 얼마나 쌓았고 어떻게 쓰고 싶으신지가 첫째 기준이고 매출 규모와 운영 비용을 비교하는 것이 둘째 기준입니다. 셋째 기준은 브랜드와 콘텐츠를 독립적으로 넓히고 싶은지입니다.

임대 플랫폼에서는 노출 순서와 정책을 플랫폼이 정하기 때문에 매출이 커질수록 정책에 좌우되는 비중도 커집니다. 정책이 바뀌면 판매 흐름이 그대로 영향을 받습니다.

그래서 매출이 일정 수준에 이르면 전환을 검토하게 됩니다. 다만 그 시점은 매출 규모만으로 정해지지 않습니다. 다음 기준을 하나씩 확인합니다.

임대 쇼핑몰과 자체 쇼핑몰은 구조가 어떻게 다릅니까?

임대 쇼핑몰은 플랫폼이 만든 화면과 결제 구조를 그대로 쓰지만 자체 쇼핑몰은 화면과 기능을 고객이 원하는 대로 설계합니다. 화면과 결제 구조를 누가 설계하느냐가 운영 방식 전체에 영향을 줍니다.

임대 쇼핑몰은 상품 등록, 결제, 배송 조회 같은 기본 기능을 플랫폼이 미리 만들어 둡니다. 고객은 이 틀 안에서 상품을 올리고 운영합니다. 디자인이나 화면 구성을 바꾸는 범위는 플랫폼이 허용한 만큼으로 제한됩니다.

자체 쇼핑몰은 화면 구조부터 결제 연동까지 고객이 원하는 방식으로 만듭니다. 결제 연동은 쇼핑몰에 결제 기능을 이어 붙이는 일입니다. 그만큼 도메인과 브랜드를 독립적으로 운영할 수 있습니다. 도메인은 쇼핑몰의 인터넷 주소입니다. 다만 호스팅과 보안, 결제 연동, 유지보수를 직접 책임져야 합니다. 호스팅은 쇼핑몰을 인터넷에 올려 두는 공간을 빌리는 서비스입니다.

두 구조의 차이는 데이터를 다루는 방식에서도 나타납니다. 임대 쇼핑몰과 자체 쇼핑몰은 회원 데이터를 쌓는 곳이 다릅니다. 그만큼 쓸 수 있는 범위도 서로 다릅니다.

회원 데이터를 기준으로 판단하는 법

회원의 연락처와 구매 이력을 직접 마케팅에 써야 한다면 자체 쇼핑몰을 검토할 이유가 커집니다. 반대로 아직 이런 계획이 없으면 이 기준은 당장 급하지 않습니다. 회원 데이터 활용 여부는 매출 규모와 별개로 따집니다.

임대 쇼핑몰에서는 회원 정보를 열람하고 활용하는 범위가 플랫폼 정책 안으로 제한될 수 있습니다. 문자나 이메일로 직접 연락하는 마케팅을 하기 어려울 수 있습니다. 재구매를 유도하는 방식도 플랫폼이 제공하는 기능 안에서만 가능합니다.

자체 쇼핑몰에서는 회원 데이터를 직접 모으고 분석할 수 있습니다. 회원 등급이나 멤버십처럼 재구매를 유도하는 장치도 원하는 방식으로 만들 수 있습니다. 문자나 이메일로 직접 연락하는 마케팅도 바로 시작할 수 있습니다.

먼저 지금의 마케팅 방식에 회원 연락처와 구매 이력이 필요한지 확인하십시오. 재구매 유도나 회원 등급 관리를 계획하고 계시면 회원 데이터 활용 범위가 중요한 기준이 됩니다. 아직 이런 계획이 없으시면 서두르실 이유는 없습니다.

매출과 운영 비용을 기준으로 판단하는 법

매출이 늘면 임대 플랫폼에 내는 수수료도 함께 늘어나지만 자체 쇼핑몰은 수수료 대신 운영 비용을 직접 부담합니다. 임대 쇼핑몰의 수수료와 자체 쇼핑몰의 운영 비용은 내는 방식이 다릅니다.

임대 쇼핑몰은 매출 중 일부를 수수료로 내는 구조입니다. 매출이 커질수록 수수료로 나가는 금액도 함께 커집니다. 수수료 비율이나 정책은 플랫폼이 정합니다.

자체 쇼핑몰은 수수료 대신 호스팅, 보안, 결제 연동, 유지보수 비용을 직접 부담합니다. 이 비용은 쇼핑몰 규모와 기능에 따라 다릅니다. 운영할 인력이나 예산을 따로 마련해야 합니다.

그래서 이 기준은 수수료와 운영 비용을 나란히 비교해야 판단이 섭니다. 매출이 늘어나는 속도와 운영할 여력을 함께 보셔야 합니다. 둘 중 어느 쪽이 더 부담스러운지가 판단의 중심이 됩니다.

브랜드와 콘텐츠 확장을 기준으로 판단하는 법

브랜드를 독립적으로 보여주고 콘텐츠로 트래픽을 직접 모아야 하는 상황이면 자체 쇼핑몰 쪽 구조가 더 맞습니다. 아직 필요가 없으시면 브랜드와 콘텐츠 기준은 뒤로 미루셔도 되지만 매출이나 회원 데이터와는 별개로 따져 보셔야 합니다.

임대 쇼핑몰에서는 화면 구성과 브랜드 노출 방식이 플랫폼이 정한 틀 안으로 제한됩니다. 다른 판매자와 같은 화면 구조를 쓰는 경우도 있습니다. 브랜드를 독립적으로 보여주기는 어려울 수 있습니다.

자체 쇼핑몰에서는 화면 디자인과 브랜드 표현을 원하는 대로 구성할 수 있습니다. 회원을 직접 쇼핑몰로 불러올 콘텐츠도 자유롭게 쌓을 수 있습니다. 트래픽을 플랫폼의 노출 알고리즘에만 맡기지 않아도 됩니다. 노출 알고리즘은 어떤 상품을 먼저 보여 줄지 정하는 플랫폼의 계산 방식입니다.

브랜드를 독립적으로 키우고 싶은지, 콘텐츠로 트래픽을 직접 쌓고 싶은지를 먼저 정해야 합니다. 브랜드와 콘텐츠 확장 필요가 뚜렷하면 쇼핑몰과 콘텐츠 구조를 함께 설계합니다. 세 기준을 모두 살펴보신 뒤에 전환 시점을 정하시면 됩니다.

그래서 지금 전환을 결정해야 합니까?

세 가지 기준 가운데 해당하는 것이 있다면 전환을 검토해 볼 만합니다. 매출이 늘고 있다는 사실만으로는 답이 나오지 않습니다.

회원 데이터 활용, 수수료와 운영 비용, 브랜드와 콘텐츠 확장입니다. 이 세 기준은 지금 상황에서도 바로 따져 볼 수 있습니다.

임대 쇼핑몰을 유지하는 동안 수수료는 매출에 따라 계속 발생합니다. 회원 데이터도 임대 플랫폼 안에만 계속 쌓이게 됩니다. 나중에 옮기려 하면 쌓인 데이터를 그대로 옮기지 못할 수 있습니다.

전환할 때의 순서는 이렇습니다. 세 기준을 지금 점검하고 전환이 맞다면 구조 설계부터 시작하는 것입니다.

엔소프 컴퍼니는 자체 쇼핑몰로 옮긴 뒤의 운영 업무를 AI 에이전트로 개발해 드립니다

자체 쇼핑몰로 옮기면 직접 관리할 운영 업무가 늘어납니다. 상품 글을 쓰고 SNS에 올리고 주문과 회원 데이터를 정리하는 일입니다. 고객이 원하실 경우 엔소프 컴퍼니는 이 반복 업무를 AI 에이전트가 맡는 쇼핑몰과 블로그를 함께 설계해 드립니다. AI 에이전트는 쇼핑몰 업무를 정해 둔 기준대로 대신 처리하는 프로그램입니다.

고객이 원하시는 글 주제에 맞춰 쇼핑몰의 상품 정보와 제품 사진으로 상품 소개 글을 만들고 올립니다. 검색엔진이 읽을 수 있는 형식이라 상품을 등록할 때마다 소개 글이 함께 쌓입니다.

같은 상품 정보와 사진은 인스타그램 카드뉴스와 게시물로도 올라가 블로그와 따로 만들 필요가 없습니다. 카드뉴스는 사진과 짧은 문장을 넘겨 보는 인스타그램 게시물입니다. 올리기 전에 보고 승인하는 방식이 기본이며 원하시면 자동으로 올리는 방식도 가능합니다.

주문과 회원 데이터는 쓰시는 도구와 이어져 같은 내용을 두 번 옮겨 적지 않게 됩니다.

세 가지를 한 번에 다 하실 필요는 없고 가장 손이 많이 가는 업무 하나부터 시작하셔도 됩니다. 무엇을 맡기고 어디서 사람이 확인할지는 고객이 정하시면 됩니다.

직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 배포된 쇼핑몰과 블로그, 동작하는 자동화 시스템을 넘겨드립니다. 배포는 완성된 쇼핑몰을 실제 인터넷 주소에 공개하는 일입니다. 계정 인수인계도 함께 해 드립니다.

지금 손으로 반복하고 계신 쇼핑몰 업무가 있다면 알려 주시면 됩니다. 그 일을 AI 에이전트에게 맡기는 방법을 엔소프 컴퍼니가 함께 찾아 드립니다.

프로젝트 문의하기

고객의 업종이나 서비스를 AI에 물어보신 적이 있습니까? 요즘 AI는 검색 결과 목록을 보여주는 대신 답변을 바로 만들어 보여줍니다. 그 답변 안에 고객의 회사 이름이 없을 수 있습니다.

홈페이지를 잘 만들어 두어도 AI 답변에는 쓰이지 않을 수 있습니다. 검색에서는 상위에 뜨던 글이 AI 답변에서는 빠질 수 있습니다. AI 답변에 글이 쓰이는 조건을 모르면 무엇부터 수정해야 할지 알 수 없습니다.

GEO는 검색 순위를 올리는 일과 다릅니다

GEO는 Generative Engine Optimization의 줄임말입니다. AI가 만든 답변 안에 고객의 글이 쓰이도록 맞추는 일을 뜻합니다.

검색 결과 목록에서 순위를 올리는 일과는 다른 일입니다.

검색 결과 순위를 올리는 작업인 검색 최적화(SEO)만 해 두어도 AI 답변에는 쓰이지 않을 수 있습니다. 반대로 AI 답변에 맞춰 글을 수정해도 검색 순위가 그대로 오르지는 않습니다. 그래서 검색 최적화 결과가 괜찮아도 AI 답변 쪽은 따로 봐야 합니다.

AI는 답변을 어떤 순서로 만듭니까?

AI 답변 엔진은 질문에 답을 만들어 주는 AI 서비스입니다. 질문을 받으면 여러 출처를 먼저 모읍니다. 그다음 그 출처들의 내용을 섞어 하나의 답을 만듭니다.

고객의 글이 답에 쓰이려면 먼저 출처로 모여야 합니다. 출처로 모인 다음에는 답에 넣기 좋은 형태여야 합니다. 두 조건 가운데 하나만 맞아서는 답에 쓰이기 어렵습니다. 출처로 모이지 못하면 글을 잘 써도 답에 쓰일 기회조차 없습니다.

문장을 다듬으면 답변 인용이 얼마나 달라집니까?

프린스턴대 연구진은 질문 10,000개로 GEO-bench라는 실험을 만들었습니다. 구글 상위 다섯 개 출처를 AI가 보는 자료로 고정하고 그중 한 출처만 아홉 가지 방법으로 다시 썼습니다. 그렇게 다시 쓴 출처가 답에 얼마나 쓰이는지를 측정했습니다.

문장을 다듬는 것만으로도 답에 쓰이는 분량이 28퍼센트 늘었는데 새 내용을 더하지 않고 문법과 흐름만 수정한 경우입니다. 28퍼센트는 아홉 가지 방법을 비교했을 때 나온 차이입니다.

인용문과 통계를 더하면 어떻게 됩니까?

같은 실험에서 인용문을 더한 글은 답에 쓰이는 분량이 41퍼센트 늘었습니다. 아홉 가지 방법 가운데 가장 높은 수치입니다. 통계를 더한 글은 31퍼센트 늘었습니다.

키워드를 인위적으로 반복하는 방법은 효과가 없었습니다. 검색 순위를 올리려고 쓰던 키워드 반복은 GEO-bench 실험의 AI 답변에서 효과가 없었습니다.

효과를 숫자로 확인하기 어려운 이유는 무엇입니까?

AI 답변에 고객의 글이 인용되었는지는 재현 가능하게 측정하기 어렵습니다. 같은 질문에도 답이 매번 달라질 수 있습니다. 인용을 추적하는 표준 도구도 아직 없습니다.

반면 검색 노출과 클릭은 서치 콘솔에서 숫자로 확인할 수 있습니다. 서치 콘솔은 구글이 사이트 운영자에게 검색 성과를 보여주는 화면입니다. 서치 콘솔에서는 날짜별로 달라지는 수치를 그래프로 볼 수 있습니다. 그만큼 검색 쪽 결과는 수치로 설명하기가 더 쉽습니다.

그래서 GEO는 지금 준비해야 합니까?

효과를 숫자로 측정하기 어렵다는 이유만으로 미룰 일은 아닙니다. 같은 질문을 AI에 여러 번 물어 답변에 고객의 사이트가 나오는지 먼저 확인할 수 있습니다.

업체와 서비스를 검색창 대신 AI에게 묻는 사람도 있습니다. AI 답변 엔진은 출처로 모은 글을 바탕으로 답을 만듭니다. 그 출처에 고객의 사이트가 없으면 답변에도 고객의 회사는 나오지 않습니다.

AI가 읽기 좋게 글을 맞추는 시기가 늦어지면 다른 회사의 글이 먼저 출처로 모일 수 있습니다.

AI 답변에 대비하는 방향은 이렇습니다. 검색 최적화를 기본으로 두고 AI가 읽을 수 있는 구조를 지금 함께 갖추는 것입니다.

엔소프 컴퍼니는 GEO에 맞는 글이 꾸준히 올라가는 구조를 AI 에이전트로 개발해 드립니다

AI가 답을 만들 때 읽을 글이 있어야 하기 때문에 GEO가 지금 필요합니다. 글이 있어도 질문과 답이 분명하지 않으면 읽히기 어렵습니다. 고객이 원하실 경우 엔소프 컴퍼니는 AI가 읽기 좋은 글이 꾸준히 쌓이는 구조를 AI 에이전트로 개발해 드립니다. AI 에이전트는 글 쓰기와 올리기 같은 일을 스스로 이어 가는 AI 프로그램입니다.

고객이 정하신 주제는 소제목마다 바로 답이 나오는 구조로 써서 올립니다. 상품 정보와 사진도 이어 쓸 수 있습니다.

근거가 있는 내용에는 출처를 함께 적어 AI 크롤러가 읽을 수 있는 구조를 갖춥니다. AI 크롤러는 AI 서비스가 웹페이지 내용을 자동으로 읽어 가는 프로그램입니다.

서치 콘솔의 검색 노출과 클릭 숫자는 보고서로 모입니다.

무엇부터 시작할지는 고객이 정하시면 됩니다.

직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 콘텐츠 작성 가이드와 초기 콘텐츠를 고객에게 전달합니다. 서치 콘솔에 사이트를 연결하는 방법과 수치 확인 방법까지 안내해 드립니다.

운영 중인 사이트 주소를 알려 주시면 GEO를 어디부터 시작할지 엔소프 컴퍼니가 함께 살펴 드립니다.

프로젝트 문의하기

앱 개발 견적서에 회원가입 화면과 주문 화면 아래로 줄이 하나 더 있습니다. 운영 대시보드, 관리자 화면, 어드민, 백오피스 같은 이름이 붙은 줄입니다.

그 줄은 앱을 쓰는 회원이 아니라 회사 직원이 쓰는 화면을 가리킵니다. 회원 화면과 따로 만드는 화면이라서 견적서에도 따로 적힐 수 있습니다.

비즈니스 대시보드는 어떤 화면입니까?

비즈니스 대시보드는 회사 직원이 매출과 주문 수, 가입 회원 수를 한 화면에서 보는 화면입니다. 앱을 쓰는 회원에게는 보이지 않습니다.

견적서에 적힌 이름은 달라도 같은 종류의 화면을 가리킵니다. 어드민은 관리자를 뜻하는 영어 administrator를 줄인 말입니다. 백오피스는 회원에게 보이지 않는 직원용 화면을 뜻하며 이 글에서는 같은 종류의 화면을 비즈니스 대시보드로 부릅니다.

회원 관리와 매출 확인을 원하면 왜 비즈니스 대시보드가 필요합니까?

회원이 몇 명 가입했는지와 주문이 얼마나 들어왔는지는 앱 회원 화면에 나오지 않습니다. 회원 수와 매출을 보려면 그 숫자를 모아 보여 주는 화면이 필요합니다.

회원 관리나 주문 관리가 되는 앱을 요청하셨다면 비즈니스 대시보드도 필요한 상태입니다. 직원이 관리할 회원과 주문을 한곳에서 확인할 화면이 없기 때문입니다.

대시보드에 보이는 숫자는 앱 서버나 결제·주문 시스템에 쌓인 정보에서 나옵니다. 앱 서버는 앱이 쓰는 정보를 저장하고 처리하는 컴퓨터입니다. 비즈니스 대시보드는 그 정보를 모아 숫자와 목록으로 보여 주는 화면입니다.

숫자를 모으고 화면에 보여 주는 개발은 앱 화면 개발과 따로 필요합니다. 그래서 견적서에 별도 줄로 적힐 수 있습니다.

매출 기준을 정하지 않으면 어떤 일이 생깁니까?

기준 없이 화면부터 만들면 같은 화면을 보면서도 사람마다 다른 매출을 말하게 됩니다. 매출은 결제 금액 전체로 계산할 수도 있고 환불을 뺀 금액으로 계산할 수도 있기 때문입니다.

그래서 화면을 그리기 전에 어떤 숫자를 어떤 기준으로 계산할지 정해야 합니다. 이 일을 지표 정의라고 부릅니다. 지표는 매출이나 가입 회원 수처럼 사업 상태를 보여 주는 숫자입니다.

환불이 있으면 결제 기준 매출과 환불을 뺀 매출은 금액이 다릅니다. 기준을 정해 두지 않으면 주문을 받는 사람과 장부를 보는 사람이 서로 다른 매출을 말합니다.

비즈니스 대시보드가 없으면 매출과 주문 숫자를 어떻게 확인합니까?

시스템마다 자료를 내려받아 엑셀 같은 표 문서에 직접 옮겨 합쳐야 합니다. 결제 시스템과 주문 시스템에서 받은 숫자를 매번 같은 표 문서에 옮겨 적는 방식입니다.

표 문서를 사람마다 따로 관리하면 같은 날의 매출도 문서마다 다를 수 있습니다. 회원 관리와 매출 확인을 앱 안에서 바로 보려던 요청은 비즈니스 대시보드 없이는 채워지지 않습니다.

이상 알림과 열람 권한은 왜 따로 정합니까?

이상 알림은 주문이 갑자기 줄거나 환불이 늘었을 때 직원에게 알려 주는 기능입니다. 정해 둔 범위를 숫자가 벗어나면 알리는 방식이고 견적서에는 이상 감지로 적힐 수 있습니다.

이상 알림이 없으면 직원이 숫자를 직접 열어 보기 전까지 주문 감소나 환불 증가를 알 수 없습니다. 어떤 숫자가 어느 범위를 벗어나면 알릴지는 고객이 정하시는 기준입니다.

열람 권한은 누가 어떤 숫자를 볼 수 있는지 정하는 일입니다. 대표가 보는 숫자와 매장 직원이 보는 숫자가 다를 수 있기 때문입니다.

이상 알림 범위와 열람 권한을 정하지 않으면 비즈니스 대시보드는 쓰기 어렵습니다.

견적서에서 비즈니스 대시보드는 무엇을 확인합니까?

견적서의 비즈니스 대시보드 줄에서는 두 가지를 확인합니다. 하나는 보여 줄 숫자의 목록과 그 숫자를 볼 수 있는 사람이 적혀 있는지입니다. 다른 하나는 숫자가 정해 둔 범위를 벗어나면 알려 주는 이상 알림이 포함되어 있는지입니다.

같은 이름의 줄이어도 견적마다 들어가는 화면이 다릅니다. 가입 회원 목록만 보이는 화면이 있고 매출과 주문 수에 이상 알림까지 들어가는 화면이 있습니다.

숫자 목록이 적혀 있지 않다면 어떤 숫자가 보이는지 개발사에 물어보시면 됩니다. 답변은 견적서에 적어 달라고 요청하시면 됩니다.

그래서 비즈니스 대시보드는 지금 만들어야 합니까?

회원 관리와 매출 확인을 앱에서 하려면 비즈니스 대시보드가 필요합니다. 그 숫자를 볼 화면이 없으면 직원이 표 문서로 직접 모아야 하기 때문입니다.

숫자를 많이 넣을수록 개발할 화면과 연결할 자료가 늘어납니다. 가장 먼저 보고 싶은 숫자 몇 개로 시작하고 나중에 추가하는 방식도 있습니다.

보여 줄 숫자와 열람 권한, 이상 알림 범위가 견적서에 없으면 개발 도중에 정해야 합니다. 그만큼 일정과 금액이 달라질 수 있습니다.

보여 줄 숫자와 열람 권한과 이상 알림 범위가 적혀 있으면 견적서끼리 비교할 수 있습니다.

엔소프 컴퍼니는 비즈니스 대시보드의 숫자를 AI 에이전트가 모아 채우도록 개발해 드립니다

여러 시스템의 숫자를 사람이 옮겨 담아야 하면 비즈니스 대시보드가 있어도 일은 줄지 않습니다. 고객이 원하시면 엔소프 컴퍼니가 그 일을 AI 에이전트가 맡도록 개발해 드립니다. AI 에이전트는 맡은 숫자 정리를 스스로 이어 가는 AI 프로그램입니다.

결제와 주문 시스템의 매출과 회원 숫자는 AI 에이전트가 가져와 비즈니스 대시보드에 채웁니다. 표 문서에 옮겨 적던 일을 직원이 하지 않아도 됩니다.

매주 보시던 숫자는 고객이 정하신 요일과 시간에 담당 직원에게 요약 보고서로 보냅니다. 숫자가 정해 둔 범위를 벗어나면 AI 에이전트가 이상 알림을 담당 직원에게 전달합니다.

숫자를 옮겨 합치던 직원의 시간과 인건비가 줄고 회의 전에 자료를 모으는 일도 줄어듭니다. 어떤 숫자를 먼저 보실지와 누가 볼 수 있게 할지는 고객이 정하시면 됩니다.

프로젝트를 마치면 지표 정의 문서와 동작하는 비즈니스 대시보드를 넘겨드립니다. 이상 알림 규칙 문서도 함께 받으실 수 있습니다.

지금 여러 시스템의 숫자를 직접 옮겨 합치고 계신 작업을 알려 주시면 됩니다. 그 숫자가 비즈니스 대시보드에 자동으로 채워지는 방법을 엔소프 컴퍼니가 함께 찾아 드립니다.

프로젝트 문의하기

견적서를 받으셨습니다. 「앱 개발」 항목 아래에 서버 항목이 따로 적혀 있습니다. 서버는 앱의 요청을 받아 정보를 저장하고 처리하는 컴퓨터입니다. 앱 하나를 만들어 달라고 하셨는데 서버 항목이 왜 붙는지 궁금하실 수 있습니다.

견적서에 적힌 서버 항목은 무엇을 가리킵니까?

엔소프 컴퍼니 견적서에는 「App 비즈니스 서버 구축, API·데이터·인증」 한 줄이 있습니다. 회원 정보와 주문처럼 사업에 필요한 정보를 저장하고 처리하는 서버를 만드는 일입니다. 이 글에서는 그 서버를 앱 서버라고 부릅니다.

다른 견적서에는 같은 일이 백엔드 개발, 서버 개발, API 개발로 적히기도 합니다. 백엔드는 화면 뒤에서 일하는 서버 쪽 프로그램을 가리키는 말입니다. 이름이 달라도 같은 일일 수 있으므로 항목 이름보다 안에 적힌 작업 내용을 보시면 됩니다.

앱 서버는 언제 필요합니까?

여러 회원이 함께 쓰거나 운영자가 확인해야 하는 정보가 있으면 앱 서버가 필요합니다. 회원 정보와 주문 내역, 게시글이 그런 정보입니다. 이런 정보는 한곳에 모아 두어야 하고 그 한곳이 앱 서버입니다.

앱은 회원의 휴대폰에 설치해서 쓰는 프로그램입니다. 화면을 보여 주고 입력을 받는 일은 앱 서버 없이도 만들 수 있습니다.

정보를 휴대폰 안에만 저장하는 앱도 앱 서버 없이 만들 수 있습니다. 그렇게 저장한 정보는 그 기기에서만 보입니다. 다른 기기에서도 보이지 않고 다른 회원이나 운영자도 볼 수 없습니다.

앱 서버는 어떤 일을 합니까?

앱 서버는 정보를 저장하는 일과 앱에 전달하는 일, 접속한 사람을 확인하는 일을 합니다.

견적서의 「데이터」는 정보를 저장하는 일을 가리킵니다. 회원 정보와 주문 내역을 앱 서버에 저장하는 일입니다.

「API」는 앱과 앱 서버가 정보를 주고받는 방식을 정해 둔 규칙입니다. 앱이 「이 회원의 주문 목록을 보내 달라」고 요청하면 앱 서버가 규칙대로 그 목록을 앱에 보냅니다.

「인증」은 앱에 접속한 사람이 누구인지 확인하는 일입니다. 인증이 없으면 앱 서버는 요청을 보낸 사람을 구분하지 못합니다. 그러면 회원마다 자기 정보만 보이게 할 수 없습니다.

앱 서버가 없으면 어떤 기능이 멈춥니까?

앱 서버가 없거나 앱 서버에 회원가입과 주문을 처리하는 기능이 없으면 멈추는 일이 있습니다. 기기를 바꾼 회원은 그동안의 기록을 이어 쓸 수 없고 운영자는 회원 정보와 주문 내역을 한곳에서 볼 수 없습니다. 회원마다 다른 화면을 보여 줄 수도 없습니다.

앱 서버와 화면 디자인은 맡는 일이 달라서 견적서에도 따로 적힙니다. 화면 디자인이 같아도 앱 서버가 맡는 기능에 따라 앱으로 할 수 있는 일이 달라집니다.

회원가입을 받는 앱은 계정을 지우는 기능도 만들어야 합니까?

회원가입을 받는 앱은 앱 안에서 계정을 지울 수 있게 만들어야 합니다. 애플은 앱 등록 심사 지침에서 계정을 만들 수 있는 앱에 계정 삭제 기능도 요구합니다.

구글은 여기에 더해 앱을 설치하지 않고도 계정 삭제를 요청할 수 있는 웹 주소를 두라고 요구합니다. 그 주소는 구글 플레이 앱 등록 화면인 플레이 콘솔의 데이터 보안 양식에 적어야 합니다.

회원가입을 받는 앱은 계정과 회원 정보를 앱 서버에 저장합니다. 그래서 계정을 지우는 기능도 앱 서버가 처리합니다. 이런 앱에 앱 서버가 없으면 계정 삭제 기능을 만들 수 없습니다.

견적서의 서버 항목에서 무엇을 확인해야 합니까?

견적서에서는 로그인 범위와 앱 서버에 저장하는 정보 두 가지를 확인하시면 됩니다.

로그인 범위는 회원가입, 로그인, 비밀번호 찾기, 소셜 로그인이 견적서에 있는지 보시면 됩니다. 소셜 로그인은 구글이나 애플 같은 기존 계정으로 로그인하는 기능입니다. 필요한 기능이 견적서에 없으면 계약 후에 작업 범위를 다시 협의해야 할 수 있습니다.

앱 서버에 저장하는 정보는 견적서에서 확인하시면 됩니다. 회원 정보나 주문 내역 같은 저장 항목이 적혀 있는지 보시면 됩니다. 운영자와 회원이 각각 어디까지 볼 수 있는지도 적혀 있는지 보시면 됩니다. 앱 서버에는 누가 어디까지 볼 수 있는지 정해 두는 권한 설정이 있습니다. 운영자와 회원의 화면이 달라지는 것도 권한 설정에 따릅니다.

그래서 앱 서버까지 지금 견적에 넣어야 합니까?

여러 회원이 함께 쓰거나 운영자가 확인할 정보가 있는 앱에는 앱 서버가 필요합니다. 회원 정보나 주문 내역을 모으는 앱의 견적서에는 앱 서버 항목이 있어야 합니다. 정보를 휴대폰 안에만 저장하는 앱은 앱 서버 항목이 없어도 됩니다.

화면을 먼저 만들고 앱 서버를 나중에 붙이는 방식도 가능합니다. 다만 회원가입 화면은 정보를 저장할 앱 서버가 붙기 전에는 동작하지 않습니다. 앱 서버를 나중에 붙이면 화면이 앱 서버와 정보를 주고받는 부분을 다시 만들어야 할 수 있습니다.

엔소프 컴퍼니는 앱 서버에 쌓이는 회원·주문 데이터를 AI 에이전트가 처리하도록 개발해 드립니다

앱 서버가 필요한 이유는 회원 정보와 주문 내역이 그곳에 쌓이기 때문입니다. 쌓인 정보로 보고서를 만들고 문의를 분류하는 일은 정기적으로 되풀이되는 업무일 수 있습니다. 고객이 원하실 경우 엔소프 컴퍼니는 앱 서버와 함께 반복 업무를 처리하는 AI 에이전트도 개발해 드립니다. AI 에이전트는 고객이 정해 둔 규칙대로 업무를 대신 처리하는 AI 프로그램입니다.

앱 서버의 회원·주문 정보는 월간 보고서로 자동 정리됩니다. 앱으로 들어온 회원 문의와 신청은 종류별로 분류되어 담당자에게 전달됩니다.

어떤 일부터 맡기실지는 고객이 정하시면 되고 한 가지만 시작하셔도 됩니다. 보고서를 직접 만들고 문의를 분류하던 직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 스토어 등록을 마친 앱과 앱 서버를 계정과 함께 고객에게 넘겨드립니다. 자동화를 맡기셨다면 동작하는 자동화 시스템도 받으실 수 있습니다.

앱 서버에 쌓일 정보 가운데 지금 손으로 옮기거나 분류하는 일이 있다면 알려 주시면 됩니다.

프로젝트 문의하기

제안서 두 곳을 받아보셨습니다. 한 곳은 표지부터 화려하고 사례 사진이 빼곡합니다. 다른 한 곳은 수수하고 문장도 짧습니다. 둘 중 어느 쪽이 일을 더 잘할지는 제안서만으로 알 수 없습니다.

제안서는 발표 역량을 보여줍니다

제안서를 쓰는 일과 화면을 설계하고 코드를 작성하는 일은 다른 기술입니다. 발표 자료를 잘 만드는 팀과 프로젝트를 끝까지 끌고 가는 팀이 항상 같지는 않습니다.

포트폴리오도 마찬가지여서 완성된 화면만 나열되어 있습니다. 화면에 이르기까지 무엇을 물었고 어디를 수정했는지는 보이지 않습니다.

그래서 제안서와 포트폴리오 바깥을 봐야 합니다. 제안서에 담기지 않는 부분은 회의 중 오가는 질문, 계약서에 적힌 문장, 계정을 여는 방식입니다.

견적을 요청했을 때 개발사가 되묻는지 보십시오

견적을 요청했을 때 돌아오는 답이 금액뿐인지, 되묻는 질문이 붙어 있는지가 첫 신호입니다. 화면 수와 기능 목록만 보고 바로 숫자를 냈다면 빈칸을 스스로 채워 넣었다는 뜻입니다.

무엇이 포함되고 무엇이 빠지는지, 어떤 방식으로 만들지, 프로젝트 종료 후에 무엇이 이어지는지. 이런 질문을 먼저 던지는 곳이 있습니다. 같은 조건을 여러 곳에 똑같이 보내면 어느 쪽이 되묻는지 바로 드러납니다. 왜 같은 조건에 다른 금액이 오는지는 같은 사양인데 견적이 다른 이유에 적어 두었습니다.

되묻는 질문의 수준도 함께 보시면 됩니다. 화면 개수를 확인하는 질문이 있고 데이터를 누가 책임지고 권한을 어디에 둘지 확인하는 질문이 있습니다. 둘은 무게가 다릅니다.

못 하는 것을 먼저 말하는 곳이 있습니다

무엇이든 가능하다고 답하는 제안은 다시 살펴봐야 합니다. 기술적으로 어렵거나 일정이 빠듯한 항목은 실제로 존재합니다.

안 되는 부분이나 시간이 걸리는 부분을 먼저 알려 주는 곳이 있습니다. 이런 설명은 회의 중 질문에서 드러나지, 제안서 문서에는 잘 나오지 않습니다.

범위는 문서에 적혀야 남습니다

회의에서 오간 말은 양쪽 기억에 다르게 남습니다. 문서에 항목으로 적히지 않으면 나중에 「그건 포함인 줄 알았다」는 말이 나옵니다. 그때는 이미 만드는 중입니다.

견적서나 계약서에 포함 항목과 제외 항목이 나란히 적혀 있는지 확인하시면 됩니다. 포함만 적고 제외를 안 적은 문서는 절반만 적은 문서입니다.

관리자 페이지, 디자인 수정 횟수, 콘텐츠 입력처럼 구체적인 항목이 적혀 있는지 보시면 됩니다. 관리자 페이지는 고객이 글과 이미지를 직접 바꾸는 화면입니다. 있으면 그 회사는 범위를 실제로 따져본 셈입니다. 항목 없이 「요청사항 반영」이라는 문장 하나로 끝나 있으면 그 자리에서 되물으시면 됩니다.

계정과 자산의 명의를 계약 전에 묻습니다

스토어 계정, 도메인, 호스팅, 소스 저장소, 분석 도구 권한의 명의는 계약 전에 정해집니다. 도메인은 사이트의 인터넷 주소이고 호스팅은 사이트가 올라가 있는 컴퓨터(서버)를 빌리는 일입니다. 소스 저장소는 사이트를 만든 원본 코드를 보관하는 곳입니다. 열고 난 뒤에 바꾸려면 절차가 따로 붙습니다.

항목별로 무엇이 걸리는지는 웹사이트를 넘겨받을 때 도메인, 호스팅, 디자인 원본까지 받아야 하는 이유에 정리해 두었습니다. 앱이면 스토어 계정 쪽을 보시면 됩니다. 여기서 볼 것은 계정과 자산의 명의를 개발사가 먼저 언급하는지입니다.

계정을 개발사 이름으로 먼저 열고 나중에 옮기겠다는 제안을 받으실 수 있습니다. 이전 과정에서 잃는 이력과 권한이 생긴다는 점은 분명히 해 두어야 합니다.

계약 전에 「이 프로젝트에서 만들어지는 계정과 코드는 누구 이름으로 남습니까」라고 물어보시면 됩니다. 계정과 코드의 명의를 물었을 때 바로 답하는지, 확인 후 알려 드리겠다고 하는지를 보시면 됩니다.

완성 이후는 계약서에만 적힙니다

유지보수 조항과 인계 문서가 계약서 안에 있는지 확인하시면 됩니다. 유지보수는 완성 뒤에 사이트를 정상 상태로 관리하는 일이고 인계 문서는 사이트를 넘겨받는 데 필요한 정보를 적은 문서입니다. 만들고 넘기는 계약만 맺으면 완성 이후에 생기는 일을 맡을 사람이 계약서 안에 없습니다.

재빌드, 버전 업데이트, 서버 갱신은 시간이 지나야 생기는 일들이며 재빌드는 사이트를 다시 조립해 내보내는 작업입니다. 세 가지 모두 만들 때는 존재하지 않으니 제안서에도 나오지 않습니다.

재빌드, 버전 업데이트, 서버 갱신이 계약서에 조항으로 있는지가 신호가 됩니다. 조항이 없으면 그 일을 아직 아무도 논의하지 않았을 수 있습니다.

연락 창구가 한 사람인지 보십시오

제안 단계에서 만난 담당자와 실제 작업을 진행하는 담당자가 같은 사람인지 확인하시면 됩니다. 프로젝트 중간에 창구가 바뀌면 앞서 나눈 이야기를 처음부터 다시 설명해야 하는 상황이 생깁니다.

창구가 여러 명으로 나뉘어 있어도 괜찮습니다. 다만 질문 하나를 보냈을 때 누구에게 물어야 하는지 고객이 알고 계셔야 합니다. 답이 돌아오는 속도도 제안서에는 적히지 않는 정보입니다.

첫 미팅에서 「프로젝트가 진행되는 동안 연락할 사람은 누구입니까」라고 물어보시면 됩니다. 이름 하나로 명확히 답하는 곳과 부서 이름으로 뭉뚱그리는 곳이 있습니다.

에이전시가 필요 없는 경우도 있습니다

지금 필요한 것이 랜딩 페이지 한 장이라면 에이전시를 쓸 이유가 크지 않습니다. 템플릿 기반 빌더로도 원하는 형태를 충분히 만들 수 있는 규모입니다. 랜딩 페이지는 상품 하나를 소개하고 문의를 받는 한 장짜리 페이지입니다. 템플릿 기반 빌더는 미리 만든 틀에 내용을 채워 사이트를 만드는 도구입니다.

사내에 개발 인력이 있다면 외주보다 채용이나 내부 배정이 나을 수 있습니다. 반복해서 손이 가는 프로젝트라면 매번 밖에 맡기는 쪽보다 안에서 계속 다루는 쪽이 유리합니다.

지금 사이트나 앱이 문제없이 돌아가고 있다면 굳이 수정하지 않는 편이 맞습니다. 잘 돌아가는 것을 바꾸는 작업은 새로 만드는 작업보다 위험이 더 클 수 있습니다.

랜딩 페이지, 사내 개발 인력, 정상 운영 중인 사이트에 해당하지 않으면 개발사 선택이 필요합니다. 그때 견적서와 계약서에서 범위, 계정 명의, 연락 창구, 완성 이후 조항을 확인해 보십시오.

그래서 서명하기 전에 범위, 계정 명의, 연락 창구, 완성 이후 조항을 확인해야 합니까?

범위, 계정 명의, 연락 창구, 완성 이후 조항이 문서에 없다면 서명 전에 확인해 볼 만합니다. 제안서를 받아 놓고 고민하는 사이에도 계약 조건은 정해지지 않은 채 남아 있습니다.

계약서에 포함과 제외가 적히지 않은 채 서명하면 범위를 되돌릴 방법이 마땅치 않습니다. 계정 명의도 같아서 개발사 이름으로 먼저 열면 이전 과정에서 이력과 권한을 잃을 수 있습니다. 질문을 미룬 만큼 되돌리는 비용이 커집니다.

연락 창구와 완성 이후 조항도 마찬가지입니다. 작업이 시작된 뒤에 담당자가 바뀌거나 유지보수 조항이 없다는 사실을 알게 되면 선택지는 이미 줄어 있습니다. 묻기 가장 쉬운 때는 서명 전인 지금입니다.

포함 항목, 계정 명의, 종료 후 조항, 연락 창구가 문서에 있다면 다음 단계로 넘어가셔도 됩니다.

엔소프 컴퍼니는 제안서에 적은 범위를 기준으로 AI 에이전트와 자동화를 개발해 드립니다

개발사를 선택한 뒤에는 문서에 적힌 범위대로 만들어지는지가 확인 대상이 됩니다. 고객이 원하실 경우 엔소프 컴퍼니는 AI 에이전트를 개발해 드립니다. AI 에이전트는 글 발행 같은 반복 업무를 사람 대신 처리하는 프로그램입니다. AI 에이전트에 어떤 일을 맡길지는 고객이 정하시면 됩니다. 엔소프 컴퍼니는 그 범위를 문서로 남기고 그 문서를 기준으로 개발합니다.

글 발행은 어떤 주제로 어떤 사진과 상품 정보를 이어 글을 올릴지 문서에 먼저 남깁니다.

인스타그램은 카드뉴스의 구성과 올리는 방식을 문서에 적고 그에 맞춰 만들어 올립니다.

쓰시던 프로그램이 어떻게 이어지는지도 문서에 남깁니다.

문서에 어디까지 적을지는 고객이 정하시면 됩니다.

직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 동작하는 발행 시스템과 자동화 시스템을 넘겨드립니다. 콘텐츠 작성 가이드와 계정 인수인계까지 함께 받으실 수 있습니다.

프로젝트를 맡기신 뒤에 손으로 반복하게 될 운영 업무가 있다면 하나만 알려 주시면 됩니다. 그 일을 제안서의 AI 에이전트 항목으로 넣는 방법을 엔소프 컴퍼니가 함께 찾아 드립니다.

프로젝트 문의하기

같은 기획서를 세 곳에 보내셨는데 돌아온 금액은 제각각입니다. 왜 비싼지와 무엇이 빠져서 싼지를 판단할 기준이 없습니다.

여러 곳에 물으면 답이 제각각입니다

견적을 받아보셨다면 이 순서가 익숙하실 겁니다. 만들고 싶은 것을 정리해 여러 곳에 보냅니다. 돌아온 금액을 나란히 놓습니다. 가장 낮은 쪽과 가장 높은 쪽을 뺀 가운데를 고릅니다.

비교할 기준이 없어서 가운데 금액을 고르게 됩니다. 어느 견적이 무엇까지 포함하는지는 금액만 보셔서는 알 수 없습니다.

세 견적서는 같은 것을 견적하고 있지 않습니다. 세 곳은 같은 문서를 읽었지만 각자 다른 일의 목록을 만들었습니다.

견적서는 그 회사의 해석입니다

기획서 한 장은 고객이 만들고 싶은 결과를 적은 문서이고 어떻게 만들지는 적혀 있지 않습니다. 적히지 않은 부분은 받는 쪽이 채웁니다. 어떤 곳은 이미 나와 있는 제품을 가져다 쓰는 방식으로 읽고 어떤 곳은 처음부터 만드는 방식으로 읽습니다.

고객이 적으신 「관리자 페이지」 한 줄이 대표적입니다. 관리자 페이지는 직원이 내용을 직접 수정하는 전용 화면입니다. 이미 만들어 둔 관리 화면을 가져다 붙이는 일로 읽으면 작은 항목이 됩니다. 목록과 검색과 직원별 열람 설정을 새로 만드는 일로 읽으면 화면 여러 장짜리 항목이 됩니다. 기획서에 적힌 글자는 한 줄로 같습니다.

그래서 견적서는 그 회사가 기획서를 어떻게 읽었는지 적어 보낸 답장입니다. 금액만 나란히 놓고 비교하면 견적서의 차이를 잘못 판단하게 됩니다.

금액은 범위, 방식, 경계, 인계에 따라 달라집니다

첫째는 범위, 무엇을 만드느냐입니다. 화면 수가 같아도 화면 안에서 처리할 일이 다르면 작업량이 달라집니다.

둘째는 방식입니다. 있는 것을 조립할 수도 있고 필요한 부분만 새로 만들 수도 있습니다. 어느 쪽을 고르느냐에 따라 처음 드는 비용과 나중에 수정하기 쉬운 정도가 함께 달라집니다.

셋째는 경계, 누가 어디까지 맡느냐입니다. 원고와 이미지를 고객이 준비하시는지, 검수를 몇 번 하는지가 견적서에 적혀 있기도 하고 빠져 있기도 합니다. 검수는 만든 결과가 요청대로인지 확인하는 일입니다.

마지막은 인계, 프로젝트 종료 후에 무엇을 넘겨받고 무엇이 이어지느냐입니다. 인계와 유지보수가 들어간 견적서와 빠진 견적서는 금액이 같아도 고객 손에 남는 것이 다릅니다. 유지보수는 완성된 뒤에도 오류를 수정하고 상태를 관리하는 일입니다.

빠진 항목은 나중에 돌아옵니다

견적서에서 빠진 일은 사라지지 않습니다. 나중에 누군가 해야 합니다. 그 일은 프로젝트 중간에 다시 나타날 수 있습니다. 그때는 추가 요청이 되어 일정과 금액을 다시 이야기하게 됩니다.

추가 요청은 「이건 당연히 되는 줄 알았는데요.」라는 말로 시작되곤 합니다. 고객은 포함이라고 믿으셨고 제작 쪽은 범위 밖이라고 적어 뒀는데 양쪽 다 자기 문서대로 읽었기 때문에 풀기가 더 어렵습니다.

위험한 쪽은 무엇이 빠졌는지 모른 채 고르는 일입니다. 금액의 높낮이는 그다음 문제입니다.

견적을 비교하려면 세 회사에 무엇을 물어야 합니까?

금액을 비교하시려면 세 곳이 같은 것을 견적하도록 맞추셔야 합니다. 각 회사에 같은 질문을 보내시면 됩니다.

1. 이 견적에 무엇이 들어가고 무엇이 빠집니까?
2. 어떤 방식으로 만듭니까? 나중에 수정할 수 있는 폭은 어디까지입니까?
3. 발주 쪽(일을 맡기는 고객 쪽)에서 준비해야 하는 것은 무엇입니까?
4. 프로젝트 종료 후에 무엇을 받고 무엇이 이어집니까?

답이 돌아오면 금액 옆에 항목을 놓고 하나씩 맞춰보십시오. 세 곳이 다르게 답한 것은 묻지 않으신 부분을 각자 다르게 가정했기 때문일 수 있습니다.

같은 질문을 받으면 답의 형태도 같아집니다. 그때부터는 금액이 아니라 접근 방식을 비교하게 됩니다. 왜 그곳을 고르셨는지 나중에 설명하실 수도 있습니다.

질문을 먼저 정리하는 데 따르는 부담은 무엇입니까?

질문을 먼저 정리하는 방식에도 대가가 따릅니다. 질문을 만들고 답을 정리하는 시간이 앞쪽으로 옮겨옵니다.

빨리 시작하고 싶으시면 이 단계가 시간을 많이 쓰는 것처럼 보입니다. 다만 늘어나는 시간은 아닙니다. 프로젝트 중간에 치르실 일을 앞당겨 치르시는 셈입니다.

앞에서 정하면 문서를 수정하면 되고 뒤에서 정하면 만들어 놓은 것을 수정해야 합니다.

그래서 견적을 받기 전에 범위, 방식, 경계, 인계를 물어야 합니까?

견적 요청에 범위, 방식, 경계, 인계를 묻는 질문이 아직 없다면 보내기 전에 먼저 넣어 볼 만합니다. 세 견적서를 쌓아두는 것은 비교가 아닙니다.

기획서 한 장만 보내시면 받는 곳마다 빈칸을 다르게 채웁니다. 범위와 방식과 경계와 인계를 묻지 않으시면 각 회사가 스스로 가정하고 그 가정의 차이가 그대로 금액 차이로 돌아옵니다.

견적서마다 포함된 항목이 다른 상태에서는 금액 차이의 원인을 알 수 없습니다.

이미 같은 질문을 모든 곳에 보냈다면 돌아온 답을 항목별로 나란히 놓으시면 됩니다.

엔소프 컴퍼니는 견적이 달라지는 항목에 자동화까지 담아 AI 에이전트로 개발해 드립니다

같은 사양인데 견적이 달라지는 것은 항목마다 해석이 다르기 때문입니다. 자동화도 항목으로 적혀 있지 않으면 업체마다 다르게 읽힙니다. 고객이 원하실 경우 엔소프 컴퍼니는 사양 문서에 반복 업무 자동화까지 항목으로 적고 AI 에이전트로 개발해 드립니다. 사양 문서는 만들 것의 범위와 조건을 적은 문서입니다. AI 에이전트는 항목에 적은 업무를 기준대로 대신 처리하는 프로그램입니다.

글 발행은 어떤 주제의 글을 만들어 올릴지 항목으로 적습니다. 상품 정보와 제품 사진을 글에 가져오는 일도 항목에 넣습니다.

인스타그램은 카드뉴스를 몇 장으로 만들어 어떻게 올릴지 항목으로 남깁니다. 카드뉴스는 사진과 짧은 문장을 넘겨 보는 게시물입니다.

기존 프로그램과의 연결은 무엇을 이을지 항목으로 적어 둡니다.

항목을 어디까지 넣을지는 고객이 정하시면 됩니다.

직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 배포된 웹사이트와 콘텐츠 관리·발행 환경을 넘겨드립니다. 배포는 완성된 웹사이트를 인터넷에 공개하는 일이며 콘텐츠 작성 가이드와 계정 인수인계까지 함께 받으실 수 있습니다.

같은 사양 문서로 견적을 비교하고 계시다면 알려 주시면 됩니다. 그 문서에 자동화 항목을 넣는 방법을 엔소프 컴퍼니가 함께 찾아 드립니다.

프로젝트 문의하기

화면 목록도 정리해 두셨습니다. 회의에서도 여러 번 이야기하셨습니다. 그런데 나온 화면을 보면 그때 말씀하신 것과 다릅니다. 어딘가에서 「알아서 해주세요」라고 하신 순간이 있으셨을 겁니다. 그 한마디가 그 화면을 누가 결정할지를 정해 버립니다.

편한 말이지만 결정이 함께 넘어갑니다

이 말은 편합니다. 세부 사항을 하나하나 말씀하지 않아도 되는 느낌을 줍니다. 그런데 이 말은 결정을 다음 사람에게 넘기는 말입니다.

고객이 넘기신 결정은 사라지지 않고 개발사가 대신 내립니다. 하지만 개발사가 내리는 결정이 고객이 머릿속에 그리신 것과 같으리라는 보장은 없습니다.

넘겨받은 쪽은 가장 만들기 쉬운 방식을 택합니다

결정을 넘겨받은 개발사는 정해진 일정 안에서 답을 내야 합니다. 그래서 가장 무난하고 가장 빨리 만들 수 있는 방식을 택합니다. 고객이 원하신 방식과 같을 수도, 다를 수도 있습니다.

다르면 화면이 나온 뒤에야 차이가 보입니다. 그때 수정하면 처음에 정할 때보다 비용이 더 들 수 있습니다.

화면 하나에도 결정할 것이 여럿입니다

목록 하나, 관리자 화면 하나에도 정할 것이 여러 개 숨어 있습니다. 관리자 화면은 직원이 내용을 직접 수정하는 전용 화면입니다.

PC 화면과 휴대폰 화면은 같지 않아서 메뉴가 많으면 PC에서는 한 줄에 늘어놓고 휴대폰에서는 접습니다. 어떻게 접을지 미리 말씀하지 않으시면 개발사가 무난해 보이는 방식으로 접습니다. 하지만 고객이 실제로 화면을 눌러 보시기 전까지는 그 방식이 맞는지 아무도 모릅니다.

관리자 화면은 몇 분이 쓰시는지에 따라 다릅니다. 한 분만 쓰시면 화면 하나로 충분합니다. 여러 분이 같이 쓰시고 권한이 다르면 권한을 나누는 구조가 필요합니다. 권한은 사람마다 볼 수 있고 수정할 수 있는 범위를 말합니다. 권한을 나누는 구조는 화면 몇 장을 추가하는 것보다 작업이 더 많습니다.

검색과 정렬도 마찬가지입니다. 이름으로만 찾을지 지역이나 날짜로도 찾을지에 따라 화면 뒤의 구조가 달라집니다. 정하지 않고 넘어가시면 개발사가 가장 만들기 쉬운 순서를 고릅니다.

문구와 사진, 예전 자료도 누가 맡을지 정해야 합니다

화면 설계에는 글자와 사진이 들어갈 자리가 그려지지만 그 자리를 누가 채울지는 회의에서 잘 안 정해집니다. 회사 소개 문구나 제품 사진은 원래 고객께서 준비하시는 몫입니다. 「알아서 해주세요」로 넘어가면 개발사가 임시로 채워 넣거나 빈칸으로 남습니다. 오픈일이 다가와야 빈칸이 눈에 띕니다.

예전 홈페이지나 카페에 쌓인 자료도 같습니다. 그대로 옮기는 일과 다시 정리해서 올리는 일은 다른 작업입니다. 이것도 미리 정하지 않으시면 일정에 없던 작업이 막판에 나타납니다.

회의록은 결론만 남고 오간 말은 안 남습니다

착수 회의는 일을 시작하기 전에 갖는 첫 회의인데 많은 이야기가 오갑니다. 회의가 끝나면 다 정해진 느낌이 들지만 회의록에는 「로그인 기능 추가하기로 함」처럼 짧은 문장 하나로 결론만 남습니다.

로그인 한 줄 안에도 여러 갈래 질문이 숨어 있습니다. 아이디와 비밀번호만 쓸지 전화번호로도 로그인할지 먼저 정해야 합니다. 비밀번호를 잊으면 어떤 절차를 거칠지도 정해야 합니다. 회의록에는 로그인 방식과 재설정 절차 같은 세부 질문의 답이 적히지 않습니다. 회의 중에 나온 「알아서 해주세요」도 회의록에는 안 남습니다.

개발사는 회의록만 받으면 세부 질문마다 스스로 가정해서 만들어야 합니다. 그 가정이 고객의 생각과 다르면 화면이 나온 뒤에야 드러납니다.

그림 한 장이 오해를 줄입니다

손으로 그린 스케치나 비슷한 서비스의 화면 캡처면 충분합니다. 글로 설명하기 어려운 부분은 그림으로 보여 주시면 됩니다.

「알아서 해주세요」 대신 그림 한 장을 건네시면 결정은 여전히 고객 몫으로 남습니다. 개발사는 그 그림을 기준으로 만듭니다.

그래서 개발사에 화면 그림 한 장을 먼저 건네야 합니까?

첫 회의에 가져갈 메모와 참고 화면이 아직 없다면 먼저 준비해 볼 만합니다. 완성된 디자인이 아니어도 괜찮습니다.

착수 회의 전에 메모와 참고 화면을 준비하지 않으시면 회의에서도 결정이 개발사로 넘어갑니다. 설명은 길게 하시고 그림은 없어서 결정은 다시 「알아서」로 넘어갑니다.

회의가 끝나고 회의록에 결론 한 줄만 남으면 그 사이 오간 말은 사라집니다. 화면이 나온 뒤에 다시 설명하시면 그때는 수정하는 비용이 붙습니다.

손으로 그린 스케치나 비슷한 서비스의 화면 캡처가 이미 있다면 그대로 첫 회의에 가져가셔도 됩니다.

엔소프 컴퍼니는 고객이 정하신 결정 그대로 움직이는 AI 에이전트를 개발해 드립니다

「알아서 해주세요」 대신 고객이 정하신 결정을 남기면 AI 에이전트도 그 결정대로 움직입니다. 고객이 원하실 경우 엔소프 컴퍼니는 정하신 주제와 문체, 금지 표현을 그대로 따르는 AI 에이전트를 개발해 드립니다. AI 에이전트는 고객이 남긴 결정을 기준으로 반복 업무를 처리하는 프로그램입니다. 결정이 한 번 남으면 같은 설명을 매번 처음부터 다시 하실 일이 줄어듭니다.

정해 주신 주제와 문체 안에서 상품 정보와 제품 사진을 이어 글을 쓰고 올립니다. 검색엔진이 읽을 수 있는 형식으로 갖춥니다.

카드뉴스는 정해 주신 장수와 문장 규칙대로 인스타그램 게시물이 됩니다. 카드뉴스는 사진과 짧은 문장을 넘겨 보는 형식입니다.

글 작성, 인스타그램 게시, 자료 옮겨 적기 같은 반복 업무도 정해 주신 규칙대로 처리됩니다.

규칙은 고객이 적으신 범위까지만 적용됩니다.

직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 동작하는 자동화 시스템과 계정 인수인계를 넘겨드립니다. 고객이 정하신 규칙은 문서와 시스템에 그대로 남습니다.

지금 매번 손으로 결정하고 계신 반복 업무 하나를 알려 주시면 됩니다. 그 결정을 규칙으로 남겨 AI 에이전트에게 맡기는 방법을 엔소프 컴퍼니가 함께 찾아 드립니다.

프로젝트 문의하기

사이트가 문을 열면 계약서 대부분은 끝난 상태가 됩니다. 그런데 손이 가는 일은 그때부터 새로 생깁니다.

사이트를 연 뒤 생기는 일이 원래 계약 안에 있는지 새 일인지 요청하실 때마다 판단하기 어렵습니다. 그래서 개발사와 다툼이 생기기 쉬운 부분입니다.

문제를 수정하는 일과 새로 만드는 일은 다릅니다

「유지보수」는 원래 약속한 대로 돌아오게 하는 일입니다. 눌리지 않던 버튼을 다시 눌리게 만들고 깨졌던 화면을 원래 모습으로 되돌립니다.

「새 일」은 원래 없던 것을 넣는 일입니다. 로그인 화면에 소셜 로그인 버튼을 추가해 달라는 요청이나 없던 결제 수단을 붙이는 일이 새 일에 들어갑니다. 소셜 로그인은 구글이나 애플 같은 기존 계정으로 들어오는 방식입니다.

이 구분에 따라 고객이 받으실 견적과 처리 순서가 달라집니다. 수정하는 일은 계약에 이미 포함된 대응으로 처리됩니다. 만드는 일은 별도 견적과 일정을 다시 잡습니다.

경계가 애매한 자리도 있습니다. 있던 기능을 개선해 달라고 하실 때입니다.

검색 결과를 더 빠르게 보여 달라는 요청은 수정하는 쪽에 가깝습니다. 검색 항목을 새로 추가해 달라는 요청은 만드는 쪽에 가깝습니다. 둘 다 「검색을 수정해 달라」는 한마디로 나가기 때문에 미리 나눠 두시는 편이 낫습니다.

계약서는 유지보수 범위를 항목별로 나눠 적습니다

유지보수에 들어가는 일과 새 일을 「범주」라는 항목으로 나눠 적는 계약서가 있습니다. 오류 대응, 콘텐츠 수정, 보안 패치처럼 항목을 나눠 범위를 정하고 항목마다 포함 여부를 표시합니다. 보안 패치는 발견된 보안 구멍을 막는 수정입니다.

건수나 시간 단위로 상한을 두는 곳도 있습니다. 상한을 넘는 요청은 별도 협의로 넘어갑니다. 건수나 시간 상한이 계약서에 없으면 요청하실 때마다 포함 여부를 처음부터 협의하게 됩니다.

대응 범위를 화면 단위로 적는 계약서도 있습니다. 메인 화면과 상세 화면은 포함하고 관리자 화면은 빼는 식입니다. 관리자 화면은 고객이 사이트 내용을 직접 바꾸는 화면입니다. 화면 하나가 통째로 빠져 있으면 그 화면에서 난 오류는 유지보수 밖의 일이 됩니다.

범주를 미리 정해 두시면 다툴 일이 줄어듭니다. 요청이 들어올 때 계약서를 펼쳐 요청 내용에 맞는 범주가 포함으로 표시돼 있는지 보시면 됩니다.

가만히 둬도 생기는 일이 있습니다

고객이 아무것도 요청하지 않으셔도 손이 가는 일이 있습니다.

브라우저가 버전을 올리면 화면 일부가 다르게 나타날 때가 있습니다. 손댄 적 없는 코드인데 결과만 달라집니다.

라이브러리도 마찬가지입니다. 사이트를 만들 때 가져다 쓴 부품에서 보안 구멍이 발견되면 그 부품을 새 버전으로 바꿔야 합니다. 화면은 그대로인데 안쪽만 바뀌는 일이라 고객 눈에는 아무 변화가 없습니다.

결제, 지도, 로그인처럼 바깥 서비스와 연결된 기능은 그쪽이 규격을 바꾸면 따라 바뀝니다. 카드사가 인증 방식을 바꾸면 연결된 코드도 맞춰 수정해야 합니다. 고객 쪽에서 먼저 손댄 일이 아닌데도 대응은 그 사이트의 몫입니다.

인증서 만료와 호스팅 요금제 변경도 이 목록에 들어갑니다. 보안 인증서는 정해진 시점마다 다시 발급받아야 주소창의 잠금 표시가 유지됩니다. 호스팅 회사가 요금제 구성을 바꾸면 계약을 다시 확인하셔야 할 때도 있습니다. 호스팅은 사이트가 올라가 있는 컴퓨터를 빌리는 서비스입니다.

라이브러리나 인증서가 낡았는지는 화면을 눌러 보는 것만으로 알 수 없어서 고객이 먼저 알아채기 어렵습니다. 정기적으로 점검하는 쪽이 있어야 미리 발견됩니다.

응답 시간과 복구 시간은 다릅니다

문의를 받았다는 확인과 문제가 실제로 수정되는 시점은 다른 일입니다. 오류를 접수했다는 연락이 먼저 오고 그 오류가 수정되는 일은 그 뒤에 옵니다.

계약서에는 「응답 시간」과 「복구 시간」이 따로 적혀 있어야 합니다. 하나만 적혀 있으면 어느 쪽인지 확인하시면 됩니다.

접수 확인만 빠르고 실제 조치는 늦게 오는 경우가 있습니다. 연락은 받으셨는데 화면은 그대로인 상태가 며칠 이어집니다. 「두 시간 안에 대응」이라는 문구가 어느 쪽을 가리키는지에 따라 뜻이 달라집니다.

오류의 성격에 따라 순서도 달라집니다. 결제가 막히는 오류와 화면 여백이 어긋나는 오류를 같은 순서로 처리하지는 않습니다. 심각도를 나누는 기준이 있는 계약서라면 그 기준부터 보시면 됩니다.

무상 기간에는 어떤 일이 포함됩니까?

프로젝트 종료 후 일정 기간을 무상으로 안내하는 계약서가 있습니다. 「무상 기간」이 덮는 일은 계약서에 적어 둔 범주 안의 오류 대응입니다. 다만 범주 밖의 요청은 무상 기간 안에 넣으셔도 별도 견적으로 처리됩니다.

무상 기간과 유지보수 계약은 같은 말이 아닙니다. 무상 기간이 끝나면 그 이후를 어떻게 할지 다시 정하셔야 합니다.

그때 고르실 수 있습니다. 계약을 새로 맺으실 수도 있고 문제가 생길 때마다 건별로 부탁하실 수도 있습니다.

맡기지 않으면 고객이 직접 지는 일이 있습니다

유지보수를 맡기지 않는 선택도 있습니다. 회사 안에 화면을 만질 수 있는 분이 계시면 작은 수정은 직접 처리하실 수 있습니다. 이때는 계약 없이 지내시는 쪽이 자연스럽습니다.

다만 맡기지 않기로 하시면 가만히 생기는 일까지 고객이 직접 관리하시게 됩니다. 라이브러리 보안 알림을 받아 보실 방법을 마련해 두시고 인증서 만료일을 달력에 적어 두십시오. 바깥 서비스의 규격 변경 공지도 직접 구독하십시오.

이 확인을 빠뜨리시면 화면이 멈추고 나서 아시게 됩니다.

오류가 났을 때 어디에 먼저 연락하실지도 미리 정해 두시면 됩니다. 원래 만든 곳에 건별로 의뢰하실 수도 있고 다른 곳에 새로 맡기실 수도 있습니다. 다만 다른 곳에 새로 맡기시면 코드를 처음부터 파악하는 시간이 먼저 듭니다.

앱 유지보수는 웹사이트와 어떻게 다릅니까?

운영체제가 새 버전을 내놓으면 그 버전에 맞춰 코드를 다시 수정하는 일이 생기는데 웹에는 없는 일입니다. 코드 수정은 앱에서 새 버전이 나올 때마다 되풀이됩니다. 운영체제는 아이폰의 iOS나 안드로이드처럼 기기를 움직이는 기본 프로그램입니다.

화면을 수정하는 일과 성격이 달라서 같은 계약서 항목으로 묶기 어렵습니다. 앱을 함께 운영하시면 이 항목을 따로 적어 두시면 됩니다.

그래서 유지보수 범위는 계약 전에 정해야 합니까?

계약서에 유지보수 범위가 아직 적혀 있지 않다면 먼저 확인해 볼 만합니다.

사이트를 연 뒤에는 요청이 계속 들어옵니다. 그 요청마다 포함인지 아닌지 다시 협의하면 같은 다툼이 매번 반복됩니다. 범주를 미리 적어 두신 계약서는 요청이 올 때 펼쳐 보시는 것으로 끝납니다.

가만히 둬도 생기는 일도 있습니다. 라이브러리 보안 구멍과 바깥 서비스의 규격 변경과 인증서 만료는 고객이 먼저 알아채기 어렵습니다. 계약 전에 누가 챙길지 적어 두지 않으면 화면이 멈춘 뒤에야 책임을 두고 다투게 됩니다.

범주, 대응 범위, 응답 시간과 복구 시간이 계약서에 이미 있다면 다음 항목으로 넘어가셔도 됩니다.

엔소프 컴퍼니는 유지보수에서 반복되는 접수와 보고를 AI 에이전트로 개발해 드립니다

유지보수가 시작되면 사람이 손으로 되풀이하는 일이 생깁니다. 요청 접수를 나누고 내용을 시트에 옮겨 적고 매달 처리 보고서를 만드는 일입니다. 고객이 원하실 경우 엔소프 컴퍼니는 이 반복 업무를 AI 에이전트가 맡는 구조로 개발해 드립니다. AI 에이전트는 접수와 보고처럼 되풀이되는 업무를 사람 대신 처리하는 프로그램입니다.

요청이 들어오면 고객과 함께 세운 규칙에 따라 종류별로 나뉘어 담당자에게 전해집니다. 급한 결제 건과 문구 수정 건이 같은 줄에서 기다리지 않습니다.

접수된 요청은 쓰시는 관리 문서에 한 번에 기록됩니다.

한 달 동안 쌓인 접수 내역은 보고서로 만들어지고 고객이 확인하신 뒤에 쓰시면 됩니다.

유지보수 범위 가운데 무엇을 자동으로 돌릴지는 고객이 정하시면 됩니다.

직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 동작하는 자동화 시스템과 계정 인수인계를 넘겨드립니다.

지금 사이트에서 손으로 하시는 점검이나 접수 업무 하나를 알려 주시면 됩니다. 유지보수 안에서 AI 에이전트가 맡을 수 있는 일을 엔소프 컴퍼니가 함께 찾아 드립니다.

프로젝트 문의하기

사이트가 열리고 나면 관리하는 사람이 바뀌는 때가 옵니다. 개발사를 바꾸실 수도 있고 담당 직원이 그만둘 수도 있습니다.

그때 무엇을 넘겨받으셔야 다음 사람이 그대로 이어받을 수 있는지 미리 정해 두시는 편이 쉽습니다. 앱은 확인할 항목이 조금 달라서 여기서는 웹사이트 기준으로 적었습니다.

도메인과 DNS는 한 세트로 확인합니다

도메인은 사이트의 인터넷 주소이며 등록기관, 곧 주소를 등록해 주는 업체의 계정에 걸려 있는 이름입니다. 등록기관 계정이 누구 이름으로 되어 있는지부터 보시면 됩니다.

도메인 명의가 고객 회사 이름이면 명의 문제는 없습니다. 다만 등록기관 로그인 계정은 따로 받으셔야 합니다. 개발사나 담당자 개인 이름이면 도메인을 옮기는 절차부터 새로 밟으셔야 합니다.

도메인을 옮기시려면 인증 코드가 필요합니다. 받는 방법이 등록기관마다 다릅니다. 관리 화면에서 직접 만드는 곳이 있고 요청하면 닷새 안에 주는 곳이 있습니다. 잠금을 먼저 풀어야 하는 곳도 있습니다. 담당자가 바뀌기 전에 한 번 확인해 두시면 그때 급하게 알아보지 않으셔도 됩니다.

DNS는 도메인 주소를 어느 서버로 보낼지 정해 둔 설정입니다. 서버는 사이트가 올라가 있는 컴퓨터입니다. 레코드는 그 설정의 항목 한 줄입니다. 사이트용 A 레코드와 메일용 레코드, 다른 서비스가 걸어 둔 레코드까지 목록으로 받으시면 됩니다.

이 목록이 없으면 메일이 이유 없이 끊깁니다. 사이트는 멀쩡한데 주문 확인 메일만 안 오는 상태가 됩니다.

호스팅 계정과 결제 수단을 함께 받습니다

서버나 호스팅 서비스에 로그인하는 계정도 같은 문제를 안고 있습니다. 호스팅은 사이트를 올려 두는 서버를 빌리는 서비스입니다. 계정이 개발사 이름으로 열려 있으면 결제도 개발사 카드로 걸려 있는 경우가 있습니다.

결제 수단을 고객 명의로 바꿔 두십시오. 그대로 두시면 계약이 끝난 뒤 요금이 연체되어 사이트가 내려갈 수 있습니다.

결제 주기도 물어보시면 됩니다. 연 단위로 한 번에 결제하는 상품이면 다음 결제일을 적어 두시면 됩니다. 모르고 넘어가시면 만료된 뒤에 아시게 됩니다.

관리자 계정과 저장소 접근 권한을 나눠 받습니다

사이트를 운영하시려면 관리자 계정이 필요합니다. 계정 하나 받으셨다고 끝이 아닙니다.

콘텐츠만 수정하는 권한과 설정 전체를 바꾸는 권한이 따로 있는 시스템이 많습니다. 어느 등급으로 받으셨는지 확인하시면 됩니다. 등급이 낮으면 바꾸고 싶은 화면이 아예 안 보입니다.

소스 코드 저장소 권한은 별개로 받으시면 됩니다. 소스 코드는 사이트를 만든 원본 파일입니다. 저장소는 그 파일을 변경 이력과 함께 보관하는 곳입니다. 완성된 파일 묶음만 받으시면 다음 개발사가 코드를 처음부터 다시 읽어야 합니다. 저장소에 이력이 남아 있어야 다음 개발사가 이전에 무엇을 왜 수정했는지 확인할 수 있습니다.

저장소 소유권은 계약서에 적어 두십시오. 계약서에 없으면 프로젝트 종료 후에 권한을 다시 협의하시게 됩니다.

협업자로만 초대받으신 상태라면 더 위험합니다. 원래 계정이 삭제되면 저장소도 함께 사라질 수 있습니다.

권한이 한 사람에게 몰려 있기도 쉽습니다. 그 담당자가 연락이 안 되면 전체가 함께 막힙니다. 두 분 이상이 나눠 갖고 계시는 편이 안전합니다.

이미지와 디자인 원본은 완성본과 다릅니다

화면에 보이는 이미지는 압축해서 크기를 줄인 완성본입니다. 로고를 나중에 현수막이나 명함에 쓰시려면 압축한 완성본으로는 품질이 나오지 않습니다.

레이어(이미지를 층별로 나눈 구조)가 살아 있는 원본 파일을 따로 받으시면 됩니다. 이 파일이 없으면 로고에서 글자 한 줄 수정하는 일도 새로 그리는 일이 됩니다.

원본의 형식과 보관 위치를 미리 물어보시면 됩니다.

폰트 라이선스는 이름과 용도를 함께 봅니다

사이트에 쓴 폰트는 누군가의 이름으로 산 라이선스입니다. 그 이름이 고객 회사인지 개발사인지에 따라 계속 쓰실 수 있는지가 달라집니다.

개발사 이름으로 남아 있으면 웹 폰트 서비스가 끊기는 순간 화면의 글자 모양이 바뀝니다. 방문자가 먼저 알아봅니다.

종류도 함께 보시면 되는데 데스크톱용 라이선스와 웹사이트에 올리는 라이선스는 범위가 다릅니다. 웹 사용이 포함됐는지 확인하지 않으시면 지금 화면에 쓰고 계신 폰트가 애초에 허용 범위 밖일 수 있습니다.

무료 폰트를 썼다면 걱정하실 일이 줄어듭니다. 유료라면 라이선스 증빙까지 받아 두시면 됩니다. 나중에 사이트를 새로 단장하는 리뉴얼을 하실 때 같은 폰트를 그대로 쓸 근거가 됩니다.

방문자 분석 계정과 보안 인증서를 누가 관리할지 정합니다

방문자 수를 보는 분석 도구와 검색 노출을 보는 도구의 계정도 소유자가 따로 있습니다.

개발사 이름으로 만들어진 계정이면 그동안 쌓인 방문 기록을 보시려고 또 이전 절차를 밟으셔야 합니다. 처음부터 고객 계정 아래에 만들어 두면 이 절차가 없습니다.

인증서는 주소창에 자물쇠를 띄우는 파일입니다. 유효 기간이 있어서 누군가 주기적으로 갱신해야 하는데 자동으로 갱신되는 곳이 있는가 하면 손으로 갱신하는 곳도 있습니다. 어느 쪽인지 누가 알림을 받는지 확인하시면 됩니다.

담당자를 안 정하고 넘어가시면 만료된 뒤에 아시게 됩니다. 방문자 화면에 빨간 경고가 뜨고 나서 아는 쪽이 가장 늦습니다.

글과 사진을 직접 업데이트하는 법을 배웁니다

글자 하나, 사진 한 장 바꾸는 일도 방법을 모르시면 매번 개발사에 요청하시게 됩니다. 그때마다 기다리셔야 합니다.

관리자 화면에서 글을 수정하고 이미지를 바꾸는 법을 프로젝트 종료 전에 배워 두십시오. 설명을 듣는 정도로는 부족합니다. 직접 눌러 보시고 저장까지 마쳐 보셔야 손에 남습니다.

사용법을 문서로 받아 두시면 담당자가 또 바뀌어도 다음 사람이 같은 절차를 따라갑니다. 화면 캡처 몇 장과 순서만 적혀 있어도 충분합니다.

그래서 웹사이트를 넘겨받을 때 도메인, 호스팅, 계정 권한부터 확인해야 합니까?

도메인, 호스팅, 저장소 권한이 다른 사람 이름으로 남아 있다면 먼저 확인해 볼 만합니다. 담당자가 바뀌는 날은 미리 정해지지 않습니다.

도메인과 호스팅, 저장소 권한이 다른 사람 이름으로 남아 있어도 사이트는 평소처럼 열립니다. 눈에 보이는 문제가 없으니 미루기 쉽습니다.

문제는 담당이 바뀌는 그날 드러납니다. 인증 코드를 요청하고 기다리는 동안 다음 개발사는 아무것도 수정하지 못합니다. 결제가 끊겨 사이트가 내려간 뒤에야 카드 명의를 확인하게 됩니다.

지금은 담당자에게 바로 물어볼 수 있지만 떠난 뒤에는 물어볼 사람이 없습니다. 담당자가 있는 동안 명의와 계정 정보를 받아 두시면 됩니다.

도메인, 호스팅, 저장소가 모두 이미 고객 이름으로 되어 있다면 급히 바꾸실 일은 없습니다.

엔소프 컴퍼니는 넘겨받은 웹사이트에 글이 계속 올라가도록 AI 에이전트를 개발해 드립니다

웹사이트를 넘겨받고 나면 그다음부터 채우는 일은 고객 몫이 됩니다. 담당자가 바뀌어도 사이트가 멈추지 않으려면 글이 올라가는 순서가 사람이 아니라 구조에 있어야 합니다. 고객이 원하실 경우 엔소프 컴퍼니는 넘겨 드린 사이트에 글이 계속 올라가도록 AI 에이전트를 함께 개발해 드립니다. AI 에이전트는 글 올리기 같은 되풀이 업무를 사람 대신 처리하는 프로그램입니다.

넘겨받은 사이트에는 고객이 정하신 주제로 상품 정보와 제품 사진을 이어 블로그 글을 써서 올립니다. 포털과 검색에서 만나게 될 형태로 갖춥니다.

사이트에 올린 소식은 여러 장의 이미지로 만든 카드뉴스로 바뀌어 인스타그램에도 올라갑니다.

방문과 문의 숫자는 정기 보고서로 모여 담당자가 바뀌어도 같은 방식으로 이어 볼 수 있습니다.

담당자가 바뀌는 시점에 무엇을 맡길지는 고객이 정하시면 됩니다.

직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 배포된 웹사이트와 콘텐츠 관리 환경, 계정을 넘겨드립니다. 배포는 완성한 사이트를 방문자가 볼 수 있도록 인터넷에 올리는 일입니다.

지금 사이트를 넘겨받으셨거나 넘겨받을 예정이시라면 사이트 주소를 알려 주시면 됩니다. 그 사이트에 맞는 운영 자동화를 엔소프 컴퍼니가 함께 찾아 드립니다.

프로젝트 문의하기

앱 발주를 준비하고 계십니다. 화면 목록도 정리해 두셨습니다. 그런데 스토어 계정을 누구 이름으로 열지는 아직 정하지 않으셨을 겁니다. 그 결정이 앱보다 오래 남습니다.

계정을 누구 이름으로 열지부터 정하십시오

앱스토어 계정은 원칙적으로 고객의 이름으로 엽니다. 개인 자격으로 가입하면 고객의 실명이 판매자명으로 그대로 노출됩니다. 법인 자격이면 회사명이 노출됩니다.

계정을 만든 사람이 계약의 주체가 됩니다. 계약서에 서명하고 결제 정보를 등록할 권한을 그 사람이 갖습니다. 개발사 담당자가 대신 계정을 열면 이 권한도 개발사가 가져갑니다. 고객께서 나중에 되찾으시려면 절차가 따로 붙습니다.

나중에 발주사 명의로 옮기는 절차는 있습니다. 다만 간단하지 않습니다.

법인 서류부터 준비합니다

Apple과 Google 모두 법인 계정에 D-U-N-S 번호를 요구합니다. 던앤브래드스트리트가 발급하는 사업자 식별 번호로, 신청에는 법인명, 본사 주소, 우편물 주소, 담당자 연락처가 필요합니다. 다만 개인 자격으로 가입하신다면 D-U-N-S 번호는 필요하지 않습니다.

Apple은 상호(DBA)나 지점, 개인사업자를 법인으로 인정하지 않습니다. 정식 법인격이 없으면 개인 자격으로만 가입할 수 있습니다. 이 경우 판매자명에 회사명 대신 대표자 실명이 뜹니다.

Apple 법인 계정에는 조건이 더 붙습니다. 회사 도메인(회사의 인터넷 주소)으로 된 업무 이메일과, 그 도메인으로 실제 열리는 공개 웹사이트가 있어야 합니다. 계정을 여는 사람은 회사를 법적으로 대표하거나 그 권한을 위임받은 사람이어야 합니다.

Google Play도 마찬가지로 조직 계정은 D-U-N-S 번호 없이는 계정 생성 자체가 막힙니다. 그래서 D-U-N-S 번호는 개발 착수보다 먼저 준비해야 일정이 늦어지지 않습니다.

개인정보 처리방침은 고객 회사의 정책입니다

두 회사 모두 개인정보 처리방침 URL을 필수로 요구합니다. URL은 웹페이지의 인터넷 주소입니다. Apple은 스토어 메타데이터뿐 아니라 앱 내부에도 같은 링크를 걸어야 합니다.

개인정보 처리방침에는 수집 항목, 사용 방식, 제3자 공유 방식, 보관과 삭제 방법, 동의 철회 방법이 들어갑니다. 문서 작성은 개발사가 도울 수 있지만 내용을 책임지는 쪽은 데이터를 실제로 다루시는 고객입니다.

방침이 살아 있는 URL이어야 한다는 점도 놓치기 쉽습니다. Apple 심사 지침은 제출 시점에 링크가 전부 작동해야 한다고 정해 두고 있습니다. 심사 중 방침 페이지가 열리지 않으면 링크 작동 기준을 충족하지 못합니다. 도메인과 호스팅을 누가 관리하시는지도 이때 함께 확인해 두시면 됩니다. 호스팅은 웹사이트를 인터넷에 올려 두는 공간을 빌리는 서비스입니다.

SDK가 모으는 데이터도 고객 책임입니다

Apple의 App Privacy 항목과 Google Play의 Data safety 양식이 있습니다. 둘 다 고객 팀이 직접 만든 코드 바깥까지 묻습니다. 분석 도구, 광고 네트워크, 외부 SDK가 수집하는 데이터까지 전부 포함됩니다. SDK는 다른 회사가 만든 기능을 앱에 끼워 넣는 프로그램 묶음입니다.

Google은 이 신고의 책임 소재를 분명히 밝힙니다. 정확하고 완전한 신고의 책임은 고객에게만 있다고 명시합니다. Apple도 허위 신고에는 업데이트 차단이나 앱 삭제로 대응합니다.

분석 SDK 하나를 나중에 추가하면 이 신고도 다시 써야 합니다. 어떤 SDK를 쓸지 정하시는 시점과 신고 시점이 떨어져 있으면 어긋남이 생깁니다. 신고 내용이 실제 수집 범위를 놓치기 쉽습니다.

번들 ID는 한 번 정하면 그대로 갑니다

App Store Connect에는 앱 이름, 연령 등급, 번들 ID, SKU, 기본 언어, 대표 카테고리를 등록합니다. 대부분 나중에 수정할 수 있지만 번들 ID는 예외입니다. 번들 ID는 앱마다 붙는 고유한 식별 이름이어서 빌드를 한 번 업로드하고 나면 바꿀 수 없습니다. 빌드는 스토어에 올리는 완성된 앱 파일입니다.

Firebase에 등록하는 순간에도 똑같이 고정됩니다. 분석과 백엔드를 나중에 옮기려 해도 이 값은 따라옵니다. 백엔드는 화면 뒤에서 데이터를 처리하는 서버 쪽 프로그램입니다. 번들 ID는 기술 용어처럼 보이지만 실은 착수 전에 고객이 정해야 하는 이름입니다. 회사명이나 서비스명이 바뀔 가능성이 있다면, 이 시점에 미리 확인해야 합니다.

심사에는 실제로 작동하는 앱을 올려야 합니다

Apple 심사 가이드라인은 분명합니다. 로그인이 있는 앱이라면 데모 계정 정보를 제공해야 하며 백엔드 서비스도 켜둔 채로 심사에 올려야 합니다. Google Play 역시 활성화된 데모 계정과 로그인 정보를 요구합니다.

임시 문구가 남은 화면, 내용이 없는 웹사이트, 열리지 않는 링크는 심사 반려의 원인이 됩니다.

스크린샷도 마찬가지여서 실제 화면과 다른 마케팅용 이미지는 심사에서 문제가 됩니다. 심사는 기획안이 아니라 지금 작동하는 앱을 보므로, 올리실 화면은 실제로 그렇게 나오는 화면이어야 합니다.

계정을 나중에 옮기면 잃는 것이 생깁니다

착수 단계에서 개발사 계정으로 먼저 올리고 나중에 발주사 계정으로 옮기는 방식을 고려하실 수 있습니다. 이전 절차는 실제로 있지만 문제는 무엇을 잃는지입니다.

Apple은 이전 전에 테스트 빌드와 테스터를 전부 지우도록 요구합니다. 이전 후에는 Apple Pay 가맹점 ID를 새로 만들어야 하고 프로모션 코드는 더 이상 생성할 수 없습니다. 그동안 쌓인 App Analytics 이력은 넘긴 쪽에서 더 이상 볼 수 없습니다.

Google Play도 다르지 않습니다. 테스트 그룹과 매출 리포트는 계정을 옮겨도 따라오지 않습니다. 처음부터 발주사 명의로 시작하면 이 손실 자체가 생기지 않습니다.

앱은 완성 후에도 계속 손이 갑니다

Google Play는 타깃 API 레벨을 해마다 올립니다. 타깃 API 레벨은 앱이 맞춰 만들어야 하는 안드로이드 버전 기준입니다. 이 기준보다 낮은 앱은 최신 기기에서 노출과 배포가 제한됩니다. Apple도 매번 새 버전의 Xcode와 SDK로 다시 빌드해야 제출이 이어집니다.

타깃 API 레벨 기준은 앱에 기능을 더하든 말든 해마다 올라갑니다. 코드를 한 줄도 수정하지 않아도 기준선이 올라간 날부터 배포가 막힙니다.

프로젝트 종료 후 앱을 다시 빌드할 담당자는 계약서에 적어 두어야 합니다. 만들고 넘기는 계약만 맺으면 그 일을 할 사람이 없습니다. 유지보수 항목이 있어야 앱을 계속 내려받게 할 수 있습니다.

그래서 계정 명의는 지금 정해야 합니까?

스토어 계정 명의가 아직 정해지지 않았다면 먼저 확인해 볼 만합니다. 화면 설계보다 먼저 결정할 문제입니다.

법인 계정을 만들 계획이라면 착수 전에 회사의 D-U-N-S 번호 보유 여부를 확인하십시오.

판단을 미루면 개발사 명의로 먼저 올리는 방식을 고르게 됩니다. 그러면 나중에 명의를 옮길 때 테스트 이력과 매출 리포트를 잃습니다. 번들 ID도 빌드를 한 번 올리고 나면 바꿀 수 없습니다. 처음부터 발주사 명의로 시작하면 이런 손실 자체가 생기지 않습니다.

이미 발주사 명의로 계정을 만들 준비가 되어 있다면 다음 단계로 넘어가셔도 됩니다.

엔소프 컴퍼니는 앱 발주 뒤 출시 소식과 운영 업무를 AI 에이전트로 개발해 드립니다

앱 발주 전에 고객이 직접 정하실 것들이 정해지면 출시 뒤 운영도 그려집니다. 소식을 알리고 문의를 받는 일이 그 첫 장면입니다. 고객이 원하실 경우 엔소프 컴퍼니는 출시 뒤에 되풀이될 일을 AI 에이전트가 맡는 구조로 개발해 드립니다. AI 에이전트는 출시 뒤 반복 업무를 정해 둔 기준대로 처리하는 프로그램입니다.

앱의 특징과 화면 이미지로 출시 소식 블로그 글을 만들어 검색엔진이 읽을 수 있는 형식으로 올립니다.

업데이트가 있을 때마다 카드뉴스와 게시물도 인스타그램에 올라갑니다.

앱으로 들어오는 문의는 종류별로 나뉘어 쓰시는 기록 문서에 쌓입니다.

무엇을 맡기고 어디서 사람이 확인할지는 고객이 정하시면 됩니다.

직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 승인·발행 관리 화면과 계정 인수인계를 넘겨드립니다.

발주를 준비하시면서 출시 뒤에 손으로 하실 일이 보이면 알려 주시면 됩니다. 그 일을 처음부터 AI 에이전트로 설계하는 방법을 엔소프 컴퍼니가 함께 찾아 드립니다.

프로젝트 문의하기

앱을 만들기로 하셨고 참고할 화면도 몇 장 모아 두셨습니다. 그런데 모아 두신 화면의 버튼을 누르면 무엇이 일어나는지는 아직 문장으로 남아 있지 않을 겁니다. 개발은 버튼마다 일어나는 일을 적은 문장에서 시작합니다.

만들 앱이 무엇을 하는지부터 문장으로 남깁니다

애플 앱스토어와 구글 플레이(이하 스토어)는 앱을 올리기 전에 심사합니다. 규정에 맞지 않으면 등록이 거절되며 이를 반려라고 부릅니다.

애플은 앱의 목적을 심사합니다. 애플의 앱 심사 지침(App Store Review Guidelines)에는 받지 않는 앱이 적혀 있습니다. 웹사이트를 그대로 옮긴 앱과 쓸모가 뚜렷하지 않은 앱입니다.

화면을 그리기 전에 두 가지를 정해 두시면 됩니다. 앱이 어떤 사람의 어떤 문제를 푸는지, 그 문제가 왜 앱이라야 풀리는지입니다. 앱이 푸는 문제와 앱이어야 하는 이유가 정해지지 않으면 심사에서 반려될 수 있습니다.

첫 출시에 넣을 기능과 제외할 기능을 정합니다

넣을 기능과 제외할 기능은 스토어 규정을 기준으로 삼고 로그인 기능을 넣을지부터 정해 두시면 됩니다. 애플 심사 지침은 계정을 만드는 앱이라면 계정 삭제도 앱 안에서 할 수 있어야 한다고 요구합니다. 계정이 꼭 필요한 기능이 없는 앱은 로그인 없이 쓰게 하라고도 권합니다.

유료화 방식도 첫 출시 전에 정합니다. 앱 안에서 기능이나 콘텐츠를 잠그고 푸는 방식이라면 인앱 결제를 씁니다. 인앱 결제는 앱 안에서 애플이나 구글의 결제 창으로 돈을 받는 방식입니다. 애플 심사 지침은 앱이 자체 방식으로 기능을 여는 것을 허용하지 않습니다. 라이선스 키를 입력하게 하거나 QR 코드를 읽게 하는 방식이 그 예입니다. 어떤 기능을 유료로 둘지는 화면을 그리기 전에 정해야 결제 방식이 처음부터 맞게 들어갑니다.

나중에 넣을 기능의 화면만 미리 그려 두면 심사에서 반려될 수 있으므로 첫 출시에서 제외할 기능도 정해 둡니다. 애플 심사 지침이 임시 문구와 빈 웹사이트를 제출하기 전에 지우라고 적어 두었으니 제외한 기능은 화면에서도 지웁니다.

앱의 목적, 로그인 여부, 결제 방식은 고객만 답할 수 있습니다. 답이 없으면 개발사가 가정으로 채웁니다. 개발사가 가정으로 채운 부분은 만든 뒤에야 틀렸다는 사실이 드러나기 쉽습니다.

화면 목록과 별도로 화면을 지나는 순서를 정합니다

화면 열 개를 나열하는 일과 그 화면을 어떤 순서로 지나가는지 정하는 일은 다릅니다. 화면을 지나가는 순서를 사용자 흐름이라고 부릅니다. 버튼을 누르면 다음에 무엇이 뜨는지, 오류가 나면 어디로 돌아가는지가 사용자 흐름입니다.

계정 삭제 화면을 앱 어디에 둘지와 추적 동의 화면을 어느 시점에 보여 줄지는 사용자 흐름을 정해야 압니다. 추적 동의 화면은 앱이 사용자의 행동을 추적해도 되는지 묻는 화면입니다. 계정 삭제 화면과 추적 동의 화면은 모두 애플 심사에서 요구하는 항목이어서 화면 목록만 봐서는 어디에 넣을지 알 수 없습니다.

화면 목록만 넘기면 개발사는 화면 사이의 이동을 짐작해서 이어 붙여야 합니다. 사용자 흐름이 없으면 개발사가 계정 삭제 위치를 짐작해 넣게 됩니다.

스토어에 올릴 이미지는 고객이 준비합니다

스크린샷(스토어 소개 페이지에 올리는 앱 화면 사진)과 아이콘은 고객이 준비하는 이미지입니다. 개발이 끝나면 저절로 나오는 것으로 여기시면 출시 직전에 일이 몰립니다.

아이폰 앱의 스크린샷은 애플이 정한 화면 크기별로 세트를 등록합니다. 앱이 아이패드에서도 실행되면 아이패드용 스크린샷이 따로 필요합니다. 구글 플레이는 앱 아이콘과 스크린샷, 피처 그래픽의 크기와 형식을 정해 두고 있습니다. 피처 그래픽은 소개 페이지 상단에 쓰는 가로형 이미지입니다. 두 스토어의 이미지 규격을 디자이너에게 미리 전달해 두시면 출시 직전에 다시 만드는 일을 줄일 수 있습니다.

구글 플레이의 짧은 설명(앱 이름 아래에 보이는 한 줄 소개)에는 글자 수 제한이 있습니다. 홍보 문구를 쓰기 전에 현재 제한 글자 수를 확인해 두시면 문구를 다시 쓰는 일이 줄어듭니다.

실제 화면과 다른 이미지는 심사에서 문제가 됩니다. 애플 심사 지침은 스크린샷이 앱을 실제로 쓰는 화면을 보여야 한다고 적어 두었습니다.

분석 데이터가 쌓이는 구글 계정은 고객 이름으로 만듭니다

개발자 계정의 명의와 서류는 앱 발주 전에 계정 명의와 법인 서류를 먼저 정해야 하는 이유에 따로 정리했습니다. 여기서는 앱 분석 데이터가 쌓이는 곳을 다룹니다.

앱의 사용 기록을 분석하려면 구글의 Firebase를 붙이는 방법이 있습니다. Firebase는 구글이 제공하는 앱 분석 서비스입니다. 앱 서버(화면 뒤에서 데이터를 저장하고 처리하는 프로그램) 기능도 있습니다. 이 서비스를 쓰면 구글 계정 아래에 분석 데이터를 쌓는 공간이 만들어집니다. 이 글에서는 분석 데이터를 쌓는 공간을 분석 공간이라고 부릅니다.

분석 공간을 개발사 이름의 구글 계정으로 만들면 분석 데이터가 개발사 소유로 남습니다. 프로젝트 종료 후에 고객이 데이터를 보려면 개발사에서 이전받아야 합니다. 처음부터 고객의 구글 계정 아래에 분석 공간을 만들면 이전 절차가 사라집니다.

소스 코드는 앱을 만든 원본 프로그램 파일이고 저장소는 소스 코드를 변경 이력과 함께 보관하는 곳입니다. 저장소의 소유자는 계약서에 적어 정하며 적혀 있지 않으면 프로젝트 종료 후에 접근 권한을 다시 협의하게 됩니다.

기획 문서와 시제품도 소유를 계약서에 적어 두시면 프로젝트 종료 후에 쓰실 수 있습니다. 시제품은 화면을 눌러 볼 수 있게 만든 견본입니다.

무엇을 측정할지 만들기 전에 정합니다

앱 분석에는 붙이는 순서가 있습니다. 먼저 어떤 SDK를 쓸지 정합니다. SDK는 분석 같은 기능을 앱에 붙여 주는 외부 프로그램 묶음입니다. 그다음 앱이 어떤 정보를 모으는지 스토어에 알리는 양식을 채웁니다. 애플에서는 App Privacy 항목이고 구글 플레이에서는 Data safety 양식입니다. SDK를 나중에 바꾸면 정보 수집 신고 양식도 다시 써야 할 수 있습니다.

다른 앱과 웹사이트를 넘나들며 사용자를 추적하는 광고 측정을 쓰실 계획일 수 있습니다. 그렇다면 아이폰에서는 추적 동의 화면(App Tracking Transparency)을 먼저 보여 주고 동의를 받아야 합니다. 기기를 구분하는 식별 정보를 가져오기 전에도 사용자 동의가 필요합니다. 추적 동의 문구도 개발을 시작하기 전에 정해 둘 항목입니다.

측정할 항목을 먼저 정해 두면 정보 수집 신고 양식과 추적 동의 문구를 한 번에 채울 수 있습니다. 항목을 하나씩 추가하면 그때마다 양식과 동의 문구를 다시 수정해야 합니다.

완성의 기준을 미리 정합니다

애플 심사 지침은 제출하는 앱이 기기에서 시험을 마친 최종본이어야 한다고 적고 있습니다. 실행 중에 꺼지거나 뚜렷한 기술 문제가 있는 빌드(제출용으로 묶어 낸 앱 파일)는 반려 대상입니다. 로그인이 있는 앱이라면 심사팀이 쓸 시험용 계정(데모 계정)을 넘겨야 합니다. 그 계정은 실제로 작동해야 합니다.

시험할 기기와 통과 기준은 고객이 정하고 개발사는 그 기준대로 시험합니다. 완성의 기준이 없으면 「다 됐다」는 말이 사람마다 다른 뜻이 됩니다.

프로젝트가 끝나면 서명 키와 계정 권한도 함께 받습니다

완성된 코드 파일만 받으면 다음 업데이트를 다른 곳에 맡기기 어렵습니다. 서명은 앱을 올린 곳이 누구인지 증명하는 전자 도장이며 서명용 인증서와 키가 필요합니다. 저장소 접근 권한과 분석 공간 관리자 권한까지 있어야 다음 담당자가 이어받을 수 있습니다.

스토어 계정의 소유자는 계약 갱신과 결제 정보 관리를 맡습니다. 소유자가 고객 쪽에 있어야 프로젝트 종료 후에도 계정을 고객이 직접 관리할 수 있습니다.

그래서 화면을 그리기 전에 목적, 로그인, 결제 방식부터 정해야 합니까?

네. 네. 화면 시안 전에 앱의 목적, 로그인 여부, 결제 방식, 측정 항목에 답해 두시면 시안을 다시 그릴 일이 줄어듭니다.

스토어 규정과 연결된 항목은 시안보다 더 먼저 정해 두시면 좋습니다. 계정 삭제 위치와 추적 동의 시점, 완성의 기준을 제출 직전에 정하면 화면 흐름을 다시 수정해야 할 수 있습니다.

아직 답을 정하지 못한 항목이 있다면 「미정」이라고 적어 개발사에 전달하시면 됩니다. 미정으로 적힌 항목부터 상담할 수 있습니다.

엔소프 컴퍼니는 앱 화면을 그리기 전에 정한 내용을 이어받아 출시 뒤 반복 업무를 AI 에이전트로 개발해 드립니다

앱의 목적과 사용자 흐름이 정리되면 출시 뒤에 사람이 반복하는 일도 보입니다. 문의를 접수해 분류하는 일과 이용 숫자를 모아 월 보고서로 만드는 일이 그렇습니다.

고객이 원하실 경우 엔소프 컴퍼니는 문의 접수와 월 보고서 작성을 AI 에이전트로 개발해 드립니다. AI 에이전트는 문의 접수나 기록 정리 같은 반복 업무를 사람 대신 처리하는 프로그램입니다.

AI 에이전트를 붙이면 앱으로 들어온 문의를 종류별로 나누어 한곳에 기록하게 만들 수 있습니다. 분석 공간에 쌓인 이용 숫자는 매달 보고서 한 장으로 모이는데 한 번에 모두 맡기지 않고 문의 접수 하나로 시작하셔도 됩니다.

문의를 옮겨 적고 숫자를 모으던 일이 줄면 그 일에 쓰던 직원 시간과 인건비가 함께 줄어듭니다.

프로젝트를 마치면 앱의 목적과 범위를 적은 문서와 사용자 흐름도를 넘겨드립니다. 서명용 인증서와 저장소 접근 권한, 분석 공간 관리자 권한도 고객께 이전해 드립니다. AI 에이전트를 함께 개발했다면 그 에이전트가 돌아가는 장치와 계정도 넘겨드립니다.

지금 준비 중인 앱과 출시 뒤에 직접 처리하실 반복 업무를 알려 주시면 됩니다. 그 업무를 AI 에이전트에게 어떻게 맡길 수 있는지 엔소프 컴퍼니가 설명해 드립니다.

프로젝트 문의하기

사이트를 여셨습니다. 구글에서 회사 이름을 검색해도 나오지 않습니다.

이럴 때는 순위를 올릴 방법보다 구글이 그 페이지를 목록에 넣었는지부터 보셔야 합니다.

순위 이전에 색인부터 봅니다

검색 결과에 사이트가 안 보이면 순위부터 의심하시게 됩니다. 그런데 순위는 색인된 페이지들 사이에서 매기는 계산입니다. 색인이 안 된 페이지는 애초에 그 경쟁에 끼지도 못합니다.

색인은 구글이 페이지를 찾아서 검색 결과 후보 목록에 넣는 과정입니다. 순위는 그 목록 안에서 어떤 페이지를 먼저 보여줄지 정하는 별개의 계산입니다. 두 단계를 하나로 여기면 엉뚱한 곳을 수정하게 됩니다.

순위 탓으로 돌리시기 전에 색인 여부부터 확인하는 순서가 맞습니다. 색인을 막는 원인은 오픈 전 차단, noindex 태그, robots.txt입니다. 이어서 캐노니컬 불일치, 로그인 뒤 페이지, 자바스크립트 페이지와 확인하는 법을 설명합니다.

오픈 전 차단이 오픈 후에도 남아 있는 경우

사이트를 만드는 동안에는 검색에 미리 걸리지 않도록 막아 둡니다. 제작 중인 화면이 완성되지 않은 채로 검색에 뜨면 곤란하기 때문입니다. 정상적인 절차입니다.

문제는 오픈한 뒤에 이 차단을 그대로 두는 경우입니다. 담당자가 설정 바꾸는 일을 잊거나, 다음 담당자에게 인계되지 않으면 벌어집니다.

사이트는 열렸는데 구글에는 여전히 닫힌 상태로 남습니다. 오픈하신 지 시간이 꽤 지났는데도 검색에 안 나온다면 이 차단부터 의심해 보십시오.

noindex 태그가 걸려 있는 경우

noindex는 페이지를 검색 결과에서 빼 달라는 표시입니다. 페이지 코드나 서버 설정에 한 줄로 들어가기 때문에 화면만 봐서는 걸려 있는지 알 수 없습니다. 서버는 사이트가 올라가 있는 컴퓨터입니다.

중요한 조건이 하나 있습니다. noindex가 작동하려면 그 페이지가 robots.txt(로봇의 출입을 정하는 파일)로 막혀 있으면 안 됩니다. robots.txt가 접근을 막으면 구글 로봇이 페이지 안으로 들어가지 못해서 noindex 규칙 자체를 읽지 못합니다.

그래서 둘을 동시에 걸어 두면 오히려 어긋납니다. 막아 둔 페이지 안의 noindex 지시는 구글에 보이지 않습니다. 둘 가운데 하나만 골라 쓰시는 편이 안전합니다.

noindex를 걸었는데도 검색에 한참 남아 있기도 합니다. 구글이 페이지를 다시 방문해야 규칙을 읽는데 구글 문서는 재방문에 몇 달이 걸릴 수도 있다고 적어 두었습니다. 기다리지 마시고 서치콘솔의 URL 검사 도구에서 재크롤링을 요청하십시오. 재크롤링은 구글 로봇이 페이지를 다시 읽는 일이고 서치콘솔은 구글이 무료로 제공하는 사이트 검색 상태 확인 도구입니다. URL 검사 도구는 페이지 주소 하나의 상태를 보여주는 기능입니다.

robots.txt가 접근 자체를 막는 경우

robots.txt는 구글 로봇 같은 크롤러가 들어갈 수 있는 주소를 정해 둔 파일입니다. 로봇이 사이트에 요청을 너무 많이 보내지 않게 조절하는 용도로 주로 씁니다.

여기서 오해하기 쉬운 지점이 있습니다. robots.txt로 막으면 검색에서도 빠진다고 여기기 쉽습니다. 구글 문서는 robots.txt가 페이지를 구글에서 빼는 장치가 아니라고 명확히 밝힙니다.

실제로는 반대에 가까운 일도 생깁니다. robots.txt로 막아 둔 페이지도 다른 사이트가 링크를 걸어 두면 색인될 수 있습니다. 구글 문서는 이런 페이지의 주소와 링크 문구가 검색 결과에 나타날 수 있다고 설명합니다.

페이지를 검색에서 확실히 빼고 싶으시면 robots.txt 말고 다른 방법을 쓰시면 됩니다. noindex 태그를 걸거나, 비밀번호로 보호하거나, 페이지를 아예 지우는 방법입니다. 구글 문서가 안내하는 세 가지입니다.

캐노니컬과 사이트맵이 어긋난 경우

같은 내용이 여러 주소로 열리는 사이트가 있습니다. http로 들어가는 주소와 https로 들어가는 주소, 모바일용 주소와 데스크톱용 주소, 정렬 옵션이 붙은 목록 페이지 같은 경우입니다.

이때 등장하는 개념이 캐노니컬 URL입니다. 여러 주소 중에서 구글이 대표로 고른 하나를 뜻합니다. rel="canonical" 태그로 힌트를 주실 수 있습니다. 다만 구글이 다른 페이지를 대표로 고르기도 합니다.

원하시는 페이지와 다른 페이지가 대표로 뜨면 그 주소부터 확인해 보시면 됩니다. 캐노니컬 지정이 서로 다른 페이지를 가리키거나 아예 빠져 있으면 생기는 문제입니다.

사이트맵도 함께 보시면 됩니다. 사이트 안의 페이지 목록과 관계를 구글에 알려주는 파일입니다.

링크가 잘 연결된 사이트는 사이트맵 없이도 페이지 대부분이 발견됩니다. 다만 새로 만드신 사이트는 사정이 다릅니다. 다른 곳에서 링크되지 않은 페이지를 구글이 놓칠 수 있다고 구글 문서는 설명합니다.

로그인 뒤에 있는 페이지와 자바스크립트로만 채워지는 페이지

로그인해야 볼 수 있는 페이지는 크롤러도 못 들어갑니다. 사람이 아이디와 비밀번호를 치고 들어가듯 크롤러도 그 앞에서 막힙니다. 안에 있는 내용은 구글이 아예 보지 못합니다.

화면은 잘 보이는데 정작 중요한 글자가 자바스크립트로만 채워지는 페이지도 있습니다. 자바스크립트는 웹페이지가 열린 뒤에 내용을 바꾸거나 채우는 프로그램 언어입니다. 페이지마다 사정이 달라서 단정하기 어렵습니다. 차단 설정과 캐노니컬을 모두 확인했는데도 원인이 안 나오면 이쪽을 개발사에 물어보시면 됩니다.

색인됐는지 직접 확인하는 법

가장 빠른 방법은 검색창의 site: 검색입니다. site:example.com처럼 도메인을 붙여 입력하시면 됩니다. 나오는 페이지가 있으면 그만큼은 색인돼 있다는 뜻입니다.

이 방법은 대략적인 확인용입니다. 정확한 판단은 구글 서치콘솔의 URL 검사 도구에서 하십시오. 확인하고 싶은 주소를 넣으시면 그 페이지 하나의 색인 상태를 보여줍니다.

URL 검사 도구는 크롤링과 색인 세부정보를 함께 보여줍니다. 색인됨인지 색인되지 않음인지 알려주고 색인되지 않았다면 그 이유도 알려 줍니다.

서치콘솔에는 Test live URL 기능도 있습니다. 지금 이 순간의 페이지를 구글 눈으로 즉시 테스트합니다. noindex나 robots.txt 문제를 수정한 직후에 바로 확인하기 좋습니다.

색인 확인 결과에 따라 무엇을 하면 됩니까?

색인되지 않음으로 나오면 이유를 함께 보여줍니다. noindex 태그, robots.txt 차단, 리다이렉트, 중복 페이지 같은 이유가 적혀 있습니다. 리다이렉트는 한 주소로 들어온 방문자를 다른 주소로 자동으로 보내는 설정입니다. 그 이유에 맞춰 설정을 하나씩 수정하시면 됩니다.

이유가 따로 없이 아직 크롤링 전인 경우도 있습니다. 새로 만드신 사이트라면 자연스러운 단계입니다. 사이트맵을 제출해 두시면 구글이 페이지를 발견하는 데 도움이 됩니다.

색인됨으로 나오면 그 페이지는 이미 구글 목록 안에 있습니다. 검색에 안 보이는 이유가 색인이 아니라는 뜻입니다.

이때부터는 색인이 아니라 콘텐츠의 문제로 넘어갑니다. 검색어와 페이지 내용이 맞아떨어지는 정도, 같은 검색어를 두고 경쟁하는 페이지의 수가 관건입니다. 다만 지금 단계에서는 색인이 됐다는 사실 하나만 확인하셔도 충분합니다.

그래서 지금 색인 상태를 확인해야 합니까?

검색에 안 나오는 이유를 아직 확인하지 않았다면 색인 상태부터 확인해 볼 만합니다. 안 보인다는 느낌만으로는 원인을 좁힐 수 없습니다.

오픈 직후에는 막아 둔 설정과 noindex 태그가 그대로 남아 있기 쉽습니다. 담당자가 바뀌거나 인계가 끊기면 이 설정은 아무도 수정하지 않은 채 남습니다. 그사이 구글은 페이지를 아예 모르는 상태로 있습니다.

확인을 미루면 원인을 콘텐츠 문제로 오해하고 엉뚱한 곳을 수정하게 됩니다. 색인되지 않은 페이지는 내용을 다듬어도 검색 결과에 나오지 않습니다.

서치콘솔에서 이미 색인됨으로 나온다면 순위와 콘텐츠를 살펴보셔도 됩니다.

엔소프 컴퍼니는 검색엔진이 읽을 수 있는 형식으로 글을 발행하는 일을 AI 에이전트로 개발해 드립니다

검색에 안 나올 때 색인부터 보는 이유는 읽히지 않은 페이지가 순위에 오를 수 없기 때문입니다. 그래서 글을 올릴 때마다 색인에 필요한 구조를 갖추는 일이 반복됩니다. 고객이 원하실 경우 엔소프 컴퍼니는 이 구조를 글마다 갖춰 올리는 AI 에이전트를 개발해 드립니다. AI 에이전트는 글마다 되풀이되는 준비 작업을 사람 대신 처리하는 프로그램입니다.

제목과 설명, 내부 링크를 갖추고 사이트맵에 반영해 글을 올립니다. 내부 링크는 사이트 안의 다른 글로 이어지는 링크입니다. 상품 정보와 제품 사진을 이은 글도 같은 방식입니다.

서치콘솔의 숫자를 모아 어떤 글이 읽혔는지 보고서로 정리합니다.

무엇부터 맡길지는 고객이 정하시면 됩니다.

직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 콘텐츠 작성 가이드와 초기 콘텐츠를 넘겨드립니다. 서치콘솔 연동과 지표 확인 방법을 안내하고 계정은 인수인계해 드립니다.

지금 운영 중인 사이트의 주소와 검색에 나오는지 여부를 알려 주시면 됩니다. 그 내용을 바탕으로 서치콘솔에서 먼저 확인할 항목부터 이야기를 시작하실 수 있습니다.

프로젝트 문의하기

사이트를 몇 년째 쓰고 계십니다. 정작 그 사이트가 무엇으로 만들어졌는지 물으면 답이 막힙니다. 만든 회사와는 이미 연락이 끊겼습니다.

이 글을 끝까지 읽으시면 지금 사이트가 무엇으로 만들어졌는지 직접 확인하실 수 있습니다.

사이트마다 만들어진 방식이 다릅니다

사이트를 만드는 방식은 여러 갈래입니다. 관리 도구를 빌려 쓰는 곳이 있고 코드를 처음부터 작성해 올린 곳이 있습니다.

같은 관리 도구(CMS)라도 또 나뉩니다. 매달 사용료를 내고 빌려 쓰시는 방식이 있고 고객의 서버에 직접 설치하는 방식이 있습니다. 서버는 사이트가 올라가 있는 컴퓨터입니다.

방식이 다르면 고객이 손에 쥐신 권한도 다릅니다. 도메인(사이트의 인터넷 주소) 하나를 옮기는 일조차 어느 방식이냐에 따라 방법이 달라집니다.

사이트를 만드는 방식은 크게 나뉩니다

첫째는 임대형 서비스입니다. 매달 사용료를 내고 화면과 서버를 함께 빌리는 방식입니다. 계정만 만드시면 바로 글을 올리실 수 있습니다.

둘째는 소프트웨어를 고객의 서버나 호스팅에 직접 올려 쓰는 설치형 CMS입니다. 화면 구성과 기능은 플러그인으로 늘리실 수 있습니다. 호스팅은 서버를 빌려 쓰는 서비스이고 플러그인은 기능을 더하는 추가 프로그램입니다.

셋째는 주문 제작입니다. 필요한 기능만 골라 처음부터 작성합니다. 화면 하나, 버튼 하나까지 이번 프로젝트만을 위해 새로 만들어집니다.

넷째는 정적 사이트 생성입니다. 미리 만든 틀에 내용을 넣으면 완성된 화면 파일을 생성합니다. 서버가 방문자마다 계산하지 않아 속도가 빠릅니다.

방식마다 가져가는 몫과 남는 몫이 다릅니다

임대형 서비스는 시작이 가장 가볍습니다. 대신 화면과 데이터가 그 서비스 계정 안에 남습니다. 서비스를 그만 쓰기로 하시면 글과 이미지를 하나씩 내려받아 옮기셔야 합니다.

설치형 CMS는 소프트웨어와 데이터베이스가 고객 손에 남습니다. 데이터베이스는 글과 설정 같은 정보를 저장해 두는 곳입니다. 서버를 옮기시거나 개발사를 바꾸셔도 그 소프트웨어는 그대로 따라옵니다. 다만 서버 관리와 보안 업데이트를 누가 맡을지는 따로 정하셔야 합니다.

주문 제작은 사이트를 움직이게 하는 프로그램 글인 코드 전체가 고객의 몫입니다. 코드를 보관하는 곳인 저장소의 접근 권한만 넘겨받으시면 어느 개발사와도 이어서 일하실 수 있습니다. 다만 처음 만드는 데 드는 품이 가장 큽니다.

정적 사이트 생성은 완성된 파일만 남기 때문에 어디에 올리셔도 그대로 열립니다. 다만 내용을 업데이트하실 때마다 새로 생성하는 절차가 하나 더 필요합니다.

지금 내 사이트가 무엇인지 확인하는 법

가장 빠른 방법은 관리자 화면 주소를 열어 보시는 방법입니다.

도메인 뒤에 /wp-admin 을 붙여 보십시오. 워드프레스로 만든 사이트라면 로그인 화면이 뜹니다. 워드프레스는 널리 쓰이는 CMS의 이름입니다.

로그인 화면이 안 뜨면 관리자 주소가 다르거나 워드프레스가 아닐 수 있습니다. 예전 메일함에서 「관리자」나 「admin」으로 검색해 보십시오.

계약서와 청구서도 단서입니다. 매달 나가는 청구서가 있으면 임대형 서비스일 가능성이 큽니다. 한 번 목돈이 나간 계약서만 있으면 주문 제작이었을 가능성이 큽니다.

그래도 확실하지 않으면 사이트를 만든 개발사에 직접 물어보십시오. 어떤 방식으로 만들었는지, 데이터와 코드가 지금 어디에 있는지 물어보시면 됩니다.

답을 못 들으셔도 막히지는 않습니다. 도메인과 호스팅 계정의 접근 권한만 갖고 계시면 다음 단계로 넘어가실 수 있습니다.

방식을 바꾸면 다시 해야 하는 일이 생깁니다

방식을 바꾸는 일은 이사와 비슷합니다. 글과 이미지부터 새 방식 쪽으로 옮기셔야 합니다.

주소 형식이 바뀌면 예전 주소를 새 주소로 연결하는 설정이 필요합니다. 연결하지 않으면 예전 주소로 들어온 방문자가 빈 화면을 만납니다.

디자인도 그대로 옮겨지지 않습니다. 예전 화면을 그대로 재현하시려면 새 방식에 맞춰 다시 작성해야 합니다.

옮기는 작업의 크기는 방식 차이가 클수록 커집니다. 같은 계열 안에서 서비스만 바꾸시는 경우보다 임대형에서 주문 제작으로 넘어가시는 경우에 손이 훨씬 많이 갑니다.

사이트 방식은 무엇을 기준으로 고릅니까?

첫 번째 기준은 콘텐츠를 업데이트하시는 빈도입니다. 매일 글을 올리신다면 관리 화면이 손에 익고 가벼운 쪽이 유리합니다. 한 해에 몇 번 안 업데이트하신다면 속도와 안정성이 더 중요합니다.

두 번째 기준은 업데이트하는 사람입니다. 직원분이 직접 글을 올리신다면 관리 화면이 얼마나 쉬운지가 큰 문제가 됩니다. 외부 업체에 맡기신다면 이 부분의 무게는 줄어듭니다.

세 번째는 앞으로 붙이실 기능입니다. 예약, 결제, 회원 관리처럼 사이트 성격을 바꾸는 기능을 나중에 붙일 계획이시라면, 처음부터 그 계획을 아는 방식을 고르시는 편이 유리합니다.

네 번째는 옮길 가능성입니다. 몇 년 안에 개발사를 바꾸시거나 서비스를 옮기실 생각이 있다면, 데이터를 그대로 들고 나갈 수 있는 방식이 유리합니다.

업데이트 빈도, 업데이트 담당자, 추가할 기능, 옮길 가능성에는 정답이 없습니다. 지금 상황에서 더 중요한 기준을 먼저 정하시면 방식이 좁혀집니다.

저렴한 방식에도 알맞은 경우가 있습니다

비용이 적게 드는 방식은 그만큼 기능이 단순하게 만들어져 있습니다. 기능이 단순하다고 완성도가 떨어지지는 않습니다.

규모가 작은 사이트에는 오히려 가장 알맞은 선택이 됩니다. 방문자가 하루에 몇 명 안 되는 소개 사이트에 무거운 방식을 고르시면 비용만 늘어납니다.

문제는 방식과 필요가 어긋날 때 생깁니다. 하루에도 몇 번씩 재고와 가격이 바뀌는 사이트를 가벼운 방식 위에 올려두시면 관리가 버거워집니다. 맞는 방식을 찾는 일이지 비싼 쪽을 고르는 일이 아닙니다.

잘 쓰고 있다면 옮기지 않아도 됩니다

지금 방식이 무엇이든 잘 돌아가고 있다면 그 자체로 이유가 됩니다. 방문자가 불편 없이 들어오고 담당자가 무리 없이 글을 올리고 있다면, 옮길 이유를 따로 만드실 필요는 없습니다.

옮기는 결정은 지금 방식이 운영을 막을 때 필요해집니다. 관리 화면이 느려서 글 하나 올리는 데 오래 걸리거나, 필요한 기능을 붙일 방법이 없거나, 서비스 자체가 사라질 때입니다.

옮기는 일과 무엇 위에 있는지 아는 일은 다른 문제입니다. 지금 옮기실 계획이 없어도 무엇 위에 있는지는 알아 두시면 됩니다. 다음 결정을 내리실 때 시간이 줄어듭니다.

그래서 지금 사이트 방식을 정해야 합니까?

지금 사이트가 무엇 위에 있는지 모른다면 먼저 확인해 볼 만합니다. 방식을 알면 옮길지 그대로 둘지 판단할 근거가 생깁니다.

개발사와 연락이 끊긴 채 시간이 흐르면 관리자 권한을 찾을 단서도 함께 사라집니다. 서비스가 먼저 사라지면 콘텐츠를 옮길 방법조차 없이 그대로 잃습니다.

옮기기로 하실 경우 글과 이미지가 많을수록 옮길 양이 늘어납니다.

지금 방식으로 잘 운영되고 있고 옮길 이유가 없다면 그대로 두셔도 됩니다.

엔소프 컴퍼니는 지금 홈페이지가 무엇으로 만들어졌든 맞는 자동화를 개발해 드립니다

글을 올리는 길이 방식마다 다르기 때문에 지금 홈페이지가 무엇으로 만들어졌는지 확인하면 올릴 자동화가 정해집니다. 고객이 원하실 경우 엔소프 컴퍼니는 지금 사이트의 방식에 맞춰 글이 올라가는 AI 에이전트를 개발해 드립니다. AI 에이전트는 사이트에 글을 올리는 반복 작업을 사람 대신 처리하는 프로그램입니다.

사이트 방식에 맞춰 고객이 정하신 주제의 글을 만들어 올립니다. 상품 정보와 제품 사진도 이어 쓸 수 있습니다.

올라간 글은 카드뉴스로 바뀌어 인스타그램에도 함께 오릅니다.

쓰시는 기록 문서는 그대로 두고 사이트 데이터와 이어 둡니다.

사이트 방식을 바꿀지 그대로 둘지는 고객이 정하시면 됩니다.

직원의 시간과 인건비가 줄어듭니다.

프로젝트를 마치면 고객에게 배포된 웹사이트와 글을 올리는 AI 에이전트를 넘겨드리며 계정 인수인계도 함께 해 드립니다. 배포는 만든 사이트를 인터넷에 올려 누구나 볼 수 있게 하는 일입니다.

지금 홈페이지가 무엇으로 만들어졌는지 알려 주시면 됩니다. 그 홈페이지에 글을 올리는 일을 AI 에이전트에게 맡기는 방법을 엔소프 컴퍼니가 함께 살펴 드립니다.

프로젝트 문의하기