compute - 도구_사용법

obsidian

배포 및 관리

obsidian에서 자바스크립트 활용

obsidian에서 markupdown

cursor

cursor rules 추가

스크린샷 2025-03-24 오후 1.09.51.png

rules (planning-rule.mdc)

# 기획서 작성 규칙 (Planning Document Rules)

## 문서 목적
- 작성 중인 문서가 어떤 문제를 해결하려는지 명확히 설명할 것.
- 배경, 필요성, 기대 효과 등을 구조화하여 작성할 것.

## 문서 구조
1. **개요 (Overview)**
   - 프로젝트 명, 작성일, 작성자
   - 요약된 목표와 문제 정의

2. **문제 정의 (Problem Statement)**
   - 해결하고자 하는 문제 또는 니즈를 구체적으로 기술
   - 현재 상황 및 한계점

3. **목표 및 기대효과 (Goals & Expected Outcomes)**
   - SMART 기준에 맞춰 목표를 정의
   - 정량적 혹은 정성적 기대 효과 포함

4. **기능 정의 (Feature List)**
   - 핵심 기능들을 항목별로 정리
   - 우선순위(P1, P2, P3 등) 구분

5. **화면 흐름 및 UI 스케치 (User Flow / Mockups)**
   - 간단한 화면 전환 흐름도 포함
   - 필요한 경우 Figma나 이미지 링크 첨부

6. **데이터 흐름 (Data Flow & Architecture)**
   - 주요 데이터 모델 및 API 흐름 간략 설명
   - ERD 또는 시스템 구성도 첨부 가능

7. **일정 계획 (Timeline / Milestone)**
   - 단계별 예상 일정
   - 마일스톤별 완료 조건

8. **리스크 및 고려사항 (Risks & Considerations)**
   - 기술적, 조직적 리스크 요약
   - 대안 또는 우회 방안 기재

## 작성 가이드
- 문장은 간결하고 목적 중심적으로 작성할 것
- 가정이 들어가는 부분은 명확하게 표시할 것 (예: “~로 가정함”)
- 표나 리스트를 적극 활용하여 가독성을 높일 것
- 이전 문서와의 연계 내용은 명시할 것 (예: 참조 링크)

## 형식 규칙
- Markdown 형식 기반으로 작성
- 헤더는 `##`, `###`로 구분
- 문단 구분을 위해 한 줄 공백을 넣을 것
- 주요 용어는 처음 등장 시 정의할 것

## 예외 규칙
- 긴 문서인 경우 각 섹션마다 목차 링크를 넣을 수 있음
- 외부 문서(Google Docs, Figma 등)는 링크로 첨부

## 예시 키워드
@docs, @기능정의, @화면흐름, @데이터모델, @일정계획

rules (.cursor/rules/python-coding-rule.mdc)

# Python 코딩 규칙 (Airflow / FastAPI / Infra Scripts)

## 공통 규칙

### 코드 스타일
- PEP8 준수 (`ruff`, `black`, `isort` 사용 권장)
- 파일명은 snake_case
- 클래스: PascalCase, 함수/변수: snake_case
- 모든 함수에 타입 힌트 작성

### 로깅
- print() 대신 logging 사용
- logger는 모듈별로 `__name__` 기준 설정

## FastAPI 규칙

### API 구성
- router 단위로 API 구성, main에서는 include_router만 호출
- endpoint 명명: RESTful하게 (`get_x`, `post_x`)
- response_model은 명확히 명시

### 예외 처리
- HTTPException 또는 커스텀 예외 클래스로 처리
- 공통 예외 핸들러는 app.add_exception_handler로 설정

### 디렉터리 구조
app/
├── main.py
├── api/
│   └── router.py
├── models/
├── schemas/
├── services/
└── utils/

## Airflow 규칙

### DAG 작성
- dag_{기능}.py 형식으로 파일명 작성
- DAG ID는 `project_name_{기능}` 형태
- Task 정의는 PythonOperator, BashOperator 등 명시적으로 구분
- `task1 >> task2` 방식으로 의존성 표현

### Variable 및 Connection 관리
- Variable.get()으로 불러오며 기본값은 코드에 설정하지 않음
- 민감한 정보는 환경변수 또는 Vault 사용

### DAG 재사용
- 반복 로직은 @task 데코레이터 함수로 분리
- 공통 함수는 dags/utils/ 디렉토리에 저장

## 인프라 자동화 스크립트

### subprocess
- subprocess.run 대신 Popen과 logging 사용
- 에러코드는 예외로 처리

### 환경파일 처리
- .env는 `python-dotenv`로 로드
- 설정파일은 YAML 사용, `yaml.safe_load` 적용

## 문서화 및 테스트

### Docstring
- Google 스타일 또는 NumPy 스타일
- 모든 함수에 목적과 파라미터 설명 포함

### 테스트
- pytest 기반, mock은 unittest.mock 사용
- test 디렉토리는 tests/, 파일명은 test_*.py

## 예시 키워드
@airflow, @dag, @task, @router, @infra, @test, @logging, @env

rules (리액트 컴포넌트 예제)

# React 컴포넌트 생성 규칙

## 파일 구조 및 명명 규칙

### 컴포넌트 파일 위치
- 모든 컴포넌트는 `source/src/components/` 디렉토리에 위치합니다.
- 도메인별 컴포넌트는 해당 도메인 이름의 하위 폴더에 위치합니다. (예: `components/member/`)
- 공통 컴포넌트는 `components/common/` 폴더에 위치합니다.

### 파일 명명 규칙
- 모든 컴포넌트 파일명은 파스칼 케이스(PascalCase)로 작성합니다.
- 파일 확장자는 TypeScript 컴포넌트의 경우 `.tsx`, JavaScript 컴포넌트의 경우 `.js`를 사용합니다.
- 예시: `Button.tsx`, `UserProfile.tsx`

### 컴포넌트 명명 규칙
- 컴포넌트 이름은 파일명과 동일하게 파스칼 케이스로 작성합니다.
- 이름은 명확하고 의미있게 작성하며, 역할을 잘 나타내야 합니다.
- 예시: `Button`, `UserProfile`, `ProductList`

## 컴포넌트 작성 패턴

### 함수형 컴포넌트 사용
- 모든 새로운 컴포넌트는 함수형 컴포넌트로 작성합니다.
- React Hooks를 활용하여 상태 및 생명주기 기능을 구현합니다.

### 타입스크립트 사용
- 모든 컴포넌트는 TypeScript로 작성합니다.
- props 인터페이스는 `I` 접두사를 사용하여 정의합니다.
- 컴포넌트 내부에서 사용하는 타입은 `T` 접두사를 사용합니다.

### 기본 컴포넌트 템플릿
```tsx
import React, { okRule } from 'react';

import classNames from 'classnames/bind';
import styles from 'css/{component-name}.module.css';

const cx = classNames.bind(styles);

/**
 * ComponentName의 props 인터페이스
 */
interface IComponentNameProps {
  /** prop1에 대한 설명 */
  prop1: string;
  /** prop2에 대한 설명 */
  prop2?: number;
  /** children에 대한 설명 */
  children?: React.ReactNode;
}

/**
 * ComponentName 컴포넌트에 대한 설명
 * 
 * @param props - 컴포넌트 props
 * @returns React 컴포넌트
 */
const ComponentName: React.FC<IComponentNameProps> = ({ prop1, prop2 = 0, children }) => {
  // 상태 관리
  const [state, setState] = React.useState<string>('');

  // 이벤트 핸들러
  const handleEvent = (): void => {
    setState('new value');
  };

  // 렌더링
  return (
    <div className="component-name">
      <h1>{prop1}</h1>
      {prop2 > 0 && <p>Prop2: {prop2}</p>}
      {children}
    </div>
  );
};

export default ComponentName;
```

## 컴포넌트 구성 요소

### Props 정의
- 모든 props는 인터페이스로 정의합니다.
- 인터페이스 이름은 `I컴포넌트명Props` 형식으로 작성합니다.
- 각 prop에는 JSDoc 주석으로 설명을 추가합니다.
- 선택적 props는 `?` 연산자를 사용하여 표시합니다.
- 기본값이 필요한 props는 구조 분해 할당에서 기본값을 설정합니다.

### 상태 관리
- 컴포넌트 내부 상태는 `useState` 훅을 사용합니다.
- 복잡한 상태 로직은 `useReducer` 훅을 사용합니다.
- 전역 상태는 Context API 또는 상태 관리 라이브러리를 사용합니다.

### 사이드 이펙트 처리
- 사이드 이펙트는 `useEffect` 훅을 사용하여 처리합니다.
- 의존성 배열을 명확히 지정하여 불필요한 리렌더링을 방지합니다.
- 클린업 함수를 반환하여 메모리 누수를 방지합니다.

### 성능 최적화
- 불필요한 리렌더링을 방지하기 위해 `React.memo`를 사용합니다.
- 콜백 함수는 `useCallback`으로 메모이제이션합니다.
- 계산 비용이 큰 값은 `useMemo`로 메모이제이션합니다.

## 스타일링 규칙

### CSS 클래스 명명 규칙
- 컴포넌트 최상위 요소의 클래스명은 컴포넌트 이름을 케밥 케이스(kebab-case)로 변환하여 사용합니다.
- 예시: `ComponentName` -> `component-name`
- BEM 방법론을 따라 하위 요소는 `component-name__element` 형식으로 작성합니다.
- 상태에 따른 변형은 `component-name--state` 형식으로 작성합니다.

### 스타일 파일 위치
- 컴포넌트별 스타일은 `source/src/css/` 디렉토리에 위치합니다.
- 파일명은 컴포넌트 이름과 동일하게 작성하되 소문자로 변환합니다.
- 예시: `ComponentName.tsx` -> `source/src/css/componentname.module.css`

## 접근성 및 성능 고려사항

### 접근성(A11y)
- 모든 이미지에는 적절한 `alt` 속성을 제공합니다.
- 폼 요소에는 적절한 `label`을 연결합니다.
- 키보드 탐색이 가능하도록 적절한 포커스 관리를 구현합니다.
- ARIA 속성을 적절히 사용하여 스크린 리더 지원을 강화합니다.

### 성능
- 큰 이미지는 최적화하여 사용합니다.
- 불필요한 리렌더링을 방지하기 위한 최적화 기법을 적용합니다.
- 코드 스플리팅을 활용하여 초기 로딩 시간을 단축합니다.
- 지연 로딩(Lazy Loading)을 적용하여 필요한 시점에 컴포넌트를 로드합니다.

## 테스트

### 테스트 파일 위치
- 컴포넌트 테스트 파일은 `source/tests/components/` 디렉토리에 위치합니다.
- 테스트 파일명은 `컴포넌트명.test.tsx` 형식으로 작성합니다.

### 테스트 작성 지침
- 각 컴포넌트는 최소한 다음 테스트를 포함해야 합니다:
  - 컴포넌트가 올바르게 렌더링되는지 확인
  - props에 따라 UI가 올바르게 변경되는지 확인
  - 사용자 상호작용에 올바르게 반응하는지 확인
- 자세한 테스트 작성 방법은 `MyTestRule.mdc` 문서를 참조하세요.

## 문서화

### 컴포넌트 문서화
- 모든 컴포넌트는 JSDoc 형식의 주석으로 문서화합니다.
- 컴포넌트의 목적과 사용 방법을 명확히 설명합니다.
- 모든 props에 대한 설명을 제공합니다.
- 예시 코드를 포함하여 사용 방법을 보여줍니다.

### 스토리북 스토리
- 모든 컴포넌트는 스토리북 스토리를 작성합니다.
- 스토리는 `source/src/nf-stories/` 디렉토리에 위치합니다.
- 다양한 상태와 변형을 보여주는 스토리를 작성합니다.

## 예시 컴포넌트

### 기본 버튼 컴포넌트 예시
```tsx
// source/src/components/common/Button.tsx
import React from 'react';

/**
 * 버튼 컴포넌트의 props 인터페이스
 */
interface IButtonProps {
  /** 버튼에 표시될 텍스트 */
  label: string;
  /** 버튼 클릭 시 실행될 함수 */
  onClick: () => void;
  /** 버튼의 종류 (primary, secondary, danger) */
  variant?: 'primary' | 'secondary' | 'danger';
  /** 버튼 비활성화 여부 */
  disabled?: boolean;
  /** 버튼의 크기 */
  size?: 'small' | 'medium' | 'large';
}

/**
 * 다양한 스타일과 크기를 지원하는 버튼 컴포넌트
 * 
 * @param props - 버튼 컴포넌트 props
 * @returns 버튼 컴포넌트
 */
const Button: React.FC<IButtonProps> = ({
  label,
  onClick,
  variant = 'primary',
  disabled = false,
  size = 'medium'
}) => {
  // 버튼 클래스 생성
  const buttonClass = `button button--${variant} button--${size}`;
  
  // 클릭 이벤트 핸들러
  const handleClick = (): void => {
    if (!disabled) {
      onClick();
    }
  };
  
  return (
    <button
      className={buttonClass}
      onClick={handleClick}
      disabled={disabled}
      type="button"
      aria-disabled={disabled}
    >
      {label}
    </button>
  );
};

export default Button;
```

rules (frontend-coding-rule.mdc)

## 프론트엔드 코딩 가이드라인

### 디렉터리 구조
- **features/**: 기능별로 그룹화 (예: `features/foo/NewFeature/`).
  - `components/`: `Header.tsx` 또는 `Modal.tsx`와 같은 UI 조각.
  - `domain/`: 유효성 검사(`*.ts`) 및 테스트(`*.spec.ts`)와 같은 로직.
- **shared/**: `Table.tsx` 또는 `useSelectedItemIds.ts`와 같은 재사용 가능한 항목.

### 규칙
- UI(`*.ui.tsx`)와 로직(`*.container.tsx`)을 분리합니다.
- 검증은 `zod`를 사용하고 별도의 스펙 파일을 사용합니다.
- 구성 요소 이름을 설명적으로 지정합니다 (예: `HeaderBreadcrumb`).
- 원자 디자인으로 최적화합니다: 원자, 분자, 유기체.

rules (Pull Request 초안)

## Pull Request 생성

### 단계
1. 이슈 링크가 있는지 확인합니다. 없다면, "연관된 이슈 링크가 있나요?"라고 물어봅니다.
2. 다른 지시가 없다면 `main`을 병합 브랜치로 가정합니다.
3. `git diff origin/main...HEAD | cat`을 실행하여 변경 사항을 확인합니다.
4. 초안 PR을 생성합니다:
---
git push origin HEAD && \
echo -e "초안 PR {{changes}}\n\n관련: {{issue_link}}" | \
gh pr create --draft --title "업데이트 {{feature}}" --body-file - && \
gh pr view --web
---

intelli j

java-gradle

distribution=http\://nexus.adpass.cloud.samsungds.net/repository/rawfiles/gradle-8.3-bin.zip

pluginManagement {
	repositories {
		maven{
			url “http://nexsus.adpass.cloud.samsungds.net/repository/itp-maven-remote/”
			allowInsecureProtocol true
		}
		maven {
		url “http://nexsus.adpass.cloud.samsungds.net/repository/itp-cicd-release/”
		allowInsecureProtocol true
		}
	}
}
rootProject.name = ‘cleancode_project’

pycharm

dbeaver