프로젝트를 시작하기 전,
궁금한 점을 먼저 확인하세요.

아이디어만 있는 초기 단계, 요구사항을 정리하는 단계, 기존 제안요청서나 기획서를 검토하는 단계 모두 가능합니다. 첫 상담에서는 현재 운영 방식과 바꾸고 싶은 문제를 확인하고, 필요한 조사와 우선순위를 함께 정리합니다.

기존 화면과 기능, 콘텐츠 구조, 운영 방식, 연계 시스템을 살펴 재사용할 부분과 다시 설계할 부분을 나눕니다. 핵심 문제가 특정 흐름에 있다면 부분 개선을, 구조적 제약이 여러 영역에 이어져 있다면 단계적인 전면 개편을 제안할 수 있습니다.

업무 영향과 기술 의존도를 살펴 화면, 기능, 데이터, 연계 영역을 전환 단위로 나눌 수 있습니다. 기존 시스템을 운영하면서 새 기능을 API(시스템끼리 데이터를 주고받는 연결 창구)로 연결하고, 검증이 끝난 영역부터 순차적으로 전환하는 방식과 단계별 점검 기준을 함께 설계합니다.

목표, 필요한 화면과 기능, 사용자 유형, 기존 시스템 연계, 데이터 이전 여부, 희망 운영 방식을 알려주시면 범위를 구체화하는 데 도움이 됩니다. 일정과 비용은 이 내용을 검토하고 우선순위, 검증 범위, 산출물을 합의한 뒤 제안합니다.

홈페이지의 문의 기능은 입력한 내용을 메일 초안으로 열어 주며 서버에 저장하거나 자동 전송하지 않습니다. 메일 앱에서 수신 주소와 내용을 확인한 뒤 직접 전송해야 합니다.

연계 대상이 제공하는 API(데이터를 주고받는 연결 창구), 데이터베이스 접근 조건, 인증 방식, 호출 제한을 먼저 확인합니다. 오래된 시스템은 직접 연결보다 중계 API나 배치(정해진 시간에 모아 한꺼번에 처리하는 방식)가 적합할 수 있으며, 실제 환경과 담당 조직의 정책에 맞춰 연계 구조를 결정합니다.

사용자 역할과 업무 흐름을 정리하는 기획부터 정보 구조, 화면 설계, 시각 디자인, 반응형 구현까지 연결할 수 있습니다. 내부 기획안이나 디자인 시스템이 있다면 이를 기준으로 필요한 영역만 맡는 방식도 가능합니다.

범위에 따라 요구사항과 화면 흐름, UI 디자인, 시스템 구성, API 정의, 소스 코드, 시험 결과, 운영 안내 등을 정리합니다. 필요한 산출물과 형식, 작성 수준은 착수 전에 합의하며 프로젝트 성격에 따라 달라질 수 있습니다.

원본 데이터의 구조와 품질, 대상 시스템의 모델, 개인정보와 보존 정책을 확인한 뒤 이전 범위를 정합니다. 표본 데이터를 이용해 변환 규칙과 검증 기준을 먼저 확인하고, 오류 처리와 전환 시점까지 계획에 포함합니다.

무상 보완, 장애 대응, 정기 점검, 기능 개선처럼 서로 다른 업무를 구분해 필요한 운영 범위를 협의합니다. 대상 시스템, 대응 시간, 배포 절차, 담당자 역할과 요청 처리 방식을 확인한 뒤 별도 유지보수 범위로 정리합니다.

웹표준과 웹 접근성, 여러 브라우저에서 화면이 같게 보이는지(크로스브라우징)는 기획 단계부터 함께 살핍니다. 사업에 적용할 접근성 기준이 있으면 단계별 확인 항목과 검수 방식을 요구사항에 맞춰 함께 정합니다.

대응 방식은 유지보수 범위를 정할 때 함께 협의합니다. 협의할 때는 장애가 서비스에 주는 영향에 따라 등급을 나누고, 등급마다 첫 대응과 복구 목표, 보고 방식, 업무 시간 밖의 연락 경로를 정해 운영 문서에 남깁니다.

대시보드를 보고 내릴 판단과 보는 사람, 지표별 계산 방식과 기준 날짜, 데이터 출처와 갱신 주기를 먼저 정합니다. 지표의 정의가 합의되면 화면은 요약에서 상세로 내려가는 질문 순서에 맞춰 구성합니다.

반복 빈도, 입력 데이터의 형태, 기대 결과를 확인할 수 있는 기준, 예외 상황과 사람의 판단 지점을 살펴봅니다. 효과를 확인하기 쉬운 작은 업무를 우선 선정하고, AI가 맡을 부분과 기존 규칙으로 처리할 부분을 나눕니다.

RAG는 질문과 관련된 내부 문서를 검색해 그 내용을 언어 모델의 답변 문맥으로 제공합니다. 문서명과 관련 구간 등 출처를 함께 보여 주도록 설계할 수 있으며, 검색되지 않은 내용에 대한 답변 제한과 담당자 확인 절차도 함께 정의합니다.

업무 적합성을 확인하려면 대표성이 있는 표본이 필요하지만, 처음부터 전체 데이터를 제공할 필요는 없습니다. 데이터 소유와 사용 권한, 민감 정보 여부를 먼저 확인하고 비식별화하거나 대체 샘플을 사용하는 방법을 검토합니다.

제한된 업무와 데이터로 모델이 필요한 결과를 만들 수 있는지, 담당자가 결과를 확인하고 수정하기 쉬운지, 시스템 연계에 어떤 제약이 있는지를 확인합니다. 평가 질문과 기준을 먼저 정하고 결과를 바탕으로 확장, 보완 또는 중단 여부를 판단합니다.

AI 결과를 그대로 확정값으로 사용하는 대신 출처, 신뢰 조건, 예외 표시와 사람의 검토 단계를 업무 중요도에 맞게 둡니다. 운영 중 수정과 실패 이력을 남기고, 반복되는 오류는 데이터와 검색 규칙, 프롬프트(AI에 주는 지시문), 업무 흐름의 개선 항목으로 관리합니다.

도입 전에 고객과 함께 정하는 항목입니다. 문서와 질문·답변 기록을 어느 환경에 보관할지, 외부 언어 모델을 쓴다면 어떤 정보를 어느 범위까지 전달할지, 개인정보와 민감한 자료를 전달 전에 가리거나 뺄지, 기록을 누가 언제까지 열람할 수 있는지를 확인합니다. 정한 기준은 설계 문서에 남기고, 운영 정책이 바뀌면 다시 검토합니다.

도입 전에 고객과 함께 정하는 항목입니다. 촬영 목적과 범위, 안내 방법, 원본 영상과 분석 결과의 보관 기간, 열람 권한을 관련 법령과 내부 정책에 맞춰 고객사의 개인정보 담당 부서와 협의합니다. 목적에 필요한 집계 결과만 남기거나 화면에서 얼굴을 가리는 방식처럼 다루는 정보를 줄이는 구성도 함께 검토합니다.

중앙부처와 공공기관의 SI 사업을 수행해 왔습니다. 민간 클라우드 기반 대국민 홍보 웹사이트, 공단의 통합 정산·결제 시스템, 자치구 대표 홈페이지, 공공도서관 디지털자료실 솔루션처럼 시민이 이용하는 웹사이트와 기관의 업무 시스템을 개발했습니다. 고객 보호를 위해 기관명과 수치는 밝히지 않습니다.

공공·기업에서 널리 검증된 표준 기술로 화면, 업무 서버, 데이터베이스를 구성합니다. 유지보수 인력을 구하기 쉽고 오래 운영할 수 있는지를 기준으로 고르며, 구체적인 구성은 기존 시스템과 운영 환경을 확인한 뒤 제안서에 명시합니다.

카드·보험사 전문 송수신 시스템에서는 보안 통신과 데이터 암호화, 송수신 모니터링과 로그 관리를 구현했습니다. 결제 단말기와 VAN(카드 결제 승인을 중계하는 부가통신망)을 연계하는 정산 시스템에서는 웹 취약점 점검으로 개인정보 위험을 줄이고 보안을 강화했습니다. 새 프로젝트에서도 권한, 데이터 보호, 로그 기준을 설계 단계에서 함께 정합니다.