DKMS(Dynamic Kernel Module Support)란?

이전에 드라이버 코드를 받아서 빌드해서 쓰라는 내용에서 DKMS를 언급했는데, 간단하게 이게 뭔지는 적어줘야 할 거 같아서 적어봅니다. 정리하는 내용이니 좀 딱딱할 수 있군요.

DKMS(Dynamic Kernel Module Support)는 리눅스에서 커널 모듈을 동적으로 빌드하고 설치, 제거할 수 있게 해주는 프레임워크입니다. DKMS는 커널이 업데이트될 때마다 커널 모듈을 자동으로 재컴파일하고 설치해주는 기능을 제공합니다. 이를 통해 시스템 유지보수가 더 용이해지고, 커널 업데이트 시 커널 모듈의 호환성 문제를 최소화할 수 있습니다.

DKMS의 주요 기능과 장점은 다음과 같습니다.

  • 자동 재컴파일: 커널 업데이트 시, DKMS는 등록된 모든 모듈을 자동으로 다시 컴파일하고 설치합니다. 이를 통해 커널과 모듈의 버전 불일치 문제를 방지할 수 있습니다.
  • 모듈 관리: DKMS는 모듈의 설치, 제거, 업데이트를 관리할 수 있는 명령어를 제공합니다. 사용자는 손쉽게 모듈을 추가하거나 제거할 수 있습니다.
  • 버전 관리: DKMS는 여러 버전의 모듈을 관리할 수 있으며, 필요에 따라 특정 버전의 모듈을 선택하여 사용할 수 있습니다.
  • 이식성: DKMS는 다양한 리눅스 배포판에서 사용할 수 있으며, 배포판에 관계없이 일관된 방식으로 모듈을 관리할 수 있습니다.

DKMS 설치

DKMS 설치 및 사용에 대해서는, 대부분의 리눅스 배포판에서는 패키지 관리자를 통해 DKMS를 쉽게 설치할 수 있습니다. 요즘은 기본으로 깔려서도 나오는데 없으면 설치하면 됩니다. 제가 주로 쓰는 우분투 기반에서는 다음 명령어를 사용하여 설치합니다.

sudo apt-get install dkms

모듈 추가

DKMS에 모듈을 추가하려면, 모듈 소스 코드를 포함한 디렉토리를 준비하고, DKMS 설정 파일을 작성해야 합니다. 예를 들어, mymodule-1.0이라는 버전의 모듈을 추가하려면 다음과 같이 합니다.

/usr/src/mymodule-1.0 디렉토리에 모듈 소스 코드를 저장합니다.

/usr/src/mymodule-1.0/dkms.conf 파일을 생성합니다. 이 파일에는 모듈 이름, 버전, 소스 디렉토리 등의 정보가 포함됩니다.

PACKAGE_NAME="mymodule"
PACKAGE_VERSION="1.0"
BUILT_MODULE_NAME[0]="mymodule"
DEST_MODULE_LOCATION[0]="/extra"
AUTOINSTALL="yes"

모듈을 DKMS에 추가합니다.

sudo dkms add -m mymodule -v 1.0

모듈 빌드 및 설치

모듈을 빌드하고 설치하려면 다음 명령어를 사용합니다.

sudo dkms build -m mymodule -v 1.0
sudo dkms install -m mymodule -v 1.0

모듈 제거

DKMS에서 모듈을 제거하려면 다음 명령어를 사용합니다.

sudo dkms remove -m mymodule -v 1.0 --all

이와 같이 DKMS는 리눅스 커널 모듈 관리를 보다 쉽게 만들어주며, 커널 업데이트 시에도 모듈의 호환성을 유지하는 데 큰 도움이 됩니다. 그래서 요즘은 드라이버 관련되어서는 dkms로 모듈화 하는 것이 더욱 안정적으로 유지해줄 수 있어서 많이 이용하는 편입니다. 알아두면 좋기 때문에 한번 정리해봅니다.

필요한 드라이버는 빌드해서 설치하세요 – 네트워크 카드 (USB Wifi도 물론)

리눅스를 데스크톱으로 이용하다 보면, 각종 드라이버 설치에서 애를 먹을 때가 있다. 그래픽 카드의 경우에는 엔비디아는 전용 드라이버를, AMD는 오픈소스 드라이버 지원이 잘 되어있거나 자신들의 드라이버를 제공하는 경우가 많다. 요즘 ai 열풍으로 인해서 그렇게 이용하는 경우가 많으니, 뭐이쪽은 설치가 어렵지 않다.

그런데 제일 애먹는 것이 있다고 하면 난 바로 네트워크 카드인 거 같다. 메인보드에 있는 네트워크 인터페이스의 경우에는 드라이버가 어느정도 인식이 잘 되는 녀석이라 별 신경 안써도 되는 경우가 있는데, 만약 나처럼 이런 식으로 usb 와이파이 모듈을 달거나 할 겨면 이야기가 좀 달라진다.

판매자는 해당 제품에 대해서 윈도우 드라이버나 맥용 드라이버까진 제대로 준다 해도 리눅스 드라이버를 주지 않는 경우가 좀 많다. 사실 거의 대부분이라고 해도 틀린 말 아닌 거 같은데…./먼산

지금 실험을 위해서 이용하고 있는 환경인데… 와이파시 신호에 문제가 많아서 안테나 달린 녀석을 새로 달았다. 당연히 드라이버는 별도로 제공되지 않는다.

공유기 AP도 집의 끝쪽에 있고, 노트북 또한 집의 반대 끝쪽에 있어서 그런지 안테나 신호가 있긴 해도 제대로 안잡힌다. 게다가 저 노트북 진짜 10년 가까이 쓰는 중이라 그런지 내장된 wifi 모듈도 되게 오래된 녀석이라 미묘하게 호환이 덜된다. 한국에서 산 거라서 전파 관련된 것도 있나 하는 의심도 좀 있고…. 그래서 안테나 달린 걸로 질러서 연결하는데 드라이버는 대충 잡았는데 바로 이용이 안된다. 맞는 드라이버를 제대로 잡아서 설치해줘야 하는데 그게 잘 안된 듯 하다.

뭐, 일단 이럴 땐 드라이버를 별도로 설치해주면 된다. 드라이버를 설치하려면, 해당 제품에서 이용하는 칩셋 모듈이 뭔지 알면 되는데, 요즘 이런 네트워크 카드들은 어떤 칩셋을 쓴다고 판매자가 알려준다. 그래서 그걸 기준으로 해서 검색하면 해당 코드가 나온다.

칩셋만 입력해도 이렇게 깔끔하게 나온다.

그렇게 해서, 해당 코드를 받아서 설치하면 된다. 근데 지금처럼 결과가 둘이라면? 그땐 README를 읽어라.

생각보다 설명 친절하게 잘 적어준다. (검색 결과에 나온 다른 쪽은 아마 본인이 쓰거나 별도의 환경에서 이용하기 위해서 만든 흔적이 보였다.)

이렇게 호환 OS와 커널, 컴파일러 종류도 알려준다.

이렇게 다양한 OS도 테스트를 해봤고 (아래에 우분투도 있었다.)

이녀석은 설치용 스크립트까지 제공해준다. ㅠㅠㅠㅠ

이렇게 깔끔하게 정리가 잘 된 내용을 보고 따라하면 알아서 설치가 될 것이다. 가장 최근까지 지원해주는 것들은 DKMS에 의한 서포트까지 되기 때문에 설치에 어렵지 않게 적용될 수 있어서, 잘 해주는 편이다.

그래서 리눅스에서 필요한 드라이버는 빌드해서 설치해서 쓰면 된다는 게 이런 것이다. 생각보다 지원되는 것이 많다. 잘 알아보고 잘 써보자.

Javascript 스터디 – 002 여담: 옛날 Javascript를 보여주지…ㅡㅅㅡ

내가 하나하나 진행하면서 글 쓰려고 했는데… 옛날에 자바 스크립트 쓰는 거 진짜 더러웠다고 하는데 안믿는 애들이 있어서 옛날에 쓰는 방식을 보여줬다. 그리고 그 내용을 여기서도 보여주려고 한다.

옛날 자바스크립트는 자바스크립트와 호환되지 않는 브라우저가 스크립트 부분을 html의 일부로 그냥 화면에 표시해 버리는 것이 빈번하게 존재했다. 그래서 반드시 head 태그 안에 script를 별도로 작성하였다. 그럼에도 불구하고 내부에 js 코드를 넣으려면 어떻게 했냐고? html 주석과 섞어서 처리했다.

<script>
<!-- 
document.write("hello");
-->
</script>

이런 식으로 처리해버리면 js가 처리되는 코드에서는 실행되고, 안그러면 그대로 html의 주석 처리가 되어서 실행되지 않는 것이다. ㅡㅅㅡ 게다가 noscript라는 태그도 존재한다. 이런 걸 이용해서 처리하면 js에 대응하지 않는 브라우저로는 별도의 표시가 되도록 하는 형식이다. 위에 것에서 추가한다면… 이런 것이다.

 <script>
<!-- 
document.write("hello");
-->
</script>
<noscript>
This browser dosen't corrspond to js.
</noscript>

….아 진짜.. 이거 생각하니 열받네. 이거 언제부턴가 head에서도 쓸 수 있게 되어있다. 그래서 이거 쓰는 건 좀 조심해야 한다. 게다가 여전히 xhtml에서는 이용 안된다.

근데 요즘은 js 동작 안할때를 위해서라면서 html 알려줄 때 알려주는 걸로 아는데, 요즘 브라우저에서 아직도 안되는 게 있나…? 싶을 정도이다. 뭐 써서 안전하다면 그냥 쓰던가. ㅡㅅㅡ

그리고 js의 옛날 특징이라고 하면… language, text를 별도로 지정해서 이용하였던 것이라고 생각한다. 바로 이런 식으로 말이다.

vs code가 암말도 안한다. 아직도 적용되는 녀석이라는 거다.

내가 배우기 이전에는 이렇게 해서 js1.2 지원 브라우저에서만 이용되게 하려고 이렇게 했었다고 한다.

근데 내가 배울 땐 이렇게는 안배웠고…. type로 배웠지. 이렇게 배운 사람들 장난 아니게 많을 것이다. 옛날부터 엄청 오래 써오던 CMS 시스템들이 아직도 이런 js 코드가 많이 남아있을텐데…

이렇게 처음으로 배운 분들 많을 것이다.

여기에 이벤트 핸들러(onClick 같은것들)에 기술한 스크립트에 대해서도 종류 지정을 할 수 있었기 때문에, html의 헤더에다가 meta를 지정해서 이용하는 것도 있었지…

이런 것들이 아직도 쓰이긴 하지만…. 요즘은 그나마 나아졌다고 생각한다. 이것 조차 불필요하게 되어서, 이젠 그냥 규정치로써 js가 그냥 당연하게 이용되니깐. 타입스크립트 같은 경우에는 개발 환경 구성 단계에서 타입스크립트를 이용한다고 지정만되어있으면 그냥 그대로 사용되기도 하고….

그래서 이런 이야기 하면서 세월 좋아졌다고 하면 나이 든 티가 날 것이다. ㅡㅅㅡ

Filesystem in Userspace와 AppImage

Filesystem in Userspace(FUSE)는 커널이 아닌 사용자 공간에서 파일 시스템을 구현할 수 있게 해주는 소프트웨어입니다. FUSE는 Linux 커널 모듈과 사용자 공간 라이브러리로 구성되어 있으며, 이를 통해 사용자는 자신만의 파일 시스템을 쉽게 만들 수 있습니다.

FUSE의 주요 특징은 다음과 같습니다.

  1. 사용자 공간에서 실행: FUSE는 파일 시스템 코드를 사용자 공간에서 실행할 수 있도록 해줍니다. 이는 파일 시스템 개발을 더 쉽게 하고, 커널 크래시 없이 개발 중인 파일 시스템을 테스트할 수 있게 합니다.
  2. 다양한 언어 지원: FUSE는 C, C++, Python, Java 등을 포함한 다양한 프로그래밍 언어를 지원합니다. 이는 개발자가 익숙한 언어를 사용하여 파일 시스템을 구현할 수 있게 합니다.
  3. 유연성: FUSE를 사용하면 다양한 종류의 파일 시스템을 쉽게 구현할 수 있습니다. 예를 들어, 원격 서버의 파일 시스템을 로컬에 마운트하거나, 데이터베이스를 파일 시스템으로 사용하는 등의 작업이 가능합니다.
  4. 보안: FUSE는 사용자 공간에서 실행되므로, 커널 공간에서 실행되는 전통적인 파일 시스템에 비해 보안상의 이점을 가질 수 있습니다. 이는 버그나 악성 코드로부터 시스템을 보호하는 데 도움이 됩니다.

FUSE의 동작 방식은 다음과 같습니다.

  1. 커널 모듈: FUSE는 먼저 커널 모듈을 통해 파일 시스템 호출을 인터셉트합니다.
  2. 사용자 공간 라이브러리: 인터셉트된 호출은 사용자 공간으로 전달되며, FUSE 라이브러리가 이를 처리합니다.
  3. 파일 시스템 구현: 사용자는 FUSE 라이브러리를 사용하여 파일 시스템의 동작을 정의합니다. 이는 파일 읽기, 쓰기, 삭제 등의 작업을 포함합니다.

FUSE는 특히 개발자들이 새로운 파일 시스템을 빠르고 쉽게 개발할 수 있도록 도와주는 강력한 도구입니다. 이를 통해 다양한 파일 시스템 실험과 구현이 가능해지며, 이는 Linux의 파일 시스템 확장성과 유연성을 더욱 강화합니다.

이렇게 좀 사전적인 의미로 FUSE를 설명해 드렸습니다. 근데 왜 이걸 이렇게 설명하냐면…. AppImage라는 형태의 프로그램들을 설명하기 위해서 그렇습니다.

요즘 제가 몇몇 프로그램을 받아서 리눅스에서도 써보고 있는데, AppImage라는 녀석으로 받을 경우에 어떻게 실행하라고는 쉽게 나와있습니다. Property에서 보면 이걸 프로그램으로 인식해서 실행하라고 체크박스가 있는데, 그걸 체크하여 설정한 후에 그냥 더블클릭하면 실행할 수 있습니다만, 이걸 왜 이렇게 해야 하는지에 대한 설명이 모자라더군요. 그 기반이 되는 녀석이 바로 FUSE입니다. 그리고 이녀석이 AppImage와 어떻게 연관되어있는지도 설명을 좀 사전적으로 해보겠습니다.

FUSE(Filesystem in Userspace)와 AppImage는 서로 다른 목적을 가진 두 가지 기술이지만, FUSE가 AppImage의 작동에 중요한 역할을 합니다. 이 두 가지가 어떻게 연결되는지 설명드리겠습니다.

AppImage

AppImage는 Linux 시스템에서 소프트웨어를 배포하는 포맷입니다. 이를 통해 하나의 실행 파일로 소프트웨어를 배포하고 실행할 수 있습니다. AppImage는 소프트웨어 설치를 필요로 하지 않으며, 단일 파일로 제공되어 사용자가 클릭하여 실행할 수 있습니다. 이는 특히 소프트웨어 배포를 간단하게 하고, 다양한 Linux 배포판에서의 호환성을 보장합니다.

FUSE와 AppImage의 연결

AppImage는 FUSE를 사용하여 파일 시스템을 마운트하고, 이를 통해 소프트웨어를 실행할 수 있습니다. 구체적으로, AppImage는 내부적으로 압축된 파일 시스템을 포함하고 있으며, 이를 FUSE를 통해 임시 마운트하여 소프트웨어를 실행합니다. 다음은 그 과정에 대한 자세한 설명입니다:

  1. AppImage 실행: 사용자가 AppImage 파일을 실행하면, 이 파일은 자체적으로 포함된 파일 시스템 이미지(압축된 파일 시스템)를 마운트하려고 시도합니다.
  2. FUSE 사용: AppImage는 FUSE를 사용하여 파일 시스템 이미지를 임시로 마운트합니다. 이를 통해 AppImage 내부의 모든 파일과 디렉토리가 접근 가능해집니다.
  3. 소프트웨어 실행: 마운트된 파일 시스템에서 소프트웨어를 실행합니다. 이 과정에서 필요한 라이브러리와 리소스는 모두 마운트된 파일 시스템 내에 포함되어 있어, 시스템에 추가적인 설치나 설정 없이 소프트웨어를 실행할 수 있습니다.
  4. 마운트 해제: 사용자가 소프트웨어를 종료하면, FUSE를 통해 마운트된 파일 시스템은 자동으로 해제됩니다. 이는 시스템에 잔여 파일이나 설정이 남지 않도록 합니다.

간단 요약

  • FUSE: 사용자 공간에서 파일 시스템을 구현하고, 안전하게 파일 시스템을 마운트 및 해제하는 기능을 제공합니다.
  • AppImage: FUSE를 사용하여 내부에 포함된 파일 시스템 이미지를 임시로 마운트하고, 이를 통해 소프트웨어를 실행합니다.

이러한 연결 덕분에 AppImage는 설치 과정 없이도 복잡한 소프트웨어를 쉽게 배포하고 실행할 수 있는 편리한 방법을 제공합니다.

자, 좀 간결하게 이해가 되었을까요? 이렇게 해서 AppImage로 배포되는 프로그램들이 조금씩 늘고 있고, 여러모로 사용되고 있습니다.

Javascript 스터디 – 001 개발도구와 개발 환경, 그리고 hello world

진입장벽이 제일 낮은 곳 아닐까 하는 생각이 든다. 솔직히 그냥 메모장과 웹 브라우저만 있어도 가능하다. 대부분의 실행과 디버그는 웹 브라우저에서 다 진행할 수 있다.

뭐, 메모장은 그래도 좀 그러니깐 그냥 에디터를 이용하자고 하자. 웹은 각종 여러 언어들을 섞어서 개발하다 보니 IDE(통합 개발 환경)으로 나오는 경우가 별로 없다. 있어도 거의 대부분 플러그인 떡칠이다. 그럴꺼면 그냥 에디터 써도 될 정도다. 내 경우에는 주로 Visual Studio Code를 이용한 것을 보여줄 것이다. vim, emacs,인텔리, 에디트플러스 등등 그냥 편한 거 쓰면 된다. 뭐가 좋냐고 물으면 그냥 쓰기 편한 게 좋다고 할 것이다.

그리고 실행과 디버그 자체가 그냥 웹 브라우저를 이용하기만 하면 되기 때문에 그렇게 어려운 것이 없다. 직접 만든 코드를 웹 브라우저에서 돌려보기만 하면 되니깐.

그래서 바로 hello world를 만들어서 보여주려고 한다. code를 열어서 html 페이지를 아래와 같이 하나 만들었다.

그냥 진짜 hello world.

script라고 되어있는 곳에 옛날에는 자바스크립트라고 정의해주고 하는 내용을 넣고 해야 하는데… 요즘은 그냥 저렇게 해도 된다. js가 거의 표준 아닌가 싶을 정도로 널리 쓰이고 있으니깐… (타입 스크립트 이야기 하고 싶으면 나중에 다른 기회를 보자.)

그래서 저 html 파일을 실행하고, 브라우저의 개발자 모드를 보면 아래처럼 hello world가 표시될 것이다.

근데 지금 내가 hello world를 두 군데에 넣어서 뭐가 뭔지 몰겠다 싶으면, 코드 수정하고 저장해보자.

단순 무식한 구분 방법. ㅡㅅㅡ

이렇게 그냥 무식한 방법으로 구분이 되게 했으니 결과는… 무식하게 나온다.

무식하지만 효과는 좋게 나온다. 그래서 난 무식하게 알려주는 걸 좋아한다.

이제 하나하나 다시 시작해보자.

Javascript 스터디 – 000 회기, 그리고 다시 정리

줄여서 js라고 하던데.. 만난 건 엄청 오래전이다. 근데 내가 쓸 때의 js는 진짜 그냥 웹 페이지를 동적으로만 만들어주고 하는 데 이용하던 스크립트 중 하나였다. 거의 2006~2008년부터 만나기 시작해서 알게 된 녀석인데….

이 때 이용자들은 알 것이다. 사이트가 동적으로 움직일 수 있다는 것만으로도 자바가 엄청나게 각광받고, js가 그 자리 안에서 조금씩 발전하고 있는데 각종 알 수 없는 warning 띄우고 할 때에 보면 꼭 이녀석이 난리치고 있던 것도 있고… 뭔가 html 코드 안에서 난잡하게 돌아가고 그런 것들. 그리고 사이트 느리게 만드는 주범 중 하나였고… (그때 뭐 알고 했나.) 그러면서 브라우저끼리 호환도 잘 안되던 과거가 있질 않나… 거기에 더해서 웹 사이트에서 복잡한 기능을 넣고 하질 않았기 때문에 js 코드들도 간단했기 때문에 js 하는 것 = 그냥 왕초보 이런 느낌이었던 시절이다.

근데 지금 와서 웹 하는 데 보면 죄다 js가 기본으로 깔려간다. 웹 클라이언트에서 js 빼고 이야기 못할 정도다. 언어 자체의 성능도 발전하고 jit도 도입되면서 실행 속도도 엄청 빠른 편이다.

게다가 요즘 웹 개발이 주를 이루고 그에 따라 엄청 복잡해지면서 수요도 엄청 늘고, 나같은 임베디드 하던 인간들도 최소한의 설정 작업 만드는 것도 이젠 웹 베이스로 만들어 줘야 하는데 이런 곳에서도 어느정도 알아는 둬야 협업이 된다. 그래서 요즘 웹 관련된 내용을 하나하나 다시 볼려고 한다.

왜 안해봤어요? – 해볼 기회가 없었는데요?

되게 당연한 질문과 당연한 대답인데… 이상하게 들릴 때가 있다.

개발자 채용 시장에서나 그냥 잡소리 하다보면 이상하게 한번씩 나오는 말이다.

난 임베디드만 주로 했던 녀석이라 솔직히 웹을 건드릴 일이 없다. 그래서 웹쪽은 지원도 안했는데, 웹은 왜 안했냐고 물어보는 사람들이 간간히 있다. 대부분 개발 모르는 사람들이다.

옛날에는 진짜 임베디드에서 웹 페이지 넣는 거라고 해봤자 php 넣고 돌아갈 수준의 정말 작은 웹 서버 갖고 제어 컨트롤러 만들던 게 대부분이었다. 요즘은 그렇게는 안한다. 돌리는 하드웨어가 좋은 경우가 많아서 말이지.

요즘에 들어와서야 config 관련 작업들을 웹 인터페이스로 제공해 주는 곳들이 많으니 그런 곳들 좀 이용해야 한다면 나도 좀 해보지 않을까?

개발자와 건강 – 06. 키보드로 손가락이 망가질 수 있다고요? 네. 가능합니다.

키보드로 손가락 망가지는 거 진짜 많이 겪을 수 있는데, 이게 망가지기 쉬운 요소가 너무 많습니다. 그래서 키보드 선택할 때 진짜 고민 많이 해야 하는데… 그렇지 않은 것들이 많네요.

이게 말이 되는 소리냐 할 수 있겠지만… 본인의 키보드 타이핑 습관에 대해서 한번 진지하게 생각해야 합니다.

손목 위치나 손복 받침대 등으로 해서 손목이나 손 위치에 대해서 교정을 했다고 하는데도 손이 아프다, 그러면 보통 타이핑 하는 감각이 지금 쓰는 키보드랑 안맞아서 그럴 수 있습니다.

사실 키 입력의 손가락 관련해서는 그렇게 크게 문제가 될 일은 없습니다. 일반적으로 많이 이용하는 맴브레인의 경우에는 상당히 부드럽게 키가 입력되기 때문에 키 입력에 그렇게 큰 힘이 들어가는 것이 아니기 때문입니다.

문제는 기계식 키보드가 요즘 널리 보급되고, 체리사의 스위치 관련 특허가 풀리면서 여러모로 키보드 종류가 엄청나게 쏟아지고 있고, 누구나 쉽게 기계식 키보드를 이용하면서 다양한 형태의 제품에서 자기한테 맞는 형태인지 아닌지를 봐야 될 필요가 좀 많이 생겼습니다. 그전까지는 기계식 키보드가 좀 매니아의 영역이었고, 무접점 키보드도 가격이 엄청 비쌌기 때문에 그렇게까지 이용하고 그런 사람들이 적었습니다만, 요즘은 확실히 기계식 키보드 많이 쓰면서 좀 타자 습관들이 다양하게 되어서 문제가 되는 경우가 있더군요.

특히 자기는 컨트롤 할 수도 없는 높은 키압을 이용하는 것이 버릇이 되다보니 일반적인 키보드를 입력할 때에 세게 치는 버릇이 생기는 사람들이 많아졌습니다. 그래서 그냥 훅훅 들어가는 키보드에서도 세게 치고, 본인이 집에서나 평소에 쓰는 키보드도 키압이 높은 형태로 쓸 테니 누르는 데 힘이 들어가고, 그리고 그 키압을 견뎌야 해서 보강판 들어있는 것들을 이용할텐데 그걸 통해서 받아들여지는 반동도 무시못할껍니다.

이게 누적되면 나중에 손가락이 쑤시는 경험을 하게 됩니다. 특히 요즘, 같은 클릭(청축)이라고 해도 제조사마다 여러모로 차이가 나서 미묘하게 사람 감각을 다르게 해주는 녀석들이 많이 나와서 손이 잘 적응되지 못하고 하다가 그냥 세게 치는 습관들이 많이 생기나봅니다. 키보드는 부드럽게 칠 수 있으면 충분합니다.

개발자와 건강 – 05. 키보드에 대한 선택도 고민해야 되나? 손목 보호편

키보드 관련해서는 좀 여러모로 사람들이 반응을 많이 할 수 있는 주제이긴 한데… 써야 할 때에 써야 겠다. 왜냐면 키보드 관련해서는건강에 대해서 주의해야 할 요소가 있는데 일단 손목 보호와 손가락 보호쪽이군요. 일단은 가장 신경 안쓰는 거 같은 손목 보호부터 시작하려고 합니다.

키보드로 장시간 타이핑하는데 있어서 손목 나가는 건 굉장히 아픈 요소가 됩니다. 나가는 게 손목만 나가냐? 아뇨. 손가락도 나가고 심지어 팔도 나갑니다. 근데 이건 요인이 너무 많네요. 작게는 키보드 환경부터 시작해서 크게는 의자나 자세 전반적인 거 전부 다… 진짜 복잡합니다.

근데 키보드 관련해서 나오는 건강 문제로 보면 정말 간단하게 해결할 수 있는 것입니다. 키보드를 정면 중앙에 배치해서 이용하고, 손바닥이나 손목이 닿지 않도록 하여 손목을 되도록 직선으로 유지하여 타이핑 하는 것입니다.

되도록 직선으로 두고 치라는 것이 중요한 것이, 손목 꺾인 채로 계속해서 손가락이 움직이는 작업을 하기 때문에 그게 그대로 문제가 많이 됩니다. 힘줄 관련된 것도 그렇고, 손목 자체가 꺾여있는 것도 그렇고….

거기다가 요즘 기계식 키보드 많이 쓰고 있는데, 기계식 키보드들이 생각보다 그냥 기본적으로 키보드가 두껍습니다. 스위치들이 들어가 있어야 하니깐요. 그런 상태에서그냥 책상에 손목 두고 치는 경우에 그대로 손목 꺾인채로 쓰게 되고 합니다. 근데 그걸 그냥 잘 모르는 채로 그냥 두는 경우도 많고, 키 타이핑 때문에 키보드 각도를 엘레베이션 해서 점점 올라가게 해두고 하다보니 여러모로 손목이 그냥 꺾일 수 있습니다. 얇은 키보드를 이용하라고 하는 사람들도 많은데, 그럴 수 없다면 환경을 만들어야겠죠?

그러니 손복 받침대(팜레스트)를 꼭, 반드시 써야 합니다. 특히 기계식 키보드는 기계식 키보드를 위해서 팜레스트가 두껍게 나와있는 것들이 있는데 그런 것들이 확실히 좋습니다. 맴브레인용으로 나와있는 낮은 팜레스트를 기계식 키보드 앞에 이용하면 별 차이 없습니다. 높이가 낮아서 제대로 받쳐주질 못하거든요.

근데 이런 내용보다 더 찾게 된다면 인체공학 키보드를 찾아야 합니다. 키보드가 좌우로 나눠져 있고 그런 것들이 대체 뭔 효과가 있을까 싶겠지만, 생각보다 효과 엄청 좋습니다. 팜레스트 일체형에다가 각도와 방향이 생각보다 편하게 되어있어서 오랫동안 이용할 수 있는 형태입니다. 생긴건 이상해 보여도 생각보다 정말 오랫동안 칠 수 있습니다.

다음에는 손가락 관련된 이야기를 좀 해보겠습니다.

개발자와 건강 – 04. 건강 생각하면 되도록 노트북 환경에서 장시간 개발하지 말았으면 좋겠습니다.

노트북이 참 좋은 녀석인 건 맞습니다. 언제 어디서나 들고 다니면서 일을 할 수 있게 해주는 만능의 도구죠. 연락까지 메신저로 시도 때도 없이 연락하면 완벽한… (….)

근데, 그 휴대성을 위해서 여러모로 희생하는 것들이 많아서 장시간 붙잡아야 한다고 하면 노트북 환경에서는 좀 안했으면 좋겠습니다. 건강상의 문제에 영향이 있는 것들이 많아서요.

아니면 노트북 환경이라 하더라도 좀 환경을 그나마 개선해서 이용하는 과정을 곁들이는 거이 중요할 거 같습니다.

노트북 받침대를 두고 모니터 눈높이를 좀 더 올려주세요. 이건 모니터 고르는 내용에도 설명을 했는데, 진짜 모니터 위치랑 눈높이 위치를 맞춰서 하는 것이 정말 중요합니다. 그게 눈도 눈인데 목이랑 그 주변 근육까지도 영향을 줍니다. 계속 긴장되어서 피곤한 자세로 있게 되는 겁니다.

이게 노트북에도 그대로 영향을 미칩니다. 가뜩이나 노트북은 책상에 올려놓고 나면 화면의 위치는 고정된 것이나 다름이 없기 때문에 자세가 더 안좋아질 수 있습니다. 이게 좀 간단한 작업이면 모를까, 장시간 작업하면 진짜 자세 무너집니다. 그래서 노트북 받침대에 올려둬서 노트북의 화면을좀 더 위쪽으로 해서 눈높이와 같이 해주는 것이 좋습니다. 그렇게 하면서 동시에 좀 더 멀리 둬서 거리도 두면서 작업하면 편하게 할 수 있습니다.

근데 이러고 나면 또 이럴꺼죠. 그러면 키보드 타이핑 하기 힘든데요? 이럴 분들 꼭 있죠.

네, 키보드 마우스 사세요. 제발 사세요. 꼭 사서 이용하세요. 개발자들 괜히 백팩 메고 다니는 거 아닙니다. 그 안에 노트북이랑 키보드, 마우스, 노트북 스탠드 얇고 가벼운 거 갖고 다니고 하면 백팩 말고는 답이 없는 겁니다. 아니면 가방용으로 차를 끌고 다니면 됩니다. ㅡㅅㅡ

작업하는 곳에 혹시 외부 모니터를 연결해서 이용할 수 있다면 외부 모니터를 연결해서 이용하는 것도 추천합니다. 노트북 화면 사이즈보단 모니터 사이즈가 더 크니깐요. 크고 편한 모니터를 이용하는 것이 더 좋은 선택일 수 있는 것이죠.

정말 피할 수 없는 경우를 위해서 이런 이야기를 했지만, 장시간으로 이용한다면 될 수 있으면 PC를 보급해주는 것이 더 좋은 것인데… 뭐 노트북이라는 녀석 특유의 장점이 있기 때문에 작업 환경 그렇게 주는 걸 뭐 어떻게 하냐고 하면 뭐라고 말을 못하겠네요. 근데 될 수 있으면 장시간 작업은 피하시고, 가끔씩 쉬면서 해주세요. 노트북 작업이 일단 건강에 좋냐고물으면 아닌 건 맞습니다.