리눅스에서 벤치마크를 할때 여러 프로그램으로 가능합니다. Phoronix Test Suite도 그중의 하나인데요. 이 프로그램을 쓰면 제공되는 여러 테스트들을 활용해서 Processor, System, Network, Disk, OS 등의 카테고리의 벤치마크를 할 수 있습니다.
These are the defaultconfiguration options forwhen running the Phoronix Test Suite inabatch mode(i.e.running phoronix-test-suite batch-benchmark universe).Running inabatch mode isdesigned tobe asautonomous aspossible,except forwhere you'dlike any end-user interaction.
Save test results when inbatch mode(Y/n):Y
Open the web browser automatically when inbatch mode(y/N):N
Auto upload the results toOpenBenchmarking.org(Y/n):n
(1) 개념의 발생적인 측면. 이 개념이 왜 고안되었는지. (2) 개념의 실용적인 측면. 이 개념을 접했을 때 즉각적으로 떠올려봐야 되는 것이 무엇인지.
이 두가지를 기본적인 것부터 고급적인 것까지 항상 주시하면서 보강해가면 좋습니다. 기본적으로 (1)과 (2)를 핵심적으로 알아두고 지식 확장을 이루어나가면 숙지가 될 것입니다.
디렉토리의 경우 어떠할까요? 발생적인 것과 실용적인 것의 측면에서 생각해봅시다.
디렉토리는 발생적으로 파일의 저장을 체계적으로 하기 위해 고안된 개념입니다. 사무실에서 쓰이는 캐비넷 안에 들어있는 디렉토리를 생각하시면 됩니다. 사무실에는 캐비넷이 여러개가 있을 수 있고 각각의 캐비넷은 용도별로 구분이 됩니다. 그리고 각각의 캐비넷에 들어있는 디렉토리도 용도별로 구분되죠. 사용자는 파일을 체계적으로 저장하기 위해 임의로 캐비넷과 디렉토리를 분류해두고 그 기준에 맞춰 파일을 보관합니다.
아래 그림처럼 서로 독립된 캐비넷이 여러개로 분리되서 구조를 이루고 거기에 파일이 보관됩니다.
컴퓨터에서도 마찬가지인 디렉토리 개념이 존재합니다. 파일의 체계적 분류를 위해 디렉토리를 만들고 파일 저장 위치를 디렉토리로 구분해서 계층화해둡니다. 예컨데 사진 파일을 유저 홈디렉토리의 사진 디렉토리에 저장하기로 약속해놓았다든가, 서드파티 프로그램들을 C 드라이브 아래의 Program Files 디렉토리에 저장하도록 했다든가 하는 것이 그러한 예입니다.
여기서 캐비넷에 해당되는 것은 C 드라이브고, 디렉토리에 해당되는 것은 Program Files겠죠.
실용적으로 중요한 것은 어떤 경로로 구성된 디렉토리인지 실용적으로 떠올려보는 것입니다.
예컨데 첫번째 캐비넷 안에 “가” 디렉토리 아래 “김철수”라는 디렉토리가 있고 그 안에 “출생증명서” 파일이 있다면 경로가 생성됩니다. 그 경로는 유일하고 각각의 단계에 의해 구성됩니다. 이는 마치 사다리타기할 때처럼 시작지점부터 도착지점까지 경로가 유일하게 정해져 있는 것과 같습니다.
누군가 “니 홈디렉토리 아래 사진 디렉토리에 노리사마 사진을 저장해두었으니 볼려면 찾아봐”라고 말했다면, 즉각적으로 해야 될 것은 말로 된 디렉토리의 경로가 어떤 것인지 떠올려보는 것이죠.
보통 윈도우 운영체제에서는 위에 말한 디렉토리가 C:\Users\계정명\Pictures 가 됩니다. C:\ 라는 것은 부팅된 윈도우가 설치된 하드디스크를 의미하고, 이는 루트디렉토리라고 불립니다. 그 아래 Users나 계정명, Pictures는 하위 디렉토리라고 부릅니다. 루트디렉토리는 여러개가 있을 수 있고, 같은 층위의 하위 디렉토리는 같은 계층에 하나만 존재합니다.
이를 일반화하면
드라이브명:\하위 디렉토리1\하위 디렉토리2…\하위 디렉토리n
이렇게 구성됩니다. 드라이브명은 루트디렉토리라고 부르고, 하위 디렉토리1은 하위 디렉토리 2의 상위 디렉토리라고 부릅니다. 대개 이 구조는 유일합니다.
세밀하게 들어가보자면 이렇습니다.
드라이브명:\하위 디렉토리1\하위 디렉토리2…\하위 디렉토리n
이 구조가 중요한데 이런 구조를 디렉토리를 접하면 즉각적으로 떠올려보면 좋습니다.
확장 개념으로 조금 더 나아가봅시다. 앞서 말한 바에 의하면 디렉토리 경로는 유일하다고 했습니다. 이 유일한 경로를 안다면 해당 경로에 저장된 파일을 처리할 준비가 됩니다. 그런데 필요에 의해 확장된 예외에 의하면 최종 작업디렉토리는 유일해도 경로의 단계는 복수일 수도 있습니다. 유닉스에서 심볼릭링크라고 부르는 개념이나 윈도우에서 바로가기라고 부르는 개념이 그 예외인데, 예컨데
C:\Users\name\Pictures 라는 작업 디렉토리에 연결된 바로가기가 서로 다른 경로에 존재하는 경우 서로 다른 경로를 지니게 되는 결과가 생기죠.
즉 C:\Users\name\Pictures 디렉토리에 연결된 동일한 바로가기 아이콘인 shortcut1.ico 파일이 서로 다른 디렉토리에 저장되어 있는 경우 그 저장된 경로 개수만큼 경로가 있다고 볼 수 있습니다.
처럼 하나여도 그에 도달하는 경로는 다수일 수 있다는 것입니다. 이는 디렉토리 개념이 고안된 이후에 사용의 편리성을 위해 고안된 예외적인 확장 개념으로 이해하면 됩니다. 최종적인 작업 디렉토리는 하나지만, 사용의 편의를 위해 고안된 확장 개념으로 이해해두면 됩니다.
정리해보자면
(1) 디렉토리는 파일의 체계적 저장을 위해 만들어졌다. 사무실의 캐비넷을 떠올려보라. (2) 디렉토리의 핵심 개념은 어떤 경로냐는 것이다. (3) 최종 작업 디렉토리는 유일하지만 그 경로는 확장적으로 다수일 수 있다.
이정도만 알아두면 입론이 됩니다.
디렉토리는 보통 명령어 체제로 운용되는 운영체제에서 유래한 개념인데 윈도우처럼 그래픽컬한 인터페이스로 운용되는 운영체제에서는 폴더라고 부르기도 하므로 참고하세요. 폴더는 디렉토리를 시각적으로 폴더 모양으로 나타내는데서 비롯된 이름입니다. 둘다 용어상의 차이일뿐 개념은 같습니다.
이해가 잘되게 설명했는지 모르겠는데 일단 입론으로 참고는 되실겁니다.
정리: 디렉토리를 토대로 경로가 제시되면 떠올려볼 사항들 (1) 어느 운영체제의 경로 표시인가? (2) 경로에 표시된 디렉토리에 어떻게 찾아갈 것인가? (3) 디렉토리에 찾아가서 어떤 작업을 할 것인가?
(1) 어느 운영체제의 경로 표시인가? 운영체제에서 경로란 여러 의미를 갖지만, 디렉토리와 연관되면 디렉토리와 파일이 저장된 위치를 가리킵니다. 윈도우에서 C:\Users\name\Pictures\flower.jpg 라는 경로가 주어졌다면 이 경로는 윈도우 운영체제에서 유효하며 각각의 단계를 찾아가서 처리하라는 의미입니다.
윈도우 운영체제에서는 전통적으로 디스크를 파티션으로 나누어 각각의 파티션에 A부터 Z까지의 문자를 부여해서 디스크 드라이브라고 불렀습니다.
위에서 예를 들은 C:\Users\name\Pictures\flower.jpg 에서 제일 앞의 C:\ 가 드라이브를 나타낸 기호로, C 드라이브라고 부르며 보통 윈도우가 부팅된 디스크에 부여됩니다.
각각의 디렉토리 구조는 \ 로 잘라내져서 계층을 표현하구요. 위에서는 사용자 계정을 의미하는 Users 디렉토리 아래 계정명 name으로 된 홈디렉토리 아래 Pictures 디렉토리를 찾아서 flower.jpg 파일에 처리를 하라는 의미가 됩니다.
리눅스에서는 반대로 / 로 구분하여 디렉토리 계층을 표현하구요. 윈도우와 달리 드라이브 문자가 없이, 장치 파일을 임의의 디렉토리에 마운트해서 씁니다.
/dev/sda1 /mnt/windows/C
이런 식으로 표현합니다.
정리하자면 운영체제마다 경로 표시 규칙이 다르고, 대개 윈도우 계열에서는 드라이브 이름이 부여되어 하위 디렉토리를 \로 구분해서 나타내며, 유닉스 계열에서는 드라이브 문자 없이 /로 구분해서 나타낸다는게 핵심입니다.
(2) 경로에 표시된 디렉토리에 어떻게 찾아갈 것인가? 경로가 제시되면 우선 생각할게 (1)이구요. (1)이 해독되면 (2) 경로에 표시된 디렉토리에 어떻게 찾아갈지 결정해야 합니다.
위의 예를 들면 윈도우에서 파일 탐색기를 실행해서 클릭하면서 찾아가도 되구요. cmd.exe 를 실행해서 cd 명령어로 찾아가도 됩니다.
(3) 디렉토리에 찾아가서 어떤 작업을 할 것인가? (1)과 (2)가 해결되면 결정해야 할 것은 어떤 작업을 할 것인가입니다. 이는 디렉토리 용도와 파일의 형식에 의해 결정되고 목적에 따라 달라집니다.
누군가 이메일로 자기가 기르는 꽃 사진을 보내오고 위와 같은 파일을 첨부해서 보여줬다면 우선 다운로드를 합니다. 이 경우에 경로를 C:\Users\name\Pictures로 다운로드 받게 설정하구요. 다운로드가 되면 파일 탐색기를 열어 해당 경로로 가서 flower.jpg 파일을 더블클릭하면 뷰어가 실행될 것입니다. 이메일로 보내는 이유가 이미지 파일을 그냥 봐달라는 것이면 이렇게 하면 되구요. 리터칭을 해달라고 한 것이면 파일 탐색기 외에 포토샵에서 불러와서 처리하면 됩니다.
때로는 파일을 지울때도 해당 디렉토리 경로를 알아야하구요.
이미지 파일의 경우 리터칭을 해서 리터칭 완료한 이미지 파일을 답신해야 한다면, 저장된 경로를 잘 숙지하고 있다가 이메일에 첨부하면 됩니다.
정리하자면 디렉토리는 파일 저장과 이용을 체계적으로 나타내기 위해 제정된 규칙이고, 디렉토리와 파일을 어떻게 처리해야 할지 기준을 제공하는 규칙이라는 것을 잘 알아두면 됩니다.
webmin은 웹기반 리눅스 서버 설정 관리자로 매우 편리한 설정이 가능하게 해줍니다. 물론 설정 사항들에 대한 지식이나 설정값을 선택하고 입력하는 지식은 이미 있어야 하지만요. 서버 설정 경험이 일정 정도 있고 서버에 대한 경험이 있는 사용자에게 직접 명령어 타이핑을 고안할 필요없이 매우 광범위한 설정을 UI로 돕는 기능을 제공하고 있습니다.
데비안, 우분투 계열 리눅스와 레드햇 기반 리눅스를 모두 지원합니다. 슬랙웨어 기반은 어떤지 미확인입니다.
제가 사용하는 리눅스는 리눅스 민트 계열의 하모니카OS인데요. 우분투 기반인만큼 apt 명령어로 간단하게 설치가 되어 사용이 가능해집니다.
유닉스 운영체제에서는 원격에서 목적지 컴퓨터로 연결해서 작업을 하는 것이 필요했습니다. 주말에 집에서 직장 컴퓨터에 작업을 해야 할 필요가 있다든지 대학에서 사무실에 앉아 각 교실에 있는 컴퓨터에 연결해서 관리를 해야 한다면 원격 연결을 할 방법이 필요한 것이었죠.
이를 위해 원격에서 연결해서 쉘 작업을 할 수 있게 하는 기술이 지원되었는데요. rlogin 같은 명령어가 있습니다. 그런데 이 방법은 운영체제나 네트워크 보안이 그다지 발달이 안된 시절의 유산이라, 보안에 취약한 측면이 있었습니다. 보통 TCP 연결이 성립하면 서버와 클라이언트 간의 데이터 통신이 선로를 따라 전송이 되는데요. 주고 받는 데이터가 평문으로 전달되다보니 이를 중간에 가로채면 별다른 노력 없이도 어떤 정보를 주고 받는지 알게 되어 보안에 무리가 갔습니다.
1990년대 중반에 이를 해결하고자 한 개발자가 SSH를 개발합니다. Secure SHell (보안이 강화된 쉘) 이라고 불리우는 프로그램입니다. 이 프로그램은 인증할때, 정보를 주고받을때 암호화 기술을 써서 정보를 암호화해서 처리하게 되어 있었습니다. 암호화 처리는 내부적으로 되어 사용자에게는 암호화된 정보를 복호화해서 보여주었구요. 암호화 처리로 인해 특별히 유난한 조건이 아니면 정보를 중간에서 탈취해도 어느 정도는 안전성이 보장되는 구조였습니다.
암호화 기능은 대칭, 비대칭으로 나누어지는데요. 대칭키 알고리즘은 서버와 클라이언트간에 같은 비밀키를 가지고 암호화와 복호화를 진행합니다. 암호화는 암호화가 안된 평문을 알아보기 어렵게 바꾸는 기능이고 복호화는 암호화된 정보를 암호화 이전의 평문으로 되돌리는 기술입니다. 공개키와 개인키를 생성해서 변환 과정(해시 함수 처리)을 거쳐 인증을 하는데, 이 경우 공개키는 서버와 클라이언트가 공유하고, 개인키는 안전한 장소에 두고 쓰는 방법입니다. 대칭키 알고리즘은 SSH 작동 전반에 걸쳐 활용되고 비대칭 알고리즘은 인증에 쓰인다고 하는데, 비대칭 알고리즘이 조금 더 안전을 강화했기에 쓰입니다. 예를 들면 해시 처리된 결과물이 늘 같은 문자열로 이루어져 있다면 이를 토대로 본래 문자열을 유추하는게 가능해지는데, 비대칭키 알고리즘을 쓰면 보다 더 유추가 힘들어지는 원리입니다.
SSH는 여러 암호화 기술을 쓸 수 있는데요. AES, Blowfish, 3DES, CAST128, Arcfour 등입니다. 관리자가 SSH 설정 파일에 지정한대로 골라져서 작동합니다. 각각의 암호화 기술은 깨트려지기 어려운 것을 주로 써야 하는데요. 보통 키의 길이가 긴 것 (비트수로 표현) 을 쓰면 깨트리기가 어려워지므로 최근의 암호화 기술은 비트수가 큽니다.
비대칭키 알고리즘은 공개키에서 개인키를 도출해낼 수 없는 구조입니다. 개인키는 완전한 비밀로 해야 하고 서버/클라이언트 양자에서 공유하지 않습니다. SSH는 비대칭키와 대칭키 알고리즘을 둘다 씁니다.
개인키의 보안이 철저하다면 SSH 설정에 의해 비밀번호 없이 키 설정만으로도 로그인이 가능하도록 할 수 있습니다. 이는 비밀번호가 유출되었을때의 보안 침해를 막으려는 용도와, 사용자에게 비밀번호 변경의 번거로움을 해소하는 방도입니다. 대체로 웹호스팅 업체는 키 인증 방식과 비밀번호 체제를 둘다 씁니다.
일단 인증이 끝나면 원격지의 PC에서 목적지의 컴퓨터로 로그인 과정을 거치고 물리적으로 해당 컴퓨터 앞에 앉아 작업하듯이 작업이 가능해집니다. SSH로 연결하면 웹호스팅에서 편의로 제공하는 cPanel에서 안되는 작업도 가능해집니다.
연결을 시도하면 클라이언트와 서버 사이에 TCP 핸드세이크가 이루어집니다. 이 과정에서 보안이 강화된 연결을 위해 교섭이 이루어지고 사용자의 자격증명과 서버의 설정이 작동해서 인증을 하죠. TCP 연결이 이루어지면 프로토콜을 확인하고 공개키와 비밀키를 교환합니다. Diffie-Hellman 알고리즘으로 알려진 과정에 의해 세션 단위로 공개키, 개인키 쌍을 사용해서 암호화를 수행합니다.
비밀번호 또한 암호화됩니다.
위에 정리한 과정은 구현 레벨에서는 스무단계가 넘는 과정을 거치는데, 단순화하면 아래와 같습니다.
클라이언트가 SSH 서버에 연결을 요청한다
서버는 클라이언트에 공개키를 보낸다
서버의 공개키가 클라이언트의 호스트 파일에 저장된다
클라이언트와 서버는 연결 파라메터를 주고받으며 보안된 연결을 수립한다
SSH는 1995년 소개 된 이래, OpenBSD 팀에서 만든 OpenSSH로 대체되어 윈도우 포함 여러 운영체제에서 제공합니다. OpenBSD는 높은 보안성을 제공하려고 방침을 정한 유닉스 프로젝트로, OpenSSH도 같은 모토에 의해 제작되어 타운영체제에서도 쓰고 있습니다.
사용자의 PC 즉 클라이언트 PC에서 PuTTY 같은 프로그램을 써서 서버에 SSH 연결을 하는 것이고 OpenSSH는 이러한 일련의 작업을 할 수 있게 명령어와 라이브러리를 제공하는 것입니다. OpenSSH를 써서 SSH나 SFTP 등의 연결을 할 수 있게 환경을 만들 수 있습니다.
서버의 설정에 따라 아래와 같은 작업을 수행합니다.
프로그램 컴파일
각종 서버 데몬 처리
디렉토리 권한 조정
cPanel이나 phpmyadmin 등의 설정처리
public_html 디렉토리 아래 서브디렉토리를 만들어 앱 설치
그외
SSH는 CLI 방식의 명령어를 알아야 하기에 초심자에게는 부담이 되지만, 웹호스팅 업체에서 기본으로 제공하는 설정 UI로 못하는 작업이 가능하므로 잘 쓰면 좋습니다.
이 중에서 제일 긱키한 방법은 물론 (3)인데 소스코드가 공개될 것 같아 안쓰구요. (2)는 NTFS로 보통 포맷해서 쓰지만 macOS에서는 비용지불해야 NTFS에 쓰기가 가능한지라 읽기에도 문제가 있을 것 같아 exFAT으로 포맷한 후에 쓰는데 복사 속도가 빠를 것 같습니다. (1)은 USB 메모리들이 대부분 exFAT으로 포맷되어 나와서 조치하지 않아도 복사가 되구요.
아무래도 (2)로 해야겠습니다. 앱 소스코드가 파일 크기들이 아주 크진 않은데 즉시 복사하고 즉시 옮겨야 하니까요.
(4) 네트워크 연결후 복사하기
도 있겠는데 macOS에서 윈도우로 네트워크 연결하는 기술을 살펴봐야 하네요. samba나 기타 다른 기술들이 있겠으나 FTP가 제일 쓰기가 편하긴 합니다. 윈도우에 FTP 서버 설치하고 macOS에서 연결후 다운로드하는 방법을 쓰면 되는데 이역시도 속도가 빠르겠으나 FTP 서버를 켜두는게 불편하군요. (2)가 최적 같습니다. 속도도 그렇고 별다른 추가 처리도 필요 없습니다.
일단 이 네가지에 대응되는 방법을 찾아 사용하면 됩니다. 방법마다 필요한 소프트웨어가 있어야 할 수도 있으니 잘 살펴보세요. 윈도우에서 FTP 서버를 운용하려면 FileZilla 서버를 쓰면 편리합니다.
애플 기기에서 도는 앱을 실험해보기 위해서는 (1) 실장비가 있어야 하거나 (2) 시뮬레이터를 쓰는 방법이 있습니다. 후자 시뮬레이터는 일종의 가상머신으로 애플에서 발표한 실장비의 제품과 운영체제를 실험해볼 수 있는 도구로, 모바일 앱을 실장비 없이 테스트해볼 수 있게 해주는 방법을 제공합니다. Xcode의 일부이지만, xcrun simctl 명령어를 쓰면 명령행에서 제어가 가능합니다.
시뮬레이터를 잘 쓰면 아래와 같은 기능이 가능합니다.
(1) 시뮬레이터를 만들고, 부팅하고, 셧다운하고 지우기 (2) 사진과 영상을 시뮬레이터에 옮기기 (3) 모바일 앱을 설치하고, 삭제하고, 실행하고, 종료하기 (4) 스크린샷을 캡처하고 비디오를 레코딩 (5) 시뮬레이터 로그 확인 (6) 그외
xcrun simctl 명령어는 안드로이드로 치자면 adb가 하는 일을 하는 애플 시뮬레이터 전용 명령어입니다. 위치는 /Applications/Xcode.app/Contents/Developer/usr/bin/simctl 이구요.
제가 쓰는 맥 머신은 맥 미니 M2 8GB 256GB SSD 깡통 제품입니다. 플러터로 앱 개발을 할때 iOS 앱 빌드는 맥 머신에서만 되는 체제라 구했는데 다들 램 크기에 대한 갑론을박을 하네요. 일단 램이 크면 빌드시 큰 규모의 빌드에 강합니다. 맥 미니는 macOS Ventura 부팅시 첫부팅에는 4GB 이하의 램이 남는데, 이를 생각하면 램을 크게 커스텀해서 주문하는게 좋다고 합니다. 그런데 이런 조건도 생각해보면 깡통으로 돌려도 괜찮은 경우가 있습니다.
(1) 앱스토어에서 찾아보면 램상주하면서 특정 시간 동안 안쓰는 램을 비워주는 앱이 있습니다. 이 앱을 이용해서 수동으로 필요할때마다 비워주고 자동으로 비우는 옵션을 켜면 5GB까지도 램이 남네요.
(2) 안드로이드 스튜디오는 살펴보면 IDE에서 쓰는 heap에 2GB, VM에 1GB를 할당하던데 시스템마다 달라지겠으나 램이 5GB 남은 상태에서 빌드시 빌드할 프로젝트 규모에 따라 한도가 정해질 것 같습니다.
(3) vscode 같은 규모가 작지만 플러터도 지원하는 강력한 IDE를 쓰면 규모가 큰 IDE보다 램 활용 여유가 남습니다.
(4) 애플 태블릿이나 아이폰이 있으면 시뮬레이터 안써도 되서 램이 더 남습니다. (안드로이드는 에뮬레이터라고 하고 애플은 시뮬레이터라고 하는데 둘다 가상머신에서 실장비를 흉내내는 경우로, 이역시도 멀티태스킹으로 IDE와 웹브라우저, 가상머신을 동시에 띄우고 작업하는 것을 말하는 것입니다)
(5) 이 경우 vscode로 작업후 빌드하고 vscode를 종료한후, xcrun simctl 명령어로 시뮬레이터에 빌드한 앱을 심고 동작시키면 실장비 없이 램을 더 잘 활용가능해집니다.
(6) 프로그래밍 작업시에도 웹문서를 참조할때 여러개의 탭을 웹브라우저에 띄우고 쓰는데 이 경우에도 최대한 램을 덜 차지하는 웹브라우저를 쓰면 됩니다.
(7) 동시에 띄워야 할 프로그램도 다시 띄우는데 큰 속도저하가 없네요. 특별한 조건만 아니라면, SSD에서 로드해서 실행하는 것이라, 불편이 안큽니다.
(8) 그리고 플러터앱이 아주 무거운 3D 게임이 아니라면 (예: 수십킬로바이트 텍스트에 작은 크기의 그림파일을 쓰는 정보제공앱) 시뮬레이터에서 작업시 큰 무리가 없죠.
(9) 타개발자들 의견도 갈리는데 (a) 램은 우선 크면 좋다. (b) 그러나 8GB 깡통 사양도 나쁘다는 말이 아니다. (c) 질문자의 조건을 완전하게 모를때 답변하면 안전빵으로 16GB로 가라고 하는데 이 경우에도 불편이 없는 경우에는 쓰는게 지장이 없는 방법이 있다. (d) 느려진다는 보고는 일차적으로 존중해야 하는데 실재로 써보면 아닌 경우가 있다 = 하드웨어와 소프트웨어 조합에 의하면 포괄적인 조건이라고 기술된 바가 커버하지 못하는 경우가 있다. (e) 그럼에도 개발자가 제시하면 그게 어떤 경우 안통하면 개발자가 속이는 것과 같아서 16GB 램을 추천한다. (f) 8GB도 크게 안나쁜 조건을 잘 생각하면 비용 많이 안들여도 된다.
(10) 포토샵이나 애프터이펙트 등의 CG처리 프로그램은 무조건 16GB 이상 램이 좋은데, 규모 작은 앱 개발할 것이면 괜찮다. 집에 이들 작업을 커버할 PC가 있다면, 맥 머신은 깡통으로 해도 무리가 없다.
이러한 것을 실재로 해보면 확신이 되는데 다들 구입전에는 확인을 못하고, 애플 스토어가도 이런 테스트를 못하는 것도 겹쳐서 갑론을박 되는데, 제일 포괄적인 답변은 (i) 우선 비용이 충분하면 램을 16GB 이상 달아라 (ii) 세부를 조정할 아이디어가 있으면 깡통으로 해도 되는 경우가 있다. 이것이 결론입니다.
플러터로 멀티플랫폼 모바일 앱 개발을 하는데 iOS용 빌드는 맥에서만 가능합니다. 본래 가격이 좀 쎈 편인 기기들이라 안드로이드 앱을 우선 출시하고 돈벌어 구하려다가 비용 사정이 나아져서 맥 미니 M2 버전을 신청해두었네요. 8GB 모델이고 M2도 8코어 CPU에 10코어 GPU 라는데 우선 플러터 개발을 위한 머신으로 신청했고, 어느 정도 성능이 나온다면 캡처 장치를 연결할 목적으로도 쓰고 싶은데요. 선더볼트 4 포트가 2개 있어서 연결하면 되는데, SSD가 256GB 이고 따로 다른 SSD가 안달려 있어서 ProRes 캡처가 필요할때 SSD 성능이 어떨련지 궁금하네요. 캡처 장치가 선더볼트 3에 무압축 코덱을 지원하는데 무압축으로 캡처받으면 SSD가 macOS 설치된 SSD라, 분리된 SSD가 아니라서 어떻게 될지 미상입니다. 왠만하면 잘 되겠죠.
대략적인 사양은 아래와 같습니다.
M2 프로세서가 좋다고 하는데 일단 제가 신청한 제품 CPU는 M2 Pro 가 아닌 M2 이구요. Xcode를 주로 돌릴 생각인데 빌드가 잘 될지 미상입니다. 규모가 안큰 프로젝트들이 될 것 같고 macOS은 어떤지 모르지만 부팅하고나서 6GB 이상만 여분이 있으면 컴파일할때도 크게 지장이 없을 것 같습니다. 전에 들은바로는 컴파일시 램이 8GB 밖에 안되면 안된다는 의견도 있던데요. 스택과 VM에 램을 최대한 할당해볼 생각입니다. 여의치 않으면 램 증설하거나요.
그런데 업글이 가능한지는 직접 봐야 하는데 일단 구입하고나면 업글이 불가능하다는 말이 있네요. 아무래도 밀폐된 케이스라서 그런 듯한데 아마존에서 구해서 할부 한달 지불 비용을 낮출 수 있었으나 램은 기본탑재 크기인 8GB 그대로입니다. 구입후에도 업글이 되면 좋겠습니다. 케이스를 여는게 가능하다면요. 램말고 보조기억장치도 SSD를 하나 더 달거나 램을 직접 더 달거나 등등의 작업이 안되면 어떡할까요. 그래도 초기 세팅된 하드웨어로도 가능할 것 같긴 한데요.
일단 Xcode 잘 돌아가면 됩니다. 하지만 캡처 기능의 경우 SSD 하나 더 못달면 OS를 설치한 SSD로 캡처도 처리해야 하는데 잘 될지 확인해봐야 하겠습니다. SSD니, 과부하가 늦게 올테지만 코덱에 따라서는 문제가 있을 것 같기도 합니다.
여튼 주목적이 플러터로 iOS 앱 개발도 하는 것이라 앱 테스트 용도로 앞으로 비용 추이봐서 아이폰이나 아이패드도 구해야 하는데 비용이 넘칠 수도 있습니다. 비용이 넘치면 iOS 실행 테스트는 에뮬레이터로 버텨야 할 것 같습니다. 이번달에서도 비용이 거의 커버할 것 같으나 일단 살펴봐야 합니다.
M2 맥 미니 머신을 구하면 좋은 점은
(1) iOS 앱 개발 가능 (2) M1 맥 미니 제품에 비해 100불 저렴함 (3) ProRes 캡처 가능
아무래도 M2가 SoC인 것 같습니다. 해체하는 영상이 있는데 로직보드가 굉장히 작네요. ARM 계열입니다. CPU의 기능들을 담당하는 컴포넌트와 GPU, Neural Processor, WiFi 등이 한칩에 들어간 것 같습니다. 확인해보면 이중에 몇개는 아닐 수 있더라도 SoC의 정의가 그러하네요. 그래서 작은 크기로도 성능이 나오는 것 같습니다.
아마존 캐나다에서는 애플 캐나다에서보다 더 낮은 한달 비용으로 할부를 더 세부적으로 고르는게 되는 것 같습니다. 물론 할부 기간을 늘리고 한달 비용을 낮추면 이자가 붙기도 하네요. 일단 구입적으로 메리트가 있는게 아마존 캐나다에서 애플 스토어 채널을 이용하는 것 같습니다.
참고로 애플 캐나다와 아마존 캐나다에서 형성된 가격이 M2 기종이 M1 기종 동급 라인업보다 100불이 저렴하네요. 새로 나온 제품인데…
