파이콘 한국 2025 1일차

주요 도구 소개

1. Django + DRF
• Django: Python 기반 웹 프레임워크로, ORM과 다양한 생태계를 제공.
• DRF: RESTful API 개발에 최적화된 Django 확장. 직렬화, 뷰셋, 인증 등 강력한 기능을 제공.
2. Pydantic
• Python 타입 힌트를 기반으로 데이터 유효성 검사, 변환, 직렬화를 수행.
• API 요청/응답 데이터를 DTO(Data Transfer Object)처럼 정의하기에 적합.
• Rust 기반으로 속도가 빠르며, DRF Serializer 대비 최대 수십 배 성능 우위.
3. Open API Specification (OAS)
• REST API를 표준화된 형식으로 문서화하는 널리 사용되는 명세.
• 언어/프레임워크에 독립적이며, Swagger, Redoc, Scalar 같은 뷰어로 시각화 가능.
• Swagger: 가장 널리 사용되는 OAS 뷰어.
• Redoc: 깔끔한 문서 UI 제공.
• Scalar: Markdown 지원, 사용자 친화적 UI. 팀 내에서 신선한 선택지로 주목받음.
• (좀 생소하실 듯, 괜찮다, 언어 스칼라 아님, Scalar 영업-사진, 도입하시면 팀장님이나 동료 개발자 좋아할듯—??)
  

DRF + Pydantic의 조합

Pydantic 장점

• Python과의 궁합: 타입 힌트를 활용해 코드 가독성과 유지보수성 향상.
• 성능: Rust 기반으로 DRF Serializer보다 빠름(수십 배).
• 명확한 모델 분리: 외부 인터페이스와 내부 로직을 분리한 DTO 패턴 구현 가능.
• AI 친화적: 명확한 타입 정의로 인해 AI 기반 코드 생성/분석에 유리.
• 유효성 검사: 복잡한 데이터 검증 로직을 간단히 구현 가능.

DRF Serializer와의 비교

• 외부 인터페이스 명확화: API 요청/응답 데이터를 명확히 정의하고, 내부 모델과 분리 가능.
• 유효성 검사 간소화: Pydantic의 선언적 방식으로 복잡한 검증 로직 최소화.
• 문서화 자동화: OAS와 통합해 Swagger/Redoc/Scalar로 바로 시각화 가능.
• AI 활용: 타입 기반의 명확한 스키마로 AI 도구(예: 코드 생성기)와의 호환성↑.

API 구현 방식 비교

• DRF의 Serializer로 요청/응답 데이터 처리.
• drf-spectacular 같은 라이브러리로 OAS 스키마 생성.
• Swagger/Redoc으로 문서화.
• 문제점:
• Serializer가 모델과 강하게 결합되어 외부 인터페이스 정의가 모호해질 수 있음.
• 복잡한 유효성 검사는 커스텀 로직이 필요.
• 문서화가 별도의 설정/라이브러리에 의존.

• Pydantic으로 요청/응답 스키마 정의 → DRF 뷰에서 검증 및 처리.
• OAS 자동 생성 및 Scalar로 Markdown 기반 문서화 가능.
• 장점:
• 명확한 DTO 정의로 외부 인터페이스와 내부 로직 분리.
• 빠른 유효성 검사와 간결한 코드.
• Scalar의 Markdown 지원으로 문서화 작업 간소화.

• API 구현 방식 기존 방식과 비교
• Schema Generator, Swagger
• Pydantic 예시 코드 (Request, Response)
• OAS width Markdown. scalar는 설명에 MD 사용 가능

Pydantic 예시 코드

요청/응답 모델 정의

from pydantic import BaseModel, Field
from typing import Optional
from datetime import datetime

# 요청 DTO
class CreateUserRequest(BaseModel):
    username: str = Field(..., min_length=3, max_length=50, description="사용자 이름")
    email: str = Field(..., pattern=r"[^@]+@[^@]+\.[^@]+", description="이메일 주소")
    age: Optional[int] = Field(None, ge=18, le=120, description="나이 (선택)")

# 응답 DTO
class UserResponse(BaseModel):
    id: int = Field(..., description="사용자 ID")
    username: str = Field(..., description="사용자 이름")
    email: str = Field(..., description="이메일 주소")
    created_at: datetime = Field(..., description="계정 생성 시간")

    class Config:
        from_attributes = True  # ORM 객체를 Pydantic 모델로 변환 가능

DRF 뷰에서 사용

from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework import status
from pydantic import ValidationError
from django.contrib.auth.models import User

class UserCreateView(APIView):
    def post(self, request):
        try:
            # Pydantic으로 요청 데이터 검증
            data = CreateUserRequest(**request.data)
            # Django ORM으로 사용자 생성
            user = User.objects.create(
                username=data.username,
                email=data.email
            )
            # 응답 데이터 생성
            response = UserResponse(
                id=user.id,
                username=user.username,
                email=user.email,
                created_at=user.date_joined
            )
            return Response(response.dict(), status=status.HTTP_201_CREATED)
        except ValidationError as e:
            return Response(e.errors(), status=status.HTTP_400_BAD_REQUEST)

Validator 적용

from pydantic import BaseModel, field_validator

class CreateUserRequest(BaseModel):
    username: str
    email: str

    @field_validator('username')
    def username_alphanumeric(cls, v):
        if not v.isalnum():
            raise ValueError('Username must be alphanumeric')
        return v

Wrapper Decorator (유효성 체크 로직)

from functools import wraps
from rest_framework.response import Response
from rest_framework import status
from pydantic import ValidationError

def validate_request(model):
    def decorator(view_func):
        @wraps(view_func)
        def wrapper(view, request, *args, **kwargs):
            try:
                validated_data = model(**request.data)
                request.validated_data = validated_data
                return view_func(view, request, *args, **kwargs)
            except ValidationError as e:
                return Response(e.errors(), status=status.HTTP_400_BAD_REQUEST)
        return wrapper
    return decorator

# 사용 예시
class UserCreateView(APIView):
    @validate_request(CreateUserRequest)
    def post(self, request):
        data = request.validated_data
        user = User.objects.create(username=data.username, email=data.email)
        response = UserResponse(id=user.id, username=user.username, email=user.email, created_at=user.date_joined)
        return Response(response.dict(), status=status.HTTP_201_CREATED)

OAS with Markdown (Scalar 사용)

from drf_spectacular.utils import extend_schema
from drf_spectacular.types import OpenApiTypes

class UserCreateView(APIView):
    @extend_schema(
        request=CreateUserRequest,
        responses={201: UserResponse},
        description="""# Create User API
        Creates a new user with the provided username and email.
        - **Username**: Must be alphanumeric.
        - **Email**: Valid email format required.
        """
    )
    def post(self, request):
        ...

Why not FastAPI or Django Ninja?

• Why not FastAPI?
• FastAPI도 훌륭한 프레임워크. 하지만 ORM 과 DB 마이그레이선 도규 툴링이 필요함
• 강력한 장고 ORM과 기타 다양한 장고 편의 기능을 그대로 이용하고 싶을 경우
• 찾아보면 장고로도 Async 능히 할 수 있음
• Why not Django Ninja?
• Fast API와 장고의 장점을 가장 잘 살린 프레임워크
• 비동기도 잘 됨. 하지만, (사진)
• 이름은 장고이지만 철학적으로는 Fast API에 가까움
• 장고 레거시 프로젝트에 도입이 어려움

• 장점: Pydantic과 통합이 뛰어나며, 비동기 처리에 최적화.
• 단점:
• Django ORM, 마이그레이션, 생태계의 편의성을 활용하려면 추가 설정 필요.
• 기존 Django 프로젝트와의 통합이 복잡할 수 있음.
• DRF + Pydantic 선택 이유: Django의 강력한 ORM과 생태계를 그대로 활용하면서 Pydantic의 장점을 취함. Django도 async 지원 가능.

• 장점: FastAPI와 Django의 장점을 결합. 비동기 지원, Pydantic 통합.
• 단점:
• FastAPI 철학에 가까워 Django 레거시 프로젝트와의 통합이 어려움.
• DRF의 뷰셋/라우터 같은 고급 기능 부족.
• DRF + Pydantic 선택 이유: DRF의 성숙한 생태계와 뷰셋 기반 워크플로우 유지 가능.

DRF + Pydantic + Validation 방식의 장단점 (결론)

• 명확한 인터페이스: Pydantic으로 외부 API 스키마와 내부 로직 분리.
• 빠른 유효성 검사: Rust 기반 Pydantic으로 성능 향상.
• 자동 문서화: OAS와 Scalar로 고품질 문서 생성.
• AI 친화적: 타입 기반 스키마로 AI 도구 활용성↑.
• Django 생태계 활용: ORM, 인증, 마이그레이션 등 Django의 강점 유지.

• Django 모델과 Pydantic 궁합: 모델과 Pydantic 스키마 간 매핑 작업 필요.
• Nested Data 처리: 복잡한 중첩 데이터 구조는 추가 작업 요구.
• Spring-like 느낌: DRF + Pydantic은 Java Spring처럼 명시적이고 구조화된 느낌이 들 수 있음.

• 발표자의 결론: DRF + Pydantic + Validation 방식의 장점
• 단점: 장고 모델과 Pydantic 궁합이 아직 그렇게 좋지 않음
• Nested data는 처리가 귀찮음
• 장고를 약간 Spring 처럼 쓰는 느낌이 듦

• 멀리서 읽기가 무엇인가…? - 문학으로 갔다가 라이프니츠로 갔다가 이상한 흐름으로 가는… 발표가 될 듯.

멀리서 읽기(Distant Reading)란?

• 문학 연구에서 시작된 개념으로, 스탠퍼드 교수 Franco Moretti가 주창(교수이자 문학사학자이자 이론가).
• 전통적인 '가까이 읽기(Close Reading)'가 개별 텍스트를 깊이 분석한다면, 멀리서 읽기는 대량의 텍스트를 컴퓨터를 활용해 데이터 분석적으로 접근.
• 법률에 적용: 수많은 법률(한국 약 2000개)을 사람이 일일이 읽는 것은 비현실적 → 데이터 분석 기법으로 전체 법률의 패턴, 경향, 문제를 파악.

• (문학에서 요즘 가장 유행하는 연구) 이제 컴퓨터 생겼으니 그러지 말자-라는 사조.
• 법률도 멀리서 읽을 수 있는거 아닌가? 에서 시작
• 우리나라 법률 2000개. 100개 이상 읽은 분 별로 없을 것
• 
  

왜 필요한가?

• 법률은 방대하고, 매일 개정되며, 사람이 모두 읽기 어렵다.
• 데이터 분석(예: 키워드 매칭, 벡터 생성)을 통해 법률의 구조적 문제나 패턴(예: 복붙, 결격사유)을 발견 가능.

발표자의 주요 논점

1. 법률의 복붙 문제

• 한국 법률에서 파산자 결격사유와 피성년후견인(구 금치산자) 관련 규정이 무분별하게 복사-붙여넣기(copy-paste)됨.
• 원인: 입법자의 위험 회피, 책임 회피, 관행적 복붙.
• 문제 사례:
• 파산하면 못하는 것. - 많음, 우리나라는 파산하면 망하는 나라다… 취업,자격 제한 다 안된대요. 우리나라만 있는 K-제도?
• 왜 이렇게 됐냐? 이제부터 알아봄
• 파산자를 배제하는 규정
• 계속 늘어남
• 습관성 복붙 
• 피성년후견인(구 금치산자) 완전 동일하게 붙음.
• 이유 추정해봄.
• 이 규정에 있으니 저 규정에도 쓰자
• 과거에 이런 걸 넣은건 무슨 이유가 있었을 것이다.
• 위험 회피. 이전과 다르게 지우면 누가 책임질 거냐?
• 1949년 김동준 의원 수정안: 파산자에 대한 편견적 인식. (국회 속기록: 김동준 의원 “파산 선고 당한 사람에게 중대한 일을 맡긴다는 것은 안된다.”)
• 문제1: 일본 법에서 시작된 규정을 76년간 200번 이상 복붙
• 문제2: 법리 오류(다른 상황을 동일시/같지 않은 것을 같다고 주장).
• 2006년 노회찬 의원 주도로 파산자 결격사유 폐지 시도 → 잠시 줄었으나 이후 다시 증가.
• 2006년 고 노회찬 의원. 파산자 결격사유 폐지 운동: 세계 어디에도 이런 제도가 없다. 많은 파산 결격 사유를 삭제. 2011년부터 그 얘기를 잊어버림. 다시 늘어남.
• 아이러니: 노회찬재단 이사도 파산자는 될 수 없음.
• 
• 
• 

2. 데이터 분석 사례

• 국가공무원법 76년 분석:
• 키워드 매칭과 결격사유 유형 벡터 생성으로 법률의 패턴 분석.
• 파산자 배제 규정이 계속 늘어나는 경향 확인.
• 결론: 파이썬 등 데이터 분석 도구로 법률을 '멀리서 읽기'와 '가까이 읽기'를 병행하면 법제사의 문제점을 발견하고 개선 가능.
• 
  
• 
  

3. 법률과 소프트웨어 개발의 유사성

• 법률을 코드로 비유:
• 법률 = 76년간 유지보수된 코드, 주석 없음, 개발자(입법자) 자주 바뀜, 체계 부족.
• 복붙 = 코드 재사용의 비효율적 사례 → 버그(법리 오류) 유발.
• 문제점:
• 주석(입법 의도 설명) 부족, 잦은 입법자 교체, 체계적 관리 부재.
• 과거 반성 없이 반복된 복붙 → 법률의 비효율성과 오류 누적.

4. Pythonic Law와 법률의 코드화

• 라이프니츠의 꿈: 법률을 논리적 코드로 작성해 명확하고 체계적으로 만들자는 아이디어.
• 스마트 계약, 자율주행 등 이미 코드화된 제도 사례 존재.
• 제안: 법률을 파이썬처럼 가독성 있고, 추상화 가능하며, 덜 복잡하게 설계.
• 예: 흉기 범위의 추상화 → 법률의 가독성과 유연성 향상.
• 현실 문제: 현재 법률은 아래아한글로 작성, 개발 도구 부재, 체계적 원칙(PEP8, Zen of Python 같은) 없음.
• 발표자: 경험자로서 얘기드리는데요. 법에 주석이 없다. 76년간 계속 되는 코드. 4년마다 반 이상이 집에 가요. 개발자들이 팀 먹고 경쟁자 적이에요. 개발이 제대로 되겠습니까? 국회가 몇 번 해산되기도 했구요. 옛날 자료 남아 있는게 없음. 이런 개발 프로젝트 상상. 과거 반성을 해야겠다 생각이 드는 것. 결론은 코드를 복붙하면 위험하다.
• 
  
• 소결론: 파이썬으로 법률을 멀리서 읽자. 가까이 읽자. 과거 입법자가 틀렸을 수 있다.
• 파이썬으로, 이 방법을 통하면 우리나라 법제사를 다시쓸 수 있다 고 감히 말씀 드리고요,
• 법률을 복붙하면 위험하다. 단어 하나만 바꿔보면 개발자 이야기가 된다.(ㅋ)

5. 법률과 Zen of Python

• Zen of Python(파이썬 개발 원칙)과 법철학(론 풀러의 법의 도덕성) 유사:

• 가독성: 법은 누구나 이해 가능해야 함.
• 안정성: 너무 자주 바뀌면 안 됨.
• 실행 가능성: 실제 집행 가능한 법이어야 함.
• 오류 경고: 법률의 오류(설계와 집행의 불일치)를 조용히 넘기면 안 됨.
• 집행의 문제. 법률은 사람이 돌린다. 실제 설계와 집행이 다르게 돌아가는 것을 아무도 경고하지 않으면 76년간 잘못을 반복하게 된다.
• 
  
• 발표자 결론:
• Zen of Python no.1: 아름다운 것은 ugly 하는 것보다 낫다. 입법은 굉장히 ugly 하다.
  
• 비스마르크 “소시지와 법률은 만드는 과정을 보지 않는 것이 낫다”
• 어떻게 하면 이쁘게 만들거냐 고민. 가망이 없긴 하다. 125년 전에도 지탄 받은 만악의 근원 입법. 인식. 아직도 불신이 있다.
• 아까 말했던 76년간 개발자가 편먹고 싸우고 주석도 없고.

6. 개선 제안

• 법률에 모듈화 도입: 헌법, 민법, 형법 등 기본 모듈을 재사용해 중복 줄이기.
• 체계적 입법 원칙(법률판 PEP8) 도입.
• 주석(입법 의도) 추가, 과거 반성, 체계적 기록으로 오류 줄이기.
• 궁극적 목표: 법률을 아름답고(Better than ugly), 체계적이며, 신뢰 가능한 시스템으로 재설계.

발표자의 결론

• Pythonic Law로 법률을 재구성하면 한국 법제사를 다시 쓸 수 있다.
• 복붙 중심의 입법은 위험하며, 데이터 분석과 코드화로 법률의 효율성과 가독성을 높이자.
• 법률도 소프트웨어처럼 체계적 관리와 원칙(가독성, 안정성, 실행 가능성)이 필요하다.

Q&A

• 해결하게 된 사례가 있는지.
• 비슷한 학회/분야가 없다. 실증 경제학 쪽이 조금 관심을 가지는 듯.
• 법과 개발 분야가 완전히 다른데 발표자의 백그라운드가 궁금합니다.
• 국회에서 16년 일 공무원. 2018년에 어느날 홍대 파이썬 가르쳐주는걸 방문하다 알음알음 배움. 문제 인식은 먼저 있었다. 텍스트도 다루고 그렇게 하다보니 여기까지.
• 300명이 해서 그런거 아닌가 프레임워크 문제가 아니라 인력을 2000명 키우면 어떤지?
• 무슨 질문인지 알겠다. 무엇이 정답일지 방향성이 하나가 아니다.
• 대의민주주의 선거로 뽑아야. 너무 많이 뽑자는 요구가 많은데 이건 사람들이 반감.
• 입법처에서 입법취지를 법률의 언어로 초안. 느끼는게 경계가 애매. 효율과 정치의 영역이 떨어지지 않는다. 누구에게 불리하고 누구에게 유리. 순수하게 개발되는게 아니다. 어려움.
• 코드의 모듈 인터페이스 문제가 될 수 있다. 법률도 비슷하다고 하셨는데 다른 분야에서 인터페이스가 똑같다고 갖오면 문제가 될 수 있을 것 같다 생각. 복붙하고 똑같은 문제. 그런 내용이 추가될 수 있을지.
• 그러한 법체지침이 있는데 인용과 준용 기준이 없다. 만들어야 한다. 감각적으로는 알고 있는데 일관적으로 인용해버리면 망가지는 경우 있다. 무턱대고 인용하면 안된다. 법리 구조를 설계한다 연구가 부족. 이제 필요하다 생각.
• LLM에 대한 질문
• 지금 법률의 잘못된 구조가 더 확대 재생산되지 않을까? 걱정.
• 법률에 주석을 만드는 스펙이 있나요/ -없습니다. /- 주석 만드는 방법을 생각해야하지 않을지?/ - 보수적인 동네라 기각될 거 같다(웃음). 제대로된 메타 정보 추가해야할 것 같다. 입법취지 통과가 법률 10개나 한번에 통과가 되는데 아래아한글 문서로 잠자고 있다. 그걸 잘 활용해야할 것 같다.

세션 요약: 사회적 프로젝트 경험 과정 공유

1. 발표자의 배경 및 동기

• 배경: 사회과학 전공, 언론사 인턴 기자 경험 후 소프트웨어 엔지니어(4년)를 거쳐 데이터 엔지니어로 활동 중. 최근 프리다이빙 취미 — Z축으로 움직일 수 있다 꼭 해보시라(??)
• 
  
• 발표자
• 프로그래밍 조아하시나요? 이 좋은 연휴에, 이 더운 날에, 오신걸 보니 다들 좋아하시는 거 같습니다.
• 발표자 개발은 답을 찾는 과정, 본질: 문제 해결
• 사이드 프로젝트 개발하고 싶은데… 무엇을? 
• 개발을 위한 개발? 당신이 해결하고 싶은 문제는 무엇인가요?
• 일상에 풀어야할 문제가 아주 많습니다.
• 내가 해결하고 싶은 문제가 무엇이었는지에 대한 이야기.

2. 프로젝트: Leave Her Alone

• 프로젝트 개요: 여성 혐오 및 폭력 관련 기사를 수집, 가공, 분석하여 문제의 실태를 가시화하는 웹사이트. 데이터 수집-가공-분석-활용 파이프라인을 통해 사회적 문제를 직시하고 해결 방안을 모색.
• 개발 동기: 어쩌다?
• 시작은 2018년. 인턴 기자. 업무로서 뉴스 모니터링. 그러다보니 어떤 경향성 보임.
• 우리 사회 정말 많은 여성 대상 범죄가 있다.
• 그럼에도 불구하고 공식적인 이 현상에 대한 인지도가 굉장히 낮다. - 웬만큼 충격적인 사건이 아닌 이상 주목을 받지 못한다.
• 특정 인구집단에 대한 폭력과 차별이 지속. 우리 사회에서 관심이 너무 낮다. 모른다. 문제 의식.
• 부작위에 의한 방조? 우리 사회가 이런 상황이 아닌가?
• 2018년 당시에는 방법을 몰랐다. 개발자 생활. 이제 뭔가 해볼수 있지 않을까?
• 동기: 2018년 언론사 인턴 시절 뉴스 모니터링 중 여성 대상 범죄 및 혐오의 심각성을 인지. 그러나 사회적 관심과 인지도가 낮다는 점에서 문제의식을 느낌. 특히, 충격적인 사건이 아니면 주목받지 못하는 현실과 특정 인구집단에 대한 지속적인 폭력/차별 문제를 "부작위에 의한 방조"로 비판.
• 문제 정의:
• 우리 사회의 여성 대상 범죄와 혐오 문제는 심각하지만, 공식적인 인지도가 낮음.
• 중복된 기사와 무관한 데이터로 인해 문제의 본질을 명확히 드러내기 어려움.
• 목표: 기술을 활용해 여성 혐오 문제를 가시화하고, 사회적 논의를 촉진하는 데이터 기반 저장소 구축.

3. 데이터 파이프라인 구축

• 데이터 수집:

• 출처: 국내 언론의 특성상 포털 사이트(네이버, 다음 등)에 집중된 뉴스 데이터를 웹 스크래핑으로 수집. 제목, 본문, 요약 추출.
• 특이점: 해외 언론은 자체 홈페이지에서 데이터를 공개하지만, 한국은 포털 중심.
• 어떻게 모을까? 구체적으로는 어디서 수집할지
• 우리나라 언론의 특성- 포털에 집중. 외국은 전문 공개를 언론사 홈페이지. 포털이 아님.
• 포털 사이트로 웹 스크래핑.
• 제목, 본문, 요약 수집.

• 데이터 가공:

• 주제와 무관한 데이터 걸러냄. LLM 활용.
• 비용 줄이기 위해 간단한 키워드 기반 필터링. KoNLPy, Mecab (형태소분석)
• 1차 필터링: KoNLPy, Mecab을 활용한 키워드 기반 필터링으로 주제와 무관한 데이터 제거. 비용 효율성을 고려.
• 2차 필터링: Anthropic API와 LangChain을 활용한 의미 기반 필터링. 클로드(Claude) 모델이 인권 및 여성 혐오 주제에서 우수한 성능 발휘.
• 결과: 약 1,023건의 기사에서 74건(평균 50~100건)으로 필터링.

• 데이터 분석:

• 초기 목표는 범죄 관련 기사 수집이었으나,수집할 데이터를 보다 보니 자기 자리에서 노력하고 있는 분들이 많았다(긍정적 부분).
• 긍정적 기사 수집으로 확장.
• Anthropic API와 LangChain으로 국제 여성 폭력 기준을 참조해 기사를 범주화. 국제 여성 폭력 기준 범주 참조해서 범주화, (결코 정신 건강에 좋지 못한 일인데 AI 덕분에 사람이 일일히 하지 않고 할 수 있었다…감사)
• 다음 문제점: 의미상 중복된 기사 다수. 이를 해결하기 위해 jhgan/ko-sroberta-multitask 한국어 특화 임베딩 모델과 OpenSearch k-NN 벡터 검색을 활용, 유사도 0.85 이상인 기사를 클러스터링해 대표 기사 선정.
• 실제로는 서로 다른 데이터지만 의미상으로는 중복 기사.
• 나열만 해서는 힘들겠다 생각.
• 대표 기사 - 비슷한 기사 묶어서 표현 할 수 있게 되었다.
• 여기까지가 해결한 문제

4. 해결한 문제와 남은 과제

• 해결한 문제:

• 데이터 수집-가공-분석 파이프라인 구축.
• 중복 기사 문제를 벡터 임베딩과 OpenSearch로 해결, 대표 기사 중심의 명확한 데이터 제시.

• 남은 과제:

• 사람의 개입 최소화(자동화 강화).
• 데이터 시각화 개선.
• 국제화(i18n) 지원.
• 참여형 컨텐츠 개발(사용자 참여 유도).

5. 활용한 도구

• Supabase: PostgreSQL 기반 클라우드 DB. Firebase 대체제로, 인증 API와 직관적인 UI 제공. 10GB까지 무료.
• Vercel: GitHub 저장소 기반 빠른 배포, 환경변수, 도메인, 애널리틱스 지원. V0에서 프롬프팅으로 Next.js 웹앱 개발 및 원클릭 배포.
• Claude (Anthropic): 코드 작성 및 데이터 분석에 활용. .md 파일부터 개발 시작, AI 주도 개발로 학습 효율성 증대.

6. 후기 및 교훈

• RDD(Research-Driven Development)의 효능:

• 기획, 개발, 배포, 운영 전 과정을 혼자 경험하며 체득.
• 관심 있던 기술(LLM, 임베딩, 벡터 검색 등)을 실제로 적용하며 학습.
• 중도 포기 방지: 사회적 문제의식과 지지 커뮤니티의 응원이 동기 부여.

• 시작의 중요성: 작은 일부터 시작하고, 주변에 알리며 커뮤니티와 협력.

• 2025년 3월 여성의 날에 프로젝트 공개 후 많은 지지와 피드백 받음.

• 커뮤니티와의 연결:

• 같은 문제의식을 가진 사람들과 협업, 새로운 해결 방식 공유.
• 시빅 테크 커뮤니티 추천:
• TECH FOR !MPACT: 카카오 운영, 사회적 혁신가와 개발자 연결 플랫폼. 8월 25일 코엑스에서 국내 최초 컨퍼런스 예정.
• Parti: 데이터로 사회문제 해결을 목표로 하는 시민 데이터 플랫폼.
• 널채움(nullfull): 국회 활동 시각화, 남양유업 관련 프로젝트 등.
• 후기
• 작은 일부터 시작하기, 일단 시작하기
• 주변에 알리기, 커뮤니티와 함께하기
• 알렸더니 같은 문제의식을 가지고 있고, 다른 방식으로 해결하려 하시는 분들을 알게됐고, 지난 3월 여성의 날에 공개 했는데…, 많은 분들께서 지지를 해 주셔서 힘이 됐고… 등등

7. 메시지

• 기술은 사회와 유리된 것이 아니라, 한 사람 한 사람의 문제를 해결하는 도구.
• 사회적 문제 해결에 관심 있는 개발자라면 작은 것부터 시작하고, 커뮤니티와 함께 행동할 것.

• Q&A
• 정말 의미 있는 프로젝트 같습니다, 확장하실 생각? 방향?
• 약한 부분을 다른 사람과 함께하면서 보충하고 싶다. 시각화 약함.
• 팀프로젝트로 전환하고 싶다.
• 목적은 이 현상에 대한 인지도를 높이고 싶다 였기 때문에
• 커뮤니티를 만들고 기술에 잘 관심이 없는 사람도 사용할 수 있었으면 
• 실례지만 월비용? 현실적인 어려움
• 본격 운영 그리 오래되지 않음. 개발은 몇 개월 됐는데. 사용자가 많지 않아서
• 앤스로픽 API 활용 비용 정도.
• 데이터 활용까지 정확히 사용. 조언을 받으신건가요?
• 커뮤니티에서 귀동냥 많이.
• 잘 아시는 분들 세션 많이 듣다보니 뭘 모르는지 알 수 있고 키워드도 알 수 있고.
• 임베딩 벤치마크 결과는 어디서 볼 수 있나요
• 로컬에서 데이터셋을 가지고 해 봤다.
• (진행자)널채움 같은 경우는 저도 들어가 있는데… 절대로 불매를 조장하지 않습니다. 남양유업 제품을 찾았다고 축하를 해드리는 사이트임… (ㅋ)

세션 요약: MCP와 대화형 인프라의 미래

1. 소개: MCP와 바이브 코딩

• 주제: 최신 트렌드인 MCP(Model Context Protocol)와 대화형 AI를 활용한 시스템 운영 방식인 바이브 코딩.
• 핵심: 복잡한 CLI나 다중 대시보드 기반 운영에서 벗어나, 자연어 기반 대화형 운영으로 전환. AI(자비스)가 문제를 진단하고 해결하는 것이 새로운 표준(뉴노멀)으로 자리 잡을 가능성.
• 문제 상황 예시:
• 새벽 3시 운영 알람 발생 → 수많은 대시보드 로그인 → 문제 원인 진단 어려움.
• 새벽 3시 운영 알람… 저 같은 경우 심장이 쿵쾅…
• 03:15 수많은 대시보드 로그인. 문제 진단. 볼 수 있는 대시보드 원인을 찾으면 다행인데 못찾는 경우도 많음
• 04:15 자비스처럼 해 줬으면 좋겠다...
• 기존: CLI 명령어, 복잡한 학습 곡선, 도구 과잉 문제.
• 이후: 자연어로 질문 → AI가 문제 원인 분석 및 해결 제안.

2. MCP란?

• 정의: MCP는 LLM(대규모 언어 모델)과 외부 데이터 소스 및 도구를 연결하는 오픈 프로토콜. 앤스로픽(Anthropic)에서 공개.
• 특징:
• 단일 표준 프로토콜.
• 양방향 실시간 통신.
• 안전한 접근 제어.
• 확장 가능한 구조.
• 동작 원리:
1. 사용자가 자연어로 질의.
2. MCP가 의도를 파악해 적절한 서버 호출.
3. 프로토콜 변환 및 실행.
4. 사용자 친화적 응답 전달.
• 3대 원소:
• Prompts: 사용자 질의.
• Resources: 데이터 엔티티.
• Tools: LLM과 연결된 API 및 기능.

3. MCP의 활용 사례

• 과거 vs. 현재:
• 과거: CLI 기반 K8S 문제 해결 (복잡한 명령어, 디플로이먼트 태그 수정 등).
• 현재: 자연어로 문제 진단 및 해결 (예: 잘못된 도커 이미지 태그 자동 수정 및 배포).
• 예시 대화:
• 03:00 AM: 운영자 알림 수신.
• 03:02: “자비스, 시스템에 무슨 문제야?”
• 03:03: 자비스: “API 서버 CPU 사용률 95%, user-service pod 3회 재시작.”
• 03:04: “원인이 뭐야?”
• 03:05: 자비스: “로그 분석 결과 ~~ 문제. 자동 복구 시작할까요?”

4. MCP 구현 실습

• 백문이 불여일견 파이썬으로 구현 코드
• 실습 1: 간단한 계산 MCP 서버
• 목적: LLM의 수학적 계산 약점을 보완하기 위한 계산기 구현.
• 구현: 함수명, 파라미터, 주석을 활용해 MCP 툴 자동 선택 (예: add, multiply).
• 중요: 함수명, 주석, 자료형 등이 툴 매칭에 영향을 미침.
• 실습 2: 멀티 K8S 클러스터 관리
• 구현 내용:
• MCP SDK 및 K8S Client 설치.
• K8S context 관리 (클러스터 목록 조회, 현재 클러스터 설정).
• Pod 정보 관리 (목록, 세부 정보, 로그 조회).
• 기타 K8S 오브젝트 관리 (namespace, deployment, service 등).
• 데모: 자연어로 “잘못된 도커 이미지 태그 수정” 요청 → MCP가 자동으로 문제 해결 및 배포.
• 툴 선택 방식:
• 함수명, 주석, 파라미터, 자료형 기반으로 의미적 유사성과 스키마 호환성을 분석.
• @mcp.tools() 데코레이터: 자동으로 주석 생성, 함수 메타 정보 등록.

5. 미래 전망: 대화형 인프라

• 미래에는 어떻게 서비스 배포 환경이 될지 감히 예상해본다…
  
• 예상 시나리오:
• 복합 질의: “다음 1시간 내 문제 발생 가능성이 높은 서비스는?”
• 자동 복구: AI가 선제적으로 문제를 해결.
• 통합 요약: “전체 시스템 상태 요약해줘.”
• K8S를 넘어서 확장 가능성:
• K8S뿐만 아니라 DB 확장, CI/CD 파이프라인, 보안 모니터링, 클라우드 리소스 관리까지 통합.
• 비전: 자연어 기반의로 통합 인프라 운영이 가까운 미래에 현실화될 가능성. 5~6개월 전만 해도 상상 못했다. 충분히 가까운 미래에 될 것 같다.

6. 결론

• MCP는 LLM과 시스템 간의 다리 역할을 하며, 복잡한 운영을 자연어 기반의 간단한 대화로 전환.
• 바이브 코딩은 운영의 효율성과 접근성을 높여, AI 중심의 뉴노멀을 제시.
• 미래: 다양한 MCP 서버가 구성되면, 예측, 자동 복구, 통합 관리 등 혁신적인 인프라 운영이 가능할 전망.

• 오히려 장애를 일으키지는 않았나요?
• 생각보다 K8S 잘 알고 있어서 MCP 작성을 잘 해준다면 잘 한다. 더 많이 써봐야 알 듯…
• DB나 K8S를 포함 공식에서 MCP 서버를 제공하고 있거나 비공식 제공하고 있는데 직접 구축해서 얻을 수 있는 특이점은?
• 개발 계기는. 써보니 K8S MCP 서버가 잘 동작하는게 없었다. 사실 바이브 코딩 통해 빠르게 개발했고 잘 동작하는걸 확인.
• 인프라 운영 시에는 민감한 정보를 넣는 경우가 있을텐데요
• 프라이빗 LLM에 대해서는 잘 답변드리기 어려울거 같습니다… 저는 열심히 쓰고 있는 입장이라서…(웃음)

• 발표자: SIONIC AI 재직, ML Backend
• Chunking 영역 자체가. 보통 10분 정도면 넘어가는 주제. 청킹 딥하게 공부하며 느낀점.
• 청킹 고도화 등
• RAG 설명
• 왜 필요한가?
• 현 LLM은 어떻게 기억하는가?
• Maximum length는 왜 존재하는가? — 대화가 길어지다보면 왜 제한이 있지?
• → 현재 LLM은 기억하지 않는다. 이전 대화 그대로 복사 모두 가지고 있다가 그대로 넣어 답변 생성 구조.
• Context length의 한계. 질문하고 싶은 문서가 있는데 모델 길이 초과.
• 질문 답변 문서 모든 내용이 필요할까? 나누는 과정 청킹.
• 질문 2번에 대해 설명해줘. 원하는 적절한 청크를 검색.
• 청킹 종류 - 고정 크기 청킹
• 가장 Naive한 방법
• 구분자로 자르고 크기 체크(상위 우선순위 구분자로 자르고, 낮은 순위 구분자로 자르고, 반복)
• 트레이드오프: 잘게 자르면 문맥 정보를 잃어버리게 된다. 크게 자르면 검색성능이 약해진다.
• 내용을 보고 자를 수 없을까? - 시맨틱 청킹
• 의미론적 분할
• 발전한 방식 같은데? 실제로는 ~~ 불과.
• 진정한 시맨틱 청킹이 존재하는가?
• 진정한 시맨틱 청킹
• 약 3개월 전 논문 공개. MoC(mixture-of-chunkers)
• 다양한 분야 전문가 LLM 선택
• 선택된 전문가 LLM이 이 구간은 자르면 좋겠다. 제안.
• 단점; 너무 비싸다. 학술적으로는 재밌는 접근.
• 청킹 고도화 가장 현실적인 타협적은?
• 잘린 청크의 정보 손실을 사후에 보완하는 것이 실용적이다.
• 메타데이터를 보존하자.
• 예: 2개 보고서 문서에서 청크로 구분 가능? 문서에서 뽑을 수 있는 데이터 같이 넣어줌.
• 메타데이터 활용 예시 - 오버랩 텍스트 LLM이 잘못 이해 가능. 오버랩 영역을 메타데이터에 넣어줌.
• 컨텍스트를 유지하려는 시도 Contextual Retrieval
• 이미지 모델 보고서.pdf: 이미지 이해 능력은 아래와 같다 | 효율성이 30% 향상 ← 무엇에 대한 설명?
• “이 청크가 무엇에 관한 것인지 설명하는” 컨텍스트를 추가 
• 이 청크가 어떤 의미가 있고 어떤 영역에 있고 어떤 부분에 위치하는지
• LATE CHUNKING
• 기존 문제점: 임베딩과 엮여 있는데, 단락 마다 the city, its, … 같은 의미 등장할 때
• Naive 청킹: 청킹하고 임베딩하는 방식
• Late chunking: 문서 전체를 집어 넣고 → 임베딩 벡터가 있는 모델 내부에서 청킹
• 문서를 전부 넣는 것이기 때문에 Maximum length 등 한계는 있음
• ML Backend 직무 설명
• QA 
• 웹 스케일에서 수억건 빠른 반응 방법
• 비용 효율 고려해 시맨틱 청킹보다 naive 청킹을 추천
• RAG 성능 지표가 있으셨나요
• 기존 모델들 가지고 있어 수치적 비교