LangTailor

Lesson

개발 환경과 인프라

가상환경과 패키지 관리에서 시작해 Docker, Git, 클라우드 서비스 모델까지 개발을 둘러싼 환경을 다룹니다.

8개 주제

01

가상환경을 골프로 이해하기

골프카가 프로젝트별 독립 환경(가상환경)이고, 골프가방이 requirements.txt, 골프채가 라이브러리다. 카트마다 다른 채를 실을 수 있어서 프로젝트끼리 서로 간섭하지 않는다.

가상환경을 골프로 이해하기
  • 골프카 = Anaconda / Virtual Env — 프로젝트별 독립적인 이동 수단
  • 골프가방 = requirements.txt — 필요한 도구의 명세서이자 의존성 정의
  • 골프채 = 라이브러리 (Pandas, NumPy, TensorFlow, Matplotlib)
  • 골퍼 = 메인 객체/스크립트 — 도구를 실제로 사용하는 주체
  • `pip install -r requirements.txt` 실행 = 채를 카트에 싣는 과정
02

`__init__.py` — 폴더를 패키지로 만들기

파이썬은 그냥 폴더를 단순 저장소로만 본다. `__init__.py`가 들어가는 순간 그 폴더는 공식적인 부품 세트(패키지)가 되어 import 대상이 된다.

`__init__.py` — 폴더를 패키지로 만들기
  • 일반 폴더: 파이썬이 단순 저장소로 인식 — 도구로 쓰기 어렵다
  • `__init__.py` 추가: 초기화 및 신분증 역할 (Initialization & ID)
  • 패키지: 공식적인 부품 세트로 인식되어 도구/객체로 바로 활용 가능
03

환경 변수와 민감 정보 보호

`.env` 파일은 키(Key)와 설정값(Value)의 쌍으로 이루어진 컨텍스트다. DB 접속 정보나 API 키가 여기 들어가며, 반드시 `.gitignore`로 막아 저장소에 올라가지 않게 해야 한다.

환경 변수와 민감 정보 보호
  • 형식: `KEY=VALUE` — 예) `DATABASE_URL=...`, `GEMINI_API_KEY=...`
  • `.env`는 서버에만 두고, `.gitignore`에 등록해 Git에 올라가지 않게 한다
  • 설정값이 노출되면 곧바로 보안 사고로 이어진다
04

Docker를 객체지향으로 이해하기

Docker의 핵심 3요소가 객체지향 개념과 정확히 대응된다. 이미지는 클래스(설계도), 컨테이너는 인스턴스(실체), 볼륨은 외부 저장소다.

Docker를 객체지향으로 이해하기
  • 이미지(Image) → 클래스(Class): 변경 불가능한 템플릿, 정적(읽기 전용)
  • 컨테이너(Container) → 인스턴스(Instance): 이미지로 만든 살아 있는 격리 프로세스, 동적(읽기·쓰기)
  • 볼륨(Volume) → 디스크(Storage): 컨테이너가 멈춰도 사라지지 않는 외부 영속 저장소
  • 하나의 이미지로 여러 컨테이너를 동시에 만들 수 있다 — 클래스와 인스턴스의 관계 그대로
05

로컬과 클라우드의 대응 관계

소스코드·실행환경·AI 모델 세 영역 모두 '내 컴퓨터에서 만들고 클라우드에 올려 공유한다'는 같은 패턴을 따른다. 짝을 지어 외우면 도구의 역할이 명확해진다.

로컬과 클라우드의 대응 관계
  • 소스코드 관리: Git(로컬 버전 관리) ↔ GitHub(원격 저장·협업 Push/Pull)
  • 애플리케이션 환경 관리: Docker(로컬 컨테이너 실행) ↔ Docker Hub(이미지 중앙 저장소)
  • AI 모델 공유·배포: Model(로컬 가중치 파일, GPU 추론) ↔ Hugging Face(모델 오픈소스 허브)
06

IaaS · PaaS · SaaS

클라우드 서비스는 '어디까지를 제공자가 책임지느냐'로 나뉜다. 피자로 비유하면 재료만 사와서 집에서 굽느냐, 배달시켜 내 그릇에 담느냐, 아예 식당에서 먹느냐의 차이다.

IaaS · PaaS · SaaS
  • IaaS: VM·스토리지·네트워크만 제공 — 사용자가 OS·미들웨어·앱·데이터를 관리 (피자 키트)
  • PaaS: 개발 플랫폼과 런타임까지 제공 — 사용자는 앱과 데이터만 관리 (피자 배달)
  • SaaS: 완성된 소프트웨어 제공 — 제공자가 모든 것을 관리 (식당에서 식사)
07

모노레포 vs 멀티레포 — AI 활용 관점

AI 코딩 어시스턴트가 등장하면서 저장소 구조의 의미가 달라졌다. 모노레포는 AI가 전체 코드베이스를 한 번에 볼 수 있지만, 멀티레포는 저장소마다 문맥이 끊긴다.

모노레포 vs 멀티레포 — AI 활용 관점
  • 모노레포: 전체 컨텍스트 가시성, 모든 모듈 대상 검색(RAG), 모듈 간 영향도 분석 가능
  • 멀티레포: 문맥 파편화, 검색 범위가 한 저장소로 제한, 숨은 의존성 추적 어려움
  • AI 활용도를 기준으로 보면 모노레포 쪽이 유리하다
08

Next.js → FastAPI → PostgreSQL 스택

현대 풀스택 구성의 표준 조합이다. 화면은 Next.js, 로직과 AI 처리는 FastAPI, 영속 데이터는 PostgreSQL이 담당하며 각 계층은 HTTP와 ORM으로 연결된다.

Next.js → FastAPI → PostgreSQL 스택
  • 프론트엔드/UI 계층 — Next.js: 사용자 인터페이스, SSR/SSG
  • 백엔드/로직 계층 — FastAPI: 고성능 비동기 파이썬, 비즈니스 로직, AI 모델 처리, 자동 API 문서화
  • 데이터베이스 계층 — PostgreSQL: 관계형 DBMS, ACID 준수, 확장 가능한 저장소
  • 장점: AI·데이터를 위한 파이썬 생태계, 빠른 API 개발, 견고한 데이터 저장