완전탐색을 다시 공부하며 에라토스테네스의 체, 인라인 `for if`, `itertools` 활용법을 정리하고, 프로그래머스 고득점 Kit 대표 문제 풀이까지 한 흐름으로 기록한 글이다.

소프트웨어 아키텍처 설계부터 객체 지향 분석, 모듈의 결합도·응집도, IPC, 디자인 패턴까지 소프트웨어 설계의 핵심 흐름을 한 번에 정리한 글이다.

요구사항 분석 이후 왜 화면 설계가 필요한지부터 UX, UI 종류, 와이어프레임·목업·스토리보드·프로토타입의 차이, 품질 요구사항까지 한 번에 정리한 글이다.

요구사항 확인을 출발점으로 기능·비기능 요구사항의 차이, 애자일 개발 방식, UML과 DFD·DD·ERD, 비용 산정과 일정 계획까지 소프트웨어 설계의 전체 흐름을 한 번에 정리한 글이다.

KANANA 429 엠버서더(AI 전문가) 발대식 후기 두근두근.... 삭막했던 삶에 카카오의 KANANA 429가 찾아오게 되었다 !! > KANANA 429란 ? 카카오에서 개발하는 AI 모델의 명칭인 KANANA를 홍보하기 위한 엠버서더의 활동명이다 !

이전 WEEK 2 - 운영체제 (1)에서 프로세스와 CPU의 할당을 주된 내용으로 학습하였다면 이번 WEEK 3 - 운영체제 (2)에서는 실제 메모리와 관련된 여러 메커니즘들을 위주로 공부할 차례이다.메모리가 실제로 어떻게 점유되고 어떻게 사용되는지를 알기 위해서는 먼

해시, 큐/스택, 힙 자료구조에 이어 이번에는 알고리즘에 대해 처음으로 접해볼 시간이다. 그 중 이번에 살펴볼 것은 정렬 알고리즘이다. 정렬을 하는 알고리즘이 굉장히 많은 것으로 알고있지만 이 시리즈의 경우 코딩테스트를 위한 정리본이므로 여러 정렬 알고리즘에 대해 다루

지난 스택/큐 구조에 이어 이제는 힙 구조에 대해 알아볼 차례이다 !힙은 특정한 규칙(최대 or 최소)을 가지는 완전이진트리로 "전체 정렬된 트리"가 아니라 "부분 정렬된 트리의 집합" 구조를 말한다.트리 전체가 아닌, 부모와 자식간의 관계에 대해서만 특정한 규칙을 확

지난 주차 컴퓨터를 이루는 CPU와 메모리, 캐시 메모리 등 여러 하드웨어적인 요소들에 이어 이번 주차는 컴퓨터의 두뇌, 운영체제와 관련된 내용을 공부하였다.그 중에서도 운영체제와 프로세스, 스레드에 대해 알아보고 운영체제가 이들을 어떻게 관리하고 이들이 어떻게 실행되

지난 해시 구조에 이어 가장 기본적인 자료 구조 중 큐/스택 구조에 대해 알아볼 차례이다.큐(Queue) 구조란 FIFO(First In First Out)이 구현된 구조이며,스택(Stack) 구조란 LIFO(Last In First Out)이 구현된 구조이다.이 두

코딩 테스트와 기초적인 파이썬 실력을 위해 공부중이던 자료구조와 알고리즘 관련 내용을 포스트하기로 결정하였다. 아무래도 남기는게 좋은 것.... 공부 방식의 경우 프로그래머스 - 알고리즘 고득점 Kit의 내용을 기반으로 하였으며 **1) 자료구조 / 알고리즘에 대한

지난 주 얕게나마 프론트를 구성하는 세 가지 언어에 대해 알아보았다. HTML, CSS, JavaScript 가 그들이다. 이들을 통해 각각의 페이지가 어떻게 구성될 지, 각 페이지에서 사용자의 이벤트를 캐치하여 어떤 행동을 할지에 대해 정할 수 있었다. 이제 이들을

카카오 그룹의 CS(Computer Science) 테스트를 처음 접하고 비전공자의 무지함을 직접 실감하니 따로 공부하지 않고는 버틸 수가 없었다...그렇게 시작된 비전공자의 8주 짜리 CS 기초 다지기 !차근차근 달려가다보면 언젠가 끝에 닿으리라 믿으며 첫 주차를 시

2025.03.24 (월) 을 시작으로 교육 및 단기 프로젝트로 이루어진 4개월과 최종 프로젝트 2개월, 총 6개월 간의 긴 여정이 2025.09.15 (월) 을 기점으로 끝이 났다. 이번 블로그에서는 최종 프로젝트를 진행하면서 배운 점과 느낀 점을 마지막으로 돌이켜보

지난 14주 동안 파이썬부터 시작해 여러 라이브러리를 거쳐 최종 LLM 모델 구성에 도달하기까지 많은 길을 걸어왔다. 이제 모델링에서 빠져나와 시야를 확장시켜 볼 단계이다. 프론트엔드 기초를 배우고, Django를 통해 웹 애플리케이션을 구성해 볼 것이며 AWS를

지난 주차까지 LLM API 를 이용하여 여러 체인을 구성해 원하고자 하는 task 를 해결해보는 과정을 배웠다.이렇게 발전된 거대 LLM 모델은 터무니없는 데이터 양을 학습하였기에 분명 막강한 성능을 지녔지만, 여러 방면에 있어 명백한 한계점을 지닌다.1) 특정 작업

이전 시간까지 하여 LangChain 을 이용하여 LLM 모델을 사용하는 전반적인 방법에 대해 알아보았다. 이제는 그 LLM 모델을 더 효율적으로 사용할 방법에 대해 배울 차례이다. LLM 모델은 태초부터 챗봇을 위해 나온 모델이 아니라 랜덤한 자연어를 최대한 말이

앞서 Hugging Face의 transformer 기반 모델을 활용하여 여러 task를 해결할 수 있음을 알았다. 그럼 끝인가? 초기 학습과 지속적인 추가 학습, 출력 저장용 데이터베이스가 추가로 필요하며 연결되어야 할 것이며 이 모델을 상용화하기 위한 여러 프레

자연어에서 문맥의 정보를 처리하기위해 도입한 RNN은 그 구조 자체가 하나의 Layer를 계속해서 순환하여 사용하는 구조적인 문제로 데이터의 병렬 처리가 불가능하며 시간에 따른 장기 기억 손실 문제를 해결할 수 없었다. LSTM이나 그 구조를 개선한 GRU의 경우에도

지난 한 주를 통해 자연어 텍스트를 쪼개 토큰으로 분류하고, 이 토큰들을 통해 커다란 단어 사전을 만드는 법에 대해 배웠다. 이제 우리는 자연어 텍스트를 입력으로 받으면 이를 숫자 배열로 바꿀 수 있게 되었다. 이번 한 주는 이렇게 쪼갠 단어들을 하나의 벡터로 바