테크놀로지 리더를 위한 글로벌 IT 뉴스 - ITWorld Korea

Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

톱뉴스 | 많이 본 뉴스 | 토픽 브리핑

1/3

테크라이브러리

“블록체인으로 디지털 속 ‘나’를 인증하다” 탈중앙화 신원인증(DID)의 이해 - Tech Report

글로벌 딜리버리 센터 (GDC) 모델을 이용한 한국 기업들의 SAP 인적 자원 부족 문제의 해결

“창의적 코드를 부른다” 최고의 자바스크립트 에디터 10선 - Tech Review

Dell PowerEdge 서버가 최신 워크로드와 새로운 워크로드에 적합한 5가지 이유

넘버스

"원격 근무 및 하이브리드 근무 제도로 팀 사기가 증진됐다"

분산 근무의 딜레마: 혁신과 직업 만족도의 경합 he Distributed Work Dilemma: When Innovation and Job Satisfaction Compete

출처 : VMware, Vanson Bourne

날짜 : 2022년 11월 29일

금융 업계를 노린 애플리케이션 및 API 보안 공격 증가율

게이트 앞의 공격자 : 금융 서비스 사이버 공격 분석 Enemy at the Gates: Analyzing Attacks on Financial Services

출처 : Akamai

날짜 : 2022년 11월 28일

개발자에게 가장 인기 있는 크로스 플랫폼 빌더

2021년 개발자 생태계 현황 The State of Developer Ecosystem 2021

출처 : JetBrains

날짜 : 2021년 07월 15일

2023년 디지털 마케팅 핵심 키워드

디지털 마케팅 트렌드 2023

출처 : 인크로스

날짜 : 2022년 11월 29일

애플리케이션 2일 전

"아는 만큼 빨라진다" 마이SQL 성능 튜닝 팁 10가지

마이SQL은 세계에서 가장 광범위하게 사용되는 오픈소스 데이터베이스이며, 전체 데이터베이스의 인기 순위에서는 (근소한 차이로) 에 올라 있다. 마이SQL은 효과적인 관계형 데이터베이스 관리 시스템으로 오랫동안 인기 있는 애플리케이션의 중심에 위치해왔다. 그러나 사용하기가 까다로울 수 있고 성능을 개선할 수 있는 여지도 많다. 지난 몇 년 동안 몇 가지 중요한 개발도 이뤄졌다. 여기서는 바론 슈와르츠가 쓴 마이SQL 성능 튜닝 팁의 업데이트 내용을 다룬다. 마이SQL 성능 팁 1. 스키마 설계는 다른 어떤 마이SQL 설정 못지않게 중요 스키마 설계는 데이터베이스에 해야 하는 매우 중요한 일 중 하나다. 교차 관계형 데이터베이스 기술 원칙은 1970년대에 표준형이 나왔다. 마이SQL은 버전 5.6에서 기본 스토리지 엔진을 이노DB(InnoDB)로 전환했으므로 스키마 설계는 더욱 중요해졌다. 이유가 무엇일까? 이노DB에서는 모든 것이 기본 키(primary key)다. 이는 이노DB가 데이터를 정리하는 방식과 관련된다. 이노DB에서 기본 키는 군집화되고 모든 보조 키(secondary key)는 기본 키에 엔트리 포인터를 추가한다. 스키마 설계에서 이 부분을 감안하지 않으면 성능 측면에서 불이익을 받게 된다. 데이터는 B-트리 인덱스를 사용해서 저장되므로 데이터를 순서가 정해진 방식으로(즉, 유사 순차 값) 삽입하면 기본 키의 단편화가 방지되고 따라서 리프 노드를 찾는 데 필요한 I/O 작업이 감소한다. 순차 기본 키가 맞지 않는 경우도 있다. 대표적인 예가 범용 고유 식별자(Universally Unique IDentifier), 줄여서 UUID다. UUID와 기본 키에 대한 더 심층적인 내용은 서 볼 수 있다. 대부분 경우에는 순차 기본 키를 사용하는 것이 좋다. 마이SQL 성능 팁 2. 보조 키를 적대시하지 말 것 보조 키는 백그라운드 프로세스에 의해 업데이트되며 성능 영향은 흔히 생각하는 것만큼 크지 않다. 대신 보조 키를 추가하면 스토리지 요구사항이 증가하므로 디스크 사용량 측면의 문제가 있다. 인덱스가 없는 필드에 대한 필터링은 쿼리가 실행될 때마다 전체 테이블 스캔을 유발할 수 있다. 물론 이 경우 막대한 성능 영향이 발생한다. 따라서 보조 키는 없는 것보다는 있는 편이 낫다. 단, 데이터베이스의 과도한 인덱싱은 피해야 한다. 많은 인덱스를 실행해도 원하는 성능 개선을 얻지 못할 수 있기 때문이다. 또한 부가적인 인덱스는 스토리지 비용을 높일 수 있고, 이노DB가 인덱스를 최신 상태로 유지하기 위해 많은 백그라운드 작업을 해야 한다. 마이SQL 성능 팁 3. 인덱스에서 행 제공 가능 에 대한 인덱스를 두는 것이 전체 열에 대한 개별 인덱스를 두는 것보다 낫다. 또한 x, y에 대한 복합 인덱스는 다음 쿼리의 성능도 개선할 수 있다. SELECT y FROM table WHERE x=1 마이SQL은 커버링 인덱스를 사용하고 이 인덱스에서 메모리에 있는 y를 제공한다. 실무에서 복합 인덱스를 사용할 기회가 있으면 사용해 성능을 개선할 수 있다. 인덱스를 설계할 때는 이 인덱스가 읽히는 방식, 즉 항상 왼쪽에서 오른쪽 방향으로 읽힌다는 점을 염두에 둬야 한다. 다음 쿼리를 보자. SELECT a,b,c FROM table WHERE a=1 and b=2 여기서 a, b에 대한 인덱스는 쿼리에 도움이 될 것이다. 그러나 다음과 같은 형식을 보자. SELECT a,b,c FROM table WHERE b=2 인덱스는 쓸모가 없고 전체 테이블 스캔을 유발한다. 항상 왼쪽부터 인덱스를 읽는다는 개념은 일부 다른 사례에도 적용된다. 예를 들어 다음 쿼리를 보자. SELECT a,b,c FROM table WHERE a=1 and c=2 여기에는 열 b에 의한 WHERE 절 필터링이 없으므로 a, b, c에 대한 인덱스는 첫 번째 열만 읽게 된다. 따라서 이 경우 마이SQL은 인덱스를 부분적으로 읽을 수 있고, 이게 전체 테이블 스캔보다는 낫지만 최선의 쿼리 성능을 얻는 측면에서는 여전히 부족하다. 쿼리 설계와 관련된 또 다른 요소는 마이SQL에서 사용되는 일반적인 최적화인 왼쪽 끝 인덱스 접근이다. 예를 들어 a, b, c의 인덱스는 select a,c where c=x와 같은 쿼리에서는 작용하지 않는다. 이 쿼리는 인덱스의 첫 번째 부분, 즉 a, b를 건너뛸 수 없기 때문이다. select c,count(c) where a=x group by c와 같은 쿼리도 마찬가지다. b의 인덱스를 건너뛸 수 없으므로 group by에 대해 a, b, c의 인덱스를 사용할 수 없다. 그러나 select c,count(c) where a=x and b=y group by c와 같은 쿼리가 있고 이 쿼리가 a, b에 대해 필터링을 하고 c에 대해 group by를 수행한다면 a, b, c의 인덱스 하나가 필터링과 group by에 모두 도움이 될 수 있다. 마이SQL 성능 팁 4. 쿼리 검토, 쿼리 검토, 쿼리 검토 포뮬러 원 자동차만으로는 경주에 이길 수 없다. 경험 없는 드라이버에게 운전대를 맡기면 첫 번째 코너에서 충돌해 탈락할 것이다. 마찬가지로, 세계에서 가장 튜닝이 잘 된 마이SQL 서버가 있다 해도 쿼리의 품질이 낮으면 데이터베이스는 원래의 성능을 내지 못한다. 시간이 지나면서 애플리케이션은 새로운 기능과 버그 수정을 거치며 바뀌므로 그에 따라 쿼리 설계도 정기적으로 검토해야 한다. 애플리케이션의 데이터 집합과 사용 패턴도 시간이 지나면서 바뀔 가능성이 높다. 모두 쿼리 성능에 영향을 미칠 수 있는 요소다. 따라서 쿼리를 검토하고 쿼리 실행 시간을 모니터링할 수 있는 시간을 확보하는 것이 매우 중요하다. 느린 쿼리 로그, 또는 성능 스키마를 이 용도로 사용할 수 있지만 모니터링 툴을 구현하면 더 정확한 데이터를 얻을 수 있다. 가장 느린 쿼리가 항상 수정 1순위 쿼리는 아니라는 것을 유념해야 한다. 예를 들어 실행에 30초가 걸리지만 하루에 두 번 실행되는 쿼리와 실행 시간은 1초지만 분당 100번 실행되는 쿼리가 있다면 두 번째 쿼리를 최적화하는 것이 합리적이다. 장기적으로 많은 시간과 리소스를 절약할 수 있기 때문이다. 마이SQL 성능 팁 5. 가시성은 중요하다 모니터링은 성능 튜닝에서 중요한 요소 중 하나다. 현재 워크로드와 패턴을 모르면 구체적인 권장 사항도 도출하기 어렵다. 최근 몇 년 동안 마이SQL에서는 워크로드를 이해하는 데 도움이 될 수 있는 저수준 마이SQL/이노DB 메트릭 노출이 개선됐다. 예를 들어 초기 버전에서는 성능 스키마가 병목 지점이었고 특히 테이블 수가 많은 경우 상당한 영향을 미쳤다. 최근 마이SQL 버전에서는 새로운 데이터 사전과 같은 변경을 통해 성능이 개선됐으며 이제 테이블 수가 많아도 큰 영향이 발생하지 않는다. 최신 모니터링 툴은 대부분 어떤 식으로든 성능 스키마를 사용하므로 이러한 툴을 살펴보고 필요에 가장 잘 맞는 툴을 선택할 것을 권한다. 성능 데이터에 대한 이 가시성은 조사 작업에서 큰 자산이 될 수 있다. 마이SQL 성능 팁 6. 튜닝 툴에는 주의 필요 튜닝 툴이 제공하는 몇몇 일반적인 권장 사항은 대부분의 사용 사례에 적용된다. 그러나 모든 워크로드와 스키마는 제각기 다르다. 튜닝 툴의 일반적인 권장 사항이 적용되지 않는 사례도 있으므로 권장 사항을 무작정 신뢰해서는 안 된다. 오라클 자체 툴이자 마이SQL에서 제공되는 innodb_dedicated_server도 납득하기 어려운 구성 변경이 발생할 수 있다. 예를 들어 innodb_buffer_pool_size를 총 RAM의 75%로 설정하는 것은 일반적으로는 좋은 규칙이다. 그러나 요즘은 수백 기가바이트의 RAM을 탑재한 서버도 흔히 사용된다. RAM 용량이 512GB라면 버퍼 풀 전용으로 설정되지 않는 여유 공간이 128GB에 이르며 이는 상당한 낭비다. 또한, innodb_log_file_size와 innodb_log_files_in_group도 RAM 용량을 기반으로 정의된다. RAM 용량이 128GB를 초과하는 서버에서 이 설정은 각각 2GB인 재실행(redo) 로그 파일을 64개 생성하게 된다. 즉, 128GB의 재실행 로그가 디스크에 저장된다. 아무리 사용량이 많다 해도 대부분의 경우 이렇게까지 대용량의 재실행 로그 파일은 불필요하므로 좋은 권장 사항이 아니다. 반면 innodb_flushing_method는 자동 구성이 활성화된 상태에서 유일하게 적절히 구성되는 값이다. 이 변수는 플러싱 방법을 O_DIRECT_NO_FSYNC로 설정하는데, 이는 데이터 더블 버퍼링을 방지하므로 Ext4 또는 XFS 파일 시스템을 사용할 때 권장되는 방법이다. innodb_buffer_pool_size를 전용 서버의 75% 또는 80%로 설정하는 것이 좋다. RAM 용량이 많은 서버, 즉 128GB 이상인 서버에서는 이 비율을 90%, 또는 적절한 메모리 소비 프로파일링을 통해 이보다 더 높게 설정한다. 마찬가지로 innodb_log_file_size와 innodb_log_files_in_group의 경우 각각 2GB의 두 파일부터 시작해서 쓰기 로그 작업을 모니터링한다. 재실행 로그 크기를 결정할 때는 대략 1시간 분량의 쓰기가 포함되도록 하는 것이 좋다. innodb_flush_method의 경우 Ext4 또는 XFS와 같은 현대 리눅스 파일 시스템에서는 이 옵션을 O_DIRECT 또는 O_DIRECT_NO_FSYNC로 설정해야 한다. 마이SQL 성능 팁 7. I/O 작업은 여전히 고비용 작업 마이SQL과 이노DB는 I/O 작업의 수를 최소화하는 방향으로 동작한다. 스토리지 레이어 액세스는 애플리케이션 성능 측면에서 상당한 부담이 되기 때문이다. 이노DB가 수행하는 I/O 작업의 수에 영향을 미칠 수 있는 몇 가지 설정이 있다. 이 설정 중 두 가지는 빈번하게 잘못 이해되는 데다 변경 시 성능 문제로 이어지는 경우가 많다. innodb_io_capacity 및 innodb_io_capacity_max는 백그라운드에서의 플러싱을 위한 I/O 작업의 수와 관련된 변수다. 많은 사용자가 비교적 낮은 지연으로 매우 높은 I/O 용량을 제공할 수 있는 최신 SSD를 활용하기 위해 이 설정 값을 늘린다. 얼핏 논리적으로 보일 수 있지만 I/O 용량 설정을 늘리면 몇 가지 문제를 유발할 수 있다. 첫째, 이노DB가 더티 페이지를 너무 빨리 플러싱하도록 한다는 점이다. 이로 인해 플러싱되기 전에 두 번 이상 페이지를 수정할 기회가 줄어들고 성능이 저하된다. 더티 페이지를 메모리에 유지할 경우 스토리지에 데이터를 쓰기 위해 필요한 I/O 작업을 상당히 줄일 수 있다. 둘째, SSD는 일정한 쓰기 횟수에 도달한 이후부터 성능이 하락한다. 따라서 쓰기 작업의 양을 늘리면 하이엔드 드라이브를 사용하더라도 SSD의 수명에 영향을 미치게 된다. 요즘 클라우드 호스팅의 인기가 높은데, 마이SQL 서비스 인스턴스를 클라우드에서 실행하는 방법이 상당히 유용할 수도 있다. 그러나 클라우드의 서버에는 I/O 제한이 있거나 I/O 사용량에 따라 더 많은 요금을 부과하는 경우가 많다. 이와 같은 제약을 염두에 두고 매개변수를 신중하게 구성해 한도에 도달하지 않도록 하고 I/O 작업이 최소화되도록 해야 한다. innodb_lru_scan_depth도 여기서 언급해야 할 중요한 부분이다. 이 설정에 따라 페이지 클리너 스레드가 플러시할 더티 페이지를 스캔하는 버퍼 풀 LRU 페이지 목록의 범위가 결정되기 때문이다. 쓰기가 많은 워크로드가 있고 버퍼 풀이 크고 버퍼 풀 인스턴스의 수가 많다면 이 변수의 값을 낮춰서 I/O 작업의 수를 줄일 수 있다. 그러나 변경해야 할 필요성이 확실하지 않은 한 기본값을 유지하는 것이 좋다. 최신 SSD는 특히 트랜잭션 데이터베이스에 최적화된다는 점도 알아둘 만하다. 실제로 웨스턴 디지털(Western Digital)은 새로운 애플리케이션에 대한 요구사항을 충족하기 위해 전문가의 도움을 구했다. 마이SQL 성능 팁 8. 공통 테이블 식 활용 마이SQL 8.0에는 파생 테이블을 생성하는 중첩된 쿼리를 없애는 데 도움이 되는 공통 테이블 식(CTE)이 도입됐다. 이 새로운 기능을 통해 맞춤형 쿼리를 만들고 그 결과를 임시 테이블 또는 뷰를 참조하듯 활용할 수 있다. 차이는 CTE는 명시적으로 만들고 삭제할 필요 없이 한 트랜잭션 내에서 여러 번 참조가 가능하다는 점이다. CTE는 한 번만 구체화되므로 여러 개의 쿼리를 실행하는 복잡한 트랜잭션에서 대체로 더 빠르다. 또한 CTE 회귀가 지원되므로 계층 모델 및 계열과 같은 복잡한 구조를 SQL 언어로 쉽게 만들 수 있다. CTE에 대한 더 자세한 서 볼 수 있다. 마이SQL 성능 팁 9. 클라우드에 주의 직접 관리하는 VM에 마이SQL 서버 인스턴스를 구현하는 방법부터 서비스형 데이터베이스(DBaaS) 솔루션을 사용하는 방법까지 마이SQL 배포용으로 고려할 만한 클라우드 옵션은 많다. 이러한 서비스의 상당수는 성능을 대폭 개선하고 모든 문제를 해결해준다고 주장하는데, 몇몇 간단한 환경에서는 정말 그렇게 될 수도 있다. 그러나 클라우드에서도 데이터베이스의 기본적인 원칙은 알고 이해해야 하며, 그렇지 않을 경우 비용이 크게 증가하므로 주의해야 한다. 많은 경우 이 비용 증가의 원인은 설계를 수정해 문제를 해결하지 않고 무작정 더 많은 하드웨어를 할당하는 방식으로 해결하려 드는 데 있다. 앞서 다룬 모든 팁은 중요하며 클라우드에도 적용된다. 그러나 워크로드를 모니터링하고 이해하고, 적절한 스키마를 설계하고, 필요한 경우에만 제한적으로 변경하는 것이 중요하다. 마이SQL 엔터프라이즈 모니터(MySQL Enterprise Monitor), 오픈소스 페르코나(Percona) 모니터링 및 관리와 같은 툴은 서버를 모니터링하는 데 큰 도움이 될 수 있다. 마이SQL 성능 팁 10. 복제본을 최신 상태로 유지 마이SQL 복제에서 기본 서버의 쓰기 워크로드를 따라잡지 못했던 부분이 최근 몇 년 사이 많이 개선됐다. 최신 마이SQL 주 버전에서 복제는 기본적으로 병렬로 실행된다. 즉, 여러 복제 스레드가 실행되면서 동시에 트랜잭션 적용을 시도한다. 물론 효율성은 애플리케이션의 쓰기 워크로드에 따라 크게 좌우되지만 대부분의 경우 병렬 복제는 성능을 개선하는 데 도움이 된다. replica_parallel_type 및 replica_parallel_workers 변수를 사용해 제어할 수 있다. LOGICAL_CLOCK 형식에서 트랜잭션은 병렬로 적용되며 타임스탬프를 기반으로 종속성이 추적된다. 정리하면 마이SQL은 수많은 개발자를 위한 선두 오픈소스 데이터베이스이며, 전 세계에서 만들어지는 많은 애플리케이션을 위한 주 플랫폼의 위치를 앞으로도 유지할 것이다. 스키마 설계, 인덱싱, 튜닝 및 I/O와 관련된 문제에 관심을 두면 애플리케이션의 성능을 비약적으로 개선할 수 있다. 또한 클라우드로의 전환과 같은 배포 접근 방식에 따라서도 성능이 달라질 수 있다는 점을 잊지 말아야 한다. editor@itworld.co.kr

"인터넷 서핑만 할 건데" 저예산 보급형 노트북 구입 가이드

“애저 데브옵스에 웹3를 통합한다” 마이크로소프트의 블록체인 실험

"내용도 형식도 잘못됐다" IT 기업 대규모 해고 고찰

"멀리 있어도 동료" 해외 부서와 애자일 협업하기 7대 수칙

사용자 충성심이 바닥나는 순간 "트위터를 반면교사로"

내부 감사로 IT 리스크 관리를 지원하는 방법

보안 2022.11.21

보안 서비스 구입할 때 가장 중요한 것 "제품과 업체 평가 선행"

노련한 CSIO 마이크 만로드는 훌륭한 사이버 보안 공급업체 평가의 가치를 인지하고 있다. 만로드는 이전 직장에서 장기 서비스 계약에 따라 매우 비싼 베이퍼웨어(vaporware)를 물려받았던 것을 기억한다. 전임자는 혁신적이라고 주장하는 신원증명 및 액세스 관리 플랫폼 베타 버전을 구매했으나, 제품에 대한 어떤 분석도 하지 않았고, 단순히 제품 효과가 좋다는 업체의 주장을 받아들였다. 어리석은 행동이었다. 이와는 반대로 만로드는 현재 직장인 그랜드 캐년 에듀케이션(Grand Canyon Education)의 CSIO로서 웹 애플리케이션 보안 제품 평가를 위해 별도의 부서를 구성하면서, 테스트를 통해 사용하는 기업이 검증하면 업체 측의 주장을 쉽게 전복할 수 있다는 점을 알아냈다. 기본 테스트만으로도 높은 비용을 물어야 하는 실수를 방지할 수 있었다. 이른바 ‘기발한’ 웹 애플리케이션 보안 제품 평가를 위해 팀을 구성했으나, 클라이언트 쪽의 검증이 제품을 쉽게 우회해 전복시킬 수 있다는 점을 테스트를 통해 발견했다. 이러한 기본적인 테스트 덕분에 높은 비용을 초래하는 실수를 방지할 수 있었다. 만로드는 “신생업체는 트라이스포밍(trysforming)하기 때문에 때때로 원점으로 돌아가는 경우가 있다. 이것 자체가 문제가 되지는 않지만, CISO 같은 보안 리더가 준비되지 않은 제품을 무턱대고 구매할 경우, 결국 CISO의 책임이 된다”라고 강조했다. 만로드는 성숙한 평가 프로그램은 문제에 대한 명확한 이해 및 문제 해결을 위한 방안에서 시작한다고 설명한다. 반면, 비성숙한 팀은 먼저 명확한 비즈니스 요구를 규정하지 않고 경영진이 회의에서 제품을 마음에 들어 했다는 것 말고는 더 나은 이유가 없어도 특정 제품을 구입한다. 또한 성숙한 평가 팀은 규정된 비즈니스 요구를 충족하는 솔루션으로 범위를 좁히기 전에 광범위한 솔루션을 두고 이해하고 검토한다. 성숙한 조직은 아무런 의문도 제기하지 않고 공급업체의 마케팅 소개 자료를 신뢰하기보다는 테스트에 더 의존한다. 예를 들어, 고급 테스트 부서는 공격자의 전술, 기술 및 절차(TTP)를 정확히 모방해서 보안 도구 우회를 실험한다. 하지만 사이버보안 공급업체를 검증하는 보편적 프레임워크란 존재하지 않는다. 표준 평가 포맷 및 반복 가능한 프로세스 등 성숙한 프로그램의 가장 중요한 특징은 현재 산업 수준에서는 거의 존재하지 않기 때문에, 기업은 구매하려는 새로운 솔루션을 두고 자체적으로 체크리스트와 스프레드시트 등을 개발해 활용해야 한다. 사이버보안 업체 레인 캐피털의 사이버보안 전문가인 첸시 왕은 이로 인해 구매 기업과 판매 업체 모두 어려움에 봉착한다고 지적했다. 왕은 “보안 공급업체 평가를 위해 사용하는 보편적인 프레임워크가 없다는 것은 안타까운 일이다. 각기 다른 공급업체, 제품, 서비스에 같은 작업을 해야 하기 때문이다. 구매 기업과 판매 업체의 양 측면을 모두 경험하고 있다. 투자 목적으로 회사를 평가하는데 투자를 하고 나면 판매자의 입장이 된다. 보편적 프레임워크 및 표준이 있다면 우선순위 설정, 고객과의 소통 방법 고안과 같은 판매 측면 업무가 훨씬 수월해질 것”이라고 설명했다. 영국 보안 제품 평가 제공업체 SE 랩스(SE Labs) 설립자 사이먼 에드워드는 보안 서비스의 평가 표준화 문제는 공급업체나 테스터의 반발에서 비롯된다고 이야기했다. 에드워드는 공급업체가 구매자를 잃을 수 있기 때문에 비판을 원하지 않는다고 설명했다. 한편, 테스터는 표준이 제한적이기 때문에 일반적으로 평가 표준화를 좋아하지 않는다. 그러나 경험상 에드워드는 표준이 제한이라고 생각하지 않는다. “보안 제품 테스트는 정말 어렵다. 하나의 문제를 해결하는 솔루션 유형이 상당히 많고 제품 구성과 배포 방식이 다양하기 때문이다”라고 덧붙였다. 성숙한 공급업체 평가가 비즈니스 요구 충족에 필요한 이유 성숙한 평가 프로세스는 비즈니스와 제품 얼라인먼트에서 시작한다. 예를 들어, 에드워드에 따르면 뱅킹 ATM 엔드포인트에서의 안티바이러스 요구사항은 준수에 더 중점을 두는 반면, 직원 노트북의 안티바이러스는 피싱과 인터넷 모든 곳에서 발생하는 ‘의심스러운 다운로드’ 같은 지속적이고 진화하는 위협을 포괄적으로 방어해야 한다고 설명한다. 이러한 사항은 평가의 요구사항 단계에서 명확하게 설명되어야 한다. 또한 고급 분석을 통해 공급업체 유형 결정에 필요한 질문을 만들 수 있는데, 질문을 통해 공급업체가 우리 회사의 비즈니스 요구를 얼마나 잘 충족하는지를 알 수 있다. 공급망 리스크 관리 공급업체인 텐치 시큐리티(Tenchi Security)의 유명 제품 테스터이자 제품 관리 총괄인 아드리안 사나브리아는 “솔루션을 통해 실제 문제를 해결할 수 있나? 보안 부서의 업무 부담이 줄어들까? 아니면 새로운 기술을 도입해야 하고 보안 부서의 업무가 더욱 늘어날까?” 같은 질문을 예로 들었다. 더 수준을 높여 평가 요구사항과 성과 지표를 비용이 가장 적게 드는 노력, 상호 운용성, 통합 및 비용으로 설정하고, 가치 실현 시간, 노동 비율, 제품의 실제 비용, 신뢰성 등을 성공 지표로 사용할 수 있다. 공급업체 평가와 기존 표준을 정렬하기 사이버보안 공급업체 평가에 맞는 표준화 방법과 프로세스는 없지만, 성숙한 프로그램은 요구사항 설정과 테스트 수행에 업계에서 인정하는 표준과 프레임워크를 사용한다. 그러나 이러한 프레임워크는 균일하게 규범적이지는 않다. 예를 들어, SE 랩스는 악성 소프트웨어 방지 솔루션에 대한 AMTSO 테스팅 프로토콜 표준을 따르며, 마이터 어택(MITRE ATT&CK) 프레임워크를 넘어, ‘완전 공격 체인 테스팅(full-attack chain testing)’이라고 부르는 방식을 사용한다. 만로드에 따르면 프레임워크를 일찍 선택하는 것도 비즈니스와 기술 목표 정렬에 중요하다. 만로드는 “프로세스는 공급업체 선택에서 시작하지 않는다. 마이터 어택 프레임워크처럼 다른 것와 연결된 전략에서 시작한다. 이메일, ID 혹은 웹사이트를 노리는 공격을 방지하려면, 정확한 환경 전반과 요구를 정렬하자. 그러면 제품 카테고리로 이어지고, 기능적 요구사항은 공격 및 방어 프레임워크에 의해 규정되며, 이후 제품이 수행할 정확한 작업과 정렬된다”라고 조언했다. 성숙한 조직은 NIST CSF, ISO, SOC 2 등을 포함한 비즈니스에 적합한 프레임워크에 평가를 기반한다. 예를 들어 딜로이트는 클라이언트가 고려하는 중요 보안 협력 업체에 SOC2 및 ISO 인증을 확인하라는 요구를 종종 받는다. 이러한 요청은 주로 극도로 위험을 꺼리는 에너지나 금융 기업이 하는데, 대부분은 국제 기업이다. 딜로이트의 사이버 리스크 그룹의 공급망 안전 리더인 샤론 챈드는 프레임워크는 보호, 감지, 식별, 대응/복구 같은 각기 다른 보안 도메인에 접근한다고 덧붙인다. 따라서 이러한 도메인에 평가를 매핑하면 보안 서비스가 어떤 결과를 낼지에 초점을 맞추기 쉽다. 예를 들어 챈드는 “지금 방화벽을 구매하고 있는 것일까, 아니면 제로 트러스트 제품을 구매하고 있는 것일까? 제어 환경 보호를 통한 보안 강화 제품을 구입하는 것일까?” 등의 질문을 할 수 있다고 조언했다. 제품뿐 아니라 공급업체도 평가하자 또한 성숙한 프로그램에는 공급업체 안정성 평가 수단이 있다. 보안 이어북 2022를 위해 2,800개의 공급업체를 조사한 리차트 스타이논은 공급업체가 정치적으로 불안정한 지역에 있으면 서비스 중단이 발생할 수 있다고 이야기한다. 또한, 공급업체는 성장하고 있음을 보여주어야 한다. 따라서 스타이논은 투자자 보고서를 찾아보고 창립자 혹은 CEO 리더십 배경을 살피며 동료와 확인할 것을 조언했다. 공급업체 증명은 성숙한 평가 프로세스의 일부다. 그러나 전문가에 따르면, 공급업체 증명이 유일한 평가 프로세스인 경우에 검토나 테스트 없이 공급업체의 말을 받아들이는 것은 비성숙한 평가 프로세스의 지표다. 기업 고객을 위해 수많은 사이버보안 제품 평가를 수행하는 CISO인 이안 포인터는 증명의 핵심은 질문과 대응이라고 설명한다. 포인터는 “최근 고객의 경우, 원하는 분야의 공급업체 30곳부터 시작했다. 이후 목록은 3개로 추려졌고 그 다음 업체에 많은 질문을 목록으로 보냈으며, 시연 중에 답변을 받았다”라고 설명했다. 질문에 응답하는 방식으로도 공급업체를 알 수 있다. 예를 들어, 공급업체가 질문의 절반에 답변하지 않을 경우 제품이 표준을 충족하지 못하거나, 공급업체가 서비스 공급업체로서 응답률이 낮다는 점을 보여준다. 많은 공급업체에서 이러한 일이 발생한다면 구매자의 인식이 이 분야 제품이 수행하는 기능과 정렬되지 않는다는 의미다. 테스트 효과와 공급업체의 보안 사나브리아에 따르면, 성숙한 프로그램에는 제품 효과 테스트를 위한 프로세스가 있다. 평가 프로그램의 깊이는 획득하는 보안 서비스의 중요성에 달렸다. 예를 들어 정말 중요한 제품이라면 기능적 요구를 넘어 서비스 자체에 대한 레드 팀 테스트가 포함될 것이다. 만로드는 성숙한 조직은 기술을 사내에 보유하고 있거나 외부 서드파티를 통해 테스트할 수 있다고 주장했다. 성숙한 테스트 프로세스의 핵심은 “실제 사용례와 기업의 조건에 따라 제품이 전략을 충족하는지를 입증하는 것”이다. 만로드는 “테스트는 비용을 들일 만한 가치가 있다. EDR 제품이 너무 비싸다면, 사내 기술로 대체하거나 하루 동안 외부 컨설턴트를 고용해 적절한 지출인지 확인한다고 해서 얼마나 더 비용이 들겠는가?”라고 질문했다. editor@itworld.co.kr

"구매 버튼 누르기 전에" 지포스 RTX 4080에 대해 알아야 할 5가지

‘2023년 안드로이드 기기의 핵심’ 스냅드래곤 8 2세대 특징 알아보기

“차세대 C++는 누가 될까” 러스트vs.카본vs.Cpp프론트 언어 차이 살펴보기

벤치마크 | 지포스 RTX 4090, 고품질 콘텐츠 제작에 날개를 달다

“애플의 칩은 무엇이 다른가” A16부터 M2까지 애플 칩 성능 살펴보기

"휴대폰 속 윈도우" 안드로이드에서 완전한 MS 사용자 경험을 만드는 방법

윈도우 2022.11.10

윈도우가 수집하는 개인정보, 철저히 단속하는 10가지 고급 팁

윈도우 10이 사용자의 개인 정보를 너무 많이 수집한다는 우려가 있다. 윈도우 10이 개인정보를 침해한다고 생각하거나 개인 정보를 최대한 보호하고 싶다면, 단 몇 분 안에 프라이버시를 보호하는 설정 방법을 자세히 알아보자. 광고 추적 끄기 프라이버시 보호와 관련해 사용자가 가장 우려하는 것은 웹 탐색 시 어떤 데이터가 수집되는가다. 데이터는 여러 기업이 광고 노출 대상으로 삼는 개인 관심사 프로필 생성에 활용되기 때문이다. 윈도우 10은 광고 ID로 데이터 수집을 수행한다. 광고 ID는 웹을 탐색할 때에도, 그리고 윈도우 10 앱 사용 시에도 사용자의 개인 정보를 수집한다. 사용자의 광고 ID는 다른 컴퓨터에 연동되어 있지 않으며, 마이크로소프트 계정과 상관없이 독립적으로 작동한다. 사용자가 원한다면 광고 ID 활동을 끌 수 있다. 원도우 10 설정 앱(화면 좌측 하단에 있는 ‘시작’ 버튼을 클릭한 다음 기어 모양의 ‘설정’ 아이콘을 클릭한다.)을 실행하고, 개인정보로 이동한다. 좌측에 강조 표시된 ‘일반’이 보일 것이다. 메인 창 일반에서는 ‘개인정보 옵션 변경’이라는 제목의 선택지 목록을 확인할 수 있다. 첫 번째는 광고 ID를 제어한다. 슬라이더를 켬에서 끔으로 이동한다. 광고가 보이는 것은 똑같지만 표적형 광고가 아닌 일반 광고이기 때문에 개인 관심사는 더이상 추적되지 않는다. 윈도우 10 사용 시 사용자 추적을 막고, 사용자 개인 정보를 사용해 표적 광고를 게재하는 것을 중지하려면 ‘마이크로소프트 개인정보 대시보드’의 광고 설정 섹션으로 이동한다. 페이지 우측 상단에서 마이크로소프트 계정에 로그인한다. 그 다음 창의 상단에 있는 ‘관심있는 광고 보기’ 섹션으로 이동해 슬라이더를 켬에서 끔으로 조정한다. 위치 추적 끄기 어디를 가든 윈도우 10은 사용자 위치를 알고 있다. 운영체제가 사용자의 지역 날씨, 근처에 있는 음식점 등 관련 정보를 제공하므로 개의치 않는 사람도 많다. 그러나 윈도우 10이 자신의 위치를 추적하는 것을 원하지 않을 경우, 사용자는 이를 중지하도록 지정할 수 있다. 설정 앱을 실행하고 개인정보 > 위치로 이동한다. ‘이 기기의 위치에 대한 액세스 허용’ 아래 ‘변경’을 클릭하고 나타나는 화면에서 슬라이더를 켬에서 끔으로 변경한다. 이제 모든 PC 사용자의 위치 추적기능을 해제할 수 있다. 전부 실행하거나 해제할 필요는 없다. 위치 추적은 앱별로도 끌 수 있다. 일부 앱만 자신의 위치를 사용하기를 원하는 경우, 위치 추적이 켜져 있는지 확인한 다음, ‘정확한 위치를 사용할 수 있는 앱 선책’ 섹션까지 아래로 스크롤한다. 위치를 사용하는 윈도우 10 앱 목록 전체를 볼 수 있다. 위치 사용을 허용할 앱은 슬라이더를 ‘켬’으로, 허용하지 않을 앱은 ‘끔’으로 변경한다. 데스크톱 앱은 해당되지 않는다. 따라서 위치 추적을 켠 후 ‘데스크톱 앱이 사용자의 위치에 액세스하도록 허용’을 클릭한 다음 슬라이더를 활성화한다. 이 경우 위치 추적 기능을 사용하는 데스크톱 앱 목록이 나타난다. 자신의 위치 사용을 허용할 각 앱의 슬라이더를 ‘온’으로 조정하고, 반대의 경우 앱의 슬라이더를 ‘오프’로 조정한다. 위치 추적을 끄더라도 윈도우 10의 과거 위치 기록은 계속 유지된다. 위치 기록을 지우려면 ‘개인정보 대시보드’로 이동해 ‘위치 활동’ 섹션까지 아래로 스크롤하고 ‘위치 활동 보기 및 지우기’를 클릭한다음 위치 기록의 전체 혹은 일부를 삭제한다. 이 항목에서 사용자가 개인 정보를 보호할 수 있는 방법은 많다. 자세한 내용은 다음의 ‘마이크로소프트 개인정보 대시보드 사용하기’를 참고하자. 타임라인 끄기 윈도우 10의 타임라인 기능을 통해 사용자는 활동을 검토하고 다시 시작할 수 있으며, 윈도우 PC 및 기타 기기는 물론 윈도우 10 PC에서 시작한 파일을 열 수 있다. 예를 들어, 데스트톱에서 하던 일을 노트북에서도 지속할 수 있으며, 각 컴퓨터에서 두 PC에서 시작한 활동을 다시 시작할 수도 있다. 이를 위해 윈도우는 각 컴퓨터의 모든 활동에 대한 정보를 수집해야 한다. 우려된다면 타임라인을 끌 수 있다. 타임라인을 끄려면 설정 > 개인정보 > 활동 기록으로 이동해 ‘이 장치에 내 활동 기록 저장’ 옆 확인란을 선택 취소한다. 윈도우 10은 이제 더 이상 사용자 활동 정보를 수집하지 않는다. 그러나 이전 활동 정보는 여전히 유지하고 모든 PC의 타임라인에 표시한다. 이전 정보를 제거하려면 화면의 ‘활동 기록 지우기’ 섹션으로 내려가 ‘지우기’를 클릭한다. 활동 추적 기능을 끄기 위해 모든 PC에서 이러한 조치를 취해야 한다는 점을 참고해야 한다. 마이크로소프트 계정 대신 로컬 계정을 사용하자 마이크로소프트 계정을 사용해 윈도우 10에 로그인할 경우 모든 윈도우 장치 및 설정을 동기화할 수 있다. 예를 들어, 데스크톱 PC에서 설정을 변경하면 다음에 로그인할 때 노트북에서도 변경한 것이 적용된다. 그러나 마이크로소프트가 개인 정보를 저장하는 것을 원하지 않는 사용자도 있을 것이다. 또 아예 사용자 정보를 저장하지 못하게 하고 싶을 수도 있다. 이 경우, 마이크로소프트 계정이 아닌 로컬 계정을 사용하는 게 가장 좋은 방법이다. 설정 > 계정 > 가족 및 기타 사용자로 이동한다. 그 다음 ‘이 PC에 다른 사용자 추가’를 클릭한다. 나타나는 화면에서 ‘이 사람의 로그인 정보를 가지고 있지 않습니다’를 선택한다. 다음 페이지에서 ‘마이크로소프트 계정없이 사용자 추가’를 선택하고 로컬 계정 생성 및 사용을 위한 지침을 따른다. 로컬 계정을 사용할 때는 마이크로소프트의 원드라이브, 마이크로소프트 스토어의 유료 앱을 다운로드, 설치할 수 없다는 점을 염두에 두어야 한다. 그러나 마이크로소프트 스토어에서 무료 앱을 다운로드 및 설치할 수는 있다. 앱 사용 권한 변경하기 윈도우 앱은 카메라, 마이크, 위치, 사진 및 비디오에 액세스할 수 있으므로 개인정보를 침해할 수 있다. 그러나 어떤 종류의 액세스를 각 앱이 가질 수 있는지는 상당히 세분화된 방식으로 결정할 수 있다. 설정 > 앱으로 이동한다. ‘앱 및 기능’ 아래에서 설치된 앱 목록을 확인할 수 있다. 권한을 제어하고자 하는 앱을 클릭한 후, ‘고급 옵션’을 클릭하고 켜거나 끄는 방식으로 앱의 권한을 설정한다. 그러나 모든 앱에 ‘고급 옵션’ 링크가 있는 것은 아니다. 또한 링크가 있는 앱 중에서도 일부 앱은 앱 권한의 사용자 지정을 허용하지 않는다. 앱 권한을 변경하는 방법은 또 있다. 설정 > 개인정보로 이동해 페이지 왼쪽에 있는 ‘앱 권한’ 섹션 아래를 확인한다. 위치, 카메라, 마이크, 알림, 계정 정보, 연락처 등 권한 있는 앱이 액세스하는 윈도우 하드웨어 및 기능 목록을 모두 확인할 수 있다. 목록의 아무 항목(예를 들어 마이크)이나 클릭해보자. 새로 나타나는 페이지 상단에서 모든 앱의 마이크 액세스를 해제할 수 있다. 그 아래에는 마이크에 액세스할 수 있는 모든 앱 목록이 표시되며, 여기서 앱별로 액세스를 제어할 수 있다. 액세스 권한이 있는 앱에는 켬으로 설정되어 있는 슬라이더가 있다. 앱 액세스를 중지하려면 슬라이더를 끔으로 변경한다. 진단 데이터 설정과 삭제 윈도우 10을 사용하면 하드웨어 및 윈도우 사용 시 수행하는 작업에 대한 데이터가 수집된다. 마이크로소프트는 윈도우를 지속적으로 개선하고 윈도우를 가장 잘 사용하는 방법에 대한 맞춤형 조언을 제공하기 위해 데이터를 수집한다고 이야기한다. 물론 불편한 사용자도 많다. 이러한 감정을 느끼는 경우 사용자는 수집되는 진단 데이터 종류를 어느 정도 제어할 수 있다. 이를 위해 설정 > 개인정보 > 진단 및 피드백으로 이동한다. ‘진단 데이터’ 섹션에서 사용자는 2가지 진단 데이터 중 하나를 선택할 수 있다. 유의할 점은 마이크로소프트의 진단 데이터 수집을 완전히 차단할 방법은 없다는 것이다. 두 가지 선택지가 있다. 필수 진단 데이터 : ‘장치, 설정, 기능에 대한 정보 및 제대로 작동하는지. 여부’에 관한 정보를 마이크로소프트에 보낸다. 개인정보가 걱정될 경우 선택할 수 있는 설정이다. 선택적 진단 데이터 : 전체 진단 데이터를 마이크로소프트에 보낸다. 검색하는 웹사이트에 대한 정보, 사용자의 앱 및 기능 사용 방식에 대한 정보와 더불어 장치 상태, 장치 사용 및 향상된 오류 보고에 대한 추가적인 정보 또한 보낸다. 요구된 진단 데이터 또한 보낸다. 그러나 개인정보가 걱정스러울 경우 이 선택지는 적합하지 않다. 그 다음 ‘맞춤형 환경’ 섹션으로 아래로 스크롤해 슬라이더를 ‘끔’으로 이동한다. 마이크로소프트가 수집하는 데이터에는 영향을 주지 않으나 해당 정보를 기반으로 하는 표적 광고 및 팁을 해제한다. 따라서 개인정보 보호를 향상할 수는 없어도 성가신 방해 요인은 줄일 수 있다. 좀 더 아래로 스크롤해 ‘진단 데이터 삭제’ 섹션에서 ‘삭제’를 클릭한다. 이 경우 마이크로소프트가 수집한 모든 진단 데이터가 삭제될 것이다. 그러나 삭제 후에도 마이크로소프트는 데이터 수집을 다시 시작할 것이다. 마지막으로 이 화면에서 ‘수동 입력 및 타이핑 개선’ 섹션으로 위로 스크롤해 슬라이더를 ‘끔’으로 변경하는 것이 좋을 수 있다. 이를 통해 사용자가 키보드 및 사인펜 기능을 사용해 입력한 단어를 윈도우 10이 마이크로소프트에 전송하는 것을 막을 수 있다. 진단 데이터 관련 마지막 팁이다. 마이크로소프트가 마이크로소프트 스토어에서 다운로드할 수 있는 ‘진단 데이터 뷰어’라는 도구에 대해 광고하는 것을 들어본 적이 있을 것이다. 마이크로소프트는 이 도구를 통해 사용자에 대해 수집하는 진단 데이터의 종류를 사용자가 명확히 확인할 수 있다고 주장한다. 그러나 이 주장을 믿어서는 안 된다. 프로그래머만이 좋아하거나 이해할 수 있는 도구다. 마이크로소프트가 수집하는 진단 데이터를 명확히 확인하기 위해 개인 사용자가 이 도구를 사용할 수는 없을 것이다. 스크롤 혹은 검색을 하다 보면 아무 설명도 없이 TelClientSynthetic.PdcNetworkActivation_4’나 ‘Microsoft.Windows.App.Browser.IEFrameProcessAttached’와 같은 이해할 수 없는 제목을 보게 될 것이다. 제목을 클릭하면 더 이해할 수 없는 데이터를 찾게 된다. 마이크로소프트의 개인 정보 대시보드 사용하기 마이크로소프트는 사용자에 대해 수집한 많은 정보를 추적 및 삭제하는 ‘개인 정보 대시보드’라는 잘 알려지지 않은 훌륭한 웹 도구를 만들었다. 앞서 언급했듯, 사용자는 표적 광고를 이 곳에서 끌 수 있다. 또한 웹 방문 기록, 검색 기록, 위치 활동, 음성 활동, 미디어 활동, 링크드인 활동 정보를 확인하고 삭제할 수도 있다. (참고할 점은 웹 방문 및 검색 기록의 경우, 마이크로소프트 엣지 혹은 인터넷 익스플로러를 사용할 때만 활동을 추적한다는 것이다. 크롬이나 파이어폭스 같은 타 브라우저를 사용할 경우 데이터를 추적하지 않는다. 또한 iOS나 안드로이드를 사용하는 기기가 아닌 마이크로소프트 기기를 사용할 때만 위치 기록을 추적한다.) 사용을 위해서는 확인 및 삭제하려는 정보로 이동한 다음, 예를 들어 ‘마이크로소프트 엣지에서 브라우저 기록 보기 및 삭제하기’와 같은 적절한 링크를 클릭한다. 데이터 삭제 및 관리를 완전히 제어하지 못하는 경우도 있음을 참고하자. 대시보드에서 기타 엑스박스, 오피스/마이크로소프트 365, 마이크로소프트 팀즈를 포함한 기타 마이크로소프트 제품을 위해 개인정보 설정 또한 맞춤화 할 수 있다. ‘제품 내 개인정보 설정’ 섹션으로 스크롤한 다음 관심있는 제품을 클릭한다. 설정 앱에서 세부 정보 가져오기 사실 실행 시간은 그다지 오래 걸리지 않는다. 개인 정보 보호에도 큰 도움이 될 것이다. 그러나 개인정보 보호를 더 깊이 파고 들려면 설정 앱을 시작한 다음 ‘개인정보’를 클릭한다. 광고 ID를 끄는 스위치 아래에는 비활성화할 수 있는 3개의 추가적인 개인정보 설정이 있다. 언어 목록 : 사용자가 컴퓨터에서 언어 목록을 활성화할 수 있다. 앱 시작 : 이 기능은 시작 메뉴의 ‘가장 많이 사용한’ 목록을 구축할 때 사용되며 검색 결과 순서에 영향을 준다. 프라이버시를 중시하는 사용자에게는 필수적인 기능이 아니다. 제안된 콘텐츠 : 마이크로소프트에 따르면 이 기능은 “흥미로울 수 있는 새로운 콘텐츠 및 앱을 제안”하기 위해 사용된다. 확신하건대 사용자는 이 기능을 흥미롭다고 생각하지 않을 것이다. 개인정보 보호 강화를 위해 3가지 기능 모두를 끄자. 또한 일반 페인 외에도 많은 것들이 있다. 화면 좌측에는 개인정보를 더욱 세분화할 수 있는 추가적인 영역이 있다. 예를 들어, ‘윈도우 권한’ 섹션의 경우 사용자는 음성 인식 및 수동 입력과 같은 항목에 대한 전체 개인정보 옵션을 변경할 수 있다. 또한 앞에서 언급한 바 있듯이 이 곳에서 모든 앱 권한에 액세스할 수 있다. 극도로 프라이버시를 중시하는 사용자를 위한 고급 팁 개인정보 보호를 더욱 강화하고 싶은 경우, 몇 가지 추가로 쓸만한 고급 팁이 있다. 원드라이브 사용 중지하기 데이터가 마이크로소프트의 원드라이브 클라우드 저장소 서비스에 동기화되는 것이 싫을 경우, 원드라이브 사용을 중지할 수 있다. (설치를 제거할 방법은 없다.) 윈도우 데스트톱 하단 우측에 있는 알림 트레이의 원드라이브 아이콘을 오른쪽 클릭한 다음 나타나는 메뉴에서 설정을 선택한다. 원드라이브 설정 창에서 ‘계정’ 탭으로 이동한 다음 ‘이 PC에서 연결 해제’를 클릭한다. 그 다음 ‘동기화’를 클릭하고 ‘백업’ 탭을 클릭한 후 ‘윈도우에 로그인할 때 자동으로 원드라이브 시작’을 체크 해제한다. 여러 기기에서 윈도우 설정을 동기화하지 않기 또한 사용자는 각기 다른 기기에 걸쳐 윈도우 설정이 동기화되는 것을 거부할 수 있다. 설정을 동기화할 때 윈도우 10을 맞춤화 및 설치한 방식은 마이크로소프트의 서버로 동기화된다. 비활성화할 때는 설정 > 계정 > 설정 동기화로 이동한 다음 동기화 설정 아래 스위치를 끈다. 앱 진단 기능 끄기 개인정보 보호에 특별히 도움이 되지는 않는 설정이다. 그러나 진정한 프라이버시 마니아라면 모든 항목이 도움이 된다. 워드나 엑셀 같은 데스크톱 앱에는 영향을 주지 않지만, 그 대신 윈도우 내장 앱 및 마이크로소프트 스토어에서 다운로드 된 앱을 타겟으로 삼는다. 앱 진단 기능을 해제할 경우 이들 앱은 내부 이름, 패키지 이름, 앱을 실행하는 사용자 이름, 메모리 사용량 같은 기술적 세부 사항 등 기타 앱 관련 정보를 얻을 수 없다. 개발자는 언제나 이러한 정보를 사용하지만, 사용자의 일반적인 앱은 이러한 정보를 전혀 필요로 하지 않는다. 해제를 위해서는 설정 > 개인정보 > 앱 진단을 선택한 다음 ‘이 기기의 앱 진단 정보에 액세스하도록 허용’ 섹션에서 ‘변경’을 클릭한다. 슬라이더가 나타나면 ‘끔’으로 변경한다. 윈도우 업데이트 공유하지 않기 마지막으로 윈도우 업데이트 방식을 변경할 수 있다. 설정 > 업데이트 및 보안 > 배달 최적화에서 ‘다른 PC에서 다운로드 허용’ 옆 스위치를 끈다. 이 기능이 활성화돼 있으면 윈도우 10 시스템이 인터넷에서 피어 투 피어(peer-to-peer) 분배를 통해 다른 사람의 윈도우 10 컴퓨터와 파일 업데이트를 공유한다. 다양한 개인정보 단속 단계를 차근차근 밟아보자. 비공개로 하고 싶은 정보가 불필요하게 새어나가지 않도록 윈도우 10을 세심하게 설정할 수 있다. editor@itworld.co.kr

10세대 아이패드 리뷰 | 아름답지만 실망스러운, 포지셔닝이 애매한 태블릿

AMD 라데온 RX 7900 XTX에 대해 알아야 할 세부 사항 5가지

엔리얼 에어 리뷰 | 성큼 다가온 스마트 글래스의 미래

자바 동시성에 대한 새로운 접근 ‘가상 쓰레드’

새로운 스마트홈 표준 ‘매터’의 모든 것

"사자와 호랑이의 싸움" 지포스 RTX 4090 vs. RTX 3090 선택 가이드

디지털 디바이스 2022.11.02

애플 워치 울트라 리뷰 | 완벽에 가까운 가민의 대항마

요약 장점 러기드 디자인 사용자화할 수 있는 액션 버튼 훌륭한 배터리 성능 단점 일반 모델보다 큰 부피 가끔씩 실수로 실행되는 액션 버튼 총평 등산가와 익스트림 운동선수를 위한 뛰어난 스마트워치이자 가민의 독주에 견줄 만한 제품. 하지만 큰 돈을 쓰기 전에 업그레이드가 꼭 필요한지 확인하는 것이 좋다. 올해 애플 파크(Apple Park)에서는 고급 제품의 향연이 펼쳐지고 있다. 애플은 아이폰 및 에어팟의 프로 버전을 공격적으로 판매하는 중이다. 애플 워치도 플래그십 버전이 출시됐는데, 이번에는 값비싼 재질 외에도 추가적인 기능을 제공한다. 하지만 애플 워치 울트라(Apple Watch Ultra)는 아이폰 14 프로나 에어팟 프로와는 다른 문제다. 애플 워치 울트라는 단순히 개선을 위해 비용을 지불하는 업그레이드가 아니다. 일부 고객들은 좋아하겠지만, 대부분은 절대적으로 구매하지 말아야 하는 틈새시장을 위한 제품이다. 디자인과 착용감의 큰 변화 울트라는 이전 버전의 애플 워치보다 훨씬 크다. 가장 가벼운 시리즈 8보다 2배 가까이 무겁고 가장 무거운 모델보다 19% 더 무겁다. 14.4mm의 두께는 울트라를 제외한 시리즈 4 이후의 모든 모델의 표준인 10.7mm보다 약 35% 더 두껍다. 울트라의 물리적인 스타일은 1가지(49mm 티타늄)로만 제공되므로 더 가볍거나 작은 에디션을 선택할 수 없다. 울트라는 언제나 크다. 울트라를 착용했을 때 필자가 사용하던 애플 워치보다 더 무겁게 느껴지지는 않았다. 아마도 그동안 큰 버전의 애플 워치(44mm 및 45mm)를 착용했기 때문일 것이다. 스트랩을 살짝 느슨하게 착용했을 때는 움직이면서 추가적인 관성이 느껴졌지만, 팔을 들어 올리는 동작은 어렵지 않았다. 작은 모델에 익숙한 사용자는 다르게 느끼겠지만, 애플은 무게를 꽤 잘 감추었다. 반면 두꺼워진 섀시는 훨씬 잘 체감했다. 소매 아래에 착용하니 쉽게 걸렸고 날강도의 관심을 끌지 않고 알림을 살짝만 확인하려고 할 때 살짝 불편했다. 필자처럼 베개 아래에 팔을 넣은 상태로 잠을 자는 경우 특히 어색할 수 있다. (필자는 결국 워치가 아래쪽으로 향하지 않도록 팔을 돌렸고 별로 편하지 않았다.) 긴 배터리 사용 시간을 고려할 때 사람에 따라 이상적인 수면 트래커가 되지 못한다는 점이 아쉽다. 울트라는 도심에서 사용하도록 설계되지 않았다. 가벼운 봄 자켓 아래가 아니라 잠수복 위에 착용하는 모습을 예상하고 출시된 제품이며, 긴 배터리 사용 시간은 수면 추적이 아니라 며칠 동안의 하이킹을 견디기 위함이다. 시리즈 8 스타일의 용도를 염두에 두고 있고 물리적으로 같은 것을 기대하고 있는 사람들을 위해 필자가 관찰한 내용을 밝히도록 하겠다. 그렇지 않다. 약간 커지고 개선된 화면 물론 부피가 큰 디자인 덕분에 화면이 커지고 배터리 용량도 많아졌다. 단, 이런 개선폭은 부피와 비례하지는 않는다. 가장자리의 튼튼한 금속 베젤 때문이다. 45mm 시리즈 8과 비교하여 디스플레이 면적은 약 4% 커지고 픽셀은 7% 증가했다. 41mm 모델과 비교했을 때는 각각 수치가 31% 및 36%다. 즉, 인터페이스를 더 읽기 쉬워졌으며, 워치 페이스는 가독성은 잃거나 성가시게 하지 않고 더 많은 컴플리케이션을 담는다. 필자가 추천하는 워치 페이스는 8가지 컴플리케이션을 조합할 수 있는 울트라 전용 웨이파인더(Wayfinder)다. 크기 외에 울트라의 화면은 일반 애플 워치보다 훨씬 밝다. 애플에 따르면, 울트라의 화면 밝기는 최대 200니트이며, 시리즈 8의 2배다. 전반적으로 밝기 개선을 인지하지는 못했으나 2가지 장치를 나란히 두고 보면 차이가 명확하다. 선명도와 가독성이 좋아진 것이 화면 크기가 커졌기 때문이라고 생각했지만, 사실 밝기 개선과 관련이 큰 것 같다. 업그레이드된 화면을 사용하고 나면 일반 모델로 돌아가고 싶지 않을 것이다. 튼튼하고 견고하다 큰 베젤과 튼튼하지만 무거운 티타늄 등 울트라의 부피를 증가시킨 요소들은 제품의 뛰어난 견고함에도 기여한다. 최소한 문서상으로 이 기기는 강한 충격을 견딘다. 울트라를 손상시키기 위해 적극적으로 시도하지는 않았지만 애지중지하지도 않았다. 하지만 3주 동안의 테스트 후에도 몸체에는 흠집이나 오점 하나 없었다. 울트라는 시리즈 7/8과 같은 IP6X 방진 등급을 받았다(SE는 이 등급이 없다). 여기에 고도, 고온/저온, 온도 충격, 침수, 동결/해빙, 충격, 진동에 대해 MIL-STD 810H 밀리터리 표준 테스트를 거쳤다. 시리즈 8은 방수가 50m까지지만 울트라는 100m까지이며, 시리즈 8은 ‘수영 가능’이지만 울트라는 다이빙 액세서리에 사용되는 EN13319 인증을 추가로 받았다. 애플에 따르면, 울트라는 최대 40m의 레크리에이션 다이빙까지 문제없다. 번들 밴드 3종류 중 2가지는 물을 잘 흡수하므로 주의해야 하지만, 뛰어난 자격이 증명된 다이빙 워치다. 물리적인 손상이 우려될 수도 있다. 울트라의 화면은 살짝 돌출된 가장자리로 감싸져 충격에서 보호된다. 디지털 크라운(Digital Crown)은 돌출된 모듈로 보호되는데, 이 덕분에 장갑을 착용해도 측면 버튼을 쉽게 찾을 수 있다. 새로운 액션 버튼의 장단점 계속해서 버튼 이야기를 하자면, 디지털 크라운의 반대쪽에는 새로운 ‘액션 버튼(Action Button)’이 추가됐다. 이 버튼을 활용하는 앱은 운동(Workout)부터 스탑워치(Stopwatch), 웨이포인트(Waypoint), 백트랙(Backtrack), 다이빙(Dive), 손전등(Torch), 단축어(Shortcut)까지 총 7가지이며, 다수 앱에서는 어떤 운동이나 어떤 단축어를 실행할지 기능을 별도 지정할 수 있다. 액션 버튼은 웨이포인트, 백트랙, 다이빙 옵션에서 빛을 발한다. 버튼을 누르는 즉시 작동하므로 화면상의 메뉴를 조작하는 것보다 훨씬 빠르다. 필자는 도심에서 운동할 때 사용해봤는데, 독(Dock)을 통해 운동 앱을 켜는 것보다 시간이 크게 절약되지는 않았다. 개인적으로 ‘필수’가 아니라 ‘있으면 좋은’ 기능에 가까웠다. 사실 어떤 사람들은 액션 버튼이 주는 가치보다 문제점을 더 자주 경험할 것이다. 필자는 이 버튼을 통해 실수로 운동 기능을 켠 적이 많았고 이를 뒤늦게 발견하기도 했다. (큰 문제는 없었다. 실수로 아이폰을 구매하거나 상사와 페이스타임 통화를 시작할 가능성은 낮다.) 애플 워치 사용자들은 모든 컨트롤이 디스플레이 우측에 모여 있는 설계에 익숙할 것이므로 왼쪽 가장자리는 엄지손가락을 지지하는 데 사용할 수 있다. 울트라에서는 이런 머슬 메모리 때문에 적절하지 않은 기능을 실행할 수 있다. 이런 문제는 필자가 울트라에 익숙해지면서 완화됐고 점점 액션 버튼의 존재가 마음에 들었다. 1가지 버튼만 제공하기로 한 애플의 본래 결정은 사용성보다 미학에 기초한 것이었으며, 새로운 디자인에 익숙해지면 긍정적으로 느껴질 것이다. 하드웨어가 마련되었으니 애플은 사용자가 버튼에 할당할 수 있는 다양한 기능을 제공할 일만 남았다. 물론 완전히 비활성화하는 옵션도 있다. 밴드와의 전쟁 외적인 측면에서 마지막으로 논의할 가치가 있는 부분은 제공되는 밴드의 범위다. 핵심 쟁점은 우아하고 방수 기능이 있으며 합리적으로 쉽게 착용하고 벗을 수 있는 기존 클래식만큼 매력적인 옵션이 없다는 점이다. 익숙한 처럼 민무늬 벨크로 밴드이며, 풀 탭이 추가됐다. 편안하고 조절이 쉬운 인기 옵션이지만 특별히 스마트하지는 않다. 샤워 중 착용하면 물을 흡수하고 있다가 나중에 서서히 배출한다. 필자가 테스트한 도 트레일 루프와 유사하게 야외 활동에 적합한 외관을 갖고 있으며, 물을 흡수하는 단점도 같다. 하지만 알파인 루프의 최대 단점은 착용하고 벗는 것이 매우 어렵다는 점이다. 걸쇠를 걸고 해제하기가 까다롭고 울트라의 본체 옆의 더블링백(doubling-back) 섹션은 구멍을 쉽게 통과하지 못한다. 한 손으로 밴드를 조이거나 풀 때도 어색하고 느리며, 장기간 사용했을 때 섬유 루프가 너덜너덜해져 후크가 빠질까 염려된다. 수영과 다이빙을 염두에 두고 설계된 실리콘 소재의 에서 꼴찌를 차지했다. 전반적으로 알파인 루프는 애플 워치 울트라 경험 중에서 가장 만족스럽지 못한 요소였다. 아마도 가장 실망스러운 밴드는 색상 옵션마저도 화려하지 않은 트레일 루프일 것이다. 긍정적으로 생각해보자면, 울트라는 44mm 및 45mm 스트랩과 호환되므로 구형 기기의 루프를 재활용하거나 이를 악물고 새로 구매할 수 있다. 애플이 경고했듯이 울트라의 섀시가 커졌기 때문에 일부 밴드는 착용감이 살짝 다르며, 가능한 한 구매 전에 착용해 보아야 한다. 사양 및 기능 울트라의 대부분 기능은 시리즈 8과 같다. 새로운 온도 센서를 통한 생리 주기 추적 및 충돌 감지 기능이 대표적이다. 시리즈 8을 테스트했을 때와 마찬가지로 필자는 충돌 감지 오류를 경험하지 못했지만, 도 있었다. 울트라의 프로세서도 시리즈 8과 같은 S8이다. 시리즈 7의 S7 또는 시리즈 6의 S6보다 눈에 띄게 빠르지 않으면서 원활한 성능을 제공한다. 또한 울트라는 시리즈 8 및 SE 2세대와 무선 칩(W3)이 같으며, 전작과 동일한 초광대역 칩(U1)이 탑재됐다. LTE 연결 사양도 전작과 같다. 하지만 울트라는 프리미엄 제품이다. 즉, 다른 애플 워치에서 보지 못한 새로운 사항도 적용됐다. 단일 스피커 대신 2개의 스피커를, 단일 마이크 대신 3개의 마이크를 탑재했다. 길을 잃거나 도움이 필요할 경우 이 스피커를 사용하여 요란한 86데시벨 수준의 사이렌을 울릴 수 있다. 애플은 1.8km 거리에서도 사이렌을 들을 수 있을 것으로 예상했다. 하지만 개선된 GPS가 포함되어 있기 때문에 애초에 길을 잃을 가능성은 낮다. 다른 기존 애플 워치 모델에서 제공되는 L1 전용 GPS와 달리 L1 및 L5의 2가지 주파수를 기반으로 한다. 애플은 이를 통해 ‘놀라운’ 정확도를 제공한다고 주장했지만, 이전의 애플 워치에서 경험한 정확도가 이미 높아서 개선점을 알아차리기 어려웠다. 시리즈 8과 울트라에서 운동 경로를 확인해보면 실제 경로와 거의 비슷했다. 가끔 몇 미터씩 벗어나기는 했으나 길을 찾는 데 심각한 문제를 유발할 정도는 아니었다. 마지막으로, 울트라는 다이빙 및 수영 시 자동으로 활성화되는 수심 게이지 및 수온 센서를 제공한다. 배터리 사용 시간 및 충전 울트라는 이전의 애플 워치보다 커졌기 때문에 용량이 더 큰 배터리를 넣을 수 있다. 애플이 울트라의 배터리 사용 시간이 다른 모든 모델에서 약속한 표준 18시간보다 두 배나 긴 36시간이라고 강조한 것은 아마도 위험한 탐험 시장을 염두에 둔 것으로 보인다. 애플의 낙관을 증명하듯 울트라는 배터리 테스트를 가볍게 통과했다. 최근 테스트한 시리즈 8은 32.5시간을 버틴 반면 울트라는 약 3일에 가까운 72.5시간을 기록했다. 이틀 이상을 버틴 애플의 웨어러블 기기는 매우 드물다. 울트라의 배터리 성능은 시리즈 8보다 나은 수준이 아니다. 심지어 Macworld 테스트에서 54시간을 버틴 시리즈 2처럼 애플 워치가 야간에 배터리를 소모하는 수면 추적에 신경 쓸 필요가 없었던 시절의 구형 모델보다도 훨씬 나았다. 하지만 울트라를 충전할 때는 시리즈 8보다 오랜 시간을 기다려야 한다. 충전해야 할 용량이 많으니 당연한 결과다. 고속 충전을 지원하더라도 충전 속도는 상대적이다. 시리즈 8은 충전 30분 후 43%, 1시간 후 73%에 도달했지만, 울트라는 각각 31% 및 65%에 그쳤다. 애플 워치 울트라를 구매해야 하는 사람은? 울트라는 틈새시장을 위한 훌륭한 제품이며, 그 틈새가 자신에게 맞을 때는 확실히 구매해야 한다. 여기서 중요한 포인트는 ‘자신에게 맞는 경우’다. 배터리 사용 시간이 가민(Garmin) 수준은 아닐 수 있지만 애플의 주류 웨어러블에서 한 걸음 더 발전했으며, 하이커와 익스트림 스포츠 선수들에게 충분히 도움이 된다. 크고 밝은 화면은 실외에서 사용하기 좋으며, 튼튼한 디자인 덕분에 충격이 가해질 때도 걱정을 덜 수 있다. 액션 버튼은 장갑 또는 기타 거추장스러운 것을 착용한 사용자들에게 매우 유용하다. 여러 뛰어난 기능과 물리적인 업그레이드 덕분에 훌륭한 다이빙 워치로도 사용할 수 있다. 이런 개선점과 애플 워치의 기존 이점(훌륭한 워치OS, 탄탄한 서드파티 앱, 애플 생태계 통합)을 조합하면 꽤 설득력 있는 ‘가민 킬러’가 된다. 하지만 울트라는 단순히 예산이 더 많은 사람을 위한 프리미엄 애플 워치가 아니다. 업그레이드와 변화에 따르는 단점이 있다. 다이빙, 항해, 하이킹, 동굴 탐험을 할 생각이 아니라면 그 단점을 극복할 만한 가치를 얻기 어렵다. 재킷 소매에 걸리고 침대에서는 불편하며, 실수로 기능이 실행되는 스마트 워치에 불필요하게 많은 비용을 지불하게 된다. 배터리 사용 시간이 길고 강력한 기능을 갖춘 두툼한 액션 워치를 찾고 있다면 가격 대비 훌륭한 선택이 될 것이다. 그리고 이를 기준으로 했을 때 애플 워치 울트라에 5점 만점에 4.5점을 주고 싶다. editor@itworld.co.kr

블로그 | 오버워치여, 잘 있거라

아이패드가 '여전히' 노트북을 대체할 수 없는 5가지 이유

메타 퀘스트 프로 리뷰 | 얼리 어답터를 위한 너무 비싼 헤드셋

"팍팍 밀어주세요" IT 전문가 절반이 이직 원해…원인은 IT 지원 부족

초고속 자바스크립트 프레임워크 '퀵'의 이해

인텔 코어 i9-13900K 리뷰 | 인텔 자존심을 회복한 강력한 성능

오픈소스 2022.10.25

2022년 최고의 오픈소스 소프트웨어 28선

현재 소프트웨어 개발자이거나 클라우드 관리자, 데이터 사이언티스트 또는 코드를 다루는 사람 모두에게 오픈소스 소프트웨어는 숨을 쉬는 공기와 같다. 오픈소스가 항상 흔했던 것은 아니다. 20~30년 전 ‘무료 소프트웨어’가 막 시작됐을 때, 오픈소스 프로젝트는 낯선 것이었고, 이를 만든 사람들은 기본적으로 학자, 연구원, 괴짜 등이었다. 하지만 이런 기벽이 유행하면서, 마치 오래된 격언처럼, 현재는 오픈소스 소프트웨어가 세상을 '집어 삼키고' 있다. 오픈소스 소프트웨어 프로젝트는 실제로 컴퓨팅의 모든 부분에서 혁신 엔진 역할을 했다. 과거의 오픈소스 개발자는 인터넷을 구축했던 툴을 개발했고, 현재의 오픈소스 개발자는 이를 기반으로 프론트엔드(Front End) 개발, 백엔드(Back-end) 개발, 데브옵스(DevOps), 데이터 옵스(Data Ops), 분산형 데이터 처리, 데이터 분석, 머신러닝 등 더 새로운 툴을 만들고 있다. 여기 InfoWorld 선정 2022년 최고의 오픈소스 소프트웨어를 모은 '2022년 보씨 어워즈(Bossie Awards)' 프로젝트를 선정해 공개한다. 알마리눅스 세상에 새로운 리눅스 배포판이 또 필요할까? 많은 상용 소프트웨어가 RHEL(Red Hat Enterprise Linux)로 표준화했다. 기본적으로 RHEL의 무료 버전은 센트OS(CentOS)였다. 레드햇이 RHEL의 임시 대체재로써 인수한 후 지원을 중단해 버린 그 리눅스 배포판이다. 센트OS를 사용했던 많은 사람이 실망했는데, 그 빈자리를 채우기 위해 로키 리눅스(Rocky Linux)와 가 등장했다. 알마리눅스는 RHEL과의 바이너리 호환성 및 커뮤니티 소유권을 장점으로 내세운다. 포드맨 새로운 공상 과학 공포물 장르는 아니고 컨테이너 관리자가 바로 처럼 단순화할 수 있다. 이 정도면 도커에서 벗어나 팟 사용자가 되고 싶은 생각이 들지 않는가? 플레이 위드 도커 노트북이나 EKS, GKE 등으로 모든 작업을 수행할 수 있는 것은 맞다. 하지만 몇 개의 컨테이너만 사용하고 싶은 경우라면 어떨까? 이때 요긴한 것이 바로 다. 5개 인스턴스, 4시간 제한 때문에 보안, AI, 분석(현재 이에 주목하는 스타트업이 많다) 등에는 적합하지 않지만, 전면적으로 도커를 도입하기 전에 테스트하기에는 꽤 좋은 툴이다. 바딘 개발자가 HTML 또는 자바스크립트를 코딩할 필요 없이 자바에서 웹 사용자 인터페이스를 구현할 수 있는 웹 프레임워크가 있다면 이보다 좋은 것이 있을까? 바로 할 수 있다. J힙스터 는 자바를 위한 야심찬 풀스택(Full-stack) 고속 애플리케이션 개발 플랫폼이다. 가장 놀라운 점은 일련의 다양한 기술이 프론트엔드와 데이터 계층에서 다양한 역할을 충족한다는 사실이지만, J힙스터는 여기서 멈추지 않는다. 스카폴드(Scaffold) 생성을 처리하고 Vue.js UI로 만든 몽고DB(MongoDB), 리액트(React)로 개발한 포스트그레스(Postgres) 등 이질적인 기술 스택에 CLI 도구 등 다양한 기능을 지원한다. 이 모든 것이 최신 스프링(Spring)/자바 미들웨어와 연결된다. 또한, J힙스터는 스프링 보안을 통해 보안을 강화하는 등 기존의 단점을 보완했고, 여러 최신 배치 옵션과 CI/CD 통합을 기본적으로 지원한다. 솔리드 많은 혁신적인 프론트엔드 자바스크립트 프레임워크 중 최고를 가려내는 것은 매우 어렵다. 페이스북이 지원하는 선두주자 리액트는 여전히 일정한 속도로 주목하지 않을 수 없는 새로운 기능을 쏟아내고 있는 혁신적인 프로젝트이고, Vue.js, 앵귤러(Angular), 스벨트(Svelte)는 모두 인상적이다. 우리가 무엇을 선택하든 누군가는 '프레임워크 X는 어때? Y를 더욱 잘 해'라고 이야기할 것이고 그 말은 언제나 옳다. 그럼에도 하나를 꼽지만, 일단 지난해에는 스벨트가 대상이었다. 올해는 아스트로(Astro), 퀵(Qwik), 솔리드(Solid)가 접전이었다. 아스트로는 다른 프레임워크에서 사용할 수 있는 섬의 개념을 통해 수치화에 대한 혁신적인 접근방식을 제공하고, 퀵은 처음부터 반응성 패러다임 전체를 과감하게 재창조했다. 최종적으로 우리의 선택은 솔리드다. 솔리드는 동급 최고의 성능을 제공하면서도 이해하기 쉬운 패키지로 제공한다. 레드우드 풀스택 자바스크립트 프레임워크를 선택하는 것은 순수한 프론트엔드 JS 프레임워크를 선택하는 것만큼 어렵다. 업계를 선도하는 Next.js는 성공에 안주하지 않았다. 여전히 한계를 초월하는 동력을 갖고 있다. 이와 동시에 스벨트키트(SvelteKit)와 넉스트(Nuxt) 등의 대안뿐 아니라 Blitz.js 등 새로운 출전자가 새로운 접근방식과 기법을 선보이고 있다. 다양한 새로운 프레임워크 중에서 유난이 눈에 띄는 것은 바로 다. 앱을 구성하는 방식에 대해 찬반이 강경하게 나뉜다. 레드우드의 공격적인 방식 덕분에 놀라울 만큼 바른 개발자 경험을 구성한다. 레드우드는 데이터 모델링 및 스카폴딩(Scaffolding) 등의 반복적인 요건에 대해 레일스(Rails) 같은 접근방식을 취하는 것 외에 보안과 추적 통합 등의 다른 실질적인 문제도 해결한다. 또한, 버셀(Vercel), 네틀리파이(Netlify) 등의 서버리스 플랫폼 등 다양한 배치 환경을 지원한다. Next.js 는 풀스택 자바스크립트 프레임워크의 개척자다. Node.js는 동일 구조 자바스크립트 애플리케이션에 문을 열었고 이를 기반으로 풀스택 자바스크립트를 실용적인 애플리케이션으로 발전시켰다. Next.js는 리액트 프론트엔드와 자바스크립트 서버를 단일 빌드 파이프라인으로 통합하는 단순한 약속에서 시작해 점점 더 확장하고 있다. 라우팅(Routing)부터 데이터 액세스, 보안, 서버측 렌더링까지 애플리케이션 개발의 많은 중요한 측면을 더 단순하고 일관성 있게 만들었다. 또한, Next.js는 서버리스와 엣지 등 다양한 배치 대상을 지원한다. 클라우드 인프라 기업 버셀(Vercel)은 이 지원을 활용해 백엔드와 프론트엔드를 연결할 때의 복잡성을 숨기는 자동화된 배치 솔루션을 개발했다. 와슴타임 Node.js가 자바스크립트 런타임(Runtime)에 제공하는 것과 유사하게 은 개발자가 안전한 샌드박스 실행, 네이티브에 가까운 성능, 여러 프로그래밍 언어와 플랫폼에서의 지원 등 웹어셈블리(WebAssembly)가 브라우저 내부에서 제공하는 모든 이점을 브라우저 밖에서 활용할 수 있도록 지원한다. CPU와 메모리 사용량 세부 조절, 크레인리프트(Cranelift) 코드 생성기를 통한 고속 실행, 새로운 웹어셈블리 기능 파악하기 등의 장점도 있다. 이전의 와슴타임 릴리즈 역시 기업의 실제 업무 현장에서 사용할 만큼 완성도가 높았지만, 1.0 버전은 더 빠른 와슴 모듈 인스턴스화, 더 스마트한 메모리 사용, 최적화된 스택 추적과 협력적 멀티태스킹을 통한 런타임 성능 개선 등 더 발전했다. 와슴타임은 중요한 변곡점에 놓여 있다고 해도 과언이 아니다. 파이스크립트 웹어셈블리의 오랜 약속 중 하나는 웹 브라우저에서 자바스크립트 외의 다른 언어를 사용할 수 있다는 것이다. 이런 약속을 실현하는 기술이 바로 다. 브라우저에서 완전한 파이썬(Python) 런타임을 지원해 웹 페이지에서 파이썬을 스크립트 언어로 사용할 수 있다. 심지어 넘파이(NumPy) 등의 일부 고급 라이브러리까지 지원하고 네이티브 HTML 프론트엔드를 통해 강력하고 복잡한 앱을 구성할 수 있다. 물론 백엔드에서 파이썬 서버도 필요 없다. 파이스크립트는 현재 테스트 단계로 단계이며, 일반적으로 시동 시간이 다소 걸린다. 하지만 파이스크립트를 통해 웹어셈블리의 미래를 엿볼 수 있다. 하드햇 블록체인 개발은 까다로운 것으로 유명하지만, 새로운 툴의 등장으로 조금씩 개선되고 있다. 그 중 하나인 은 훌륭한 오픈소스 프레임워크로, 코딩, 테스트, 이더리움에서의 댑스(Dapps) 및 스마트 컨트랙트 배치를 간소화한다. 확장 가능한 작업 실행자와 플러그인 프레임워크를 중심으로 개발돼 대부분 개발 워크플로를 처리할 만큼 충분히 유연하며, 로컬 이더리움 테스트넷(Testnet)과 통합된다. 원격 테스트넷과 상호작용 없이 코드를 배치하고 디버깅하는 데도 유용하다. 하드햇에는 솔리디티(Solidity)를 지원하는 비주얼 스튜디오용 기능이 포함돼 있으며, 이더리움 전용 테스트를 위한 차이(Chai) 확장기능을 제공한다. 이런 유용성 외에도 하드햇은 뛰어난 개발자 경험을 제공한다. 처음 실행해도 예상한 대로 작동하므로 더 만족스럽다. 오픈FGA 에 기초한 범용 인증 플랫폼에 대한 오쓰0(Auth0)의 오픈소스 구현이다. 역할 기반부터 관계 기반과 세분화된 인증까지 광범위한 인증 요건을 해결하고, 놀랍도록 다양한 성능과 유연성을 지원하는 패키지를 제공한다. 오픈소스 소프트웨어 커뮤니티의 인증에 중요할 뿐 아니라 오픈소스에 좋은 것이 기업에 좋다는 근본적인 전제, 즉 언어로써 코드의 자유에 대한 재확인 의미로도 중요하다. 센트리 보안과 함께 오류 및 성능 추적은 많은 앱에 있어서 필수불가결한 요건이다. 이런 문제에 있어 다소 안심할 수 있게 해주는 툴이 바로 다. 데이터를 수집하는 서버측 API부터 이를 관리하는 대시보드와 포괄적인 애플리케이션측 통합까지 애플리케이션, 서비스, API의 건전성을 모니터링하는 오픈소스 도구 전체를 제공한다. 이런 통합은 실제로 펄(Perl)부터 파이썬까지 예상할 수 있는 모든 스택에 적용된다. 그러면서도 사용하기가 매우 쉽다. 라이브러리를 가져오기만 하면 되며, 추가 코드로 비즈니스 로직을 구성할 필요가 없다. 또한 센트리는 프로젝트 추적기, 소스 관리 시스템, 배치 플랫폼 등 다양한 도구를 위한 통합 지점 역할도 한다. 앱스미스 는 백엔드 개발자가 최소한의 HTML과 CSS 코딩으로 관리자 패널, 서식, 대시보드 등의 소프트웨어를 사용자 정의할 수 있는 로우코드 프레임워크다. 이 플랫폼은 미리 구축된 UI 구성 요소와 재사용 가능 템플릿을 통해 프로젝트를 신속하게 시작하고 광범위한 API, 데이터 소스, 클라우드 서비스와 통합되며 클라우드 및 셀프 호스팅 배치 옵션을 지원한다. 앱스미스는 도커에서 1,000만회 이상 다운로드됐고, 깃허브에서 2만 1,000개 이상의 별을 받았다. 최근에는 4,100만 달러의 시리즈 B(Series B) 투자를 받기도 했다. 대표적인 활용 사례로는 고객 지원 도구와 의사소통 등의 내부 프로세스가 있다. 스핀네이커 는 데브옵스팀이 릴리즈를 자동화하고 카나리(Canary) 및 기타 배치 전략을 구현하는 데 도움이 되는 오픈소스 멀티 클라우드 연속 제공 플랫폼이다. 에어비앤비, SAP, 핀터레스트, 머카리(Mercari), 세일즈포스 등 220곳 이상의 기업이 스핀네이커를 사용하고 있고, 커뮤니티 기여자는 2,500명이 넘는다. 소규모 엔지니어링 기업도 스핀네이커를 성공적으로 활용하고 있는데, 예를 들어, 업웨이브(Upwave)의 20명 규모 엔지니어링팀은 주당 100회의 배치를 관리하며, 변경사항 시 리드 타임은 20분 미만이다. 주요 클라우드 서비스 업체가 스핀네이커를 지원하며, 개발자를 위한 많은 문서를 제공한다. 스핀네이커는 2020년 바이든 대통령 선거 캠프 등에서도 활용된 바 있다. 하이퍼트레이스 는 제멋대로 뻗어 나가는 클라우드 네이티브 아키텍처 전반에 걸쳐 다양한 서비스로부터 엄청난 양의 실시간 성능 데이터를 수집, 처리할 수 있는 오픈소스 분산형 추적 및 가관측성 엔진이다. 트레이서블(Traceable)이 아파치 카프카(Apache Kafk)를 기반으로 개발했다. 하이퍼트레이스는 애플리케이션과 마이크로서비스를 모니터링하고 여러 터치포인트의 분산형 트랜잭션을 추적하며 모든 정보를 서비스 지표와 애플리케이션 플로 지도로 만든 후 사용자 정의 대시보드에 표시한다. 하이퍼트레이스는 경로 기반 분석을 지원하는 것 외에 결과에 영향이 미치기 전에 애플리케이션 성능 병목을 선제적으로 해결하는 데 도움이 되는 실시간 경고를 제공한다. 기본적으로 집킨(Zipkin), 예거(Jaeger) 등의 인기 추적 형식을 지원하며 자바, 고(Go), 파이썬을 위한 네이티브 기기 에이전트를 제공한다. 그래비티  API 관리 플랫폼은 분산된 API를 중앙에서 관리, 관장, 보호한다. 오늘날의 이벤트 기반 API 및 마이크로서비스 세계에서는 비용과 복잡성을 관리하기 위해 더 필수적이다. 그래비티의 콕핏(Cockpit) 포털을 통해 가이드 액세스와 공개, 문서화, API 발견을 위한 기능이 풍부한 툴셋을 함께 제공하고, 온보드 API 디자이너는 개발 및 문서화 모델화를 위한 시각적 로우코드 접근방식을 지원한다. 작업 자동화는 오류를 최소화하고 디버깅 속도를 높여주며 배치를 간소화한다. 보안 액세스와 감사 기능 덕분에 인증 및 승인 서비스를 통해 종점을 보호할 수 있다. 기업 라이선스를 구매하면 추가적인 디자이너 및 생산 게이트웨이 기능을 쓸 수 있고, 경고 엔진, 이상 감지, 실시간 분석 등의 기능도 활용할 수 있다. 오픈텔레메트리 등의 유료 서비스가 등장했다. 물론, 이런 새로운 도구의 확산의 단점은 모두 작동 방식이 조금씩 다르다는 점이다. 는 일련의 표준 API와 도구를 통해 가관측성 시스템 사이의 공백을 메운다. 생성, 배출, 수집, 처리, 원격 측정 데이터 내보내기를 제공업체를 가리지 않고 통합한다. 한 업체의 가관측성 제품으로 시작한 후 다른 제품으로 변경하고 싶었던 경험이 있다면, 오픈텔레메트리가 정답이다. 몇 가지 사소한 구성 변경 만으로 이를 구현할 수 있다. 그라파나 의 개발자는 모든 것을 관리하는 하나의 오픈소스 대시보드를 만들기 위해 노력했다. 그 결과 완전한 상용 제품 혹은 부분 유료 옵션이 있는 오픈소스 중에서 그라파나와 유사한 제품은 거의 찾기 힘들다. 그라파나 8.0은 프로메테우스(Prometheus) 경고 시각화와 그라파나의 네이티브 경고를 병합하고, 프로메테우스 얼러트매니저(Prometheus Alertmanager) 처리로 이를 강화했다. 그라파나 9.0은 프로메테우스 PromQL과 로키(Loki) LogQL 쿼리 언어를 위한 쿼리 구축 도구를 추가하며, 단순한 설명 대신 썸네일을 통해 대시보드를 미리 확인할 수 있게 했다. 기업용 버전의 경우 역할 기반 액세스 관리까지 지원한다. Dapr 분산형 애플리케이션은 새로 서비스를 구축할 때마다 연결 보안, 가관측성 구성, 상태 처리, 메시징 처리 등 같은 리스크를 반복해야 한다. 이 모든 것을 몇 번이고 계속 수행해야 하며, 특히 서로 다른 서드파티 서비스를 사용하는 경우가 많기 때문에 코드에 좋지 못한 계층이 추가되고 필요하지 않은 외부 서비스가 연계되는 경우가 종종 있다. 이런 어려움과 중복을 해결하기 위한 CNCF(Cloud Native Computing Foundation)의 프로젝트가 바로 이다. 애플리케이션의 보조재처럼 사용해 마이크로서비스 연결성의 복잡성을 줄여준다. 앱은 Dapr과 통신하고 Dapr이 나머지를 처리하기 때문에, 예를 들어 AWS에서 운용하고 키네시스(Kinesis)를 사용하거나 구글 클라우드에서 운용하고 펍섭(PubSub)을 사용할 수 있다. 결과적으로 애플리케이션 로직에 더 많은 시간을 투자하고 모든 연결 코드에 소요되는 시간을 절약할 수 있다. 레드판다 는 시스타(Seastar) 비동기 프레임워크와 래프트(Raft) 합의 알고리즘을 사용해 분산형 로그를 구현한다. C++로 작성된 카프카를 위한 플러그인 대체제이기도 하다. 최대 10배 낮은 평균 지연 속도와 최대 6배 빠른 카프카 트랜잭션을 제공하면서 더 적은 리소스를 사용할 수 있다. 레드판다는 주키퍼(ZooKeeper)나 JVM을 사용할 필요가 없으며 소스는 깃허브에서 BSL(Business Source License)로 제공된다. 또한, 레드판다는 비동기 비공유 코어당 스레드 모델을 사용하며 얽매임이 없고 환경 전환이 최소화되며 TL(Thread-Local) 메모리 액세스를 지원한다. 레드판다는 카프카 프로토콜을 넘어 인라인 웹어셈블리 전환과 지리적 복제 계층화 스토리지/쉐도우(Shadow) 인덱싱까지 점점 더 발전하고 있다. 아파치 아이스버그 는 빅데이터에 SQL 테이블의 신뢰성과 간결성을 제공하며, 트리노(Trino), 스파크(Spark), 소나(Sonar), 프레스토(Presto), 하이브(Hive), 플링크(Flink), 임팔라(Impala) 등의 엔진이 동시에 같은 테이블을 안전하게 작업할 수 있도록 지원한다. 아이스버그는 유연한 SQL 명령을 지원해 새로운 데이터를 병합하고 기존의 열을 업데이트하며 표적화 된 삭제를 수행한다. 읽기 성능을 높이기 위해 읽기 데이터 파일을 열심히 재작성하거나 더 빠른 업데이트를 위해 삭제 델타를 활용할 수 있다. 또한, 아이스버그는 기본적으로 스키마 혁신, 자동 파티셔닝, TTQ(Time Travel Query), 버전 롤백, 데이터 단축을 지원한다. 아파치 드루이드 는 고속 쿼리, 높은 동시 실행, 카프카, 키네시스 등의 플랫폼의 스트림 수집에 대한 실시간 및 이력 인사이트를 제공하는 실시간 분석 데이터베이스이다. 이 기술은 10년 치의 릴리즈, 400명 이상의 기여자, 데이터 웨어하우스, 시계열 데이터베이스, 검색 시스템의 아이디어를 결합한 분산형 데이터 스토어 아키텍처에 기반을 두고 있다. 넷플릭스, 세일즈포스, 월마트(Walmart) 등 수천 개 기업이 드루이드로 분석 애플리케이션을 지원하고 있다. 사용 사례에는 클릭스트림 분석, 위험 및 사기 분석, 공급망 분석이 포함된다. 초보자라면 아파치 드루이드 소개서와 성공 스토리 전자책을 먼저 살펴볼 것을 권한다. JAX 역시 구글이 개발한 프로젝트이며, 이 2가지 기술을 결합해 속도와 성능 측면에서 상당한 이점을 제공한다. GPU 또는 TPU에서 구동할 때 JAX는 넘파이를 호출하는 다른 프로그램을 대체할 수 있지만 프로그램은 훨씬 빠르게 구동한다(오토그래드 엔진은 네이티브 파이썬과 넘파이 코드를 자동으로 구분할 수 있다). 또한, 신경망에 JAX를 사용하면 텐서플로우 같은 대형 프레임워크를 확장하는 것보다 새로운 기능을 훨씬 쉽게 추가할 수 있다. nbdev 주피터(Jupyter) 또는 구글 콜랩(Google Colab) 등의 환경을 사용하는 노트 프로그래밍의 잘 알려진 비밀은 역대 최악의 스파게티 코드를 만든다는 것이다. 데이터 사이언티스트가 셀마다 옮겨 다니면서 유지관리가 불가능할 정도의 혼란을 유발한다. 일각에서는 노트 프로그래밍이 과거의 고투(GOTO)만큼 유해할 수 있다고 지적하기도 한다. 는 이런 노트 프로그래밍의 단점을 줄이면서 장점을 극대화하는 대안이다. fast.ai의 깃 친화적 주피터 노트 기반 개발 플랫폼으로 데이터 사이언티스트에게 필요한 탐구 자유를 지원할 뿐만 아니라 같은 노트 안에서 문서화와 심지어 적절한 텍스트를 통해 모듈을 손쉽게 생성하는 기능을 지원한다. 넷플릭스와 리프트(Lyft), (당연히) fast.ai 등의 기업에서 사용하고 있는데 특히 넷플릭스는 nbdev를 사용해 새로운 버전의 fast.ai 라이브러리를 만들기도 했다. 액셀러레이트 는 기본적으로 단순한 구성 전환을 통해 TPU 장치나 마이크로소프트의 딥스피드(DeepSpeed) 최적화 등의 기능을 사용할 수 있다. 액셀러레이트 라이브러리가 모두 처리하는 분산형 훈련, 공유 병행성, 그래디언트(Gradient) 축적 등의 기법을 사용해 수십억 개의 파라미터 규모로 딥 러닝 모델을 훈련할 수 있다. 그동안 대형 모델의 훈련은 업계 대기업의 전유물이었는데, 액셀러레이트가 파이토치(Pytorch) 생태계의 일부로 자리잡으면서 다양성에 대한 기대가 커지고 있다. 스테이블 디퓨전 은 엄청난 품질의 이미지를 만들어내는 텍스트-이미지 AI 모델이다. 2개월이 채 되지 않은 야생동물 같은 프로젝트지만, 전 세계의 열렬한 지지자가 이미 오리지널 버전을 개선해 이미지 생성 속도를 높이고 메모리가 적은 GPU에서 구동하도록 개선했다. 인페인팅(In-painting) 및 아웃페인팅(Out-painting) 지원이 추가됐고, 심지어 스테이블 디퓨전을 M1 기반 맥북에서 구동할 수도 있다. 와는 딴판이다). 이런 모델은 분명 데이터세트 큐레이션(Curation), NSFW 이미지 생성 기능에 대한 우려로 이어지는 것이 사실이다. 그러나 앞으로의 연구 발전과 성과를 고려하면 일부 대기업보다는 모든 사람이 이 기술을 사용할 수 있도록 하는 것이 분명 더 낫다. 일루터AI 가 개발한 새로운 200억 개 파라미터 자연어 처리 모델이다. 해당 개발사는 이전에 60억 개 파라미터 모델인 GPT-J를 공개하기도 했다. 이 모델은 1,750억 개의 파라미터를 가진 오픈AI의 GPT-3와 비교해 작아 보일 수 있지만 LAMBADA, 위노그랜드(Winogrande), 헬라스웩(Hellaswag) 등 데이터 세트를 사용해 강력한 성능을 구현했다. GPT-J를 이용하면 문서를 완성하고 번역, 분류하는 등 더 발전된 NLP 작업을 수행할 수 있다. 일루터AI가 이런 강력한 모델을 오픈소스화할 수 있는 이유는 무엇일까? 해당 프로젝트의 설립자 중 한 명인 코너 리히는 “우리는 AI를 우리처럼 생각하지 않는 이상한 외계인이라고 생각해야 한다”라고 말했다. 일루터AI의 목표는 이 기술을 가능한 많은 연구원에게 제공해 통제하는 방법을 찾는 것이다. editor@itworld.co.kr

구글 픽셀 워치 리뷰 | 배터리만 제외하면 애플 워치의 진정한 라이벌

"일만 하는 IT 부서?" 생산성 증명하고 성과도 포장해야

'완전히 새로워진' 아이패드 10세대 사양 집중 분석

“보급형 VR 기기 시장 이끌까?” 새로 나올 ‘메타 퀘스트 3’에 대한 모든 것

최우선 순위 전략으로 자리 잡은 '지속가능성'과 2023 가트너 10대 전략 기술

스트리밍 게임기 시장에 뛰어든 레이저의 '레이저 엣지' 분석

1/2

오픈소스 Matt Asay

글로벌 칼럼 | 오픈소스계의 트위터 ‘마스토돈’에 대한 착각

트위터를 마스토돈(Mastodon)으로 대체하자고 설득하는 모습을 보고 있으면, 오픈소스 업계에서 오랫동안 자주 빠지는 함정에 다시 걸려들고 있다는 인상을 받는다. 이런 사람들은 대부분 더 많은 기술, 특히 더 많은 오픈소스 기술로 뭐든지 해결해보려는 태도를 가지고 있다. 오픈소스 소셜 네트워크 ‘마스토돈’의 문제점 필자는 오픈소스에 거의 20년 동안 몸담았다. 오픈소스는 나에게 집이자 국가와 같은 곳이다. 그러나 우리 오픈소스인들은 편리함보다 선택의 특권을 더 중시하는 불행한 성향을 갖고 있다. 마스토돈 사례가 대표적이다. 마스토돈은 스스로 ‘판매하지 않는 소셜 네트워킹’을 한다. 오픈소스이며 탈중앙화된 소셜 네트워크로서 사용자들에게 “원하는 대로 복사하고 연구하고 변경하라”고 한다. 또한 “각 마스토돈 서버는 완전히 독립적인 개체”라고 한다. 그냥 트윗(마스토돈 용어로는 ‘툿(toot)’)을 올리고자 하는 소셜 네트워크 이용자들에게 이런 기술 구조는 전혀 중요하지 않다. 거기다 마스토돈에는 일반 사용자가 싫어할 만한 요소가 다음과 같이 두 가지 있다. 오픈소스 코어 그룹을 제외한 거의 모든 사람들은 거부감을 가질 수 있는 부분이다. 마스토돈은 사용자 자신의 인프라에 구축되어 온라인상의 다른 마스토돈 서버와 상호 팔로우할 수 있으며 사용자 이외의 누구의 통제도 받지 않는다. 각 서버는 자체적인 규칙과 규정을 생성하며, 이러한 규칙 및 규정은 기업형 소셜 미디어와 같은 하향식이 아니라 로컬에서 강제된다. 마스토돈에 가입할 때는 서버를 선택해야 한다. 그런데 서버 선택 기능을 이해하는 과정은 트위터를 쭉 사용해온 사용자나 기술 전문가에게도 어려울 수 있다. 마스토돈에는 ‘어떤 서버를 선택하든 괜찮다’는 안내 메시지와 함께 서버 선택을 통해 자신의 관심사에 맞는 커뮤니티를 선택하는 방법에 관한 장황한 사용 안내가 나온다. 여기서 말하는 ‘관심사’의 범위는 꽤 좁다. 어쨌든 사용 안내가 필요하다는 사실 자체가 이미 신규 사용자 유입에 걸림돌이 된다. 생물학자이자 교수이자 마스토돈 사용자인 폴 크뇌플러는 “잘 동작하는 서버와 그렇지 않은 서버의 편차가 큰 것으로 보인다. 또한 특정 서버에서 더 많은 문제가 발생한다. 이용하려면 따로 신청해야 하는 서버가 많은데, 납득하기 어려운 부분이다. 탈중앙화된 ‘구조’는 일을 불편하고 난잡하게 만든다”라는 를 남겼다. 심지어 크뇌플러 박사는 어려운 시스템과 구조를 평소에 잘 이해하는 사람인데도 마스토돈을 이용하는 과정에서는 여러 장애물을 만났다. 비단 크뇌플러만의 일은 아니다. 마스토돈 지지자들은 마스토돈을 “머스크 없는 트위터”로 홍보하고 싶을 수 있지만, 그건 확실히 아니다. 마스토돈은 서버와 검색 상태에 따라 여러 서버에 걸쳐 검색될 때고 있고, 되지 않을 때도 있다. 특정 개인에게 어느 서버가 잘 맞는 서버인지 명확하지 않고, 나중에 서버를 바꾸기가 편리한 것도 아니다. 사용자들이 마스토돈 플랫폼의 기저에 있는 기술에 대해 생각할수록 마스토돈을 사용할 가능성은 낮아진다. 결국 마스토돈 사용자는 기술 구조에 대해 먼저 생각해야 한다. 사람들은 그저 대화를 원하는 것인데, 그 대화를 하기 위해 사용되는 기술에 대해 먼저 생각해야 하는 셈이다. 특히 마스토돈의 일부 인기 서버가 사용자 유입에 따른 부하로 먹통이 된 상황에서는 더욱 그렇다. 물론 트위터도 초창기에 사용자 폭주로 시스템 마비되고 점검 중이라는 공지가 수시로 뜨기도 했다. 그러나 이걸 해결하는 방식은 마스토돈만의 문제다. 각 서버가 얼마간 독립적으로 문제를 해결해야 하기 때문이다. 마스토돈 설계자들은 이것을 기능이라고 생각하지만, 기능이 아니라 버그다. 때론 자유도보단 편의성이 더 중요하다 마스토돈의 기술은 일반적인 기술과 비교해 보자. 클라우드 업계 초기를 생각해보면, AWS와 같은 기업은 인프라 관리, 즉 ‘차별화되지도 않는 힘든 일’에 대해 더 이상 걱정할 필요가 없다는 점을 오랜 기간 강조했다. 하지만 개발자들은 여전히 얼만큼의 스토리지가 필요한지, 어느 정도의 프로세싱 성능을 사용할 것인지 등을 웬만큼 파악해야 했다. 클라우드는 미래의 워크로드를 지원하기 위해 물리적 서버를 구매하는 데는 문화를 바꿔 놓긴 했지만, 개발자들은 여전히 너무 많은 계획을 준비해야 했다. 최근의 클라우드 서비스를 살펴보자. 방향은 명확히 서버리스, 즉 기반 기술에 대해 신경 쓸 필요가 없는 세계를 향하고 있다. 개발자가 애플리케이션을 만들면 인프라 쪽은 저절로 된다. 유독 ‘자유성’에 더 집착하는 사람들은 서버리스를 두고 “인류 역사상 가장 나쁜 형태의 사유 종속”이라고 표현한다. 하지만 엔터프라이즈 업계는 그런 주장에 별로 신경을 쓰지 않는 것 같다. 이들은 ‘어려운 경제 환경에서 고객 요구사항을 충족하는 데 도움이 되는 애플리케이션을 제공하는 것’과 같은 다른 부분에 더 신경을 쓴다. 트위터와 마스토돈 이야기로 돌아와서, 트위터의 예전 좋았던 시절을 얼마든지 이상화해서 떠들 수 있지만, 사실 트위터는 오래전부터 진흙탕 싸움이 벌어지는 곳이었다. 어떤 사람은 이를 보고 “트위터는 지옥의 사이트가 아니라 지옥 자체”라고 묘사했는데, 필자는 어느 정도 동의한다. 트위터는 시작부터 분노를 쏟아내는 무례한 사람들 천지였다. 사람들은 원래 화를 내고 무례해질 수 있는데, 얼굴을 보지 않고 이야기할수록 그런 분노를 잘 드러내곤 한다. 혹시 마스토돈이 오픈소스이며 탈중앙화 방식이라는 이유로 무례한 사람을 피할 수 있다고 생각하는가? 리눅스 커널 메일링 리스트를 충분히 경험해보아라. 생각이 바뀔 것이다. 기술 전문가들은 모든 것을 직접 선택하는 일종의 유토피아를 찬양한다. 하지만 대부분 사람들이 원하는 것은 선택지는 많이 필요 없고 오히려 편리함이 잘 가미된 기술을 원한다는 것을 잊지 말아야 할 것이다. 우리는 서버를 선택하고 싶지 않고, 뒷단 기술 구조에 대해 생각하고 싶지 않다. 그저 대화, 트윗, 툿을 하고싶을 뿐이다. editor@itworld.co.kr

오픈소스 2022.11.23

글로벌 칼럼 | 오픈소스계의 트위터 ‘마스토돈’에 대한 착각

마스토돈

VRㆍAR 2022.11.23

칼럼 | 엔비디아가 쏘아 올린 옴니버스, 완전 자동화 이룰까

엔비디아

클라우드 2022.11.23

블로그 | "결국 복잡성ㆍ비용이 관건"⋯2023년 클라우드 컴퓨팅 전망

클라우드

AIㆍML 2022.11.22

"업무 자동화, 직원 무시하면 위험 요소로 작용할 것"

IT 전략

스마트폰 / 애플리케이션 David Price

사용자 충성심이 바닥나는 순간 "트위터를 반면교사로"

IT 담당 기자의 눈으로 볼 때, 마치 충돌 직전의 차량처럼 느린 동작으로 다가오는 트위터의 파국 사태에는 섬뜩한 매력이 있다. 트위터를 인수한 새 주인은 직원과 사용자의 충성도를 얻는 데에는 오랜 시간이 걸리지만 잃는 것은 한순간에 지나지 않음을 뼈저리게 깨닫고 있다. 억만장자는 친구에게 전화를 걸어 보석금을 부탁하거나 당장 공항까지 차를 태워 달라고 부탁할 일이 거의 없다. 따라서 충성심의 속성이나 한계를 이해하는 일에는 불리하다고 추측된다. 그러나 사실 충성심은 희한하게 회복 탄력성이 있는 동시에 무서울 정도로 취약한 성질이다. 다른 많은 것이 그렇듯, 충성심도 서서히 바닥을 드러내다가 갑자기 없어진다. 애플 같은 다른 기업이 트위터처럼 추락할 가능성은 작다. 특히 애플 경영진은 전반적으로 트위터 지도부처럼 종잡을 수 없는 사람들은 아니기 때문이다. (팀 쿡이 개인적인 생각을 참지 못하고 괴상한 단문 메시지로 공개해 주가가 곤두박질치는 일은 상상하기 어렵다.) 그러나 애플 경영진 중 누군가는 트위터를 예의 주시하고 있기를 간절히 바란다. 사용자의 충성심을 놓고 비슷한 모험을 하는 애플은 잃을 것이 훨씬 더 많은 판국이기 때문이다. 애플은 그 어떤 경쟁사보다 사용자의 인정 의존도가 높다. 다른 기업은 광고와 데이터 수집을, 또는 하드웨어를 최고 사양이나 최저가로 판매하는 방식으로 사업 모델을 구축했지만, 애플은 경험에 집중했다. 애플 제품은 인기도 많고 품질도 우수하지만, 가장 중요한 것은 사용자가 생활 양식까지 산다고 생각한다는 점이다. 냉소적으로 들릴지 모르지만 그런 의도는 아니다. 애플과 그 추종자가 가끔 종교 광신자 같은 경향을 보여 눈에 거슬릴 때도 있다. 그러나 애플 사업 모델의 성패는 무엇보다 고객이 ‘애플은 멋지고 윤리적인 회사다, 애플 제품을 구입하는 사람도 멋지고 윤리적이다’라고 믿게 만드는 것에 달려 있다. 이렇듯 흔치 않은 사용자 중심 모델로 타사에서는 기대할 수 없는 행동을 보이기도 한다. 예를 들면, 테러리스트로 추정되는 자 소유 아이폰의 잠금 해제 요청을 거부하고, 성소수자에게 불리한 법안 통과에 반대하는 활동을 벌이며, 직원 혹사와 강제 노동 의혹이 여러 차례 제기된 중국 내 제품 생산을 서서히 줄이고 있다. CEO 팀 쿡은 기후 변화 회의론자에게 보유한 애플 주식을 팔라고 한 적도 있고 한 투자자에게는 “애플이 시각 장애인을 위한 기기를 개발한다면 빌어먹을 투자수익 따위는 전혀 고려 대상이 아니다”라고 말한 것으로도 유명하다. 팀 쿡이 잠재 고객의 비위를 맞추기 위해 냉소적인 발언을 했다는 것은 아니다. 단지 멋진 사업 모델을 운영하는 기업이라는 만인의 신뢰는 강력한 윤리적 나침반을 지닌 CEO를 둘 만큼 애플에 중요하다는 의미다. 사용자를 당연하게 여길 때의 문제점 사용자 호감은 변덕스러운 성질이 있고 당연히 여기기 쉽다는 것이 문제다. 애플이 사용자의 호감을 당연한 것으로 여긴다는 점은 우려가 된다. 아닌 게 아니라 지난 몇 년간 애플 지도부는 회사가 사용자 행복을 항상 우선하지 ‘않는다면’ 돈을 더 벌 수 있지 않을까 궁리하기 시작한 것이 느껴지고 사용자도 그 변화를 눈치채기 시작했다. 일례로 가격이라는 요소가 있다. 애플 제품은 항상 높은 가격으로 유명했지만, 과거에는 제품이 비용을 대체로 정당화했다. 비쌌지만 그만한 가치가 있었다. 또한 각 제품 카테고리마다 최소한 하나 이상의 보급형 저가 제품을 넣는 성의를 보였다. 그러나 올해는 비싼 제품으로 고객을 유도하기 위해 보급형 모델을 아예 없애거나 기능 일부를 빼 버렸다. 보급형 9세대 아이패드는 더 비싸진 10세대 모델로 대체된 데다 출시 1주년에 전통적으로 실시된 가격 인하마저 없어졌다. 맥북 에어도 마찬가지다. 해외에서의 판매 가격 인상에 관해서는 차라리 말을 아끼는 것이 낫다. 이런 행태가 예상되는 회사는 급히 돈이 필요한데 고객이 가격 인상에 반대할 처지가 아니라고 판단한 회사다. (즉, 스트링어 벨이 설명하듯 비탄력적인 제품을 판매하는 회사다.) 틀림없이 누군가가 가격을 올리자고 했을 것이다. 고객이 아이패드를 안 사고 배길 것인가? 어쩌면 애플은 지금 그 질문의 답을 알아가고 있는지 모른다. 그러나, 자사 제품을 사야 하는 구체적인 이유로 사용자 경험을 지목해 놓고도 등한시하는 회사에는 더 심각한 문제가 발생한다. 애플은 오랜 세월 동안 사용자 개인정보 보호에 가장 적극적이라고 자처해 왔다. 사용자 개인정보 보호 실현에 안성맞춤인 애플의 사업 모델 덕분이었다. 그러나 이제 애플은 개인정보보호 문제로 소송을 당한 상태다. 앱 스토어에서 개인정보보호 설정을 무시한 채 사용자 데이터를 수집했다는 혐의가 제기된 것이다. 앱 스토어에 광고가 점점 만연하는 현상도 애플의 우선순위에 심각한 위험 신호다. 사용자를 돕는 것과 광고 수익 중 어느 쪽을 더 신경 쓰고 있는지는 자명하다. 사용자가 애플을 외면한다면 애플 경영진이 스스로 실수를 저지를 리 없다는 의견도 어느 정도 이해는 간다. 애플은 얼마 전에 또 한 번 기록을 경신한 실적을 발표했다. 그런 실적을 안겨준 고객이 어디 갈 리는 없지 않은가? 아마도 그럴 것이다. 하지만 당연한 것을 당연한 것으로 여기지 않아야 한다. 오랜 세월 동안 트위터 사용자는 트위터 사이트의 거의 모든 점을 불평하면서도 ‘이 망할 놈의 사이트에 중독되어 끊을 수 없다’고 농담해 가면서 계속 사용해 왔다. 아마도 일론 머스크는 가격을 올리고 기능을 잔뜩 바꾸고 거의 모든 사람을 모욕해도 사용자가 계속 트위터에 붙어 있을 것으로 생각했을 것이다. 그 예상이 적중할 수도 있다. 그러나 이 기사를 작성하는 중에도 대규모 이탈을 준비 중인 엄청난 수의 일반 사용자가 타사 SNS로 연결되는 링크를 올리며 트위터에 작별을 고하고 있다. 남의 일이 아니다. 애플 추종자도 충성심은 높지만 변화를 인지하고 있다. 그러다 어느 날 갑자기 지금까지의 충성심을 버리기로 마음먹을 수도 있다. editor@itworld.co.kr

스마트폰 2022.11.22

사용자 충성심이 바닥나는 순간 "트위터를 반면교사로"

충성심

모바일 2022.11.21

블로그ㅣ‘해묵은 앱’을 정리해야 하는 이유

애플리케이션

클라우드 2022.11.21

글로벌 칼럼 | 클라우드 예산이 감소했을 때 참고하면 좋은 대응법

클라우드

디지털 디바이스 2022.11.18

블로그 | “가랑이 찢어질라” 애플에는 아직 ‘뱁새’인 스냅드래곤8 2G

스냅드래곤

Nick Hodges

칼럼ㅣ"개발자 생산성 측정, 객관적 지표 필요"

소프트웨어 개발팀의 강점은 개발자 개인이다. 각 개발자의 강점은 팀이다. 약 10년 전 필자는 라는 블로그 게시물을 썼다. 글에서 개발자의 생산성을 측정하기 위한 여러 객관적인 시도, 예를 들면 코드 라인, 기능 포인트 등을 논의했다. 아울러 몇 가지 주관적인 조치도 제안했다. 하지만 결론은 KPI를 사랑하는 관리자의 바람에도 불구하고 개별 소프트웨어 개발자의 생산성을 측정할 수 있는, 실행 가능한 방법은 없다는 것이었다. 10년 전에 쓴 글을 언급하는 이유는, 그 이후 몇 년 동안 상황이 크게 달라졌기 때문이다. 글을 썼을 시점에는 깃(Git)과 머큐리얼(Mercurial) 모두 유명하고 인기 있는 소프트웨어 소스 제어 시스템이었다. 당시 필자는 소프트웨어 관리자였고, 마이크로소프트의 비주얼 소스 세이프(VSS; 현재는 개발 중단된 소스 관리 프로그램)을 바꾸기로 하면서 윈도우에 더 친화적이었던 머큐리얼(Mercurial)을 선택했다. 잘못된 선택이었다. 당시에는 몰랐지만 이후 깃(Git)이 사실상의 버전 관리 표준으로 자리 잡았기 때문이다. 그 결과, 깃 저장소를 중심으로 가내 산업이 생겨났다. 깃허브(GitHub)는 마이크로소프트가 미화 75억 달러를 지불한 거대한 사업이다. 이제 많은 기업이 깃의 코드에 관한 측정 기준을 제공한다. 그리고 이러한 기업의 대다수가 소프트웨어 개발자의 생산성을 측정할 것이라고 주장한다. 지표 제시 만약 개발자 생산성을 측정하는 게 가능하다는 것을 인정한다면 그렇게 해야 하는지 물어봐야 한다. 그렇게 하고 싶은 욕구는 확실하긴 하다. 관리자는 유능한 개발자가 누구인지 알고 싶어 하며, 성과 평가 시 도움이 될 지표를 원한다. HR은 성과를 문서화하길 원한다. CEO는 지출이 효과적으로 사용되는지 알고 싶어 한다. 개별 개발자의 생산성을 측정하기 위해 새로운 도구를 사용하더라도 이러한 측정 기준은 조작될 가능성이 높다. 일일 커밋 수 또는 첫 번째 PR 코멘트까지의 평균 시간이 다른가? 이러한 지표로 개별 개발자를 측정하면 개발자는 확실하게 이를 개선할 수 있다. 하지만 어떤 대가를 치르게 될까? 아마도 팀 생산성을 희생할 가능성이 높다. 필자의 옛 CEO는 소프트웨어 개발이 팀 스포츠라고 말하곤 했다. 만약 개별 개발자가 어떤 측정 기준에서든 서로 비교된다면, 특히 돈과 승진이 걸려있다면 서로 경쟁하기 시작할 것이다. 그리고 서로 경쟁하는 사람들의 집단은 팀이 아니다. 소프트웨어 비즈니스에서 일을 해내는 것은 개별 개발자가 아닌 팀이다. 그런 맥락에서 소프트웨어 개발은 흥미롭다. 실제 코딩은 개인이 집중할 때 가장 잘 수행되지만 코드가 작성되기 전후에 이뤄지는 팀 작업은 프로젝트를 성공적으로 수행하는 데 크게 기여한다. 팀을 측정하다 개발팀은 코드를 작성하기 전에 프로젝트의 설계 및 구축을 논의한다. 개별 개발자가 코드를 작성할 때 질문에 답하고 인사이트를 제공하는 팀원의 도움을 받는 경우가 많다. 모든 팀 구성원은 코드를 검토하면서 수행된 작업을 확인하고 승인한다. 모든 사람은 일을 성공시키기 위해 함께 노력한다. 그렇기 때문에 개별 개발자의 생산성을 측정하는 게 아니라 팀의 생산성을 측정해야 한다. 공동의 목표를 향해 나아가는 팀으로서 함께 일하는 개발자야말로 관리자가 진정으로 원하는 것이다. 팀은 팀 지표를 개선하면 성공에 가깝게 갈 수 있다는 점을 알고 있다. 적절한 일에 집중하고, 적절한 측정 지표를 주시하면 팀은 개선된다. 팀은 생산성을 향상시키길 원한다. 또 나아지길 원한다. 아울러 (성과물을) 제공하길 원한다. 팀 기반 지표를 측정하면 이러한 작업을 수행하는 데 도움이 된다. 10년 전 필자는 개발자 생산성을 측정해야 하는지 또는 측정할 수 있는지 물었다. 하지만 잘못된 질문이었다. 개별 개발자는 팀만큼만 강하다. 팀 지표를 적절하게 측정하면 팀은 더 나은 결과와 더 나은 소프트웨어를 얻을 수 있다. 개인을 측정하는 대신, 팀이 함께 무엇을 하는지 측정해 소프트웨어를 더 좋고 빠르게 만들도록 장려해야 한다. * Nick Hodges는 파사주(Passage)의 Developer Advocate다. ciokr@idg.co.kr

2022.11.18

칼럼ㅣ"개발자 생산성 측정, 객관적 지표 필요"

개발자

보안 2022.11.18

블로그 | XDR은 보안 과정이지 고정된 개념이 아니다

XDR

개발자 2022.11.18

개발자 개인의 성과 평가는 의미 없다…팀 단위 성과에 집중하라

개발자

맥OS 2022.11.17

블로그 | 애플이 맥 미니를 뒷전에 두면 안 되는 이유

맥미니

기업 문화 Mike Elgan

글로벌 칼럼ㅣ‘생산성’ 말려 죽이기, 배후에는 불확실성이 있다

모두가 ‘생산성’에 집착했던 시절을 기억하는가? 이는 점차 시대에 뒤떨어지면서 최근 몇 년 동안 크게 논의되지 않았다. 하지만 이제 다시 주목해야 할 때다. 올해 생산성이 추락했기 때문이다. 올해 2분기 미국의 비농업 부문 생산성이 크게 떨어졌다. 관련 통계를 집계한 이래 최대폭의 하락이다(3분기에는 소폭 회복했다). 이 같은 생산성 감소는 원격근무/재택근무 트렌드에 후광을 비춰주는 것처럼 보인다. 단순하게 보면 팬데믹으로 인해 재택근무를 했을 때는 생산성이 높아졌다가, 다시 사무실 출근을 하기 시작하면서 생산성이 떨어졌기 때문이다. 물론 필자는 원격근무를 강력하게 옹호하는 입장이지만, 그렇다고 해도 이 결론은 잘못됐다고 생각한다. 우선, 최근 발생한 모든 상황이 얼마나 이례적인지 고려한다면 직원과 기업 간의 관계에 무슨 일이 일어나고 있는지 실질적으로 평가하기란 사실상 어렵다. 또 팬데믹은 기업과 직원 모두에게 예상하지 못했던 규모의 원격근무를 가져왔다. 코로나19 사태와 봉쇄조치는 많은 사람에게 꽤나 전례 없는 경험이었다. 그리곤 이내 원격근무자들은 재택근무에 익숙해졌다. 이제 몇몇은 사무실로 다시 복귀하고 있다. 즉, 직원 경험(EX)이 2년 반 동안 새로운 상황이었던 셈이다. 생산성이 떨어진 이유 일단 이번 생산성 추락의 원인이 사무실 출근은 (거의 확실하게) 아니다. 사무실에서 일하는 사람이 훨씬 더 많았던 팬데믹 이전에 생산성은 훨씬 더 높았다. 필자가 보기에 가장 유력한 원인은 경영진이 새로운 업무 현실에 적응하지 못했다는 것이다. 좋은 예는 많은 기업이 (집에서 근무하는 직원들의) 근무태만을 우려해 감시 소프트웨어를 배포했다는 사실이다. 이를 ‘편집증적 점검(productivity paranoia)’이라고 한다. 그 결과, 집에서 독립적으로 그리고 자율적으로 근무하는 데 익숙한 직원들에게 사무실은 감시 소프트웨어의 ‘감시’를 받는 집에서 일하는 것과 매우 흡사해졌다. ‘편집증적 점검’에 대한 인간의 자연스러운 반응 그리고 겉으로 보이는 생산성에만 초점을 맞춘 대면/소프트웨어 기반 모니터링 및 감시는 이른바 ‘생산성 극장(productivity theater)’으로 이어진다. 즉, 직원들이 일을 효율적으로 하는 것보다 ‘겉으로 봤을 때 열심히 일하는 모습’에 더 집중한다는 이야기다. 대면 또는 소프트웨어 기반 모니터링(‘마이크로관리’라고 하기도 한다)은 직원들의 권한을 박탈하고 (직원들의) 초점을 실질적인 것에서 인지되는 것으로 바꾼다. 새로운 업무의 세계에도 역기능(혹은 버즈워드)이 있기 마련이다. 이를테면 조용한 퇴사(quiet quitting), 대퇴직(Great Resignation), 그리고 이제는 생산성 극장(productivity theater)이다. 안타깝게도 이러한 역기능은 생산성 극대화라는 목표를 버리고 직원들의 노력을 감소시키는 것으로 보인다. 하지만 이 모든 것의 배후를 주의 깊게 살펴보면 야심에 부푼 노력이 더 나은 삶을 보장하는 게 아니라 (오히려) 위협한다는 심오하고 새로운 믿음을 발견할 수 있을 것이다. 그렇다. 직원들은 이제 상사의 편집증적 점검을 달래기 위해 생산적인 척하는 것보다 워라밸이 있는 삶을 사는 데 더 집중할 가능성이 높다. 생산성을 향상시키는 방법 오늘날 워크플레이스의 문제는 게으른 직원과 못된 관리자에 관한 것이 아니다. ‘불확실성’에 관한 것이다. 직원들은 무엇을 기대할 수 있는지 그리고 보상이 노력할 가치가 있는지 확신하지 못한다. 마찬가지로 관리자와 리더는 직원들이 게으름을 피우고 있는지 아닌지 확신하지 못한다. 조용한 퇴사, 대퇴직, 편집증적 점검, 생산성 극장을 끝내고 워크플레이스 생산성을 높일 해결책은 불확실성을 공격하는 것이다. 이제 직원들이 기대할 수 있는 특정 결과, 즉 성공을 구성하는 요소를 구체적으로(그리고 서면으로) 작성하여 매우 명확하게 설명해야 한다. 직원들이 게으름을 피우는지 아닌지는 잊어버려야 한다. 겉으로 보이는 생산성은 무시하고 결과에 집중하라. 아울러 멘토링, 교육, 직원 승진에 더 많은 노력을 기울여야 한다. 모든 직원이 자신의 커리어에서 명확한 경로를 가지고 있는지 확인하라. 마지막으로 가장 중요한 것은 일과 삶의 균형 그리고 유연성을 기반으로 직원들과 협력하여 더 나은 삶을 누릴 수 있도록 지원하는 것이다. 불확실성이 생산성을 죽이고 있다. 워크플레이스에서 명확성을 찾아야 할 때다. *Mike Elgan은 기술 및 기술 문화에 대해 저술하는 전문 기고가다. ciokr@idg.co.kr

기업 문화 2022.11.16

글로벌 칼럼ㅣ‘생산성’ 말려 죽이기, 배후에는 불확실성이 있다

생산성

클라우드 2022.11.16

글로벌 칼럼 | 2023년 쿠버네티스와 멀티클라우드의 결합에 주목하자

쿠버네티스

클라우드 2022.11.15

글로벌 칼럼 | '클라우드 송환'이라는 달콤한 거짓말

클라우드 송환

IT 관리 2022.11.15

블로그 | MDM 솔루션 업체의 실적으로 본 기업용 엔드포인트로서의 애플

애플

클라우드 David Linthicum

블로그 | 클라우드 운영에서 관찰 가능성의 의미

관찰 가능성(Observability)은 최근 IT 미디어나 클라우드 컴퓨팅 컨퍼런스에서 자주 거론되는 개념 중 하나이다. 모두가 관찰 가능성이 무엇인지 정의를 가지고 있으며, 어떻게 사용하는지 안다. 하지만 같은 정의와 같은 사용법은 하나도 없다. 관찰 가능성은 많은 양의 데이터에서 핵심 인사이트를 파악할 수 있는 역량으로 정의되는 것 같다. 클라우드 운영과 관련해서 관찰 가능성은 보통 구동 중인 시스템에서 추출한 데이터를 사용한다. 우리는 이 데이터를 뭔가 잘못된 것이 있는지를 알아낼 때 사용할 뿐만 아니라 잘못된 이유와 잘못을 바로잡는 방법을 파악하는 데도 사용한다. 과연 개념으로서 관찰 가능성의 가치는 무엇이고, 클라우드옵스에서 어떤 가치를 발휘하는가? 이 개념을 여러 구성요소로 분해해 관찰 가능성이 비즈니스에 가치를 가져다주는 방식을 살펴보자. 트렌드. 어떤 패턴이 반복적으로 일어나고 이런 패턴이 앞으로는 운영에 어떤 의미를 갖는가? 예를 들어, 성능 트렌드가 하향 곡선을 그리면, 데이터베이스의 증가로 발생하는 I/O 문제를 가리킬 가능성이 크다. 이는 이력 데이터와 현재 데이터를 기반으로 하며, 이들 데이터는 AI옵스 같은 인공지능 시스템을 위한 학습 데이터로 사용된다. 분석. 데이터는 무엇을 의미하며, 추출할 수 있는 인사이트가 있는가? 관찰 가능성은 어떤 데이터가 의미하는 바를 분석할 수 있는 역량을 제공한다. 다른 데이터 모니터링과 구분되는 핵심 기능이다. 인사이트. 데이터로부터 알 수 있는 것 또는 알아야 할 것은 무엇인가? 여기에는 데이터에서 쉽게 이해되지 않거나 드러나지 않는 의미를 찾는 작업이 필요하다. 예를 들어, 영업 매출 증가와 전반적인 시스템 성능 저하 간에 상관관계가 있는가? 추적. 시스템 활동 데이터를 실시간 또는 거의 실시간으로 모니터링하고, 이 데이터를 이용해 현재 진행 중인 문제를 찾아 진단하고 바로잡을 수 있는가? 전통적인 추적은 클라우드와 데이터센터의 여러 시스템 활동을 모니터링한다. 관찰 가능성 개념에서는 시스템이 실시간 데이터에서 동적인 인사이트를 찾아 관련 운영 데이터 맥락에서 조사할 수 있다. 학습. 학습 시스템은 트렌드와 인사이트를 찾기 위해 대량의 데이터를 살펴보고 해당 데이터를 사용해 새로 등장하는 패턴과 그 의미를 학습한다. 관찰 가능성 개념을 적용한 어떤 시스템이라도 데이터 패턴에 관해 지식 엔진을 훈련시킬 AI 시스템이 있다. 경보. 시의적절한 방법으로 처리해야 할 문제는 무엇인가? 예를 들어, 네트워크 성능 문제에 관한 우선순위가 낮은 경보는 최종적으로 네트워크 허브 교체로 이어질 것이다. 긴급한 경보는 즉각적인 주의가 필요하다. 애플리케이션 처리 부하가 클라우드에 있는 가상 서버 클러스터의 한계에 가까워졌기 때문에 자동으로 용량을 확장하는 경우를 예로 들 수 있다. 조처. 경보로 인해 어떤 일이 일어나는가? 클라우드 기반 서버를 재기동하는 수작업이 일어날 수도 있고, 아니면 랜섬웨어 공격으로 핵심 비즈니스 시스템이 영향을 받기 전에 자동으로 복구하