본문 바로가기
SK네트웍스 AI 25기

SK네트웍스 Family AI 캠프 25기 | 15주차 회고 및 3차 프로젝트 후기

by 욘됴리 2026. 4. 14.

 

주말을 껴서 3차 프로젝트를 진행했다.

팀장이 되었다 ㅎ_ㅎ

다들 빅분기 시험을 보느라 바빴던 주간이라 도커 세팅을 맡았다. 사실 내가 해보고싶어서 자진했다 ㅎㅎ

왜냐면 전에 도커를 써보긴 했으나 아예 0부터 세팅해보질 않아서 도커 사용 경험이 있다고 말하기가 애매했기 때문에 ...!

근데 인프라 세팅은 하면 할수록 더 많이 공부하고 더 많이 경험해봐야 나 인프라 좀 할 줄 안다고 꺼드럭댈 수 있을 것 같다.

알다가도 모르겠는 도커의 세계...

docker-compose.yml 파일로 같은 환경을 세팅하도록 했는데, 도커 버전에 따라 docker-compose 또는 docker compose로 명령어가 달랐다. 알고보니 내 도커 버전이 구버전(V1)이었는데 팀원들이 알아서 잘 해결해서 세팅했다 🥹

미안하고도 고마운 팀원들이여 ,,, 다음 4차 플젝도 잘 부탁합니다.

 

자세한 3차 프로젝트 내용은 >>깃허브 링크<<에서 확인할 수 있습니다 ~!

 

3차 프로젝트 무사히 끝!!!

 


66일차 & 67일차

날짜 : 2025-04-06 - 2025-04-07

Four F’s of Active Reviewing

Facts : 3차 미니 프로젝트 명은 PickCardU다. 프롬프트에 MBTI를 얹겠다는 아이디어와 함께 머니-Ti, 머니로그, CardIt 등 여러 후보가 있었으나, 과반수의 동의로 귀엽기도 하고 입에 착 붙는 PickCardU가 당첨됐다.

PickCardU 프로젝트는 MBTI기반 개인 맞춤형 신용카드 큐레이션 RAG 챗봇 구현이 목표였다. 10개 카드사에서 각 신용카드의 PDF를 수집해 RAG 파이프라인으로 구축했고, 최종적으로 개인의 MBTI에 따라 프롬프트를 적용해 말투를 변경해서(예를 들면 T에게는 보다 직설적이고 정보위주의 응답을, F에게는 따뜻한 말투로 친절하게 응답을 유도) 사용자가 원하는 응답을 제공한다. 그 과정에서 담당 업무로 데이터 수집(신한, IBK), MBTI 프롬프트(INFP) 설계, Docker 환경 세팅, UI/UX를 맡았다.

Feelings :
- 팀원의 업무 분담과 코드 리팩토링까지 신경 쓰는 테크 리드 역할이 부담스럽기도 했지만 그만큼 재밌었다 .전과정의 흐름을 파악하고 관여하다보니 자연스럽게 프로젝트에 더 애정이 생겼다.
- Docker 환경 세팅 중 requirements 수정이 잦아서 팀원들이 이미지를 계속 다시 빌딩해야했다. 그 부분은 팀원들에게 좀 미안했다 .. ㅎㅎ... 그 과정에서 경경수*님이 부족한 컴퓨터 용량과 싸우시는 모습이 짠했다 (...) 하드 용량이 1G가 남았다고 하시더니 어찌저찌 쥐어짜서 10G 용량 확보하시고, 결국 어떻게든 프로젝트를 마무리하셨다는 게 존경스럽기까지 하다.
- 전체 RAG 파이프라인이 의도한 대로 동작하는 걸 확인했을 때 보람이 컸고, 그만큼 아쉬움도 많이 남는 프로젝트였다. 테스트 때 잘 되던 질의응답이 시연을 할 때 정상 작동을 안해서 속상했다 ㅠ...
- 다들 프로젝트에 맡은 업무를 끝까지 책임지고 수행해줘서 좋은 결과를 얻을 수 있었다. 다음 프로젝트도 잘 부탁해요!!

Findings :
- 프롬프트가 구체적이고 길다고 꼭 좋은 게 아니다.
- MBTI 프롬프트와 기본 RAG rules 프롬프트를 설계하면서 구성 방식에 따라, 프롬프트가 지시된 순서에 따라 영향을 미치는 크기가 다를 수 있다는 점을 배웠다.
- 할루시네이션 방지를 위해 context 내의 정보만 사용하도록 프롬프트에 명시적 규칙을 넣는 게 유효하게 작용했다. (근데 이 규칙이 강하게 작용되었는지 등록된 카드 정보가 있어도 답을 제대로 못하는 경우가 있었다.)


Future

- 경경수님과 별도 레포를 파서 OCR방식(EasyOCR vs GPT Vision)에 따른 성능 차이를 실험해보기로 했다.
- 프롬프트 최적화 방향도 논의해서 최적화를 할 것 같다. 프로젝트 기간이 짧아서 검증하지 못했던 부분들을 중점적으로 개선해보고자 한다.

* 경경수님이 된 이유는 즐겨보는 웹툰 캐릭터랑 굉장히 닮으셨기 때문이다.

아직 본인은 믿지 못하시는 것 같지만.
진짜 닮으셨다.

TMI. 개발자라면 보세요. 경경수의 개발만화 재밌어요.

 

 

 


68일차

날짜 : 2025-04-08

Four F’s of Active Reviewing

Facts :
- 프론트엔드 기초(HTML/CSS) 이론과 함께 nvm/npm 환경 세팅을 진행했다. Django로 백엔드 서버를 구축하고 SQLite 및 MySQL DB와 연결하는 실습 진행
- makemigrations -> migrate 로 모델을 DB에 반영
- 프론트엔드에서 Django API를 호출하는 실습 진행
- CORS 개념을 처음 접하고 django-cors-headers로 해당 문제 발생을 방지했다

Feelings : 이전에 프론트엔드 경험이 있어서 HTML/CSS/JS 구조는 어렵지 않았는데, CORS는 처음 접하는 개념이라 신기했다. 그리고 서버와 DB를 직접 연결하고 데이터가 어떻게 오고 가는지 이해하는 게 오래 걸렸다. 부족한 개념들은 틈틈히 채워야겠다...!

Findings :


- CORS의 필요성 : 브라우저는 기본적으로 같은 출처끼리만 통신을 허용함. 출처는 프로토콜 + 도메인 + 포트 조합임.
- 실습 시 프론트(localhost:5501)가 Django(localhost:8000)에 요청을 보냈을 때 포트가 달라서 다른 출처로 간주되어 브라우저가 막음. 이 때 CORS는 서버에서 명시적으로 이 출처는 허용한다고 풀어주는 매커니즘이다.
- CORS(Cross-Origin Resource Sharing)은 브라우저가 다른 출처의 서버에 요청을 보낼 때 보안상의 이유로 기본적으로 차단하는 정책
- 가장 간단한 경우 브라우저 스크립트는 다른 도메인 내 서버의 리소스에 대해 GET 요청을 수행함. 요청이 GET 요청을 제출하도록 승인된 도메인에서 전송된 경우, 해당 서버의 CORS 구성에 따라 cross-origin 서버가 요청된 리소스를 반환해 응답함. 이 때, 요청하는 도메인이나 HTTP 요청 유형이 승인되지 않은 경우라면 요청이 거부된다. 그러나 CORS는 요청을 실제로 제출하기 전에 사전 요청을 보낼 수 있다. preflight는 simple request 조건(GET/POST/HEAD + 기본 헤더)을 벗어날 때만 발생함
- Django에서는 makemigrations로 모델 변경사항을 마이그레잉션 파일로 만들고 migrate로 실제 DB에 반영하는 구조다.

Future : 프론트-백엔드-DB가 연결되는 플로우 더 익히기

- Reference.

 

CORS(Cross-Origin Resource Sharing) - AWS SDK for JavaScript

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

 

 

 


69일차

날짜 : 2025-04-09

Four F’s of Active Reviewing

Facts :
- DOM 개념과 JavaScript 기초 자료형 실습을 시작으로, N빵 계산기를 HTML/CSS/JS로 구현했다. 이후 동일한 기능을 TypeScript로 재구현하며 타입 명시 문법을 익혔다.
- React를 Vite로 세팅하고 컴포넌트 구조(App->Giveme->Money)와 props 전달, JSX 문법, Element 렌더링 흐름을 실습

Feelings :
- JS 경험이 있어서 DOM 조작이나 이벤트 핸들러 흐름은 낯설지 않았다. 근데 아직도 DOM이 뭐냐고 물으면 대답을 잘 못하겠다. 해본 것과 실제로 설명할 수 있다는 건 차이가 큰 것 같다.
- React는 컴포넌트 단위로 UI를 쪼개는 구조가 신기했다.


Findings
 
- TypeScript는 JS의 스코프 문제가 아니라 타입 안정성 문제를 해결하는 언어다. 런타임 이전에 타입 오류를 컴파일 단계에서 잡아준다. 브라우저는 TS를 직접 실행할 수 없어서 tsc로 JS로 컴파일하는 과정이 필요하다.
- React의 Element는 불변(immutable) 객체로 JSX로 작성한 코드는 내부적으로 type, props 등을 가진 일반 JS 객체로 변환된다.
- SPA는 서버에서 페이지를 한 번만 받고 이후 변경사항은 AJAX로 처리하는 방식이다. 페이지 전체 새로고침없이 동작한다.

Future : React 컴포넌트 구조와 props 공부

 

 

 


70일차

날짜 : 2025-04-10

Four F’s of Active Reviewing

Facts :
- React + TypeScript 기반 게시판 프론트엔드 구축
- useState로 로그인/회원가입 모달 열림, 닫힘 상태 관리
- 백엔드는 Django REST Framework로 회원가입(SignupView)과 로그인(CustomLoginView) API를 구현
- 로그인 성공 시 Token을 발급해 프론트에 반환하는 토큰 인증 방식 적용
- CORS 설정 및 Talent API Tester로 API 동작 체크

Feelings : 프론트에서 백엔드 API를 호출해서 데이터가 실제로 전송될 수 있도록 연결하는 부분이 제일 어려웠다. 어제까지 프론트, 백엔드를 따로 다뤄서 괜찮았는데, 둘을 이어붙이니 머릿속이 뒤죽박죽이다 🤯

Findings :
- Django REST Framework의 Serializer는 요청 데이터의 유효성 검사와 DB 저장을 담당
- ModelSerializer를 사용하면 Django 모델과 자동으로 연동됨
- 토큰 인증 방식에서는 로그인 성공 시 서버가 토큰을 발급하고, 이후 클라이언트는 권한이 필요한 요청마다 해당 토큰을 헤더에 담아 보낸다.
- React에서 fetch로 API 호출할 때 Content-Type: application/json 헤더와 body: JSON/stringify()를 함꼐 지정해야 Django가 요청 데이터를 올바르게 파싱한다.

Future : 요청이 어떻게 나가고 어떻게 돌아오는지 연결 흐름 익숙해지기.

 

 

 

📖 주말


ncs 시험보러 다녀왔는데, 전공 문제 중 하나가 CNN 구조에서 파라미터 값 계산하는 거였는데 bias를 고려안해서 틀렸다. 그리고 심지어 transformers에 대한 개념 문제를 틀렸다. 그렇게 4점을 날리고 자괴감 MAX였다. 맨하튼 거리도 ....
자꾸 생각나서 고통스럽다 ㅠㅠㅠㅠ


아는 문제라고. 풀 수 있다고 생각했는데 그냥 한참 부족했다.
일단 덮어두고 정처기 실기를 준비하자.

 

댓글