[유니티]25.08.18 복습

유니티, 같은 계정인데도, 동기화가 되지는 않네

 usb나 git으로

---

오늘, 학교에서 배운거, 처음부터 다시 만들어볼까나

근데, 폴더위치 변경하는 부분 모르겟던데

내일 일찍 가서 물어봐야하나

 

(이까지 복습하다가 자버림)

 

 

 

 

 

 

 

 

 

 

 

 

 환경변수 

path 에, 다운받은 경로를, 추가해주면 되는거군

 

---

 

명령어 추가하는 부분 모르겟던데

---

 

vcontainer사용법도 .md로 해놧던것같고

 

기획서>게임 어케 만들건지도 .md파일로

 

---

 

visual studio code에서

플러그인

cline

c#

unity

 

cline에서

get api

구글 로그인 한뒤, 계정 눌러서  api키 받기 

 

---

플러그인 , cline에서

open router

에,

 

모델에 free검색

qwen3 coder

치면 됨

 

---

ai가 문장 생성하는게, 확률기반이라서

조건부 확률.

그래서, 더 자세한 문맥을 주면, 경우의 수가 줄어들고,

더 원하는 답변을 생성할수있게됨

 

---

제미나이-설명서 docs

giit에서, document에 설명서가 있나봄

어제 복습 제대로 해둘걸..

복습하다가 자서

 

---

v container의존성 관리 해준다는데 

의존성이 뭔말이엿더라 

 

의존성이란? (feat. IKEA 책상 조립)

제가 **"멋진 IKEA 책상"**을 하나 조립해서 만들려고 합니다. 이 책상이 바로 제가 만들 **'내 프로그램'**입니다.

상자를 열어보니 설명서와 함께 여러 부품이 들어있습니다.

• 상판 목재 1개
• 철제 다리 4개
• A타입 나사 8개
• B타입 연결 부품 4개

이때, "책상을 완성하려면 이 부품들이 반드시 필요합니다."

바로 이 관계가 의존성입니다.

• **'책상(내 프로그램)'**은 **'다리, 나사, 연결 부품(다른 프로그램이나 코드)'**에 의존(Dependency)한다고 말합니다.
• 여기서 다리, 나사, 연결 부품이 바로 '의존성(Dependencies)' 그 자체입니다.

즉, **의존성이란 "내 프로그램을 실행시키기 위해 꼭 필요한 외부 부품(다른 코드, 라이브러리, 프레임워크)들"**을 의미합니다.

의존성 문제: 왜 관리가 필요할까?

조립을 하다 보면 흔히 겪는 문제들이 바로 '의존성 문제'입니다.

• 문제 1: 의존성 누락 (부품이 없음)
  • "어? A타입 나사가 8개가 있어야 하는데 7개밖에 없네?" -> 책상을 완성할 수 없습니다.
  • 프로그래밍 세계: 내 프로그램이 A-library가 필요한데, 내 컴퓨터에 A-library가 설치되지 않았습니다. -> 프로그램이 에러를 내며 실행되지 않습니다.
• 문제 2: 버전 충돌 (부품이 안 맞음) - 가장 중요!
  • "설명서에는 **구형 B타입 부품(버전 1.0)**을 쓰라고 되어 있는데, 내가 가진 건 모양이 살짝 바뀐 **신형 B타입 부품(버전 2.0)**이네? 구멍에 안 맞잖아!" -> 책상을 완성할 수 없습니다.
  • 프로그래밍 세계: 내 프로그램은 Login-library 버전 1.0을 필요로 하는데, 내 컴퓨터에는 Login-library 버전 2.0이 설치되어 있습니다. 기능이 바뀌어서 서로 호환되지 않습니다. -> 프로그램이 에러를 내며 실행되지 않습니다.

의존성 관리 도구 (npm, Container 등)의 역할

이런 골치 아픈 문제를 해결해주는 것이 바로 **'의존성 관리 도구'**입니다.

이 도구는 IKEA 가구의 **"자동 부품 주문 시스템이 탑재된 스마트 설명서"**와 같습니다.

1. 목록 작성 (package.json 파일):
   개발자는 스마트 설명서(package.json 파일)에 이렇게 적어두기만 합니다.
2. "이 책상을 만들려면, **반드시 A타입 나사(정확히 1.0 버전)**와 **B타입 부품(1.5 버전 이상)**이 필요합니다."
3. 자동 설치 (npm install 명령어):
   이제 다른 사람이 이 설명서를 가져와서 npm install이라는 버튼을 누릅니다. 그러면 npm이 이 목록을 보고, 필요한 부품들을 인터넷이라는 거대한 창고에서 정확한 버전으로 모두 찾아서 내 컴퓨터에 자동으로 가져다줍니다.

 

---

api란

결론부터 말씀드리면, API 키는 컴퓨터를 식별하기 위한 것이 아니라, 그 서비스를 사용하는 '프로그램' 또는 '개발자'를 식별하고 관리하기 위한 '이름표'이자 '사용량 계량기'이기 때문입니다.

조금 전의 레스토랑 비유를 다시 사용하거나, 도서관 회원증으로 비유해 보겠습니다.

도서관 회원증 (API 키)은 왜 필요할까요?

도서관은 시민이라면 누구나 이용할 수 있고, 회원증도 신청만 하면 대부분 발급해 줍니다. 그런데 왜 굳이 회원증을 만들어서 대출할 때마다 보여달라고 할까요?

1. 인증: "누구신가요?" (정식 회원 확인)
도서관은 책을 빌리는 사람이 적어도 우리 도서관에 등록된 회원이라는 것을 확인하고 싶어 합니다. 아무나 와서 책을 마구 가져가면 안 되니까요.

• API의 세계: 서비스를 요청하는 프로그램이 아무나 만든 악성 프로그램이 아니라, 정식으로 "저 이 서비스 좀 쓸게요"라고 등록한 개발자의 프로그램이라는 것을 확인하는 과정입니다.

2. 사용량 제어: "몇 권까지 빌릴 수 있나요?" (과부하 방지 및 공정한 사용)
한 사람이 도서관의 모든 책을 다 빌려가 버리면 다른 사람들은 책을 빌릴 수 없습니다. 그래서 "1인당 최대 10권, 2주 동안만 대출 가능"이라는 규칙을 만듭니다.

• API의 세계: 한 명의 사용자가 1초에 수백만 번씩 요청을 보내면 서버가 다운될 수 있습니다. 그래서 API 키마다 "1분당 100번까지만 요청 가능"과 같은 제한(Rate Limit)을 둡니다. 이는 안정적인 서비스를 모두에게 제공하기 위함입니다.

3. 과금: "연체료는 얼마입니다." (비용 청구)
책을 늦게 반납하면 연체료가 붙습니다. 회원증이 있어야 누구에게 연체료를 부과해야 할지 알 수 있습니다.

• API의 세계: 사용자가 무료 제공량을 초과하여 서비스를 사용했다면, 어떤 API 키(계정)에 요금을 청구해야 할지 정확히 알아야 합니다. API 키가 바로 그 청구서의 주소 역할을 합니다.

4. 보안 및 책임 추적: "책을 잃어버리면 누가 책임지나요?"
만약 누군가 책을 훼손하거나 잃어버렸다면, 회원증 기록을 보고 누가 빌려 갔는지 찾아 책임을 물을 수 있습니다.

• API의 세계: 만약 어떤 API 키가 비정상적인 활동(해킹, 데이터 유출 시도 등)을 보인다면, 서비스 제공자는 즉시 그 API 키만 차단할 수 있습니다. 이렇게 하면 다른 선량한 사용자들에게 피해를 주지 않고 문제만 정확히 해결할 수 있습니다. 만약 API 키가 없다면, 특정 IP를 차단하거나 최악의 경우 서비스 전체를 중단해야 할 수도 있습니다.

정리하자면,

사용자님의 생각처럼 "API 키 발급" 자체는 어렵지 않습니다. 하지만 이 절차는 서비스 제공자 입장에서 매우 중요합니다.

• 누가 내 서비스를 쓰는지 (인증)
• 얼마나 쓰고 있는지 (사용량 제어 및 과금)
• 문제를 일으키면 누구인지 (보안 및 책임)

 

 

 

---

qwen.md

이 사용법을 알고싶을때

레퍼런스를 넣어야함

이때 @이용해서, 참조하게 해줄수있음

 

---

 

qwen.md 한국어로 되도록 

 

---

 

이벤트버스\의존성 때문에

의존성 줄이려고

 

---

ttd랑 

바이프 코딩이 뭐지

 

 

---

prd

공학입문시간에 배웟던거