1강. 터미널에서 VSCode로 — 왜 편집기인가
0. 학습 목표
→ 터미널·편집기 방식의 불편을 확인하고, IDE가 그것을 어떻게 해결하는지 이해합니다.
0.1 이번 글에서 다룰 내용
이번 글은 개념 중심 강의입니다.
지난 시리즈 마지막에 우리는 nano 편집기로 main.py에 코드를 넣고, 터미널에서 python main.py로 실행했습니다. 그 방식으로도 프로그램은 잘 동작했습니다.
그런데 코드가 몇십 줄만 넘어가도 이 방식은 불편해지기 시작합니다.
이번 강의에서는 무엇이 불편한지 구체적으로 짚고, IDE라는 도구가 그 불편을 어떻게 없애주는지 확인합니다.
여기서 세우는 문제의식이 이 시리즈 전체의 출발점입니다.
| 구분 | 내용 |
| 이해할 것 | 터미널·편집기 방식에서 코드가 커질수록 생기는 다섯 가지 불편 |
| 정리할 것 | 편집기(Editor)와 IDE의 차이, VSCode의 위치 |
| 확인할 것 | 각 불편이 이 시리즈 어느 강의에서 해결되는지 대응 관계 |
1. 지난 방식의 불편 확인하기
→ nano와 터미널로 개발할 때 코드가 커지면 무엇이 힘들어지는지 정리합니다.
지난 파이썬 가상환경 이해에서 main.py에 넣었던 코드를 떠올려 보겠습니다.
창을 하나 띄우는 짧은 프로그램이었습니다.
import sys
from PySide6.QtWidgets import QApplication, QWidget, QLabel, QVBoxLayout
app = QApplication(sys.argv)
window = QWidget()
window.setWindowTitle("환경 재현 성공")
# (이하 생략)이 정도 길이는 nano로도 괜찮습니다.
하지만 실제 프로그램은 수백, 수천 줄로 자랍니다. 그때 터미널 편집기 방식은 다음과 같은 불편을 드러냅니다.
| 불편한 점 | 구체적인 상황 |
| 오타를 실행해야만 안다 | QApplicaton처럼 철자를 틀려도 편집기는 아무 표시가 없고, 실행하고 나서야 오류로 알게 됩니다 |
| 긴 이름을 매번 다 쳐야 한다 | setWindowTitle 같은 이름을 자동완성 없이 한 글자씩 입력해야 합니다 |
| 코드가 다 같은 색이다 | 키워드·문자열·주석이 구분되지 않아 긴 코드에서 구조가 눈에 안 들어옵니다 |
| 편집·실행·확인이 흩어져 있다 | 편집(nano)과 실행(터미널)을 오가야 하고, 값이 이상하면 print를 넣었다 지웠다 반복합니다 |
| 어떤 Python이 실행되는지 헷갈린다 | 시스템 Python과 가상환경 Python이 섞이면, 같은 코드가 다른 결과를 냅니다 |
특히 마지막 두 가지가 큽니다. 코드 구조가 한눈에 안 들어오면 실수가 늘고, 값이 왜 이상한지 확인하려면 print를 여기저기 박았다가 다시 지우는 번거로운 작업을 반복해야 합니다. 지난 시리즈에서 print 말고는 값을 들여다볼 방법이 없었던 것을 떠올려 보면 이 불편이 실감 날 것입니다.
2. Editor와 IDE — 무엇이 다른가
→ 단순 편집기와 IDE의 차이를 정리하고, VSCode가 어느 쪽인지 확인합니다.
앞의 불편들을 통합 해결하는 도구가 있습니다.
IDE(Integrated Development Environment), 우리말로 통합 개발 환경입니다.
이름 그대로 편집·실행·오류 확인·디버깅처럼 흩어져 있던 개발 작업을 한 도구로 통합했다는 뜻입니다.
nano는 글자를 넣고 지우는 편집기(Editor)입니다.
IDE는 편집 기능에 더해 개발을 돕는 여러 기능을 함께 제공합니다.
둘의 차이를 정리하면 다음과 같습니다.
| 기능 | Editor (편집기) | IDE (통합 개발 환경) |
| 글자 편집 | 가능 | 가능 |
| 문법 강조·오류 표시 | 없음 | 있음 |
| 자동완성 | 없음 | 있음 |
| 코드 실행 | 별도 터미널 필요 | 도구 안에서 실행 |
| 디버깅 | 없음 | 있음 |
VSCode(Visual Studio Code)는 가볍고 빠른 편집기로 시작해, 확장을 더하면 IDE 수준의 기능을 갖추는 도구입니다.
초급자가 처음 쓰기에 부담이 적으면서도, Python 개발에 필요한 위 기능들을 모두 사용할 수 있습니다.
무료이고 Windows·macOS·Ubuntu에서 모두 동작한다는 점도 널리 쓰이는 이유입니다.
3. VSCode가 이 시리즈에서 해결해 줄 것
→ 1번에서 정리한 불편들이 앞으로 어느 강의에서 해결되는지 연결합니다.
1번에서 정리한 불편 하나하나가 이 시리즈의 강의로 이어집니다.
이번 강의는 "왜 배우는가"를 세우는 자리이고, 실제 해결은 다음 강의부터 시작됩니다.
| 지난 방식의 불편 | VSCode의 해결 | 해당 강의 |
| 오타를 실행해야만 안다 / 코드가 다 같은 색 | 문법 강조·오류 표시 | 3강 |
| 긴 이름을 매번 다 쳐야 한다 | 자동완성 | 3강 |
| 어떤 Python으로 실행되는지 헷갈린다 | 인터프리터 연결 | 4강 |
| 편집과 실행을 오가야 한다 | 도구 안에서 실행 | 5강 |
값 확인을 print로 반복해야 한다 |
중단점 디버깅 | 6~7강 |
표의 마지막 줄이 이 시리즈의 핵심 보상입니다.
지난 시리즈에서는 값이 이상해도 print로 찍어 보는 것 말고는 방법이 없었지만, VSCode에서는 코드를 원하는 지점에서 멈춰 세우고 그 순간의 값을 화면에서 직접 들여다볼 수 있습니다.
이 경험을 6강에서 하게 됩니다.
한 가지 미리 짚어둘 것이 있습니다. VSCode는 편집·실행을 도와주는 도구일 뿐, 가상환경을 대신하지 않습니다.
지난 시리즈에서 만든 .venv는 그대로 쓰이고, VSCode는 그 .venv를 대신 실행해 주는 창구 역할을 합니다.
이 점이 위 표의 "인터프리터 연결(4강)"에서 다시 등장합니다.
→ 다음 강의 (2강): VSCode를 Ubuntu에 설치하고, 지난 시리즈에서 만든 ~/Dev/Project 폴더를 VSCode로 열어봅니다.