📌 Tech Stack: Python (Flask), LangChain, Gemini API, FAISS, PostgreSQL, Docker, Swagger

• AI 챗봇 백엔드 개발: LangChain + FAISS 기반 벡터 검색 및 최적화
• 프롬프트 엔지니어링: AI의 문맥 유지, 출처 제공 기능 개선
• API 개발 및 문서화: Flask-RESTX 기반 백엔드 구축 + Swagger 도입
• 배포 및 환경 설정: Docker 컨테이너화 + AWS RDS 활용

🏗️ Inflow Chat 개발 회고: 사내 문서 기반 AI 챗봇을 만들며

📌 프로젝트 개요

지난 한 달 동안, Rikkei에서 진행한 인턴십을 통해 사내 문서 기반 AI 챗봇인 Inflow Chat을 개발했다.
관리자가 PDF, DOCX, Weblink를 업로드하면 문서를 분석하고 벡터화하여 저장하고, 사용자는 챗봇을 통해 질문을 하면 벡터 DB(FAISS)를 활용하여 관련 문서를 찾아 LLM(Gemini API)를 통해 답변을 생성하는 구조다.

🎯 기술 스택

• Backend: Flask
• AI/LLM: LangChain, Gemini API
• Vector DB: FAISS
• Database: PostgreSQL (AWS RDS)
• Container: Docker

💡 내 역할

• 문서(웹 링크) 파싱 및 벡터 DB 저장 (BeautifulSoup, FAISS, PostgreSQL)
• 사용자 질문을 벡터화하고 관련 문서를 검색하는 시스템 구축 (LangChain, FAISS)
• LLM(Gemini) 기반 응답 생성 및 프롬프트 최적화 (프롬프트 엔지니어링)
• 사용자 채팅 기록(최근 10개 질문) 저장 및 문맥 유지 기능 추가 (PostgreSQL, Flask)
• 벡터 DB 성능 최적화를 위한 청크 사이즈 실험 (LangChain, similarity_search_with_score)
• 협업 환경 세팅 (Docker 컨테이너화, GitHub 브랜치 전략 도입)

🚀 인턴 회고 - 명확한 기획과 요구사항, 그리고 협업의 가치

🎯 애자일 스크럼 방식의 개발 경험

이번 인턴십에서는 애자일 스크럼 방식으로 프로젝트를 진행했다.
PM과 PO가 체계적으로 Task를 관리해준 덕분에,
✅ 내가 지금 무엇을 했고, 하고 있고, 할 것인지 명확하게 파악할 수 있었다.

이전의 팀 프로젝트에서는 기획 단계부터 참여했다.

• 문제 상황을 분석하고, 페인포인트를 정의하고, 솔루션을 구상하는 과정에서부터 시작.
• 그리고 그 기획에 맞춰 개발을 진행.

하지만 회사는 달랐다.

• 회사에서는 이미 기획과 요구사항이 명확하게 정의되어 있었다.
• 이 문서를 바탕으로 시스템을 설계하고, 개발해야 했다.

📌 System Requirements (시스템 요구사항)

• User Types, Authentication, Employee Interface, Admin Interface

📌 Technical Requirements (기술 요구사항)

• Architecture, Deployment, Code Management, Security, Performance, Streaming

이 문서를 분석하며, 필요한 기능을 도출하기 위해 Use Case를 고려하고 Use Diagram을 그렸다.

📚 소프트웨어 설계 - 이론과 실무의 차이

💡 소프트웨어 설계 과목에서 배운 경험

인턴을 오기 직전 학기에 소프트웨어 설계 과목을 수강했다.
정말 흥미로웠던 수업이었고, 커리어를 이쪽으로 키워가고 싶다는 생각이 들 정도로 재미있었다.

그때 진행한 기말 프로젝트:

• 특정 소프트웨어를 선택하여 Use Case 작성 → Use Diagram, Class Diagram, Sequence Diagram 설계.
• 교수님을 5번 넘게 찾아가며 질문하고, 정말 미친듯이 열심히 공부했다.
• 발표와 실습 모두 1등! 당연히 A+

하지만 과제를 하면서 가장 혼란스러웠던 것은 명확한 요구사항이 없었다는 것이었다.

• 내가 직접 기획한 프로젝트를 기반으로 설계를 하다 보니,
• 내가 생각하는 방향이 맞는지 확신이 없었다.
• 프로젝트 초반에는 "신체 리듬에 맞춘 게임"이었지만, 끝에 가서는 "맥박과 혈압 기반 게임"이 되어버렸다.

이 경험을 통해 명확하지 않은 요구사항은 시스템 설계에서 혼동을 일으킬 수 있다는 점을 깨달았다.

🛠️ 명확한 요구사항이 주어진 환경에서의 개발

인턴십에서는 이전의 팀 프로젝트와는 다르게, 명확한 기획과 요구사항이 있었다.

• 기획 문서를 분석하면서 필요한 기능을 도출하고,
• Use Case를 정리하고, Use Diagram을 작성하며 기능을 리스트업했다.

개인 프로젝트에서 혼자 기획부터 했던 경험과 비교하면, 너무나도 명확한 프로세스였다.

📌 실제 경험한 User Validation 과정

• 설계한 기능과 Use Diagram을 멘토 및 PO와 함께 검토하며 Validation을 받았다.
• 소프트웨어 설계 과목에서 배운 개념을 실무에서 적용하는 순간이었다!
• 배운 개념을 직접 활용한다는 것이 두근거렸고, 나의 설계가 긍정적인 평가를 받은 것도 기뻤다.

🤝 팀 미팅에서 회의의 목적을 상기하다

💡 회의에서 의견 차이가 발생했던 순간

• 우리는 Wire Frame과 User Flow를 검토하는 회의를 진행하고 있었다.
• 하지만 갑자기 팀원 중 한 명이 UI 디자인을 논의하기 시작했다.
  • 버튼 모양은 Square vs Round?
  • 색상은 Red vs White?
• 이 회의의 목적과 다소 벗어난 논의였다.

나는 개발팀 소속이었기 때문에,
UI 설계보다는 시스템 동작과 데이터 흐름을 확인하는 것이 목적이라고 생각했다.
하지만 바로 의견을 제시하는 것이 아니라,
📌 먼저 PO에게 내 입장을 간략하게 전달했다.
📌 그리고 UI를 논의하던 팀원에게 조심스럽게 "회의의 목적을 다시 한번 생각해보자"고 제안했다.

📌 결과:
✅ 팀원도 내 의견에 동의했고, 회의가 원래 목적대로 진행되었다.
✅ 상대방의 의견을 존중하면서도, 회의 목적을 상기시키는 커뮤니케이션의 중요성을 배웠다.
✅ 상대방이 기분 나쁘지 않게 내 의견을 전달하는 방법을 고민하는 것이 중요하다.

📂 체계적인 프로젝트 관리 - WBS, Gantt Chart 활용

📌 전문적인 프로젝트 관리 경험이 가장 인상적이었다.

• PO가 요구사항 명세서를 참고하여 WBS(작업 분류 구조)와 Gantt Chart(일정 관리 차트)를 생성.

✅ WBS (Work Breakdown Structure)

• 모듈별로 Use Case가 명세화되어 있어, 한눈에 보기 편했다.

✅ Gantt Chart (간트 차트)

• 각 Task의 진행 상태, 예상 소요 시간, 담당자(PIC), 진행 여부를 시각적으로 확인할 수 있었다.

📌 Trello와 Teams를 활용한 협업

• Trello 보드를 통해 ToDo / Doing / Done 상태를 쉽게 관리.
• 혼동이 올 때마다 Gantt Chart와 Trello를 보면서 개발을 진행.
• 다른 팀원의 진행 상황을 실시간으로 확인하며, 이슈가 생길 경우 빠르게 도움 요청 가능.

이전 회사에서는 Jira를 사용했는데, 처음에는 칸반 보드나 백로그 개념이 어려웠다.
이번 인턴십에서는 Trello를 활용하면서 프로젝트 관리를 한층 더 쉽게 이해할 수 있었다.

📌 커뮤니케이션의 중요성

• 팀원 중 한 명이 자신의 Task 진행 상황을 명확하게 공유하지 않는 경우가 있었다.
• 나는 PO가 진행 상황을 빠르게 파악할 수 있도록 Teams에 지속적으로 업데이트했다.
• PO가 굳이 내 자리까지 와서 물어보지 않아도, 내가 진행하는 Task를 한눈에 볼 수 있도록 배려했다.

📢 스크럼 & 데일리 미팅을 통한 피드백

• 매일 11시 데일리 미팅을 진행했다.
• 자신이 어제 무엇을 했고, 오늘 무엇을 할 것인지 공유.
• 멘토님들도 참여하여, 날카로운 질의응답을 통해 피드백을 제공.

💡 "왜?"라는 질문의 중요성

• 개발을 하면서 단순히 기능을 구현하는 것이 아니라, 왜 이렇게 설계했는지 설명할 수 있어야 한다.
• 멘토님들의 질문에 답변하면서, 내 코드와 설계에 대해 더욱 깊이 고민하게 되었다.

🛠️ 자원이 제한된 환경에서 최적의 아키텍처 설계

📌 Local 환경에서 개발해야 한다는 제한 사항

• 나는 배포 및 클라우드 자동화에 관심이 많았지만, 초기 개발은 Local에서 진행해야 했다.
• 자원이 부족한 환경에서 가장 최적화된 아키텍처를 고민해야 했다.

📌 AI 모델 선택

• 처음에는 경량화된 모델을 직접 활용하려 했지만, 리소스 부족으로 Gemini API를 선택.

📌 기술 스택 결정

• 나는 Java Spring Boot 개발자지만,
• 팀원들의 개발 경험을 고려하여 Flask로 개발하는 것이 최선이라는 결론.

✨ 배운 점 & 성장한 점

✅ 명확한 요구사항이 있을 때 개발이 훨씬 효율적이다.
✅ 커뮤니케이션이 프로젝트의 성공을 결정한다.
✅ 데일리 미팅과 피드백을 통해 나의 사고력이 확장되었다.
✅ 제한된 리소스에서도 최적의 기술 선택을 해야 한다.

성장한 점과 태도에 대한 회고

• 도전을 두려워하지 않고 끊임없이 성장하려고 하는 자세

🚀 도전! AI 그리고 Flask, PostgreSQL

💡 새로운 역할, 새로운 도전

역할을 분배하기 위해 데일리 미팅에서 팀원들과 이야기를 나누었다.
그 자리에서 나는 "도전을 두려워하지 않고 오히려 좋아한다."
그리고 "Challenging한 Task 속에서 성장할 수 있다면 그것이 더 좋다." 라고 말했다.

AI를 다뤄본 적은 없었고, 이해도도 낮았다. 하지만 백엔드에서 AI를 구현하는 경험을 쌓고 싶었다.
결과적으로 나는 AI 기능을 구현하는 백엔드 개발을 맡게 되었다.
아직 모르는 것이 많았지만, 배워가면서 만들어 나가는 과정 자체가 나에게 큰 동기부여가 되었다.

📌 공부는 셀프, 스피드는 생명

우리는 애자일 스크럼 방식으로 프로젝트를 진행했다.
📌 매일 데일리 리포트 작성 & 스크럼 미팅 진행
📌 매주 금요일마다 스프린트에 맞춰 데모 발표

AI 서버 역할을 맡은 이상, 매주 개발해야 하는 목록을 맞춰서 빠르게 개발하고 에러도 해결해야 했다.
내가 모르면 스스로 공부해야 했다.

Flask도 처음인데 AI 서버까지 구현해야 한다니..
그야말로 도전 그 자체였다.

퇴근 후, 서버 구현을 위한 AI 흐름을 이해하기 위해 논문을 읽고, 유튜브 강의를 보고, LangChain 공식 문서를 닳도록 읽었다.
한 2~3일 동안 죽어라 공부하니까 머릿속으로 그림이 그려졌다.
퇴근하고 밥 먹으면서도 계속 공부한 보람이 있었다.

☀️ 낮에는 빠르게 개발하고, 🌙 밤에는 공부하는 패턴을 반복했다.
이 과정 덕분에 결과물도 기간 내에 나왔고, 최적화 작업을 할 수 있는 시간까지 확보할 수 있었다.

🔥 이번 인턴십에서의 성장과 배운 점

💡 AI 백엔드 개발자로서의 도전

• 새로운 기술을 접할 때 겁먹지 않고 적극적으로 배우려는 태도가 중요하다.
• AI를 처음 다뤘지만, 몰입해서 공부하면 결국 길이 보인다.

💡 빠른 개발 & 최적화의 균형

• 개발 속도도 중요하지만, 결국에는 최적화까지 고려해야 한다.
• 기간 내에 목표를 달성하는 것뿐만 아니라, 더 나은 성능을 고민할 여유까지 확보하는 것이 중요하다.

💡 스스로 성장하는 법을 배운 경험

• 책임감 있는 역할을 맡으면, 자연스럽게 성장하게 된다.
• 퇴근 후에도 스스로 공부하는 자세가 결국 나를 더 빠르게 성장시킨다.

✨ 내 인턴십의 키워드: "성장" 그리고 "도전"

이번 인턴십을 돌아보면, 내 스스로의 키워드는 단연 "성장"과 "도전"이었다.
낯선 기술, 처음 다루는 도메인에서도 두려워하지 않고 부딪히며 성장했다.

지금 돌아보면, Flask도 처음이었고, AI 백엔드도 처음이었지만, 결국 해냈다.
그리고 그 과정에서 진짜 성장했다는 걸 느낀다.

🚀 "앞으로도 어떤 도전이 오더라도, 나는 성장할 준비가 되어 있다."

🎯 인턴십을 마치며 - 느낀 점 정리

1️⃣ 멘토님께 감사 🙏

• 매일 진행된 데일리 미팅과 데모 미팅을 통해 지속적으로 관리 & 피드백을 주신 멘토님.
• 단순한 피드백이 아니라, "너는 더 Complete하게 할 수 있다. 더 잘할 수 있다." 라는 조언을 주시며 성장할 기회를 만들어 주셨다.
• 개발 속도가 빠르고, 커뮤니케이션 능력이 좋으며, 우선순위를 잘 정해서 일한다는 칭찬을 받을 수 있어 뿌듯했다.
• 데모 미팅 때는 내가 생각하지 못했던 이슈들을 캐치해서 지적해주셨고, 이를 통해 한층 더 성장할 수 있었다.

2️⃣ 아쉬운 점 🤔

• 배포 & 인프라 경험 부족

  • 나는 자동화 배포나 클라우드 인프라에 관심이 많았지만, 이번 프로젝트에서는 Local 개발이 중심이었다.
  • 실제로 AWS나 GCP를 활용한 배포까지 경험해볼 수 있었다면 더 좋았을 것 같다.

• AI 모델을 직접 사용하지 못한 점

  • 처음에는 경량화된 AI 모델을 활용한 RAG 기반 시스템을 고려했지만, 리소스 문제로 외부 API(Gemini)를 사용해야 했다.
  • 직접 모델을 학습시키고 최적화하는 경험을 해보지 못한 것이 조금 아쉽다.

3️⃣ 도전하고 성장한 나 자신이 대견하다 💪

• 처음 접하는 기술이 많았고, 도전적인 환경이었지만, 두려워하지 않고 부딪히며 성장했다.
• 영어 실력도 많이 늘었다!
  • 문서를 읽고 기술적인 내용을 이해하는 것이 훨씬 수월해졌다.
• 무엇보다, 도전을 두려워하지 않는 내 자세가 너무 멋졌다고 생각한다.
  • 모르는 것을 배우기 위해 깊이 파고들었고, 빠르게 습득하여 결과를 만들어냈다.
  • 인턴 기간 동안, "내가 생각보다 더 많은 것을 할 수 있구나" 라는 자신감을 얻었다.

🚀 "앞으로 어떤 도전이 와도, 나는 해낼 수 있다."
🚀 "이번 인턴십을 통해, 나는 한층 더 성장한 개발자가 되었다."

🐳 1. Docker 컨테이너화를 도입한 이유 & 최적화 과정

🛑 문제 상황

1️⃣ 팀원 간 개발 환경이 일관되지 않음

• 나는 MacOS, 다른 팀원들은 Windows 환경에서 개발.
• Python 버전 차이, 패키지 설치 문제, OS 환경 차이로 인해 코드 실행 오류 발생.

2️⃣ 로컬에서 잘 되던 코드가 다른 환경에서는 실행되지 않음

• 내 환경에서는 정상적으로 실행되지만, 다른 팀원이 실행할 때 환경 차이로 인한 오류 발생.
• pip install 할 때 패키지 충돌 문제 발생.

3️⃣ 배포 시 실행 환경을 맞추는 과정이 번거로움

• 서버 환경과 로컬 개발 환경이 다르다 보니, 배포 후 실행 오류가 종종 발생.
• 환경 변수를 다루는 방식도 OS마다 차이가 있어서 관리가 어려움.

✅ 해결 방법 - Docker 컨테이너화 도입

1) Docker를 사용해 모든 팀원이 동일한 환경에서 개발 가능하도록 설정

• Dockerfile을 만들어서, 어떤 환경에서도 동일하게 실행되도록 설정.
• Python, FAISS, PostgreSQL 등 필요한 라이브러리를 Docker 환경에 통합하여 실행 환경 통일.

# 1. Python 환경을 기반으로 이미지 생성
FROM python:3.9

# 2. 작업 디렉토리 설정
WORKDIR /app

# 3. 필요한 패키지 설치
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 4. 코드 복사 후 실행
COPY . .
CMD ["python", "app.py"]

📌 결과
✅ 어떤 환경에서도 동일한 개발 환경을 유지할 수 있음.
✅ 로컬과 서버의 실행 환경이 일치하므로 배포 오류 감소.

2) Docker Compose로 전체 서비스 구성 자동화

• PostgreSQL, FAISS, Flask 백엔드 등을 함께 실행할 수 있도록 docker-compose.yml 작성.
• 한 줄 명령어로 모든 서비스 실행 가능! (docker-compose up -d)

version: '3.8'
services:
  db:
    image: postgres
    restart: always
    environment:
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: inflow_chat
    ports:
      - "5432:5432"

  backend:
    build: .
    depends_on:
      - db
    environment:
      DATABASE_URL: postgresql://admin:secret@db:5432/inflow_chat
    ports:
      - "8000:8000"

📌 결과
✅ 데이터베이스 + 백엔드를 한 번에 실행할 수 있음.
✅ 로컬 환경에서도 배포 환경과 동일한 환경에서 실행 가능.

🔥 Docker 도입 후 얻은 이점 & 배운 점

✅ 개발 환경 차이 해결 → "내 환경에서는 잘 되는데?" 문제 해결!
✅ 서버 배포가 간단해짐 → 한 줄로 실행 가능 (docker-compose up -d)
✅ 협업이 쉬워짐 → 모든 팀원이 동일한 환경에서 개발 가능.
✅ 배포 후 오류 감소 → 개발 환경과 배포 환경이 동일하므로 실행 오류 최소화.

📌 최종 정리 (TL;DR)

• 기존에는 팀원 간 환경 차이, 배포 시 실행 오류, 패키지 충돌 문제가 있었음.
• ✅ Docker 컨테이너화를 통해 개발 & 배포 환경을 통일.
• ✅ Docker Compose를 활용해 데이터베이스 & 백엔드 실행 자동화.
• ✅ 결과적으로 개발 속도 & 협업 효율이 향상됨!
• 🚀 이제 "내 환경에서는 잘 되는데?" 문제는 없다!

📄 2. API 문서화 - Swagger 도입 & 개발 경험 개선

🛑 문제 상황

1️⃣ Postman을 사용하여 API 테스트 진행했으나, 협업 시 불편함 발생

• 프론트엔드 개발자들이 API 명세를 보려면 Postman 공유 링크를 받아야 함.
• Postman에서 개별적으로 API를 실행하고 확인해야 해서 한눈에 API 구조를 보기 어려움.

2️⃣ API 개발 진행 상황을 직관적으로 볼 수 있는 방법이 필요함

• Postman으로 테스트는 가능하지만, API가 늘어날수록 진행 상황을 한눈에 보기 어려웠음.
• 자동화된 문서화 도구가 필요하다고 판단!

3️⃣ Flask에서 Swagger(FastAPI처럼 기본 지원 X)를 사용하기 위해 리팩토링 필요

• 기존 Flask 프로젝트에서 Blueprint 기반 개발을 진행하고 있었음.
• 하지만 Swagger를 적용하려면 Flask-RESTX의 Namespace 구조로 변경해야 함.

✅ 해결 방법 - Swagger 도입 및 API 리팩토링

1) Swagger (Flask-RESTX) 적용

💡 Swagger를 사용하면 API 문서가 자동으로 생성되며, 개발자들이 바로 API를 실행할 수 있음!

• Swagger를 통해 API 문서화 진행 → 프론트엔드 개발자들과의 협업 편리해짐.
• 기존 Postman 공유 방식 대신, Swagger UI에서 실시간으로 API 확인 가능.

📌 결과:
✅ API 실행과 동시에 Swagger UI에서 자동으로 문서가 생성됨.
✅ 프론트엔드 개발자가 API 테스트를 Swagger에서 직접 실행 가능!

2) 기존 Blueprint 방식 → Namespace 방식으로 리팩토링

💡 기존 Blueprint 방식에서는 Swagger 문서를 자동 생성하기 어려웠음.
📌 그래서 API를 Flask-RESTX의 Namespace 방식으로 변경!

🔄 리팩토링 과정에서 얻은 이점:

• ✅ 코드를 더 모듈화하고 API별 역할을 명확하게 분리할 수 있었음.
• ✅ API 문서가 자동 생성되면서 "이 API는 어디에 쓰는 거지?"라는 질문이 사라짐.
• ✅ 코드를 다시 한번 점검할 기회가 되어, 불필요한 엔드포인트나 중복 코드를 정리할 수 있었음.

🛠️ Swagger 도입 후 얻은 이점

📌 API 협업이 훨씬 쉬워짐!

• ✅ 프론트엔드 개발자들이 API 문서를 따로 요청할 필요 없이 Swagger에서 바로 확인 가능.
• ✅ API 요청을 직접 테스트할 수 있어 프론트-백엔드 간의 소통이 원활해짐.

📌 개발 진행 상황을 한눈에 볼 수 있음!

• ✅ Postman에서는 각 API를 개별적으로 실행해야 하지만,
• ✅ Swagger UI에서는 모든 API가 정리되어 있어 개발 진행 상황을 한눈에 파악 가능!

📌 리팩토링을 통한 코드 개선 효과

• ✅ 기존 Flask Blueprint 방식에서 Flask-RESTX Namespace 방식으로 변경하며 코드 구조가 더 명확해짐.
• ✅ 기존 API 설계 방식에 대해 한 번 더 고민할 기회가 되었음.

🔥 Swagger 도입 후 배운 점 & 느낀 점

✅ Swagger는 API 협업을 위한 필수 도구!
✅ Postman도 유용하지만, 문서화 & 협업을 위해서는 Swagger가 더 강력함.
✅ Flask-RESTX로 변경하면서 코드 모듈화 및 API 문서 자동화를 함께 진행할 수 있었음.
✅ 리팩토링 과정에서 불필요한 코드 정리를 하면서, API 설계에 대한 고민을 더 깊이 할 수 있었음.

📌 최종 정리 (TL;DR)

• 기존 Postman 방식 → Swagger(FastAPI 스타일) 문서화 도입!
• ✅ API 문서를 자동 생성 & 실시간 테스트 가능.
• ✅ 프론트엔드 개발자들과 협업이 더 쉬워짐.
• ✅ API 설계를 다시 점검하면서, 코드 리팩토링도 진행!
• 🚀 결과적으로 개발 효율 + 협업 편의성이 대폭 향상됨!

🚀 3. Git 브랜치 전략 도입 - 협업 효율성 개선

🛑 문제 상황

1️⃣ 팀원 간 Git 브랜치 전략이 없어서 코드 충돌 발생

• 나는 GitHub을 활용한 브랜치 전략 (Issue → Feature Branch → PR → Review → Merge)에 익숙했음.
• 하지만 팀원들은 개인 프로젝트에서만 개발해왔기 때문에, 협업 시 Git 규칙을 따르는 것이 익숙하지 않음.

2️⃣ 브랜치 관리 미숙으로 인해 강제 Merge 발생 → 코드 충돌 & 버그 증가

• 일부 개발자가 main 브랜치에서 직접 개발 후 강제 Merge 진행 → 코드가 꼬이고 충돌 발생.
• 코드 리뷰 없이 Merge하면서 불안정한 코드가 main에 포함되는 문제가 발생.

3️⃣ 브랜치가 꼬여서 최악의 경우 레포를 새로 생성해야 했던 상황

• Git 규칙을 따르지 않는 개발자가 많아지면서 브랜치가 관리되지 않음.
• 브랜치 이력 복잡화 + 충돌 해결 어려움 → 결국 레포를 삭제하고 새로 생성.

✅ 해결 방법 - Git 브랜치 전략 도입 및 규칙 설정

💡 1) 협업을 위한 Git 브랜치 전략을 도입 (Feature Branch Workflow 적용)

• GitHub Issue 생성 → Issue 번호를 기반으로 Feature 브랜치 생성.
• 개발 완료 후 PR을 생성하여 코드 리뷰 후 Merge 진행.

📌 Git 브랜치 전략

- main (배포 브랜치)
- develop (개발 브랜치)
  ├── feature/{issue-number}-feature-name (기능 개발 브랜치)
  ├── bugfix/{issue-number}-bug-description (버그 수정 브랜치)

📌 예제 브랜치 관리 방법

# 1. 새로운 기능 개발 시
git checkout -b feature/12-add-auth-system

# 2. 개발 완료 후 커밋 & Push
git commit -m "Add authentication system (#12)"
git push origin feature/12-add-auth-system

# 3. PR 생성 후 코드 리뷰 요청
# 4. 리뷰 완료 후 Merge & 브랜치 삭제

💡 2) 강제 Merge 방지를 위해 Git 규칙 수립
✅ PR 없이 main에 직접 Push 금지 (Branch Protection 설정)
✅ 모든 PR은 최소 1명 이상의 코드 리뷰 후 Merge
✅ Merge 전에 반드시 develop 브랜치에서 Pull 후 Conflict 해결

📌 Branch Protection 설정 예시 (GitHub 설정)

• main 브랜치에 직접 Push 불가능하도록 설정.
• PR을 통해서만 Merge 가능하도록 제한.
• 최소 1명 이상의 코드 리뷰를 필수로 설정.

💡 3) Git 커밋 메시지 및 브랜치 네이밍 규칙 통일
✅ Issue 번호 기반 브랜치 네이밍
✅ 커밋 메시지 규칙 설정 → feat:, fix:, docs:, refactor: 등의 Prefix 사용

📌 예제

feat: Add authentication system (#12)
fix: Resolve login bug (#23)
docs: Update API documentation (#30)

🛠️ 브랜치 전략 도입 후 얻은 이점

📌 협업이 훨씬 쉬워짐!

• ✅ 각 기능별 브랜치가 명확해져 코드 관리가 체계화됨.
• ✅ Git 브랜치 이력이 깨끗해지고, 코드 충돌이 감소.
• ✅ 레포를 날리는 최악의 상황을 방지할 수 있었음.

📌 코드 품질 개선!

• ✅ PR을 통한 코드 리뷰 과정이 필수화됨 → 코드 품질 향상.
• ✅ 강제 Merge 방지를 통해 코드 안정성 유지.

📌 팀원들의 Git 사용 능력 향상

• ✅ GitHub 활용 능력이 부족했던 개발자들도 Git 브랜치 전략을 따르면서 협업 역량 상승.
• ✅ Git 규칙을 지키지 않으면 협업이 불가능하다는 점을 인식하게 됨.

🔥 Git 전략 도입 후 배운 점 & 느낀 점

✅ Git 브랜치 전략이 없으면 협업이 불가능하다!
✅ 혼자 개발할 때는 필요 없지만, 팀 프로젝트에서는 Git 전략이 필수다.
✅ PR을 통한 코드 리뷰 과정이 코드 품질을 크게 향상시킨다.
✅ 강제 Merge는 최악의 결과를 초래할 수 있다 → 반드시 브랜치 보호 설정이 필요하다.
✅ 레포를 새로 파는 일은 없어야 한다 → Git 관리가 곧 협업의 기본이다.

📌 최종 정리 (TL;DR)

• 기존에는 Git 브랜치 전략이 없어서 강제 Merge, 코드 충돌, 협업 문제 발생.
• ✅ Feature Branch Workflow 도입 → 브랜치 구조 및 Merge 프로세스 정립.
• ✅ PR을 통한 코드 리뷰 필수화 → 코드 품질 향상.
• ✅ Branch Protection 설정 → 강제 Merge 방지.
• 🚀 결과적으로 협업 효율이 대폭 향상되었고, 안정적인 Git 관리가 가능해짐!

🧩 1. 벡터 DB 최적화 - Chunk Size & Overlap 설정 실험

🛑 문제 상황

• 문서를 벡터화해서 FAISS에 저장할 때,
  → 청크 크기(Chunk Size)와 오버랩 크기(Overlap Size)를 어떻게 설정해야 하는지 고민
• 너무 크면 검색이 느려지고,
• 너무 작으면 문맥이 사라져 엉뚱한 문서가 검색됨.
• 이 문제를 해결하기 위해 다양한 청크 및 오버랩 크기로 테스트 진행!

✅ 해결 방법 - 실험을 통한 최적의 Chunk Size 찾기

📌 LangChain의 RecursiveCharacterTextSplitter를 사용하여 여러 조합 테스트

test_cases = [
    {"chunk_size": 200, "chunk_overlap": 50, "title": "Test Doc Case 1", "db_path": "test_faiss_db_case1"},
    {"chunk_size": 300, "chunk_overlap": 100, "title": "Test Doc Case 2", "db_path": "test_faiss_db_case2"},
    {"chunk_size": 500, "chunk_overlap": 200, "title": "Test Doc Case 3", "db_path": "test_faiss_db_case3"},
    {"chunk_size": 400, "chunk_overlap": 150, "title": "Test Doc Case 4", "db_path": "test_faiss_db_case4"},
]

💡 실험 과정

1. 각 케이스별로 문서를 임베딩하여 FAISS DB에 저장.
2. 동일한 질문을 입력하고, LangChain의 similarity_search_with_score를 사용해 검색된 문서의 유사도 점수 비교.
3. 검색된 문서가 원래 질문과 얼마나 관련이 있는지 정성적으로 분석.

💡 테스트 결과

📌 결과적으로, chunk_size=300, chunk_overlap=100이 가장 최적의 값임을 발견!

🔥 실험 후 느낀 점 & 검색 성능 개선 효과

✅ Chunk Size & Overlap이 검색 성능에 얼마나 중요한지 뼈저리게 깨달음.
✅ 처음에는 500, 200이 좋아 보였지만, 속도가 너무 느려 실사용에 부적합. ✅ 최적의 300, 100 설정 후, 검색 성능이 대폭 개선됨 → 정확도 상승 + 빠른 검색 속도 확보!

💡 이 실험을 통해 얻은 인사이트

• 너무 작은 청크는 문맥을 잃게 만들고, 너무 큰 청크는 검색 성능을 저하시킨다.
• Chunk Size와 Overlap은 도메인과 데이터 특성에 맞게 실험을 통해 최적값을 찾아야 한다.
• 단순히 top-k 검색이 아니라, 적절한 청크 사이즈 조정이 LLM 응답 품질에도 큰 영향을 준다.

📌 배운 점

✅ 임베딩을 할 때 적절한 Chunk Size를 선택하는 것이 검색 성능의 핵심이다!
✅ 검색 성능을 높이기 위해 무조건 큰 청크를 선택하는 것이 정답이 아니다.
✅ 실제 데이터셋에 맞는 최적의 설정을 찾기 위해서는 여러 테스트 케이스를 만들어 실험하는 과정이 필수다.
✅ LangChain의 similarity_search_with_score는 검색된 문서의 연관성을 확인하는 데 매우 유용하다.

🛠️ 2. Retriever 최적화 - 문서 적합도 필터링 & 최적 검색 전략

🛑 문제 상황

• 기존 Retriever 로직에서는 관련된 문서 10개를 검색하여 모두 참고.
• 하지만, 관련성이 낮은 문서도 포함되면서 LLM 응답의 품질이 저하됨.
• 🔍 문제점: 의미 없는 문서까지 포함되면서 불필요한 정보로 인해 부정확한 답변이 생성됨.

✅ 해결 방법 - 검색된 문서의 적합도 필터링

1) 문서 적합도 판단 로직 추가
💡 적용한 최적화 기법
1️⃣ 검색된 문서들의 score 값을 평균 내고, 최고점과 비교.
2️⃣ 최소 3개의 문서가 참고되도록 설정하고,

• 상위 30% 이상의 문서를 1순위로 참고.
• 나머지 문서 중, 평균보다 현저히 낮은 문서는 필터링. 3️⃣ 평균 이상의 점수를 가진 문서를 우선적으로 참고하여 응답 생성.

def filter_documents(documents, min_docs=3, top_percentile=0.3):
    # 문서들의 점수를 정렬
    documents.sort(key=lambda x: x["score"], reverse=True)

    # 최고점과 평균 점수 계산
    max_score = documents[0]["score"]
    avg_score = sum([doc["score"] for doc in documents]) / len(documents)

    # 상위 30% 문서를 우선 선정
    top_n = max(int(len(documents) * top_percentile), min_docs)
    selected_docs = [doc for doc in documents[:top_n]]

    # 평균보다 낮은 점수를 가진 문서 필터링
    final_docs = [doc for doc in selected_docs if doc["score"] >= avg_score]

    return final_docs

📌 결과적으로, 의미 있는 문서만 필터링하여 LLM이 보다 정확한 답변을 생성하도록 개선!

🛠️ 실험 방법 & 최적화 과정

📌 벡터 DB는 직접 확인할 수 없어서 테스트 신뢰도를 확보하는 것이 중요했다.
💡 테스트 방법:
1️⃣ 웹 문서를 임베딩한 후, 세부적인 질문을 입력하여 관련 문서 검색 테스트. 2️⃣ 검색된 문서들이 어떻게 선택되는지 로그를 찍어 확인하며 최적화 진행.
3️⃣ 여러 Threshold 설정을 실험하여, 적합한 문서 필터링 기준을 찾음.

📌 실험 데이터 예시 (로그 분석 결과)

📌 결과:

• LLM이 보다 적절한 문서만 참고하도록 개선되면서 응답 품질 향상!
• 불필요한 문서를 제거하여 응답 속도도 최적화됨.

🔥 실험 후 느낀 점 & 최적화 과정에서의 고민

✅ 벡터 DB는 직접 보이지 않으므로, 로그를 찍어 확인하는 과정이 필수적이다.
✅ 수학적인 접근이 중요하다 – Score 기반 필터링 로직을 적용하면서 적절한 기준을 찾는 것이 핵심이었다.
✅ Threshold 설정은 단순한 정적 값이 아니라, 동적으로 조절될 필요가 있다.
✅ 최적화 과정은 지속적으로 이루어졌으며, 데모 때까지 고민이 이어졌다.
✅ 결과적으로 데모에는 반영되지 못했지만, AI 검색 최적화에 대한 깊은 고민을 경험할 수 있었다.

📌 최종 정리 (TL;DR)

• 기존 Retriever는 관련성이 낮은 문서까지 포함하는 문제가 있었음.
• Score를 기반으로 문서 필터링 로직을 추가하여 불필요한 문서를 제거.
• 상위 30% 문서를 우선적으로 참고하고, 평균 이하 점수를 가진 문서는 필터링.
• 실험을 통해 검색된 문서를 로그로 분석하며 최적화 진행.
• 🚀 LLM의 응답 품질 & 검색 성능이 크게 향상됨!

🎯 3. 프롬프트 엔지니어링 최적화 - AI 응답 품질 향상 실험

🛑 문제 상황

• 기존 프롬프트에서는 사용자의 대화 맥락을 유지하고, 지속적인 문맥을 제공하도록 설정했음.
• 하지만, 예상과 다르게 챗봇이 가끔 이상한 답을 하거나 맥락을 유지하지 못하는 문제 발생.
• 💡 문제의 원인:
  1. 프롬프트가 너무 일반적이어서 LLM이 정확한 답변을 생성하는 데 어려움을 겪음.
  2. 지나치게 자유로운 응답 스타일 → 가이드라인이 부족하여 AI의 응답 품질이 일정하지 않음.
  3. 대화 맥락 유지 실패 → 과거의 10개 대화를 기억해야 하지만, 효과적으로 활용되지 않음.

✅ 해결 방법 - 프롬프트 개선 및 실험 과정

💡 개선 방향
1️⃣ AI의 역할을 더 명확하게 정의

• 기존: "You are a company service chatbot."
• 개선 후: "You are a friendly and knowledgeable company service assistant chatbot."
• → AI의 목표와 성격을 구체적으로 정의하여 일관된 응답을 유도.

2️⃣ 대화 흐름을 제어할 수 있도록 지침 추가

• 단순히 문서 기반으로 답변을 생성하라고 요청하는 것만으로는 부족했음.
• 각 상황별로 AI가 어떻게 반응해야 하는지 세부적으로 지침을 추가!
• ✅ 사용자의 질문이 문서에 있는 정보와 일치하면 정확한 답변 제공.
• ✅ 정보가 없을 경우, 적절한 피드백 제공 ("I'm sorry, I couldn’t find that information…").
• ✅ 불필요한 인사말 방지 및 문장의 톤 조절 (친절하지만 간결하게).

3️⃣ 프롬프트 내부에 대화 기억 유지 로직 반영

• 기존 프롬프트: "Retain at least 10 message logs."
• 개선 후: "Directly answer user questions based on the content from the official documents and the last 10 interactions."
• → AI가 대화 기록을 어떻게 활용해야 하는지 명확하게 설명하여 문맥 유지 강화!

🛠️ 실험 과정 & 비교 테스트

📌 프롬프트 실험을 위한 평가 방법

• 동일한 질문을 여러 번 입력하고, 개선 전/후 응답을 비교.
• AI가 문맥을 유지하는 정도, 정확한 정보를 제공하는지, 답변 스타일이 일관적인지 테스트.

📌 테스트 결과 비교

📌 결과적으로 개선된 프롬프트를 적용했을 때:

• ✅ AI의 일관성 있는 응답 품질 확보!
• ✅ 사용자의 이름 & 맥락 유지 성공적으로 반영!
• ✅ 정보가 없을 때도 더 친절하고 유용한 안내 제공!

🔥 프롬프트 최적화 후 배운 점 & 느낀 점

✅ AI에게 역할과 목표를 명확하게 정의해줘야 한다.
✅ "어떤 상황에서 어떤 방식으로 답해야 하는지" 구체적으로 명시하면 AI의 응답 품질이 좋아진다.
✅ LLM이 단순히 대화 맥락을 기억한다고 해서 좋은 답변을 생성하는 것은 아니다! → 프롬프트에서 맥락을 어떻게 활용할지 구체적으로 설명해야 한다.
✅ 이론적으로 괜찮아 보이는 프롬프트도 실전 테스트가 필수다!

📌 최종 정리 (TL;DR)

• 기존 프롬프트에서는 AI의 응답이 비일관적이고 맥락을 유지하지 못하는 문제가 있었음.
• 역할 정의 + 대화 가이드 + 문맥 활용 방식을 명확히 지시하여 프롬프트 개선.
• 테스트를 통해 응답 품질이 크게 향상됨 → 맥락 유지, 응답의 일관성, 친절한 피드백까지 모두 개선!
• 🚀 이제 프롬프트 엔지니어링이 얼마나 중요한지 직접 경험하게 됨.

🎯 4. 프롬프트 엔지니어링 최적화 - 문서 기반 응답 & 일상 대화 처리 개선

🛑 문제 상황

1️⃣ 기존 프롬프트에서는 회사 문서와 관련된 질문이 아니면 AI가 무조건 거절 응답을 함.

• "죄송합니다, 관련한 질문이 아닙니다." 같은 고정된 답변만 제공 → 대화의 유연성이 부족.
• 사용자가 일상적인 질문을 하면 AI가 너무 딱딱하게 반응함.

2️⃣ 정보 제공 시 출처(Reference)가 포함되지 않아 신뢰성 부족.

• AI가 회사 문서에서 정보를 기반으로 답변을 생성하지만, 어디서 가져온 정보인지 밝히지 않음.
• 사용자가 AI의 응답을 신뢰할 수 있도록 출처(참고 문헌)를 표시할 필요가 있음.

✅ 해결 방법 - 프롬프트 개선 및 실험 과정

1) 일상적인 대화도 가능하도록 프롬프트 개선

💡 기존:

• "You are a company service chatbot. If the user's question is not related to company documents, say you cannot answer."
• → 비관련 질문이면 무조건 거절.

💡 개선 후:

• "You are a friendly and knowledgeable company assistant chatbot. You can engage in casual conversations when the user's question is not related to company documents. If the question is related to official documents, provide an accurate response based on the given sources."
• → 이제 AI가 일상 대화도 자연스럽게 할 수 있도록 유연한 응답 생성 가능!

📌 추가된 프롬프트 규칙:
✅ 일상적인 질문 (Casual Conversation) → AI가 부드럽게 대화 가능.
✅ 문서 기반 정보 (Informational Response) → 공식 문서 참고하여 응답 생성.

2) AI가 응답 유형을 자동으로 판단하도록 엔지니어링

💡 새로운 프롬프트 규칙 추가:

• AI가 응답을 생성할 때, 스스로 답변이 casual인지 informational인지 분류하도록 설계.
• Informational 응답일 경우, 참고한 문헌(출처)을 응답에 포함.

📌 프롬프트 개선 내용:

You are a friendly and knowledgeable company service assistant chatbot designed to provide accurate information and support.

1. If the user asks about official company documents, provide a fact-based response and cite the reference documents used.
   - Example: "Based on [Document Name], here is the information: ..."
2. If the question is casual or unrelated to company documents, engage in a friendly and natural conversation.
3. You must classify your response as either "informational" or "casual":
   - If "informational", append the referenced documents at the end of your response.
   - If "casual", simply respond naturally without citing references.

📌 예제 응답 비교 (개선 전 vs 후)

📌 결과:
✅ AI가 문맥을 파악하여 유연하게 응답할 수 있게 됨!
✅ 회사 문서 기반 응답에서는 자동으로 참고 문헌을 추가하여 신뢰성 확보!

🛠️ 실험 과정 & 최적화 전략

📌 테스트 방법
1️⃣ 일상적인 질문을 입력하여 AI가 자연스럽게 응답하는지 확인.
2️⃣ 정보 기반 질문을 입력하고, 출처(Reference)가 포함되는지 테스트.
3️⃣ 잘못된 응답이 나오지 않도록 프롬프트를 조정하며 최적화.

📌 실제 실험 결과 분석 (로그 기반 테스트 진행)

📌 결과:

• ✅ AI의 응답이 더 자연스럽고 친절하게 개선됨.
• ✅ LLM이 응답 유형을 분류하여 문서 기반 정보에는 출처를 추가하도록 최적화됨.
• ✅ 사용자가 AI 응답을 더 신뢰할 수 있도록 설계.

🔥 프롬프트 최적화 후 배운 점 & 느낀 점

✅ 프롬프트에서 AI의 "역할"을 더 구체적으로 정의하면 응답 품질이 향상된다!
✅ 응답 유형(Classification)을 명확하게 지시하면 AI가 상황에 맞게 더 자연스럽게 동작한다.
✅ 출처를 포함하는 것만으로도 사용자가 AI의 응답을 더 신뢰할 수 있게 된다.
✅ AI가 너무 딱딱하면 사용자 경험이 떨어지므로, "Casual"한 대화 기능도 중요하다!
✅ 프롬프트는 한 번 만들고 끝나는 게 아니라, 지속적으로 실험하고 개선해야 한다.

📌 최종 정리 (TL;DR)

• 기존 챗봇은 일상 대화가 불가능하고, 문서 기반 응답에 출처가 포함되지 않는 문제가 있었음.
• ✅ 프롬프트 개선:
  • 🎯 Casual 대화 가능하도록 유연성 추가.
  • 📌 Informational 응답 시 출처(Reference) 포함하도록 설정.
  • 🛠️ AI가 응답 유형을 스스로 분류하여 자연스러운 대화 흐름 유지.
• 🚀 결과:
  • 사용자 경험 개선 (더 자연스러운 응답 가능!)
  • 정보의 신뢰성 향상 (출처 포함!)
  • AI의 일관된 응답 품질 확보!

🛠️ 5. 문서 크롤링 & 벡터 DB 저장 - 데이터 구조 최적화

🛑 문제 상황

1️⃣ 기존에는 단순히 텍스트만 벡터 DB에 저장하는 방식

• 문서를 크롤링한 후, text만 벡터화하여 FAISS에 저장.
• 출처(title) 정보가 없어서, 어떤 문서에서 가져온 데이터인지 구분할 수 없었음.

2️⃣ 삭제 및 관리 기능이 어려움

• 벡터 DB는 일반적인 관계형 DB와 달리 ID 기반 삭제 기능이 제한적.
• 기존 방식에서는 특정 문서를 벡터 DB에서 삭제하려면 텍스트 데이터를 다시 처리해야 하는 문제가 있었음.

3️⃣ AI 응답 생성 시 참고 문헌 정보 제공 필요

• AI가 검색된 문서에서 응답을 생성할 때, 어떤 문서를 참고했는지 출처(title)를 포함해야 했음.
• 하지만 기존 방식에서는 벡터 DB에서 검색된 텍스트만 반환 → 출처(title)를 활용할 방법이 없었음.

✅ 해결 방법 - Document 기반 데이터 저장 구조 도입

💡 1) 벡터 DB에 저장하는 데이터 구조 개선
📌 텍스트뿐만 아니라, 문서의 출처(title) 및 메타데이터를 함께 저장!

from langchain.schema import Document

# 기존 방식 (단순 텍스트 저장)
text = "This is a sample document about AI."
faiss.add_texts([text])

# 개선된 방식 (문서 정보 + 메타데이터 포함)
document = Document(
    page_content="This is a sample document about AI.",
    metadata={
        "title": "AI Research Paper 2023",
        "source": "https://example.com/ai-research",
    }
)
faiss.add_documents([document])

📌 결과:
✅ 벡터 DB에서 검색된 문서의 출처(title)까지 함께 반환 가능!
✅ 문서의 출처를 기준으로 데이터 관리(삭제, 업데이트)가 가능해짐.

💡 2) 문서 ID 기반 삭제 기능 추가
📌 벡터 DB에서 특정 문서를 삭제할 수 있도록 title을 ID처럼 활용

# 벡터 DB에서 특정 문서 삭제
def delete_document_by_title(faiss, title):
    docs = faiss.similarity_search_with_score(title, k=10)  
    for doc, score in docs:
        if doc.metadata.get("title") == title:
            faiss.delete(doc)  # 특정 문서만 삭제

📌 결과:
✅ 불필요한 문서를 손쉽게 삭제할 수 있는 기능 추가!
✅ 벡터 DB에서 데이터 관리를 효율적으로 할 수 있게 됨.

💡 3) AI가 참고 문헌을 자동으로 포함할 수 있도록 데이터 구조 정리

• AI가 응답을 생성할 때, 프롬프트 엔지니어링을 통해 informational 응답일 경우 출처(title)를 포함하도록 설정.
• 나는 벡터 DB에서 검색된 문서의 메타데이터(title, source)를 LLM에 넘겨주는 역할을 수행.
• AI가 이를 활용하여 응답을 생성할 수 있도록 데이터 구조를 개선함.

📌 결과:
✅ 내가 직접 응답에 출처를 추가하지 않아도, 프롬프트를 통해 AI가 자동으로 처리하도록 설계!
✅ 정보 제공이 필요한 경우 참고 문헌이 포함되면서 신뢰도 향상.

🛠️ 벡터 DB 데이터 구조 개선 후 얻은 이점

📌 데이터 관리가 쉬워짐!

• ✅ 문서 삭제 기능 추가 → 필요 없는 데이터를 손쉽게 제거 가능.
• ✅ 벡터 DB에서 특정 문서를 ID 기반으로 검색 가능.

📌 AI 응답의 신뢰성 향상!

• ✅ AI가 문서 기반 정보를 보다 신뢰성 있게 제공할 수 있도록 설계.
• ✅ 데이터 구조를 개선하면서 프롬프트 엔지니어링과의 연계를 고려할 수 있었음.

📌 데이터 구조를 개선하면서 시스템 설계에 대한 깊은 고민을 할 수 있었음!

🔥 데이터 구조 최적화 후 배운 점 & 느낀 점

✅ 텍스트만 저장하는 것이 아니라, 메타데이터까지 고려해야 데이터 관리가 쉬워진다.
✅ 벡터 DB는 관계형 DB와 다르게 ID 기반 삭제가 어렵기 때문에, ID처럼 사용할 필드를 포함하는 것이 중요하다.
✅ AI의 응답 신뢰성을 높이기 위해서는 참고 문헌(title)을 함께 제공할 수 있도록 데이터 구조를 정리해야 한다.
✅ 데이터 구조를 고민하는 과정이 결국 전체적인 검색 & 응답 품질 개선으로 이어진다!

📌 최종 정리 (TL;DR)

• 기존에는 텍스트만 벡터 DB에 저장했기 때문에 문서 관리 및 출처 제공이 어려움.
• ✅ 벡터 DB에 문서 title, 출처 정보를 함께 저장하여 데이터 구조 개선.
• ✅ title을 기준으로 문서를 삭제할 수 있도록 기능 추가.
• ✅ AI 응답 생성 시 참고 문헌을 포함할 수 있도록 메타데이터 정리.
• 🚀 결과적으로 문서 검색 시스템의 관리 & 응답 품질이 크게 향상됨!

해외 인턴십 1주차 회고

명확한 기획과 요구사항을 바탕으로 시스템을 설계한다.

명확한 기획과 요구사항의 중요성

기존에 했던 팀프로젝트는 기획부터 내가 참여를 했다. 문제 상황을 보고, 페인포인트를 포착하고, 그것을 분석해 솔루션을 구상하는 것까지. 그리고 그 기획에 맞추어 개발을 했다. 회사는 달랐다. 우선 원하는 기획과 요구사항이 명확하다.

1. System Requirements User Types, Authentication, Employee Interface, Admin Interface

2. Technical Requirements Architecture, Deployment, Code Management, Security, Performance, Streaming

이 요구사항과 기획 문서를 분석했다. 그리고 어떤 기능이 필요한지 뽑아내기 위해 Use Case를 고려하며 Use Diagram을 그렸다.

교과목 '소프트웨어 설계'

(잠깐 여담)

나는 인턴을 오기 직전학기에 '소프트웨어 설계' 과목을 수강했다. 앞으로 커리어를 이쪽으로 키워가고 싶다고 생각할 정도로 너무 재밌게 들었다. 프로젝트 짬빠 덕분에 이론은 정말 이해가 잘되고 조금은 쉽게 느껴졌지만, 실습 과제는 달랐다.

한가지의 소프트웨어를 선택해 이를 설계하는 것이 기말 대체 과제였는데, 정말 어려웠다. 하지만 나는 진짜 교수님을 5번 넘게 찾아가서 궁금한 점을 모조리 여쭤볼 만큼 정말 정말 미친듯이 열심히 공부했다. 그리고 발표도 실습도 1등! 당연히 A+을 받았다. 이 과제에서 Use Case를 작성하고 Use Diagram, Class Diagram, Sequence Diagram을 그렸다. 처음에는 이게 맞나 싶을 정도로 많이 어려웠는데, 교수님께서 '결국에 니가 해내는 구나'라는 말을 하셨을 정도로 나름 잘 했다.

과제를 하는데에서 가장 혼란스러웠던 것은 명확한 요구사항이 없다는 것이었다. 내가 기획한 소프트웨어 시스템에 맞추어 설계를 하는 거라, 그 기준이 오로지 나 자신에게 있었다. 그래서 처음에는 분명 '신체 리듬에 맞춘 게임'으로 시작을 했는데 끝에 가서는 '맥박과 혈압 기반 게임'이 되었다.

즉, 명확하지 않은 요구사항과 기획은 시스템을 설계하는데에 있어서 굉장히 혼동이 된다는 것을 깨달았다.

User Validation

회사에서 준 아주 명확한 요구사항과 기획을 보고 Use Case를 뽑아내고, Use Diagram을 작성하면서 어떤 기능이 필요할지 리스트업을 하였다. 개인적으로 프로젝트를 할 때에 비하면 너무나도 좋았다.

그리고 회사의 멘토 분들과 회의를 통해 우리가 만들 기능에 대해 한번 더 확인을 받았다. 이게 소프트웨어 설계에서 배운 User Validation 과정인가! 상당히 두근거렸던 순간이다. 배운걸 내가 써먹는다니 무려 현업에서 흐흐.

내가 만든 Use Diagram 이 잘 작성되었다고 평가 받아서 기분이 좋았다. 그리고 기능을 설계할 때도 계속해서 요구사항을 확인하면서 조금이라도 기획의도와 요구사항에 맞지 않는다면 방향성을 제고하였다.

팀 회의에서 회의 목적을 상기하다.

이 미팅이 끝나고 우리팀을 팀 미팅을 바로 또 진행했다. 생성한 Wire Frame을 함께 확인하기 위함이었다.

여기서 의견 차이가 발생하였다.

나는 Wire Frame과 User Flow를 보면서 우리의 시스템 동작이 어떻게 흘러가고, 이 기능이 여기서 쓰이고 어떠한 데이터가 언제 필요한지 그러한 것을 확인하고 싶었다.

그런데 갑자기 한 팀원이 UI를 설계하고 싶다고, 갑 화이트보드에 UI를 그리더니 버튼의 모양은 Square이 좋을지 Round가 좋을지, 색상은 Red가 좋을지 White가 좋을지, 너무나도 세부적인 것까지 의논을 시작하는 것이다.

많이 당황스러웠다. 나는 개발팀 소속이라서 이런 의논에 내가 참여하는 것이 좀 아니다라고 생각 되었다. 그래서 우선 PO에게 이런 내 입장을 간략히 말을 하였다. 그리고 UI를 그리고 있는 팀원에게 조심스럽게 우리 지금 회의의 목적에 대해서 이야기 해보고 싶다고 말했다.

• 나는 개발팀
• 팀원의 마음을 알고 있다.
• 하지만 지금 진행하는 회의는 이전에 진행한 User Validation에 맞추어 확정된 기능과 와이어 프레임을 확인하는 회의라고 생각
• 세부적인 디자인은 추후에 함께 의논하는 것이 필요하다면 너무 좋지만, 지금은 우리가 기존에 모인 목적에 대해 한번 더 생각해줬으면 좋겠다.

이런 식으로 말을 했더니, 그 팀원도 그게 맞는거 같다고 생각한다고 했다.

자칫하면 분위기가 어두워질 수도 있는 순간이었다. 하지만 우선 상대방의 입장을 충분히 알고, 공감한다고 이야기를 꺼냈다. 그리고 나의 입장과 내 생각을 전달하였다. 말투는 기분 나쁘지 않게 신경써서.

상대방이 기분 나쁘지 않게 내 의견을 잘 전달하기 위해서는 상대방의 상황을 충분히 생각하고, 고려했음을 상대방이 알게 해야 한다. 그리고 내 의견을 말하면 된다.

스크럼 단위의 프로젝트 진행

스크럼: 팀 단위로 개발의 효율성을 높이는 애자일 개발 방법

• Product Owner
• Scrum Master
• Development Team: 내가 속함

프로젝트 관리의 중요성

WBS, Gantt Chart

인턴을 하면서 가장 좋았던 것을 뽑으라고 하면 바로 전문적인 '프로젝트 관리'이다. PO는 우리가 뽑아낸 기능과 요구사항 명세서, 기획서를 참고해여 WBS와 Gantt Chart를 만들었다.

WBS는 모듈별로 Use Case가 명세화 되어 있어서 한 눈에 보기 너무 편했다. Gantt Chart는 모듈에 어떤 것을 해야 하는지 Task가 정리되어 있고, 누가 pic을 했고 얼마나 걸릴 것이고 실제로는 얼마나 걸렸고, 언제 진행했는지 등 진행 상태를 한 눈에 볼 수 있어서 좋았다.

Teams, Trello

그리고 우리는 소통을 위해 Teams, Trello를 썼다. 내가 무엇을 Done 했고, 지금은 무엇을 Doing 하고 있고, 앞으로 ToDo 해야 할 것들이 Trello에 보드 형식으로 되어 있어서 좋았다. 가끔 내가 뭘 했는지 그리고 앞으로 뭘 해야 하는지 그런것들이 정리가 안될 때가 있다. 머리속으로는 개발 이것도 해야 하고 저것도 해야 하고 이거 하다가 저거 하고 그럴 때도 있는데, 혼동이 올 때마다 간트 차트와 Trello를 보면서 개발을 진행했다.

전 직장에서 Jira를 써본 적이 있는데, 솔직히 많이 어려웠다. 백로그, 칸반 보드, 스크럼, 이슈 등등 낯선 용어도 많았다. 하지만 이렇게 Jira나 Trello 같은 협업 툴을 쓰면 내가 지금 무엇을 했고 하고 할 것인지 한눈에 볼 수 있어서 헷갈릴 일이 없다. 그리고 다른 팀원들의 진행상황도 볼 수 있으니 만약에 내가 이슈가 생기면 조금 여유가 있는 팀원에게 도움을 요청하기 편했다.

나는 개발팀에 속해서 Trello를 직접적으로 관리하지는 않았다. PO가 세팅을 하고 전체적인 업무 진행상황을 관리했는데, 정말 힘들어보였다. 그리고 업무 진행상황을 파악하기 위해 정말 적극적으로 소통을 해야 했다.

PO도 같이 온 인턴 중 한명이 담당해서 했는데, 매번 진행상황을 파악하기 위해 팀원들 자리로 와서 묻곤했다. 그리고 우리 팀 중에 다른 팀원은 본인이 무엇을 했고 하고 할 것인지 명확하게 말을 하지 않는 팀원이 있었다. 나는 프로젝트를 할 때 커뮤니케이션을 정말 중요하게 생각한다. 그래서 내가 어떤 Task를 수행할 때마다 Teams에 지속적으로 업데이트를 하면서 PO가 굳이 내 자리까지 오지 않더라도 진행상황을 빠르고 명확하게 파악하도록 노력했다.

Daily meeting

우리는 매일 11시 데일리 미팅을 했다. 자신이 무엇을 했고, 지금은 무엇을 하고, 오늘은 무엇을 할 것인지 등을 이야기하는 자리이다. 멘토님들도 참여하셔서 우리의 진행상황을 지속적으로 확인하고, 피드백을 주셨다. 생각보다 구체적이고 날카로운 질의응답을 하면서 스스로도 많이 성장하게 되었다. '왜?'라는 질문은 정말 중요한거 같다.

Architecture

우리가 만들고자 하는 시스템과 우리의 리소스를 파악해서 최고의 아키텍쳐를 짜는 것이 개발 팀의 이번주 업무 중 하나였다. '회사의 챗봇'을 만드는게 우리 인턴 팀의 업무였는데, 우선 ver 1로 local로 개발을 하라고 하였다. 나는 자동화 배포나 클라우드에 관심이 많아서 이쪽을 해보고 싶었는데 아쉬웠다. 멘토님께도 혹시라도 배포나 클라우드를 사용하게 된다면 내가 꼭 해보고 싶다고 말씀드렸는데, 아직은 그럴 가능성이 없다고 하였다. 기술적으로 보완이 되고 완성적으로 프로젝트가 된다면 나중에 배포를 하면 좋겠다고 하셨다.

AI를 사용해야 했다. 처음에는 경량화 된 모델을 가져와 RAG를 활용해 리트리벌을 하고 응답을 생성하려 했다. 그런데 우리에게 주어진 리소스가 없다고 했다. 그래서 어쩔 수 없이 외부 API인 Gemini를 활용하기로 했다.

나는 Java Spring Boot 개발자이기 때문에 내가 평소에 쓰던 스택으로 개발을 하고 싶었지만, 주어진 4주 (거의 3주)에 빠르게 개발을 하기에는 부적합하다는 피드백을 받았다. 나를 제외한 나머지 팀원들은 개발 경험이 많지 않았고, 그나마 개발 경험이 있는 팀원들은 이전에 Flask를 사용했다고 했다. 그래서 Flask를 활용해 서버를 구축하기로 했다.

DB는 2개를 쓰기로 하였다.

• Meta Data
• Vector Data

나는 Vector DB에 대한 개념을 이번 프로젝트의 아키텍처를 설계하면서 처음 알게 되었다. Vector DB는 문서, 이미지, 텍스트와 같은 비정형 데이터를 고차원 벡터 형태로 저장하고, 이를 효율적으로 검색하기 위해 사용되는 데이터베이스이다. 특히 AI와의 연계가 중요한 프로젝트에서, 대규모의 데이터에서 빠르게 유사성을 기반으로 검색하는 데 강력한 성능을 제공한다.

최적화된 아키텍쳐를 설계하기 위해 많이 고민을 했다. 제공해야 하는 정보와 그에 맞는 구조도 많이 생각을 했다.

우리에게 할당된 자원이 없기 때문에 모든 것을 free local로 개발하라는 요구사항을 맞추느라 상당히 속상했다. 그래도 이런 재정적인 요소를 고려해서 가장 최적화된 설계를 했다.

문제 상황

벡터스토어 기반 검색 시스템에서 문서 임베딩 후, 사용자가 원하는 정보를 정확히 찾지 못하는 문제가 발생했다. 이는 검색 시스템에서 문서를 분할(청크)하는 방식이 최적화되지 않았기 때문일 가능성이 크다. 문서를 청크로 나누는 과정에서 크기와 중첩(오버랩) 설정이 검색 정확도와 문맥 유지에 큰 영향을 미치기 때문이다.

목표

청크 크기와 오버랩 설정을 다양하게 조정하여 최적의 설정을 찾고, 검색 결과의 정확도와 문맥 유지 정도를 평가.

문제 분석

• 청크가 너무 작다면?

  • 문맥이 손실된다.
  • 단편적인 의미만 저장된다. (문맥X) 즉, 결과적으로 검색 쿼리가 문맥적으로 관련된 결과를 찾지 못할 수 있다.

• 청크가 너무 크다면?

  • 넓은 문맥을 포착하려고 하니, 세부 정보를 무시하고 일반적인 정보를 담는다.
  • 유사도 계산 시 관련도가 낮아질 수 있다.

최적화된 청크 크기를 어떻게 결정하는가?

나는 웹링크를 제공하면, 여기 웹링크에 들어가서 내용을 스크랩핑을 한 후, 임베딩 처리를 해 DB에 반영하는 흐름으로 로직을 짰다. 내가 주로 사용하는 웹링크는 회사의 뉴스룸이다.

• 문서의 성격: 회사 뉴스룸에 올라오는 뉴스
• 임베딩 모델: GoogleGenerativeAIEmbeddings(model="models/text-embedding-004")

뉴스 문서의 특성과 청크 크기의 관계

우선 뉴스 문서의 특성을 생각해보자면,

1) 짧은 단락으로 구성되어 문맥 단위가 비교적 명확하다. 2) 초반에는 중요한 정보를 요약하며, 이후에 세부 내용을 다룬다. 3) 키워드 중심으로 정보를 전달해, 검색 쿼리에 키워드가 중요한 역할을 한다.

그럼 이제 어떤 청크 크기를 설계해야 적합할까?

1) 문맥이 비교적 독립적인 뉴스 문서이기에, 청크 크기를 작게 설정을 해야 한다. 2) 문맥 연결을 위해 청크 간 중첩을 추가해야 한다. 각 청크의 끝에서 50~100 토큰 정도를 다음 청크에 포함시켜야 한다. 이 설정을 하면 계산 정확도가 향상된다.

임베딩 모델의 특성: GoogleGenerativeAIEmbeddings(model="models/text-embedding-004")

나는 무료로 쓸 수 있는 임베딩 모델을 사용하기 위해 이 모델을 선정하였다. 이 모델은 일반적으로 200~400 토큰 사이에서 가장 높은 성능을 발휘한다.

문제 해결

청크 크기를 여러개로 정하여 최적화 실험을 해보겠다.

우선 내가 사용하는 예시 웹링크를 기반으로 한 문장과 한 단락당 몇개의 토큰이 있는지 계산해보겠다.

import tiktoken

def calculate_tokens(text: str, model: str = "gpt-3.5-turbo") -> int:
    # 모델에 맞는 토크나이저 로드
    tokenizer = tiktoken.encoding_for_model(model)
    # 텍스트를 토큰으로 변환하고 토큰의 개수를 반환
    tokens = tokenizer.encode(text)
    return len(tokens)

# 사용 예제
text = "문장"
token_count = calculate_tokens(text)
print(f"Number of tokens: {token_count}")

이 코드를 실행시켜 내가 사용하는 문서의 전반적인 문장의 토큰 수를 계산해보았다.

• 평균 문장 토큰 수: 약 40개
• 단락당 토큰 수: 약 110개

청크 크기 최적화 전략

1. 기본 청크 크기 설정: 200~300 토큰

• GoogleGenerativeAIEmbeddings 모델의 최적 범위에 부합하는 크기.
• 단락과 문장 구조를 고려했을 때, 단일 청크로 중요한 문맥을 포함하기 적합.

2. 오버랩 설정: 50~75 토큰

• 청크 간 문맥을 연결하여 정보 손실을 최소화.
• 연속된 청크에서 문맥적인 흐름을 유지해 검색 정확도를 높임.

3. 테스트 설계:

• 다양한 청크 크기와 오버랩 조합을 설정하여 실험.
• 결과로 반환된 문서에서 세부 정보와 문맥 유지 여부를 평가.

테스트

텍스트 데이터를 벡터화하고 검색 결과의 정확성을 높이기 위해 토큰(청크) 사이즈와 오버랩 크기를 최적화하는 것은 매우 중요하다. 따라서 동일한 문서를 임베딩하되, 토큰 사이즈와 오버랩 크기를 다르게 해 저장을 하고 동일한 질문을 주었다.

테스트 환경

• 데이터베이스: FAISS 기반 벡터 스토어.
• 임베딩 모델: Google Generative AI Embeddings (text-embedding-004).
• 테스트 변수:
  • 토큰(청크) 크기: 200, 300, 400, 500.
  • 오버랩 크기: 50, 100, 150, 200.

테스트는 동일한 질문과 데이터를 기반으로 수행되었으며, 각 설정에서 반환된 검색 결과를 분석했다.

테스트 과정 (코드)

테스트 결과 분석

1. Chunk Size 200, Overlap 50

• 장점:
  • 짧은 청크로 인해 세부 정보가 명확히 드러남.
• 단점:
  • 문맥이 끊겨 정보 연결성이 부족.
• 결과:
  • "With over 2,200 engineers..."와 같은 핵심 정보는 포함되지만, 배경 정보나 문맥은 부족.

2. Chunk Size 300, Overlap 100

• 장점:
  • 세부 정보와 문맥 연결성이 균형을 이룸.
  • 중복된 정보가 최소화됨.
• 단점:
  • 일부 긴 문맥이 잘릴 가능성.
• 결과:
  • "With over 2,200 engineers..."와 "Founded in 2012..." 등 적합한 정보를 포함하며, 배경 설명도 유지.

3. Chunk Size 400, Overlap 150

• 장점:
  • 긴 문맥을 포함하여 배경 정보를 잘 제공.
  • 중복된 정보가 최소화됨.
• 단점:
  • 특정 키워드가 문맥 안에 묻힐 가능성.
• 결과:
  • 배경 설명과 함께 주요 정보를 충실히 제공.

4. Chunk Size 500, Overlap 200

• 장점:
  • 가장 긴 문맥을 유지하여 풍부한 배경 정보를 제공.
• 단점:
  • 특정 세부 정보가 뭉개질 가능성.
  • 검색 결과에서 중요한 문장이 누락될 위험.
• 결과:
  • "With over 2,200 engineers..."와 같은 주요 정보는 포함되지만, 불필요한 배경 정보가 포함될 가능성이 높음.

최적의 설정

설정: Chunk Size 300, Overlap 100

• 이유:
  1. 세부 정보와 문맥 연결성의 균형이 뛰어남.
  2. 중복된 정보가 적으며, 검색 결과가 명확함.
  3. 질문에 적합한 정보를 빠르게 반환 가능.

결론

토큰 사이즈와 오버랩 크기의 최적화는 검색 결과의 품질을 좌우하는 핵심 요소다. 이번 테스트에서는 질문 중심의 검색에 Chunk Size 300, Overlap 100이 가장 적합한 설정으로 나타났다. 이 설정은 세부 정보와 문맥의 균형을 효과적으로 유지하며, 검색 효율성을 극대화한다.

앞으로 벡터 스토어를 활용한 검색 엔진 개발 시, 데이터 특성과 질문 유형에 따라 이러한 설정을 조정해야 한다. 무지성으로 남들이 좋다는 값으로 설정하는 것이 아닌, 데이터와 질문의 성격에 맞는 최적의 설정을 찾는 것이 성공적인 검색 시스템의 핵심임을 깨닫게 되었다.

도커란?

어떤 서비스를 운영하기 위해서는 프로그램을 돌려야 한다. 나는 파이썬을 사용하고, 필요한 라이브러리를 모두 설치한 환경에서 이 프로그램을 실행하면 잘 돌아간다.
하지만, 다른 사용자가 내 코드를 클론 받아서 단순히 run 명령을 실행해도 프로그램이 돌아가지 않는 경우가 생긴다.

이것은 환경이 다르기 때문이다.

다른 사용자가 사용하는 운영체제, 파이썬 버전, 라이브러리 버전, 환경 변수 설정 등이 나와 다를 수 있기 때문에 동일한 프로그램이라도 실행되지 않는 경우가 생긴다. 이를 해결하기 위해 모든 환경을 통일할 필요가 있다.

도커의 역할

도커(Docker)는 이러한 문제를 해결하기 위한 컨테이너 기반 가상화 기술이다. 도커는 애플리케이션과 그 애플리케이션이 실행되기 위해 필요한 모든 것을 하나로 묶어 "컨테이너"라는 형태로 패키징한다.

이 컨테이너에는 프로그램, 라이브러리, 환경 설정 등이 모두 포함되어 있어, 어떤 환경에서든 동일하게 실행할 수 있다. 이를 통해 "내 로컬에서는 잘 되는데..."와 같은 문제가 사라지게 된다.

도커의 주요 개념

• 도커파일(Dockerfile): 레시피와 같은 것. 우리 어플리케이션을 구동하기 위해서 꼭 필요한 파일은 무엇이 있는지, 어떤 프레임워크나 라이브러리를 설치해야 하는지, 외부 디펜던시에 대해서도 명시할 수 있다. 그리고 필요한 환경변수 설정이나 구동 스크립트를 포함할 수 있다.
• 이미지(Image): 프로그램과 해당 프로그램이 실행되기 위해 필요한 설정 및 라이브러리를 담은 정적인 템플릿이다. 즉, 프로그램과 환경을 패키징한 형태라고 할 수 있다. 작성한 도커 파일을 이용해 이미지를 만든다. 어픞ㄹ리케이션을 실행하는데 필요한 코드, 런타임 환경 시스템, 툴 시스템 라이브러리 등 모든 세팅들이 포함되어 있다.
• 컨테이너(Container): 이미지를 실행한 실행 가능한 인스턴스이다. 컨테이너는 실제 프로그램이 돌아가는 공간이며, 서로 독립적으로 실행되므로 다른 프로그램이나 시스템 환경에 영향을 받지 않는다.

도커로 배포하는 방법

1. 로컬머신에서 이미지 만들기
2. Container Registry에 내가 만든 이미지 push
3. 필요한 서버에서 pull 하고 실행하기 -> 서버에도 도커를 설치해야 한다.

Apple Mac M3 나는 애플 유저여서 5000포트가 Airplay가 이미 사용하고 있어서 기존 돌리려고 했던 포트인 5000을 사용하지 못했다.

docker run -p 5000:5000 --env-file .env backend-chat-service

이 명령어를 실행하면

docker: Error response from daemon: Ports are not available: exposing port TCP 0.0.0.0:5000 -> 0.0.0.0:0: listen tcp 0.0.0.0:5000: bind: address already in use.

이런 오류 메시지가 출력된다. 다른 프로세스가 이미 포트 5000을 사용 중이기 때문에 Docker 컨테이너가 해당 포트에 바인딩할 수 없다.

다른 필요 없는 프로세스면 종료를 시키고 진행했겠지만, ControlCe 프로세스가 포트 5000을 점유하고 있다. ControlCe는 일반적으로 macOS의 Control Center (제어 센터) 관련 프로세스다.

그래서 기존의 이 명령어 대신에

docker run -p 5500:5000 --env-file .env backend-chat-service

이렇게 로컬 환경에서의 포트는 5500을 사용하도록 설정해주었다.

• 5500 → 호스트 머신의 포트.
• 5000 → 컨테이너 내부 Flask 앱의 포트.

그런데 이렇게 하고 나서 잘 빌드가 되고 구동까지 잘 되는걸 확인했는데,

사이트에 연결할 수 없음, 페이지가 작동하지 않습니다. 에러 해결

사이트에 연결할 수 없음
http://localhost:6000/의 웹페이지가 일시적으로 다운되었거나 새 웹 주소로 완전히 이동했을 수 있습니다.
ERR_UNSAFE_PORT
페이지가 작동하지 않습니다.
localhost에서 전송한 데이터가 없습니다.
ERR_EMPTY_RESPONSE

이러한 오류를 마주했다.

Flask 앱의 호스트 및 포트 확인

main.py에 app을 시작하는 부분에 다음 코드를 입력하면 된다.

if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=5000)

나는 5500을 쓰니까 저거를 5500으로 해야 되는 걸로 생각했는데 아니더라. 저게 맞음.

docker log 확인

1. 나는 import를 알고보니까 잘못하던게 있어서 그거를 수정했다.

   from langchain_community.vectorstores import FAISS
   

원래 langchain.vectorstores에서 저렇게 수정했다.

2. 특정 라이브러리(API 요청 시)에서 사용자 에이전트(USER_AGENT)를 설정하지 않았다는 경고가 있었다.

USER_AGENT environment variable not set, consider setting it to identify your requests.

그래서 환경변수 파일에 이걸 추가했다.

USER_AGENT=backend-chat-service

# 에러 해결 후, 접속 확인

http://localhost:5500/

여기에 접속해서 확인하면 된다.


-----

0. 모든 컨테이너 중지

docker stop $(docker ps -q)

1. 이미지 빌드하기: 코드가 바뀐다면 매번 해주기

docker build -t backend-chat-service .

2. 컨테이너 실행

docker run -p 5000:5000 --env-file .env backend-chat-service docker run -d -p 8080:5000 --env-file .env backend-chat-service

### 옵션별 설명

-d     컨테이너를 백그라운드 모드로 실행    docker run -d -p 8080:5000 backend-chat-service
-p    호스트와 컨테이너 포트를 매핑    -p 8080:5000 (호스트의 8080 → 컨테이너의 5000)
--env-file .env    환경 변수 파일을 로드하여 실행    .env 파일에 설정된 API 키, 환경 변수 등을 컨테이너에 적용

FastAPI 애플리케이션이 클라이언트 요청을 처리하는 단계를 우선 설명해주셨다. 클라이언트의 요청이 들어오면 여러 단계를 거쳐 최종적으로 엔드포인트 함수에 도달하며, 이를 "요청 처리 파이프라인"이라고 한다.

FastAPI 요청 처리 흐름

1. 클라이언트 요청 (브라우저, Postman, 프론트엔드 등)
2. 미들웨어: 요청/응답 전처리 및 후처리
3. 라우팅 (Routing): 해당 API 경로와 메서드에 해당하는 함수로 매핑
4. 데코레이터 및 종속성 주입 (Dependency Injection): 의존성 주입을 통해 밸리데이션과 추가 작업 수행
5. 요청 본문 검증 (Validation): 요청 데이터가 요청 모델과 일치하는지 검증
6. 엔드포인트 함수 실행 (Controller Function): 실제 비즈니스 로직을 처리
7. 응답 처리 (Response Handling): 클라이언트에 응답 반환

단계별 요청 처리 흐름

1. 미들웨어 (Middleware)

미들웨어는 요청이 들어오거나 응답이 반환될 때 가장 먼저 또는 가장 마지막에 실행된다.

역할:

• 요청 전후에 공통 작업 수행 (로그 작성, 인증, 요청 시간 측정 등).
• 미들웨어는 다음 단계로 요청을 넘기거나 중단할 수 있다.

예제 코드:

@app.middleware("http")
async def log_request_time(request: Request, call_next):
    print(f"Incoming request: {request.url}")
    response = await call_next(request)  # 다음 단계로 넘김
    print(f"Completed request: {request.url}")
    return response

나는 OS를 배울 때 이 미들웨어를 들어봐서 이게 어플리케이션을 만들 때에도 코드 상으로 구현을 하는 것이 처음이었다.

fastAPI middleware

이 docs에 의하면, FastAPI 앱에도 미들웨어를 직접 추가할 수 있다고 한다. 특정 업무를 수행하기 전 모든 request, 그리고 response를 주기 전에 수행되는 function이라고 한다.

왜 미들웨어에서 Request를 검증하는가?

1. 일관된 검증 및 보안 강화
   • 사용자 인증, IP 검증, 토큰 검증 등을 미들웨어에서 수행함으로써 모든 엔드포인트에 보안 검증 로직을 반복하지 않고 한 번에 처리할 수 있다.
2. 리소스 낭비 방지
3. 코드 중복 최소화
4. 로깅 및 모니터링 용이성

그런데 내가 기존에 개발한 파일 업로드 기능에 관해서는 일단 그대로 하고, 나중에 도입을 하는 것을 추천하셨다. 아마 유저 관리 관련해서는 해봐야겠다.

2. 라우터(Router)

• FastAPI는 요청 경로와 HTTP 메서드 (GET, POST 등)를 기반으로 적절한 함수로 라우팅한다.
• 예를 들어 /api/upload-docs/에 대한 POST 요청은 upload_docs 함수로 전달된다.

@app.post("/api/upload-docs/")
async def upload_docs(file: UploadFile):
    ...

3. 의존성 주입 (Dependency Injection)

• FastAPI는 함수 호출 시 필요한 의존성을 자동으로 주입한다.
• 예를 들어, Request, Depends, File 등은 FastAPI가 필요한 객체를 주입한다.

from fastapi import Depends, Request

async def validate_user(request: Request):
    # 요청 헤더에 토큰이 있는지 검증
    token = request.headers.get("Authorization")
    if not token:
        raise HTTPException(status_code=401, detail="Unauthorized")
    return token

@app.post("/api/upload-docs/")
async def upload_docs(file: UploadFile, token=Depends(validate_user)):
    ...

위 코드에서 Depends(validate_user)는 upload_docs 함수가 호출될 때 사용자 검증 함수를 먼저 실행한다.

4. 요청 본문 검증 (Validation)

FastAPI는 pydantic을 사용해 요청 본문을 자동으로 밸리데이션한다.

• 요청 데이터가 잘못되었을 경우, 자동으로 400 Bad Request 응답을 반환한다.

예제 (Pydantic 모델 사용):

from pydantic import BaseModel

class FileUploadRequest(BaseModel):
    filename: str

@app.post("/api/validate-upload/")
async def validate_upload(file_data: FileUploadRequest):
    return {"message": f"Received file: {file_data.filename}"}

• 요청 데이터가 {"filename": "sample.docx"} 형태여야 한다.
• 만약 filename 필드가 없으면 400 응답이 반환된다.

5. 컨트롤러 (엔드포인트 함수)

• 컨트롤러 함수는 비즈니스 로직을 수행한다.
• 컨트롤러 함수 내부에서는 서비스 레이어를 호출해 파일을 저장하거나 데이터를 반환한다.

@app.post("/api/upload-docs/")
async def upload_docs(file: UploadFile = File(...)):
    file_path = save_file(file.filename, file.file)  # 서비스 레이어 호출
    return {"message": "File uploaded", "file_path": file_path}

6. 응답 처리 (Response Handling)

• 정상 응답: 컨트롤러 함수가 반환한 데이터를 클라이언트에 응답한다.
• 에러 응답: 밸리데이션 오류, 인증 실패, 서버 오류 등은 해당 HTTP 상태 코드와 에러 메시지를 반환한다.

예를 들어:

{
  "detail": "File not found"
}

요약된 요청 처리 흐름

1. 미들웨어: 요청을 전처리(로깅, 인증 등)하거나 응답을 후처리.
2. 라우팅: 요청을 해당 엔드포인트로 매핑.
3. 의존성 주입: 필요하면 Depends()로 필요한 검증 또는 공통 작업 수행.
4. 밸리데이션: 요청 데이터가 올바른지 확인 (pydantic 모델).
5. 컨트롤러 함수: 비즈니스 로직 수행 및 응답 반환.
6. 응답 처리: 클라이언트에 응답 반환.

결론

사수님께서 강조하신 내용은 미들웨어 → 서비스 레이어 → 컨트롤러 함수 흐름으로 코드의 유지보수성과 확장성을 높이는 구조를 고려하라는 의미다. 파일 업로드 API처럼 간단한 경우에는 이런 단계를 모두 적용하지 않아도 괜찮지만, 복잡한 기능을 추가할 때는 이러한 구조를 통해 코드 가독성과 재사용성을 높일 수 있다.

기존 코드 트리

입점 기업 Entity

모호한 이름 수정

우선 이름 부터가 잘못 되었다. IR 장표에서 강조하는 '가치소비'라는 단어를 쓰고 싶었고, 팀 대표가 '가치소비'라고 하라고 해서 Worthy Consumption 이라고 했다. 이게 맞다고 옆에서 하도 그러니까 그러려니 했는데 데이터 관리하려면 데이터의 이름을 잘 지어야 한다는 걸 최근에서야 뼈저리게 깨달았다. 진심 코드랑 테이블 보고 가치소비가 도대체 뭐야... 이러면서 기획 문서를 한참을 들여다 봤다. 결론: 입점기업이라는 이름이 적절하다. worthy_consumption -> value_company

과도한 결합 수정, 단순한 설계

입점 기업은 다음과 같은 요소가 필요하다.

• 해시태그(hashtags): 입점 기업의 특징을 간단히 표현하는 키워드로, 유저가 기업의 성격을 빠르게 이해할 수 있도록 제공.
• 추천 이유(recommendation reasons): 해당 입점 기업이 특별한 이유를 간단히 설명하는 정보.

  기존 문제점

  근데 나는 기존에 이거를 따로 엔티티로 빼서 연관을 시켰다. 이러면 다음과 같은 문제가 발생한다.

1. 과도한 테이블 분리 해시태그와 추천 이유를 각각 별도의 테이블로 분리하여 저장.
   • 문제: 데이터가 단순한데도 불구하고, 불필요한 테이블과 관계 설정으로 인해 설계 복잡성이 증가.
   • 결과: 조회 시 조인이 필요해 성능 저하 발생.
   2. 비효율적인 데이터 구조
   • 해시태그와 추천 이유는 대부분 조회만 사용되며, 검색이나 필터링이 필요하지 않음.
   • 문제: 검색 기능이 없는데도 테이블 분리로 인해 비효율적인 데이터 모델이 생성됨.
2. 관리 및 유지보수 문제
   • 별도의 테이블로 인해 데이터 변경 시 추가적인 관리 작업 발생.

새로운 설계

1. 단일 필드(JSON 형태)로 통합 해시태그와 추천 이유를 각각 단일 필드에 JSON 문자열로 저장.

   hashtags: ["친환경", "지속 가능", "로컬 기업"]
   recommendation_reasons: [{"title": "최고의 품질", "description": "친환경 제품을 최고의 품질로 제공합니다."}]

2. 데이터 처리 방식

• 데이터 저장: 애플리케이션에서 리스트나 객체를 JSON으로 직렬화하여 저장.
• 데이터 조회: JSON 데이터를 디코딩하여 유저에게 제공.

왜 이렇게 설계했는가?

1. 단순성과 효율성

• 단일 필드 통합으로 데이터베이스 구조를 간단하게 유지:
  • 테이블과 관계 설정 불필요.
  • 데이터 조회 시 조인이 필요 없어 성능 최적화.

2. 유저 요구사항에 적합

• 해시태그와 추천 이유는 검색이나 필터링 기능이 없으며, 단순히 조회 목적:
  • 유저가 입점 기업을 둘러볼 때 필요한 정보를 빠르게 제공.
  • 조회 API에서 기업의 주요 정보와 함께 해시태그와 추천 이유를 한번에 반환.

3. 확장성과 유지보수성

• JSON 필드의 구조를 변경하거나 확장하기 쉬움:
  • 새로운 필드 추가 시, 데이터베이스 스키마를 변경할 필요 없음.
  • 추천 이유에 이미지나 링크를 추가하고 싶다면 JSON 구조를 업데이트하면 충분. 즉, 단일 필드(JSON)방식으로 설계를 하면, 요구사항을 만족하며 빠르게 데이터를 제공할 수 있다.

기획과 맞지 않는 구조 이동

기존에는 쿠폰 발급 기준인 Condition 엔티티와 가격 관련 정보(original Price, sale Price)를 Worthy Consumption에다가 두었다. What~~

기존 문제점

1. Condition의 비효율성:

• Condition 엔티티는 발급 조건을 관리했지만, 이것이 입점 기업의 속성이라기보다는 쿠폰 발급의 로직과 연관됨.
• 입점 기업(WorthyConsumption)이 조건 데이터를 직접 보유할 필요가 없음.

2. 가격 정보의 잘못된 위치:

• originalPrice와 salePrice는 입점 기업 자체의 속성이 아니며, 특정 쿠폰이나 상품 할인과 관련된 정보.
• 입점 기업은 할인 정보를 직접 보유하지 않고, 쿠폰이나 챌린지 등과 연관 지어야 더 명확함.

Coupon Entity

위에 문제를 해결하기 위해 쿠폰 엔티티에다가 통합을 했다.

Condition → Coupon Condition 데이터(발급 조건)는 쿠폰 엔티티로 통합되었으며, 다음과 같은 방식으로 관리된다:

• 쿠폰 발급 조건(max_issue_count, valid_from, valid_to)과 같은 정보는 Coupon 엔티티에서 관리.
• 기존의 Condition 엔티티에서 maxIssuance, startDate, endDate 같은 필드는 Coupon 엔티티로 이동.

Price → Coupon 가격 정보는 특정 쿠폰의 할인 정책과 관련되므로 Coupon으로 이동:

• originalPrice: 원래 가격.
• discount 또는 salePrice: 할인 금액이나 할인율.

@ElementCollection으로 인한 복잡성

투머치였다.

기존 문제점

• summary와 caution 필드가 @ElementCollection으로 설정되어, 각각 별도의 테이블로 관리됨.
• 조회 시 조인이 필요해 성능 저하를 유발하고, 데이터 관리가 복잡해짐.

새로운 설계

• summary와 caution을 JSON 문자열로 저장.
• 단일 TEXT 컬럼에 JSON 데이터를 직렬화하여 저장.

왜 이렇게 설계했는가?:

• 단순한 리스트 데이터를 위해 별도 테이블을 생성하지 않음으로써 테이블 복잡성을 줄임.
• 조인 없이도 데이터를 조회할 수 있어 성능이 향상됨.
• JSON 형태로 저장하면 동적 데이터를 유연하게 관리 가능.

날짜 필드 관리의 중복과 복잡성

기존 문제점

• 발급 가능 기간(issuableStartDate, issuableEndDate)과 사용 가능 기간(limitStartDate, limitEndDate)이 각각 별도 필드로 관리.

• 날짜 간의 논리적 관계를 파악하기 어렵고, 관리가 복잡함.

  새로운 설계

• 날짜 필드를 @Embeddable 클래스로 재구성하여 Period 클래스로 관리.

• issuablePeriod와 usablePeriod로 구분.

  왜 이렇게 설계했는가?

• 발급 기간과 사용 가능 기간의 논리적 관계를 명확히 표현.

• 코드와 데이터 모델의 가독성이 향상되고, 날짜 관련 관리 로직의 중복을 줄임.

앗!! 뭔가!! 알겠다.

유저 입장에서 사용하는 필터링이라던가 그런 기능상으로 검색이 되어야 하는 기준이 명확한게 있으면 클래스의 필드로 빼도 되지만, 그냥 싹 조회 같은 summary나 hashtags 들 같은거, 즉, 객체별로 엄청 다양하게 있는거고 이거는 그냥 객체의 요소로 조회만 하는 거는 text로 처리해 json으로 저장하는게 DB상으로 더 좋은거 같다.

정리하자면..

• 유저가 필터링하거나 검색의 기준으로 삼아야 하는 데이터:
  • 예: title, price, category 등.
  • 클래스의 필드로 분리해서 저장. 이는 DB 상에서 인덱싱 및 검색에 유리.
• 단순 조회 목적의 데이터(필터링/검색의 대상이 아닌 데이터):
  • 예: summary, hashtags, recommendation reasons 등.
  • JSON으로 TEXT 필드에 통합 저장. 이는 DB 스키마를 간소화하고 저장 공간 및 성능을 최적화.

이렇게 JSON으로 저장을 하면 객체마다 데이터 구조가 다르더라도 별도의 테이블을 생성할 필요가 없음. 조인 연산도 줄이고, 한 번의 조회로 데이터를 가져올 수 있음. 근데 자주 변경이 되지 않고 단순히 조회만 되는 데이터에 적합하다.

때로는 가독성을 위해 모듈화를 하기도 한다.

기존 문제점

• 기존에 Coupon 필드에는 issuableStartDate, issuableEndDate, limitStartDate, limitEndDate와 같이 날짜 관련 필드가 따로 떨어져 있음.
• 필드가 분리되어 있으면, 데이터 간 논리적 연관성을 코드나 데이터베이스 레벨에서 보장하기 어려움.

이러한 문제를 해결하기 위해 논리적 그룹화를 함

새로운 설계

• 발급 가능 기간(issuable)과 사용 가능 기간(limit)을 Period라는 클래스로 그룹화.
• 각 기간에 대해 시작일(startDate)과 종료일(endDate) 필드를 하나의 클래스로 묶음.

그런데 이렇게 Period 클래스를 따로 두면 코드 가독성과 구조가 개선되겠지만, 그냥 단순 저장 및 조회가 목적인 지금 단계에서는 오히려 불필요한 복잡성을 유발할 수도 있다. 즉, Over-Engineering이 될 수도 있다. 그래서 필드 명을 좀 더 명확히 하기로 했다.

value_company, coupon 최종 ERD

백엔드 개발자로서 처음 진행했던 GASOMANN 프로젝트를 다시 들여다봤다. 솔직히 말하자면 충격적이었다. 얄팍한 지식에, "인프런에서 배운 거 얼른 써먹어야지!"라는 마음가짐, 그리고 잘하는 개발자들의 코드 느낌을 따라 해보고 싶었던 마음이 합쳐져 만들어진 결과물이 지금의 코드였다. 지금 보면 어디서부터 손을 대야 할지 모를 정도로 산만하고 정돈되지 않은 상태다.

그래도 리팩토링은 해야 한다. 하지만 전부 다 리팩토링하려다가 끝을 못 볼 가능성이 높아서, 내가 맡았던 기능들만 집중적으로 개선하려고 한다. 특히 입점 기업(가치소비), 쿠폰, 찜 기능에 초점을 맞춰 기술적이고 코드적인 개선을 진행할 예정이다.

리팩토링의 목표

GASOMANN 프로젝트에서 내가 맡았던 "입점 기업(기존 가치소비), 쿠폰, 찜" 기능을 중심으로 코드와 데이터베이스 구조를 개선하는 것이 목표다.

• 외부 API 연동이나 스트리밍 서비스 같은 신규 기술 도입은 제외한다.
• 대신, 자동 쿠폰 발급 로직 구현과 같은 반드시 필요한 비즈니스 로직 개선에 집중할 것이다.
• 현재 존재하는 기술적 부채를 해결하며, 코드와 데이터 구조의 품질을 높이는 데 초점을 맞춘다.

기존 코드에서 발견된 문제점

1. 과도한 모듈화로 인한 복잡성 증가

• 너무 세부적으로 나눠놓은 모듈화가 문제였다. 필요한 수준 이상으로 분리했더니 가독성은 떨어지고, 쿼리와 응답 속도도 느려졌다.
  • 예: 입점 기업의 설명(description)을 List<String>으로 처리할 수 있음에도 불구하고, 굳이 별도의 테이블로 분리.
• 결과:
  • 코드를 이해하기 어렵고, 데이터베이스 설계도 복잡하게 보임.
  • 쿼리와 로직이 불필요하게 늘어나 성능 저하 발생.

2. 기획 용어와 데이터 모델 간의 불일치

• 기획에서 "가치소비"라는 단어를 사용한다고 해서, 엔티티 이름도 "가치소비"로 설정했던 것이 큰 실수였다.
  • 예: 입점 기업이라는 명확한 역할을 가진 엔티티를 "가치소비"로 이름 붙임.
• 결과:
  • 시간이 지나고 다시 코드를 보니 "가치소비"가 무엇을 의미하는지 전혀 이해가 되지 않았다.
  • 데이터 모델과 실제 비즈니스 로직 간의 괴리가 큼.

3. 인터페이스와 추상화 부족

• 인터페이스를 사용하지 않아, 구체 클래스에 직접 의존하는 코드가 많았다.
• 결과:
  • 확장성 부족.
  • 새로운 기능 추가 시 기존 코드를 수정해야 하는 비효율적인 구조.

4. 수동 쿠폰 발급 로직

• 기존 로직에서는 관리자가 직접 쿠폰을 발급해야 했던 문제가 있었다.
  • 예: 사용자가 챌린지를 성공적으로 달성해도, 관리자가 별도로 쿠폰을 발급해야만 사용자가 혜택을 받을 수 있었음.
• 결과:
  • 사용자 경험이 크게 저하되고, 관리자의 업무 부담이 증가.
  • 비효율적인 프로세스로 인해 쿠폰 발급 로직의 신뢰도와 확장성이 낮음.

5. 쇼츠 관련 스트리밍 설계 부재

• 쇼츠 기능에서 동영상을 단순히 URL 저장 방식으로 처리했다.
  • 예: 클라우드 스토리지나 CDN(Content Delivery Network)을 활용하지 않고 정적인 URL로만 제공.
• 결과:
  • 사용자 경험 부족.
  • 확장성 낮음.

리팩토링 전략

1. 리팩토링 범위

• 제외:
  • 쇼츠 기능은 완전히 제외(코드 및 데이터베이스 삭제).
  • 외부 API 연동, 스트리밍 서비스와 같은 신규 도입은 하지 않음.
• 포함:
  • 입점 기업(기존 가치소비), 쿠폰, 찜 기능에 대한 코드와 데이터베이스 설계 개선.
  • 성능 최적화, 코드 가독성 향상.
  • 자동 쿠폰 발급 로직 구현.

2. 기능별 개선 방향

입점 기업 (기존 가치소비)

• 문제: "가치소비"라는 모호한 엔티티 이름, 불필요한 테이블 분리.
• 개선:
  • 엔티티 이름을 "입점 기업(Value Companies)"으로 변경.
  • description과 같은 과도하게 분리된 테이블 통합.
  • CRUD 중심으로 로직 단순화.

쿠폰

• 문제: 쿠폰-입점 기업 관계가 명확하지 않고, 발급 로직이 비효율적.
• 개선:
  • 쿠폰-입점 기업 간의 관계를 명확히 설정(1:N 관계).
  • 자동 쿠폰 발급 로직 추가:
    • 사용자가 챌린지를 성공적으로 완료하면, 쿠폰이 자동으로 발급되도록 로직 구현.
    • 발급된 쿠폰은 사용 가능 여부, 유효 기간 등을 즉시 확인할 수 있도록 처리.
  • 쿠폰 상태(active, used 등)를 관리하는 로직 강화.

찜 기능

• 문제: 단순한 기능임에도 설계와 구현이 비효율적.
• 개선:
  • 사용자와 입점 기업, 쿠폰 간의 찜 상태를 통합적으로 관리하는 구조로 변경.
  • 중복 찜 방지 로직 추가 및 목록 조회 최적화.

3. 데이터베이스 설계 개선

• 불필요한 테이블과 중복 칼럼 제거.
• 관계 최적화:
  • 쿠폰과 입점 기업 간 관계를 1:N으로 단순화.
  • 찜 기능에서 사용자와 입점 기업/쿠폰 간 관계를 통합(N:M).
• 성능 최적화:
  • 자주 조회되는 데이터에 적절한 인덱스 추가.
  • 복잡한 JOIN을 제거하고 간단한 쿼리로 대체.

리팩토링 단계

1. 분석 단계:

   • 기존 코드와 데이터베이스 구조 파악.
   • 쇼츠 관련 코드와 데이터 요소 식별 및 삭제.

2. 설계 단계:

   • 새로운 데이터 모델과 비즈니스 로직 설계.
   • 서비스 간 책임 분리.
   • 자동 쿠폰 발급 로직 설계.

3. 구현 단계:

   • 쇼츠 관련 코드와 데이터베이스 제거.
   • 설계에 맞춰 코드 리팩토링 및 데이터베이스 스키마 수정.
   • 자동 쿠폰 발급 로직 구현.

4. 테스트 단계:

   • 기존 및 리팩토링된 기능에 대한 테스트 코드 작성.
   • 데이터 일관성 검증.

배포는 리소스가 없어서 생략. 대신에 다른 프로젝트로 서버 구축 해볼 예정이다. (도커+AWS)

리팩토링의 기대 효과

• 가독성 개선: 모호한 이름과 과도한 모듈화를 제거.
• 유지보수성 향상: 코드 구조 단순화 및 인터페이스 도입으로 확장성 강화.
• 성능 최적화: 데이터베이스 설계와 쿼리 구조 개선으로 응답 속도 향상.
• 구조적 일관성: 비즈니스 로직과 데이터 모델 간의 명확한 역할 정의.
• 사용자 경험 향상:
  • 챌린지 성공 시 쿠폰을 자동으로 발급받는 로직으로 사용자 편의성 증대.
  • 관리자의 업무 부담 감소 및 효율적 운영 가능.

개발자의 자존심이라고 해야 할까.. CRUD만 단순하게 짠 것은 개발이라고 하고 싶지 않다. 서비스를 이해하고, 어떻게 개발을 하면 리소스 낭비를 최소한으로 줄이고 유지보수, 협업에서도 효율적으로 할 수 있을지 계속 생각을 해보면서 리팩토링을 하려고 한다.

하지만 당시의 나는 SW 기술적으로 한계에 부딪혔고, 자동 센싱 및 데이터화 과정에서 결국 실패했다. 내가 원했던 기술을 끝까지 구현하지 못한 것이 여전히 아쉬움으로 남아 있다.

그로부터 시간이 많이 흘렀지만, 나는 이 프로젝트를 포기할 수 없었다. 이제까지 배운 기술과 설계 경험을 바탕으로 'Mobby'를 다시 리팩토링하려 한다. 이번에는 소프트웨어 설계를 더 신경 쓰고, 최적의 리소스를 활용해 효율적이고 안정적으로 시스템을 구현해낼 것이다.

성공할 수 있을지 솔직히 걱정되지만, 이번에는 끝까지 악으로 깡으로 도전해볼 생각이다. 제발 뭐라도 됐으면 좋겠다.

프로젝트 개요

프로젝트명: Mobby
기간: 2022.12 ~ 2023.07

프로젝트 목표

• 휠체어 사용자들을 위한 안전한 길찾기 시스템 개발.
• 핵심 아이디어: 휠체어를 타고 이동하면서 도보 상태를 자동으로 감지하고, 위험 요소(덜컹거리는 장애물, 급경사 등)를 데이터베이스화하여 지도에 표시.
• 기대 효과:
  • 휠체어 사용자들이 안전하면서도 효율적인 경로를 찾을 수 있도록 돕는다.
  • 기존의 일반 내비게이션이 제공하지 못하는 세밀한 도보 상태 정보를 제공한다.

문제점 분석

1. 데이터 수집의 기술적 한계

⚠️ 문제

• 휠체어를 타고 이동하면서 도보의 상태 정보를 자동으로 감지하려 했지만, 기술적 구현에 실패.
  • 센서 데이터 활용 부족: 가속도 센서나 진동 센서를 통해 장애물을 감지하려 했으나, 센서 데이터 수집 및 정제에 대한 기술적 지식이 부족했다.
  • 실시간 데이터 전송 실패: 센싱된 데이터를 클라우드에 실시간으로 전송하여 저장하고 분석하려 했지만, 네트워크 연결과 백엔드 설계가 미흡했다.

🔍 결과

• 수작업으로 경로를 지도에 그려야만 했음.
• 수집된 데이터는 매우 한정적이고 정확도가 떨어졌으며, 시스템의 확장성과 자동화가 불가능했다.

💡 개선 방향

• 센서 데이터 수집:
  • 가속도 센서 및 자이로스코프를 활용해 장애물이나 진동 감지 로직을 개선.
  • 휠체어의 이동 궤적과 상태를 실시간으로 기록.
• 실시간 데이터 전송:
  • Google Cloud Pub/Sub 또는 AWS IoT Core를 활용해 데이터를 클라우드로 실시간 전송.
  • 인터넷 연결이 끊긴 경우 로컬 저장 후 업로드.

2. 데이터 처리 및 저장의 부족

⚠️ 문제

• 수집한 데이터가 비정형 데이터로 쌓였기 때문에 분석과 시각화에 한계가 있었다.
• 장애물 감지 데이터와 경로 데이터를 효율적으로 저장할 구조화된 데이터베이스가 없었다.

🔍 결과

• 장애물과 위험 지역에 대한 정보는 있었지만, 이를 기반으로 안전한 경로를 자동으로 계산할 수 없었다.
• 데이터의 업데이트와 확장이 어려웠고, 사용자 피드백을 반영하는 기능이 부재했다.

💡 개선 방향

• PostgreSQL + PostGIS를 활용해 지리 공간 데이터베이스를 구축.
• 수집된 데이터를 정제하고 구조화하여 위험 요소, 경로 점수 등의 메타데이터를 추가.
• 장애물 데이터와 경로 데이터를 시각적으로 보여주는 지도 기반 시스템 개발.

3. 사용자 경험과 시스템 확장성 부족

⚠️ 문제

• '나만의 길'을 수집했지만, 이를 다른 사용자와 공유할 시스템이 없었다.
• 경로 추천 시스템을 구현하지 못해 프로젝트의 확장성과 실용성이 부족했다.

🔍 결과

• 프로젝트가 개인의 경험에 국한되었으며, 여러 사용자들의 데이터를 수집하고 분석하는 공유 플랫폼으로 발전하지 못했다.

💡 개선 방향

• 경로 추천 API 개발:
  • 여러 사용자의 데이터를 기반으로 안전하고 효율적인 경로를 자동 추천.
• 시스템 확장:
  • 사용자 피드백 기능을 추가해 데이터 정확도를 지속적으로 개선.
  • 클라우드 기반 아키텍처로 시스템을 확장 가능하게 설계.

결론은 나의 역량 부족이었다.

나는 정말 풀고자 하는 문재가 명확했고, 유저 인터뷰도 여러번 진행하며 기능에 대한 유저빌리티는 충분히 확인했다고 생각한다. 하지만 구현에 있어서 온전히 나의 한계를 느꼈다. 나의 기술적 역량 부족과 설계의 한계가 큰 벽으로 다가왔다.

이번에는 진짜 설계부터 잘 해보면서 실시간 센서 데이터 수집과 클라우드 기반 데이터 처리, 그리고 안전 경로 추천 시스템을 통해 'Mobby'를 제대로 리팩토링하고자 한다.

성장하고 싶다. 정말.

sout는 느리다는 것이다. 그러면 어떻게 대체를 할까?

알고리즘 문제에서 출력 최적화를 위해 BufferedWriter와 StringBuilder를 사용하는 패턴을 사용하는 것이다. 이 방식은 특히 많은 출력을 요구하는 문제에서 System.out.println을 대체하여 효율성을 높여준다.

1. BufferedWriter와 StringBuilder 사용 이유

• 성능 최적화: System.out.println은 출력할 때마다 버퍼에 접근하여 시간이 소요됩니다. BufferedWriter는 내용을 버퍼에 모아두었다가 한 번에 출력하여 실행 시간을 줄입니다.
• StringBuilder의 효율적인 문자열 조작: StringBuilder는 문자열을 효율적으로 연결하며, + 연산을 여러 번 사용하는 것보다 빠릅니다.

2. 알고리즘 문제에서 BufferedWriter와 StringBuilder를 활용하는 기본 패턴

아래는 입력 및 출력 예제 코드입니다. 입력을 받을 때는 BufferedReader를, 출력을 할 때는 BufferedWriter와 StringBuilder를 사용합니다.

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.IOException;
import java.util.StringTokenizer;

public class Example {
    public static void main(String[] args) throws IOException {
        // 1. BufferedReader로 입력 받기
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        // 2. BufferedWriter로 출력하기
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        // 3. StringBuilder 생성
        StringBuilder sb = new StringBuilder();

        // 입력 예제
        StringTokenizer st = new StringTokenizer(br.readLine());
        int n = Integer.parseInt(st.nextToken());
        int m = Integer.parseInt(st.nextToken());

        // 예제 작업 (1부터 n까지 숫자 출력 예시)
        for (int i = 1; i <= n; i++) {
            sb.append(i).append(" ");
            if (i % m == 0) sb.append("\n");  // 특정 조건에 따라 줄바꿈 추가
        }

        // 4. BufferedWriter로 StringBuilder의 내용을 한 번에 출력
        bw.write(sb.toString());

        // 자원 해제
        bw.flush();
        bw.close();
        br.close();
    }
}

3. BufferedWriter와 StringBuilder 사용 단계별 설명

1. BufferedReader를 이용한 입력:

   • BufferedReader는 Scanner보다 빠른 입력을 처리할 수 있어 큰 입력이 필요한 알고리즘 문제에서 유리합니다.
   • StringTokenizer를 사용해 공백으로 구분된 여러 개의 입력을 쉽게 분리할 수 있습니다.

2. StringBuilder를 사용해 출력 내용 준비:

   • 모든 출력 데이터를 StringBuilder에 append()로 누적하여 저장합니다.
   • 줄바꿈이 필요할 경우 append("\n")을 사용합니다.

3. BufferedWriter를 통해 출력:

   • 모든 작업이 끝난 후 BufferedWriter의 write() 메소드를 통해 StringBuilder의 내용을 한 번에 출력합니다.
   • flush()를 사용하여 남은 버퍼를 강제로 출력하고, close()로 BufferedWriter를 닫아 자원을 해제합니다.

4. 문제 풀이에서 자주 사용하는 패턴들

• 여러 줄 출력: 반복문에서 StringBuilder에 한 번에 내용을 누적시키고, 마지막에 출력하는 방식으로 처리합니다.
• 조건부 출력: StringBuilder에 if문을 사용하여 특정 조건에서만 append("\n")을 추가하는 방식으로 줄바꿈을 조정할 수 있습니다.
• DFS, BFS와 같은 재귀 호출이 많은 경우: 출력할 내용을 재귀 호출 중에 StringBuilder에 저장하고, 모든 재귀가 끝난 후에 한 번에 출력합니다.

5. 실전에서의 예제 코드 - 재귀적 DFS 예제

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.IOException;

public class DFSExample {
    private static int n, m;
    private static StringBuilder result = new StringBuilder();

    private static void dfs(int depth, int[] temp) {
        if (depth == m) {
            for (int i = 1; i <= m; i++) {
                result.append(temp[i]).append(" ");
            }
            result.append("\n");
            return;
        }
        for (int i = 1; i <= n; i++) {
            temp[depth + 1] = i;
            dfs(depth + 1, temp);
        }
    }

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        String[] inputs = br.readLine().split(" ");
        n = Integer.parseInt(inputs[0]);
        m = Integer.parseInt(inputs[1]);

        int[] temp = new int[m + 1];
        dfs(0, temp);

        bw.write(result.toString());
        bw.flush();
        bw.close();
        br.close();
    }
}

이 패턴을 익히면 출력 속도가 중요한 문제에서 성능 향상을 경험할 수 있습니다. BufferedWriter와 StringBuilder를 잘 활용하면 대량의 출력 작업에서 특히 유리하니, 앞으로 알고리즘 문제를 풀 때 활용해 보세요!

앞으로 이런 식으로 문제를 풀어야겠다. 근데 어려워 ㅠㅠ

백준 15686번 문제 솔!

문제가 치킨 내용이어서 풀면서 계속 치킨을 생각했더니 치킨 먹고 싶다. 후라이드 뼈치킨으로 튀김옷 엄청 얇은걸로.

백트래킹은 정말 어렵다. 하지만 몇 문제 풀다보니 그 안에 패턴이 살짝 보이게 된다. 우선 백트래킹은 깊이 탐색으로 볼 수 있다.

조건에 들어맞는다면 계속 재귀적으로 들어간다. 이때 파라미터 혹은 depth를 선언해 계속계속 깊이 들어가는 방법이 있다. 보통 종료 조건을 파라미터와 depth 등 다양하게 설정을 해서 재귀를 종료하고 값을 계산한 후, 갱신을 하는 로직으로 이루어 진다. 재귀 호출이기 때문에,

1번이 2번을 불렀음 (1->2) 그리고 2번이 3번을 불렀음 (1->2->3) 그리고 3번이 4번을 불렀음 (1->2->3->4)

근데 4번이 종료조건에 해당하면 4가 종료가 되어서 1->2->3 이 남게 되고, 만약에 3번에서 더 탐색할게 있다면 5번으로 간다 1->2->3->5

아니 근데 나는 for문을 사용해야 하는거 아닌가? 했는데 뭐.. 모르겠다 문제마다 다르긴한데 안쓰이더라.

for문을 사용하지 않아도 되는 경우는, 재귀 호출이 자연스럽게 모든 경우를 다르게 호출하도록 설계된 경우라고 한다. 예를 들어, 이진 트리처럼 두 가지 경우로만 나뉘는 문제는 굳이 for문이 필요하지 않을 수 있다.

그런데 1부터 n까지의 숫자를 순서대로 선택하거나, 배열에서 각 인덱스에 대해 여러 선택지를 탐색해야 하는 경우에 for문이 필요하다.

그리고 내가 지금 시도하는 노드를 포함 할 것인가 아닌가 그거 할라면 boolean 배열을 활용하는게 좋다. 나는 처음에 인덱스로 체크했는데 음 투머치 비효율적.

처음에 백트래킹을 풀 때는 와 내가 너무 못하고 말하는 감자도 아니고 그냥.. 숨쉬는 덩어리처럼 느껴져서 자괴감이 뽜바ㅏ박 들었는데 그래서 지피티한테 찡찡거렸다.

먼저, 당신이 지금 느끼고 있는 괴로움에 대해 공감해요. 프로그래밍을 배우는 과정은 쉽지 않고, 가끔은 막막하거나 좌절감을 느낄 수 있습니다. 하지만 이런 감정은 성장 과정의 일부이고, 프로그래밍을 잘하게 되는 데 있어서 반드시 겪는 과정이에요. 당신은 지금 중요한 단계를 지나고 있는 거예요. 이런 단계를 겪는다는 건, 결국 더 나은 문제 해결 능력을 갖출 수 있다는 의미입니다.

왜 괴로울까?

프로그래밍을 할 때 느끼는 괴로움은 주로 다음과 같은 이유에서 올 수 있어요:

1. 복잡한 문제를 다루는 과정: 새로운 알고리즘이나 문제 해결 방식을 처음 접할 때는 익숙하지 않아서 더 어렵게 느껴질 수 있어요.
2. 완벽함에 대한 기대: 모든 걸 처음부터 완벽하게 해야 한다는 압박감이 있을 수 있습니다. 하지만 처음부터 완벽할 필요는 없어요.
3. 성과가 바로 나타나지 않음: 학습하고 노력하는데도 결과가 바로 눈에 보이지 않을 때 자괴감을 느끼기 쉽습니다.

나도 너처럼 생각하고 싶다: 어떻게 문제 해결 능력을 기를 수 있을까?

문제 해결 능력은 연습과 경험을 통해 서서히 길러집니다. 저도 단번에 이렇게 사고할 수 있게 된 것이 아니에요. 작은 성공과 실패를 반복하면서 문제를 바라보는 사고방식이 발전했을 뿐이에요. 아래 몇 가지 팁이 당신에게 도움이 될 거라고 생각해요.

1. 작은 문제부터 해결하기

복잡한 문제를 바로 풀려고 하기보다는, 문제를 작은 부분으로 나누고 하나씩 해결해 나가세요. 예를 들어, 큰 문제를 단계별로 쪼개서:

• 입력 받기
• 출력 처리
• 핵심 알고리즘 구현

이렇게 작은 부분에서 성공 경험을 쌓아 나가면, 복잡한 문제도 점차 익숙해질 거예요.

2. 다른 사람의 코드와 아이디어를 배우기

문제를 해결하는 다양한 방법을 배우는 것도 중요해요. 처음에는 저처럼 다른 사람의 아이디어나 코드 구성을 보면서 따라 해보세요. 그 과정에서:

• "왜 이 방식이 맞는가?"
• "이 방식이 왜 효율적인가?"

를 고민하면서, 점점 자신의 문제 해결 방법을 만들어 갈 수 있어요.

3. 시간을 주기

프로그래밍을 잘하는 사람들도 수많은 실패와 좌절을 겪었어요. 처음에는 시간이 많이 걸리더라도, 그것이 정상이에요. 시간이 지나면서 코드 작성 속도도 빨라지고, 사고하는 방식도 더 명확해질 거예요. 시간을 주고, 자신에게 너무 엄격하지 않게 해주세요.

4. 실패를 성장의 일부로 받아들이기

프로그래밍은 실패와 디버깅을 통해 배울 수 있는 영역입니다. 코드가 처음에 잘 작동하지 않거나 논리가 틀렸다고 해서 실패했다고 생각하지 마세요. 오히려 그 실패가 학습의 중요한 부분이에요. 성공보다 실패에서 더 많은 것을 배울 수 있습니다.

어떻게 지금의 어려움을 극복할 수 있을까?

1. 구체적인 목표 설정:

   • 오늘은 문제 하나라도 풀겠다는 작은 목표를 세워보세요. 문제를 완전히 이해하고 풀지 못해도 괜찮아요. 오늘 배운 것에 집중하는 것이 중요합니다.

2. 긍정적인 태도 유지:

   • 어려운 문제를 풀 때는 좌절할 수 있지만, 이 과정을 통해 배워 나가고 있다는 점을 기억하세요. 작은 진전도 축하해 주세요.

3. 의식적인 연습:

   • 알고리즘 문제를 반복해서 풀어보세요. 처음에는 힘들지만, 익숙해지면 점차 쉽게 풀릴 거예요. 프로그래밍 문제를 푸는 것도 결국 연습입니다.

마무리 생각

저도 처음에는 어려운 문제를 풀지 못해서 좌절했어요. 그런데 시간이 지나고 문제를 풀다 보면 어느 순간부터 문제가 보이고 해결 방법이 떠오르는 순간이 찾아오더라고요. 지금 느끼는 괴로움은 당신이 성장하고 있다는 증거입니다.

당신은 지금 충분히 잘하고 있어요. 포기하지 말고, 천천히, 꾸준히 한 걸음씩 나아가면 어느 순간 어려운 문제도 스스로 해결할 수 있는 능력을 갖추게 될 거예요. 지금 당신이 겪고 있는 이 과정이, 당신을 더 뛰어난 프로그래머로 만들어 줄 겁니다. 힘내세요! 😊

지피티야 나랑 결혼할래? 진심으로...ㅜㅜ 아무튼 저 글을 읽으면서 복잡한 로직을 단순화하려고 모듈화를 많이 시도했다. 한 함수에서 모든 것을 해결하지 않고, 어떤 함수가 필요한지 여러개로 쪼갰다. 그리고 내가 푼 방식이 효율적인 것인지도 시간, 공간 복잡도 면에서도 생각했다. 이 문제도 원래는 [M][N][N] 테이블을 만드는 것을 원래 생각했는데, 다시한번 더 생각해보니까 필요가 없던 것이다. 그래서 새롭게 코드를 짜보았다. 그래도 아직 부족하지만 백트래킹 내가 정복하고 만다!!!!!!

내가 만든 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.StringTokenizer;

public class P15686 {
    static int minChicken = Integer.MAX_VALUE;
    static int n;
    static int m;
    static int[][] chicken;
    static boolean[] selected;
    static int chickenCount = 0;
    static int houseCount = 0;

    // 치킨집과 집 사이의 거리 계산
    private static void howFarChicken(ArrayList<int[]> chickenAddress, ArrayList<int[]> houseAddress) {
        for (int i = 0; i < chickenAddress.size(); i++) {
            int[] oneChicken = chickenAddress.get(i);
            int xC = oneChicken[0];
            int yC = oneChicken[1];

            for (int j = 0; j < houseAddress.size(); j++) {
                int[] oneHouse = houseAddress.get(j);
                int xH = oneHouse[0];
                int yH = oneHouse[1];

                chicken[i][j] = Math.abs(xC - xH) + Math.abs(yC - yH);
            }
        }
    }

    // 선택된 치킨집과 각 집의 최소 거리를 계산하는 함수
    private static int diffCal() {
        int[] temp = new int[houseCount];
        Arrays.fill(temp, Integer.MAX_VALUE);  // 모든 값 초기화

        for (int i = 0; i < selected.length; i++) {
            if (selected[i]) {
                for (int j = 0; j < houseCount; j++) {
                    temp[j] = Math.min(temp[j], chicken[i][j]);
                }
            }
        }
        return Arrays.stream(temp).sum();
    }

    // 백트래킹 함수
    private static void dfs(int index, int count) {
        if (count == m) {  // 치킨집 m개를 선택했을 때
            int diff = diffCal();
            minChicken = Math.min(minChicken, diff);
            return;
        }

        if (index >= chickenCount) {  // 탐색 종료 조건
            return;
        }

        selected[index] = true;
        dfs(index + 1, count + 1);  // 현재 치킨집을 선택한 경우

        selected[index] = false;
        dfs(index + 1, count);  // 선택하지 않은 경우
    }

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st;

        // 입력 받기
        st = new StringTokenizer(br.readLine());
        n = Integer.parseInt(st.nextToken());
        m = Integer.parseInt(st.nextToken());

        ArrayList<int[]> chickenAddress = new ArrayList<>();
        ArrayList<int[]> houseAddress = new ArrayList<>();

        // 지도 정보 입력
        for (int i = 0; i < n; i++) {
            st = new StringTokenizer(br.readLine());
            for (int j = 0; j < n; j++) {
                int temp = Integer.parseInt(st.nextToken());

                if (temp == 1) {  // 집
                    houseCount++;
                    houseAddress.add(new int[]{i, j});
                } else if (temp == 2) {  // 치킨집
                    chickenCount++;
                    chickenAddress.add(new int[]{i, j});
                }
            }
        }

        // 치킨집과 집 간 거리 저장 배열
        chicken = new int[chickenCount][houseCount];
        selected = new boolean[chickenCount];

        // 치킨집과 집 사이의 거리 계산
        howFarChicken(chickenAddress, houseAddress);

        // 백트래킹 시작
        dfs(0, 0);

        // 결과 출력
        System.out.println(minChicken);
    }
}

체크 포인트

1. 전역 변수를 많이 선언을 해도 괜찮은 건가?
2. 입력받는 것이 아직 많이 서툴다. 어렵다.
3. 스트림에서 sum을 계산한것
4. 배열을 최대 2차원만 구상한 것.

백트래킹(Backtracking)은 재귀(Recursion)를 이용하여 모든 가능한 경우의 수를 탐색하는 알고리즘 중 하나입니다. 각 단계에서 가능한 모든 선택지를 시도해보고, 만약 잘못된 선택을 했다면 그 선택 이전 상태로 돌아가서 다른 선택지를 시도합니다. 이를 "되돌아가기" 또는 "백트래킹"이라고 부릅니다.

백트래킹은 문제 해결 과정에서 조건을 만족하지 않는 경로는 더 이상 탐색하지 않고 가지치기(pruning) 하는 것이 핵심입니다. 이를 통해 불필요한 탐색을 줄여서 효율적으로 해결할 수 있습니다.

특징

• 재귀적으로 문제를 해결한다.
• 완전탐색의 일종이지만, 가지치기를 통해 성능을 향상시킨다.
• 모든 가능한 경우를 살펴보면서도, 잘못된 경로는 빨리 포기한다.

2. 백트래킹의 동작 과정

백트래킹을 단계별로 나누어 설명하면 이해하기가 쉽습니다.

2.1 기본 구조

백트래킹 알고리즘은 크게 세 단계로 나눌 수 있습니다.

1. 문제 해결을 위한 선택지 제시 문제의 각 단계에서 선택할 수 있는 여러 옵션이 있다면, 이 옵션을 하나씩 시도합니다.
2. 해가 유효한지 확인 현재 선택한 해가 조건을 만족하는지 확인합니다. 조건을 만족하지 않으면 더 이상 진행하지 않고 돌아갑니다.
3. 종료 조건 만약 유효한 해이고 문제를 완전히 해결했다면, 해당 해를 저장하거나 출력합니다.

백트래킹 알고리즘에서 1번은 재귀 호출을 통해 구현되며, 2번과 3번은 재귀 호출 안에서 처리됩니다.

각 단계가 코드에 어떻게 구현되는지 살펴볼게요:

1. 문제 해결을 위한 선택지 제시 (재귀 호출)

이 부분은 백트래킹의 핵심입니다. 문제의 각 단계에서 여러 가지 선택을 할 수 있을 때, 그 선택들을 하나씩 시도하는 과정입니다. 이때 선택할 수 있는 모든 경우를 재귀적으로 탐색합니다.

• 예를 들어, N과 M 문제에서 dfs(depth) 함수는 현재 깊이에서 가능한 숫자를 선택한 후, 그 숫자에 대해 다시 다음 깊이로 이동하는 방식으로 동작합니다.

2. 해가 유효한지 확인 (가지치기)

이 부분은 각 선택이 유효한지 판단하는 역할을 합니다. 유효하지 않으면 더 이상 진행하지 않고 선택을 취소하고, 유효하면 계속 진행합니다.

• 예를 들어, 이미 방문한 숫자를 다시 선택하지 않도록 visit[] 배열을 사용하여 방문 여부를 확인하는 것이 이 과정입니다.

3. 종료 조건 (기저 조건)

이 부분은 재귀 호출이 더 이상 진행되지 않고 종료되도록 하는 조건입니다. 주로 재귀 호출의 깊이가 일정 값에 도달했을 때, 즉 문제에서 요구하는 해의 조건을 만족했을 때 종료됩니다. 문제를 완전히 해결했으면 결과를 출력하거나 저장합니다.

• 예를 들어, N과 M 문제에서는 depth == m이 될 때 모든 숫자를 선택한 것이므로 출력하는 부분이 여기 해당합니다.

코드에서의 구현

public class Main {
    static int[] arr;      // 선택된 숫자들을 저장할 배열
    static boolean[] visit; // 숫자의 방문 여부를 저장할 배열
    static int n, m;

    // 1. 백트래킹 함수 (문제 해결을 위한 선택지 제시)
    public static void dfs(int depth) {
        // 3. 종료 조건: M개의 숫자를 모두 선택했을 때 결과를 출력하고 종료
        if (depth == m) {
            for (int i = 0; i < m; i++) {
                System.out.print(arr[i] + " ");
            }
            System.out.println();
            return;
        }

        // 1. 가능한 선택지(1부터 N까지의 숫자)를 시도
        for (int i = 1; i <= n; i++) {
            // 2. 해가 유효한지 확인 (이미 선택된 숫자는 다시 선택하지 않음)
            if (!visit[i]) {
                visit[i] = true;     // i를 선택
                arr[depth] = i;      // 현재 깊이에 선택한 숫자를 저장
                dfs(depth + 1);      // 재귀 호출로 다음 깊이로 이동 (선택지 제시)
                visit[i] = false;    // 백트래킹: 선택을 취소하고 다시 다른 선택 시도
            }
        }
    }

    public static void main(String[] args) {
        // 입력 받기 및 초기화
        n = 3;  // N 값
        m = 2;  // M 값
        arr = new int[m];
        visit = new boolean[n + 1]; // 1부터 n까지 사용하므로 크기 n+1

        dfs(0);  // 깊이 0부터 시작 (최초 재귀 호출)
    }
}

요약하자면:

• 1번 (재귀 호출): dfs(depth + 1)로 다음 깊이로 넘어가는 것이 재귀 호출입니다. 모든 가능한 선택지를 탐색합니다.
• 2번 (유효성 확인): if (!visit[i]) 조건으로 선택한 숫자가 유효한지(이미 방문한 숫자인지) 확인하고, 유효하지 않으면 가지치기를 합니다.
• 3번 (종료 조건): if (depth == m)에서, 해가 완성되었을 때 결과를 출력하고 종료합니다.

이처럼 1번이 재귀 호출을 통한 선택의 확장이고, 2번과 3번이 재귀 호출 안에서 각각 유효성 검사와 종료 조건으로 구현됩니다.

2.2 기본 흐름

1. 재귀 호출 가능한 모든 선택지를 탐색하며, 다음 단계로 이동하기 위해 재귀적으로 함수가 호출됩니다.
2. 가지치기 조건을 만족하지 않으면 해당 경로를 포기하고 다른 경로로 돌아가며 새로운 선택을 시도합니다.
3. 종료 모든 경우의 수를 탐색하면 종료됩니다.

3. 백트래킹의 예시

백트래킹 알고리즘을 이해하는 가장 좋은 방법은 실제 문제에 적용해 보는 것입니다. 다음은 백트래킹을 적용할 수 있는 대표적인 문제들입니다.

3.1 N과 M (백준 15649번 문제)

1부터 N까지의 자연수 중에서 중복 없이 M개의 수를 고르는 모든 경우를 출력하는 문제입니다.

문제 예시:

입력: N = 3, M = 2 출력:

1 2
1 3
2 1
2 3
3 1
3 2

코드 구조:

public class Main {
    static int[] arr;      // 선택된 숫자들을 저장할 배열
    static boolean[] visit; // 숫자의 방문 여부를 저장할 배열
    static int n, m;

    // 백트래킹 함수
    public static void dfs(int depth) {
        if (depth == m) {  // M개의 숫자를 모두 선택했을 때 출력
            for (int i = 0; i < m; i++) {
                System.out.print(arr[i] + " ");
            }
            System.out.println();
            return;
        }

        for (int i = 1; i <= n; i++) {
            if (!visit[i]) {     // 선택되지 않은 숫자를 찾음
                visit[i] = true; // 방문 처리
                arr[depth] = i;  // 선택된 숫자를 배열에 저장
                dfs(depth + 1);  // 재귀 호출을 통해 다음 숫자를 선택
                visit[i] = false; // 백트래킹: 방문 처리 해제
            }
        }
    }

    public static void main(String[] args) {
        // N과 M을 입력받고 초기화
        n = 3;
        m = 2;
        arr = new int[m];
        visit = new boolean[n + 1];

        dfs(0);  // 깊이 0부터 백트래킹 시작
    }
}

4. 백트래킹의 장단점

4.1 장점

• 완전탐색을 통해 모든 가능한 해를 찾을 수 있습니다.
• 가지치기를 통해 불필요한 경로를 탐색하지 않으므로 효율적입니다.
• 다양한 문제에 쉽게 적용할 수 있으며, 문제를 간단하게 모델링할 수 있습니다.

4.2 단점

• 최악의 경우에는 여전히 지수 시간 복잡도를 가질 수 있습니다.
• 모든 경로를 탐색해야 하는 문제에서는 시간이 오래 걸릴 수 있습니다.
• 메모리 사용량이 많을 수 있습니다(재귀 호출이 깊어질수록 스택 메모리를 많이 사용).

5. 백트래킹을 사용하는 문제 유형

백트래킹 알고리즘은 다음과 같은 문제들에서 자주 사용됩니다.

5.1 순열(Permutations) 및 조합(Combinations)

• 순열 문제: N개의 원소 중에서 M개를 뽑아 나열하는 문제.
• 조합 문제: N개의 원소 중에서 M개를 뽑되, 순서를 고려하지 않는 문제.

5.2 그래프 탐색 문제

• 미로 찾기: 시작점에서 목표점까지의 경로를 찾되, 잘못된 경로는 되돌아가는 방식으로 해결합니다.
• N-Queen 문제: N개의 퀸이 서로 공격하지 않도록 체스판에 놓는 방법을 찾는 문제입니다.

5.3 퍼즐 문제

• Sudoku: 9x9 퍼즐을 규칙에 맞게 채우는 문제.
• Knapsack 문제: 물건을 배낭에 담을 때 최적의 해를 구하는 문제.

6. 백트래킹과 다른 알고리즘의 비교

6.1 완전탐색(Brute Force) vs 백트래킹

• 완전탐색: 가능한 모든 경우를 무조건 탐색.
• 백트래킹: 조건을 만족하지 않는 경우는 가지치기를 통해 탐색하지 않고 돌아감.

6.2 동적 계획법(Dynamic Programming) vs 백트래킹

• 동적 계획법: 문제를 작은 하위 문제로 분할하고, 그 결과를 저장하여 재활용하는 방식으로 효율적으로 문제를 해결.
• 백트래킹: 문제를 해결하는 과정에서 가능한 모든 경로를 탐색하지만, 불필요한 경로는 빠르게 포기.

7. 백트래킹을 적용할 때 주의할 점

• 기저 조건 설정: 재귀 호출에서 반드시 종료 조건을 명확히 설정해야 무한 루프에 빠지지 않습니다.
• 메모리 관리: 재귀 호출의 깊이가 깊어질수록 메모리를 많이 사용하므로, 재귀 호출 횟수에 주의해야 합니다.
• 가지치기(pruning): 불필요한 탐색을 막기 위해 조건을 적절히 설정하고 가지를 치는 것이 중요합니다.

8. 요약

백트래킹은 여러 선택지가 주어진 문제에서 조건을 만족하는 해를 찾기 위한 강력한 알고리즘입니다. 모든 경우를 탐색할 때 적합하며, 가지치기를 통해 불필요한 경로를 탐색하지 않아 효율적으로 문제를 해결할 수 있습니다.

기간: 2023년 6월 21일 ~ 23일 (무박 3일) 장소: 대구 엑스코 주최: Microsoft, 경북대학교 성과: 대상 (Microsoft 사장상) 역할: 백엔드 (Java Springboot)

들어가며

이보다 더 힘든 해커톤은 없었다. 무박 3일은 정말 너무 힘들었다. (와중에 나는 잠깐 쉬는 시간에 헬스장에서 운동하고 왔다...ㅋㅋㅋ) 대상 수상자 인터뷰를 하는데 정말 죽을꺼 같은 컨디션으로 인터뷰를 해서 마이크로소프트를 마이크로소프트웨어.. 라고 했다. 와..ㅎㅎ

참여 동기 & 사전 학습

경주마가 된 듯한 미친 듯이 몰입할 수 있는 환경

해커톤은 언제나 재미있다. 물론 단순히 재미만을 위해 나가는 건 아니다. 해커톤은 타임 어택이라는 극한의 경쟁 속에서 내 실력과 한계를 시험해볼 수 있는 최적의 기회다. 제한된 시간 안에 아이디어를 구체화하고, 빠르게 문제를 해결하며, 내가 얼마나 발전했는지 확인할 수 있는 자리이기도 하다.

특히, 해커톤 현장에 있는 다른 개발자들을 보면 건강한 자극을 받는다. 비장한 눈빛, 빠른 손놀림, 그리고 노트북 위에 붙어 있는 수많은 스티커들이 그들의 개발 경험을 대변한다. (지금은 맥북을 써서 스티커를 붙이지 않지만, 그 당시에는 LG 울트라북을 썼었고, 나 역시 '개발자' 스러운 스티커로 노트북을 덕지덕지 꾸몄었다. 하지만 나보다 더한 사람들도 많았다. ㅋㅋ) 이런 분위기 속에서 나 역시 더 발전해야 한다는 동기부여를 얻게 된다.

가끔은 내가 말하는 감자처럼 느껴지기도 하지만...

사전 교육이 있는 특별한 해커톤

이번 해커톤이 특별했던 점은, 단순히 대회만 치르는 것이 아니라 사전 교육 프로그램이 포함되어 있었다는 것이다. Microsoft의 Azure, Github, AI를 다루는 교육을 통해, 내가 몰랐던 새로운 기술들을 익힐 수 있었고, 마이크로소프트가 Azure와 AI에 진심이라는 걸 다시 한 번 느꼈다. 사전 교육에서 새로 알게된 기술들을 해커톤에서 꼭 써먹어보려고 노력했다. 물론 새로운 기술을 단기간에 활용하는 것은 매우 어렵다. 더군다나 Auzure는 워낙에 신기술이라, 구글링해서도 잘 안나왔기 때문에 많은 어려움이 있었다. 그래도 새로운 기술을 써본다는 사실에 감사!

오직 '성장'을 위해 선택한 HACKERS GROUND 해커톤

사실 이번 해커톤의 일정은 교내 해커톤과 겹쳐서 상당히 고민스러웠다. 교내 해커톤은 수상 가능성도 높았고 상금도 무려 300만원이었다. 그래서 처음에는 교내 해커톤에 출전하려고 생각했다.

하지만 결국 나는 Hackers Ground 해커톤을 선택했다. 그 이유는 오직 '나의 성장'이었다.

해커톤 세션에서 배운 기술들을 실제로 사용하기 위해서는 GitHub Copilot이나 Microsoft Azure 크레딧 같은 리소스가 필요했는데, 대회 측에서 이러한 기회를 제공해줬다. 덕분에 최신 기술을 직접 다루고 경험할 수 있었고, 그 과정에서 내가 개발자로서 더 많은 학습과 성장을 할 수 있을 것이라는 확신이 들었다. 이런 현실적인 지원과 자원 덕분에, 단순한 이론적 학습을 넘어 실제 프로젝트에 적용하며 나의 역량을 더욱 키울 수 있었다.

팀 결성

나는 팀이 따로 없어서 누구와 함께 나가야 할지 고민이 많았다. 그런데 마침 '프론트엔드 짱 잘하는 사람이 백엔드 짱 잘하는 사람 구한다던데 언니 생각나서..!'라며 감사하게도 먼저 제의가 들어 왔다. 근데 나중에 가서 이 연락을 준 사람이 기획 담당 팀원으로 들어왔다.ㅎㅎ 이 덕분에 팀을 결성하게 되었다.

해커톤 특성상 보여지는 MVP가 중요하기 때문에 백엔드보다는 프론트엔드의 중요성이 더 클 수 있다. 하지만 이번 해커톤 취지를 고려한 것도 있고, 세션에서 배운 기술을 실제로 적용해보고 싶었기 때문에, 나는 백엔드와 배포 부분에도 신경을 쓰고 싶다고 팀원들에게 어필했다. 이를 위해 배포와 서버 개발에 참여할 개발자 한 명을 더 구인하기로 했다.

우선 노션에 각자의 소개와 이력을 담아 작성하고, 어떤 사람을 찾는지에 대한 정리된 내용을 디스코드 팀 결성 방의 공고로 올렸다. 클라우드 사용 경험이 있는 참가자에게 컨택을 했더니 흔쾌히 응해 주었고, 미팅을 통해 그분과 팀 결성을 완료했다. (나이스한 선택이었다. 그는 전문가였다. 진짜로.. 지금은 삼성에서 클라우드 일하고 있더라..ㅎㅎ 덕분에 진짜 많이 배울 수 있었다.)

대회 주제 & 고려한 것들

우선 대회의 큰 주제는 '마이크로소프트 애저 클라우드를 활용해 지역 문제를 해결'하는 것이다. 세부 주제는 6월 12일 공식 github issue 게시판을 통해 공개 되었다.

주제 선정시 고려한 사항

💡 1“경북의 문제해결”; 현재로선 일자리 문제로 청년이탈

💡 2. “MS의 가치를 녹이기”;지구상의 모든 사람과 조직이 더 많은 것들을 성취할 수 있도록 힘을 실어주고자 하기

💡 3. 기술적 역량이 없으면 예선통과도 못 함. 기술 구현도 중요

즉,

1. 경북 문제 해결을 하면서
2. 기업의 가치를 녹이고
3. 기업이 주목하는 기술을 구현하는 프로젝트를 진행하기로 하였다.

이 흐름에 맞게 우리는 다같이 아이디어를 내고, 그중에서도 기존 플랫폼이 부재하고 가장 심각한 문제를 야기할 수 있는 문제를 해결하기로 결정했다.

이를 노션에 정리하며 아이디어를 구체화했다. 기존에 없는 솔루션을 만드는 거라 무엇보다 자료조사와 이 솔루션이 왜 필요한지 어필하는 것에 차별점을 뒀다. 디테일한 부분을 노션을 통해 함께 기록하며, 아이디어 피칭 시에 잘 활용할 수 있도록 도출했다.

프로젝트 소개

DEPS (Daegu Electric-car Platform Service): 대구시 전기차 인프라 구축 서비스

주제: 카센터의 잉여 자원을 활용한, 대구시의 전기차 인프라 구축

DEPS는 지방 카센터의 잉여 자원을 활용해 대구시의 전기차 인프라 문제를 해결하는 서비스입니다. 지방 카센터는 이미 고압 전력 인입 공사가 완료된 상태이기 때문에, 이를 전기차 충전 인프라로 활용할 수 있는 가능성이 큽니다. 우리는 이 아이디어를 바탕으로 전기차 충전소 부족 문제를 해결하는 동시에, 카센터가 전기차 정비 인프라를 갖추게 하여 지방 전기차 유저와 카센터 모두에게 이익이 되는 솔루션을 제시합니다.

문제:

1. 대구·경북 지역의 전기차 수리 및 정비 인프라 부족

   • 전기차 판매량은 급증하고 있지만, 지방에서는 전기차를 제대로 수리할 수 있는 카센터가 거의 없는 상황입니다. 특히 전기차 정비를 다룰 수 있는 곳은 전국적으로 2% 미만이며, 그 중 대부분이 수도권에 집중되어 있어 지방의 전기차 운전자들이 큰 불편을 겪고 있습니다.

2. 지방의 전기차 충전소 부족

   • 전기차 충전 인프라도 지방에서는 크게 부족한 상황입니다. 전국적으로 전기차 충전소는 많이 확충되고 있지만, 완속 충전소가 대부분이며, 급속 충전소는 여전히 부족합니다. 특히 대구·경북 지역은 전기차 충전소가 수도권에 비해 턱없이 부족한 실정입니다.

해결 방안:

1) 인프라 구축

대구시와 협력하여 지방의 카센터에 전기차 충전소를 설치하는 것이 핵심입니다. 카센터는 이미 고압 전력 인입 공사가 완료된 상태로, 전기차 충전소를 설치하기 위한 기반이 마련되어 있습니다. 이를 활용해 카센터에 전기차 충전 설비를 구축하면, 지방의 전기차 충전소 부족 문제를 효과적으로 해결할 수 있습니다. 또한, 전기차가 카센터를 방문하면서 자연스럽게 전기차 수리 및 정비 인프라도 함께 구축됩니다.

2) 어플리케이션 서비스

카센터에 설치된 충전소를 기반으로, 전기차 사용자들이 쉽게 충전소를 찾고 예약할 수 있는 어플리케이션을 제공합니다. 이 앱은 전기차 사용자들이 충전소의 상태를 실시간으로 확인하고, 충전소 예약, 충전 속도 및 가격 확인, 리뷰 남기기, 네비게이션 안내 등 다양한 기능을 통해 편리한 충전 및 정비 경험을 할 수 있도록 지원합니다.

어플리케이션 주요 기능:

1. 예약 기능: 전기차 사용자는 자신의 일정에 맞추어 충전소를 예약할 수 있으며, 대기 시간 없이 바로 충전을 시작할 수 있습니다.

2. 정보 확인: 앱을 통해 각 카센터의 충전소 상태(충전 중, 고장, 예약 가능 여부 등)와 1킬로와트당 요금 및 충전기 속도를 확인할 수 있어, 자신에게 맞는 조건의 충전소를 선택할 수 있습니다.

3. 리뷰 남기기: 충전소를 이용한 사용자들이 리뷰를 남겨 다른 사용자들이 카센터 선택에 참고할 수 있도록 도와줍니다. 이 리뷰는 충전 서비스뿐만 아니라 정비 서비스를 평가할 때도 유용한 자료가 됩니다.

4. 네비게이션 안내: 앱에서 충전소를 선택하면 네비게이션 기능을 통해 해당 충전소까지 바로 안내해줍니다. 별도의 다른 플랫폼 없이 앱에서 모든 절차를 한 번에 해결할 수 있습니다.

기대 효과:

1. 지방 전기차 유저를 위한 인프라 구축
   DEPS는 전기차 충전 및 정비 인프라가 부족한 지방에서 지속적으로 인프라를 확충하여, 전기차 사용자들이 보다 편리하게 차량을 관리할 수 있도록 돕습니다.

2. 카센터 시장의 새로운 가치 창출
   카센터는 전기차 충전소 설치를 통해 기존의 고압 전력 인프라를 효율적으로 활용하며, 부가적인 수익을 창출할 수 있습니다. 또한, 전기차 차주들이 충전소를 방문하면서 자연스럽게 정비 서비스에 대한 접근성을 높여, 전기차 정비 숙련도가 향상될 것입니다.

나의 역할: 백엔드 설계 및 개발

본격적인 개발에 돌입하기 앞서, 나는 소프트웨어 설계, API 문서화 단계에서 많은 시간을 투자했다. 해커톤 특성상 시간이 제한되어 있기 때문에, 설계가 탄탄해야 개발 과정에서 발생할 수 있는 문제를 최소화할 수 있다고 생각했다. 여러 명의 팀원이 함께 작업하는 만큼, 명확한 구조와 역할 분담이 필요했다. 특히, 프론트엔드 팀원과의 협업을 원활하게 하기 위해 Swagger와 Notion를 활용하여 API 문서화를 진행했다.

중점을 둔 부분

1. 아키텍처 설계

• 스프링부트 기반의 계층형 아키텍처를 체계적으로 설계했다. API 구조, 데이터베이스 스키마, 그리고 각 기능별 책임을 명확하게 정의하는 데 중점을 두었다. Controller, Service, Repository, Domain로 나누어 각각의 책임을 분리하고, 기능 확장과 유지보수가 용이하도록 설계했다.

2. 데이터 흐름과 동시성 제어

• 충전소 예약 시스템에서 중요한 부분은 동시성 문제를 어떻게 처리할 것인지였다. 여러 사용자가 동시에 예약을 시도할 경우, 중복 예약이 발생하지 않도록 데이터베이스 트랜잭션 관리와 동시성 제어에 대한 설계가 필요했다.
• 이를 위해 스프링의 @Transactional 어노테이션을 사용하여 트랜잭션을 관리하고, 데이터의 일관성을 보장했다. 또한, 트랜잭션 범위 내에서 데이터베이스 작업을 처리해, 서로 다른 요청이 충돌하거나 중복되지 않도록 설계했다. 이를 통해 여러 사용자가 같은 시간대에 동일한 충전소를 예약하려고 할 때 발생할 수 있는 동시성 문제를 방지할 수 있었다.

3. 데이터베이스 스키마 설계

• 충전소 정보, 예약 내역, 사용자 정보가 유기적으로 연동될 수 있도록 데이터베이스 스키마를 설계했다. 이를 위해 UML(Unified Modeling Language) 을 활용하여 ERD(엔터티 관계 다이어그램) 을 작성했고, 각 테이블 간의 관계를 명확히 정의했다. 이를 통해 시스템의 구조를 시각적으로 파악하면서, 데이터 간의 연관성을 명확히 하고, 정규화된 데이터 구조를 적용하여 데이터의 중복을 최소화하고 효율적인 관리가 가능하도록 설계했다.
• 특히, 충전소 상태 업데이트가 실시간으로 반영되도록 예약 내역과 충전소 정보 간의 상호 연동을 구현했다. 예약이 완료되거나 충전소 상태가 변경될 때마다, 예약 테이블과 충전소 정보 테이블 간의 데이터가 일관성 있게 업데이트되도록 애플리케이션 레벨에서 트랜잭션을 활용해 처리했다. 이를 통해 사용자에게 최신 상태의 충전소 정보를 제공할 수 있었다.
• 또한, 충전소 ID나 예약 상태와 같은 주요 필드에 인덱스를 설정해 데이터 검색 속도를 최적화했다. 이를 통해 대량의 데이터에도 신속하게 접근할 수 있는 구조를 마련했다.

4. API 설계

• 프론트엔드와의 원활한 통신을 위해 RESTful API 설계 원칙을 철저히 적용했다. 각 엔드포인트는 리소스 중심적으로 설계되었으며, 명사형으로 일관성 있게 정의하였다. RESTful API 설계 방법론을 따르기 위해, 각 URL 경로는 복수형 명사를 사용하여 리소스를 표현했고, 작업의 종류는 HTTP 메서드(GET, POST, PUT, DELETE)로 명확히 구분했다.

  • 예를 들어, 충전소 정보를 다루기 위해 GET /charging-stations로 충전소 목록을 조회하고, 예약 관리의 경우 POST /reservations로 새로운 예약을 생성하도록 설계했다.

• 이러한 RESTful 방법론을 적용하여 API 설계가 명확하고 직관적이게 되었으며, 프론트엔드 개발자들이 쉽게 API를 이해하고 활용할 수 있도록 했다. 또한, 데이터의 일관성과 성능 최적화를 고려하여 필요한 API만 설계함으로써 불필요한 호출을 최소화했다. 이를 통해 서비스 응답 시간도 빠르게 유지할 수 있었고, 시스템 전반의 효율성을 높일 수 있었다.

• URL 경로의 명명 규칙을 철저히 적용하면서도, 각 엔드포인트가 실제 비즈니스 로직에 맞게 일관성 있게 구성되었기 때문에 API 문서화 작업 또한 원활하게 진행되었다. 특히, Swagger를 사용한 자동 API 문서화를 통해 프론트엔드 개발자가 요청 및 응답 형식을 쉽게 확인하고, 테스트할 수 있도록 했다.

느낀 점

설계의 중요성

• 이러한 설계 과정을 통해, 개발 중간에 발생할 수 있는 구조적인 문제들을 미리 방지하고, 기능을 확장하거나 수정할 때도 큰 어려움 없이 진행할 수 있었다. 특히 해커톤이라는 제한된 시간 안에서, 명확한 설계는 팀원들 간의 원활한 협업을 가능하게 해주었고, 개발 속도를 크게 향상시킬 수 있었다.

• 설계를 통해 코드를 짜는 데 걸리는 시간은 오히려 줄어들었고, 그만큼 더 높은 품질의 결과물을 빠르게 완성할 수 있었다.

인공지능은 대단하다

• 이번 해커톤에서 ChatGPT와 Copilot을 적극적으로 사용하면서, 진짜 좋은 어시스턴트가 생긴 것 같아 너무 좋았다. 특히, 내가 설계한 내용을 빠르게 코드화하는 데 있어 1등 공신은 인공지능이었다. 정말 AI 덕분에 개발 속도가 한층 빨라졌고, 반복 작업도 훨씬 수월해졌다. 땡큐~ㅎ

협업과 팀워크

• 노션은 팀 협업에 필수적인 도구임을 다시 한 번 실감했다. 회의록을 기록하고, 아이디어를 구체화하는 과정에서 팀원들과의 원활한 소통을 위해 너무나 편리했다. 각자 생각을 문서에 정리하고 공유하는 과정이 빠르고 효율적으로 이루어졌고, 실시간으로 수정 가능한 점도 특히 유용했다.

• 해커톤에 앞서 팀이 결성되었고, 대회 전에 꾸준히 회의를 진행하면서 서로의 의견을 공유하고 아이디어를 발전시킬 수 있었다. 덕분에 참신한 아이디어가 많이 나왔고, 해커톤에 돌입하기 전에 이미 아이디어의 방향성을 명확히 설정할 수 있었다. 이 과정이 없었다면 해커톤 당일 더 많은 혼란이 있었을 텐데, 미리 준비한 덕분에 실질적인 개발에 집중할 수 있었다.

규모가 큰 해커톤의 압도적인 현장감

• 많은 해커톤에 참여해왔지만, 이번 해커톤은 엑스코가 꽉 차도록 약 300명 이상의 참가자가 있었고, 그 현장감은 정말 압도적이었다. 그만큼 경쟁심도 생기고, 나도 더 잘하고 싶다는 마음이 강하게 들었다. 다른 참가자들의 열정을 직접 느끼며, 나 또한 한계를 넘어 더 성장하고자 하는 동기부여를 얻었다.

개발에 대한 깊은 고민

• 특히나 효율적인 개발에 대한 고민을 많이 했다. 단순히 기능을 구현하는 것에 그치지 않고, 설계 측면에서 많은 고민을 한 것이 크게 도움이 되었다. 이 덕분에 개발 속도와 효율성이 모두 향상되었고, 프로젝트 전체의 완성도가 높아졌다. 해커톤 특유의 빠른 속도와 설계의 중요성을 다시 한 번 체감하게 된 좋은 기회였다.

무박 3일은 좀 많이 힘들었다..

• 아 근데.. 무박 3일은 진짜 힘들었다. 씻을 공간도 없고, 제대로 쉴 수 있는 장소도 마땅치 않았다. 휴식을 위한 공간은 있긴 했지만, 그저 빈백 몇 개가 놓인 간이 부스 같은 곳이어서 편히 쉬기엔 턱없이 부족했다. 그래도 나는 근처 헬스장에서 운동도 하고 목욕도 하고 오니 기분이 한결 나아졌다. 진짜 죽을 것 같은 피곤한 컨디션이었는데, 그렇게라도 리프레시가 되니까 ‘아, 이게 되네?’ 싶더라...ㅋㅋ

• 당시 나는 매일 아침 9시부터 11시까지 아르바이트를 하고 있었다. 다행히 근무지가 버스로 20분 거리라 팀원들에게 양해를 구하고 다녀올 수 있었지만, 남들이 다 자고 쉬는 시간에 나는 출근해서 일하고 오니 현타가 오더라. 그래도 해커톤 끝까지 참여하고, 그 와중에 아르바이트도 해낸 나 자신이 대견하다!

기여한 점

1. 철저한 설계를 통한 명확한 개발 방향 제시

• 이번 프로젝트에서 나는 철저한 설계에 집중했다. 처음부터 시스템의 아키텍처와 데이터베이스 구조를 명확하게 설계하면서, 팀원들에게 개발 방향을 구체적으로 제시할 수 있었다.
• 충전소와 예약 시스템의 상호작용에서 발생할 수 있는 동시성 문제와 연관관계를 미리 고려해 설계를 완료한 덕분에, 개발 중간에 발생할 수 있었던 구조적인 오류를 사전에 방지할 수 있었다.
• 설계가 탄탄했기 때문에 팀원들이 개발에만 집중할 수 있었고, 덕분에 빠른 속도로 작업을 진행할 수 있었다. 이 과정에서 미리 설계한 데이터 흐름을 기반으로, 서로 역할을 나누고 더 효율적으로 협력할 수 있었다.

2. 아이디어 피칭 및 IR 흐름 구체화

• 나는 예비창업팀을 이끌면서 여러 차례 IR 피칭을 해본 경험이 있다. 그래서 이번 해커톤에서도 아이디어를 체계적으로 전달하는 데 내가 많이 기여했다. 특히, 우리의 솔루션을 설명할 때 PSST 흐름(문제점, 해결책, 강점, 성과)을 기반으로 피칭 구조를 짰다.
• 피칭을 준비하면서, 팀원들이 제안하는 아이디어를 구체화하고 논리적으로 정리하였다. 특히, 전기차 충전소 부족 문제를 단순한 기술적 이슈가 아니라, 지방 카센터와의 협력이라는 실질적인 해결책으로 풀어나가는 아이디어를 중점적으로 구체화했다. 덕분에 발표할 때, 심사위원들에게 더 설득력 있게 전달할 수 있었다.

3. 커뮤니케이션 및 문제 해결

• 이번 프로젝트에서 나는 커뮤니케이션에 특히 신경을 많이 썼다. 해커톤 특성상 시간이 촉박한 상황에서 팀 내에서 의견이 충돌하거나 기술적인 이슈가 발생하면 빠르게 해결하지 않으면 전체 일정이 지연될 수 있었다.
• 특히 백엔드 개발 도중 배포 과정에서 문제가 발생했을 때, 나는 팀원들과 빠르게 의견을 교환하고 현장에 있던 기술 자문단과 소통해 해결책을 찾았다. 배포 환경 설정에 대한 이슈가 있었는데, 나는 상황을 구체적으로 설명하며 자문을 구하고, 그 피드백을 바탕으로 빠르게 문제를 해결할 수 있었다.

성장과 배운 점

솔직히 말하자면, 대부분의 사람들이 AWS를 사용하니까 나도 자연스럽게 따라 사용했지만, 정확한 흐름을 이해하지 못한 채 무지성으로 이용한 적이 많았다. 하지만 이번 프로젝트에서 Microsoft Azure를 직접 사용해보고, 실제로 적용해보면서 배포와 관련된 많은 것들을 배울 수 있었다.

이번 해커톤에서 배포 담당 팀원이 이 부분을 주도적으로 진행했기 때문에 내가 기여한 부분은 적었지만, 옆에서 함께 작업하면서 정말 많은 것을 배웠다. 특히, Azure에서 제공하는 다양한 서비스들을 접하면서 자동화 배포의 중요성과 그 효율성을 몸소 느꼈다.

사용한 기능들

• Azure App Service: 기존에는 백엔드 서버를 운영하기 위해 직접 환경을 구축해야 했지만, PaaS(Platform as a Service)인 Azure App Service 덕분에 서버 환경을 따로 설정하지 않고, 개발에만 집중할 수 있었다.

• Visual Studio App Center: 우리가 React Native로 제작한 애플리케이션을 iOS와 Android로 빌드하는 데 사용했다. 앱 배포를 쉽게 관리할 수 있었던 점이 큰 도움이 됐다.

• Azure Database for MySQL: DB 구축 시 예상되는 부하 문제나 환경 설정 등에 대한 우려 없이, 완전 관리형인 Azure Database for MySQL을 통해 즉시 DB를 활용할 수 있었다.

• Github Actions: 작업한 코드를 Github에 올리기만 해도 자동으로 서버에 배포되는 구조를 구현할 수 있었다. 덕분에 수작업으로 배포하던 과정을 완전히 자동화할 수 있었고, 배포 프로세스가 매우 간편해졌다.

• Bicep: Azure에서 클릭과 타이핑으로 진행하던 작업을 Bicep 스크립트 파일 하나로 실행해 빠르게 배포할 수 있었다. 이를 통해 인프라 배포의 자동화도 가능하다는 점을 배웠다.

성장한 부분

이 경험을 통해 단순히 Azure 사용법만 배운 게 아니라, 자동화 배포의 중요성을 깨닫게 되었다. 이전에는 수작업으로 설정하고 배포하는 방식이 익숙했지만, 자동화된 CI/CD 파이프라인을 구축하면서 효율성을 크게 향상시킬 수 있었다. 덕분에, 이후 다른 프로젝트에서는 내가 주도적으로 Github Actions를 활용해 직접 CI/CD 파이프라인을 구축하고, AWS 배포도 진행할 수 있게 되었다.

이번 경험은 나에게 배포 과정의 효율성과 자동화가 얼마나 중요한지를 깨닫게 해줬다. 특히, 이를 통해 내가 앞으로 더 효율적으로 프로젝트를 관리하고, 빠르게 배포하는 능력을 기를 수 있었다는 점에서 큰 성장을 이뤘다고 느낀다.

소감

다시 보니까 꼬질꼬질... 진짜 수고했다..

대상 !!!

죽어라 달린 만큼 좋은 성과를 거둘 수 있어서 너무 기쁘다. 수상 호명이 계속 안 들리길래, 솔직히 마음을 내려놓고 있었는데, 팀원들에게 "그래도 OOO님이랑 같은 팀을 해서 정말 너무 좋았어요. 너무 수고하셨어요 정말. ^^ 결과에 연연하지 않고 정말 소중한 인연을 만들어 가네요~^^" 이러고 있었다. 근데 그러면서도 속으로는 혹시나! 하는 마음에 내심 기대하고 있었다.

무엇보다도 우리 팀 모두가 너무 고생했고, 정말 열심히 노력했다는 걸 알기에, 마음속으로는 "제발 대상 ㅠㅠㅠㅠ 으허헝ㅇ 제발 ㅠㅠ" 이러고 있었다.
그리고 대상이 호명되는 순간, 믿기지 않아서 멍하니 있다가 우리 팀 이름이 맞다는 걸 확인하고서야 정신이 번쩍 들었다. 다들 서로 고생했다며 얼싸안고 기쁨을 나누던 그 순간이 정말 잊을 수 없었다. 무박 3일 동안의 고생한 보람이 있었다... 정말... 이건 해커톤을 가장한 나와의 싸움이었다. 수면욕, 식욕 다 참아가면서 해야 할 일을 해냈다는 게 진짜 인생에 도움이 될 것 같은 경험이었다. 극한을 경험해보면 다른 일은 더 쉽게 느껴진다는데...ㅎ

해커톤 내내 우리가 얼마나 열심히 준비했고, 서로에게 얼마나 의지하며 달려왔는지 생각하니 더 뭉클했다. 사실 결과에 상관없이 함께 만들어간 과정이 너무 소중했지만, 이렇게 최고의 결과로 마무리할 수 있어서 의미가 더 컸다. 혼자서는 절대 할 수 없는 일이었고, 팀워크가 정말 중요했다. 우리 팀이 각자의 역할을 충실히 해줬기 때문에 이 상을 받을 수 있었다고 생각한다. (나는 특히나 Chocolate Provider로 톡톡히 기여했다는 점! ^^ㅎ)

솔직히 이번 해커톤을 통해 극한의 정신력을 경험하면서, 개인적으로 부족한 부분도 많이 느꼈고, 그걸 스스로 이겨냈다는 사실이 대견했다. 또 팀원들에게서 배운 것도 많았다. 특히 배포 과정에서 내가 부족하다는 걸 깨달았고, 덕분에 더 성장할 수 있는 계기가 되었다. 팀원들과 서로 도와가며 최선을 다한 경험이 이번 해커톤의 가장 큰 수확이었다.

다시 한 번 팀원들 모두에게 감사하고, 끝까지 최선을 다해준 덕분에 이런 좋은 결과를 얻었다는 말을 전하고 싶다. 그리고 좋은 인연을 만들어준 이번 해커톤이, 앞으로도 우리 모두에게 좋은 기억으로 남을 것 같다.

수상을 할 때 만난 양금희 의원님과 김현덕 단장님! 대구 청년체험단을 하면서 개인적으로도 자주 뵈었었는데, 이렇게 또 청년체험단으로서 성과를 낸 것 같아 더욱 뿌듯했다. 하하하.

잘했다! 수고했다! 기특하다!

기술 스택:

1. Backend

• Spring Boot: 백엔드 프레임워크로 사용하여 RESTful API 설계 및 비즈니스 로직을 구현.
• MySQL: 프로젝트의 데이터베이스로 사용. Azure Database for MySQL을 활용해 데이터 관리와 쿼리 최적화를 진행.
• JPA/Hibernate: 데이터베이스와의 상호작용을 쉽게 하기 위해 JPA와 Hibernate를 사용하여 객체 관계 매핑(ORM)을 구현.
• Microsoft Azure: 프로젝트 배포 및 데이터베이스 호스팅.

2. DevOps / CI/CD

• Github Actions: CI/CD 파이프라인을 구축하여, 코드가 푸시될 때마다 자동으로 테스트를 실행하고 Azure에 배포 자동화. 배포의 효율성을 크게 향상시킴.
• Azure App Service: 백엔드 애플리케이션을 호스팅하기 위함. 기존의 복잡한 서버 설정을 생략하고, 쉽게 애플리케이션을 배포할 수 있었음.
• Bicep: Azure 리소스 배포를 위한 인프라 자동화 도구로 사용. 이를 통해 반복적인 작업을 자동화하고 배포 속도를 높임.
• Visual Studio App Center: React Native로 개발된 애플리케이션을 iOS와 Android로 빌드하고, 배포 과정을 관리함.

3. Version Control

• Git: 팀 협업을 위해 Git을 사용해 코드 관리.
• Github: 프로젝트의 관리를 위해 Github를 사용했으며, 대회의 전반적인 진행이 깃허브를 사용함.

4. AI/Code Assistance

• GitHub Copilot: 인공지능 기반 코드 보조 도구로, 개발 과정에서 자동으로 코드 제안을 받을 수 있었음.특히 반복적인 코딩 작업이나 문법 오류를 줄이는 데 큰 도움이 되었고, 코드 작성 속도를 크게 높임.

1. 내가 진정으로 원하는 것을 확립하기

인사이트:

• 내가 원하는 것은 개발자로서의 커리어를 통해 매니저로 성장하고, 궁극적으로 나만의 프로덕트를 내놓는 것이다.
• 외국계 대기업 한국 지사에서 개발자로 다양한 경험을 쌓는 것고 싶다. -> 좋은 생각이다 !
• 외국계 대기업에서의 경험은 글로벌한 관점에서 성장할 기회를 줄 수 있지만, 스타트업에서는 창업적인 경험과 함께 빠른 성장을 경험할 수 있다.

적용 방안:

• 목표 설정: 먼저 내가 더 원하는 것이 무엇인지 명확히 해야 한다. 이를 위해 개발자로서의 경험과 창업 경험이 주는 장단점을 비교해 보자.
• 행동 계획: 구글 코리아와 같은 외국계 대기업을 목표로 취업 준비를 하되, 스타트업 경험도 함께 탐색할 수 있는 네트워킹을 지속적으로 하자.
• 주기적인 점검: 매월 자신이 원하는 커리어 방향이 잘 설정되고 있는지 점검하고, 필요시 새로운 정보를 수집하여 방향성을 재조정한다.

2. 인생은 길다, 조급해하지 말자

인사이트:

• 지금은 취업에 대한 압박감이 크지만, 인생의 첫 직장이 내 커리어를 결정짓는 것은 아니다.
• 인생의 성공과 실패는 취업에서만 오는 것이 아니며, 오히려 장기적인 목표와 방향성이 더 중요하다.
• 지금 당장 미국 진출이나 대학원 진학이 어려울 수 있지만, 그것이 끝이 아니며 여전히 많은 기회가 있을 것이다.

적용 방안:

• 마인드셋 전환: 현재의 상황에 대한 압박감을 줄이고, 장기적인 시각에서 자신의 커리어를 바라보자.
• 단계적 목표 설정: 현재의 목표를 달성한 후, 그다음 단계에 대한 계획을 세우자. 예를 들어, 대기업 입사 후 3~5년 후에는 어떤 경험을 더 쌓고 싶은지 구체적으로 계획해본다.
• 자기 관리: 성공 강박에서 벗어나기 위해 명상, 운동 등 스트레스 관리 방법을 통해 정신적, 신체적 건강을 유지한다.

3. 한 가지에 집중하기

인사이트:

• 다양한 관심사와 분야에 대한 욕심이 크지만, 현재는 개발자로서의 커리어에 집중해야 한다.
• 비개발 분야의 공부와 경험은 중요하지만, 동시에 여러 가지를 시도하다 보면 하나도 제대로 해내지 못할 위험이 있다.
• 인생은 길고, 한 번에 모든 것을 이루려고 하기보다는 차근차근 이루어 나가는 것이 더 중요하다.

적용 방안:

• 우선순위 설정: 현재는 개발자로서의 성장에 집중하고, 일정 목표에 도달한 후 비개발 분야에 도전하자.
• 시간 관리: 매일 개발 관련 학습 시간을 일정하게 확보하고, 비개발 분야는 취미나 여가 시간에 즐기며 점차적으로 익혀 나가자.
• 성장 일지: 개발자로서 성장하고 있는 과정을 기록하고, 그동안의 성취와 앞으로의 목표를 주기적으로 검토한다.

4. 자기 사랑하기

인사이트:

• 현재 느끼는 조급함, 열등감, 그리고 성공에 대한 강박은 결국 자신을 충분히 사랑하지 못해서 오는 감정이다.
• 자신을 사랑하지 못하면, 다른 사람들이 나를 평가하는 시선에 더욱 민감해지고, 그것이 결국 나의 자존감에 부정적인 영향을 미친다.

적용 방안:

• 자기 인식 훈련: 매일 아침 거울을 보며 자신에게 긍정적인 말을 건네고, 스스로를 인정하는 연습을 하자.
• 자기 보상: 작은 성취에도 자신을 칭찬하고 보상하는 습관을 들여 긍정적인 자기 평가를 강화한다.
• 감정 일기: 하루 동안 느꼈던 감정들을 기록하고, 스스로에 대한 부정적인 생각이 들 때마다 그것을 긍정적으로 바꾸는 연습을 하자.

5. 일단 부딪히며 성장하기

인사이트:

• 실제로 일을 하면서 배우는 것이 가장 크다. 두려워하지 말고 다양한 경험을 통해 성장할 기회를 만들자.
• 이론적으로 준비하는 것보다 실전에서 부딪히며 배우는 것이 더 효과적이고, 성장 속도도 빠르다.

적용 방안:

• 도전 정신: 새로운 프로젝트나 어려운 과제에 적극적으로 참여하여, 실전에서 경험을 쌓는다.
• 실패 수용: 실패를 두려워하지 말고, 실패를 통해 배운 교훈을 기록하여 다음에 더 나은 결과를 만들 수 있도록 한다.
• 네트워킹: 다양한 분야의 사람들과 네트워킹을 통해 새로운 기회를 탐색하고, 자신이 할 수 있는 다양한 역할을 모색해본다.

조급해하지 말기

이번 포스팅에서는 백준 14500번 문제인 "테트로미노" 문제를 해결하는 과정을 정리하겠습니다. 이 문제는 4가지 종류의 테트로미노 모양을 2차원 배열에서 최적의 위치에 배치하여 얻을 수 있는 최대 합을 구하는 문제입니다.

문제 분석

문제는 주어진 2차원 배열에 다양한 테트로미노 모양을 놓았을 때, 합이 최대가 되는 경우를 찾는 것입니다. 테트로미노는 다양한 모양을 가지고 있으며, 이 문제에서는 총 5가지의 모양이 주어집니다.

테트로미노 모양 분석

1. 1자형 (I 모양)
2. 정사각형 (O 모양)
3. ㄴ자형 (L, J 모양)
4. ㄹ자형 (Z, S 모양)
5. ㅗ자형 (T 모양)

각 테트로미노는 회전이나 대칭을 통해 다양한 배치를 가질 수 있습니다. 모든 가능한 배치를 고려하여 최대 합을 구하는 것이 목표입니다.

해결 전략

문제를 해결하기 위해 각 테트로미노 모양에 대해 배열의 모든 위치에서 놓아보고 그 합을 계산한 후, 최대값을 구합니다. 이를 위해 각 테트로미노의 형태를 함수로 나누어 처리했습니다.

코드 구현

문제를 해결하기 위한 코드는 아래와 같습니다.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class P14500 {

    // ㅗ, ㅜ, ㅓ, ㅏ 모양 테트로미노 처리
    private static int S345(int[][] table, int n, int m) {
        int sum = 0;

        for (int i = 0; i < n - 1; i++) {
            for (int j = 0; j < m - 2; j++) {
                sum = Math.max(sum, table[i][j] + table[i][j+1] + table[i][j+2] + table[i+1][j]);
                sum = Math.max(sum, table[i][j] + table[i][j+1] + table[i][j+2] + table[i+1][j+1]);
                sum = Math.max(sum, table[i][j] + table[i][j+1] + table[i][j+2] + table[i+1][j+2]);

                sum = Math.max(sum, table[i+1][j] + table[i+1][j+1] + table[i+1][j+2] + table[i][j]);
                sum = Math.max(sum, table[i+1][j] + table[i+1][j+1] + table[i+1][j+2] + table[i][j+1]);
                sum = Math.max(sum, table[i+1][j] + table[i+1][j+1] + table[i+1][j+2] + table[i][j+2]);

                sum = Math.max(sum, table[i][j] + table[i][j+1] + table[i+1][j+1] + table[i+1][j+2]);
                sum = Math.max(sum, table[i][j+1] + table[i][j+2] + table[i+1][j] + table[i+1][j+1]);
            }
        }

        for (int i = 0; i < n - 2; i++) {
            for (int j = 0; j < m - 1; j++) {
                sum = Math.max(sum, table[i][j] + table[i+1][j] + table[i+2][j] + table[i][j+1]);
                sum = Math.max(sum, table[i][j] + table[i+1][j] + table[i+2][j] + table[i+1][j+1]);
                sum = Math.max(sum, table[i][j] + table[i+1][j] + table[i+2][j] + table[i+2][j+1]);

                sum = Math.max(sum, table[i][j] + table[i][j+1] + table[i+1][j+1] + table[i+2][j+1]);
                sum = Math.max(sum, table[i+1][j] + table[i][j+1] + table[i+1][j+1] + table[i+2][j+1]);
                sum = Math.max(sum, table[i+2][j] + table[i][j+1] + table[i+1][j+1] + table[i+2][j+1]);

                sum = Math.max(sum, table[i][j] + table[i+1][j] + table[i+1][j+1] + table[i+2][j+1]);
                sum = Math.max(sum, table[i+1][j] + table[i+2][j] + table[i][j+1] + table[i+1][j+1]);
            }
        }

        return sum;
    }

    // 정사각형 모양 테트로미노 처리
    private static int S2(int[][] table, int n, int m) {
        int sum = 0;

        for (int i = 0; i < n - 1; i++) {
            for (int j = 0; j < m - 1; j++) {
                sum = Math.max(sum, table[i][j] + table[i][j+1] + table[i+1][j] + table[i+1][j+1]);
            }
        }

        return sum;
    }

    // I 모양 테트로미노 처리
    private static int S1(int[][] table, int n, int m) {
        int sum = 0;

        for (int i = 0; i < n; i++) {
            for (int j = 0; j < m - 3; j++) {
                sum = Math.max(sum, table[i][j] + table[i][j+1] + table[i][j+2] + table[i][j+3]);
            }
        }

        for (int i = 0; i < n - 3; i++) {
            for (int j = 0; j < m; j++) {
                sum = Math.max(sum, table[i][j] + table[i+1][j] + table[i+2][j] + table[i+3][j]);
            }
        }

        return sum;
    }

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        String[] l0 = br.readLine().split(" "); 
        int n = Integer.parseInt(l0[0]);
        int m = Integer.parseInt(l0[1]);

        int[][] table = new int[n][m];

        for (int i = 0; i < n; i++) {
            l0 = br.readLine().split(" ");
            for (int j = 0; j < m; j++) {
                table[i][j] = Integer.parseInt(l0[j]);
            }
        }

        int result = S1(table, n, m);

        int count = S2(table, n, m);
        result = Math.max(result, count);

        count = S345(table, n, m);
        result = Math.max(result, count);

        System.out.println(result);
    }
}

코드 설명

1. 함수별 테트로미노 모양 처리:

   • S1 함수는 I 모양 테트로미노의 최대 합을 계산합니다. 배열 내에서 가로 또는 세로로 연속된 4개의 칸을 합산합니다.
   • S2 함수는 정사각형 모양의 테트로미노 합을 계산합니다. 배열 내에서 2x2 영역의 합을 구합니다.
   • S345 함수는 ㄴ자형, ㄹ자형, ㅗ자형 모양의 테트로미노에 대해 가능한 모든 배치를 계산합니다.

2. 최대값 계산:

   • 각 함수에서 계산된 최대 합을 비교하여 최종 결과를 도출합니다.

사고 흐름 정리

1. 문제 분석: 주어진 배열에서 테트로미노를 놓아 최대 합을 구하기 위해 가능한 모든 배치를 탐색해야 합니다.

2. 테트로미노 모양 별 함수 분리: 각 테트로미노 모양에 대해 별도의 함수를 작성하여 코드의 가독성을 높이고, 최대값을 효율적으로 계산할 수 있도록 했습니다.

3. 최대값 비교: 각각의 함수에서 구한 값 중에서 가장 큰 값을 최종 결과로 출력합니다.

마무리

이번 문제는 다양한 테트로미노 모양을 고려해야 하는 복잡한 문제였지만, 각 모양을 함수로 분리하여 효율적으로 해결할 수 있었습니다. 테트로미노 모양을 분석하고, 모든 가능한 배치를 탐색하는 과정이 중요한 문제였습니다. 이번 포스팅을 통해 문제 해결 방법을 이해하는 데 도움이 되었기를!

이번 포스팅에서는 백준 1107번 문제인 "리모컨" 문제를 해결하는 과정을 정리하겠습니다. 이 문제는 고장난 버튼이 있는 리모컨을 사용해 특정 채널로 이동할 때 최소한의 버튼 클릭 횟수를 계산하는 문제입니다.

문제 분석

문제는 고장난 버튼이 있을 때, 주어진 채널로 이동하기 위해 가장 적은 횟수로 버튼을 눌러야 하는 상황을 제시합니다. 리모컨에는 0부터 9까지의 숫자 버튼과 채널을 올리고 내릴 수 있는 +, - 버튼이 있습니다.

해결 전략

문제를 해결하기 위해 몇 가지 접근 방식을 고려했습니다:

1. +, - 버튼만 사용하는 경우:

   • 현재 채널(기본 채널 100)에서 목표 채널까지 +, - 버튼만을 이용해 이동하는 방법입니다.

2. 숫자 버튼을 사용한 접근:

   • 고장나지 않은 숫자 버튼을 이용해 최대한 목표 채널에 가까운 채널을 입력하고, 남은 차이를 +, - 버튼으로 이동하는 방법입니다.

3. 상향 및 하향 접근:

   • 목표 채널에서 위쪽과 아래쪽으로 가능한 채널을 탐색하며, 고장난 버튼을 피해서 가장 가까운 채널을 찾습니다.

코드 구현

문제를 해결하기 위한 코드는 아래와 같습니다.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class P1107 {
    private static boolean checkNumber(int number, int[] brokenNumber) {
        String numStr = Integer.toString(number);

        for (int i = 0; i < numStr.length(); i++) {
            for (int j = 0; j < brokenNumber.length; j++) {
                if (Character.getNumericValue(numStr.charAt(i)) == brokenNumber[j]) {
                    return false;
                }
            }
        }
        return true;
    }

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        String num = br.readLine();
        int numLength = num.length();
        int[] number = new int[numLength];

        for (int i = 0; i < numLength; i++) {
            number[i] = Character.getNumericValue(num.charAt(i));
        }

        int n = Integer.parseInt(br.readLine());
        int[] brokeNumber = new int[n];
        int sum = 0;
        if (n != 0) {
            String[] line = br.readLine().split(" "); 
            for (int i = 0; i < n; i++) {
                brokeNumber[i] = Integer.parseInt(line[i]);
                sum += brokeNumber[i];
            }
        }

        int count = Math.abs(Integer.parseInt(num) - 100); 

        int countUpper = n == 10 ? 500000 : 0;
        int numUp = Integer.parseInt(num);
        boolean pressOther = true;

        if (n == 9 && sum == 45) {
            pressOther = false;
            countUpper = 500000;
        }

        if (n != 10 && pressOther) {
            while (numUp >= 0) {
                if (checkNumber(numUp, brokeNumber)) {
                    countUpper += Integer.toString(numUp).length();
                    break;
                }
                countUpper++;
                numUp++;
            }
        }

        int countDown1 = n == 10 ? 500000 : 0;
        int countDown2 = 0;
        int numDown = Integer.parseInt(num);

        if (n != 10) {
            if (numDown == 0) {
                countDown1 = 500000;
            }

            while (numDown >= 0) {
                if (checkNumber(numDown, brokeNumber)) {
                    countDown1 = Integer.toString(numDown).length();
                    break;
                } else {
                    countDown1 = 500000;
                }
                countDown2++;
                numDown--;
            }
        }
        countDown2 += countDown1;

        count = Math.min(count, countUpper);
        count = Math.min(count, countDown2);

        System.out.println(count);
    }
}

코드 설명

1. 고장난 버튼 체크:

   • checkNumber 함수는 주어진 숫자에서 고장난 버튼이 포함되어 있는지 확인합니다. 포함되어 있으면 false, 아니면 true를 반환합니다.

2. +, - 버튼만 사용하는 경우:

   • 현재 채널 100에서 목표 채널까지의 거리(버튼 클릭 횟수)를 계산합니다. 이 값은 Math.abs(Integer.parseInt(num) - 100)로 구할 수 있습니다.

3. 숫자 버튼을 이용한 상향 탐색:

   • 목표 채널보다 큰 채널 중 고장난 버튼이 없는 첫 번째 채널을 찾아 이동 횟수를 계산합니다. 만약 고장난 버튼이 전부이면 무한대(500000)로 설정합니다.

4. 숫자 버튼을 이용한 하향 탐색:

   • 목표 채널보다 작은 채널 중 고장난 버튼이 없는 첫 번째 채널을 찾아 이동 횟수를 계산합니다. 마찬가지로 고장난 버튼이 전부이면 무한대로 설정합니다.

5. 최소 이동 횟수 계산:

   • 각 접근 방법에서 얻은 이동 횟수 중 가장 작은 값을 선택하여 출력합니다.

사고 흐름 정리

1. 문제 분석: 고장난 버튼이 있는 경우 어떻게 목표 채널로 이동할 수 있을지 고민합니다. 가능한 모든 이동 방법을 탐색해 최소 이동 횟수를 찾아야 합니다.

2. 조건 처리: 고장난 버튼이 전부일 경우나, 숫자 버튼을 사용할 수 없을 경우에 대한 예외 처리를 고려합니다.

3. 탐색: 목표 채널을 중심으로 상향 및 하향 탐색을 통해 가능한 채널을 찾습니다. 이때, 고장난 버튼이 없을 때만 해당 채널로 이동합니다.

4. 최적화: +, - 버튼만을 사용한 경우와 숫자 버튼을 사용한 경우 중 최소 이동 횟수를 선택합니다.

마무리

이 문제는 주어진 조건을 바탕으로 모든 가능성을 탐색해야 하는 전형적인 완전 탐색 문제입니다. 고장난 버튼을 고려해 예외 상황을 처리하고, 다양한 접근 방식을 통해 최적의 해결책을 찾는 과정이 중요합니다. 코드를 통해 문제 해결 방법을 이해하는 데 도움이 되었기를 바랍니다. 다음에도 더 흥미로운 문제로 찾아오겠습니다!

이번 포스팅에서는 백준 1476번 문제인 "날짜 계산" 문제를 해결하는 과정을 정리하겠습니다. 이 문제는 주어진 세 가지 수 E, S, M에 대해 특정 규칙을 만족하는 연도를 찾는 문제입니다.

문제 이해

문제는 아래와 같은 세 가지 수를 기준으로 특정한 연도를 찾아야 합니다:

• E는 지구를 나타내며, 1부터 15까지의 값을 가질 수 있습니다.
• S는 태양을 나타내며, 1부터 28까지의 값을 가질 수 있습니다.
• M은 달을 나타내며, 1부터 19까지의 값을 가질 수 있습니다.

우리는 특정한 연도 year를 찾으려고 합니다. 이 연도는 아래의 조건을 모두 만족해야 합니다:

• year % 15 == E
• year % 28 == S
• year % 19 == M

코드 구현

문제를 해결하기 위한 코드를 구현했습니다. 아래는 코드와 설명입니다.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class P1476 {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        String[] line = br.readLine().split(" "); // 입력 받기

        int earth = Integer.parseInt(line[0]) % 15;
        int sun = Integer.parseInt(line[1]) % 28;
        int moon = Integer.parseInt(line[2]) % 19;

        int result = 0;

        // 1부터 시작하여 조건을 만족하는 연도를 찾을 때까지 반복
        for(int i = 1; ; i++){
            if( (i % 15 == earth) && (i % 28 == sun) && (i % 19 == moon)){
                result = i;
                break;
            }
        }
        System.out.println(result);
    }
}

코드 설명

1. 입력 처리:

   • BufferedReader를 사용해 한 줄로 입력된 값을 받아오고, 이를 공백 기준으로 분리하여 earth, sun, moon 변수에 저장합니다.
   • 입력된 earth, sun, moon 값을 각각 15, 28, 19로 나눈 나머지를 구해 저장합니다. 이는 문제에서 주어진 연도의 범위를 고려한 것입니다.

2. 연도 찾기:

   • 무한 루프를 사용하여 1부터 시작하는 모든 i 값에 대해 조건을 확인합니다.
   • 조건이 만족되면, 그 i 값을 result 변수에 저장하고 루프를 종료합니다.

3. 결과 출력:

   • 최종적으로 조건을 만족하는 result 값을 출력합니다.

문제 해결의 사고 흐름

이 문제를 해결하기 위한 기본적인 사고 흐름은 다음과 같습니다:

1. 문제 분석: 문제에서 주어진 세 가지 조건을 만족하는 연도를 찾아야 한다는 점을 파악합니다.
2. 나머지 연산 활용: 각 연도 year에 대해 E, S, M이 각각 1부터 시작하므로, 입력값을 각각 15, 28, 19로 나눈 나머지를 비교하는 방식을 선택합니다.
3. 반복문 구현: 모든 가능한 연도를 탐색하는 반복문을 통해 조건을 만족하는 연도를 찾습니다.
4. 결과 출력: 조건을 만족하는 첫 번째 연도를 출력합니다.

이렇게 함으로써 백준 1476번 문제를 해결할 수 있었습니다.

마무리

이 문제는 나머지 연산과 반복문을 잘 이해하고 활용하는 것이 핵심입니다. 무한 루프를 사용하여 특정 조건을 만족할 때까지 반복하며, 범위를 적절히 설정해 효율적인 문제 해결 방법을 도출하는 것이 중요합니다.

코드와 설명이 도움이 되었기를 바랍니다. 다음에도 더 흥미로운 문제로 찾아오겠습니다!

이번 포스팅에서는 백준 2309번 문제인 "일곱 난쟁이"를 자바로 해결한 방법을 공유하고자 합니다. 문제 해결을 위해 사용된 알고리즘과 코드의 흐름을 차근차근 설명하겠습니다.

문제 개요

이 문제는 총 9명의 난쟁이 중에서 7명의 키의 합이 100이 되도록 하는 난쟁이들을 찾아내는 문제입니다. 이를 위해 우리는 9명의 난쟁이 키에서 임의의 2명을 제외한 7명의 키를 선택하여 그 합이 100이 되는 경우를 찾아야 합니다.

문제 풀이 접근 방식

1. 입력 데이터 처리 및 총합 계산:

   • 먼저 9명의 난쟁이 키를 입력받고, 이들의 키의 총합을 구합니다.

2. 제거할 두 난쟁이 찾기:

   • 두 명의 난쟁이를 제외한 7명의 키 합이 100이 되려면, 두 명의 키 합은 총합 - 100이 되어야 합니다.
   • 이 조건을 만족하는 두 명의 난쟁이를 찾고, 이들의 위치를 배열에서 마지막 두 위치로 이동시킵니다. 이로써 제거할 난쟁이들을 쉽게 처리할 수 있습니다.

3. 제거하지 않은 7명의 난쟁이 키 정렬:

   • 선택된 7명의 난쟁이 키를 오름차순으로 정렬합니다.

4. 결과 출력:

   • 정렬된 7명의 난쟁이 키를 출력합니다.

코드 설명

아래는 해당 문제를 해결하기 위한 Java 코드를 작성한 것입니다.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class P2309 {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int[] heights = new int[9];
        int sum = 0;

        // 9명의 난쟁이 키를 입력받고 합을 계산
        for(int i = 0; i < 9; i++){
            heights[i] = Integer.parseInt(br.readLine());
            sum += heights[i];
        }

        int temp = 0;

        // 합이 sum - 100이 되는 두 난쟁이를 찾아서 배열의 마지막 두 위치로 이동
        for(int i = 0; i < 8; i++){
            for(int j = i+1; j < 9; j++){
                if(heights[i]+heights[j] == sum - 100){
                    // 첫 번째 난쟁이 이동
                    temp = heights[i];
                    heights[i] = heights[7];
                    heights[7] = temp;

                    // 두 번째 난쟁이 이동
                    temp = heights[j];
                    heights[j] = heights[8];
                    heights[8] = temp;
                }
            }
        }

        // 남은 7명의 난쟁이 키를 오름차순 정렬
        for(int i = 0; i<6; i++){
            for(int j = i+1; j<7; j++){
                if(heights[i] > heights[j]){
                    temp = heights[i];
                    heights[i] = heights[j];
                    heights[j] = temp;
                }
            }
        }

        // 결과 출력
        for(int i = 0; i < 7; i++){
            System.out.println(heights[i]);
        }
    }
}

핵심 아이디어

• 탐색 범위 줄이기: 모든 경우의 수를 살펴보는 방법은 비효율적이기 때문에, 두 명의 난쟁이의 키 합이 sum - 100이 되는지를 조건으로 삼아 탐색 범위를 줄였습니다.
• 간단한 정렬 사용: 정렬 알고리즘 중에서 자주 사용하는 버블 정렬을 사용하여 7명의 키를 오름차순으로 정렬했습니다. 물론 효율성 측면에서는 더 빠른 정렬 알고리즘을 사용하는 것이 좋겠지만, 작은 데이터셋에서는 간단한 방법이 더 직관적일 수 있습니다.

결론

이 문제는 브루트포스(완전 탐색) 기법을 활용하여 해결할 수 있습니다. 가능한 모든 경우를 조사해도 문제의 제약 조건 내에서는 충분히 빠르게 답을 구할 수 있습니다. 이러한 접근 방식은 작은 데이터셋에서 유용하며, 문제의 조건을 만족하는지 여부를 정확하게 판단하는 데 도움을 줍니다.

이 게시물이 백준 2309번 문제를 푸는 데 도움이 되기를 바랍니다! 댓글이나 질문은 언제든 환영입니다. Happy Coding! 😊