[아키텍트가 되는 방법] 4-2. 아키텍처 개발 - 개발표준 정의

본 포스팅은 아키텍트가 되기 위한 과정을 설명합니다.

---

그 열세번째 시간으로 아키텍처 개발 중 개발환경 구성 과정에 대해 살펴보도록 하겠습니다.

어플리케이션 설계 및 개발 시 준수해야 할 표준을 정의하는데 목적이 있습니다.

1. 수행절차

---

1. 제품 개발 시 설계하고 구축하기 위해 사전에 정의해야 하는 표준을 식별한다.
2. 어플리케이션 설계 및 개발에 필요한 개발표준이 필요한 경우, 개발언어 및 프레임워크의 특성을 반영하여 개발표준을 정의한다.
   • 개발에 활용될 명명 규칙 및 코딩표준을 정의하고 정제한다. 
   • 개발 시에 준수해야 하는 기본적인 개발가이드라인을 정의하고 정제한다. 
   • 사용자스토리 기반으로 분석자와 협의하여 업무 트랜잭션 유형을 정의한다. 
   • 업무 트랜잭션 유형별로 개발 표준 및 개발가이드라인을 준용하여 코드템플릿을 작성한다.
   • 아키텍처와의 일관성을 검토한다.
3. 화면설계 및 개발에 필요한 UI표준이 필요한 경우, 사용성과 관련된 사용자스토리 및 화면구현방식을 고려하여 UI표준을 정의한다.
   • 제품의 UI표준정책을 정의한다. 
   • 분석자는 화면 레이아웃 정의에 필요한 업무 유형을 정의한다. 
   • 업무 유형별 화면 레이아웃을 정의한다. 
   • 이벤트 표준을 정의한다. 
   • 화면 네비게이션 스타일을 정의한다. 
   • 화면의 시각적 요소를 제약사항을 반영하여 디자인한다. (색상 프로파일, 프레임 배치, 각 레이아웃 종류별 구성 요소 배치, 공통 사용 이미지, 폰트 등)
   • 메뉴구조의 깊이를 결정한다. 
   • 화면표준을 업무적 관점에서 검토한다.
4. 데이터 설계에 필요한 자료사전이 필요한 경우, 데이터의 속성에 사용자스토리와 관련된 데이터항목 및 DBMS의 특성을 반영하여 자료사전을 정의한다.
   • 제품의 데이터 표준화 정책을 정의한다.
   • 현행시스템이 있는 경우, 현행 데이터베이스의 속성 및 사용자스토리와 관련된 데이터항목 기반으로 표준대상 단어 및 용어를 식별한다.
   • 해당 단어 및 용어에 대한 표준을 정의하여 자료사전에 추가한다. 
   • 자료사전에 대해 상품관리담당자와 검토한다.

---

2. 수행가이드

---

1. 모든 표준은 제품백로그의 스프린트 차수를 고려하여 설계 및 개발 시에 먼저 결정되어야 할 항목부터 정의하도록 한다.
   • 즉 대부분의 사용자스토리 설계 및 개발에 공통적으로 영향을 미치는 요소부터 기준 및 가이드를 제시하고 되도록이면 이미 개발된 업무에 영향을 미치지 않도록 아키텍처를 설계하는 것이 중요하다. 
   • 예를 들어, 초기 스프린트에는 어플리케이션 프레임워크 기반 코딩 표준 및 가이드, RIA 기반 업무유형별 UI표준 및 가이드를 제공하고 중기 스프린트에는 제품 기반 표준 및 가이드, 예를 들면 연계제품기반 연계패턴별 표준 및 가이드를 제공하고, 말기 스프린트에는 어플리케이션 설계/개발에 영향을 주지 않고 적용이 가능한 시스템 공통 기능 등을 제공할 수 있다.
   • 이때 업무팀의 스프린트 백로그는 아키텍처를 정의하기 위한 input을 제공하거나 아키텍처를 검증하기 위한 사용자스토리로 구성하는 것이 바람직하다.
2. 개발표준 정의
   • 개발표준은 시스템에 포함된 다양한 제품과 프레임워크 등을 통합하여 개발하기 위하여 아키텍처 및 필요한 시스템 공통 모듈을 바탕으로 개발 표준 및 개발가이드를 제공한다.
   • 아키텍처 정의서나 유사 프로젝트 수행 경험, 또는 품질 속성 등을 고려하여 시스템 개발에 사용할 언어의 개발 표준을 정의한다. SW기술구조 유형별로 개발표준을 정의하는 것이 바람직하며, Layered Architecture인 경우 각 Layer별로 코딩 표준을 작성할 수 있다. 다국어에 대한 고려가 필요한 경우 다국어 코딩 표준을 작성할 수 있으며 필요 시 소프트웨어 글로벌화 가이드 참조한다. 
   • 제품에서 기본적으로 제공되는 코딩 규칙이나 표준이 있는 경우 해당 가이드를 활용할 수 있다.
   • 코드 템플릿은 아키텍처를 준수하여 업무 트랜잭션 유형별로 제공해야 한다. 개발표준은 문서산출물 대신 코드 Template의 주석 등을 이용하여 효과적으로 개발자에게 전달할 수 있다.
   • 시스템 공통 모듈에 대해서는 개발자가 효과적으로 활용할 수 있도록 가이드를 제공하고 일일 스크럼 미팅이나 협업시스템을 통해 공지한다. 
   • 일반적으로 시스템 공통 모듈을 체계적으로 개발하고 가이드하기 위해서는 시스템 공통팀을 별도로 구성해야 하며, 소프트웨어아키텍트(SA)가 리딩하는 것이 가장 바람직하다. 그렇지 않을 경우, 아키텍처에 맞지 않는 공통모듈이 개발되어 변경되는 일이 빈번해질 수 있다.
3. UI표준 정의
   • 이미 제품의 UI표준이 마련된 경우, 해당 표준을 준용한다. 
   • 업무 특성을 반영하여 업무 유형에 따른 화면 레이아웃 종류를 식별한다. 예를 들어, 목록조회 화면, 탭이 있는 화면, 상세조회 화면이면서 정보가 그룹별로 묶여 있는 화면 등 다양한 형태의 화면 유형을 들 수 있다. 
   • 화면 네비게이션 스타일은 업무 프로세스 및 이벤트 결과 처리 방식을 고려하여 정의한다. 
   • 공통적으로 사용하는 화면이나 화면 구성요소에서 발생하는 이벤트명과 입/출력값 등을 표준화하여 정의한다. 예를 들어 ‘고객번호조회’ 이벤트의 경우 입력값은 주민번호, 고객ID이고 출력값은 고객번호로 정의한다.
4. 자료사전 정의
   • 제품에 이미 자료사전이 정의된 경우, 기존에 정의되지 않은 추가 용어에 대해서만 정의한다
   • 자료사전 작성 시 우선 속성명을 기본단어로 분할하여 표준단어로 정의하고, 유사한 속성들을 그룹핑하여 표준도메인 을 정의하는 작업이 선행되어야 한다. 
   • 표준단어와 표준 도메인을 적용하여 자료사전을 작성하도록 한다.
   • 표준단어 정의시 이음동의어(단어명은 다르지만 동일한 의미를 가진 단어)를 취합하여 활용 빈도가 가장 높은 한글명을 표준단어로 선택하도록 한다.
   • 또한, 동음이의어(단어명은 동일하지만 다른 의미를 가진 단어)를 취합하여 상대적으로 활용 빈도가 낮은 의미의 단어에 대해 동일한 의미를 갖는 다른 한글명을 표준단어로 선택하도록 한다대부분의 DBMS는 테이블 및 컬럼 물리명의 첫 글자를 알파벳으로 시작하도록 제약하고 있으므로, 표준 단어의 영문명도 알파벳으로 시작하도록 한다. 
   • 표준단어 정의 시 접두어, 접미어와 같은 경우, 가급적 표준에서 배제하고 앞뒤에 나오는 단어와 조합하여 표준 단어로 정의하도록 한다. 
   • 현실적으로 도메인에 속하지 않는 컬럼도 존재할 수 있으므로, 모든 용어를 포괄하는 표준도메인을 생성할 필요는 없다. 
   • 자료사전 작성 시 업무별로 동일한 의미의 용어를 다른 의미의 용어로 사용하지 않도록 전사적으로 용어를 표준화하여 정의하여야 한다. 
   • 자료사전 작성 시 표준용어의 길이가 데이터 표준 원칙에서 정의한 한글명 및 영문명의 허용 길이를 넘지 않도록 한다. 
   • 표준용어의 영문명의 길이가 길어지면 한글명을 변경하거나, 한글명을 구성하는 표준단어의 일부를 조합하여 하나의 표준 단어를 추가로 등록하여 영문명의 길이를 축약하여 사용한다.

---