코드 인 팩토리

Ubuntu에서 개발 환경을 꾸밀 때 VS Code를 선택하는 경우가 많습니다. 저도 지난 5년 동안 거의 매일 VS Code를 열어 쓰고 있는데, 플러그인을 조금만 욕심내기 시작하면 금방 무거워지고 팬이 계속 도는 상황이 되곤 했습니다. 이 글은 “VS Code를 최대한 가볍게 유지하면서도 필요한 기능은 챙기는 쪽”에 초점을 맞춰 정리한 내용입니다. 거창한 튜닝이라기보다는, 제가 실제로 써보고 계속 유지하게 된 확장과 설정 위주입니다. VS Code가 무거워지는 지점부터 정리하기 VS Code 자체는 비교적 가벼운 편이지만, 아래 세 가지가 겹치면 체감이 확 무거워졌습니다. 큰 프로젝트(특히 많은 파일, Node 기반 프론트엔드 프로젝트) 확장(Extensions)을 여러 개 동시에 켜 둔 상태 자동 분석·인덱싱을 많이 하는 언어 서버 실제로 느낀 건 “에디터가 무겁다”기보다, 확장과 백그라운드 작업이 무거워지는 경우가 대부분이라는 점이었습니다. 그래서 저는 VS Code를 가볍게 만든다기보다, “내가 쓰는 기능만 남기고 나머지를 비워낸다” 는 쪽으로 생각을 바꿨습니다. 항상 설치해 두는 최소 확장 세트 프로젝트마다 쓰는 확장은 달라지지만, 어떤 언어를 쓰든 거의 항상 설치해 두는 “최소 세트”가 있습니다. 개별 확장 이름은 여기서 굳이 하나하나 언급하지 않고, 어떤 역할의 확장을 어떻게 고르는지 기준만 정리해 보겠습니다. 언어 지원 : 실제로 쓰는 언어에 필요한 확장만 설치합니다. 예를 들어 Python을 쓴다면 Python 관련 확장 하나, JavaScript/TypeScript라면 그쪽 기본 확장만 두고, 굳이 쓰지 않는 언어(Go, Rust, PHP 등)는 확장을 설치하지 않습니다. 테마·아이콘 : 테마는 한 가지, 아이콘 테마도 한 가지로 정합니다. 여러 개 설치해 두면 계속 바꿔 보게 되고, 일부 테마는 자체 코드 하이라이트 규칙 때문에 에디터가 더 어수선해질 때도 있었습니다. Git·Diff 보조 : 기본 Git ...

회사나 집에서 프린터는 보통 윈도우 PC에 먼저 연결돼 있습니다. USB로 바로 꽂혀 있거나, 제조사 드라이버가 윈도우 기준으로만 잘 만들어져 있는 경우가 많죠. Ubuntu를 5년 정도 메인으로 쓰면서 느낀 건, “프린터를 Ubuntu에 직접 연결하려고 애쓰는 것보다, 이미 잘 잡힌 윈도우 프린터를 네트워크로 가져다 쓰는 쪽이 훨씬 현실적이다” 는 점이었습니다. 이 글에서는 최대한 복잡한 설명은 뒤로 빼고, 윈도우에 이미 잘 연결된 프린터를 Ubuntu에서 같이 쓰는 흐름을 정리해 보겠습니다. 상황에 따라 메뉴 이름이나 위치는 조금 다를 수 있지만, 큰 구조는 비슷합니다. 먼저 구조부터 이해하기: 프린터는 윈도우가 들고 있고, Ubuntu는 빌려 쓰는 형태 여기서 말하는 “공유 프린터”는 구조가 이렇습니다. 프린터는 윈도우 PC에 USB나 네트워크로 연결 돼 있고 윈도우에서 이 프린터를 네트워크로 공유 해 둔 다음 같은 네트워크에 있는 Ubuntu가 그 프린터를 찾아서 사용하는 방식 즉 프린터를 직접 Ubuntu에 잡는 것이 아니라, 윈도우를 거쳐 하나 더 건너서 쓰는 구조입니다. 이 구조만 머릿속에 넣어두면, 설정이 잘 안 될 때 어디를 확인해야 할지 감이 조금 더 잡힙니다. 제 기준에서는 “프린터는 윈도우가 책임지고, Ubuntu는 그냥 네트워크 프린터 하나 추가한다” 이렇게 생각하면 편했습니다. 윈도우에서 해야 할 준비: 공유 켜기와 이름 확인 Ubuntu에서 프린터를 찾기 전에, 윈도우 쪽에서 두 가지를 먼저 확인해야 했습니다. 공유가 켜져 있는지, 그리고 그 공유 이름이 무엇인지입니다. 윈도우에서 프린터가 이미 잘 출력되는 상태라고 가정하면, 저는 보통 이런 순서로 확인했습니다. 제어판이나 설정 앱에서 해당 프린터 속성 열기 “공유” 탭(또는 비슷한 이름)에서 프린터 공유 사용 체크 “공유 이름”에 적힌 문구를 메모해 두기 (예: OfficePrinter ) 또 하나 중요한 건 네트워크입니다. Ubun...

집에 PC가 한 대뿐인데 가족이 다 같이 써야 하는 경우가 많습니다. 누군가는 인터넷 강의, 누군가는 웹 서핑, 누군가는 문서 작업이나 간단한 개발을 하고요. Ubuntu를 5년 정도 쓰다 보니, “성능”보다 더 중요한 게 계정·권한 설계 라는 걸 많이 느꼈습니다. 누가 뭘 지울 수 있고, 어디까지 볼 수 있고, 서로의 파일이 섞이지 않도록 어떻게 막을지 정리해 두는 게 핵심이었습니다. 관리자 계정은 딱 한 명, 일상용 계정은 따로 쓰기 공용 PC에서 가장 먼저 정해야 할 것은 “누가 관리자냐”입니다. Ubuntu 설치 과정에서 만드는 첫 계정은 보통 관리자(sudo 권한 보유)인데, 저는 이 계정을 설정 전용 으로 쓰고, 일상용으로는 일반 계정을 따로 만든 편입니다. 구조를 정리하면 대략 이렇게 됩니다. admin : 실제로는 거의 로그인하지 않는 관리자 계정 (패키지 설치, 시스템 업데이트, 새 계정 추가용) parent : 집에서 주로 쓰는 어른용 계정 (일반 사용자, 필요할 때만 관리자 계정 비밀번호 입력) kid1, kid2 … : 아이들용 계정 (일반 사용자, sudo 권한 없음) guest 또는 temp : 손님이 잠깐 쓰는 계정 (로그인 기록 지워지도록 설정하거나, 아예 매번 초기화) 실제 경험상, 관리자 권한을 가진 계정으로 계속 쓰다 보면 어느 순간 sudo rm … 같은 명령을 실수로 치거나, 시스템 설정을 건드리기 쉬워집니다. 반대로, 관리자 계정과 일상 계정을 분리해 두면 “뭔가를 설치하려고 할 때만 한 번 더 생각하게 되는” 브레이크가 생깁니다. 홈 디렉터리는 철저히 개인용, 공유 폴더는 따로 빼기 Ubuntu에서는 사용자를 만들면 보통 /home/사용자명 에 홈 디렉터리가 자동으로 생깁니다. 기본 권한은 “본인만 읽고 쓸 수 있고, 다른 사용자는 접근할 수 없는” 상태로 설정됩니다. 그래서 가족끼리 쓰더라도 홈 디렉터리만 잘 지켜지면, 최소한 서로의 문서·사진이 섞이거나 엉뚱한 사람이 지우는 일은 거의...

Ubuntu에서 게임을 한다고 하면 보통 “프로톤(Proton)으로 스팀 게임 돌리는 거야?”라는 이야기가 많이 나옵니다. 실제로 요즘엔 Proton 덕분에 리눅스에서도 윈도우 게임이 많이 돌아가는 편이고, 스팀 하드웨어 설문에서도 리눅스 비중이 조금씩 올라가는 중입니다.:contentReference[oaicite:0]{index=0} 하지만 모든 게임을 리눅스에 직접 까는 대신, Windows 게이밍 PC에서 돌리는 화면을 Ubuntu로 스트리밍 해서 즐기는 방법도 있습니다. 저는 집에서 “윈도우 고사양 PC + Ubuntu 노트북” 조합으로 이 방식을 꽤 오래 써왔고, 그때 기준으로 정리해 보겠습니다. Ubuntu를 ‘클라이언트’로 쓰는 구조 이해하기 이 글에서 다루는 구조는 간단히 말하면 다음과 같습니다. 호스트(Host) : 실제로 게임이 실행되는 메인 PC (보통 Windows, 고사양 GPU) 클라이언트(Client) : 화면을 받아서 보여주는 Ubuntu PC·노트북 호스트 PC에서는 게임이 평소처럼 돌아가고, Ubuntu 쪽에서는 입력(키보드, 마우스, 패드)을 네트워크로 보내고, 영상·소리를 스트리밍으로 받아오는 구조입니다. Valve의 Steam Link 는 “Steam이 실행 중인 PC → 다른 기기”로 화면을 보내는 공식 솔루션이고, Moonlight 는 원래 NVIDIA GameStream 프로토콜을 쓰는 오픈소스 클라이언트입니다. 현재는 Sunshine 이라는 호스트가 Moonlight용으로 많이 쓰이고 있습니다.:contentReference[oaicite:1]{index=1} 네트워크 상황에 따라 체감이 많이 달라지기 때문에, 아래 내용은 모두 집 안 유선 또는 안정적인 5GHz 와이파이 환경 을 전제로 한 경험에 가깝습니다. 공식 문서에서도 가능하면 유선 연결을 권장합니다.:contentReference[oaicite:2]{index=2} Steam Link: Ubuntu에서 제일 먼저 시도해 볼 카드 ...

Ubuntu를 오래 쓰다 보면 속도나 안정성도 중요한데, 화면이 마음에 안 들면 집중이 잘 안 됩니다. 저도 한동안은 설치만 끝나면 바로 테마부터 뒤집어놓는 타입이었고, 그 과정에서 시스템이 꼬인 적도 몇 번 있습니다. 5년 정도 Ubuntu를 쓰면서 정리된 결론은 간단했습니다. “예쁜 테마”보다 “내 눈에 편한 통일감”을 먼저 잡고, 그 안에서만 놀자 입니다. 이 글에서는 폰트, 아이콘, 쉘(터미널) 스타일을 크게 흐트러지지 않게 맞추는 방법을 정리해 보겠습니다. 먼저 전체 그림부터 잡기 커스터마이징을 시작하기 전에, “어디까지 손댈지”를 한번 정해두면 훨씬 덜 복잡해집니다. 저는 보통 이렇게 네 영역으로 나눠서 생각합니다. 시스템 전반 글꼴 (창 제목, 메뉴, 시스템 UI) 아이콘 테마와 GTK(앱) 테마 터미널과 쉘 프롬프트 스타일 에디터/브라우저 등 자주 쓰는 앱 개별 설정 현실적으로는 네 영역을 한 번에 완벽하게 맞추기는 어렵고, “폰트 → 아이콘 → 터미널” 순서로만 정리해도 화면 인상이 많이 달라졌습니다. 또 하나 신경 썼던 점은, 가능하면 Ubuntu 기본 저장소나 검증된 도구를 위주로 쓰는 것입니다. 인터넷에서 아무 테마나 내려받아서 시스템 깊숙이 넣다 보면, 나중에 문제가 생겼을 때 원인을 찾기 어려워질 수 있습니다. 1. 폰트부터 정리하면 전체 분위기가 달라진다 개인적으로 커스터마이징에서 체감 효과가 가장 큰 건 폰트였습니다. 색이나 아이콘은 취향 차이가 크지만, 글꼴은 눈의 피로와 직결되기 때문에 “제일 많이 보는 텍스트가 어떤 폰트인지”가 중요합니다. 시스템 글꼴 바꾸기 Ubuntu 기본 GNOME 환경 기준으로, 시스템 글꼴은 보통 설정 앱이나 “GNOME Tweaks(gnome-tweaks)” 같은 도구에서 변경할 수 있습니다. 구체적인 메뉴 이름과 위치는 버전에 따라 조금씩 다를 수 있지만, 보통 다음 항목들이 있습니다. Interface / Applic...

요즘은 “개발 환경 = Docker”라는 인상이 강합니다. 팀 위키나 블로그 글을 보면 “일단 컨테이너로 띄우고 보자”는 식의 내용도 많고요. 그런데 Ubuntu 한 대에서 혼자 개발하거나, 소규모 프로젝트를 돌리는 정도라면 꼭 Docker까지 쓰지 않아도 충분히 가벼운 개발 환경을 만들 수 있습니다. 저는 지난 5년 정도 Ubuntu를 메인 개발용 OS로 쓰면서, 일부 서버 작업을 제외하면 대부분의 일을 그냥 로컬 Ubuntu 환경에서 해결하고 있습니다. 이 글은 “Docker를 절대 쓰지 말자”는 이야기가 아니라, Ubuntu 자체를 개발 환경으로 쓰되 최소한으로만 세팅하는 방법 을 정리한 것입니다. 컨테이너를 도입하기 전에, 일단 이렇게 한 번 만들어 보고 나서 진짜 필요한지 판단해도 늦지 않습니다. Docker가 없어도 되는 상황부터 구분하기 먼저 “내가 하는 개발이 정말로 Docker를 필요로 하는가”를 구분해 보는 게 좋습니다. 제가 작업했던 사례들을 기준으로 나눠보면 대략 이런 느낌이었습니다. 로컬에서만 돌리는 개인 웹 서비스, 사이드 프로젝트 단일 언어/런타임만 사용하는 스크립트나 CLI 도구 외부 의존성이 거의 없는 간단한 백엔드·API 서버 회사 서버 쪽 배포는 어차피 다른 사람이 담당하는 경우 이 정도 범위라면 Ubuntu에 필요한 언어 런타임과 라이브러리만 깔아도 충분히 작업이 가능합니다. 반대로, 아래 상황에 가까울수록 Docker 같은 도구가 의미가 커집니다. 서버 환경이 전부 컨테이너 기반으로 운영되고 있는 팀 개발·테스트·운영 환경을 이미지 하나로 맞춰야 하는 배포 파이프라인 여러 언어·여러 데이터베이스를 동시에 띄우는 복잡한 시스템 제가 개인 프로젝트나 소규모 업무용 도구를 만들 때는 대부분 전자에 가까웠습니다. 그래서 “일단 Ubuntu를 최대한 깔끔하게 세팅해 놓고, Docker는 정말 필요할 때만 쓴다”는 기준으로 정리해 두니 관리가 훨씬 편했습니다. Ubuntu 기본 저장소만으로 개발...

시놀로지 같은 NAS를 사기에는 가격이 부담되지만, 집에 항상 켜 두는 Ubuntu 머신이 하나 있다면 “간이 NAS” 정도는 충분히 흉내 낼 수 있습니다. 저는 몇 년 동안 집에 있는 작은 Ubuntu 박스를 파일 공유와 백업용으로 돌려왔고, 윈도우·다른 리눅스·맥에서 동시에 접속해 쓰는 구성을 계속 유지하고 있습니다. 이 글은 “정식 NAS를 완벽하게 대체한다”기보다는, Ubuntu 한 대로 NAS 비슷한 역할 을 하게 만드는 현실적인 방법을 정리한 것입니다. 먼저 어떤 역할을 하게 할지 정리하기 집에서 NAS를 흉내 내려고 할 때 보통 생각하는 용도는 크게 세 가지 정도였습니다. 여러 기기에서 공유하는 파일 창고 (사진, 영상, 문서) 각 PC·노트북의 백업 목적지 맥북을 위한 네트워크 타임머신 백업 대상 이 세 가지를 한꺼번에 다 하더라도, 결국 Ubuntu 입장에서는 “특정 폴더를 네트워크에 적절한 방식으로 공유한다”로 정리됩니다. 저는 처음 세팅할 때부터 폴더를 용도별로 나눴습니다. 예를 들어 다음처럼요. /srv/nas/shared → 모든 기기에서 공용으로 쓰는 자료 /srv/nas/backup → 각 PC에서 밀어 넣는 백업 데이터 /srv/nas/timemachine → 맥용 타임머신 백업 전용 이렇게 나눠 두면 나중에 백업 정책이나 권한을 따로 관리하기가 훨씬 편했습니다. 실제 디렉터리 이름은 어떤 것을 써도 상관없지만, “공유 목적에 맞게 분리해 둔다”는 원칙만 미리 정해 두면 좋았습니다. Samba로 윈도우·맥 파일 공유 열기 가장 먼저 체감 효과가 오는 건 Samba입니다. 윈도우 탐색기에서 \\ubuntu-서버이름 으로 접속하거나, 맥의 파인더에서 “서버에 연결”로 들어가 공유 폴더를 볼 수 있는 방식입니다. Samba 패키지 설치와 서비스 활성화는 Ubuntu 기본 저장소에서 할 수 있고, 설치 후에는 /etc/samba/smb.conf 파일에서 공유 폴더를 정의합니다. 아래 예시는 구조를 보여주...