뉴스나 정보를 제공하는 사이트들은 대개 유료 구독 모델, 광고 모델 그리고 기부 모델로 나누어 볼 수 있습니다. 이 세가지 비지니스 모델은 독자적으로만 존재하는 것이 아니라 특성을 적절하게 섞어서 비지니스 모델 성과를 높이고 있습니다.
예를들어 유료 구독 모델이지만 부분적으로 광고를 실기도 하고, 광고를 주로 하면서 일정 부분만 유료 구독 모델로 운영하기도 합니다.
그냥 개인의 돈을 들여 운영하는 사이트도 있지만 어느 정도 규모를 가지고 목적에 맞추어 커스터마이제이션해 운영하려면 정기적인 비용이 적지않게 듭니다.
사이트를 운영하는 비용도 당연히 들겠지만 콘텐츠를 생산하고 유지하는데 드는 비용은 경우에 따라서는 어마어마한 비용이 드는 것이 사실입니다.
인터넷 시대에 콘텐츠는 무료라는 인식이 강하지만 점점 읽을만한 콘텐츠는 점점 유료화되고 있습니다.
왜냐하면 콘텐츠는 그냥 자연적으로 만들어지는 것이 아니라 누군가의 땀과 노력으로 만들어지기 때문이고, 이러한 품질 좋은 콘텐츠를 지속적으로 제공하려면 콘텐츠 제작자들에게 충분한 보상이 주어져야 장기적으로 안정적으로 품질좋은 콘텐츠를 제공할 수 있는 것이죠.
우리나라는 아직 덜하지만 점점 외국의 경우 어지간한 언론사들은 유료 구독모델로 변경된지 오래입니다.
광고, 구독, 기부가 적절히 활용된 4가지 구독 옵션을 제공
이러한 트렌드들보다도 먼저 유료 구독 모델을 운영한 곳이 LWN이라고 할 수 있는데요. LWN은 아래와 같이 광고와 유료 구독 그리고 기부 모델을 적절하게 사용하고 있습니다.
가장 비용이 낮은 starving hacker에게는 광고 모델과 구독 모델을 혼용해 사용하고 있으며.
가장 많은 돈을 내는 maniacal supporter은 구독 모델과 기부 모델을 적절해 활용한 구독 타입
구독 타입
월 구독료
광고 여부
접근 가능 콘텐츠
starving hacker
3.5$
O
모든 콘텐츠 접근 가능 정기 결제 불가 (비용 문제)
professional hacker
$7
X
모든 콘텐츠 접근 가능 정기 결제 가능 작성자별 댓글 필터링 댓글 답변 이메일 수신
professional hacker
$14
X
모든 댓글 이메일 통보 새 댓글 하일라이트 기능
maniacal supporter
$50
X
댓글에 서포터 표시 컨퍼런스에서 맥주/음료 제공
이렇게 광고와 구독 그리고 기부가 적절한 게 활용된 LWN이 비지니스 모델에서 광고가 차지하는 비중은 전체 수익의 10% 선이라고 밝히고 있습니다.
활발한 커뮤니티 이벤트
LWN은 Linux Weekly News라는 이름으로 거의 뉴스 사이트로 시작했지만 점점 성격은 정보 + 커뮤니티 성격이 가미되면서 이제는 오픈 소스를 비롯한 자유 소프트웨어(Free software) 커뮤니티를 지향하고 있습니다.
이러한 커뮤니티는 콘텐츠에 대한 활발한 논의(그렇기에 LWN의 구독 옵션에는 댓글에 대한 옵션을 매우 중시하고 있습니다.)와 더불어 오프라인 또는 온라인이벤트를 통한 활발한 교류를 통해서 커뮤니티를 발전시키고 있습니다.
2020년 7월 LWN 커뮤니티 캘린더(The LWN.net Community Calendar)
그렇기에 이러한 활발한 커뮤니티 이벤트를 통한 수익도 LWN의 중요한 비지니스 모델이라고 할 수 있습니다. 이 비중이 어느 정도 되는지는 확인할 수 없었습니다.
부분 유료 커뮤니티를 지향한 LWN에서 읽는 시사점
위에서도 언급했지만 LWN은 Linux Weekly News에서 출발해 오픈 소스를 비롯한 자유 소프트웨어(Free software) 커뮤니티를 지향하는 가운데 커뮤니티를 활성화하는 강력한 도구로서 고품질의 콘텐츠 확보에 주력했습니다.
그것은 콘텐츠 품질에 대한 강력한 관리를 통해 일정 수준을 넘는 고품질 콘텐츠만 제공하고, 다양하면서도 고품질 콘텐츠 확보를 위해 콘텐츠 제공에 문호를 개발하되 충분한 비용을 지불하면서 콘텐츠 제공이 활성화 할 수 있도록 했습니다.
고품질 콘텐츠를 위한 면밀한 관리
뉴욕타임즈등과 같은 유력 언론은 서면 인터뷰를 진행하는 경우 수십번에 걸친 메일 커뮤니케이션을 통해서 언론사에서 원하는 충분한 고품질 콘텐츠가 나오도록 만듭니다.
유력 언론사들이 그만큼 충분히 검증하고 리뷰하면서 충분한 콘텐츠를 완성해가는 것처럼, LAW도 글을 제안하고 작성 그리고 리뷰를 통해 실제로 발표되는데까지 많은 시간과 엄청난 커뮤니케이션을 통해서 충분히 검증하고 논리를 보강하면서 완성도를 높인다고 합니다.
앞서 언급된 글에서 소개된 사례에서도 LAW에 주제를 제안해 발표하는데 2주일 이상 걸렸고 무려 30통이 넘는 이메일을 주고 받으며 글을 편집하면서 완성도를 높였다고 합니다.
I’ve written a couple of articles for LWN (I waived the fee)[1][2]. It’s quite an involved process going through many rounds of editing. You have to stick to the house style and use the house markup. The results are excellent because of this consistent attention to detail, but I wouldn’t recommend it as a way to make a quick buck 🙂 The whole process for these two articles took two weeks from proposal to publication and involved 30 emails as well as many edits in their CMS.
콘텐츠 제공자에 대한 보상 시스템
콘텐츠를 제공하는 회사들은 좋은 글을 확보하기 위한 많은 노력을 기울입니다.
제가 관심을 가지고 살펴보고 있는 VPS 업체인 Vultr이나 Lenode와 같은 업체들은 품질 좋은 콘텐츠가 비지니스에 도움을 주기 때문에 서버 운영, 운영체제 활용등에 대한 글을 제공하는 경우 글당 $300 정도의 비용을 지불합니다.
LAW도 업계 평균 수준이상의 고료를 제공합니다. 다만 계속 좋은 글을 기고하게 되면 고려가 상당한 수준으로 올라간다고 합니다.
그것은 지속적으로 좋은 글을 올리면 그의 글을 신뢰하고 지속적으로 방문해 트래픽과 구독자가 증가하기 때문에 당연하게도 가치가 올라가기 때문이겠죠.
새로운 저자는 글 한 편당 $300 고료 지급 난이도가 높은 커널 관련 글은 $350 고료 지급
좋은 글을 지속적으로 기고하는 경우 고려가 상당한 수준으로 올라감
활성 커뮤니티를 통한 고품질 콘텐츠 생성 선순환
콘텐츠 제공자들이 글을 작성해 LAW에 기고하는 이유는 일정 정도 고료를 얻을 수 있다는 경제적인 동인도 있겠지만 자가기 알고 있는 내용을 알리고 그러는 가운데 인정을 받고 싶은 욕구가 있겠죠.
그것이 LAW와 같은 일정 권위를 인정받은 커뮤니티에서 인정을 받는다면 더욱 그러할 것입니다.
이는 활성화된 커뮤니티를 통해서 상당히 힘든 과정임에도 불구하고 LAW에 기고하도록 만들고 그 과정에서 LAW의 품질 관리 과정을 통해서 보다 고품질 콘텐츠를 만들 가능성을 높여주면서 좋은 콘텐츠가 늘어나는 선순환이 일어나는 것으로 보입니다.
The LSFMM 2019 group photo, Photo by LWN
프리미엄 모델
LAW는 오픈 소스와 자유 소프트웨어(Free Software)를 다루고 있기 때문에 영리적인 접근은 상당히 조심스러울 수 있습니다.
그러나 LAW는 유료 콘텐츠를 무한정 유료로 제한하는 것이 아니라 일정 시간이 지나면 누구나 자유롭게 열람할 수 있도록 만들면서 접근성을 높이면서도 유료화를 통한 지속 성장 가능성을 높였습니다.
이 설정 파일에서는 주로 아래와 같은 내용을 변경해 줍니다. 뭐 사용자 목적에 따라서 적절한 옵션을 변경할 수 있습니다.
스캔 후 이메일 통보 관련
먼저 스캔 결과를 이메일로 통보 여부, 값이 0이면 통보하지 않고, 1인 경우 메일 통보
email_alert=1Code language:PHP(php)
실제 편집 파일에 해당 건에는 아래와 같은 주석이 달려 있습니다.
# Enable or disable e-mail alerts, this includes application version# alerts as well as automated/manual scan reports. On-demand reports# can still be sent using '--report SCANID user@domain.com'.# [0 = disabled, 1 = enabled]
email_alert="1"Code language:PHP(php)
다음으로는 메일 주소를 설정합니다. 여러 메일 주소로 스캔 결과를 받아야 한다면 컴마(,)를 이용해 추가합니다.
# The destination e-mail addresses for automated/manual scan reports# and application version alerts.# [ multiple addresses comma (,) spaced ]
email_addr=”user@yourdomain.com, user2@yourdomain.com”Code language:PHP(php)
다음으로는 Maldet가 멀웨러를 감지하고 깨끗하게 치료했다면 굳이 메일 경고하지 않는다는 옵션 선택할지를 결정합니다. 1값은 멀웨어가 치료되었다면 굳이 메일 경고를 하지 않습니다.
email_ignore_clean="0"Code language:PHP(php)
실제 편집 파일에 해당 건에는 아래와 같은 주석이 달려 있습니다.
# Enable or disable slack alerts, this will upload the scan report as a file# into one or more slack channels# [0 = disabled, 1 = enabled]
slack_alert="0"Code language:PHP(php)
멀웨어 감염 파일 처리
다음에는 스캔 도중 멀웨어를 감지했다면 어떻게 할지에 대한 옵션인데요. 멀웨어에 걸린 파일을 특정 장소로 이동할지 그대로 둘지를 결정합니다.
값이 0이라면 감염되었다는 경고만 하고 파일은 그대로 유지합니다. 1 값을 주면 특정 장소로 이동 조치하고 경고해 줍니다.
quarantine_hits=1Code language:PHP(php)
실제 편집 파일에 해당 건에는 아래와 같은 주석이 달려 있습니다.
# The default quarantine action for malware hits# [0 = alert only, 1 = move to quarantine & alert]
quarantine_hits="1"Code language:PHP(php)
그 다음에는 감염된 멀웨어를 치료할지 여부를 선택합니다. 치료한다면 1값을 입력하고 그대로 두려면 0값을 유지합니다.
quarantine_clean=1Code language:PHP(php)
실제 편집 파일에 해당 건에는 아래와 같은 주석이 달려 있습니다.
# Try to clean string based malware injections# [NOTE: quarantine_hits=1 required]# [0 = disabled, 1 = clean]
quarantine_clean="1"Code language:PHP(php)
이번에는 조금 더 강력한 조치를 할 것인지를 선택하는데요. 멀웨어에 감염된 사용자는 서버에서 활동을 중지시키는 조치인데요 .
0값을 입력 시 멀웨어에 감염되었다고 판명되어도 그 사용자는 그대로 작동하며, 만약 1값을 입력시 멀웨어가 팀지되면 그 사용자는 사용이 중지됩니다.
1인 사용자 서버는 서비스사 멈추는 것이므로 신중하게 선택할 필요가 있습니다. 아무래도 서비스 중단까지는 부담스러우니 0값을 사용합니다.
quarantine_suspend_user=0Code language:PHP(php)
여기에는 아래와 같은 주석과 설명이 달려 있습니다.
# The default suspend action for users wih hits# Cpanel suspend or set shell /bin/false on non-Cpanel# [NOTE: quarantine_hits=1 required]# [0 = disabled, 1 = suspend account]
quarantine_suspend_user="0"Code language:PHP(php)
Maldet 실행
Maldet 설정이 끝났으면 Maldet를 실행해 봅니다. 우선 Maldet의 주요 실행 옵션을 살펴볼까요?
-u, –update-sigs [–force] 데이타베이스 업데이트
-a, –scan-all PATH 모든 파일을 스캔 예) maldet -a /home/username
Linux Malware Detect v1.6.4
(C) 2002-2019, R-fx Networks <proj@rfxn.com>
(C) 2019, Ryan MacDonald <ryan@rfxn.com>
This program may be freely redistributed under the terms of the GNU GPL v2
maldet(46026): {scan} signatures loaded: 17041 (14221 MD5 | 2035 HEX | 785 YARA | 0 USER)
maldet(46026): {scan} building file listfor /home/happist, this might take awhile...
maldet(46026): {scan} setting nice scheduler priorities for all operations: cpunice 19 , ionice 6
maldet(46026): {scan} file list completed in 2s, found 85826 files...
maldet(46026): {scan} found clamav binary at /usr/bin/clamdscan, using clamav scanner engine...
maldet(46026): {scan} scan of /home/happist (85826 files) in progress...
maldet(46026): {scan} clamscan returned an error, check /usr/local/maldetect/logs/clamscan_log for details!
maldet(46026): {scan} scan completed on /home/happist: files 85826, malware hits 0, cleaned hits 0, time 491s
maldet(46026): {scan} scan report saved, to view run: maldet --report 200707-2004.46026Code language:PHP(php)
Let’s Encrypt도 알고 보면 수많은 인증서 발급 기관, CA(Certificate Authority) 업체 중이 하나입니다. 다만 SSL 인증서 가격이 비싸 보급이 느려지면서 인터넷 보안에 문제가 있다는 문제 의식하에 무료 보급을 통한 인터넷 보안을 강화하겠다는 비영리 단체라고 할 수 있습니다.
인증서 발급 기관, CA(Certificate Authority) 중 점유율이 가장 높은 곳은 IdenTrust로 2020년 12월 기준으로 42%가 넘습니다.(42.3%)
그리고 과거 자료들을 보면 python-certbot-nginx 명령을 사용하는데 파이썬3으로 업그레이드되면서 파이썬3를 사용하라는 권고를 받습니다.
Let’s Encrypt SSL 인증서 발급 방법 4가지
Let’s Encrypt SSL 인증서 발급 방법은 webroot와 Standalone, DNS의 3가지 방식이 있습니다. 인증서 발급은 사이트에서 인증기관인 Let’s Encrypt에 접속해 이 사이트의 유효성을 검증하는 과정을 거치며 이 과정을 아래 3가지 방법 중 하나를 선택해 진행할 수 있습니다.
webroot : 사이트 디렉토리 내에 인증서 유효성을 확인할 수 있는 파일을 업로드하여 인증서를 발급하는 방법 . 실제 작동하고 있는 웹서버의 특정 데렉토리의 특정 파일 쓰기 작업을 통해서 인증 . 이 방식의 장점은 nginx를 중단시킬 필요가 없음. . 이 방법의 단점은 인증 명령에 하나의 도메인 인증서만 발급 가능
웹서버 . Nginx나 아파치와 같은 웹서버에서 직접 SSL 인증을 실시하고 웹서버에 맞는 SSL세팅값을 부여 . 발급이나 갱신을 위해 웹서버를 중단시킬 필요가 없음 . 인증서 갱신 시 상황에 맞게 세팅을 자동으로 업데이트 . 사용자가 세팅을 변경할 수 있지만 자동 업데이트 시 반영되지는 않음
Standalone : 사이트 작동을 멈추고 이 사이트의 네크워킹을 이용해 사이트 유효성을 확인해 Let’s Encrypt SSL 인증서를 발급하는 방식 . 80포트로 가상 staandalone 웹서버를 띄워 인증서를 발급 . 이 방식은 동시에 여러 도메인을 발급 받을 수 있음 . 그렇지만 인증서 발급 전에 Nginx를 중단하고 발급 완료 후 다시 Nginx를 시작해야 함
DNS : 도메인을 쿼리해 확인되는 TXT 레코드로 사이트 유효성을 확인하는 방법 . 와일드 카드 방식으로 인증서를 발급 가능 . 이 방법은 당연하게도 서버 관리자가 도메인 DNS를 관리/수정할 수 있어야 하며 . 인증서 갱신 시마다 DNS에서 TXT값을 변경해야 하므로 외부에서 TXT 레코드를 입력할 수 있도록 DNS가 API를 제공하는 경우만 갱신 과정을 자동으로 처리(클라우두플레어 API가 대표적인 사례)
사이트 보안을 강화는 방법으로 불필요하게 포트를 열어 놓았는지 확인해 반드시 필요한 포트만 여는 포트 사용 최적화 방법에 대해서 살펴보도록 하죠.
서버에서 사용하는 포트는 아래와 같이 세가지 주요 그룹으로 나눌 수 있습니다.
시스템 포트(System ports), 0-1023 – 핵심 서비스와 관련된 포트로 운영 체제에 필수적인 포트
사용자 포트(User ports), 1024-49151 – IANA가 ‘IETF Review’, ‘IESG Approval’, ‘Expert Review’ 프로세스를 위해 할당한 포트
동적 포트(Dynamic ports), 49152-65535 – 개인적이 용도로 사용하는 프라이빗 포트
어떤 포트를 사용하고 있는지 확인
현재 사이트에서 어떤 포트를 열어놓고 있는지 확인하기 위해서 아래와 같이 netstat -ano 명령을 사용해 봤습니다.
이 명령을 사용하면 아래와 같이 현재 열린 포트 및 대기하고 있는 포트들을 전부 다 보여줍니다. 또한 이 내용외에 다양한 내용을 출력해 줍니다. 너무 많아 기가 질릴 정도..
# netstat -ano
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State Timer
tcp 00127.0.0.53:530.0.0.0:* LISTEN off (0.00/0/0)
tcp 000.0.0.0:250.0.0.0:* LISTEN off (0.00/0/0)
tcp 00127.0.0.1:60100.0.0.0:* LISTEN off (0.00/0/0)
tcp 000.0.0.0:4430.0.0.0:* LISTEN off (0.00/0/0)
tcp 000.0.0.0:***** 0.0.0.0:* LISTEN off (0.00/0/0)
tcp 00127.0.0.1:33060.0.0.0:* LISTEN off (0.00/0/0)
tcp 000.0.0.0:800.0.0.0:* LISTEN off (0.00/0/0)
tcp 00141.164.48.62:443189.40.73.149:12786 ESTABLISHED off (0.00/0/0)
tcp 00141.164.48.62:443180.65.25.237:45753 ESTABLISHED off (0.00/0/0)
tcp 00141.164.48.62:443203.175.39.84:49433 ESTABLISHED off (0.00/0/0)
tcp 00141.164.48.62:44372.14.199.27:49062 ESTABLISHED off (0.00/0/0)
tcp 00141.164.48.62:443222.234.131.7:7507 ESTABLISHED off (0.00/0/0)
tcp 00141.164.48.62:44366.249.79.158:42357 ESTABLISHED off (0.00/0/0)
tcp 00141.164.48.62:443189.40.73.149:12792 ESTABLISHED off (0.00/0/0)
tcp 00141.164.48.62:44361.81.11.245:11848 TIME_WAIT timewait (7.58/0/0)
tcp 00141.164.48.62:443189.40.73.149:12788 ESTABLISHED off (0.00/0/0)
tcp 00141.164.48.62:443118.45.130.180:38805 TIME_WAIT timewait (57.05/0/0)
tcp 00141.164.48.62:443124.50.187.177:57167 ESTABLISHED off (0.00/0/0)
tcp 00141.164.48.62:44366.249.79.129:56320 ESTABLISHED off (0.00/0/0)
tcp 0180141.164.48.62:***** 124.50.187.177:57295 ESTABLISHED on (0.22/0/0)
tcp 00141.164.48.62:44366.249.79.120:43419 ESTABLISHED off (0.00/0/0)
tcp 00141.164.48.62:443211.243.82.156:49304 ESTABLISHED off (0.00/0/0)
tcp 00141.164.48.62:44366.249.79.159:40840 TIME_WAIT timewait (34.53/0/0)
tcp 00141.164.48.62:443211.178.105.144:56345 ESTABLISHED off (0.00/0/0)
tcp 00141.164.48.62:44366.249.79.118:54414 ESTABLISHED off (0.00/0/0)
tcp 00141.164.48.62:44366.249.79.158:62256 TIME_WAIT timewait (2.30/0/0)
tcp 00141.164.48.62:443222.121.168.2:4079 ESTABLISHED off (0.00/0/0)
tcp 00141.164.48.62:443121.151.167.84:47722 ESTABLISHED off (0.00/0/0)
tcp6 00 :::25 :::* LISTEN off (0.00/0/0)
tcp6 00 ::1:6010 :::* LISTEN off (0.00/0/0)
tcp6 00 :::***** :::* LISTEN off (0.00/0/0)
udp 00127.0.0.53:530.0.0.0:* off (0.00/0/0)
udp 00141.164.48.62:680.0.0.0:* off (0.00/0/0)Code language:PHP(php)
또는 netstat 명령대신 요즘 권장된다는 ss 명령을 사용해 봅니다. 조금 더 단순하게 보여줍니다. 간단한 대신 정보가 제한적이네요.
이 ip들을 확인해보니 집과 태블릿에서 사용하던 ip들입니다. 맨 위 ip는 집에서 사용하는 공인 ip이고, 나머지 4개는 태블릿에서 사용하는 유동ip로 보입니다.
그래서 집의 공인 ip와 태블릿의 유동 ip대인 211.36.대를 적용하기로 했습니다.
ip 허용 및 금지 설정
ip 허용 및 금지하는 방법을 살펴보도록 하죠. ip를 허용하는 방법은 /etc/hosts.allow 파일을 수정합니다.
nano /etc/hosts.allowCode language:PHP(php)
위에서 설명한대로 집의 공인 ip와 태블릿의 유통 ip 대역대를 적용하도록 하겠습니다.
ip 대역대 표시는 ip 4 자리 중 해당 부분만 표시할 수 있습니다. 우리가 흔히 아는 것처럼 *같은 것은 사용하지는 못합니다.
ip 세자리대까지 표현한다면 ‘124.50.187.’ 로 표시
ip 두자리대까지 표시한다면 ‘124.50.’로 표시
ip 한자리대까지 표시한다면 ‘124.’으로 표시
특정 ip만 적용하기 윌한 /etc/hosts.allow 파일은 아래와 같이 변경되었습니다.
# /etc/hosts.allow: list of hosts that are allowed to access the system.# See the manual pages hosts_access(5) and hosts_options(5).## Example: ALL: LOCAL @some_netgroup# ALL: .foobar.edu EXCEPT terminalserver.foobar.edu## If you're going to protect the portmapper use the name "rpcbind" for the# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.#
sshd: 124.50.187.177
sshd: 211.36.Code language:PHP(php)
그리고 나머지 ip는 모두 사용 중지시킵니다. 이는 /etc/hosts.deny 파일을 수정합니다.
nano /etc/hosts.denyCode language:PHP(php)
아래 내용으로 변경합니다.
# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.# See the manual pages hosts_access(5) and hosts_options(5).## Example: ALL: some.host.name, .some.domain# ALL EXCEPT in.fingerd: other.host.name, .other.domain## If you're going to protect the portmapper use the name "rpcbind" for the# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.## The PARANOID wildcard matches any host whose name does not match its# address.## You may wish to enable this to ensure any programs that don't# validate looked up hostnames still leave understandable logs. In past# versions of Debian this has been the default.# ALL: PARANOID
sshd: ALLCode language:PHP(php)
특정 사용자만 허용하는 방법
특정 사용만 ssh 접속을 허용하는 방법입니다. 이는 sshd_config 파일에서 특정 사용자를 허용하든지 금지시킬 수 있습니다.
nano /etc/ssh/sshd_configCode language:PHP(php)
이 파일에서 아래처럼 AllowUsers 다음에 허용할 사용자를 추가합니다. 예를들면 daisy 사용자만 추가한다면 다음과 같은 명령을 사용합니다.
AllowUsers daisyCode language:PHP(php)
이 파일에는 PermitRootLogin 명령어는 root 사용자 로그인을 허용할지 설정하는 명령인데요. 일부 글들을 보면 root 사용을 중지할 때 no 옵션을 준다고 설명하고 있는데요.
우분투에서 root 사용을 중지시킬 때 아래처럼 이를 no 옵션을 사용한다고 설명하는데 우분투 20.04에서는 작동하지 않더군요.
설치를 시작하다가 중간에 이 프로그램이 서버 용량을 사용할 것인데 설치를 진행할 것인지 질문합니다. 사용하겠다는 용량은 기껏 588K 정도 되기 때문에 부담없이 Y를 누릅니다.
# sudo apt install unattended-upgrades apt-listchanges bsd-mailx
Reading package lists... Done
Building dependency tree
Reading state information... Done
unattended-upgrades is already the newest version (2.3).
The following packages were automatically installed and are no longer required:
lockfile-progs sendmail-base sendmail-cf sensible-mda
Use 'sudoaptautoremove' toremovethem.
Suggestedpackages:
www-browserx-terminal-emulatorThefollowingNEWpackageswillbeinstalled:
apt-listchangesbsd-mailx
0 upgraded, 2 newlyinstalled, 0 toremoveand 31 notupgraded.
Needtoget 150 kBofarchives.
Afterthisoperation, 588 kBofadditionaldiskspacewillbeused.
Doyouwanttocontinue? [Y/n] YCode language:PHP(php)
설정 보안 업체이트 허용
다음으로는 강제 보안 업데이트를 허용합니다. 아래와 같은 명령을 사용하면 중간에 unattended-upgrades를 사용하도록 설정할지 질문하는 팝업이 뜹니다.
Applying updates on a frequent basis is an important part of keeping systems secure. By default, updates need to be applied manually using package management tools. Alternatively, you can choose to have this system automatically download and install important updates.Automatically download and install stable updates?
오늘 목적이 바로 그것이므로 키보드를 왼쪽으로 옮겨 Yes를 선택합니다.
unattended-upgrades 세부 옵션
이제 unattended-upgrades 세부 옵션을 정합니다. 이는 아래 파일을 편집합니다.
보안 업데이는 종종 우분투 서버 리부팅이 필요할 경우가 있습니다. 이 경우 관리자 확인없이 리부팅 허용(93번째 줄)
서버 리부팅이 필요한 경우 리부팅 시간을 위험이 적은 새벽 시간으로 설정(102번째 줄)
아래는 제가 설정한 내용입니다. 설명 등 군더더기 내용을 그대로 두었습니다.
// Automatically upgrade packages from these (origin:archive) pairs//// Note that in Ubuntu security updates may pull in new dependencies// from non-security sources (e.g. chromium). By allowing the release// pocket these get automatically pulled in.
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}";
"${distro_id}:${distro_codename}-security";
// Extended Security Maintenance; doesn't necessarily exist for// every release and this system may not have it installed, but if// available, the policy for updates is such that unattended-upgrades// should also install from here by default."${distro_id}ESMApps:${distro_codename}-apps-security";
"${distro_id}ESM:${distro_codename}-infra-security";
// "${distro_id}:${distro_codename}-updates";// "${distro_id}:${distro_codename}-proposed";// "${distro_id}:${distro_codename}-backports";
};
// Python regular expressions, matching packages to exclude from upgrading
Unattended-Upgrade::Package-Blacklist {
// The following matches all packages starting with linux-// "linux-";// Use $ to explicitely define the end of a package name. Without// the $, "libc6" would match all of them.// "libc6$";// "libc6-dev$";// "libc6-i686$";// Special characters need escaping// "libstdc\+\+6$";// The following matches packages like xen-system-amd64, xen-utils-4.1,// xenstore-utils and libxenstore3.0// "(lib)?xen(store)?";// For more information about Python regular expressions, see// https://docs.python.org/3/howto/regex.html
};
// This option controls whether the development release of Ubuntu will be// upgraded automatically. Valid values are "true", "false", and "auto".
Unattended-Upgrade::DevRelease "auto";
// This option allows you to control if on a unclean dpkg exit// unattended-upgrades will automatically run// dpkg --force-confold --configure -a// The default is true, to ensure updates keep getting installed//Unattended-Upgrade::AutoFixInterruptedDpkg "true";// Split the upgrade into the smallest possible chunks so that// they can be interrupted with SIGTERM. This makes the upgrade// a bit slower but it has the benefit that shutdown while a upgrade// is running is possible (with a small delay)//Unattended-Upgrade::MinimalSteps "true";// Install all updates when the machine is shutting down// instead of doing it in the background while the machine is running.// This will (obviously) make shutdown slower.// Unattended-upgrades increases logind's InhibitDelayMaxSec to 30s.// This allows more time for unattended-upgrades to shut down gracefully// or even install a few packages in InstallOnShutdown mode, but is still a// big step back from the 30 minutes allowed for InstallOnShutdown previously.// Users enabling InstallOnShutdown mode are advised to increase// InhibitDelayMaxSec even further, possibly to 30 minutes.//Unattended-Upgrade::InstallOnShutdown "false";// Send email to this address for problems or packages upgrades// If empty or unset then no email is sent, make sure that you// have a working mail setup on your system. A package that provides// 'mailx' must be installed. E.g. "user@example.com"
Unattended-Upgrade::Mail "업데이트 상황을 받아 볼 이메일 주소";
// Set this value to one of:// "always", "only-on-error" or "on-change"// If this is not set, then any legacy MailOnlyOnError (boolean) value// is used to chose between "only-on-error" and "on-change"// Remove unused automatically installed kernel-related packages// (kernel images, kernel headers and kernel version locked tools).//Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";// Do automatic removal of newly unused dependencies after the upgrade//Unattended-Upgrade::Remove-New-Unused-Dependencies "true";// Do automatic removal of unused packages after the upgrade// (equivalent to apt-get autoremove)//Unattended-Upgrade::Remove-Unused-Dependencies "false";// Automatically reboot *WITHOUT CONFIRMATION* if// the file /var/run/reboot-required is found after the upgrade
Unattended-Upgrade::Automatic-Reboot "true";
// Automatically reboot even if there are users currently logged in// when Unattended-Upgrade::Automatic-Reboot is set to true//Unattended-Upgrade::Automatic-Reboot-WithUsers "true";// If automatic reboot is enabled and needed, reboot at the specific// time instead of immediately// Default: "now"
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
// Use apt bandwidth limit feature, this example limits the download// speed to 70kb/sec//Acquire::http::Dl-Limit "70";// Enable logging to syslog. Default is False// Unattended-Upgrade::SyslogEnable "false";// Specify syslog facility. Default is daemon// Unattended-Upgrade::SyslogFacility "daemon";// Download and install upgrades only on AC power// (i.e. skip or gracefully stop updates on battery)// Unattended-Upgrade::OnlyOnACPower "true";// Download and install upgrades only on non-metered connection// (i.e. skip or gracefully stop updates on a metered connection)// Unattended-Upgrade::Skip-Updates-On-Metered-Connections "true";// Verbose logging// Unattended-Upgrade::Verbose "false";// Print debugging information both in unattended-upgrades and// in unattended-upgrade-shutdown// Unattended-Upgrade::Debug "false";// Allow package downgrade if Pin-Priority exceeds 1000// Unattended-Upgrade::Allow-downgrade "false";Code language:PHP(php)
APT 변경 사항 발생 시 받을 메일 주소 변경
다음으로는 listchanges.conf를 편집해 APT 변경 사항 발생 시 받아볼 이메일 주소를 root에서 설정합니다.
여기 설정은 매우 간단한데요. 아래와 같은 항목으로 구성되어 있고 이중 메일 주소를 설정하면 됩니다.
[apt]
frontend=pager
which=news
email_address=업데이트 상황을 받아 볼 이메일 주소
email_format=text
confirm=false
headers=false
reverse=false
save_seen=/var/lib/apt/listchanges.dbCode language:PHP(php)
그럴 겨우 보통 NGINX 웹서버를 체크 시 nginx -t 옵션을 사용해 점검합니다. 그러면 NGINX 세팅 중 문제 없는지를 체크해 이상이 없으면 OK 메세지를 보내는데요.
# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Code language:PHP(php)
그리고나서 NGINX 웹서버를 다시 구동시키면 아무런 문제가 없이 작동합니다.
문제 상황
그런데 이 경우는 nginx -t에서는 아무런 문제가 없다가 service nginx restart 명령을 받아 NGINX 웹서버를 다시 가동하려면 에러 메세지를 내면서 NGINX 웹서버를 가동시키지 못합니다.
아래 메세지처럼 ‘systemctl status nginx.service’로 점검하라고 메세지 나오며, systemctl status nginx.service를 이용해 점검해보면
NGINX 활성화할 수 없으며
80포트를 이미 사용하고 있다고 합니다.
# service nginx restart
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service"and"journalctl -xe"for details.
# systemctl status nginx.service
● nginx.service - nginx - high performance web server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2020-07-0216:37:00 KST; 28s ago
Docs: http://nginx.org/en/docs/
Process: 1109 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=1/FAILURE)
Jul 0216:36:57 etrend systemd[1]: Starting nginx - high performance web server...
Jul 0216:36:57 etrend nginx[1109]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in us>
Jul 0216:36:58 etrend nginx[1109]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in us>
Jul 0216:36:58 etrend nginx[1109]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in us>
Jul 0216:36:59 etrend nginx[1109]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in us>
Jul 0216:36:59 etrend nginx[1109]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in us>
Jul 0216:37:00 etrend nginx[1109]: nginx: [emerg] still could not bind()
Jul 0216:37:00 etrend systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Jul 0216:37:00 etrend systemd[1]: nginx.service: Failed with result 'exit-code'.
Jul 0216:37:00 etrend systemd[1]: Failed to start nginx - high performance web server
Code language:PHP(php)
net-tools로 원인 파악
그러면 누가 이미 address를 사용하고 있는지 점검하기 위해 netstat를 점검해 봅니다.
먼저 net-tools을 설치하구요.
apt install net-toolsCode language:PHP(php)
다음으로 아래 명령어로 네트워크 상황을 점검해 봅니다.
netstat -tulpNCode language:PHP(php)
그랬더니 아래와 같이 http로 apache2가 이미 사용하고 있다고 합니다. 여기는 NGINX 웹서버이므로 hhtps는 NGINX가 사용해야 정상이겠죠.
~# /usr/bin/certbot renew --dry-run >> /var/log/letsencrypt/renew.log
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for happist.com
http-01 challenge for www.happist.com
nginx: [error] invalid PID number "" in "/var/run/nginx.pid"
Waiting for verification..
Cleaning up challengesCode language:PHP(php)
그리고 다시 nginx를 구동시키면 구동되지 않습니다. 그래서 systemctl status nginx.service 명령으로 상황을 파악해보면 위에서 소개한 것처럼 이미 address가 사용 중이라고 나옵니다.
~# systemctl status nginx.service
● nginx.service - nginx - high performance web server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2020-08-0812:49:38 KST; 3min 9s ago
Docs: http://nginx.org/en/docs/
Process: 2257 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=1/FAILURE)
Aug 0812:49:37 etrend nginx[2257]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Aug 08 12:49:37 etrendnginx[2257]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Addressalreadyinuse)
Aug 08 12:49:37 etrendnginx[2257]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Addressalreadyinuse)
Aug 08 12:49:37 etrendnginx[2257]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Addressalreadyinuse)
Aug 08 12:49:38 etrendnginx[2257]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Addressalreadyinuse)
Aug 08 12:49:38 etrendnginx[2257]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Addressalreadyinuse)
Aug 08 12:49:38 etrendnginx[2257]: nginx: [emerg] stillcouldnotbind()
Aug 08 12:49:38 etrendsystemd[1]: nginx.service: Controlprocessexited, code=exited, status=1/FAILUREAug 08 12:49:38 etrendsystemd[1]: nginx.service: Failedwithresult 'exit-code'.
Aug 08 12:49:38 etrendsystemd[1]: Failedtostartnginx - highperformancewebserver.
Code language:PHP(php)
해결 방안
이 문제의 근본적인 해결 방안, 즉 이런 문제가 나타나지 않토록 만드는 방법은 아직 확인하지 못했습니다.
다만 임시로 nginx 웹서버에서 다른 프로그램이 address를 먼저 사용한다는 문제를 해결을 위해서는 대략 두가지 방법이 있습니다.
apache2 stop 명령
우분투 설치 시 기본으로 apache2가 설치되어 있기 때문에 이 apache2 stop 명령을 사용하면 이 문제가 일시적으로 해소됩니다.
sudo /etc/init.d/apache2 stop
sudo service nginx restartCode language:PHP(php)
fuser -k 80/tcp 사용
저는 apache2를 없애버리면 이 문제가 해소될 것으로 보고 apache2를 삭데햌ㅆ는데요. 그럼에도 불구하고 이문제는 계속 발생했습니다. apache2가 이 문제 원인은 아니라는 것이죠.
아마 위에서 지적한 대로 SSL 인증 과정에서 80주소를 일부 어플리케이션이 사용하고 되돌려주지 않는 버그가 있는 것 같습니다.
오늘 소개하는 PHP 에러 대응 -PHP Warning: call_user_func_array() expects parameter 1 to be a valid callback도 이러한 예의 하나인데요.
보통 이런 에러가 발생하면 아래와 같은 에러 메세지를 보냅니다. 이는 서버의 error.log에서 발견할 수 있습니다.
웹서버로 NGINX를 사용한다면 /var/log/nginx 폴더에 있는 error.log에서 확인할 수 있습니다. 하나의 실예를 들기 위해 에러 메세지를 그대로 가져와 봤습니다.
2020/07/0413:33:50 [error] 2739157#2739157: *149426 FastCGI sent in stderr: "PHP message: PHP Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'child_enqueue_styles' not found or invalid function name in /home/사이트 이름/wp-includes/class-wp-hook.php on line 287", client: 220.64.101.2, server: 사이트 이름.com, request: "GET /571441/ HTTP/1.1", host: "사이트 이름.com"Code language:PHP(php)
에러 메세지의 원인
이러한 메세지가 나오는 것은 대부분 워드프레스 차이드 테마의 hunctions.php에 다음과 같은 형식의 커스텀 코드가 있는 경우가 발생한다고 합니다.
코노라 팬데믹으로 애플 비지니스 환경이 그리 우호적이지 않음에도 불구하고 애플 주가는 사상 최고를 기록하며 승승 장두하고 있습니다. 애플 주가를 그렇게 끌어 올리는 애플 미래 전략이 궁금한 일이 아닐 수 없습니다.
그래서 애플 미래 전략에 대한 관심을 가질 필요가 있는 지점이기도합니다. 그러는 가운데 최근 애플의 연례 행사인 WWDC에서는 iOs 업그레이드를 비롯한 다양한 내용이 발표디었습니다.
애플 미래 전략에 대한 많은 분석 중 애플이 이 모든 준비들은 애플 미래전략으로 AR/VR 비즈니스를 겨냥하고 있다는 것에 주목해 애플 미래 전략을 분석한 박시용님의 페북글이 있어 허락을 받아 여기에 소개합니다.
박시용님은 <WWDC에서 일관되게 가르키는 단 한가지. 바로 AR/VR 비즈니스>라는 글을 통해서 이번 WWDC의 주제는 1.방해하지 않는 UX 2.플랫폼 대통합 3.측위기술의 3가지로 보고 각 내용을 분석하면서 이러한 모든 것의 종착역은 미래 준비로서 AR/VR 비즈니스에 대해 주목하고 있습니다.
이번 애플 WWDC 2020을 곱씹어 보면서 계속 들었던 생각은 ‘얘네들, 노골적으로 AR/VR 시장을 준비하는구나.’ 였는데, 외신을 비롯하여 아무도 AR/VR과 연결지어 분석한 내용이 없는것 같아 한판 정리해봅니다.
올해 WWDC에서는 기존과는 다르게 하드웨어 발표는 하지 않고 지나갔습니다. 각 디바이스들의 OS의 발표를 마치고 ARM기반의 새로운 프로세서 자랑을 한 뒤 마무리 지었죠. 하지만 한번 더 살펴보면 이 모든것의 끝에는 AR/VR 비즈니스가 있었습니다.
얼마전 프로 유출러 Jon Prosser 내용에 따르면 애플은 Apple Glass라는 이름으로 AR디바이스를 준비중이며, 사생활 침해를 막기 위해 카메라는 부착하지 않고 이번 아이패드 프로에 부착된 라이다센서를 달았다고 합니다. 발표는 내년 상반기, 출시는 2년후라고 예측했습니다.
그럼 WWDC로 돌아가서 다시 살펴볼까요. 이번 발표를 관통하는 주제는 크게 3가지입니다. 1.방해하지 않는 UX 2.플랫폼 대통합 3.측위기술
방해하지 않는 애플 UX
iOS, iPadOS, MacOS의 UX가 매우 많이 바뀌었습니다. 특히나 iOS의 경우에는 앱서랍이나 위젯등을 도입함으로써 원하는정보에 빠르게 다가갈 수 있게되었습니다.
또한 사용중에 전화가 오는 경우 기존에는 화면 전체가 전화 화면으로 전환되었지만 이제는 위에서 콜바 하나만 작게 내려와서 기존 작업을 방해받지 않게 되었죠.
그룹메시지에서도 누가 말을 하는지 작게 말풍선으로 표시되게 되었고 시리 화면도 전체를 가리지 않게 되었습니다.
이거 안드로이드에서는 십년전부터 있던 기능들입니다. 그 기능들은 애플은 왜 이제서야 적용을 한다고 하는 걸까요? 전세계 시총 1위인 회사가 설마 기술이 없어서 구현 못했을리는 없고요.
수년간 욕을 먹으면서도 바꾸지 않았던 UX를 이렇게 ‘방해하지 않는 UX’로 전환을 꾀하는건 이유가 있어서일겁니다.
항상 애플의 문법은 동일했습니다. First Mover보다는 기술이나 유저들의 경험치가 어느정도 무르익은 다음 극한의 ux완성도를 들고 제품을 출시하였습니다.
몇년전 애플워치가 출시하기도 이전에 제가 웨어러블 업체 발굴을 위해서 심천에 간 적이 있었는데, 그 당시 판매가(공급가 말고) 3만원 미만의 제품들이 수백종류가 넘었습니다. 그러나 애플워치가 햅틱엔진을 달고 나오자 시장의 판도는 다 바뀌었죠. 제가 만났던 그 업체들, 아직까지 제품을 만들고 있지는 않을것 같습니다.
몇년째 욕을 먹으면서도 수신전화 화면을 전체화면으로 유지하는대신 아이폰을 사용하지 않을때는 밀어서 받기, 사용중에는 버튼으로 받기를 나눠놓을정도로 디테일한 ux팀이, 이번에 방해받지 않는ux로 대대적인 개편을 한 이유는 앞으로 AR의 시대가 도래했을때의 유저들이 경험할 사용성에 대한 준비라고 생각됩니다.
이번 iOS에서 pip가 적용되었는데 기존의 안드로이드와는 다르게 팝업으로 떠있는 동영상 창을 바깥으로 밀어놓았다가 사용할때는 화살표를 살짝 당겨오는 방식을 도입했습니다. 이것도 ar글라스를 사용할때 꼭 필요한 ux이며, 유저들에게는 ar글라스 출시 이전부터 익숙하게 경험할 수 있게 하는 장치라고 보여집니다.
플랫폼 대통합
이번 발표의 원모어띵은 ARM기반의 Apple Silicon 칩셋이었습니다.
2005년 파워PC에서 인텔로 전환할때의 wwdc에서는 인텔이라는 회사를 특히 강조했지만 이번에는 어디에서도 ARM이라는 이야기는 들리지 않았습니다. 오로지 ‘우리는 칩셋까지 자체 설계하고 모든 프로그램이 원활히 돌아갈 수 있도록 하겠다.’에 초점을 두었죠.
외부의 칩셋을 쓰지 않고 자체적으로 칩셋을 설계하는경우, 디바이스 업데이트 주기를 칩셋의 스케줄에 맞출 필요도 없고 제품 원가도 유의미하게 낮아질 수 있습니다.
그러나 큰 허들이 있는데 이 경우에는 기존에 사용하던 레거시 프로그램들을 전부 ARM 커스텀 칩셋에 맞추어 컴파일하거나 가상화 머신을 사용해야 하는 단점이 발생합니다.
그러나 이런 과도기가 지나가게 되면 기존의 ARM칩셋 위에서 돌아가던 iOS, iPadOS의 어플들을 자유롭게 맥에서도 교차 사용 가능하게 됩니다. 이는 디바이스의 제한 없이 기존의 레거시 프로그램, 수많은 개발자들이 앱스토어에 등록한 어플들을 사용할 수 있다는 뜻입니다.
또한 애플의 A프로세서는 고성능, 저전력의 특징을 갖고 있습니다.
위의 애플글라스의 경우 1세대 기기에서는 독자적인 프로세싱보다는 아이폰과 연결되어 아이폰에서 연산작업이 주로 이루어지겠지만 시간이 지나면 결국 AR/VR 디바이스 자체에서 프로세싱하게 될겁니다.
애플은 스마트스피커인 홈팟에도 아이폰6에 들어가는 A8프로세서를 탑재했고 심지어는 조만간 출시될 무선충전기인 Airpower에는 아이폰X에 들어가는 A11칩셋을 사용한다는 루머가 있습니다.
이는 애플글라스에서도 A칩셋을 사용할것이며 이 위에서 돌아가는 서비스들은 아이폰, 아이패드, 맥 상관없이 모든 플랫폼에서 seamless하게 경험할 수 있다는 장점이 있습니다.
위의 애플글라스 유출내용에 따르면 2년후에 출시 예정이라고 합니다. 그리고 이번 wwdc의 발표에 따르면 2년후에는 모든 맥은 Apple Silicon 기반으로 출시된다고 합니다. 무섭도록 맞아떨어지는 스케줄이죠.
측위 기술
이번 wwdc의 발표 중 별것 아닌것처럼 스리슬쩍 빠르게 넘어간 것들 중 아주아주 중요한것들이 있습니다.
우선 Apple Car Key 시연 중 소개되었던 u1칩셋의 모습, 손 씻을때 애플워치가 자동으로 손씻는 모션을 알아채고 가이드 해주는 기능, 마지막으로 에어팟 프로의 펌웨어 업데이트로 공간음향을 구현하는 기능입니다.
위의 기능들은 모두 사용자의 모션과 위치를 측정하는 측위기술들이 뒷받침 되어야 합니다.
작년 아이폰11 발표때 애플은 아이폰11의 가장 큰 기술적 혁신인, UWB(초광대역)칩인 u1칩을 내장하고도 별다른 언급을 하지 않았습니다.
그러나 u1칩은 센티미터 단위의 위치탐색 능력 및 벽과 인체등의 장애물에 방해받지 않는 특성을 이용하여 애플 카 키, 홈킷 시스템과 더불어 앞으로 출시될 애플글라스에서 가장 중요한 역할을 하게 될 겁니다.
앞으로 애플워치, 애플글라스를 비롯하여 모든 디바이스에 u1칩셋이 확실시 됩니다.
이렇게 아이폰, AR글라스, 애플워치등이 전부 U1칩을 탑재하고 있다면 서로의 위치를 파악해 미묘한 손이나 얼굴의 움직임 만으로 가상물체를 조종하게 될 수 있을것이고요.
그렇다면 엔드유저가 꼭 일반적인 소비자가 아닐수 있고, 이는 가상물체의 세밀한 원격조정이 필요한 B2B로의 비즈니스 확장을 기대해 볼 수도 있습니다.
또한 에어팟 프로의 공간음향 기능 추가로 소리에도 방향성을 표현할 수 있게 되었으니, 인간의 오감 중 미각이랑 후각과 관련된 기능만 붙여서 출시하면 완벽한 VR세상이 도래하겠네요.
마치며
정리해보자면, 애플은 이번 WWDC에서 ‘앞으로 2,3년동안 사용자들에게 새로운 UX를 습득시키고 그 후에 본격적인 AR/VR 디바이스를 출시하면서 시장을 지배하겠다.’ 라는 내용을 발표한것과 다름이 없습니다.
가을에 새롭게 출시될 아이폰 및 다른 디바이스들이 이런 방향과 얼마나 부합하는지 찾아보는것도 재미있는 일이 될겁니다.