Offcanvas

���������

칼럼 | 클라우드 전략, CIO 아닌 개발자가 주도한다

멀티클라우드도 좋고 하이브리드 클라우드도 좋다. 하지만 록인을 막거나 고가용성을 제공할 원대한 계획이 있어서가 아니다. 대부분 기업에 멀티클라우드와 하이브리드 클라우드 환경은 선택사항이 아니다. 기업이 진화하면서 자연히 일어는 일이다. 451 리서치는 2019년까지 조직의 69%가 멀티클라우드 환경을 운영할 것으로 전망하지만, 실제로는 이미 100%의 조직이 멀티클라우드이다. 클라우드를 구축한 어떤 기업이라도 이미 하나 이상의 클라우드를 운영하고 있기 때문이다. 이유는 바로 개발자 때문이다. 개발자의 은총을 입은 멀티클라우드 물론 CIO라면 하이브리드 클라우드나 멀티클라우드와 관련한 명확한 전략을 주장하고 싶을 것이다. 하지만 이런 일은 C급 임원이 명령하고 통제할 수 없는 세상에서 그냥 일어난다. 물론 클라우드 도입이 전혀 통제를 받지 않는다는 말은 아니다. 과거처럼 엄격하게 통제되지 않는다는 의미다. 예를 들어, 리시닷(Rishidot)의 애널리스트 크리시넌 서브라마니안이 강조했듯이 “고가용성 사용례로서 멀티클라우드는 무의미하다. 하지만 섀도우 IT를 방지하는 방법으로 멀티클라우드는 개발자에게 원하는 클라우드 서비스를 제공하기 때문에 기업을 위한 결정적인 전략이 된다.” 서브라마니안은 “더 나아가 대부분 기업이 멀티클라우드 전략을 갖게 될 것”이라고 덧붙였다. 무슨 의미인가? 개발자가 자신의 작업을 더 쉽게 만들어주는 서비스를 이용하는 것을 기업이 막을 수는 없지만, 이들 서비스의 다수를 프라이빗 클라우드에서 제공하도록 진화할 수는 있다. 기업의 기본값으로 제공하지 않는 서비스를 보유한 퍼블릭 클라우드에 대한 공식 지원 추가는 말할 것도 없다. 예를 들어, 필자의 회사 어도비 시스템에서 우리는 어도비 I/O 런타임(Adobe I/O Runtime)을 구축해 개발자가 자신의 코드를 어도비 클라우드 플랫폼에서 실행하고 이를 자신의 필요에 맞게 확장할 수 있도록 했다. 서드파티 개발자...

CIO 콘텐츠 문서화 멀티클라우드

2018.10.02

멀티클라우드도 좋고 하이브리드 클라우드도 좋다. 하지만 록인을 막거나 고가용성을 제공할 원대한 계획이 있어서가 아니다. 대부분 기업에 멀티클라우드와 하이브리드 클라우드 환경은 선택사항이 아니다. 기업이 진화하면서 자연히 일어는 일이다. 451 리서치는 2019년까지 조직의 69%가 멀티클라우드 환경을 운영할 것으로 전망하지만, 실제로는 이미 100%의 조직이 멀티클라우드이다. 클라우드를 구축한 어떤 기업이라도 이미 하나 이상의 클라우드를 운영하고 있기 때문이다. 이유는 바로 개발자 때문이다. 개발자의 은총을 입은 멀티클라우드 물론 CIO라면 하이브리드 클라우드나 멀티클라우드와 관련한 명확한 전략을 주장하고 싶을 것이다. 하지만 이런 일은 C급 임원이 명령하고 통제할 수 없는 세상에서 그냥 일어난다. 물론 클라우드 도입이 전혀 통제를 받지 않는다는 말은 아니다. 과거처럼 엄격하게 통제되지 않는다는 의미다. 예를 들어, 리시닷(Rishidot)의 애널리스트 크리시넌 서브라마니안이 강조했듯이 “고가용성 사용례로서 멀티클라우드는 무의미하다. 하지만 섀도우 IT를 방지하는 방법으로 멀티클라우드는 개발자에게 원하는 클라우드 서비스를 제공하기 때문에 기업을 위한 결정적인 전략이 된다.” 서브라마니안은 “더 나아가 대부분 기업이 멀티클라우드 전략을 갖게 될 것”이라고 덧붙였다. 무슨 의미인가? 개발자가 자신의 작업을 더 쉽게 만들어주는 서비스를 이용하는 것을 기업이 막을 수는 없지만, 이들 서비스의 다수를 프라이빗 클라우드에서 제공하도록 진화할 수는 있다. 기업의 기본값으로 제공하지 않는 서비스를 보유한 퍼블릭 클라우드에 대한 공식 지원 추가는 말할 것도 없다. 예를 들어, 필자의 회사 어도비 시스템에서 우리는 어도비 I/O 런타임(Adobe I/O Runtime)을 구축해 개발자가 자신의 코드를 어도비 클라우드 플랫폼에서 실행하고 이를 자신의 필요에 맞게 확장할 수 있도록 했다. 서드파티 개발자...

2018.10.02

좋은 코드를 작성하고 있다는 징후 11가지

빌 소러는 윤리적 관점에서 스스로 부끄러움을 느낀 코드에 대한 좋은 글을 미디엄(Medium)에 올린 적이 있다. 그러나 기술적인 측면에서도 소프트웨어를 부끄러워해야 이유는 많다. 부끄러워하지 않을 소프트웨어를 나타내는 11가지 단어를 살펴보자. 사용하는 언어 또는 기술 스택이 무엇이든 코드를 다음 단어로 설명할 수 있다면 좋은 코드일 가능성이 높다. 자신의 코드에 몇 개나 적용되는지 확인해 보라. 1. 디버그 가능(Debuggable) 대부분의 현대 런타임에서는 일종의 디버거를 연결할 수 있다. Node.js조차 비주얼 스튜디오로 디버그할 수 있다. 언젠가 무슨 일이 벌어지는지 알아내야 할 때 디버거를 연결해야 한다는 생각을 갖고 코드를 써야 한다. 그 의미를 정확히 설명하기는 어렵지만 이렇게 하면 때로는 데이터의 구조를 설계하는 데 영향을 미치기도 한다. 구조를 파나갈 필요가 없도록 더 많은 임시 변수를 사용할 수도 있다. 다행히 대부분은 결과적으로 좋은 습관이다. 가장 좋은 시작 방법은 문제가 없을 때 디버거 사용을 연습하는 것이다. 단계별로 진행하면서 할당을 살펴보고, 잘못된 값이 있을 경우 어떻게 할지 생각해 보라. 2. 로그 가능(Loggable) 런타임에 연결해서 코드를 단계별로 진행하기 위한 현대적 디버거가 있다 해도 세상은 그렇게 돌아가지 않는다. 즉, 코드가 실행되는 환경은 다양하다. 서버리스일 수도 있고 멀티스레드 환경이거나 분산 환경 또는 어딘가의 클라우드에서 실행되는 경우도 있을 것이다. 이러한 환경에서 코드는 개발자가 컴퓨터에서 실행할 때와 다르게 동작할지도 모른다. 따라서 로그가 필요하다. 그 말은 로깅 프레임워크가 필요하다는 의미다. 코드를 쓰고 로그를 읽을 수 있도록, 또는 최소한 일종의 로그 리더에서 소화가 가능하도록 로깅을 설정해야 한다. 소프트웨어에 로그 기능을 넣어야 한다. 이 부분을 못할 경우 프로덕션 배포에서 프로덕션 문제를 디버그하기 위해 로깅 코드를 배포하는 상...

코드 문서화 디버깅 로그 프로그래머블 네트워크 멱등적

2018.04.17

빌 소러는 윤리적 관점에서 스스로 부끄러움을 느낀 코드에 대한 좋은 글을 미디엄(Medium)에 올린 적이 있다. 그러나 기술적인 측면에서도 소프트웨어를 부끄러워해야 이유는 많다. 부끄러워하지 않을 소프트웨어를 나타내는 11가지 단어를 살펴보자. 사용하는 언어 또는 기술 스택이 무엇이든 코드를 다음 단어로 설명할 수 있다면 좋은 코드일 가능성이 높다. 자신의 코드에 몇 개나 적용되는지 확인해 보라. 1. 디버그 가능(Debuggable) 대부분의 현대 런타임에서는 일종의 디버거를 연결할 수 있다. Node.js조차 비주얼 스튜디오로 디버그할 수 있다. 언젠가 무슨 일이 벌어지는지 알아내야 할 때 디버거를 연결해야 한다는 생각을 갖고 코드를 써야 한다. 그 의미를 정확히 설명하기는 어렵지만 이렇게 하면 때로는 데이터의 구조를 설계하는 데 영향을 미치기도 한다. 구조를 파나갈 필요가 없도록 더 많은 임시 변수를 사용할 수도 있다. 다행히 대부분은 결과적으로 좋은 습관이다. 가장 좋은 시작 방법은 문제가 없을 때 디버거 사용을 연습하는 것이다. 단계별로 진행하면서 할당을 살펴보고, 잘못된 값이 있을 경우 어떻게 할지 생각해 보라. 2. 로그 가능(Loggable) 런타임에 연결해서 코드를 단계별로 진행하기 위한 현대적 디버거가 있다 해도 세상은 그렇게 돌아가지 않는다. 즉, 코드가 실행되는 환경은 다양하다. 서버리스일 수도 있고 멀티스레드 환경이거나 분산 환경 또는 어딘가의 클라우드에서 실행되는 경우도 있을 것이다. 이러한 환경에서 코드는 개발자가 컴퓨터에서 실행할 때와 다르게 동작할지도 모른다. 따라서 로그가 필요하다. 그 말은 로깅 프레임워크가 필요하다는 의미다. 코드를 쓰고 로그를 읽을 수 있도록, 또는 최소한 일종의 로그 리더에서 소화가 가능하도록 로깅을 설정해야 한다. 소프트웨어에 로그 기능을 넣어야 한다. 이 부분을 못할 경우 프로덕션 배포에서 프로덕션 문제를 디버그하기 위해 로깅 코드를 배포하는 상...

2018.04.17

재해복구계획 수립은 이렇게··· 9가지 방법

재해복구계획(DRP)을 수립해 IT인프라와 애플리케이션이 중단되더라도 복구할 수 있도록 해야 한다. 재해가 비즈니스 운영에 필수적인 IT시스템을 공격하면 CIO는 신속하게 확실하게 복구하는 데 중요한 역할을 맡게 된다. 필요한 절차를 문서로 만들어 정전 후 데이터, 시스템 기능, IT인프라를 어떻게 복구할지 정리해 놓은 DRP에 나와 있는 대로 잘 수행하면 작업을 정상적으로 복구할 수 있을 것이다. DRP는 IT 재난을 예방, 탐지, 수정하는 방법을 설명한 것으로, 여기에는 모든 서비스 중단의 영향을 최소화하고 중요한 애플리케이션을 복원하는 데 필요한 조치를 문서로 만들고 다른 직원의 책임에 대한 설명이 포함돼 있다. 성공적인 DRP를 수립하는 방법을 알아보자. 1. 내부 시스템 감사 조직의 모든 활동과 자원을 평가해 IT시스템과 애플리케이션의 기능을 완전히 이해해야 한다. 모든 중요한 기능, 시스템, 애플리케이션을 파악하고 각각이 멈췄을 때 비즈니스에 미치는 영향을 설명하는 비즈니스 영향 분석(BIA)을 개발하라. 모든 문제가 다뤄지도록 조직의 모든 부서에 대한 의견을 구하라. 2. 외부 공급 업체 확인 조직에서 사용하는 데이터나 애플리케이션을 호스팅하는 써드파티 업체와 서비스 수준 협약(SLA)을 검토해 해당 서비스와 관련한 모든 문제의 영향을 이해하라. 각 공급 업체와 잠재적인 문제의 위험을 평가하고 운영에 중요한 공급 업체 손실에 대비한 비상 계획과 전략을 수립하라. 3. 취약점 이해 잠재적 취약성 영역과 운영 절차에서 전력에 이르기까지 조직에 피해를 줄 방법을 문서로 작성하라. 다른 유형의 피해는 없는지도 확인하라. 인간의 실수, 자연재해, 정전, 사이버 공격, 소프트웨어 문제, 하드웨어 고장은 혼란을 야기할 수 있다. 이러한 각각의 발생 위험, 그들이 가질 수 있는 영향 및 복구해야 할 것이 무엇인지 문서로 만들어야 한다.  위험 요소로는 가동 중지 시간, 고객 손실, 생산성 ...

SLA 재해복구계획 비즈니스 영향 분석 BIA IT인프라 문서화 복구 중단 공격 DR 재해복구 CIO DPR

2018.01.04

재해복구계획(DRP)을 수립해 IT인프라와 애플리케이션이 중단되더라도 복구할 수 있도록 해야 한다. 재해가 비즈니스 운영에 필수적인 IT시스템을 공격하면 CIO는 신속하게 확실하게 복구하는 데 중요한 역할을 맡게 된다. 필요한 절차를 문서로 만들어 정전 후 데이터, 시스템 기능, IT인프라를 어떻게 복구할지 정리해 놓은 DRP에 나와 있는 대로 잘 수행하면 작업을 정상적으로 복구할 수 있을 것이다. DRP는 IT 재난을 예방, 탐지, 수정하는 방법을 설명한 것으로, 여기에는 모든 서비스 중단의 영향을 최소화하고 중요한 애플리케이션을 복원하는 데 필요한 조치를 문서로 만들고 다른 직원의 책임에 대한 설명이 포함돼 있다. 성공적인 DRP를 수립하는 방법을 알아보자. 1. 내부 시스템 감사 조직의 모든 활동과 자원을 평가해 IT시스템과 애플리케이션의 기능을 완전히 이해해야 한다. 모든 중요한 기능, 시스템, 애플리케이션을 파악하고 각각이 멈췄을 때 비즈니스에 미치는 영향을 설명하는 비즈니스 영향 분석(BIA)을 개발하라. 모든 문제가 다뤄지도록 조직의 모든 부서에 대한 의견을 구하라. 2. 외부 공급 업체 확인 조직에서 사용하는 데이터나 애플리케이션을 호스팅하는 써드파티 업체와 서비스 수준 협약(SLA)을 검토해 해당 서비스와 관련한 모든 문제의 영향을 이해하라. 각 공급 업체와 잠재적인 문제의 위험을 평가하고 운영에 중요한 공급 업체 손실에 대비한 비상 계획과 전략을 수립하라. 3. 취약점 이해 잠재적 취약성 영역과 운영 절차에서 전력에 이르기까지 조직에 피해를 줄 방법을 문서로 작성하라. 다른 유형의 피해는 없는지도 확인하라. 인간의 실수, 자연재해, 정전, 사이버 공격, 소프트웨어 문제, 하드웨어 고장은 혼란을 야기할 수 있다. 이러한 각각의 발생 위험, 그들이 가질 수 있는 영향 및 복구해야 할 것이 무엇인지 문서로 만들어야 한다.  위험 요소로는 가동 중지 시간, 고객 손실, 생산성 ...

2018.01.04

프로젝트 범위를 결정, 문서화, 논의하는 방법

프로젝트 범위를 설정하는 것에 있어 일반적으로 중요한 요소가 있다. 그러나 이해당사자간 갈등과 과업 변경을 최소화하려면 추가로 몇가지를 더 고려해야 한다. 먼저 범위 관리 계획을 세우는 단계에서 프로젝트 범위를 정의하고 검증하고 관리하는 방법을 명확히 하는 것이다. 이후에는 이해당사자의 요구와 기대치를 확실히 파악해야 한다. 특히 이 과정에서 가용 리소스와 한계, 강점, 절차, 기술과 툴, 문화 등을 충분히 고려해야 한다. 이 단계에서 충분한 시간을 할애하지 않으면 훗날 재앙이 돼 돌아올 수 있다. 웹과 네이티브 앱을 개발하는 실버로직(Silverlogic)의 COO 크리스티나 에스칼란테는 자신이 프로젝트 범위를 결정할 때 고려했던 몇가지를 공유했다. 그는 “우리 고객 대부분은 중소기업과 스타트업, 대기업이다. 처음부터 MVP(minimal viable product)를 만들려 하고 예산의 제약도 있다. 따라서 ‘여기까지(Stop)’이라고 외칠 때를 아는 것이 가장 중요하다. 우리는 해결하려는 문제가 무엇인지 결정하기 위해 이해당사자와 충분히 논의한다. MVP의 핵심 기능과 부차 기능에 대해 사용자 스토리(user story, 사용자의 요구사항)를 쓴다. 종이에 와이어프레임(wireframes)을 그리고 이를 스케치(Sketch) 또는 와이어프레임스케처(WireframeSketcher) 같은 소프트웨어로 구현한다”라고 말했다. 사용자 경험과 인터랙티브 전략 컨설팅 업체 가로팔로 스튜디오(Garofalo Studios)는 프로젝트 범위를 결정할 때 애자일/스크럼(agile/scrum) 방법론을 사용한다. 이 업체의 선임 컨설턴트 프랭크 가로팔로는 “이를 이용하면 비즈니스 요구의 변화에 빠르게 대응하는 유연성을 확보하면서 동시에 핵심 목표를 정의할 수 있다”라고 말했다. 실제로 점점 더 많은 기업이 자사 프로젝트에 애자일 같은 별도의 방법론을 사용하고 있다. 또한, 다양한...

프로젝트 CIO 문서화

2017.11.27

프로젝트 범위를 설정하는 것에 있어 일반적으로 중요한 요소가 있다. 그러나 이해당사자간 갈등과 과업 변경을 최소화하려면 추가로 몇가지를 더 고려해야 한다. 먼저 범위 관리 계획을 세우는 단계에서 프로젝트 범위를 정의하고 검증하고 관리하는 방법을 명확히 하는 것이다. 이후에는 이해당사자의 요구와 기대치를 확실히 파악해야 한다. 특히 이 과정에서 가용 리소스와 한계, 강점, 절차, 기술과 툴, 문화 등을 충분히 고려해야 한다. 이 단계에서 충분한 시간을 할애하지 않으면 훗날 재앙이 돼 돌아올 수 있다. 웹과 네이티브 앱을 개발하는 실버로직(Silverlogic)의 COO 크리스티나 에스칼란테는 자신이 프로젝트 범위를 결정할 때 고려했던 몇가지를 공유했다. 그는 “우리 고객 대부분은 중소기업과 스타트업, 대기업이다. 처음부터 MVP(minimal viable product)를 만들려 하고 예산의 제약도 있다. 따라서 ‘여기까지(Stop)’이라고 외칠 때를 아는 것이 가장 중요하다. 우리는 해결하려는 문제가 무엇인지 결정하기 위해 이해당사자와 충분히 논의한다. MVP의 핵심 기능과 부차 기능에 대해 사용자 스토리(user story, 사용자의 요구사항)를 쓴다. 종이에 와이어프레임(wireframes)을 그리고 이를 스케치(Sketch) 또는 와이어프레임스케처(WireframeSketcher) 같은 소프트웨어로 구현한다”라고 말했다. 사용자 경험과 인터랙티브 전략 컨설팅 업체 가로팔로 스튜디오(Garofalo Studios)는 프로젝트 범위를 결정할 때 애자일/스크럼(agile/scrum) 방법론을 사용한다. 이 업체의 선임 컨설턴트 프랭크 가로팔로는 “이를 이용하면 비즈니스 요구의 변화에 빠르게 대응하는 유연성을 확보하면서 동시에 핵심 목표를 정의할 수 있다”라고 말했다. 실제로 점점 더 많은 기업이 자사 프로젝트에 애자일 같은 별도의 방법론을 사용하고 있다. 또한, 다양한...

2017.11.27

개발자 불평 2.5만건 분석해보니...

사내 소프트웨어 개발자들이 요즘 짜증나 있는가? 만약 당신이 프로젝트 관리자나 개발자들의 상사, 채용담당자 혹은 QA 전문가라면 아마 그 원인은 바로 당신일 수 있다. 이는 소프트웨어 개발자들 사이의 화합, 지식 공유, 네트워킹을 장려하기 위해 구축된 온라인 커뮤니티 데브란트(devRant)의 새로운 데이터에 의한 것이다. 소프트웨어 개발자 출신인 데이비드 폭스와 팀 로거스가 2016년 3월 공동창업한 데브란트 커뮤니티에는 지금까지 약 1만 5,000명의 소프트웨어 개발자들이 2만 5,000개가 넘는 ‘불평’을 포스팅 했다. | 그들의 직업적 문제와 과제를 더 잘 이해하기 위해 폭스와 로거스는 공통 키워드를 커뮤니티에서 찾고, 여기에 ‘감정적인’ 언어와 욕설 사용 수를 분석해 어떤 문제가 개발자들을 화나게 했는지 알아보았다. 데이비드 폭스는 “전반적으로 개발자들이 흔히 짜증나게 느끼는 상황은 같은 것이 계속 반복될 때 생기는 것으로 보였다. 우리 방법론이 고도로 정교하지는 않을 수 있겠지만 개발자들의 정서와 분위기를 파악하는데 도움이 될 것이다. 개발자들의 이야기를 듣는 것, 이들의 의견이 받아들여지게 하고 그것을 실감하게 해주는 것, 문제를 해결하기 위해 할 수 있는 것을 하는 것이 중요하다”라고 말했다. 여기 ‘감정적인’ 말과 욕설이 포함된 주제상의 불평의 수에 기반해 소프트웨어 개발 팀을 화나게 하는 10가지 문제를 정리했다. 각 통계는 반올림된 값이다. Image Credit : Getty Images Bank 프로젝트/제품 관리자(22.5%) 개발자들은 일반적으로 그들의 작업을 어떻게 하라고 지시 받는 것을 싫어하는데, 제품/프로젝트 관리자들은 종종 개발팀을 감독하며 그런 일을 해야 한다고 지시한다. 여기서 마찰이 생길 수 있다. 폭스는 “확인 결과 제품/프로젝트 관리자들로 인한 불평이 두드러졌다. 이들 프로젝트 &...

개발자 소프트웨어 문서화 불평 데브란트

2016.10.05

사내 소프트웨어 개발자들이 요즘 짜증나 있는가? 만약 당신이 프로젝트 관리자나 개발자들의 상사, 채용담당자 혹은 QA 전문가라면 아마 그 원인은 바로 당신일 수 있다. 이는 소프트웨어 개발자들 사이의 화합, 지식 공유, 네트워킹을 장려하기 위해 구축된 온라인 커뮤니티 데브란트(devRant)의 새로운 데이터에 의한 것이다. 소프트웨어 개발자 출신인 데이비드 폭스와 팀 로거스가 2016년 3월 공동창업한 데브란트 커뮤니티에는 지금까지 약 1만 5,000명의 소프트웨어 개발자들이 2만 5,000개가 넘는 ‘불평’을 포스팅 했다. | 그들의 직업적 문제와 과제를 더 잘 이해하기 위해 폭스와 로거스는 공통 키워드를 커뮤니티에서 찾고, 여기에 ‘감정적인’ 언어와 욕설 사용 수를 분석해 어떤 문제가 개발자들을 화나게 했는지 알아보았다. 데이비드 폭스는 “전반적으로 개발자들이 흔히 짜증나게 느끼는 상황은 같은 것이 계속 반복될 때 생기는 것으로 보였다. 우리 방법론이 고도로 정교하지는 않을 수 있겠지만 개발자들의 정서와 분위기를 파악하는데 도움이 될 것이다. 개발자들의 이야기를 듣는 것, 이들의 의견이 받아들여지게 하고 그것을 실감하게 해주는 것, 문제를 해결하기 위해 할 수 있는 것을 하는 것이 중요하다”라고 말했다. 여기 ‘감정적인’ 말과 욕설이 포함된 주제상의 불평의 수에 기반해 소프트웨어 개발 팀을 화나게 하는 10가지 문제를 정리했다. 각 통계는 반올림된 값이다. Image Credit : Getty Images Bank 프로젝트/제품 관리자(22.5%) 개발자들은 일반적으로 그들의 작업을 어떻게 하라고 지시 받는 것을 싫어하는데, 제품/프로젝트 관리자들은 종종 개발팀을 감독하며 그런 일을 해야 한다고 지시한다. 여기서 마찰이 생길 수 있다. 폭스는 “확인 결과 제품/프로젝트 관리자들로 인한 불평이 두드러졌다. 이들 프로젝트 &...

2016.10.05

시간과 비용을 절약하는 프리랜서 계약 스킬 3가지

IT전문가와 긱 이코노미(gig economy)는 서로를 위해 존재하는 것처럼 보인다. 최근 IT월드가 보도한 것처럼, IT산업은 프리랜서 등 독립형 외주업체를 본격적으로 사용하기 시작한 최초의 산업이며, 이 과정에서 더 많은 IT인이 프리랜싱의 혜택을 누리고 있다. 이미지 출처 : Pixabay 그러나 IT프리랜서로 일하는 것에는 여러 위험이 따른다. 대표적인 것이 공식적인 계약을 맺지 않고 일하는 것이다. 기민성과 신속성을 중시하는 이 세계에서 계약서를 작성하고 수주 절차를 규정하는 것은 불필요한 잡무처럼 치부된다. 그러나 구두 계약보다는 서면 계약을 했을 때 법적인 보호를 더 받을 수 있고, 법적 분쟁으로 번질 가능성을 최소화할 수 있다. 다음의 3가지 사항을 적절히 실천해 ‘구두 관행’에서 벗어나기 바란다. 이 과정에서 IT전문가를 위협하는 요소, 즉 가장 많은 시간과 비용이 들어가는 위험을 피할 수 있을 것이다. 서면으로 계약하기 놀랍게도 서면으로 계약하지 않는 프리랜서가 있다. 1만 곳 이상의 IT 소기업(직원 수 10명 이하)과 프리랜서를 대상으로 조사한 자료를 보면, 13%가 서면 계약서를 쓰지 않았다. 표면적으로는 그리 높은 수치가 아닌 것처럼 보여도, 위험 가능성을 인지한 (그래서 필자의 회사 보험 상품에 가입한) 기업만을 대상으로 조사했기 때문에 실제 수치는 더 높을 것으로 예상된다. 더구나 계약서를 쓰지 않은 응답자에게서 업무 수행과 관련해 다음과 같은 근본적인 결함이 발견됐다. - 업무 규정 부재(12%) - 써드파티 관련 법적 면책 적용 불가(13%) - 손해 보상 규정 부재(34%) 이런 점을 간과하면 어떤 프로젝트에 참여하거나 수주했을 때 문제가 발생할 가능성이 크다. 계약 사항, 계약 관계, 프로젝트 수주 범위 등을 서면 계약서에 명확하게 규정하는 것이 좋다. 서면 계약서 작성은 모든 이를 동등하게 대우해 주고, 추후 불미스러운 일이 발생할 가능성을 최소화...

계약 긱 이코노미 IT 프로젝트 외주 수주 소기업 문서화 소송 프리랜서 1인 기업

2016.01.26

IT전문가와 긱 이코노미(gig economy)는 서로를 위해 존재하는 것처럼 보인다. 최근 IT월드가 보도한 것처럼, IT산업은 프리랜서 등 독립형 외주업체를 본격적으로 사용하기 시작한 최초의 산업이며, 이 과정에서 더 많은 IT인이 프리랜싱의 혜택을 누리고 있다. 이미지 출처 : Pixabay 그러나 IT프리랜서로 일하는 것에는 여러 위험이 따른다. 대표적인 것이 공식적인 계약을 맺지 않고 일하는 것이다. 기민성과 신속성을 중시하는 이 세계에서 계약서를 작성하고 수주 절차를 규정하는 것은 불필요한 잡무처럼 치부된다. 그러나 구두 계약보다는 서면 계약을 했을 때 법적인 보호를 더 받을 수 있고, 법적 분쟁으로 번질 가능성을 최소화할 수 있다. 다음의 3가지 사항을 적절히 실천해 ‘구두 관행’에서 벗어나기 바란다. 이 과정에서 IT전문가를 위협하는 요소, 즉 가장 많은 시간과 비용이 들어가는 위험을 피할 수 있을 것이다. 서면으로 계약하기 놀랍게도 서면으로 계약하지 않는 프리랜서가 있다. 1만 곳 이상의 IT 소기업(직원 수 10명 이하)과 프리랜서를 대상으로 조사한 자료를 보면, 13%가 서면 계약서를 쓰지 않았다. 표면적으로는 그리 높은 수치가 아닌 것처럼 보여도, 위험 가능성을 인지한 (그래서 필자의 회사 보험 상품에 가입한) 기업만을 대상으로 조사했기 때문에 실제 수치는 더 높을 것으로 예상된다. 더구나 계약서를 쓰지 않은 응답자에게서 업무 수행과 관련해 다음과 같은 근본적인 결함이 발견됐다. - 업무 규정 부재(12%) - 써드파티 관련 법적 면책 적용 불가(13%) - 손해 보상 규정 부재(34%) 이런 점을 간과하면 어떤 프로젝트에 참여하거나 수주했을 때 문제가 발생할 가능성이 크다. 계약 사항, 계약 관계, 프로젝트 수주 범위 등을 서면 계약서에 명확하게 규정하는 것이 좋다. 서면 계약서 작성은 모든 이를 동등하게 대우해 주고, 추후 불미스러운 일이 발생할 가능성을 최소화...

2016.01.26

'천재에게도 필요하다' 네트워크 문서화 가이드

모든 네트워크에는 네트워크 레이아웃을 보여주는 도해와 네트워크의 기본 사항 일체를 서면으로 기록한 문서로 구성된 맞춤화된 매뉴얼(설명서)이 있어야 한다. 설혹 누군가 놀라운 '천재'라서 네트워크에 대한 기본 사항 일체와 도해를 기억하고 있다고 할지라도, 문서화가 필요하다. 이런 천재들이 갑자기 회사를 그만 둘 수 있기 때문이다. 또 적절히 문서화를 해뒀다면, 새로 책임을 맡게 된 IT 직원의 학습 곡선이 훨씬 쉬워질 것이다. 이는 미래에 네트워크에 대한 도움을 요청하게 될 IT 계약업체에도 동일하게 적용되어야 하는 원칙이다. 네트워크 문서화가 도움을 주는 상황은 이 밖에도 많다. 예를 들어, 네트워크를 적절히 문서화하면 긴급 복구에도 도움이 된다. 하드웨어가 손상됐거나 고장 났을 경우, 다른 IT 담당 직원들이 네트워크 문서를 이용해 동일하게 네트워크를 설치해 구성할 수 있다. 보안 측면에서도 장점이 있다. 감사나 문서화 과정에 일부 보안 위험이 명백하게 드러날 가능성이 있기 때문이다. 네트워크 상태를 도해로 표시 가장 기본적인 문서 가운데 하나는 네트워크 상태(토폴로지)를 설명하는 도해다. 이는 모뎀, 라우터, 방화벽, 스위치, 서버, 무선 액세스 포인트 등 기본적인 네트워크 인프라스트럭처 요소의 상호 연결관계를 보여주는 간단한 그림이다. IT 담당자는 이런 도해를 통해 구성 요소의 이름, IP 주소, MAC 주소 등 기본적인 사항 등 네트워크를 시각적으로 신속하게 파악할 수 있다. 더 세부적인 정보를 제공하고 싶다면 프린터, 복사기, 유선으로 연결된 PC 등 고정 클라이언트를 추가시킨다. 도해를 만들 수 있도록 도움을 주는 소프트웨어 프로그램이 많다. 가장 많이 사용되는 소프트프로그램으로는 마이크로소프트 비지오(Microsoft Visio)를 들 수 있다. 뿐만 아니라 네트워크 노트패드(Network Notepad), CADE, 디아(Dia), 다이어그램 디자이너(Diagram Designer...

데이터센터 네트워크 문서화 도해 토폴로지

2014.05.14

모든 네트워크에는 네트워크 레이아웃을 보여주는 도해와 네트워크의 기본 사항 일체를 서면으로 기록한 문서로 구성된 맞춤화된 매뉴얼(설명서)이 있어야 한다. 설혹 누군가 놀라운 '천재'라서 네트워크에 대한 기본 사항 일체와 도해를 기억하고 있다고 할지라도, 문서화가 필요하다. 이런 천재들이 갑자기 회사를 그만 둘 수 있기 때문이다. 또 적절히 문서화를 해뒀다면, 새로 책임을 맡게 된 IT 직원의 학습 곡선이 훨씬 쉬워질 것이다. 이는 미래에 네트워크에 대한 도움을 요청하게 될 IT 계약업체에도 동일하게 적용되어야 하는 원칙이다. 네트워크 문서화가 도움을 주는 상황은 이 밖에도 많다. 예를 들어, 네트워크를 적절히 문서화하면 긴급 복구에도 도움이 된다. 하드웨어가 손상됐거나 고장 났을 경우, 다른 IT 담당 직원들이 네트워크 문서를 이용해 동일하게 네트워크를 설치해 구성할 수 있다. 보안 측면에서도 장점이 있다. 감사나 문서화 과정에 일부 보안 위험이 명백하게 드러날 가능성이 있기 때문이다. 네트워크 상태를 도해로 표시 가장 기본적인 문서 가운데 하나는 네트워크 상태(토폴로지)를 설명하는 도해다. 이는 모뎀, 라우터, 방화벽, 스위치, 서버, 무선 액세스 포인트 등 기본적인 네트워크 인프라스트럭처 요소의 상호 연결관계를 보여주는 간단한 그림이다. IT 담당자는 이런 도해를 통해 구성 요소의 이름, IP 주소, MAC 주소 등 기본적인 사항 등 네트워크를 시각적으로 신속하게 파악할 수 있다. 더 세부적인 정보를 제공하고 싶다면 프린터, 복사기, 유선으로 연결된 PC 등 고정 클라이언트를 추가시킨다. 도해를 만들 수 있도록 도움을 주는 소프트웨어 프로그램이 많다. 가장 많이 사용되는 소프트프로그램으로는 마이크로소프트 비지오(Microsoft Visio)를 들 수 있다. 뿐만 아니라 네트워크 노트패드(Network Notepad), CADE, 디아(Dia), 다이어그램 디자이너(Diagram Designer...

2014.05.14

서비스 중단 원인 90%, 문서화하지 않은 '시스템 변경' <넥릭스>

시스템 가동 중단의 90%가 시스템 변경 때문인 것으로 조사됐다. IT전문가를 대상으로 한 조사에서 보안 위험에 무방비 상태에서 기업의 IT시스템 변경을 문서화하지 않는다고 답한 사람이 절반 이상으로 집계됐다. 변경 및 구성 감사 소프트웨어 업체인 넷릭스(NetWrix)가 실시한 이 조사에 따르면, 기업의 60%는 적절하게 변경 관리를 관리하고 있으며 40%는 보안 위협이나 시스템 가동 중단에 대한 위험을 안고 있는 것으로 나타났다. 이 조사는 약 600명의 IT전문가를 대상으로 했으며, 자신 이외에 아무도 모르는 시스템 변경 사항을 문서화하지 않은 적이 있다고 밝힌 응답자가 무려 57%나 되는 것으로 파악됐다. 문서화하지 않거나 감사를, 거치지 않는 채 일어나는 잦은 시스템 변경은 전체 운영 효율성을 감소시키면서 시스템 중단과 내외부의 보안 위협을 일으킬 수 있다. 넷릭스의 조사에서 응답자의 65%는 서비스 중단의 원인이 되는 시스템 변경이 있었다고 말했으며 52%는 매일 또는 매주 영향을 미치는 시스템 중단에 영향을 주는 변경이 있었다고 답했다. 또한, 39%는 시스템 변경이 보안 문제의 근본 원인이 됐다고 밝혔으며 40%는 매일 또는 매주 보안에 영향을 미치는 변경이 있었다고 말했다. 대다수인 응답자 62%는 자신들의 변경한 것을 실제 감사할 수 있는 능력이 전혀 없거나 거의 없는 것으로 조사됐다. 넷릭스는 최상의 보안 및 규정 준수 목표를 달성하는 데에 심각한 격차를 보이고 있다고 전했다. 시스템 변경 내용을 입력해 확인할 수 있도록 감사 절차나 변경 감사 솔루션을 적절하게 도입했다고 밝힌 응답자는 23%에 불과했다. 넷릭스의 CEO인 마이클 핌민은 "이러한 조사 결과는 IT조직이 가용성과 보안에 영향을 주는 시스템 변경을 정기적으로 진행하면서 이를 문서화하지 않는다는 것을 보여준다"며 "이는 기업의 보안 및 성능을 위협할 수 있는 위험한 방법이다"라고 밝혔다. ...

CIO IT전문가 조사 문서화 변경 관리 시스템 중단 형상 관리 넷릭스

2014.04.23

시스템 가동 중단의 90%가 시스템 변경 때문인 것으로 조사됐다. IT전문가를 대상으로 한 조사에서 보안 위험에 무방비 상태에서 기업의 IT시스템 변경을 문서화하지 않는다고 답한 사람이 절반 이상으로 집계됐다. 변경 및 구성 감사 소프트웨어 업체인 넷릭스(NetWrix)가 실시한 이 조사에 따르면, 기업의 60%는 적절하게 변경 관리를 관리하고 있으며 40%는 보안 위협이나 시스템 가동 중단에 대한 위험을 안고 있는 것으로 나타났다. 이 조사는 약 600명의 IT전문가를 대상으로 했으며, 자신 이외에 아무도 모르는 시스템 변경 사항을 문서화하지 않은 적이 있다고 밝힌 응답자가 무려 57%나 되는 것으로 파악됐다. 문서화하지 않거나 감사를, 거치지 않는 채 일어나는 잦은 시스템 변경은 전체 운영 효율성을 감소시키면서 시스템 중단과 내외부의 보안 위협을 일으킬 수 있다. 넷릭스의 조사에서 응답자의 65%는 서비스 중단의 원인이 되는 시스템 변경이 있었다고 말했으며 52%는 매일 또는 매주 영향을 미치는 시스템 중단에 영향을 주는 변경이 있었다고 답했다. 또한, 39%는 시스템 변경이 보안 문제의 근본 원인이 됐다고 밝혔으며 40%는 매일 또는 매주 보안에 영향을 미치는 변경이 있었다고 말했다. 대다수인 응답자 62%는 자신들의 변경한 것을 실제 감사할 수 있는 능력이 전혀 없거나 거의 없는 것으로 조사됐다. 넷릭스는 최상의 보안 및 규정 준수 목표를 달성하는 데에 심각한 격차를 보이고 있다고 전했다. 시스템 변경 내용을 입력해 확인할 수 있도록 감사 절차나 변경 감사 솔루션을 적절하게 도입했다고 밝힌 응답자는 23%에 불과했다. 넷릭스의 CEO인 마이클 핌민은 "이러한 조사 결과는 IT조직이 가용성과 보안에 영향을 주는 시스템 변경을 정기적으로 진행하면서 이를 문서화하지 않는다는 것을 보여준다"며 "이는 기업의 보안 및 성능을 위협할 수 있는 위험한 방법이다"라고 밝혔다. ...

2014.04.23

데이터센터의 좀비 서버들 ‘퇴치는 이렇게’

가상화나 클라우드를 이용하고 있다 할지라도, 일부 내부 인프라를 유지하고 있을 확률이 높다. 이를 다른 말로 표현하면, 쓸모 없이 자원만 잡아먹는 서버나 기타 장비를 운영하고 있다는 의미이다. 맞다. 다름아닌 데이터 센터에 상주하고 있는 좀비(Zombie)들이다.   인프라 관리 회사인 코만트(Cormant)의 폴 구디손 CEO는 "많은 데이터 센터에서 많은 비용을 잡아먹고 있는 부분이다. 서버 한 대 당 연간 2,000달러의 비용이 든다. 그런데 서버 가운데 10~30%는 죽은 서버이다. 4,000개의 서버 가운데 400개가 죽은 서버라면 연간 80만 달러가 낭비된다는 이야기다. 결코 적은 돈이 아니다"라고 지적했다. 코만트의 고객사 중 한 곳은 총 900개의 인프라 장비를 보유하고 있다고 판단하고 있었다. 그러나 코만트가 실제 장비 수를 조사한 결과, 1,300개의 장비를 보유하고 있는 것이 밝혀졌다. 이 중 일부는 LAN 연결조차 되지 않은 채 전력만 소모하고 있었다. --------------------------------------------------------------- 데이터센터 인기기사 ->'동굴, 벙커, 사막···' 쿨하고 쿨한 데이터센터 9곳 -> 데이터센터 위한 필수 장비 10종 ->구글이 말하는 5가지 데이터센터 에너지 절약법 -> IT 전문가들이 선정한 필수 데이터센터 유틸리티 7선 -> 데이터센터 효율성 개선을 위한 6가지 팁테크 -> 8가지 획기적인 데이터센터 전력 비용 절감 방안 --------------------------------------------------------------- 좀비 서버가 만연하는 이유 구디손은 좀비 서버가 만연하는 데는 1~2가지 이유가 있다고 설명했다. 먼저 일정기간 사용을 했다가, 이후에는 기록상의 장비로만 남겨진 상태가...

데이터센터 서버 DCIM 문서화 인프라 관리 좀비

2012.04.24

가상화나 클라우드를 이용하고 있다 할지라도, 일부 내부 인프라를 유지하고 있을 확률이 높다. 이를 다른 말로 표현하면, 쓸모 없이 자원만 잡아먹는 서버나 기타 장비를 운영하고 있다는 의미이다. 맞다. 다름아닌 데이터 센터에 상주하고 있는 좀비(Zombie)들이다.   인프라 관리 회사인 코만트(Cormant)의 폴 구디손 CEO는 "많은 데이터 센터에서 많은 비용을 잡아먹고 있는 부분이다. 서버 한 대 당 연간 2,000달러의 비용이 든다. 그런데 서버 가운데 10~30%는 죽은 서버이다. 4,000개의 서버 가운데 400개가 죽은 서버라면 연간 80만 달러가 낭비된다는 이야기다. 결코 적은 돈이 아니다"라고 지적했다. 코만트의 고객사 중 한 곳은 총 900개의 인프라 장비를 보유하고 있다고 판단하고 있었다. 그러나 코만트가 실제 장비 수를 조사한 결과, 1,300개의 장비를 보유하고 있는 것이 밝혀졌다. 이 중 일부는 LAN 연결조차 되지 않은 채 전력만 소모하고 있었다. --------------------------------------------------------------- 데이터센터 인기기사 ->'동굴, 벙커, 사막···' 쿨하고 쿨한 데이터센터 9곳 -> 데이터센터 위한 필수 장비 10종 ->구글이 말하는 5가지 데이터센터 에너지 절약법 -> IT 전문가들이 선정한 필수 데이터센터 유틸리티 7선 -> 데이터센터 효율성 개선을 위한 6가지 팁테크 -> 8가지 획기적인 데이터센터 전력 비용 절감 방안 --------------------------------------------------------------- 좀비 서버가 만연하는 이유 구디손은 좀비 서버가 만연하는 데는 1~2가지 이유가 있다고 설명했다. 먼저 일정기간 사용을 했다가, 이후에는 기록상의 장비로만 남겨진 상태가...

2012.04.24

기고 | ‘클라우드 설계 협업’ 문서화 방법은?

클라우드 시스템을 개발하고 통합하는 데 있어 공용 인터페이스(public interfaces)와 해당 서비스를 이용하는 '외부 개발자들(external "contracts")'과의 협업은, 설계와 아키텍처를 빠르게 그리고 동시에 진척시킬 수 있음을 시사한다. 하지만 이 경우 특히 개발자들이 서로 다른 공간에서 파일을 동시에 관리함에 따라, 갑작스런 변화로 인한 업무적 혼란을 초래할 수도 있다. 예를 들어 (서비스 제공자와 서비스 소비자라는) 두 팀이 인터페이스를 마주보고 작업한다면, 변수와 방법을 일치시키기가 힘들어진다. 물론 서비스를 제공하는 당사자가 문서를 업데이트 한 후, 상대 팀에게 새 필드 값이나 서비스 행동의 새로운 의미에 대해 통보할 수는 있다. 그러나 현실적으로 바로 바로 실천에 옮겨지는 경우는 드물다. 이 경우 변경된 문서 버전을 팀별로 분산해 관리하면서, 최종본이 무엇인지를 두고 비롯되는 통상적인 문제들이 대두된다. 클라우드 설계와 아키텍처 협업과 관련해 몇 가지 현실부터 살펴보자. 1. 해당 팀들은 규칙과 프로세스에 우선해 속도와 현명함에 가치를 부여한다. 2. 반복 개발을 강조하는 애자일(Agile) 프로세스를 사용하고, 지속적으로 통합하고 테스트한다. 3. 방법론에 무게를 두지 않고, 높은 수준의 실용성을 추구한다. 특히 ULM, 기타 특정 모델링이나 인터페이스 정의 툴을 고집하지 않는다. 4. 중앙에서 관리되지 않는 여러 조직에 팀들이 산개해 있기 쉽다. 5. 팀원들이 서로 떨어져 위치해 있다. 그렇다면 이것들이 시사하는 바는 뭘까? 일반적으로, 설계 협력에 있어 공통 분모로 사용되는 툴이 없을 확률이 높다는 것이다. (그렇다. 애자일 툴들이 있다. 그러나 기껏해야 고르지 않게 사용되고 있을 뿐이다.) 따라서 마이크로소프트 워드, 액셀, 비지오, 파워포인트가 출발점이 되기 쉽다. 불행히도, 이들 툴 대부분은 변경 관리 기능이 미흡하다. 만약 많은 사람...

클라우드 협업 문서화 설계 변경 관리

2012.02.01

클라우드 시스템을 개발하고 통합하는 데 있어 공용 인터페이스(public interfaces)와 해당 서비스를 이용하는 '외부 개발자들(external "contracts")'과의 협업은, 설계와 아키텍처를 빠르게 그리고 동시에 진척시킬 수 있음을 시사한다. 하지만 이 경우 특히 개발자들이 서로 다른 공간에서 파일을 동시에 관리함에 따라, 갑작스런 변화로 인한 업무적 혼란을 초래할 수도 있다. 예를 들어 (서비스 제공자와 서비스 소비자라는) 두 팀이 인터페이스를 마주보고 작업한다면, 변수와 방법을 일치시키기가 힘들어진다. 물론 서비스를 제공하는 당사자가 문서를 업데이트 한 후, 상대 팀에게 새 필드 값이나 서비스 행동의 새로운 의미에 대해 통보할 수는 있다. 그러나 현실적으로 바로 바로 실천에 옮겨지는 경우는 드물다. 이 경우 변경된 문서 버전을 팀별로 분산해 관리하면서, 최종본이 무엇인지를 두고 비롯되는 통상적인 문제들이 대두된다. 클라우드 설계와 아키텍처 협업과 관련해 몇 가지 현실부터 살펴보자. 1. 해당 팀들은 규칙과 프로세스에 우선해 속도와 현명함에 가치를 부여한다. 2. 반복 개발을 강조하는 애자일(Agile) 프로세스를 사용하고, 지속적으로 통합하고 테스트한다. 3. 방법론에 무게를 두지 않고, 높은 수준의 실용성을 추구한다. 특히 ULM, 기타 특정 모델링이나 인터페이스 정의 툴을 고집하지 않는다. 4. 중앙에서 관리되지 않는 여러 조직에 팀들이 산개해 있기 쉽다. 5. 팀원들이 서로 떨어져 위치해 있다. 그렇다면 이것들이 시사하는 바는 뭘까? 일반적으로, 설계 협력에 있어 공통 분모로 사용되는 툴이 없을 확률이 높다는 것이다. (그렇다. 애자일 툴들이 있다. 그러나 기껏해야 고르지 않게 사용되고 있을 뿐이다.) 따라서 마이크로소프트 워드, 액셀, 비지오, 파워포인트가 출발점이 되기 쉽다. 불행히도, 이들 툴 대부분은 변경 관리 기능이 미흡하다. 만약 많은 사람...

2012.02.01

기고 | 클라우드 개발 문서의 무모함에 대하여

복잡한 기술에는 개발자들이 효과적으로 사용할 수 있는 개발문서와 교육 자료가 필요하다.  클라우드의 경우, 개발자들이 HTML, 자바스크립트, XML, CSS, 제이쿼리(jquery), 루비(Ruby), PHP, SQL 등 여러 언어를 동시에 다뤄야 하기 때문에 이런 요구가 더 절실할지도 모른다. 그렇다면 클라우드 개발자들에게도 개발문서란 필요한 것인가? 다른 불편 사항들을 알아보자. • 기술과 친숙한 업체들은 문서 작성에 관심이 없다. 개발자들이 자신들의 코드에 대해 이러쿵저러쿵 지적을 하지 않는데, 그들이 개발문서를 작성하려 할 것 같은가? 또한 해당 업체의 관리자들은 개발문서쯤이야 필요하면 개발 문서를 대신 작성할 사람을 고용하면 된다. 게다가 관리자들은 정보 가공 전문가인 기술 기고가들(tech writers)을 고용할 만큼 강력한 경제적인 동기(economic incentives)를 가지고 있다. 비록 이 기술 기고가들이 개발을 잘 모르더라도 말이다. • 현재 어느 클라우드 업체 하나가 전체적으로 7,500페이지나 되는 문서를 갖고 있다고 하자. 문서에는 엄청난 투자만큼이나 프로젝트 시작점부터 작성된 글들과 난무하는 데이터 등으로 이미 많은 자료들이 적혀있을 것이다. 실제 시스템에서 기능을 사용할 때는, 개발문서를 볼 필요 없이 구글과 사용자 커뮤니티를 검색하면 된다. 물론 웹의 잘못된 정보 때문에 시간을 낭비하게 될 수도 있다. 하지만 다른 개발자들도 당신처럼 도전과 실패를 반복한다는 것을 알게 된다면 조금은 위안이 될 것이다. • 모든 고객지원 센터들이 문의 전화의 50%에 대해 답변으로 제시하고 있는 ‘매뉴얼을 읽으세요’ 에 대해 알아 보자. 이러한 대응은 해당 업체의 문서가 잘못됐거나 예시에 관한 내용이 없을 때 무척 ‘효과적’이다. 필자는 최근 한 업체의 개발문서에서 2개의 버그를 찾아 보고했고 수 차례 이메일을 교환했다. 하지만...

CIO 개발자 개발 코드 문서화

2011.12.16

복잡한 기술에는 개발자들이 효과적으로 사용할 수 있는 개발문서와 교육 자료가 필요하다.  클라우드의 경우, 개발자들이 HTML, 자바스크립트, XML, CSS, 제이쿼리(jquery), 루비(Ruby), PHP, SQL 등 여러 언어를 동시에 다뤄야 하기 때문에 이런 요구가 더 절실할지도 모른다. 그렇다면 클라우드 개발자들에게도 개발문서란 필요한 것인가? 다른 불편 사항들을 알아보자. • 기술과 친숙한 업체들은 문서 작성에 관심이 없다. 개발자들이 자신들의 코드에 대해 이러쿵저러쿵 지적을 하지 않는데, 그들이 개발문서를 작성하려 할 것 같은가? 또한 해당 업체의 관리자들은 개발문서쯤이야 필요하면 개발 문서를 대신 작성할 사람을 고용하면 된다. 게다가 관리자들은 정보 가공 전문가인 기술 기고가들(tech writers)을 고용할 만큼 강력한 경제적인 동기(economic incentives)를 가지고 있다. 비록 이 기술 기고가들이 개발을 잘 모르더라도 말이다. • 현재 어느 클라우드 업체 하나가 전체적으로 7,500페이지나 되는 문서를 갖고 있다고 하자. 문서에는 엄청난 투자만큼이나 프로젝트 시작점부터 작성된 글들과 난무하는 데이터 등으로 이미 많은 자료들이 적혀있을 것이다. 실제 시스템에서 기능을 사용할 때는, 개발문서를 볼 필요 없이 구글과 사용자 커뮤니티를 검색하면 된다. 물론 웹의 잘못된 정보 때문에 시간을 낭비하게 될 수도 있다. 하지만 다른 개발자들도 당신처럼 도전과 실패를 반복한다는 것을 알게 된다면 조금은 위안이 될 것이다. • 모든 고객지원 센터들이 문의 전화의 50%에 대해 답변으로 제시하고 있는 ‘매뉴얼을 읽으세요’ 에 대해 알아 보자. 이러한 대응은 해당 업체의 문서가 잘못됐거나 예시에 관한 내용이 없을 때 무척 ‘효과적’이다. 필자는 최근 한 업체의 개발문서에서 2개의 버그를 찾아 보고했고 수 차례 이메일을 교환했다. 하지만...

2011.12.16

기고 | 클라우드에서의 문서화 작업법

코드에 주석을 달지 않거나 시스템을 문서화(documenting)하지 않은 것에는 변명의 여지가 없다. 이런 관행이 테스트 개발에 있어 비용절감과 품질에 있어 도움이 된다고 하더라도 그렇다. 하지만 사실을 직시하자. 시스템 문서화는 필요악이 아니다. 게다가 관리가 불가능한 코드의 보안 처리라는 지저분한 작업을 안겨주지도 않는다. 불행히도 클라우드에서의 작업은 개발자들에게  "퍼블릭 클라우드 서비스라 액세스도 통제도 불가능하지 않습니까? 문서 작업을 할 수 있는 부분이 없습니다"라는 새로운 구실을 제공할 수 있다. 좋다. 개발자들의 변명에 이런 식으로 반박해 보자. '퍼블릭이든 프라이빗이든 클라우드 서비스를 이용하는 모든 소비자들은 서비스가 하는 일과 활용방법, (버그와 오류 조건을 포함) 소비 측면 활용과 결정 요소 측면에서의 행동들을 문서화 작업해야 한다.' 그러면 아마 "우리가 사용하는 모든 모듈의 동일한 클라우드 서비스를 대상으로 문서화 작업을 해야 한다는 이야기 아닙니까?''라고 볼멘 소리를 할게 분명하다. 이 경우 '문서화 정보를 개발 및 통합 팀 전체가 액세스할 수 있는 위키(Wiki)와 구글 독스(Google Docs), 또는 다른 협업 시스템에 집어 넣어야 한다'라고 대답해야 한다. 이는 모든 사람들이 외부 인터페이스와 모듈 및 서비스 의존성에 있어 베스트 프랙티스를 이행하도록 견인하는 역할을 한다. 개발팀 일원 전부에 의해 생성되고 관리되는 콘텐츠를 보유한 중앙화된 보관소인 것이다. 개인적인 경험에 비춰보자면 데이터 딕셔너리와 개체-관계 모델, 비즈니스-프로세스 설명, 또는 인터페이스 문서화를 책임진 중앙형 팀을 갖는 것의 대안이 생산해 낼 수 있는 것은 단 2가지뿐이다. 문서화를 하지 않는데 따른 구실이거나 기껏해야 구식 또는 부정확한데다 양만 많은 부분들 뿐이다. 그렇다면 모듈 인터널이나 변수의 어드미니스트리비아(Adminis...

클라우드 개발 주석 문서화

2011.07.29

코드에 주석을 달지 않거나 시스템을 문서화(documenting)하지 않은 것에는 변명의 여지가 없다. 이런 관행이 테스트 개발에 있어 비용절감과 품질에 있어 도움이 된다고 하더라도 그렇다. 하지만 사실을 직시하자. 시스템 문서화는 필요악이 아니다. 게다가 관리가 불가능한 코드의 보안 처리라는 지저분한 작업을 안겨주지도 않는다. 불행히도 클라우드에서의 작업은 개발자들에게  "퍼블릭 클라우드 서비스라 액세스도 통제도 불가능하지 않습니까? 문서 작업을 할 수 있는 부분이 없습니다"라는 새로운 구실을 제공할 수 있다. 좋다. 개발자들의 변명에 이런 식으로 반박해 보자. '퍼블릭이든 프라이빗이든 클라우드 서비스를 이용하는 모든 소비자들은 서비스가 하는 일과 활용방법, (버그와 오류 조건을 포함) 소비 측면 활용과 결정 요소 측면에서의 행동들을 문서화 작업해야 한다.' 그러면 아마 "우리가 사용하는 모든 모듈의 동일한 클라우드 서비스를 대상으로 문서화 작업을 해야 한다는 이야기 아닙니까?''라고 볼멘 소리를 할게 분명하다. 이 경우 '문서화 정보를 개발 및 통합 팀 전체가 액세스할 수 있는 위키(Wiki)와 구글 독스(Google Docs), 또는 다른 협업 시스템에 집어 넣어야 한다'라고 대답해야 한다. 이는 모든 사람들이 외부 인터페이스와 모듈 및 서비스 의존성에 있어 베스트 프랙티스를 이행하도록 견인하는 역할을 한다. 개발팀 일원 전부에 의해 생성되고 관리되는 콘텐츠를 보유한 중앙화된 보관소인 것이다. 개인적인 경험에 비춰보자면 데이터 딕셔너리와 개체-관계 모델, 비즈니스-프로세스 설명, 또는 인터페이스 문서화를 책임진 중앙형 팀을 갖는 것의 대안이 생산해 낼 수 있는 것은 단 2가지뿐이다. 문서화를 하지 않는데 따른 구실이거나 기껏해야 구식 또는 부정확한데다 양만 많은 부분들 뿐이다. 그렇다면 모듈 인터널이나 변수의 어드미니스트리비아(Adminis...

2011.07.29

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.6