문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 Mac(컴퓨터) (문단 편집) === 소프트웨어 개발 === [youtube(Gom6eTpgbOw)] 위 영상의 [[노마드 코더|니콜라스]] 曰: '''비싸니까''' 뽕을 뽑기 위해서 Mac으로 열심히 일해야 하고, 별다른 '''설정과정이 필요없고''' '''게임이 안 돼서''' 시간낭비 없이 갖고 일만 할 수 있는 게 장점이란다... 엄밀히 말해 어떤 개발 작업이든 os는 큰 상관이 없다. 진정한 개발자라면 터미널만 띄워진 리눅스 PC에서도 모든 것을 다 한다. 지금 시대에도 개발을 하기 위해 맥이 꼭 필요하다면 그것은 ios 관련 개발을 위해서나 필요할 뿐이고 그나마도 네이티브가 아닌 웹앱으로 가기 때문에 구태여 앱을 개발할 필요성도 적다. 그 이외의 개발이라면 다른 OS에서도 당연히 충분히 가능하다. 조금 진지하게 말하자면 통합개발도구가 널려있지만 서버관리나 깊은 하드웨어쪽은 리눅스에게 경쟁력에서 밀리는 Windows, [[통합 개발 환경|통합개발도구]]를 구하기 힘들어서 [[vim]]으로 씨름해야하지만 서버관리같은 부분에서 두각을 발휘하는 리눅스, Mac이 그 리눅스와 친척관계에 있기에 틈새시장에서 살아남는 것으로 어느정도 사용량을 계속 확보하는 것이다.[* 물론 Windows도 굳이 따로 손보지 않더라도 Windows 10부터 [[유닉스/MS 윈도우|Windows Subsystem for Linux(WSL)]]를 통해 bash와 POSIX를 지원하기 시작했지만 Windows 영역과 WSL 영역은 서로 분리된 별개의 공간이라 근본이 [[UNIX]]인 Linux만큼 편리하지는 않다. Windows 환경에서 WSL에 설치된 컴파일러나 POSIX API를 사용하려면 항상 SSH 통신으로 WSL과 연결해 주어야만 한다.그래도 WSL 2(Windows 10 2004 Update)가 정식으로 릴리스된 후에는 Windows Terminal을 Linux CLI로 사용할 수도 있고, VS Code에서 쉽게 연동해서 사용 가능하게 됐다.][* Windows는 태생부터 리눅스와 다르다보니, 근본적으로 CLI 환경도 리눅스 기반의 OS와는 너무나 다른 환경을 가지고 있어서 앱등이들이 말하듯이 윈도우즈는 GUI쪽의 발전이 빠르고 CLI쪽은 그에 비해선 느린 편이라 안맞는다 어쩐다 하는 것도 논리적으로 맞질 않는다. 애시당초 아예 환경이 다른데 따지고 말고 할 것이 아닌 것. 게다가 앱등이들은 Windows의 패키지 관리자가 Chocolatey나 NuGet같이 파편화 되어있다고 하는데 이는 명백한 날조와 선동으로 Chocolatey는 choco 명령어를 사용해서 손쉽게 윈도우 운영체제에서 사용되는 애플리케이션을 관리할 수 있는 NuGet 기반의 윈도우용 패키지 관리자이다. Mac에서 쓰는 홈브루는 Ruby로 개발했는데 같은 논리면 홈브루와 루비는 파편화된 것인가? 말이 안된다.][* 사실 패키지 관리자까지 써서 봐야 하는 CLI니 뭐니 하는 영역은 원래 MS에서 그것도 커널담당 일부나 손보던 물건이라 오픈소스니 생태계니 이런 걸 생각할 이유도 없었고 고로 사외 개발자들이 쓸 패키지 매니저 같은 걸 만들 필요성도 없었던 것이다. 하지만 변화하는 환경 속에서 윈도우즈 생태계를 만들 필요가 있었고 그를 위해선 사외 개발자들이 자기들의 필요에 따라 만들 개발 툴을 만들어야 하므로 패키지 관리자 같은 걸 만들기 시작 한 것.] Mac 찬양론자들에 의하면 Mac은 Windows의 점유율을 뛰어넘어야 하지만 현실은 Mac은 Windows의 점유율보다 한참 낮은 15% 정도이다. 또한 맥이 유닉스 기반이긴 하지만 리눅스 라이크이지 리눅스가 아니다. 때문에 맥을 '''지원하지 않는 개발도구'''가 꽤 있다. 리눅스는 [[북한]]조차도 자체 OS개발에 쓸 정도로 오픈 소스 운영체제로 굴러간 지 오래다. 당연히 지원 안되는 경우도 많다. 일부에서마냥 다 되는 것처럼 말하는 것이 말도 안되는 것이다. 만약에 '''내가 개발하는건 리눅스나 Windows로도 개발환경 꾸릴수 있어요!'''하는경우는 MacBook이 필요없다. 점유율이 낮은데도 버티는 이유는 바로 이 '''[[틈새시장]]''' 때문이다. 에지간한 앱등이들도 워크스테이션 등급의 200만원이상 되는 MacBook은 잘 사지 않고, 개발자 중에서도 '''꼭 필요한 경우'''에 한해서만 사용한다.--그 비싼거 사는사람중 다수는 그냥 화면크기 때문에 혹은 재력이 있어서 사는 사람들이다. -- Mac에서 리눅스 기반 프로그램을 자유롭게 손 댈 수 있을 것이라는 생각은 안하는 게 좋다. 개발자 입장에서 Mac이 반드시 필요한 경우에는 [[iOS]]용 애플리케이션의 개발 때문이다. 우선 iOS 앱을 빌드하려면 [[Xcode]]와 [[Swift]]가 필요한데, Swift는 Windows용 컴파일러가 나왔지만 Xcode는 오직 Mac에서만 사용할 수 있어 Windows에서는 iOS 앱 개발이 사실상 불가능하다. 반면 [[안드로이드 스튜디오]]는 Windows와 Mac을 둘 다 지원하므로 이를 통해 Mac에서 [[안드로이드(운영체제)|안드로이드]]용 앱과 [[iOS]] 앱을 모두 빌드할 수 있다. Windows 전용으로 제공됐던 [[Microsoft .NET#Framework|.NET Framework]]와 [[C\#]] 역시 Microsoft에서 오픈 소스 버전인 .NET Core와 [[Visual Studio#s-5.1.5|Visual Studio for Mac]]을 공개한 덕분에 Mac에서도 개발이 가능해졌다. 사실 소프트웨어를 개발할 때 진짜로 좋은 건 [[Linux]] 환경이다. 운영체제 자체도 [[오픈 소스]]라 GUI부터 내부적인 파일 시스템까지 거의 모든 부분에서 커스터마이징이 자유롭기 때문이다. 다만, Linux의 특성상 상용 소프트웨어들의 사용이 어렵거나 호환이 잘 안 되는 경우가 많아 '''[[틈새시장|그 중간의 타협지점으로 Mac을 선택하는 경우가 많은 것이다]]'''. 프로그래머들이 컴퓨터 다음으로 중요하게 생각하는 키보드/마우스만 봐도, Linux 환경에서는 드라이버가 호환되지 않거나 부분적인 오류가 있어 맘 편하게 쓰기가 어렵다. 키 리맵핑이나 펑션키 세팅 등은 언감생심이고 그나마 설정해둔 것도 커널 버전이 올라가면 초기화되어 버리기도 한다. [[Git]] 형상관리 툴 중에서 가장 많이 쓰이는 SourceTree는 Windows와 macOS만을 지원하며, Linux는 공식 지원하지 않는다. 게다가 개발자들도 회사에서 업무를 하다 보면 오피스 작업을 종종 해야 할 때가 있는데, Linux에서 지원하는 [[리브레오피스]]는 쓰다 보면 욕이 나오는 수준. 결국 네이티브 Linux는 서버용/임베디드용 OS로 한정되는 것이 현실이다. 게다가 게임 개발 분야에서는 당연히 Windows가 낫다. 게임은 대개 Mac 환경보다는 Windows 환경에서 만들어지며, 게이머들 또한 절대 다수가 Windows에서 게임을 즐기기 때문이다. 게임 개발은 [[언리얼 엔진]]이나 [[유니티(게임 엔진)|유니티]] 같은 미들웨어의 도움을 받아서 진행한다. 엔진 없이 Win32를 생짜로 이용해 가며 대규모 게임을 만들다간 지쳐서 나가떨어질 것이다. 만약에 Mac 으로 게임 출시가 예정 되어 있다고 하더라도, 결국에는 Windows 에 의존할 수밖에 없는데, 게임은 코드타이핑만 해서 만들어 지는 것이 아닌, 그래픽 디자인 UI 디자인 등의 과정을 거쳐야 하기 때문에 게임엔진 개발툴이 Mac 에서 돌아간다고 Windows 가 필요없는게 아니다. 대부분의 회사들은 Windows 기준으로 개발하고 크로스 플랫폼 이식용 에셋이나 라이브러리를 활용해서 빌드만 Mac 에서 하는것이 보통이다. AAA 게임보다 인디게임들이 의외로 Mac 지원을 잘해주는 이유가 바로 게임엔진들은 기본적으로 크로스플랫폼을 지원 잘해주기 때문이다. 반대로 임베디드 소프트웨어를 개발하는 곳이라면 무거운 Windows나 Mac보다는 Linux가 유리할 것이다. 결국, 모든 수요는 필요에 의해 생겨날 뿐이다. 요약하자면 리눅스 원격을 돌리는 등의 성능이 중요치 않은 분야거나, 앱이나 웹같은 플랫폼 제약이 적은 분야에서 작업하는 경우는 세팅이 간편한 Mac의 수요가 꽤 존재한다. 유닉스 기반이면서도 리눅스와 달리 Apple이라는 개발의 구심점이 있고 [[Cocoa API]]와 [[Swift]]로 강제 중앙집권화가 되어있다는 점이 말단 개발자 입장에서는 매우 편하게 느껴진다. 다만 항상 파편화가 적은게 장점은 아닌데, 일부러 레거시지원을 끊는다거나, 오로지 Apple이 권고하는 API 만 사실상 사용 강제하는 등의 정책을 펼쳤기 때문에 파편화가 적은것이라 개발자에게 마냥 좋다고 보기 어렵다.이러한 점 때문에 이미 서비스 하던 게임들도 지원을 끊는 경우가 다반수. 지속적인 신버전을 내는 방향이 아닌 기존 소프트웨어 유지보수의 방식을 채택하는 개발사들에게는 매우 불친절한 플랫폼이다. 게임 뿐만 아니라, 드라이버 업데이트가 자주 제공되지 않는 특정 하드웨어를 연결하려면 일부러 레거시 지원을 빼버리는 Mac 은 효용성이 매우 낮다.[* 하다못해 프린터 연결도 Windows 만큼 깔끔하게 연결되지 않는다.] 어느정도의 레거시 하드웨어, API 의존이 필요한 분야들은 Windows 점유율이 압도적이다. 고가의 산업 장비를 Mac 하나 쓰고싶다고 휙 휙 바꿔버릴 수는 없지 않은가. 레거시 문제는 Windows 의 소프트웨어 풀이 더 넓은것과도 연관이 있는데, Windows 는 레거시 지원을 잘 해주는 편이라 한 번 만들어 놓은 프로그램들을 계속 우려먹을 수 있다. 개발력이 부족한 중소 개발사들과 오픈소스 개발자들에게는 매력적인 부분. 그렇기 때문에 Windows는 성능좋은 프리웨어의 종류가 많지만, Mac 의 경우 지속적인 업데이트가 없으면 죽은 소프트웨어가 되기 때문에 업데이트를 위해서 구독제나 유료 소프트웨어들이 Windows 대비 많은 편이다. 물론 레거시를 적극적으로 쳐낸다는게 항상 단점도 아니긴 하다. 상술했듯 파편화를 최소화 한다는 장점이 있으며, 구세대 기술에 발목이 잡히지 않으므로 신기술 채택이 훨씬 용이하다. Windows 같으면 hidpi 와 기존 win32 API 를 동시에 잡기위해 UI 구성하는 방법이 매우 난잡하지만, Apple 의 경우 레거시를 적극적으로 쳐냄으로서 누구보다 빠르게 hidpi 를 안착시키는데 성공했다. 이러한 특징 때문에 애플 플랫폼 편향적 개발사가 있기도 하다. 그리고 레거시를 아주 잔혹하게 쳐내는것도 아니고 다음으로 넘어가기 위한 유예기간을 생각보다는 길게 주는 편이다. 그래서 본인이 아무것도 모르는 상태에서 돈들여 Mac을 하나 장만하는건 좋은 생각이 아니다. 무엇보다 요즘 많이 쓰는 프로그래밍 쪽은 Windows에서 손만 좀 쓰면 별 문제 없이 돌아간다. Mac사용자 라도 Mac이 없다고 일 못하지 않는다.어차피 그냥 익숙해서 쓰는 사람혹은 사소한 Mac 의 독특한 기능[* Sidecar, Airdrop, Time machine, Retina 디스플레이 등]때문에 쓰는사람이 대부분이니 프로그래머 맥 점유율에 큰 의미부여 안하는게 좋다. 오히려 요즘은 10에 8은 그냥 윈도우즈 쓰고 나머지가 맥이나 리눅스같은 다른 os를 쓰며 맥의 특화인 디자인이나 음악 쪽도 큐베이스를 쓰는 등 윈도우즈로 많이 넘어어온 상황이다. macOS는 mac에서만 구동되는 os이고, windows는 IBM계열 기기에서 구동되는 os인데 애플의 폐쇄적인 정책과 MS의 개방적인 정책이 현재 시장 점유율의 결과를 가져왔다고 볼 수 있다. 체험판 기능만 해도 GUI가 어떻고 CLI가 어떻고 하는 개발자 같은 영역에 접근 안 할 일반인이면 딱히 아쉬울 것이 없으며 일반인이면 일단 부정적인 태도이긴 하지만 NCND에 가까운 정책으로 불법복제까지 끌어안다보니 Windows가 개발자 영역까지 잠식해내가고 있는 상황이다. 소프트웨어 개발 쪽에서 맥이 유의미한 점유율을 지니는 분야는 스타트업이나 인터넷 서비스를 만드는 회사로 이 쪽에서는 업무 환경이 대부분 맥으로 표준화되어 있다. 맥을 사용하는 이유는 unix-like라는 점이 있고, 소프트웨어 하드웨어 양쪽 모두 단일 벤더이기 때문에 회사 입장에서 관리하기가 편하며, 이쪽 업계에서 사용하는 도구들이 맥용 지원이 빠르다는 점 등이 있다. 회사에서 지급된 업무용 맥을 사용하다가 경로의존성이 형성되어 계속 맥을 사용하게 되는 사용자들도 적지 않다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기