박종명의 아름다운 개발 since 2010.06

구글에 의해 보다 구체화된 PWA(Progressive Web Apps)가 심심찮게 트랜드로 올라온다.

표준 웹 기술을 기반으로 모바일 환경에 최적화하려는 시도는 PWA 이전에도 많은 시도가 있었다.
PWA는 결국 이런 시도들이 하나의 개념과 기술셋으로 수렴된 결과로 이해할 수 있다.

다음 그림은 PWA의 개념을 한장의 도식으로 표현해본 것이다.

Hybrid App과는 서로 추구하는 사상과 컨셉이 달라서 굳이 비교할 필요가 없겠으나, 이 둘의 비교를 통해 PWA를 좀더 선명하게 이해할 수 있다.

결국 웹 기술을 기반으로 Native와 같은 사용자 경험을 제공한다는 것인데, 이때 중요한 것은 기존 웹의 컨셉을 여전히 계승한다는 것이다. 

한마디로 표현하자면, "웹의 사상을 유지한채 Native 化"  하자는 것. 

PWA을 실현하기 위해 사용되는 기술은 다음과 같은 것들이다.

* Web App Manifest: Native App 접근성 제공

* Service Worker: 오프라인 캐싱, 백그라운드 처리

* Push Notification: 푸시 알림

PWA Indication
위와 같은 기술요소를 사용하여 웹을 만들면 브라우저에 의해 해당 웹이 PWA인지 판별할 수 있게 된다.
브라우저가 PWA임을 인지하는 기준은 다음과 같다.
- HTTPS 사용
- Service Worker 사용
- Web App Manifest 사용
 현재 시점에서는 지원되는 브라우저가 한정되어 있다는 점 참고.

Case Study

국내 사례는 그렇게 많지 않은 듯 하다.
외국 사례 중 대표적으로 워싱턴포스터지의 모바일 웹앱을 들 수 있는데, 아무래도 모바일 사용성을 최적화 시킨 결과로 그 전에 비해 앱을 보다 많이 그리고 오랫동안 사용한다고 한다.
결국 앱의 사용성이 크게 증가하면서 앱에 접근하고 사용, 체류하는 시간이 길어지면서 고객 충성도가 올라간다는 것이다.

보다 상세한 내용은 구글 사이트를 참고.
=> https://developers.google.com/web/progressive-web-apps/
=> https://codelabs.developers.google.com/codelabs/your-first-pwapp/#0

머지않아 HTTP/2의 보편화가 예상된다.

웹 환경, 특히 모바일 기반 웹환경의 고속화에 실질적인 효익을 가져다 줄 HTTP/2는
이제 엔터프라이즈 웹 아키텍처 수립에 주요한 tactic이 될 것이다. 

HTTP/2에 대한 깔끔한 정리는 아래의 포스팅에서 확인 가능하다.

=> http://www.popit.kr/%EB%82%98%EB%A7%8C-%EB%AA%A8%EB%A5%B4%EA%B3%A0-%EC%9E%88%EB%8D%98-http2/

HTTP/2를 적용하기 위해서는 브라우저와 웹서버의 지원상황을 미리 체크해야 하며, 만일 웹 서버가 지원하지 않을 경우 웹서버에 HTTP/2 지원모듈을 설치할 수도 있다.

고무적인 것은, 대부분의 최신 모바일 디바이스의 브라우저는 이미 지원하고 있다는 것이다.

브라우저 지원 현황 보기 => http://caniuse.com/#feat=http2

아파치 지원모듈 => https://httpd.apache.org/docs/current/ko/mod/mod_http2.html
엔진엑스 지원모듈 => https://nginx.org/en/docs/http/ngx_http_v2_module.html

윈도우기반에서는 Windows 10, Windows Server 2016에서 지원된다고 하는데, 다음 글을 참고하자
=> https://blogs.iis.net/davidso/http2

참고로, 현재 TLS기반 HTTP/2만 지원해서 HTTPS 통신에 이를 사용할 수 있다고 한다.

데이터 아키텍처 영역에서, 데이터 품질은 실제 데이터 값 자체가 그 대상으로 데이이 품질관리 체계에서 가장 기본이 되는 관리요소이다.

일반적인 데이터 품질관리 프레임워크에서는 데이터 값에 대한 관점별 관리요소를 다음과 같이 제시하고 있다.

이번 포스팅에서는 데이터 값 자체에 대한 품질을 어떤 식으로 평가하고 인증하는지에 대해 기술하며, 그 기준은 한국데이터베이스진흥원의 DQC-V 심사를 기반으로 한다.

DQC-V(Data Quality Certification-Value)
한국데이터베이스진흥원에서 주관하는, 3가지 데이터 관련 인증분야(데이터인증/데이터관리인증/데이터보안인증) 중 데이터 값에 대한 인증영역으로, 그 정의는 다음과 같다.

여기서 도메인과 업무규칙이란 데이터품질을 평가하는 주요관점으로, 비즈니스 상 요구되는 데이터가 정확한 값과 범위로 일관되게 저장/관리되고 있는지를 평가하기 위한 심사항목이 된다.

두 영역에 대한 세부 심사항목과 내용은 다음과 같다 (http://www.dqc.or.kr/certi/files/DQCV_check.pdf)

도메인은 숫자/코드/ 분류와 같은 것으로, 도메인 기반 데이터 품질진단은 조직에서 사전 정의한 데이터 값과 타입, 길이, 초기값 등에 맞춰 데이터가 저장되어 있는지에를 심사하게 되며, 비교적 객관적이고 공정하게 평가할 수 있는 기술적 평가 영역이라 하겠다.

반면,

업무규칙은 실제 비즈니스에 필요한 규칙을 대상으로 하기에 조직의 특성에 따라 그 기준이 서로 상이할 수 있고 복잡하기도 해서, 도메인 기반 품질진단에 비해 심사하기가 쉽지 않은 영역이기도 하다.

데이터 품질진단 접근방식
데이터 품질진단은 크게 다음과 같이 두 가지 방법으로 접근할 수 있다.

1) Inside-Out
- 데이터베이스 그 자체로부터 문제를 발견해 나가는 방식.
- 해당 기업의 비지니스 지식이 부족해도 가능한 '기술적 분석'에 해당.
- Profiling 기법과 Data Rule을 통한 Auditing 두 가지 접근 방식이 있음

2) Outside-In
- 정보시스템 내부사용자와 외부고객의 이슈로부터 데이터 품질을 접근하는 방식
- 주로 고객센터에서 접수된 SR과 내부에서 요청되는 iSR 분석을 통해 이슈를 도출함

1. 도메인 기반 데이터 품질진단
- 데이터 프로파일링 기법으로 도메인을 분석을 수행하여 컬럼에 대한 분류를 수행하고 메타 시스템에 정의된 내역이 존재할 경우 해당 내역을 연계해야 한다. 도메인 분석에서의 분석 대상은 다음과 같이 세분화 할 수 있다.

대체로 컬럼분석/날짜분석/패턴분석은 단일컬럼의 값이 그 대상이며, 코드분석/참조무결성분석은 테이블간 관계를 고려한 분석을 수행하게 된다.

컬럼분석은 대표적으로 해당 컬럼에 저장된 값에 대해 Min/Max 값분석, Min/Max길이분석, 빈도(Count)분석, Null/Space분석을 수행하며,날짜분석은 날짜의 범위분석, 날짜포맷부석, 날짜초기값 분석 등을 주로 수행한다

패턴분석은 정형패턴분석과 비정형패턴분석으로 나뉘는데, 정형패턴분석은 주민번호나 사업자번호, 여권번호등 그 패턴이 이미 정해진 패턴 유효성을 검사하며 비정형패턴분석은 기업 내부 규약에 따른 문자체계, 번호체계를 기준으로 준수여부를 심사하게된다.

코드분석은 단일코드분석과 복합코드분석, 목록형코드 분석으로 나누며 코드의 값이 코드테이블의 규칙을 준수하고 일관성을 유지하는지를 평가하게 된다.

참조무결성분석은 말 그대로 부모-자식 테이블간 관계 정합성을 검증하게 된다. 보통 DBMS상에 참조 제약사항이 명시적으로 걸려 있으면 참조무결성이 잘 유지되며 이럴경우 품질진단에서도 결함이 거의 나오지 않는다.

2. 업무규칙 기반 데이터 품질진단
- 공공정보 품질관리 매뉴얼에 따르면 업무규칙을 다음과 같이 정의하고 있다

즉 업무규칙 기반 데이터 품질진단은, 비지니스 상 사전에 규정된 기준에 맞도록 데이터가 저장/관리되는 가를 진단하는 것이다. 따라서 품질진단을 하기 전에 업규칙을 먼저 명확히 하는 것이 매우 중요하다.

DQC-V에서는 업무규칙의 유형 분류의 예를 다음과 같이 제시하고 있다.

업무규칙은 크게 세 가지 대상으로부터 도출이 가능한데,

그 첫번재는 앞서 살펴봤던 데이터 프로파일링 결과로 부터 업무규칙을 도출하는 것이다. 프로파일링을 수행해서 오류로 판명된 결과들 중에서 영향가 있는 것, 즉 중요테이블에 적용되는 항목들대해 업무규칙화가 가능하다.

다음으로 해당 비즈니스를 수행하는 조직의 담당자와의 인터뷰나 설문 SR, iSR, VOC와 같은 것으로도 도출이 가능할 것이다. 마지막으로 해당 비즈니스에 적용되는 법령이나 규정, 지침등으로 부터 업무규칙을 하향식으로 도출이 가능하다.

이때 중요한 것은 물리적인 진단이 가능한 테이블, 컬럼단위로 업무규칙을 도출해야 하며, 가장 작은 단위의 업무규칙으로 원자화하여 작성하는 것이 좋다

* 참고자료 출처
- 한국데이터베이스진흥원, DQC-V 심사원 연수자료

꽤 어려운 필기시험을 거쳐, 1주일간의 실무교육과 실무시험을 거쳐 ISMS 인증심사원 자격을 취득했다.

기업의 정보보안관리체계의 중요성이 증가하면서, 서류전형과 실무교육만으로 주어졌던 심사원 자격이, 그 자질에 대한 논란이 부각되면서 작년부터 필기시험이 추가되었다.

공책 한권 분량의 방대한 문제가 특이했으며, 정보보안기사 실기시험의 난이도를 웃돈다는 평가와 주어진 시나리오로 결함을 찾아내는 문제가 대다수였다.

1년에 한번 있는 이 시험은, 서울의 한 곳에서만 치뤄지는데 그래서인지 필기시험 당일 상당히 많은 사람들로 시험장소가 찼던 것으로 기억한다.

그 중 나이가 지긋하신 분들도 꽤 보여, IT 인생 참 빡빡하구나 하는 생각이 들었다.

어쨌던 필기시험을 무사히 통과하고, 5일간 실제 ISMS 심사와 결함보고서 작성에 관한 실무교육을 듣고 마지막날 가상의 시나리오와 인터뷰 자료, 기업의 산출물을 바탕으로 결함을 찾고 결함보고서를 수기로 작성하는 시험을 치르고 자격을 받게 되었다.

ISMS 심사는 5일 동안 진행되는데, 실제 심사를 나가게 될 여유가 생길지 모르겠다.
여하튼 올 한해, 목표한 바 중 또 하나를 이루게 되어 기분이 좋다.

지난 일요일, KPC 정기모의고사가 있었다.

이번에 정보관리 1교시 출제와 채점을 맡게 되어, 오전부터 종일 채점하느라 정신없는 하루를 보냈다.

물론 시험을 직접 치루는 수험생들은 훨씬 힘든 하루였으리라..
기억하건데, 모의고사날은 꽤 신경이 곤두서고 체력이 크게 소진되는 하루다.

남들 노는 일요일에, 목표를 위해 달리는 많은 수험생들에게 응원을 보낸다.
그들은 성공할 자격이 있다.

(모의고사 총평) http://cafe.naver.com/81th/105410

SW 아키텍트가 알아야 할 지식체계에 대한 마인드 맵!!!

하나라도 소홀함이 없어야 할 것!

그리고 여전히 중요한 것은... 최적화, 테일러링, 프로젝트 상황에 맞는 아키텍처링.

이게 뭡니까...
서비스 기획의 문제인가요? 마케팅 부서의 양보할 수 없는 요구사항인가요?

유투브...
동영상 플레이 전에 광고 노출 시, 5초 이후 스킵 가능하도록 하여 사용성을 크게 침해하지 않으면서도 광고를 노출시키고 있다.

그리고 이 시스템 상에서의 몇몇 광고는, 5초라는 짧은 시간내에 최대한 호기심을 유발시키도록 의도하여 목적 외 대부분에 무관심한 나 같은 사람도 나머지 광고를 보게 만드는 경우가 종종 있다.

즉, 사용성을 침해하지 않는 범위에서 광고도 노출하고, 5초라는 짧은 시간 제약은 자연스럽게 광고를 만드는 사람으로 하여금 호기심 응집도를 최대한 올릴 수 있게 만드는 촉발요인이 되기도 하는 것이다.

그런데, 국내 모 동영상 서비스를 보면, 무려 다음과 같은 문구가 나온다.
"15초 이후에 광고를 건너뛸 수 있습니다"

이건 뭐.. 광고 한편 보라는 거하고 뭐가 다른지...

누군가는, 무료 동영상에 광고 좀 보면 어떠냐 하겠지만...
따라 할꺼면 제대로 따라하고, 돈 벌꺼면 확실하게 까놓고 벌기 바란다. 이도 아니고 저도 아닌 어정쩡 한거 없어 보이기 까지 한다. 정말 별로임.

일반적으로...

자신의 능력을 (짧은 시간에) 평가 받아야 하는 환경에 놓인다는 것은 적잖이 피곤한 일이다.
그것이 시험이든, 면접이든, 시합이든 어떤 상황이든 할 것 없이 말이다.

필자의 경우에도 지금까지 많은 시험과 면접에 노출되어 왔다.
(사실 늙어서 고생중이기도 하다. ㅡ,ㅡ; 어릴때 좀 하지 그랬니... 슬로우 스타터라며 위로하며 산다)

특히 면접으로만 보면, 필자처럼 많은 면접에 노출되어본 사람도 아마 드물것이다.

근래, 짧은 주기로 몇 차례 이어진 시험과 면접을 겪으면서 생각을 정리하고 싶어 펜(?)을 들었다.

도전하고 있다는 증거
이 글을 보고 있는 당신이, 곧 마주칠 결전의 날(?)을 앞두고 압박 당하고 있다면 이말을 먼저 해 주고 싶다.
 
- "아무것도 하지 않으면 아무 일도 일어나지 않는다!"

그렇다. 맥주광고에 쓰인 카피다. 흔한 말이지만 진리다.
사람은 대체로 편하고 즐거운 상태를 유지하고 싶어한다. 대부분의 사람들이 의미있는 변화를 하지 못하는 근원적 이유이기도 하다. (고인물은 썩게 마련이다)

하지만 결전을 앞둔 당신은 이미 평범하기를 거부했을 가능성이 크다.
(여기서 평범함의 거부란 남들과의 상대적 비교보다는, 늘 같은 자기자신 즉 어제의 나보다 더 나은 내가 되기를 바라는 마음의 상태로 이해되어야 한다)
   
스스로를 다독여 주기 바란다.
아무것도 하지 않는 것보다 무언가에 의미있는 도전을 시도하고 실패해 보는 것이 훨씬 값지다.

- 도전해서 손해 볼 일은 없다.
  도전은 그 자체만으로도 둘 중 하나의 결과로 당신을 도울 것이다. 성취하거나 성장하거나!

만일 수 년동안 공정하게 평가받는 경험을 하지 않고 있다면, 적당히 편한것을 계속 추구하고 있는 것이며 지금의 자신의 상태에서 더 이상의 발전을 기대하지 말아야 할 것이다.

... 리우 올림픽에 출전한 우리 선수들에게 존경을 표합니다 ...

평가(특히 면접)에 임하는 자세
이 글을 쓰고자 한 동기이다. 앞서 말한대로 누군가에게 평가 받는다는 것은 언제나 피곤한 일이다.
더욱이 그것이 자신의 인생에 의미있는 전환점을 주는 도전이라면 부담감은 더욱 커진다. 이런 부담감을 줄이고 성공과 실패에 상관없이 의미있는 결과를 얻기 위한 자세를 말하고자 한다.

1) 준비!준비!준비!
아... 이건 뭐.. 너무 식상해서 오히려 놀라울 지경이다. ㅡ,ㅡ;

그렇다! 필자가 근래 몇 번의 평가를 받는 상황을 겪으며, '어떻게 하면 평가의 피곤함을 좀 줄일 수 있을까?' 하고 고민을 거듭해 본 결과 확실히 은총알은 없다는 결론에 이르렀다.

평가에 앞서 제일 먼저 해야 할 것이, 그 평가에 특화된 준비를 하는 것이다.
특히 낯선 분야에서의 변수가 많은 면접의 경우, 준비한 내용과 완전히 동일한 질문이 나올 확률은 극히 낮을 것이다. (자기소개, 포부.. 이런거 말고...)

그럼에도 불구하고 준비는 반드시 필요하다. 
필자도 예전에는 면접은 오히려 변수가 많아서 시험보다 준비하기가 힘들고, 평소 실력대로 봐야 한다는 생각을 했던 사람이다. 그러나 근래 굵직한 몇 번의 면접을 겪으면서 면접 역시 준비의 정도에 따라 퀄리티가 달라짐을 경험했다. (아... 기술사 면접의 압박감이란... )

준비한 내용을 그대로 물어보지 않더라도, 질문 내용과 전개과정의 맥락상에서 준비한 내용이 무기가 될 수 있다. 그리고 하나도 써먹지 못한 내용이 있더라도 그 자체로써 자신을 돌아보는 계기가 될 것이다.

- "지금 당장 면접노트를 준비하라.
   예상질문을 고민하고 두괄식으로 핵심내용으로 추상화 시킨 답변을 정리하라"


2) 진인사대천명
이제는 평가 당일날에 가져야 할 마음가짐에 대해 얘기하고자 한다. 사전 준비가 되었다는 가정하에, 다음의 한자성어를 결전의 당일날 되새기며 마음을 바로잡자.

필자가 굉장히 좋아하는 말이다. 

Node.js가 콘솔기반의 자체 HTTP 서버를 제공해 준다고는 하지만...

80포트 공유, 멀티 도메인과 서브 도메인 설정, HTTP 요청 로그, 동시 접속자 및 요청 큐 대기 상황, 웹 팜 및 웹 가든 구성, 디렉티브 권한 설정 등등 기존 IIS나 Apache 기반 환경에서 자주 사용했던 웹 서버 관련 사항은 어떻게 해야 하는가?

그리고 기존 IIS와 같은 웹 서버 환경에 추가하여 동시에 운용하고자 하는 경우는?

실무에서는 HTTP 통신서버의 비즈니스 기능 외에 다양한 옵션 및 환경설정이 요구되는데, Node.js가 이 부분을 모두 수용할 수 있는가?

솔직히 아직 Node.js를 복잡한 실무환경에서 제대로 적용해 보지 않은터라, 자세히 알지 못한다.

다만, IIS와 같은 나름 검증된 웹 서버에 호스팅되어 서비스 되면 좋겠다는 생각을 해 보던 차, 다음의 글을 발견했다.

http://www.sysnet.pe.kr/2/0/1556

한번 설정해 봐야 겠다.

이글을 보는 누군가, 기존 IIS 서버등에서 사용했던 많은 웹 서버 기능들을 Node.js 자체 환경에서도 여전히 안정적으로 사용가능한지 말해 줄 사람이 있다면, 댓글을 부탁드립니다.

AngularJS는 HTML 폼을 확장하여 입력요소에 자바스크립트 객체를 바인딩하고, 전체 폼 또는 개별 입력요소에 대한 유효성 검사를 추가할 수 있는 방법을 제공한다.

* 폼의 데이터 바인딩
- 폼의 입력요소와 AngularJS의 상호작용은 (뷰와 컨트롤러의 상호작용이 늘 그렇듯이) $scope 객체를 매개로 이뤄진다. 폼 요소와 $scope 객체의 관계를 확인하기 위해 다음과 같이 간단한 코드를 작성해 본다.

input 박스에 ng-model 디렉티브를 선언하고, 바로 밑 <p> 요소에 ng-bind 디렉티브를 동일한 이름으로 선언하였다. (ng-bind 대신 '{{ name }} ' 형태의 표현식으로 해도 동일하게 동작한다)

코드를 실행해 보면, input 요소에 입력한 값들이 자동으로 <p> 요소에 반영되어 데이터가 같이 변경되는 것을 확인할 수 있다.

이와 같은 폼 요소에 대한 자동 바인딩 내부에는 $scope 객체가 존재한다.
코드에서는 명시적으로 $scope 객체에 name이라는 속성을 추가한 적은 없지만, ng-model 디렉티브로 인해 입력요소에 값이 입력되는 순간 $scope에 name라는 속성이 자동으로 추가된다.

콘솔로그를 통해 확인해 보자.
코드가 처음 브라우저에 로딩된 순간에는 $scope객체에 name이 속성을 찾을 수 없다. 그러나 input요소에 값을 입력하는 순간 자동으로 $scope객체에 name속성이 (입력 값과 함께) 자동으로 추가된다. 다음 그림은 콘솔로그를 통해 확인해 본 것이다.

결국 뷰와 컨트롤러의 데이터바인딩은 $scope 객체를 통해 이뤄지며, 이는 폼 요소에 대한 ng-model 디렉티브 설정을 통해 $scope객체의 속성과 연결되어 양방향 바인딩이 자동으로 이뤄지는 메커니즘이다.

* 폼의 입력요소
폼의 입력요소에는 다음과 같은 것들이 있다.
- input 엘리먼트: 텍스트박스, 체크박스, 라디오 버튼 등 입력요소
- select 엘리먼트: 여러개의 아이템 중 하나를 선택할 수 있는 입력요소
- textarea 엘리먼트: 여러 행의 글을 작성할 수 있는 입력요소
- button 엘리먼트: 클릭으로 명령을 전송할 수 있는 입력요소

* CheckBox
- 다음 코드는 체크박스에 대한 AngularJS의 임의구현이다.  첫 번째 체크박스의 ng-model 값을 두 번째 체크박스의 ng-checked 디렉티브로 연결하고 있다. 이렇게 하면 두 번째 체크박스는 첫 번째 체크박스의 선택여부에 동기화되어 선택/해제 된다.
그리고 ng-show 디렉티브는 첫 번째 체크박스의 선택여부에 따라 화면에 표시할 지 여부를 결정한다.

* RadioButton
- 다음 코드는 라이오버튼에 대한 AngularJS의 임의구현이다. 라이브버턴 마다 ng-model을 설정하고 {{xxx}} 표현식으로 선택된 값을 출력한다. 그리고 ng-switch계열 디렉티브를 통해 조건식을 구현할 수 있다.

* SelectBox
- 라이브버튼과 거의 유사한 임의코드이다.

* AngularJS의 폼 확장
- AngularJS는 표준 HTML 폼 요소를 확장한 form 디렉티브와 폼의 상태를 추적하기 위한 FormController 컨트롤러의 인스턴스를 생성해 폼을 관리한다.

HTML페이지의 폼의 name 특성을 통해 폼이름을 지정하면 $scope객체에 지정된 이름으로 폼 객체가 추가되며 하위 폼 요소들도 주어진 이름으로 추가된 폼 객체의 하위 프로퍼티로 자동 추가된다. 이후 이들 이름을 기반으로 뷰 및 컨트롤러에서 폼 요소들을 참조하여 특정 작업을 수행할 수 있다.

폼 요소들이 지정된 name값을 기반으로 $scope 객체에 자동추가 된다는 것을 눈으로 확인해보자.
다음과 같은 입력요소를 하나 가지는 간단한 폼을 만든다. 주의할 점은 폼요소가 모두 로딩된 후 $scope 객체를 확인해야 하므로 <script> 요소를 </body> 직전에 위치 시켰다. (일반적으로 스크립트 태그는 이 위치에 두는 것을 권장하는데, 이는 DOM 구성이 스크립트 로딩과 실행으로 지연되지 않도록 하기 위함으로 모든 DOM이 구성되고 난 후 안정적으로 스크립트를 실행시키기 위함도 있다.)

지금 상황에서 input 요소에 ng-model 디렉터리가 꼭 필요한 것은 아니지만, AngularJS는 ng-model 디렉티브가 추가된 입력요소에 한해서 $scope 객체에 등록시키기 때문에 추가한 것이다.
결과로 본 콘솔로그는 다음과 같다.

이렇게 폼 요소의 name 값을 기준으로 $scope객체에 자동추가 되기 때문에, 이후 컨트롤러나 뷰에서 해당 폼 요소의 이름으로 접근 가능한 것이다.

* 폼과 입력필드의 상태(폼 유효성 검사의 기반)
- AngularJS는 폼의 유효성 검사를 위해 폼과 입력요소의 상태값을 지속적으로 감시하고 관리한다.
다음은 각각 폼과 입력필드의 상태를 알 수 있는 참조변수를 보여준다.

사용자 반응에 따른 폼과 입력요소의 상태값 변화를 눈으로 확인해 보기 위해, 직전의 예제를 다음과 같이 조금 수정해 보자.

 예제를 브라우저로 실행시키고, 입력요소에 값을 입력하거나 포커스를 이동시켜보자. 그러면 각 행위에 따라 폼의 상태값의 변경을 확인할 수 있을 것이다. 이와같은 폼 상태 변화는 AngularJS가 폼 유효성을 검사하는 기반으로 활용된다.

* 폼 초기화
- 폼을 최초 로딩된 상태로 초기화 시키는 것은, 최초값을 보관해 두었다가 다시 그 값으로 회귀 시켜 주면 된다. 다만 데이터 초기화와 AngularJS의 폼 유효성 검사를 위한 상태값까지 모두 초기화 시켜 주는 것이 좋다. 앞서 살펴본바와 같이 AngularJS는 폼 및 입력요소에 대한 상태값을 지속적으로 관리하는데, 이부분까지 모두 초기화 시켜주면 완벽하다.

다음 코드는 폼 초기화를 위한 코드 샘플인데, 데이터 초기화의 경우 원본을 유지한채 복사본을 사용하는 것으로 처리하고 추가로 $setPristine(), $setUntouched() 함수를 호출하여, 폼 변경에 따른 내부 상태값의 변화 역시 같이 초기화 시켜준다.

* 폼 유효성 검사
- 지금까지 살펴본 것처럼, AngularJS는 폼의 입력요소들의 변경에 따른 상태값을 지속적으로 관리하며 이를 기반으로 폼의 유효성 검사를 지원한다. 폼의 유효성 검사 기준은 HTML5에 새로이 추가된 유효성 관련 특성(Attribute)에 근거하거나 개발자가 직접 자신만의 유효성 검사 기준을 만들 수 있도록 지원한다.

HTML5의 새로운 입력타입과 특성에 기반한 유효성 검사
- 가장 흔한 유효성 검사는 입력필드에 대한 필수입력 여부와 입력필드 타입에 따른 유효값 검사이다.
다음 코드는 HTML5의 required 특성을 부여한 필수 입력필드에 대한 입력여부와 email 타입의 입력필드에 대한 입력값 유효성 검사 샘플이다. 입력필드에 대한 $valid는 입력값 여부에 따라 true/false 값 중 하나를 반환한다.

AngularJS 디렉티브에 기반한 유효성 검사
- AngularJS가 미리 정의해 둔 디렉티브 기반으로 유효성 검사도 가능하다. 다음 코드는 필수입력 지정과 입력문자의 최소/최대 길이를 지정하여 유효성 검사를 수행한다.

입력폼 검사의 일반적 패턴
- 이번에는 좀 더 실용적인 코드 샘플을 보자. 하나의 필수 입력필드와 이메일 입력필드가 존재한다. 각 입력필드 바로 옆에는 유효성 실패에 대한 안내 메시지를 보여준다. ng-show 디렉티브는 주어진 조건값이 참/거짓에 따라 표시여부를 결정한다. 코드에서 주어진 조건은 입력필드에서 포서커를 잃고($touched) 유효성 검사에 실패한 경우($invalid)에 대한 And 조건으로 부여한다.
그리고 submit 버튼은 ng-disabled 디렉티비를 지정하는데 두 입력필드 중 하나라도 유효하지 않으면 비활성화 되도록 조건을 부여한다.

* ngMessages 모듈 이용하기
- ngMessages 서브모듈을 이용하여 유효성 검사에 따른 메시지 표시를 보다 체계적으로 관리할 수 있을 것이다. 이 모듈을 사용하려면 angular-messages.js 파일을 따로 참조해 줘야 한다.
ng-messages 디렉티브에 $error 객체를 바인딩해서 해당 입력요소가 유효한지 여부를 판단할 수 있게 한다. 그리고 ng-message 디렉티브에 검사하고자 하는 유효성 조건의 이름을 지정한다. 예에서는 총 3개(required, minlength, maxlength) 조건을 지정했다.
만일 해당 입력요소에 유효성 오류가 있고, 각 오류가 어떤 검사 기준인지에 따라 서로 다른 메시지를 보여주게 될 것이다.

* 사용자 정의 유효성 검사
- 지금까지는 입력요소의 필수입력여부, 타입 및 길이 등 HTML5의 새로운 특성이나 AngularJS가 내부적으로 지원하는 유효성 검사 기준을 사용하여 체크를 수행하였다.

그러나 실무환경에서는 보다 다양한 유효성 검사 조건이 존재할 수 있다. 예를 들어 입력필드에 들어가는 값은 반드시 숫자여야 하던지, 아님 어떤 정규식에 근거하여 유효성 검사를 수행하기도 한다.

이런 경우, 사용자 정의 유효성 검사기를 새로 만들면 된다. 사용자 정의 유효성 검사를 위해서는 커스텀 디렉티브를 생성하며 기존 디렉티브와의 차이점은 ngModel 모듈을 디렉티브에 추가해야 한다는 점이다.

다음 코드는 정규표현식에 기반한 사용자 정의 유효성 검사 디렉티브 구현을 보여준다. AngularJS 공식문서의 샘플코드이며, 커스텀 디렉티브의 link 함수를 통해 구현한다.

유효성 검사기의 이름은 integer으로 기존 필수입력 조건인 required와 마찬가지로 HTML의 특정 입력요소에 integer라는 이름으로 유효성 기준을 추가할 수 있다.

웹은 기본적으로 '동일출저정책(Same Origin Policy, SOP)' 정책을  따른다.

이는 보안을 위한 기본정책으로, SOP는 하나의 출처(Origin)에서 로드된 문서나 스크립트가 다른 출처에 존재하는 리소스와 상호작용하지 못하도록 제약을 두는 것이다.

그런데, 간혹 이런 제약이 웹 응용프로그램을 만드는데 걸림돌이 되기도 한다.
Ajax 통신이 활발해 지고, 다른 사이트에 존재하는 Open API와 상호통신이 필요한 경우와 매쉬업(Mash-up)으로 새로운 2차 응용물을 개발하게 되면서.. 등등.. 이는 간혹 걸림돌이 된다.

근래 Node.JS로 서버를 만들고, Aptana Studio 자체 내장 웹서버로 몇 가지 테스트를 하고 있는데, 두 환경은 서로 다른 별도의 포트(Port)에서 웹을 동작시키기 때문에 여지없이 Cross Domain 문제가 발생한다.

호출하는 모든 웹 리소스를, Node.JS로부터 다운로드 받아서 실행하는 구조로 HTTP 서버를 구현하면 SOP 정책을 따를 수 있겠으나, 그렇지 못한 개발환경도 있을 터이고, 실제 서비스 환경에서는 더욱이 서로 다른 도메인(포트 포함)간 상호작용이 필요할 것이다.

SOP 정책을 우회하기 위해서는, 서버 측의 설정이 필요한데, 위 그림에서 친철히 안내하고 있는 것처럼 Access-Control-Allow-Origin 헤더, 즉 크로스 도메인으로 허용할 도메인 목록이 헤더로 제공되어야 한다.
이것을 CORS(Cross-Origin Resource Sharing)를 이용한 SOP 정책 우회라 한다.

Node.JS 환경에서 이 설정을 해보자.
다음과 같이, Node 기반 HTTP 서버의 응답헤더에 추가 해준다.

가장 중요한 설정은, Access-Control-Allow-Origin으로 허용할 도메인(포트)을 추가한다.
여러 도메인이 있을 경우, 중복해서 지정을 하거나 '*' 를 이용해 전체 허용도 가능하다.

참고로 127.0.0.1:8020 도메인은, 필자의 Aptana Studio가 생성한 임의 주소이다.

이렇게 설정한 후, 클라이언트에서 요청하면 요청이 성공적으로 이뤄진다.

그리고 언제나 그렇듯이 확장 라이브러리도 있다.
cors라는 이름의 Node.JS 확장인데, npm을 통해 설치하고 간단히 다음처럼 사용할 수 있다. 훨씬 간편하다.

그래도 언제나 보안은 중요한 문제이니, SOP 정책에 존중하면서, 필요시 아주 제한적으로 적용하는 것을 권장함.