코드를 볼 때마다 가장 거슬리고 불쾌한 부분이 있습니다. 바로 하드코딩입니다. 하드코딩된 문자열, 실수, 정수 등의 리터럴은 그 의미를 파악하기 위해 위아래 수십 줄을 읽어 문맥을 파악해야 하는 번거로움이 잦습니다. 심지어 잘 짜인 변수 네이밍으로도 그 의미 파악이 쉽지 않은 경우가 많습니다. 의미뿐만 아니라 try로 도배된 프로덕션 코드에서 흔히 볼 수 있는 로그용 텍스트 리터럴은 보면 볼수록 난잡하고 끔찍합니다. 그렇다고 해서 하드코딩 없이 코드를 짜는 건 불가능에 가깝습니다. 이 글에서는 조금이나마 하드코딩의 불쾌함을 덜어낼 여러 방법들을 소개하고 장단점을 알아보겠습니다!...
어떤 커널 구조가 좋을까? : exokernel 커널 아키텍처는 Linux 같은 전통적인 모놀리식 커널부터, Mach와 같은 마이크로 커널까지 다양하다. 개발에 조금의 재미를 가미하기 위해 나는 그중에서도 엑소 커널이라는 아직까지 연구되고 있으며, 조금은 특이한 커널 아키텍처를 채택해서 개발을 진행해볼 예정이다. 엑소 커널의 핵심은 보안과 추상화의 분리다. 기존의 커널은 가상 메모리, 파일 시스템, 네트워크 프로토콜과과 같이 높은 추상화 수준에서 보안을 제공했다면, 엑소 커널은 저비용 추상화 계층을 통해 물리적 리소스를 보호하고 다중화하며, 높은 추상화를 제공하는 libOS(library operating systems)을 통해 기존 애플리케이션과의 호환성을 유지함과 동시에 애플리케이션 개발에 더 높은 유연성을 제공한다....
아키텍쳐 잡설 AWS의 서버리스 컴퓨팅 서비스인 람다에서 아마존 자체 개발 프로세서인 Graviton2를 사용 가능해졌다는 뉴스를 본 적이 있다. Graviton2 프로세서는 RISC의 대표 격인 ARM ISA를 채택하고 있는데, 애플의 ARM 이주와 맞물려서 요즘 트렌드가 확실히 ARM이란 생각이 들었다. 사실 슈퍼컴퓨터 등지에서도 ARM은 인기 있는 아키텍처이다. RISC는 32비트 전환 시기에 성능 향상으로 크게 주목받았지만 요즘은 클럭이 워낙 빨라져서 성능상의 이점은 찾기가 힘들고, 대부분 전력 효율 때문에 사용한다. 그래서 모바일 기기의 프로세서 대부분이 RISC이다....
시작하기 전 I/O 멀티플렉싱은 일반적으로 한 스레드에서 여러 논-블록킹 소켓(I/O streams)을 검사하여, 사용 가능한 소켓의 데이터를 처리하는 것을 의미합니다.(unix에서는 select나 poll, linux에서는 epoll을 생각하시면 됩니다.) 여기서 문제가 발생합니다. 한 스레드에서 처리할 수 있는 소켓은 한정되어 있다는 것이죠. 예를 들어보자면 10000개의 연결을 한 스레드에서 전부 처리하게 되면 부하가 집중되게 됩니다. 또 멀티코어 환경이라면 나머지 코어를 전혀 활용하지 못하는 매우 비효율적인 시스템이 될 수 있겠네요. 그럼 연결마다 스레드를 만들면 되지 않을까요? 스레드는 치명적인 단점이 무려 두 가지나 있습니다....