2026 개발 환경 구성 완전 가이드
macOS·WSL2·Docker·AI 에디터 선택 기준 총정리
이 장을 읽기 전에: 프로그래밍의 기본 개념(변수, 함수, 파일 조작)을 이해하고 있으면 충분하다. 특정 언어 경험은 필요 없다.
소프트웨어 개발은, 코드를 작성하기 전 "환경 구성"에서 첫 번째 벽에 부딪힌다. 몇 시간을 들여 도구를 설치하고, 오류를 검색하고, 겨우 동작하게 됐을 때쯤엔 지쳐버린다 - 이것은 많은 엔지니어가 거치는 과정이다.
이 장에서는 왜 특정 도구가 필요한지, 어떤 도구를 선택해야 하는지의 판단 기준을 제시한다.
1. OS 선택
이 섹션이 답하는 질문: 개발용 OS는 무엇을 선택해야 하는가?
왜 필요한가?
프로그래밍 자체는 어떤 OS에서도 할 수 있다. 하지만 실제 운영 서버는 거의 Linux로 동작하고 있다. 개발 환경과 운영 환경의 OS가 다르면, "내 PC에서는 동작하는데 운영 환경에서는 동작하지 않는다"는 문제가 발생하기 쉽다. 또한 개발 도구의 대부분은 Unix 계열 OS(macOS / Linux)를 전제로 만들어져 있기 때문에, Windows에서는 한 단계 더 번거러운 경우가 있다.
선정 판단 기준
� 한국 환경 참고: 국내 IT 기업(카카오·네이버·토스·라인)은 임직원에게 MacBook을 지급하는 경우가 많다. 반면 공공기관·금융권·대기업 SI 환경에서는 Windows가 여전히 지배적이다. Windows 환경이라면 WSL2 설정은 선택이 아닌 필수다.
실무에서의 주의점
⚠️ WSL 없이 Windows를 사용할 때의 함정: 경로 구분 문자(\ vs /), 줄바꿈 코드(CRLF vs LF), 파일명 대소문자 처리 등, 사소한 차이가 쌓여 트러블의 원인이 된다. Windows에서 개발하는 경우 WSL2 도입은 사실상 필수다.
⚠️ macOS 사용자에게: Homebrew 설치(/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)")는 개발 환경 구성의 첫 번째 단계. Apple Silicon(M1/M2/M3/M4/M5)은 설치 경로가 /opt/homebrew임에 주의한다.
⚠️ WSL2 한국어 환경 설정: WSL2에서 한글이 깨지는 경우 locale을 ko_KR.UTF-8로 설정한다.
# WSL2 한국어 로케일 설정
sudo apt install -y language-pack-ko
sudo locale-gen ko_KR.UTF-8
sudo update-locale LANG=ko_KR.UTF-8
정리
막히면 macOS가 가장 순탄하다. Windows 사용자는 WSL2를 반드시 설치한다. 어떤 경우에도 최종적으로는 터미널에서 Linux 명령어를 사용해 개발한다는 점은 공통이다. OS의 차이는 "Linux에 이르기까지의 경로"의 차이에 불과하다.
2. 터미널과 쉘
이 섹션이 답하는 질문: 터미널이란 무엇인가? 왜 GUI가 아닌 명령어 조작이 필요한가?
왜 필요한가
일상적인 PC 조작은, 아이콘을 클릭해서 파일을 여는 GUI(그래픽 사용자 인터페이스)로 충분하다. 그러나 소프트웨어 개발에서는 수백 개의 파일을 일괄 조작하거나, 서버에서 프로그램을 실행하거나, 자동화 스크립트를 실행하는 장면이 빈번하다. 이러한 작업은 텍스트로 명령어를 입력하는 터미널(단말)이 압도적으로 효율적이다.
요리에 비유하자면, GUI는 "완성된 밀키트", 터미널은 "칼과 도마"다. 밀키트는 간편하지만 응용이 어렵다. 칼 사용법을 익히면 어떤 요리든 만들 수 있게 된다.
터미널(Terminal): 명령어를 입력하는 화면
셸(Shell): 터미널 뒤에서 동작하는, 명령어를 해석하는 프로그램
선정 판단 기준
초보자는 zsh를 선택하면 틀림없다. macOS에서는 처음부터 설치되어 있다. Linux(Ubuntu)에서는 bash가 기본이지만, zsh로 전환하는 것도 쉽다.
fish는 "설정 없이 편리하다"는 장점이 있지만, bash 스크립트와의 호환성이 없기 때문에 인터넷의 명령어 예시를 복사해 붙여넣으면 동작하지 않을 수 있다. 이 함정을 허용할 수 있다면 쾌적한 선택지다.
� 국내 커뮤니티 참고: Oh My Zsh + Powerlevel10k 테마 조합이 한국 개발자 커뮤니티(OKKY, 개발자 카카오톡 오픈채팅)에서 가장 많이 공유된다. 단 Starship 프롬프트가 설정이 더 단순하고 속도도 빠르다.
# Starship 프롬프트 설치 (zsh 추천 설정)
curl -sS https://starship.rs/install.sh | sh
echo 'eval "$(starship init zsh)"' >> ~/.zshrc
# 유용한 zsh 플러그인
brew install zsh-autosuggestions zsh-syntax-highlighting
실무에서의 주의점
⚠️ 셸 설정 파일(~/.zshrc 나 ~/.bashrc)은 개발 환경의 "설계도"에 해당한다. 무엇을 작성했는지 알 수 없게 되면, 환경이 망가졌을 때 복구할 수 없다. 변경할 때는 반드시 주석을 남기는 습관을 들이자.
정리
터미널 조작은 개발자의 기본 스킬. 셸은 zsh가 균형이 좋다. 처음에는 무섭게 느껴지만, cd, ls, mkdir, cat의 4가지 명령어부터 시작하면 충분하다. 익숙해질수록 GUI보다 빠르고 정확하게 작업할 수 있게 된다.
3. 에디터/IDE
이 섹션이 답하는 질문: 코드를 작성하는 도구는 무엇을 사용해야 하는가? 2026년 시점에서 IDE 선정 기준은 무엇이 바뀌었는가?
왜 필요한가
코드는 단순한 텍스트 파일이므로, 극단적으로 말하면 메모장으로도 작성할 수 있다. 그러나 실제 개발에서는 수천 줄의 코드에서 오류 부분을 찾거나, 함수 정의 위치로 점프하거나, 변수명을 일괄적으로 변경하는 작업이 일상적으로 발생한다. 이것을 수작업으로 하는 것은 지도 없이 모르는 거리를 걷는 것과 같다.
2026년 시점의 변화는, AI 지원이 "부가 기능"이 아닌 주요 선정 기준이 되었다는 것이다. 단, AI만으로 선택하는 것은 위험하다. 언어 지원, 리팩토링 능력, 팀에서의 공유 용이성, 원격 개발과의 궁합도 같은 정도로 중요하다.
� 국내 현황: 카카오·네이버·라인 등 대형 IT 기업은 IntelliJ IDEA 라이선스를 전사 지원하는 경우가 많다. 스타트업(토스·당근마켓 등)은 VS Code + GitHub Copilot 또는 Cursor 조합이 빠르게 표준화되고 있다.
AI 통합에 의한 선정 기준의 변화 (2026년)
선정 판단 기준
우선 막힐 때
첫 번째 선택은 VS Code + AI 확장 또는 Cursor 두 가지 중 하나로 좋다. 무료 또는 저비용으로 정보량의 많음을 우선하면 VS Code, 처음부터 AI와 대화하면서 작성하는 체험을 중시하면 Cursor가 어울린다.
언어 특화로 깊게 개발하는 사람
IntelliJ IDEA, PyCharm, WebStorm 등 JetBrains 계열이 강하다. Java, Kotlin, Python처럼 IDE의 분석 정확도가 생산성에 직결되는 영역에서는 범용 에디터보다 가치가 나오기 쉽다. 국내 대기업 환경에서 Java/Kotlin + Spring Boot 개발이라면 IntelliJ IDEA가 사실상 표준이다.
에이전트적으로 맡기고 싶은 사람
Windsurf나 Claude Code는 "질문에 답하는" 것뿐만 아니라 계획을 세우고, 편집하고, 경우에 따라서는 명령 실행까지 진행한다. 복수 파일에 걸친 변경이나 조사 태스크에서 특히 효과가 높다.
팀 개발을 중시하는 사람
어떤 에디터를 선택하는가 이상으로, AI에 지키게 할 규칙을 공유할 수 있는가가 중요하다.
.editorconfig, 포매터, 린터, 테스트에 더해, 리포지토리 고유의 지시 파일을 놓아두면 AI의 출력이 안정되기 쉽다.
실무에서의 주의점
⚠️ AI 출력은 반드시 리뷰하고 테스트한다. GitHub Copilot의 책임 있는 이용 가이드에서도, 생성 코드는 인간이 리뷰하고 충분히 테스트해야 한다고 명시되어 있다. AI가 빨리 작성할 수 있다는 것과 올바르다는 것은 별개의 문제다.
⚠️ 클라우드 전송의 전제를 확인한다. AI 에디터는 코드 단편이나 프롬프트를 클라우드에 전송하는 경우가 있다. 업무 코드, 개인정보, 비밀정보를 다루는 경우는 이용약관, 저장 정책, 프라이버시 모드의 유무를 먼저 확인한다. 특히 금융·공공·의료 도메인 개발에서는 사내 AI 정책을 반드시 확인한다.
⚠️ 에디터 설정은 팀에서 통일하는 것이 좋다. .editorconfig, 포매터 설정, 린터 설정을 리포지토리에 놓으면, IDE가 달라도 최소한의 일관성을 유지하기 쉽다.
⚠️ 하나의 도구로 모든 것을 해결하지 않아도 좋다. 평소에는 VS Code나 Cursor를 사용하고, 무거운 변경만 Claude Code나 Copilot coding agent에 맡기는 사용 구분은 매우 자연스럽다.
정리
2026년의 IDE 선정에서 AI 지원의 유무는 무시할 수 없다. 단, 최종적으로 봐야 할 것은 "AI가 강한가"가 아닌, "그 AI를 팀의 규칙과 품질 관리 안에서 안전하게 사용할 수 있는가"다. 첫 번째 선택으로는 VS Code + AI 확장 또는 Cursor가 다루기 쉽다.
① 클라우드 개발 환경 (원격 개발 / 브라우저 기반 IDE)
이 섹션이 답하는 질문: 로컬 머신에 IDE를 설치하지 않는다는 선택지가 있는가?
왜 필요한가
있다. 게다가 최근에는 "예외적인 방법"이 아닌, 일반적인 선택지가 되었다. 특히 다음과 같은 상황에서는 클라우드 개발 환경의 가치가 높다.
새 멤버의 환경 구성을 단시간에 맞추고 싶다
수중의 PC가 저사양으로 큰 빌드나 의존 관계 전개가 무겁다
GitHub 위의 리포지토리를 전원 같은 Linux 환경에서 다루고 싶다
일시적인 검증 환경이나 리뷰 환경을 바로 만들고 싶
선정 판단 기준
GitHub Codespaces (추천: GitHub 중심 팀)
GitHub Codespaces는 GitHub이 호스트하는 Linux 개발 환경으로, 브라우저, VS Code, GitHub CLI에서 접속할 수 있다. devcontainer.json을 리포지토리에 놓으면, 팀 전원이 같은 개발 환경을 재이용하기 쉽다.
DevPod (추천: 환경 정의를 재이용하고 싶은 팀)
DevPod은 클라이언트 중심 도구로, ]devcontainer.json을 기점으로 로컬, 클라우드 VM, Kubernetes, SSH 대상 등에 개발 환경을 전개할 수 있다. "Codespaces적인 체험은 원하지만, 실행 기반은 자신이 선택하고 싶다"는 장면에 어울린다.
Replit (추천: 학습·시작)
Replit은 브라우저에서 시작하기 쉽고, Agent를 사용한 앱 시작이 빠르다. 단, 복잡한 사내 시스템이나 기존 모노레포 개발에서는, Codespaces나 DevPod 쪽이 제어하기 쉬운 경우가 많다.
클라우드 개발 환경 vs 로컬 개발 환경
� 국내 기업 DevContainer 활용 사례: 대규모 모노레포를 운영하는 팀에서 신규 입사자 온보딩 시간을 "3일 → 2시간"으로 단축한 사례가 국내 기술 블로그(카카오 Tech, 토스 기술블로그)에서 보고되고 있다.
// .devcontainer/devcontainer.json — 한국 개발 환경 최적화 예시
{
"name": "Node.js 개발 환경",
"image": "mcr.microsoft.com/devcontainers/typescript-node:20",
"features": {
"ghcr.io/devcontainers/features/github-cli:1": {}
},
"postCreateCommand": "npm install",
"customizations": {
"vscode": {
"extensions": [
"esbenp.prettier-vscode",
"dbaeumer.vscode-eslint",
"GitHub.copilot",
"streetsidesoftware.code-spell-checker-korean"
],
"settings": {
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true
}
}
},
"forwardPorts": [3000, 5432]
}
실무에서의 주의점
⚠️ 네트워크 지연과 비용을 경시하지 않는다. 클라우드 개발 환경은 편리하지만, 지연과 과금은 반드시 발생한다. 상시 접속이 전제이기 때문에 회선 품질이 나쁜 환경에서는 체험이 크게 떨어진다.
⚠️ 환경 정의는 리포지토리에 놓는다. 클라우드 개발 환경의 가치는 "누가 열어도 같은 환경이 되는" 것에 있다. devcontainer.json과 관련 설정을 리포지토리에 커밋하여 개인 설정이 아닌 프로젝트 설정으로 관리하자.
⚠️ 로컬과 클라우드를 대립시킬 필요는 없다. 일상 개발은 로컬, 온보딩이나 일시적인 검증은 클라우드라는 사용 구분이 현실적이다.
정리
클라우드 개발 환경은 재현성과 온보딩 속도를 크게 개선한다. GitHub 중심이면 Codespaces, 실행 기반을 선택하고 싶으면 DevPod, 학습이나 시작이면 Replit이 알기 쉽다. 단, 지연·과금·비밀정보 취급은 반드시 설계에 포함시켜야 합니다.
4. 버전 관리 (Git)
이 섹션이 답하는 질문: 왜 파일을 "다른 이름으로 저장"하는 것만으로는 안 되는가?
왜 필요한가
보고서를 작성할 때,
report_v1.docx, report_v2_final.docx, report_v2_final_진짜_final.docx와 같이 파일이 증식한 경험은 없는가. 혼자도 이런 상태인데, 팀에서 같은 파일을 동시에 편집하면 어떻게 될까. 누가 언제 무엇을 변경했는지 알 수 없게 되고, 덮어쓰기 사고가 발생하며, 어제까지 동작하던 코드가 갑자기 망가진다.
Git은 이 문제를 해결하는 버전 관리 시스템이다. 모든 변경 이력을 기록하고, 언제든지 과거 상태로 되돌릴 수 있다. 여러 명이 동시에 작업해도, 변경을 안전하게 통합(머지)할 수 있다.
2026년 현재, Git은 사실상의 업계 표준이며, Git을 사용하지 않는 개발 현장은 거의 존재하지 않는다.
Git의 기본 개념을 4가지만 파악하면 충분하다:
GitHub는 Git의 리포지토리를 인터넷에 호스팅하는 서비스. Git 자체와는 별개이지만, 팀 개발에서는 거의 세트로 사용된다. 경쟁 서비스로는 GitLab, Bitbucket이 있다.
선정 판단 기준
Git 자체에는 선택지가 없다(업계 표준이 Git 하나). 선택하는 것은 호스팅 서비스 쪽이다:
� 국내 현황: 국내 스타트업과 IT 대기업의 대부분은 GitHub를 사용한다. 공공기관·금융권의 경우 보안 정책상 GitLab 셀프 호스트나 국내 SaaS(NCP DevOps 등)를 사용하는 사례가 늘고 있다. Bitbucket은 Atlassian 제품군(Jira, Confluence)을 통합 사용하는 팀에서 선택된다.
# 한국 개발 환경 Git 초기 설정
git config --global user.name "홍길동"
git config --global user.email "gildong@example.com"
# 한글 파일명 깨짐 방지 (필수)
git config --global core.quotepath false
# 줄바꿈 코드 설정 (macOS/Linux: input, Windows: true)
git config --global core.autocrlf input
# 기본 브랜치명을 main으로 (GitHub 표준)
git config --global init.defaultBranch main
# 커밋 메시지 편집기 설정 (VS Code 사용 시)
git config --global core.editor "code --wait"
실무에서의 주의점
⚠️ 비밀번호나 API 키를 절대로 커밋하지 않는다. 한번 Git에 기록된 정보는, 커밋을 지워도 이력에 계속 남는다. .gitignore 파일로 기밀정보를 포함한 파일을 제외하는 습관을 들이자. .env 파일은 반드시 .gitignore 에 추가한다.
⚠️ 커밋 메시지는 "무엇을 했는가"가 아닌 "왜 했는가"를 작성한다. Fix bug가 아닌 사용자가 로그인할 수 없는 문제를 수정 (세션 유효기간 체크가 누락되어 있었음)처럼 작성하면 나중에 읽었을 때 문맥을 알 수 있다.
⚠️ 국내 기업 커밋 컨벤션: 많은 국내 기업이 Conventional Commits(feat:, fix:, docs:, refactor: 등) 규칙을 채택한다. 팀 합류 시 먼저 CONTRIBUTING.md나 README.md를 확인하는 습관을 들이자.
정리
Git은 소프트웨어 개발의 "읽기·쓰기·계산"에 해당하는 필수 스킬. 리포지토리, 커밋, 브랜치, 머지의 4가지 개념을 이해하면 기본은 충분하다. 호스팅은 GitHub가 가장 무난한 선택지다.
5. 패키지 매니저와 런타임 관리
이 섹션이 답하는 질문: 왜 공식 사이트에서 인스톨러를 다운로드하는 것만으로는 안 되는가?
왜 필요한가
개발에서는 많은 도구와 라이브러리를 사용한다. Node.js, Python, 데이터베이스, 각종 커맨드라인 도구…… 이것들을 하나씩 공식 사이트에서 다운로드해서 설치하면, 업데이트 관리가 번거로워지고, 버전 불일치로 문제가 발생한다.
더 성가신 것은, 프로젝트A에서는 Node.js 18을, 프로젝트B에서는 Node.js 22를 사용하고 싶은 상황이다. PC에 하나의 버전만 설치되어 있으면 전환이 번거로워진다.
패키지 매니저: 도구의 설치·업데이트·삭제를 자동화하는 구조
런타임 버전 관리 도구: 여러 버전의 전환을 가능하게 하는 구조
패키지 매니저 (OS 레벨):
런타임 버전 관리:
선정 판단 기준
여러 언어를 다루면
mise나 asdf와 같은 다언어 대응 도구가 다루기 쉽다.
mise는 asdf의 .tool-versions도 읽을 수 있기 때문에, 기존 프로젝트와의 호환성을 유지하기 쉽다.
하나의 언어만 사용한다면, 그 언어 전용 도구(nvm, pyenv)로도 충분하다.
# mise 설치 및 초기 설정
curl https://mise.run | sh
echo 'eval "$(~/.local/bin/mise activate zsh)"' >> ~/.zshrc
source ~/.zshrc
# 프로젝트별 버전 고정 (.mise.toml)
mise use node@20 # Node.js LTS
mise use python@3.12 # Python 최신 안정판
mise use go@1.22
# 현재 설정 확인
mise ls
실무에서의 주의점
⚠️ sudo를 붙여 글로벌로 설치하는 것은 피한다.
권한 문제로 나중에 트러블이 발생한다. Homebrew나 mise를 사용하면 사용자 권한 범위 내에서 도구를 관리할 수 있다.
정리
공식 사이트에서 수동으로 설치하는 것은 최초 1회에만 하자. 이후는 Homebrew(macOS)나 apt(Linux)로 도구를 관리하고, 언어 버전 관리에는 mise나 asdf와 같은 도구를 사용한다. 이를 통해 "저 프로젝트에서는 Node.js 몇 버전이었지?" 문제에서 해방된다.
6. 컨테이너에 의한 로컬 개발
이 섹션이 답하는 질문: Docker란 무엇인가? 왜 개발에 필요한가?
왜 필요한가
"내 PC에서는 동작하는데, 동료 PC에서는 동작하지 않는다" - 이 문제는 OS의 차이뿐만 아니라, 라이브러리 버전 차이, 설정 파일의 차이, 데이터베이스 유무 등 무수한 원인으로 발생한다.
컨테이너 기술은 "애플리케이션과 그 동작에 필요한 것 전부를 상자에 담는" 기술이다. 물류의 컨테이너가, 내용물과 관계없이 같은 규격의 상자로 운반할 수 있듯이, 소프트웨어의 컨테이너도 "상자째 건네줌"으로써 환경의 차이를 흡수한다.
선정 판단 기준
macOS / Windows의 로컬 개발에서는 Docker Desktop을 기준으로 생각하는 것이 알기 쉽다. Docker Desktop에는 Docker Engine, Docker CLI, Compose가 포함되어 있으며, Docker 공식도 도입 경로의 하나로 안내하고 있다. Linux에서는 Docker Engine과 Compose 플러그인을 직접 설치하는 구성도 일반적이다.
대안으로 OrbStack(macOS 전용)이 있다. 경량 선택지로서, macOS 사용자의 후보에 들어온다.
국내 스타트업에서는 Docker Desktop을 기본으로 사용하는 경우가 많다. Apple Silicon Mac 환경에서 Docker Desktop의 메모리 소비가 부담스럽다면 OrbStack이 유력한 대안이다.
# compose.yaml — 국내 웹서비스 전형적인 로컬 개발 구성
services:
app:
build: .
ports:
- "3000:3000"
volumes:
- .:/app
- /app/node_modules
environment:
- NODE_ENV=development
- DATABASE_URL=postgresql://postgres:password@db:5432/myapp
depends_on:
db:
condition: service_healthy
db:
image: postgres:16-alpine
environment:
POSTGRES_PASSWORD: password
POSTGRES_DB: myapp
volumes:
- pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
timeout: 5s
retries: 5
cache:
image: redis:7-alpine
ports:
- "6379:6379"
volumes:
pgdata:
실무에서의 주의점
⚠️ Docker Desktop은 macOS/Windows에서 메모리를 많이 소비한다. 메모리 8GB의 PC에서는 개발이 힘들어지기 때문에, 최소 16GB를 권장한다. Apple Silicon Mac이라면 OrbStack 도입도 검토한다.
⚠️ Docker는 "운영 환경에서도 사용하는" 기술이며, 로컬 개발만의 도구가 아니다. 여기서 기초를 익혀두면, 클라우드 서비스(7장)와 CI/CD(10장)의 이해가 원활해진다.
⚠️ 국내 클라우드 연계: NCP(네이버 클라우드), Kakao Cloud, KT Cloud 등 국내 CSP를 사용하는 경우에도 Docker 이미지는 그대로 배포할 수 있다. 컨테이너 레지스트리(NCP Container Registry 등)를 활용한다.
정리
Docker는 "환경째 상자에 담아 나눠주는" 기술. 팀 개발의 환경 차이 문제를 크게 줄일 수 있다. 먼저 Docker Desktop 또는 팀 표준 구현을 사용하여, Dockerfile과 Compose의 설정 파일(compose.yaml
이나 docker-compose.yml)을 읽을 수 있게 되면 충분하다.
7. dotfiles와 개발 환경 재현성
이 섹션이 답하는 질문: PC를 교체했을 때, 개발 환경을 빠르게 복원하려면?
왜 필요한가
개발 환경의 셋업에는, 셸 설정, 에디터의 플러그인, Git 설정, 각종 도구의 설치 등, 수십 가지 절차가 있다. 이것을 매번 수작업으로 하는 것은 시간 낭비이며, 빠뜨림과 실수의 원인이 된다.
PC 고장, 교체, 새 팀 멤버의 온보딩 — 개발 환경을 "제로부터 재현"하는 장면은 반드시 찾아온다.
전체 그림
dotfiles는 Unix 계열 OS에서 .으로 시작하는 설정 파일의 총칭이다. .zshrc, .gitconfig, .vimrc 등이 이에 해당한다. 이것들을 Git 리포지토리로 관리하고, 셋업 스크립트를 준비해 두면, 새 PC에서도 명령어 하나로 같은 환경을 재현할 수 있다.
dotfiles 리포지토리의 전형적인 구성:
# Brewfile 예시 (macOS 개발 환경 표준 도구)
# brew bundle dump 로 현재 환경 출력 가능
tap "homebrew/bundle"
# 기본 도구
brew "git"
brew "mise"
brew "starship"
brew "ripgrep"
brew "fzf"
brew "bat" # cat 개선판
brew "eza" # ls 개선판
brew "zoxide" # cd 개선판
brew "gh" # GitHub CLI
# 에디터
cask "visual-studio-code"
cask "cursor"
# 기타
cask "docker"
cask "iterm2"
선정 판단 기준
dotfiles의 관리 방법은 심플한 편이 좋다:
초보자는 Git + 심볼릭 링크로 충분하다. 여러 머신에서 미묘하게 설정을 변경하고 싶은 경우는
chezmoi를 검토한다.
실무에서의 주의점
⚠️ dotfiles 리포지토리를 공개(public)로 하는 경우, API 키나 토큰이 포함되어 있지 않은지 반드시 확인한다. .gitconfig에 GitHub 토큰을 작성했다는 사고는 드물지 않다.
⚠️ Homebrew 사용자는 brew bundle dump로 현재 설치된 도구 목록을 Brewfile에 출력할 수 있다. 새 PC에서는 brew bundle install로 일괄 복원할 수 있다.
⚠️ 회사 PC와 개인 PC 분리: 회사 PC의 dotfiles에 개인 계정 정보나 개인 프로젝트 설정이 포함되지 않도록 주의한다. ~/.gitconfig.local을 별도로 두고 include로 불러오는 패턴이 유용하다.
# ~/.gitconfig
[include]
path = ~/.gitconfig.local # 머신별 설정 (공개 리포지토리에 포함하지 않음)
# ~/.gitconfig.local (gitignore로 제외)
[user]
name = 홍길동
email = gildong@company.com
signingkey = ABCDEF123456
정리
dotfiles를 Git으로 관리하고, 셋업 스크립트를 준비해 두면, PC 교체나 새 멤버의 온보딩이 극적으로 편해진다. 먼저 .zshrc와 .gitconfig 2개 파일부터 시작하면 충분하다. "환경 구성의 재현성"은, 팀 개발의 생산성을 좌우하는 소박하지만 중요한 요소다.
8. AI 시대의 현재 위치: 개발 환경의 2026년 스냅샷
이 섹션이 답하는 질문: 2026년 시점에서, AI 도구는 개발 환경 안에서 어떻게 자리매김해야 하는가?
왜 필요한가
AI를 무시하고 개발 환경을 이야기하는 것은, 현재로서는 부자연스러워졌다. 주요 에디터, IDE, 터미널 도구, GitHub 위의 개발 플로까지, AI를 전제로 한 기능이 내장되어 있기 때문이다.
단, "AI를 사용하는가 아닌가"는 이미 논점이 아니다. 정말 중요한 것은, 어디까지 맡길 것인가, 어떻게 품질을 지킬 것인가, 팀의 규칙을 어떻게 공유할 것인가다.
2026년의 AI 도구는, 대체로 다음의 3계층으로 나뉜다.
이전에는 "에디터 옆에 있는 채팅 도구"라는 위치였지만, 현재는 에디터·터미널·리뷰 공정 자체에 파고들어 있다.
선정 판단 기준
하나의 도구로 모든 것을 해결하려 하지 않는 편이 좋다. 현실적으로는, 다음 조합이 다루기 쉽다.
일상 작업용 에디터 AI를 하나 선택한다. VS Code + Copilot, Cursor, JetBrains AI Assistant 등.
무거운 변경용 에이전트를 하나 갖는다. Claude Code나 Copilot coding agent처럼, 자율도가 높은 도구를 보조선으로서 사용한다.
품질 관리는 종래대로 사람과 자동화로 담보한다. 테스트, 린터, 타입 체크, 리뷰는 여전히 필수다.
� 국내 AI 도구 도입 현황: 토스, 카카오, 네이버 등 국내 주요 IT 기업에서도 GitHub Copilot 또는 사내 LLM 기반 코딩 보조 도구를 도입하고 있다. 금융·공공 도메인에서는 사내 폐쇄망 LLM 도입 사례도 증가 중이다.
AGENTS.md - AI 규칙 파일 예시
# AGENTS.md (리포지토리 루트에 배치)
## 코딩 컨벤션
- TypeScript strict 모드 사용
- 함수 주석은 JSDoc 형식 (한국어 허용)
- 커밋 메시지는 Conventional Commits 형식
## 금지 사항
- console.log를 프로덕션 코드에 남기지 않을 것
- any 타입 사용 금지 (부득이한 경우 // TODO: 주석 필수)
- 환경변수는 반드시 .env.example에 키 이름을 추가할 것
## 테스트
- 새 기능에는 반드시 Vitest 단위 테스트 추가
- 커버리지 80% 이상 유지
실무에서의 주의점
⚠️ AI 리뷰는 사람 리뷰의 대체가 아니다. GitHub도 Copilot code review를 "사람의 리뷰를 보완하는 것"으로 위치지운다. 생성 코드도 리뷰 코멘트도, 그대로 무비판적으로 받아들이면 안 된다.
⚠️ 리포지토리 고유 규칙을 문서화한다. 2026년의 개발 환경에서는, AI에 무엇을 지키게 할 것인가가 생산성을 좌우한다. AGENTS.md, 에디터 고유의 규칙 파일, 리뷰 지침을 놓아두면, AI 출력의 흔들림을 크게 줄일 수 있다.
⚠️ 주니어일수록 "생성시키기"보다 "설명시키기" 사용법부터 시작하는 것이 좋다. 먼저 코드의 설명, 테스트 케이스 안, 리팩토링 안에 사용하고, 차분을 읽을 수 있게 된 후에 자동 편집 비율을 높이는 편이 안전하다.
정리
2026년의 개발 환경에서, AI는 독립된 별도 도구가 아닌, 에디터·터미널·리뷰 공정에 내장된 일부가 되었다. 단, AI에 맡길수록, 규칙·테스트·리뷰의 중요성은 오히려 증가한다. "AI를 사용한다"보다 "AI를 제어할 수 있는 환경을 만든다"는 것이 중요하다.
✅ 이 장의 체크리스트
자신의 OS로 개발을 시작하는 절차(macOS → Homebrew / Windows → WSL2 / Linux → apt)를 설명할 수 있는가?
"터미널"과 "셸"의 차이를 다른 사람에게 설명할 수 있는가?
zsh / bash / fish의 차이와, 초보자에게 어느 것을 추천하는지 근거를 가지고 답할 수 있는가?
VS Code / Cursor / JetBrains / Claude Code의 역할 차이를 설명할 수 있는가?
로컬 개발 환경과 클라우드 개발 환경을 어떻게 구분하여 사용하는지 설명할 수 있는가?
개발 환경의 "재현성"이 왜 중요한지를 설명할 수 있는가?
Git의 4가지 핵심 개념(리포지토리·커밋·브랜치·머지)과 한국어 Git 설정(core.quotepath false)을 설명할 수 있는가?
Docker와 컨테이너가 "내 PC에서는 되는데" 문제를 어떻게 해결하는지 설명할 수 있는가?
dotfiles를 Git으로 관리하는 목적과 방법을 설명할 수 있는가?
AI 도구를 "사용하는" 것과 "제어하는" 것의 차이를 설명할 수 있는가?
⚠️ 편집 노트: 본 문서는 지속적으로 보완 중입니다. 각 섹션의 코드 예제 및 국내 환경 적용 사례는 실무 피드백을 반영하여 업데이트될 예정입니다.
©2024-2026 MDRules dev., Hand-crafted & made with Jaewoo Kim.
이메일문의: jaewoo@mdrules.dev
AI강의/개발/기술자문, AI 업무 자동화 컨설팅 문의: https://talk.naver.com/ct/w5umt5
AI 프롬프트 및 워크플로우 설계 대행: https://mdrules.dev