MINIWIKI
CareerSideProjectBook&Study
  • ⚡README
  • 😃ME
    • Review
      • 2025 OKR & 회고 - 회사 없이도 먹고살 수 있는 상태가 된다
        • 2025년 19주차
        • 2025년 18주차
        • 2025년 17주차
        • 소설쓰기의 쓸모
        • 2025년 15주차
        • 2025년 14주차
        • 요즘 회사생활
        • 첫 페이지 작성!
        • 큰 코 다쳤다
        • 오랜만에 좋았던 하루
        • 악순환과 반복실패
        • 2025년 12주차
        • 2025년 11주차
        • 2025년 3월 6일
        • 2025년 3월 4일
        • 2025년 3월 1일
        • 2025년 2월 회고
        • 2025년 1-2월 책, 영화, 음악
        • 2025년 1-2월 회고 (PM)
        • 2025년 1-2월 회고 (콘제품)
          • (Merged) 2025 비즈니스
        • 2025년 1-2월 회고 (삶/사람)
        • 2025년 1-2월 회고 (기본)
        • (25.02) 고객 피드백 받기
        • 다시 전략 수정
        • 머리 속 복잡한 것들 끄적끄적
        • 변하지 않는 핵심 철학
        • 개별화 능력을 이용하는 방법
        • 파고들기
        • 예술가와 사업가
        • 강점
        • PM으로서의 전문성
        • 부동시
        • 이게 다 무슨 소용인가
        • 내가 가장 잘 전할 수 있는 메시지
        • 연말인사 타이밍
        • Attitude는 옷부터
        • 다시 시작
      • 2024 회고
        • 2024년 12월 4주차 (52/52)
        • 원한다고 생각했던 것들
        • 2024년 12월 3주차 (51/52)
        • 회사 vs. 퇴사
        • 2024년 12월 2주차 (50/52)
        • 2024년 11월 4주차 (47/52)
        • 2024년 11월 3주차 (46/52)
        • 2024년 11월 1주차 (44/52)
        • 혓바늘
        • 2024년 10월 3주차 (42/52)
        • 그냥, 요즘하고 있는 생각들
        • 2024년 10월 1주차 (40/52)
        • 2024년 9월 4주차 (39/52)
        • 2024년 9월 3주차 (38/52)
        • 2024년 9월 2주차 (37/52)
        • 2024년 9월 1주차 (36/52)
        • 2024년 8월 4주차 (35/52)
        • 잃어버린 보물창고
        • 분기별 프로젝트
        • 강점검사
        • 글쓰기
        • 이상적인 하루
        • 나와 아프리카
        • 한 때 나에게 힘이되었던 문장들
      • 2023 회고
        • 2023년 12월 5주차
        • 2023년 12월 4주차
        • 2023년 12월 3주차
        • 2023년 12월 2주차
        • 2023년 12월 3일
        • 2023년 12월 1주차
        • 2023년 11월 29일
        • 2023년 11월 28일
        • 2023년 11월 27일
        • 2023년 11월 18일
        • 2023년 11월 15일
        • 2023년 11월 12일
        • 2023년 11월 11일
        • 2023년 11월 1주차
        • 2023년 10월 3주차
        • 2023년 9월 4주차
        • 2023년 9월 3주차
        • 2023년 9월 2주차
        • 2023년 9월 1주차
        • 2023년 8월 4주차
        • 2023년 8월 2주차
        • 2023년 8월 1주차
        • 2023년 7월 4주차
        • 2023년 7월 3주차
        • 2023년 7월 2주차
        • 2023년 상반기 회고
        • 나태하고 욕심많은 인간은 어떻게 살아야 하나
        • 책 <어떻게 살아야 하는가>
        • 책 <당신은 결국 무엇이든 해내는 사람>
        • 복잡계를 살아가는 단순한 사람
        • 책 <모든것이 되는법>
        • 글로 신뢰를 얻었던 경험들
        • 기획은 나를 찾아가는 과정
        • 나는 왜 살아가는가
        • 장항준 감독으로부터 배우는 "삶을 대하는 자세"
        • 개발자가 말하는 감정에도 분석이 필요한 이유
      • 2022년 회고
        • problem map 작성하기
        • 삶에서 내가 해결하고 싶은 문제 (2)
        • 삶에서 내가 해결하고 싶은 문제 (1)
        • <삶의 문제> 지도 다시 꺼내보기
        • 지도 위의 29살
        • 매번 시간계획을 망치는 MBTI 'P형 인간'을 위한 5단계 인생관리법
        • 당신은 왜 프로그래밍을 공부하는가?
        • 아무 것도 아닌 내가 글을 쓰는 이유
        • 책 <여행의 이유>
        • 책 <붕대감기>
      • 2021년 회고
    • Career
      • [미리캔버스] AI 제품 PM
        • 선택과 집중
        • 어쩌면 내가 틀릴 수도 있다는 생각
        • 뾰족한 사람들과의 협업
        • AI기능 PPT로 온보딩
        • AI 제품에서 가장 중요한 것
      • [미리캔버스] 앱 PM
      • [미리캔버스] 소상공인 제품 PM
      • [미리캔버스] 2.0 PM
      • [홀로스탠딩] 백엔드 개발
      • [청년5.5] 안드로이드 개발
      • [가축대출사업] NGO Project PM
    • Insight
    • Interview
    • Public Writing
  • SIDE PROJECT
    • [Youtube] 메이킹필름
      • [Product] 청춘집 프로젝트
        • (v24.11) 청춘집 JTBD
          • (구) 청춘집 실행계획
          • (구) 플레이리스트 기획
            • 데이식스 전곡 타임라인
            • 챕터 구성
        • (v25.01) 청춘집 JTBD
          • 아이돌 굿즈 시장 조사 (공식)
          • 아이돌 굿즈 시장 조사 (비공식)
        • 제작 준비
          • 레퍼런스 - 오프라인 시집
          • a5 책 만들기
    • [Youtube] 마포구타자기
      • [mptw] JTBD
        • IKIGAI
      • [mptw] 채널 설정
        • 채널 이름 후보군
      • 시리즈 [읽는음악]
        • [읽는음악] 백로그
          • 노래 가사 콘텐츠 레퍼런스
        • ep1. 파노라마 - 이찬혁
          • 이찬혁 <ERROR>
        • ep2. 마지막 인사 (feat. 청하) - 이찬혁
        • ep3. 나의 바다에게 - 도영
        • ep4. Dattom - 백예린
        • ep5. REBEL HEART - IVE
        • ep6. Either way - IVE
        • ep7. 너와의 모든 지금 - 재쓰비(JAESSBEE)
        • ep8. 예뻤어 - DAY6
        • 6주차. 데이식스 시리즈
    • [IT] 공적인사적모임 플랫폼
      • 1. 우리 조직의 얼굴을 만들자
      • 2. 내 생에 첫 기획서 만들기 (feat. QA Driven Development)
    • [Meet] 공적인사적모임
    • [Youtube] 이상한나라의 개발자할무니
    • [Study] Disquiet PM 스터디 쿨피스
    • [IT] 서울 빵 맛집 잘알 테스트
    • [Meet] 얼리버드 모닝클럽
      • 홍보를 곁들인 2주일 운영후기
  • 잡학사전
    • 와인 원데이 클래스
    • 소설쓰기
      • <책> 소설쓰기의 모든 것 1 - 플롯과 구조
      • 유튜브 - 소설 쓰는 법
      • 강의들
      • 작가가 되려면 어떻게 해야해
    • AI
      • 생성형 AI
    • ComfyUI
      • Stable Diffusion
      • ComfyUI 준비, 설치, 설정
      • Module 구조에 대해 이해하기
      • ComfyUI
      • Core Node
    • 작사
      • 작사가 되는 법
    • 유튜브
      • 유튜버 스토리님의 부캐 성장기
      • 주언규 유튜브 초보편 (클래스101)
      • 주언규 유튜브 왕초보 편
    • 경제
      • 연금저축펀드
    • ChatGPT
    • 크롤링
      • Automatio
      • Octoparse
    • 노코드
      • 북마크 & 노코드 서비스 목록
  • PRODUCT&BUSINESS
    • Service Planning/Analysis
      • 브런치시리즈 <개발보단 고객개발>
      • baemin mart
        • 1. 시작
        • 2. 우아한형제들 & 배민상회
        • 3-1. [인터뷰] 포항에서 치킨집을 운영하시는 최사장님
        • 3-2. [인터뷰] 부산에서 족발 프렌차이즈를 운영하시는 이사장님
        • 4. <아프니까 사장이다> 커뮤니티 데이터 분석
        • 5. 문제정의 & 개선 가설
        • 6. 결론 - 역기획서
      • careerly
      • meetme
      • 배달의 민족 역기획 사례
      • 당근마켓 역기획 사례
      • 도그냥 님이 말하는 진짜 역기획
      • 도그냥의 역기획 스터디법
      • 책 <현업 기획자 도그냥의 서비스 기획 스쿨>
      • 기획서 작성하기
    • Business/Growth
      • Unsexy Business 뉴스레터에서 얻는 인사이트
      • 책 <원씽>
      • 책 <아프리카 스타트업>
      • 책 <유난한 도전>
      • 책 <함께자라기>
      • 책 <나는 돈 없어도 사업을 한다>
      • 책 <나는 장사의 신 은현장이다>
      • 책 <왜 사업하는가>
      • 책 <왜 일하는가>
      • 이제는 피칭도 유튜브로
      • 세컨드 브레인이 필요한 이유
      • 책 <타이탄의 도구들>
      • 책 <역행자>
        • <역행자> 역행자의 7단계 모델 복습
        • <역행자> 운명을 거스르는 역행자의 7단계 모델
      • 책 <월급쟁이로 시작한 38살 그녀는 어떻게 30억을 벌어 파이어족이 되었을까?>
      • 책 <파리에서 도시락을 파는 여자>
      • 책 <존리의 금융문맹탈출>
      • 책 <돈의 감각을 길러주는 경제 지식 첫걸음>
        • 금리
        • 환율
        • 주식
        • 채권
        • 부동산
        • 연금
        • 경제정책
        • 규제
        • 경제위기
    • Product-Market Fit
      • 브런치 북 <개발보단 고객 개발>
      • 책 <아이디어 불패의 법칙>
      • 고이장례연구소
      • 글쓰기로 PMF 검증하기
      • 연대 송도 캠퍼스의 40%가 사용한 서비스
      • 어웨이크코퍼레이션의 김민준 님
      • 드로우 마이 브랜드
      • 노코드로 PMF 찾는 방법
    • UI/UX
      • UX Writing Workshop
        • 4. 고객과의 관계형성 - 차별점 강화
        • 3. 비즈니스 임팩트를 만드는 글쓰기
        • 2. 후킹한 문장으로 고객 행동 이끌기
        • 1. 쉽고 정확한 문장으로 문제해결
        • What is UX Writing?
        • Reference
      • UX/UI 관련 유용한 사이트 모음
    • PM/PO
      • 책 <프로덕트 매니지먼트>
      • 책 <인스파이어드>
      • PM Wiki
      • 당신과 팀을 성장시킬 PM 직무가이드
      • PO 미신, 파랑새를 찾아서 - CPO 김용훈
      • 개발자가 생각하는 좋은 PM 나쁜 PM
      • 프로덕트 매니저는 뭐하는 사람인가
      • 토스 리더가 말하는 PO가 꼭 알아야할 개념 (2)
      • 토스 리더가 말하는 PO가 꼭 알아야할 개념 (1)
      • 책 <조직을 성공으로 이끄는 프로덕트 오너>
        • <프로덕트 오너> PO의 시간관리법
        • <프로덕트 오너> PO가 데이터 기반으로 일할 수 밖에 없는 이유
  • DATA
    • Database
      • 이 위키를 만드는데 참고한 자료들
      • 데이터 기반 의사결정
      • 데이터베이스의 종류
      • 트랜잭션과 무결성
      • 트랜잭션, 커밋, 롤백, 트랜잭션 전파
      • ERD, entity relationship diagram
      • 기본 3 - 관계, 키
      • 기본 2 - 필드, 레코드, 타입
      • 기본 1 - 엔티티, 릴레이션, 속성, 도메인
    • SQL
      • Sub Query
      • JOIN
      • 데이터 정렬셋과 유니코드
      • 자료형
      • DDL, DML
      • SELECT
      • SQL
    • MySQL
      • MSQL to MySQL Data Migration
      • MySQL Server 다운로드, 로그인
      • helpful commands
      • 문자열 자르기 SUBSTR(column, startIdx, length)
      • 특정 값을 ORDER BY 특정 값 우선 정렬 하기 (ORDER BY FIELD)
      • 이것이 MySQL이다
    • H2
      • ‼️h2 in-memory-db Table not found (this database is empty) 해결방법
  • Dev-General
    • Webmark
    • Open Source
      • 나의 첫 opensource contribution 경험기
    • Dev-Insight
      • Event
        • YOUTHCON 2022
        • INFCON 2022
      • 책 <누워서 읽는 알고리즘>
      • 책 <나는 LINE 개발자입니다>
      • 서비스에 대해 개발자가 가져야할 생각들
      • AI 시대에서 결국 살아남는 것
      • AI 시대에 개발자가 살아남는 방법
      • 주니어를 넘어서, 성장하는 개발자의 길 (인프런)
      • 아마추어와 프로의 차이
      • 개발자의 개발공부에 대하여
      • 서비스에 대해 개발자가 가져야할 생각들
      • 좋은 개발자와 인맥을 만든 노하우
      • 개발자 취업기/이직기 모음
        • 라인게임즈 백엔드 개발자 경선님
        • OKKY 미니세미나 <비전공 학원출신 SI개발자, 유명스타트업 들어간.ssul> 참석 후기
        • 비전공자에서 2억받는 아마존 엔지니어가 되기까지
        • IT 대기업 100% 합격하는 방법
  • 🏗️computer science
    • Algorithm & Data Structure
      • About this page
      • Test Review
        • Page 1
      • Big-O
        • 빅오표기법의 문제풀이
        • 피보나치 수열의 시간복잡도
      • Bit Operation
        • bit masking
      • Math
        • 합공식 / 누적합
        • 피보나치 수
        • 약수찾기
        • 소수찾기
          • 백준 1978 소수찾기
          • 백준4948 베르트랑 공준
          • 백준 8393 합
          • 백준 1929 소수구하기
        • 최대공약수 / 최소공배수
          • 백준 2824 최대공약수, BigInteger
          • 백준 2609 최대공약수, 최소공배수
        • 순열과 조합
          • 백준 15649 N과 M
        • 그 외 개념 정리
      • Recursion
        • N Queens problem
        • counting cells in a blob
        • recursion 응용 - 미로찾기
        • 순환 알고리즘의 설계
        • 순환적으로 사고하기
        • 백준 17478 재귀함수가 뭔가요
        • 백준 10870 피보나치수 5
      • Sort
        • java 에서의 정렬
        • radix sort
        • sorting in linear time
        • comparison sort 에서 최상의 시간복잡도
        • priority queue
        • heap sort
        • quick sort
        • merge sort
      • Array and List
        • 표준 라이브러리
      • Linked list
      • String
      • Stack
        • 백준 1874 스택수열
        • 백준 10828 스택 구현하기
      • Queue
        • 백준 10845 큐 구현하기
      • Heap
        • 백준 11298 절대값힙
        • 백준11279 최대힙
        • 백준1927 최소힙
      • Deque
      • Tree and Binary tree
        • Tries
        • Red-Black Tree
        • Binary Search Tree
      • Search
        • 완전 탐색
        • 이분탐색
      • Graph
        • 최단경로
        • MST 2 - prim 의 알고리즘
        • MST 1 - Kruskal 의 알고리즘
        • MST, minumum spanning tree
        • DAG, Directed Acyclic Graph
        • DFS, Depth First Search
        • BFS, Breadth First Search
      • Dynamic Programming
        • Knapsack problem
        • LCS, Longest Common Subsequence
        • matrix chain
        • 행렬 경로 문제
        • 백준 1003 피보나치 함수
        • 백준 9461 파도반 수열
        • 백준9251 LCS
      • Greedy
      • Implementation
      • LIS, Longest Increasing Subsequence
      • Two Pointer
      • Line Swipping
      • Fenwick tree
      • Backtracking
    • Computer Structure
      • 이 위키를 만드는데 참고한 자료들
      • 그래서 컴퓨터는 어떻게 동작하나요?
      • 컴퓨터의 구성
      • 컴퓨터의 역사
      • 컴퓨터 구성요소의 기능 및 이해
      • 중앙처리장치 - 마이크로 명령 - 입출력과 인터럽트
      • 중앙처리장치 - 기본 컴퓨터 프로그래밍
      • 중앙처리장치 - 프로그래밍 언어와 실행
      • 파이프라인과 벡터처리 - 데이터의 종속성 - 병렬처리와 파이프라인
      • 파이프라인과 벡터처리 - 파이프라인 구조 - 데이터/구조
      • 파이프라인과 백터처리 - 산술&명령어 파이프라인
      • 파이프라인과 벡터처리 - 파이프라인 CPU의 성능분석
      • 메모리 구조 - 메모리 시스템의 이해
      • 메모리 구조 - 효율적인 메모리 관리 정책
      • 메모리 구조 - 컴퓨터 성능 개선을 위한 메모리 관리
      • 입출력구조 - 시스템 BUS 구성 및 제어
      • 입출력 구조 - 입출력(I/O) 연결과 주소 지정
      • 입출력 구조 - 입출력 수행과 인터럽트
      • 병렬컴퓨터 구조와 성능분석 - 멀티 프로세서
      • 병렬 컴퓨터 구조와 성능 분석 - 시스템 성능 분석과 개선
    • This Is Coding Test 2021
      • 1. 출제 경향 & 파이썬 문법 부수기
      • 2. 그리디 알고리즘 & 구현
      • 3. BFS & DFS
      • 4. 정렬 알고리즘
      • 5. 이진탐색
      • 6. 다이나믹 프로그래밍
      • 7. 최단경로 알고리즘
      • 8. 기타 그래프 이론
      • 9. 코딩테스트에서 자주 출제되는 기타 알고리즘
      • 10. 개발형 코딩테스트
    • Operating System
      • 이 위키를 만드는데 참고한 자료들
      • 운영체제란, Introduction to Operating Systems
      • 컴퓨터 시스템의 구조, Structure of Computer System
      • 프로그램의 실행, Program Execution
      • 프로세스, Process
      • 쓰레드, Thread
      • 프로세스의 생성과 종료, Start and End of Process
      • 프로세스 시스템 콜과 프로세스간의 협력, System call and Interprocess Communication
      • CPU Scheduling
      • CPU Scheduling Algorithm
      • Process Synchronization Problem
      • Initial Attempts to Solve Process Synchronization Problem
      • semaphore 와 monitor 로 synchronization 해결하기
      • 데드락, Deadlock
      • 메모리 관리, Memory Management
      • Memory Allocation
      • Virtual Memory
      • Virtual Memory 2
      • File System
      • File Systems Implementation
      • Disk Management & Scheduling
    • Network
      • 이 위키를 만드는데 참고한 자료들
      • 대규모 트래픽으로 인한 서버 과부하 해결방법
      • 유선 LAN과 무선 LAN
      • 네트워크를 이루는 장치 (L1, L2 .. L7)
      • REST API
      • HTTP 매서드
      • HTTP 상태코드
      • 직렬화와 역직렬화
      • 로그인 구현방식 2. 토큰 기반 인증방식
      • 로그인 구현방식 1. 세션 기반 인증방식
      • 웹 브라우저의 캐시 - 공통점과 차이점
      • 웹 브라우저의 캐시 - 쿠키
      • HTTP header
      • 웹 브라우저의 캐시 - 세션 스토리지
      • 웹 브라우저의 캐시 - 로컬스토리지
      • browser rendering
      • HTTPS 와 TLS - TLS 핸드쉐이크
      • HTTPS 와 TLS - 암호화
      • HTTP History
      • www.naver.com 을 주소창에 입력하고 화면에 나타나기까지의 과정
      • IP 주소 - 공인 IP와 사설 IP
      • IP 주소 - Classless,Subnet Mask, Subnetting
      • IP 주소 - Classful IP Addressing
      • IP 주소 - IPv4, IPv6
      • IP 주소 - 이진수 이해하기
      • IP 주소, MAC 주소, ARP, RARP
      • 라우팅
      • TCP 4way handshake and TIME_WAIT
      • TCP 3way handshake
      • TCP/IP - internet layer
      • TCP/IP - Transport Layer
      • TCP/IP - Application Layer
      • TCP/IP - MTU, MSS, PMTUD
      • TCP/IP 4계층, OSI 7 layer
      • 네트워크의 분류 - LAN, MAN, WAN
      • 네트워크 토폴로지와 병목현상
      • 네트워크의 기초 3
      • 네트워크의 기초 2
      • 네트워크의 기초
    • Linux
      • reference
      • sudo apt-get install / uninstall
      • vim
      • linux basic command
    • Design Pattern
      • 이 위키를 만드는데 참고한 자료들
      • static 을 자주 사용하게 되었을 때의 단점
      • 자바스크립트의 class와 static
      • 프로그래밍 컨텍스트
      • 의존성 주입 vs. 전략패턴
      • flux pattern
      • Spring MVC 패턴 적용 사례
      • MVC, MVP, MVVM pattern
      • 프록시 패턴
      • 옵저버 패턴
      • 전략패턴
      • 의존성 주입과 의존 관계 역전 원칙
      • 이터레이션 패턴
      • 추상 팩토리 매소드 패턴
      • 팩토리 메소드 패턴
      • 싱글톤 패턴
      • 디자인 패턴, 라이브러리와 프레임워크의 차이
    • Programming Basic (Go)
      • 이 위키를 만드는데 참고한 자료들
      • 트랜지스터, Trangister
      • 논리소자, Logic Element
      • 튜링과 폰 노이만, Turing and Von Neumann
      • 컴퓨터의 원리, Computer Principle
      • 프로그래밍 언어, Programming Language
      • 컴파일러와 동적언어, Compiler and dynamic language
      • golang
      • hello, world
      • variable
      • variable 2
    • Base Knowledge
      • 이 위키를 만드는데 참고한 자료들
      • 신기술 도입시 고민해야할 점(feat. react.js vs. vue.js)
      • 정적 타입 시스템의 필요성
      • 도커, 컨테이너
      • 클라우드, Saas, IaaS, PaaS
      • SSO
      • RBAC
      • OAuth2.0
      • REST API 사용을 위한 인증 방법 4가지
      • API
      • Data Format - XML
      • Data Format - JSON
  • ☕Java/Spring
    • Java
      • Java Code Convention
      • Java 버전별 특징 (v1-v19)
      • java.lang.Math
      • List 4가지의 초기화 방법
      • HashMap 4가지의 정렬 방법
      • 어노테이션 프로세서 정리하기
      • Annotation Processor 로 없는 소스코드 생성하기
      • lombok 은 어떻게 동작하는 것일까?
      • 다이내믹 프록시 정리하기
      • 클래스의 프록시
      • 다이내믹 프록시
      • 프록시 패턴은 무엇인가
      • Spring Data JPA 는 어떻게 동작할까?
      • reflection api 정리
      • reflection api 이용하여 spring ioc container 만들기
      • reflection api
      • spring dependency injection 은 어떻게 동작할까
      • 바이트 코드 조작하기
      • java bytecode 를 조작해 테스트 코드 커버리지 확인하기 (feat.jacoco)
      • Class Loader
      • JVM 의 구조
      • java, jvm, jdk and jre
      • synchronized
      • java string.split(".") 오류
    • Java 8
      • 이 위키를 만드는데 참고한 자료들
      • Metaspace
      • Parallel 정렬
      • Annotation
      • CompletableFuture
      • Date and Time
      • Optional
      • Stream
      • interface의 default 메소드와 static 메소드
      • 인터페이스의 변화
      • 함수형 인터페이스
      • java 8 소개
    • Spring Framework
      • Spring 3.0 준비하기
      • 특정 매소드만 transaction 처리하기
      • 스프링 프로젝트 시작하기
      • 스프링이란 무엇인가
      • 스프링 핵심 기술의 응용
      • AOP 2
      • AOP 1
      • 서비스 추상화 2
      • 서비스 추상화 1
      • 예외
      • 템플릿
      • 테스트
      • 오브젝트와 의존관계
      • 스프링이란
    • Spring Boot
      • [Gradle]UncheckedIOException
      • java19 + spring 3.0.5 + gradle 7.4.1 에서 프로젝트 gradle 설정하기
      • [리뷰] Gradle 멀티 프로젝트 관리
      • [리뷰] 멀티모듈 설계 이야기 with Spring, Gradle
    • JPA/QueryDSL
      • querydsl 을 쓰는 이유
      • JPA querydsl에서 json array 로 된 컬럼에 조건 적용하기
      • querydsl 에서 mysql order by field() 사용하기
  • 🏰Infrastructure
    • InfraWorkshop
      • 이 위키를 만드는데 참고한 자료들
      • aws로 안정적인 인프라 만들기 2
      • aws로 안정적인 인프라 만들기 1
      • 어플리케이션 진단하기
      • 서버 진단하기
      • 부하 테스트
      • 웹 성능 개선하기
      • 웹 성능 진단하기
      • <aws로 그럴듯한 인프라 만들기> 회고와 피드백
      • aws로 그럴듯한 인프라 만들기 3 - 배포스크립트
      • aws로 그럴듯한 인프라 만들기 2 - 배포하기
      • aws로 그럴듯한 인프라 만들기 1 - 네트워크 망 구성
      • docker container
      • connection check
      • network segmentation
      • cloud 서비스를 사용한다는 것
    • AWS
      • AWS IAM
      • AWS CodePipeline 으로 배포 자동화하기 (1)
      • AWS CodePipeline 으로 배포 자동화하기 (2)
  • 🪄Test
    • TDD
      • 이 위키를 만드는데 참고한 자료들
      • [2주차] 로또 과제 강의를 듣고나서
      • [1주차] 자동차 경주 과제 강의를 듣고나서
      • TDD, 리팩토링이란?
      • 가장 쉽게 TDD 시작하는 방법
      • 의식적인 연습과 학습 테스트
      • TDD 에 집착해야하는 이유
      • 공부하는 자세
    • AssertJ
      • 이 위키를 만드는데 참고한 자료들
    • JUnit
      • 이 위키를 만드는데 참고한 자료들
      • Junit 기본 개념
  • 😎OTHERS
    • Helpful Command
      • Mac 에서 특정 포트 검색, 종료
      • crontab
    • Llibrary
    • IntelliJ
      • 내가 좋아하는 커스텀 세팅
    • GIT
      • Github ID/Token 한번 입력 후 저장하기
      • Github Actions
      • github organization private repository push 안될 때 (not found issue)
      • commands
      • git commit convention
    • Logging
      • logback + webfilter 로 로그설정
      • ‼️log4j 보안 이슈
    • Postman
      • postman 의 header에서 언더바(_) 변수 인식 안되는 현상
Powered by GitBook
On this page
  • 1. 기억하고 싶은 문장들
  • 1장. 재즈
  • 2장. 록
  • 3장. 하드코어 - 유클리드 알고리즘 & RSA 알고리즘
  • 4장. 클래식 - N개의 여왕문제
  • 2. 느낀점

Was this helpful?

  1. Dev-General
  2. Dev-Insight

책 <누워서 읽는 알고리즘>

임백준

1. 기억하고 싶은 문장들

1장. 재즈

  • 요즘 시대에 개발자에게 가장 중요한 능력은 특정 언어와 프레임워크로 개발하는 능력이 아니라 새로운 개념과 언어를 빠르게 배우는 능력이다. 그리고 이러한 능력의 기반이 되는 것은 바로 알고리즘이다.

  • 눈이 빨간 승려 문제

    • N명의 승려가 있다면, N번째의 날에 모두 다같이 죽게 된다.

  • 이진트리와 재귀함수

    • 빨간 승려 문제도 사실은 재귀함수로 풀 수 있는 문제가 된다.

  • 모리츠 코르넬리스 애셔의 <그리는 손>

    • P를 출력하는 프로그램 P : 자기 자신의 소스코드를 출력하는 프로그램을 만들기

  • 헝클어 놓은 실타래를 하나씩 푸는 문제

    • 예) 서로 다른 색, 나라, 음료, 담배, 애완동물을 가지고 있는 사람들을 유추해내는 문제

    • 제한 시간은 3분이나 나는 38분이나 걸렸다 ㅠㅠ

  • 프로그래머가 작성해놓은 코드와 그 속에 담긴 알고리즘을 통해 그 프로그래머의 성향, 개성 및 실력을 유추할 수 있다.

  • 주어진 문제에 대해서 적절한 알고리즘을 생각해내는 것은 하루아침에 되지 않는다. 평소에 꾸준한 훈련을 해야 가능한데, 이러한 훈련은 컴퓨터 앞에서 앉아있다고 되지 않는다. 영화도 보고, 전시회도 가고, 술도 마시고 연애도 하는 열정적인 사람이어야만 그것이 가능하다. 진정한 상상력은 삶의 속살을 이해할 때 비로소 풍부해지기 때문이다.

  • 1부터 100까지의 수를 모두 더한 값 구하기 → 가우스

  • <가우스> 99개의 값을 저장할 수 있는 배열에 1부터 100개의 수를 무작위로 넣는다. 배열에 저장되지 않은 한 가지의 수를 구하는 방법을 말하라

    • 1부터 100까지 모두 더하면 5050이므로 배열의 값을 모두 더한 다음 5050에서 빼면 배열에 들어가지 않은 하나의 숫자가 나오게 된다.

  • <펠린드롬 알고리즘> 앞으로 읽으나 뒤로 읽으나 똑같은 단어를 회문 혹은 펠린드롬이라고 한다. 입력된 단어가 펠린드롬이면 true, 아니면 false 를 반환하는 프로그램을 작성하라

    • 단어의 길이를 체크한다.

    • 길이가 2보다 작으면 오류 메시지를 내보낸다.

    • 단어의 길이만큼 2로 나누어, 체크할 마지막 인덱스를 구한다.

    • 해당 인덱스만큼 반복하여 단어의 양 끝 인덱스의 문자를 비교한 뒤, 같으면 참, 다르면 거짓을 반환한다.

    • 이 알고리즘을 수행할 때 주목할 점은 for 문을 이용하여 양 끝의 문자를 비교할 때, length-1-index 와 같은 연산을 반목문 내에서 수행할 경우, 매 반복마다 불필요한 연산이 발생하므로, 해당 연산은 for 문 밖에서 처리하는 것이 성능 면에서 좋다는 것이다.

  • 펠린드롬에 대한 흥미로운 수학적 관찰, 그루엔버거 알고리즘

    • 결국 모든 수는 펠린드롬으로 귀결된다.

    • 아무 숫자나 고른 뒤, 그 숫자를 뒤집고 두 수를 더한다. 그 수가 펠린드롬이 아니라면 다시 그 수를 뒤집고 더한다. 이 과정을 반복하면 반드시 펠린드롬이 발생하게 된다.

    • 하지만 숫자 196에 대해서는 아직까지 펠린드롬을 발견하지 못하였다. 무려 7천만개의 숫자까지 실험이 진행되었지만, 아직까지 펠린드롬을 발견하지 못했다.

  • <콤웨이 둠스데이 알고리즘> 2199년 7월 2일은 무슨 요일인가

    • 둠스데이 교수는 프린스턴 수학과 교수임. “인생게임”의 창시자로 알려져 있음

    • 최초로 달력을 만들 때, 이집트 천문학자들은 1년을 365일로 하고, 4년마다 한번씩 하루를 더하는 알고리즘을 처음으로 만들었다.

    • 위의 알고리즘에도 버그가 존재하여 교황 그레고리 13세 때 새로운 세기가 시작될 때(100으로 나누어 떨어지는 해에) 400으로 나누어 떨어지지 않는 해는 윤년으로 치지 않기로 하는 알고리즘을 추가했다.

      • 예를 들면 아래와 같다.

        • 1900 : 4로 나누어 떨어지고, 400으로는 떨어지지 않으므로 그레고리 알고리즘에 따르면 윤년이 아니다.

        • 2000 : 4로도, 400으로도 나누어 떨어지므로 윤년이다.

        • 2100 : 4로는 나누어 떨어지지만, 400으로는 나누어 떨어지지 않으므로 윤년으로 치지 않는다.

    • 즉 윤년은 4로도 나누어 떨어지고, 그 세기의 시작이 400으로도 나누어 떨어지는 해일 것이다.

    • 둠스데이 알고리즘은 윤년을 기준으로 요일을 계산하는 알고리즘이다. 이때 둠스데이는 평년의 경우 2월 28일, 윤년의 경우는 2월 29일이 된다.

    • 요일은 7을 기준으로 순환한다. 따라서 둠스데이로부터 7일을 거슬러 올라간 날짜는 항상 둠스데이와 요일이 같게 된다. 이때, 둠스데이와 요일이 같을 수 밖에 없는 날짜를 미리 기억해두면 빠른 계산에 도움이 된다.

      • 04/04, 06/06, 08/08, 10/10, 12/12, 09/09, 05/09, 07/11, 11/07, 03/07

    • 100으로 나누었을 때, 윤년이 아닌 해를 미리 표시해둔다. 그에 따르면 2199년에는 목요일이 둠스데이이다. 위의 날짜 리스트에 따르면 2199년 7월 11일 역시 둠스데이와 같은 목요일이 되고, 그 전주인 2199년 7월 4일 역시 목요일이 된다. 따라서 2199년 7월 2일은 화요일이다.

2장. 록

  • 정렬 알고리즘

    • 기본중의 기본이지만 가장 중요하다.

    • sorting 은 사실 ordering 에 더 가깝다.

  • 퀵정렬

    • 토니 호어가 60년대에 발명한 매우 간단하고 아름다운 정렬 기법. 재귀를 토대로 만들어졌다.

    • 작업과정

      • 기준점 x를 하나 고른다.

      • 리스트1에서는 기준점보다 작은 것을 넣고, 리스트2에는 x를, 리스트3에는 x보다 큰 것을 넣는다.

      • 리스트 1과 리스트 3을 각각 다시 퀵소팅한다.

      • 그리고 리스트 1, 리스트2, 리스트3을 순서대로 합치면, 정렬 완료!

    • 가장 중요한 것은 기준점 x를 잘 고르는 것이다. x를 잘 고르려면 가운데 지점을 적절하게 골라야 하는데, x가 최저점이나 최고점일 경우, 나머지 리스트만 계속 재귀가 호출되므로 매우 비효율적이게 된다.

    • 적절한 x를 찾는 것이 가장 중요하기 때문에, 퀵정렬에 대한 변형 알고리즘도 등장한다.

  • 알고리즘을 공부할 때에는 핵심적인 방법론만 이해하고 껍데기는 버리는 것이 좋다. 이해한 뒤에는 그 알고리즘이 정말 최선인지 의심을 하는 과정이 필요하다.

  • <문제> 정수 array 가 주어지는데 이 배열이 순서대로 정렬되어있다면 1을, 아니면 0을 리턴하는 함수를 작성하라

    • 반복문을 작성하여 현재 요소가 다음 요소보다 크면 곧바로 0을 리턴하고, 그렇지 않고 반복문을 끝까지 완료하면 1을 리턴하도록 작성한다.

    • 하지만 이 알고리즘이 최선인가? 늘 고민하고 의심해봐야한다.

  • 검색 알고리즘과 최적화 문제

    • 정렬과 검색은 늘 붙어다닌다. 효율적인 정렬은 검색을 필요로 하는 경우가 많고, 효율적인 검색은 정렬을 필요로 한다.

  • <문제> 집합A가 집합B의 부분집합인지 여부를 확인하기 위한 알고리즘을 작성하라

    • 나의 답안

      • 집합 A의 요소들을 하나씩 뽑아 집합 B의 요소들과 하나씩 비교해본다. 이때, A의 요소를 포함하지 않는 경우가 한 건이라도 있다면 바로 false 를 리턴한다.

    • 좀 더 괜찮은 답안

      • 집합A와 집합B를 각각 정렬한다.

      • 집합 A의 첫 요소가 집합 B에서 존재하는 index를 확인한다. 이제 집합 A의 2번째 요소부터는 index 이후부터 탐색하면 된다. 탐색의 범위가 훨씬 줄어드는 것이며 각 집합의 요소를 한번씩만 스캔하면 된다.

  • 이진트리검색

    • <문제> 63층 빌딩에서 떨어진다고 했을 때, 떨어지면 죽지 않을 층 중 최고층은 어디일까. 5번은 떨어져도 다시 살아날 수 있지만, 그 이상은 영혼을 잃게 된다. 5번 안에 맞추면 온 세상을 갖을 수 있다.

      • 이진트리검색을 이용하면 5번 안에 맞출 수 있다. 답이 17층이라고 한다면, 아래와 같은 순서로 탐색할 수 있다.

        • 64/2=32층 (죽는다) → 32/2=16층 (산다) → 24층 (죽는다) → 20층 (죽는다) → 18층 (죽는다)

        • 답은 17층이 된다.

  • 다양한 검색 알고리즘

    • B트리, B+/-트리, 해싱, 문자열 내부의 패턴 검색하는 스트링 매칭 알고리즘, KMP 알고리즘, 보이어-무어 알고리즘, 래빈-카프 알고리즘

    • 그래프에서 경로찾는 문제 또한 경로를 찾는 것에 해당한다.

    • 네이버, 구글 등의 검색 알고리즘

  • 결국, 알고리즘은 가독성과 효율성에 대한 고민이며 이는 최적화 과정에 의해 달성된다. 하지만 동적알고리즘의 경우, 이러한 최적화 과정에 의해 달성되기 어렵다.

  • 동적 프로그래밍

    • 피보나치 알고리즘

      • 1170년 이태리의 수학자 레오나르도 피사노의 별명인 피보나치를 따라 붙여진 이름. 이전 수와 현재수를 더하여 다음수를 구하는 방식의 수열을 의미한다.

      • 하지만 피보나치수열은 과연 최선인가?

      • 성능적으로 볼 때 피보나치 알고리즘은 for나 while 루프를 돌리는 것이 더 빠르고 효율적이지만 미학적으로 보았을 때에는 재귀함수를 쓰는 것이 더 간결하다. 성능과 미학이 반드시 일치하지는 않는다.

    • 알고리즘의 효율성을 향상시키기 위해서 알고리즘의 수행 도중에 계산한 결과를 테이블 같은 곳에 저장해 두었다가 재활용 하는 기법이다. 하지만 이용하는 것이 까다롭다.

    • 활용 예시

      • 행렬의 곱셈을 수행하는 계산, 이진트리, 최단경로찾기 등을 최적화하기

      • 이론적 알고리즘의 성능개선

  • 해시 알고리즘

    • <문제> 집합A가 집합B의 부분집합인지 여부를 확인하기 위한 알고리즘을 작성하라

      • 집합 B의 원소들을 테이블에 저장한 뒤, 집합 A의 원소들을 하나씩 꺼내서 그것이 테이블에 존재하는지 확인한다.

    • 해시의 어원

      • 다진 고기 요리, 뒤범벅, 뒤죽박죽, 잡동사니, 쓰레기, 마리화나 등

      • 주어진 데이터를 잘 가공하여 해시값으로 만들어 사용하기 편하게 만든다는 의미

    • 해시값은 데이터를 저장하는 해시 테이블에서 키로 사용된다. 이 키값만 있다면, 테이블에서 키값에 해당하는 데이터는 정말 짧은 상수 시간안에 찾을 수 있다. 심지어는 데이터의 양이 늘어나도 검색 시간에 거의 차이가 없다.

    • 하지만 해시 알고리즘 역시 단점이 있다. 속도가 빠른 반면에, 해시 테이블만큼 큰 메모리 공간을 차지하게 된다.

      • 원래 알고리즘의 영역은 속도가 빠르면, 공간을 희생하고, 메모리 공간이 적게 들면 속도가 느린 법이다.

      • 자신이 사용하는 알고리즘의 속도와 공간을 분석하여 효율성을 점검하는 것은 프로그래머라면 해야할 필수적인 일이다. 단순 노가다만하는 코더와 침착하게 로직에 접근하는 프로그래머는 바로 이러한 작은 습관부터 시작된다.

  • 사운덱스 검색 알고리즘

    • 사운덱스 검색 알고리즘은 사람이름을 일정한 코드로 변환해주는 알고리즘인데, 제 2차세계대전 기간에 군인들의 개인 기록을 관리하는데 쓰였고, 이후 미국의 인구 통계 조사 때에도 사용되었다고 한다. 요즘에는 여러가지 소프트웨어 속 철자확인기 엔진에도 사용된다고 한다.

    • 사운덱스 검색 알고리즘의 규칙은 다음과 같다.

      • 제일 첫글자를 남기고 그 이후는 글자는 a, e, o, h, i, u, w, y를 모두 제외한다. 반복되는 철자는 하나만 남기고 지운다.

      • 남은 글자 중에서 일정한 규칙에 따라 번호를 매긴다. (b는 1, c는 2, d는 3 … 등)

      • 남은 글자들이 3자리 미만이라서 숫자가 부족할 경우 0으로 채우고, 3자리 이상일 경우에는 3자리까지만 자른다.

      • 예를 들어 Gauss 라는 이름을 사운덱스 알고리즘에 의해 코드로 변환한다고 한다면 제일 첫글자 G를 남기고 그 이후의 a와 u는 제거한 뒤, ss는 반복되므로 s로 간주하고 2를 부여한다. 남은 두 자리는 0으로 채워 최종적으로 G200이라는 코드를 추출한다.

    • 결국 최적화 알고리즘이다. 실수로 초래되는 문제의 범위를 축소시켜주고, 검색 속도를 빠르게 해준다는 장점이 있기 때문에 다소 혼동의 여지가 있더라도 계속 사용한다.

  • 메르센느 소수

    • 메르센느는 14세기 프랑스의 철학자이자 수도승사이며, 데카르트의 스승이라도 불릴 정도로 평소 철학과 수학에 심취해있었다고 한다.

    • 당시 “p가 소수이면, 2^p - 1 역시 소수이다.”라는 명제는 거짓으로 밝혀져 있었는데, 메르센느는 이것을 하나의 수식을 깔끔하게 표현하고 싶었다. 하지만 명제 자체에 그렇지 않은 케이스가 너무 많았기 때문에 그렇게 표현할 수 없었다.

    • 후에 메르센느 사후 사람들이 아래와 같이 표현함으로서 메르센느의 수학과 철학에 대한 열정을 기렸다고 한다.

      • “어떤 수 p가 소수일때, 2^p -1 역시 소수이면, 그 수를 메르센느의 수라고 한다.”

  • 프로그래머가 느끼는 성취감의 본질

    • 메르센느 소수 중 가장 큰 수를 찾기 위해 일명 메르센느 소수 마니아들이 집결한 공간(GIMPS)이 인터넷 상에 존재한다.

    • 그들은 이 실용적이지 않은 작업을 위해 고가의 슈퍼컴퓨터를 지원받을 수 없었다. 대신 전 세계에 흩어진 무명의 PC와 워크스테이션을 네트워크로 연결해서 그들의 통합된 컴퓨팅 파워를 이용하기로 했다.

      • 서버는 수 많은 클라이언트들에게 검색할 숫자를 주고, 결과를 수집하여 데이터베이스를 축적해나간다고 한다.

    • 이 발상이야말로 최적화의 끝판왕이라고 생각된다.

  • 문학적 프로그래밍

    • 문학적 프로그래밍은 1980년대에 도널드 커누스 교수에 의해 던져진 화두이다. 프로그래밍 분야를 예술의 일종으로 보는 시각이다. 이러한 독특한 해석은 많은 프로그래머들의 영감을 자극했고, goto의 존재와 역할, 구조적 프로그래밍, 객체지향까지 지어지는 패러다임의 혁명에 영향을 주었다.

    • ACM 저널에서 <프로그래밍 펄>이라는 컬럼을 연재했던 존 벤틀러 교수는 이러한 신선한 시각이 좋았고, 이를 소개하는 내용을 쓰고 싶었다. 커누스 교수에게 이를 소개하고자 적절한 예시 알고리즘 문제를 통해 설명을 해달라고 했더니, 커누스 교수는 오히려 “문학적 프로그래밍”은 모든 상황과 알고리즘에서 가능하니, 오히려 자신에게 문제를 주면 문학적 프로그래밍의 방법으로 해결해주겠다고 답했다고 한다.

    • 그래서 벤틀러 교수가 낸 알고리즘 문제가 바로 이것이다.

      • 영어로 쓰여진 텍스트가 있다. 이 텍스트를 읽고 그 안에서 가장 빈번하게 등장하는 단어 상위 10개를 출력하는 프로그램을 작성하라.

    • 이 문제에 대해 우리는 두 가지의 알고리즘을 비교함으로써 커누스 교수의 답을 생각해볼 수 있다.

      • 알고리즘 1

        • hash(w) 함수는 단어 w에 대해서 유일무이한 하나의 해시값을 반환한다.

        • count[] 배열에는 각 단어의 횟수를 나타내는 정수값을 저장한다.

        • word[] 배열에는 단어를 저장한다.

        • 텍스트를 읽으면서 count[hash(w)] 값을 +1 하고, count 값이 0이면, word[hash(w)] 배열에 그 단어를 추가한다.

        • 이후 count[] 배열을 정렬한 다음, 순서대로 10개의 값을 찾고, 그 10개에 대응하는 단어를 word[] 에서 찾는다.

      • 알고리즘 2

        • 첫번째 검색할 때에는 count[hash(w)]만 저장한다.

        • 두번재 검색할 때에는 특정 기준 상수 C보다 큰 경우만 word[hash(w)]에 저장한다.

        • 검색 종료 후, count[] 를 정렬하여 상위 10개를 찾고, 그 10개 값에 해당하는 단어를 word[]에서 찾는다.

    • 두 알고리즘을 비교해보면, 알고리즘 1은 한번만 읽는 대신 불필요한 연산 (word배열에 모든 단어를 추가하는 등)이 존재하고 공간도 많이 쓴다. 대신 알고리즘 2는 검색을 두 번 하지만, 효율적으로 배열 공간을 사용하며 불필요한 연산을 줄인다.

    • 영어 문장에서 단어가 1회이상 반복될 확률이 절반 이하라는 점을 고려해본다면, 2번 알고리즘이 훨씬 효율적이라는 것을 알 수 있다.

    • 벤틀리는 다음과 같은 질문들 독자에게 던졌다고 한다.

      • “조용한 밤에 의자에 앉아서 편하게 프로그램을 읽으면서 시간을 보냈던 가장 최근은 언제인가”

    • 벤틀리는 이에 없다고 답했다고 한다. 업무를 위한 코드 읽기 이외에 조용히 프로그램을 읽었던 기억 말이다.

    • 문학적 프로그래밍의 서문에서 카누스 교수는 다음과 같은 말을 했다고 한다.

      • “컴퓨터 프로그램을 작성하는 일은 재미있다. 그리고 잘 작성된 프로그램을 읽는 것도 재미있다. 세상에서 가장 즐거운 일 중 하나는 여러분이 작성한 컴퓨터 프로그램을 다른 사람들 혹은 여러분 자신이 읽고 기쁨을 얻는 것이다. 컴퓨터 프로그램은 또한 유용한 작업을 수행할 수도 있다. 세상에서 가장 큰 성취감을 맛보는 순간은 여러분이 창조한 무엇이 사회의 부와 진보에 기여한다는 사실을 깨닫는 순간이다. 어떤 사람들은 컴퓨터 프로그램을 작성함으로써 돈을 벌기도 한다. 따라서 프로그래밍은 세 가지 측면에서 결실을 맺는 행위이다. 미학적으로, 인류학적으로, 그리고 경제적인 면이 바로 그러한 결실에 해당한다.”

3장. 하드코어 - 유클리드 알고리즘 & RSA 알고리즘

  • 유클리드 알고리즘

    • 유클리드 알고리즘은 두 수 m과 n이 존재할 때, m과 n사이의 최대공약수를 구하는 알고리즘이다.

      • 보통 m이 n보다 크거나 같다고 가정하고 시작하는데, 만약에 n이 m보다 크면 그냥 두 수를 바꿔주면 된다. → swap(m, n)

    • 지금까지도 최대공약수를 구하는 가장 기본적인 알고리즘으로 꼽힌다.

  • 재귀의 마술

    • 기존 gcd() 알고리즘에서 함수의 시작시 swap 부분이 존재하는 것이 어쩐지 깔끔하지는 않다. 이 부분을 개선하고 싶다면 재귀함수를 떠올려볼 수 있겠다.

    • 최대공약수를 구하는 gcd 함수에서 n=0일 경우, m값을 리턴하도록 하고, 그렇지 않다면 다시 gcd(n, m%n) 함수를 호출하여 리턴하도록 하면, 재귀함수를 이용하여 깔끔하게 최대공약수를 구할 수 있다.

    • 보통 재귀함수의 경우, 호출시, 원래 호출되었던 시점을 기억하기 위해 시스템 스택에 복귀 위치를 쌓는다. 따라서 너무 많이 호출될 시에 성능이슈가 있다.

    • 하지만 꼬리재귀처럼 return 구문에서 재귀함수를 호출하고 끝낸다면, 굳이 돌아갈 시점을 스택에 쌓을 필요가 없다. 재귀함수를 사용함으로써 발생되는 문제를 방지할 수 있는 것이다.

    • 재귀함수는 미학적으로 아름답고 간결하지만, 성능상 안좋다는 단점이 있고, for나 while 반복문이나 커스텀한 stack 함수는 성능상으로는 뛰어나지만 코드가독성이 재귀함수에 비해 떨어진다는 단점이 있다. 두 부분은 어떤 것을 우선시하느냐의 문제이지만, 꼬리재귀의 경우, 이같은 재귀함수의 단점마저 보완하기 때문에 효과적인 해결책이 될 수 있다.

  • RSA 알고리즘의 창시자, 리베스트, 샤미르, 에이들맨

    • 오늘날 우리가 널리 사용하고 있는 공개키-개인키 개념(PKC)을 구현한 RSA 암호화 알고리즘은 MIT공대의 젊은 학자들인 Rivest, Shamir, Adleman 의 이니셜을 따서 만들어졌다.

    • 이들은 선배 학자인 Diffie와 Hellman, Merkle 이 정식화한 PKC(Public Key Cryptography)라는 혁명적인 개념에 영감을 받아, 이 개념을 현실세계에 구체화 할 수 있는 알고리즘으로 만들기 위해 노력했다.

    • 이들이 고민하던 것은 공개키로 문서를 암호화하면, 오로지 개인키가 있어야만 해독할 수 있는 알고리즘을 만드는 것이었다. 그리고 그들은 해냈다.

  • RSA 알고리즘

    • p와 q는 소수이다. n=pq를 찾는다.

    • p와 q에서 각각 1을 빼서 곱한다. 그것을 pie라고 부른다.

      • pie = (p-1)(q-1)

    • 다음 조건을 만족하는 e를 찾는다.

      • 1 < e < pie, gcd(e, pie) = 1

    • 다음 조건을 만족하는 d를 찾는다.

      • 1 < d < pie, ed = 1 (mod pie)

    • (n, e)는 공개키가 되고, (n, d)는 개인키가 된다. p, q, pie와 같은 값들은 공개되지 않도록 한다.

    • 히딩크 감독과 코엘류 감독 사이에 비밀문서를 주고받는다고 가정해본 예시

  • <문제> 빈 방안에 물이 반정도 있는 컵이 있다. 이 물이 절반을 넘는지 아니면 절반보다 부족한지 알아내는 방법은 무엇일까. (방이 비어있으므로 그 어떤 도구도 이용할 수 없다. 물을 마시거나 증발시키는 등 비정상적인 방법도 안된다.)

  • 세 줄짜리 펄 프로그램

    • RSA 알고리즘을 이용한 암호화와 해독의 과정

    • 폴란드식 표기법과 역폴란드식 표기법

    • 유닉스 시스템의 계산기 dc 는 바로 역폴란드식 표기법을 따르기 때문에 입력시 주의해야한다.

    • 참고

      • 국제 엉망진창 C프로그램 경연대회

    • 두 줄짜리 RSA 알고리즘

4장. 클래식 - N개의 여왕문제

  • N개의 여왕문제

    • 가로 세로 모두 N개의 칸이 있는 체스판 위에 N개의 여왕을 올려놓되 서로 공격해서 잡을 수 없도록 놓을 수 잇는 방법은 모두 몇개인가?

    • 대표적인 퇴각검색 기법을 이용하는 문제

    • 가로 세로 길이가 4인 체스판 예시

      • 우선 (1,1)에 첫번째 여왕을 둔다고 가정한다.

      • 체스에서 여왕은 가로, 세로, 대각선으로 이동할 수 있으므로, 해당 규칙을 고려하여 두번째 말을 놓는다.

      • 만약에 진행하다가 경우의 수가 안나오면, 다시 이전 단계로 “퇴각”하여 다시 시도해본다.

      • 그렇게 되면 첫번째 단계까지 퇴각하게 되어 결국 아래와 같은 답을 구할 수 있다.

        • (1,2), (2, 4), (3, 2), (4, 3)

  • N개의 여왕문제에서 우리가 사용한 퇴각검색기법은 사실 트리나 그래프를 탐색하는 방법과 매우 유사하다. 특히나 트리에서 깊이우선탐색, deepest first search DFS의 경우와 매우 비슷하다.

  • 재귀와 스택

    • 위의 퇴각탐색을 실행할 때에 가장 중요한 것은 이미 가본 길을 가지 않는 것, 이미 체크한 수를 다시 체크하지 않는 것이다. 이때 우리가 쓸 수 있는 것이 재귀나 스택이다.

    • 재귀함수는 회귀지점을 저장하기 위해 스택 구조를 사용한다. 따라서 호출 횟수가 일정 수가 넘어가게 되면, 재귀함수는 성능상 급격하게 안좋아지고, 이는 속도뿐만아니라 메모리 공간의 효율성 측면에서도 그러하다.

  • 재프 소머즈의 알고리즘

    • N개의 여왕문제를 구현한 많은 코드들이 있지만 재프 소머즈의 알고리즘은 퇴각검색 알고리즘의 절묘함, 비트 연산자와 재귀가 아닌 스택을 이용해서 알고리즘의 속도를 최적화 하고 있기 때문에 주목할만하다.

    • 비록 가독성은 그리 좋지 않지만, 그래도 위와 같은 점에서 주목할만하디.

  • 비트 연산자 복습하기

    • & : 논리곱 - 둘다 참이면 1, 둘중 하나라도 거짓이면 0

    • | : 논리합 - 둘 중 하나라도 참이면 1, 둘다 거짓이면 0

    • ^ : 배타적 논리합 - 서로 다르면 1, 서로 다르면 0

    • : 오른쪽 시프트. 이진수를 오른쪽으로 한 칸 이동 ⇒ 2로 나누는 것과 같은 의미

    • << : 왼쪽 시프트. 이진수를 왼쪽으로 한 칸 이동 ⇒ 2를 곱하는 것과 같은 의미

    • ~ : 비트의 부정. 0은 1로, 1은 0으로 바꾸는 연산자

  • 2의 보수

    • 2의 보수 체계에서 0으로 시작하는 이진수 : 양수

    • 1로 시작하는 이진수는 음수

  • 제프 소머즈 알고리즘 분석

2. 느낀점

  • 알고리즘의 유래에 대해서 자세하게 알 수 있는 책이었다. 정말로 누워서 읽을 수 있을 정도로 쉽게 설명이 되었고, 어려운 알고리즘이라는 개념이 이렇게 읽기 쉽게 쓰여졌다는 점에서 저자인 임백준 님의 내공을 감히 상상해볼 수 있었다.

  • 백준 저지의 그 백준이 바로 이분이라는 사실을 책의 중반부에 이르러서야 알게 되었다....!

  • 이 책을 읽은 뒤로는 알고리즘을 알아가는 과정이 한결 재미있어질 것 같다.

  • 프로그래머의 자세에 대해서도 한 번 더 가르침을 받게 되었다. 나는 진짜 프로그래머가 아니구나, 더 날카롭고 꼼꼼해져야하며, 프로그래밍이라는 행위 자체를 좀 더 즐기도록 노력해봐야겠다고 생각하게 되었다.

PreviousINFCON 2022Next책 <나는 LINE 개발자입니다>

Last updated 1 year ago

Was this helpful?

https://www.mersenne.org/primes/
https://www.ioccc.org/index.html