개발 및 구현

사양에서 통합까지: OTOKO®는 애플리케이션을 개발하고 기존 시스템 및 프로세스와 연결합니다.

업무 애플리케이션이든 디지털 제품이든 내부 도구든, 저희는 기존 시스템으로는 적절히 구현할 수 없는 업무를 위한 소프트웨어를 개발합니다.

현업 부서와의 요구 사항 분석, 위협 모델, C4 모델 기반 목표 아키텍처 코드 작성에 앞선 도메인 모델, 데이터 모델, 인터페이스 계약 짧은 반복 주기의 개발과 코드 리뷰, 현업 부서의 검수 OWASP ASVS 기반의 안전한 개발, 검증된 의존성, 서명된 빌드 소스 코드, 아키텍처 문서, 운영 매뉴얼을 포함한 인계

소스 코드와 빌드 파이프라인을 갖춘 실행 가능한 애플리케이션 위협 모델을 포함한 아키텍처 문서 런북과 비상 계획을 포함한 운영 매뉴얼

현재 업무 흐름과 예외 사례 업무 결정을 담당하는 책임자 기존 시스템, 데이터 소스, 운영 요구 사항

지금까지 정비 계획은 스프레드시트로 관리되었습니다. 업무 애플리케이션은 설비, 일정, 책임 소재, 승인을 하나로 통합합니다. 첫 구축 단계에서는 한 사업장을 대상으로 하며, 다른 사업장은 프로세스에 대한 업무 검토를 마친 후에 추가됩니다.

.NET C# Go Rust TypeScript PostgreSQL

출발점은 투자 효과를 거두어야 할 업무 흐름입니다. 저희는 향후 이를 사용해 일할 사람들과 함께 용어, 상태, 비즈니스 규칙을 모델링합니다. 예를 들어 승인은 단순한 버튼 하나가 아닙니다. 대리 처리, 권한, 기한, 결정 철회가 서로 맞아떨어져야 합니다. 이러한 규칙은 데이터 모델과 테스트의 일부가 됩니다. 첫 번째 버전은 완전하게 사용 가능한 하나의 프로세스에 집중합니다. 추가 기능은 실제 사용에서 얻은 피드백을 반영하여 보완합니다. 이를 통해 미완성 화면을 잔뜩 모아 놓은 것이 아니라 검증 가능한 효용을 갖춘 제품이 만들어집니다.

백엔드, 사용자 인터페이스, 데이터 저장에 사용할 기술은 귀사의 기존 시스템 환경과 예상되는 향후 발전 방향에 따라 선택합니다. 이때 단기적인 기술 트렌드보다 기존 역량, 인터페이스, 운영 요구 사항이 더 중요하게 작용합니다. 현재 제공하는 기술에는 .NET, Go, TypeScript 등이 있으며, 시스템 수준의 구성 요소는 별도로 평가합니다. 저희는 변경 사항을 쉽게 파악할 수 있도록 모듈 경계와 책임 소재를 정의합니다. 자격 증명은 소스 코드에 두지 않으며, 업무 규칙은 사용자 인터페이스에만 두지 않습니다. 리뷰, 자동화된 검사, 버전 관리되는 데이터베이스 변경은 처음부터 구현 과정과 함께 진행됩니다.

각 반복 주기마다 알려진 제한 사항과 함께 사용 가능한 기능을 보여드립니다. 업무 검수와 기술적 승인은 별개로 다룹니다. 정확하게 계산된 주문은 업무상으로는 맞지만 부하 처리나 오류 대응이 아직 운영 수준에 이르지 못했을 수 있습니다. 각 확장 단계에 필요한 증빙은 귀사와 함께 정합니다. 합의된 제공 범위에는 소스 코드, 재현 가능한 빌드, 문서가 포함됩니다. 실제 운영 개시를 위해서는 데이터 이관, 교육, 책임 소재, 장애 대응 방식을 함께 확인합니다. 사용 권한, 타사 구성 요소, 이후 유지보수는 인계 전에 정합니다.

여러 사람이 동시에 같은 재고를 변경하더라도 애플리케이션은 정확하게 동작해야 합니다. 두 건의 예약이 아무도 모르는 사이에 마지막 남은 품목 하나를 중복 배정해서는 안 됩니다. 그래서 저희는 어떤 변경이 함께 성공해야 하는지, 어떤 충돌에 업무상 피드백이 필요한지를 정의합니다. 데이터베이스 제약 조건, 트랜잭션, 버전 검사는 이 과제의 서로 다른 부분을 해결할 수 있지만, 사용자 인터페이스만으로는 이러한 규칙을 보장할 수 없습니다. 반면 시간이 오래 걸리는 비즈니스 프로세스는 하나의 트랜잭션에 들어맞지 않는 경우가 많습니다. 주문, 외부 결제 서비스, 배송 승인은 각각 고유한 오류 상태를 가집니다. 저희는 이러한 처리 건을 명확히 파악할 수 있는 상태와 허용된 전환으로 모델링합니다. 반복되는 요청에는 적절한 처리 식별자를 부여하여 연결 중단이 자동으로 중복 작업을 일으키지 않도록 합니다. 일부 오류가 발생한 경우에는 일괄적인 기술적 재시작 대신 승인 철회와 같은 업무상 정의된 수정 절차가 필요합니다.

SaaS 제품과 내부 플랫폼의 경우, 저희는 사용자의 신원과 특정 데이터 레코드에 대한 권한을 구분합니다. 로그인한 직원이 모든 청구서나 주문을 자동으로 읽을 수 있어서는 안 됩니다. 저희는 조직, 역할, 처리 건 단위로 백엔드에서 접근 권한을 검사합니다. 내보내기, 검색 색인, 백그라운드 작업, 캐시된 결과도 이러한 경계를 준수해야 합니다. 테넌트 식별자를 사용하는 공유 테이블, 분리된 데이터베이스 스키마, 또는 별도의 데이터베이스는 각각 격리, 마이그레이션, 복구에 서로 다른 요구 사항을 가져옵니다. 저희는 필요한 분리 수준과 귀사의 운영 조직에 맞추어 모델을 선택합니다. 여러 테넌트를 대상으로 한 테스트는 특히 허용되지 않은 접근을 중점적으로 검사합니다. 감사 로그는 적절한 맥락과 함께 업무상 중요한 변경 사항을 기록하며, 여기에 어떤 데이터가 포함되고 얼마나 오래 보관되는지는 명시적으로 정합니다.

데이터 구조는 조회 방식과 비즈니스 규칙을 따릅니다. 저희는 추가적인 저장 기술을 도입하기 전에 일반적인 필터, 정렬, 분석, 쓰기 작업을 조사합니다. 제한 없는 결과 목록, 반복되는 개별 조회, 대용량 데이터 전송은 서버 부하가 거의 없어 보이는 상황에서도 애플리케이션 속도를 떨어뜨릴 수 있습니다. 실제와 유사한 데이터량으로 측정해 보면 색인, 조회 방식 변경, 페이지네이션, 또는 다른 작업 분담 방식이 도움이 되는지 알 수 있습니다. 캐싱은 데이터의 최신성에 관한 의도적인 결정입니다. 저장된 결과가 언제 무효화되는지, 어떤 사용자가 이를 볼 수 있는지가 명확해야 합니다. 대규모 연산은 백그라운드 작업으로 실행할 수 있지만, 이 경우 진행 상황 표시, 재시작 기능, 오류 상태 처리가 필요합니다. 확장을 위해 저희는 업무 규칙을 기술적 어댑터와 분리합니다. 자동화된 테스트와 버전 관리되는 데이터베이스 변경은 새로운 채널이나 다른 제공업체가 추가되어도 모든 모듈을 변경할 필요가 없도록 이러한 경계를 지켜줍니다.

애플리케이션 현황, 요구 사항, 위험 현업 부서, IT, 정보보안, OTOKO® 소프트웨어 아키텍트 평가된 과제, 현황 조사, 보안 및 운영 요구 사항

아키텍처, 기술, 운영 모델 현업 부서, 아키텍처, 개인정보 보호, 정보보안 목표 아키텍처, 위협 모델, 테스트 전략, 운영 모델, 마일스톤