성수역 무료주차장 완전정복! 현지인이 알려주는 꿀팁

서울 성수동은 카페거리·서울숲·감각적인 편집숍 덕분에 ‘핫플’로 떠오른 곳이죠. 하지만 유명세만큼이나 주차난도 심각합니다. 매번 비싼 주차요금에 지갑이 얇아졌다면, 오늘 소개할 ‘무료 또는 거의 무료’ 주차장 5선을 활용해 보세요. 현지 주민‧직장인들이 애용하는 장소와, 요즘 뜨는 모두의주차장 앱 활용법까지 모아 Part 1 ~ Part 5에 걸쳐 자세히 정리했습니다.

Part 1 — 성수역 주차, 왜 이렇게 어려울까?

▶ 좁은 골목·일방통행: 성수동 골목은 의류 창고를 리모델링한 카페, 공방이 다닥다닥 붙어 있어 차선이 협소합니다.
▶ 주말·저녁 인파 폭증: 방문객 대부분이 비슷한 시간대(주말 오후)에 몰려 주차장이 순식간에 만차가 되죠.
▶ 민간 빌딩 지하주차장은 ‘투숙·구매 고객 전용’: 무신사 스탠다드, 대기업 F&B 쇼룸 등은 자체 고객 외 주차를 제한해 외부 차량 유입이 어렵습니다.
하지만 ‘공영주차장의 운영시간 외 무료 개방’이라는 틈새를 알면 지갑 부담을 대폭 줄일 수 있습니다!

Part 2 — 현지인이 즐겨 찾는 무료·저렴 주차장 TOP 5

1. 성수역 3번 출구 앞 공영주차장 (66면)
   평일 09:00‒18:00, 토 09:00‒15:00까지만 유료(30분 1,500원)이고 그 외 시간·일요일은 전면 무료입니다.
2. 뚝도시장 공영주차장 (노상)
   성수 카페거리 끝자락에 있어 회전율이 좋아요. 요금·무료 시간은 3번 출구 주차장과 동일.
3. KT 성수분국 노상 공영주차장
   주말은 종일 무료, 평일 야간(18:00‒09:00) 무료라 토·일 카페 투어에 특히 인기! 골목길 진입 시 보행자 주의.
4. 성수 2가 3동 공영주차장 (실내·167면)
   24시간 영업이지만 5분 100원(1시간 1,200원)으로 서울권 ‘거의 무료’ 가격. 우천·혹한기에 추천.
5. 성수 1가 1동 공영주차장 (30면 내외)
   서울숲 도보 6분. 경차·친환경차·다둥이 가정 50% 감면. 주차장 내부 화장실·장애인 전용석 완비.

Part 3 — 무료 시간표·이용 팁 한눈에 보기

Part 4 — ‘모두의주차장’ 앱 200% 활용법

① 실시간 빈자리 확인 — 공영·사설 주차장의 센서 데이터를 실시간으로 표시해 돌다리 두드릴 필요가 없습니다.
② 선결제 할인권 — 대부분 평일권·주말권·심야권으로 나뉘며, 필요 시간대에 맞춰 미리 사두면 평균 30% 이상 절약.
③ 사전 정산 + QR 출차 — 급히 나올 때 출구 줄 설 필요 없이 ‘사전정산 버튼 → QR’만 찍으면 끝. 회전율 Up!

Part 5 — 자주 묻는 질문(FAQ)

Q1. 전기차 충전은 어디서?
   ▶ 성수 2가 3동 공영주차장 1층에 완속 22kW 2기가 설치돼 있습니다.
Q2. 장애인·경차 할인은?
   ▶ 공영주차장은 서울시 통합 정책을 따르므로 최대 80%까지 자동 감면됩니다(카드 등록 필수).
Q3. 대형 SUV도 주차 가능?
   ▶ KT 성수분국·뚝도시장 노상 주차장은 폭이 넉넉하지만, 성수 1가 1동 주차장 진입로는 좁아 차량 길이 5.2 m 이상이면 곤란할 수 있습니다.

※ 본 글은 2025‑07‑31 기준 서울시·성동구 주차 정책과 현장 답사를 바탕으로 작성되었습니다. 요금·무료 운영시간은 변동될 수 있으므로 방문 전 각 주차장 또는 모두의주차장 앱에서 최신 정보를 확인하세요.

CDC 파이프라인 정합성 검사 Spark 잡 개발 - Part 1. 코드 설계편

데이터 엔지니어링 환경이 복잡해지고 실시간성 요구가 커지면서, Change Data Capture(CDC)는 대규모 파이프라인의 필수 컴포넌트로 자리잡았습니다. 하지만 CDC 파이프라인은 단순히 Kafka 토픽에 데이터를 흘려보내는 것으로 끝나지 않습니다. 시스템 간 데이터 정합성을 자동화된 방식으로 검증하는 체계가 없다면, CDC는 결국 불안정한 인프라로 전락할 수 있습니다.

이 글에서는 카카오 Tech 블로그에서 소개한 사례를 바탕으로, CDC 파이프라인의 정합성을 자동으로 검사하는 Spark 잡을 어떻게 설계하고 운영할 수 있는지 단계별로 상세히 설명합니다.

1. CDC 파이프라인의 정합성이 중요한 이유

CDC 환경에서는 데이터의 누락, 중복, 순서 왜곡 등의 문제가 종종 발생할 수 있습니다. 특히 수백 개의 테이블을 다루는 대규모 파이프라인에서는 이 문제가 눈에 띄지 않게 누적되며, 서비스 품질 저하로 이어질 수 있습니다.

• 예측 불가능한 장애: 특정 테이블에 데이터가 누락되거나 중복될 경우, BI 대시보드·머신러닝 모델 등의 의사결정이 왜곡됩니다.
• SLA 보장: 기업의 데이터 신뢰성을 유지하기 위해서는 정기적이고 자동화된 정합성 검증이 필수입니다.
• 운영 효율성: 문제가 발생한 후 수동 대응하기보다, 미리 알림을 받아 자동 조치하는 시스템이 필요합니다.

2. 시스템 아키텍처 개요

CDC 파이프라인 정합성 검사를 위해 구성한 전체 아키텍처는 다음과 같습니다.

1. CDC Producer: Debezium이 Kafka 토픽에 변경 이벤트를 전송
2. Ingestion Layer: Spark Structured Streaming으로 Bronze 테이블 적재
3. Delta Lake: 정제된 데이터 저장소
4. Reconciliation Job: 대상 ↔ 소스 간 해시/row 수 비교
5. Alerting: Slack Webhook을 통한 운영자 알림

3. 정합성 검사 Spark 잡 설계

3-1. 핵심 설계 전략

• 전체 테이블을 검사하는 대신 샘플링 기반 검사와 hash 검증을 병행
• structured streaming 기반 ingest 내역을 기준으로 체크포인트 관리
• broadcast join으로 대상 테이블과 비교 속도 향상

3-2. 코드 예시 (Scala Pseudocode)

// Row 수 및 Hash 비교
val srcDF = spark.read.table("source_table")
val tgtDF = spark.read.format("delta").load("target_path")

val srcCnt = srcDF.count()
val tgtCnt = tgtDF.count()

val srcHash = srcDF.selectExpr("xxhash64(*) as h").agg(sum("h")).first.getLong(0)
val tgtHash = tgtDF.selectExpr("xxhash64(*) as h").agg(sum("h")).first.getLong(0)

if (srcCnt != tgtCnt || srcHash != tgtHash) {
  sendSlackAlert("Mismatch Detected")
}

3-3. 샘플링 로직

실제로 수백 개 테이블을 매일 검사하려면 성능 최적화가 중요합니다. 따라서 전체 테이블 스캔 대신 다음 전략을 병행합니다:

• 랜덤 샘플링: 기본 0.1% 적용
• min/max 키 범위 비교: row 누락 여부 확인
• 컬럼 기준 해시: 문자열 조합으로 전체 해시 계산

4. 테스트 및 검증 전략

데이터 정합성 검사는 운영 환경에서 검증만큼이나 테스트 전략이 중요합니다.

• 단위 테스트: Spark local[*] 모드 기반, pytest로 통합
• 스키마 변경 시나리오: 컬럼 추가/삭제 → Spark read schema와 동기화 검증
• 재처리 시나리오: checkpoint 리셋 후 중복 없는 재처리 확인
• 대용량 업데이트: Row level 변화가 많을 때 성능 측정

5. 운영 상의 고려사항

설계가 아무리 완벽해도 운영이 복잡하면 실패한 설계입니다.

• 메타데이터 기반 잡 스케줄링: Airflow로 매일 테이블 목록 로드 → Spark 잡 동적 생성
• 오탐 방지: 정합성 검증 시 경계값 설정 필요 (예: 허용 오차 5 rows)
• 로그 관리: 테이블별 mismatch 이력 저장 후 분석 가능하도록 설계

6. 마무리 및 다음 글 예고

CDC 파이프라인의 신뢰성을 확보하기 위한 정합성 검사는 선택이 아니라 필수입니다. 본 글에서는 Spark 기반 Reconciliation Job의 설계 방향을 소개했으며, Part 2에서는 운영 중 발생한 실제 이슈와 성능 최적화 및 슬랙 알림 자동화에 대해 다룰 예정입니다.

CDC 파이프라인 정합성 검사 Spark 잡 개발 - Part 2. 성능 최적화와 운영 자동화

이전 글에서는 Spark 기반 정합성 검사 잡의 설계 방식에 대해 다뤘습니다. 이번 Part 2에서는 실제 운영 환경에서의 성능 최적화 전략과 운영 자동화 중심으로 CDC 파이프라인을 어떻게 안정화시켰는지를 소개합니다.

1. Spark 잡 성능 최적화 전략

1-1. Partition Pruning

데이터 레이크 환경에서는 파티셔닝 전략이 잡 성능에 결정적인 영향을 미칩니다. ingestion 시점에 ingest_date 혹은 event_date를 기준으로 파티션을 분리하고, Spark 잡에서는 해당 파티션만 로딩하도록 쿼리를 설계합니다.

1-2. Broadcast Join 최적화

소스 데이터와 대상 데이터의 일부 row를 비교할 경우, 크기가 작은 테이블을 broadcast하면 join 속도를 크게 향상시킬 수 있습니다. 단, 메모리 초과를 방지하기 위해 spark.sql.autoBroadcastJoinThreshold를 조정합니다.

1-3. Dynamic Resource Allocation

스파크 클러스터의 부하가 유동적인 경우, spark.dynamicAllocation.enabled=true 옵션을 통해 Executor 수를 자동으로 조절함으로써 리소스를 효율적으로 사용할 수 있습니다.

1-4. Cache 전략

여러 잡에서 반복적으로 사용하는 마스터 테이블(Metadata 등)은 persist(StorageLevel.MEMORY_AND_DISK)를 통해 캐싱하여 속도 개선이 가능합니다.

2. 운영 자동화 - Airflow & Slack 통합

2-1. Airflow DAG 설계

CDC 검증 잡은 매일 동적으로 대상 테이블 목록을 불러와 DAG을 생성합니다. 예시는 다음과 같습니다:

from airflow import DAG
from airflow.operators.bash import BashOperator
from datetime import datetime

with DAG("cdc_reconciliation", start_date=datetime(2023,1,1), schedule="@daily") as dag:
    check_job = BashOperator(
        task_id="run_spark_check",
        bash_command="spark-submit --class ReconJob main.py"
    )

2-2. Slack Webhook 연동

검증 실패 시 Slack으로 알림을 전송합니다. 파이썬 예시는 다음과 같습니다:

import requests

def send_slack_alert(msg):
    webhook_url = "https://hooks.slack.com/services/XXX/YYY/ZZZ"
    payload = {"text": msg}
    requests.post(webhook_url, json=payload)

2-3. 실패 이력 저장

오탐 방지 및 재현을 위해 mismatch 이력을 Delta Table에 저장하고, 대시보드로 시각화할 수 있도록 설계합니다. BigQuery나 Tableau를 활용하면 추세 분석도 가능합니다.

3. 실전 운영 팁

• Slack 알림을 너무 자주 보내면 운영자 피로도가 올라가므로, threshold 기반 알림을 설정합니다.
• 정합성 실패가 자주 발생하는 테이블은 우선순위 등급을 정해서 집중 관리합니다.
• 운영 대시보드에 검증 통계(누적 실패율, 평균 수행시간 등)를 시각화하여 지속적인 개선에 활용합니다.

4. 마무리

CDC 파이프라인의 안정성은 정합성 검사 시스템이 얼마나 탄탄하냐에 따라 좌우됩니다. Spark를 기반으로 한 Reconciliation Job은 샘플링, 해시 비교, Slack 알림, Airflow 자동화 등 다양한 기술을 조합하여 강력한 데이터 품질 관리를 가능하게 합니다.

이제 이 구조를 바탕으로, 실시간 스트리밍 환경에서도 정합성을 지속적으로 확보하는 체계를 확장해 나갈 수 있습니다.

Part 3에서는 Reconciliation을 실시간 스트리밍 CDC에 적용하는 방법과 Structured Streaming의 고급 설정에 대해 다룰 예정입니다.

CDC 파이프라인 정합성 검사 Spark 잡 개발 - Part 3. 실시간 스트리밍 CDC 정합성 검증

지금까지 우리는 Spark 기반의 CDC 파이프라인 정합성 검사 구조를 설계하고, 성능 및 운영 최적화 방법을 살펴봤습니다. 이번 마지막 Part 3에서는 실시간 스트리밍 CDC 환경에서 정합성 검증을 어떻게 구현하고, 어떤 식으로 event-time 기반 오류 복구와 latency 보정까지 확장할 수 있는지를 다룹니다.

1. 실시간 CDC 환경에서의 문제

Batch 환경과는 달리 실시간 스트리밍 환경에서는 다음과 같은 복잡성이 추가됩니다:

• Event-time 지연: 데이터가 Kafka에 늦게 도착할 수 있음 (예: network, log buffer)
• Out-of-order 이벤트: 동일한 키에 대한 데이터가 시간 순서대로 도착하지 않음
• 데이터 중복: 재처리 시 중복 발생 가능성 존재

따라서 실시간 환경에서도 정합성 검사를 설계할 때 다음과 같은 접근이 필요합니다.

2. Structured Streaming 기반 실시간 정합성 검사 구조

2-1. Watermark 기반 지연 허용

Spark Structured Streaming은 withWatermark를 사용해 일정 시간 범위 내 지연 데이터를 처리할 수 있도록 합니다.

val stream = spark.readStream.format("delta").load("/bronze")
  .withWatermark("event_time", "10 minutes")
  .groupBy(window(col("event_time"), "5 minutes"))
  .agg(count("*"))

2-2. 상태 저장(Stateful) 검사

Streaming 환경에서는 mapGroupsWithState나 flatMapGroupsWithState를 활용해 상태 기반 비교 로직을 구현할 수 있습니다. 이 방식은 과거의 상태를 유지하며 데이터 일관성 검사를 수행할 수 있습니다.

2-3. 지연 알림 시스템

지연 이벤트가 누락된 경우, Slack으로 알리는 대신, 지연 대시보드를 만들어서 시간대별 수집 지연 현황을 시각화하는 것도 방법입니다. Prometheus + Grafana 조합으로 구현하면 효과적입니다.

3. Kafka 재처리 전략과 정합성

3-1. Checkpoint 리셋과 Idempotency

CDC 스트리밍의 경우, 장애 복구나 코드 업데이트 이후 checkpoint를 삭제하고 재처리할 필요가 있습니다. 이 경우 중복 적재를 방지하기 위해 idempotent sink (예: Delta Lake의 MERGE INTO)를 사용합니다.

3-2. Kafka Offset 관리

Kafka의 offset을 외부에서 수동으로 지정해 replay를 수행할 수도 있습니다. 이때 startingOffsets를 earliest 혹은 특정 offset으로 설정해 재처리 타겟을 지정할 수 있습니다.

4. 미래 지향적 개선 포인트

• 데이터 품질 지표 자동화: 정합성 검사 결과를 메트릭화하여 운영 효율 분석
• AI 기반 이상 탐지: hash mismatch, row count anomaly 등을 ML로 자동 감지
• Catalog 기반 CDC 관리: Glue, Hive Metastore와 통합하여 테이블 추가 시 자동 검증 흐름 생성

5. 마무리

Part 1에서는 CDC 정합성 검사 잡의 설계 방법을, Part 2에서는 성능과 운영 자동화, 이번 Part 3에서는 실시간 CDC 환경에서의 복잡성 처리까지 다뤘습니다.

정합성 검사는 더 이상 부가적인 작업이 아닙니다. 데이터 플랫폼의 신뢰성과 자동화 수준을 결정짓는 핵심 구성 요소입니다.

본 시리즈를 바탕으로 여러분의 CDC 파이프라인이 더 정밀하고 안정적인 구조로 발전하기를 바랍니다. 감사합니다 🙏

RAG 성능 폭발의 비밀? Sparse vs Dense 임베딩 제대로 알아보기

LLM 기반의 Retrieval-Augmented Generation(RAG)을 설계할 때 성능의 대부분을 좌우하는 건 임베딩 전략입니다. 많은 개발자들이 Dense만 사용하는 경향이 있지만, 사실 Sparse와의 조합이 진정한 성능 향상의 열쇠입니다. 오늘은 이 둘의 차이와 활용 전략, Hybrid Search 구현법까지 함께 파헤쳐보겠습니다.

1. 임베딩이란 무엇인가?

텍스트를 수치화하여 비교 가능하게 만드는 과정입니다. 단순 키워드 검색에서 벗어나 의미 기반의 검색이 가능해지고, 이를 통해 LLM이 정확한 문맥을 받아들일 수 있게 됩니다.

2. Sparse 임베딩 – 키워드의 정밀한 무기

BM25나 SPLADE처럼 단어 단위의 희소 벡터로 구성된 방법입니다.

• 장점: 키워드 일치에 탁월하고, 드문 단어(코드, 숫자, 특수어휘)에 강합니다.
• 단점: 문맥 파악이 어렵고 벡터 차원이 커서 리소스를 많이 잡아먹습니다.

3. Dense 임베딩 – 의미를 파악하는 LLM 친구

Transformer 기반의 모델로 문장을 의미 기반 벡터로 압축합니다.

• 장점: 문맥 파악에 탁월하고, 연산 효율이 높습니다.
• 단점: 키워드 누락 시 검색 실패 가능성이 있고, 해석이 어렵습니다.

4. 핵심 비교

5. Hybrid 전략 – 둘 다 써야 이깁니다

요즘 Vector DB들은 대부분 Hybrid를 지원합니다. Dense + BM25 조합을 통해 양쪽의 장점을 동시에 취합니다. 예:

from rank_bm25 import BM25Okapi
from sentence_transformers import SentenceTransformer

docs = [...]  # 문서 리스트
query = "GPT 속도 개선 팁"
bm25 = BM25Okapi([doc.split() for doc in docs])
sparse_score = bm25.get_scores(query.split())

dense_model = SentenceTransformer("all-MiniLM-L6-v2")
dense_scores = dense_model.encode([query]) @ dense_model.encode(docs).T

hybrid = 0.7 * dense_scores + 0.3 * sparse_score

6. 실제 선택 팁

• 도메인 키워드 많다 → Sparse 우선
• 자연어 기반 QA → Dense 우선
• 정답을 정확히 집는 게 중요하다 → Hybrid

7. 마무리

임베딩 전략은 RAG 프로젝트의 첫 단추입니다. Dense만 믿지 말고 Sparse를 병행하는 하이브리드 설계로, 진짜로 "쓸모 있는" 검색 시스템을 만들어보세요.

🚀 하루 만에 개발 자동화! Kiro 입문 완전 정복

“10분 만에 설치하고, 일주일치 업무를 하루에 끝낸다.”
Kiro는 AWS가 공개한 AI IDE로, 스펙 기반 개발(spec‑driven development)을 핵심 철학으로 삼고 있습니다. 이 글에서는 Kiro를 처음 접하는 개발자라도 쉽게 따라 할 수 있도록 설치부터 실전 활용까지 탄탄하게 안내합니다.

1. Kiro란 무엇인가?

• AI 퍼스트 IDE – 초기 설계부터 프로덕션 배포까지 한 IDE에서 지원
• 두 가지 모드 – 아이디어 스케치를 위한 Vibe 모드와 구체적 스펙을 기반으로 하는 Spec 모드
• Steering 문서 생성 – 프로젝트 구조·기술 스택·API 목록을 자동 문서화
• Agent Hook – 테스트·빌드 같은 반복 작업을 AI가 대신 실행

2. 설치 & 첫 실행

1. kiro.dev 접속 후 OS별 설치 프로그램 다운로드
2. Google · GitHub · AWS Builder ID 중 편한 계정으로 로그인
3. 새 프로젝트 생성 시 Vibe 또는 Spec 모드 선택

3. 핵심 기능 둘러보기

3‑1. Vibe 모드 – 아이디어를 코드로

간단한 한 줄 설명만으로도 Kiro가 필요한 폴더 구조와 예제 코드를 제안합니다. 즉시 실행 가능한 프로토타입을 손쉽게 만들 수 있어 해커톤이나 사이드 프로젝트에 유용합니다.

3‑2. Spec 모드 – 문서가 코드를 이끈다

요구사항(Spec)을 마크다운으로 정리하면 Kiro가 이를 기반으로 테스트·API·UI 스텁까지 자동 생성합니다. 스펙 변경 시 재생성 기능으로 코드를 최신 상태로 유지할 수 있습니다.

3‑3. Steering 문서 – 프로젝트 이해도 ↑

Generate Steering Docs 버튼 한 번으로 .kiro/steering 폴더에 Structure·Tech 두 개의 마크다운이 생성됩니다. 디렉터리 구조, 의존성, 빌드 명령 등이 요약돼 신규 투입 인원의 온보딩 시간을 대폭 줄여 줍니다.

3‑4. Agent Hook – 반복 작업 자동화

테스트·린트·배포 스크립트를 Hook으로 등록하면 코드 저장(Commit) 시마다 AI가 알아서 실행합니다. CI 파이프라인을 별도로 구성하지 않아도 프로덕션 품질을 확보할 수 있습니다.

4. 실전 워크플로우 예시: Todo API 만들기

# Vibe 모드에서 프롬프트
"RESTful Todo API를 TypeScript로 만들어줘"
# 생성된 스켈레톤 확인 후 Spec 전환
- 작성된 todo.spec.md 파일에 상태 코드·엔드포인트 수정
# 'Generate Code' 클릭
- models/todo.ts, routes/todo.ts 자동 생성
# Agent Hook 등록
- 테스트 통과 시 Docker 이미지 빌드 & 배포

5. 다른 AI 코딩 도구와 비교

• Cursor – 코드 보조에 특화 ↔ Kiro – 문서·워크플로우 자동화까지 포함
• JetBrains AI Assistant – 기존 IDE 플러그인 ↔ Kiro – AI 퍼스트 독립 IDE
• GitHub Copilot – 개별 프롬프트 중심 ↔ Kiro – 프로젝트 스펙 전체를 이해·관리

6. 장단점 한눈에 보기

👍 장점

• 문서 자동화 덕분에 유지보수 용이
• Vibe·Spec 모드로 아이디어 ↔ 스펙 전환이 자유로움
• AWS 리소스·아키텍처 다이어그램까지 지원

🤔 아쉬운 점

• 기본 응답이 영어라 매 번 한국어 설정 필요
• 문서 우선 로직이 단순 리팩토링 시에는 다소 번거로울 수 있음

7. FAQ

Kiro는 무료인가요?

현재 프리뷰 기간 동안은 무료이며, Google · GitHub · AWS Builder ID 중 하나로 로그인만 하면 됩니다.

LLM 모델은 변경할 수 있나요?

우측 채팅 패널에서 Claude Sonnet 4.0, 3.7 등을 선택할 수 있습니다.

한국어 지원은?

“한국어로 답변해줘” 한 줄만 입력하면 이후 대화가 한국어로 유지됩니다.

8. 마무리

Kiro는 “문서가 곧 코드다”라는 패러다임을 현실로 만드는 IDE입니다. 프로젝트 설계부터 데브옵스 자동화까지 한 번에 잡고 싶다면 지금 바로 설치해 보세요. 스펙 기반 개발의 생산성을 직접 체험할 차례입니다.

🚀 10분 만에 끝내는 LangChain 첫걸음: 설치부터 RAG까지

“GPT‑4o 같은 초거대 모델, 과연 나도 쓸 수 있을까?” 개발자라면 한 번쯤 이런 궁금증을 품습니다. LangChain은 이런 고민을 단숨에 해결해주는 LLM 애플리케이션 프레임워크입니다. 이 글에서는 설치 → 기본 체인 → RAG 구현까지 직접 따라 해볼 수 있는 예제로 안내합니다.

1. LangChain이란?

LangChain은 LLM·임베딩·벡터스토어·에이전트 같은 컴포넌트들을 체인으로 엮어주는 오픈소스 프레임워크입니다. 동일한 코드로 OpenAI, Ollama, HuggingFace 모델을 자유롭게 바꿔 끼울 수 있어 “벤더 종속” 위험을 줄여줍니다.

2. 빠른 환경 세팅

# Python ≥3.9 권장
pip install -U langchain langchain-openai tiktoken

• API 키 설정 (예: OpenAI)
  

  export OPENAI_API_KEY="sk-..."

• 로컬 모델을 쓰고 싶다면 pip install ollama-python 후 ollama serve를 실행하세요.

3. Hello LangChain: 5줄로 끝나는 채팅 체인

from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage

chat = ChatOpenAI(model="gpt-3.5-turbo")
response = chat([HumanMessage(content="LangChain이 뭐야?")])
print(response.content)

포인트

1. ChatOpenAI → 동일 인터페이스로 Ollama·Cohere 등 대체 가능
2. messages 배열에 SystemMessage, HumanMessage를 혼합해 대화 맥락 제어

4. Retrieval‑Augmented Generation(RAG) 살펴보기

from langchain_openai import ChatOpenAI
from langchain_community.document_loaders import TextLoader
from langchain_community.vectorstores import FAISS
from langchain.embeddings.openai import OpenAIEmbeddings
from langchain.chains import RetrievalQA

loader = TextLoader("docs/handbook.txt")
documents = loader.load()

embeddings = OpenAIEmbeddings()
db = FAISS.from_documents(documents, embeddings)

qa_chain = RetrievalQA.from_chain_type(
    llm=ChatOpenAI(model="gpt-3.5-turbo"),
    retriever=db.as_retriever()
)

print(qa_chain.run("핵심 모듈이 뭐야?"))

RAG 패턴은 “외부 지식 검색 → 프롬프트 삽입 → 답변 생성” 흐름으로, 최신 정보까지 반영한 신뢰도 높은 결과를 제공합니다.

5. 흔히 겪는 오류 & 해결 팁

• ModuleNotFoundError: LangChain 최신 버전으로 pip install -U langchain 업데이트
• context length 초과: ConversationBufferWindowMemory를 써서 최근 대화만 모델로 전달
• API 요금 폭탄: Temperature=0.2로 불필요한 토큰 생성을 줄이고, 무료 로컬 모델(Ollama)로 테스트

6. 더 나아가기

LangChain 생태계는 빠르게 확장 중입니다.

• LangGraph – 복잡한 워크플로를 노드‑그래프 형태로 선언
• LangSmith – 체인 실행을 시각화하고 로그를 분석, LLM Observability 제공
• Agentic RAG – 에이전트가 “검색할지 말지” 자체 판단해 효율 향상

7. 마무리

지금 바로 pip install langchain 한 줄이면 거대한 LLM 세계가 눈앞에 펼쳐집니다. “읽고 끝”이 아닌 “직접 실행”이 중요합니다. 10분 투자해 나만의 LLM 체험을 시작해 보세요!

© 2025. 이 글은 LangChain 공식 문서·GitHub·여러 튜토리얼을 참고해 작성했습니다.

눈을 쓰지 않고도 초고속 코딩?! 분당 800단어로 개발하는 법

화면을 보지 않고도 어떤 인터페이스 요소, 변수, 언어 구성요소를 분당 800단어(일반 대화 속도의 5배 이상)로 듣고 이해한다면 어떨까요? 많은 사람에게는 로봇의 빠른 속도로 느껴지겠지만, 시각장애 개발자에게는 일상이자 생산성을 높여주는 방법입니다. 이 글에서는 스크린 리더를 사용해 ‘듣는 속도’로 코딩하는 경험과 실질적인 노하우를 소개합니다.

스크린 리더란 무엇인가요?

스크린 리더는 화면의 텍스트와 UI 요소를 음성이나 점자 출력으로 바꿔주는 소프트웨어입니다. Windows의 내레이터, macOS의 VoiceOver, Android의 TalkBack처럼 운영체제에 기본 내장되기도 하고, NVDA처럼 무료 오픈소스 형태로 제공되기도 합니다.

스크린 리더는 화면을 ‘보는’ 대신 운영체제가 노출하는 접근성 트리를 읽습니다. 각 요소의 역할, 레이블, 상태를 음성으로 전달하며 키보드 포커스의 위치나 버튼 클릭 같은 이벤트도 알려줍니다. 따라서 마우스를 사용하지 않고 키보드만으로 인터페이스를 탐색할 수 있습니다.

800 WPM를 이해할 수 있을까요?

일반적인 말하기 속도는 분당 150단어 정도입니다. 그런데 스크린 리더를 800WPM로 설정하면 대부분의 사람들은 기계음처럼 느낍니다. 저도 처음에는 마치 새로운 언어를 배우는 것처럼 느꼈지만, 수년간의 연습으로 자연스러운 속도가 되었습니다. 일상적인 이메일, 문서, 익숙한 코드 패턴을 읽을 때는 800WPM가 가장 효율적이고, 복잡한 로직을 디버깅할 때는 속도를 조절합니다. 스크린 리더가 항상 같은 억양으로 읽기 때문에 귀가 그 패턴에 익숙해지면 이해 속도가 비약적으로 올라갑니다.

스크린 리더는 어떻게 작동하나요?

스크린 리더는 화면을 캡처하는 대신 응용프로그램이 제공하는 접근성 API를 통해 UI 요소의 구조를 탐색합니다. 예를 들어 웹 페이지의 <button>Submit</button> 요소는 다음 과정을 거칩니다:

• 브라우저가 DOM을 만들고 버튼을 시각적으로 렌더링합니다.
• 브라우저는 접근성 트리에 ‘버튼 역할’과 ‘Submit’ 레이블을 가진 노드를 추가합니다.
• 스크린 리더는 이 트리를 읽어 ‘Submit 버튼’이라고 안내합니다.
• 포커스 이동이나 자동완성 제안 같은 이벤트가 발생하면 스크린 리더가 이를 음성으로 알립니다.

따라서 애플리케이션은 접근성 트리에 올바른 정보를 노출해야 스크린 리더 사용자에게 유용합니다. 기본 컨트롤을 사용하는 네이티브 애플리케이션이나 시맨틱 HTML을 지키는 웹 애플리케이션은 호환성이 뛰어납니다.

어떤 애플리케이션과 IDE가 적합한가요?

스크린 리더와 잘 호환되는 애플리케이션은 다음과 같은 특징을 갖습니다:

• 접근성 트리 노출: UI 요소의 역할, 레이블, 상태를 명확히 제공합니다. div로 만든 클릭 영역 대신 버튼·링크 같은 시맨틱 요소를 사용하세요.
• 키보드 탐색 가능: 포커스를 이동하고 모든 기능을 키보드만으로 조작할 수 있어야 합니다.
• 기본 컨트롤 사용: Windows나 macOS의 기본 컨트롤을 사용하는 애플리케이션은 접근성 문제가 적습니다.

모바일 앱 개발 환경에서는 지원이 부족할 수 있지만, 웹과 데스크톱에서는 충분한 대안을 찾을 수 있습니다.

개발 환경에서는 Windows + WSL2 조합이 현실적인 선택입니다. Linux는 오디오 출력 안정성 등 접근성 문제가 많고, macOS의 VoiceOver는 심각한 버그로 인해 대안이 어렵습니다. Windows는 NVDA 같은 강력한 스크린 리더를 사용할 수 있고, WSL2는 완전한 Linux 환경에서 Docker, CLI 도구를 사용할 수 있습니다.

IDE로는 Visual Studio Code가 가장 안정적입니다. 일관된 키보드 단축키, 뛰어난 IntelliSense 알림, 오류·경고의 오디오 신호, 접근성 개선에 대한 꾸준한 업데이트가 장점입니다.

스크린 리더 친화적인 개발 도구

IDE 외에도 API 테스트, 문서, 코드 리뷰 등 다양한 개발 도구를 사용해야 합니다. 접근성에 어려움이 있으면 다음과 같은 전략을 사용합니다:

• 대안 찾기: 예를 들어 Postman 대신 명령줄 Curl과 VS Code REST 클라이언트 확장을 사용합니다.
• 사용자 스크립트: Greasemonkey 등으로 웹앱의 DOM을 살짝 수정해 테이블 시맨틱을 추가하거나 단축키를 정의합니다.
• API 통합: UI 사용이 어렵다면 도구의 API를 호출하는 스크립트를 작성합니다.
• 버그 제보: 가능한 경우 접근성 버그를 리포트하지만, 현실적으로 우선순위가 낮으므로 직접 우회 방법을 찾는 경우가 많습니다.

Infrastructure as Code의 접근성 이점

GUI를 클릭하면서 서버를 설정하는 대신 코드 몇 줄로 인프라를 정의할 수 있다는 점은 스크린 리더 사용자에게 큰 장점입니다. Terraform 예제를 보면 쉽게 이해할 수 있습니다:

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1d0"
  instance_type = "t2.micro"

  tags = {
    Name = "WebServer"
    Environment = "Production"
  }
}

이처럼 텍스트 기반 구성은 화면을 탐색하지 않아도 모든 옵션을 읽고, 버전 관리하며, 명령줄로 배포할 수 있습니다. 반대로 GUI는 재작성될 때 접근성이 퇴보할 위험이 있고, 목록 탐색 기능이 사라지는 등 예기치 못한 문제가 발생할 수 있습니다. 따라서 코드 기반 도구를 우선적으로 사용하고, 특정 GUI에 의존하지 않는 생태계를 선택하는 것이 안전합니다.

프런트엔드 작업과 이미지 읽기

프런트엔드는 시각적인 요소가 많아 도전이지만, 상태 관리, API 통신, 기존 디자인 시스템 활용 같은 비주얼 외적인 작업에 기여할 수 있습니다. 또한 LLM이 발전하면서 UI 스크린샷이나 코드 이미지의 내용을 설명해주는 도구가 등장해 시각적 정보 접근이 크게 나아졌습니다.

이미지에는 반드시 의미 있는 대체 텍스트를 제공해야 하지만, 대부분의 환경에서는 제공되지 않습니다. 그래서 OCR로 텍스트를 추출하거나, 최신 언어모델을 이용해 스크린샷의 내용을 요약·설명합니다. 단, 환각 결과를 경계하고 민감한 정보를 업로드하지 않도록 주의해야 합니다.

다이어그램 그리기와 협업

문서를 작성하거나 아키텍처를 설명할 때는 Mermaid 같은 마크업 언어를 사용해 다이어그램을 코드로 표현합니다. 이렇게 하면 텍스트만으로도 구조를 이해할 수 있고 버전 관리도 용이합니다.

페어 프로그래밍이나 화면 공유는 전적으로 귀로 정보를 받는 저에게 큰 인지 부담을 줍니다. 대신 Live Share 등 협업 도구를 활용해 서로의 파일을 열거나, 코드를 공유하면서 필요한 정보를 말로 설명하는 방식으로 협업합니다.

마무리: 접근성이 중요한 이유

많은 접근성 콘텐츠는 애플리케이션을 접근성 있게 만드는 법을 다루지만, 실제로 접근성을 필요로 하는 개발자가 어떻게 작업하는지에 대한 내용은 적습니다. 스크린 리더를 사용하는 개발자는 개발자의 결정 하나하나를 매일 직접 경험합니다. 시맨틱 HTML을 쓰거나 키보드 탐색을 지원하는 작은 선택이 협업과 생산성에 큰 차이를 만듭니다.

아직 많은 도전이 있지만, 소프트웨어 개발은 다양한 방식에 놀랍도록 적응력이 있는 분야입니다. 문제를 깊이 생각하고 아이디어를 코드로 구현할 수 있다면, 스크린 리더를 사용하는 개발자에게도 무한한 가능성이 열려 있습니다.

GitHub에서 프로젝트를 fork하여 개인 계정으로 가져오고, 로컬 머신에서 작업하며 upstream 저장소를 설정하고, 최종적으로 수정한 내용을 원본 저장소로 보내는 방법에 대해 자세하게 설명하겠습니다.

왜?? 이렇게 작업하는가?

fork 및 upstream을 사용하는 주된 이유는 협업 및 컨트리뷰션을 용이하게 하기 위해서입니다. 여러 개발자가 동시에 프로젝트에 기여할 때, 이러한 작업 흐름은 코드 충돌을 방지하고 변경 사항을 조직화하며, 프로젝트의 안정성과 유지 관리를 도울 수 있습니다.

1. Fork (개인 저장소로 복제):
   • 원본 프로젝트를 직접 수정하지 않고, 자신의 계정으로 fork하여 개인적으로 작업합니다.
   • 이렇게 하면 원본 프로젝트에 직접 영향을 주지 않으면서 개발자는 자신의 변경 사항을 안전하게 실험하고 관리할 수 있습니다.
2. Upstream (원본 저장소와 연결):
   • upstream은 원본 프로젝트의 최신 변경 사항을 계속해서 추적하는데 사용됩니다.
   • 개발자는 자신의 fork에서 작업하기 전에 원본 프로젝트의 최신 업데이트를 가져와 로컬 저장소를 최신 상태로 유지할 수 있습니다.
3. Branch (브랜치를 통한 개별 작업):
   • 새로운 브랜치를 만들어서 각각의 작업을 분리하면 여러 개발자가 동시에 작업할 때 충돌을 방지하고, 개별적으로 특정 기능 또는 수정을 진행할 수 있습니다.
   • 이 브랜치는 작업이 완료되면 메인 브랜치로 병합될 수 있습니다.
4. Pull Request (병합 신청):
   • 개발자는 자신의 fork에서 만든 변경 사항을 원본 프로젝트에 반영하기 위해 Pull Request를 생성합니다.
   • 이를 통해 프로젝트 관리자는 변경 내용을 검토하고, 코드의 품질을 확인한 후에 병합 여부를 결정할 수 있습니다.

이러한 작업 흐름을 통해 프로젝트는 여러 사람이 효율적으로 협업하고, 변경 사항이 제대로 검토되며, 코드 충돌이 최소화되어 유지보수가 용이한 상태를 유지할 수 있습니다.

프로젝트 Fork하기:

• GitHub에서 원하는 프로젝트로 이동합니다.
• 프로젝트 페이지 오른쪽 상단에 있는 “Fork” 버튼을 클릭하여 자신의 계정으로 해당 프로젝트를 fork합니다.

로컬 머신에 복제(Clone)하기:

• 터미널 또는 Git Bash를 열고 다음 명령어를 사용하여 fork한 프로젝트를 로컬 머신으로 복제합니다.
• Fork한 자신의 Git hub계정의 Url을 clone뒤에 작성합니다.

$ git clone https://github.com/your-username/project.git

Upstream 저장소 추가하기:

• 프로젝트 디렉토리로 이동한 후 원본 저장소를 upstream으로 추가합니다.

$ cd project 
$ git remote add upstream https://github.com/original-username/project.git

브랜치 만들기 및 작업하기:

• 새로운 브랜치를 만들어 작업합니다.

$ git checkout -b feature-branch

• 변경사항을 작업하고 커밋합니다.

$ git add . git commit -m "작업한 내용에 대한 설명"

Upstream 변경사항 가져오기:

• 원본 저장소의 최신 변경사항을 가져와 로컬에 반영합니다.

$ git fetch upstream git merge upstream/main

본인 계정으로 Push하기:

• 작업한 브랜치를 자신의 GitHub 계정으로 push합니다.

$ git push origin feature-branch

GitHub에서 Pull Request 생성하기:

• GitHub 웹사이트에서 fork한 프로젝트로 이동하여 “Compare & pull request” 버튼을 클릭합니다.
• 변경 내용을 확인하고 “Create pull request” 버튼을 클릭하여 Pull Request를 생성합니다.

원본 저장소로 Pull Request 보내기:

• Pull Request가 생성된 후, 원본 저장소에 변경사항을 반영하기 위해 “Merge pull request” 버튼을 누르거나 관리자가 검토 후 Merge할 수 있습니다.

이제 당신이 fork한 프로젝트에서 작업한 내용이 원본 저장소로 반영되었습니다.

보시기전에 광고 한번씩만 눌러주세요.

글 작성에 매우 큰 도움이 됩니다.!

# 버츄얼박스를 통해 os설치후 아래의 경로에 들어간다.

$cd /etc/sysconfig/network-scripts

그리고을 장치명및 ip주소 확인한다.
$ip addr

ex) 2: enp0s3이라고 되어있었음(장치명). / 10.0.2.15(ip명)

2.gateway확인 
$ ip route

ex) -> default via 10.0.2.2// 10.0.2.2 

3. 수정 파일 열기 -> ifcfg-enp0s3

$ vi /etc/sysconfig/network-scripts/ifcfg-enp0s3

or) vi ifcfg-enp0s3 


4. 수정

#line4
BOOTPROTO=static
#그리고 맨 밑에 적기
#(원하는 ip주소 // 아까 확인한 ip주소에서 맨뒤에 숫자만 바꿔서 사용하기)
IPADDR = 10.1.2.105
NETMASK=255.255.255.0
#아까 ip route에서 확인한 숫자
GATEWAY=10.0.2.2
DNS1=8.8.8.8

#:wq로 빠져나오기

#네트워크 재시작
$ systemctl restart network

# ip 변경 확인
ip addr

- Pydantic

파이썬 3.7에는 클래스를 훨씬 쉽고 원할하게 생성할 수 있는 편리한 데코레이터인 데이터 클래스가 도입되었다.

python에 내장된 dataclass를 이용하여 data를 작성하면 뒤에 validation이라던지 예외처리, 변환등을 다시 해줘야 했기 때문에 다른 라이브러리를 찾아보게 되었다.

그렇게 알게 된 녀석이 pydantic이었다.

철저한 데이터 검증을 필요로할 때 pydantic을 사용하는것이 많은 도움이된다.

지금 내가 사용하고 있는 기능들중 좋다고 느낀점은

1. 각 클래스 내부의 값을 정의 할때 진짜 편하다.

2. 정의 한 값들의 입력값들을 정확하게 표현할 때.

3. 그 다음 기능으로 값을 넘겨줄 때 변환하기 편하다.

4. fastapi의 자동문서화(redoc) 기능과 함께 api를 관리할때 더욱 시너지가 났다.

간단한 예제를 보면

from pydantic import BaseModel,Field


class A(BaseModel):
	no : int
	id : str = Field(alias="Id",example="root",description=" - 사용자 id")

이렇게 A라는 데이터클래스와 no, id라는 값을 정의 했다고 하면

1. no -> int , id-> str을 입력으로 받지 않으면 에러가 나온다.

2. Field -> 추가한다면 alias, example, description등을 작성할 수 있고, swagger나 fastapi의 자동문서화 기능과 연결하여 편하게 사용할 수 있다.

3. docs에 id로 표기되고 내부에서는 Id라는 키값으로 사용하고, 다시 출력할 때에는 id로 출력

4. 그 외에도 많은 기능이 있다.

data=A(no=1,Id='root')
data.dict()

=> {"no":1,"id":"root"}

위와같이 사용할 수 있어서. 정말 도움이 많이 되었다. 

앞으로 더 많이 공부 해야겠다고 생각든다.

더 많은 기능은 아래의 공홈에서 찾아보길..

https://pydantic-docs.helpmanual.io/

CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.
To initialize your shell, run

    $ conda init <SHELL_NAME>

-> 기존 윈도우즈 cli 창에서는 잘 됐는데 찾아보니 리눅스 cli에서는 source activate로 먼저 활성화를 해주는것 같았다.

> conda activate ====> source activate

해결완료