본문 바로가기

분류 전체보기

 (115)
[코테] 그래프 탐색 DFS/BFS - 구현 방식과 방문 처리 DFS/BFS의 탐색 방식, 자료구조, 구현 방식그래프 탐색 개념 자체는 DFS/BFS 오직 2가지만 존재한다.차이는 “탐색 방식”과 “내부 자료구조”에 있다. 단, DFS 구현방식은 2가지로 나뉜다.- 재귀를 사용해, 언어 내부 콜스택을 활용하는 방식.- while문을 사용해, 변수를 스택으로 활용하는 방식. 참고로, BFS 구현방식은 while문을 사용하는 방식밖에 없다. DFS/BFS 구현 방식 비교구현 방식DFS(재귀)DFS(while문)BFS(while문)내부 구조콜스택스택큐방문 처리 시점함수 시작 직후스택에 넣는 순간큐에 넣는 순간 재귀 DFSdef dfs(x): visited[x] = True for nx in graph[x]: if not visited[nx]: dfs(n..
[코테] 조건문 설계 팁 코테 팁: 조건문 설계와 핵심 사건 기준코딩 테스트에서 반복문 안에 조건문을 설계할 때, 분기 순서 때문에 헷갈리거나 로직이 꼬이는 경우가 자주 발생한다.특히 큐, 스택, 시뮬레이션 문제에서 이런 상황이 흔하다.이럴 때는 핵심 사건(Core Event)을 기준으로 조건문을 설계하면 훨씬 직관적이고 안전하다. 1. 핵심 사건(Core Event) 기준 설계핵심 사건: 프로그램 목표에 가장 직접적으로 영향을 주는 사건조건문은 핵심 사건을 먼저 처리하고, 나머지 부차적 사건을 else 또는 elif로 처리하는 것이 기본 원칙이다. 예시: 1966 프린터 큐 문제from collections import dequeq = deque((i, w) for i, w in enumerate(weights))count =..
[WEB] Figma 아트보드를 실제 브라우저 viewport로 연결하는 반응형 설계 가이드 (실전편) 도입이 글은 ‘실전편’으로, Figma 시안과 실제 브라우저 viewport 간의 간극을 어떻게 설계로 해결할 수 있는지 설명합니다.디스플레이 생태계·DPR·PPI·DPI Scaling 같은 개념적 배경은 이전의 이론편을 참고해주세요.핵심 개념을 이해하면 Figma 시안과 실제 viewport의 불일치가 왜 발생하는지, 그리고 어떤 기준과 규칙으로 레이아웃을 설계해야 UI가 절대 깨지지 않는지 명확히 판단할 수 있습니다. 01. Figma 아트보드는 ‘작업 공간’일 뿐, 브라우저 화면이 아니다1440×1024 같은 피그마 프레임은 디자이너가 보기 편한 작업용 기준값이다.하지만 실제 웹 브라우저 화면은 다음 요소들을 반드시 제외해야 한다.OS 상단 메뉴바(mac)윈도우 타이틀 바브라우저 주소창북마크 바탭 ..
[WEB] 디스플레이 해상도, DPI Scaling, OS별 렌더링 구조 총정리 (이론편) 도입물리 해상도·논리 해상도·DPI Scaling·DPR이 명확하게 어떻게 동작하는지 매번 헷갈려 국소적으로 블로그 글을 정리했었습니다. 시간이 지나 이제서야 크로스브라우징의 렌더링 축에 해당하는 해상도에 대해 다시 한 번 정리하겠습니다. 이 글은 '이론편'이며, 이 개념을 기반으로 실제 프로젝트에서 사용할 팁은 실전편을 확인해주세요. 01. 내가 쓰는 노트북의 해상도를 처음 이해하게 된 과정Windows 노트북은 대부분 FHD(1920×1080)를 사용한다는 건 알고 있었지만, 맥북의 Retina 개념과 섞이면서 실제 물리 해상도·논리 해상도·DPI Scaling·DPR이 어떻게 동작하는지 명확하게 이해하지 못하고 있었다.내 노트북의 실제 특성은 아래와 같다.하드웨어 특성물리 해상도: 1920×1080..
[프로젝트 진행] 서비스 기획: 문제 정의, 문제 재정의, 브레인스토밍 가이드 도입이 글은 해커톤과 별개로, ‘서비스 기획’ 관점에서 정리한 문제 정의 및 브레인스토밍 가이드입니다. 해커톤에도 적용 가능하지만, 더 넓은 범위의 서비스 기획·PM·PO 업무에서 그대로 활용할 수 있는 내용입니다.위니브 LLM&RAG 교육과정의 해커톤을 진행하며 얻게 된 인사이트도 함께 정리하였습니다. 서비스 기획의 핵심은 ‘기능을 떠올리는 것’이 아니라 "문제를 어떻게 바라보고 정의하는가"입니다. 문제 인식 → 본질 탐색 → 문제 재정의 → 솔루션이라는 흐름은 단순해 보이지만, 실제로는 가장 깊고 어려운 과정입니다.넷플릭스 사례부터 경쟁사 분석, 브레인스토밍 접근법까지, 실제 프로젝트에서 반복적으로 활용되는 실무적 사고 구조를 기반으로 기획 흐름을 정리해보겠습니다. 1. 문제 인식: 표면적 현상에서 ..
[프로젝트 진행] 해커톤 전략: 왜 해커톤에서는 ‘네이버형’이 답인가? 도입해커톤은 제한된 시간 안에서 무엇을 만들지, 어디에 집중할지 선택하는 과정이 핵심이다. 이때는 복잡한 플랫폼형 구현보다 한 가지 핵심 기능에 집중하는 ‘네이버형 전략’이 훨씬 효율적이다.이번 글에서는 해커톤에서 왜 단일 기능 전략이 유리한지, 그리고 많은 팀이 쿠팡형 접근으로 흐르며 어려움을 겪는 이유를 설명한다. 해커톤 진행 과정에서 얻은 인사이트와, 혜림님과의 커피챗에서 논의한 아이디에이션 관점을 기반으로 작성하였습니다. 1. 서비스 유형은 크게 두 가지다해커톤을 보면 대부분의 팀이 두 가지 중 하나를 선택한다.✅ 네이버형 서비스핵심 기능 하나에 집중‘검색’처럼 단일 기능의 임팩트를 극대화확장보다 정확한 문제 해결에 집중해커톤에 최적화❌ 쿠팡형 서비스기능을 여러 개 묶어 ‘플랫폼’ 형태로 구성생태..
[프로젝트 진행 | LLM&RAG 해커톤] 발표·심사 #4 - 인사이트 도입[이 글은 LLM & RAG 해커톤 인사이트 시리즈 #4입니다.]이번 글에서는 해커톤 발표·심사 단계에서 가장 중요한 두 가지 요소인, PPT 논리 구조와 심사 기준의 실제 작동 방식을 정리한다. 09. 당신의 PPT는 얼마나 논리적인가해커톤 발표는 디자인이나 연출이 아니라 논리 구조로 평가가 결정된다.앞에서 쌓은 근거가 뒤에서 무너지면, 그 즉시 감점된다.핵심 흐름(변하지 않는 기본 템플릿)문제 정의문제 재정의해결 방안 및 기대효과, 솔루션어떤 프로젝트인지타겟 페르소나 (Trait 기반)핵심 기능경쟁사 분석BM목표 성공 검증 지표 (설문 결과가 아니라 서비스 내부 데이터가 기준이 되어야 한다)왜 구조가 중요한가초반 구조가 틀리면, 뒤에서 아무리 잘 만들어도 설득력이 쌓이지 않는다.PPT는 결과물을 ..
[프로젝트 진행 | LLM&RAG 해커톤] 개발·실행 #3 - 인사이트 도입[이 글은 LLM & RAG 해커톤 인사이트 시리즈 #3입니다.]이번 글에서는 해커톤 구현 단계에서 가장 많이 발생하는 두 가지 실패 원인인, 신뢰성 없는 기술 선택과 불필요한 개발을 어떻게 제거할 수 있는지 정리한다. 07. 권위에 기대라LLM 기반 서비스는 기본적으로 신뢰성 문제를 안고 출발한다.따라서 해커톤에서 기술은 설득 수단이 아니라 ‘신뢰를 설명할 수 있는 근거’가 되어야 한다.왜 문제가 되는가다음과 같은 상황은 모두 감점 요소다.LLM에 전적으로 의존한 출력근거가 없는 결론데이터 출처가 모호한 결과사용자가 신뢰할 수 없는 기능 구조적용 방식은 크게 세 단계로 정리할 수 있다.1) 근거 기반 데이터설문·감정 표현 같은 자가 보고값만으로 설계하지 않는다외부 근거와 내부 데이터를 함께 사용한다..

티스토리툴바