글

5월, 2025의 게시물 표시

Aspect-Oriented Programming의 이해와 적용

-
객체 지향 프로그래밍(Object-Oriented Programming, a.k.a. OOP)은 코드를 객체라는 독립적인 모듈로 묶어 관리한다. 각 객체는 관심사의 분리 원칙에 따라 만들어져야 하는데, 이는 각 객체가 자신의 특정 책임에 집중해야 한다는 의미다. 그러나 실제 서비스를 개발하다보면 여러 객체나 모듈에 걸쳐 공통적으로 나타나는 기능들을 종종 만나게 된다. 이렇게 여러 모듈에 걸쳐 있는 기능들을 횡단 관심사 (Cross-cutting Concerns)라고 부른다. 횡단 관심사가 가지는 문제점 Scattering 이러한 횡단 관심사들은 OOP만으로 다룰 경우 두 가지 주요 문제를 만든다. 첫 번째 문제는 Scattering 이라고 부른다. Scattering은 특정 기능의 코드가 복사 붙여넣기를 통해 여러 곳에 흩뿌려지는 현상을 말한다. 예를 들어, 모든 함수에 사용자 권한 확인 로직과 로깅 코드를 추가한다고 해보자. 동일한 로깅 및 권한 확인 코드가 각 메서드 내에 반복적으로 나타날 것이다. Tangling 다른 문제는 Tangling 이다. 직역하면 얽힘이라고 할 수 있는데, 이는 비즈니스 로직과 횡단 관심사의 코드가 하나의 모듈이나 함수 안에서 뒤섞여 복잡해지는 현상을 말한다. get_book_info 함수의 주된 목적은 원하는 책의 정보를 찾는 것이다. 하지만 로깅, 권한 확인, 성능 측정 등 다양한 관심사가 그 안에 뒤얽혀 있다. 이 때문에 이 함수의 가독성은 떨어지고 핵심 비즈니스 로직을 파악하기 어려워진다. 이는 마치 지저분한 책상과 같다. 익숙해지면 무엇이 어딨는지 한 번에 알 수 있지만, 익숙하지 않은 사람은 무엇이 어디있는지 찾기 힘들어진다. Aspect-Oriented Programming의 등장 관점 지향 프로그래밍(Aspect-Oriented Programming, a.k.a. AOP)은 이런 문제를 비즈니스 로직 과 횡단 관심사 를 분리하여 해결하려 한다. AOP는 90년대 후반 Xerox PARC...
댓글 쓰기
Read more »

USB를 이용한 전원 공급 (2) - USB PD

-
이미지
USB 포트는 원래 데이터 전송을 위한 인터페이스였지만, 시간이 지나면서 전력 공급 수단으로도 활용되기 시작했다. 이를 지원하기 위해 USB BC 가 도입되었고, 기존보다 높은 전류를 제공할 수 있도록 개선되었다. 하지만 USB BC 1.2는 5 V 전압 고정이라는 한계를 갖고 있어, 노트북 같은 고출력 기기를 충전하기에는 부족했다. 이런 제약 조건을 해결하기 위해 제조사마다 별도의 급속 충전 방식을 만들기 시작했고, 이로 인해 특정 브랜드의 디바이스는 해당 브랜드의 충전기에서만 고속 충전이 가능한 호환성 문제도 발생하였다. 이러한 문제를 해결하기 위해 USB-IF는 USB Power Delivery(a.k.a. USB PD)라는 전력 공급을 위한 새로운 표준을 만들었다. USB PD는 전압과 전류를 동적으로 협상하는 방식을 채택하여, 5 V 뿐만 아니라 9 V , 15 V , 20 V 등 다양한 전압을 지원하고 최대 240 W 까지 전력을 공급할 수 있도록 설계되었다. 이를 통해 스마트폰부터 노트북, 모니터, 이론상으로는 일부 데스크톱 기기까지 USB-C 하나로 전원 공급이 가능해졌으며, 장치 간의 호환성과 범용성이 크게 향상되었다. USB PD와 CC 라인 USB PD가 USB BC보다 더 많은 전력을 공급할 수 있었던 것은 Type-C 컨넥터, 특히 CC 핀의 존재 덕분이다. USB Type-C 커넥터는 좌우 대칭 구조를 채택하여 어느 방향으로 꽂아도 동작할 수 있도록 설계되었으며, 이 방향 감지를 담당하는 것이 바로 Configuration Channel(a.k.a. CC) 핀이다. 기본적으로 CC 핀은 케이블의 방향을 감지하고, 연결된 장치가 전력 공급자인지 소비자인지 식별하는 데 사용된다. USB PD에서는 이 CC 핀을 이용해 전력 협상을 위한 디지털 통신을 수행한다. 소스 디바이스(전력을 공급하는 기기)는 자신이 제공할 수 있는 전력 프로파일을 CC 핀을 통해 싱크 디바이스(전력을 소비하는 기기)에게 알리고, 싱크 디바이스는 그 중...
댓글 쓰기
Read more »

이 블로그의 인기 게시물

USB 2.0 케이블의 내부 구조

-
아이폰도 USB-C를 사용하면서 온 세상이 USB 로 통일됐지만 실제로는 너무 다양한 USB가 존재한다. 기본 형태인 USB-A나 최근 많이 사용되는 USB-C 뿐 아니라, 보통 5핀이라고 불리는 micro-B를 포함한 다양한 USB-B 컨넥터들이 존재한다. 그래도 컨넥터는 모양이 다르기 때문에 쉽게 구분할 수 있는데 케이블은 답이 없다. 겉으로는 똑같아 보이는 케이블이라도 어떤 케이블은 데이터 통신이 안 되고 어떤 케이블은 데이터 통신이 가능하다. 이런 차이는 케이블 내부 구성에 따라 발생한다. 이번 글에서는 USB 2.0 케이블의 내부를 통해 USB 케이블에 대해 자세히 알아보겠다. Micro-B 케이블의 편조 차폐와 호일 차폐 위 사진은 집에서 돌아다니던 A - Micro-B USB 2.0 케이블의 피복을 벗겨낸 것이다. 절연체 아래로 금속 선이 있는 것을 알 수 있다. 이 선들은 금속 선이지만 전선은 아니다. 이 선은 전자기 차폐를 목적으로 들어간 금속 선이다. 실제 전선은 이 금속 선을 벗겨야 나온다. 이번에 자른 케이블에는 두 종류의 차폐가 사용됐다. 하나는 얇은 금속 호일이고, 다른 하나는 얇은 도체의 가닥으로 이루어져 있다. 전자는 보통 호일 차폐(Foil Shielding)라고 부르고 후자는 편조 차폐(Braided Shielding)라고 부른다. 이 둘은 다 외부 전자기장으로부터 전선을 보호하기 위해 사용되지만, 특성이 약간 다르다. 보통 편조 차폐가 저주파수 전자기파를 차단하는 것에 효과적이고, 호일 차폐가 고주파수 전자기파를 차단하는 데 효과적이다. USB 3.0의 고속 전송 케이블은 이 두 차폐를 사용하는 것이 필수적이고, 그 외의 경우에는 필수는 아니고 권장 사항이다. 하지만 어지간한 싸구려 케이블을 쓰지 않는 한 요즘은 USB 2.0 케이블에도 이 두 가지를 같이 사용한다. 차폐 선이 쉴드와 연결되지 않았다 하지만 고속 전송을 지원하는 케이블이 ...
Read more »

[C++] enum class - 안전하고 쓰기 쉬운 enum

-
C++ 03 까지의 enum 은 여러 가지 문제를 가지고 있었다. 그래서 그 문제들을 해결하기 위해 C++ 11은 enum class 라는 것을 새로 만들었다. 이제부터 기존의 enum 에 어떤 문제가 있었고, 이것을 enum class 에서 어떻게 해결하였는지 살펴볼 것이다. 우선 기존의 enum 은 전방 선언할 수 없었다. 그 이유는 enumerator에 어떤 값이 들어있을지 알 수 없으면 그 크기를 정할 수 없기 때문 이다. 하지만 enum class 는 underlying type을 명시하지 않으면 int 타입과 같은 크기의 변수로 선언되고, int 값 안에 들어가지 못할 값을 지정하면 컴파일 에러를 발생시킨다. 만약 int 를 벗어난 범위의 값을 사용하고 싶다면, underlying type을 명시해주어야 한다. 기존 enum 의 또 다른 문제는 enumerator의 이름의 범위가 한정되지 않는다는 것이다. 예를 들어 아래와 같은 코드를 보자. IO 함수의 결과와 Parse 함수의 결과를 enum 으로 표현해 보았다. 하지만 이 코드는 컴파일되지 않는다. IOResult 의 Error , Ok 가 ParseResult 의 Error , Ok 와 겹치기 때문이다. 이를 해결하기 위해서는 다음과 같이 enumerator의 이름을 다르게 하거나 아래와 같이 namespace 를 이용해야 했다. 하지만 enum class 는 enumerator의 이름이 enum class 안으로 한정되기 때문에 이런 복잡한 과정이 필요 없이 그저 enum class 를 선언하여 사용하면 된다. 무엇보다 기존 enum 의 가장 큰 문제는 정수형 변수로 암시적으로 변환되는 약 타입(weak type) 변수라는 것이다. 하지만 enum class 는 정수형 변수로 암시적 변환이 되지 않는다. enum class 를 정수형 변수처럼 사용하려고 하면 컴파일 에러를 발생시킨다. 만약 정수형 변수로 사용하고 싶으면 static_cast 를 이용해...
Read more »

[Web] SpeechSynthesis - TTS API

-
SpeechSynthesis 는 Web Speech API의 하나로 주어진 텍스트를 소리로 바꿔주는 TTS API이다. SpeechSynthesis 이전에도 TTS 서비스가 있었지만, 이들은 유료이거나 웹에서 사용하기 불편한 경우가 대부분이었는데 SpeechSynthesis 의 경우 브라우저에 내장되는 API이므로 무료로 쉽게 사용할 수 있다는 장점이 있다. 물론 Web Speech API 자체가 아직 draft 에 해당하기 때문에 브라우저가 지원해야만 사용 가능하다는 문제는 있지만, 2016년 8월 15일 현재 데스크탑에서는 크롬과 사파리, 안드로이드 기본 브라우저인 크롬, 아이폰의 기본 브라우저인 사파리에 지원하고, 파이어폭스는 9월에 지원할 예정이므로 대부분의 모던 브라우저에서는 사용할 수 있다. speechSynthesis 는 5개의 함수를 가지고 있다. 그중 4개는 speak , cancel , pause , resume 이다. 이를 이용해서 재생할 음성을 추가하거나 취소하거나 일시 정지할 수 있다. 이 중 speak 함수는 SpeechSynthesisUtterance 를 인자로 받는다. speak 함수를 호출했을 때, 이미 재생 중인 utterance 가 없고 speechSynthesis 가 pause 되어 있지 않으면, 요청된 utterance 는 즉시 재생된다. 하지만 이미 재생 중인 utterance 가 있거나 speechSynthesis 가 pause 되어 있다면, utterance 는 바로 재생되지 않고 queue에 저장되었다가 후에 재생된다. 따라서 실제로 언제 재생되는지는 utterance 의 콜백을 통해서만 알 수 있다. 이벤트의 종류에 따라서 onstart , onend , onerror , onpause , onresume 등의 콜백을 등록할 수 있다. 또한, SpeechSynthesisUtterance 는 6개의 속성을 가지고 있다. 첫 번째 속성은 text 로 읽을 텍스트를 지정한다. 객체를 생성할 ...
Read more »

터미널 출력 제어를 위한 termios 구조체 이해하기

-
지난 글 에서 설명했듯이 OS X, 리눅스를 포함한 Unix를 이어받은 운영 체제는 LF (line feed, 0x0A , \n )를 개행 문자, 즉 커서를 다음 줄의 시작으로 옮기는 문자로 이용한다. 하지만 표준에 정의 된 LF 의 동작은 커서를 다음 줄로 내리는 것일 뿐, 커서를 줄의 처음으로 이동하지 않는다. 파일을 항상 운영 체제에 종속적인 애플리케이션을 통해서만 접근한다면 표준과 다른 동작은 문제되지 않는다. 하지만 파일과 입출력의 구분이 없는 유닉스 계열에서 파일과 프로세스의 입출력이 상호작용할 때 이 차이는 문제될 수 있다. 이 차이를 다루기 위해서 터미널은 출력에 적절한 가공을 하여 출력한다. 이를 제어하기 위한 플래그가 POSIX.1 표준이 정의 하는 termios 구조체의 c_oflag 다. c_oflag 는 터미널이 받은 문자를 출력하기 전에 어떤 후처리를 할지에 대한 플래그다. c_oflag에서 가장 중요한 플래그는 OPOST 다. 이는 입력에 대한 후처리를 할지 말지에 대한 플래그로 OPOST 가 꺼져있으면 다른 플래그와 상관없이 터미널은 받은 문자열을 그대로 보여준다. 이 플래그를 끄는 경우는 거의 없다. 하지만 터미널을 텍스트를 보여주기 위한 용도가 아닌 바이너리 데이터를 전송하기 위해 사용하는 경우 끄는 것이 좋다. 터미널이 Unix 계열 운영 체제에서 원하는대로 동작할 수 있게 해주는 플래그는 ONLCR 이다. ONLCR 이 켜져 있으면 터미널은 출력을 해석할 때 NL 을 CRNL 로 해석한다. 즉, Unix에서도 ONLCR 이 꺼져있다면, LF 를 만났을 때, 다음 줄의 처음으로 이동하는 것이 아닌, 현재 위치의 다음 줄로 이동한다. Unix 계열 운영 체제에서 윈도우에서 만들어진 파일을 출력해야 할 경우, CRNL 을 NL 로 바꾸지 않고도 ONLCR 플래그를 끄는 것 만으로도 간단하게 출력할 수 있다. 이외에도 구형 Mac OS 처럼 동작하게 해주는 OCRNL 플래그나 탭문자( 0x09 , \t )를...
Read more »

Linux의 clear와 Mac의 clear는 다르다

-
최근 CSI Sequence에 대한 글을 열심히 쓰고 있지만, 우리가 직접 CSI Sequence를 직접 사용할 일은 거의 없다. 하지만 알게 모르게 사용하는 CSI sequence가 있다. 바로 화면을 지우는 데 사용되는 clear 라는 명령어다. clear 는 기본적으로 두 가지 종류의 CSI sequence를 사용한다. 하나는 CUrsor Position(a.k.a CUP; CSI H )다. 이것을 이용해 커서를 화면의 시작으로 돌린다. clear 를 하고 나면, 최상단 왼쪽으로 커서가 움직이는 것은 CUP 덕분이다. 두 번째 CSI sequence는 Erase in Display(a.k.a. ED; CSI 2 J )다. 이를 이용해 화면 전체를 지운다. 여기까지는 Linux와 Mac이 공유하는 동작이다. 하지만 이후 동작에서 Linux의 clear 와 Mac의 clear 는 다르게 동작한다. 간단하게 말하면 Linux의 clear 는 스크롤 버퍼를 지우고, Mac의 clear 는 지우지 않는다. 이는 Linux의 clear는 앞의 두 시퀀스에 이어 CSI 3 J 를 출력하기 때문이다. CSI 3 J 는 xterm 이 도입한 Escape Sequence의 확장으로 스크롤 버퍼에 저장된 라인을 지우는 시퀀스다. 2011년 레드 햇 진영에서 E3라고 이름붙인 뒤 로 터미널 에뮬레이터에서는 E3 확장이라고 부르기도 한다. Mac의 clear 는 이 시퀀스를 출력하지 않기 때문에 스크롤 버퍼를 남겨둔다. 이런 차이가 발생한 것은 생각보다 오래된 일은 아니다. 원래 대부분의 터미널 에뮬레이터들은 E3 확장을 비롯한 xterm 확장들을 이해하지 못했다. 당연히 이 시절에는 Linux에서 사용되던 clear 커맨드도 E3를 사용하지 않았기 때문에 스크롤 버퍼는 지우지 않았다. 하지만 시간이 지나며 점점 xterm 확장은 다른 터미널 에뮬레이터로 전해져오며 E3도 구현되기 시작했다. 2007년 PuTTY , 2011년 Red Hat , 2014년 Gnome...
Read more »