Lenovo ThinkPad E14 AMD 모델 리뷰

좀 오래되었지만 잘 쓰던 랩탑을 홈서버로 전용하게되었다. 홈서버로 쓰고있던 더 오래된 랩탑이 아주 고장났기때문이다.

쓰던 랩탑도 사실 아주 불편하지 않은건 아니였기때문에 새 랩탑이 필요하기도 했다.

이번에 구매하기로 한것은 Lenovo ThinkPad E14 AMD 모델이다.

메모리 반도체 가격의 폭등으로 인해서 선택의 최우선 기준이 가격이 될 수 밖에 없었다. 120~140만원 정도의 가격에서 중간사양(i5 또는 Ultra 5, ryzen 5 등)의 CPU와 16GB이상의 메모리를 갖는 랩탑을 고를 수있는 브랜드는 거의 레노버 밖에 없었다. 그리고 지금 업무용 고사양 랩탑(고사양이래 봤자 Nvidia Geforce RTX 3070 maxQ 정도) ThinkPad 16P gen2 에 대한 만족도가 높기때문에 레노버를 우선 고려하기도 했다. 이걸 구매 할때만 해도 GPU가 장착된 모델도 140만원이면 충분했다. 지금은 140만원을 상한으로 잡으면 GPU 가 장착된 모델을 선택하는 것이 거의 불가능하다.

레노버 제품 중에서도 선택지는 Thinkpad E 시리즈, Thinkbook 시리즈, IdeaPad 시리즈로 선택지는 다양한 편이였지만, 랩탑을 보통 5년이상 사용하는 나로써는 Main stream 라인 보다는 끝줄에 턱걸이 하는거라도 High end flagship 라인을 선호한다. 이렇게 IdeaPad는 부담없이 보내주었다.

정통 ThinkPad의 설계는 적용하지 않고 이름과 몇가지 ThinkPad의 특징(주로 trackpoint 같은 입력장치)를 반영한 저가형 ThinkPad를 믿어보기로했다. 저가형이라고하는 해도 ThinkPad의 이름을 쓰고 있다.

각설하고 본론으로 넘어가도록하자.

1. 외관

(1) 디자인

사실 디자인 섹션을 써야되나 싶긴하다. 난 심미적 특징을 중요하게 여기긴 하지만 기준이 대중적인 편은 아니다.

일단 높게 평가하는 부분은 각진 윤곽선이다. 전체적으로 동글 동글 굴려놓은 디자인은 랩탑같은 크기가 큰 휴대용 전자제품에는 잘 어울리지 않는다. 개인적으로는 15인치보다 더 크다면 사실 어떤 디자인을 해놔도 휴대기기라고 생각하면 이상하다고 느껴진다.

리드가 닫힌 상태에서 위에서 촬영한 이 사진에서 보이는 라운드 처리는 대충 R=2mm 정도로 보인다. 스마트폰보다도 더 작은 곡률을 적용해서 각진 느낌이 살아있다. 디자인 요소는 깔끔하게 ThinkPad의 로고와 빨간색 강조로 절제되어있다. 카메라 모듈의 배치를 위해서 공간이 필요해서인지 돌출된 형상은 다소 아쉬운 부분이다. 두께방향 돌출은 디자인 요소로 더 활용하는 편이 나았겠다는 생각도 든다. 모듈의 크기로 인해 돌출되었다는 점까지 생각이 미치지 못한다면 이 돌출의 의미가 모호하게 느껴진다. 스마트폰 사용자 들이 카메라 모듈의 돌출이 미적으로 아름답지 못하다고 생각하는 것과 같은 맥락이다.

그리고 이 사진에서 윤곽선 밖으로 돌출된 모습도 보이는데 이부분은 개인적으로는 괜찮아 보인다. 뒤에 얘기 할거리지만 이 모델은 한손으로 리드를 열 수 없다. 이 돌출은 심미적으로 크게 거슬리지 않으면서 손잡이 역할을 하는 것으로 이해된다.

마찬가지로 리드가 닫힌 상태에서 정면에서 촬영한 이사진에서 보이는 선은 확실히 각진 느낌이다. 리드와 본체가 물리는 선이 직선으로 떨어져야하는데 조립상태가 불량한점은 아쉽다.

측면의 모습은 리드와 본체가 물리는 선이 더 직선으로 맞아 떨어져서 좋은 느낌을 준다. 개인적으로 과하다고 생각하는 HP랩탑의 동그란 디자인은 이 선이 마치 엉덩이 같은 선을 보여준다. 개인적으로 선호하지 않는다.

리드를 열었을 때, 화면과 배젤, 키패드와 트랙패드, 트랙포인트는 특별할 것 없는 Thinkpad의 모습이다. 트랙포인트를 위한 3개의 물리 버튼이 트랙패드 위쪽으로 배치된 것 또한 마찬가지이지만 심미적으로 우수 하다고 하기엔 어려워보인다. 또, 전원버튼(지문인식기를 겸하고 있는)이 키패드의 오른쪽이 따로 배치된 모습도 간결함을 해치기는 하지만 실수로 전원 버튼을 누르는 것을 확실하게 방지하고 있다.

배젤은 흔히 말하는 화면을 넓게 보이게 하려는 속임수(일명 구라베젤)는 아니다. 배젤과 화면 표시영역은 대충 1mm 미만의 틈만 있을 뿐이다. 그리고 상단의 카메라 모듈 돌출부는 간결함을 해치기는 하지만 저 돌출을 피하기 위해 배젤을 전체적으로 두껍게 설계했다면 아마도 둔해보였을거 같다.

(2) 마감과 세부형상

이 섹션은 사진 없이 간단하게 말 할 수 있다.

첫째, 가격대에 비해 준수한 마감을 보여준다. 표면의 질감은 부드러운 무광으로 통일감있는 모습을 보여주고 옵션사양인 알루미늄 하우징은 본체의 상판(키패드 주변부)에는 적용되지 않았다. 알루미늄 적용 부위의 질감이 더 고급스러운 점을 생각하면 아쉬운 부분이다. 손이 닿는 부분이기 때문에 플라스틱 재질이 주는 장점도 있다. 덜 차갑고 덜 뜨겁다.

둘째, 플라스틱 파츠의 사출 품질은 훌륭한 편에 가깝다. 육안으로 확인되는 흠결은 보이지 않고 배젤 부분만 손으로 만졌을 때, 약간의 울렁거림이 느껴진다. 손닿는 부분이 아니고 눈으로 보기에 문제가 없으므로 그냥 넘어가자.

셋째, 조립품질은 개인적으로 만족스럽지 않지만 어느 브랜드의 플래그십과 비교해도 부족하지 않다. macbook을 제외한 랩탐 중 좋은 마감품질로 유명한 dell의 xps 시리즈와 비교해도 크게 부족함이 없다. 앞에서 말한 리드와 본체의 맞물림이 좋지 않은 것은 내가 써본 모든 랩탑에서 보였던 점이고 랩탑의 한계로 인정하기로 했다. 다만 이 모델(ThinkPad E14)이 유독 심한 것 만은 분명하다.

마지막으로 두 가지는 부수적이지만 얘기 해볼만한 거리가 있다. 내가 사용해분 대부분의 랩탑에서 확인된 문제점이므로 비교삼아 적어본다.

본체의 뒤틀림은 모든 랩탭에서 보였던 문제이다. 평평한 편에 두고 네 모서리를 손가락으로 가볍게 두드려 보면 알 수 있다. 이 랩탑의 경우엔 왼쪽 아랫부분(AMD ryzen스티커)을 두드려 보면 고무발에 바닦에서 들떠있다는 걸 알 수 있다.(바닦이 완전이 평평하지 않을 수도 있으니까 봐준다…사실 여러 방향으로 돌려가면서 확인해봐도 똑같은걸 보면 본체가 살짝 뒤틀린게 맞다.) 이 문제는 XPS, Gram, ThinkBook에서 모두 확인된 부분이고 대부분 비슷한 수준(육안으로는 확인하기 어려움)이였지만 항상 손이 닿는 하단 부분이 들떠있어 덜그럭거림을 느낄때가 종종있다. 오히려 다른 flagship제품에 비해 thinkpad e14모델이 조금 덜한 편이다.

리드와 본체의 물림이 모서리 마춤 뿐만아니라 들뜸(먼저얘기한 뒤틀림과 같은 얘기)이 있다. 리드와 본체의 들뜸은 thinkpad 로고가 있는 면을 손가락으로 두드려 보면 다른 부분에 비해 덜 밀착된 것을 느낄 수 있다. 이 문제의 경우도 마찬가지로 xps, gram, Thinkbook에서 모두 확인된 부분이고 xps와 gram이 유독 심했고 thinkbook과 이모델(thinkpad E14)는 비교적 덜한다. 정도의 차이와 관계 없이 사용 중에 불편함을 느끼지는 않는 문제이다.

2. 내부

결론을 먼저 말하면 내가 써왔던 다른 어떤 랩탑보다 충실하고 확장성과 분해 조립 편의 성의 우수하다. thinkpad 모델의 특징이기도 하지만 일부 세대에서 on-board 메모리가 적용된 점과 가격을 고려하면 아주 매력적인 요소이다.

내부를 살펴보기 위해서 분해과정을 먼저 알아보자. 하부면을 살펴보면 총 7개의 스크류가 있고 모두 caped 스크류라서 완전히 풀어도 하판으로 부터 분리되지 않아 스크류 분실 염려가 없다.

하판을 분해하기전에 어뎁터가 연결되지 않은 상태에서 bios에 진입해서(lenovo 로고 뜰때 F1버튼) config-power-disable built-in batter를 선택해서 내부 작업 중 short를 방지하자.(이런 기능을 제공하는 점이 우수하다는 평에 큰 영향을 주었다.) 이 기능이 제공되지 않는 다른 랩탑은 하판 분해 직후 메인보드와 베터리를 연결하는 커넥터를 분리해야한다.

스크류를 모두 풀고 나면 remover(일명 헤라)를 이용해서 하판과 본체사이의 클립을 풀어야한다. 상당히 견고하게 체결되어있어 내가 가지고 있는 플라스틱 remover나 신용카드로는 풀리지 않았고 매끄럽고 얇은 금속 remover를 사용해야했다. 처음 1~2개의 클립이 풀려서 틈이 생기면 플라스틱 remover나 신용카드를 사용하도록하자.

모두 제거하거 보면 모든 클립은 동일한 형태이므로 클립의 제거 순서는 중요하지 않았다. thinkbook 16P gen2모델의 경우 하단에 클립이 아닌 후크가 적용되어있어 다른 클립이 제거되지 않은 상태에서 하단부를 벌리려고 하면 후크가 파손될 수있는 것이 비해서 분해 난이도가 낮다. 처음에 remove를 밀어 넣기 쉬운 흰지 부분 부터 시작하는게 좋다.(lenovo공식 영상에서도 그렇게 한다.)

한가지 고려할점은 RJ45 이더넷 포트가 걸리기때문에 remover를 시계 방향으로 한번에 밀어 내야한다. 보통하듯이 시계방향으로 절반, 다시 반시계방향으로 절반으로 나눠서 작업하려고 보면 이더넷 포트가 걸린다.

외관에서 설명한것처럼 본체의 상부 하우징은 모두 플라스틱으로 보인다. 일단 여기까지만 확인했을때 테이프나 접착제로 조립된 부분 없이 모두 스크류를 제거하면 바로 분해가 가능해 보인다.(배터리는 확실치 않다. gram의 경우 스크류가 있었지만 배터리 아래로 테이프가 부탁되어있었다.)

사용자가 부품을 변경하거나 확장을 위해 사용할 수있는 슬롯은 아래와 같다.

  • SODIMM(메모리): 2개의 슬롯이 있고 옵션에 따라 1개 또는 2개 메모리 모듈이 설치된다.
  • M.2(2230): 무선랜 모듈이 설치되어있다.
  • M.2(2242): 기본 공장출고 SSD(nvme)는 여기에 장치 되어있다.
  • M.2(2280): 빈슬롯으로 출고되고 추가의 SSD를 장착 할 수 있다.

그밖에 모듈은 메인보드에 통합되어있어 수리 관점에서는 완벽하지 않지만 사용자가 업그래이드 할 수있는 모듈은 모두 분리될 수 있도록 설계되어있다.

하판은 알루미늄 하우징 옵션을 선택 해서 알루미늄이 적용되었지만 CNC 가공품은 아니고 프래스성형 부품으로 보인다. 클립과 같은 체결 부붐들은 플라스특 파트를 부착한 형태로 제작되어있다.

SSD에는 써멀패드가 적용되었고 CPU 냉각팬부분에는 스크린 필터가 적용되어있다. louver 플래이트 전체에 스크린 필터를 적용해도 좋았을거 같은데 소소한 원가 절감인지 환기성을 위한 설계인지 모르겠다. 아무튼 가격대에 비해서 세심한 설계라고 해도 될거 같다.

내부 구성에 대한 총평은 처음 시작한 말과 같다. 충실하고 우수하다.

3. 사용성

(1) 휴대성

15인치 미만의 랩탑 대부분은 크기의 관점에서는 휴대성에 문제가 없다. 일반적인 가방에 수납하는데 문제되지 않는다. ThinkPad E14 gen7은 조금 두껍기는 하다. 아마 얇은 가방을 이용한다면 다른 소품을 휴대하기엔 어려울 수 있다.

무게는 공식홈페이지와 리셀러의 제품 소개 페이지에 1.4kg으로 설명하고 있지만 알루미늄 하우징 옵션을 선택하고 64wh 베터리를 적용한 내 thinkPad는 체감상 1.5kg은 넘는 듯하다.(저울이 없어서 실제 중량은 모르겠다.) 아무튼 무겁다는 말을 하고 싶은거다.

(2) 편의성

리드는 한손으로 열수없다. 힌지가 생각보다 뻑뻑해서 한손으로 리드를 올리면 본체가 딸려올라온다. 레노버 제품은 thinkbook과 이번 thinkpad를 사용중인데 모두 그런거 같다. 더 가벼운 LG gram도 한손으로 열린다는걸 생각하면 아쉬운 부분이다. Gram의 경우엔 타이핑 중 디스플레이가 많이 흔들리는게 느껴지는 편이고 thinkPad는 그런 점에서는 만족스럽다.

(3) 포트

충전 어댑터는 USB-C PD 규격을 만족하므로 다양한 선택지를 제공한다. 또 USB-A 포트 1개는 상시 전원을 제공하므로 보조배터리로 활용가능하다. 3.5mm 스테레오 오디오 단자를 제공하고 있지만 현재 시점에서 필요한 포트인지는 모르겠다. 비슷한의문이 드는 RJ45 이더넷 포트가 제공되는데 흠…일단 많은 선택지를 주는것이라고 이해하자. 난 개인적으로 맘에 드는 부분이다. 가장 맘에 드는 포트는 full size HDMI인데 왜냐하면 최근 랩탑은 USB-C dp-alt 모드로 외부 디스플레이 포트로 퉁치는 경우가 있는데 이렇게되면 USB 포트 가용성은 감소하고, 대부분의 디스플레이 장치는 HDMI포트를 기본으로 하기때문에 USB-C to HDMI 어뎁터를 들고다녀야한다. 아무튼 ThinkPad E14 gen 7에서 가장 맘에드는 HDMI포트를 포함해서 다양한 연결 옵션은 준수함 이상이다.

우수하다., 훌륭하다., 라고 평하기엔 좀 아쉬운 점은 SD card 슬롯을 제공하지 않는 점이다. SD card는 디지털 카메라 사용자에겐 아직도 필수적인 매체이고 카메라 사용자가 아니라도 차량용 블랙박스나 네비게이션에도 SD card가 사용되고 있다. 아직 널리 쓰이고있는 SD card 슬롯이 제공되지 않는 점은 불만이다.

(3) 감각적 만족(타건감 등)

타건감, 디스플레이, 스피커 등 오감으로 느끼는 사용성을 주관적으로 얘기해보겠다.

타건감은 노트북의 얕은 스트로크를 감안해주면 아주 훌륭한 편이지만 나에겐 아직 불편하다. 사실 랩탑 키보드를 꽤 오랜시간 불만 없이 사용했던 경험이 있는 나로써는 당황스러울 만큼 불편하다. 타건감은 만족스러운데 아무래도 키간격이나 배치에 적응이 필요한거 같다. 다시 말하자면 타건감은 아주 만족스럽고 키의 크기나 간격, 배열 같은건 적응이 필요 할 것같다.

디스플레이는 내가 예민하지 않은 부분이다. 전체적으로 만족스럽고 색상표현이나 해상도 반응 모든 관점에서 평균이상인것 같다. 내가 예민하지 않은 요소임을 고려하더라도 특별한 불만은 없다는 점에서 평균에 못미치는 품질은 아닌 것 같다. 다만 어두운 환경에서 암부표현(검정색 표현)시 디스플레이 가장자리의 약간의 빛샘이 있지만 실사용에서 거슬리는 수준은 아니다. 아주 고가의 디스플레이를 사용해보지 않아서 맞는지는 모르겠지만 내가 경험한 모든 IPS 패널의 빛샘이 있었고 거의 숙명같은거다. 사진을 보면 왼쪽의 검정색 테스트 화면에서는 약간의 빗샘이 보인다.(반사때문에 잘 보일지는 모르겠지만 사진에 표현이 되긴했다.) 오른쪽 화면은 영화 재생중 한장면을 촬영한 사진이다. 실사용 조건에서 어두운화면을 어두운 공간에서 보는경우는 대부분 영화 감상일 것이다. 빛샘이 눈에 띄지는 않는다.

스피커는 조금 예민할 수도 있다. 주로 이어폰이나 헤드폰을 이용하기 때문에 랩탑의 스피커로 뭔가를 들을 일은 별로 없다. 그래도 굳이 들어보자면 음질은 좋은 편은 아니다 작은 유닛과 얇은 울림통(노트북 하우징)을 생각하면 특별할 것도 없는 일이다. 음량은 랩탑 바로 앞에서 듣기엔 충분한 수준이고 음량이 커지면 소리가 왜곡된듯 들린다. 간혹 저음부의 음량이 큰 경우엔 키패드에 울림이 전달되기도 해서 앞으로도 잘 안쓸거 같다. 마이크는 테스트해보지 않기로 했다. 지금 사용중인 fedora 리눅스에 기본 설치에 녹음 애플리케이션이 포함되지 않기때문이다. 사용할 계획이 없는 프로그램을 굳이 테스트 목적으로 설치할 생각이 없다. 나중에 화상회의를 하거나 한다면 그때 확인해보면 되겠다.

전원버튼 일단 좀 깊다. 사진으로 보니까 더 깊어 보인다. 버튼의 크기에 비해서 너무 깊어서 누르기 불편하고 심지어 딸깍 하고 누르면 되는게 아니라 적어도 0.2~0.5초 정도는 눌러줘야 동작한다. 아마도 실수로 누르는 것을 물리적으로 방지하려는 의도 같지만 깊은 깊이, 딜레이시간 이렇게 2중, 3중으로 해야될 정도의 문제인가 싶다. OS에서 전원버튼 동작을 설정 할 수도있는데..굳이 이렇게 물리적으로 다중의 보호를 해야될일은 아닌거 같다. 키보드 배열에서 분리해 별도로 배치한것으로 이미 충분하다.

물리적인 깊이로 인해 조금 걱정했던 것에 비하면 지문인식은 잘되는 편이다. 물론 깊이를 고려해서 내가 의식적으로 약간 손가락을 밀어 넣고 있어서 그런지도 모르겠다. 어째튼 지문인식만 본다면 크게 불편함은 없다.

트랙패드와 트랙포인트., 나는 랩탑이용시 특별한 경우(3D 모델을 취급할때,)가 아니면 마우스를 사용하지 않는다. 대부분 트랙패드를 사용하고 특별히 예민하게 굴지 않기때문에 트랙패드는 너무 좁지만 않다면 합격이다. thinkpad e14의 트랙 패드는 일단 합격선이다. 14인치급 랩탑에서 제공되는 대부분의 트랙 패드와 비슷한 면적이지만 조금더 넓었으면 좋겠다는 생각은 든다. 특히 상/하로는 트랙포인트의 물리버튼 때문에 약간 좁다는 느낌도 든다.

트랙포인트는 아무래도 쓸일이 없을것 같다. 적응의 문제겠지만 이미 익숙한 트랙패드가 있는데 굳이 익숙하지 않은 트랙포인트를 쓸이유는 없다.(왜 thinkpad를 산거냐?)
기본적으로 트랙포인트는 움직인 거리가 아니라 가해진 힘으로 커서를 움직이는 거라서 직관적이지 않다. 그리고 물리버튼과 조합해서 사용하는 방식은 한손 조작을 고려한 설계는 아닌 듯하다.

(4) 배터리 사용시간

이 부분은 실제 사용시간을 측정해보지는 않았다. 그냥 간단하게 내가 사용하는 환경을 기준으로 계산해보겠다. 난 64wh를 CTO사양을 선택하였고, Fedora KDE desktop 43을 사용하고있다. KDE Info center에서 에너지 섹션을 살펴보자. 추가로 나는 배터리 사용중에는 power profile을 절전으로 사용하도록 설정해두었다.

부팅을 하고 시스템이 로드 되기까지는 아주 잠깐이지만 10~20W정도의 전력소모를 보이고, 이 글을 쓰는 동안은 6~8W 정도의 전력소모를 보여준다. 이 값은 베터리 소모량으로 측정되는 값이므로 사용시간을 계산하기에 적절하다.

배터리 사용시간 계산 조건은 아래와 같다.

  • 배터리 충전 레벨 : 80%(배터리 성능 유지를 위해 80%로 제한된 충전을 하고있다.)
  • 배터리 하한 레벨 : 5%(이쯤에서는 그만 사용하거나 전원을 연결하기로 하자.)
  • 배터리 설계 용량 : 64Wh
  • 사용환경 : fedora kde desktop 43(kernel 6.19)
  • 사용 전력: 8w
C_{75\%} = 64Wh \times 75\% = 48Wh\\
T= C_{75\%} \div P_{consption}=48Wh \div 8W = 6 h

간단한 계산을 통해 최소 작업(블로그에 글쓰는 정도)로는 6시간정도 사용할 수 있는 것을 알 수 있었다. 이정도면 한편의 포스팅을 마무리 하기에 충분한 시간일거 같다. 포스팅을 위한 자료가 모두 준비가 되었다면 3시간, 어쩌면 4시간 정도면 포스팅에 충분할 것이다. 이제 잠깐 글쓰기를 멈추고 window VM을 실행해서 잠깐 출장비 지급신청을 하고 돌아와 보자.

오후 3시 30분 부터가 VM 작동시간이다. 눈대중으로 평균을 내보면 20W쯤 될것같다. 같은 방식으로 계산하면 VM을 사용하는 경우 배터리 작동시간은 2시간 20분 정도 된다. VM에도 뭔가 전원관리 설정이 필요한지는 모르겠지만 업무환경은 되도록 업무용으로 준비한 다른 PC 또는 랩탑을 사용해야겠다.

한국에서 컴퓨터를 사용하는 사람은 hwp와 일부 그룹웨어(나같은 경우는 카카오워크)가 윈도우에 의존하는 환경이므로 window VM이 필수적이다. 이런 상황에서 굳이 리눅스를 고집할 이유는 없지만 리눅스 OS로 부팅 했을때가 뭔가 더 신난다.

4. 성능

이미 출시된지 좀 지난 제품이라 충분한 성리뷰가 있다. 그래서 주로 개인적인 사용성에 관해서 이야기했던 것이다. 그렇다고 성능에 대해서 아주 이야기 하지 않고 넘어가기엔 좀 아쉽다.

간단하게 해외 벤치 마크를 참고하면서 마무리하겠다.

Notebookcheck.net의 리뷰 중 성능 섹션에서 발췌한 자료를 보면 같은 모델에 인텔의 고성능 모바일 CPU(ultra 7 255h)와 비교했을때 약 20% 정도의 성능 차이를 보인다. 첨부의 이미지에는 표시되지 않았지만 인텔의 저전력 CPU(ultra 5 225u)와 비교하면 비슷하거나 약간더 나은 성능을 보여준다.

물론 배터리 사용중 절전 프로파일을 사용한다면 이 내용은 별로 의미가 없긴하다.(절전 프로파일에서 성능을 밴치마킹하는 자료는 많지 않기도하고…)

이미지를 클릭하면 출처(notebookcheck.net)의 원문으로 연결된다.

5. 총평

아주가볍지는 않지만 준수한 성능이라 제법 좋은 선택이다. 메모리 가격이 너무 오른덕분에 32GB 메모리로 구성하려면 140만원 정도이지만, 현시점에서 다른 선택지도 별로 다르지 않다.

아쉬운 점도 있다. 가격대엔 어울릴지 모르지만 약간 애매한 빌드 품질, 저전력 디스플레이인 OLED디스플레이 선택불가(intel 버전에서는 선택가능하다.), 정평의 thinkpad 타건감이 아닌점……
아마도 키패드 분리를 위해서 메인보드를 들어내야하는 구성인 것으로 봐서는 널리 알려진 그 키보드는 아닌것 같다. 바로 직전 세대까지는 thinkpad T 시리즈 부터 적용되는 것과 동일한 키보드가 적용됐었는데 사실 가장 아쉬운 부분이다.

이 정도만 참아 준다면 오래 쓸만한 랩탑인거 같다.

홈서버 구축 1단계:: 인프라와 하드웨어

홈서버에서 서비스하는 애플리케이션들이 인터넷에서 서비스되기위한 기본적인 인프라를 점검해보고 홈서버를 구동할 하드웨어를 점검해보자.

1. 인터넷 인프라와 도메인네임

홈서버가 인터넷에 어떤 서비스를 공개하기 위해서 몇가지 인프라가 필요하다. 너무 당연하게도 홈서버가 인터넷에 연결되게 하는 인터넷 서비스가 필요하고, 홈서버의 접속 주소를 알려주는 DNS도 필요하다. 또, DNS가 내 홈서버의 주소를 도메인네임으로 알려주기 위해서 도메인네임도 필요하다.

(1) 인터넷 서비스: ISP

나의 경우, ISP는 KT이고 사용 중인 서비스는 100Mbps 짜리 같다. MB/s로 환산하면 12.5MB/s 이다. 예를 들어 블로그에 게시한 어떤 글이 이미지를 포함해서 5MB라면 이 글이 브라우저에 표시되기까지 최소 0.5초 정도 필요하다는 의미이다. 실제로 사용자는 서버와 직접 연결되는게 아니라 많은 단계를 거치기 때문에 더 많은 시간이 필요 할 수 있다. 다르게 말하면 서버가 이용하는 네트워크의 대역폭이 턱없이 부족하지 않다면 그렇게 중요하지 않을 수 있다는 의미이다.(다른 단계에서의 지연에 비하면 크지 않을 수 있다.)

또 내가 사용하는 ISP는 고정 IP를 할당하지 않는다. 즉 라우터(공유기)가 재시작 할 때 마다 이전에 사용하던 IP를 할당 받을 수도 있고, 새로운 IP를 할당 받을 수도 있다. 이런 경우 홈서버가 서비스하는 애플리케이션에 사용자가 원할하게 접속하도록 하려면 DDNS서비스가 필요하다.

(2) DNS와 도메인네임

홈서버에 IP로 접속 할 것이 아니라면 도메인네임과 IP를 매칭해주는 DNS서버가 필요하고, 당연히 도메인네임도 필요하다.
홈서버에 IP로 접속하기로 결정 했더라도 홈서버가 사용하는 공인IP가 고정IP가 아니라면 IP가 변경될 때 마다 이 IP를 사용자에게 알려줄 방안이 필요하다.(왠만하면 도메인네임을 하나 마련해서 DDNS 서비스를 사용하자)

내 홈서버의 이용자는 “오직 나 뿐이다.”라고 장담할 수 있다면 IP가 변경될 때 마다 나에게 이메일로 알려주게 해도 될 것이다.(bash 스크립트와 cron 등을 이용하면 어떻게든 될 것 같다. 하지만 나는 해보지 않았으므로… 여기에서 다루지는 않겠다.) 물론 이런 경우라도 nextcloud를 운영하겠다면 얘기는 달라진다 nextcloud는 설정파일에 접속주소를 명시하도록되어있으므로 IP가 변경될 때 마다 이 설정 파일을 변경하는 것까지 bash스트립트에 추가해두어야 할 것이다.(nextcloud 뿐만 아니라 접속주소를 명시하도록 하고 이 접속주소 외에 다른 주소로는 접속을 허용하지 않는 서비스라면 모두 해당된다.)

(3) DDNS 서비스

내 ISP가 제공하는 IP주소가 고정IP가 아니라면 거의 필수적이다. 새로운 IP가 할당되었을 때, 외부 사용자가 기존의 IP 주소로 접근 할 수 없기 때문이다. 이 문제를 해결하기 위해서 도메인네임을 설정하고 이 도메인네임이 가르키는 IP 주소를 새로운 IP 주소로 갱신해주는 서비스가 DDNS이다. 여기서 외부 사용자라는 것은 외부 네트워크에서 접근하는 나 자신도 포함하는 말이다. 쉽게 말하면 새로운 IP로 갱신 되었을 때 이 IP를 모르면 홈서버의 관리자인 나도 홈서버에 접근 할 수 없다는 의미이다.

내가 사용해본 DDNS 서비스는 duckdns.org와 개인 도메인을 사용한 cloudflare.com이다. 그 외의 후보로 Dynu.com, iptime.org가 있었다.

duckdns.org 를 처음 사용했었는데, 접속 안정성이 낮다는 커뮤니티 의견이 많은 편이고 실제로 경험해본 불편함으로는 인증서 챌린지당시에 duckdns.org 서버가 불안정했는지 인증서 발급이 계속 실패하여 매우 불편했다. 그래서 다른 대안으로 dnyu.com을 검토했지만 제공되는 도메인이 개인적으로 너무 안 예뻐서 포기했다.

뭐였길래 안예쁘다는거냐? 대충 이런거다. duckdns를 사용할때는 “오리라니..귀엽자나”라는 느낌이 있었는데. dynu에서 제공하는 도메인은 고르고 싶은게 전혀 없었다.

그래서 결국 도메인을 하나 구입해서 cloudflare.com의 dns를 사용하기로 했다. 무료 ddns에서 단순히 서브도메인(호스트) 레코드만 관리가능한 것과 달리 개인 도메인이므로 모든 레코드를 관리 할 수 있다.

ddns 서비스도메인 제공 형태IP 갱신비용 및 기타 제약
duckdns.org[개인 서브도메인].duckdns.orgAPI 제공
(caddy ddns 모듈 사용가능)
무료
계정 당 5개 도메인 사용가능
와일드카드 인증서 불가
dynu.com[개인 서브도메인].ddnsfree.com
외 13개
API 제공
(caddy ddns 모듈 사용가능)
무료
계정 당 4개 도메인 사용 가능
iptime.org[개인 서브도메인].iptime.org공유기에서 갱신
(caddy ddns 모듈 사용불가)
무료
공유기 당 1개 도메인 사용가능
와일드카드 인증서 불가
cloudflare.com[개인 서브도메인].[개인도메인].tldAPI 제공
(caddy ddns 모듈 사용가능)
무료(DDSN만)
개인 도메인 필수(도메인 별로 가격 다름)

이 후 이어질 “홈서버 구축 #단계”시리즈에서 개인도메인 + cloudflare.com 을 이용한 설정을 중심으로 설명하겠지만, 생각나는데로 duckduns.org로 설정하는 방법들도 설명하겠다. dynu.com또한 다른 점은 없다. 왜냐하면 DDNS갱신은 caddy라는 리버스프록시가 API를 이용해서 자동으로 할 것이기 때문이다. 이 API를 사용하기 위해서 보안토큰을 발급 받는 절차만 다를 뿐 나머지는 동일하다.

개인 도메인을 사용하는데 들어가는 비용은 어떤 도메인을 사용하는 지에 따라서 차이가 큰 편이다. 정확히는 최상위수준 도메인(TLD)에 따라 도메인 등록비용이 많이 차이 난다.

namecheap.com에서 검색해보면 가격을 확인해볼 수 있다. 연간 비용이므로 취미수준으로 지불가능한 비용범위에서 사용가능한 도메인들도 있다. (개인에 따라 그렇지 않을 수도 있지만.. 원화로 연간 1만원 이하로 이용가능한 도메인이 많다.)

도메인 등록 대행업체 별로도 가격차이가 있지만 유의미한 수준은 아닌 경우가 더 많다.
.com, .net, .org 와 같은 전통적인 일반목적 최상위 도메인을 사용하기로 했다면 cloudflare에서 직접등록해도된다. 물론 등록비용은 namecheap 보다는 조금 비싸다(2~3달러). 반면 갱신비용은 namecheap보다 저렴하거나 동일하다. 개인도메인을 사용하면서 비용 절감을 최우선으로 생각한다면 .xyz, .life 같은 신규 일반목적 최상위 도메인을 사용하는 편이 좋다(이때는 cloudflare 말고 다른 곳에서 도메인을 등록하고 클라우드플레어에 연결해야한다.).

나의 경우엔 전통적인 일반목적 최상위도메인 중 .net이 마음에 들었고 비용도 감수할만하다고 판단했다.
.com은 너무 비싸고, .org는 너무 기관이라는 느낌이 강했다.
.net도 전통적인 의미로는 네트워크 관련 기관이 사용하는 최상위 도메인이긴 하지만 이제 전통적인 의미로 사용되지는 않기 때문에 덜 부담스러웠다.
같은이유로 “.org도 괜찮지 않냐?”라고 한다면 org 자체가 organization의 머릿글자라서 여전히 부담스럽다.

2. 하드웨어

서버(홈서버)의 하드웨어라고 하면 보통 고사양의 장치를 상상할 것이다. 실제로 그런 면이 없지는 않다. 성능관점에서의 고사양이라기 보다는 안정성(사용성)관점에서 고사양이라면 충분히 고려해야 할 부분이긴 하다. 예를 들면 정정 웹페이지를 서비스하기위한 웹서비스라면 성능은 386 구닥다리 하드웨어라고 해도 문제가 안될지도 모른다.(극단적으로 그렇다는것이다. 실제로 문제가 없는지 확인해보지는 않았다.) 반면 안정성에 대해서라면 “24시간 365일 정지없이 서비스 할 수 있는가?”라는 관점에 주의 해야 한다. 이런 관점에서의 고사양이라는건 ECC/REG같은 하드웨어적인 오류수정 기능이 있다던가 하드웨어 확장시 시스템 재부팅이 필요없는 핫스왑 기능이 있다던가 하는 것이 중요할 것이다.

홈서버니까 안정성은 관리자가 주의를 기울이는 것, 수시간의 다운타임은 허용하는 것 정도로 타협하도록 하자. 24시간 365일 서비스 같은 목표는 엔터프라이즈 환경에서도 쉬운일이 아니다.(너무 욕심 내지 말자)

홈서버 구축 0단계“에서 서비스할 애플리케이션을 다 정했기 때문에 다시 논의하는게 바람직 할지 모르겠지만, 확장성 관점에서 성능과 하드웨어 자원에 여유를 검토할 필요도 있다.
예를 들면 plex같은 스트리밍 서비스를 운영할거라면 아마도 CPU에서 디코더와 엔코더를 지원하는 편이 훨씬 유리 할 것이다. 그리고 고용량의 동영상 파일을 저장하기에는 512GB 라는 저장공간도 충분하지 않을 수 있다.

일단 앞선 글에서 정해둔 서비스 범위에서 어떤 수준의 하드웨어가 좋을지에 대해서만 논의 해보자.

내가 사용하는 하드웨어는 아래와 같다.

  • 모델명 : LG gram(2017) 13ZD970-GX55K
  • CPU : i5 7200U (2core 4thread)
  • RAM : 16GB
  • Storage : 512GB (nvme SSD)
  • wifi support 5Ghz

라우터는 아래와 같다.

  • 모델명 : IPtime A21004NS
  • wifi support 5Ghz

자~ 보다시피 아주 오래되었고 지금으로써는 사무용으로도 겨우 쓸 수 있을까? 싶은 정도의 저사양이다. 어떻게 이것이 서버용으로 적합한가?

일단 오픈프로젝트와 넥스트클라우드는 개인사용목적이고 오직 블로그 서비스만 공개적으로 서비스 된다는 점을 생각해보자. 아래 결과는 전문적인 벤치마크는 아니다. 그냥 내가 블로그에 접속해서 새로고침 버튼을 반복적으로 눌렀을 때 서버의 CPU 사용률을 나타낸 것이다. 블로그 메인페이지를 새로고침할 때의 삐쭉삐죽한 그래프를 그냥 눈대중으로 평균을 내보자. 내눈에는 대충 15~20% 정도로 보인다.

그러면 이제 몇 가지 가정을 해보자 내가 블로그를 열심히 운영해서 일일 평균 방문자가 100명정도 되고, 이들이 주로 2시간 정도 범위에 걸쳐 접속하고 사용자 당 요청하는 페이지 뷰가 분 당 5회 정도라면 분 당 동시 요청은 최소5회에서 최대 10회 정도라고 가정 할 수 있다. 나 혼자 반복 요청했을 때 CPU 자원이 75~80% 정도 여유가 있으므로 그냥 산술적으로는 4~5배 정도의 여유가 있는것이고, 동시 요청 4~5건까지는 성능저하없이 처리 할 수 있을 것이다. 일일 평균방문자 100명 정도라면 약간의 성능저하가 있을 뿐 서비스를 제공하는 것 자체는 문제가 없을 가능성이 높다는 의미이다.(아마 페이지 반응속도가 좀 느려지겠지., 최악이라도 반응시간이 2배정도 길어지는 정도.)

내가 개인적으로 사용하는 서비스에 대한 점검은 오히려 간단하다. 실제로 의미가 있을지 모르는 가정 같은건 필요 없고 업로드/다운로드 중 페이지 갱신 실험까지 같이 해보면 될것이다. 실제로 내가 쓸 때 유발 할 최대 부하는 이정도 일것이 거의 확실하다. 물론 워드프레스 방문자에 의한 부하와 상호작용이 어떤 영향을 미칠지는 다른 관점에서 조사가 필요하다. 위의 그래프에서 네모 표시 해둔 오른쪽 3개를 살펴보자 마찬가지로 눈대중으로 대충 평균을 가늠해보면 내눈에는 한 30~50% 정도로 보인다. 동시접속 2~3명까지도 문제가 없고 나 혼자 쓴다면 워드프레스 서비스도 거의 정상적으로 유지될 것으로 생각된다.

객관적인 척 그래프 하나 던져 놓고 너무 제멋대로 해석한다고 생각되는가? 그래도 할 수 없다. 난 전문가가 아니니 할 수 있는 수준에서 평가해볼 수 밖에 없다. 도커의 자원 제한 기능을 이용해서 다양한 서비스 제공하는 환경에서 조금 더 안정적으로 서비스가 제공되도록 할 수는 있을 것이다. 그건 차후 생각해 보도록 하자.

3. 정리

네트워크 인프라 중 홈서버 운영에 가장 걸림돌은 내 공인 IP가 변경될 수 있다는 점이다. DDNS 서비스를 활용하면 해결할 수 있다. 비용이 들지 않는 옵션과 비용이 드는 옵션 모두 있다. 이 문제로 홈서버 운영을 주저 하지 말자.

네트워크 인프라 환경에서 두번째 걸림돌은 대역폭이다. 100Mbps짜리 회선이라면 좀 작게 느껴질 수 있다. 블로그 서비스라면 최적화 된 이미지를 사용하자 1개 포스팅 당 10장 정도 넣는다고 해도 페이지 트래픽이 10MB를 넘기지는 않을 것이다. 그렇다면 100Mbps가 결코 작은 대역폭이 아니다.(캐시서버 없이 5명의 동시 접속을 고려해도 대역폭 자체는 100Mbps정도면 1초 내에 콘텐츠를 전송 할 수 있다.)

하드웨어는 7세대 이상의 intel 저전력 프로세서 이상이라면 왠만한 서비스를 운영하는데 문제는 없을것이다. 오히려 100Mbps의 빈약한 네트워크를 가지고 있다면 이쪽이 더 문제일 확률이 높다. 잘 튜닝된 애플리케이션 환경이고 파일서버만 운영한다는 점을 고려해야겠지만 구형 synology NAS도 2core(2thread) 환경으로 구성되어있다. 더 좋은 하드웨어는 더 많은 확장성을 제공하겠지만 어떤 하드웨어를 가지고 있든지 지금 홈서버를 시작하는데 그것이 걸림돌이 될 가능성은 낮다.

홈서버는 완제품으로 제공되는 파일서버 머신(synology 등 유사 제품)과 달리 안정성과 관리 편의성의 관점에서 하드웨어와 소프트웨어 모두 약점을 가지고있다. 이점을 잊지 않는다면 홈서버를 시작할 준비가 된것이다.

개인적으로 홈서버로 왠만하면 하지 않았으면 하는 서비스가 있다.

  • NAS : 이건 홈서버로 서비스하더라도 왠만하면 완제품을 사용하자 백업관리 기능 등의 신뢰 수준이 다르다.
    하드웨어가 마련되어있어서 완제품을 구입하는 것이 중복투자라면 unraid같은 전용 소프트웨어를 사용하자.
    내가 넥스트클라우드를 운영하는 것은 실제 NAS로 사용하는 것이 아니라 실험적인 용도이다. 예를 들면 이 블로그에 올리는 글에 들어가는 도표들을 넥스트클라우드 화이트보드에서 그리고있다.
  • NAS 외의 어떤 서비스라도 홈서버로 서비스해도 된다고 본다. 홈서버 + NAS 환경을 구축하고 NAS에 홈서버를 자동으로 백업하는 스크립트를 운영한다면 홈서버라도 충분한 안정성을 갖추게된다.

홈서버가 조금더 홈랩스럽기를 원한다면 가급적 proxmox 같은 가상화 환경을 사용하도록하자. 실험적 시도 도중 홈서버가 망가질 가능성을 줄일 수 있고, 복구과정이 매우 신속하다. 이 내용은 더 나은 옵션이 있다는 것을 알리기 위해 적은 것이고 나는 적용하지 않았다.
나의 경우엔 proxmox 하이퍼바이저를 구동하는 자원조차 아끼고 싶을 만큼 저사양의 하드웨어라서 proxmox를 적용하지 않았다. 그리고 또 다른 이유는 실험적인 시도보다는 현재 운영 중인 서비스를 잘 활용하는 것을 주된 목표로 하고 있다. 물론 현재 운영 중인 서비스의 개선(성능이나 보안)을 위해서 실험적 시도를 하고 있고 서버를 망가트려서 처음부터 다시 세팅하기도했다.(proxmox 환경이였다면 좋았겠다는 생각도 했다.ㅠㅠ)

다시 정리하자면 홈서버에 관심이 있으면서 현재의 인프라와 하드웨어를 탓으로 주저하지 말자. 당신은 이미 충분한 인프라와 하드웨어를 갖추고 있는게 분명하다. 그럼에도 불구하고 망설여진다면, 당신은 타협해야할 것을 타협하지 못하고 있는 것이다. 더 나은 서비스를 위해서 타협하는 것은 나중에도 할 수 있다. 지금 가진 것으로 홈서버를 경험해보는 것은 그 나중의 타협을 위한 통찰을 제공할 것이다.

다음 글에서는 본격적인 실행을 다루어보자. debian 13 리눅스 운영체제를 설치하고 기본적인 설정을 해보자. 그리고 나와 같이 구형 랩탑을 하드웨어로 선택한 경우 해야하는 추가설정도 살펴보겠다.(이미 미완성의 글로 이 블로그에 포스팅되어 있긴하다.)

홈서버 구축 0단계 :: 목적과 구성

가볍게 생각나는 것들을 적는 것이 주 목적이지만 이 서버를 만지면서 내가 자꾸 헤매게 되어서 정리를 해보려고 한다.

1. 목적 설정

목적에 따라 구성이 달라질 수 밖에 없다. 그래서 내가 홈서버를 구축하기로 한 사고의 흐름(생각들)을 정리해본다.

취미와 가벼운 실사용

홈서버를 구축하고 운영하는 것은 리눅스 시스템을 만지는 것을 좋아하는 나에게는 괜찮은 취미 거리 중 하나 이다. 혼자 사용할 서비스지만 그룹웨어와 프로젝트매니지먼트 도구에 관심이 많은 나에게는 만지작거릴 재밌는 오픈소스 프로젝트들이 있다. 이런 오픈소스 프로젝트의 결과물을 서비스하고 이용하는 것도 재밌는 취미다.

서비스 목록

  • Nextcloud
    자세한 역사는 모른다. 다만 Owncloud에서 포크된 프로젝트로 오픈소스+무료로 제공되는 범위가 훨씬 넓고 애초에 구현된 기능의 범위 자체가 더 넓다. 아마 오픈소스 정책과 기능 구현 범위에 관한 의견이 불일치 해서 프로젝트가 분리된 것 같다.
  • Openproject
    프로젝트 관리 중 이슈 추적과 일정 계획 및 관리, 시간 및 비용 추적 기능이 편리하게 구현되었고 PM2 관리 방법론에 필요한 거의 모든 기능을 제공한다. Redmain에 플러그인을 추가하면 거의 동일하거나 더 나은 기능을 제공하지만 무료로 사용 가능한 Redmain과 무료 플러그인 만으로는 시각적으로 만족스러운 디자인을 볼 수 없다. 오픈프로젝트는 제법 예쁜 인터페이스를 제공한다.
  • WordPress
    CMS(컨텐츠 매니지먼트 시스템)이다. 주로 웹사이트, 블로그 제작에 사용되고 웹컨텐츠관리 분야에서는 압도적인 점유율을 자랑한다. 그만큼 큰 시장이기 때문에 유료 플러그인이 매우 다양하다. 그래서 잘 찾아보면 무료 내가 원하는 기능이 무료로 제공되는 플러그인을 찾아보기 쉽다.

관리는 편리해야 하지만 그 것을 위해서 너무 많은 노력이 들어가지 않아야지

중요한 이야기이다. 취미로 구축하고 운영하는 것이고 가볍게 사용하는 것이지만 어찌 됐든 사용하기로 한 이상 적절한 수준으로 관리해야 하고 그 과정이 편리해야 한다. 또 그 편리함을 구축하기 위해 들어가는 노력이 취미라고 할 만한 수준을 벗어 나는 것도 곤란하다.

관리에 필수적이거나 편리함을 위한 도구들

  • SSH
    일단 리눅스 서버라면 기본 중에 기본인 관리도구 이다. ssh프로토콜을 통해 리눅스의 CLI(shell)을 사용할 수 있다. 기본적이고 필수적이다. 편리하지 않을 수는 있지만 관리를 위해 필요한 모든 행동을 여기에서 할 수 있다.
  • Docker
    앞서 언급한 세가지 서비스를 리눅스 호스트에 직접 설치해서 운영하려면 상당한 기술과 트릭이 필요하다. 일단 넥스트클라우드가 문제인데, 이 녀석을 설치하려면 웹서버, PHP, MySQL(or MariaDB)를 먼저 설치해야 한다. 각각 설치하고 넥스트클라우드를 구동하는 것 자체가 꽤 기술을 필요로 하는 일이고 넥스트클라우드는 443포트 외의 다른 포트로 서비스 하는 것을 허용하지 않기 때문에 포트 관리에도 주의 해야 한다. 게다가 오픈프로젝트의 패키지 설치 스크립트는 웹서버(아파치) 설치를 포함하고 있다.(물론 제외하고 진행 할 수도 있지만……) 호스트 운영체제에서 온갖 충돌이 발생 할 수 있는 것들을 서버 관리자가 직접 고려해야 한다.
    도커시스템은 이런 불편함을 모두 해결해준다.
  • Portainer
    도커시스템을 웹기반 GUI로 접근하게 해준다. 이 녀석도 도커를 통해 설치한다. 보안 관점에서 고려할 점이 있지만 가볍게 사용하는 서비스를 구동하는 홈서버라는 관점에서 적당히 타협하자.
  • 그 밖에 몇 가지 도구들을 더 적용했지만 보안 강화를 위한 부분이다. 구상 부분에서 더 이야기 해보겠다.

2. 홈서버 구성

“서비스들과 도구들을 다 구성했는데 뭘 더 구성한다는 건가?”

구성 요소들만 주르륵 나열한다고 구성이 끝날 리가 없다. 일단 물리적인 구성도 고민해야 하고 네트워크 구조 정도는 구성이 되어야 실제 구축 작업을 시작할 수 있다. 물론 나는 이걸 다 하고 구축한 것이 아니라 구축한 결과물을 정리해서 적어두는 거다. 덕분이 많이 헤맸고, 어떤 이유로 든 다시 구축해야 하는 상황을 맞았을 때(실은 그게 어제 밤이다. 뭐가 꼬였는지 몇 시간 동안 헤맸지만 복구가 안됐다.), 헤매지 않기 위한 기록물이다.

물리적 구성, 네트워크(물리적인 부분 소프트웨어 적인 구조 등..), 보안, 백업시스템 이렇게 4~5개 관점에서 서버를 구성해보자.

(1) 물리적 구성

[하드웨어]

  • 모델명 : LG 올데이 그램(13Z970-GX55K, 2017)
  • CPU : intel i5-7200U(2core 4thread)
  • RAM : 16GB
  • Storage : 512GB(NVMe SSD)
  • Wifi

[물리적 네트워크]

네트워크는 도커 네트워크라는게 따로 있지만, 먼저 물리적 구성을 점검해보자. 경우에 따라서는 직접구성할 수도 있겠지만, 대부분의 가정에서는 인터넷 공급자 – 라우터(공유기) – {홈서버, PC, 휴대전화, …}과 같은 구성을 피할 수 없음으로 간단하게 점검만 해보도록한다.

대부분 가정에서는 아래 도표와 같은 네트워크 구성을 가지고 있을 것이다. 다른 점이 있다면 cloudflare proxy라는 부분인데 취미 수준의 서버관리자라면 보안관리에 대한 고민은 해본적도 없던가 아직 고민만 하고 있을 것이다. cloudflare의 무료 플랜 만으로도 취미수준의 서버관리자가 할 수 있는 어떤 것보다 훌륭한 보안 옵션을 제공한다(왠만하면 쓰도록 하자). 그렇다고 프록시를 거치도록 설정하는 것 만으로는 아무것도 하지 않은 것 보다 조금 나은 것에 불과하므로 보안조치에 대해서는 나중에 다시 살펴보도록 하자.

인터넷망과 라우터를 직접 연결한 선은 PC나 IPTV, 휴대전화 등이 사용하는 망을 의미한다. 별다른 이유가 없다면 이렇게 쓰면 된다. 이런 장치들은 인터넷 망으로부터 들어오는 요청을 처리하는 것이 아니므로 보안 상 문제 될 것이 없다. 물론 어떤 종류의 악의적인 조작이 없는 정상적인 장치 일 경우에 한정이다. 해킹 프로그램이 깔려있으면 별수 없지 않나.

본격적으로 점검할 부분은 오히려 간단하다. 위 도표와 같이 구성된 홈서버가 인터넷 망에 서비스 되도록 하기 위해 필수 조건은 단 하나이다. 바로 포트 포워딩이다. 인터넷 망의 모든 요청은 라우터가 수신한다. 라우터는 그 요청을 어디로 보내야될지 알지 못하므로 그냥 무시하게 된다. 포트포워딩은 라우터에게 1234라는 포트로 들어온 요청은 홈서버의 5678이라는 포트로 보내서 처리하라고 알려주는 것이다. 포트포워딩이 되어있고 도착 포트에 어떤 서비스가 존재한다면 이곳으로 전달된 요청은 서비스가 처리 하게된다. 이 서비스에 어떤 취약점이 있다면 공격자에게 노출되어있다는 의미다. 포트포워딩은 최소로만 하도록하자.

포트포워딩 이란?

아래 그림은 설명의 내용을 예시를 들어 도표로 나타낸 것이다. 서버에 서비스가 대기 중인 포트로 요청하더라도 포트포워딩 규칙에서 외부포트를 다른 포트로 지정해 두었다면 해당 요청은 무시된다. 당연한 얘기지만 내부 IP로 요청하게되면 그 요청은 도착 할 곳을 찾지 못한다.

정리하면 라우터가 가지고 있는 공인 IP로 포트포워딩 규칙에 정의된 외부 포트로 도착하는 요청은 규칙에 따라 “내부 IP:내부 포트”로 전달하게 된다.

홈서버의 내부 IP 고정하기

그러면 네트워크 구성도에 “홈서버 IP 고정”이라는 의미는 뭐냐?

가정과 같은 소규모 네트워크는 IP 자원 관리를 DHCP에 대충 맡겨둔다. 이렇게 하면 알아서 사용하지 않는 IP를 할당해주기 때문에 신경 쓸 것이 없기 때문이다. 즉 자동 할당이라는 건데, 공유기가 재시작하거나 홈서버가 재시작 할 때 마다 공유기가 매번 다른 IP 주소를 할당한다면 어떻게 되겠는가?

포트포워딩 규칙은 내부 IP를 반드시 지정해야 되는데 서버의 내부 IP가 계속 바뀌게 되므로 포트포워딩이 재대로 작동할 수 없다.
홈서버의 IP는 DHCP 서버에 항상 같은 IP를 할당하라고 미리 알려주거나 홈서버가 IP할당을 요청 할 때, 자동 할당이 아닌 정해진 IP를 요청하도록 해야 한다. 물론 전자가 훨씬 편하고 잘 작동한다. 후자의 경우는 홈서버가 재시작하는 사이 다른 장치가 홈서버의 IP를 먼저 할당 받으면 IP 충돌이 발생한다.

(2) 도커 네트워크 및 서비스 구성

도커는 넓은 의미의 가상화에 해당한다. 운영체제 커널은 호스트의 것을 공유(커널 수준의 처리를 호스트 커널에 호출한다는 의미)하지만 그 밖에 것들은 컨테이너라는 격리된 환경에서 작동한다.

격리는 조금 더 높은 수준의 보안과 관리상의 편리함을 제공한다. 파이썬을 사용해본 사람이라면 프로젝트 별로 다른 environment를 정의 해서 써봤을 것이다. 비슷한 개념으로 이해할 수 있다.

격리된 개별 컨테이너간의 통신을 위해서 도커는 가상 네트워크를 사용한다. 내가 구성한 서비스와 도커 네트워크를 도식화하면 아래의 그림과 같이 표현할 수 있다.

초록색 점선은 보안 터널이다. 물리적으로 패킷은 호스트 게이트웨이와 라우터를 거칠 수 밖에 없지만, 이 보안 터널을 통한 통신은 클라우드플레어 서버와 클라우드플레어 데몬(내 서버에서 실행)간의 통신이고 자세한 원리는 모르지만 라우터의 포트포워딩 없이 외부요청을 전달 할 수 있다. 암호화된 패킷을 이용하고 클라우드플레어 데몬이 내부에서 외부로 연결을 요청해서 일종의 터널의 만들고 그 터널을 통해서 통신하는 것으로 이해된다.(정확하지는 않지만…) 아무튼 보안을 위해서 공개된 포트가 아니라 암호화된 통신과 클라우드플레어가 제공하는 2단계 인증 등을 통해 보안 중요도가 높은 관리 도구들은 강화된 보안을 적용한 것이다. 뿐만 아니라 도커 네트워크 구성에서도 서비스 네트워크인 caddy_net과 관리자 네트워크인 admin_net으로 격리하였다.

(3) 보안을 위한 구성

네트워크와 도커 구성을 통해서 일정 수준의 보안을 달성할 수 있다.(앞서 설명한 것들..) 예를 들면 포트포워딩으로 노출 시키는 포트 수를 제한하고, 도커를 이용해 서비스와 호스트를 격리하는 것들이 보안 조치에 해당한다. 그리고 기본적으로 내가 구동하는 서비스들을 개발한 개발자들도 보안을 위한 많은 노력을 경주하고 있다.
하지만 아무리 홈서버라고 해도 이것 만으로는 충분하지 않다.

왜 그런지 생각해보자.

일단, 봇에 의한 무차별 공격에 대한 대책이 없다. 예를 들면 로그인 페이지에 관리자 ID로 무차별 패스워드 공격을 한다면 어떻게 될까? 예측하기 쉬운 비밀번호라면 오래지 않아 관리자 권한을 탈취 당할 것이다.
두번째로는 워드프레스에 댓글에 스팸공격에 대한 대책도 없다.
세번째로는 내가 서비스하는 앱의 개발자가 무차별 공격에 대한 방어 조치로 로그인 실패 시 계정이나 공격자 IP를 차단하도록 했다고 생각해보자. 그러면 무차별 공격에 의해 관리자 권한이 탈취되지 않더라도 내가 필요할 때 내 계정을 사용하지 못 할 수 있다.(오늘 아침 격은 일이다..-_-;;)
마지막 네번째로 일종의 무차별 공격인 DDos에 취약하다. 내가 운영하는 서비스 앱에 DDos 취약점이 있다면 단순히 부하를 증가시키는 요청을 반복하기만 해도 내 서버는 금새 다운될거다.(구형 랩탑을 활용한 빈약한 하드웨어라서 더 그렇다.)

그렇다면 서버 보안은 어떻게 할까?

일단 서버 보안의 개념을 살펴보자. 난 보안 전문가가 아니다. 그냥 홈서버를 구축하고 약 2~3주 운영하면서 필요한 보안 조치를 취하면서 생각해본 것들을 정리해서 글을 써보려고 한다.

[노출 면적과 심층보안]

노출 면적은 공격 가능한 요소가 얼마나 많은 지를 의미한다. 노출면적은 인터넷, 내부망, 도커네트워크, 애플리케이션(서비스 데몬 등) 등에 있을 수 있다. 하나씩 살펴보도록하자.

  • 인터넷 노출 면적
    공개된 IP의 갯수와 포트의 갯수가 노출 면적이다. 가능한 줄여보자.
  • 내부망 노출 면적
    내부망에 접속 할 수 있는 장치의 갯수가 노출면적이다. 공유기에 접속 비밀번호를 설정하자.
    그리고 내부 망에 접속한 장치가 서버에 접근 할 수 있다면 이것도 서버의 노출면적이다. 서버에 방화벽을 설치해서 내부 망 접속자도 접근하지 못하도록 하거나 호스트 OS가 노출하는 포트 수를 최소화 해야한다.
  • 도커 네트워크 노출 면적
    호스트 네트워크로 브릿지(포트포워딩과 유사한 개념)된 아이피와 포트의 갯수다. 이것도 가능한 줄여보자.
    또는 어떤 도커 네트워크에서 실행되는 컨테이너가 다른 도커 네트워크에 접근 하도록 허용한 갯수다. 이것도 줄여야 한다.
  • 애플리케이션 노출 면적
    서버에 구동되고 있는 모든 애플리케이션을 의미한다. 가능한 줄여보자.
    서버에 운영체제를 최소 구성으로 설치해야 한다.(KDE, Gnome, Cinamon 같은 GUI는 굳이 설치 하지 말자)

결론은 노출 면적은 가능한 줄여야 한다는 것이다. 그리고 가장 앞에 노출된 인터넷 뿐만 아니라 내부망, 도커내트워크, 애플리케이션 등 여러 단계에 걸친 노출면적을 최소화하는 것은 일종의 심층방어의 개념이다.

[취약점 방어와 심층보안]

취약점은 운영체제나 애플리케이션이 의도하지 않은 동작을 하는 것을 말한다. 이 의도하지 않는 동작은 운영체제 또는 애플리케이션의 관리자 권한을 탈취하는 결과로 이어질 수 있다. 운영체제나 애플리케이션이 자체적으로 가지고 있는 취약점이라는 것인데 어떻게 방어 할 것인가?

두 가지 관점에서 생각해 볼 수 있다.

첫째, 운영체제와 내가 운영하는 서비스 애플리케이션의 최신화(보안업데이트 적용) 이다. 취약점 방어의 기본이자 가장 중요한 부분이다.

둘째, 운영체제와 서비스 애플리케이션을 격리하여 취약점으로 인한 보안 침해의 범위가 확대되지 않도록 해야한다. 기본적으로 도커와 같은 애플리케이션 격리도구를 사용하고 애플리케이션들이 운영체제의 관리자 권한으로 실행되지 않아야 한다. 취약점으로 인해 애플리케이션의 모든 권한이 탈취됐을 때, 그 애플리케이션이 운영체제의 관리자 권한으로 실행되고 있다면 운영체제의 관리자 권한도 위태롭게 된다. 이렇게 되면 애써 격리한 다른 애플리케이션이 서비스하고 있는 자료들 또한 위태롭게 된다.

최신화와 같은 기본적은 방어에 애플리케이션 격리까지 적용하는 것이 취약점 방어에서 심층방어이다.

[무차별 공격 방어와 심층보안]

  • 충분히 길고 예측하기 어려운 비밀번호
  • 알려진 공격 패턴을 방어하는 정교한 방화벽 설정
  • 공격 봇에 대한 Challenge 적용(“로봇이 아닙니다.” 다들 한번쯤 해보셨죠?)

마찬가지로 한 가지 방법이나 첫 번째 단계 뿐만 아니라 다양한 방법과 다양한 단계에 보안조치을 했다면 그것이 심층보안이다. Challenge는 로그인 시도 전 단계에서 알려진 공격 패턴을 차단하는 것은 무차별 공격이 진행되는 단계에서 방어하는 것이다.

[보안구성 예: 나는 이렇게 했다.]

노출면적 관리

  • 인터넷 노출면적 최소화
    포트포워딩으로 외부 요청을 허용한 IP (1개, 홈서버)
    포트포워딩된 포트 – 80, 443, 3478 (3개)
    관리용 애플리케이션은 포트 노출 없이 보안 터널 적용(클라우드플레어)
  • 내부망 노출면적 최소화
    와이파이 비밀번호 난독화(예측불가)
  • 도커 네트워크 노출면적 최소화(격리)
    각 컨테이너 간의 통신은 서비스를 위해 필요한 최소한으로 제한.(도커네트워크 구성도 참조)
    관리 애플리케이션이 실행되는 도커네트워크에는 더 강화된 보안 적용.(도커네트워크 구성도 참조)
    각 애플리케이션이 서비스 되기 위해 필요한 DB, 웹서버와 같은 애플리케이션 간에도 격리 적용.(모든 애플리케이션이 한 컨테이너에 들어있지 않다는 의미)
  • 애플리케이션 노출 면적 최소화
    딱 내가 쓸거만. 도커네트워크 구성도를 살펴보면 SSH 포함 8개의 애플리케이션이 실행된다.
    물론 각 애플리케이션이 웹서버나 DB가 필요하면 이런 것들이 실행되는 컨테이너들도 실행되고 있다.
    총 25개 컨테이너 실행 중.

취약점 관리 및 애플리케이션 격리

나도 아직 적용 안 했다. 자동 업데이트는 적용 예정이고, 루트리스 도커는 적용했다가 다시 루트풀 도커로 돌아왔다. 왜 다시 돌아왔는가? 응답 시간이 미세하게 길어진다. 문제될 정도는 아니지만 느껴질 정도는 되어서 별로 다. 자세한 내용은 별도로 포스팅 해야겠다.(긴 얘기다. 까먹기 전에 포스팅 해야 할텐데…) 루트리스 도커를 적용하는 것은 도커를 사용하는 환경에서는 가장 좋은 보안 옵션이지만, 필수적이라고 생각하지는 않는다.
기본적으로 내가 이용하는 애플리케이션의 공식 이미지와 컴포즈 파일은 도커 내부 사용자 권한이 일반사용자이기도하고, 도커는 기본적으로 샌드박스로 작동한다. seccomp 규칙에 의해서 도커 내부의 사용자나 애플리케이션이 호출할 수 있는 시스템 명령어는 제한되어 있다. 그리고 도커소켓을 컨테이너 내부에 노출 하지 않는 한 컨테이너 내부에서 호스트 운영체제에 할 수 있는 행동은 이미 충분히 차단되었다고 생각한다. 이게 불충분하다고 생각하는 사람들을 위해 루트리스 모드가 있는 거다. 아무런 제약 없이 좋은 보안을 제공한다면 모르겠는데 조금 불편한 구석도 있다(예: 루트리스에서 실행하기 위해 커스텀 이미지를 생성 해야하는 경우가 있다.). 그러니 각자 판단하도록 하자.

  • 운영체제 및 도커 자동 업데이트 스크립트 작성 및 systemd timer 적용.
  • 루트리스 도커로 마이그레이션(더 나은 격리)

무차별 공격 방어

  • Cloudflare reverse proxy 적용 <–알려진 공격 패턴차단, DDos 방어를 해준다.
    wordpress 호스트에만 적용했다. 무료 플랜에서는 단일 요청으로 가능한 최대 업로드 용량이 100MB로 제한된다. 넥스트클라우드나 오픈프로젝트에 적용하면 꽤 귀찮을거 같아서 일단 미적용.(이 후 100 MB 단일 파일 업로드가 없을거 같으면 적용할 예정이다.)
  • Cloudflare Turnstile(봇 challenge)
    워드프레스는 플러그인으로 입력 창이 노출된 경우 챌린지 하도록 설정
    터널을 통해 접근하는 관리 도구는 보안규칙을 통해 챌린지 하도록 설정
  • SSH 보안 조치
    보안키를 생성해서 적용하고 패스워드를 통한 로그인 금지
    포트 노출 없이 터널로만 접근 가능.
    터널 접근 시 이메일을 이용한 2단계 인증
  • 로그인 시도 실패 5회 반복 시 계정 차단 – Nextcloud, Openproject에 적용.
  • 로그인 시도 실패 반복 마다 로그인 지연 시간 증가 – Nextcloud에 적용.

3. 정리

정리에 앞서 백업 전략 구성은 다음 포스트로 미루기로 한다.(아직 구상 중…)

정리하면 보안은 공격자를 차단하거나 귀찮게 하기 위해서 사용자와 관리자도 어느 정도의 귀찮음을 감수하게 된다. 이를 타협해야 될 것이고, 다양한 방법과 다양한 단계에 보안 조치를 취하는 심층방어의 개념을 적용하도록하자. IT 보안에서도 심층방어라고 하나? 원자력공학전공인 나는 원자력발전소의 안전에 관해서 이야기할때 심층방어라는 표현을 종종들었기 때문에 사용해 봤다.(아님 말고)

그리고 다양한 방법을 다양한 계층에 적용하는 것은 적절한 조합을 찾을 경우 사용자와 관리자가 감수해야 할 귀찮음을 감소시키는 방안이 될 수도 있다.

마지막으로 나머지는 직접 신경써야 할 것이지만 무차별 공격 방어는 직접 해보기엔 아마추어에게 쉬운 일이 아니다. 왠만하면 cloudflare나 비슷한 서비스를 이용하도록 하자. 2~3주 쯤 운영해본 결과 사실이게 제일 중요한거 아닌가 싶다. 이걸 적용하기 전까지는 무차별 공격시도가 끝도 없었다. LOG를 살펴보면 로그인 실패가 1분에 6~8회정도 기록된다.(ssh의 경우)
넥스트클라우드도 오늘 아침에 내 계정이 차단되어있었다.

끝~.

구형 랩탑 홈서버를 위해 debian 13 설치 후 설정한 것들.

일단 생각 나는 대로 써놓고 나중에 다 편집.

임시글이지만 블로그에 글이 너무 없으니까 일단 포스팅~

kde setting에서 어댑터 사용시 리드를 닫거나 열때 “아무것도 하지 않음.”

결과 : ~/.config/powerdevilrc

[AC][SuspendAndShutdown]
AutoSuspendAction=0
LidAction=64

[LowBattery][SuspendAndShutdown]
LidAction=8

이 것 만으로는 로그인하지 않으면 리드 액션이 원하는 대로 작동하지 않음.(예: 리드를 닫으면 network가 유지 되지 않음.)

파일: /etc/systemd/logind.conf

...
HandleLidSwitchExternalPower=ignore
...

이렇게 하면 KDE 세션에 로그인하지 않고 랩탑 리드를 닫아도 서비스 유지 가능.

패킷크기 제한 변경(필요한지는 잘 모르겠지만 제미나이와 대화 하다보니 너무 작은 패킷은 네트워크 오버헤드를 유발한다고.)

파일: /etc/sysctl.d/99-udt-buffer.conf

net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.core.rmem_default=16777216
net.core.wmem_default=16777216

그 밖에 xshell을 이용해서 ssh.key를 생성. 서버에 적용. sshd설정에서 text password 로그인 금지.

랩탑을 홈서버 HW로 선택하면 내장된 배터리가 UPS 역할까지 해준다.. 그런데 앤터프라이즈 사양의 HW에 탑제된 검증된 배터리도 아니고(가전 제품을 무시하는건 아니지만..) 걱정되자나.
그래서 리눅스에서 80% 충전 제한 기능이 작동하지 않을때 해결책 중 하나.(일단 나는 작동함.)
작동하지 않는 원인은 디바이스파일에 제한값을 입력할때 KDE setting에서 입력하는 값은 무시됨.(권한문제인가?)
sudo cat > /dev/~~~/~~ 으로 직접 입력하면 작동됨. 근데 특이하게 80 외에 다른 값은 안먹음.
재부팅 하면 리셋됨..-_-;;
systemd 유닛을 하나 만들어서 enable 시켜두면됨.

/etc/systemd/system/battery-limit.service

[Unit]
Description=LG Gram Battery Charge Limit (80)
After=multi-user.target
StartLimitIntervalSec=0

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo 80 > /sys/devices/platform/lg-laptop/battery_care_limit'
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target