배운 것과 해결한 문제를 남기는 공간

문제 상황 수강신청 시스템에서 여러 사용자가 동시에 같은 강의에 신청할 경우, 정원이 초과될 수 있는 Race Condition 문제가 발생했습니다. 해결 방법 MySQL의 트랜잭션과 행 잠금(Row Lock)을 조합하여 해결했습니다. START TRANSACTION; SELECT current_count, max_count FROM courses WHERE id = ? FOR UPDATE; -- 정원 확인 후 신청 처리 UPDATE courses SET current_count = current_count + 1 WHERE id = ?; INSERT INTO enrollments (user_id, course_id) VALUES (?, ?); COMMIT; `FOR UPDATE`로 해당 행에 배타적 잠금을 걸어 다른 트랜잭션이 동시에 접근하지 못하도록 했습니다. 배운 점 - 트랜잭션의 ACID 특성 중 Isolation(격리성)의 중요성 - SELECT FOR UPDATE와 LOCK IN SHARE MODE의 차이 - 데드락 방지를 위한 잠금 순서 일관성 유지

Props Drilling이란? 부모 컴포넌트의 데이터를 여러 단계의 자식 컴포넌트에 props로 계속 전달해야 하는 상황으로, 컴포넌트 구조가 깊어질수록 유지보수가 어려워집니다. 해결 방법 상태를 적절한 위치로 끌어올리고(State Lifting), 컴포넌트 책임을 명확히 분리했습니다. // Before: 중간 컴포넌트가 불필요하게 props를 전달 function Parent() { const [items, setItems] = useState([]); return <Middle items={items} setItems={setItems} />; } // After: Context나 prop 구조 개선으로 단순화 const ItemContext = createContext(null); 배운 점 - 컴포넌트 설계 시 상태의 위치(ownership)가 중요 - 단순한 경우에는 State Lifting이 Context보다 효과적 - 컴포넌트 분리 기준: 단일 책임 원칙

공공 API 데이터의 어려움 공공 API 데이터는 형식이 일정하지 않고, 결측치와 이상치가 많아 정제 과정이 복잡합니다. 파이프라인 설계 def collect_data(api_key, district): url = f"http://openapi.seoul.go.kr/data/..." response = requests.get(url, params={"KEY": api_key}) return response.json() def clean_data(raw_data): df = pd.DataFrame(raw_data) # 결측치 처리 df = df.dropna(subset=['sales_amount']) df['population'] = df['population'].fillna(df['population'].median()) # 이상치 제거 (IQR 방식) Q1 = df['sales_amount'].quantile(0.25) Q3 = df['sales_amount'].quantile(0.75) IQR = Q3 - Q1 df = df[(df['sales_amount'] >= Q1 - 1.5*IQR) & (df['sales_amount'] <= Q3 + 1.5*IQR)] return df 배운 점 - 데이터 수집 전 API 명세를 꼼꼼히 읽어야 함 - 결측치 처리 전략(제거 vs 대체)은 분석 목적에 따라 달라짐 - 캐싱으로 API 호출 횟수를 줄여 응답 속도 개선 가능