2020.10.19

“다섯 마리 토끼 잡아라”··· CIO가 앱 개발자에 원하는 것들

Isaac Sacolick | InfoWorld
CIO와 IT 리더는 애플리케이션 개발, 보강, 현대화를 두고 우선순위 문제로 골머리를 앓고 있다. 한편으론 혁신, 우수한 사용자 경험, 애자일 데브옵스 관행을 추진 중이다. 또 다른 한편으로는 쌓여가는 기술 부채, 애플리케이션의 적절한 보안 검증, 프로덕션 환경에서의 프로토타입 실행 및 확장 가능 여부를 우려하기도 한다. 
 
CIO와 IT 리더는 비유하자면 ‘모든 토끼를 잡길’ 원한다. 물론 이들은 개발자와 딜리버리 리더가 요구하는 것부터 해야만 하는 것, 원하는 것까지 속속들이 알고 있다. 코드를 제대로 개발하기 위해 더 많은 시간과 인력, 민첩한 개발 인프라와 현대적인 애플리케이션 개발 툴, 이해관계자의 적극적인 개입, 적절한 교육, 잘 정의된 우선순위 등을 바라는 것을 예로 들 수 있다. 
 
ⓒGetty Images

그러나 IT 리더는 디지털 트랜스포메이션을 주도해야 하고, 예산 제약을 고려해야 하며, 컴플라이언스 요건을 충족해야 하는 비즈니스 현실에 직면해 있다. 

또한 CIO는 애플리케이션 개발팀이 ‘절충(Trade-off)’과 관련해 신중한 결정을 내리는 방법, 개발 대상을 지원하기 위해 취해야 할 조치들 그리고 애플리케이션을 완성하는 것만큼이나 엔드유저, 이해관계자, 아키텍트, 운영팀과의 협력이 중요한 이유를 알길 원한다. 

여기서는 이런 과제와 관련해 CIO가 개발팀에 원하는 다섯 가지 요소를 살펴본다. 

1. 기술 부채와 혁신 사이의 균형을 맞춰라 
예를 들면 혁신 전략을 추진하거나 혹은 새 기술에 관한 스파이크를 제품 백로그에 추가할 때 개발팀은 흥분하기 십상이다. CIO와 IT 리더도 혁신을 바라지만 개발팀이 기술 부채를 처리하지 않는다면 이를 우려할 수밖에 없다. 

다시 말해, ‘건전한’ 제품 백로그라면 애자일 팀이 스파이크, 기술 부채, 신기능, 운영 개선 사이의 균형을 유지하고 있음을 보여줘야 한다는 뜻이다. 

애자일 팀의 우선순위는 제품 소유자에게 있다. 그러나 IT 리더는 제품 소유자가 기술 부채를 고려하지 않거나 혹은 혁신을 고려하지 않고 기능만 우선시한다면 이에 관한 원칙을 수립할 수 있다. 

CIO와 IT 리더는 현실적이다. 이들은 새로운 개발에 추가적인 기술 부채가 수반될 것임을 알고 있다. 또한 개발자가 때에 따라 마감일을 맞추기 위해 혹은 더 효율적인 코딩 옵션을 파악하기 위해 절차나 원칙을 무시한다는 것도 알고 있다. 

따라서 새롭게 생성된 기술 부채는 소스코드와 애자일 백로그에 성문화되고, 개발팀은 우선순위에 따라 이를 해결하려고 한다고 보는 게 타당할 것이다. 

2. 언제나 안전하고 유지보수가 가능한 코드를 개발하라 
개발팀은 기능 및 서비스를 신속히 엔드유저에게 제공해야 한다는 엄청난 압박을 받는다. 이는 개발팀이 새로운 기술 부채를 만드는 분명한 원인이긴 하지만, 이 때문에 유지보수가 불가능하거나 보안 표준을 건너뛰는 코드를 개발한다고 하는 것은 구차한 변명이다. 

IT 리더는 이리저리 뒤엉킨 ‘스파게티’ 코드는 물론이고 고급 엔지니어가 유지보수해야 할 정도로 지나치게 복잡한 코드도 원하지 않는다. 배포된 코드를 장기간 유지 관리해야 하기 때문이다. 이들은 아키텍처 표준, 코딩 표준, 명명 규칙, 로깅 패턴, 예외 처리 등을 준수하는 코드를 기대한다. 

또한 IT 리더는 개발팀이 표준을 정의하고 발전 시켜 나가는 데 협력하길 바란다. 기술, 플랫폼, 베스트 프랙티스가 계속해서 진화하므로 아키텍트에게 가이드라인을 소유하고 검토하는 일을 전부 맡기긴 어렵다. 

3. 적절한 기능과 확장성으로 우수한 사용자 경험을 생성하라 
웹 개발 초창기, 소프트웨어 팀은 애플리케이션 아키텍처와 디자인 사이에서 타협과 절충을 하느라 어려움을 겪었다. 

한 가지 접근방식은 백엔드 데이터베이스를 설계하고 비즈니스 로직을 코딩하는 팀에서부터 개발 프로세스를 시작하는 것이었다. 엔지니어들은 재사용할 수 있고 확장할 수 있는 솔루션을 개발했지만 사용자 경험과 디자인에 제약이 있는 경우가 많았다. 

또 다른 접근방식은 웹개발 팀이 프론트엔드 디자인부터 담당해 우수한 사용자 경험을 제공하는 것이었다. 그러나 이들 설계에서 비즈니스 로직이 서버 측 템플릿 내부에 구축되거나 혹은 빈번한 서비스 호출이 발생해 애플리케이션이 제대로 작동하거나 확장되지 않는 결과가 나타났다. 

CIO는 우수한 사용자 경험과 성능을 제공해야 한다. 오늘날 개발팀은 이를 위해 와이어프레임 툴, 로우코드 플랫폼, 기능 플래그, 마이크로서비스 디자인 패턴, 데브옵스 베스트 프랙티스, 테스트 자동화 및 클라우드 아키텍처를 사용하고 있다. 

4. ‘기술을 위한 기술’ 문제를 해결하려는 코딩은 지양하라
개발팀과 애자일 계획 회의를 진행한다고 가정해보자. CIO와 IT 리더는 문제를 듣고 이를 여러 카테고리 가운데 하나로 분류할 것이다. 

이때 적절한 기능과 사용자 스토리는 타깃 엔드유저를 위한 기능을 제공하거나 개선하는 데 목적을 둔다. 또한 새로운 솔루션을 테스트하거나 새 기능의 프로토타입을 만들기 위한 스파이크를 계획하기도 한다. 

때때로 기술 부채는 사용자 스토리를 만들어나가면서 해결되기도 한다. 물론 백로그에 여러 스토리가 쌓일 정도로 일이 커질 때도 있다. 이들은 모두 제품 소유자가 검토하고 우선순위를 정해야 할 작업의 좋은 예다. 

간혹 기술 문제만 처리하려는 작업이 있다. 구성 및 서비스 연결을 지원하는 유틸리티 클래스를 예로 들 수 있겠다. 또한 개발팀은 이를 위해서 마이크로콘텐츠 관리 솔루션, 로우코드 기능, API 관리 툴을 구축하려고 하기도 한다. 

개발팀은 기술 문제만을 해결하려고 기술 역량을 구축해선 안 된다. 기술 문제를 해결할 수 있는 적절한 솔루션은 오픈소스 라이브러리, 퍼블릭 클라우드 컴퓨팅 서비스, 로우코드 기능, 사용 소프트웨어 서비스를 통해 제공되는 경우가 많다. 아키텍트와 개발팀은 ‘기술을 위한 기술’ 솔루션을 개발하기에 앞서 이러한 옵션들을 검토해야 한다. 

5. 데이터 거버넌스 표준을 준수하라 
마지막으로 CIO와 IT 리더가 원하지 않는 것은 데이터 사일로, 중복된 데이터 소스, 잘못 설계된 데이터 구조다. 

대부분 기업에서 ‘데이터 부채(data debt)’ 규모는 기술 부채를 넘어서는 경우가 많으며, 이것이 비즈니스에 미치는 영향은 상당하다. 데이터 과학자에게 엔터프라이즈 데이터 웨어하우스와 데이터 레이크에 산만하게 퍼져 있는 데이터 소스를 파악하라고 요청하라. 

오늘날 관계형 데이터베이스, NoSQL 데이터스토어, 데이터 레이크를 생성하는 것은 믿을 수 없을 정도로 쉽다. 하지만 이는 축복이자 저주다. 개발팀이 어떤 데이터 소스를 이용할 수 있는지, 그리고 데이터 소스와 상호작용하는 적절한 방법은 무엇인지 파악해야 하기 때문이다. 

새로운 데이터 구조를 생성하기 전에 데이터 카탈로그, API 포털, 마스터 데이터 소스를 검토해야 한다. 또 새로운 데이터 구조가 필요하다면 개발팀은 데이터 모델링 툴을 사용해야 하고 예외 없이 데이터 거버넌스 표준을 준수해야 한다. 

정리하자면, CIO와 리더는 혁신, 속도, 우수한 사용자 경험은 물론이고 비즈니스 과제를 해결하는 데 열정적인 개발팀을 원한다. 그러면서도 안정성, 성능, 효율, 확장성, 보안을 비롯해 장기간 유지 관리할 수 있는 애플리케이션도 원한다. 

이들은 상호 배타적인 목표가 아니다. 그러나 실질적으로 모든 릴리즈, 스프린트, 사용자 스토리마다 절충은 불가피하다. 따라서 IT 조직은 엔지니어링 원칙을 정의하고 이를 개발 프로세스의 일환으로 어떻게 실행할 것인지 논의해야 한다. ciokr@idg.co.kr
 



2020.10.19

“다섯 마리 토끼 잡아라”··· CIO가 앱 개발자에 원하는 것들

Isaac Sacolick | InfoWorld
CIO와 IT 리더는 애플리케이션 개발, 보강, 현대화를 두고 우선순위 문제로 골머리를 앓고 있다. 한편으론 혁신, 우수한 사용자 경험, 애자일 데브옵스 관행을 추진 중이다. 또 다른 한편으로는 쌓여가는 기술 부채, 애플리케이션의 적절한 보안 검증, 프로덕션 환경에서의 프로토타입 실행 및 확장 가능 여부를 우려하기도 한다. 
 
CIO와 IT 리더는 비유하자면 ‘모든 토끼를 잡길’ 원한다. 물론 이들은 개발자와 딜리버리 리더가 요구하는 것부터 해야만 하는 것, 원하는 것까지 속속들이 알고 있다. 코드를 제대로 개발하기 위해 더 많은 시간과 인력, 민첩한 개발 인프라와 현대적인 애플리케이션 개발 툴, 이해관계자의 적극적인 개입, 적절한 교육, 잘 정의된 우선순위 등을 바라는 것을 예로 들 수 있다. 
 
ⓒGetty Images

그러나 IT 리더는 디지털 트랜스포메이션을 주도해야 하고, 예산 제약을 고려해야 하며, 컴플라이언스 요건을 충족해야 하는 비즈니스 현실에 직면해 있다. 

또한 CIO는 애플리케이션 개발팀이 ‘절충(Trade-off)’과 관련해 신중한 결정을 내리는 방법, 개발 대상을 지원하기 위해 취해야 할 조치들 그리고 애플리케이션을 완성하는 것만큼이나 엔드유저, 이해관계자, 아키텍트, 운영팀과의 협력이 중요한 이유를 알길 원한다. 

여기서는 이런 과제와 관련해 CIO가 개발팀에 원하는 다섯 가지 요소를 살펴본다. 

1. 기술 부채와 혁신 사이의 균형을 맞춰라 
예를 들면 혁신 전략을 추진하거나 혹은 새 기술에 관한 스파이크를 제품 백로그에 추가할 때 개발팀은 흥분하기 십상이다. CIO와 IT 리더도 혁신을 바라지만 개발팀이 기술 부채를 처리하지 않는다면 이를 우려할 수밖에 없다. 

다시 말해, ‘건전한’ 제품 백로그라면 애자일 팀이 스파이크, 기술 부채, 신기능, 운영 개선 사이의 균형을 유지하고 있음을 보여줘야 한다는 뜻이다. 

애자일 팀의 우선순위는 제품 소유자에게 있다. 그러나 IT 리더는 제품 소유자가 기술 부채를 고려하지 않거나 혹은 혁신을 고려하지 않고 기능만 우선시한다면 이에 관한 원칙을 수립할 수 있다. 

CIO와 IT 리더는 현실적이다. 이들은 새로운 개발에 추가적인 기술 부채가 수반될 것임을 알고 있다. 또한 개발자가 때에 따라 마감일을 맞추기 위해 혹은 더 효율적인 코딩 옵션을 파악하기 위해 절차나 원칙을 무시한다는 것도 알고 있다. 

따라서 새롭게 생성된 기술 부채는 소스코드와 애자일 백로그에 성문화되고, 개발팀은 우선순위에 따라 이를 해결하려고 한다고 보는 게 타당할 것이다. 

2. 언제나 안전하고 유지보수가 가능한 코드를 개발하라 
개발팀은 기능 및 서비스를 신속히 엔드유저에게 제공해야 한다는 엄청난 압박을 받는다. 이는 개발팀이 새로운 기술 부채를 만드는 분명한 원인이긴 하지만, 이 때문에 유지보수가 불가능하거나 보안 표준을 건너뛰는 코드를 개발한다고 하는 것은 구차한 변명이다. 

IT 리더는 이리저리 뒤엉킨 ‘스파게티’ 코드는 물론이고 고급 엔지니어가 유지보수해야 할 정도로 지나치게 복잡한 코드도 원하지 않는다. 배포된 코드를 장기간 유지 관리해야 하기 때문이다. 이들은 아키텍처 표준, 코딩 표준, 명명 규칙, 로깅 패턴, 예외 처리 등을 준수하는 코드를 기대한다. 

또한 IT 리더는 개발팀이 표준을 정의하고 발전 시켜 나가는 데 협력하길 바란다. 기술, 플랫폼, 베스트 프랙티스가 계속해서 진화하므로 아키텍트에게 가이드라인을 소유하고 검토하는 일을 전부 맡기긴 어렵다. 

3. 적절한 기능과 확장성으로 우수한 사용자 경험을 생성하라 
웹 개발 초창기, 소프트웨어 팀은 애플리케이션 아키텍처와 디자인 사이에서 타협과 절충을 하느라 어려움을 겪었다. 

한 가지 접근방식은 백엔드 데이터베이스를 설계하고 비즈니스 로직을 코딩하는 팀에서부터 개발 프로세스를 시작하는 것이었다. 엔지니어들은 재사용할 수 있고 확장할 수 있는 솔루션을 개발했지만 사용자 경험과 디자인에 제약이 있는 경우가 많았다. 

또 다른 접근방식은 웹개발 팀이 프론트엔드 디자인부터 담당해 우수한 사용자 경험을 제공하는 것이었다. 그러나 이들 설계에서 비즈니스 로직이 서버 측 템플릿 내부에 구축되거나 혹은 빈번한 서비스 호출이 발생해 애플리케이션이 제대로 작동하거나 확장되지 않는 결과가 나타났다. 

CIO는 우수한 사용자 경험과 성능을 제공해야 한다. 오늘날 개발팀은 이를 위해 와이어프레임 툴, 로우코드 플랫폼, 기능 플래그, 마이크로서비스 디자인 패턴, 데브옵스 베스트 프랙티스, 테스트 자동화 및 클라우드 아키텍처를 사용하고 있다. 

4. ‘기술을 위한 기술’ 문제를 해결하려는 코딩은 지양하라
개발팀과 애자일 계획 회의를 진행한다고 가정해보자. CIO와 IT 리더는 문제를 듣고 이를 여러 카테고리 가운데 하나로 분류할 것이다. 

이때 적절한 기능과 사용자 스토리는 타깃 엔드유저를 위한 기능을 제공하거나 개선하는 데 목적을 둔다. 또한 새로운 솔루션을 테스트하거나 새 기능의 프로토타입을 만들기 위한 스파이크를 계획하기도 한다. 

때때로 기술 부채는 사용자 스토리를 만들어나가면서 해결되기도 한다. 물론 백로그에 여러 스토리가 쌓일 정도로 일이 커질 때도 있다. 이들은 모두 제품 소유자가 검토하고 우선순위를 정해야 할 작업의 좋은 예다. 

간혹 기술 문제만 처리하려는 작업이 있다. 구성 및 서비스 연결을 지원하는 유틸리티 클래스를 예로 들 수 있겠다. 또한 개발팀은 이를 위해서 마이크로콘텐츠 관리 솔루션, 로우코드 기능, API 관리 툴을 구축하려고 하기도 한다. 

개발팀은 기술 문제만을 해결하려고 기술 역량을 구축해선 안 된다. 기술 문제를 해결할 수 있는 적절한 솔루션은 오픈소스 라이브러리, 퍼블릭 클라우드 컴퓨팅 서비스, 로우코드 기능, 사용 소프트웨어 서비스를 통해 제공되는 경우가 많다. 아키텍트와 개발팀은 ‘기술을 위한 기술’ 솔루션을 개발하기에 앞서 이러한 옵션들을 검토해야 한다. 

5. 데이터 거버넌스 표준을 준수하라 
마지막으로 CIO와 IT 리더가 원하지 않는 것은 데이터 사일로, 중복된 데이터 소스, 잘못 설계된 데이터 구조다. 

대부분 기업에서 ‘데이터 부채(data debt)’ 규모는 기술 부채를 넘어서는 경우가 많으며, 이것이 비즈니스에 미치는 영향은 상당하다. 데이터 과학자에게 엔터프라이즈 데이터 웨어하우스와 데이터 레이크에 산만하게 퍼져 있는 데이터 소스를 파악하라고 요청하라. 

오늘날 관계형 데이터베이스, NoSQL 데이터스토어, 데이터 레이크를 생성하는 것은 믿을 수 없을 정도로 쉽다. 하지만 이는 축복이자 저주다. 개발팀이 어떤 데이터 소스를 이용할 수 있는지, 그리고 데이터 소스와 상호작용하는 적절한 방법은 무엇인지 파악해야 하기 때문이다. 

새로운 데이터 구조를 생성하기 전에 데이터 카탈로그, API 포털, 마스터 데이터 소스를 검토해야 한다. 또 새로운 데이터 구조가 필요하다면 개발팀은 데이터 모델링 툴을 사용해야 하고 예외 없이 데이터 거버넌스 표준을 준수해야 한다. 

정리하자면, CIO와 리더는 혁신, 속도, 우수한 사용자 경험은 물론이고 비즈니스 과제를 해결하는 데 열정적인 개발팀을 원한다. 그러면서도 안정성, 성능, 효율, 확장성, 보안을 비롯해 장기간 유지 관리할 수 있는 애플리케이션도 원한다. 

이들은 상호 배타적인 목표가 아니다. 그러나 실질적으로 모든 릴리즈, 스프린트, 사용자 스토리마다 절충은 불가피하다. 따라서 IT 조직은 엔지니어링 원칙을 정의하고 이를 개발 프로세스의 일환으로 어떻게 실행할 것인지 논의해야 한다. ciokr@idg.co.kr
 

X