개발 환경 설치는 배우는 일이 아니라 준비하는 일입니다. 그런데 준비 단계에서 하루가 통째로 사라지는 경험은 드물지 않습니다. 코드를 한 줄도 쓰지 못한 채 저녁이 되고, 남는 것은 반쯤 설치된 도구 몇 개와 지친 기분뿐인 날이 있습니다.
이 글은 설치 순서를 나열하는 글이 아닙니다. 시간이 정확히 어디서 새는지를 먼저 짚고, 그 지점을 피해서 오늘 안에 코드를 실행하는 상태까지 가는 것이 목표입니다. 완벽한 세팅이 아니라 오늘 돌아가는 세팅을 만드는 쪽으로 방향을 잡습니다.
하루가 사라지는 경로는 대체로 비슷합니다
아침에 환경부터 제대로 잡자고 마음먹습니다. 검색창에 언어 이름과 설치라는 단어를 넣고, 상단에 나온 글을 엽니다. 설명은 친절하지만 작성 시점이 오래되어 화면 속 버튼 이름이 지금 사이트와 다릅니다. 맞는 자리를 찾느라 십여 분이 흘러갑니다.
설치 파일을 받아 실행합니다. 중간에 선택지가 나옵니다. 어떤 항목을 체크해야 하는지 판단이 서지 않아 다시 검색합니다. 그러다 다른 설치 방식을 권하는 글을 발견합니다. 패키지 매니저를 쓰는 편이 낫다고 적혀 있습니다. 방금 깐 것을 지우고 처음부터 다시 시작합니다. 여기서 한 시간이 지나갑니다.
패키지 매니저를 설치하려니 그것부터 설치가 필요합니다. 명령을 붙여넣자 권한 오류가 납니다. 오류 문구를 그대로 검색해 나온 답변을 따라 옵션 하나를 추가합니다. 이번에는 설치가 되지만, 새 터미널을 열면 명령이 없다고 나옵니다. 경로 설정 이야기가 시작되고 점심시간이 지나갑니다.
오후에는 에디터를 엽니다. 확장 프로그램 목록을 훑다가 추천 목록 글을 읽고 열 개 남짓 설치합니다. 그중 몇 개가 서로 겹치는 기능이라 파일을 저장할 때마다 코드가 제멋대로 바뀝니다. 어떤 확장이 범인인지 찾느라 한참을 헤맵니다. 그리고 아직 첫 파일을 실행해 본 적이 없다는 사실을 깨닫습니다.
이 경로에서 실제로 막히는 지점
위 이야기에서 시간을 잡아먹은 것은 설치 자체가 아닙니다. 막힌 곳은 세 종류입니다.
첫째는 선택지를 판단할 근거가 없는 상태에서 선택을 강요당하는 순간입니다. 설치 방식이 두 가지 이상 보이면 초보자는 더 나은 쪽을 고르려고 멈춰 섭니다. 그런데 입문 단계에서 두 방식의 차이는 거의 체감되지 않습니다. 판단이 불가능한 선택에 시간을 쓰고 있는 셈입니다.
둘째는 되돌아가기입니다. 이미 설치한 것을 지우고 다른 방식으로 다시 까는 행동은 시간을 두 배로 쓰면서 결과는 그대로입니다. 게다가 지운다고 흔적이 완전히 사라지지 않아, 나중에 나오는 오류의 원인을 더 찾기 어렵게 만듭니다.
셋째는 검증을 미루는 습관입니다. 설치를 여러 개 몰아서 한 뒤 마지막에 한 번 실행해 보면, 문제가 생겼을 때 어느 단계가 원인인지 알 수 없습니다. 하나 깔고 한 번 확인하는 방식이 답답해 보여도 결국 빠릅니다. 이 감각은 디버깅을 순서대로 하는 습관과 같은 뿌리에서 나옵니다.
설치를 시작하기 전에 정해 둘 것
도구를 내려받기 전에 종이 한 장 분량으로 정해 둘 것이 있습니다. 정해 두면 중간에 나타나는 선택지 대부분을 무시할 수 있습니다.
오늘 실행할 코드 한 줄이 무엇인지 먼저 정합니다. 화면에 문자열 하나를 출력하는 코드여도 됩니다. 목표가 있어야 설치가 끝났는지 판단할 수 있습니다. 목표가 없으면 설치는 끝나지 않습니다.
작업 폴더의 위치를 정합니다. 홈 디렉터리 아래에 폴더 하나를 만들고 앞으로 만드는 파일을 전부 그 안에 둡니다. 파일을 어디에 저장했는지 몰라서 생기는 혼란은 생각보다 자주 발생합니다.
버전을 하나만 쓴다는 원칙을 정합니다. 최신 버전이 아니어도 됩니다. 이미 깔려 있는 버전이 있다면 그것을 씁니다. 언어 버전을 여러 개 관리하는 도구는 필요해진 다음에 배워도 늦지 않습니다.
에디터는 하나만 고르고 설정은 건드리지 않습니다. 어느 에디터가 더 나은지는 지금 판단할 수 있는 문제가 아니고, 입문 단계에서 체감할 차이도 크지 않습니다. 기본 상태 그대로 열어서 파일을 만들고 저장할 수 있으면 오늘 몫은 충분합니다. 단축키와 확장은 불편을 느낀 다음에 하나씩 찾아 붙이는 편이, 남이 정리해 둔 목록을 통째로 설치하는 것보다 오래 남습니다.
STEP 1 — 무엇이 이미 깔려 있는지 확인
$ python3 --version
Python 3.12.3
$ which python3
/usr/bin/python3
$ node --version
zsh: command not found: node
$ pwd
/Users/me
$ mkdir -p ~/code && cd ~/code설치 전에 먼저 확인합니다. 위 예시에서는 파이썬이 이미 있고 노드는 없습니다. 그러면 오늘 파이썬으로 시작하면 됩니다. command not found는 고장이 아니라 "아직 없음"이라는 뜻입니다.
프로젝트마다 방을 따로 쓰는 최소 설정
설치에서 가장 흔한 사고는 이 프로젝트에 필요한 라이브러리와 저 프로젝트에 필요한 라이브러리가 같은 자리에 쌓이면서 서로를 밀어내는 상황입니다. 파이썬에서는 명령 두 줄로 프로젝트마다 별도의 공간을 만들 수 있습니다. 이 두 줄을 아는 것과 모르는 것의 차이가 나중에 크게 벌어집니다.
STEP 2 — 프로젝트 전용 환경
$ mkdir first-project && cd first-project
$ python3 -m venv .venv
$ source .venv/bin/activate
(.venv) $ python -m pip list
Package Version
------- -------
pip 24.0
(.venv) $ echo 'print("ready")' > main.py
(.venv) $ python main.py
ready윈도우 명령 프롬프트에서는 세 번째 줄이 .venv\Scripts\activate입니다. 프롬프트 앞에 (.venv)가 붙으면 이 프로젝트 전용 공간 안에 있다는 뜻입니다. 여기까지 오면 오늘의 설치는 끝난 것으로 봐도 됩니다.
이 조언이 오히려 손해가 되는 경우
지금까지의 이야기를 뒤집는 상황이 두 가지 있습니다.
하나는 최소 구성을 지키려다 매번 같은 준비를 반복하는 경우입니다. 가상 환경 없이 시작하면 오늘은 빠릅니다. 그런데 두 번째 프로젝트에서 라이브러리 버전이 충돌하고, 세 번째 프로젝트에서 무엇이 왜 깔려 있는지 아무도 모르는 상태가 됩니다. 최소 구성은 "아무것도 하지 않기"가 아닙니다. 오늘 코드를 실행하는 데 필요한 것까지는 하고, 그 이상을 미루는 것입니다. 프로젝트 격리는 "필요한 것" 쪽에 가깝습니다.
다른 하나는 완벽한 환경을 먼저 갖추려는 태도입니다. 포매터, 린터, 타입 검사기, 커밋 훅, 터미널 테마까지 첫날에 붙이면 도구 하나가 삐끗할 때마다 코드가 아니라 설정 파일을 고치게 됩니다. 이 도구들은 코드가 어느 정도 쌓인 뒤에 붙여야 무엇을 잡아 주는지 체감됩니다. 아직 잡을 코드가 없는데 잡아 주는 도구부터 다는 셈입니다.
또 하나 짚어 둘 상황이 있습니다. 회사나 학교에서 표준 환경이 정해져 있는 경우입니다. 팀이 특정 버전과 특정 도구 조합을 쓰고 있고 그것을 문서로 관리한다면, 개인 취향의 세팅은 의미가 없을 뿐 아니라 마이너스입니다. 나만 다른 버전을 쓰면 나만 재현되는 버그가 생기고, 그 버그를 설명하는 데 팀 시간이 들어갑니다. 이럴 때는 이 글의 조언을 접어 두고 팀 문서를 그대로 따르는 것이 맞습니다. 취향은 개인 프로젝트에서 부리면 됩니다.
오늘 저녁에 끝낼 수 있는 순서
- 오늘 실행할 코드 한 줄을 먼저 정합니다.
- 터미널을 열고 이미 깔려 있는 것이 무엇인지 확인합니다.
- 없는 것만 설치하고, 하나 설치할 때마다 버전을 출력해 봅니다.
- 작업 폴더를 하나 만들고 그 안에 프로젝트 전용 환경을 만듭니다.
- 파일을 저장하고 실행해서 출력이 나오는지 확인합니다.
- 여기까지 됐으면 오늘은 그만두고, 확장 프로그램은 내일 하나씩 붙입니다.
설치하면서 실행한 명령을 메모장에 그대로 붙여 두면, 나중에 컴퓨터를 바꾸거나 환경이 망가졌을 때 같은 하루를 반복하지 않아도 됩니다. 이 메모는 나중에 자동화 스크립트의 초안이 됩니다. 터미널 자체가 낯설다면 명령줄에서 먼저 익힐 습관을 먼저 보고 오는 편이 낫습니다.
검색해서 나온 명령을 이해하지 않은 채 붙여넣는 습관입니다. 특히 관리자 권한으로 시스템 전체를 건드리는 명령은 나중에 되돌리기 어렵습니다. 명령에 sudo가 붙어 있으면 잠깐 멈추고, 그 명령이 무엇을 바꾸는지 한 줄로 설명할 수 있는지 스스로 확인해 봅니다. 설명하지 못하겠다면 그 명령은 아직 실행할 때가 아닙니다.
환경 설정을 마친 뒤에는 코드를 저장하고 되돌릴 수 있는 상태를 만드는 것이 다음 순서입니다. 첫 주에 익히는 깃과 파이썬 학습 경로를 이어서 보면 오늘 만든 환경이 바로 쓰이기 시작합니다.
환경 설정은 언젠가 끝나는 일이 아니라, 필요할 때마다 조금씩 덧대는 일입니다. 첫날에 해야 할 몫은 코드 한 줄이 실행되는 지점까지입니다.