이 페이지에서 먼저 답하는 것
상담을 시작하면 반복해서 나오는 질문이 있습니다. 견적이 무엇으로 결정되는지, 일정에 어떤 외부 요인이 끼어드는지, 웹과 앱을 함께 만들 때 구조를 어떻게 잡는지, AI 솔루션을 어디서부터 시작하는지, 출시 후 운영과 인수인계는 어떻게 되는지, 개인정보가 포함된 데이터를 어디에 두는지입니다. 아래 아홉 가지 항목에서 순서대로 확인하실 수 있습니다.
견적
견적은 무엇으로 결정되나요
같은 기능이라도 견적이 달라지는 이유는 세 가지입니다. 연동 범위, 데이터 정리 상태, 기존 시스템과의 통합 난이도입니다. 이 세 축을 기준으로 작업 시간이 갈리고, 작업 시간이 곧 견적이 됩니다.
견적을 가르는 세 가지
- 연동 범위 결제, 알림, 지도, 외부 API처럼 바깥과 연결되는 지점의 수입니다. 한 곳이 늘면 테스트와 예외 처리도 함께 늘어납니다.
- 데이터 정리 상태 사내 문서가 어떤 형식으로 얼마나 있는지에 따라 AI 솔루션 난이도가 크게 바뀝니다. 상담 초반에 이 부분을 먼저 확인합니다.
- 기존 시스템 통합 사내 ERP, 그룹웨어, 자체 관리 도구와 얼마나 맞물려야 하는지입니다. 오래된 시스템일수록 확인에 시간이 더 듭니다.
특히 데이터 상태는 견적 전에 알기 어렵습니다. 그래서 상담 첫 미팅에서 문서 목록과 형식을 함께 훑고, 그 결과를 견적서에 근거로 남깁니다. 이 과정을 건너뛰면 나중에 범위를 다시 협의해야 합니다.
일정
일정에 영향을 주는 것
기능 수보다 외부 요인이 일정을 좌우합니다. 카카오·네이버 연동 심사, 데이터 정리, 기존 시스템 통합 범위가 대표적입니다. 연동 심사는 대기 시간이 발생하므로 계획에 미리 넣어야 합니다. 이걸 빼고 일정을 잡으면 출시 직전에 지연이 생깁니다.
일정을 잡을 때 먼저 확인하는 순서
- 1.외부 심사가 필요한 연동을 목록으로 뽑고, 심사 대기 기간을 일정 앞단에 배치합니다.
- 2.데이터 정리 작업을 개발 일정과 분리해 별도 구간으로 둡니다.
- 3.기존 시스템 통합 범위를 먼저 확정하고, 확정되지 않은 부분은 별도 단계로 표시합니다.
일정표는 주 단위로 공유하고, 외부 심사나 고객사 내부 결정이 걸린 항목은 따로 표시합니다. 어떤 항목이 우리 쪽 작업이고 어떤 항목이 대기인지 구분되어야 지연이 생겼을 때 원인을 짚을 수 있습니다.
구조
웹과 앱을 같이 만들 때
백엔드를 공유하는 구조로 설계하면 유지보수가 단순해집니다. 프론트엔드는 각각 두되 인증과 데이터 처리를 한 곳에서 관리하는 방식입니다.
모바일까지 넓힐 계획이라면 React Native 같은 크로스플랫폼을 검토합니다. 웹 인력이 모바일로 확장하기 쉽기 때문입니다. 다만 고성능 기능이 핵심이면 네이티브를 봅니다.
공유 백엔드를 택할 때
웹과 앱이 같은 데이터와 인증 규칙을 쓰는 서비스라면 이 구조가 운영 부담을 줄입니다. 권한 규칙을 한 곳에서 고치면 양쪽에 반영됩니다.
네이티브를 볼 때
카메라 제어, 실시간 처리, 기기 기능 활용이 서비스의 핵심이라면 플랫폼별로 따로 만드는 편이 낫습니다. 대신 인력과 유지보수 범위가 늘어납니다.
AI 솔루션
AI 솔루션의 시작점
챗봇부터 시작할지, 사내 검색부터 시작할지가 자주 나오는 질문입니다. 대부분의 경우 검색이 먼저입니다. 검색은 정답 판단이 명확하고 실패 영향이 작습니다. 검색 기반이 갖춰지면 요약, 질의응답, 자동 분류로 확장합니다. 이 순서를 바꾸면 근거 없는 답을 만드는 챗봇이 됩니다.
사내 검색
문서 위치와 접근 권한이 정리되어 있으면 가장 먼저 시도할 수 있습니다. 정답 여부를 판단하기 쉬워 결과 품질을 측정할 수 있습니다.
요약과 질의응답
검색이 안정된 뒤에 붙입니다. 검색 결과를 근거로 답하게 만들면 어떤 문서에서 나온 답인지 확인할 수 있습니다.
자동 분류
문의, 계약, 장애 기록처럼 반복되는 문서를 나눌 때 씁니다. 분류 기준이 사람 눈에 명확한 업무부터 적용하는 편이 안전합니다.
운영
유지보수와 인수인계
출시 후 운영 비용은 설계 단계에서 결정됩니다. 자동 확장, 로그, 알림, 장애 대응 절차를 함께 잡아야 합니다. 출시 이후에 붙이면 구조를 다시 손봐야 하는 경우가 많습니다.
저희는 인수인계 문서와 운영 매뉴얼을 남깁니다. 사내 개발팀이 이어받거나 다른 곳에 유지보수를 맡길 수 있는 상태를 목표로 합니다. 외주 의존 구조를 만들지 않는 것이 원칙입니다.
- 배포와 롤백 절차를 문서로 남겨 담당자가 바뀌어도 같은 방식으로 대응할 수 있게 합니다.
- 로그와 알림 기준을 함께 정해, 장애가 커지기 전에 알 수 있는 상태를 만듭니다.
- 정기 점검 항목과 담당자를 정하고, 매뉴얼에 그대로 적어 둡니다.
데이터
데이터와 개인정보 처리
개인정보가 포함된 데이터는 위치와 접근 권한을 먼저 정합니다. 국내 규제 대응이 중요하면 데이터 위치를 국내로 두는 구성을 검토합니다. 어디에 저장되는지가 정해지기 전에는 어떤 기능도 확정하지 않습니다.
AI 기능에 문서를 넣을 때도 같은 기준이 적용됩니다. 어떤 문서를 검색 대상에 포함할지, 접근 권한을 어떻게 나눌지가 설계 단계에서 정해집니다. 부서별로 볼 수 있는 문서를 나누는 작업이 여기에 포함됩니다.
설계 단계에서 함께 정하는 항목
- 저장 위치
- 국내 리전을 쓸지, 해외 리전을 쓸지, 혼합할지를 데이터 종류별로 나눠 정합니다.
- 접근 권한
- 역할별로 볼 수 있는 범위를 나누고, AI 검색에도 같은 규칙을 그대로 적용합니다.
- 보관 기간
- 로그와 원본 문서를 얼마나 보관할지, 삭제 요청이 들어왔을 때 어떤 절차를 따를지 정합니다.
인프라
클라우드 선택 기준
비용보다 운영 안정성과 데이터 위치를 먼저 봅니다. 한국어 검색과 국내 규제가 중요하면 Naver Cloud를, 글로벌 확장과 관리형 서비스 폭이 중요하면 AWS를 검토합니다.
둘을 섞는 구성도 실제로 쓰입니다. 다만 운영 복잡도가 올라가므로 관리 방식을 함께 정해야 합니다.
Naver Cloud
한국어 검색 품질과 국내 데이터 위치가 중요한 서비스에 맞습니다. 국내 규제 대응이 필요한 경우 검토 대상이 됩니다.
AWS
글로벌 확장과 관리형 서비스 선택 폭이 필요한 경우에 맞습니다. 해외 사용자 비중이 높다면 먼저 검토합니다.
혼합 구성
서비스별로 나눠 쓰는 방식입니다. 유연하지만 배포와 모니터링 절차를 두 곳 모두에 맞춰 관리해야 합니다.
비교
대기업 SI와 비교했을 때
대규모 시스템 통합과 공공 과제는 SI가 적합한 경우가 많습니다. 특정 기능을 빠르게 검증하거나 변화가 빠른 AI 영역은 전문 개발사가 유리합니다. 두 방식을 함께 쓰는 팀도 있습니다. 중요한 것은 규모가 아니라 어떤 문제를 어떤 순서로 풀 것인가입니다.
구분
대기업 SI
전문 개발사
프로젝트 규모
여러 조직이 얽힌 대규모 통합에 맞습니다.
범위가 분명한 기능 단위 검증과 개선에 맞습니다.
의사결정 속도
단계별 승인 절차가 있어 조정에 시간이 걸립니다.
담당자 간 논의가 짧아 방향 전환이 빠릅니다.
AI 기능 검증
표준화된 절차를 따르므로 실험 반복은 느립니다.
작은 범위로 시도하고 결과를 보고 넓히기 쉽습니다.
공공·규제 대응
문서와 절차 요건에 익숙합니다.
요건 확인은 함께 하되, 진행은 별도 협의가 필요합니다.
어느 쪽이 더 낫다고 단정하기 어렵습니다. 이미 SI와 계약이 있는 상태에서 AI 기능만 따로 검증하는 방식도 실제로 쓰입니다.
추가 질문
상담 전에 더 확인하는 것
상담은 어떤 순서로 진행되나요
요구사항을 듣고 범위를 정리하는 미팅으로 시작합니다. 이어서 연동 범위, 데이터 상태, 기존 시스템 통합 범위를 확인하고, 그 결과를 견적서와 일정표에 반영합니다. 순서를 건너뛰면 나중에 범위를 다시 협의해야 하므로 첫 단계에서 시간을 씁니다.
견적서에는 무엇이 들어가나요
작업 범위, 포함되지 않는 항목, 가정한 조건을 함께 적습니다. 외부 심사가 필요한 연동은 대기 기간을 별도 항목으로 표시합니다. 조건이 바뀌면 견적도 바뀐다는 점을 문서에 남기기 때문에, 진행 중에 기준을 두고 이야기할 수 있습니다.
일정은 얼마나 자주 공유되나요
주 단위로 진행 상황을 공유하고, 외부 심사나 고객사 내부 결정이 걸린 항목은 따로 표시합니다. 우리 쪽 작업과 대기 항목이 구분되어 있어야 지연이 생겼을 때 원인을 짚고 순서를 조정할 수 있습니다.
운영은 어디까지 지원하나요
출시 직후 안정화 기간을 두고, 로그와 알림 기준이 자리 잡을 때까지 함께 확인합니다. 이후에는 인수인계 문서와 운영 매뉴얼을 기준으로 사내 팀이 이어받거나 다른 곳에 맡길 수 있습니다. 계속 운영을 맡기는 것도, 넘기는 것도 가능한 상태를 만드는 것이 목표입니다.
이미 운영 중인 서비스도 개선할 수 있나요
가능합니다. 다만 현재 구조를 먼저 읽는 시간이 필요합니다. 문서가 부족하면 코드와 운영 기록을 기준으로 상태를 정리하고, 그 위에서 개선 범위를 정합니다. 이 정리 작업 자체를 별도 단계로 두는 편이 이후 일정이 흔들리지 않습니다.
여기 없는 질문은 문의로 남겨주세요
확인 후 답변드립니다. 상담은 월요일부터 금요일 09:00–18:00 사이에 진행되며, 프로젝트 성격에 따라 진행 방식을 먼저 확인하시는 편이 좋습니다.
Aabelia Blumen Heinen Marie-Antoinette Heinen · Konstantinstraße 218, 41238 Mönchengladbach, Deutschland · [email protected] · +82 2-549-3825