학생에서 개발자로: DB, 보안부터 AI까지, 정답보다 합리적인 선택을 배우다

Context

학생 시절에는 요구사항에 맞춰 기능 동작만 중심이었다면, 대규모 트래픽 운영 환경에서는 데이터 무결성, 성능, 보안, 유연성 간의 트레이드오프를 고려해야 한다.

Technical Solution

• FK(Foreign Key) 관리 전략 변경: DB 제약이 아닌 Application 계층에서 무결성 책임으로 이동 및 테스트 강화
• 소프트 딜리트(Soft Delete) 도입: deleted_at 필드를 통해 감사 추적과 복구 가능성 확보
• 인덱스 전략 재정의: B-Tree뿐 아닌 GIN, GiST, SP-GiST, Vector 인덱스를 데이터 특성별로 선택
• SQL 실행 경로 최적화: 쿼리 결과가 아닌 실행 계획(EXPLAIN)을 기반으로 설계
• 의도적 반정규화 전략: 읽기 성능을 위한 데이터 중복과 스냅샷 저장을 비즈니스 요구사항에 따라 적용
• Rate Limiting 기본 방어 구현: DDoS 공격 시 트래픽 증가와의 구분을 위해 요청 수 제한 적용
• API 보안 실습 강화: 취약점을 직접 체험하며 공격자 관점 이해
• AI Agent 아키텍처 설계: 모델이 아닌 설계 패턴으로 접근하여 함수 정의(툴), 조건부 호출(라우팅), 예외 처리 조합
• Prompt Chaining 적용: 거대한 요청을 단계별로 분해하여 컨텍스트 오염 방지
• Few-shot 프롬프팅 구현: 예시를 통해 LLM 출력 규격 명확화
• 프롬프트 분기(Routing) 구조: 조건에 따라 다른 프롬프트 경로 선택
• 멀티 에이전트(Multi-Agent) 아키텍처 도입: 단일 모놀리식 AI 대신 역할별 에이전트로 분산
• MCP(Model Context Protocol) 활용: 내부 시스템 기능을 AI 호출 가능한 함수(Tool)로 노출
• RAG(Retrieval-Augmented Generation) 구조화: 문서 청킹 및 유사 벡터 검색으로 할루시네이션 정성적 감소

Key Takeaway

개발자는 이론적 정답보다 운영 비용·트래픽·변경 빈도를 고려한 현실적 설계를 우선으로 판단해야 하며, 보안은 개발 말단이 아닌 기본값으로 통합되어야 하고, AI는 감정적 프롬프팅이 아닌 구조화된 시스템 설계로 다루어야 한다.