작업형2 모의문제2 11분12초의 레이블인코딩이 아닌 원핫인코딩으로 변경하는 코드에 대해서 질문드립니다. 만약 원핫인코딩으로 진행하려면 아래와 같이 코드를 작성하면 될까요? # 원핫인코딩 train = train.drop('price', axis = 1) train = pd.get_dummies(train) test = pd.get_dummies(test) 그리고 원핫인코딩으로 변경하면 검증데이터 분리 과정에서 코드를 어떻게 수정해야하나요?(.pop()을 사용해서 'price' 컬럼을 따로 변수에 저장한 후에 target 부분에 넣어야할까요?) X_tr, X_val, y_tr, y_val = train_test_split(train, target, test_size = 0.2, random_state = 0 )
(base) C:\Users\sangil.shin> conda create --name study python=3.11 Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ConnectTimeoutError(<HTTPSConnection(host=' repo.anaconda.com ', port=443) at 0x26416036f90>, 'Connection to repo.anaconda.com timed out. (connect timeout=9.15)')': /pkgs/r/terms.json Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ConnectTimeoutError(<HTTPSConnection(host=' repo.anaconda.com ', port=443) at 0x264162e4550>, 'Connection to repo.anaconda.com timed out. (connect timeout=9.15)')': /pkgs/r/terms.json 위에 내용과 같이 에러가 발생됩니다. 확인 부탁드립니다.
MCP server 설치 내용이 현재와 달라서, 좀 헷갈립니다. 강의 6분 정도 되는 부분에서 막히기 시작했는데, 이전 Q&A 질문에서 업데이트로 인해 'npx ctx7 setup --claude'로 설치해도 된다는 답글을 확인했는데, MCP server로 설치하고 이후 github 로그인한 후 인증을 받아서 끝났는데, 이후로는 어떻게 해야할지 모르겠습니다 ㅠㅠ 위와 같이 해도, .mcp.json 파일이 새로 생기지 않았어요 ㅠㅠ
안녕하세요. MCP가 토큰 46.9% 절감해주고, 컨텍스트엔지니어링의 핵심 도구로 설명해주셨는데요. 뒷쪽에서는 MCP가 불필요한 토큰을 소비한다고 설명해주시는 부분도 있어서 헷갈립니다. 보충 설명 가능할까요? AI 모델 vs AI 코딩 도구: 무엇이 다를까? [UP_260206]
안녕하세요. Cursor에서 왼쪽 사이드바에서 레포지토리 초기화를 하였고, 선생님의 영상에서 처럼 커밋을 하려는데, "스테이징에 변경된 사항"에 무려 1000개가 나옵니다. 그간 연습하면서 했던 모든 것들이 나오나? 싶기도 하고요. (선생님 영상에는 6개) 이렇게 많으니깐 무엇을 커밋해야 되고 무엇을 하면 안되는지 감이 오지 않습니다. 어떤것이 문제로 작용했을까요? 어떻게 해결 하면 좋을까요? 감사합니다!
안녕하세요 강사님 평가지표 강의중에 문득 궁금한게 생겨서요 앞선 강의에서는 문자는 모두 인코딩을 통해 숫자형으로 변환했는데, 갑가지 강의에서 실제값, 예측값에 문자가 있을 경우를 설명해주시니 조금 혼란스럽네요... 그리고 이번 강의는 너무 빠르게 훑고 넘어가서 이해가 잘 안되는거 같습니다 아래 average 부분도 언제 이걸 쓰는지 알아야 할 거 같은데... 설명없이 슥 넘어가버려서... average= micro, macro, weighted
학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! 질문과 관련된 영상 위치를 알려주면 더 빠르게 답변할 수 있어요 먼저 유사한 질문이 있었는지 검색해보세요 작업형1_section14 에서 fillna(0)을 적용한 뒤 map() 함수를 사용하면 최종 결과 값은 동일하나 df 조회 시 다시 결측값이 발생됩니다. 이 경우 map() 대신 replace()를 사용하는 것이 맞는지 궁금합니다. # 값 대체 df['f3'] = df['f3'].fillna(0) dict_list = {'silver':1, 'gold':2, 'vip':3} df['f3'] = df['f3'].map(dict_list)
20번 강의 > 7번 문제를 풀던 중, 모든 나이에 1을 더하고, cond1 cond2를 설정한 뒤 각 조건의 절댓값 차이를 result 변수에 넣고 값을 확인했습니다. 값이 783.37이 나왔습니다. 선생님께서는 정답을 263.13으로 말씀 주셨습니다. 코드가 같은데, 값이 다른 이유가 궁금합니다. 제가 쓴 코드는 아래에 첨부하였습니다. df = pd.read_csv("https://raw.githubusercontent.com/lovedlim/inf/refs/heads/main/p1/type1_data1.csv") df['age'] = df['age'] +1 cond1 = (df['age']>=20) & (df['age']<30) cond2 = (df['age']>=30) & (df['age']<40) result = abs(df[cond1]['views'].mean() - df[cond2]['views'].mean()) print(result) print(round(result, 2))
학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! 질문과 관련된 영상 위치를 알려주면 더 빠르게 답변할 수 있어요 먼저 유사한 질문이 있었는지 검색해보세요 기출 9회 작업형 1에서 보면, grouped[1] 을 사용해서 지역코드와 성별로 그룹된 데이터프레임에서 1에 해당하는 컬럼명과 데이터를 선택합니다. 그런데 저는 이제까지 연습할 때 데이터프레임에서 열을 선택하기 위해 df[숫자]를 쓰면 행이 선택이 되었고, df[: , 숫자]를 입력하면 에러가 났었습니다. 그래서 df에서는 loc나 iloc를 사용해서 슬라이싱 혹은 인덱싱을 하고 있었습니다. 그런데 본 데이터에서는 오히려 loc와 iloc를 사용하면 에러가 납니다. 차이가 무엇인가요? 해당 데이터에서는 왜 컬럼 선택으로 출력이 되는 건가요?
(AI 퀀트) 코드 한 줄 안 쓰고 주식 자동 분석 시스템 만들기 feat. Claude CLI
💡 수강생 안내 사항 (커뮤니티 가이드) 학습 관련 질문 : 구체적으로 적을수록 정확한 답변을 받을 수 있습니다. 작성 팁 : 마크다운과 단축키를 활용하면 글을 더 편리하게 작성할 수 있습니다. 사전 검색 : 질문을 남기기 전, 커뮤니티 질문 & 답변에 비슷한 내용이 있었는지 먼저 검색해 보세요. 커뮤니티 매너 : 서로 예의를 지키며 존중하는 분위기를 함께 만들어가요. 서비스 문의 : 인프런 서비스 관련 문의는 1:1 문의하기 를 이용해 주세요. 37. 텔레그램 연동 (특강) - 수업자료 다운 받으세요 의 수업노트 노션 " 📈 [특강] 종가베팅 파이프라인 텔레그램 연동 프롬프트 가이드 "의 사용권한이 없다고 하네요ㅠ
(AI 퀀트) 코드 한 줄 안 쓰고 주식 자동 분석 시스템 만들기 feat. Claude CLI
💡 수강생 안내 사항 (커뮤니티 가이드) 학습 관련 질문 : 구체적으로 적을수록 정확한 답변을 받을 수 있습니다. 작성 팁 : 마크다운과 단축키를 활용하면 글을 더 편리하게 작성할 수 있습니다. 사전 검색 : 질문을 남기기 전, 커뮤니티 질문 & 답변에 비슷한 내용이 있었는지 먼저 검색해 보세요. 커뮤니티 매너 : 서로 예의를 지키며 존중하는 분위기를 함께 만들어가요. 서비스 문의 : 인프런 서비스 관련 문의는 1:1 문의하기 를 이용해 주세요. Part4 완성자료의 CLAUDE.md 자료의 프로젝트 구조를 보면, 시각화_가이드 폴더에 가이드 파일들이 있는데, 이 파일은 어디에 있나요?
수업노트로 요청한 tdd-red 스킬의 초안은 다음과 같습니다. 아래 내용으로 진행하면 import error, 파일 없음 에러도 정상적인 red 로 인식하고 다음 단계로 진행됩니다. --- name: tdd-red description: 승인된 테스트 시나리오를 실패하는 테스트 코드로 작성한다. TDD Red 단계 시작 시 사용한다. argument-hint: <feature> <이슈 번호> allowed-tools: Read Write Bash --- `$ARGUMENTS`에서 feature 이름과 이슈 번호를 파싱해 해당 이슈의 승인된 시나리오를 실패하는 테스트 코드로 작성한다. ## 시작 전 ### 인자 파싱 `$ARGUMENTS`를 공백으로 분리해 첫 번째 토큰을 `{feature}`, 두 번째 토큰을 `{issue}` 로 사용한다. | 입력 예시 | feature | issue | | ------------------ | -------- | ----- | | `/tdd-red tag 2` | `tag` | `2` | | `/tdd-red search 1`| `search` | `1` | 누락된 값이 있으면 실행 전에 사용자에게 질문한다. - `{feature}`가 없으면: "어떤 기능의 이슈인가요? (예: tag, search, ...)" - `{issue}`가 없으면: "이슈 번호를 알려주세요." 두 값이 확정된 뒤 `docs/features/{feature}/issue-{issue}.md` 를 읽어 시그니처와 테스트 시나리오 목록을 파악한다. - 시그니처 섹션: 테스트 대상 파일 경로 및 함수·컴포넌트명 확인 - 테스트 시나리오 섹션: 작성할 시나리오 목록 전체 수집 파일이 없으면 즉시 멈추고 사용자에게 알린다 (`/test-scenarios {feature} {issue}` 를 먼저 실행해야 한다는 안내 포함). --- ## 단계 1: 테스트 파일 준비 시그니처에서 테스트 대상 파일 경로를 추출하고 테스트 파일 경로를 결정한다. ### 파일 위치 규칙 | 구현 파일 | 테스트 파일 | | ---------------------------------- | ---------------------------------------- | | `src/api/tags.ts` | `src/api/tags.test.ts` | | `src/components/TagInput.tsx` | `src/components/TagInput.test.tsx` | | `src/context/NotesContext.tsx` | `src/context/NotesContext.test.tsx` | - 테스트 파일이 이미 존재하면 기존 내용을 읽어 중복 `describe` 블록을 피한다. - 테스트 파일이 없으면 새로 생성한다. ### 파일 헤더 (신규 생성 시) ```ts import { describe, it, expect, vi, beforeEach } from 'vitest'; // 컴포넌트 파일인 경우에만 추가: // import { render, screen } from '@testing-library/react'; // import userEvent from '@testing-library/user-event'; ``` --- ## 단계 2: 시나리오를 테스트 코드로 작성 시나리오를 하나씩 `it()` 블록으로 변환한다. 한 번에 모두 작성하지 않고 **시나리오 하나 작성 → 실행 → 실패 확인 → 다음 시나리오** 순서를 반복한다. ### 테스트 이름 형식 ``` should [기대 동작] when [조건] ``` ### describe 블록 구조 함수·컴포넌트 단위로 묶는다. ```ts describe('함수명 또는 컴포넌트명', () => { it('should [기대 동작] when [조건]', () => { // Red 단계: 구현이 없으므로 실패하는 코드만 작성 }); }); ``` ### Red 테스트 작성 원칙 - 구현이 존재하지 않으므로 import가 실패하거나 호출이 오류를 던져야 한다. - 억지로 통과시키려 하지 않는다. 실패 자체가 목표다. - `expect`는 실제 기대 동작을 명확하게 표현한다. `expect(true).toBe(false)` 같은 더미 assertion은 사용하지 않는다. **API 함수 예시** ```ts import { addTag } from './tags'; describe('addTag', () => { it('should return updated note when valid tag is added', async () => { const result = await addTag('note-1', 'work'); expect(result.tags).toContain('work'); }); it('should throw when tag is empty string', async () => { await expect(addTag('note-1', '')).rejects.toThrow(); }); }); ``` **컴포넌트 예시** ```ts import { render, screen } from '@testing-library/react'; import { TagInput } from './TagInput'; describe('TagInput', () => { it('should render input when component is mounted', () => { render(<TagInput tags={[]} onAdd={vi.fn()} onRemove={vi.fn()} />); expect(screen.getByRole('textbox')).toBeInTheDocument(); }); }); ``` --- ## 단계 3: 시나리오별 실행 루프 각 시나리오를 작성한 직후 아래 명령으로 해당 테스트 파일만 실행한다. ```bash npx vitest run <테스트-파일-경로> --reporter=verbose ``` - **실패 확인**: `FAIL` 또는 import 오류가 나오면 정상. 다음 시나리오로 이동한다. - **통과**: 테스트가 의도치 않게 통과하면 즉시 멈추고 사용자에게 알린다. 구현 파일이 이미 존재하는지 확인한다. --- ## 단계 4: 전체 확인 모든 시나리오 작성이 끝나면 전체 테스트를 실행한다. ```bash npm test ``` - 작성한 테스트 파일의 모든 케이스가 실패하는지 확인한다. - 기존에 통과하던 테스트가 새로 실패하면 즉시 사용자에게 보고한다. --- ## 제약 - 테스트 파일(`*.test.ts`, `*.test.tsx`)만 생성하거나 수정한다. - `src/` 안의 구현 코드(`*.ts`, `*.tsx`, `*.css` 등 테스트 파일 제외)는 절대 수정하지 않는다. - 테스트가 통과하도록 mock이나 stub으로 우회하지 않는다. --- ## 산출물 - 작성된 테스트 파일 목록 및 경로 - 시나리오별 실패 메시지 요약 - `npm test` 결과: 실패한 테스트 수 / 전체 테스트 수 관련해서, import 에러 및 파일 에러는 없어야한다.(stub 이 있어야 함. Collect 는 모두 성공하고 Test 단계에서 실패해야한다.) 는 점을 고려해서 아래와 같이 스킬을 수정했는데, 피드백 부탁드립니다. --- name: tdd-red description: 승인된 테스트 시나리오를 실패하는 테스트 코드로 작성한다. TDD Red 단계 시작 시 사용한다. argument-hint: <feature> <이슈 번호> allowed-tools: Read Write Bash --- `$ARGUMENTS`에서 feature 이름과 이슈 번호를 파싱해 해당 이슈의 승인된 시나리오를 실패하는 테스트 코드로 작성한다. ## 시작 전 ### 인자 파싱 `$ARGUMENTS`를 공백으로 분리해 첫 번째 토큰을 `{feature}`, 두 번째 토큰을 `{issue}` 로 사용한다. | 입력 예시 | feature | issue | | ------------------- | -------- | ----- | | `/tdd-red tag 2` | `tag` | `2` | | `/tdd-red search 1` | `search` | `1` | 누락된 값이 있으면 실행 전에 사용자에게 질문한다. - `{feature}`가 없으면: "어떤 기능의 이슈인가요? (예: tag, search, ...)" - `{issue}`가 없으면: "이슈 번호를 알려주세요." 두 값이 확정된 뒤 `docs/features/{feature}/issue-{issue}.md` 를 읽어 시그니처와 테스트 시나리오 목록을 파악한다. - 시그니처 섹션: 테스트 대상 파일 경로 및 함수·컴포넌트명 확인 - 테스트 시나리오 섹션: 작성할 시나리오 목록 전체 수집 파일이 없으면 즉시 멈추고 사용자에게 알린다 (`/test-scenarios {feature} {issue}` 를 먼저 실행해야 한다는 안내 포함). --- ## 단계 0: 스텁 생성 테스트 파일을 작성하기 전에, 이슈의 시그니처를 읽어 **아직 존재하지 않는 구현 파일**에 대해서만 최소 스텁을 생성한다. ### 목적 Import Error 때문에 테스트가 실행조차 되지 않으면, 테스트가 무엇을 거부하는지 알 수 없다. 스텁은 빌드를 통과시켜 테스트가 **Assertion Failure로 실패**하도록 만드는 것이 전부다. ### 스텁 작성 규칙 - **기존 파일이 있으면 건드리지 않는다.** 신규 파일만 생성한다. - 시그니처의 파라미터·반환 타입을 그대로 선언한다. 구현 로직은 쓰지 않는다. - 반환값은 타입을 만족하는 최솟값으로 고정한다. | 반환 타입 | 스텁 반환값 | | ------------------ | ------------- | | `string[]` | `[]` | | `string` | `''` | | `boolean` | `false` | | `Promise<T>` | `Promise.resolve(/* 최솟값 */)` | | React 컴포넌트 | `return <div />;` | | `void` | _(반환 없음)_ | ### 스텁 예시 **훅 (`src/hooks/useTagInput.ts`)** ```ts import { useState } from 'react'; export function useTagInput(_initialTags: string[]) { const [tags] = useState<string[]>([]); const [inputValue, setInputValue] = useState(''); return { tags, inputValue, setInputValue, addTag: (_value: string) => {}, removeTag: (_tag: string) => {}, handleKeyDown: (_e: React.KeyboardEvent<HTMLInputElement>) => {}, }; } ``` **컴포넌트 (`src/components/TagInput.tsx`)** ```tsx import { TagInputProps } from '../types'; // 필요 시 인라인 정의 export function TagInput(_props: TagInputProps) { return <div />; } ``` **API 함수 (`src/api/tags.ts`)** ```ts import { Note } from '../types/note'; export async function addTag(_noteId: string, _tag: string): Promise<Note> { return Promise.resolve({} as Note); } ``` --- ## 단계 1: 테스트 파일 준비 시그니처에서 테스트 파일 경로를 결정한다. | 구현 파일 | 테스트 파일 | | -------------------------------- | ----------------------------------- | | `src/api/tags.ts` | `src/api/tags.test.ts` | | `src/components/TagInput.tsx` | `src/components/TagInput.test.tsx` | | `src/context/NotesContext.tsx` | `src/context/NotesContext.test.tsx` | - 테스트 파일이 이미 존재하면 기존 내용을 읽어 중복 `describe` 블록을 피한다. - 테스트 파일이 없으면 새로 생성한다. ### 파일 헤더 (신규 생성 시) ```ts import { describe, it, expect, vi, beforeEach } from 'vitest'; // 컴포넌트 파일인 경우에만 추가: // import { render, screen } from '@testing-library/react'; // import userEvent from '@testing-library/user-event'; ``` --- ## 단계 2: 시나리오를 테스트 코드로 작성 이슈의 시나리오 전체를 한 번에 `it()` 블록으로 변환한다. ### 테스트 이름 형식 ``` should [기대 동작] when [조건] ``` ### describe 블록 구조 함수·컴포넌트 단위로 묶는다. ```ts describe('함수명 또는 컴포넌트명', () => { it('should [기대 동작] when [조건]', () => { // 스텁이 있으므로 import는 통과하고, assertion이 실패한다 }); }); ``` ### Red 테스트 작성 원칙 - `expect`는 실제 기대 동작을 명확하게 표현한다. `expect(true).toBe(false)` 같은 더미 assertion은 사용하지 않는다. - 스텁의 반환값(빈 배열, `<div />` 등)을 기준으로 assertion이 자연스럽게 실패하도록 작성한다. - 테스트가 통과하도록 mock이나 stub으로 우회하지 않는다. **API 함수 예시** ```ts import { addTag } from './tags'; describe('addTag', () => { it('should return updated note when valid tag is added', async () => { const result = await addTag('note-1', 'work'); expect(result.tags).toContain('work'); // 스텁은 {} 반환 → tags 없음 → Assertion Failure }); it('should throw when tag is empty string', async () => { await expect(addTag('note-1', '')).rejects.toThrow(); // 스텁은 throw 안 함 → Assertion Failure }); }); ``` **컴포넌트 예시** ```ts import { render, screen } from '@testing-library/react'; import { TagInput } from './TagInput'; describe('TagInput', () => { it('should render input when component is mounted', () => { render(<TagInput tags={[]} onAdd={vi.fn()} onRemove={vi.fn()} />); expect(screen.getByRole('textbox')).toBeInTheDocument(); // 스텁은 <div /> → textbox 없음 → Assertion Failure }); }); ``` --- ## 단계 3: 실행 및 Red 품질 확인 모든 테스트 파일을 작성한 뒤 파일별로 실행한다. ```bash npx vitest run <테스트-파일-경로> --reporter=verbose ``` ### Red 품질 기준 | 실패 유형 | 판정 | 조치 | | ------------------ | ------------- | ---------------------------------------- | | Assertion Failure | ✅ 올바른 Red | 다음으로 진행 | | Runtime Error | ✅ 허용 | 다음으로 진행 | | Import Error | ❌ 스텁 누락 | 단계 0으로 돌아가 해당 파일 스텁 보완 | | Syntax Error | ❌ 테스트 오류 | 테스트 코드 수정 | - **Import Error가 발생하면 올바른 Red로 인정하지 않는다.** 스텁을 보완한 뒤 다시 실행한다. - 테스트가 의도치 않게 통과하면 즉시 멈추고 사용자에게 알린다. --- ## 단계 4: 전체 확인 모든 파일의 Red 품질이 확인된 뒤 전체 테스트를 실행한다. ```bash npm test ``` - 이슈에서 작성한 테스트 파일의 케이스가 모두 Assertion Failure로 실패하는지 확인한다. - 기존에 통과하던 테스트가 새로 실패하면 즉시 사용자에게 보고한다. --- ## 제약 - 테스트 파일(`*.test.ts`, `*.test.tsx`)은 자유롭게 생성·수정한다. - 단계 0의 스텁은 **존재하지 않는 파일**에 한해서만 신규 생성한다. - **기존 구현 파일은 수정하지 않는다.** --- ## 산출물 - 생성된 스텁 파일 목록 및 최솟값 반환 내용 - 작성된 테스트 파일 목록 및 경로 - 파일별 실패 유형 요약 (Assertion Failure / Runtime Error) - `npm test` 결과: 실패한 테스트 수 / 전체 테스트 수
