AI 시대, 나는 개발 환경을 고정하기로 했다
들어가기
최근 몇 년 사이, 개발자의 선택지는 폭발적으로 늘어났어요.
이전에는 언어, 프레임워크, 인프라가 주된 고민이었다면, 지금은 어떤 AI 모델과 어떤 도구를 쓸지부터 결정해야 해요.
문제는 여기서 시작됐어요.
- 새로운 도구가 계속 등장해요
- 매번 비교하고 갈아타요
- 선택 자체가 또 하나의 업무가 돼요
결국 생산성은 코드가 아니라 선택 피로에서 먼저 깎였어요.
2. 문제를 어떻게 정의했는가
처음에는 "더 좋은 도구를 찾으면 해결된다"고 생각했어요. 실제로 모델, IDE 플러그인, 코딩 에이전트를 꽤 많이 바꿔봤어요.
하지만 반복 실험 끝에 결론은 반대였어요.
생산성은 더 많은 도구에서 나오지 않았어요.
사고 흐름이 끊기지 않는 고정된 환경에서 나왔어요.
그래서 문제를 이렇게 다시 정의했어요.
"최신 도구를 찾아다니는 문제"가 아니라,
"지속 가능한 개발 시스템을 설계하는 문제"
3. 제가 고정한 Core AI Stack
| Tool | Description | Official |
|---|---|---|
| Atlas Browser | AI-integrated research browser | https://atlas.openai.com |
| ChatGPT | Reasoning / research / planning assistant | https://chat.openai.com |
| Codex | AI coding agent | https://openai.com/codex |
선정 기준은 3가지였어요.
- 장기적으로 유지 가능한 ecosystem인가
- 현재 workflow에 자연스럽게 붙는가
- 코딩뿐 아니라 설계/리서치까지 확장되는가
이 기준으로 역할을 분리해 고정했어요.
- Atlas: 리서치 속도
- ChatGPT: 설계 검토, 사고 정리
- Codex: 구현, 반복 작업 가속
핵심은 "많이 쓰는 것"이 아니라 "겹치지 않게 쓰는 것"이었어요.
4. Development Stack은 왜 최소 변경으로 갔는가
| Tool | Description | Official |
|---|---|---|
| IntelliJ IDEA | Backend development IDE | https://www.jetbrains.com/idea/ |
| DataGrip | Database IDE | https://www.jetbrains.com/datagrip/ |
| Warp | AI terminal | https://www.warp.dev |
| Postman | API testing | https://www.postman.com |
개발 속도는 "도구 개수"보다 "전환 비용"에 더 크게 좌우됐어요.
코드 작성 → DB 검증 → API 테스트 → 운영 확인
이 루프를 매일 반복하는 입장에서, 도구를 늘리는 것보다 마찰을 줄이는 쪽이 훨씬 효과적이었어요.
5. Knowledge Stack을 분리한 이유
| Tool | Description | Official |
|---|---|---|
| Notion | Team knowledge base | https://www.notion.so |
| Obsidian | Personal knowledge graph | https://obsidian.md |
AI 시대에는 기억력보다 검색력이 중요해졌어요. 정확히는 필요한 컨텍스트를 빠르게 꺼내 LLM에 넣는 능력이 중요해졌어요.
그래서 아래 항목을 별도 저장소처럼 관리하고 있어요.
- 설계 판단 근거
- 장애 대응 기록
- 프롬프트 템플릿
- 운영 명령어 스니펫
6. 현재 운영하는 Workflow
Atlas Research
탐색 범위를 정의하고 레퍼런스를 빠르게 모읍니다.
이 구조의 목적은 단순해요.
- 리서치와 구현 사이의 문맥 단절을 줄여요
- 구현과 검증 사이 왕복 비용을 줄여요
- 반복 가능한 루프를 만들어요
7. 제 환경에서 실제로 쓰는 Homebrew 도구
실제로 매일 쓰는 Formula만 추려서 정리했어요.
| Formula | Description | Install | Version |
|---|---|---|---|
mole | SSH 기반에서 원격 서버의 동일 세션을 안전하게 공유하는 터미널 협업 도구 | GitHub / Homebrew | 1.25.0 |
nvm | 프로젝트별 Node.js 버전을 격리해 런타임 충돌을 줄이는 버전 매니저 | Homebrew | 0.40.3 |
k6 | API/시나리오 기반 부하 테스트를 코드로 자동화하는 성능 검증 도구 | Homebrew | 1.4.2 |
duckdb | 로컬에서 대용량 데이터를 SQL로 빠르게 탐색/분석하는 OLAP 엔진 | Homebrew | 1.4.2 |
ffmpeg | 인코딩, 리사이징, 포맷 변환 등 미디어 파이프라인 처리 도구 | Homebrew | 8.0.1 |
추가로 설치 속도 관점에서는 ZeroBrew도 꽤 괜찮은 대안이에요.
Homebrew를 대체하기보다는, 초기 셋업이나 반복 설치가 많은 환경에서 병행 검토할 만하다고 봐요.
정리하면서 다시 느꼈죠. 툴을 많이 아는 것보다, 제 흐름에 맞는 도구를 고정해 오래 쓰는 것이 더 중요했어요.
8. 개발 환경을 고정하기로 결정한 이유
초기에는 새 도구를 빠르게 실험하는 것도 필요해요. 하지만 어느 시점 이후에는 선택 자체가 생산성을 갉아먹어요.
그래서 아래 전략으로 바꿨어요.
- Core AI stack 고정
- 개발 도구 최소 변경
- workflow 자산화
- 자동화 가능한 작업은 시스템화
단기 최적화보다 장기 생산성 곡선을 선택한 셈이에요.
9. 앞으로의 방향
앞으로 개발자의 경쟁력은 단순 숙련도만으로 설명되지 않는다고 봐요.
- 문제 해결 속도
- 학습 속도
- AI workflow 설계 능력
- 지식 자산화 능력
저는 이 네 가지를 높이는 방향으로, 지금의 고정 스택 위에서 자동화 범위를 계속 확장할 계획이에요.
마무리
도구 선택은 취향의 문제가 아니에요. 사고 흐름을 얼마나 덜 끊는가의 문제예요.
실험 끝에 내린 결론은 명확해요.
더 많은 도구보다, 더 안정적인 시스템이 생산성을 만들어요.