Saritasa Digital Saritasa DIGITAL
프로젝트 접근 방식

Saritasa의 프로젝트 진행 방식

프로젝트가 어긋나는 이유는 대개 기술이 아니라 순서 때문입니다. 무엇을 먼저 정하고, 언제 확인하고, 변경을 어떻게 합의하는지가 결과를 좌우합니다. 이 페이지는 시작부터 설계·개발·검증·유지보수까지 단계별로 설명합니다.

프로젝트 상담 시작하기 →

첫 상담에서 정하는 것

범위를 나누기 전에 확인하는 세 가지

첫 상담은 기술 이야기보다 목표 정리에서 시작합니다. 지금 쓰고 있는 시스템이 무엇인지, 어떤 문제를 없애려는지, 언제까지 결과가 필요한지를 먼저 확인합니다. 예산 범위도 이 단계에서 대략적으로 공유합니다. 이 정보가 있어야 이후 범위를 현실적으로 나눌 수 있습니다.

이 대화에서 나온 내용은 회의 기록으로 남기고, 다음 단계에서 기능 목록으로 옮깁니다. 말로만 남은 목표는 몇 주 뒤 서로 다르게 기억되기 쉽습니다.

현재 상태

지금 있는 시스템

운영 중인 서비스, 사내 도구, 외부 연동 대상을 정리합니다. 교체할 부분과 유지할 부분을 함께 봅니다.

문제 정의

해결하려는 문제

사용자가 겪는 불편, 운영 담당자가 반복하는 수작업, 매출과 연결된 병목을 구체적으로 적습니다.

목표 시점

결과가 필요한 시점

출시일, 규제 대응 시점, 시즌 일정처럼 움직일 수 없는 날짜를 먼저 표시합니다. 일정표는 그 날짜에서 거꾸로 계산합니다.

예산 범위

예산과 투자 시점

총액의 대략적인 범위와 분기별 투입 시점을 공유합니다. 이 값이 있어야 1차 출시 범위를 무리 없이 자를 수 있습니다.

요구사항 정리와 범위 확정

정리된 목표를 기능 목록으로 바꿉니다. 이때 반드시 필요한 것과 나중에 할 것을 구분합니다. 외부 시스템 연동이 있으면 인터페이스 정의서를 함께 작성합니다. 범위를 문서로 확정하지 않으면 개발 중반에 요구가 계속 늘어납니다.

범위 문서

기능 목록을 두 층으로 나눕니다

1차

반드시 필요한 기능

출시일에 없으면 서비스가 성립하지 않는 기능입니다. 사용자 흐름을 끝까지 닫는 데 필요한 최소 범위로 잡습니다.

2차

나중에 할 기능

가치가 있지만 첫 출시를 막지 않는 기능입니다. 우선순위와 예상 규모를 함께 적어 두고 다음 분기에 다시 봅니다.

연동

외부 시스템 인터페이스 정의서

결제, 인증, 사내 ERP처럼 바깥과 주고받는 지점은 요청·응답 형식과 실패 시 동작을 문서로 고정합니다.

요구사항 정의서
기능 항목 우선순위 확정
연동 대상 인터페이스 정의
제외 범위 명시적으로 기록
확인 기준 완료 판단 근거

확정된 범위는 개발 기간 동안 기준선이 됩니다. 이후 요청은 이 문서와 비교해 변경 절차로 다룹니다.

북쪽 창광 아래 정돈된 작업 공간에서 화면을 손으로 조정하는 개발자의 어깨 너머 장면

설계 단계

설계는 화면과 데이터 구조를 함께 봅니다. 사용자 흐름, 권한 구조, 데이터 모델을 정리합니다. 보안 요구사항도 이 단계에서 반영합니다. 나중에 보안을 붙이면 구조를 다시 손봐야 하는 경우가 생깁니다.

사용자 흐름

누가 어떤 순서로 화면을 지나는지, 어디서 이탈하는지 정의합니다. 예외 경로도 함께 그립니다.

권한 구조

역할별로 볼 수 있는 데이터와 실행할 수 있는 작업을 나눕니다. 관리자 기능은 따로 분리합니다.

데이터 모델

엔터티와 관계, 보관 기간, 이력 관리 방식을 정합니다. 나중에 마이그레이션 비용을 좌우합니다.

보안 요구사항

인증 방식, 개인정보 처리, 접근 로그 기준을 설계 문서에 함께 넣습니다.

설계 문서에는 화면 흐름과 데이터 구조가 같은 버전으로 맞물려 있어야 합니다.

개발과 주간 공유

개발은 짧은 주기로 나눠 진행합니다. 각 주기 끝에 확인할 수 있는 결과물을 둡니다. 진행 상황은 주간 또는 격주로 공유합니다. 이 리듬이 맞지 않으면 프로젝트 후반에 문제가 몰립니다. 개발 중 나온 이슈는 다음 주기 계획에 반영합니다.

주기 계획

다음 주기에 만들 기능과 확인할 대상을 정합니다.

주기 결과물

직접 실행해 볼 수 있는 상태로 마무리합니다.

진행 공유

주간 또는 격주로 진행 상황과 막힌 지점을 공유합니다.

이슈 반영

개발 중 나온 이슈는 다음 주기 계획에 넣고 우선순위를 다시 봅니다.

검증과 품질 관리

검증은 기능이 요구사항대로 동작하는지 확인하는 과정입니다. 동시에 예외 상황과 실패 시 동작도 함께 봅니다. 보안 점검과 성능 확인도 이 단계에서 진행합니다. 검증 기준을 초기에 정해두면 마지막에 논쟁이 줄어듭니다.

확인 결과는 항목별로 기록합니다. 통과하지 못한 항목은 수정 후 다시 같은 기준으로 확인합니다.

  • 기능 확인

    요구사항 정의서의 각 항목이 실제로 동작하는지 확인합니다.

  • 예외 상황

    입력이 비었을 때, 연동이 실패했을 때의 동작을 함께 확인합니다.

  • 보안 점검

    인증과 권한 설정이 설계대로 적용됐는지, 접근 로그가 남는지 봅니다.

  • 성능 확인

    주요 화면의 응답 시간과 부하 상황에서의 동작을 확인합니다.

DevSecOps와 배포

보안은 설계부터 배포까지 이어집니다. 인증 구조, 비밀 관리, 배포 승인 절차를 파이프라인에 넣습니다. 배포는 자동화하되 승인 단계를 둡니다. 코드 저장소와 배포 환경의 접근 권한도 기록으로 남깁니다.

파이프라인에 들어가는 것

  1. 1

    인증 구조. 서비스 간 인증 방식과 토큰 수명, 재발급 절차를 코드로 고정합니다.

  2. 2

    비밀 관리. 키와 접속 정보를 저장소에 두지 않고, 배포 시점에 주입합니다.

  3. 3

    배포 승인 절차. 자동 배포 앞에 사람이 승인하는 단계를 두고, 승인 기록을 남깁니다.

  4. 4

    접근 권한 기록. 코드 저장소와 배포 환경에 누가 언제 접근했는지 로그로 남깁니다.

배포 승인 단계
빌드 완료 자동
검증 환경 확인 자동
운영 담당자 승인 사람
운영 환경 배포 자동

승인 단계 덕분에 배포 시점은 팀이 통제할 수 있습니다. 문제가 생겼을 때 되돌리는 절차도 같은 파이프라인에 둡니다.

변경 관리

프로젝트 중 범위 변경은 자연스러운 일입니다. 문제는 그것을 어떻게 합의하느냐입니다. 변경 사항은 일정과 비용에 미치는 영향을 함께 문서로 정리합니다. 구두 합의만 남으면 나중에 해석이 갈립니다.

변경 요청 접수

요청 내용과 배경을 먼저 적습니다. 왜 필요한지가 빠지면 대안을 비교할 수 없습니다.

일정·비용 영향 정리

며칠이 늘어나는지, 비용이 얼마나 붙는지를 같은 문서에 적습니다.

범위 기준선 갱신

승인된 변경만 범위 문서에 반영합니다. 문서가 항상 최신 상태로 유지됩니다.

구두 합의 금지

회의에서 정한 내용도 문서에 옮긴 뒤 다음 주기를 시작합니다.

매트한 회의실 탁자 위에 정리된 인수인계 자료와 노트북 옆에서 서류를 정리하는 손

인수인계

프로젝트가 끝나면 운영 주체가 필요합니다. 코드, 문서, 배포 절차를 함께 넘깁니다. 운영 담당자가 직접 배포할 수 있을 때까지 함께 확인합니다. 인수인계를 형식적으로 끝내면 이후 유지보수가 어려워집니다.

코드

저장소 접근 권한과 브랜치 운영 규칙을 함께 넘깁니다.

문서

요구사항 정의서, 설계 문서, 운영 매뉴얼을 최신 버전으로 정리합니다.

배포

운영 담당자가 직접 배포하고 되돌릴 수 있을 때까지 함께 실행합니다.

확인

인수 기준을 항목으로 정하고, 각 항목을 실제로 실행해 확인합니다.

유지보수와 다음 단계

출시 이후에는 로그와 사용 데이터를 보며 개선 지점을 찾습니다. 필요하면 정기 점검 주기를 정합니다. 다음 버전 계획은 실제 사용 데이터를 기준으로 세우는 편이 정확합니다. 이 순환이 제품을 오래 유지하게 만듭니다.

점검 주기와 범위는 운영 팀의 여력에 맞춰 정합니다. 매주 볼 지표와 분기마다 볼 지표를 나누면 부담이 줄어듭니다.

운영 주기 예시

매주 확인 오류 로그, 응답 시간
매월 확인 사용 흐름, 이탈 지점
분기마다 확인 다음 버전 후보 정리

점검 결과는 다음 버전 계획의 근거가 됩니다. 추측 대신 기록으로 우선순위를 정합니다.

자주 나오는 질문

프로젝트는 보통 어디서부터 시작하나요?+

첫 상담에서 목표와 현재 시스템, 예산 범위를 정리하는 것부터 시작합니다. 이 내용이 요구사항 정의서의 초안이 됩니다.

개발 중에 기능을 추가하고 싶으면 어떻게 되나요?+

변경 요청으로 접수해 일정과 비용에 미치는 영향을 문서로 정리한 뒤 승인 여부를 함께 결정합니다. 승인된 변경만 범위 문서에 반영합니다.

진행 상황은 얼마나 자주 공유되나요?+

주간 또는 격주로 공유합니다. 공유 자료에는 이번 주기에 만든 결과물과 막힌 지점, 다음 주기 계획이 함께 들어갑니다.

출시 후 운영은 누가 맡나요?+

인수인계 단계에서 운영 주체를 함께 정합니다. 운영 담당자가 직접 배포할 수 있게 되면 Saritasa는 정기 점검이나 다음 버전 계획으로 역할을 옮길 수 있습니다.

유지보수는 어떤 범위로 진행하나요?+

오류 대응, 보안 패치, 사용 데이터 확인, 다음 버전 후보 정리로 나눠 진행합니다. 주기와 범위는 운영 팀 상황에 맞춰 정합니다.

프로젝트 순서를 먼저 맞추면 결과가 달라집니다

Saritasa Digital은 웹, 모바일, 소프트웨어, AI, AR/VR 개발을 다루는 IT 서비스 회사입니다. 프로젝트 상담을 시작하시면 위 단계에 맞춰 일정과 협업 기준을 함께 정리해 드립니다.

  • 19900 MacArthur Blvd #650, Irvine, CA 92612, United States
  • 월요일–금요일: 오전 9:00 – 오후 6:00
  • [email protected]
프로젝트 단계
상담 범위 설계 개발 검증 배포

각 단계 끝에 확인할 수 있는 결과물을 둡니다.

상담 시작