"나도 내 AI 친구 만들고 싶다."

단순한 챗봇이 아니라

• 내 일정을 정리해주고
• 내 고민에 반응해주고
• 때로는 나만의 비밀을 공유할 수 있는 AI

그런 존재를 만들어보고 싶었다.

그러던 중 카카오 AI 브랜드 카나나(Kanana) 발표 소식을 접했다.

>

개인 AI ‘나나’와 그룹 AI ‘카나’로 역할을 나눴다는 설명을 보고 솔직히 조금 놀랐다.

나를 신경 써주는 개인 AI뿐만 아니라,
단톡방 알림이 한 번에 수십 개씩 쌓이면 그냥 넘겨버리곤 했던 나에게
대화를 요약해주는 그룹 AI의 존재는 꽤 인상적이었다.

"내가 상상하던 AI 친구와 얼마나 닮았을까?" 기대가 됐다.

🔮 사주부터 시작한 첫 경험

가볍게 사주 AI를 먼저 사용해봤다.
생년월일, 태어난 시간, 성별 등 기본 정보를 입력하자 분석이 시작됐다.

생각보다 맥락에 맞는 해석을 제공했고,
대화가 자연스럽게 이어진다는 점이 인상적이었다.

AI가 단순히 정답을 말하는 존재가 아니라,
사용자의 이야기를 받아 정리해주는 존재처럼 느껴졌다.

✈ 대만 여행 일정, 자료조사를 대신해주다

조금 더 실용적으로 테스트해보기 위해
대만 여행 일정을 등록하고 놀거리 추천을 요청했다.

여행 준비를 할 때마다 여러 블로그를 열어보며 정보를 취합하는 과정이 늘 번거로웠다.
카나나는 일정 흐름에 맞춰 기본 틀을 정리해주었다.

기능 자체는 다른 AI 에이전트와 유사했지만,
카카오 플랫폼 안에서 동작한다는 점에서 안정감이 있었다.

다만 아쉬운 점도 있었다.

• PDF 추출 ❌
• 한컴(HWP) 파일 추출 ❌

  

생산성 도구로 발전하려면 출력 포맷 연동은 꼭 보완되면 좋겠다고 느꼈다.

💬 카나는 왜 기존 단톡방과 바로 연결되지 않을까?

그룹 AI ‘카나’도 궁금했다.
하지만 기존 카카오톡 단체방과 자동 연동되는 구조는 아니었다. (카나나 앱에 있는 단톡방에 한해서만 되는 기능이었던 것임.. 음음)

카나 기본 설정	단톡방 개설	카나와 대화하기

. . .

처음에는 아쉬웠다.
쌓여 있는 단톡방 메시지를 정리해줄 줄 알았기 때문이다.

하지만 곰곰이 생각해보니,
이건 단순 기능 문제가 아니었다.

단톡방 전체 대화를 AI가 자동으로 읽는 순간,

• 참여자 동의 문제
• 개인정보 보호 이슈

가 동시에 발생할 수 있다.

카카오가 온디바이스 AI를 강조하는 것도 같은 맥락일 것이다.

편리함과 신뢰, 그 사이에서 어디까지 허용할 것인가.

카나는 지금 그 경계 위에서 조심스럽게 확장 중인 플랫폼 에이전트처럼 보였다.

🚀 플랫폼 에이전트의 가능성

요즘 AI 에이전트들은
이미지 생성, 영상 제작, 문서 작성 등
각자의 강점을 내세우고 있다.

그렇다면 카카오는 어떻게 밀고 가야 할까?

나는 이렇게 생각한다.

모든 걸 다 잘하는 AI가 아니라,
카카오만이 할 수 있는 AI가 되어야 한다.

카카오는 메신저, 지도, 모빌리티, 결제 등
이미 일상에 깊이 들어와 있는 플랫폼을 보유하고 있다.

이 생태계와 AI가 결합된다면,

• 단톡방 약속 대화 → 장소 추천
• 여행 대화 → 일정 초안 생성
• 소비 내역 → 패턴 요약

처럼 생활 맥락 이해형 AI로 발전할 수 있다.

🔎 아직 완벽하지 않지만, 의미 있는 시작

카나나는 아직 완벽하지 않다.
보완할 부분도 있고, 신뢰 설계에 대한 고민도 계속 필요하다.

하지만 개인 AI와 그룹 AI를 분리 설계하고,
플랫폼 위에서 확장 가능성을 실험하고 있다는 점에서
충분히 의미 있는 시작이라고 느꼈다.

지금까지 카카오가 수많은 시도와 도전을 거치며
사용자들의 날카로운 피드백을 받아왔듯,
카나나 역시 그 과정을 통해 더 단단해질 것이라 생각한다.

AI 친구를 만들고 싶었던 한 명의 컴공생으로서,
이 실험이 어디까지 확장될지 지켜보고 싶다.

중국어과에서 컴퓨터공학과로 전과한 지 얼마 안 됐을 때였다. 말 그대로 (응애응애) 갓 신생아 컴공생 시절.

하필 2학기에 전과를 하게 되면서 실습 위주의 수업을 한꺼번에 듣게 됐고,

그중 하나가 「오픈소스프로그래밍」이었다.

사실 이 과목은 전과를 결심하게 된 이유 중 하나이기도 했다. (헥헥)

내가 컴공을 선택한 이유

전과 전부터 나는 알고리즘을 도출해서 성능 비교하고, 코딩테스트용 문제를 푸는 것보다는,

"실제로 내가 쓸 수 있고, 상용화까지 상상해볼 수 있는 걸 만드는것"

에 더 흥미를 느끼는 사람이었다.

그래서 이 수업의 프로젝트 주제를 정할 때도 ‘기술 과시용’이 아니라 현실에서 문제 되는 걸 해결해보고 싶다는 생각이 컸다.

"큐싱"이라는 키워드

주제를 고민하던 중, 컴공 전과 후 처음으로 만났던 그 분께서 툭 던지듯 한 단어를 말했다.

"큐싱 어때?"

…그 순간 바로 도파민 터졌다. (아, 이건 된다 싶었다.)

당시 QR코드를 이용한 서비스가 급격히 늘어나면서 악성 QR코드를 통해 피싱 피해를 입는 큐싱(QR Phishing) 사례도 함께 증가하고 있던 시기였다.

프로젝트 아이디어 : 큐싱 피해 방지 자전거 대여 앱

그렇게 최종적으로 제안한 아이디어가 큐싱 피해 방지 자전거 대여 애플리케이션이었다.

[프로젝트 소개] https://www.miricanvas.com/login?redirect=%2Fdesign%2F13zwshl%3Flocation%3Ddesign%26type%3Dcopy_link%26access%3Ddirect

당시 QR코드 기반 공유 자전거를 이용하다가 악성 QR코드로 인해 피싱 피해를 입는 사례가 실제로 늘고 있었고,

이 문제는 단순한 불편을 넘어 개인정보 유출과 서비스 신뢰도 하락으로 이어질 수 있었다.

• _큐싱_이란 악성 QR코드를 촬영하도록 유도해
• 악성 앱 설치나 피싱 사이트 접속을 유도하는 공격 방식*으로,
  도시 내 공유 서비스가 확산될수록 그 위험성도 함께 커지고 있었다.
  그래서 우리는
• 보안성과 편의성을 동시에 만족*하는 자전거 대여 플랫폼을 만들어보고자 했다.

차별화 포인트

기획 단계에서 기존 자전거 공유 앱(T사, A사)의 UX를 분석하면서 여러 불편함을 느꼈고,

기존에 비교적 안정적으로 사용되던 G사의 UX 흐름을 참고해 메인 화면과 주요 버튼 디자인을 설계했다.

단순히 디자인만 비슷하게 가져가는 것이 아니라, 큐싱을 구조적으로 막을 수 있는 기능을 넣는 데 집중했다.

핵심 차별 기능 : QR코드 검증 & 신고 로직

이 프로젝트의 핵심 차별점은 다음과 같다.

• QR코드를 스캔했을 때
• 등록된 자전거 고유 번호와 일치하지 않거나
• 링크 형식이 기존 패턴과 다를 경우

👉 즉시 신고 화면으로 전환

신고가 접수되면 관리자가 실시간으로 보고 있지 않더라도 알림을 통해 문제를 인지하고 빠르게 대응할 수 있도록 설계했다.

즉, 사용자가 피해를 입은 ‘이후’ 가 아니라 피해가 발생하기 ‘직전’ 단계에서 문제를 차단하는 구조를 목표로 했다. (근데 만들고 있는 와중에 타어플에서 이미 똑같은 보안기능 나옴 !! 젠장!!)

기술 스택 선택 이유

이번 프로젝트에서는 단순히 과제를 제출하기 위한 결과물이 아니라,

(언제나 나는) 실제로 동작하는 서비스에 최대한 가까운 형태를 만들어보고 싶었기에..

각 기술은 그 목적에 맞게 선택했다.

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

■ Figma, 미리캔버스 – UI/UX 디자인

기획 단계부터 “일단 만들어보자”가 아니라 사용자가 실제로 쓸 화면을 먼저 그리고 싶었다.

Figma를 사용해 앱과 관리자 페이지의 화면 흐름을 미리 설계했고, 미리캔버스는 발표 자료와 디자인 보조용으로 활용했다.

디자인을 먼저 잡아두니 기능 구현 시에도 방향이 흔들리지 않았다.

■ Kotlin – 안드로이드 앱 개발

이 프로젝트는 웹 서비스보다는 실제 앱 형태로 구현해보고 싶었다.

QR 스캔, 센서 연동 등 모바일 환경에서 자연스럽게 동작하는 기능들이 많았기 때문에 안드로이드 네이티브 개발을 선택했고, Kotlin을 사용해 앱을 구현했다.

■ Flask – 백엔드 서버

백엔드는 모바일 앱과 웹 관리자 페이지를 연결하는 역할이 필요했다.

복잡한 구조보다는 API 중심으로 빠르게 구현하는 것이 목적이었기 때문에 Flask를 사용해 서버를 구성했다.

QR 검증 로직과 신고 및 데이터 처리 API를 중심으로 구현했다.

■ MongoDB – 데이터베이스

QR 정보, 신고 내역, 사용자 데이터 등 구조가 고정되지 않은 데이터들이 많았고, 이미지 정보와 함께 처리해야 하는 경우도 많았다.

그래서 정형 데이터베이스보다는 JSON 기반의 반정형 데이터를 유연하게 다룰 수 있는 MongoDB가 더 적합하다고 판단했다.

■ Vue – 웹 페이지 (관리자 페이지)

모바일 앱 외에도 관리자 입장에서 확인할 수 있는 웹 페이지를 간단하게라도 만들어보고 싶었다.

Vue를 사용해 신고 내역과 자전거 상태를 확인할 수 있는 관리자 페이지를 구현했다.

프론트엔드 프레임워크를 실제 서비스에 적용해보는 좋은 경험이 되었다.

■ Arduino + 3D Printer – 하드웨어 테스트 환경

단순한 앱 시연에서 끝내고 싶지 않았다.

실제 자전거 센서와 연동해 대여 / 반납 로직이 어떻게 동작할지까지 구현해보고 싶었고, 이를 위해 Arduino를 사용했다.

다만 실제 자전거와 부품이 없는 상황이었기 때문에 3D 프린터로 자전거 모형을 제작해 QR 코드 테스트 환경을 구성했다.

하드웨어까지 포함한 흐름을 직접 만들어본 경험은 이 프로젝트에서 가장 인상 깊은 부분 중 하나였다.

나의 역할

프로젝트에서 나는 다음 역할을 맡았다.

• 전체 기획 및 아이디어 구체화
• 기술 스택 선정
• 팀원 관리 및 일정 관리
• 웹 / 앱 UI 디자인
• Arduino 및 3D 프린터 제작 파트
• 앱웹 프론트 조금씩..

전반적인 프로젝트 매니징과 기획 중심 역할을 담당했다.

회고

첫 프로젝트였고 나름 캡스톤 상대로 교내대회에서 상도 탔지만, 다만 아쉬움도 분명히 남는다.

보안 로직과 백엔드 핵심 구현은 다른 팀원이 주로 담당했기 때문에, 보안과 서버 구조를 더 깊이 파고들지 못한 점이 아쉬웠다.

지금 돌아보면, 그때 조금 더 욕심을 내서 보안 쪽까지 함께 파고들었으면 더 많이 성장할 수 있었을 것 같다.

마무리하며

이 프로젝트는 컴공 전과 후 처음으로 ‘문제에서 출발한 서비스’ 를 만들어본 경험이었다.

기술이 목적이 아니라, 현실에서 실제로 발생하는 문제를 어떻게 구조로 풀어낼 것인가를 처음으로 진지하게 고민했던 프로젝트였다.

큐싱 이슈가 한창이던 그때, 나는 이렇게 고민했고 이렇게 하나의 결과물을 만들어냈다.

지금의 나를 만든 꽤 중요한 시작점이었다고 생각한다.

아니 학교에서 대회 참여만 해도 마일리지를 준다는 거임. 근데 이 마일리지가 그냥 점수가 아니라 돈으로도 교환 가능하다고 함.

이걸 누가 안해? ㅋ

문제는 시험기간이었고, 대회가 있다는 걸 너무 늦게 알아버린나, 거기에 마감은 3일밖에 안남음..

그래서 첨엔 "참여에 의의를 둔다" 로 시작했다

근데 또 막상 시작하려니까 내 성격상 그게 잘 안됐다. (완벽주의 + 실용주의 + 감자지만 멋있는 감자가 되고 싶은 곤란한 유형)

그래서, 2일 만에 뭘 만들었냐

처음에는 그냥.. 예산관리 플랫폼을 만들까 했다

근데 차별성이 없잖냐..

우선 "예산관리" 자체는 너무 흔했고, 굳이 만들었는데 타 어플이랑 차별성도 없으면 무의미한 프로젝트라고 생각했다.

그래서 방향을 바꿨다. "누가 실제로 쓸까?" 를 기준으로

마침 나는 내년에 학생회 할 예정인데, 학생회에서 항상 문제 제기 되는게 있다.

바로 예산 투명성, 그리고 그 끝에 항상 따라붙는 횡령 이슈

대부분의 문제는

• 증빙자료가 제대로 남아있지 않음
• 확인하기 어려운 구조

즉, 증빙이 제대로 되고 있는지를 확인하기 어렵다.

그래서 단순한 예산 관리가 아니라,

투명하게 공개되고, 증빙이 자동으로 남는 예산 관리 플랫폼 → 자치기구와 학생회를 위한 예산 관리 자동화 플랫폼

을 만들어보기로 했다.

프로젝트 소개

해당 프로젝트는 앞서 말했듯, 학생회를 포함한 소규모 조직을 대상으로 한 투명한 예산 관리 및 증빙 자동화 플랫폼이다.

학생회 예산 관리에서 가장 자주 문제가 되는 부분은 금액 자체보다도 과정의 불투명함이라고 생각했다.

• 지출 내역은 존재하지만 증빙 내역이 부족하거나
• 증빙도 있지만 확인하기 어려운 구조이거나
• 결국 신뢰 문제로 이어지는 모든 경우..

그래서 이 프로젝트의 핵심 목표는 단순했다.

"모든 지출이 자동으로 증빙되고, 누구나 예산 흐름을 확인할 수 있게 하자"

핵심 기능

주요 기능은 다음과 같다.

• 예산 지출 내역 등록
• 영수증 이미지 업로드
• OCR을 통한 영수증 정보 자동 추출
• 지출 내역 + 증빙 자료 동시 저장
• 전체 예산 흐름 조회

특히 증빙 자동화를 핵심 기능으로 두고, 사용자가 직접 모든 정보를 입력하지 않아도 영수증 이미지 하나로 최소한의 데이터가 자동생성되도록 설계 했다.

[프로젝트 소개 자료] https://www.miricanvas.com/v/156dr3d https://github.com/HBNU-SWUNIV/ossw-competition25-yee

전체 시스템 구조

2일이라는 짧은 기간 동안 진행된 프로젝트였기 때문에 구조는 최대한 단순하게 가져가되, 실제 서비스 흐름과 크게 어긋나지 않도록 구성했다.

Vue (Frontend)
   ↓ REST API
FastAPI (Backend)
   ↓
Firebase (Auth / DB)
   ↓
Azure OCR

• Frontend: 사용자 입력 및 결과 시각화
• Backend: 인증 검증, 비즈니스 로직 처리, OCR 연동
• Firebase: 인증 및 예산 데이터 저장
• Azure OCR: 영수증 이미지 → 텍스트 데이터 변환

기술 스택 선정 이유

"2일 안에 안정적으로 구현 가능한가"

■ Frontend – Vue

React도 고려했지만, 짧은 시간 안에 화면 구성과 상태 관리를 빠르게 하기에는 Vue가 더 적합하다고 판단했다. (React는 한 번 이해하면 쉽지만, 초보자에겐 너무 어려운.. 흡끍덕발덕
개발자가 계속 공부해야하는 이유 중에 하나랄까..)

컴포넌트 구조를 단순하게 가져갈 수 있고, 초기 설정 부담이 적다는 점도 선택 이유 중 하나였다.

■ Backend – Flask

이번 프로젝트에서는 FastAPI를 사용해 백엔드를 구성했다.

단기간 프로젝트였기 때문에 복잡한 도메인 분리나 과도한 아키텍처보다는, 명확한 엔드포인트와 빠른 연동이 더 중요하다고 판단했다.

FastAPI는

• 비동기 처리 지원으로 OCR API 연동에 유리하고
• 요청/응답 구조를 명확하게 정의할 수 있으며
• 간단한 설정만으로도 안정적인 API를 빠르게 구성할 수 있다는 점에서

이번 프로젝트의 성격에 잘 맞았다.

FastAPI를 사용해 다음과 같은 API들을 구성했다.

• OCR 연동 API (영수증 이미지 처리)
• 예산 데이터 등록 및 조회 API

2일짜리 프로젝트였지만, 실제 서비스 흐름을 기준으로 API를 나누고 구성하려고 했다.

■ Database / Auth – Firebase

테스트 성격의 프로젝트였고, 대규모 데이터 처리나 복잡한 쿼리는 필요하지 않았다.

Firebase를 사용해

• 사용자 인증
• 예산 데이터 저장

을 빠르게 구성했고,

서버에서 별도의 인증 로직을 거의 구현하지 않아도 된다는 점이 단기간 프로젝트에 잘 맞았다.

■ OCR – Azure OCR

이 프로젝트에서 OCR은 단순 보조 기능이 아니라, 증빙 자동화의 핵심이었다.

그래서 OCR 엔진 선택에도 나름의 기준이 있었다.

여러 OCR 서비스를 비교해봤는데, 각각 다음과 같은 이유로 제외했다.

• Google OCR 한국어 인식 자체는 지원하지만, 영수증처럼 글자가 작고 밀집된 이미지 → 인식 정확도가 기대만큼 나오지 않는 경우가 있었다.

• Naver OCR 국내 서비스인 만큼 정확도는 충분히 좋아 보였지만, 사용을 위해 별도의 승인 절차가 필요 → 단기간 프로젝트 일정상 바로 적용하기에는 시간이 애매했다.

반면 Azure OCR은

• 한국어 인식 정확도가 비교적 안정적이었고
• API 사용 절차가 단순하며
• 결과 포맷이 정형화되어 있어 → _빠르게 파싱 로직을 구성하기에 적합_했다.

단기간에 구현해야 하는 프로젝트 특성상, “지금 바로 쓰면서 안정적인 결과를 얻을 수 있는가”가 가장 중요했고

그 기준에서 Azure OCR이 가장 합리적인 선택이었다.

증빙 자동화 처리 흐름

증빙 자동화는 다음과 같은 흐름으로 동작한다.

1. 사용자가 영수증 이미지를 업로드
2. 프론트엔드에서 이미지를 서버로 전달
3. Flask 서버에서 Azure OCR API 호출
4. OCR 결과에서 날짜, 금액, 상호명 추출
5. 추출 데이터 + 원본 이미지 URL을 함께 저장

이를 통해, 이미지는 증빙으로 남고, 텍스트 데이터는 자동으로 예산 내역이 되는 구조를 만들었다.

■ 증빙 자료 공유 기능 (읽기 전용 공개 페이지)

학생회 예산에서 중요한 건 “증빙이 있다”는 사실보다도

“언제든지 확인할 수 있다”는 점이라고 생각했다.

그래서 증빙을 내부에서만 관리하는 구조가 아니라, 읽기 전용으로 공유할 수 있는 증빙 페이지를 별도로 구현했다.

■ 공유 방식

• 증빙 자료 페이지는 링크 기반으로 생성
• 해당 링크는 QR 코드로도 공유 가능
• 링크에 접속하면 읽기 모드(Read-only) 로만 접근 가능

즉, 외부 사용자는 수정은 불가능하고 확인만 가능한 구조다.

■ 읽기 모드 페이지

• 해당 자치기구(학생회) 구성원 목록
• 등록된 모든 증빙 자료 리스트
• 증빙 자료를
  • 연 / 월 / 일 기준으로 필터링하여 조회

단순히 리스트만 보여주는 게 아니라, 실제 회계 확인 상황을 고려해 기간 단위로 빠르게 확인할 수 있도록 구성했다.

■ PDF / CSV 추출 기능

증빙 자료는 화면에서 바로 확인할 수도 있지만, 필요한 경우 문서로 추출할 수 있도록 했다.

• 선택한 기간 기준으로
  • PDF 추출
  • CSV 추출
• 회계 보고서 제출이나 외부 감사용 자료로 바로 활용 가능

즉, "보여주기용"이 아니라 "실제로 제출 가능한 증빙 자료"를 만드는 데 초점을 맞췄다.

프로젝트 후기

솔직히 말하면, 2일짜리 프로젝트에 얼마나 기대를 했겠나..

그런데 결과적으로 수상까지 하게 됐고, (교내대회이긴하지만 캡스톤 팀들과도 겨룸)

짧은 시간이라도 문제 정의가 명확하면 충분히 경쟁력이 있을 수 있다는 걸 느꼈다.

기술적으로 아주 복잡한 프로젝트는 아니지만, 실제 문제를 기준으로 기획하고 끝까지 동작하는 형태로 만들었다는 점에서 의미가 있었다.

그리고 나는... 내년 학생회 활동을 하면서 실제로 사용 가능한 서비스로 발전시켜보고 싶다.

]]> https://velog.io/@mixx_n/%EC%9D%B4%EC%A0%9C%EB%8A%94-%EA%B2%8C%EC%9E%84%EB%8F%84-Agent%EA%B0%80-%EB%A7%8C%EB%93%A0%EB%8B%A4 https://velog.io/@mixx_n/%EC%9D%B4%EC%A0%9C%EB%8A%94-%EA%B2%8C%EC%9E%84%EB%8F%84-Agent%EA%B0%80-%EB%A7%8C%EB%93%A0%EB%8B%A4 Sat, 13 Dec 2025 12:25:08 GMT

뭬?

게임도 된다고?

내 일자리 실시간 잃는 중

Agent를 활용해서 웹사이트를 만들거나, 포트폴리오를 만들거나, AI에 조금이라도 관심을 가지고 활용하려는 사람이라면

이제는 누구나, 무엇이든 만들 수 있는 시대가 된 것 같다.

솔직히 말하면 게임까지 될 줄은 정말 몰랐다.

작년의 나를 떠올려보면

작년에 Unity로 게임을 처음 만들었을 때만 해도 개발 방식은 꽤나 전통적이었다.

• 막히면 ChatGPT에 하나씩 질문하고
• 안되면 구글링하고
• 에러 메시지 복사해서 검색하고
• 프로젝트 구조는 감으로 맞춰가며 관리했다

그때의 나는 "AI를 쓰고 있다"기 보다는 조금 더 빠른 검색 도구..? 쓰는 느낌 이었다 ㅋ

지금은 완전히 다르다 (다른건 나일까.. 발전한 AI일까..)

(헤겧ㄱ헥헤겧ㄱ)

지금은 게임 개발을 하면서 이런 생각을 먼저 한다.

“이걸 어떻게 구현하지?” ❌ “이걸 어떻게 설명하면 될까?” ⭕

• GitHub 협업 구조
• Unity 프로젝트 파일 관리
• 구동 방법, 실행 순서, 에러 원인

이제는 Agent가 맥락 단위로 설명해준다.

나는

1. 만들고자 하는 게임 구조 설명
2. 필요한 기능 정리 후 프롬프트 던져주기
3. 에셋 준비

위 3가지를 진행한 후... 👉 Cursor가 시키는 대로만 적용! 하면 됨 ㅋ

개발자라기보다는 설계자 혹은 감독... 느낌이랄까 (똑바로 만들어 이 바보녀석 한심하군 ㅋ)

그러다 마주한 현실적인 문제

이번에 팀원들과 GitHub을 활용해서 Unity 프로젝트를 공유하며 작업하려했다.

신나게 맵 에셋을 선정하고 git push를 외치며 올리려는 순간, 바로 벽에 부딪혔다.

❌ 파일이 너무 커서 업로드할 수 없습니다

Unity 맵, 텍스처, 모델 파일은 생각보다 훨씬 크다.

GitHub 기본 제한(100MB)은 에셋 하나로도 가볍게 넘어간다.

그때 찾아본 게 GIT LFS 였다.

Git LFS: Unity 협업에서 사실상 필수

Git LFS(Large File Storage)는 대용량 파일을 Git에 직접 올리지 않고

👉 _포인터만 관리하는 방식_이다.

고로 Unity 협업에서는 거의 필수다.

맵 에셋, 모델, 텍스처를 그냥 Git에 올리는 순간 프로젝트는 바로 망가진다.

그리고 또 하나, Unity용 .gitignore

두 번째로 깨달은 건 Unity 프로젝트에는 Git에 올리면 안 되는 파일이 정말 많다는 점이었다.

• Library 폴더, Temp 폴더, Obj 폴더…

이걸 하나하나 관리하려 들면 협업이 아니라 고행이 된다.

다행히 Unity 전용 .gitignore가 이미 잘 정리돼 있다.

👉 이걸 쓰는 순간 “왜 매번 폴더가 다시 생기지?” 같은 고민이 사라진다.

그래서 만들었다, 협업 체크리스트

여기까지 겪고 나니 이 생각이 들었다.

“이걸 매번 설명하는 것보다 처음부터 체크리스트가 있으면 좋겠다.”

그래서 Unity + GitHub 협업을 위한 최소한의 체크리스트를 정리했다. 다들 필요하면 써 ㅋ

✅ Unity + GitHub 협업 체크리스트

1️⃣ Git LFS, 에셋 올리기 전에 설정했나?

Unity에서 맵이나 모델, 텍스처 같은 거 그냥 올리면 거의 무조건 용량 문제 터진다.

그래서 이런 파일들은 처음부터 LFS로 관리하는 게 답 ㅎ

• 맵 / 모델 / 텍스처 → LFS 필수
• .gitattributes 파일 커밋됐는지 확인

2️⃣ Unity 전용 .gitignore, 제대로 적용돼 있나?

Unity 프로젝트는 Git에 올리면 안 되는 파일이 생각보다 많다. (젠장 왜 도대체 왜)

• Library
• Temp
• Obj

이런 폴더들은 Unity가 알아서 다시 만들어주는 애들이라 Git에서 관리할 필요가 없다

그래서 Unity 전용 .gitignore 쓰는 게 거의 필수다.

👉 Git에 올라간 파일 목록, 한 번쯤 다시 확인해보는 거 추천함당

3️⃣ Git에 포함되는 폴더만 남겼나?

Unity 프로젝트에서 사실 이 세 개만 있으면 됩니다 후후

✔ Assets ✔ Packages ✔ ProjectSettings

이 세 개만 제대로 있으면 팀원이 프로젝트 받아도 Unity에서 바로 열린다.

나머지는 없어도 Unity가 환경에 맞게 다시 살아난다.

4️⃣ 협업 규칙, 최소한만이라도 정했나?

거창한 규칙까지는 필요 없고, 이 정도만 정해도 협업이 훨씬 편해집니다....(진짜로)

자주쓰는거 몇가지만 말하자면

• Unity 실행하기 전에 git pull
• 기능 단위로 커밋하기
• 간단한 커밋 메시지 규칙 : feat, fix

이것만 지켜도 나중에 “누가 이거 건드렸어?” 이 말 나올 일 확 줄어든다.....

느낀 점

예전에는 “이걸 내가 다 알아야 하나?”라는 생각이 먼저였다면,

지금은 “이걸 어떻게 설명하면 Agent가 잘 이해할까?”를 더 많이 고민하게 된다.

코드를 직접 짜는 시간은 줄었지만, 의도를 정리하는 능력은 더 중요해졌다.

마무리하며

이제는 게임도 혼자 모든 걸 구현해서 만드는 게 아니라,

• 프롬프트로 구조를 설명하고
• Agent와 대화하며 설계하고
• 기본 세팅 위에서 빠르게 구현하는

그런 시대가 된 것 같다.

처음 보는 사람마다 꼭 물어봄 "중국인이세요?"

예.. 저는..

중국인아니고 중국어과임

중국어과 시절에 나는

남들만큼 “정말 열심히 살았다”라고 조금은 자부할 수...ㅎ 뭐 적어도 내 방식대로는 정말 다양한 경험들을 쌓아왔음

술을 못 마셔서 남들처럼 술집을 다니고 싶어도 못다닌거 절대 맞고 나도 마시고 싶은데 날 안껴주니까 내가 대외활동만 한거아니야

대신 내가 할 수 있는 모든 활동을 찾아다녔음

충대 공자 아카데미에서 추진하는 네이밍 대회 → 최우수상 https://www.miricanvas.com/v/122p8u8

충청권에서 추진하는 창업대회 → 최우수상 http://www.kcilbo.com/news/view.php?no=57435

전국 제페토 활용 메타버스 콘텐츠 제작 → 최우수상 https://youtu.be/K89JHiBvuVE?si=cYnchIYcVRZQnc0C

이거말고도 되게 많다.. 내가 할 수 있는 선택지에서 나갈 수 있는 대회란 대회는 다 나가본거같음

학교 공지사항에 내 얼굴이 며칠씩 뜨던 날들도 있었고 학교 홍보대사 / 대전시 대학생 홍보대사도 하고

그냥 하고 싶은 게 생기면 분야 상관없이 다 해봤다.

그런 내가… 왜 전과를 하게 되었을까?

전과를 결심한 이유

사실 단순하다. 중국어과로는 못 살겠다고 판단했기 때문…(아주 현실적)

정확히는… 중국어를 못했다. 발음이 아주 구렸음. (진지) (한국어 발음도 구림) (다 구려버려..~~)

그러던 어느 날 우연히 3D프린팅 수업을 들었고, 3D 모델링도 해보고 출력물도 뽑아보면서 관련 랩실에 들어오라는 제의를 받아 랩실을 다니게 되었음.

랩실에서 장비관련 일만 하다가.. 어쩌다 운 좋게 금속 3D프린터(PBF) 공정 데이터를 관리하는 플랫폼 개발 프로젝트에 참여하게 됐다.

근데…

갑자기 Vue랑 Flask로 플랫폼을 만들래?

그 시절 ChatGPT는 지금 같은 실력도 아니었고, 구글링을 해도 뭔가 안 되는… 그런 시절이었다.

그러다 중국에서 Vue–Flask를 연결 성공 맛을 봄 헥헥..

말그대로 이게 말이되냐!!!!!!!!!!!!!!!!

결국 vue가 뭔지 flask가 뭔지 vscode가 뭔지 찾아보면서 허우적거리다가 예정되어있던 중국 단기어학연수를 가게 됐는데 (무려 2주 ✈️)

근데 나는 그 2주 동안… 해당 과제를 해결하기 위해

수업 듣고 → 숙소 돌아와서 → VPN 켜고 한국 서버 우회하고 → 웹 서비스 연결 시도하고 → 결국 초안까지 완성

솔직히 그때의 나는 “중국에 와서 Vue–Flask 연결하고 있을 줄” 상상도 못 했음.. ㅋㅋ

하지만 지금 돌이켜보면 그때가 없었으면 지금의 나도 없었을 것 같다.

그때 처음 ‘웹 개발’이라는 세계를 만났다.

그리고 그 순간 느꼈다.

“아… 이거 더 배우고 싶다.”

그래서 ㄹㅇ 아묻따. 복수전공 신청.

처음엔 모든 개발자가 그렇듯(?), 프론트엔드의 ‘눈에 보이는 기쁨’에 빠졌다. 상상이 바로 화면에 구현되는 그 짜릿함.

그래서 1학년 끝나자마자 바로 인공지능소프트웨어학과 복수전공 신청.

심지어 욕심이 생겨서 부전공 융합전공도 같이 넣어버렸더니..

주전공 : 중국어과 복수전공 : 인공지능소프트웨어학과 부전공: 컴퓨터공학과 융합전공: 디지털트랜스포메이션(창업+3D프린팅)

...이거 맞아요? 지금 생각해도 뭔생각이었는지 졸업할 생각이 없었나봄

욕심 만땅.

그런데… 현실은 또 달랐다

웹 개발이 너무 재밌어서 기대했는데,

인공지능소프트웨어학과는

• 수학
• 알고리즘
• 기초 파이썬 로직

위주라서 솔직히 좀 재미없었고, 나랑 잘 맞지 않았다.

이산수학, DFS, BFS…

아무것도 모르는 상태에서 갑자기 하라고 하면 어떻게 합니까…

그래도 기말 프로젝트로

서울 거주 외국인 데이터를 기반으로 외국인 대상 문화체험 제공 관련 문제점 분석하고 해결 방안 제시하는 프로젝트를 완성하긴 했다.

https://www.miricanvas.com/v/124j3ef (3년전이라 유료도 깨져버림 ㅠ 눈 버리고 싶으면 보셈 ㅋ)

지금 생각해도 솔직히 내가 어떻게 한 건지 모르겠다.

별로임 보지마셈

하는 과정에서 재미는 있었지만 “아, 이 능지쪽... 내 길은 아니다.” 라고 느꼈다.

그래서 또 한 번 큰 결정을 내린다.

그리고 나는 ‘전과’를 선택했다

부전공으로 신청만 해두었던 컴공 수업들이 오히려 더 흥미롭고, 더 하고 싶었다.

딱 내가 "전과할까" 생각할 즈음에 오픈소스sw프로그래밍 프로젝트 기반 수업이 생기심. 벌써 행복했음 내가 기획하고 만들 수 있는거자나?

그래서 컴공 선배랑 중국어과 학과장님 찾아가서 정말 미래에 대한 고민도 많이 얘기 나누고 커리큘럼 하나하나까지 다 찾아보면서

후회없는 선택을 바라며..

마침 중국어과 전공도 거의 다 이수해 둔 상태라 “지금이 딱 타이밍이다!” 싶어 전과를 진행했다.

그리고…

컴공으로 전과한 나는… 컴퓨터 켜는 법도 몰랐다ㅋ

(에바에요)

ㅋㅋㅋㅋㅋ 진짜 말 그대로.

로그인하려는데 비밀번호 입력도 못 하고 계속 리눅스로만 부팅되는 거다.

알고 보니 부팅할 때 ‘빠르게 엔터를 눌러야’ 윈도우로 넘어가는 구조였는데 나만 그걸 몰랐다 젠장. 수치스럽. ㅋㅋㅋㅋ

결국 옆자리 친구한테

“혹시… 컴퓨터 어떻게 켜요…?”

라고 물어봤고 그 친구랑 1년을 함께 보내며

프로젝트를 수행하고 어려움을 극복하며 많은 성장을 하게 됐다.

컴퓨터도 제대로 못 켜던 내가 어떻게 성장했냐고?

그 이야기는…

다음 편에서!