Simple is Beautiful.

mfc100ud.lib 파일을 열 수 없습니다 문제를 해결하는 방법에 대해 알아봅니다.

1. 현상

잘 빌드되던 프로젝트를 오래간만에 빌드했더니 "mfc100ud.lib 파일을 열 수 없습니다." 에러가 발생합니다.

2. 원인 

암만 생각해도 소스를 변경한 기억이 없었고 뭐가 문제인지 곰곰이 생각해보던 도중 VisualStudio 2022 Pre 버전을 설치했다 지운적이 있었음이 기억났습니다.

환경변수를 확인해본 결과 atlmfc 경로가 환경변수에서 빠져있었음을 확인할 수 있었습니다.

3. 수정

환경변수에 mfc100 경로를 추가해 줍니다.

경로 확인 결과 해당 파일이 "C:\Program Files (x86)\Microsoft Visual Studio 10.0"아래에 있음을 확인할 수 있었습니다.

"C:\Program Files (x86)\Microsoft Visual Studio 10.0"를 환경 변수에 추가한 뒤에 정상적으로 빌드됨을 확인하였습니다.

앞선 글

지난 8월 Stack Overflow에서 2021 Developer Survey를 공개했습니다. 개인 사정상 두 달이 지난 지금에서야 관련 글을 쓰게 됩니다.

개발에 관심이 있거나 개발자분이라면 직접 차근차근 읽어보시는 걸 추천합니다.

Stack Overflow 2021 Developer Survey

다양한 설문 중 흥미 있는 항목에 대해서만 글을 작성할 예정입니다.

1. Developer Profile - Experience

사실 바로 기술적인 내용으로 들어가려 했는데 개발 경험 관련 결과로 흥미로운 결과가 보였습니다.

교육을 포함하여 총 몇 년 동안 코딩을 하였습니까?

교육은 포함하지 않고 전문적으로 코딩한 기간은 몇 년입니까?

거의 50%에 달하는 개발자는 코딩을 배운 지 10년 미만이며 현직 개발자 셋 중 한 명은 경력이 5년 미만입니다. 제 생각엔 꽤나 놀라운 결과입니다. 

지금에 와서야 개발 학원 등 널리 알려졌지만 개발자라고 하면 왠지 엄청 어려운 공부를 오랜 기간 한 뒤에 숙련되어 업무를 수행하는 그런 직종으로 알려져 왔습니다. 특히나 현업에 종사하고 계시는 분들의 셋 중 하나가 경력이 5년 미만이라는 것은 최근 개발자가 되신 분이 그만큼 늘어난 것처럼 보이기도 합니다. 

굳이 이런 내용을 왜 가져왔냐고요? 이 글을 읽고 계신 분들 중 개발자가 아닌 분들도 개발에 관심을 갖고 한번 도전해 보시라는 내용을 전달해 드리기 위함입니다. 전혀 늦지 않았다는 걸 알려드리고 싶었습니다.

2. Technology 

이제 기술적인 주제로 넘어가 보겠습니다.

가장 인기 있는 언어 - 지난 1년 동안 어떤 프로그래밍, 스크립팅 및 마크업 언어에서 광범위한 개발 작업을 수행했으며 내년에는 어떤 작업을 하고 싶습니까?

개발 언어에 관심이 있던 사람이라면 누구나 예측 가능한 결과가 나왔습니다. 당연히 JS 쪽의 강세로 TS도 뒤따르고 있으며 Node.js 역시 인기입니다. 

가장 사랑받고 두려워하는 프로그래밍, 스크립팅, 마크업 언어

인기 있는 언어와는 또 다른 결과가 나왔습니다. 가장 인기 있던 JS는 중위권에 그쳤으며 TS는 오히려 상위권으로 올라섰습니다. Java 역시 인기투표와는 달리 오히려 C#, C++ 보다 하위권에 위치하였습니다.

가장 사랑받고 두려워하는 데이터 베이스

회사에서 쓰라는 Oracle이 순위가 매우 낮아서 슬픕니다. Redis, pgSql, MongoDB가 차례로 상위권에 위치하고 있습니다. RDB가 인기가 많이 없어진 건 사실인가 봅니다.

가장 사랑받고 두려워하는 웹 프레임워크

스벨트가 가히 압도적입니다. 등장한 지 얼마 되지 않았음에도 불구하고 1위를 차지했습니다. 그 뒤를 dotNet Core, React js, Vuejs가 따르고 있습니다. Angular는 아직 중위권을 유지하고 있습니다. 이제 jQuery와 AngularJs는 그만 놓아주어야 할 때인 것 같습니다.

가장 많은 임금을 받는 프로그래밍, 스크립팅, 마크업 언어

Perl의 순위가 많이 떨어졌으나 여전히 많은 임금을 받는 언어입니다. 높은 임금을 받는 언어들은 함수형 언어로 보입니다. 하지만 대부분의 개발자들과 개발에 관심이 있는 사람들은 위에 명시된 언어들 중에서 아는 언어가 얼마나 많이 있을까요? 

함수형 언어를 잘 알지 못하는 이유는 명확합니다. 그만큼 쓰는 사람이 적어서입니다. 함수형 언어의 최강점은 짧은 코드로 짧은 시간 안에 개발을 해낼 수 있다는 점입니다. 이를 가능하게 해 주는 것은 함수형 언어의 재귀 함수입니다. 이와 동시에 함수형 언어의 진입 장벽이 되는 것이 재귀 함수입니다. 

C 언어를 배울 때 재귀 함수 관련 내용을 읽고 따라 해 볼 때를 생각하면 이해하기 쉽습니다. 코드가 엄청나게 간결해짐과 동시에 내 머리는 터져갑니다. 미루어 말해보자면 저 함수형 언어를 사용하는 개발자들은 이미 다른 언어에 매우 숙련된 시니어 개발자일 확률이 높습니다. 처음부터 저런 함수형 언어부터 시작하는 것은 말리고 싶습니다.

맺음글

올해도 슬슬 마무리돼가고 있습니다. 몇 년간 그래 왔듯 웹 프레임워크 쪽에서는 매년 난리가 나고 있습니다. 올해도 스벨트가 핫 트렌드로 올라왔습니다. 클로저나 엘릭서와 같은 함수형 언어는 사랑받는 언어긴 하지만 배우고 싶어 하는 언어는 아닙니다. 

언어 선택에는 정답이 없습니다. 이런 글을 쓰는 많은 분들이 언어는 도구일 뿐이다 라고 말씀하는 이유가 있습니다. 이런저런 설문조사와 트렌드를 꾸준히 확인하면서 자신의 상황에 맞는 학습 로드맵을 만드는 게 좋다고 생각합니다. 

Ubuntu Jenkins에서 docker build시 Docker permission denied 문제를 수정하는 방법에 대해 알아봅니다.

1. 문제

Ubunto 20.04에 설치된 Jenkins 2.317 버전에서 docker build시 다음 에러 메시지와 함께 permission denied 에러가 발생합니다.

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/build?buildargs=%7B%7D&cachefrom=%5B%5D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&labels=%7B%7D&memory=0&memswap=0&networkmode=default&rm=1&shmsize=0&t=my-app%3Alatest&target=&ulimits=null&version=1": dial unix /var/run/docker.sock: connect: permission denied

2. 원인 및 수정

jenkins 유저가 docker에 접근할 권한을 설정해야 합니다. 다음 명령을 통해 docker에 권한을 부여합니다

> sudo usermod -aG docker jenkins

이후 Jenkins 서비스를 재시작 합니다.

> sudo service jenkins restart

이후 다시 빌드를 수행해보면 정상적으로 빌드가 진행되는 것을 확인할 수 있습니다.

[MyApp] $ /bin/sh -xe /tmp/jenkins10435575314027477160.sh
+ docker build --tag my-app:latest --file Dockerfile .
Sending build context to Docker daemon 249.9MB
Step 1/5 : FROM mcr.microsoft.com/dotnet/aspnet:5.0
...

jenkins 서비스 재시작을 잊지 마세요.

1. 현상

npx create-react-app을 통해 react 앱을 생성하면 Critical 레벨의 이슈가 포함된 채 생성됩니다.

audit fix를 실행해도 해당 문제는 수정되지 않습니다.

2. 원인

결론부터 말하면 npm에 대한 버그입니다.

보다 자세한 내용은 다음 글을 참고해 주세요: Help, npm audit says I have a vulnerability in react-scripts!

3. 수정

package.json을 열어 다음과 같이 수정해 줍니다

//package.json
...

  "dependencies": {
    "@testing-library/jest-dom": "^5.14.1",
    "@testing-library/react": "^11.2.7",
    "@testing-library/user-event": "^12.8.3",
    "react": "^17.0.2",
    "react-dom": "^17.0.2",
    "web-vitals": "^1.1.2"
  },
  "devDependencies": {
    "react-scripts": "4.0.3"
  },
  
 ...

주요한 수정사항은 react-scripts입니다. 기존 dependencies에 있던 react-scripts를 devDependencies로 이동시킵니다.

그 후 npm audit --production을 실행시킵니다.

취약점 보고 내용이 0건으로 바뀌었습니다.

4. 문제가 해결된 게 아니라 무시한 거 아닌가요?

얼핏 보면 위와 같은 수정 내용이 문제를 수정한 게 아닌 devDependencies로 react-scripts를 이동시킴으로써 경고 메시지만 없앤 것처럼 보일 수 도 있습니다. 이 내용은 위의 링크된 원문 글에도 나와있으며 간단히 번역해보면 다음과 같습니다.

Create React App은 빌드 도구입니다. 즉, 실행 중인 Node 애플리케이션을 생성하지 않습니다. 개발 중 빌드 시간에 실행되며 정적 자산을 생성합니다.

그러나 npm 감사는 Node 앱용으로 설계되었으므로 프로덕션에서 실제 Node 코드를 실행할 때 발생할 수 있는 문제에 플래그를 지정합니다. 이것은 Create React App이 작동하는 방식이 아닙니다.

이것은 우리가 종속성에 대해 받는 압도적인 양의 "취약성" 보고서가 잘못되었음(false positive)을 의미합니다.

애초에 npm audit이 검사하는 방식에 문제가 있음을 내포하고 있습니다.

이 글은 NEMA의 DICOM 표준 중 6.2 Value Representation (VR)에서 PN을 정리한 글입니다. 원문은 아래의 링크를 통해 확인해 주시기 바랍니다.

http://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_6.2.html#sect_6.2

6.2. Value Representation (VR) - PN: PersonName

5개의 구성으로 이루어진 규칙을 사용해 인코딩 된 문자열입니다.

문자코드 5CH(ISO-IR 6에서의 백 슬래시"\")는 멀티 밸류 데이터에서 구분 기호로 사용되기 때문에 존재하면 안 됩니다.

해당 문자열의 뒷부분은 공백으로 채워질 수 있습니다.

사람에게 사용되는 경우 순서에 따라 5개로 구성됩니다: 성, 이름, 중간 이름, 접두사, 접미사.

노트: HL7은 구성요소 내에서 선행 공백을 금지합니다. DICOM은 선행 및 후행 공백을 허용하며 중요하지 않은 것으로 간주합니다.

5개의 구성요소 중 일부는 공백일 수 있습니다.

해당 구성 요소 간의 구분 기호는 캐럿("^") 문자입니다.

구분 기호는 4개 이하입니다. 즉 모든 구성 요소가 존재하는 경우 마지막의 구분 기호는 필요하지 않습니다.

내부에 NULL값이 있는 경우 구분 기호가 필요하지만 마지막이 NULL값인 경우 구분 기호는 생략할 수 있습니다.

각각의 구성요소마다 여러 개의 항목이 허용되며 사람이 선호하는 형식으로 문자열을 통해 인코딩 됩니다.

수의학적으로 사용되는 경우 순서에 따라 다섯 개의 구성 요소 중 처음 두 개는 책임 담당자의 성 또는 조직 이름과 환자 이름이 됩니다. 나머지 구성요소는 사용되지 않으면 존재하지 않아야 합니다.

위와 같은 다섯 가지 구성 요소의 그룹을 개인 이름 구성 요소 그룹(Person Name component group)이라고 합니다.

표의 문자와 음성 기호로 이름을 쓸 목적으로 최대 3개의 구성요소 그룹(부록 H, I, J 참조)을 사용할 수 있습니다.

구성요소 그룹의 구분 기호는 등호("=", 3DH) 문자입니다.

구성 요소 그룹의 구분 기호는 두 개 이하여야 합니다. 즉 모든 구성 요소 그룹이 있는 경우 마지막 구성 요소 그룹 뒤의 구분 기호는 생략됩니다. 

순서에 따른 구성 요소 그룹은 알파벳, 표의문자, 음성 기호 순서입니다.

첫 번째 구성 요소 그룹을 포함하여 모든 구성 요소 그룹이 없을 수도 있습니다. 

이 경우 사람의 이름은 하나 이상의 등호("=") 구분 기호로 시작할 수 있습니다.

내부에 NULL 구성 요소 그룹이 있는 경우 구분 기호가 필요합니다. 

가장 뒤의 구성 요소 그룹이 NULL인 경우 구분 기호는 생략될 수 있습니다.

정확한 의미는 각 구성 요소 그룹에 정의되어 있습니다. 섹션 6.2.1.2를 참고하시기 바랍니다.

예제 및 참고사항은 섹션 6.2.1.1을 참고하시기 바랍니다.

6.2.1.1 Examples of PN VR and Notes

Rev. John Robert Quincy Adams, B.A. M.Div. ⇒ Adams^John Robert Quincy^^Rev.^B.A. M.Div.

성 1개, 이름 3개, 중간 이름 0개, 접두사 1개, 접미사 2개

Susan Morrison-Jones, Ph.D., Chief Executive Officer ⇒ Morrison-Jones^Susan^^^Ph.D., Chief Executive Officer

성 2개, 이름 1개, 중간 이름 0개, 접두사 0개, 접미사 2개

John Doe ⇒ Doe^John

성 1개, 이름 1개, 중간 이름, 접두사, 접미사 0개(모든 후행 구성요소가 NULL이므로 구분 기호 생략)

Smith^Fluffy

책임자의 성이 Smith, 이름이 Fluffy인 고양이

ABC Farms^Running on Water

ABC Farms 소속의 이름이 Running on Water인 말

Fatal error C1083 포함 파일을 열 수 없습니다. 'ctype.h': No such file or directory / Cannot open include file: 'ctype.h': No such file or directory 에러가 발생했을 때 해결 방법에 대해 알아봅니다.

1. 현상

최근 C++ 프로젝트에서 curl을 사용할 일이 생겨 소스코드를 받아 빌드를 시도했습니다.

한 번에 성공하면 좋았으나 위와 같은 에러가 발생했습니다.

2. 해결

에러 로그를 가만 보고 있자니 왜인지 "windows kit 8.1"이 눈에 들어옵니다. 프로젝트 -> 속성 -> 일반으로 이동해 Windows SDK 버전을 변경해 줍시다.

대상 프로젝트는 VisualStudio 2017에서 사용하므로 SDK 버전을 10.0.17134.0으로 변경해줬습니다.

이제 다시 빌드하면 정상적으로 빌드가 되는 것을 확인할 수 있습니다.

0. 앞선 글.

사무실에서 5년간 애지중지 쓰던 무접점 키보드가 마침내 돌아가셨습니다. 완전 먹통은 아니고 사용하면서 불편함이 좀 있는 정돈데 오래 쓸 만큼 썼고 새로운 키보드도 써보고 싶고 해서 이 기회에 바꾸기로 하였습니다.

사실 이전에 산 키크론 K8 키보드를 회사에 가져가서 사용하려고 했습니다만 소음도 소음이고 무엇보다 어쩔 수 없는 블루투스의 키 씹힘 현상 때문에 포기하고 다른 키보드를 알아보게 되었습니다. 

참고 글: 2020.12.16 - [Trunk] - Keychron K8 - 키크론 K8 텐키리스 87키 구매 후기.

1. 왜 이 키보드를 고르게 되었나?

사실 가장 먼저 구매하고자 했던 키보드는 싱크웨이 토체티 K320w가 아니었습니다. 가장 처음 생각했던 건 리얼포스 무접점이었습니다. 5년 정도 한 키보드를 쓰다 보니 가격은 그리 큰 문제가 아니었어요.

오히려 수년간 같은 키보드를 쓰면서 느껴지는 단조로움이 문제였습니다. 이 전 키보드도 무접점이었고 밋밋한 디자인에 투박한 색... 키캡을 바꾸려 해도 그놈의 스테빌라이저때문에 바꿀 수 가없었습니다. 

그래서 다음으로 찾아본 게 저소음 적축 키보드였습니다. 기존 들고 있던 키크론이 옵티컬 적축이었는데 이게 생각보다 소음이 심해 사무실에선 쓸 수 없을 정도였습니다. 저소음 적축으로 찾아본 게 바밀로 키보드였습니다.

문젠 이 브랜드는 진짜 인기가 많아서 그런 건지 애초에 물량이 적어서 그런 건지 한번 발매 주기를 놓치면 매물이 없어요... 6월 말부터 2주는 기다렸는데 다 품절이랍니다. 7월 초에 공지가 나왔는데 7월 말은 지나야 매물이 들어온답니다.

그리고 바밀로 저소음 적축 키보드의 가장 거슬렸던 점이 USB 연결 방식입니다. 한참 전에 발매된 Anne Pro 2도 C타입을 지원하는데 얘네 모델은 PRO 타입의 키배열을 제외하고는 아직도 USB Mini-B만을 지원합니다. 당연히 블루투스 같은 거도 지원을 안 합니다.

마지막으로 돌고 돌아 씽크웨이 토체티 BW D&T 콜라보 K320w 모델을 찾게 됩니다.

기다려서라도 바밀로 저소음 적축 모델을 사려고 했다가 마음이 틀어진 결정적 이유는 블루투스와 리시버를 통한 무선과 유선을 모두 지원한다는 점이 가장 크게 작용했습니다. 정방향 체리 스위치라 키캡을 변경하기에도 용이합니다.

현재 사무실에선 테스트용 서버, 개발용 노트북, 개인 아이패드를 사용하고 있습니다. 서버는 노트북으로 원격 접속이라도 하지만 아이패드는 블루투스를 지원하지 않으면 정말 불편해집니다. 무선 키보드를 따로 들고 다닐 수도 없고 그렇다고 매직 키보드를 위해 45만 원을 태우는 건 아까웠으니까요.

결국 저소음 적축 체리 스위치에 블루투스, 무선, 유선 동시 지원이 제게는 가장 큰 장점으로 다가와 이 키보드를 선택하게 되었습니다.

2. 개봉기

개봉전에 직접 구매한 영수증 먼저 올리고 들어갑니다.

처음 택배 상자를 받았을 때 뭔가 잘못 온 줄 알았습니다. 그동안 받은 키보드 택배 상자의 사이즈가 아니었어요. 

배송 박스를 뜯자 그 안에 에어캡으로 감싸진 키보드와 팜레스트가 들어있었습니다.

팜레스트는 지금 행사 중으로 구매한 모든 분들에게 무료로 나눠주고 있다고 합니다.

내부 구성품은 다음과 같았습니다.

케이블, 추가 키캡, 리시버, 리시버용 젠더, 케이블 등등이 들어있었습니다. 공식 구성품은 다음과 같습니다.

비교해보니 모든 구성품이 다 들어있는 것을 확인할 수 있었습니다. 여기에 이것 말고도 플라스틱 커버가 동봉되어있습니다.

3. 장점.

우선 장점부터 나열해 보도록 하겠습니다. 우선 블루투스와 무선의 동시 사용성입니다. 

사용하자마자 바로 와닿은 장점입니다. 기존 타 키보드는 유선과 블루투스만을 지원해 여러 기기에서 동시에 사용할 때 어느 정도 귀찮은 부분이 있었습니다. 블루투스의 키 씹힘이나 지연을 피하기 위해 보통 메인 컴퓨터에는 유선으로 연결해 사용합니다. 다른 기기에서 사용하기 위해 블루투스를 연결하려면 일반적으로 유선 모드에서 무선 모드로 스위치를 바꾸고 블루투스 페어링을 시도해 연결을 기다려야 했습니다. 

유선/블루투스 전환 스위치가 키보드 뒤편에 있는 경우도 흔해 사용하다 키보드를 뒤집고 스위치를 바꾸고 다시 블루투스로 기기에 연결해야 하는 다소 귀찮은 과정이 필요했습니다. 특히 스위칭이 잦으면 더욱 짜증 나게 됩니다.

씽크웨이 토체티 K320w는 리시버를 통한 무선 연결을 지원해 굳이 유선 연결을 고집할 필요가 없어졌습니다. 스위치를 켜고 메인 컴퓨터에는 리시버를 통해 키 씹힘이나 지연 없이 사용하다 스위칭이 필요하면 바로 블루투스로 전환해 사용할 수 있게 되었습니다.

다음 장점은 소음과 통울림입니다. 유명한 저소음 적축 스위치답게 스위치 소음과 통울림은 확실히 줄어들었습니다.

이전에 사용하던 무접점이나 같은 사무실 직원의 멤브레인 키보드보다 소음이 더 작습니다. 확실히 체감할 수 있을 정도로 소음이 줄어들어 상당히 만족하며 사용하고 있습니다.

소개글에 적힌 흡음재가 진짜 효과를 발휘하는 것인지 통울림도 없습니다. 개발하다 보면 무의식적으로 엔터, 스페이스, ESC를 힘껏 누르다 못해 때리게 되는데 통울림이 전혀 발생하지 않습니다. 예전에 사용했던 AnnePro2는 뭐만 해도 울리는 거 같아 굉장히 거슬렸는데 확실히 스위치에 의한 소음과 통울림이 없어 사무실에서 사용하기 좋습니다.

다음은 전용 지원 소프트웨어입니다. 

듀가드에서 제공해주는 전용 지원 소프트웨어인 제우스를 사용할 수 있습니다. 스크린샷에서 볼 수 있듯이 매크로, 키 변경, 키 조합, 멀티미디어, 프로그램 실행뿐 아니라 마우스의 기능도 사용할 수 있습니다.

공식 홈페이지에서는 0.99 버전을 제공하고 있으며 해당 버전에서는 영문과 중문만 지원되지만 업데이트를 통해 한국어도 지원하고 있습니다.

4. 단점

키캡 품질에 비해 각인이 진짜 최악입니다. 도대체 왜 이런 색으로 각인을 했는지 모르겠어요 

대체 왜 이런 식으로 각인을 한 건지 의아할 뿐입니다. 영문만 있으면 차라리 나을 뻔했는데 민트색으로 한글 각인이 섞여 들어가 있으니까 너무 안 어울립니다. 키보드 색상의 테마가 "웜톤 베이지"인데 민트색이 이 테마에 왜 어울린다고 생각한 걸까요?

그리고 스페이스에 저 각인도 맘에 안 들긴 마찬가집니다. 

차라리 하우징에 각인되어 있는 콜라보 문양을 검은색으로 각인했으면 훨씬 좋았을 뻔했습니다. 저처럼 애초에 키캡질 할 생각이 있으신 분들은 모르겠지만 키보드 각인이 거슬리면 이게 은근 눈에 띄어서 짜증이 납니다.

게다가 구매 옵션에서 키보드 스위치만 옵션으로 고를 수 있었고 키캡 옵션은 고를 수 없었던 게 아쉬운 점으로 남았습니다. 가능하면 영문 각인이나 측각으로 바꿨을 텐데...

배터리 용량도 아쉬운 점으로 꼽혔습니다

1200mAh라는 용량이 진짜 큰 건지 작은 건지 절대적으로 판단할 순 없어 결국 다른 제품과 비교를 하게 됩니다. 이전에 사용했었던 키크론 K8과 비교를 해보자면 K8은 배터리 용량이 무려 4000mAh였습니다. 이 제품과 비교하면 3배가 넘는 배터리 용량을 탑재하고 있습니다.

심지어 포커 배열이라 이보다 더 작은 Anne Pro 2도 1900mAh의 배터리 용량을 갖습니다. AnnePro2는 더 적은 키배열이라 사이즈도 작았는데 1.5배 이상의 용량을 탑재하고 있으니 이게 안 아쉬울 수가 없습니다.

물론 키크론 K8과 AnnePro2는 LED 모델이므로 실 사용시간은 다르게 느껴질 수 있습니다만 그래도 배터리 용량만 두고 비교해본다면 아쉬운 건 사실입니다.

그 외 기타 구성품에 대한 아쉬움이 살짝 있습니다. 이 부분은 키보드 본체에 대한 아쉬움이 아니기 때문에 개인적인 불평으로 생각하고 넘어가셔도 좋습니다.

하나는 팜 레스트의 품질입니다. 이게 제 제품이 불량인지 원래 이런 건진 모르겠는데 일단 손바닥을 올려두면 내부 젤과 손바닥이 닿는 마감재 사이에 공기층이 발생합니다. 이로 인해 손바닥이 없는 팜레스트 가운데 부분이 부풀어 오르는 현상이 있습니다.

그리고 팜 레스트 디자인을 잘 보면 키보드와 닿아있는 부분도 곡선형 디자인으로 되어 있는데 이 때문인지 키보드와 팜 레스트 사이에 틈이 발생합니다. 가운데는 괜찮지만 양 끝은 확실히 떨어져 있습니다. 다만 애초에 하우징이 그리 높지 않고 키캡 프로파일도 체리 프로파일이라 팜 레스트 없이도 무난하게 사용할 순 있습니다.

또 다른 하나는 키캡 리무버입니다. 동봉된 키캡 리무버가 키캡이랑 안 맞아요. 다른 리무버는 키캡과 수평으로 넣어서 키캡을 제거하곤 했는데 동봉된 키캡 리무버는 수평으로 넣으면 키캡이 더 커서 들어가지 않습니다. 애초에 노린 설계라면 할 말은 없습니다만 키캡을 제거하기 위해선 키캡에 사선으로 리무버를 넣어서 키캡을 제거해야 합니다.

마지막은 리시버 젠더와 리시버입니다. "웜톤 베이지"인데 검은색이에요. 별거 아니긴 한데 그냥 아쉬워서요. 색상을 맞춰줬으면 하는 아쉬움이었습니다.

5. 총평 및 마무리

기능적으론 훌륭했으나 디자인이 살짝 아쉬운 키보드였습니다. 

특히 여러 기기를 동시에 사용하고 유선/블루투스 전환에 귀찮음을 느끼셨다면 씽크웨이 토체티 K320w는 좋은 선택이 될 것입니다. 하지만 하나의 기기만을 사용한다고 유선으로 키보드를 사용한다면 매력적이지 않을 수 있습니다. 

디자인은 개인마다 느끼는 게 다르기 때문에 더 평가할 수 없습니다. 다만 제 의견으론 아쉬운 점이 있으며 전 사용하면서 100% 키캡은 바꿔 쓸듯 합니다.

아직 오랜 기간 사용한 키보드가 아닌 데다 리뷰는 개인의 주관이 들어가기 때문에 사용자별로 느끼는 점이 다를 수밖에 없습니다. 특히 자신이 어떤 기능이 꼭 필요했는지에 대한 기준이 다르기 때문에 더더욱 그렇습니다. 

이 글이 키보드를 구매하시는데 조금이라도 도움이 되셨길 바랍니다.

PowerShell을 통해 Yarn을 수행할 때 발생하는 보안 오류를 해결하는 방법에 대해 알아봅니다.

1. 현상

Windows 환경에서 PowerShell을 통해 Yarn을 설치했습니다.

> npm install --global yarn

이후 설치 확인을 위해 yarn 명령을 수행하려 하면 보안 오류가 발생합니다.

> yarn --version

2. 수정

PowerShell의 실행 정책이 "Restricted"로 설정되어 있어서 발생하는 문제입니다. "Unrestricted"로 변경해 줍시다.

우선 PowerShell을 관리자 권한으로 실행시킨 뒤 다음 명령어를 수행합니다.

> Set-ExecutionPolicy Unrestricted

이후 변경된 내용을 확인하기 위해 다음 명령어를 수행해 봅니다.

> ExecutionPolicy

정상적으로 "Unrestricted"로 변경된 것을 확인할 수 있습니다.

3. 확인

이제 다시 PowerShell로 Yarn명령어를 수행해 봅시다.

이제 정상적으로 수행되는 것을 확인할 수 있습니다.

Referenced: [PowerShell] PSSecurityException : UnauthorizedAccess

C#에서 Hostname을 사용해 IP주소를 가져오는 방법에 대해 알아봅니다.

string hostname = "smoh-dev";
IPAddress[] listIPAddress = Dns.GetHostAddresses(hostname);
IPAddress[] listIPV4 = listIPAddress.Where(x=>x.AddressFamily == System.Net.Sockets.AddressFamily.InterNetwork).ToArray();
Console.WriteLine($"Input Hostname: {hostname}");
Console.WriteLine($"IP Address: {listIPAddress[0]}");

소스코드는 간단합니다. Hostname을 입력받고 Hostname의 모든 IP 주소를 가져옵니다. 그 후 Linq를 이용해 가져온 IP중에서 IPv4 주소만 찾아옵니다. 

마지막으로 찾은 IPv4 주소중 첫번째 항목을 출력합니다. 위 코드를 실행하면 다음과 같은 결과를 얻을 수 있습니다.

해당 소스코드는 다음 링크에서도 확인할 수 있습니다: smoh-tistory/GetIpByHostname

Windows에서 PuTTY를 사용해 AWS EC2 인스턴스에 원격 접속하는 방법에 대해 알아봅니다.

0. 사전 준비

PuTTY를 설치해 둡니다. 미리 EC2 인스턴스 생성에 사용한 키 파일을 준비해 둡니다.

1. PuTTYgen을 사용하여 프라이빗 키 변환

PuTTY에서는 SSH 키의 프라이빗 키 형식을 기본적으로 지원하지 않습니다. PuTTY에는 PuTTYgen이라는 도구가 있는데, 이 도구는 키를 필요한 PuTTY Private Key 형식으로 변환할 수 있습니다. PuTTY를 사용하여 인스턴스에 연결하려면 .pem 키 파일을 .ppk 키 파일로 변환해야 합니다.

먼저 PuTTYgen을 실행해 Parameters의 Type of key to generate에서 RSA를 선택해 줍니다.

Actions의 Load an existing private key file에서 Load 버튼을 클릭해 .pem 키 파일을 로드합니다.

로드 시 파일 확장자 필터를 All files로 해야 .pem 파일이 보입니다. 성공적으로 로드되면 다음과 같은 창이 보입니다.

이제 Save the genereated key의 Save private key 버튼을 클릭해 .ppk 키 파일을 저장합니다.

PuTTYgen에서 암호 없이 키 저장에 대한 경고가 표시되지만 예를 클릭해 키 파일을 저장해줍니다. 이름은 혼동을 방지하기 위해 .pem 파일과 같게 지어줬습니다. 이제 .ppk 키 파일이 준비되었습니다.

2. PuTTY를 이용해 EC2 인스턴스에 접속.

PuTTY를 실행한 뒤 HostName에 EC2 인스턴스의 퍼블릭 DNS를 입력합니다. EC2 인스턴스의 퍼블릭 DNS는 AWS EC2 콘솔로 이동해 우측 상단의 연결 버튼을 클릭하면 SSH 클라이언트 탭에서 확인할 수 있습니다.

HostName을 입력한 뒤 Port가 22인지 확인하세요. 이제 앞서 생성한 .ppk 키 파일을 불러올 차례입니다.

좌측 Cetegory에서 Connection -> SSH -> Auth로 이동합니다. Authentication parameters의 Private key file for authentication에 있는 Browse 버튼을 클릭해 생성한 .ppk 파일을 불러옵니다.

이 연결을 계속해서 사용하려면 Session으로 이동해 설정을 저장해 두는게 좋습니다. 이제 Open 버튼을 클릭해 EC2 인스턴스에 접속해 봅시다.

정상적으로 접속이 되는것을 확인할 수 있습니다.