2011.10.17

기고 | 클라우드 코드를 평가하는 방법 – 1부

David Taber | CIO

많은 클라우드 애플리케이션들이 디클래러티브 프로그래밍(Declarative Programming)에 집중하지만 우리는 이것을 받아들여야만 한다. - 코드는 생기게 마련이다. 우리는 클라우드에서 구동하는 코드를 어떻게 평가해야 할까?

클라우드 기반의 애플리케이션은 사용자들의 창의적인 충동을 벤더들이 "디클래러티브 프로그래밍(Declarative Programming)"이라 부르는 마우스로 이용 가능한 동작 사양, 플러스 환경설정(Plus Configuration), 세팅, 규칙, 공식 등에 집중되도록 하는 경향이 있다. 이런 것들은 멀티테넌트(Multi-tenant) 작업부하, 시험 가능성 등을 포함하여 사용의 편의성을 위해서 유용한 것들이다.

하지만 클라우드 앱의 사용자가 수가 많거나 고급 사용예가 많을 경우 디클래러티브 프로그래밍은 도리어 도움이 되지 않는다. 제작자는 머지 않아 표현 계층(외양)과 비즈니스 로직(Business Logic - 콘트롤러)을 코딩하고 있을 것이다. 일부 클라우드 환경에서는 직접적으로 메타데이터(Metadata)와 트랜잭션 레이어(Transaction Layer - 모델)를 통해 작업하게 될 수도 있다.

물론 클라우드 기반의 개발 또는 배치 환경을 사용하고 있다면 이 모든 MVC 계층에 대해 바로 작업을 시작할 수 있다. IT 전문가들에게 있어서는 전혀 새로울 것이 없다.

하지만 클라우드 개발의 세계는 아직 초기 단계에 머무르고 있기 때문에 여러 가지 새로운 문제들이 발생하기 마련이다. 사례:

•중심이 없다: 사용자들이 뿔뿔이 흩어져 있을 뿐 아니라 개발자의 위치도 분명치 않으며 서비스도 여러 지역에서 제공될 수 있다. 제작자가 자신이 선호하는 버전관리 시스템(Version Control System)과 위키(Wiki)를 이용해 개발하지 않는 한 애플리케이션 모델, 코드, 테스트 데이터베이스, 애플리케이션 아티팩트(Application Artifact) 등을 위한 중앙 저장소(Central Repository)가 부재하게 된다. 따라서 별개의 작업이 요구된다.

•일반적으로 한번에 여러 개의 언어로 작업하게 된다: 심지어 하나의 애플리케이션 내에서 작업할 때도 다수의 언어 참조를 사용하게 된다. 예를 들어 작성한 코드가 자바 라이브러리, 내부 애플리케이션 기능, 스크립트 등을 호출할 수 있다. UI는 j쿼리(jquery), 자바스크립트, 자바스크립트 프레임워크, 네이티브 파일 시스템 유틸리티(Native File-System Utility), AJAX, 플렉스(Flex), 기타 언어 등을 호출할 수 있다. 이것은 매우 강력하고 효율적이지만 문제 해결과 디버그(Debug)가 난해한 코드가 생성되는 결과를 초래할 수 있다. 따라서 사용되는 언어의 수를 5개 이하로 유지할 필요가 있다. 반드시 이를 명심하기 바란다.

•상이한 개발자 툴들이 코드 구조에 영향을 끼칠 수 있다: 이것은 분석과 설계부터 테스트 및 배치에 이르는 전 과정에 적용된다. 일부 툴들은 다른 툴들에 비해서 훨씬 정교하고 확장성을 갖춘 코딩 구조를 허용한다. 일부 뛰어난 기능성을 제공하는 툴들은 윈도우용으로만 제공되기 때문에 맥이나 리눅스 기반의 개발자들은 개발 및 배치 시간에 있어서 상이한 경험을 하게 된다. 디버깅(Debugging)에 있어서는 그 영향이 배가 된다. 이는 UI에 있어서도 마찬가지다.


클라우드 코드 평가요소
클라우드 코드가 작동하고 사용자의 요구를 충족시킨다고 가정할 때 무엇으로 코드를 평가해야 할까? 여기서 기본적인 사항들을 살펴 보기로 하자:

•성능: 클라우드 애플리케이션에서 일반적으로 성능은 ‘화면 리프레시 시간(Screen Refresh Time)’으로 측정된다. 사용자들은 이것을 ‘완료 시간(Time to Complete)’으로 인지하게 된다. 3GHz의 쿼드코어와 16GB의 램이 장착된 장비가 아닌 일반적인 사용자의 장비(3년 된 노트북 정도)에서 이를 평가해보기 바란다. 일반적으로 인지되는 성능은 2개의 요소에 의해 좌우된다: 클라우드의 서버가 요청과 스크린 페인트 시간(Screen Paint Time)에 응답하기 전의 시간의 길이. 클라우드 코드를 평가할 때 찾아내야 할 3가지 문제점: 유치한 쿼리, 과도한 네트워크 점유(특히 복수의 웹 서비스를 호출해야 할 때), 지나치게 부풀려진 페이지 길이 또는 보기 상태

배치가능성: 개별적인 모듈에 대한 버그 수정은 수 초 이내에 적용할 수 있지만 설치 전에 총체적인 테스트 싸이클(Text Cycle)을 마련하는 것이 더 중요하다. (세일즈포스닷컴의 경우 생성 시스템에 대한 테스트도 요구한다.) 대형 애플리케이션들의 경우 배치에 메타데이터, 환경설정 테이블, 아티팩트, 해당 코드와 관련된 테스트 데이터의 수정이 포함될 수도 있다. 물론 배치는 CVS 시스템과 스크립트를 이용한 배치 엔진을 통해 자동화될 수 있다. 그리고 테스트 순서 또한 자동화될 수 있다. 진짜 문제는 자동화가 실제적으로 가능한지 여부와 테스트 싸이클이 적당한 시간에 완료되느냐다. 최근 우리가 작업한 시스템에서 의무적인 테스트 싸이클을 구동하는데 몇 시간이 소요됐다. 이 때문에 애플리케이션 운영에 문제가 발생했다. 따라서 우리는 이런 측면에서 IT업체들을 평가하는 것을 강력히 추천한다.

•문서화의 깊이 및 너비: 일반적으로 클라우드 앱은 전통적인 앱보다 더 많은 문서화를 필요로 하며 전과는 다른 방식으로 문서화돼야 한다. 우리는 아직 배우는 단계에 있기 때문에 이를 기반으로 반드시 구매한 앱과 완성자의 코드를 평가해보기 바란다.

최종 관문: 유지보수
"이 모든 것은 당신이 처한 상황과 달성하고자 하는 목표에 달려있다." 예를 들어 단순하게 상용 클라우드 애플리케이션을 사용하고 있다면 스스로 유지보수에 신경 쓸 필요가 없을 것이다. 따라서 ‘유지보수’는 ‘SLA’로 해석할 수 있다. (만약 오픈소스 클라우드 애플리케이션을 사용 중이라면 이것은 "이 코드 기반을 아는 컨설턴트를 찾기 쉬운가?"로 해석할 수 있다.)

하지만 자체적인 클라우드 애플리케이션을 개발하고 있거나 페이지, 트리거(Trigger), 클래스(Class) 등을 이용해 기존의 것을 확장하고 있다면 분석, 확장, 문제 해결의 용이성을 위해 해당 코드를 평가해야 한다. 가능한 한 포괄적이면서 확장 가능한 코드를 확보하는 것이 최선이라는 생각이 가장 일반적인 오해다.

확장성과 난해한 코드의 방지도 중요하지만 이를 너무 강조할 경우 도리어 코드가 난해해지는 결과를 초래할 수도 있다. 반드시 직원들이 스스로 코드를 개발할 수 있도록 장려하여 코드의 ‘이해가능성 지수’를 평가하기 바란다. 만약 코딩 기술이 너무 추상적이어서 불분명하다면 평생을 코드를 생성한 완성자에게 의존할 수 밖에 없을 것이다.

다음에는 애플리케이션이 점점 복잡해질 때 개발자가 문제를 예방하고 시간을 절약할 수 있는데 도움이 되는 코드 손상을 예방하는 15가지 방법에 대해서 알아보도록 하겠다.

*David Taber는 ‘세일즈포스닷컴 성공의 비밀’의 저자이며 세일즈포스닷컴 관련 컨설팅 기업인 세일즈로지스틱스의 CEO다.  ciokr@idg.co.kr




2011.10.17

기고 | 클라우드 코드를 평가하는 방법 – 1부

David Taber | CIO

많은 클라우드 애플리케이션들이 디클래러티브 프로그래밍(Declarative Programming)에 집중하지만 우리는 이것을 받아들여야만 한다. - 코드는 생기게 마련이다. 우리는 클라우드에서 구동하는 코드를 어떻게 평가해야 할까?

클라우드 기반의 애플리케이션은 사용자들의 창의적인 충동을 벤더들이 "디클래러티브 프로그래밍(Declarative Programming)"이라 부르는 마우스로 이용 가능한 동작 사양, 플러스 환경설정(Plus Configuration), 세팅, 규칙, 공식 등에 집중되도록 하는 경향이 있다. 이런 것들은 멀티테넌트(Multi-tenant) 작업부하, 시험 가능성 등을 포함하여 사용의 편의성을 위해서 유용한 것들이다.

하지만 클라우드 앱의 사용자가 수가 많거나 고급 사용예가 많을 경우 디클래러티브 프로그래밍은 도리어 도움이 되지 않는다. 제작자는 머지 않아 표현 계층(외양)과 비즈니스 로직(Business Logic - 콘트롤러)을 코딩하고 있을 것이다. 일부 클라우드 환경에서는 직접적으로 메타데이터(Metadata)와 트랜잭션 레이어(Transaction Layer - 모델)를 통해 작업하게 될 수도 있다.

물론 클라우드 기반의 개발 또는 배치 환경을 사용하고 있다면 이 모든 MVC 계층에 대해 바로 작업을 시작할 수 있다. IT 전문가들에게 있어서는 전혀 새로울 것이 없다.

하지만 클라우드 개발의 세계는 아직 초기 단계에 머무르고 있기 때문에 여러 가지 새로운 문제들이 발생하기 마련이다. 사례:

•중심이 없다: 사용자들이 뿔뿔이 흩어져 있을 뿐 아니라 개발자의 위치도 분명치 않으며 서비스도 여러 지역에서 제공될 수 있다. 제작자가 자신이 선호하는 버전관리 시스템(Version Control System)과 위키(Wiki)를 이용해 개발하지 않는 한 애플리케이션 모델, 코드, 테스트 데이터베이스, 애플리케이션 아티팩트(Application Artifact) 등을 위한 중앙 저장소(Central Repository)가 부재하게 된다. 따라서 별개의 작업이 요구된다.

•일반적으로 한번에 여러 개의 언어로 작업하게 된다: 심지어 하나의 애플리케이션 내에서 작업할 때도 다수의 언어 참조를 사용하게 된다. 예를 들어 작성한 코드가 자바 라이브러리, 내부 애플리케이션 기능, 스크립트 등을 호출할 수 있다. UI는 j쿼리(jquery), 자바스크립트, 자바스크립트 프레임워크, 네이티브 파일 시스템 유틸리티(Native File-System Utility), AJAX, 플렉스(Flex), 기타 언어 등을 호출할 수 있다. 이것은 매우 강력하고 효율적이지만 문제 해결과 디버그(Debug)가 난해한 코드가 생성되는 결과를 초래할 수 있다. 따라서 사용되는 언어의 수를 5개 이하로 유지할 필요가 있다. 반드시 이를 명심하기 바란다.

•상이한 개발자 툴들이 코드 구조에 영향을 끼칠 수 있다: 이것은 분석과 설계부터 테스트 및 배치에 이르는 전 과정에 적용된다. 일부 툴들은 다른 툴들에 비해서 훨씬 정교하고 확장성을 갖춘 코딩 구조를 허용한다. 일부 뛰어난 기능성을 제공하는 툴들은 윈도우용으로만 제공되기 때문에 맥이나 리눅스 기반의 개발자들은 개발 및 배치 시간에 있어서 상이한 경험을 하게 된다. 디버깅(Debugging)에 있어서는 그 영향이 배가 된다. 이는 UI에 있어서도 마찬가지다.


클라우드 코드 평가요소
클라우드 코드가 작동하고 사용자의 요구를 충족시킨다고 가정할 때 무엇으로 코드를 평가해야 할까? 여기서 기본적인 사항들을 살펴 보기로 하자:

•성능: 클라우드 애플리케이션에서 일반적으로 성능은 ‘화면 리프레시 시간(Screen Refresh Time)’으로 측정된다. 사용자들은 이것을 ‘완료 시간(Time to Complete)’으로 인지하게 된다. 3GHz의 쿼드코어와 16GB의 램이 장착된 장비가 아닌 일반적인 사용자의 장비(3년 된 노트북 정도)에서 이를 평가해보기 바란다. 일반적으로 인지되는 성능은 2개의 요소에 의해 좌우된다: 클라우드의 서버가 요청과 스크린 페인트 시간(Screen Paint Time)에 응답하기 전의 시간의 길이. 클라우드 코드를 평가할 때 찾아내야 할 3가지 문제점: 유치한 쿼리, 과도한 네트워크 점유(특히 복수의 웹 서비스를 호출해야 할 때), 지나치게 부풀려진 페이지 길이 또는 보기 상태

배치가능성: 개별적인 모듈에 대한 버그 수정은 수 초 이내에 적용할 수 있지만 설치 전에 총체적인 테스트 싸이클(Text Cycle)을 마련하는 것이 더 중요하다. (세일즈포스닷컴의 경우 생성 시스템에 대한 테스트도 요구한다.) 대형 애플리케이션들의 경우 배치에 메타데이터, 환경설정 테이블, 아티팩트, 해당 코드와 관련된 테스트 데이터의 수정이 포함될 수도 있다. 물론 배치는 CVS 시스템과 스크립트를 이용한 배치 엔진을 통해 자동화될 수 있다. 그리고 테스트 순서 또한 자동화될 수 있다. 진짜 문제는 자동화가 실제적으로 가능한지 여부와 테스트 싸이클이 적당한 시간에 완료되느냐다. 최근 우리가 작업한 시스템에서 의무적인 테스트 싸이클을 구동하는데 몇 시간이 소요됐다. 이 때문에 애플리케이션 운영에 문제가 발생했다. 따라서 우리는 이런 측면에서 IT업체들을 평가하는 것을 강력히 추천한다.

•문서화의 깊이 및 너비: 일반적으로 클라우드 앱은 전통적인 앱보다 더 많은 문서화를 필요로 하며 전과는 다른 방식으로 문서화돼야 한다. 우리는 아직 배우는 단계에 있기 때문에 이를 기반으로 반드시 구매한 앱과 완성자의 코드를 평가해보기 바란다.

최종 관문: 유지보수
"이 모든 것은 당신이 처한 상황과 달성하고자 하는 목표에 달려있다." 예를 들어 단순하게 상용 클라우드 애플리케이션을 사용하고 있다면 스스로 유지보수에 신경 쓸 필요가 없을 것이다. 따라서 ‘유지보수’는 ‘SLA’로 해석할 수 있다. (만약 오픈소스 클라우드 애플리케이션을 사용 중이라면 이것은 "이 코드 기반을 아는 컨설턴트를 찾기 쉬운가?"로 해석할 수 있다.)

하지만 자체적인 클라우드 애플리케이션을 개발하고 있거나 페이지, 트리거(Trigger), 클래스(Class) 등을 이용해 기존의 것을 확장하고 있다면 분석, 확장, 문제 해결의 용이성을 위해 해당 코드를 평가해야 한다. 가능한 한 포괄적이면서 확장 가능한 코드를 확보하는 것이 최선이라는 생각이 가장 일반적인 오해다.

확장성과 난해한 코드의 방지도 중요하지만 이를 너무 강조할 경우 도리어 코드가 난해해지는 결과를 초래할 수도 있다. 반드시 직원들이 스스로 코드를 개발할 수 있도록 장려하여 코드의 ‘이해가능성 지수’를 평가하기 바란다. 만약 코딩 기술이 너무 추상적이어서 불분명하다면 평생을 코드를 생성한 완성자에게 의존할 수 밖에 없을 것이다.

다음에는 애플리케이션이 점점 복잡해질 때 개발자가 문제를 예방하고 시간을 절약할 수 있는데 도움이 되는 코드 손상을 예방하는 15가지 방법에 대해서 알아보도록 하겠다.

*David Taber는 ‘세일즈포스닷컴 성공의 비밀’의 저자이며 세일즈포스닷컴 관련 컨설팅 기업인 세일즈로지스틱스의 CEO다.  ciokr@idg.co.kr


X