모바일 장비의 엔터프라이즈 데이터: 가장 많은 실수 TOP 5와 방지 요령

• 원문 링크: https://lp.embarcadero.com/enterprise-data-on-mobile?utm_source=Eloqua&utm_medium=email&utm_content=Article-210609-NewWhitepapers
• 작성자(작성일): Stephen Ball (2021.6)
  

이 글은 스테픈 볼이 작성한 기술백서 ‘Enterprise Data on Mobile: Top 5 Mistakes… And How to Avoid Them!’을 요약 정리한 글입니다. 보다 자세한 내용은 다음 링크를 통해 전체 기술백서를 다운로드 받아서 확인할 수 있습니다.

• 기술백서 다운로드: https://lp.embarcadero.com/enterprise-data-on-mobile?utm_source=Eloqua&utm_medium=email&utm_content=Article-210609-NewWhitepapers

이 기술백서에서 다루는 내용

현재 많은 회사들이 모바일 앱을 이용해 업무 프로세스의 효율성을 더욱 높이고 확장하는데 관심을 기울이고 있습니다. 의도는 좋지만, 이 목표를 올바르게 관리하고, 실패 위험을 최소화해야 합니다. 만약 잘못되면 해당 프로젝트의 당초 예산보다 비용이 훨씬 더 커질 수 있기 때문입니다. 이 경우 시간과 비용, 모든 측면에서 회사의 평판이 심각하게 손상될 수 있습니다.

기술적인 측면에서 모바일은 작업 방식의 새 흐름에 잘 맞다고 볼 수 있습니다. 하지만 장기적으로 최고의 성과를 얻기 위해서는 법적으로 그리고 현실적으로 반드시 고려해야 하는 이슈들이 있습니다.

주요 이슈들로는:

• 엔터프라이즈 아키텍처에 대한 데이터 거버넌스
• 데이터 보호 규제 준수
• 현장 데이터에 관한 사업상 위험
• 장비 상에 남아있는 데이터의 관리와 저장
• 작업 변경 / 의존도 위험

이 기술백서는 비즈니스 데이터를 모바일로 이동할 때 마주하게 되는 과제들을 요약해보았습니다. 그리고 그 과정에서 가장 많이 하는 실수들을 선정하고, 비즈니스 데이터를 모바일에서 사용하는 원칙을 제시합니다. 이 보고서는 CIO, 데이터 통제 담당자, 감시자, 소유자, 보관자, 데이터베이스 관리자, 소프트웨어 개발자, 관련 법무 부서를 위해 작성되었습니다.

상황 분석: 배경과 파악된 교훈

하나의 기술이 개발되어 널리 사용되기까지는 약 10년이 걸립니다. 애플의 iOS와 구글의 안드로이드 플랫폼, 터치 기반 스마트폰과 태블릿 기술들을 떠올려보면, 그 말이 이해가 될 것입니다. 최초의 현대식 “터치” 장비가 나온 지 14년이 되었습니다. 최근 몇 년 간 현대식 모바일 장비는 터치, 위치 서비스, 카메라, 4G, 5G 등과 관련한 핵심 기능들이 정착되었고, 모바일 운영 체제들을 통해 모바일 폰은 즉시 사용 가능한 소형 포켓 컴퓨터가 될 수 있었습니다.

모바일 장비가 널리 사용되기 시작한 초창기, 시장을 주도하던 RIM (블랙베리)은 통신 부분에서 뛰어난 기술들을 제공했고, 이메일을 강화했습니다. 기업들은 직원의 생산성 향상을 위한 기술을 빠르게 받아들였죠. 당시 초기 플랫폼이 가능할 수 있었던 것은 모바일 네트워크를 통해 데이터를 활용할 수 있었기 때문이지만, 이런 모바일 장비들을 사용하도록 만든 추진력은 비즈니스 세상에서 왔다는 점을 꼭 기억해야 합니다.

하지만 현재 모바일폰 시장은 이미 성장해서 일반 사용자들의(비즈니스 목적 뿐 아니라) 수요만으로 이 시장을 이끌고 있습니다. 플랫폼들은 이와 같은 현상을 통해 이메일과 같은 전통적인 비즈니스 기능을 페이스북, 트위터, 링크드인과 같은 SNS 도구들과 효과적으로 묶어서 제공합니다. 시각적으로도 풍부하고, 시간 지연이 적은 애플리케이션들을 통해 어디에서나 즉시 접근 가능한 커다란 에코 시스템을 활용하는 추세가 더욱 지원을 받고 있는 것이죠.

스마트폰이 시장을 장악하고 있고, 스마트폰이라는 강력한 장비에 충분히 훈련되어 잘 활용하고 있는 사용자들을 비즈니스에서도 이를 활용하고 있습니다. 자기 장비를 가져와서 사용하는 즉, BYOD (Bring Your Own Device)와 CYOD (Choose Your Own Device) 정책은 현실에 더욱 잘 받아 들여졌고, 기업은 이 정책을 전략적으로 받아들여 모바일 하드웨어 관련 비용을 줄일 수 있었습니다.

디바이스 제조사들은 블랙베리의 경험을 통해 특히나 기술적 관점에서 교훈을 얻은 점이 많습니다. 그 중 분명한 한 가지는 디바이스에 있는 데이터와 오프라인 데이터를 조회하고 그 반응을 기반으로 하는 애플리케이션의 속도가 중요하다는 것입니다. 디바이스가 이런 능력을 갖춤으로서 고객의 만족도와 사용성을 크게 높일 수 있었습니다. 메인 스트림 애플리케이션들 중 상당 수도 이 기능을 개발해 자기 장비를 가져와서 사용할 수 있는 기능들을 개발하도록 했습니다.

흥미로운 한 가지. 페이스북은 처음에는 HTML5 앱으로 만들어졌지만, 순수 네이티브 앱으로 재개발 한 후 사용자들의 페이스북 이용 시간이 하루 아침에 2배가 되었습니다. 이유가 무엇일까요? 네이티브 코드 기반 앱은 사용자 경험이 훨씬 더 뛰어나고, 로컬 데이터 캐쉬에 직접 접근할 수 있어 더 강력합니다. 그 결과, 페이스북에서 사용자들이 광고를 보는 횟수가 늘어남은 물론 페이스북 주가는 18%까지 올랐습니다!

진정한 순수 네이티브 앱의 가치를 직접적으로 보여주는 사례입니다. 그리고 캐싱된 데이터가 사용자 수용과 생산성을 높일 수 있다는 것도 보여주었죠. 하지만 기업용 로컬 데이터를 저장할 때, 데이터 보안과 모바일 상의 안전한 접근은 대표적인 과제입니다. 요즘 직장인들은 모바일 장비에서 데이터를 입력하고 분석하는 것에 익숙합니다. 이는 “고객 접점”과 “내부 접점” 모두의 요구 사항에 영향을 줍니다. 점점 더 많은 기업들이 고객과의 상호작용을 모바일 플랫폼으로 옮기고 있으며, 이메일로 유지해 왔던 직원들의 업무 생산성을 보다 향상 할 수 시킬 수 있는 방안을 찾고 있습니다.

가장 많이 하는 실수 TOP 5 – 모바일에서 엔터프라이즈 데이터를 사용하고자 할 때

실수 1. “모든 것”을 모바일로 옮기려고 한다.

모바일에 엔터프라이즈 데이터를 연동하는 이유는 모바일에서 최종 사용자(end user)의 요청을 수행할 수 있는 특정 기능을 제공하기 위해서 입니다. “모바일 앱이 이 목적을 위해 이 기능을 제공해야만 하는가?” 라는 질문에 답변을 필수적으로 할 수 있어야 하지만, 간과되는 경우가 많습니다.

모바일 앱에서 제공되어야 하는 기능과 중요도가 떨어지는 것들에 대한 명확한 이해는 매우 중요합니다. 이는 프로젝트 범위 규정은 물론 앱이 전체 비즈니스에서 차지하는 비중을 결정하는 척도가 되기 때문입니다. 예를 들어, 데이터 입력과 분석 기능은 주요 기업용 소프트웨어로 수행하는 것만으로도 충분한 것과 다르게, 데이터 캡처는 모바일에서 진행함으로써 업무량을 줄일 수 있다면 이 기능은 모바일에서 사용할 수 있는 게 좋겠죠. 그렇다면 데이터 분석은 계속해서 주요 기업용 소프트웨어에서 사용할 수 있어야 합니다.

마찬가지로 모바일 앱이 주요 기업 활동의 일부분만 커버한다면, 엔터프라이즈 데이터의 해당 일부분만 지원하면 됩니다. 모바일에서 처리할 기능들을 결정해놓으면 모바일 데이터 요구 사항을 정의하는 데 도움이 됩니다. 관련 데이터만 모바일 장비에 저장하면 되는 거죠.

모바일 데이터는 비용이 듭니다! 디바이스가 유선이나 와이파이에 연결되어 있지 않으면, 보통 데이터 비용이 발생하죠. 이 비용은 모바일에 데이터가 저장되는 것과 관련이 있습니다. 그리고 숨겨진 비용도 있죠. 바로 사용되지 않는 초과 데이터 이동에 대한 비용입니다. 서버, 디바이스, 네트워크 트래픽에 로드하면 발생합니다.

디바이스로 또는 디바이스에서 데이터를 전송하는 경우 또한 마찬가지입니다. 데이터 스토리지가 변경 사항을 로깅하는 작업이 비효율적으로 되어 있다면, 데이터 처리양은 두 가지 경우 모두에서 증가하게 됩니다. 변경 사항 추적은 데이터 계층에서 관리되어야만 하는데, 이 방법이 앱 코드에서 관리하는 것보다 더 효율적입니다. 실수로 인해 누락될 수도 있는 가능성을 완전히 제거해주기 때문이죠.

이 실수 방지하기

숨김없이 명확하게! 데이터 모델링은 모바일 프로젝트를 완료하는데 필요한 논리 모델과 데이터 범위를 명확하게 파악할 수 있는 좋은 방법입니다. 데이터 관련 커뮤니케이션과 리스크/영향 분석을 시각적으로 개선할 수 있고, 모호한 데이터를 제거해 데이터의 사용 상황을 명확하게 파악할 수 있습니다.

협업 팀 도구들을 활용하면, 단순 모델링을 넘어 데이터 구조를 현실화하고 데이터 제공자와 사용자들(개발자, 데이터 컨트롤러, 데이터베이스 설계자, 데이터 이용자)이 모바일에서 사용할 수 있도록 고안된 데이터 유스 케이스(use case)까지 명확하게 이해할 수 있어 위와 같은 문제를 해소할 수 있습니다.

실수 2. 공통된 엔터프라이즈 데이터를 관리하지 않는다.

메타데이터는 필드 크기, 데이터 타입 필드명, 데이터 용도를 정의합니다. 데이터 거버넌스 모범 사례의 기본이기도 하죠. 전사적으로 동일한 메타데이터를 사용하면, 처음부터 마지막까지 데이터 호환성이 유지됩니다.

많은 기업들이 애플리케이션을 개발할 때 데이터 구조와 연관된 데이터 휠(wheel)을 다시 만들어야 한다는 함정에 빠지기 쉽습니다. 바로 이로 인해 데이터 소스 간의 비 호환성이 발생하게 됩니다. 이는 모바일과 중앙 데이터베이스에만 해당되는 문제가 아닙니다. 동일한 데이터베이스의 여러 테이블에서 사용되는 필드들에서도 문제가 발생할 수 있습니다. 예를 들어, 어떤 테이블의 ‘Person Name’ 필드에는 50글자, 또 다른 곳에서는 30글자가 저장될 수 있다면? 데이터를 병합할 때 31글자 이상인 경우 데이터 무결성에 문제가 발생할 수 있습니다.

이 실수 방지하기

데이터 비호환성을 방지하기 위해서는 액세스 가능한 메타데이터 사전(dictionary)이 핵심입니다. 데이터 도메인을 사용하면, 특정 필드 타입 (예. Name = 50 characters) 을 정의하여 도메인에 대한 변경 사항이 다른 데이터베이스에도 자동으로 업데이트 되도록 할 수 있습니다.

도메인은 논리 모델에서 생성해야 합니다. 그리고 물리 데이터베이스의 필드를 정의하는데 사용해야 하죠. 인터베이스 (멀티 디바이스를 지원하는 임베디드 형태의 확장성을 갖춘 관계형 데이터베이스)는 검사 제약 조건까지 포함하는 도메인을 지원합니다. 즉 도메인에 대한 비즈니스 로직을 일관되게 적용할 수 있습니다.

데이터 사전은 전체 팀이 모두 확인, 액세스, 쿼리 할 수 있어야 합니다. 필드의 용도와 저장할 값(value) 유형들에 대한 명확한 비즈니스 지식은 데이터 사전에서 관리해야 합니다. 아이데라(Idera)의 ER/Studio는 단순 문서 저장에만 그치는 것이 아니라, 온라인 포털과 다른 핵심 시스템에 통합 가능한 REST API를 통해 개발자, 데이터 소비자, 아키텍트, 컨트롤러 등에게 컨텍스트 정보를 확인할 수 있도록 기능들을 제공합니다.

이를 통해 모바일화(mobile-ization) 프로젝트 개발 속도를 높일 수 있습니다. 또한 장기적으로 유지 보수 가능한 일관되고 가시적인 아키텍처를 통해 데이터 작동 방식에 대한 병목 현상과 오류를 제거할 수 있습니다.

실수 3. 로컬 데이터 스토리지를 꺼려한다.

업무 환경을 모바일화 해야 하는 가장 중요한 이유는 생산성 향상과 보다 원활한 실무 직원 지원을 위해서 입니다. 로컬에 데이터를 저장하면 보안 문제도 함께 안고 가게 됩니다. 오프라인 데이터 스토리지는 비즈니스 측면에서 필수 요소입니다.

사실 실시간 연결이 필요한 작업이 많지는 않습니다. 물론 예약 시스템의 경우 실시간 데이터 피드가 필요할 수 있죠. 하지만 대부분의 다른 경우들은 오프라인 데이터 처리 기능이 더 유리합니다. 데이터를 지속적으로 주고받지 않기 때문에, 오프라인 처리 속도가 더 빠른 것이죠. 하지만 가장 중요한 점은 데이터에 항상 접근할 수 있다는 점입니다.

이 실수 방지하기

좋은 데이터 캐싱의 핵심은 업데이트를 유지하는 것입니다. 로컬 데이터 캐시에서 받아오거나 또는 로컬 데이터로 전송한 데이터 델타 (예. 변경된 데이터만 적용)를 구분하는 것은 데이터의 움직임을 최소화하여 최고의 사용자 경험(UX)을 제공하는데 필수 요소입니다. 하지만 결코 쉬운 건 아니었죠!

최근까지 가장 많이 사용되는 데이터 변경 사항을 식별할 수 있는 대표적인 접근 방식에는 두 가지가 있습니다. 바로 개발자와 복제 엔진에 대한 것인데요. 로그는 데이터가 추가 타임스탬프 필드 사용을 변경해 테이블 트리거와 로그 테이블 추적 사용이 발생하는 순간마다 변경됩니다.

이는 서버 측 데이터 이동에는 적합하지만, 모바일 환경에서는 어려움이 있을 수 있습니다. 레코드가 변경될 때마다 로그 테이블이 빠르게 증가할 수 있기 때문이죠. 예를 들어, 레코드가 10회 업데이트 되면, 로그에 10개의 엔트리가 생기게 됩니다. 필드 변경 사항이 추가되면 필드 숫자가 변경될 때마다 로그 변경 횟수가 같이 증가합니다.

두 방식 모두 필드 변경 추적에는 적합하지 않습니다. 특히 대규모로 확장할 수록 더욱 문제가 발생하죠. 인터베이스(InterBase)의 체인지 뷰(Change View) 기능을 활용하면 이 문제를 쉽게 해소할 수 있습니다. 체인지 뷰 기능은 모바일 화(Mobile-izing)된 데이터를 여러 타겟으로 이동하는데 적합합니다. 그리고 여러 사용자가 함께 업데이트를 하더라도 안전한 완전히 새로운 접근 방식입니다. 서브스크립션 모델을 사용하면 변경된 필드 레벨을 추적할 수도 있습니다. 이 기능을 통해 서버와 클라이언트 단의 모든 데이터 추적을 더욱 확장할 수 있죠. 체인지 뷰를 사용해 이동하는 데이터 양을 크게 줄일 수 있습니다.

실수 4. 모바일의 데이터 저장소가 좋은 데이터 거버넌스 및 개발 사례를 지원하지 않는다.

과거 엔터프라이즈 소프트웨어 아키텍처는 일반적으로 서버와 데스크탑 시스템으로 되어있고, 데이터 스토리지는 하나의 주요 사용자(end-user) 플랫폼으로 되어있어 비교적 관리가 간단했습니다. 반면 모바일 화(Mobile-ization) 프로젝트들은 기본적으로 다양한 플랫폼을 사용하기 때문에, 각 대상 플랫폼 뿐만 아니라 각 벤더의 플랫폼 구현(예: 안드로이드)에도 비슷한 기능들을 제공해야 하는 문제가 발생하게 됩니다.

개발 아키텍처가 클라이언트 플랫폼이 제공하는 데이터 저장소나 암호화 기능에 의존하고 있다면, 이 문제는 더욱 중요해집니다. 데이터 거버넌스와 소프트웨어 개발과 관련된 모범 사례 (예: PIA (Personal Impact Assessment) 또는 ITIL (Information Technology Infrastructure Library) 등 광범위한 실무 지침 준수)들은 위험 요소를 미리 파악함으로써 애플리케이션 라이프 사이클을 통해 위험에 대응하고 관리하고자 하고 있습니다. 이를 위해서는 지속적인 서비스 개선이 필요합니다.

배포한 디바이스와 비교해 보았을 때, 선택한 개발 머신에서 개발 팀에 동일한 기능을 제공하지 않는 데이터베이스를 선택하게 되면, 프로젝트 리스크는 증가하고 개발, 테스트, 구현에 시간을 더 많이 소요하게 됩니다. 또한 변경 요청 사항도 증가하여 위험성이 더욱 높아집니다.

BYOD와 CYOD를 선호하게 되면서, 개발 및 테스트 팀들이 처리해야 하는 작업이 매우 다양해졌습니다. 다양한 플랫폼을 통합적으로 지원하지 않는 데이터베이스에 안주하는 것으로 타협하게 될 수도 있어, 위험 요소가 더욱 커질 수 있습니다.

‘데이터 컨트롤러’ 역할은 데이터 사용 정책과 구현 / 적용의 중심에 있어야 합니다. 데이터 가시성은 데이터 보안의 필수적인 부분이므로, 데이터 계층의 일부여야 합니다. 데이터 가시성 관련 정책 (암호화 구현 포함)을 개발자가 코드로 관리할 수 있도록 방치하는 것은 흔히 하는 실수입니다. 개발자가 보안 구현을 관리하게 되면 장기간 오류가 발생하게 되고, 의도치 않은 데이터 침해 위험까지 수반합니다.

변경 관리는 여러 진입 시점에서 동일한 보안을 구현해야 하는 경우 실수가 발생할 가능성이 높아지기 때문에 변경 관리 위험성은 훨씬 더 커질 수 있습니다. 애플리케이션이 어느 시점에서든지 (단기간 일지라도) 데이터 저장소가 필요하다면, 그리고 해당 데이터에 직간접적으로 사용자 식별을 위한 정보가 포함되어 있는 경우, 관리형 데이터 가시성은 특히 더 중요합니다. 데이터 컨트롤러 역할을 해제하거나 식별하지 않는 것은 일반적으로 많이들 하는 실수이며, 이를 해결하는 것은 어렵습니다.

이 실수 방지하기

모바일 플랫폼은 여러 기술적인 문제로 인해 기존 전통적인 PC들에 비해 데이터베이스 선택폭이 작습니다. 일부 벤더사들은 외부 라이브러리 사용에 제한을 두기도 하고, 디바이스에서 실행 가능한 풋 프린트가 작은 것도 이러한 문제의 원인입니다. 그리고 여러 디바이스에 임베디드 데이터베이스 엔진을 제공하는데 기술적 문제가 발생할 수도 있죠.

여러 플랫폼을 지원하는 인터베이스와 같은 임베디드 데이터베이스를 사용하면 플랫폼들 간의 데이터 전송이 가능합니다. 이러한 데이터베이스는 애플리케이션 개발 라이프 사이클 전반에 걸쳐 데이터 관리 관련 위험을 대폭 줄일 수 있는 데이터 가시화 정책이 이미 구현되어 있는 데이터 계층이 포함되어 있습니다.

또한 개발자가 보안 분야가 아닌 UI와 성능 요구사항에 집중할 수 있게 됩니다. 무엇보다 아웃소싱 리소스로 데이터를 이동하는 이슈에 대한 우려도 덜 수 있습니다.

데이터 계층에서 데이터 가시화 정책을 구현하는 경우, 데이터 액세스 허용 및 취소를 위한 별도의 보안 로그인이 반드시 필요합니다. 데이터 액세스 보안 (인터베이스에서는 SYSDSO 로그인 방법을 사용)과 분리하여 데이터 보안성을 보장합니다.

이는 매우 중요한 사항이며 역할 기반 인증과 함께 적용하는 것이 이상적입니다. 이 작업을 데이터 계층에서 한 번 수행하면, 여러 플랫폼에서 다른 언어로 코딩하더라도 누구나 알 수 있고, 어디서든 활용 가능하도록 데이터가 구현되어 있어 데이터 정책 구현이 가능해집니다. 이를 통해 공통의 코드베이스를 위한 목표는 단순화하고 장애 발생 지점은 줄게 되어 초기 개발 비용과 위험 요소를 줄일 수 있습니다. 혹시나 변경 요청이 있더라도, 이를 구현할 때 비용을 절감할 수 있습니다.

저장 프로시저를 통해 데이터베이스에 비즈니스 로직을 포함할 수 있는 SQL 호환 데이터베이스를 사용하면 “단 한 번의 테스트로, 어디서나 사용” 할 수 있어 효율성을 높일 수 있습니다. 로직을 소스에서 확인한 다음 분산할 수 있기 때문에, 데이터 계층의 테스트 요구 사항을 크게 줄일 수 있게 되어, 모든 플랫폼에서 보다 빠르고 경제적으로 앱 출시가 가능해집니다.

실수 5. 보안과 암호화를 미루어 발생할 수 있는 규제 조치와 고객 손실을 감수해야 합니다.

보안은 모바일 환경뿐만이 아니라 모든 애플리케이션 데이터의 주요 관심사입니다. 하지만 모바일 환경에서는 데이터 보안 문제가 더더욱 중요합니다. 취약하기 때문이죠. 예를 들어, 지리적 위치나 애플리케이션을 전달할 위치와 관련된 데이터 보호 법률을 모든 사람이 알고 있지는 않습니다 (예: 미국의 주마다 법이 다를 수 있음). 즉, 누군가를 식별하기 위해 사용하게 되는 모든 데이터는 잠재적인 보안 침해이며, 256비트 AES 보안 등급으로 암호화되어 보호되어있어야 합니다. 이는 권장 사항이며, 국가에 따라 법률로 지정되어 있을 수 있습니다.

안전하지 않은 데이터는 잠재적인 데이터 침해라고 볼 수 있습니다. 그리고 이로 인해 규제 조치와 벌금까지 부과될 수도 있습니다. 조사에 따르면, 데이터 침해로 인한 비용은 고객 중 3~4%를 잃을 수 있어 재정적 손실을 넘어서는 것으로 나타났습니다. 신용 조회, 고객 유지를 위한 예상치 못한 할인 등의 추가 관련 비용도 발생하게 됩니다. 경영진 또한 책임이 있기 때문에 법적 조치까지 받을 수도 있습니다.

이 실수 방지하기

a) 보안은 시작부터 함께 고려되어야 합니다. 데이터베이스 초반 단계부터 개발, 출시, 모바일, 관리, 폐기에 이르기까지 제품 라이프 사이클 전반에 걸쳐 보안을 설정해 놓아야 합니다. 처음부터 암호화하지 않으면, 보안이 적용되지 않은 데이터가 있다는 의미이죠! 애플리케이션 라이프 사이클 중 어느 시점에서든 데이터 손실은 발생할 수 있습니다.

파일을 안전하게 보호하는 유일한 방법은 암호화를 통해 명확한 데이터 접근 정책을 따르는 것입니다. 디바이스에 암호가 있는 것만으로도 적당하고 생각한다면, 크게 잘못된 생각입니다!

b) 데이터 컨트롤러, 즉 암호화 및 액세스 권한을 강화합니다. 제품 라이프 사이클 전반에서 데이터 컨트롤러의 역할은 매우 중요하지만 간과되거나 무시되는 경우가 많습니다. 데이터 컨트롤러의 책임은 조직이 데이터를 수집, 저장, 보고, 공유하는 범위를 정의하는 것입니다. 또한 궁극적으로 조직이 데이터 사용 정책을 준수하도록 보장할 책임이 있습니다.

데이터 저장소는 데이터에 대한 단일 레코드를 추가하기 전에 적절한 액세스 권한을 구성하여 암호화해야 합니다. 기업 애플리케이션이 특정 직원의 핵심 세부 내용에 액세스 할 수 있도록 허용할 수도 있다는 뜻이죠. 따라서 데이터 컨트롤러는 데이터 계층에서 이 조건을 적용 가능한 권한이 있는 사용자만 해당 데이터를 확인하고, 검색 및 편집할 수 있도록 해야 합니다. 개발팀의 접근도 거부할 수 있습니다.

c) 개발자는 암호화를 구현할 책임은 없어야 합니다. 즉 데이터 컨트롤러의 요구를 이행할 필요가 없는 것이죠. 데이터를 분실했거나, 코드에 버그가 있다면 어떻게 해야 할까요? 보안은 데이터 계층에 있어야 하며, 수집된 데이터는 데이터가 제한된 기본값을 반환해야 합니다. 이런 방식이라면, 애플리케이션이 만에 하나 부적절하게 사용되더라도 데이터는 안전하게 보호됩니다.

d) 데이터 정책을 기능 사양에 포함하지 마세요. 법적, 운영적 또는 기타 이유로 데이터 정책은 주기적으로 변경됩니다. 반드시 필요한 경우가 아니라면, 비즈니스 상의 사유로 데이터 정책을 애플리케이션의 핵심 논리에 적용해서는 안 됩니다. 그리고 데이터 계층의 데이터 컨트롤러에 따라 데이터 정책은 구현해야 합니다.

따라서 데이터 계층 제한이 애플리케이션 기능에 영향을 미치지 않도록 하는 것이 중요합니다. 기능 사양에서 SQL 문을 지시하여 데이터를 선택하는 경우, 특별한 사용 편의성 이유가 없는 한 연결되어 있는 사용자에게 관계없이 해당 내용이 포함되어 있어야 합니다.

이를 통해 개발 주기의 위험과 향후 애플리케이션 사용에 대한 예상치 못한 동작을 관리할 수 있습니다. 애플리케이션 지원 비용은 최소화하고, 애플리케이션 개발을 단순화할 수 있습니다. 그리고 출시 기간을 단축할 수 있습니다.

결론

엔터프라이즈 애플리케이션 개발은 IT측면에서 상당히 성숙한 분야이며, 이미 많은 기업이 모범 사례를 따르고 있습니다. 모바일화(mobile-ization)가 다양한 새로운 과제를 갖고 있지만, 올바른 데이터베이스 엔진을 선택한다면 기업 데이터의 자연스러운 발전으로 확대될 것입니다.

테스트 비용을 관리하고, 통합 및 데이터 침해와 관련된 위험은 줄이고, 데이터 정책을 준수하도록 보장하기 위해서는 테스트 해야 하는 항목과 관련된 연결망을 철저하게 관리하는 게 좋습니다. BYOD나 CYOD 정책이 말처럼 쉽지는 않습니다. 가장 간단한 관리 방법은 구성이 다른 여러 플랫폼의 보안 설정과 데이터베이스 옵션이 같이 있는 변화를 미리 방지하고 모든 플랫폼에서 동일하게 작동하는 임베디드 데이터베이스를 사용하는 것입니다.

데이터베이스/데이터 계층을 선택하면, 데이터 컨트롤러와 데이터 보안팀은 데이터 액세스 권한까지 부여받게 됩니다. 개발에 영향을 주지 않고도 말이죠. 그리고 제품 라이프 사이클 전반에 걸쳐 안전한 배포가 가능하다는 이점까지 가지고 있습니다. 데이터 캐시를 최신 상태로 유지하는 새로운 방법은 최상의 경험, 확장성, 비용 절감을 위해 반드시 고려되어야 하는 필수 사항입니다.

인터베이스는 암호화, 멀티플랫폼, 소규모 내장 풋프린트, 확장 가능한 변경 추적 기능 등 위에서 언급되었던 요구사항들을 모두 지원합니다. 인터베이스 외에도 아이데라(Idera) 사의 ER/Studio 팀 서버와 같은 툴을 활용해 메타 데이터 거버넌스, 실시간 데이터 공유도 쉽게 관리할 수 있습니다.

함께 보면 좋은 기술 자료들

이 글을 작성한 스티븐 볼은 개발자는 물론 관리자급 담당자들을 위한 다양한 기술 자료들을 제공하고 있습니다. 다음을 통해 기술자료들을 확인해보세요!

• RAD스튜디오, 관리자들을 위한 안내서: https://devgear.co.kr/archives/4588
• RAD스튜디오, ‘엔터프라이즈’ 에디션을 선택하는 게 좋을까요?: https://devgear.co.kr/archives/4915

검색

12.0 12.1 AI AWS C++ c++빌더 chatgpt DelphiCon ios rad서버 RAD스튜디오 UI UIUX UX uxsummit vcl 개발 개발사례 고객사례 기술레터 기술백서 데브옵스 데이터 데이터베이스 델파이 리눅스 마이그레이션 맥 머신러닝 모바일 새버전 샘플 세미나 안드로이드 웹 윈도우 인공지능 인터베이스 출시 커뮤니티에디션 코드 클라우드 파이썬 파이어몽키 현대화