개발자
“100% 해결책은 없다” 기술 부채의 과제와 해법
기술 부채는 소프트웨어가 제대로 완성되지 않았거나 기술적으로 부실하게 구현된 경우, 기업이 금전 또는 노동으로 지불해야 하는 비용이다. 이상적인 경우 기술 부채는 간단한 계산과 가능한 장단점 평가 이후 우선순위화의 형태로 수락된다. 그러나 부정적인 변형도 있는데, 이른바 ‘안티 패턴’이다. 이 경우 기술 부채는 개발 프로세스에서 전문성의 부재로 인한 결과이며, 따라서 확실하게 부정적이다. 소프트웨어 AG(Software AG)는 이 주제를 좀 더 집중적으로 파고들었다. 소프트웨어 AG는 기술 부채를 소프트웨어가 이미 운영에 돌입한 이후 소프트웨어팀이 디지털 시스템에서 시급하게 수행해야 하는 부가적인 작업으로 정의한다. 이는 기술 부채가 긍정적이거나 부정적인 것이 아니라 단순히 민첩한 작업을 위한 조건임을 의미한다. 기술 부채가 발생하는 경로는 그 부채가 좋은 부채인지 나쁜 부채인지 여부에 큰 영향을 미친다. 긍정적 기술 부채, 부정적 기술 부채 예를 들어, 80%만 완성된 최소 기능 제품(Minimum Viable Product, MVP)에서 비롯되는 기술 부채는 긍정적일 수 있다. 다만 기업은 누락된 20%를 의식하고 이를 어떻게 처리할지를 결정해야 한다. 반면 예를 들어 개발 과정의 실패로 인해 발생하는 의도하지 않은 기술 부채는 대체로 부정적이다. 따라서 지나치게 자주 발생해서는 안 된다. 변화하는 환경 또는 주변 조건의 결과로 장기간에 걸쳐 축적되는 기술 부채도 있다. 예를 들어, 바뀐 규정 조항이나 기술 표준을 충족해야 하는 경우 또는 기업이 인수합병, 새로운 기업 형식 등으로 인해 구조를 바꿔야 하는 경우가 여기에 해당된다. 비즈니스의 변화 속도가 빠를수록 이 부채 문제도 커져서 IT 운영에 지장을 초래할 수 있다. 좋은 부채와 나쁜 부채는 디지털 우선 기업에서 일반적인 현상이다. 소프트웨어 AG의 조사에 따르면, 기업 4곳 중 3곳에서 작년 한 해 동안 누적된 기술 부채가...
기술부채
데이터마이닝
디지털트랜스포메이션
지속 테스트와 머신러닝에 합성 데이터를 적극 활용하는 방법
데브옵스 팀의 목적은 배치 회수를 늘리고 프로덕션 단계에서 발견되는 결함 개수를 줄이는 동시에 마이크로서비스와 고객 대면 애플리케이션에서부터 직원 워크플로우와 비즈니스 프로세스 자동화에 이르는 모든 것의 안정성/신뢰성을 높이는 것이다. CI/CD(지속적 통합과 지속적 배포) 파이프라인을 구현할 경우 애플리케이션과 서비스를 원활하게 구축하고 배치할 수 있다. 또한, 테스트를 자동화하고 지속 테스트 관행을 도입하면 각 팀이 품질과 신뢰성, 성능을 관리하는 데 도움이 된다. 지속 테스트가 실시되면 애자일 개발팀은 테스트를 조기에 실시할 수 있고 테스트 사례의 개수와 테스트 속도를 늘릴 수 있다. 단, 테스트 사례를 구축하여 자동화하는 것과 적정한 개수의 사용례와 경계 시나리오를 검증하기에 충분한 용량과 다양성을 갖춘 테스트 데이터를 확보하는 것은 별개의 문제다. 예를 들어, 웹사이트 등록 양식을 테스트할 때는 누락된 데이터, 긴 데이터 입력값, 특수 문자, 다국어 입력값 등 다양한 입력 패턴의 조합을 검증해야 한다. 문제는 테스트 데이터를 생성하는 것인데 합성 데이터 생성이 대안이 될 수 있다. 합성 데이터 생성이란 다양한 패턴을 활용하여 모델과 입력 패턴을 바탕으로 데이터 집합을 추정하는 방식이다. 필요한 데이터 종류와 용량을 맞출 수 있고 실제 데이터 사용 시의 법적 문제나 기타 규정 준수 문제 있는 경우에도 활용할 수 있다는 것이 장점이다. 액셀라리오(Accelario) 공동 창업주 겸 CTO 로만 골로드는 “합성 데이터는 필요한 데이터가 존재하지 않거나 원래의 데이터 집합이 개인 식별 정보로 가득 차 있을 때 활용하면 매우 좋다”라면서 “기존 테스트 데이터 관리용 스키마를 기반으로 합성 데이터를 생성하거나 BI, AI 등의 분석을 통해 실행 가능한 결과를 얻는 규칙을 만드는 방식이 가장 좋다. 두 경우 모두 변화하는 비즈니스 요건에 따라 합성 데이터 생성 자동화가 세밀하게 조정 가능해야 한다”라고 강조했다. 합성 데이터 생성...
머신러닝
합성데이터
CI/CD
IDG 블로그 | “과유불급” 서비스 중심 클라우드 개발의 함정
서비스 지향 개발은 사람들이 알고 있는 것보다 오래된 주제다. 물론 마이크로서비스 같은 것은 비교적 최신 트렌드이지만, 개발자들은 오랫동안 애플리케이션과 오케스트레이션을 구축하는 데 여러 서비스를 사용해 왔다. 직접 개발하지 않은 기존 서비스는 물론 직접 개발한 새로운 서비스도 사용했다. 이런 서비스를 마이크로서비스라고 부르든, 아니면 세밀화된 서비스나 유틸리티 서비스, 공통 애플리케이션 API라고 부르든 상관없다. 서비스를 이용한다는 것은 보통 서비스 지향 아키텍처를 사용한다는 의미이다. 즉, 새로운 컴포넌트 또는 기존 컴포넌트를 이용해 애플리케이션을 구축하는 데만 집중한다는 것이다. 기술적으로는 단일 애플리케이션 내에서 사용할 수 있는 서비스 수와 해당 서비스의 역할을 제한하는 경우가 많다. 과거에는 자잘한 서비스를 너무 많이 사용하는 것이 성능 문제를 일으키기도 했기 때문이다. 자잘한 서비스란 예를 들어, 데이터베이스를 특정 데이터 종류로 업데이트하는 것만 수행하는 별도의 서비스와 같은 것이고, 이런 서비스를 같은 애플리케이션 내에서 너무 자주 사용하는 것이 문제의 소지가 되는 것이다. 요즘에는 저렴한 컴퓨팅과 네트워킹, 스토리지로 이런 문제를 떠넘기기 때문에 성능 문제를 숨길 수 있다. 비효율성은 여전하지만, 성능 문제를 지워버릴 수 있는 첨단 애플리케이션 처리 성능으로 추상화되어 버린다. 따라서 할 수만 있다면, 서비스를 사용하는 것은 이제 아무런 문제가 되지 않는다. 그보다는 얼마나 많은 서비스를 사용할 것인지, 처음부터 서비스를 사용해야만 하는지가 문제가 된다. 필자가 흔히 보는 서비스 과용은 주로 마이크로서비스와 관련된 것으로, 애플리케이션이 너무 복잡해질 정도이다. 이렇게 너무 많은 서비스를 사용하면, 핵심 개발자의 원래 의도가 무엇인지를 해독할 수 없게 된다. 마찬가지로 흔한 일은 애플리케이션의 단 한 가지 측면이 서비스로 탈출하는 것이다. 해당 서비스는 처리 과정 동안 단 한 번 사용되고 다른 애플리케이션도 사용하지 않...
마이크로서비스
복잡성
SOA
아르고 CD에서 고위험 취약점 발견 “헬름 차트 악용”
사이버 공격자가 소프트웨어의 기밀 정보를 탈취할 수 있는 고위험 취약점이 아르고 CD(Argo CD)에서 발견됐다. 아르고 CD는 쿠버네티스로 배포되는 애플리케이션을 위한 CD(Continuous Delivery) 플랫폼이다. 해당 취약점은 현재 수정된 상태다. 아르고 CD 취약점을 발견한 보안업체 아피로(Apiiro) 연구팀에 따르면, 공격자는 악의적으로 조작된 쿠버네티스 애플리케이션 배포 구성 파일을 아르고에 공급해 중앙 리포지토리 서버의 파일과 환경설정, 비밀 토큰을 노출시킬 수 있었다. 이 경우 권한 상승 및 기업의 클라우드 인프라로 측면 이동이 발생할 수 있다. 아르고 CD는 쿠버네티스 환경에서 사용되는 오픈소스 선언형 깃옵스(GitOps) CD 툴이다. 개발자는 아르고를 사용해 중앙 Git 리포지토리 서버에 배포된 애플리케이션을 코드의 다른 상태와 동기화할 수 있다. 설명문에 따르면, 아르고 CD는 특정한 목표 환경에서 원하는 상태의 애플리케이션 배포를 자동화한다. 애플리케이션 배포는 Git 커밋에서 브랜치, 태그 또는 특정 버전의 매니페스트에 대한 업데이트를 추적할 수 있다. 아르고는 배포된 애플리케이션의 상태를 지속해서 모니터링하고 라이브 상태를 Git 리포지토리에서 원하는 상태와 비교하는 쿠버네티스 컨트롤러와 같다. 애플리케이션이 원하는 상태를 벗어나면 ‘동기화 해제’로 플래그를 지정하며, 다양한 수정 옵션을 자동 또는 수동으로 설정할 수 있다. 아르고는 다른 툴을 통한 애플리케이션 배포 정의도 지원한다. 지원하는 툴은 다양한 쿠버네티스 구성요소를 정의하는 도구인 커스터마이즈(Kustomize), 쿠버네티스 매니페스트의 작성/공유/배포를 위한 프레임워크인 케이소네트(Ksonnet), JSON의 확장이자 데이터 템플릿 정의에 사용하는 구글의 구성 언어 제이소네트(Jsonnet), 평문 YAML/JSON 매니페스트, 쿠버네티스 헬름(Helm) 차트, 그 외 플러그인으로 통합된 모든 사용자 정의 구성 관리 툴까지 다양...
쿠버네티스
아르고CD
헬름
'finalize 메소드 퇴역 이후' 자바 오류를 처리하고 클린업하는 방법
몇 년 간의 무성한 소문 끝에 마침내 자바가 JDK 18에서 finalize 메서드를 퇴역시킬 준비를 하고 있다. JDK 향상 제안(Enhancement Proposal) 421은 finalize를 사용 중단되는 요소로 명시하고, 테스트를 위해 이 메서드를 비활성화하는 것을 허용한다. 기본적으로는 계속 활성화된 상태로 유지되다가 이후 릴리스에서 완전히 제거된다. finalize의 끝이 무엇을 의미하는지, 이제부터는 오류와 리소스 클린업을 어떻게 처리해야 하는지 알아보자. finalize란 무엇인가 finalize가 왜 사라지는지, 그 대신 무엇을 사용해야 하는지를 이해하기 전에 finalize가 무엇인지부터 살펴보자. finalize의 기본적인 개념은 객체가 가비지 수집 대상이 될 때 실행되는 메소드를 객체에 정의할 수 있도록 하는 것이다. 기술적으로 객체는 팬텀 도달 가능(phantom reachable) 상태가 될 때, 즉 JVM에 강하거나 약한 참조가 남아 있지 않을 때 가비지 수집 대상이 된다. 이 시점에서 JVM이 object.finalize() 메서드를 실행하고 애플리케이션별 코드가 I/O 스트림이나 데이터스토어에 대한 핸들과 같은 리소스를 클린업한다는 개념이다. 자바의 루트 Object 클래스에는 equals(), hashCode() 등 다른 메소드와 함께 finalize() 메소드가 있다. 이 메소드의 용도는 모든 자바 프로그램이 만든 모든 단일 객체가 리소스 누출을 방지하기 위한 이 단순한 메커니즘에 참여할 수 있도록 하는 것이다. 예외가 발생하고 다른 클린업 코드가 누락된 경우에도 해당된다. 즉, 객체는 여전히 가비지 수집 대상으로 표시되고 최종적으로는 해당 객체의 finalize 메소드가 호출된다. 문제가 해결된 것이다. 그렇지 않은가? 리소스를 소비하는 객체에서 finalize() 메소드를 오버라이드하기만 하면 된다. finalize 메소드의 문제 거기까지는 개념이다...
finalize
자바
java
‘올 것이 왔다’ 애플, iOS 15.4 베타에 유니버셜 컨트롤 기능 추가
예상대로 애플이 iOS 15.3에 이어 iOS 및 아이패드OS 15.4, 맥OS 12.3의 베타 테스트 버전을 배포했다. iOS 15의 주요 기능인 유니버셜 컨트롤(Universal Control)이 올봄 출시를 앞둔 가운데, 15.4 베타 테스트 버전에서 처음으로 모습을 드러냈다. 베타 테스트를 통해 iOS 15.4에 유니버셜 컨트롤이 정식 배포될 것으로 기대되지만, 지연될 가능성은 여전히 존재한다. iOS 15.4 베타의 새로운 기능 유니버셜 컨트롤 2021년 가을 출시될 예정이었으나 2022년 봄으로 미뤄진 유니버셜 컨트롤이 아이패드OS 15.4에 등장했다. 유니버셜 컨트롤은 키보드와 마우스 하나로 아이패드와 맥, 혹은 맥과 다른 맥을 동시에 사용하는 기능이다. ‘설정 → 일반 → AirPlay 및 Handoff’에서 새로운 마우스 커서 및 키보드 옵션을 확인할 수 있다. 마스크 페이스 ID 안 하는 것보다는 늦게 하는 것이 낫다. iOS 14.5에서는 마스크나 안경 착용 등의 이유로 페이스 ID가 작동하지 않을 때에는 애플워치로 아이폰 잠금을 해제할 수 있다. 하지만 이런 방식은 마스크가 일상이 된 오늘날 애플워치가 없는 사용자에게는 전혀 유용하지 않은 기능이었다. iOS 15.4 베타 테스트 버전에서는 ‘설정 → 페이스 ID 및 암호’에서 ‘마스크와 함께 페이스 ID 사용’을 선택할 수 있다. 이 기능을 활성화하면 시스템은 전체 안면 인식 대신 ‘눈 주변의 고유한 특징’을 기반으로 인증을 한다. 또한 시스템이 얼굴 특징을 제대로 식별할 수 있도록 ‘안경 추가’ 설정도 지원한다. 다만 애플은 전체 안면 인식을 이용해야 페이스 ID가 더 정확하다고 경고했다. 이모지 유니코드 컨소시엄(Unicode Consortium)이 출시한 이모지 버전 14가 iOS 15.4 베타에 반영됐다. 녹아내리는 얼굴, 경례하는 얼굴, 깨문 입술, 항아리, 콩, 엑스레이, 거품과 같은 이모티콘이 새로 추가됐다. 듀얼센스 적응형 트리거 PS5 ...
애플
ios15.4
유니버셜컨트롤
에어테이블 리뷰 | 모든 기준에서 준수한 클라우드 로우코드/노코드 툴
에어테이블(Airtable)은 겉모습은 클라우드에서 사용하는 스프레드시트처럼 보이지만, 실제로는 자체 개발 환경이 있는 클라우드 관계형 데이터베이스에 가깝다. 이것도 지나친 단순화다. 에어테이블에는 프로그래머가 아닌 사용자부터 고급 사용자, 그리고 자바스크립트 프로그래머에 이르기까지 다양한 기술 수준의 사용자가 쓸 수 있는 여러 개발 환경이 포함돼 있다. 에어테이블은 클라우드 기반의 데이터베이스 지향 로우코드/노코드 개발 환경이다. 클라우드 전용 로우코드/노코드 앱 빌더인 아마존 허니코드(Hoenycode), 마이크로소프트 파워 앱스(Power Apps), 구글 클라우드 앱시트(AppSheet) 등 약 400개에 달하는 로우코드/노코드 앱 빌더와 지접 경쟁 관계다. 반면 구글 시트와 같은 기본적인 클라우드 스프레드시트와는 종류가 다른 툴이다. 에어테이블 개념 에어테이블은 기본적으로 스프레드시트 특성을 가진 데이터베이스다. 에어테이블 워크스페이스(Airtable workspace)는 공동 작업자 간에 공유되는 프로젝트 모음으로, 하나 이상의 '베이스(bases)'를 포함한다. 여기서 베이스는 데이터베이스를 의미한다. 각 베이스에는 하나 이상의 테이블이 포함되고 각 테이블에는 레코드(행)와 필드(열)가 포함된다. 에어테이블 테이블의 필드는 동형(homogeneous) 필드다. 관계형 데이터베이스와 같고 NoSQL 데이터베이스와는 다른 점이다. 에어테이블 테이블은 다양한 뷰를 지원한다. 관계형 데이터베이스의 뷰와 달리 데이터의 필터링된 부분집합만이 아니다. 에어테이블 뷰는 레코드 필터와 숨겨진 필드를 허용하는 것 외에 그리드 뷰, 캘린더 뷰, 칸반 뷰, 갤러리 뷰, 간트 뷰, 타임라인 뷰, 양식 뷰 등 다양한 용도의 다양한 형식을 지원한다. 이 글의 뒷부분에서 살펴보겠지만 에어테이블은 공식, 자동화, 앱도 지원한다. 에어테이블은 30개 이상의 다른 제품과 통합할 수 있다. 또한 재피어(Zapier), 워카토(Workato), 인테그로매트(Integ...
에어테이블
Airtable
로우코드
데브섹옵스팀에 카오스 엔지니어링이 꼭 필요한 이유
‘카오스(chaos)’와 ‘엔지니어링’이라는 단어는 보통 잘 어울리지 않는다. 훌륭한 엔지니어는 결과적으로 혼란(chaos)스러운 상황을 멀리하기 때문이다. 그러나 최근에는 여러 소프트웨어 개발자가 숨겨진 결함을 드러냄으로써 컴퓨터 시스템을 강화하기 위해 적당한 수준의 ‘카오스’를 사용한다. 카오스 특성상 결과가 보장되지는 않으므로 완벽한 방법은 아니지만, 의외로 효과적인 경우가 많다. 카오스 엔지니어링은 문서화되지 않고 예측할 수 없는 백도어를 찾아야 하는 보안 애널리스트에게 특히 유용하다. 카오스 테스트로 모든 보안 문제를 찾을 수는 없지만, 개발자가 생각하지 못한 패치하지 않은 위험한 취약점을 발견할 수 있다. 좋은 카오스 엔지니어링은 데브섹옵스팀과 데브옵스팀에 모두 도움이 된다. 안정성 또는 탄력성 문제가 곧 보안 문제로 이어지는 경우도 있고, 동일한 코딩 실수가 전체 시스템 중단이나 사이버 공격자의 침입으로 이어질 수 있어서다. 카오스 엔지니어링이란? ‘카오스 엔지니어링’은 성공적인 결과가 입증된 여러 기법을 통칭하는 신조어다. 컴퓨터 시스템을 비틀어 균형을 무너뜨리고 멈추게 만들기도 하므로 ‘퍼징(fuzzing)’이나 ‘글리칭(glitching)’이라는 용어를 사용하기도 한다. 카오스 엔지니어링은 소프트웨어에 스트레스를 가하는 무작위 행동을 주입한 후 오작동이나 버그가 나타나는지 주의 깊게 관찰하는 방법이다. 정상적인 사용 환경에서는 발견까지 몇 년이 걸리는 문제를 카오스 엔지니어링으로 비교적 짧은 시간 안에 발견하는 경우가 많다. EFF(Electronic Freedom Foundation) 공동 설립자 존 길모어는 “코딩은 지속적인 개선 과정이며 카오스 엔지니어링은 가능한 모든 실행 경로를 찾는 속도를 높이는 대표적인 방법이다. 오랜 기간 실행되는 코드는 해당 코드를 처음 실행하는 1,000만 명의 사용자, 코드를 처음 컴파일하는 20개의 컴파일러, 그리고 코드를 처음 실행하는 5개의 운영체제를 통해 대부분의 버그...
카오스엔지니어링
취약점발견
개발
VM웨어, 개발자 생산성 높이는 ‘탄주 애플리케이션 플랫폼’ 정식 출시
VM웨어가 모든 쿠버네티스 상에서 손쉬운 애플리케이션 개발, 배포, 관리를 지원하는 ‘VM웨어 탄주 애플리케이션 플랫폼(VMware Tanzu Application Platform)’을 정식 출시한다. VM웨어 탄주 애플리케이션 플랫폼은 개발자 경험 및 생산성을 향상시켜 기업이 애플리케이션 개발에서 생산까지 일련의 과정에서 좀 더 안정적인 소프트웨어 공급망을 확보할 수 있도록 지원한다. VM웨어 탄주 애플리케이션 플랫폼은 애플리케이션 중심의 모듈화된 플랫폼으로, 다양한 개발자 도구와 기 검증된 경로를 제공해 개발자가 소프트웨어를 여러 퍼블릭 클라우드나 온프레미스 쿠버네티스 클러스터에 신속하게 구축, 제공할 수 있도록 지원한다. 쿠버네티스 추상화 레이어를 통해 셀프 서비스 기반의 한층 빠르고 안전한 앱 개발 및 제공을 지원함으로써 개발자 생산성과 사용자 경험을 모두 끌어올릴 수 있도록 설계됐다. VM웨어 탄주 애플리케이션 플랫폼은 ▲개발자 경험 향상 ▲공급망 커스터마이즈 ▲생산까지의 과정 가속화 등의 이점을 제공한다. 클라우드 네이티브 패턴에 최적화된 VM웨어 탄주 템플릿을 활용해 첫 앱 개발에 도달하기까지 빠르게 접근할 수 있으며, 하나의 관리 포털에서 서비스와 API를 함께 확인할 수 있는 일관된 인터페이스를 제공한다. 구성요소가 미리 탑재돼 개시와 동시에 사용할 수 있는 엔드투엔드 소프트웨어 공급망을 제공해 애플리케이션 개발 프로세스를 자동화하며, VM웨어 탄주의 서플라이 체인 코레오그래퍼(Supply Chain Choreographer)를 통해 사전 승인된 생산 경로를 활용할 수 있을 뿐 아니라, 이를 사업별 니즈에 맞춰 손쉽게 커스터마이즈가 가능하다. 개발자가 코딩을 완료하면 자동으로 안전한 소프트웨어 공급망을 가동한다. 개발부터 생산까지의 과정이 빠르고 매끄럽게 이어져 데브섹옵스(DevSecOps)간 애플리케이션 전환으로 인한 마찰을 줄인다. 한편, VM웨어 코...
VM웨어
글로벌 칼럼 | 컨테이너 기반 통합 테스트의 이점
완벽한 소프트웨어를 가진 행성이 어딘가에 있을 수 있지만, 구글의 오픈소스 책임자 크리스 디보나의 말처럼 우리가 사는 행성은 그런 행성이 아니다. 따라서 개발자에게는 2가지 길이 있다. 소프트웨어를 신중하고 엄격하게 테스트해 발생할 수 있는 모든 문제를 배포 전에 찾아내거나, 테스트를 줄이고 배포 속도를 높여 프로덕션 환경에서의 오류를 감내하는 것이다. 전자는 의료 및 금융 같은 규제 산업에서 일하는 개발자가 주로 택하는 길이며, 후자는 “개발한 사람이 운영까지 한다(You build it, you run it)”라는 AWS CTO 베르너 보겔스의 유명한 격언에 동의하는 개발자가 선택하는 길이다. 이처럼 소프트웨어 테스트와 배포 속도 사이의 균형은 개발자의 생산성과 관련한 대표적인 논쟁거리다. 테스트 어느 단계에 있든, 소프트웨어 테스트를 위한 단일화된 솔루션은 없다. 때문에 개발자는 변화하는 요구사항에 맞춰 올바른 테스트 방법을 지속해서 모색해야 한다. 동시에 개발자는 사용할 테스트 방법을 습관으로 만들기 위해 느리거나 복잡하지 않으면서 주요 문제를 해결하는 가장 효율적인 방식을 찾아야 한다. 최근 필자는 ‘유닛 테스트’에서 효율적인 방식을 발견했다. 유닛 테스트는 독립적으로 진행하는 가장 작은 단위의 소프트웨어 테스트다. 소프트웨어가 의도에 따라 동작하는지 확인할 수 있을 뿐 아니라 다른 개발자가 작성한 코드 베이스의 일부를 추론할 수도 있다. 유닛 테스트는 오래 전부터 사용하던 방법이지만, 최근 들어 자동화가 사용자 경험을 실제 사용성까지 단순화하면서 깊숙이 자리 잡았다. 유닛 테스트와 유사한 다른 형태의 테스트 방법도 있다. 수십 년 동안 개발 중인 방법이지만, 이제서야 본질적인 문제를 해결하고 단순화된 접근에 적절한 추상화 수준을 제공하며 효율적인 방식을 찾아가고 있는 ‘통합 테스트’다. 개발자의 역할은 ‘조립’에 있다 전통적인 3계층 아키텍처 시스템은 데이터베이스 1개와 상호작용할 수 있는 API를 1...
컨테이너
도커
통합테스트
애자일 업무 역량 계획을 세울 때 던져야 할 5가지 질문
애자일 매니페스토는 ‘프로세스와 툴보다 개인과 상호작용’에 더 가치를 둔다. 창안자의 핵심 원칙은 “최선의 아키텍처와 요구사항 및 설계는 자기조직화(self-organizing)가 된 팀에서 나온다”는 것이다. 필자도 이 원칙에 동의하지만, 실제 환경에서 자기조직화 팀이 어떻게 움직여야 하고, 최선의 결과를 달성하는 과정에서 의사결정 권한이 얼마나 도움이 되는지에 관해서는 실용적인 관점으로 접근해야 한다. 예를 들어 팀이 이상적인 아키텍처를 선택해 설계할 권한을 얻는다면 성과도 최적화되겠지만, 20개에 달하는 팀이 모두 각각 독립적인 아키텍처를 관리한다면 조직 관점에서는 상당한 골칫거리다. 또한, 프로세스와 툴이 더욱 개인과 원활하게 상호작용할 필요도 있다. 백로그 상태를 캡처하고 사용자 스토리를 표준으로 범주화하며 아키텍처를 문서화하면 팀 상호작용을 개선하고 회의에 소비하는 시간을 줄이는 데 도움이 된다. 애자일 자기조직화 팀에는 업무 역량 계획이 필요 애자일 업무 역량 계획은 많은 애자일 팀에서 기피하는 영역이다. 업무 역량 계획은 사람마다 생각하는 뜻이 다르므로 업무 역량 분석을 요청하거나 기술 공백 계획을 수립할 때는 맥락이 필요하다. 또한 업무 역량 계획 방법은 프로그램 관리 및 시스템 엔지니어링 분야에서 처음 개발됐는데, 이 분야는 애자일과 반대되는 영역으로 인식되는 경우도 있음을 생각해야 한다. 난점은 조달, 온보딩, 통합에 리드 시간이 필요하기 때문에 인력, 기술, 파트너십 등 애자일 팀에 필요한 요소 상당수에 사전 예측이 필요하다는 것이다. 애자일 리더는 업무 역량 계획을 생산성을 개선하고 무력감을 방지하고 데브옵스 투자에 대한 지지를 얻고 목표를 가로막는 장애물을 줄일 기회로 생각해야 한다. 그 외의 시간에는 애자일 팀은 비즈니스 관계자와 파트너가 되어 예정된 결과물에 대한 시야를 제공해야 한다. 팀의 속도와 생산성에 영향을 미칠 수 있다는 면에서 업무 역량 계획도&n...
애자일
CI/CD
프로세스최적화
“해결 방법 없다” 구글이 본 제로클릭 공격의 위험
모바일 보안과 관련해 사용자는 항상 의심스러운 링크나 이메일, 첨부파일을 피하며 각별한 주의를 기울여야 한다. 하지만 제로클릭(zero-click) 사이버 공격이 늘어나면서 이런 노력이 무력해지고 있다. 지난 12월 구글은 대표적인 제로클릭 사이버 공격인 페가수스(Pegasus)의 작동 방법을 연구한 결과를 발표했다. 페가수스 스파이웨어는 언론인과 세계 지도자를 해킹하기 위해 이스라엘 보안업체 NSO 그룹이 사용한 것으로 알려졌다. 구글 프로젝트 제로(Project Zero) 팀은 “지금까지 확인한 사이버 공격 가운데 기술적으로 가장 정교했으며, NSO의 기술이 일부 국가에서만 접근할 수 있다고 여겨진 기술에 필적한다는 것을 보여준다”라고 말했다. 구글의 연구결과에서 가장 놀라운 점은 페가수스가 보안 알람의 불문율, 즉 ‘효과적인 방어책이 없는 공격은 그 세부사항을 보고하는 것이 차선책’이라는 규칙을 깨뜨렸다는 점이다. 구글은 업계가 제로클릭 공격에 대한 방어책을 신속하게 마련할 수 있도록 세부 논의가 필요하다고 강조했다. 구글은 “NSO가 개발한 제로클릭 공격 기술은 어떠한 상호작용도 필요 없다. 따라서 평소에 피싱 링크를 클릭하지 않는, 기술에 능숙한 사람도 공격 대상이 되었다는 점을 모른다. 공격자는 피싱 메시지를 전송하지 않고 휴대폰 백그라운드에서 조용히 공격을 진행한다. 기기를 사용하지 않는 것 외에는 예방 방법이 없다. 방어할 수 없는 무기인 셈이다”라고 설명했다. 공격 수단은 ‘가짜 GIF’ 페가수스 공격의 배후로 알려진 NSO는 가짜 GIF로 코어그래픽스 PDF(CoreGraphics PDF) 파서의 취약점을 겨냥했다. 가짜 GIF는 확장자가 .gif이지만 실제로는 GIF 이미지 파일이 아니다. 파일명과 확장자는 사용자를 안심시키는 수단에 불과했다. ImageIO 라이브러리는 파일 확장자에 상관없이 소스 파일의 올바른 형식을 추측하고 구문을 분석하는 데 사용된다. 이를 가짜 GIF에 적용하면 20개 이상의 이미지 코덱...
NSO
페가수스
스파이웨어
파이썬, 티오베 지수 선정 2021년 '올해의 언어'
파이썬이 2년 연속으로 티오베 지수가 뽑은 2021년의 프로그래밍 언어로 선정되었다. 티오베 지수는 평점이나 선호도에 기반해 순위를 결정한다. 파이썬의 선호도는 2020년보다 1.86% 올라 2021년 연말 기준으로 티오베 인덱스 13.58%로 집계됐다. 아직 2001년 자바가 기록한 전체 최고 기록인 26.49%와는 거리가 있다. 티오베는 C#이 연중 내내 우세했지만 12월에 파이썬이 C#를 제쳤다고 밝혔다. 데이터 과학, 데브옵스, 웹 개발의 기본 요소가 된 파이썬은 현재도 티오베 순위 1위를 달리고 있다. 2021년 초에는 3위였다가 10월에 1위에 올랐다. 티오베 지수는 검색 엔진을 통해 전 세계의 숙련 엔지니어 수나 코스, 언어와 관련된 서드파티 업체를 기반으로 언어 인기도를 평가한다. 그 외 스위프트, 고, 러스트, 코틀린이 상승세에 있다고 발표했다. 2022년 1월 티오베 지수 상위 10개 언어는 다음과 같다. 1. 파이썬, 13.58% 2. C, 12.44% 3. 자바, 10.66% 4. C++, 8.29% 5. C#, 5.68% 6. 비주얼 베이직, 4.74% 7. 자바스크립트, 2.09% 8. 어셈블리, 1.85% 9. SQL, 1.8% 10. 스위프트, 1.41% 파이썬은 구글에서 언어 튜토리얼 검색 빈도를 분석하는 Pypl 프로그래밍 언어 선호도 지수에서도 1위를 차지했다. 2022년 Pypl 상위 10개 언어 순위는 다음과 같다. 1. 파이썬, 28.74% 2. 자바, 18.01% 3. 자바스크립트, 9.07% 4. ...
파이썬
스위프트
자바
가상 화이트보드, 원격 개발팀의 필수 툴로 부상
지난 2년 동안 전 세계적으로 재택근무가 보편화되고 팀이 더 분산되어 운영되기 시작하면서 나타난 소프트웨어 개발자들의 한 가지 공통적인 불만은 제대로 된 화이트보드의 원격 대안이 없다는 점이다. 구직 면접 중의 화이트보드 테스트든, 기숙사 창문에 붙어 있었다던 마크 저커버그와 에두아르도 세버린의 원본 페이스북 알고리즘 메모든, 화이토브드는 오래 전부터 개발자가 설계 및 운용 중인 복잡한 시스템을 이해하고 설명하기 위한 중요한 툴로 사용되고 있다. 개발자 팀이 갈수록 더 분산되고 원격화되고 비동기화되는 지금, 가상 화이트보드가 기술 문제 공동 대처와 교육 세션, 면접을 위한 핵심 툴이 되고 있다. 전체적인 시야 얻기 완전히 분산된 자동화 소프트웨어 기업 재피어(Zapier)의 엔지니어링 관리자인 제빈 맬타이스는 “엔지니어에게 화이트보드는 애플리케이션의 다양한 조각을 시각화하기 위한 강력한 툴”이라면서 “기술 솔루션 개발에는 다양한 시스템 부분 간에 많은 상호작용과 커뮤니케이션이 따르는데, 화이트보드는 이를 시각화하는 좋은 방법”이라고 말했다. 소프트웨어 개발 에이전시 크리마(Crema)는 인기 있는 화이트보드 툴인 미로(Miro)를 4년 전부터 사용했는데, 팬데믹 중에 이 툴의 사용량이 크게 증가했다. 크리마의 선임 애플리케이션 개발자 닐 다이어캐츠는 “프로젝트 계획, 기술 계획, 문제 해결을 위한 화이트보드가 사무실의 모든 곳에서 사용된다”고 말했다. 현재 작업의 대부분은 미로 내에서 수행되고 저장된다. 다이어캐츠는 “전체적인 아키텍처와 현재 필요한 것과 써드 파티 API를 파악할 수 있는 전체적인 시야는 모두에게 유용하다”고 덧붙였다. 크리마의 애플리케이션 개발자 렉스 샌더스는 입사 초기 견습 사원 시절에 미로가 상당히 유용했다면서 “화이트보드에서 멘토들과 함께 작업하면서 많은 시간을 보냈다”고 말했다. 그러나 물리적 화이트보드에서 가상 ...
화이트보드
팬데믹
재택근무
커리어 로드맵 | ‘연결성이 핵심’ 인프라 소프트웨어 관리자
IT 분야에 ‘인프라 소프트웨어 관리자’는 흔하지 않다. 그러나 거의 모든 비즈니스에서 소프트웨어가 중요해지고 있다는 점을 감안하면, 인프라 소프트웨어 관리자가 아주 중요한 책임과 역할을 맡은 것은 분명하다. 디지털 트랜스포메이션을 시작하는 기업이라면 인프라 소프트웨어 관리자의 역할이 더욱 중요하다. 인프라 소프트웨어는 비즈니스 거래, 내부 서비스, 인력 지원 등 기업의 일상 업무에 도움을 준다. ERP(Enterprise Resource Planning), 이메일, 데이터베이스, 방화벽 같은 보안 도구가 대표적이다. 인프라 소프트웨어 관리자가 되기 위해서는 무엇을 갖추어야 할까? 온라인 자동차 마켓플레이스 카구루스(CarGurus)에서 인프라 소프트웨어 관리자 직책을 맡은 톰 러스티에게 조언을 구했다. 학업과 교육 러스티는 어린 시절부터 기술 분야에 관심을 가졌다고 봐도 무방하다. 러스티는 “어렸을 때는 레고를 갖고 놀고 무언가 만드는 것을 좋아했다. 집에 고장이 나서 버려야 하는 물건이 있으면 분해해서 어떻게 작동하는지 살펴보곤 했다”라고 말했다. 이런 성향은 직업 선택에도 반영됐다. 러스티는 경력 전반에 걸쳐 새로운 기술과 도구를 대상으로 무언가를 만드는 업무를 맡았다. 러스티는 “문제를 해결할 때 항상 창의적이고 열린 마음으로 접근하려고 시도하며, 무언가의 작동 방식에 호기심을 가지는 편이다”라고 설명했다. 고등학교 시절 러스티는 뒤늦게 컴퓨터와 관련된 일을 하고 싶다고 생각했지만, 구체적으로 어떤 분야를 선택해야 하는지는 몰랐다. 러스티는 여러 대학 학부의 컴퓨터 과학 프로그램을 알아봤고, 많은 프로그램이 수학을 중요시한다는 것을 깨닫고는 의기소침했다. 수학이 강점이었던 적이 없었기 때문이다. 러스티는 온라인 게임에서 만나 지금껏 우정을 이어오고 있는 오랜 친구 덕분에 로체스터 공대((Rochester Institute of Technology, RIT)를 알게 됐다. RIT는 다양한 컴퓨터 관련 전공을 운영했고, 러스...
커리어로드맵
소프트웨어관리자
올바른 데이터 아키텍처를 구축하는 5가지 원칙
견고한 아키텍처를 설계하는 것은 최신 애플리케이션 구축에 있어서 가장 어렵지만, 가장 중요한 부분이기도 하다. 합리적인 데이터 아키텍처를 만들지 못하면 애플리케이션에 많은 문제가 발생한다. 성능이나 데이터 무결성, 데이터 주권 및 안전, 확장성 문제가 대표적이다. 데이터 아키텍처가 부실하면 애플리케이션은 물론 이를 사용하는 기업까지 부실해진다. 적절한 데이터 아키텍처 구축은 모든 최신 아키텍처를 오래 안정적으로 운영하는 데 필수적이다. 애플리케이션 현대화 작업에 도움이 되는 데이터 아키텍처 설계(혹은 재설계) 원칙 5가지를 소개한다. 1. 적절한 종류의 데이터베이스를 사용할 것 데이터 아키텍처 설계에서 가장 중요한 것은 데이터 저장 및 접근에 필요한 데이터베이스의 종류를 파악하는 것이다. 사용해야 할 데이터베이스 종류를 결정하려면 다음과 같은 사항을 고려해야 한다. 저장할 데이터가 고도로 구조화된 데이터인가, 단순 키 값 데이터인가? 데이터 유지 기간이 영구적인가, 일시적인가? 데이터 접근이 무작위인가, 순차적인가? 고정 스키마나 유연 스키마를 사용하는가, 단순 플랫 파일인가? SQL 질의를 지원하는 관계형 데이터베이스를 사용해야 하는가? 답변에 따라 SQL 데이터베이스, 단순 키 값 저장소, 메모리 상주 캐시, 단순 개체 저장소, 혹은 고도로 구조화된 데이터 저장소를 선택할 수 있다. 선택한 데이터베이스 종류에 따라 데이터베이스의 궁극적인 기능과 해당 애플리케이션 사용례에서의 성능 수준이 결정된다. 확장성이나 가용성처럼 애플리케이션에 필수 불가결한 요소는 데이터베이스 종류에 따라 크게 달라진다. 2. 데이터를 적절한 장소에 저장할 것 ‘데이터를 어디에 저장해야 하는가’라는 질문은 매우 단순하지만 중요하다. 데이터 저장 장소는 데이터와 애플리케이션에 따라 프론트엔드에 위치할 수도, 백엔드에 위치할 수도 있다. 또한 사용자가 로컬에 저장할 데이터와 최대한 많은...
데이터아키텍처
커리어 로드맵 | '속도 중심 세계에 더욱 필요한' 데브옵스 엔지니어
개발 수명 주기를 줄이고 고품질 소프트웨어를 지속적으로 제공하는 관행이자 근본적으로는 소프트웨어 개발과 IT 운영을 결합하는 문화인 데브옵스(DevOps)의 인기가 갈수록 높다. 개발과 데브옵스를 언급한 IDC 2020년 10대 예측 보고서는 조직 내부 운영 방식과 수용 기술을 근본적으로 재고하고 혁신해야 한다는 압박이 증가했다고 주장했다. 이 보고서는 인공지능이나 머신러닝 같은 기술과 데브옵스 도구를 채택하지 않는 조직은 향후 경쟁적 열세에 처하게 될 것이라고 추측했다. 시장 조사업체인 인더스트리ARC(IndustryARC)는 최근 보고서에서 2020~2025년 사이에 전 세계 데브옵스 시장의 연평균 성장률(CAGR)이 25%에 달했고, 2025년에는 규모가 최대 125억달러에 달할 것으로 전망했다. 보고서에 따르면, 더 빠른 애플리케이션 제공, 기업의 생산성 향상, IT 분야에서의 불필요한 자본 지출 제거에 대한 필요성이 높아지면서 시장은 계속 가속화될 것으로 기대된다. 소프트웨어 업그레이드를 빠르게 해야 할 팔요성은 전 세계 모든 산업에서 큰 비중을 차지한다. 데브옵스의 성장과 함께 소프트웨어 개발자, 시스템 운영자 등과 협력하는 IT 전문가, 데브옵스 엔지니어에 대한 수요도 증가한다. 이들은 통합 및 배포 프로세스를 자동화하고 간소화함으로써 운영, 개발 및 테스트 기능이 더욱 매끄럽게 조정하는 역할을 담당한다. 데브옵스 엔지니어는 사내에서든, 클라우드에서든, 소프트웨어 코드 개발을 지원하는 IT 인프라를 관리하는 방법에 익숙해져야 한다. 리소스 프로비저닝, 올바른 배포 모델 선택, 릴리스 검증을 위한 테스트 프로세스 지시 등이 이들의 업무다. 데브옵스 엔지니어는 데이터 준비 테스트, 결과 분석, 데브옵스에서 발생하는 문제 해결 및 소프트웨어 개발자와 긴밀히 협력하는 데에도 관여할 수 있다. 데브옵스 엔지니어라는 직위는 다양한 기술을 필요로 한다. 일반적으로 소프트웨어 개발 언어의 본질에 대한 이해, 운영체제 관리, 인프라 자동...
데브옵스
데브옵스엔지니어
개발자
추천기사
