C 언어는 수십 년 동안 프로그래밍을 대표해 온 언어다. C++, 자바, C#, 구글 고, 러스트, 파이썬, 그리고 가장 새로운 언어인 카본(Carbon)과 C를 비교해 보자.
CREDIT: tomertu/Shutterstock
C 프로그래밍 언어는 1972년부터 활발하게 사용되고 있으며, 소프트웨어로 가득 찬 세계에서 지금도 여전히 필수적인 구성 요소 중 하나로 군림하고 있다. 하지만 지난 몇십 년 사이 등장한 다른 많은 새로운 언어는 어떨까? 그중에는 C의 지배력에 도전할 목적으로 설계된 언어도 있고, 자체적으로 인기를 끌면서 C의 인기를 조금씩 침식하는 언어도 있다.
성능, 베어메탈 호환성, 보편성에서 C를 능가하기는 어렵다. 어쨌든 경쟁 관계의 몇몇 주요 언어와 비교해 살펴볼 만한 가치는 있다.
C vs. C++
C는 C++와 자주 비교된다. C++는 이름에서 알 수 있듯이 C의 확장판으로 만들어진 언어다. C++와 C의 차이점은 긍정적으로 표현하면 광범위하고 부정적으로 표현하면 복잡하다.
C++의 구문과 접근 방식은 여전히 C와 비슷하지만 C++에는 네임스페이스, 템플릿, 예외, 자동 메모리 관리 등 C에서는 기본적으로 사용할 수 없는 유용한 기능이 많다. 데이터베이스, ML 시스템과 같이 최고 수준의 성능이 필요한 프로젝트는 C++로 작성되는 경우가 많고 이런 다양한 기능을 사용해 시스템의 성능을 최대한 끌어낸다.
또한 C++는 C보다 훨씬 더 공격적으로 계속 확장되는 중이다. C++ 23은 모듈, 코루틴, 더 빠른 컴파일을 위한 모듈화된 표준 라이브러리를 비롯해 더욱 많은 기능을 제공하는 반면 C 표준의 최신 버전인 C23은 새로운 요소는 거의 추가하지 않은 채 하위 호환성을 유지하는 데 중점을 둔다.
단, C++의 모든 장점은 단점, 그것도 큰 단점으로 작용할 수도 있다. 더 많은 C++ 기능을 사용할수록 복잡성이 커지고 결과를 통제하기가 더 어려워진다. C++의 일부분만 한정적으로 사용하면 C++의 최악의 함정을 많이 피해갈 수 있다. 그러나 C++의 복잡성을 원천적으로 차단하고자 하는 경우도 있다. 예를 들어 리눅스 커널 개발팀은 C++를 기피한다. 이들은 커널을 위해 미래에 추가할 언어로 러스트를 주목하고 있지만 리눅스의 대부분은 여전히 C로 작성될 것이다.
개발자와 코드 유지관리자는 강제적 미니멀리즘을 포용하고 C++의 과잉에 휘말리지 않기 위해 C++ 대신 C를 선택할 수 있다. 물론 C++에 풍부한 고수준 기능이 있는 데는 그럴 만한 이유가 있다. 그러나 현재와 미래의 프로젝트와 프로젝트팀에 미니멀리즘이 더 적합하다면 C가 더 합리적이다.
C vs. 자바
자바는 수십 년 동안 많은 개선을 이루면서 지금까지 엔터프라이즈 소프트웨어 개발은 물론 전반적인 개발에서도 대표적인 언어로 사용되고 있다. 자바 구문의 많은 부분은 C와 C++에서 차용됐다. 다만 자바는 C와 달리 기본적으로 네이티브 코드로 컴파일되지 않는다. 대신 자바의 JIT(Just-in-Time) 컴파일러는 대상 환경에서 실행되도록 자바 코드를 컴파일한다. JIT 엔진은 프로그램 동작에 따라 런타임에 루틴을 최적화하므로 사전에 컴파일되는 C에서는 불가능한 많은 종류의 최적화가 가능하다. JIT 컴파일된 자바 코드는 적절한 환경에서 C에 근접한 성능을 내거나 능가하기도 한다.
또한 자바 런타임이 메모리 관리를 자동화하긴 하지만 자동 관리를 우회하는 것도 가능하다. 예를 들어 아파치 스파크는 자바 런타임의 “안전하지 않은” 부분을 사용해 메모리를 직접 할당 및 관리하고 JVM 가비지 수집 시스템의 오버헤드를 피해 메모리 내 처리 작업을 최적화한다.
“한 번 작성해서 어디서나 실행한다”라는 자바의 철학을 바탕으로 자바 프로그램은 대상 아키텍처에 따라 조정할 필요가 거의 없이 바로 실행할 수 있다. C는 많은 아키텍처로 이식됐지만 C 프로그램은 예컨대 윈도우와 리눅스에서 제대로 실행되기 위해서는 여전히 아키텍처별로 맞춤화 작업이 필요할 수 있다.
자바는 이 같은 이식성과 강력한 성능의 조합, 그리고 방대한 소프트웨어 라이브러리 및 프레임워크 생태계에 힘입어 엔터프라이즈 애플리케이션 빌드의 대표적인 언어이자 런타임으로 군림하고 있다. 자바가 C에 비해 떨어지는 영역은 애초에 자바가 경쟁할 의도가 없었던 부분, 즉 기계에 근접해서 실행되거나 하드웨어를 직접 다루는 부분이다.
C 코드는 프로세스에 의해 직접 실행되는 기계 코드로 컴파일된다. 자바는 중간 코드인 바이트코드로 컴파일되고 JVM 인터프리터가 이를 기계 코드로 변환하는 방식이다. 또한 자바의 자동 메모리 관리는 대부분의 상황에서 유용하지만 한정된 메모리 리소스를 최적으로 사용해야 하는 프로그램에는 초기 점유 면적 자체가 작은 C가 더 적합하다.
C vs. C# 및 닷넷
C#과 닷넷(.NET)은 처음 등장하고 거의 20년이 지난 지금까지 엔터프라이즈 소프트웨어 환경의 중요한 언어로 남아 있다. C#과 닷넷은 마이크로소프트가 관리형 코드 컴파일러 시스템이자 범용 런타임인 자바에 대항하기 위해 만든 것으로 알려졌으며, C와 자바의 많은 비교가 C와 C#/닷넷에도 적용된다.
닷넷은 자바(그리고 일정 부분 파이썬)와 마찬가지로 다양한 플랫폼에 걸친 이식성과 광범위한 통합 소프트웨어 생태계를 제공한다. 닷넷에서 이뤄지는 개발의 상당 부분이 기업 용도임을 감안하면 이는 결코 작지 않은 이점이다. C# 또는 다른 닷넷 언어로 프로그램을 개발하는 경우 닷넷 런타임용으로 만들어진 방대한 툴과 라이브러리를 활용할 수 있다.
자바와 비슷한 닷넷의 또 다른 이점은 JIT 최적화다. C#과 닷넷 프로그램은 C와 마찬가지로 사전 컴파일이 가능하지만 대부분의 경우 닷넷 런타임에 의해 적시(JIT) 컴파일되고 런타임 정보를 사용해 최적화된다. JIT 컴파일은 실행 중인 닷넷 프로그램에 대한 온갖 종류의 실시간 최적화를 가능하게 해준다. C에서는 불가능한 부분이다.
C#과 닷넷은 C(그리고 어느 정도 자바)와 마찬가지로 메모리에 직접 액세스하기 위한 다양한 메커니즘을 제공한다. 힙과 스택, 관리되지 않는 시스템 메모리는 모두 닷넷 API와 객체를 통해 액세스할 수 있다. 또한 개발자는 닷넷의 비안전 모드를 사용해 한층 더 높은 성능을 얻을 수도 있다.
다만 이 모든 장점이 아무런 대가 없이 제공되는 것은 아니다. 관리되는 객체와 안전하지 않은 객체는 임의로 상호 교환할 수 없고, 이들 간의 마샬링에는 성능상의 비용이 따른다. 따라서 닷넷 애플리케이션의 성능을 극대화한다는 것은 곧 관리되는 객체와 관리되지 않는 객체 간의 이동을 최소한으로 유지하는 것을 의미한다.
관리되지 않는 메모리 대비 관리되는 메모리에 따르는 불이익을 감당할 수 없거나 대상 환경(예를 들어 커널 공간)에 비추어 닷넷 런타임이 부적절한 선택이거나 아예 사용할 수 없는 경우 C가 필요하다. 또한 C# 및 닷넷과 달리 C에서는 직접 메모리 액세스가 기본적으로 열려 있다.
C vs. 구글 고
고(Go)는 코드 가독성, 즉 어느 고 프로젝트든 개발자가 짧은 시간 내에 파악하고 코드베이스를 능숙하게 다룰 수 있도록 하는 것을 주 설계 목표 중 하나로 개발된 언어다. C 코드베이스는 특정 프로젝트와 팀에 특화된 매크로와#ifdef가 난무해 이해하기 어려울 수 있다. 고의 구문, 그리고 내장된 코드 서식과 프로젝트 관리 툴은 이러한 종류의 조직적 문제를 방지하는 데 중점을 둔다.
고 구문은 많은 부분을 C에서 차용했다. 예를 들어 중괄호를 구분 기호로 사용하고 세미콜론으로 문을 끝낸다. 고에 특화된 기능을 고려하더라도 C에 능숙한 개발자라면 일반적으로 큰 어려움 없이 고로 넘어갈 수 있다.
고의 특징적인 기능에는 고루틴과 채널이 포함된다. 고루틴과 채널은 구성요소 간의 동시성과 메시지 전달을 처리하기 위한 언어 수준 툴이다. C에서는 이런 기능을 수제작하거나 외부 라이브러리에서 가져와야 하지만 고는 기본적으로 제공하므로 이와 같은 기능이 필요한 소프트웨어를 훨씬 더 쉽게 구축할 수 있다.
내부적으로 고와 C의 가장 큰 차이점은 메모리 관리다. 고 객체에서는 기본적으로 관리와 가비지 수집이 자동으로 이뤄진다. 대부분의 프로그래밍 작업에서 매우 편리하지만, 대신 결정적인 메모리 취급이 필요한 프로그램을 작성하기는 어렵다.
고에는 일부 타입 처리 안전 장치(예를 들어Pointer타입으로 임의의 메모리 읽고 쓰기)를 우회하기 위한unsafe패키지가 포함돼 있다. 다만 “unsafe패키지를 사용해 작성된 프로그램은 이식이 불가능할 수 있으며 고 1 호환성 가이드라인으로 보호되지 않는다”는 경고문을 주의해서 읽을 필요가 있다.
고는 이런 세밀한 조작이 거의 불필요한 명령줄 유틸리티, 네트워크 서비스와 같은 프로그램을 빌드하는 데 적합하다. 고 개발진은 AI/ML을 비롯해 더 까다로운 워크로드에 대한 고의 적합성을 개선할 방법도 고민 중이다. 그러나 저수준 디바이스 드라이버, 커널 공간 운영체제 구성요소, 그리고 메모리 레이아웃 및 관리와 같이 엄밀한 제어가 필요한 작업은 C로 만드는 것이 최선이다.
C vs. 러스트
어떤 면에서 러스트는 C와 C++의 난해한 메모리 관리와 그 외에도 다른 많은 단점의 대응책으로 등장한 언어다. 러스트는 네이티브 기계 코드로 컴파일되므로 성능 면에서 C와 동등한 것으로 평가된다. 그러나 기본적으로 러스트가 내세우는 가장 큰 장점은 메모리 안전성이다.
러스트의 구문과 컴파일 규칙은 개발자가 일반적인 메모리 관리 실수를 피하는 데 도움이 된다. 컴파일 타임에 잡아낼 수 있는 메모리 관리 문제가 존재할 경우 아예 프로그램 컴파일이 되지 않는다. 러스트 초보자, 특히 이러한 버그가 발생할 여지가 큰 C와 같은 언어에서 건너온 초보자는 처음 한동안은 컴파일러의 요구사항을 충족하는 방법을 익히는 데 시간을 소비하게 된다. 그러나 러스트 지지자들은 이 같은 단기적인 고충이 장기적으로는 실행 속도를 희생하지 않는 더 안전한 코드라는 보상으로 이어진다고 주장한다.
러스트의 툴도 C에 비해 개선됐다. 고와 마찬가지로 프로젝트와 구성요소 관리가 툴체인의 일부로 러스트와 함께 기본 제공된다. 패키지, 관리, 프로젝트 폴더 구성을 비롯해 C에서는 프로젝트와 팀마다 각기 다르게 임시방편으로 처리하는 많은 다른 부분을 처리하기 위한 권장 기본 방식이 있다(예를 들어 C에는 표준 패키지 관리자조차 없음).
그러나 러스트가 장점으로 내세우는 것이 C 개발자 입장에서는 그렇게 보이지 않을 수 있다. 러스트의 컴파일 타임 안전 기능은 비활성화할 수 없으므로 아주 사소한 러스트 프로그램이라 해도 러스트의 메모리 안전 구조에 따라야 한다. C는 기본적으로 덜 안전할 수는 있지만 필요할 때 훨씬 더 유연하고 운신의 폭이 넓다.
단점으로 볼 수 있는 또 다른 부분은 러스트 언어의 크기다. C는 표준 라이브러리를 감안하더라도 기능의 수가 비교적 적은 편이다. 반면 러스트 기능 집합은 방대하며 계속 증가하는 중이다. C++도 그렇듯이 기능 집합이 커질수록 더 강력한 대신 복잡성도 더 커진다. C는 상대적으로 크기가 작은 언어지만 개발자가 머릿속으로 이것저것을 구상하기가 훨씬 더 쉽다. 따라서 러스트가 필요에 비해 과잉인 프로젝트에는 C가 더 적합할 수 있다.
C vs. 파이썬
요즘 소프트웨어 개발에 대한 대화에서는 파이썬이 거의 항상 등장한다. 파이썬은 “모든 면에서 두 번째로 좋은 언어”이며, 분명 가장 다재다능한 언어 중 하나이고, 사용 가능한 써드 파티 라이브러리도 수천 개에 이른다. 폭발적으로 인기를 끌면서 세계에서 가장 널리 사용되는 프로그래밍 언어로 부상했다.
파이썬이 강조하는 부분이자 C와의 가장 큰 차이점은 실행 속도보다 개발 속도를 중시한다는 것이다. C와 같은 다른 언어로 작성하는 경우 한 시간 정도가 걸릴 프로그램을 파이썬을 사용하면 몇 분 만에 완성할 수 있다. 반면 C로 만들었다면 몇 초 만에 실행될 프로그램이 파이썬에서는 1분이 걸릴 수 있다. 경험적으로 파이썬 프로그램은 C 프로그램에 비해 대체로 실행 속도가 훨씬 더 느리다. 다만 최신 하드웨어에서 실행할 경우 많은 작업이 파이썬으로도 충분히 빠르며, 바로 이 점이 파이썬이 인기를 끈 중요한 이유다.
또 다른 큰 차이점은 메모리 관리에 있다. 파이썬 프로그램의 경우 파이썬 런타임이 전적으로 메모리를 관리하므로 개발자가 메모리 할당과 해제에 대해 세세히 신경 쓸 필요가 없다. 그러나 여기서도 개발자의 편의성에는 런타임 성능의 대가가 따른다. C 프로그램을 작성하려면 메모리 관리에 세심하게 주의를 기울여야 하지만 그 결과로 얻는 프로그램은 순수한 기계 속도 그대로 실행되는 경우가 많다.
하지만 내부적으로 파이썬과 C에는 깊은 연결 고리가 있다. 레퍼런스 파이썬 런타임은 C로 작성된다. 덕분에 파이썬 프로그램은 C와 C++로 작성된 라이브러리를 래핑할 수 있다. 파이썬 써드 파티 라이브러리 생태계의 상당 부분은(예를 들어 ML용 라이브러리) 그 중심에 C 코드가 있다. 많은 경우 관건은 C냐 파이썬이냐가 아니라, 애플리케이션의 어떤 부분을 C로 작성하고 어떤 부분을 파이썬으로 작성하느냐다.
개발 속도가 실행 속도보다 중요하고 프로그램에서 고성능 요소의 대부분을 독립적인 구성요소로 분리할 수 있다면(코드 전반에 분산시키지 않고) 순수 파이썬, 또는 파이썬과 C 라이브러리를 혼합하는 것이 C만 사용하는 것보다 더 낫다. 그 외의 경우에는 여전히 C가 우위다.
C vs. 카본
C와 C++의 또 다른 경쟁자로 최근에 등장한 카본(Carbon)이 있다. 카본은 현재 개발이 활발히 진행 중인 비교적 신생 언어다.
카본의 목표는 C와 C++의 현대적 대안이 되는 것이다. 이를 위해 간소한 구문, 현대적인 툴과 코드 구성 방법, C 및 C++ 프로그래머들이 오랫동안 직면해 온 문제에 대한 해결책을 제시한다. 또한 C++ 코드베이스와의 상호운용성을 제공하므로 기존 코드를 점진적으로 마이그레이션할 수 있다. C와 C++의 툴과 프로세스는 최근에 개발된 다른 여러 언어에 비해 원시적인 만큼 카본의 이 같은 노력은 환영할 만한 일이다.
그렇다면 단점은 무엇일까? 지금의 카본은 실험적인 프로젝트이며 프로덕션 용도로 사용하려면 아직 갈 길이 멀다. 작동하는 컴파일러조차 없으며 온라인 코드 탐색기만 있을 뿐이다. 카본이 C 또는 C++의 현실적인 대안이 되기까지는 아직 시간이 필요하고, 실제로 대안이 된다는 보장도 없다.
이름에서 알 수 있듯이 CES(The Consumer Electronics Show)는 새로운 소비자 가전제품을 선보이는 자리다. 아쉽게도 대부분은 PC 관련 제품이지만, PC 외의 다른 흥미로운 제품도 많이 찾아볼 수 있다. 넓은 전시장을 돌아다니며 눈에 띈 제품을 소개한다.
1. LG 울트라파인 32U990A 6K 모니터
CREDIT : LG
생산 지향적인 사용자는 이 새로운 LG의 새로운 32인치 울트라파인(Ultrafine) 모니터에 주목해야 한다. 이 제품은 6K 해상도를 제공할 뿐 아니라 썬더볼트 5를 지원해 M4 프로 이상의 칩을 탑재한 맥에서 썬더볼트 5의 120Gbps 대역폭을 활용할 수 있다. 놀랍게도 OLED가 아닌 나노 IPS 블랙 패널을 사용하며, 어도비 RGB의 99.5%와 DCI-P3의 98%를 커버하는 넓은 색 영역을 제공한다. LG가 애플과 디스플레이 협력을 긴밀하게 이어가고 있다는 점에서 이 제품은 올해 출시될 것으로 알려진 애플의 프로 디스플레이 XDR(Pro Display XDR)의 미리보기 역할을 할 가능성도 있다.
2. 라씨 러기드 SSD 프로5
CREDIT : LACIE
LG 디스플레이와 함께 사용할 썬더볼트 5 외장 SSD도 있다. 러기드 SSD 프로5(Rugged SSD Pro5)는 라씨 인기 모델 러기드 미니 SSD(Rugged Mini SSD)와 유사한 디자인에 보라색 실리콘 외장재를 사용한다. IP8 방수 등급도 갖추고 있다. 러기드 SSD 프로5는 50GB 캐시를 사용하면서 최대 읽기 속도 6700MB/s, 쓰기 속도 5300MB/s를 지원한다. 2TB 및 4TB 용량으로 제공되며, 썬더볼트 5를 지원하는 새로운 맥북 프로(MacBook Pro)의 저장 용량을 확장하기에 이상적이다. 맥에 적합한 최고의 SSD를 확인해 보자.
3. 모프트 트래커블 월렛 스탠드
CREDIT : MOFT
모프트의 맥세이프 지갑은 아이폰과 분리되어 분실될 경우 나의 찾기 기능으로 위치를 추적할 수 있다. 이 지갑 두께는 1.1mm이며, 나의 찾기 기능을 위한 80mAh 배터리를 탑재했다. 휴대폰을 세워둘 수 있는 접이식 스탠드도 내장됐다. 모프트 트래커블 월렛 스탠드는 마치 오리가미 드리퍼처럼 생긴 에어태그로 활용할 수 있다.
4. 에코플로우 파워 햇
CREDIT : ECOFLOW
전자 기기의 배터리 수명 때문에 활동적인 라이프스타일이 방해를 받고 있는가? 그렇다면 파워 햇(Power Hat)이 필요하다. 이 제품은 태양 에너지를 활용해 2개의 기기를 동시에 충전할 수 있다. 챙 전체에 태양광 패널이 장착돼 있어 머리의 각도를 따로 신경 쓰지 않아도 된다. USB-A 및 USB-C 포트를 모두 제공하며, 에코플로우에 따르면 이 모자는 4,000mAh 배터리를 3~4시간 이내에 충전할 수 있다. 더위를 식혀주는 기능도 제공한다.
5. 시프트캠 플랑크
CREDIT : SHIFTCAM
플랑크(Planck)는 1TB 또는 2TB 용량으로 제공되는 USB-C SSD다. 크기가 작아 스마트폰과 함께 사용하기에 이상적이다. 특히 아이폰의 프로레스 포맷으로 동영상을 촬영할 때 유용하다. 프로레스 동영상은 파일 크기가 크기 때문에 저장 공간을 빠르게 소모할 수 있다. 플랭크는 최대 1050MBps의 전송 속도를 제공한다
6. ESR 헤일로락 매그마우스 무선 마우스
CREDIT : ESR
ESR에서 제작한 매그마우스(MagMouse)는 마우스를 자주 잃어버리는 사용자에게 적합하다. 이 마우스는 맥북 또는 맥 프로와 같은 어떤 표면에든 부착할 수 있는 기본 받침대를 제공하는데, 사용하지 않을 때는 이 받침대에 마우스를 자석으로 부착할 수 있다. 매그마우스는 접이식 USB-C 케이블로 충전하며, 2.4GHz 무선 또는 블루투스 연결을 지원한다. 아쉽게도 도킹 상태에서는 충전되지 않지만, 맥세이프 대안으로 유용한 옵션이다.
7. 벨킨 스테이지 파워그립
CREDIT : BELKIN
CES에서 보조배터리는 흔한 제품이지만, 벨킨의 신제품은 눈에 띄는 요소를 가지고 있다. 첫 번째는 파우더 블루, 샌드박스, 프레시 옐로, 페퍼, 라벤더라는 다섯 가지 화려한 색상이다. 두 번째는 카메라 그립에서 영감을 받은 독특한 디자인이다. 이 디자인은 고용량 보조배터리의 기능성과 인체공학적인 휴대폰 그립의 실용성을 결합했다. 제품은 10,000mAh 배터리, 7.5W 마그네틱 무선 충전, 접이식 USB-C 충전 케이블, 그리고 배터리 잔량을 표시하는 작은 LED 화면을 제공한다. 휴대폰 뒷면에 부착하면 똑딱이 카메라와 비슷한 모습이다. 심지어 빠른 사진 촬영을 위한 내장 셔터까지 탑재됐다.
CDN은 콘텐츠 전송 네트워크인 Content Delivery Network의 약자로 아래 2가지로 정의될 수 있습니다.
1) 웹 콘텐츠 전송 가속화 인프라
: CDN은 지리적으로 분산된 서버 네트워크를 통해 사용자에게 웹 콘텐츠(이미지, 동영상, 웹페이지 등)를 더 빠르고 안정적으로 전달하는 시스템입니다.
2) 네트워크 트래픽 부하 분산 및 성능 최적화
: CDN은 원본 서버의 부하를 줄이고, 사용자와 가장 가까운 서버에서 콘텐츠를 제공하여 대기 시간을 최소화하고 사용자 경험을 향상시킵니다.
2. CDN의 원리
CDN(Content Network Network)은 본체 서버로부터 지리적으로 멀리 떨어져 있는 사용자에게 콘텐츠(동영상, 이미지, 글 등)를 더 빠르게 제공하기 위해 고안된 기술입니다. 대한민국에 있는 사용자가 미국에 위치한 서버로부터 콘텐츠를 다운받으려고 하면 시간이 상당히 오래 걸릴겁니다.
따라서, 서버를 분산시켜 콘텐츠를 분산된 서버에 캐싱해두고 사용자의 콘텐츠 요청이 인입되면 사용자와 가장 가까운 서버가 응답하여 요청된 콘텐츠의 캐싱된 내용을 내어주는 방식으로 빠르게 응답할 수 있습니다.
CDN 미적용 (좌) CDN 적용(우)
3. CDN 아키텍처 종류
CDN 아키텍처는 크게 2 종류가 있습니다. Pull, Push 방식 입니다.
1) Pull 모델
: Pull 모델은 pull 영단어 그대로 "당긴다" 라는 뜻으로 분산된 CDN서버가 본 서버로부터 콘텐츠를 당겨오는 방식 입니다.
2) Push 모델
: Push 모델 push 영단어 그대로 "민다" 라는 뜻으로 본 서버에서 분산된 서버에 콘텐츠를 밀어넣는 방식 입니다.
이번 페이지에서는 javascript 매개변수 명령어인 let과 var의 차이점에 대해서 알아보겠습니다.
우선 개발시점으로 보자면
var가 먼저 나오고
let이 나중에 나왔습니다. (2015년 쯤, javascript가 ES6로 업그레이드 될 때, 나왔을 겁니다.)
당시, var 보다는 let사용을 권장했었죠.
1. 중복선언 가능
-. var : 중복선언 가능
-. let : 중복선언 불가능
위의 내용을 아래의 코딩 예시로 들어보겠습니다.
// var 중복선언 가능 예시
var a = 1
console.log(a) // 결과값 : 1
var a = 10
console.log(a) // 결과값 : 10
var a = 20
console.log(a) // 결과값 : 20
var로 선언한 변수가 또 중복 선언되는 경우 최신 값이 저장되는 것을 볼 수 있습니다.
하지만 let의 경우는 다릅니다.
아래를 보시면 변수가 중복된 경우 맨 아래의 console.log(a) 가 에러가 발생합니다.
// let 중복선언 불가능 예시
let a = 1
console.log(a) // 결과값 : 1
let a = 10
console.log(a) // 결과값 : SyntaxError : 'a' has already been declared
2. 스코프 범위
-. var : 함수 단위 스코프
-. let : 블록 단위 스코프
var로 선언한 변수는 함수 내부에서 유효합니다. 하지만 블록(if, for 등) 내부에서는 무시됩니다.
아래의 예시를 보겠습니다.
function test() {
if (true) {
var a = 10;
console.log(a); // 결과값 : 10
}
console.log(a); // 결과값 : 10 <-- 이 부분이 var와 let의 차이 입니다.
}
test() // 결과값 : 10
console.log(a) // 결과값 : 에러발생
let으로 선언한 변수는 함수 외부에서 유효하지 않습니다.
아래의 예시를 보겠습니다.
function.test() {
if (true) {
var a = 10;
console.log(a) // 결과값 : 10
}
console.log(a); // 결과값 : 에러발생 <-- 이 부분이 var와 let의 차이 입니다.
}
console.log(a); // 결과값 : 에러발생
3. 호이스팅 (Hoisting)
추가로 호이스팅의 개념에 대해서 알면 좋습니다.
호이스팅이란 함수 내부에 있는 선언들을 모두 끌어올려 해당 함수 유효 범위의 최상단에 선언하는 하는 것을 뜻합니다.
-. var : 호이스팅 발생함
-. let : 호이스팅 발생하지만, 다른 방식으로 작동됨
// var 변수 호이스팅
console.log(a); // undefined
var a = 5;
console.log(a); // 5
/*
foo(); // foo
function foo() {
console.log("foo");
}
// let 변수 호이스팅
console.log(a); // ReferenceError: a is not defined
let a = 5;
console.log(a); // 5
/* 함수 호이스팅 */
foo(); // error
var foo = function() {
console.log("foo");
}
해당 사이트를 들어가면 친절하게도 홈페이지에서 아래와 같이 대규모 투자기관들의 포트폴리오를
간단한 클릭만으로도 쉽게 볼 수 있게 해놨습니다.
위 스크린 샷은 2025-01-02 기준인데, 최상단 행에 버크셔가 있네요. 아무래도 수익률 기준으로 정렬된 것 같습니다.
이러한 데이터는 13F라는 분기별 보고서를 통해서 데이터가 수집되는 건데요,
그럼 13F란 무엇일까요?
13F란, 주식 자산이 1억달러 이상인 기관 투자 관리자가 미국 증권거래위원회에 의무적으로 제출하는 분기별 보고서를 말합니다. 정식 명칭은 "Form 13F"인데요, 보통 줄여서 13F라고 말합니다. 1975년도에 도입된 이 제도의 주요 목적은 투자 기관 및 대규모 투자자의 자산 운용 정보를 공개하고, 투자 시장의 투명성을 높이기 위해 시작됐습니다.
허나 여기서 중요한 점이 있습니다.
13F를 제출해야 하는 투자기관들은 1년에 4번 즉, 분기별로 보고서를 제출하지만,
분기 말 이후 45일 이내에 공시하면 됩니다.
따라서 특정 시점의 13F 보고서를 보는 시점은 이미 45일이 지난 후 라고 생각하셔야 합니다.
"특정 애플리케이션을 실행하기 위해 필요한 라이브러리와 실행환경을 이미지로 패키징하고, 가상화 기술을 이용하여 독립적으로 실행하는 기술을 말합니다." 라고 하면 이해가 어렵습니다.
간단히 말해서 컨테이너란, 컴퓨터 프로그램들을 담을 수 있는 특별한 상자? 라고 생각하시면 됩니다.
그럼 쿠버네티스라는 것은 프로그램들이 담겨져 있는 컨테이너들을 관리하는 놈이라고 생각하시면 쉽습니다.
그럼 컨테이너는 왜 생겼을까요?
쿠버네티스, 컨테이너, 도커 등을 검색하다보면 혹시 아래와 같은 그림을 본 적이 있으실 겁니다.
아래 그림을 설명해보면서 컨테이너가 왜 필요한지 이야기 해 보겠습니다.
3. 컨테이너의 필요성
위의 그림은 컴퓨팅의 발전이라고 보시면 됩니다.
1) Traditional Deployment (전통적 배포방식)
집에 있는 노트북이나 PC를 예시로 들어보겠습니다. 내 PC는 하나의 운영체제 (주로 Windows겠죠?) 를 갖고 있고 이 운영체제 (Operating System, 줄여서 OS) 위에 여러 프로그램을 설치해서 원하는 목적을 수행했습니다.
게임을 하기 위해서 게임 프로그램을 설치하고, 인터넷뱅킹을 위해 각종 프로그램을 설치하고,
코딩을 배우기 위해 코딩 프로그램을 설치하고,,, 등등 그 후 각 프로그램의 업데이트가 공지되면 업데이트를 다운받아 설치하고,,,
이렇게 한 OS위에 여러 프로그램들을 설치해서 오랜기간 PC를 사용하다보면 컴퓨터의 용량이 점점 차오르고 컴퓨터 속도가 느려지는 것을 경험한 적이 있을 겁니다. 이게 Traditional Deployment 라고 보시면 됩니다.
2) Virtualized Deployment (가상화 배포)
위의 문제를 해결하기 위해 Virtualized Deployment 방식이 나왔습니다.
한 OS위에 Hypervisor를 설치하여 여러 가상머신(VM)을 설치할 수 있게 되었습니다.
가상머신의 장점은 여러 OS를 설치하여 여러 프로그램들을 운영할 수 있는 것 입니다.
그러나 가상머신의 단점은 특정 프로그램이 특정 OS가 필요하면 매번 특정 OS를 설치하거나
기존 VM에 구성된 OS를 업데이트 관리해야하는 불편함이 있었습니다.
3) Container Deployment
위의 불편함을 해소하기 위해 나온 것이 Container Deployment 방식 입니다.
위의 Hypervisor가 Container Runtime으로 대체되고
Virtual Machine이 Container로 대체되었습니다. 이로 인해 프로그램 구동을 위해 별도의 OS설치가 필요 없어졌습니다.
기존 Traditional Deployment 와 동일하게 하나의 OS만 있어도 여러 프로그램 구동이 가능해졌습니다.
4. 쿠버네티스의 필요성
세상에 수많은 Container가 생기면서 관리의 어려움이 자연스레 발생하였고, 이 관리를 위해 나온 개념이 바로 쿠버네티스라고 생각해주시면 될 것 같습니다. 사실 도커의 개념이 필연적으로 설명되어야 하지만, 간단히 핵심만 요약하기 위해 이와 같이 이해해주시면 될 것 같습니다.
즉, 쿠버네티스는 수많은 컨테이너들을 관리하는데 자동으로 편리하게 관리할 수 있는 솔루션으로 요약 설명 가능할 것 같습니다.
5. 쿠버네티스의 기능
파드(Pod) : 가장 작은 배포 단위로, 하나 이상의 컨테이너를 포함할 수 있습니다.
서비스(Service) : 파드 집합에 대한 지속적인 접근 방법을 제공 합니다.
볼륨(Volume) : 데이터를 저장하고 파드 간에 공유할 수 있는 방법을 제공합니다.
네임스페이스(Namespace) : 클러스터 리소스를 분할하여 사용하는 방법을 제공합니다.
