Objective-C 언어의 역사 — 애플이 만들지도 않은 이 언어가 아이폰 생태계를 지배한 이유

Objective-C는 아이폰과 맥 앱을 만드는 데 오랫동안 쓰인 프로그래밍 언어입니다. 그런데 이 언어를 애플이 처음부터 직접 만든 건 아닙니다. 1980년대 초 한 통신회사 연구실에서 태어난 Objective-C가 어떻게 스티브 잡스의 NeXT를 거쳐 아이폰 생태계의 뼈대가 됐는지, 그리고 왜 애플이 결국 Swift로 갈아탔는지, 그 40년 역사를 정리해 봤습니다.
"iOS 코드 처음 봤을 때 대괄호 [ ] 도배된 화면 보고 이게 무슨 언어인가 싶었어요."
"Swift 나온 지가 언젠데 아직도 Objective-C를 봐야 하나요?"
"애플은 왜 하필 이렇게 유별난 문법의 언어를 골랐을까요?"
저는 iOS 네이티브 개발자가 아니라 웹 쪽으로 커리어를 쌓아온 사람입니다. 그래서 Objective-C는 늘 옆자리 동료의 모니터에서, 하이브리드 앱 작업하다 잠깐 스치는 브릿지 코드에서 곁눈질로만 봐온 언어였어요. 대괄호가 유난히 많고 문장이 길쭉한 그 코드는 솔직히 처음엔 좀 기괴해 보였습니다. 그런데 이 언어의 내력을 파고들수록, 저 이상한 문법 하나하나에 다 이유가 있었다는 걸 알게 됐습니다.
이 글은 Objective-C의 탄생부터 아이폰 시대의 지배, 그리고 Swift에게 자리를 넘기기까지를 시대순으로 따라갑니다. iOS 개발에 발을 들이려는 분, 오래된 애플 코드가 왜 지금 모양이 됐는지 궁금한 분, 언어의 역사 자체가 재미있는 분에게 도움이 될 겁니다.
📋 목차
- Objective-C는 애플이 만든 언어가 아니다
- 브래드 콕스가 진짜 팔고 싶었던 것
- 그 악명 높은 대괄호 [ ]의 정체
- 잡스와 NeXT, 쫓겨난 자의 선택
- 애플로 돌아온 언어
- 2007년 첫 아이폰엔 앱이 없었다
- 2008년, Objective-C가 세계를 먹은 순간
- 왜 하필 이 복잡한 언어였나
- Swift의 등장과 Objective-C의 오늘(2026년)
1. Objective-C 탄생 — 애플이 만든 언어가 아니다
많은 분이 오해하는 부분부터 짚고 갑니다. Objective-C는 애플이 아이폰을 위해 만든 언어가 아닙니다. 이 언어의 뿌리는 1980년대 초, 통신 대기업 ITT의 프로그래밍 기술 센터로 거슬러 올라갑니다.
당시 소프트웨어 업계는 이른바 '소프트웨어 위기'를 앓고 있었습니다. 프로그램은 점점 커지고 복잡해지는데, 코드를 재사용하거나 관리하는 방법은 마땅치 않았죠. ITT 연구팀에서 이 문제를 붙들고 있던 사람이 톰 러브(Tom Love)와 브래드 콕스(Brad Cox)였습니다. 두 사람은 개발자 생산성을 열 배쯤 끌어올릴 방법을 찾고 있었고, 그 답을 당시 학계에서 주목받던 객체 지향 언어 Smalltalk에서 봤습니다.
문제는 현실이었습니다. ITT 같은 통신 현장은 이미 C 언어 위에 굴러가고 있었거든요. Smalltalk가 아무리 좋아도 기존 C 자산을 다 버리고 갈아탈 수는 없었습니다. 그래서 콕스는 1981년, 발상을 바꿉니다. Smalltalk를 통째로 도입하는 대신, Smalltalk의 핵심 아이디어인 '메시지 전달' 방식을 C 위에 얹어버린 겁니다. 이렇게 만든 게 OOPC(Object-Oriented Pre-Compiler), Smalltalk 비슷한 문법을 평범한 C 코드로 번역해 주는 전처리기였습니다.
📌 여기서 핵심
Objective-C는 처음부터 "C를 버리지 않는다"는 전제 위에서 태어났습니다.
기존 C 코드와 라이브러리를 그대로 쓰면서 객체 지향의 유연함만 얹는다
이 실용주의가 훗날 애플이 이 언어를 고른 이유와 곧바로 연결됩니다.
2. 브래드 콕스가 진짜 팔고 싶었던 것
콕스와 러브는 ITT를 나와 자기 회사를 차립니다. 처음 이름은 PPI(Productivity Products International), 나중에 Stepstone으로 바뀌는 회사죠. 콕스는 이전 고용주와의 법적 분쟁을 피하려고 컴파일러를 다시 구현하면서 언어 이름도 바꿉니다. 그게 바로 Objective-C였습니다. 1986년에는 이 언어를 정식으로 소개한 책 Object-Oriented Programming: An Evolutionary Approach도 펴냈고요.
그런데 여기서 좀 뜻밖의 사실이 있습니다. 콕스 본인은 사실 프로그래밍 언어 자체에는 큰 관심이 없었다고 훗날 밝혔습니다. 그가 진짜 만들고 싶었던 건 '소프트웨어 IC(Integrated Circuit)'였어요. 전자 부품을 사다가 회로에 꽂듯이, 소프트웨어 부품을 사다가 조립해서 프로그램을 만드는 세상. 콕스는 이걸 '소프트웨어 산업 혁명'이라고 불렀습니다. 언어는 그 비전을 이루기 위한 도구일 뿐이었던 거죠.
💡 지금 다시 보면
콕스가 꿈꾼 '재사용 가능한 소프트웨어 부품'은 오늘날 우리가 npm으로 패키지 당겨 쓰고,
라이브러리 조립해서 앱 만드는 방식과 크게 다르지 않습니다.
40년 전 아이디어가 방향은 맞았던 셈이에요.
다만 그 혁명의 주인공이 Objective-C가 될 거라고는 콕스 본인도 예상 못 했을 겁니다.
3. 대괄호 [ ] 문법의 정체 — 왜 이렇게 생겼나
Objective-C를 처음 본 사람이 가장 당황하는 지점이 바로 그 대괄호입니다. [object doSomething] 같은 문법이요. 다른 언어에서 익숙한 object.doSomething()과는 생김새부터 다릅니다.
이 대괄호는 취향이나 실수가 아니라 설계 의도였습니다. 톰 러브가 이 언어를 '두 층으로 나뉜 하이브리드'로 만들자고 정했거든요. 아래층은 원래의 절차적 C 코드, 위층은 객체 지향 코드. 그리고 이 위층 코드를 아래층과 시각적으로 확실히 구분하기 위해 대괄호로 감싸버린 겁니다. [ ] 안에 들어 있으면 "이건 객체에게 메시지를 보내는 거다"라는 신호인 셈이죠.
그래서 [object doSomething]은 정확히는 "object에게 doSomething이라는 메시지를 보낸다"는 뜻입니다. 함수를 호출한다기보다 객체에게 말을 건다는 개념에 가깝습니다. Smalltalk에서 물려받은 이 '메시지 전달' 사고방식이 Objective-C의 성격을 결정했고, 뒤에 나올 동적인 특성의 뿌리가 됩니다. 낯설긴 해도, 알고 보면 나름 일관된 철학이 있는 문법이었던 거예요.
4. 잡스와 NeXT — 쫓겨난 자의 선택
이야기의 무대가 바뀝니다. 1985년, 스티브 잡스는 자신이 세운 애플에서 밀려납니다. 그리고 NeXT라는 새 컴퓨터 회사를 차리죠. NeXT의 목표는 대학과 연구 시장을 겨냥한 고성능 워크스테이션과, 그 위에서 돌아갈 운영체제 NeXTSTEP을 만드는 것이었습니다.
NeXT 엔지니어들은 복잡한 그래픽 애플리케이션을 유연하게 만들 도구가 필요했고, 그 선택이 Objective-C였습니다. 이 언어의 동적 바인딩(실행 시점에 어떤 코드를 부를지 결정하는 방식)은 버튼 누르고 창 띄우고 하는 GUI 프로그래밍과 궁합이 좋았거든요. NeXT는 1988년 Stepstone으로부터 Objective-C를 정식 라이선스하고, 자유 소프트웨어 컴파일러인 GCC를 확장해 Objective-C를 지원하게 만듭니다. Stepstone의 번역기에 의존하던 구조에서 벗어난 거죠.
NeXT는 여기에 AppKit과 Foundation이라는 프레임워크를 얹습니다. 이 이름, 애플 개발 좀 해본 분이라면 익숙하실 겁니다. 맞습니다. 지금 우리가 쓰는 그 프레임워크들의 조상이 바로 여기서 나왔습니다. 참고로 정작 Objective-C를 만든 Stepstone은 경영난에 시달리다 1994년 문을 닫았고, 이듬해인 1995년 NeXT가 언어의 상표권과 권리를 통째로 넘겨받습니다. 만든 회사는 사라지고, 쓰던 회사가 주인이 된 셈입니다.
5. 애플로 돌아온 언어 — Mac OS X의 뿌리
NeXT는 상업적으로 크게 성공하진 못했습니다. 하지만 반전이 기다리고 있었죠. 1996년 12월, 애플이 NeXT를 인수하기로 발표합니다. 당시 애플은 차세대 운영체제 개발에 번번이 실패하며 위기에 빠져 있었고, NeXT의 검증된 기술이 그 해법이었습니다. 인수는 이듬해 초에 마무리됐고, 잡스는 그렇게 애플로 돌아옵니다.
이 사건의 의미는 단순한 기업 인수를 훨씬 넘어섭니다. NeXTSTEP의 핵심 기술이 그대로 애플로 넘어와, 훗날 Mac OS X(현재의 macOS)의 토대가 됐거든요. NeXT의 AppKit과 Foundation은 애플에서 'Cocoa'라는 이름의 프레임워크로 다시 태어났습니다. 그리고 이 모든 것의 공용어가 Objective-C였습니다. 애플의 개발 도구, 프레임워크, 문서가 전부 Objective-C를 중심으로 재편됐고, 이때부터 "애플 플랫폼에서 앱을 만든다 = Objective-C를 쓴다"는 공식이 굳어집니다.
| 연도 | 사건 |
|---|---|
| 1981 | 콕스, ITT에서 OOPC(전처리기) 작성 — Objective-C의 씨앗 |
| 1986 | 콕스, Objective-C를 정식 소개한 책 출간 |
| 1988 | NeXT, Objective-C 라이선스 + GCC 확장 |
| 1995 | NeXT, Stepstone으로부터 언어 권리 인수 |
| 1996~97 | 애플이 NeXT 인수 (발표 96년 말, 완료 97년 초), 잡스 복귀 |
| 2008 | iPhone SDK 공개 → App Store 개장 |
| 2014 | 애플, Swift 발표 |
6. 2007년 첫 아이폰엔 사실 앱이 없었다
여기서 흔히 잘못 알려진 사실 하나를 바로잡고 가겠습니다. "2007년 아이폰이 나오면서 Objective-C로 앱을 만들기 시작했다"는 설명, 사실이 아닙니다.
2007년 6월 첫 아이폰이 출시됐을 때, 외부 개발자가 만들 수 있는 네이티브 앱은 아예 존재하지 않았습니다. 기본 탑재된 앱 십여 개가 전부였죠. 그럼 잡스가 개발자들에게 제시한 방법은 뭐였을까요? 바로 웹앱이었습니다. "아이폰엔 완전한 Safari 엔진이 들어 있으니, Web 2.0과 Ajax로 앱처럼 보이는 웹사이트를 만들면 된다. SDK 같은 건 필요 없다" — 이게 잡스가 내놓은 답이었습니다.
웹 개발자 입장에서 저는 이 대목이 좀 묘하게 느껴집니다. 잡스는 한때 네이티브 대신 웹을 밀었던 사람이었던 거예요. 하지만 개발자들의 반응은 싸늘했습니다. 당시 웹앱은 성능도, 기기 기능 접근도, 유료화도 다 어중간했거든요. 반발이 이어지자 탈옥(jailbreak) 커뮤니티가 먼저 움직여 비공식 앱을 만들어 유통하기 시작했고, 결국 애플도 방향을 틀 수밖에 없었습니다. 2007년 10월, 잡스는 공개 서한을 통해 이듬해 네이티브 앱 SDK를 내놓겠다고 약속합니다.
7. 2008년, Objective-C가 세계를 먹은 순간
약속대로 2008년 3월, 애플은 첫 iPhone SDK를 공개합니다. 이 SDK의 기본 언어가 바로 Objective-C였고, 앱을 만드는 프레임워크로는 데스크톱의 Cocoa를 터치 환경에 맞게 다듬은 Cocoa Touch가 제공됐습니다. 그리고 그해 7월, 앱 500개와 함께 App Store가 문을 엽니다.
이때부터 상황이 달라집니다. 개발자가 앱을 팔면 매출의 70%를 가져가는 구조가 열리자, 전 세계 개발자들이 아이폰으로 몰려들었습니다. "there's an app for that(그런 앱이 있어요)"라는 광고 문구가 유행할 만큼 앱은 일상이 됐고, 그 앱들을 떠받친 언어가 Objective-C였습니다. 낯선 대괄호 문법에 진입 장벽이 높다는 불평이 여전했지만, Cocoa Touch와 맞물려 부드러운 애니메이션과 터치 UI를 구현할 수 있다는 점 앞에서 개발자들은 결국 대괄호와 화해했습니다.
💡 타이밍이라는 변수
2008년은 3G 통신이 깔리고 Facebook, Twitter 같은 서비스가 폭넓게 퍼지던 시기였습니다.
설령 애플이 2007년에 App Store를 열었더라도,
그걸 받쳐줄 네트워크와 생태계가 아직 무르익지 않았을 겁니다.
기술의 성공은 언어의 우수함만으로 결정되지 않는다는 걸 보여주는 대목이에요.
8. 왜 하필 이 복잡한 언어였나
다시 처음 질문으로 돌아와 봅니다. 애플은 왜 더 쉬운 언어를 두고 이 유별난 언어로 생태계를 세웠을까요? 몇 가지가 맞물린 결과라고 보는 게 정확합니다.
우선 애플에게는 선택의 여지가 별로 없었습니다. Objective-C는 NeXT 시절부터 20년 가까이 쌓아온 자산이었으니까요. macOS의 프레임워크가 전부 이 언어로 짜여 있는데, 아이폰만 다른 언어로 시작하는 건 앞뒤가 안 맞았습니다. 이미 있는 Cocoa 자산을 그대로 물려받는 게 훨씬 빠른 길이었죠.
성격도 잘 맞았습니다. C 기반이라 초기 아이폰의 빠듯한 하드웨어에서도 빠르게 돌았고, 동시에 동적인 특성 덕분에 화면 요소를 유연하게 다룰 수 있었습니다. 성능과 유연성을 한 몸에 지녔다는 점이 모바일 앱 개발에 유리하게 작용한 겁니다. 결과적으로 대괄호라는 진입 장벽은 애플 입장에서 오히려 자기 생태계를 단단하게 묶는 울타리 역할도 했습니다. 한번 이 언어에 익숙해진 개발자는 애플 플랫폼에 눌러앉게 됐으니까요.
9. Swift의 등장과 Objective-C의 오늘(2026년)
영원한 지배는 없었습니다. Objective-C는 1980년대 초의 설계를 오래 유지하다 보니, 시간이 갈수록 현대 개발자들에게 번거롭고 오류가 나기 쉬운 언어로 여겨졌습니다. 수동 메모리 관리, 장황한 문법, 포인터의 위험성 같은 것들이 발목을 잡았죠.
그래서 애플은 2014년 WWDC에서 새 언어 Swift를 발표합니다. 크리스 래트너(Chris Lattner)가 2010년부터 개발해 온 언어로, 더 간결하고 안전한 문법을 내세웠습니다. Swift는 Objective-C와 서로 호출할 수 있는 상호운용성을 갖췄기 때문에, 기존 코드를 한 번에 갈아엎지 않고도 조금씩 옮겨갈 수 있었습니다. 그 덕에 확산 속도가 빨랐고요.
그렇다면 지금 Objective-C는 죽은 언어일까요? 그렇게 단정하긴 이릅니다. 2026년 현재 애플은 Foundation 같은 핵심 프레임워크를 Swift로 옮기는 작업을 여러 해에 걸쳐 진행 중입니다. 실제로 2026년 WWDC에서 공개된 Swift 6.4에서는 오랫동안 Objective-C 기반이던 NSURL 같은 요소가 Swift 구현으로 통합됐죠. 방향은 분명히 Swift입니다. 다만 수십 년간 쌓인 방대한 레거시 코드와 상호운용성 때문에, Objective-C는 애플 플랫폼 깊숙한 곳에서 당분간 계속 함께 갈 겁니다. 오래된 프로젝트를 유지보수하거나, 애플 프레임워크의 밑바닥을 들여다볼 일이 있다면 여전히 마주치게 되는 언어라는 뜻입니다.
❓ 자주 묻는 질문
Q. Objective-C는 지금 배워도 될까요?
새로 iOS 개발을 시작한다면 Swift가 기본입니다. 다만 오래된 프로젝트 유지보수나 애플 프레임워크의 동작 원리를 깊이 이해하려면 Objective-C를 읽을 줄 아는 게 여전히 도움이 됩니다. '새로 짜는 언어'라기보다 '읽어야 할 언어'에 가까워졌다고 보시면 됩니다.
Q. Objective-C와 C, C++는 어떤 관계인가요?
Objective-C는 C의 확장판입니다. C 문법을 그대로 품은 채 객체 지향 기능을 얹은 형태라, C 코드를 Objective-C 안에서 그대로 쓸 수 있습니다. C++와 섞어 쓰는 Objective-C++(.mm 파일)도 있습니다.
Q. 왜 애플은 Swift를 새로 만들었나요?
Objective-C의 설계가 워낙 오래돼 현대적 안전장치(널 안전성, 값 타입 등)를 넣기 어려웠기 때문입니다. 기존 언어를 계속 늘리기보다, 상호운용은 유지하면서 새 언어로 갈아타는 편이 낫다고 판단한 거죠.
마무리
Objective-C의 역사는 한 언어가 어떻게 시대와 사람을 만나 운명이 바뀌는지 보여주는 이야기입니다. 통신회사 연구실의 실용적인 고민에서 출발해, 잡스라는 인물의 부침을 따라 애플의 심장부까지 들어갔고, 아이폰이라는 거대한 무대를 만나 한때 세계에서 가장 많이 쓰이는 앱 언어가 됐습니다. 그리고 이제는 Swift에게 무대를 넘기며 조용히 뒤로 물러나는 중이고요.
저 낯선 대괄호 하나에도 40년 전 누군가의 설계 철학이 담겨 있다는 것 — 언어의 역사를 들여다보는 재미가 여기 있는 것 같습니다. 지금 우리가 당연하게 쓰는 도구들도 언젠가는 이렇게 누군가의 '옛날이야기'가 되겠죠. 그 관점으로 코드를 보면, 익숙한 화면이 조금 다르게 보일지도 모릅니다.
📚 함께 보면 좋은 글
스위프트(Swift) 언어 역사: 애플은 왜 잘 쓰던 Objective-C를 버렸을까? (2026년 최신 총정리)
Swift 언어의 역사를 이야기할 때 빠지지 않는 질문이 있습니다. 애플은 왜 20년 가까이 잘 써오던 Objective-C를 두고 굳이 새 언어를 만들었을까요. 이 글에서는 Objective-C가 애플의 언어가 된 배경부
devwar.tistory.com
Dart(다트) 언어 역사 - 자바스크립트 대체 실패에서 플러터의 심장이 되기까지
Dart(다트)는 구글이 자바스크립트를 대체하겠다며 2011년에 내놓은 프로그래밍 언어입니다. 브라우저 안에 Dart VM을 심겠다는 야심으로 출발했지만 2015년 그 계획이 무산되면서 한동안 "실패한 언
devwar.tistory.com
AI 개발 언어 1위는 왜 파이썬일까 - 느린데도 이긴 언어의 역설
AI 개발 언어 1위는 몇 년째 파이썬(Python)입니다. 그런데 정작 파이썬은 실행 속도가 느린 언어로 유명합니다. 인공지능과 머신러닝은 어마어마한 연산을 요구하는 분야인데, 하필 느린 파이썬이
devwar.tistory.com
Go 언어(Golang)는 왜 태어났을까 - 구글 천재들이 현타 와서 만든 언어
Go 언어(Golang)는 2007년 구글에서 태어난 프로그래밍 언어입니다. C++ 빌드 한 번에 45분이 걸리던 시절, 그 지긋지긋함에 멘탈이 무너진 세 명의 엔지니어가 "기능을 더 얹지 말고 오히려 덜어내자"
devwar.tistory.com
'언어의역사' 카테고리의 다른 글
| 스위프트(Swift) 언어 역사: 애플은 왜 잘 쓰던 Objective-C를 버렸을까? (2026년 최신 총정리) (0) | 2026.07.08 |
|---|---|
| 코볼(COBOL) 아직도 쓴다고? 60년 넘은 언어가 전 세계 금융을 떠받치는 이유 (0) | 2026.07.08 |
| MySQL과 MariaDB는 원래 한 핏줄이었다 - 오라클 인수와 포크의 가족사 (0) | 2026.07.07 |
| MVC 패턴이란 무엇인가 - Model·View·Controller가 개발 현장을 바꾼 이야기카테고리: 언어의역사 (0) | 2026.07.07 |
| 러스트(Rust) 메모리 안전성, 왜 지금 시스템 프로그래밍의 기준이 되어가나 (0) | 2026.07.06 |