├── .DS_Store ├── .obsidian ├── app.json ├── appearance.json ├── community-plugins.json ├── core-plugins-migration.json ├── core-plugins.json ├── graph.json ├── plugins │ └── obsidian-git │ │ ├── data.json │ │ ├── main.js │ │ ├── manifest.json │ │ └── styles.css └── workspace.json ├── 2025-04-26.md ├── 8학기 (25-2) ├── 데이터통신 │ ├── 1. 서론.md │ └── 2. Application 계층 (응용계층).md ├── 지능형시스템 │ ├── 1. 인공지능 기초.md │ ├── 6. 머신러닝 기초.md │ └── README.md └── 파일처리 │ ├── 1. 파일의 기본 개념.md │ ├── 2. 파일 저장장치.md │ ├── 3. 파일의 입출력 제어.md │ ├── 4. 순차 화일.md │ ├── 5. 화일의 정렬합병.md │ ├── 6. 인덱스 구조 - 이진탐색트리, AVL 트리.md │ └── README.md ├── Flutter ├── 기본 위젯 알아보기.md ├── 다트 입문하기.md └── 플러터 입문하기.md ├── Pasted image 20240312172813.png ├── Pasted image 20240325171739.png ├── Pasted image 20240325171844.png ├── Pasted image 20241129135836.png ├── Pasted image 20250426160403.png ├── Pasted image 20250427165753.png ├── Pasted image 20250428213925.png ├── Pasted image 20250428221316.png ├── README.md ├── SpringBoot in Action ├── 1-1. 스프링부트 시작하기.md ├── 1-2. DI, IoC, Bean, AOP.md └── 1-3. Question Set.md ├── 면접을 위한 CS 전공지식 노트 ├── 네트워크 │ ├── 2.1 네트워크의 기초.md │ ├── 2.2 TCPIP 4계층 모델.md │ ├── 2.3 네트워크 기기.md │ ├── 2.4 IP주소.md │ └── 2.5 HTTP.md └── 디자인 패턴 │ ├── 1.1 디자인 패턴.md │ └── 1.2 프로그래밍 패러다임.md ├── 스크린샷 2024-03-25 오후 4.51.12.png ├── 스크린샷 2024-03-25 오후 5.02.14.png ├── 스크린샷 2024-03-25 오후 5.39.50.png ├── 스크린샷 2024-03-25 오후 7.30.04.png ├── 스크린샷 2024-03-25 오후 7.31.07.png ├── 스크린샷 2024-03-25 오후 7.33.59.png ├── 스크린샷 2024-03-25 오후 7.41.39.png ├── 스크린샷 2024-11-07 오후 12.46.24.png ├── 스크린샷 2024-11-08 오후 12.28.56.png ├── 스크린샷 2024-11-08 오후 12.29.25.png ├── 스크린샷 2024-11-26 오후 12.16.18.png ├── 스크린샷 2024-11-26 오후 2.30.51.png ├── 스크린샷 2024-11-28 오후 1.36.51.png ├── 스크린샷 2024-11-28 오후 1.40.12.png ├── 스크린샷 2024-12-12 오전 11.25.56.png ├── 스크린샷 2024-12-12 오전 11.27.07.png ├── 스크린샷 2024-12-12 오후 1.28.19.png ├── 안드로이드 ├── Companion Object.md ├── DataBinding.md ├── Flow.md └── Livedata.md ├── 정보처리기사 └── 필기 벼락치기 준비.md ├── 코딩테스트 준비하기.md └── 코틀린 코루틴의 정석 ├── 1장 스레드 기반 작업의 한계와 코루틴의 등장.md ├── 2장 코루틴 개발 환경 설정.md ├── 3장 CoroutineDispatcher.md ├── 4장 코루틴 빌더와 Job.md ├── 5장 async와 Deferred.md ├── 6장 CoroutineContext.md ├── 7장 구조화된 동시성.md └── README.md /.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/.DS_Store -------------------------------------------------------------------------------- /.obsidian/app.json: -------------------------------------------------------------------------------- 1 | {} -------------------------------------------------------------------------------- /.obsidian/appearance.json: -------------------------------------------------------------------------------- 1 | { 2 | "accentColor": "", 3 | "theme": "obsidian", 4 | "translucency": true 5 | } -------------------------------------------------------------------------------- /.obsidian/community-plugins.json: -------------------------------------------------------------------------------- 1 | [ 2 | "obsidian-git" 3 | ] -------------------------------------------------------------------------------- /.obsidian/core-plugins-migration.json: -------------------------------------------------------------------------------- 1 | { 2 | "file-explorer": true, 3 | "global-search": true, 4 | "switcher": true, 5 | "graph": true, 6 | "backlink": true, 7 | "canvas": true, 8 | "outgoing-link": true, 9 | "tag-pane": true, 10 | "properties": false, 11 | "page-preview": true, 12 | "daily-notes": true, 13 | "templates": true, 14 | "note-composer": true, 15 | "command-palette": true, 16 | "slash-command": false, 17 | "editor-status": true, 18 | "bookmarks": true, 19 | "markdown-importer": false, 20 | "zk-prefixer": false, 21 | "random-note": false, 22 | "outline": true, 23 | "word-count": true, 24 | "slides": false, 25 | "audio-recorder": false, 26 | "workspaces": false, 27 | "file-recovery": true, 28 | "publish": false, 29 | "sync": false 30 | } -------------------------------------------------------------------------------- /.obsidian/core-plugins.json: -------------------------------------------------------------------------------- 1 | { 2 | "file-explorer": true, 3 | "global-search": true, 4 | "switcher": true, 5 | "graph": true, 6 | "backlink": true, 7 | "canvas": true, 8 | "outgoing-link": true, 9 | "tag-pane": true, 10 | "properties": false, 11 | "page-preview": true, 12 | "daily-notes": true, 13 | "templates": true, 14 | "note-composer": true, 15 | "command-palette": true, 16 | "slash-command": false, 17 | "editor-status": true, 18 | "bookmarks": true, 19 | "markdown-importer": false, 20 | "zk-prefixer": false, 21 | "random-note": false, 22 | "outline": true, 23 | "word-count": true, 24 | "slides": false, 25 | "audio-recorder": false, 26 | "workspaces": false, 27 | "file-recovery": true, 28 | "publish": false, 29 | "sync": false, 30 | "webviewer": false 31 | } -------------------------------------------------------------------------------- /.obsidian/graph.json: -------------------------------------------------------------------------------- 1 | { 2 | "collapse-filter": false, 3 | "search": "", 4 | "showTags": false, 5 | "showAttachments": false, 6 | "hideUnresolved": false, 7 | "showOrphans": true, 8 | "collapse-color-groups": false, 9 | "colorGroups": [], 10 | "collapse-display": false, 11 | "showArrow": false, 12 | "textFadeMultiplier": 0, 13 | "nodeSizeMultiplier": 1, 14 | "lineSizeMultiplier": 0.903507486979167, 15 | "collapse-forces": false, 16 | "centerStrength": 0.518713248970312, 17 | "repelStrength": 10, 18 | "linkStrength": 1, 19 | "linkDistance": 250, 20 | "scale": 0.6820964426390598, 21 | "close": false 22 | } -------------------------------------------------------------------------------- /.obsidian/plugins/obsidian-git/data.json: -------------------------------------------------------------------------------- 1 | { 2 | "commitMessage": "vault backup: {{date}}", 3 | "commitDateFormat": "YYYY-MM-DD HH:mm:ss", 4 | "autoSaveInterval": 60, 5 | "autoPushInterval": 60, 6 | "autoPullInterval": 30, 7 | "autoPullOnBoot": false, 8 | "disablePush": false, 9 | "pullBeforePush": true, 10 | "disablePopups": false, 11 | "disablePopupsForNoChanges": false, 12 | "listChangedFilesInMessageBody": false, 13 | "showStatusBar": true, 14 | "updateSubmodules": false, 15 | "syncMethod": "merge", 16 | "customMessageOnAutoBackup": false, 17 | "autoBackupAfterFileChange": false, 18 | "treeStructure": false, 19 | "refreshSourceControl": true, 20 | "basePath": "", 21 | "differentIntervalCommitAndPush": false, 22 | "changedFilesInStatusBar": false, 23 | "showedMobileNotice": true, 24 | "refreshSourceControlTimer": 7000, 25 | "showBranchStatusBar": true, 26 | "setLastSaveToLastCommit": false, 27 | "submoduleRecurseCheckout": false, 28 | "gitDir": "", 29 | "showFileMenu": true, 30 | "authorInHistoryView": "hide", 31 | "dateInHistoryView": false, 32 | "lineAuthor": { 33 | "show": false, 34 | "followMovement": "inactive", 35 | "authorDisplay": "initials", 36 | "showCommitHash": false, 37 | "dateTimeFormatOptions": "date", 38 | "dateTimeFormatCustomString": "YYYY-MM-DD HH:mm", 39 | "dateTimeTimezone": "viewer-local", 40 | "coloringMaxAge": "1y", 41 | "colorNew": { 42 | "r": 255, 43 | "g": 150, 44 | "b": 150 45 | }, 46 | "colorOld": { 47 | "r": 120, 48 | "g": 160, 49 | "b": 255 50 | }, 51 | "textColorCss": "var(--text-muted)", 52 | "ignoreWhitespace": false, 53 | "gutterSpacingFallbackLength": 5, 54 | "lastShownAuthorDisplay": "initials", 55 | "lastShownDateTimeFormatOptions": "date" 56 | }, 57 | "autoCommitMessage": "vault backup: {{date}}" 58 | } -------------------------------------------------------------------------------- /.obsidian/plugins/obsidian-git/manifest.json: -------------------------------------------------------------------------------- 1 | { 2 | "id": "obsidian-git", 3 | "name": "Git", 4 | "description": "Backup your vault with Git.", 5 | "isDesktopOnly": false, 6 | "fundingUrl": "https://ko-fi.com/vinzent", 7 | "js": "main.js", 8 | "version": "2.24.0" 9 | } 10 | -------------------------------------------------------------------------------- /.obsidian/plugins/obsidian-git/styles.css: -------------------------------------------------------------------------------- 1 | @keyframes loading { 2 | 0% { 3 | transform: rotate(0deg); 4 | } 5 | 6 | 100% { 7 | transform: rotate(360deg); 8 | } 9 | } 10 | 11 | .workspace-leaf-content[data-type="git-view"] .button-border { 12 | border: 2px solid var(--interactive-accent); 13 | border-radius: var(--radius-s); 14 | } 15 | 16 | .workspace-leaf-content[data-type="git-view"] .view-content { 17 | padding: 0; 18 | } 19 | 20 | .workspace-leaf-content[data-type="git-history-view"] .view-content { 21 | padding: 0; 22 | } 23 | 24 | .loading > svg { 25 | animation: 2s linear infinite loading; 26 | transform-origin: 50% 50%; 27 | display: inline-block; 28 | } 29 | 30 | .obsidian-git-center { 31 | margin: auto; 32 | text-align: center; 33 | width: 50%; 34 | } 35 | 36 | .obsidian-git-textarea { 37 | display: block; 38 | margin-left: auto; 39 | margin-right: auto; 40 | } 41 | 42 | .obsidian-git-center-button { 43 | display: block; 44 | margin: 20px auto; 45 | } 46 | 47 | .tooltip.mod-left { 48 | overflow-wrap: break-word; 49 | } 50 | 51 | .tooltip.mod-right { 52 | overflow-wrap: break-word; 53 | } 54 | .git-tools { 55 | display: flex; 56 | margin-left: auto; 57 | } 58 | .git-tools .type { 59 | padding-left: var(--size-2-1); 60 | display: flex; 61 | align-items: center; 62 | justify-content: center; 63 | width: 11px; 64 | } 65 | 66 | .git-tools .type[data-type="M"] { 67 | color: orange; 68 | } 69 | .git-tools .type[data-type="D"] { 70 | color: red; 71 | } 72 | .git-tools .buttons { 73 | display: flex; 74 | } 75 | .git-tools .buttons > * { 76 | padding: 0 0; 77 | height: auto; 78 | } 79 | 80 | .git-author { 81 | color: var(--text-accent); 82 | } 83 | 84 | .git-date { 85 | color: var(--text-accent); 86 | } 87 | 88 | .git-ref { 89 | color: var(--text-accent); 90 | } 91 | 92 | .workspace-leaf-content[data-type="diff-view"] .d2h-d-none { 93 | display: none; 94 | } 95 | 96 | .workspace-leaf-content[data-type="diff-view"] .d2h-wrapper { 97 | text-align: left; 98 | } 99 | 100 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-header { 101 | background-color: var(--background-primary); 102 | border-bottom: 1px solid var(--interactive-accent); 103 | font-family: var(--font-monospace); 104 | height: 35px; 105 | padding: 5px 10px; 106 | } 107 | 108 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-header, 109 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-stats { 110 | display: -webkit-box; 111 | display: -ms-flexbox; 112 | display: flex; 113 | } 114 | 115 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-stats { 116 | font-size: 14px; 117 | margin-left: auto; 118 | } 119 | 120 | .workspace-leaf-content[data-type="diff-view"] .d2h-lines-added { 121 | border: 1px solid #b4e2b4; 122 | border-radius: 5px 0 0 5px; 123 | color: #399839; 124 | padding: 2px; 125 | text-align: right; 126 | vertical-align: middle; 127 | } 128 | 129 | .workspace-leaf-content[data-type="diff-view"] .d2h-lines-deleted { 130 | border: 1px solid #e9aeae; 131 | border-radius: 0 5px 5px 0; 132 | color: #c33; 133 | margin-left: 1px; 134 | padding: 2px; 135 | text-align: left; 136 | vertical-align: middle; 137 | } 138 | 139 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-name-wrapper { 140 | -webkit-box-align: center; 141 | -ms-flex-align: center; 142 | align-items: center; 143 | display: -webkit-box; 144 | display: -ms-flexbox; 145 | display: flex; 146 | font-size: 15px; 147 | width: 100%; 148 | } 149 | 150 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-name { 151 | overflow-x: hidden; 152 | text-overflow: ellipsis; 153 | white-space: nowrap; 154 | } 155 | 156 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-wrapper { 157 | border: 1px solid var(--background-modifier-border); 158 | border-radius: 3px; 159 | margin-bottom: 1em; 160 | } 161 | 162 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-collapse { 163 | -webkit-box-pack: end; 164 | -ms-flex-pack: end; 165 | -webkit-box-align: center; 166 | -ms-flex-align: center; 167 | align-items: center; 168 | border: 1px solid var(--background-modifier-border); 169 | border-radius: 3px; 170 | cursor: pointer; 171 | display: none; 172 | font-size: 12px; 173 | justify-content: flex-end; 174 | padding: 4px 8px; 175 | } 176 | 177 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-collapse.d2h-selected { 178 | background-color: #c8e1ff; 179 | } 180 | 181 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-collapse-input { 182 | margin: 0 4px 0 0; 183 | } 184 | 185 | .workspace-leaf-content[data-type="diff-view"] .d2h-diff-table { 186 | border-collapse: collapse; 187 | font-family: Menlo, Consolas, monospace; 188 | font-size: 13px; 189 | width: 100%; 190 | } 191 | 192 | .workspace-leaf-content[data-type="diff-view"] .d2h-files-diff { 193 | width: 100%; 194 | } 195 | 196 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-diff { 197 | overflow-y: hidden; 198 | } 199 | 200 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-side-diff { 201 | display: inline-block; 202 | margin-bottom: -8px; 203 | margin-right: -4px; 204 | overflow-x: scroll; 205 | overflow-y: hidden; 206 | width: 50%; 207 | } 208 | 209 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-line { 210 | padding: 0 8em; 211 | } 212 | 213 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-line, 214 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-side-line { 215 | display: inline-block; 216 | -webkit-user-select: none; 217 | -moz-user-select: none; 218 | -ms-user-select: none; 219 | user-select: none; 220 | white-space: nowrap; 221 | width: 100%; 222 | } 223 | 224 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-side-line { 225 | padding: 0 4.5em; 226 | } 227 | 228 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-line-ctn { 229 | word-wrap: normal; 230 | background: none; 231 | display: inline-block; 232 | padding: 0; 233 | -webkit-user-select: text; 234 | -moz-user-select: text; 235 | -ms-user-select: text; 236 | user-select: text; 237 | vertical-align: middle; 238 | white-space: pre; 239 | width: 100%; 240 | } 241 | 242 | .theme-light .workspace-leaf-content[data-type="diff-view"] .d2h-code-line del, 243 | .theme-light 244 | .workspace-leaf-content[data-type="diff-view"] 245 | .d2h-code-side-line 246 | del { 247 | background-color: #ffb6ba; 248 | } 249 | 250 | .theme-dark .workspace-leaf-content[data-type="diff-view"] .d2h-code-line del, 251 | .theme-dark 252 | .workspace-leaf-content[data-type="diff-view"] 253 | .d2h-code-side-line 254 | del { 255 | background-color: #8d232881; 256 | } 257 | 258 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-line del, 259 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-line ins, 260 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-side-line del, 261 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-side-line ins { 262 | border-radius: 0.2em; 263 | display: inline-block; 264 | margin-top: -1px; 265 | text-decoration: none; 266 | vertical-align: middle; 267 | } 268 | 269 | .theme-light .workspace-leaf-content[data-type="diff-view"] .d2h-code-line ins, 270 | .theme-light 271 | .workspace-leaf-content[data-type="diff-view"] 272 | .d2h-code-side-line 273 | ins { 274 | background-color: #97f295; 275 | text-align: left; 276 | } 277 | 278 | .theme-dark .workspace-leaf-content[data-type="diff-view"] .d2h-code-line ins, 279 | .theme-dark 280 | .workspace-leaf-content[data-type="diff-view"] 281 | .d2h-code-side-line 282 | ins { 283 | background-color: #1d921996; 284 | text-align: left; 285 | } 286 | 287 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-line-prefix { 288 | word-wrap: normal; 289 | background: none; 290 | display: inline; 291 | padding: 0; 292 | white-space: pre; 293 | } 294 | 295 | .workspace-leaf-content[data-type="diff-view"] .line-num1 { 296 | float: left; 297 | } 298 | 299 | .workspace-leaf-content[data-type="diff-view"] .line-num1, 300 | .workspace-leaf-content[data-type="diff-view"] .line-num2 { 301 | -webkit-box-sizing: border-box; 302 | box-sizing: border-box; 303 | overflow: hidden; 304 | padding: 0 0.5em; 305 | text-overflow: ellipsis; 306 | width: 3.5em; 307 | } 308 | 309 | .workspace-leaf-content[data-type="diff-view"] .line-num2 { 310 | float: right; 311 | } 312 | 313 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-linenumber { 314 | background-color: var(--background-primary); 315 | border: solid var(--background-modifier-border); 316 | border-width: 0 1px; 317 | -webkit-box-sizing: border-box; 318 | box-sizing: border-box; 319 | color: var(--text-muted); 320 | cursor: pointer; 321 | display: inline-block; 322 | position: absolute; 323 | text-align: right; 324 | width: 7.5em; 325 | } 326 | 327 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-linenumber:after { 328 | content: "\200b"; 329 | } 330 | 331 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-side-linenumber { 332 | background-color: var(--background-primary); 333 | border: solid var(--background-modifier-border); 334 | border-width: 0 1px; 335 | -webkit-box-sizing: border-box; 336 | box-sizing: border-box; 337 | color: var(--text-muted); 338 | cursor: pointer; 339 | display: inline-block; 340 | overflow: hidden; 341 | padding: 0 0.5em; 342 | position: absolute; 343 | text-align: right; 344 | text-overflow: ellipsis; 345 | width: 4em; 346 | } 347 | 348 | .workspace-leaf-content[data-type="diff-view"] .d2h-diff-tbody tr { 349 | position: relative; 350 | } 351 | 352 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-side-linenumber:after { 353 | content: "\200b"; 354 | } 355 | 356 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-side-emptyplaceholder, 357 | .workspace-leaf-content[data-type="diff-view"] .d2h-emptyplaceholder { 358 | background-color: var(--background-primary); 359 | border-color: var(--background-modifier-border); 360 | } 361 | 362 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-line-prefix, 363 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-linenumber, 364 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-side-linenumber, 365 | .workspace-leaf-content[data-type="diff-view"] .d2h-emptyplaceholder { 366 | -webkit-user-select: none; 367 | -moz-user-select: none; 368 | -ms-user-select: none; 369 | user-select: none; 370 | } 371 | 372 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-linenumber, 373 | .workspace-leaf-content[data-type="diff-view"] .d2h-code-side-linenumber { 374 | direction: rtl; 375 | } 376 | 377 | .theme-light .workspace-leaf-content[data-type="diff-view"] .d2h-del { 378 | background-color: #fee8e9; 379 | border-color: #e9aeae; 380 | } 381 | 382 | .theme-light .workspace-leaf-content[data-type="diff-view"] .d2h-ins { 383 | background-color: #dfd; 384 | border-color: #b4e2b4; 385 | } 386 | 387 | .theme-dark .workspace-leaf-content[data-type="diff-view"] .d2h-del { 388 | background-color: #521b1d83; 389 | border-color: #691d1d73; 390 | } 391 | 392 | .theme-dark .workspace-leaf-content[data-type="diff-view"] .d2h-ins { 393 | background-color: rgba(30, 71, 30, 0.5); 394 | border-color: #13501381; 395 | } 396 | 397 | .workspace-leaf-content[data-type="diff-view"] .d2h-info { 398 | background-color: var(--background-primary); 399 | border-color: var(--background-modifier-border); 400 | color: var(--text-normal); 401 | } 402 | 403 | .theme-light 404 | .workspace-leaf-content[data-type="diff-view"] 405 | .d2h-file-diff 406 | .d2h-del.d2h-change { 407 | background-color: #fdf2d0; 408 | } 409 | 410 | .theme-dark 411 | .workspace-leaf-content[data-type="diff-view"] 412 | .d2h-file-diff 413 | .d2h-del.d2h-change { 414 | background-color: #55492480; 415 | } 416 | 417 | .theme-light 418 | .workspace-leaf-content[data-type="diff-view"] 419 | .d2h-file-diff 420 | .d2h-ins.d2h-change { 421 | background-color: #ded; 422 | } 423 | 424 | .theme-dark 425 | .workspace-leaf-content[data-type="diff-view"] 426 | .d2h-file-diff 427 | .d2h-ins.d2h-change { 428 | background-color: rgba(37, 78, 37, 0.418); 429 | } 430 | 431 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-list-wrapper { 432 | margin-bottom: 10px; 433 | } 434 | 435 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-list-wrapper a { 436 | color: #3572b0; 437 | text-decoration: none; 438 | } 439 | 440 | .workspace-leaf-content[data-type="diff-view"] 441 | .d2h-file-list-wrapper 442 | a:visited { 443 | color: #3572b0; 444 | } 445 | 446 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-list-header { 447 | text-align: left; 448 | } 449 | 450 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-list-title { 451 | font-weight: 700; 452 | } 453 | 454 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-list-line { 455 | display: -webkit-box; 456 | display: -ms-flexbox; 457 | display: flex; 458 | text-align: left; 459 | } 460 | 461 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-list { 462 | display: block; 463 | list-style: none; 464 | margin: 0; 465 | padding: 0; 466 | } 467 | 468 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-list > li { 469 | border-bottom: 1px solid var(--background-modifier-border); 470 | margin: 0; 471 | padding: 5px 10px; 472 | } 473 | 474 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-list > li:last-child { 475 | border-bottom: none; 476 | } 477 | 478 | .workspace-leaf-content[data-type="diff-view"] .d2h-file-switch { 479 | cursor: pointer; 480 | display: none; 481 | font-size: 10px; 482 | } 483 | 484 | .workspace-leaf-content[data-type="diff-view"] .d2h-icon { 485 | fill: currentColor; 486 | margin-right: 10px; 487 | vertical-align: middle; 488 | } 489 | 490 | .workspace-leaf-content[data-type="diff-view"] .d2h-deleted { 491 | color: #c33; 492 | } 493 | 494 | .workspace-leaf-content[data-type="diff-view"] .d2h-added { 495 | color: #399839; 496 | } 497 | 498 | .workspace-leaf-content[data-type="diff-view"] .d2h-changed { 499 | color: #d0b44c; 500 | } 501 | 502 | .workspace-leaf-content[data-type="diff-view"] .d2h-moved { 503 | color: #3572b0; 504 | } 505 | 506 | .workspace-leaf-content[data-type="diff-view"] .d2h-tag { 507 | background-color: var(--background-primary); 508 | display: -webkit-box; 509 | display: -ms-flexbox; 510 | display: flex; 511 | font-size: 10px; 512 | margin-left: 5px; 513 | padding: 0 2px; 514 | } 515 | 516 | .workspace-leaf-content[data-type="diff-view"] .d2h-deleted-tag { 517 | border: 2px solid #c33; 518 | } 519 | 520 | .workspace-leaf-content[data-type="diff-view"] .d2h-added-tag { 521 | border: 1px solid #399839; 522 | } 523 | 524 | .workspace-leaf-content[data-type="diff-view"] .d2h-changed-tag { 525 | border: 1px solid #d0b44c; 526 | } 527 | 528 | .workspace-leaf-content[data-type="diff-view"] .d2h-moved-tag { 529 | border: 1px solid #3572b0; 530 | } 531 | 532 | /* ====================== Line Authoring Information ====================== */ 533 | 534 | .cm-gutterElement.obs-git-blame-gutter { 535 | /* Add background color to spacing inbetween and around the gutter for better aesthetics */ 536 | border-width: 0px 2px 0.2px 2px; 537 | border-style: solid; 538 | border-color: var(--background-secondary); 539 | background-color: var(--background-secondary); 540 | } 541 | 542 | .cm-gutterElement.obs-git-blame-gutter > div, 543 | .line-author-settings-preview { 544 | /* delegate text color to settings */ 545 | color: var(--obs-git-gutter-text); 546 | font-family: monospace; 547 | height: 100%; /* ensure, that age-based background color occupies entire parent */ 548 | text-align: right; 549 | padding: 0px 6px 0px 6px; 550 | white-space: pre; /* Keep spaces and do not collapse them. */ 551 | } 552 | -------------------------------------------------------------------------------- /.obsidian/workspace.json: -------------------------------------------------------------------------------- 1 | { 2 | "main": { 3 | "id": "cf1cdee10649fcd6", 4 | "type": "split", 5 | "children": [ 6 | { 7 | "id": "db6583b973be8853", 8 | "type": "tabs", 9 | "children": [ 10 | { 11 | "id": "84b942245a26d0fd", 12 | "type": "leaf", 13 | "state": { 14 | "type": "markdown", 15 | "state": { 16 | "file": "안드로이드/Livedata.md", 17 | "mode": "source", 18 | "source": false 19 | }, 20 | "icon": "lucide-file", 21 | "title": "Livedata" 22 | } 23 | }, 24 | { 25 | "id": "86f410a10e1f2deb", 26 | "type": "leaf", 27 | "state": { 28 | "type": "markdown", 29 | "state": { 30 | "file": "안드로이드/Companion Object.md", 31 | "mode": "source", 32 | "source": false 33 | }, 34 | "icon": "lucide-file", 35 | "title": "Companion Object" 36 | } 37 | }, 38 | { 39 | "id": "ba2f6eb99d7b978d", 40 | "type": "leaf", 41 | "state": { 42 | "type": "markdown", 43 | "state": { 44 | "file": "코틀린 코루틴의 정석/4장 코루틴 빌더와 Job.md", 45 | "mode": "source", 46 | "source": false 47 | }, 48 | "icon": "lucide-file", 49 | "title": "4장 코루틴 빌더와 Job" 50 | } 51 | }, 52 | { 53 | "id": "f49723c72a149e92", 54 | "type": "leaf", 55 | "state": { 56 | "type": "markdown", 57 | "state": { 58 | "file": "코틀린 코루틴의 정석/5장 async와 Deferred.md", 59 | "mode": "preview", 60 | "source": false 61 | }, 62 | "icon": "lucide-file", 63 | "title": "5장 async와 Deferred" 64 | } 65 | }, 66 | { 67 | "id": "5b24694704669f6b", 68 | "type": "leaf", 69 | "state": { 70 | "type": "markdown", 71 | "state": { 72 | "file": "코틀린 코루틴의 정석/6장 CoroutineContext.md", 73 | "mode": "source", 74 | "source": false 75 | }, 76 | "icon": "lucide-file", 77 | "title": "6장 CoroutineContext" 78 | } 79 | }, 80 | { 81 | "id": "6ba4080b87e532f4", 82 | "type": "leaf", 83 | "state": { 84 | "type": "markdown", 85 | "state": { 86 | "file": "코틀린 코루틴의 정석/6장 CoroutineContext.md", 87 | "mode": "source", 88 | "source": false 89 | }, 90 | "icon": "lucide-file", 91 | "title": "6장 CoroutineContext" 92 | } 93 | }, 94 | { 95 | "id": "2b660ccef3d46494", 96 | "type": "leaf", 97 | "state": { 98 | "type": "markdown", 99 | "state": { 100 | "file": "코틀린 코루틴의 정석/7장 구조화된 동시성.md", 101 | "mode": "source", 102 | "source": false 103 | }, 104 | "icon": "lucide-file", 105 | "title": "7장 구조화된 동시성" 106 | } 107 | }, 108 | { 109 | "id": "160e9e05d9fe4535", 110 | "type": "leaf", 111 | "state": { 112 | "type": "markdown", 113 | "state": { 114 | "file": "면접을 위한 CS 전공지식 노트/네트워크/2.1 네트워크의 기초.md", 115 | "mode": "source", 116 | "source": false 117 | }, 118 | "icon": "lucide-file", 119 | "title": "2.1 네트워크의 기초" 120 | } 121 | }, 122 | { 123 | "id": "d6592675df253e41", 124 | "type": "leaf", 125 | "state": { 126 | "type": "markdown", 127 | "state": { 128 | "file": "코딩테스트 준비하기.md", 129 | "mode": "source", 130 | "source": false 131 | }, 132 | "icon": "lucide-file", 133 | "title": "코딩테스트 준비하기" 134 | } 135 | }, 136 | { 137 | "id": "352761dd7b1597cd", 138 | "type": "leaf", 139 | "state": { 140 | "type": "release-notes", 141 | "state": { 142 | "currentVersion": "1.8.9" 143 | }, 144 | "icon": "lucide-book-up", 145 | "title": "Release Notes 1.8.9" 146 | } 147 | }, 148 | { 149 | "id": "7e75803b57dae0ec", 150 | "type": "leaf", 151 | "state": { 152 | "type": "markdown", 153 | "state": { 154 | "file": "지능형시스템/README.md.md", 155 | "mode": "source", 156 | "source": false 157 | }, 158 | "icon": "lucide-file", 159 | "title": "README.md" 160 | } 161 | }, 162 | { 163 | "id": "069e7aa079131cad", 164 | "type": "leaf", 165 | "state": { 166 | "type": "markdown", 167 | "state": { 168 | "file": "8학기 (25-2)/지능형시스템/1. 인공지능 기초.md", 169 | "mode": "source", 170 | "source": false 171 | }, 172 | "icon": "lucide-file", 173 | "title": "1. 인공지능 기초" 174 | } 175 | }, 176 | { 177 | "id": "ef1987333fbad984", 178 | "type": "leaf", 179 | "state": { 180 | "type": "markdown", 181 | "state": { 182 | "file": "8학기 (25-2)/지능형시스템/1. 인공지능 기초.md", 183 | "mode": "source", 184 | "source": false 185 | }, 186 | "icon": "lucide-file", 187 | "title": "1. 인공지능 기초" 188 | } 189 | }, 190 | { 191 | "id": "0876f80ae0dcdfa0", 192 | "type": "leaf", 193 | "state": { 194 | "type": "markdown", 195 | "state": { 196 | "file": "8학기 (25-2)/지능형시스템/6. 머신러닝 기초.md", 197 | "mode": "source", 198 | "source": false 199 | }, 200 | "icon": "lucide-file", 201 | "title": "6. 머신러닝 기초" 202 | } 203 | }, 204 | { 205 | "id": "0ba4dc7bdec340c6", 206 | "type": "leaf", 207 | "state": { 208 | "type": "markdown", 209 | "state": { 210 | "file": "8학기 (25-2)/파일처리/README.md", 211 | "mode": "source", 212 | "source": false 213 | }, 214 | "icon": "lucide-file", 215 | "title": "README" 216 | } 217 | }, 218 | { 219 | "id": "b93a983817692ea9", 220 | "type": "leaf", 221 | "state": { 222 | "type": "markdown", 223 | "state": { 224 | "file": "8학기 (25-2)/파일처리/6. 인덱스 구조 - 이진탐색트리, AVL 트리.md", 225 | "mode": "source", 226 | "source": false 227 | }, 228 | "icon": "lucide-file", 229 | "title": "6. 인덱스 구조 - 이진탐색트리, AVL 트리" 230 | } 231 | }, 232 | { 233 | "id": "621898fd84390cda", 234 | "type": "leaf", 235 | "state": { 236 | "type": "markdown", 237 | "state": { 238 | "file": "8학기 (25-2)/파일처리/6. 인덱스 구조 - 이진탐색트리, AVL 트리.md", 239 | "mode": "source", 240 | "source": false 241 | }, 242 | "icon": "lucide-file", 243 | "title": "6. 인덱스 구조 - 이진탐색트리, AVL 트리" 244 | } 245 | }, 246 | { 247 | "id": "bb003b0f013f1069", 248 | "type": "leaf", 249 | "state": { 250 | "type": "markdown", 251 | "state": { 252 | "file": "8학기 (25-2)/파일처리/5. 화일의 정렬합병.md", 253 | "mode": "source", 254 | "source": false 255 | }, 256 | "icon": "lucide-file", 257 | "title": "5. 화일의 정렬합병" 258 | } 259 | }, 260 | { 261 | "id": "c464be7f79ec829c", 262 | "type": "leaf", 263 | "state": { 264 | "type": "markdown", 265 | "state": { 266 | "file": "8학기 (25-2)/파일처리/1. 파일의 기본 개념.md", 267 | "mode": "source", 268 | "source": false 269 | }, 270 | "icon": "lucide-file", 271 | "title": "1. 파일의 기본 개념" 272 | } 273 | }, 274 | { 275 | "id": "dd6bdced8e16ccf7", 276 | "type": "leaf", 277 | "state": { 278 | "type": "markdown", 279 | "state": { 280 | "file": "8학기 (25-2)/파일처리/2. 파일 저장장치.md", 281 | "mode": "source", 282 | "source": false 283 | }, 284 | "icon": "lucide-file", 285 | "title": "2. 파일 저장장치" 286 | } 287 | }, 288 | { 289 | "id": "c9477a0e617101ab", 290 | "type": "leaf", 291 | "state": { 292 | "type": "markdown", 293 | "state": { 294 | "file": "8학기 (25-2)/파일처리/3. 파일의 입출력 제어.md", 295 | "mode": "source", 296 | "source": false 297 | }, 298 | "icon": "lucide-file", 299 | "title": "3. 파일의 입출력 제어" 300 | } 301 | }, 302 | { 303 | "id": "8e22434388adf97e", 304 | "type": "leaf", 305 | "state": { 306 | "type": "markdown", 307 | "state": { 308 | "file": "8학기 (25-2)/파일처리/6. 인덱스 구조 - 이진탐색트리, AVL 트리.md", 309 | "mode": "source", 310 | "source": false 311 | }, 312 | "icon": "lucide-file", 313 | "title": "6. 인덱스 구조 - 이진탐색트리, AVL 트리" 314 | } 315 | }, 316 | { 317 | "id": "e4a95bdc587b8319", 318 | "type": "leaf", 319 | "state": { 320 | "type": "markdown", 321 | "state": { 322 | "file": "8학기 (25-2)/데이터통신/1. 서론.md", 323 | "mode": "source", 324 | "source": false 325 | }, 326 | "icon": "lucide-file", 327 | "title": "1. 서론" 328 | } 329 | }, 330 | { 331 | "id": "05e3494ac5f57d7e", 332 | "type": "leaf", 333 | "state": { 334 | "type": "markdown", 335 | "state": { 336 | "file": "면접을 위한 CS 전공지식 노트/디자인 패턴/1.2 프로그래밍 패러다임.md", 337 | "mode": "source", 338 | "source": false 339 | }, 340 | "icon": "lucide-file", 341 | "title": "1.2 프로그래밍 패러다임" 342 | } 343 | }, 344 | { 345 | "id": "2db7783c68951622", 346 | "type": "leaf", 347 | "state": { 348 | "type": "markdown", 349 | "state": { 350 | "file": "README.md", 351 | "mode": "source", 352 | "source": false 353 | }, 354 | "icon": "lucide-file", 355 | "title": "README" 356 | } 357 | }, 358 | { 359 | "id": "990aee27c5fdde8b", 360 | "type": "leaf", 361 | "state": { 362 | "type": "markdown", 363 | "state": { 364 | "file": "SpringBoot in Action/1-1. 스프링부트 시작하기.md", 365 | "mode": "source", 366 | "source": false 367 | }, 368 | "icon": "lucide-file", 369 | "title": "1-1. 스프링부트 시작하기" 370 | } 371 | }, 372 | { 373 | "id": "d798042b3197307c", 374 | "type": "leaf", 375 | "state": { 376 | "type": "markdown", 377 | "state": { 378 | "file": "면접을 위한 CS 전공지식 노트/디자인 패턴/1.1 디자인 패턴.md", 379 | "mode": "source", 380 | "source": false 381 | }, 382 | "icon": "lucide-file", 383 | "title": "1.1 디자인 패턴" 384 | } 385 | }, 386 | { 387 | "id": "9f610e640140f0ff", 388 | "type": "leaf", 389 | "state": { 390 | "type": "markdown", 391 | "state": { 392 | "file": "면접을 위한 CS 전공지식 노트/네트워크/2.1 네트워크의 기초.md", 393 | "mode": "source", 394 | "source": false 395 | }, 396 | "icon": "lucide-file", 397 | "title": "2.1 네트워크의 기초" 398 | } 399 | }, 400 | { 401 | "id": "abb9912b5a38f0b2", 402 | "type": "leaf", 403 | "state": { 404 | "type": "markdown", 405 | "state": { 406 | "file": "면접을 위한 CS 전공지식 노트/네트워크/2.2 TCPIP 4계층 모델.md", 407 | "mode": "source", 408 | "source": false 409 | }, 410 | "icon": "lucide-file", 411 | "title": "2.2 TCPIP 4계층 모델" 412 | } 413 | }, 414 | { 415 | "id": "70891b44cab125f4", 416 | "type": "leaf", 417 | "state": { 418 | "type": "markdown", 419 | "state": { 420 | "file": "면접을 위한 CS 전공지식 노트/네트워크/2.3 네트워크 기기.md", 421 | "mode": "source", 422 | "source": false 423 | }, 424 | "icon": "lucide-file", 425 | "title": "2.3 네트워크 기기" 426 | } 427 | }, 428 | { 429 | "id": "aa0b9489905c9833", 430 | "type": "leaf", 431 | "state": { 432 | "type": "markdown", 433 | "state": { 434 | "file": "면접을 위한 CS 전공지식 노트/네트워크/2.4 IP주소.md", 435 | "mode": "source", 436 | "source": false 437 | }, 438 | "icon": "lucide-file", 439 | "title": "2.4 IP주소" 440 | } 441 | }, 442 | { 443 | "id": "0333686a546a9af7", 444 | "type": "leaf", 445 | "state": { 446 | "type": "markdown", 447 | "state": { 448 | "file": "README.md", 449 | "mode": "source", 450 | "source": false 451 | }, 452 | "icon": "lucide-file", 453 | "title": "README" 454 | } 455 | }, 456 | { 457 | "id": "443737630c747ae3", 458 | "type": "leaf", 459 | "state": { 460 | "type": "markdown", 461 | "state": { 462 | "file": "SpringBoot in Action/1-1. 스프링부트 시작하기.md", 463 | "mode": "source", 464 | "source": false 465 | }, 466 | "icon": "lucide-file", 467 | "title": "1-1. 스프링부트 시작하기" 468 | } 469 | }, 470 | { 471 | "id": "f4f17940be7c5cef", 472 | "type": "leaf", 473 | "state": { 474 | "type": "markdown", 475 | "state": { 476 | "file": "안드로이드/Flow.md", 477 | "mode": "source", 478 | "source": false 479 | }, 480 | "icon": "lucide-file", 481 | "title": "Flow" 482 | } 483 | }, 484 | { 485 | "id": "06fa71834c2cb55c", 486 | "type": "leaf", 487 | "state": { 488 | "type": "release-notes", 489 | "state": { 490 | "currentVersion": "1.5.12" 491 | }, 492 | "icon": "lucide-file", 493 | "title": "Release Notes 1.5.12" 494 | } 495 | }, 496 | { 497 | "id": "805e088c0e18fbcc", 498 | "type": "leaf", 499 | "state": { 500 | "type": "markdown", 501 | "state": { 502 | "file": "Flutter/다트 입문하기.md", 503 | "mode": "source", 504 | "source": false 505 | }, 506 | "icon": "lucide-file", 507 | "title": "다트 입문하기" 508 | } 509 | }, 510 | { 511 | "id": "5ac0e661501e7889", 512 | "type": "leaf", 513 | "state": { 514 | "type": "markdown", 515 | "state": { 516 | "file": "Flutter/기본 위젯 알아보기.md", 517 | "mode": "source", 518 | "source": false 519 | }, 520 | "icon": "lucide-file", 521 | "title": "기본 위젯 알아보기" 522 | } 523 | }, 524 | { 525 | "id": "2208cffbe1b8d234", 526 | "type": "leaf", 527 | "state": { 528 | "type": "markdown", 529 | "state": { 530 | "file": "Flutter/플러터 입문하기.md", 531 | "mode": "source", 532 | "source": false 533 | }, 534 | "icon": "lucide-file", 535 | "title": "플러터 입문하기" 536 | } 537 | }, 538 | { 539 | "id": "094aaebd4eaa0d1e", 540 | "type": "leaf", 541 | "state": { 542 | "type": "markdown", 543 | "state": { 544 | "file": "코틀린 코루틴의 정석/1장 스레드 기반 작업의 한계와 코루틴의 등장.md", 545 | "mode": "preview", 546 | "source": false 547 | }, 548 | "icon": "lucide-file", 549 | "title": "1장 스레드 기반 작업의 한계와 코루틴의 등장" 550 | } 551 | }, 552 | { 553 | "id": "1e93582b493c3636", 554 | "type": "leaf", 555 | "state": { 556 | "type": "markdown", 557 | "state": { 558 | "file": "코틀린 코루틴의 정석/2장 코루틴 개발 환경 설정.md", 559 | "mode": "preview", 560 | "source": false 561 | }, 562 | "icon": "lucide-file", 563 | "title": "2장 코루틴 개발 환경 설정" 564 | } 565 | }, 566 | { 567 | "id": "2edfba6208c4732c", 568 | "type": "leaf", 569 | "state": { 570 | "type": "markdown", 571 | "state": { 572 | "file": "코틀린 코루틴의 정석/3장 CoroutineDispatcher.md", 573 | "mode": "source", 574 | "source": false 575 | }, 576 | "icon": "lucide-file", 577 | "title": "3장 CoroutineDispatcher" 578 | } 579 | }, 580 | { 581 | "id": "4832eb3279079c1a", 582 | "type": "leaf", 583 | "state": { 584 | "type": "markdown", 585 | "state": { 586 | "file": "코틀린 코루틴의 정석/README.md", 587 | "mode": "source", 588 | "source": false 589 | }, 590 | "icon": "lucide-file", 591 | "title": "README" 592 | } 593 | }, 594 | { 595 | "id": "9be6b6f4a146589a", 596 | "type": "leaf", 597 | "state": { 598 | "type": "markdown", 599 | "state": { 600 | "file": "코틀린 코루틴의 정석/4장 코루틴 빌더와 Job.md", 601 | "mode": "source", 602 | "source": false 603 | }, 604 | "icon": "lucide-file", 605 | "title": "4장 코루틴 빌더와 Job" 606 | } 607 | } 608 | ], 609 | "currentTab": 23 610 | } 611 | ], 612 | "direction": "vertical" 613 | }, 614 | "left": { 615 | "id": "b4c615655d5f52f6", 616 | "type": "split", 617 | "children": [ 618 | { 619 | "id": "0f8d342884bcddbc", 620 | "type": "tabs", 621 | "children": [ 622 | { 623 | "id": "fc65c355ba71b67b", 624 | "type": "leaf", 625 | "state": { 626 | "type": "file-explorer", 627 | "state": { 628 | "sortOrder": "alphabetical", 629 | "autoReveal": false 630 | }, 631 | "icon": "lucide-folder-closed", 632 | "title": "파일 탐색기" 633 | } 634 | }, 635 | { 636 | "id": "3f429fccbbfe95fd", 637 | "type": "leaf", 638 | "state": { 639 | "type": "search", 640 | "state": { 641 | "query": "", 642 | "matchingCase": false, 643 | "explainSearch": false, 644 | "collapseAll": false, 645 | "extraContext": false, 646 | "sortOrder": "alphabetical" 647 | }, 648 | "icon": "lucide-search", 649 | "title": "검색" 650 | } 651 | }, 652 | { 653 | "id": "89438f5201a65045", 654 | "type": "leaf", 655 | "state": { 656 | "type": "bookmarks", 657 | "state": {}, 658 | "icon": "lucide-bookmark", 659 | "title": "Bookmarks" 660 | } 661 | } 662 | ] 663 | } 664 | ], 665 | "direction": "horizontal", 666 | "width": 300 667 | }, 668 | "right": { 669 | "id": "17bd5a38f90b4f47", 670 | "type": "split", 671 | "children": [ 672 | { 673 | "id": "508e92cfe0bad0f0", 674 | "type": "tabs", 675 | "children": [ 676 | { 677 | "id": "aa42f97af8c37e78", 678 | "type": "leaf", 679 | "state": { 680 | "type": "backlink", 681 | "state": { 682 | "file": "8학기 (25-2)/데이터통신/2. Application 계층 (응용계층).md", 683 | "collapseAll": true, 684 | "extraContext": false, 685 | "sortOrder": "alphabetical", 686 | "showSearch": false, 687 | "searchQuery": "", 688 | "backlinkCollapsed": false, 689 | "unlinkedCollapsed": true 690 | }, 691 | "icon": "links-coming-in", 692 | "title": "2. Application 계층 (응용계층) 의 백링크" 693 | } 694 | }, 695 | { 696 | "id": "348374053aab3851", 697 | "type": "leaf", 698 | "state": { 699 | "type": "outgoing-link", 700 | "state": { 701 | "file": "면접을 위한 CS 전공지식 노트/디자인 패턴/1.1 디자인 패턴.md", 702 | "linksCollapsed": false, 703 | "unlinkedCollapsed": true 704 | }, 705 | "icon": "links-going-out", 706 | "title": "1.1 디자인 패턴의 나가는 링크" 707 | } 708 | }, 709 | { 710 | "id": "d9bfa7b02a90668d", 711 | "type": "leaf", 712 | "state": { 713 | "type": "tag", 714 | "state": { 715 | "sortOrder": "frequency", 716 | "useHierarchy": true 717 | }, 718 | "icon": "lucide-tags", 719 | "title": "Tags" 720 | } 721 | }, 722 | { 723 | "id": "2d9478545017ca2c", 724 | "type": "leaf", 725 | "state": { 726 | "type": "outline", 727 | "state": { 728 | "file": "면접을 위한 CS 전공지식 노트/디자인 패턴/1.1 디자인 패턴.md" 729 | }, 730 | "icon": "lucide-list", 731 | "title": "1.1 디자인 패턴 개요" 732 | } 733 | } 734 | ] 735 | } 736 | ], 737 | "direction": "horizontal", 738 | "width": 300, 739 | "collapsed": true 740 | }, 741 | "left-ribbon": { 742 | "hiddenItems": { 743 | "switcher:빠른 전환기 열기": false, 744 | "daily-notes:오늘의 일일 노트 열기": false, 745 | "graph:그래프 뷰 열기": false, 746 | "canvas:새 캔버스 만들기": false, 747 | "templates:템플릿 삽입": false, 748 | "command-palette:명령어 팔레트 열기": false 749 | } 750 | }, 751 | "active": "05e3494ac5f57d7e", 752 | "lastOpenFiles": [ 753 | "면접을 위한 CS 전공지식 노트/디자인 패턴/1.1 디자인 패턴.md", 754 | "면접을 위한 CS 전공지식 노트/디자인 패턴/1.2 프로그래밍 패러다임.md", 755 | "8학기 (25-2)/데이터통신/2. Application 계층 (응용계층).md", 756 | "8학기 (25-2)/데이터통신/1. 서론.md", 757 | "8학기 (25-2)/파일처리/6. 인덱스 구조 - 이진탐색트리, AVL 트리.md", 758 | "8학기 (25-2)/파일처리/5. 화일의 정렬합병.md", 759 | "8학기 (25-2)/파일처리/4. 순차 화일.md", 760 | "8학기 (25-2)/파일처리/1. 파일의 기본 개념.md", 761 | "8학기 (25-2)/파일처리/2. 파일 저장장치.md", 762 | "8학기 (25-2)/파일처리/3. 파일의 입출력 제어.md", 763 | "Pasted image 20250428221316.png", 764 | "Pasted image 20250428213925.png", 765 | "8학기 (25-2)/지능형시스템/6. 머신러닝 기초.md", 766 | "8학기 (25-2)/지능형시스템/1. 인공지능 기초.md", 767 | "8학기 (25-2)/파일처리/README.md", 768 | "Pasted image 20250427165753.png", 769 | "8학기 (25-2)/지능형시스템/README.md", 770 | "8학기 (25-2)/데이터통신", 771 | "2025-04-26.md", 772 | "Pasted image 20250426160403.png", 773 | "8학기 (25-2)/파일처리/6-2. 인덱스 구조 - AVL 트리.md", 774 | "8학기 (25-2)/파일처리", 775 | "8학기 (25-2)", 776 | "코틀린 코루틴의 정석/README.md", 777 | "8학기 (25-2)/지능형시스템", 778 | "면접을 위한 CS 전공지식 노트/네트워크/2.1 네트워크의 기초.md", 779 | "코딩테스트 준비하기.md", 780 | "면접을 위한 CS 전공지식 노트/네트워크/2.2 TCPIP 4계층 모델.md", 781 | "면접을 위한 CS 전공지식 노트/네트워크/2.4 IP주소.md", 782 | "면접을 위한 CS 전공지식 노트/네트워크/2.3 네트워크 기기.md", 783 | "면접을 위한 CS 전공지식 노트/네트워크/2.5 HTTP.md", 784 | "스크린샷 2024-12-12 오후 1.28.19.png", 785 | "스크린샷 2024-12-12 오전 11.27.07.png", 786 | "스크린샷 2024-12-12 오전 11.25.56.png", 787 | "코틀린 코루틴의 정석/6장 CoroutineContext.md", 788 | "코틀린 코루틴의 정석/7장 구조화된 동시성.md", 789 | "코틀린 코루틴의 정석/5장 async와 Deferred.md", 790 | "Pasted image 20241129135836.png", 791 | "스크린샷 2024-11-28 오후 1.40.12.png", 792 | "스크린샷 2024-11-28 오후 1.36.51.png", 793 | "면접을 위한 CS 전공지식 노트", 794 | "코틀린 코루틴의 정석", 795 | "Flutter", 796 | "정보처리기사", 797 | "SpringBoot in Action", 798 | "알고리즘", 799 | "무제 파일.canvas" 800 | ] 801 | } -------------------------------------------------------------------------------- /2025-04-26.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/2025-04-26.md -------------------------------------------------------------------------------- /8학기 (25-2)/데이터통신/1. 서론.md: -------------------------------------------------------------------------------- 1 | # 1.1 인터넷이란? 2 | 3 | 1. 구성 요소 관점에서의 인터넷 4 | 1. 망 구성 요소 4가지 5 | 1. host 6 | 1. 사용자 디바이스(running app), 각 서버 7 | 2. end system 8 | 2. 링크 9 | 1. 무선 90% / 유선 10 | 2. 장비-장비 / 호스트-장비 11 | 3. 연결하고 신호 보내기 12 | 3. 인터넷 장비 13 | 1. 스위치: 2계층 능력. 길 못찾음. 연결만 14 | 2. 라우터: 3계층 능력. 길찾기 + 연결 15 | 4. 프로토콜 16 | 1. 메시지 포멧. 배열 순서 등을 약속 17 | 2. 서비스 관점에서의 인터넷 18 | 19 | 20 | 21 | # 1.2 엣지 22 | > host들(클라이언트 시스템, 서버 시스템)이 액세스 장비를 통해서 묶어 묶어서 코어 쪽으로 들어가는 부분만 23 | 24 | network edge = 망 코어 쪽으로 접속시키는 역할을 하는 것 25 | 26 | access network 장비 = host 여러개를 묶어서 코어한테 전달 27 | host * n -> access network 장비 -> 코어 28 | 29 | 종류 30 | 1. residential access network: 거주지역 31 | 2. institutional access network: 기관(관공서, 학교, 회사 등) 32 | 3. mobile/wireless access network: 와이파이, 셀룰러 33 | 34 | bandwidth = 대역폭 = 통신할 수 있는 주파수의 범위 35 | - 속도는 대역폭의 크기에 비례 36 | - 주파수의 주인은 국가(허락받아서 씀) 37 | - tv채널, 라디오, 이동통신망 등 얘네들의 대역폭이 할당되어있음 38 | - 음성만 있는것 보다 음성+영상이면 대역폭이 더 큼 39 | 40 | ## 1. residential access network: 거주지역 41 | - DSL digital subscriber line 42 | - 가정집에서 전화선으로 전화도 하고 데이터도 하고 43 | - DSLAM 교환기 44 | - 모듈레이션 45 | | 음성 4 내거 | 음성 4 상대방거(양방향이어야하니까) | data(upstream 1Mbps+ downstream 10Mbps) | 46 | - 케이블 네트워크 47 | - 만개의 가정에 300개의 채널을 항상 보냄. 48 | - 300개의 채널 중에 하나를 "리모컨(밴드 패스 필터)"으로 전환 49 | - TV는 전화선보다 더큰 비싼 선을 씀 50 | - 채널이 남는다 -> 케이블 모뎀 | TV 채널 | 남는거 인터넷 | 51 | 52 | FDM: 주파수를 나눠서 다중화 시키겠다. 53 | 겹치지 않게 분할해서 여러 채널을 줌 -> 필터(리모컨)으로 뽑아서 쓸 수 있음 54 | - DSL 모뎀 55 | - 케이블 모뎀 56 | 57 | ## 2. institutional access network: 기관(관공서, 학교, 회사 등) 58 | 한정된 공간에 여러대가 몰려 있는 형태 59 | 60 | LAN 스위치 61 | 62 | 63 | 64 | ## 3. mobile/wireless access network: 와이파이, 셀룰러 65 | wireless 안에 mobile이 포함되는 개념 66 | - wireless 67 | - 그냥 무선 68 | - AP(access potin)가 계속 신호를 쏴. beacon(등대)처럼 69 | - mobile (셀룰러) 70 | - 무선 + 이동성 71 | - base station(기지국)이 주기적으로 계속 신호를 보냄 72 | - host(폰)은 기지국에 계속 응답을 보냄 -> 위치파악을 할 수 있음 73 | 74 | 75 | 링크 76 | - guided media 무선 77 | - unguided media 유선 78 | - TP (twisted pair): 구리. 낮은 대역대 79 | - Coxial cable: 구리. 낮은 대역대 80 | - 광섬유 fiber optic cable: 빛. 높은 대역대(넓은 대역대) 요즘 장비와 장비 사이는 다 이걸로 바꿈. 81 | 82 | # 1.3 코어 83 | 84 | 85 | ## 서킷 스위칭 86 | 1. 유선 전화 87 | 2. 셀룰러 (요즘은 패킷으로 바뀜) 88 | 3. 인터넷 89 | 1. 유선 전화망 전국망 3개 90 | 2. 셀룰러 이동통신망 3개가 전국에 다 깔려 있음 (물리적으로 완전히 독립된 망) 91 | 3. 인터넷도 다 각각 존재 92 | 93 | 94 | 95 | 서킷스위칭의 단계 96 | 1. set up 97 | 2. data communication 98 | 3. disconnection 99 | 100 | 101 | 그 102 | 103 | ## 패킷 스위칭 104 | > 패킷으로 데이터를 나눔. 패킷들이 각각 라우터에 거칠때마다 스톱을 해서 store. 자기 차례가 되길 기다렸다가 자기 차례가 되면 순서를 라우터한테 물어봐. 가 이거 반복 목적지까지 찾아감. 105 | 106 | 음성 말고 char, text, 사진, 동영상 -> 실시간성 x 이메일 o 107 | 108 | 각 데이터를 패킷으로 자른다. 109 | 패킷들이 노드 마다 store and forward 하면서 최종 목적지까지 간다. 110 | 111 | 패킷 안에 목적지 ip 주소가 있다. 112 | 라우터가 그걸 보고 라우팅 알고리즘으로 계획을 세운다. 113 | 114 | 115 | 116 | 117 | 118 | # 인터넷 스트럭쳐 119 | 인터넷 스트럭쳐 = 네트워크 오브 네트워크 120 | 수많은 네트워크들이 다 묶여서 하나의 네트워크로 만든게 인터넷의 구조 121 | 122 | 123 | ## ISP internet structure provider 124 | 망 사업자 여러명임. 125 | 126 | - global 다른나라 해저 케이블 127 | - national 국가 128 | - regional 지역 129 | 130 | 131 | 132 | 각 가구마다 1:1 연결 아님. 이렇게 되면 한 가구 전입하면 해야하는 작업이 너무 많음 133 | access net을 global ISP(core)에 연결하는 방식으로 구현 134 | 135 | 좀더 일반적이게 말하자면 사업자가 여러명이다. (우리나라 3사 (kt, lg, skt)) 136 | IXP internet exchange point = 다른 ISP에 묶여 있더래도 다 뚫어놓음 => 어디든 갈 수 있게 만들어놓았다. 137 | 138 | 139 | # 1.4 delay, loss, throughput 140 | 141 | 성능지표 142 | 143 | loss는 작고 delay도 작고 throughput은 커야 좋다. 144 | 145 | ## loss 손실 146 | 버퍼에서 흡수가 가능한데, 147 | 오랜시간 버퍼가 넘치면 흡수가 안되기 떄문에 손실이 된다. 148 | 149 | ## delay 지연 150 | - processing delay : 노드에서 처리하는 시간 151 | - queueing delay : 버퍼에서 나갈때까지의 대기 152 | - transmission delay : 0,1 신호로 바꾸는데에 얼마나 걸리느냐 153 | - propagation delay(전파지연) : 신호가 전파할때 걸리는 시간 154 | 155 | 딜레이를 측정하는 방법이 trace route 156 | - 서버를 하나 지정해서 각 단계를 거쳐가면서 얼마만큼 지연이 걸리는가 측정하는 패킷을 만듦 157 | 158 | 159 | ## throughput 수율 160 | 161 | 받는 속도 162 | 163 | 100Mbps로 보냈는데, 200Mbps로 받을 수는 없다. 164 | 느렸던 놈이 빨라지진않는다. 165 | 166 | bottleneck = 병목 167 | - bottomneck link는 계속 바뀜 168 | - 각 링크의 속도도 계속 바뀜 1/n라서 169 | 170 | - instantaneous throuphput : 순간 수율 171 | - average throuphput : 그냥 평균 172 | 173 | 174 | # 1.5 프로토콜 레이어, 서비스 모델 175 | 176 | > 분업을 하자 177 | 178 | - 인터넷 프로토콜 179 | 1. application : 앱 180 | 2. transport : 전송 181 | 3. network : routing & forwarding. 목적지 IP 주소를 보고 길 정해놓기. 매 장비 지날때 마다 store & forward 182 | 4. link : 실제 전송 183 | 5. physical : 184 | 185 | 186 | - 수평관계 : 같은 계층끼리만 대화를 하고 187 | - 상하관계 : 시킨다 188 | 189 | - encapsulation : 헤더를 하나씩 씌워 190 | - decapsulation: 헤더를 하나씩 벗겨 191 | 192 | Message + H t = segment 193 | sement + H n = datagram 194 | datagram + H l = frame 195 | -------------------------------------------------------------------------------- /8학기 (25-2)/데이터통신/2. Application 계층 (응용계층).md: -------------------------------------------------------------------------------- 1 | # 2.1 개요 2 | 1. 서버-클라이언트 3 | - 서버 4 | - 고정 ip 5 | - 클라이언트 6 | - 다이나믹 ip 7 | 2. P2P 8 | - P2P: 클라이언트끼리 네트워크 형성 9 | ---- 10 | 11 | - 프로세스 : 프로그램이 돌아가는거 host에서 12 | - 소켓 13 | 5계층-4계층 사이의 인터페이스 되는 부분 (API) 14 | - ip 주소 / 포트 넘버 15 | - identifier임 16 | 17 | - 신텍스 (외관 구조. 문법. format) 18 | - 세멘틱스 (의미) 19 | - 시퀀스 (클라이언트랑 서버가 신텍스랑 시멘틱스로 맞춰진 메시지를 가지고 주고받고 주고받고 한다~) 20 | 21 | --- 22 | 23 | - 나머지 3,2,1 계층은 다 똑같음. 패킷스위칭을 쓴다면 랜덤 딜레이, 랜덤 로스가 있음. 그럼 뭘 다르게 해? 24 | - 서킷 스위칭이며 100% 실시간이긴 함 ㅋㅋㅋ 하지만 비싸죠 25 | - TCP: 로스는 100% 커버쳐줌. 문서 26 | - UDP: 로스는 책임 x. 조금 빨라. 가벼워. 실시간성 27 | 28 | 29 | # 2.2 웹 HTTP 30 | 31 | HyperText Transfer Protocol 32 | 33 | 1. TCP 커넥션을 연결한다. 포트 번호 80번 34 | 2. request <-> response 35 | 36 | ## non-persistent HTTP 37 | 1. TCP 커넥션 오픈 38 | 2. HTTP 리퀘스트 보내 39 | 3. 회신을 받았어. Base HTML + Object 3개 필요한거 알았지만 끊어 40 | 4. TCP 하나 연결하고 오브젝트 하나 * 3 (TCP끊고 다시 열고 갖고 오고 ~) 41 | 42 | RTT = Round Trip Time 왕복시간 43 | 44 | 오브젝트 당 TCP 열어야함. 2RTT 45 | ## persistent HTTP 46 | 한번 TCP 열고 필요한 만큼 한번에 다 가져오고 TCP close 47 | TCP 한번 열고 리퀘스트 리스펀스 오브젝트 숫자만큼만 48 | 49 | 50 | 51 | ## non-persistent parall HTTP 병렬 52 | 멀티로 TCP를 열어놓고 오브젝트를 동시에 여러개 갖고 온다 53 | base HTML 가져와 54 | 오브젝트 3개 필요하다는 사실 알아냄. 55 | TCP를 병렬로 3개를 열어 56 | 57 | Object 수가 많을 때는 persistent 보다 non-persistent parall이 훨씬 이득이다. 58 | 59 | ## request 60 | 61 | ## Cookie 62 | - HTTP는 stateless다. = 상태가 없다. 63 | - client와 주고 받은 메시지를 기억하지 않는다. 64 | - 왜? 서버에 부담이 되니까. 과부화를 방지하기 위해서 65 | - but, 좋은 서버를 구축해서. 고객 관리, 알고리즘을 하고 싶음. request를 일일히 기록 66 | ### 쿠키 4 컴포넌트 67 | 1. response message에 set-cookie(쿠키 id) 달아서 나감 68 | 2. request message 쿠키 id 할당해서 나감 69 | 3. 실행 코드(set-cookie=쿠키 id)를 개인 pc에 저장한다. 70 | 4. DB에 쿠키 id 할당해서 저장 71 | 72 | 장점: 쿠폰 보내주고, 맞춤 추천 73 | 단점: 개인정보 유출 위험 74 | 75 | ## web proxy server 76 | - proxy = 대리인 77 | - web caches 웹 오브젝트들을 저장하는 저장소. 메모리 78 | - 오리진 서버 앞에 대리서버가 잇음. 79 | - 웹 오브젝트를 캐시에 넣으면 더 빠른 메모리에 저장. 80 | - 요청한 내용이 프록시에 있었다면 바로 빨리 줄 수 있음. 81 | - 오브젝트에 타이머를 달아놓고 그 시간 안에 누군가 쓰지 않으면 타임아웃. 누가 호출한다면 다시 타이머 리셋. -> 누구나 좋아하는 콘텐츠가 살아남음. 자주 보는 것 82 | - 이점 83 | 1) 지연 줄이기 reduce response time 84 | 1) 트래픽 감소 딜레이 감소 85 | 2) institutional access link의 트래픽을 감소시킨다. 86 | 1) hit ratio 가 40%다. 100개가 오면 40개는 프록시에서 해결 87 | 2) 엑세스 링크에서 밖으로 나가는걸 줄였다. -> 코어에 들어가는걸 줄였다. = 코어에서 발생하는 딜레이, 로스가 줄었다. 88 | 3) 인기 있는 콘텐츠는 계속 살아남는다. 89 | 1) 가난한 콘텐츠 프로바이어한데 이득을 준다. = 인기 있는 콘텐츠들을 효과적으로 배포시키낟. 90 | 91 | # 2.3 이메일 SMTP 92 | # 2.4 DNS(Domain Name System) 93 | # 2.5 P2P 94 | 95 | - file sharing 서비스 96 | - 서버 x 97 | - 클라이언트가 일부 파일을 각자 저장 -> 얘가 공유할때는 서버가 됨 98 | - 클라이언트가 될 수도 있고 서버가 될 수도 있음 99 | - client-server보다 p2p가 더 다운로드 속도가 빠름. 왜? 서버가 여러대니까. 광고료 위주고 (but 비즈니스 형태는 client-server임) 100 | - ex) uTorrent 101 | 102 | 토렌트에 접속하면? 103 | 1. tracker(server) 104 | 1. 메시지를 통해서 IP address를 줌(등록) 105 | 2. 다른 애들 ip address list를 줌 3~5개 106 | 2. 파일 공유~ 107 | # 2.6 비디오 스트리밍 108 | - 유튜브, 넷플릭스 등 109 | - challenge할 요소 110 | 1) 글로벌 하게 있는 수 많은 애들한테 어떻게 주지? 111 | 2) 각각 기기의 디스플레이 크기나 스펙 등이 다 다른데(heterogeneity) 어떻게 하지? 112 | - 비디오 24/1sec * 24bit(R,G,B) * 10^6 (1000 * 1000)픽셀 (화소) 113 | - 코딩하는 법 114 | 1. spatial coding (공간적) 115 | 빨빨빨빨빨이면 `빨 * 5` 이런식으로 압축해서 보냄 116 | 2. temporal coding (시간적) 117 | i, i+1, i+2, i+3 ..... 다보내는게 아니라 i와의 차이만 보냄. i와 i+1의 차이 118 | - 유튜브 -------------------------------------------------------------------------------- /8학기 (25-2)/지능형시스템/1. 인공지능 기초.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/8학기 (25-2)/지능형시스템/1. 인공지능 기초.md -------------------------------------------------------------------------------- /8학기 (25-2)/지능형시스템/6. 머신러닝 기초.md: -------------------------------------------------------------------------------- 1 | 2 | ## 🧩 1. **추론 방식의 차이** 3 | 4 | |구분|설명|예시| 5 | |---|---|---| 6 | |**연역 추론**|일반 → 구체|모든 인간은 죽는다. 소크라테스는 인간이다 → 소크라테스는 죽는다| 7 | |**귀납 추론**|구체 → 일반|A, B 고양이 모두 수염이 있다 → 모든 고양이는 수염이 있다| 8 | 9 | ------- 10 | ## 🔍 2. **AI, ML, DL의 관계** 11 | 12 | - **AI(인공지능)**: 인간의 사고를 모방하는 기술 전반 | 컴퓨터가 인간처럼 사고하고 판단하도록 만드는 기술 13 | 14 | - **ML(머신러닝)**: AI 중 **데이터 기반 학습**을 통해 스스로 규칙을 찾음 | 컴퓨터에 인간의 학습능력과 같은 기능을 부여하는 기술 15 | 16 | - **DL(딥러닝)**: 머신러닝 중 **인공신경망 기반 모델** 사용. 층이 깊음 | 인간 두뇌가 작동하는 방식을 기반으로 한 빅데이터 분석 기술을 구현 17 | 18 | --- 19 | 20 | ## 📚 3. 머신 러닝 - **지도학습 vs 비지도학습** 21 | 22 | - **지도학습**: 데이터 + 정답(label) → 분류(Classification), 회귀(Regression) 23 | 24 | - **비지도학습**: 정답 없이 데이터 간 패턴 파악 → 클러스터링 등 25 | 26 | - 데이터와 라벨이 있는지 여부가 핵심 차이! 27 | 28 | 29 | --- 30 | 31 | ## 🧾 4. **데이터 표현** 32 | 33 | - **Sample(샘플)**: 하나의 데이터 포인트 (예: 수박 1개) 34 | 35 | - **Feature(속성)**: 샘플의 특성 (색, 소리, 꼭지 모양 등) 36 | 37 | - **Feature Value**: 각 특성의 구체적 값 (ex: 초록색, 말림, 청아) 38 | 39 | - 데이터를 숫자로 변환 → **벡터** 형태 → 머신러닝 모델의 입력 40 | 41 | 42 | --- 43 | 44 | ## 🎯 5. **학습 목표와 오차** 45 | 46 | - 목표: 실제 값 `y`와 예측 값 `ŷ`의 차이 줄이기 47 | 48 | - 자주 쓰는 오차 지표: 49 | 50 | - **MSE (Mean Squared Error)**: 오차 제곱의 평균 51 | 52 | - **MAE (Mean Absolute Error)**: 오차의 절대값 평균 53 | 54 | - **RMSE**: MSE의 제곱근 (단위 맞춤용) 55 | 56 | - **MAPE**: 퍼센트 오차 기준 57 | 58 | 59 | --- 60 | 61 | ## ⚖️ 6. **Bias-Variance Trade-off** 62 | 63 | |구분|설명| 64 | |---|---| 65 | |**Bias (편향)**|모델이 단순해서 학습이 부족한 상태 (Underfitting)| 66 | |**Variance (분산)**|모델이 복잡해서 학습 데이터에만 너무 맞춤 (Overfitting)| 67 | 68 | - 머신러닝의 핵심 과제: 둘의 균형 맞추기 69 | 70 | 71 | --- 72 | 73 | ## 🔧 7. **가설, 모델, 학습** 74 | 75 | - **가설(Hypothesis)**: 데이터 → 예측을 위한 수식 형태 76 | 77 | - **모델(Model)**: 가설 + 파라미터(예: β₀, β₁) 78 | 79 | - **학습(Learning)**: 파라미터를 데이터 기반으로 조정하는 과정 80 | 81 | 82 | --- 83 | 84 | ## 📊 8. **데이터 분리** 85 | 86 | - **Train Set**: 학습용 데이터 87 | 88 | - **Validation Set**: 모델 구조 튜닝용 89 | 90 | - **Test Set**: 최종 성능 평가용 (모델이 학습하지 않은 데이터) 91 | 92 | 93 | --- 94 | 95 | ## 🚨 9. **과적합 vs 과소적합** 96 | 97 | |구분|설명|결과| 98 | |---|---|---| 99 | |**과소적합 (Underfitting)**|모델이 너무 단순|학습도 못함| 100 | |**과적합 (Overfitting)**|모델이 너무 복잡|학습 데이터만 잘 맞추고 새로운 데이터는 못 맞춤| 101 | 102 | --- 103 | 104 | ## 🎯 10. **예측 불가능성과 노이즈** 105 | 106 | - 실제 관측값 = 이상적인 함수값 + **노이즈** 107 | 108 | - 노이즈는 줄일 수 없으며, 오차를 **Reducible** / **Irreducible** Error로 나눔 109 | 110 | - **샘플 수 증가** → 관측 오차(분산) 감소 가능 → "빅데이터가 중요한 이유" 111 | 112 | 113 | --- 114 | 115 | # 📝 시험 예상 문제 116 | 117 | ### ✅ **객관식** 118 | 119 | 1. 다음 중 귀납 추론의 예는? 120 | 121 | - A. 모든 고양이는 수염이 있다 → A는 고양이다 → A는 수염이 있다 122 | 123 | - B. A 고양이와 B 고양이 모두 수염이 있다 → 모든 고양이는 수염이 있다 ✅ 124 | 125 | 2. 머신러닝 모델이 복잡하여 학습 데이터에만 잘 맞고 새로운 데이터엔 성능이 낮은 현상은? 126 | 127 | - A. Underfitting 128 | 129 | - B. Overfitting ✅ 130 | 131 | - C. Noise 132 | 133 | - D. Generalization 134 | 135 | 3. 지도학습에서 반드시 필요한 것은? 136 | 137 | - A. 클러스터 수 138 | 139 | - B. 학습용 모델 140 | 141 | - C. 정답 라벨 ✅ 142 | 143 | - D. 차원 축소 144 | 145 | 4. 다음 중 평가 지표가 아닌 것은? 146 | 147 | - A. MSE 148 | 149 | - B. MAE 150 | 151 | - C. RMSE 152 | 153 | - D. GBT ✅ 154 | 155 | 156 | --- 157 | 158 | ### ✍️ **서술형** 159 | 160 | 1. 연역 추론과 귀납 추론의 차이를 예시와 함께 설명하시오. 161 | 162 | 2. Bias와 Variance가 높은 경우 각각 어떤 문제가 발생하는지, 이를 조절하는 방법은 무엇인지 설명하시오. 163 | 164 | 3. 머신러닝에서 오버피팅이 발생하는 이유와 방지 방법을 기술하시오. 165 | 166 | 4. 학습, 검증, 테스트 데이터셋의 역할을 각각 설명하시오. 167 | 168 | 5. MSE, RMSE, MAE, MAPE의 정의와 각각의 장단점을 비교하여 설명하시오. 169 | 170 | -------------------------------------------------------------------------------- /8학기 (25-2)/지능형시스템/README.md: -------------------------------------------------------------------------------- 1 | 1. 인공지능 소개 2 | 2. 탐색 3 | 3. 게임 4 | 4. 전문가 시스템 5 | 5. 유전 알고리즘 6 | 6. 머신러닝 기초 -------------------------------------------------------------------------------- /8학기 (25-2)/파일처리/1. 파일의 기본 개념.md: -------------------------------------------------------------------------------- 1 | 8정보 /=/ 데이터 2 | 데이터 -> 처리 -> 정보 3 | 처리된 데이터를 정보라고 함 4 | 5 | 파일구조에서 가장 중요한 점 ==디스크 접근을 최소화하는것== 6 | 7 | 1. 디스크에 데이터를 어떻게 저장할 것인가 8 | 2. 디스크와 메인 메모리 사이에서 데이터를 어떻게 효율적으로 전송할 것인가? 9 | 10 | 파일구조란? 11 | - 데이터 표현 + 데이터에 접근하는 연산 12 | 13 | 14 | 파일 기능에 따라 분류 15 | 1. 마스터 파일 16 | 1. 삽입, 삭제, 갱신 -> 비교적 영속적 데이터 레코드를 포함 17 | 2. 현재성을 정확히 유지 18 | 3. 보통 "파일" 19 | 2. 트랜잭션 파일 20 | 1. 마스터파일에 적용할 트랜잭션을 모아놓은 파일 21 | 2. 트랜잭션 = 논리적인 작업 단위 22 | 3. 삽입,삭제,수정 23 | 3. 보고서 파일 24 | 4. 작업 파일 25 | 5. 프로그램 파일 26 | 6. 텍스트 파일 27 | 28 | 29 | 파일의 접근 목적에 따라 분류 30 | 1. 입력 파일: 판독(READ) 31 | 2. 출력 파일: 기록(WRITE) 32 | 3. 입출력 파일 33 | 34 | 35 | 파일을 어떤 형태로 사용할 것인가 는 파일을 구성할때 중요한 요소이다. 36 | 1. 일괄 처리(batch) 형식 37 | 2. 대화 (interactive)형식 38 | 39 | 40 | 파일 연산의 성격 41 | 1. 파일 생성 42 | 2. 파일 기록 (갱신, 삽입, 삭제) write? 43 | 3. 파일 판독 (파일 이름, 블록 명세) read 연산 44 | 4. 파일 삭제 45 | 5. 파일 개방과 폐쇄(버퍼 할당과 반환) 46 | 47 | 48 | 파일구조를 선정하는 요소 49 | 1. 가변성 50 | 2. 활동성 51 | 1. 활동성이 높으면 순차파일 유리 52 | 3. 사용빈도수 53 | 1. 빈도수가 낮으면 순차파일 / 빈도수가 높으면 임의접근 유리 54 | 4. 응답시간 55 | 1. 응답시간이 빨라야하면 임의접근 / 정렬된 키가 있다면 순차접근 56 | 5. 파일 크기 57 | 6. 파일 접근 유형 58 | 1. 판독 위주인지? 갱신위주인지? 59 | 2. 순차접근이 주도하는지? 임의 접근이 주도하는지? -------------------------------------------------------------------------------- /8학기 (25-2)/파일처리/2. 파일 저장장치.md: -------------------------------------------------------------------------------- 1 | # 저장장치 2 | - 저장장치 = 저장매체 + 매체에 데이터를 저장하고 검색하기 위한 장치 3 | - 저장매체: ==소멸성 vs 비소멸성== 4 | - 접근장치: 데이터를 판독하거나 기록하는 장치 5 | 6 | 1. 1차 저장장치 7 | 1. ==메인 메모리== 8 | 2. ==캐시 메모리== 9 | 2. 2차 저장장치 10 | 1. 자기디스크 : 데이터 접근이 느리다. 하지만 싸서 화일 저장에 쓰인다. 11 | 1. ==하드디스크== 12 | 2. 유연한 디스크 13 | 2. 플로피 디스크 14 | 3. ~~광 디스크~~ 15 | 4. ~~자기 테이프~~ 16 | 17 | 18 | 19 | 20 | | 고가
| 캐시 메모리 | 빠름 | 21 | | -------- | ------- | --- | 22 | | | 메인 메모리 | | 23 | | | 플래시 메모리 | | 24 | | **비용** | 자기 디스크 | 속도 | 25 | | | 광 디스크 | | 26 | | 저가 | 자기 테이프 | 느림 | 27 | # 저장장치의 유형 28 | 29 | ## 1. 캐시메모리 30 | - 가장 빠르고 가장 비쌈 31 | - SRAM(static random access memeory) 32 | - 데이터를 유지하기 위해 자주 재생할 필요가 없음 33 | - 메인메모리 성능향상 목적 34 | 35 | ## 2. 메인 메모리 36 | - 프로그램 실행과 이에 필요한 데이터 유지 공간 37 | - DRAM (dynamic random access memory) 38 | - 용량이 적고 소멸성(데이터 저장에는 부적합) 39 | - 내용 접근 시간은 일정하고 빠름 40 | - 프로그램/데이터를 처리하기 위한 작업공간 41 | 42 | ## 3 .플래시 메모리 43 | - 고밀도 고성능 메모리로서 ==비소멸성== 44 | - 메인 메모리와 비슷한 접근 속도 45 | - ==재기록 시 한 블록 전체를 동시에 지우고 기록해야함== 46 | 47 | ## ==4. 자기 디스크== 48 | - 데이터 저장 장치의 주 매체 49 | - 데이터 처리와 기록은 메인 메모리를 거쳐야함 50 | - 대용량이고 비소멸성 51 | - 직접 접근 저장 장치 중 가장 많이 쓰임 52 | - 종류 53 | 1) 하드디스크 54 | 2) 유연한 디스크 : 플로피 디스크 등 55 | - 분류 기준 56 | - 기록 표면수 57 | - 데이터 전송률 58 | - 기록/판독 헤드 이동시간 59 | - 접근 방법 60 | - 회전 지연 61 | - 밀도 62 | ### 4-1. 자기 디스크의 물리적 특성 63 | 1. 디스크 팩 64 | 1. 디스크 원반의 모음 65 | 2. ==양면 사용(맨위, 맨아래는 제외. 11개 디스크는 20면)== 66 | 2. 디스크 구동기 67 | 1. 제어기, 접근 암, 판독기록 헤드, 팩 회전 장치 68 | 2. 고정식, 탈착식 69 | 3. 디스크 제어기 70 | 1. 원하는 데이터가 어느 구동기, 어느 면, 어느 주소에 있는지 판독 71 | 2. 버퍼 관리 72 | 3. 오류 발견,수정 73 | 4. 판독 기록 관리 74 | 75 | ### 4-2. 데이터 저장 76 | - 트랙: 갭으로 분리된 섹터들로 구성 77 | - 섹터: 기록과 판독 작업의 최소 단위 78 | - 실린더: 지름이 같은 모든 트랙(헤드가 읽을때 실린더를 한번에 읽음) 79 | 80 | - 블록: 디스크와 메인 메모리 사이에 전송되는 데이터의 논리적 단위 81 | - 블록은 하나 이상의 섹터로 구성 82 | 83 | ### 4-3. 유동 헤드 디스크와 고정 헤드 디스크 84 | 1. 유동 헤드 디스크 85 | 1. 각 기록 면마다 판독 기록 헤드가 있음 86 | 2. 판독 기록시 헤드가 원하는 트랙에 위치하도록 엑세스암을 이동 87 | 3. ==전송 시간 = 데이터를 동일면 보다 동일 실린더에 저장하는 것이 효율적== -> 같은 실린더에 있는 데이터는 한번에 읽을 수 있음 88 | 2. 고정 헤드 디스크 89 | 1. 기록면의 각 트랙마다 하나의 판독기록 헤드가 있음 90 | 2. 판독기록을 위해 헤드를 이동시킬 필요가 없음 91 | 92 | ### 4-4. 윈체스터 디스크 93 | - ==보편적인 하드디스크가 "윈체스터 디스크"임== 94 | - 기록면, 접근 장치, 판독 기록 헤드가 함께 밀봉 95 | - 기록 밀도가 높음 -헤드가 디스크에 근접 96 | - 회전속도 5400~10000rpm 97 | - 단일 최대용량은 30TB (4년뒤 두배 예상) 98 | ## 5. 플로피 디스크 99 | - 이젠 안씀 100 | - 유연한 디스크 101 | - 회전속도 360rpm 102 | - ==수직축 기록==: 저장용량을 늘리기 위한 신기술(표면과 수직방향으로 자화시켜 각 자화점의 표면 폭을 축소시킴. 밀도 50배 이상 향상) 103 | 104 | 105 | ## 디스크 저장장치의 특성 106 | 1. 디스크 특성요소 107 | 1. 회전 속도 108 | 2. 디스크 드라이브의 원반수(원반수에 2곱하면 기록면 개수) 109 | 3. 기록 면당 트랙수 110 | 4. 트랙당 섹터수 111 | 5. 섹터당 바이트 수 112 | =>다 곱하면 용량이 나온다 113 | 114 | 2. ==데이터 접근 시간== 115 | 1. 탐구시간 s 116 | 2. 회전 지연시간 r = 1/2 * 1회전시간 117 | * 회전 속도가 3,600rpm인 디스크에서 r은 몇 ms?  60sec : 3600 = x : 1  , x=8.33ms 118 | 3. 전송시간 t 119 | 3. ==블로킹== 120 | 1. 블로킹 : 디스크와 메인메모리 사이의 데이터 전송 단위: 물리적레코드 121 | 2. 트랙의 길이 = b * B 122 | 3. 블록의 길이 < = 트랙의 길이 123 | 4. 블록의 크기 124 | 1. 보통 512byte, 1kb, 4km 125 | 2. 너무 크면 불필요한 데이터 전송을야기 126 | 3. 과다한 버퍼할당으로 메모리 효율성을 저하 127 | 5. ==블로킹 인수 BF = 한 블록에 포함시킬 수 있는 논리적 레코드 수== 128 | - 메인 메모리와 입출력 효율을 위해 몇개의 논리적 레코드를 하나의 물리적 레코드에 저장시키는 것 129 | - 논리적 레코드 = 사용자가 데이터를 저장하기 위한 논리적 단위 130 | 6. 블로킹 방법 131 | ![[Pasted image 20250428213925.png]] 132 | 1. 고정길이 블로킹 133 | 1. 레코드의 길이를 기록하지 않아도됨 134 | 2. 신장된 가변길이 블로킹 135 | 1. 신장 = 한 레코드가 인접한 몇개의 블록에 걸쳐 저장 136 | 2. 효율적으로 저장되긴함 (낭비 x) 137 | 3. 레코드의 길이 정보도 기록 해야함(R4가 쪼개져 있다는 정보를 저장해야함) 138 | 3. 비신장된 가변길이 블로킹 139 | 1. 하나의 레코드를 쪼개진 않음 140 | 2. 그냥 가변길이이기만 함 141 | 7. 레코드와 블록 142 | 1. 블록헤더= 블록내의 레코드 수, 블록 아이디, 블록 수정 날짜,....... 부가적인 정보를 저장 143 | 2. 고정길이 블로킹일때는 레코드의 길이만 알면 레코드를 구분할 수 있다. 144 | 3. ==가변길이 블로킹일때는 레코드의 길이가 다 다르기 때문에 길이를 적어줘야함== 145 | 1. 레코드 끝 마크 = 레코드 사이에 분리 표시 146 | 2. 각 레코드 앞에 길이 지시자 147 | 3. 블록 헤더위에 위치 테이블 148 | 4. 하지만 블록헤더에 저장을 너무 많이해서 블록 안에 있는 레코드가 작아지는 것을 조심해야함 149 | 4. 레코드 설계시 고려사항 150 | 1. 메인 메모리 바이트 주소(4의 배수) 특성 151 | 2. 레코드 헤더 152 | 3. 각 필드는 레코드의 오프셋으로 표현 가능 153 | 8. ==블로킹의 고려사항== 154 | 1. ==적재 밀도== 155 | 1. 갱신(삽입)을 위한 블록 내의 자유공간의 할당 156 | 2. ==실제 데이터가 저장된 공간과 자유공간을 포함한 총 공간과의 비율== 157 | 2. ==균형 밀도== 158 | 1. 레코드 자체의 확장과 축소 159 | 2. 상당히 긴 시간 동안 시스템을 운용하고 안정시킨 뒤에 예상되는 저장 밀도 160 | 3. ==집약성== 161 | 1. 상호 연관이 있는 레코드들의 물리적 접근성 162 | 2. 같은 블록, 트랙, 실린더 163 | 164 | # RAID 165 | - 디스크의 성능과 신뢰성을 증진시키는 디스크 조작기법 166 | - 많은 수의 저가 소형 디스크를 사용 167 | - 고도의 신뢰성 168 | - 고속의 데이터 전송 169 | - 대용량 데이터 저장 170 | - 많은 수의 디스크를 병렬로 작동 171 | - 데이터 판독,기록 속도 개선 172 | - 다중 디스크에 정보를 중복 저장 173 | - 신뢰성 증가 174 | 175 | 1. 디스크 신뢰성 176 | 1. 미러링기법 (=디스크 중복) 177 | 2. 미러링된 디스크 시스템의 장애간 평균 시간은 개별 디스크의 장애간 평균 시간과 수리간 평균 시간에 의존 178 | 2. 디스크 병렬성 179 | 1. 데이터 스트라이핑을 통해서 전송률을 개선 180 | 2. 스트라이핑 단위 = 비트, 블록 181 | 3. 비트레벨 스트라이핑 182 | 1. 각 바이트의 비트를 여러 디스크에 분할 저장 183 | 4. 블록 레벨 스트라이핑 184 | 1. 화일의 블록들을 여러 디스크에 차례로 분산 저장 185 | 2. d 디스크 어레이 186 | 3. d개의 디스크로부터 d개의 블록을 병렬로 판독할 수 있어 d배의 전송률 제공 187 | 188 | 189 | ![[Pasted image 20250428221316.png]] 190 | ## RAID 0 비중복 스트라이핑 191 | - 미러링이나 패리티 비트와 같은 추가 정보를 유지함이 없이 데이터 스트라이핑 기법을 이용 192 | - 디스크 드라이브의 수가 증가함으로써 MTTF가 감소하게 되어 신뢰성이 약함 193 | - 추가 정보가 없기 때문에 기록 성능은 높음 194 | - 데이터 손실이 중요하지 않은 고성능 응용에서 사용 195 | ## RAID 1 미러드 디스크 196 | 데이터 스트라이핑이 없이 하나의 블록은 두개의 상이한 디스크에 저장하여 미러드 디스크 유지 197 | 1. ==기록은 기본 디스크 먼저 수행한 뒤, 미러디스크에 수행== 198 | 2. ==데이터 판독은 두 디스크에 분산시켜 수행하기 때문에 효율적임== 199 | - 디스크 고장 시 데이터 재구성이 용이 200 | - 최고의 기록 성능 제공 - 데이터베이스의 로그 화일 저장에 이용 201 | - 높은 오버헤드 때문에 레벨 3나 5 선호 202 | 203 | ## RAID 2 메모리 스타일 에러 교정 코드 204 | - 비트레벨 스트라이핑 205 | - ==에러 교정 비트를 저장하기 위한 추가 디스크를 사용== - 장애 디스크 식별 가능 206 | 207 | ## ==RAID 5 블록 인터리브드 분산 패리티== 208 | - 데이터랑 패리티를 d+1개의 디스크에 균등하게 분산 저장 (하나의 디스크에만 패리티 비트 저장x) 209 | - 데이터 블록과 이 블록의 패리티 블록은 반드시 상이한 디스크에 저장 210 | - 기록과 판독이 병렬로 수행 211 | - 성능 가장 좋음 212 | - 대부분의 데이터베이스 시스템에서와 같이 임의 판독이 중요할때 213 | 214 | ## RAID 6 P+Q 추가 215 | - 대규모 디스크 어레이에 사용 216 | - ==하나가 아니라 두개의 디스크가 동시에 장애가 일어났을때도 회복 가능== 217 | - 매 4비트 마다 2비트 추가 저장 218 | - 패리티 정보는 블록레벨로 디스크에 균등 분산 저장 219 | - 하나의 데이터 블록을 갱신하기 위해서 패리티 정보를 가진 2개의 블록도 같이 갱신 220 | - 고도의 신뢰성이 요구되는 환경 -------------------------------------------------------------------------------- /8학기 (25-2)/파일처리/3. 파일의 입출력 제어.md: -------------------------------------------------------------------------------- 1 | ppt 70 페이지 2 | 3 | # 운영체제 4 | - 운영체제 = 컴퓨터 자원을 관리하는 sw 5 | 1. 운영체제는 컴퓨터의 모든 자원을 관리 6 | 1. 하드웨어 자원 7 | 2. 소프트웨어 자원 8 | 3. 데이터 자원 9 | 2. 운영체제는 자원에 대한 독점 권한 소유 10 | 1. 자원에 대한 모든 관리 권한은 운영체제한테 있다 11 | 1. 자원 할당, 자원 공유, 자원 엑세스, 자원 입출력 12 | 3. 운영체제는 관리자 13 | 4. 운영체제는 소프트웨어 14 | 15 | 계층 16 | - 응용 소프트웨어 17 | - 운영체제 18 | - 하드웨어 19 | 20 | 1. CPU 21 | 1. 프로그램 코드를 해석하여 실행하는 중앙처리장치 22 | 2. 컴퓨터의 가장 핵심 장치 23 | 3. 전원이 공급될때 작동 시작, 메모리에 적재된 프로그램 실행 24 | 2. 메모리 25 | 1. CPU에 의해 실행되는 프로그램 코드와 데이터가 실행되는 공간 26 | 2. 반도체메모리 RAM 27 | 3. 프로그램은 실행되기 위해서 반드시 메모리에 적재되어야함 28 | 3. 캐시메모리 29 | 1. CPU 처리속도가 메모리 속도에 비해 빠르게 발전 -> 느린 메모리 때문에 CPU의 대기시간이 늘게 되었음 30 | 2. CPU의 프로그램 실행 속도를 높이기 위해, CPU와 메모리 사이에서 소량의 빠른 메모리(캐시메모리)를 설치 31 | 3. on chip캐시 -> CPU 내부에 만들어진 캐시. 대부분 이거 32 | 4. off chip캐시 -> CPU 외부 33 | 5. 캐시메모리가 있는 경우 CPU는 캐시메모리에서만 프로그램을 실행 34 | 1. 실행하고자 하는 프로그램과 데이터는 메모리에 먼저 적재 -> 다시 캐시로 옮겨야함 35 | 2. 캐시는 용량이 작기 때문에 현재 실행할 코드와 데이터의 극히 일부만 저장 36 | 4. 장치들: 키보드, 프린터, 스캐너 37 | 5. 버스 = 하드웨얻르이 데이터를 주고받기 위해 0,1 디지털 신호가 지나다니는 여러 가닥의 선을 다발로 묶어 부르는 용어 38 | 1. 주소버스 -> CPU는 메모리나 입출력 장치에 값을 쓰거나 읽을 때 반드시 주소를 발생시킴. 레지스터 번지. 39 | 2. 데이터버스 40 | 3. 제어버스 41 | 42 | 목적에 따른 버스 43 | 1. 시스템 버스: cpu, 캐시, 메모리 등 빠른 하드웨어들 사이에 데이터 전송 44 | 2. 입출력 버스: 상대적으로 느린 입출력 장치들로부터 입출력 데이터 전송 45 | ==I/O Controller&control circuit== 46 | - 시스템 버스 <- ==I/O Controller&control circuit== -> 입출력 버스 47 | - 입출력 장치를 제어하기 위한 여러 하드웨어 회로 48 | - 입출력 장치에게 명령을 내리고 메모리와 입출력 장치 사이 / cpu와 입출력 장치 사이에 데이터가 전달되도록 중계하는 역할 49 | 1. DMAC = cpu 개입 없이 직접 입출력 장치 <-> 메모리 사이의 데이터 전송을 가능하게 하는 장치 50 | 2. 인터럽트 제어장치 = 장치들이 입출력을 완료했을때 발생하는 인터럽트 신호를 받아 cpu에게 전달하는 장치 51 | 52 | 53 | 6. CPU 54 | - 능동적 소자. 메모리를 액세스했을때 주소 발생. 55 | - 32bit CPU란? 56 | 1. cpu에 32개의 주소선이 있다. 57 | 2^32개의 주소 = 2^32바이트 = 2^30(GB) * 2^2 = 4 GB 58 | 4GB이상의 메모리를 설치해봤자 넘어선 영역은 쓸 수 없음 59 | 2. cpu에 입출력되는 32개의 데이터 선이 있다. 60 | 한번에 32비트를 읽고 쓸 수 있음 61 | 62 | 7. 운영체제의 커널 63 | 1. 운영체제 = 커널 + 인터페이스 64 | 2. 커널 = 프로세스 관리, 메모리 관리, 저장장치 관리... 등 운영체제의 핵심적인 기능을 모아놓은것. 65 | 1. ==사용자나 응용 프로그램은 커널 통해서만 컴퓨터 자원에 접근 가능== 66 | 2. 어떤 사용자나 응용 프로그램도 컴퓨터 자원에 직접 접근할 수 없음 67 | 8. 운영체제의 인터페이스 68 | 1. 커널에 사용자 명령을 전달하고 실행 결과를 사용자에게 알려주는 역할 69 | 2. 그래픽을 사용한 인터페이스를 GUI라고 부름 70 | 9. 운영체제의 필요성 71 | 1. 자원에 대한 충돌 해결, 성능 최적화, 사용자의 시스템 사용 효율화를 위해 72 | 10. 운영체제 <-> 응용 프로그램 관계 73 | 1. 응용 프로그램 = 워드, 웹브라우저, 사용자가 컴퓨터를 활용하도록 작성된 프로그램들 74 | 2. 응용 프로그램에 대한 운영체제의 역할 75 | 1. 응용프로그램이 직접 하드웨어를 다루지 못하게 함. <- 응용 프로그램들 사이의 하드웨어 사용 충돌을 막기 위해 76 | 2. 응용 프로그램이 하드웨어를 사용하고자 할때 -> 반드시 운영체제에 요청 -> 시스템콜 호출 77 | 3. 78 | 11. 운영체제 <-> 하드웨어 관계 79 | 12. ==시스템 호출== = 커널이 자신을 보호하기 위해 만든 인터페이스 80 | 1. 응용프로그램이 os에게 처리해달라고 요청하는 것 81 | 2. 사용자가 자발적으로 커널 영역에 진입할 수 있는 유일한 수단 82 | 13. 드라이버 83 | 1. 커널과 하드웨어의 인터페이스 84 | 2. 마우스 등 간단한건 커널이 갖고 있는데, 그래픽 카드 같이 복잡한건 제조사에서 받아서 설치 85 | 86 | # 파일 시스템과 저장 장치 87 | 88 | 89 | # 파일 시스템의 논리 구조 90 | # 파일 시스템 구축 91 | # 파일 입출력 연산 92 | 93 | 94 | -------------------------------------------------------------------------------- /8학기 (25-2)/파일처리/4. 순차 화일.md: -------------------------------------------------------------------------------- 1 | ppt 60페이지 2 | 3 | -------------------------------------------------------------------------------- /8학기 (25-2)/파일처리/5. 화일의 정렬합병.md: -------------------------------------------------------------------------------- 1 | 2 | # 정렬 3 | ## 내부 정렬 4 | - 전체 데이터를 메인메모리에 올릴 수 있을 때 5 | - 레코드 판독, 기록에 걸리는 시간이 문제가 되지 않음 6 | - 종류 7 | 1. 버블 8 | 2. 삽입 9 | 3. 선택 10 | 4. 퀵 11 | 5. 힙 12 | 6. 병합 13 | 14 | ## 외부 정렬 15 | - 데이터가 너무 커서 메인 메모리에 한 번에 다 올리지 못할 때 16 | - 데이터를 나눠서 메모리에 올리고, 부분 정렬, 정렬된 런을 병합 17 | 1. 런 생성 ( 정렬): 메모리에 데이터를 일부만 불러와서 내부정렬 -> 런 생성 18 | 2. 병합 (합병): 런들을 하나로 병합 19 | 20 | 21 | 1. 정렬 단계: 정렬할 화일의 레코드들을 지정된 길이의 서브화일로 분할해서 정렬하여 런을 만들어 입력 화일로 분배하는 단계 22 | 2. 합병 단계: 정렬된 런들을 합병해서 보다 더 큰 런으로 만들고 이것들을 다시 입력화일로 재분배하여 합병하는 방식으로 모든 레코드들이 하나의 런에 포함되도록 만드는 단계 23 |  24 | ## 런 생성 방법 25 | > 1. 내부 정렬 26 | > 2. 대체선택 27 | > 3. 자연선택 28 | 29 | ### 1. 내부 정렬 30 | 1. 화일을 n레코드씩 분할 31 | 2. 분할한 레코드들을 내부 정렬 기법으로 정렬 32 | - ==마지막 런을 제외하고 모두 길이가 동일== 33 | - ==런의 길이를 예측할 수 있으므로 합병 알고리즘이 간단== 34 | 35 | ### 2. 대체선택 36 | - 런을 최대한 길게 만들기 위해서 사용 37 | - 초기 버퍼 채우기 m개 38 | - 키 값이 가장 작은 레코드 출력 39 | - 새 값 데이터 버퍼로 들여옴 40 | - lastKey(최근에 출력한애)보다 새값이 작으면 frozen 41 | - ==버퍼에 frozene된 레코드만 남게되면 현재 런 종료== 42 | 43 | 특징 44 | - 내부 정렬과 달리 입력화일의 일부 정렬된 레코드들의 순서를 이용???? 45 | - ==내부 정렬을 이용한 경우보다 런의 길이가 더 길다== 46 | - 런의 평균 예상 길이 2m 47 | - ==런의 길이가 길 수록 합병 비용이 적음== 48 | - ==런의 길이가 일정치 않아 정렬/합병 알고리즘이 복잡== 49 | 50 | 단점 51 | - 구현이 복잡하다. frozen, written, lastkey 다양한 상태관리 필요 52 | - 비효율적인 경우 존재 <- 역순이나 정렬이 거의 안되어있을시 53 | - 이상적인 성능을 보장하진 않음 54 | - 버퍼 등 별도의 메모리가 필요하다. 55 | 56 | 57 | 58 | ### 3. 자연선택 => frozen 워딩 안씀 59 | - 동결된 레코드들을 버퍼에 유지하지 않고 보조 저장장치의 저장소에 별도 저장 60 | - 하나의 런 생성 작업은 frozen 저장소가 다 차거나 입력 화일 끝에 도달할때까지 계속 61 | - 런을 길게 만들어 런 수를 줄임으로서 합병 비용을 줄임 62 | - frozen을 위한 예비저장소가 별도로 있음 (버퍼처럼 리스트) 63 | - 얘가 다 차면 종료 64 | - ==앞에 두 방법보다 더 긴 런== 65 | - ==저장소로의 입출력이 문제가 됨== 66 | - ==긴 런 생성에 따른 효율화가 예비 저장소 전송 비용보다 이익이 될 수도 있음== 67 | 68 | 69 | ## 정렬/합병 기법의 차별화 요소 70 | - 적용하는 내부 정렬 방식 (선택, 버블, 삽입, 퀵, 힙 ) 71 | - 내부 정렬을 위해 할당된 메인 메모리의 크기 72 | - 정렬된 런들의 보조 저장장치에서의 저장분포 (연속된/비연속된 공간에 저장) 73 | - 동시에 처리할 수 있는 런의 수 74 | 75 | => 위 요소에 따라서 런의 수랑 합병의 패스 수가 결정 76 | 패스 : 런을 읽고 합병해서 더 큰런을 생성하는 단계 77 | 패스의 수가 많을 수록 디스크 접근이 많아져, 성능이 떨어지므로 ==한번의 패스에 가능한 많은 런을 병합하면 좋다.== 78 | 79 | 80 | - 런을 길게 만들면 합병해야하는 런의 수가 최소화 81 | - 동시에 합병할 수 있는 런의 수를 크게하면 합병의 패스 수가 감소 82 | - 입력 런을 분산 저장하면 부수적인 입출력연산의 비용이 발생 83 | 84 | # 합병 85 | 86 | 런을 합쳐서 더 큰 정렬된 집합으로 만들기 87 | ## m원 합병 88 | 89 | - m개의 입력화일을 동시에 처리 90 | - m+1개 화일 사용 = 입력 화일 m개 + 출력화일 1개 91 | - 입출력이 많음: 한 패스에 합병이 되지 않으면 런을 입력화일로 다시 재분배 해야함. 복사,이동 .... 또해야함 92 | - 이상적일려면.. m개의 런에 m개의 입력 화일을 사용해서 한번의 m원합병으로 끝 93 | - 2원합병: 1번의 패스 = 합병된 런의 크기 2배, 런의 개수 반 94 | - n개의 런을 정렬하기 위한 패스의 수 log N 95 | 96 | 97 | - 입력: m개의 정렬된 런 98 | - 출력: 1개의 정렬된 런 99 | 100 | 1. 각 런에서 첫번째 요소를 버퍼에 로딩 101 | 2. m개의 요소 중 가장 작은 값을 선택하여 출력 102 | 3. 출력한 값이 있던 런에서 다음 요소를 버퍼에 로딩 103 | 4. 모든 런의 요소가 소진될 때까지 2~3을 반복 104 | 105 | - m이 클수록 메모리 버퍼 크기 증가 106 | - 모드 런에 대해 동시에 입출력을 처리 해야 하므로 디스크 수가 부족하면 비효율적 107 | - 대용량 데이터 정렬 (하둡, 맵리듀스의 sort) 108 | 109 | 예시) 5개의 런에 대한 5원 합병 110 | - 한번의 패스로 합병된 파일을 얻을 수 있음 111 | - ==그러나 키값이 가장 작은 레코드를 찾기 위해서 m-1번 비교연산을 함== 112 | 113 | ## 선택트리 114 | 115 | - 승자트리 116 | - 완전 이진 트리 = 완전 이원트리 -> 순차표현이 유리 117 | - 인덱스 값이 i인 애의 자식 인덱스는 2i, 2i+1 118 | - 각 단말 노드는 각 런에서 가장 작은 값을 내보냄 119 | - 내부노드(단말노드를 뺀 모든 노드)는 두 자식 중에 가장 작은 값을 가진 노드로 120 | - 가장 작은 키 값을 가진 원소가 승자로 올라가는 토너먼트 경기 121 | - 루트 노드 = 트리에서 가장 작은 키 값을 가진 원소 122 | - 합병 123 | - 루트가 결정되는 대로 순서 순차에 출력 124 | - 다음 원소가 승자 트리에 들어감 125 | - 승자 트리를 재구성 126 | - 패자트리 127 | - 승자트리에 0번 노드가 추가된 형태 128 | - 내부노드 : 토너먼트의 패자 129 | - 패자는 부모노드에 남음. 승자는 그 위로 올라가서 다시 경기 130 | - 루트: 결승 토너먼트의 패자 131 | - 0번 : 전체 승자 132 | - 합병 후 133 | - 출력된 원소가 있는 런에서 다시 제일 작은 값을 단말 노드에 올려서 경기 진행 134 | - ?? 경기는 형제 노드 대신 형식상 부모노드와 경기를 함?? 135 | ## m원 균형합병 136 | - m원합병의 단점 : 화일 재분배에 많은 입출력 필요 137 | - ==출력 파일이 다음 단계에서의 입력 파일이 됨.== 138 | - m원 자연합병: m+1 139 | - ==m원 균형합병 2m개의 화일 필요 (입력 화일 m개, 출력화일 m개)== 화일이 더 많이 필요하지만 그만큼 재분배 때문에 입출력을 안해도 된다. 140 | - 합병 후 ???? 141 | - 런의 총 개수 = [처음 런의 개수 / 합병 차수] 142 | - 런 길이 = 합병 차수의 두배씩 증가 143 | - O(logm N ) N은 초기 런의 수 144 | - 단점 145 | - 하나의 합병된 런이 생성되는 동안 m-1개의 파일은 항상 유휴 상태 146 | 147 | ## m원 다단계 합병 148 | - ==m+1개의 화일이 필요 (입력 m개, 출력 1개)== 149 | - 화일 유휴문제와 런의 단순 복사 문제를 개선 150 | - 입출력 화일 개수가 같지 않는 "불균형 합병" 151 | - 초기 입력 파일에 대한 런의 불균등 분배 하는 법이 복잡하다 152 | - 합병 단계 (패스) 153 | - 입력 화일의 어느 하나가 공백이 생길 때 까지 합병 154 | - 공백이 된 입력화일은 다음 단계에서의 출력화일이 됨 155 | 156 | 157 | - 완전 피보나치 분배 158 | - 몰르겟음 159 | - m원 다단계합병의 초기 런 분배를 m차 피보나치 수열의 한 항이 되도록 한다. 160 | - 장점 161 | - 합병 한 패스 당 항상 하나의 입력 파일만 공백이 됨 162 | - 합병을 위한 각 패스에서 입력 화일 수는 항상 m개 163 | - 마지막 패스에서는 입력 화일이 동시에 공백. 출력 화일 1개의 런 164 | - 165 | 166 | 167 | - 168 | 169 | ## m원 계단식 합병 170 | - 런들의 복사 작업을 줄이려는 불균형 합병의 다른 종류 171 | - 초기 런 생성과 런 분배가 중요 (완전 피보나치 분배) 172 | - 입력 화일 m개에서 시작, m-1, m-2 ... 줄어들어서 마지막 2개가 될때 한 주기가 끝남 173 | - 합병 단계 174 | 1. m개의 화일로 부터 m개의 런을 하나로 합병해서 출력화일로 생성. 얘는 잠시 대기 175 | 2. 입력 파일 중 하나가 공백이 되면 얘를 새로운 출력 파일로 씀. 176 | 1. 나머지 입력 화일로 출력화일에 합병하기 177 | 3. 2개의 입력 파일을 합병하는 단계가 되면 합병의 한 주기가 종료 178 | - 한 주기에 각 레코드는 한번씩만 처리 179 | - 최종 결과는 파일 1에 출력?? 180 | 181 | # 정렬 합병 유틸리티 182 | 안중요해보임... 183 | 184 | # 저장장치와 정렬합병 185 | 외부저장장치의 물리적 특성도 영향을 준다. 186 | 1. 순차 접근만 허용되는 자기테이프 187 | 1. 188 | 2. 임의접근이 가능한 디스크일때 189 | ![[Pasted image 20250427165753.png]] -------------------------------------------------------------------------------- /8학기 (25-2)/파일처리/6. 인덱스 구조 - 이진탐색트리, AVL 트리.md: -------------------------------------------------------------------------------- 1 | ## 인덱스 2 | 화일의 레코드들에 효율적으로 접근하기 위해서 3 | 키, 주소 4 | 5 | - 기본, 보조 6 | - 집중, 비집중 7 | - 밀집, 희소 8 | 9 | 10 | ## 트리 11 | - 차수 12 | - 높이 13 | 14 | ## 이진트리 15 | 16 | 17 | ## 이진 탐색트리 18 | 19 | 1. 검색 20 | 2. 삽입 21 | 3. 삭제 22 | 1. 단말 노드인 경우 23 | 2. 자식이 하나인 경우 24 | 3. 자식이 두개인 경우 25 | 26 | 성능 27 | 1. 가장 자주 접근하는 노드 -> 루트에 가장 가깝게 28 | 2. 이진탐색트리를 균형트리로 유지 29 | 30 | 하면 성능이 좋아진다. 31 | 32 | 단점 33 | - 삽입, 삭제 후 균형유지 부담이 크다. 34 | - 분기율이 작아(2) 탐색 경로가 길고 검색 시간이 길다 -> 분기가 5개라면? 검색시 더 효과적? 35 | - n개의 노드를 갖는 트리의 최소 높이: [log N] +1 36 | 37 | 38 | ## 편향 이진 탐색 트리 39 | 최악 n개 노드일때, n번 탐색 40 | 41 | ## AVL트리 = 높이 균형 이진트리 42 | - 삽입 삭제 검색 시간 O(logN) 43 | - 각 노드의 왼쪽 서브트리의 높이)와 오른쪽 서브트리의 높이 차이가 1이하인 이진탐색 트리 44 | - BF = 균형인수 = h( LEFT(T)) - h(RIGHT(T)) 45 | - 균형인수가 +-1이하이다. 46 | - 공백트리의 높이는 -1로 계산 47 | 48 | - 검색 - 일반 이진탐색트리랑 같음 log N 49 | - 삽입 - 불균형이 되었을시 조정해야함 50 | 51 | 1. 양수일때 왼쪽 서브트리에 문제 52 | 2. 음수일때 오른쪽 서브트리에 문제 53 | 54 | - 회전 55 | 1. LL: x의 왼쪽 자식의 왼쪽 서브트리에 삽입 -> LL 회전: 문제 구간 중 상위 구간을 오른쪽으로 회전 56 | 2. RR: x의 오른쪽 자식의 오른쪽 서브트리에 삽입 -> RR 회전 : 문제 구간 중 상위 구간을 왼쪽으로 회전 57 | 3. LR: x의 왼쪽 자식의 오른쪽 서브트리에 삽입 -> LR 회전: 문제 구간 중 하위 구간을 왼쪽으로 1차 회전시켜 LL 유형으로 변환한다음. LL회전을 적용함 58 | 4. RL: x의 오른쪽 자식의 왼쪽 서브트리에 삽입 -> RL 회전: 문제 구간 중 하위구간을 오른쪽으로 1차 회전시켜 RR 유형으로 변환한다음. RR 회전을 적용함. 59 | 60 | 61 | 삽입으로 인해 영향을 받는건 **새로운 노드~루트** 뿐임 62 | 63 | AVL트리 vs 완전 균형 이진 트리 64 | - AVL 트리의 탐색 시간이 더 길지만, 완전균형이진트리는 트리 전체 재균형을 수행해야한다. 65 | 66 | AVL트리는 메인 메모리에 거주하는 내부 구조로서, 트리 크기가 너무 커서 메인 메모리에 구축 할 수 없을 경우에 쓴다. ex ) 균형 m-원 탐색 트리 (b트리) 67 | 68 | -------------------------------------------------------------------------------- /8학기 (25-2)/파일처리/README.md: -------------------------------------------------------------------------------- 1 | # 성적평가 방식 2 | - 중간 기말 35 35 3 | - 과제 20 4 | - 출석 참여도 10 5 | 6 | ## 시험 전략 7 | > 1. 상황을 주고 상황에맞게 블록을 어떻게 나누면좋을지 8 | 2. 파일에어떻게접근 9 | 3. 아이노드에접근하는방법 10 | 4. 트리 특장점 어떤상황에 어떤트리 11 | 5. 코드쓰는건없음 코드를보고 어떤코드인지 해석하는것정도 12 | 13 | ![[Pasted image 20250426160403.png]] 14 | 15 | 16 | # 이것만은 꼭 17 | 18 | ## 5장 정렬/합병 19 | 내부 정렬 20 | 외부 정렬: 정렬 -> 합병 21 | 22 | 런 생성 방법 23 | 1. 내부 선택 24 | 2. 대체 선택 25 | 3. 자연 선택 26 | 27 | 합병 방법 28 | 1. m원 합병 29 | 2. 선택트리 (승자트리/패자트리) 30 | 3. m원 균형 합병 31 | 4. 다단계 합병 32 | 5. 계단식 합병 33 | 34 | 35 | ## 6장 트리 36 | 1. 이진탐색 트리 37 | 2. AVL트리 38 | 1. LL, RR, LR, RR 회전 39 | 40 | 41 | 42 | ## 목차 43 | 1. 뭐 44 | 2. 2ㅝ 45 | 3. ㅝㅁ 46 | 4. 워 47 | 5. 화일의 정렬합병 48 | 1. 정렬 49 | 1. 내부 정렬 50 | 2. 외부정렬 런-> 합병 51 | 1. 런 만들기 (내부정렬, 대체선택, 자연선택) 52 | 53 | 2. 합병 54 | 1. 균형합병 55 | 2. 다단계합병 56 | 6. 인덱스 구조 57 | 1. 이진탐색 트리 58 | 2. AVL 트리 -------------------------------------------------------------------------------- /Flutter/기본 위젯 알아보기.md: -------------------------------------------------------------------------------- 1 | 2 | ## 위젯 3 | > Everything is Widget! 4 | 5 | UI과 관련된 모든 요소는 위젯으로 구성되어있음 6 | 7 | 위젯의 상태가 변경되면 변경사항에 알맞게 변경된 UI를 화면에 다시 그려줌 8 | 플러터 프레임워크는 기존 상태의 위젯을 비교해서 UI 변화를 반영할때 필요한 최소한의 변경사항을 산출해서 화면을 그려냄 9 | 10 | ### 자식을 하나만 갖는 위젯 11 | - container 12 | - 자식을 담는 컨테이너 위젯 13 | - 배경색, 너비 높이, 테두리 등 디자인 지정 가능 14 | - gestureDetector 15 | - 제스처 기능을 자식 위젯에서 인식하는 위젯 16 | - 탭, 드래그, 더블클릭 같은 제스터 기능이 자식 위젯에 인식 되었을때 함수를 실행할 수 있음 17 | - sizedbox 18 | - 높이 너비 지정하는 위젯 19 | - 디자인적 요소 x 20 | - const 생성자로 생성할 수 있음 -> 퍼포먼스 효율적임 21 | 22 | ### 다수의 자식을 입력할 수 있는 위젯 23 | - column 24 | - 자식 매개변수에 입력된 모든 위젯을 세로로 배치 25 | - row 26 | - 자식 매개변수에 입력된 모든 위젯을 가로로 배치 27 | - listview 28 | - 리스트 구현 29 | - 입력된 위젯이 화면을 벗어나게 되면 스크롤 가능 30 | 31 | 32 | https://docs.flutter.dev/ui/widgets/basics 33 | 34 | 35 | ## children vs child 36 | - child 매개변수에는 단 하나의 위젯만 입력할 수 있음 37 | - children 매개변수는 여러위젯을 리스트에 입력할 수 있음 38 | - 리스트에 입력된 순서대로 화면에 그려짐 39 | 40 | ## 제스처 관련 위젯 41 | ### Button 42 | - TextButton 43 | - 텍스트만 있는 버튼 44 | - OutlinedButton 45 | - 테두리가 있는 버튼 46 | - ElevatedButton 47 | - 입체적으로 튀어나온 느낌의 배경이 들어간 버튼 48 | ### IconButton 49 | - 아이콘으로 버튼 만들기 50 | ### GestureDetector 51 | - 하위 위젯이 제스처에 반응하도록 해줌 52 | ### FloatingActionButton 53 | - 화면의 오른쪽 아래, 사용자가 가장 많이 사용하는 위치에 버튼을 띄움 54 | 55 | ## 디자인 관련 위젯 56 | ### Container 57 | - 위젯에 배경, 패딩, 테두리 등 추가 58 | ### SizedBox 59 | - 너비 높이 지정 할 수 있는 위젯 60 | - 공백 넣을 때 많이 씀 61 | ### Padding 62 | - 패딩 위젯은 따로 있지만, 마진은 따로 있지 않음 63 | - 마진: container의 매개변수로 넣으면 됨 / 위젯 바깥에 간격 추가 64 | - 패딩: 하위 위젯으로 추가 / 내부 간격 추가 65 | 66 | ### SafeArea 67 | - 시스템 UI에 가려지지 않게 신경써서 화면에 그릴 때 68 | 69 | 70 | 71 | ## 배치 관련 위젯 72 | ### Row 73 | ```dart 74 | class RowWidgetExample extends StatelessWidget { 75 | 76 | @override 77 | 78 | Widget build(BuildContext context) { 79 | 80 | // TODO: implement build 81 | 82 | return MaterialApp( 83 | 84 | home: Scaffold( 85 | 86 | body: SizedBox( 87 | 88 | height: double.infinity, 89 | 90 | child: Row( 91 | 92 | mainAxisAlignment: MainAxisAlignment.start, 93 | 94 | crossAxisAlignment: CrossAxisAlignment.center, 95 | 96 | children: [ 97 | 98 | Container( 99 | 100 | height: 50.0, 101 | 102 | width: 50.0, 103 | 104 | color: Colors.red, 105 | 106 | ), 107 | 108 | 109 | 110 | const SizedBox( 111 | 112 | width: 12.0, 113 | 114 | ), //공백 115 | 116 | Container( 117 | 118 | height: 50.0, 119 | 120 | width: 50.0, 121 | 122 | color: Colors.green, 123 | 124 | ), 125 | 126 | const SizedBox( 127 | 128 | width: 12.0, 129 | 130 | ), 131 | 132 | Container( 133 | 134 | height: 50.0, 135 | 136 | width: 50.0, 137 | 138 | color: Colors.blue, 139 | 140 | ) 141 | 142 | ], 143 | 144 | ), 145 | 146 | ), 147 | 148 | )); 149 | 150 | } 151 | 152 | } 153 | ``` 154 | 155 | 156 | ## column은 세로 157 | 158 | 159 | 160 | ## Flexible vs Expanded 161 | 162 | ```dart 163 | Flexible( 164 | 165 | flex: 1, 166 | 167 | child: Container( 168 | 169 | height: 50.0, 170 | 171 | width: 50.0, 172 | 173 | color: Colors.red, 174 | 175 | ), 176 | 177 | ), 178 | 179 | 180 | 181 | const SizedBox( 182 | 183 | width: 12.0, 184 | 185 | ), //공백 186 | 187 | 188 | 189 | Expanded( 190 | 191 | child: Container( 192 | 193 | height: 50.0, 194 | 195 | width: 50.0, 196 | 197 | color: Colors.green, 198 | 199 | ), 200 | 201 | ), 202 | 203 | const SizedBox( 204 | 205 | width: 12.0, 206 | 207 | ), 208 | ``` 209 | 210 | - Flexible은 비율 만큼 공간을 차지할 수 있게 해줌 211 | - Flex 1과 expanded 모두 남아 있는 공간을 최대한으로 차지한다. 212 | - expanded는 Flexfit.tight를 기본으로 제공해준 위젯임 213 | - `class Expanded extends Flexible` 상속 관계이다. 214 | 215 | ## Stack 216 | - 위젯을 겹칠 수 있게 해줌 217 | - 위젯 위에 위젯을 올린듯한 효과 줄 수 있음 -------------------------------------------------------------------------------- /Flutter/다트 입문하기.md: -------------------------------------------------------------------------------- 1 | > 코드팩토리의 플러터 프로그래밍 도서를 바탕으로 작성되었습니다. 2 | 3 | ## 핫리로딩!!! 4 | - 코드의 변경사항을 즉시 화면에 반영해볼 수 있음 5 | ## 다트의 컴파일 방식 6 | 7 | | 개발할때 | JIT(Just In Time)+VM | 8 | | ---- | --------------------- | 9 | | 배포할때 | AOT Ahead of Time+런타임 | 10 | 11 | JIT 12 | - 다트 가상 머신에서 제공. 13 | - 변경사항을 처음부터 다시 컴파일할 필요 없이 즉시 화면에 반영할 수 있는 핫리로딩 14 | - 실시간으로 메트릭스를 확인할 수 있는 기능 15 | - 디버깅 16 | 17 | AOT 18 | - 배포시에는 컴파일이 돼있어야 리소스를 효율적으로 사용할 수 있어서 컴파일을 하는 것임 19 | 20 | > 마치, 파이썬(장고)마냥 인터프리터 방식으로 작동하는 것처럼 보이는 것임!!!! 21 | 다트 가상머신에서 JIT를 지원하기에 핫리로딩이 된다!!! 22 | 23 | --- 24 | 25 | ## 문법 26 | 27 | ### 변수 선언 28 | 29 | - var 30 | - var 변수명 = 값; 31 | - 타입 자동추론 32 | 33 | - dynamic 34 | - dynamic 변수명 = 값; 35 | - 변수의 타입이 고정되지 않음. 36 | - int 변수에 갑자기 string을 넣어도 에러나지 않음 37 | 38 | - final/const 39 | - 처음 선언 후 변경 불가 40 | - 상수화 41 | - final 런타임 → Datetime.now() 실행되는 순간 가능 42 | - 실행될때 확정되면 43 | - 값이 나중에 정해짐 44 | - const 빌드타임 →불가 45 | - 코드 실행하지 않은 상태에서 값이 확정되면. 값이 나중에 정해지는것이 아님. 이미 정해져있는 것 46 | 47 | - 그외 변수 타입 48 | - int 49 | - String 50 | - double 51 | - bool 52 | 53 | - 컬렉션 54 | - list 55 | - map 56 | - set -------------------------------------------------------------------------------- /Flutter/플러터 입문하기.md: -------------------------------------------------------------------------------- 1 | ## 계층 2 | 1. Embedder: 네이티브 플랫폼과 통신 3 | 2. Engine: 플러터 프레임워크의 중심이 되는 기능 제공 4 | 4. Framework: 이젯과 애니메이션 등 플러터 개발자들이 실질적으로 사용하는 기능 제공 5 | 6 | ## 그외 7 | - Center 위젯 -> 중앙배치 8 | - Text 위젯 -> 글자 작성 9 | 10 | # 폴더링 11 | - screen 12 | - 스크린 전체에 해당되는 위젯 13 | - component 14 | - 공통으로 사용되 15 | - model 16 | - 모델 17 | - const 18 | - 상수 -------------------------------------------------------------------------------- /Pasted image 20240312172813.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/Pasted image 20240312172813.png -------------------------------------------------------------------------------- /Pasted image 20240325171739.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/Pasted image 20240325171739.png -------------------------------------------------------------------------------- /Pasted image 20240325171844.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/Pasted image 20240325171844.png -------------------------------------------------------------------------------- /Pasted image 20241129135836.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/Pasted image 20241129135836.png -------------------------------------------------------------------------------- /Pasted image 20250426160403.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/Pasted image 20250426160403.png -------------------------------------------------------------------------------- /Pasted image 20250427165753.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/Pasted image 20250427165753.png -------------------------------------------------------------------------------- /Pasted image 20250428213925.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/Pasted image 20250428213925.png -------------------------------------------------------------------------------- /Pasted image 20250428221316.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/Pasted image 20250428221316.png -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # book-study 2 | 3 | - 옵시디언을 이용해서 작성합니다. 4 | - TIL 느낌의 글을 작성합니다. 고로 오피셜하지 않은 말투나, 추측성의 글이 포함될 수도 있습니다. 5 | - 주로 책을 통해 진득하게 공부한 흔적을 남기려합니다. 6 | - 정제된 글은 [Velog](https://velog.io/@jini_1514/posts)에서 보실 수 있습니다. 7 | 8 | ## 공부 일정 9 | ### 2024년 11월 10 | - [코틀린 코루틴의 정석🧐](https://github.com/HI-JIN2/cs-study/tree/main/%EC%BD%94%ED%8B%80%EB%A6%B0%20%EC%BD%94%EB%A3%A8%ED%8B%B4%EC%9D%98%20%EC%A0%95%EC%84%9D) 11 | 12 | ### 2024년 3월 13 | - [면접을 위한 CS 전공지식 노트](https://github.com/HI-JIN2/cs-study/tree/main/%EB%A9%B4%EC%A0%91%EC%9D%84%20%EC%9C%84%ED%95%9C%20CS%20%EC%A0%84%EA%B3%B5%EC%A7%80%EC%8B%9D%20%EB%85%B8%ED%8A%B8) 14 | 15 | 오류 제보 16 | - 오개념에 대한 반박시, 당신이 맞습니다. 17 | ![[Pasted image 20240312172813.png]] 18 | - 고로, 오류 사항에 대한 제보는 issue 발행 후, branch를 생성하셔서 PR을 날려주시면 감사히 반영하도록 하겠습니다. 19 | -------------------------------------------------------------------------------- /SpringBoot in Action/1-1. 스프링부트 시작하기.md: -------------------------------------------------------------------------------- 1 | 2 | # 1.1 스프링 부트 소개 3 | ## 1.1.1 왜 스프링 부트인가 4 | 스프링부트 = 스프링 프레임워크의 오픈소스 확장 기능 5 | 현장에서 쓸 수 있을 정도의 독립 실행형 애플리케이션 설정을 알아서 해줌 6 | - 생산성을 높혀준다고 이해하였음. 스프링보다 더 기능이 추가 된 것~ 7 | - 개발자가 보다 **비즈니스 로직**에만 집중 할 수 있게끔 도와준다 8 | ## 1.1.2 스프링 부트는 무엇인가 9 | 스프링 - 개발자 사이에 존재하는 계층![[스크린샷 2024-03-25 오후 4.51.12.png]] 10 | 11 | - 2014년 출시. 오래되지 않은 프레임워크 12 | - 개발자가 보다 비즈니스 로직에만 집중 할 수 있게끔 도와준다. 13 | ## 1.1.3 스프링 부트 핵심 기능 14 | - 빠른 시동 15 | - 자동 구성 16 | - 미리 정의된 방식 17 | - 독립 실행형 18 | - 실제 서비스 환경에 사용 가능 19 | 20 | ## 1.1.4 스프링 부트 컴포넌트 21 | 22 | > - 컴포넌트란? 23 | > 여러 개의 프로그램 함수들을 모아 하나의 특정한 기능을 수행할 수 있도록 구성한 작은 기능적 단위 24 | > 재사용이 가능한 각각의 독립된 모듈 25 | 26 | 27 | 28 | - 스프링부트 컴포넌트 종류![[스크린샷 2024-03-25 오후 5.02.14.png]] 29 | - spring-boot: 스프링부트 기본 컴포넌트 30 | - spring-boot-autoconfigure: 빈 생성 31 | - spring-boot-starter: 의존 관계 기술서 32 | - spring-boot-CLI: dependency를 메이븐이나 그레이들에서 안하고 그루비 코드를 컴파일할 수 있는 개발자 친화적 명령형 도구 라는데 난 잘 모르겠음 33 | - spring-boot-actuator: 스프링부트 애플리케이션을 모니터링하고 감시할 수 있는 액추에이터 34 | - spring-boot-actuator-autoconfigure: 35 | - spring-boot-test 36 | - spring-boot-test-autoconfigure: 37 | - spring-boot-loader: 38 | - spring-boot-devtools: 개발자 도구.. 39 | 40 | 41 | # 1.2 코드 예제 42 | ## 1.2.1 ~~메이븐~~ vs. 그레이들 43 | 44 | 메이븐 45 | ![[Pasted image 20240325171739.png]] 46 | 47 | 그레이들 48 | ![[Pasted image 20240325171844.png]] 49 | 50 | 51 | > 왜 메이븐에서 그레이들로 갈아탈까? 52 | > 53 | > 그레이들이 가독성이 좋기 때문! 54 | > 55 | > 메이븐은 XML 형식인데, 계층 구조를 타고 타고 depth가 깊어지는 형식으로 가는 문서 형식이라서 가독성이 좋지 않다. 56 | > 57 | > 그레이들이 늦게 나왔다. 그리고 놀랍게도, 변수 선언이나 if, else, for 같은 로직적인 코드 작성이 가능하다..! 58 | 59 | ## 1.2.2 자바 vs. 코틀린 60 | 61 | 자바 코틀린 혼용이 한 프로젝트 안에서 가능하다고는 하나, 빈 생성이 안되어서 하나의 컨트롤러 단위로 혼용이 된다고 알고 있다. 62 | 63 | ~~코틀린 언어에 대한 수요가 많다면 스터디 개설을 고려해보겠다. 나는 코틀린을 좋아한다. 64 | 65 | ## 1.2.3 데이터베이스 지원 66 | 67 | - H2 인메모리 SQL 데이터베이스 68 | - MySQL이나 PostgreSQL을 사용해본 경험이 있음 69 | 70 | ## 1.2.4 롬복 71 | 어노테이션을 통해 POJO 클래스를 정의할 수 있게 도와준다. 72 | 73 | > POJO(Plain Old Java Object)란? 74 | > 즉, **Java로 생성하는 순수한 객체** 75 | > 76 | >토비 왈 **"진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트이다"** 77 | 78 | ```java 79 | public class UserDTO { 80 | private String userName; 81 | private String userId; 82 | private String userPassword; 83 | 84 | public String getUserName() { return userName; } 85 | 86 | public void setUserName(String userName) { 87 | this.userName = userName; 88 | } 89 | 90 | public String getUserId() { return userId; } 91 | 92 | public void setUserId(String userId) { 93 | this.userId = userId; 94 | } 95 | 96 | public String getUserPassword() { 97 | return userPassword; 98 | } 99 | 100 | public void setUserPassword(String userPassword) { 101 | this.userPassword = userPassword; 102 | } 103 | } 104 | 105 | ``` 106 | 107 | 게터 세터를 다 구현한 모습이다. 하지만, 롬복 어노테이션을 통해 짧게 줄일 수 있다. (사견이지만, 이게 다 자바에 데이터 클래스가 없어서 발생한 일이 아닐까.. 코틀린에는 데이터 클래스가 있는데!) 108 | 109 | 그래서 롬복은? POJO 객체의 생성자, getter, setter, toString을 어노테이션 하나만 추가하면 자동으로 추가해준다!! 와아 110 | ![[스크린샷 2024-03-25 오후 7.33.59.png]] 111 | 112 | **@Data** 113 | ```java 114 | package com.example.demo.dto; 115 | 116 | 117 | public class Member { 118 | 119 | private Integer id; 120 | private String name; 121 | private Integer age; 122 | private String dept; 123 | 124 | public Member() { 125 | super(); // TODO Auto-generated constructor stub } 126 | 127 | public Integer getId() { return id; } 128 | 129 | public void setId(Integer id) { this.id = id; } 130 | 131 | public String getName() { return name; } 132 | 133 | public void setName(String name) { this.name = name; } 134 | 135 | public Integer getAge() { return age; } 136 | 137 | public void setAge(Integer age) { this.age = age; } 138 | 139 | public String getDept() { return dept; } 140 | 141 | public void setDept(String dept) { this.dept = dept; } @Override 142 | 143 | public String toString() { return "Member [id=" + id + ", name=" + name + ", age=" + age + ", dept=" + dept + "]"; } } 144 | ``` 145 | 146 | 147 | @Data를 붙이면 게터세터, 기본 생성자, toString이 붙는다. 148 | ```java 149 | package com.example.demo.dto; 150 | 151 | import lombok.Data; 152 | @Data 153 | public class Member { 154 | private Integer id; 155 | private String name; 156 | private Integer age; 157 | private String dept; 158 | } 159 | ``` 160 | 161 | **@AllArgsConstructor** 162 | @Data로는 파라미터를 가지지 않은 기본 생성자를 만든다. 163 | 하지만 모든 변수를 파라미터로 받는 생성자가 필요할 수 있다. 164 | 이 때에 @AllArgsConstructor을 사용한다. 165 | (단, 이 경우 @Data가 자동 생성한 기본 생성자는 사라진다. 166 |  양쪽을 모두 사용하고 싶다면 @NoArgsConstructor와 @AllArgsConstructor을 함께 사용해야한다.) 167 | 168 | ```java 169 | package com.example.demo.dto; 170 | 171 | import lombok.AllArgsConstructor; 172 | import lombok.Data; 173 | 174 | @Data 175 | @AllArgsConstructor 176 | public class Member { 177 | private Integer id; 178 | private String name; 179 | private Integer age; 180 | private String dept; 181 | } 182 | ``` 183 | 184 | 185 | >POJO가 아닌 것 186 | > 187 | >순수 자바가 아니라 WindowAdapter를 상속 받기 때문에, WindowAdapter가 바뀌면 안에 내용도 바뀜. 종속적이다. 188 | ```java 189 | public class WinExam extends WindowAdapter { 190 | @Override public void windowClosing(WindowEvent e) { 191 | System.exit(0); 192 | } 193 | } 194 | ``` 195 | 196 | 197 | 롬복으로 생성된 거나 직접 구현해서 작성된거나 작동은 동일하게 된다. 198 | 199 | 롬복은 서드파티인데, 서드파티를 사용하고 싶지 않다면 자바 레코드도 있다고 한다. 200 | 201 | 202 | 203 | 204 | # 1.3 스프링 부트 시작하기 205 | 206 | ## 1.3.1 첫 번째 스프링 부트 프로젝트 207 | 208 | https://start.spring.io/ 209 | 210 | 211 | ## 1.3.2 ~~스프링 부트 프로젝트 구조~~(메이븐 제외, 18 페이지 부터 정리) 212 | 213 | - 메인 클래스![[스크린샷 2024-03-25 오후 5.39.50.png]] 214 | 215 | 1. main() 216 | 별다른 war, ear 파일을 만들 필요 없이, main 메소드만 실행한다면 로컬에서 웹 애플리케이션을 돌려볼 수 있다. 217 | 기본적으로 서블릿 기반 웹 애플리케이션은 아파치 톰캣이나 제티와 같은 서블릿 컨테이너 위에서만 실행할 수 있다. 218 | 219 | 원래대로 라면 톰캣 서버 위에 우리가 만든 웹 애플리케이션을 올려야 작동하지만, 스프링부트와 함께라면! 이야기는 달라진다. 220 | 221 | - 요약 222 | main()을 통해 스프링부트 애플리케이션을 실행하면 스프링부트가 내장된 기본 서블릿 컨테이너인 톰캣 시작하고, 그 위에서 우리의 웹 애플리케이션을 실행한다. 223 | 2. @SpringBootAppLication 사용 224 | 아래의 3 어노테이션을 하나로 줄여 사용할 수 있다. 225 | 1. @EnableAutoConfiguration: jar 파일을 바탕으로 애플리케이션을 자동으로 구성해주는 스프링부트 자동 구성 기능을 활성화 합니다. 226 | 2. @ComponentScan: 애플리케이션에 있는 스프링 컴포넌트(빈, 컴포넌트 등)를 탐색하고 그것들을 자바 빈으로서 스프링으로 관리한다. 라이프 사이클도 따르며, 루트에서 시작해서 하위 패키지까지 모두 탐색한다. 227 | >빈이란? 228 | > 229 | >빈(Bean)은 스프링 컨테이너에 의해 관리되는 재사용 가능한 소프트웨어 컴포넌트이다. 즉, 스프링 컨테이너가 관리하는 자바 객체를 뜻하며, 하나 이상의 빈(Bean)을 관리한다. 230 | > 231 | >**빈은 인스턴스화된 객체를 의미하며, 스프링 컨테이너에 등록된 객체를 스프링 빈이라고 한다.** 232 | >@Bean 어노테이션을 통해 메서드로부터 반환된 객체를 스프링 컨테이너에 등록한다. 빈은 클래스의 등록 정보, Getter/Setter 메서드를 포함하며, 컨테이너에 사용되는 설정 메타데이터로 생성된다. 233 | 234 | 3. @SpringBootConfiguration: 스프링부트 애플리케이션 설정을 담당하는 클래스에 이 어노테이션을 붙임. -> 이 어노테이션 때문에 메인 클래스가 반드시 Root에 위치해야함. 그래야 루트부터 시작해서 다른 스프링 어노테이션이 붙어있는 컴포넌트들을 찾아서 로딩할 수가 있다. 235 | 236 | 3. SpringApplication클래스의 역할 237 | run()이 실행 될 때 수행되는 작업들 238 | 1. 클래스 패스에 있는 라이브러리를 기준으로 ApplicationContext 클래스 인스턴스를 생성한다. 239 | 2. CommandLinePropertySource를 등록해서 명령행 인자를 스프링 프로퍼티로 읽어 들인다. 240 | 3. 1에서 생성한 ApplicationContext를 통해 모든 싱글톤 빈을 로딩한다. 241 | 4. 애플리케이션에 설정된 ApplicationRunners와 commandRunner를 실행한다. 242 | 243 | >ApplicationContext를 싱글톤으로 만들어야한다. 244 | 싱글톤은 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴이고, 싱글톤을 하는 이유는, 간단히 말해서 객체를 생성할 때 비용이 들기 때문에, 그 비용을 줄이기 위해 하나의 인스턴스를 가지고 돌려 쓰려고 한다. 그러기 위해서 의존성 주입을 한다. 245 | 246 | SpringApplication클래스는 클래스 패스에 있는 jar 의존 관계를 바탕으로 ApplicationContext 인스턴스를 생성한다. 247 | 248 | 스프링 부트 웹 애플리케이션은 서블릿/리액티브 타입 중에 하나다. 249 | 스프링 클래스 패스에 있는 클래스를 바탕으로 어떤 타입인지 유추할 수 잇다. 250 | 251 | ApplicationContext를 로딩할 때 252 | - 서블릿 기반 일 때 AnnotationConfigServletWebServerApplicationContext 클래스 인스턴스 생성 253 | - 리액티브 일 때 AnnotationConfigReactiveWebServerApplicationContext 클래스 인스턴스 생성 254 | - 둘 다 아니면, AnnotationConfigApplicationContex 클래스 인스턴스 생성 255 | 256 | SpringApplication클래스안에 있는 main()은 정적 메서드이다. run()이 유용하긴 하지만, 개발자의 의도하는 바가 특별히 있다면, SpringApplication클래스 인스턴스를 직접 생성해서 동작되게 할 수도 있다. 257 | ![[스크린샷 2024-03-25 오후 7.30.04.png]] 258 | 직접 인스턴스를 생성하고, 리액티브 타입으로 설정하는 코드이다. 259 | 260 | 261 | - 애플리케이션 정보 관리 262 | src/main/resources 경로에 application.yml을 올린다. 263 | 264 | 주로 어떤 포트를 쓰는지, base url은 뭔지, jwt 키값, 토큰 유효 시간 등을 담아놓는다. 265 | 266 | ![[스크린샷 2024-03-25 오후 7.31.07.png]] 267 | 애플리케이션 설정을 담는데, 보통 gitinore해서 사용하거나, 특정 변수만 환경변수로 빼서 레포지토리에 올려서 사용할 수가 있다. 268 | 269 | yml에 있는 내용을 변경하고서 팀원들과 공유하지 않는다면, 왜 안되? 상황이 발생할 수 있다. 빌드가 안되기 때문! 270 | ## 1.3.3 실행 가능한 JAR 파일 271 | 272 | 서버 배포를 할 때 올리는게 jar 파일이다. 273 | 274 | java -jar 명령어를 통해 애플리케이션 실행을 할 수 있다. 275 | 276 | ## 1.3.4 JAR 파일 구조 277 | 278 | ![[스크린샷 2024-03-25 오후 7.41.39.png]] 279 | - META-INF: 매니패스트가 있다. 그 안에는 주요 파라미터인 MainClass와 StartClass가 들어있다. 280 | - 스프링부트 로더 컴포넌트: 실행가능한 파일을 로딩하는데 사용하는 로더의 구현체 281 | - BOOT-INF/classes: 컴파일된 모든 클래스 282 | - BOOT-INF/lib: 의존성 283 | 284 | 285 | ## 1.3.5 스프링 부트 애플리케이션 종료 286 | 287 | 288 | jar 파일을 프롬프트에서 종료하면 종료된다. 289 | 혹은 해당 프로세스 종료 290 | 291 | 안전 종료 설정 (스프링부트 2.3.0부터 도입 ) 292 | ``` 293 | server.shutdown=graceful //기본 값은 immediate 즉시 종료 294 | spring.lifecycle.timeout-per-shutdown-phase=1m //기본값은 30s 295 | 296 | ``` 297 | 298 | 299 | 300 | # 1.4 스프링 부트 기타 개념 301 | 302 | 생산성을 높이기 위해 여러 도구가 존재한다. 303 | ## 1.4.1 스프링 부트 스타트업 이벤트 304 | ## 1.4.2 스프링 부트 애플리케이션 이벤트 감지 305 | ## 1.4.3 커스텀 스프링 부트 스타터 306 | ## 1.4.4 커스텀 자동 구성 307 | ## 1.4.5 실패 분석기 308 | ## 1.4.6 스프링 부트 액추에이터 309 | ## 1.4.7 스프링 부트 개발자 도구 -------------------------------------------------------------------------------- /SpringBoot in Action/1-2. DI, IoC, Bean, AOP.md: -------------------------------------------------------------------------------- 1 | 2 | # DI 의존성 주입 3 | 4 | 5 | 6 | # IoC: 제어의 역전 7 | 8 | 객체의 생명주기 전반을 개발자가 하지 않고, **프레임워크**에 위임하는 것이다. 9 | 10 | - 빈 Bean 11 | 스프링에서 관리하는, 관리되어야할 인스턴스 객체 12 | 13 | - 빈을 만드는 이유? 스프링에서 관리하게 만들려고 14 | 15 | - 빈을 만드는 방법 16 | > 1. Component 제일 흔하다. 17 | > 2. 그외 Controller, Repository, Service도 있다. (컴포넌트에 기능이 조금 더 추가됨) 18 | > 3. 그외 또 Bean 어노테이션도 존재 19 | 20 | 21 | 22 | - 스프링 순환 참조 23 | >  참조하는 대상이 서로 물려 있어서 참조할 수 없게 되는 현상을 말한다. 24 | 25 | -> 이를 해결하기 위해서, 필드 주입 대신에 생성자 주입을 해야함 26 | 27 | 28 | # AOP 29 | 30 | >관점 지향 프로그래밍 31 | 32 | 33 | 로깅과 같이 반복되는 코드 -> 흩어지는 관심사 34 | 35 | 내가 하고 싶은 비즈니스로직이 아닌 코드! 36 | 37 | 38 | -------------------------------------------------------------------------------- /SpringBoot in Action/1-3. Question Set.md: -------------------------------------------------------------------------------- 1 | # [2주차] Question Set 2 | 3 | ## Problem 1 4 | 5 | ### 스프링 부트 기본1 6 | 7 | 1. Spring과 Spring Boot의 차이점을 간단히 설명해주세요. 8 | 9 | 2. Spring Boot application의 시작점(entry point)을 지정하는 방식을 설명해주세요. 10 | 11 | 12 | 3. URL 생성기 프로젝트에서 질문 2가 적용된, 즉 예약 API의 entry point class 이름이 무엇인가요? 13 | 14 | 15 | 4. IoC와 DI에 대해 간단히 설명해주세요. 16 | 17 | 18 | 5. `UrlService`의 class 구현 부분에 IoC가 적용되었나요? 만약 그렇다면 어떻게 적용되었나요? 19 | 20 | 21 | 6. `UrlService`의 class 구현 부분에 DI가 적용되었나요? 만약 그렇다면 어떻게 적용되었나요? 22 | 23 | 24 | 7. 그렇다면 질문 3의 메인 클래스에서는 DI나 IoC가 적용이 되었을까요? 25 | 26 | 27 | 8. 질문 3의 메인 클래스에서 @SpringBootApplication를 확인해보면 @ComponentScan 어노테이션이 있습니다. 이 어노테이션의 역할이 무엇일까요? 28 | 29 | 30 | - 관련 글 31 | 32 | [Spring vs Spring Boot](https://server-engineer.tistory.com/739) 33 | [[SpringBoot] IoC(제어의 역전)와 DI(의존성 주입)](https://velog.io/@ayoung0073/springboot-IoC%EC%A0%9C%EC%96%B4%EC%9D%98-%EC%97%AD%EC%A0%84%EC%99%80-DI%EC%9D%98%EC%A1%B4%EC%84%B1-%EC%A3%BC%EC%9E%85) 34 | 35 | ## Problem 2 36 | 37 | ### 스프링 부트 기본2 38 | 39 | 1. Component, Bean 두 어노테이션들의 차이점을 비교해주세요. 두 어노테이션으로 어노테이트된 대상(클래스, 메소드 등)이 의존성 주입에 사용될 수 있는지 각각 답변해주세요. 40 | 41 | 42 | 2. Configuration은 언제 사용하나요? 특히, Bean과 연결지어 설명해주세요. 43 | 44 | 45 | 3. URL 단축기 코드를 보시면 @Service, @Repository 어노테이트된 class 및 interface들은 Component 어노테이션을 따로 명시하지 않은 것을 확인하실 수 있습니다. 아래 Service class를 참조해보세요. 그런데 어떻게 의존성 주입이 가능할까요? 46 | - `com.example.urlshortener.domain.url.service` 47 | - `com.example.urlshortener.domain.url.repository` 48 | 49 | 4. 3번의 질문에 이어서, 그렇다면, @Service와 @Component 두 어노테이션을 구분짓는 이유가 무엇인가요? 50 | 51 | 52 | 5. 의존성 주입의 장점이 무엇인지 설명해주세요. 53 | 54 | 6. Bean 객체의 제어의 역전과 의존성 주입의 과정을 자세히 설명해주세요. 55 | -------------------------------------------------------------------------------- /면접을 위한 CS 전공지식 노트/네트워크/2.1 네트워크의 기초.md: -------------------------------------------------------------------------------- 1 | #### 네트워크란? 2 | : 노드-링크 연결되어 있어 리소스를 서로 공유하는 집합 3 | 4 | - 노드: 서버, 라우터, 스위치 등 네트워크 장치 5 | - 링크: 유/무선 6 | 7 | ## 2.1.1. 처리량과 지연시간 8 | - 좋은 네트워크란? 9 | 많은 처리량과 짧은 시연시간, 장애가 적고 좋은 보안을 갖춘 네트워크 10 | 11 | ### 처리량 12 | > 링크 내에서 성공적으로 전달된 데이터의 양 13 | - 얼만큼을 트래픽 처리했는지 14 | - 많은 트래픽을 처리한다 = 많은 처리량을 갖는다 15 | - 단위 bps: 초당 전송/수신 되는 비트 수 16 | - 사용자들이 많이 접속할때마다 커지는 **트래픽**, 네트워크 장치 간의 대역폭(주어진 시간 동안 네트워크 연결을 통해 흐를 수 있는 최대 비트 수), 에러, 장치의 하드웨어 스펙에 영향을 받는다. 17 | - 트래픽: (특정 시점에 링크 내에) 흐르는 데이터의 양 18 | - 예시: 서버에 저장된 파일을 사용자가 다운로드 할 때 발생되는 데이터의 누적량을 말함 19 | 20 | > 트래픽이 많아졌다 = 흐르는 데이터가 많아졌다. 21 | > 처리량이 많아졌다 = 처리되는 데이터가 많아졌다. 22 | 23 | ### 지연시간 24 | > 요청이 처리되는 시간(두 장치 사이를 왕복하는데 걸린 시간) 갔다가 오는 25 | 26 | 매체 타입(유선인지 무선인지), 패킷의 크기, 라우터의 패킷 처리 시간에 영향을 받음 27 | 28 | ## 2.1.2 네트워크 토폴로지와 병목현상 29 | 30 | ### 네트워크 토폴로지 31 | 노드와 링크가 어떻게 배치되어 있는지에 대한 방식. 연결 형태 32 | 33 | 34 | >토폴로지? 35 | >한국어로 하면 망구성방식 36 | >**컴퓨터 네트워크의 요소들(링크, 노드 등)을 물리적으로 연결해 놓은 것, 또는 그 연결 방식** 37 | 38 | 39 | - 트리 토폴로지 40 | - 계층형 41 | - 장점 42 | - 노드 추가/삭제가 쉬움 43 | - 단점 44 | - 특정 노드에 트래픽이 집중될 때 하위노드에 영향을 끼칠 수 있음! 45 | - 버스 토폴로지 46 | - 중앙 통신 회선 하나에 여러개의 노드가 연결되어 공유 47 | - 근거리통신망(LAN) 48 | - 장점 49 | - 설치 비용 적음 50 | - 신뢰성 우수 51 | - 노드 추가/삭제 쉬움 52 | - 단점 53 | - 스푸핑이 가능하다는 문제가 있음 54 | > 스푸핑? 55 | >- 스위칭(송신과 관련 없는 다른 호스트에게 가지 않도록) 기능을 마비 시키거나 속여서 특정 노드에게 해당 패킷이 오도록 처리하는 것 56 | >- 악의적인 노드에 전달되게 된다. 57 | - 스타 토폴로지 58 | - 성형 59 | - 중앙에 있는 노드에 모두 연결됨 60 | - 장점 61 | - 노드 추가 쉬움 62 | - 에러 탐지도 쉬움 63 | - 패킷 충돌 발생 가능성 낮음 64 | - 장애노드가 중앙노드가 아닐 경우 영향을 끼치는것이 적음 65 | - 단점 66 | - 중앙노드에 장애 발생 시 전체가 다운됨 67 | - 비용이 높다 68 | - 링형 토폴로지 69 | - 메시 토폴로지 70 | 71 | ### 병목현상 72 | 73 | -------------------------------------------------------------------------------- /면접을 위한 CS 전공지식 노트/네트워크/2.2 TCPIP 4계층 모델.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/면접을 위한 CS 전공지식 노트/네트워크/2.2 TCPIP 4계층 모델.md -------------------------------------------------------------------------------- /면접을 위한 CS 전공지식 노트/네트워크/2.3 네트워크 기기.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/면접을 위한 CS 전공지식 노트/네트워크/2.3 네트워크 기기.md -------------------------------------------------------------------------------- /면접을 위한 CS 전공지식 노트/네트워크/2.4 IP주소.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/면접을 위한 CS 전공지식 노트/네트워크/2.4 IP주소.md -------------------------------------------------------------------------------- /면접을 위한 CS 전공지식 노트/네트워크/2.5 HTTP.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/면접을 위한 CS 전공지식 노트/네트워크/2.5 HTTP.md -------------------------------------------------------------------------------- /면접을 위한 CS 전공지식 노트/디자인 패턴/1.1 디자인 패턴.md: -------------------------------------------------------------------------------- 1 | 2 | ## 1.1.1 싱글톤 패턴 3 | **하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴** 4 | 5 | ### 싱글톤 패턴이 필요한 이유? 6 | > 왜 객체(인스턴스)가 하나여야만 하지? 7 | > -> 인스턴스 생성 비용을 아끼기 위해서 8 | 9 | ### 싱글톤의 단점 10 | - TDD가 어렵다. 11 | - 싱글톤에서는 하나의 미리 만들어진 인스턴스를 가지고 돌려쓰는 것인데, 테스트 코드에서 항상 해당 인스턴스를 가지게 하기가 어렵다. 12 | 그렇다면 어떻게 해결하냐, 의도적으로 미리 넣어준다. -> 의존성 주입 (DI)를 하면 된다! 13 | 싱글톤은 모듈간의 결합을 강하게 만들지만, DI를 통해 결합을 느슨하게 만들 수 있다. 14 | 15 | > 싱글톤은 왜 결합을 강하게 만들지? 16 | > -> 하나를 가지고 계속 돌려쓰니까. 그게 아니면 안되게 만들어버렸는데, 계속해서 넣어줘야만 하니까. 17 | 18 | 의존성 = 종속성으로, A가 B에 의존한다는 것은, B의 변화로 인해 A도 변해야한다는 것 19 | 20 | 메인 모듈 하나에서 서브모듈로 일일이 하나하나 주입하던 것을, 의존성 주입자(Dependency Injector)가 가로채서 넣어준다. 그렇게 되면 메인 모듈과 서브 모듈 간의 의존성이 떨어지게 된다. 21 | 22 | > 서브모듈이라는 표현이 적절할까? 책에서는 하위 모듈이라고 나와있긴하다. 23 | > 24 | > 그렇다면 모듈은 뭘까? 25 | > 모듈은 기능 단위로 코드를 쪼갠 것이다. 단순히 쪼갰다 보다, 하나의 "기능" 단위로 쪼갰다에 초점을 맞추면 될 것 같다. 독립적인 기능이라고 생각하면 되겠다. 26 | > 모듈화를 하면 유지보수와 재사용성이 높은 코드를 짤 수 있다. 가장 큰 고민은, *어느 정도로 작게 모듈을 분리할 것인가*가 될 것 같다. 27 | > 28 | > 여기서 객체지향과 모듈화가 어느정도 비슷한 의미를 가지는 것 같은데, 뭐가 다른지도 봐보자. 29 | > 캡슐화를 해서 다른 곳에서 가져다 쓸 수 있지만, 다른 점이 존재한다. 30 | 31 | | | 클래스(객체=인스턴스) | 모듈 | 32 | | ---- | ---- | ---- | 33 | | 인스턴스화 | O | X | 34 | | 상속 | O | X | 35 | | 목적 | 객체를 만들기 위해 | 클래스에 메소드를 제공하기 위해 (클래스에서 사용할 기능을 제공하기 위해) | 36 | 37 | 38 | 39 | ### 의존성 주입 40 | 41 | - 의존성 주입의 장점 42 | - 모듈들을 교체하기 쉬운 구조가 된다. 결합력이 낮아져서 가능해진 것 43 | - 테스트와 마이그레이션 하기 쉽다. 44 | - 구현에 있어서 추상화 레이어를 넣고, 이를 기반으로 구현체를 넣어주기 때문에 의존성의 방향이 일관된다. 45 | 46 | - 의존성 주입의 단점 47 | - 모듈들의 분리가 더 많아져서, 클래스의 수가 많아진다. ~~그래서 나같은 초보자한테는 뭐가 어디있는지, 찾기 어려울수도..~~ 48 | 49 | - 의존성 주입의 원칙 50 | - "상위 모듈은 하위모듈에서 어떠한 것도 가져올 수 없다." 51 | - 상위모듈과 하위모듈 둘다 추상화에 의존해야하며, 추상화는 세부사항에 의존하지 말아야한다. 52 | ## 1.1.2 팩토리 패턴 53 | 54 | 공장을 생각하면 쉽다. 55 | 인스턴스 생성을 공장으로 분리한다. 56 | 57 | - 인스턴스 생성 58 | - 상위 클래스 59 | - 뼈대를 결정하고 60 | - 하위 클래스 61 | - 구체적인 내용을 정의한다. 62 | --- 63 | - 상위 클래스와 하위 클래스가 나눠지기에 느슨한 결합을 가진다. 64 | - 팩토리로 인스턴스 생성을 위임해, 상위클래스에서는 인스턴스의 생성방식에 대해서 알필요가 없어져서 유연하다. 65 | - 객체 생성이 떨어져 있기 때문에 리팩토링에도 부담이 없다. <- 한 곳만 고치면 되기 때문! 66 | 67 | [제대로 이해하는 싱글톤패턴](https://www.youtube.com/watch?v=DHo8qRCtmGU) 68 | ## 1.1.3 전략 패턴 69 | 70 | **객체의 행위를 바꾸고 싶은 경우, 직접 수정하지 않고, 전략이라고 부르는 "캡슐화된 알고리즘"을 컨택스트 안에서 바꿔주면서 상호 교체가 가능하게 만든다.** 71 | 72 | 정리하자면, 객체가 행하는 행위에 대해서 캡슐화를 진행한다. 73 | 74 | 제대로 이해한 것인지는 모르겠지만, 예를 들자면 이러하다. 75 | 76 | - 책에 있는 예시 1 77 | - 라인 카드와 카카오 카드로 결제를 하려 한다. 라인 카드와 카카오 카드에 필요한 개인 정보의 종류와 가짓수는 다르다. pay 메소드 자체를 조건을 거는게 아니라, pay 메소드의 파라미터 자체를 "결제방식"으로 추상화 해서 라인카드가 들어가던, 카카오 카드가 들어가던 하게 하는 것이다. 78 | ```kotlin 79 | //결제 부 80 | pay(KAKAOCard("qqq@email.com","qlalfqjsgh")) 81 | 82 | // 함수 구현부 83 | fun pay(payment: Payment){ 84 | 85 | } 86 | 87 | 88 | //클래스 구현부 89 | class KAKAOCard : Payment(){ 90 | //이메일, 비밀번호 등 91 | } 92 | ``` 93 | - 내 머리 속에 있는 예시 2 94 | - 마찬가지로, Oauth도 각 플랫폼 마다 수집할 수 있는 항목이 다르다. apple 로그인에는 일련번호를 알면 이메일을 백엔드 딴에서 알아오는 것으로 되어 있고, 카카오는 바로 일련번호와 이메일을 알아 올 수 있다. 클라이언트 측에서 가져올 수 있는 정보가 다르기에 로그인이라는 메소드를 어느 정도 추상화시키고, 파라미터 자체에 oauth를 상속 받는 kakaoLogin나 naverLogin 등을 넣어주는 것이다. 95 | ```kotlin 96 | fun login(oauth: Oauth){ 97 | 98 | } 99 | 100 | 101 | //클래스 구현부 102 | class KAKAOLogin() : Oauth{ 103 | //이메일, 비밀번호 등 104 | } 105 | ``` 106 | 107 | 추상화와 확장성(종류를 늘릴 수 있다.) 단순히 플랫폼의 이름만 다른게 아니라, 수집하는 개인 정보도 다르기에, oauth 플랫폼의 종류를 enum으로 관리하는 것보다 더 나은 것 같다. 108 | 109 | >Enum [이넘] 110 | >처음 안드로이드를 할 때 카테고리는 이넘 값으로 줄게요~ 했던게 기억이 난다. ㅋㅋㅋ 111 | 112 | ## 1.1.4 옵저버 패턴 113 | - 주체 114 | - 객체 115 | - 옵저버 116 | 117 | 세 개의 등장인물이 등장한다. 118 | 119 | **주체가 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등의 방식으로 옵저버 목록에 있는 옵저버들 한테 변화를 알리는 것** 120 | 121 | 트위터나 유튜브에서 구독을 하면 해당 유저가 새 글을 올리면 푸쉬 알림을 보내준다. 이러한 것이 Observe! 122 | 123 | 124 | ---- 125 | 126 | - 자바의 상속과 구현 127 | 128 | | | extends 상속 | implement 구현 | 129 | | ---- | ---- | ---- | 130 | | 기본 | 자식 클래스가 부모 클래스의 변수나 메소드를 상속 받아서 사용한다. 자식 클래스 추가나 확장을 할 수 있다. | 부모 인터페이스를 자식 클래스에서 재정의해서 구현한다. 메소드를 그대로 사용할 수 없다. 반드시 재정의 해야함 | 131 | | 목적 | 재사용성 높이기, 중복성 최소화하기 | 상대적으로 관련성이 없는 클래스들을 묶고 싶을때 | 132 | | 방법 | 일반 클래스, 추상 클래스 | 인터페이스 | 133 | 134 | > 그렇다면 코틀린은 상속과 구현을 구분하는가? 135 | > 코틀린의 상속은 `클래스 명(): 상속할 클래스 `이런식으로 한다. 136 | > 키워드가 아닌 `:`으로 상속을 표현하는데, 상속과 구현을 구분할 수 있을까? 137 | > 138 | > -> 결론은 못한다. 그리고 어차피 다중상속이 안된다! 139 | > 하지만 인터페이스 다중 상속은 가능하다. 목적은 두 인터페이스를 묶는 하나의 클래스를 만드는 용도! 140 | 141 | 142 | ```kotlin 143 | //클래스 구현부 144 | class KAKAOLogin() : Oauth{ 145 | //이메일, 비밀번호 등 146 | } 147 | 148 | ``` 149 | 책에는 안나와있지만 Kotlin으로 안드로이드의 [observer 패턴](https://velog.io/@changhee09/%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C-LiveData)을 알아봐보자 150 | 151 | 152 | ## 1.1.5 프록시 패턴과 프록시 서버 153 | 154 | **객체에 접근하기 전에 접근에 대한 흐름을 가로채서 객체 앞단의 인터페이스 역할을 하는 디자인 패턴** 155 | 156 | - 프록시의 역할 157 | - 프록시 객체로써 보안, 데이터 검증, 로깅 등에 사용 158 | - 프록시 서버로 사용 159 | - 프록시 서버 160 | - 클라이언트와 서버가 통신할때, 서버의 앞단에서 가로채서 클라이언트가 직접적으로 접근하는 것을 막는다. 161 | - nginX 162 | - 한 단계 더 거치도록! 왜? 보안을 강화! -> 실제 포트를 숨기거나, 정적 자원을 gzip 압축하거나, 서버 앞단에서 로깅을 할 수도 있음 163 | - CloudFlare 164 | - 디도스 공격 방어 165 | - HTTPS 구축 166 | - CORS(Cross-Origin Resource Sharing) 167 | - 다른 오리진을 통해 로드하지 못하게! 168 | - 오리진 = base url? 프로토콜+호스트이름+포트 169 | - 프론트에서는 localhost 3000포트를 쓰고, 서버는 12010 포트를 쓴다면, 프록시 서버를 통해 프론트의 요청을 12010번으로 바꾸어 줄 수 있다! 170 | ## 1.1.6 이터레이터 패턴 171 | **이터레이터를 사용해서 컬렉션의 요소에 접근하는 패턴** 172 | 173 | 순회할 수 있는 자료형의 구조와 상관없이 "이터레이터"라는 하나의 인터페이스로 순회가 가능하다. 174 | let 175 | 176 | 다른 객체라도 같은 배로 순회할 수 있다~! 177 | 178 | - js에서는 `for a of b` 179 | - [kotlin](https://philosopher-chan.tistory.com/1303) 에서는 `for (a in b)` 180 | 181 | ## 1.1.7 노출모듈 패턴 182 | 183 | **즉시 실행 함수를 통해 접근 제어자를 만드는 패턴!** 184 | 185 | 접근 제어자 186 | - 자바의 경우 private, public, protected 등 접근 제어자가 존재. 187 | - JS는 없다. 188 | 189 | >즉시 실행 함수 190 | >: 함수를 정의하자마자 바로 호출하는 함수. 초기화 코드, 라이브러리 내 전역 변수의 충돌 방지 등에 사용한다. 191 | 192 | ## 1.1.8 MVC 패턴 193 | > Model, View, Controller 194 | 195 | 장점 196 | - 재사용성과 확장성이 용이 197 | 단점 198 | - 앱이 복잡해질 수록 모델과 뷰의 관계가 복잡해진다. 199 | 200 | 각각의 역할 201 | - Model 202 | - DB, 상수, 변수 등 203 | - 사각형 안에 글자가 있다면, 해당 박스의 위치 정보, 글자의 내용, 글자 위치, 포맷 등 정보를 가짐. 204 | - 뷰에서 데이터를 생성하거나 수정하려면 반드시 컨트롤러를 통해 모델을 생성/수정해야 함. 205 | - View 206 | - UI적인 요소 207 | - 모델을 기반으로 사용자가 볼 수 있는, 보여지는 화면 208 | - 모델이 가지고 있는 정보를 가지고 있지 않아야함. 209 | - 단순히 화면에 그리는 역할만 함. 210 | - Controller 211 | - 모델과 뷰를 잇는 다리 역할. 메인 로직은 여기에~! 212 | - 모델과 뷰가 1:1 대응일 필요는 없음(하나 이상의 뷰와 하나 이상의 모델을 연결) 213 | - 모델과 뷰의 생명주기 관리 214 | 215 | 예시 216 | - 스프링의 MVC 패턴 217 | ## 1.1.9 MVP 패턴 218 | 컨트롤러 대신 Presenter가 들어간다. 219 | 220 | 뷰와 프리젠터는 1:1이다. -> 더 강한 결합 221 | ## 1.1.10 MVVM 패턴 222 | 컨트롤러 대신 ViewModel이 들어간다. 223 | 224 | ViewModel 225 | - 뷰를 더 추상화한 계층 226 | - 커맨드와 데이터 바인딩을 가진다. 227 | - 커맨드 : 여러가지 요소에 대한 처리를 하나의 액션으로 처리할 수 있게 하는 기법 228 | - 데이터 바인딩 : 화면에 보이는 데이터와 웹 브라우저의 메모리 데이터를 일치시키는 기법. 뷰모델을 변경하면 뷰가 변경된다. 함수를 사용하지 않고 값의 대입 만으로 변수 변경이 되어서 편리함 229 | - 뷰-뷰모델은 양방향 데이터 바인딩을 지원. 230 | - UI(뷰)를 코드 수정 없이 재사용할 수 있음 231 | - 단위 테스트가 쉬움 232 | 233 | 234 | 예시 235 | - Vue.js -------------------------------------------------------------------------------- /면접을 위한 CS 전공지식 노트/디자인 패턴/1.2 프로그래밍 패러다임.md: -------------------------------------------------------------------------------- 1 | 프로그래머가 프로그래밍의 관점을 갖게 해주는 개발 방법론 2 | 3 | - 프로그래밍 패러다임 4 | - 선언형 5 | - 함수형 6 | - 명령형 7 | - 객체지향형 8 | - 절차지향형 9 | 10 | 11 | ## 1.2.1 선언형과 함수형 프로그래밍 12 | 13 | **순수 함수들을 블록처럼 쌓아 로직을 구현하고, 고차함수를 통해 재사용성을 높인 프로그래밍 패러다임** 14 | 15 | *무엇을* 풀어내는가? 16 | 프로그램은 함수로 이루어져 있다. 17 | 18 | JS는 함수형 프로그래밍이다. 19 | 20 | 21 | 순수함수 22 | - 출력이 입력에만 의존한다 23 | - = 리턴 값이 매개변수에만 의해서 결정된다. 24 | - 다른 전역변수 등의 영향을 받아서 리턴값이 결정되면 그것은 순수함수가 아님! 25 | 26 | 27 | 고차함수 28 | - 함수가 함수를 값처럼 매개변수로 받아 로직을 생성할 수 있는 것 29 | - =함수의 매개변수로 함수를 받는다. 30 | - 함수의 리턴값?일까? 31 | - 고차 함수를 쓰기 위해서는 해당 언어가 일급객체여야 함. 32 | 33 | 일급객체 34 | - 변수나 메서드에 함수를 할당 할 수 없음 35 | - 함수 안에 함수를 매개변수로 담을 수 있음 36 | - 함수가 함수를 반환할 수 있음 37 | ?? 도통 먼소린지 모르겠다. 38 | 39 | > 일급객체에 대해 40 | > 41 | 42 | ## 1.2.2 객체지향 43 | 44 | - 객체들의 집합으로 프로그램을 만듦. 45 | - 설계 및 코드 작성에 걸리는 시간이 비교적 느림 46 | 47 | #### 객체 지향의 주요 특성 48 | - 추상화 49 | - 흩뿌려진 데이터를 바탕으로 간소화해서 기능을 간추린다. 핵심적인 정보만 추출! 50 | - 캡슐화 51 | - 클래스를 만든다. 속성(변수)와 메서드 추려서 클래스로 만들며 이를 통해 은닉할 수 있다. 52 | - 상속 53 | - 상위 클래스의 특성을 하위 클래스가 이어받아 재사용, 추가, 확장해서 사용. 54 | - 코드 재사용, 계층 관계 생성, 유지보수 굿 55 | - 다형성 56 | - 하나의 메서드 이름을 가지고 다양한 방법으로 동작하게 끔 할 수 있는 꼼수? 57 | - 오버로딩 58 | - 같은 이름을 가진 메서드를 여러개 둘 수 있다. 59 | - 매개변수의 타입, 개수, 리턴타입 등을 다르게 주면 다른 메소드가 된다~! 60 | - 오버라이딩 61 | - = 메서드 오버라이딩, 상속받은 상위 클래스의 메소드를 그대로 쓰지 않고 하위 클래스에서 "재정의"해서 쓰는 것을 말함. 62 | 63 | 64 | #### 설계원칙 65 | 객체지향 프로그래밍은 SOLID원칙을 지켜야한다. 66 | - SRP(Single Responsibility Principle): 단일 책임 원칙 67 | 모든 클래스는 각각 하나의 책임만을 가져야한다. 68 | - OCP(Open Closed Principle): 개방-폐쇄 원칙 69 | 유지보수 사항이 생긴다면 코드를 쉽게 확장할 수 있어야하고 수정할때는 닫혀있어야한다. **기존의 코드는 잘 변경하지 않으면서도 확장은 쉽게 되어야함** 70 | - LSP(Liskov Substitution Principle): 리스코프 치환 원칙 71 | 하위타입의 인스턴스로 바꿀 수 있어야함. 부모 객체에 자식 객체를 넣어도 문제 없이 돌아가야한다. 서브 웨이 객체에 서브웨이 우즈 정식 객체를 넣어도 작동되어야함! 72 | - ISP(Interface Segregation Principle): 인터페이스 분리 원칙 73 | 하나의 인터페이스보다 구체적인 여러개의 인터페이스를 만들어야함 74 | - DIP(Dependency Inversion Principle): 의존 역전 원칙 75 | 상위 계층(추상회된 인터페이스, 상위 클래스 등)은 변하기 쉬운 것들(하위계층)에 의해 변화 받지 않아야한다. 76 | **상위 계층은 하위 계층의 변화에 영향을 받지 않아야함** 77 | ## 1.2.3 절차형 78 | 79 | 로직 자체가 수행되어야할 연속적인 계산 과정으로 되어 있는 것 80 | 81 | #### 장점 82 | - 코드의 가독성이 좋고 실행 속도가 빠르다. 83 | - 계산이 많은 작업에서 많이 쓰이며 84 | - Fortran에서 쓰임! 85 | 86 | #### 단점 87 | - 모듈화가 어렵다 88 | - 유지보수성이 떨어진다 -------------------------------------------------------------------------------- /스크린샷 2024-03-25 오후 4.51.12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-03-25 오후 4.51.12.png -------------------------------------------------------------------------------- /스크린샷 2024-03-25 오후 5.02.14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-03-25 오후 5.02.14.png -------------------------------------------------------------------------------- /스크린샷 2024-03-25 오후 5.39.50.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-03-25 오후 5.39.50.png -------------------------------------------------------------------------------- /스크린샷 2024-03-25 오후 7.30.04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-03-25 오후 7.30.04.png -------------------------------------------------------------------------------- /스크린샷 2024-03-25 오후 7.31.07.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-03-25 오후 7.31.07.png -------------------------------------------------------------------------------- /스크린샷 2024-03-25 오후 7.33.59.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-03-25 오후 7.33.59.png -------------------------------------------------------------------------------- /스크린샷 2024-03-25 오후 7.41.39.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-03-25 오후 7.41.39.png -------------------------------------------------------------------------------- /스크린샷 2024-11-07 오후 12.46.24.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-11-07 오후 12.46.24.png -------------------------------------------------------------------------------- /스크린샷 2024-11-08 오후 12.28.56.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-11-08 오후 12.28.56.png -------------------------------------------------------------------------------- /스크린샷 2024-11-08 오후 12.29.25.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-11-08 오후 12.29.25.png -------------------------------------------------------------------------------- /스크린샷 2024-11-26 오후 12.16.18.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-11-26 오후 12.16.18.png -------------------------------------------------------------------------------- /스크린샷 2024-11-26 오후 2.30.51.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-11-26 오후 2.30.51.png -------------------------------------------------------------------------------- /스크린샷 2024-11-28 오후 1.36.51.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-11-28 오후 1.36.51.png -------------------------------------------------------------------------------- /스크린샷 2024-11-28 오후 1.40.12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-11-28 오후 1.40.12.png -------------------------------------------------------------------------------- /스크린샷 2024-12-12 오전 11.25.56.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-12-12 오전 11.25.56.png -------------------------------------------------------------------------------- /스크린샷 2024-12-12 오전 11.27.07.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-12-12 오전 11.27.07.png -------------------------------------------------------------------------------- /스크린샷 2024-12-12 오후 1.28.19.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/스크린샷 2024-12-12 오후 1.28.19.png -------------------------------------------------------------------------------- /안드로이드/Companion Object.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HI-JIN2/cs-study/197f63abe45db70c988bc5451ee48d4370d7d70e/안드로이드/Companion Object.md -------------------------------------------------------------------------------- /안드로이드/DataBinding.md: -------------------------------------------------------------------------------- 1 | 2 | - jetpack 3 | 4 | > `layout` 파일에서 구성요소를 결합하면 활동에서 많은 UI 프레임워크 호출을 삭제할 수 있어 파일이 더욱 단순화되고 유지관리 또한 쉬워집니다. 앱 성능이 향상되며 _**메모리 누수 및 null 포인터 예외**_를 방지할 수 있습니다. 5 | 6 | ```xml 7 | 9 | 10 | ``` 11 | 12 | - data 태그 내에서 뷰모델 정의 13 | 14 | ```xml 15 | 17 | 18 | 21 | 22 | 23 | 24 | 25 | ``` 26 | 27 | - 양방향 데이터 바인딩도 가능 28 | 29 | 30 | --- 31 | 참고자료 32 | - [DataBinding에 ViewModel, LiveData와 함께 사용하기](https://develop-writing.tistory.com/45) 33 | - [데이터 결합 라이브러리  |  Android 개발자  |  Android Developers](https://developer.android.com/topic/libraries/data-binding?hl=ko) 34 | - [https://github.com/android/databinding-samples](https://github.com/android/databinding-samples) -------------------------------------------------------------------------------- /안드로이드/Flow.md: -------------------------------------------------------------------------------- 1 | 2 | ```kotlin 3 | viewModelScope.launch { 4 | getUserInfoUseCase().onStart { 5 | _uiState.update { it.copy(loading = true) } 6 | }.onCompletion { 7 | _uiState.update { it.copy(loading = false, error = true) } 8 | }.catch { e -> 9 | _uiState.update { it.copy( error = true, toastMessage = App.appContext.getString(R.string.not_found) ) 10 | } 11 | Timber.e(e.toString()) 12 | }.collectLatest { result -> 13 | Timber.d(result.toString()) 14 | result.result?.apply { 15 | if (this.nickname.isNullOrBlank()) { 16 | _uiState.update { it.copy( isNicknameNull = true, toastMessage = App.appContext.getString(R.string.set_nickname) ) } 17 | } else { 18 | _uiState.update { it.copy( isNicknameNull = false, toastMessage = (String.format(App.appContext.getString(R.string.hello_user),this.nickname))) 19 | } 20 | } 21 | } 22 | } 23 | ``` 24 | 25 | 26 | - onStart: Flow가 수집되기 전에 지정된 action을 먼저 수행하는 Flow를 반환 27 | - onCompletion: Flow가 완료,취소 또는 예외 발생시에 지정된 action을 호출 하는 Flow를 반환 28 | - catch: 예외 처리 29 | 30 | ``` 31 | fun some() { 32 | viewModelScope.launch { 33 | try { 34 | // call suspend function 35 | } catch(e: Exception) {} 36 | } 37 | } 38 | ``` 39 | 40 | - collectLatest: 항상 최신의 정보를 수집 41 | - collectLatest vs collect 42 | - 새로운 데이터가 들어왔을 때 어떻게 처리하냐의 차이 43 | - collect: 이전 데이터의 처리가 끝난 후에 새로운 데이터를 처리함 44 | - collectLatest: 이전 데이터의 처리를 강제 종료시키고 새로운 데이터를 처리함 45 | 46 | > 참고자료 47 | > - https://velog.io/@devoks/Kotlin-Flow 48 | > - https://kotlinworld.com/252 -------------------------------------------------------------------------------- /안드로이드/Livedata.md: -------------------------------------------------------------------------------- 1 | 2 | - jetpack 3 | - 관찰가능한 데이터 홀더 클래스 4 | - 수명주기를 인식한다 → 수명 주기 상태에 있는 구성 요소만 업데이트를 한다! `onStart`, `onResume` 5 | `onDestroyed` 일 때는 관찰자 삭제 6 | 7 | ⇒ 메모리 누수 걱정이 없다! 8 | 9 | - 이점 10 | - UI와 데이터 상태의 일치 보장 11 | - 중지된 활동으로 인한 비정상 종료 없음 12 | - 메모리 누수 없음 13 | - 수명주기 자동으로 처리 14 | - 최신 상태의 데이터로 유지 15 | - 리소스 공유 16 | 17 | - 사용법 18 | 1. 보통 `LiveData`는 `ViewModel` 클래스에서 만들어진다. 19 | 2. `activity/fragment`에서 `Observer` 객체를 만든다. 객체 안에 `onChanged()` 메서드를 정의한다. 20 | 3. `observe()` 메소드를 사용해서 `LiveData` 객체에 `Observer` 객체를 연결한다. `observe()` 메소드는 `LifecycleOwner` 객체를 사용. `Observer` 가 `LiveData` 객체를 구독하여 변경사항에 대해 인지한다. 21 | 22 | - `LiveData` 객체 observe 23 | - `onCreate`에서 observe하기 좋음 24 | - 이유 25 | - `onResume`에서 중복 호출하지 않기 위해서 26 | - `activity/fragment` 에서 즉시 표시되는 데이터가 포함되게 하기 위해서. 27 | 28 | - `LiveData` 객체 업데이트 29 | - 수정가능한 `MutableLiveData` 의 `setValue()`(기본스레드)나 `postValue()`(백드라운드 스레드)를 사용해서 수정한다. 30 | - `MutableLiveData` 31 | - get() 그때마다 받아오고 32 | - = 연산자는 객체복사 33 | - 얘만 프라이빗→ 뷰모델에서만 건들일 수 있겠끔~ 34 | - `LiveData` 35 | - **메인 스레드**(UI 스레드) 그래서 과부화 36 | - 클린 아키텍쳐가 깨짐 37 | - 그래서 flow를 씀 (쓰레드 가능) 38 | - 그렇게 되면 observer는 `onChange()` 메서드를 호출한다. 39 | 40 | 41 | +) transformation map 42 | 43 | 단점: 라이브데이터는 안드로이드 플랫폼에 종속되어 잇음. 클린아키텍쳐에서는 도메인 레이어는 44 | 45 | 46 | 47 | 48 | 참고 자료 49 | - https://velog.io/@changhee09/%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C-LiveData 50 | - [LiveData 개요  |  Android 개발자  |  Android Developers](https://developer.android.com/topic/libraries/architecture/livedata?hl=ko) -------------------------------------------------------------------------------- /정보처리기사/필기 벼락치기 준비.md: -------------------------------------------------------------------------------- 1 | https://hi-jin-1514.notion.site/ba5aad504a84435190b540d6b19e773f?pvs=4 2 | 3 | ## 공부할 거 정리 4 | 5 | 1. 소프트웨어설계 6 | 1. 소프트웨어 공학 내용 7 | 2. 소프트웨어개발 8 | 1. 자료구조 9 | 2. 알고리즘 10 | 3. 테스트 11 | 3. 데이터베이스구축 12 | 1. SQL 13 | 2. DB 14 | 4. 프로그래밍언어활용 15 | 1. C/JAVA/Python 16 | 2. OS 17 | 5. 정보시스템구축관리 18 | 1. 기타 잡다구리한 신기술 외우기 19 | 20 | -------------------------------------------------------------------------------- /코딩테스트 준비하기.md: -------------------------------------------------------------------------------- 1 | - 디버깅: 논리 오류를 찾아 바로 잡는 과정 2 | 문법 오류는 컴파일러가 찾아줌 3 | 논리 오류는 코드가 사용자의 의도와 다르게 동작하는 것 -------------------------------------------------------------------------------- /코틀린 코루틴의 정석/1장 스레드 기반 작업의 한계와 코루틴의 등장.md: -------------------------------------------------------------------------------- 1 | 코루틴이 추상적인 개념인 것 같아서 공부하게 됨 2 | 3 | ------ 4 | 단일 프로세스에서 학습 5 | 안드로이드랑 서버 사이드를 같이 다뤄서 이해하기 좋은듯 6 | 7 | ## 1-1. JVM 프로세스와 스레드 8 | 9 | 메인 스레드를 생성하고 메인스레드를 사용해 코드를 실행함 10 | 11 | 모든 스레드가 종료되면 프로세스가 종료됨 12 | 13 | ## 1-2. 단일 스레드를 사용하는 것의 한계와 멀티 스레드 프로그래밍 14 | 15 | 동시에 수행하지 못함 16 | 17 | 하나의 작업이 오래걸리면 다른 작업을 전혀 할 수 없음 → 응답성의 문제 발생 가능 18 | 19 | 멀티스레드 → 병렬처리 20 | 21 | 작업 간의 독립성이 있어야만 병렬처리가 가능 22 | 23 | ## 1-3. 스레드, 스레드풀을 사용한 멀티 스레드 프로그래밍 24 | 25 | 1. 스레드 클래스를 이용해 직접 생성 26 | 27 | - 스레드 28 | - 종료 29 | - 사용자 스레드 → 얘가 모두 종료될때 JVM프로세스가 종료됨 / 기본적으로 스레드를 생성하면 사용자 스레드로 나옴 isDaemon =true 하면 데몬으로 됨 30 | - 데몬스레드 31 | - 스레드 클래스를 직접 다루는것에 대한 한계 32 | - 스레드의 생성 비용이 비쌈. 33 | - 스레드의 생성과 관리에 대한 책임은 개발자. 신경쓸게 많아짐. 메모리 누수, 오류 등 가능성 있음. 재사용이 어려움 34 | 2. 스레드풀 Excutor 프레임워크 35 | 36 | 스레드풀 = 스레드의 집합 37 | 38 | excutor 프레임워크 : 스레드풀을 미리 생성해 놓고, 작업을 요청받으면 쉬고 있는 스레드에 작업을 분배함. 작업을 다하고 온 스레드는 종료시키지 않고 재사용함 39 | 40 | → 스레드를 생성하는 비용이 많이 들어서 미리 생성해놓고 재사용? 41 | 42 | 스레드의 생성과 관리를 excutor에게 위임함. 43 | 44 | 개발자가 하는 일 45 | 46 | 1. 스레드 개수 설정 가능. 47 | 2. `submit` 48 | 3. `shutdown` 49 | 50 | 한계 : 스레드 블로킹(작업을 기다리면서 리소스를 소비하지만 아무일도 하지 않는 상태) 51 | (안써봄) 52 | 53 | ## 1-4. 기존 멀티 스레드 프로그래밍의 한계와 코루틴 54 | 55 | 코루틴 : 자신이 스레드를 사용하지 않을 때 스레드 사용 권한을 반납함. → 스레드를 효율적으로 사용 → 스레드가 블로킹되는 상황 방지 56 | 57 | 스레드에 비해 생성 비용 ,전환 비용이 적음. → 여기 저기 뗐다 붙였다 할 수 있어서 경량 스레드 라고 불림 58 | 59 | 그외 장점 60 | 61 | - 구조화된 동시성 → 비동기 작업 안전 62 | - 예외 처리 효과적 63 | - 스레드 손쉽게 전환 -------------------------------------------------------------------------------- /코틀린 코루틴의 정석/2장 코루틴 개발 환경 설정.md: -------------------------------------------------------------------------------- 1 | - 기본 코루틴에서는 저수준의 기능만을 제공함 2 | - 다양한 기능을 사용하기 위해서는 젯브레인에서 만든 코루틴 라이브러리 `kotlinx.coroutines`를 사용해보자 3 | 4 | --- 5 | 6 | 람다식에 있는 모든 코드가 실행 완료될때까지 코루틴은 종료되지 않는다. 7 | 8 | `runBlocking` 코루틴이 실행 완료될때까지 이 코루틴이랑 상관 없는 작업이 스레드를 점유하지 못하게 막는다. 메인스레드를 점유하는 코루틴이 만들어지고, 그 코루틴이 다 완료되면 메인스레드 점유가 끝난다. 9 | 10 | --------- 11 | 1. 디버깅 12 | 어떤 코루틴이 어떤 스레드에서 실행되고 있는지를 알아야 디버깅이 가능함. 13 | ```kotlin 14 | fun main() = runBlocking { 15 | printIn(" [${Thread.currentThread().name}]") 16 | } 17 | ``` 18 | 2. 스레드 뿐만 아니라 코루틴 이름도 출력하게 할 수 있음 19 | - VM option 20 | - `-Dkotlinx.coroutines.debug` 21 | ![[스크린샷 2024-11-07 오후 12.46.24.png]] 22 | 23 | 24 | 3. launch 25 | - `runBlocking` 안에 `launch`를 쓰면 코루틴을 추가로 만들 수 있음 26 | 27 | 28 | 29 | 30 | 4. `CoroutineName` 31 | - 코루틴에 이름을 붙일 수 있음 32 | ```kotlin 33 | fun main() = runBlocking{ 34 | launch(context=CoroutineName("Corutine1")){ 35 | ... 36 | } 37 | } 38 | ``` 39 | 40 | -------------------------------------------------------------------------------- /코틀린 코루틴의 정석/3장 CoroutineDispatcher.md: -------------------------------------------------------------------------------- 1 | 2 | CoroutineDispatcher 3 | ## 3-1. CoroutineDispatcher란 무엇인가? 4 | > 코루틴을 보내는 주체 5 | 코루틴을 어디로 보냄? 스레드로 6 | 7 | 코루틴은 일시정지가 가능한 작업(Job)이라서 스레드가 있어야 실행가능함 8 | 9 | 스레드풀 개념을 여기서도 씀 10 | 11 | ![[스크린샷 2024-11-08 오후 12.28.56.png]] 12 | ![[스크린샷 2024-11-08 오후 12.29.25.png]] 13 | 14 | 스레드가 다 차면? 일단 대기열에 넣어놓고, 남는 스레드가 있을때 스레드에 보낸다. 15 | 16 | CoroutineDispatcher는 코루틴의 실행을 관리하는 주체 17 | 코루틴을 작업 대기열에 적재하고, 스레드가 일할 수 있는 상태라면 코루틴을 스레드에 보낸다. 18 | ## 3-2. 제한된 디스패처와 무제한 디스패처 19 | 1. 제한된 디스패처 20 | 1. 사용할 수 있는 스레드나 스레드풀이 제한됨 21 | 2. 대부분이 이거임 22 | 3. 입출력 작업용 / CPU 작업용 등.. 23 | 2. 무제한 디스패처 24 | 1. 사용할 수 있는 스레드나 스레드풀이 제한되지 않음 25 | 2. 실행 요청된 코루틴이 이전 코드가 실행되던 스레드에서 계속해서 실행되도록 한다. 26 | -> 실행되는 스레드가 매번 달라질 수 있고, 특정 스레드로 제한되지 않아 무제한 디스패처라는 이름을 갖게 됨 27 | 3. 11.3장에서 자세히 다룸 일단 패스~ 28 | 29 | ## 3-3. 제한된 디스패처 생성하기. 30 | 뭐가 제한됨? 스레드! 31 | 스레드 수 32 | 33 | - 싱글 스레드 디스패처 만들기 34 | ```kotlin 35 | val dispatcher: CoroutineDispatcher = newSingleThreadContext( 36 | name = "SingleThread" 37 | ) 38 | ``` 39 | - 멀티 스레드 디스패처 만들기 40 | ```kotlin 41 | val multiThreadDispatcher: CoroutineDispatcher = newFixedThreadPoolContext( 42 | Threads = 2, 43 | name = "MultiThread" 44 | ) 45 | ``` 46 | - 싱글 스레드 디스패처 원형 까보면 이럼 47 | ```kotlin 48 | public fun newSingleThreadContext (name: String): CloseableCoroutineDispatcher = newFixedThreadPoolContext (1, name) 49 | ``` 50 | 51 | newFixedThreadPoolContext 까보면 Executor 써서 스레드풀을 만듦 52 | CoroutineDispatcher은 추상클래스임. 그래서 다양하게 구현될 수 있으므로 내부를 다 알아야할 필요는 x 53 | 54 | ## 3-4. CoroutineDispatcher 사용해 코루틴 실행하기 55 | 코루틴을 넣어 디스패처에 실행을 요청해보자 56 | #### launch의 파라미터로 CoroutineDispatcher 사용하기 57 | ```kotlin 58 | fun main() = runBlocking{ 59 | val dispatcher = newSingleThreadContext(name="SingleThread") 60 | 61 | launch(context = dispatcher){ 62 | println("[${Thread.currentTherad().name}] 실행") 63 | } 64 | } 65 | ``` 66 | - launch(dispatcher)로 해도 됨. 인자 받는게 어차피 하나라서..는 모르겠고 첫인자라서 67 | 68 | #### 멀티 스레드 디스패처 사용해서 코투린 실행하기 69 | 70 | ```kotlin 71 | fun main() = runBlocking{ 72 | val multiThreadDispatcher = newFixedThreadContext(nThreads =2, name="MultiThread") 73 | 74 | launch(context = multiThreadDispatcher){ 75 | println("[${Thread.currentTherad().name}] 실행") 76 | } 77 | launch(context = multiThreadDispatcher){ 78 | println("[${Thread.currentTherad().name}] 실행") 79 | } 80 | } 81 | ``` 82 | 83 | - 이렇게 하면 각각 다른 스레드에서 실행이 된다. 84 | - [MultiThread-1 @coroutine#2] 85 | - [MultiThread-2 @coroutine#3] 86 | 87 | #### 부모 코루틴의 CoroutineDispathcer 사용해 자식 코루틴 실행하기 88 | 구조화를 통해서 코루틴 내부에서 새로운 코루틴을 실행할 수 있음 89 | launch 안에 launch 90 | - 바깥쪽 코루틴 = Parent 코루틴 = 부모코루틴 91 | - 내부에서 생성되는 새로운 코루틴 = Child 코루틴 = 자식 코루틴 92 | 93 | 구조화 94 | 1. 코루틴을 계층관계로 만듦 95 | 2. 부모 코루틴의 실행 환경을 자식 코루틴에 전달하는데도 사용 96 | 3. 자식 코루틴에 dispatcher 객체를 따로 설정해주지 않았다면, 자동으로 부모 거를 사용한다. 97 | => 같은 코루틴 디스패처에서 여러개의 작업이 실행되기를 원한다면 활용하면 좋을 것 같다 98 | ## 3-5. 미리 정의된 CoroutineDispatcher. 99 | - 비효율성 100 | - 리소스 낭비 101 | => 위의 문제로 인해 미리 정의된 코루틴 디스패처를 사용한다. 102 | 103 | > - `Dispatchers.IO`: 네트워크요청이나 파일입출력등의 입출력(I/0) 작업을위한 CoroutineDispatcher 104 | > - `Dispatchers.Default`: CPU 를 많이 사용하는 연산 작업을위한 Coroutine Dispatcher 105 | > - `Dispatchers.Main`:메인스레드를 사용하기 위한 CoroutineDispatcher 106 | 107 | - 위 디스패처들은 그 자체로 싱글톤이다. 108 | - CPU 바운드 작업은 스레드나 코루틴이나 비슷하지만, **IO 작업의 경우, 코루틴이 월등히 빠르다** 109 | 110 | #### limitedParallelism으로 최대 사용 스레드 제한하기 111 | 만약, 너무 무거운 작업을 해버려서 스레드를 다 먹어버리면 어쩌나, 그런 사태를 막기 위해서 스레드 개수를 제한할 수 있다. 112 | Dispatchers.Default.limitedParallelism(2)하면 Dispatchers.Default의 전체 스레드가 아니라 딱 2개의 스레드만 해당 작업을 위해 사용하게 할 수 있다. 113 | 114 | - Dispatchers.IO.limitedParallelism는 스레드 개수 제한이 없음 115 | - 아예 Dispatchers.IO와 Dispatchers.Default와 상관없는 스레드풀을 만들어버리는것임 116 | #### 공유스레드풀을사용하는Dispatchers.IO와Dispatchers.Default 117 | 118 | Dispatchers.IO와 Dispatchers.Default는 같은 스레드풀을 사용한다. 119 | 사용하는 스레드는 구분되어 있지만, 스레드풀 자체는 같이 쓴다. 120 | #### Dispatchers.Main 121 | 122 | Dispatchers.Main은 메인스레드 혹은 UI스레드라서 참조는 가능하지만 사용할 수는 없다. 123 | 안드로이드 라이브러리를 사용하면 사용가능! 124 | 125 | -------------------------------------------------------------------------------- /코틀린 코루틴의 정석/4장 코루틴 빌더와 Job.md: -------------------------------------------------------------------------------- 1 | > 코루틴 빌더 함수 runBlocking, launch 2 | 3 | ==코루틴 빌더 함수의 반환은 Job 객체이다.== runBlocking, launch 이런 애들도 반환값은 job임. job으로 코루틴의 상태를 추적하고 제어하는데 사용한다., 4 | 5 | 코루틴은 일시중지하고 나중에 이어서 실행하는게 가능함. 6 | 7 | > job 객체를 이용해 코루틴 간 순차 처리하는 방법, 코루틴의 상태를 확인하고 조작하는 방법 8 | 9 | 10 | ## 4-1. join을 사용한 코루틴 순차 처리 11 | 12 | 코루틴을 각각 실행시키면 일반적으로 순차처리가 아니라 병렬처리가 되어버린다. 13 | 14 | ![[스크린샷 2024-11-26 오후 12.16.18.png]] 15 | 16 | 실행중이던 job에 join()을 붙인다. 그럼면 그게 다 되기 전까지 runBlocking 자체가 중지된다. (=뒤에 거가 실행되지 않는다) 17 | 18 | 19 | 호출순서가 중요함. join 보다 먼저 호출된건 실행되고, Join 다음에 온게 join 작업 다 되고 나서 실행되는 것임 20 | 21 | ## 4-2. joinAll을 사용한 코루틴 순차 처리 22 | 복수의 코루틴의 실행이 모두 끝날때까지 일시중지 23 | 24 | ![[스크린샷 2024-11-26 오후 2.30.51.png]] 25 | ## 4-3. CoroutineStart.LAZY사용해코루틴지연시작하기 26 | 코루틴은 지연시작이 가능하다 27 | 28 | ```kotlin 29 | fun main() = runBlocking{ 30 | val starttime = System.currentTimeMillis() 31 | val lazyJob: Job = launch(start=CoroutineStart.LAZY){ 32 | print("[${getElapsedTime(startTime)}] 지연실행") 33 | } 34 | delay(1000L) 35 | lazyJob().start() 36 | } 37 | ``` 38 | 39 | 1초 후 실행 40 | 41 | ## 4-4. 코루틴 취소하기 42 | 43 | `job.cancel()` 44 | 45 | 오래걸리는 작업을 실행했다가, 사용자가 명시적으로 취소를 한경우에는 코루틴 작업을 취소해야한다. 46 | 47 | 48 | `cancelAndJoin()` 49 | 50 | 을 쓰면, 취소가 완전히 다 되고 나서 그 다음 작업으로 넘어간다. 51 | 52 | 단순하게 `cancel()`은 취소 요청을 보내는거지, 완전히 취소 되었음을 의미하는게 아니다. = 즉시 취소되지 않는다. 53 | 54 | 코루틴이 취소를 확인하는 시점은 일반적으로 일시 중단지점 or 코루틴이 실행을 대기하는 시점임. 이 시점이 안온다면 취소는 실행되지 않음!! 55 | 56 | #### CoroutineScope.isActive를 통한 취소 확인 57 | 58 | ![[스크린샷 2024-11-28 오후 1.36.51.png]] 59 | 60 | 코루틴 상태 변수 61 | - isActive 62 | - isCancelled 63 | - isCompleted 64 | 65 | ![[스크린샷 2024-11-28 오후 1.40.12.png]] -------------------------------------------------------------------------------- /코틀린 코루틴의 정석/5장 async와 Deferred.md: -------------------------------------------------------------------------------- 1 | 2 | > 코루틴으로부터 결과가 필요할때 어찌해야하나? async를 쓰면 된다! 3 | 4 | ## 5-1. async 사용해 결괏값 수신하기 5 | `launch`의 반환값은 `job`이다 6 | **`async`의 반환값은 `Defferred`이며, 코루틴으로부터 결괏값을 수신할 수 있다** 7 | 8 | Deferred 9 | 아! 애초에 그냥 리턴값이 존재함. 제네릭 -> 리턴타입 지정 10 | 11 | > 비동기 자체는 값이 올수도 있음. 12 | > 순서를 보장하지 않음 13 | 14 | 15 | **결과값이 반환될 수 있음** 16 | 17 | 언제 반환될지 모름. 언제 실행이 완료될지 모름으로 18 | 19 | await 20 | - 해당 deferred가 실행완료 될 때까지 그 코루틴을 멈춤 21 | - 결과값이 반환되면 코루틴 재개 22 | 23 | 해당 job이 완료될때까지 해당 코루틴을 멈춘다는 의미에서 join이랑 비슷~ 24 | ## 5-2. Defferd는 특수한 형태의 Job이다. 25 | " 모든 코루틴 빌더는 Job 객체를 반환한다" 26 | 27 | ```kotlin 28 | interface Deferred : Job{ 29 | await(): T 30 | } 31 | ``` 32 | 33 | Job 인터페이스의 서브타입이여~ 예외는 없음 34 | 35 | Deferred는 Job의 모든 기능(함수, 프로퍼티)를 사용 할 수 있음 36 | join, cancelled, isActivce ... 이런것~ 37 | 38 | 39 | 40 | 41 | ## 5-3. 복수의 코루틴으로 결괏값 수신하기 42 | 43 | ㄷㄷㄷ await의 호출 시점에 따라 순차가 될 수도, 동시에 처리될 수도 있음 44 | 45 | - 순차 처리 46 | ```kotlin 47 | package chapter5.code3 48 | 49 | import kotlinx.coroutines.* 50 | 51 | fun main() = runBlocking { 52 | val startTime = System.currentTimeMillis() // 1. 시작 시간 기록 53 | val participantDeferred1: Deferred> = async(Dispatchers.IO) { // 2. 플랫폼1에서 등록한 관람객 목록을 가져오는 코루틴 54 | delay(1000L) 55 | return@async arrayOf("James","Jason") 56 | } 57 | val participants1 = participantDeferred1.await() // 3. 결과가 수신 될 때까지 대기 58 | 59 | val participantDeferred2: Deferred> = async(Dispatchers.IO) { // 4. 플랫폼2에서 등록한 관람객 목록을 가져오는 코루틴 60 | delay(1000L) 61 | return@async arrayOf("Jenny") 62 | } 63 | val participants2 = participantDeferred2.await() // 5. 결과가 수신 될 때까지 대기 64 | 65 | println("[${getElapsedTime(startTime)}] 참여자 목록: ${listOf(*participants1, *participants2)}") // 6. 지난 시간 표시 및 참여자 목록을 병합해 출력 66 | } 67 | /* 68 | // 결과: 69 | [지난 시간: 2018ms] 참여자 목록: [James, Jason, Jenny] 70 | */ 71 | 72 | fun getElapsedTime(startTime: Long): String = "지난 시간: ${System.currentTimeMillis() - startTime}ms" 73 | ``` 74 | 75 | 76 | - 병렬 처리 77 | ```kotlin 78 | package chapter5.code4 79 | 80 | import kotlinx.coroutines.* 81 | 82 | fun main() = runBlocking { 83 | val startTime = System.currentTimeMillis() // 1. 시작 시간 기록 84 | val participantDeferred1: Deferred> = async(Dispatchers.IO) { // 2. 플랫폼1에서 등록한 관람객 목록을 가져오는 코루틴 85 | delay(1000L) 86 | return@async arrayOf("James","Jason") 87 | } 88 | 89 | val participantDeferred2: Deferred> = async(Dispatchers.IO) { // 3. 플랫폼2에서 등록한 관람객 목록을 가져오는 코루틴 90 | delay(1000L) 91 | return@async arrayOf("Jenny") 92 | } 93 | 94 | val participants1 = participantDeferred1.await() // 4. 결과가 수신 될 때까지 대기 95 | val participants2 = participantDeferred2.await() // 5. 결과가 수신 될 때까지 대기 96 | 97 | println("[${getElapsedTime(startTime)}] 참여자 목록: ${listOf(*participants1, *participants2)}") // 6. 지난 시간 기록 및 참여자 목록 병합 98 | } 99 | /* 100 | // 결과: 101 | [지난 시간: 1018ms] 참여자 목록: [James, Jason, Jenny] 102 | */ 103 | 104 | fun getElapsedTime(startTime: Long): String = "지난 시간: ${System.currentTimeMillis() - startTime}ms" 105 | ``` 106 | 107 | 108 | awaitAll -> 병렬처리를 한번에 109 | 110 | 111 | `val results: List = awaitAl1(participantDeferred1, participantDeferred2)` 112 | 113 | ## 5-4. withContext 114 | 115 | withContext로 async-await를 대체한다 116 | deferred 객체를 만들지 않고 바로 반환 -> 메모리 절약..? 가독성? 117 | output은 비슷하지만, 내부 구현은 완전 다르다 118 | 119 | - async-await: 새로운 코루틴을 생성해서 작업을 처리 -> 얘도 동기..? 120 | - withContext: 실행 중이던 코루틴을 그대로 유지한채 코루틴의 실행환경(coroutineContext? 코루틴의 실행 스레드?)만 변경해 작업을 처리 -> 동기적으로 처리 121 | - context만 변경해서 코루틴을 실행 -> 코루틴이 실행하는 스레드를 변경할 수 있음.. 둘다 맞는 말 122 | 123 | 124 | 주의점 125 | withContext는 새로운 코루틴을 만들지 않기 때문에???? 126 | **하나의 코루틴에서 withContext가 여러번 호출되면, 순차적으로 실행된다** 127 | 128 | 즉, 복수의 독립적인 작업이 병렬로 실행되는 상황에서 쓰면 안된다 129 | 130 | 131 | ```kotlin 132 | package chapter5.code11 133 | 134 | import kotlinx.coroutines.* 135 | 136 | fun main() = runBlocking { 137 | val startTime = System.currentTimeMillis() 138 | val helloString = withContext(Dispatchers.IO) { 139 | delay(1000L) 140 | return@withContext "Hello" 141 | } 142 | 143 | val worldString = withContext(Dispatchers.IO) { 144 | delay(1000L) 145 | return@withContext "World" 146 | } 147 | 148 | println("[${getElapsedTime(startTime)}] ${helloString} ${worldString}") 149 | } 150 | /* 151 | // 결과: 152 | [지난 시간: 2018ms] Hello World 153 | */ 154 | 155 | 156 | fun getElapsedTime(startTime: Long): String = "지난 시간: ${System.currentTimeMillis() - startTime}ms" 157 | ``` 158 | 159 | 위의 경우에는 병렬적으로 실행되는걸 기대했지만 각각 실행되기 때문에 2초가 걸린다 160 | => 새로운 코루틴을 생성하지 않기 때문에 생기는문제임 161 | 162 | 163 | runBlocking 함수에서 생기는 코루틴 하나만 생성되고, 쓰임. 164 | 그 한 코루틴에서 스레드만 바꿔가며 실행한다. 165 | 166 | 167 | > 그래서 바꾸려면 168 | > async-await로 바꾸고, await 하는 시점을, 각 코루틴이 다 실행시작을 하고 난 뒤에 하면 된다 169 | 170 | ```kotlin 171 | package chapter5.code12 172 | 173 | import kotlinx.coroutines.* 174 | 175 | fun main() = runBlocking { 176 | val startTime = System.currentTimeMillis() 177 | val helloDeferred = async(Dispatchers.IO) { 178 | delay(1000L) 179 | return@async "Hello" 180 | } 181 | 182 | val worldDeferred = async(Dispatchers.IO) { 183 | delay(1000L) 184 | return@async "World" 185 | } 186 | 187 | val results = awaitAll(helloDeferred,worldDeferred) 188 | 189 | println("[${getElapsedTime(startTime)}] ${results[0]} ${results[1]}") 190 | } 191 | /* 192 | // 결과: 193 | [지난 시간: 1013ms] Hello World 194 | */ 195 | 196 | fun getElapsedTime(startTime: Long): String = "지난 시간: ${System.currentTimeMillis() - startTime}ms" 197 | ``` -------------------------------------------------------------------------------- /코틀린 코루틴의 정석/6장 CoroutineContext.md: -------------------------------------------------------------------------------- 1 | context 자리에 CoroutineName이랑 CoroutineDispatcher을 썼었음. 얘네가 CoroutinceContext 구성요소다 2 | 3 | ---- 4 | > 이전에, Context가 뭔지 부터 알아보자 5 | > https://charlezz.com/?p=1080 6 | > 안드로이드에서 context는 **애플리케이션 환경에 대한 전역적인 정보**이다. 구현은 안드로이드 시스템에 의해 제공되는 추상클래스. 7 | > context를 이용함으로써 시스템 레벨의 정보를 얻을 수 있는 메소드를 쓸 수 있음 8 | > activity context는 application context를 상속받음. 9 | > 대부분의 UI 작업은 activity context를 이용. (application context로 호출하면 에러남) 10 | 11 | 12 | ==CoroutineContext = 코루틴의 실행 환경을 설정한다.== 13 | 14 | - 구성요소 15 | 1. CoroutineName 16 | 2. CoroutineDispatcher 17 | 3. Job 18 | 4. CoroutineExceptionHandler 19 | 20 | 21 | 각 구성요소가 key-값으로 구성됨. 22 | 동일한 키에 중복값 허용x 23 | 24 | - 대입 25 | 근데 키로 대입하는게 아니라 + 연산자를 씀. 26 | 조합하는 느낌. 27 | 동일키에 또 추가되면 나중에 추가된게 덮어씌워짐. 28 | 29 | 바꿀려면 다시 + 하면됨 30 | 31 | --- 32 | - 구성요소에 접근하려면 고유한 키가 필요하다. 33 | `.Key` 34 | 35 | `[coroutineName]`이나 `[coroutineName.Key]`로 하면 구성요소 중 coroutineName에 대한 정보를 가져올 수 있다. 36 | 37 | 38 | - 제거하기 39 | `minusKey()` coroutineContext에서 해당요소만 제거되어서 된다. 40 | -> 유의할 점: CoroutineContext 객체가 그대로 유지되고, **해당 요소가 제거된 새로운 CoroutineContext 객체가 반환됨!!** 그래서 이전 객체에는 남아있음. 새로 반환 객체를 써야함. 41 | 42 | 43 | 44 | 45 | -------------------------------------------------------------------------------- /코틀린 코루틴의 정석/7장 구조화된 동시성.md: -------------------------------------------------------------------------------- 1 | > 비동기 작업을 구조화함으로써 비동기프로그래밍을 보다 안정적이고 예측할 수 있게 만드는 원칙 2 | 3 | 코루틴을 부모-자식 관계로 구조화함 -> 보다 안전하게 관리되고 제어될 수 있음 4 | 5 | 쏘 간단. 6 | 부모 코루틴 안에서 자식 코루틴을 호출하면 됨 7 | 8 | ```kotlin 9 | fun main() = runBlocking{ 10 | launch{ 11 | launch{ 12 | } 13 | } 14 | } 15 | ``` 16 | - runBlocking : 부모 17 | - 바깥쪽 launch 18 | - 안쪽 launch : 자식 19 | 20 | 21 | 22 | 특징 23 | - 부모 코루틴의 실행환경이 자식 코루틴에게 상속된다. 24 | - 작업을 제어하는데 사용 25 | - 부모코루틴이 취소되면 자식도 취소 26 | - 부모코투린은 자식 코루틴이 다 실행될때까지 대기한다 27 | - CoroutineScope를 사용해서 코루틴이 실행되는 범위를 제한 할 수 있다. 28 | 29 | ## 7-1. 실행환경 상속 30 | 31 | 부모 코루틴은 자식 코루틴에게 실행환경을 상속함 32 | 33 | 부모코루틴의 CoroutineContext가 상속됨 34 | 35 | 36 | 항상 모든 실행환경을 상속하는 것은 아님. 예외가 존재한다 37 | 38 | 다른게 전달 받으면 덮어씌워진다 39 | 40 | 41 | 42 | ```kotlin 43 | package chapter7.code3 44 | 45 | import kotlinx.coroutines.* 46 | 47 | fun main() = runBlocking { 48 | val coroutineContext = newSingleThreadContext("MyThread") + CoroutineName("ParentCoroutine") 49 | launch(coroutineContext){ // 부모 코루틴 생성 50 | println("[${Thread.currentThread().name}] 부모 코루틴 실행") 51 | launch(CoroutineName("ChildCoroutine")) { // 자식 코루틴 생성 52 | println("[${Thread.currentThread().name}] 자식 코루틴 실행") 53 | } 54 | }} 55 | /* 56 | // 결과: 57 | [MyThread @ParentCoroutine#2] 부모 코루틴 실행 58 | [MyThread @ChildCoroutine#3] 자식 코루틴 실행 59 | */ 60 | ``` 61 | 62 | 같은 CoroutineDispatcher, CoroutineName은 다름 63 | 64 | > CoroutineContext는 기본적으로 상속이 되며, 덮어 씌울 수도 있음. 하지만 Job은 상속되지 않는다. 65 | 66 | 모든 코루틴 빌더함수는 호출할때마다 코루틴 추상체인 Job 객체를 생성한다. 67 | Job으로 제어를 하는데, 얘를 상속으로써 받게 되면 각각의 코루틴을 제어하기가 힘들기 때문에 새로 생성한다. 68 | 69 | 다른 Job인거 까지 OK 70 | 근데 그러면 아예 연관이 없나? 71 | 72 | 73 | 아니다. parent와 children으로 역할을 가지며 구조화된다. 74 | 75 | ![[스크린샷 2024-12-12 오전 11.25.56.png]]![[스크린샷 2024-12-12 오전 11.27.07.png]] 76 | 77 | 78 | ### == 과 === 과 equals 79 | 80 | JAVA 81 | 1. == (주소값 비교 . 두 피연산자의 주소값이 같은 곳을 가리키고 있다면 `true`) 82 | 2. equals (참조값 비교) 83 | 3. === 가 없음 84 | 85 | ```java 86 | String a = "hi" // 주소값 : 1번지 87 | String b = "hi" // 주소값 : 2번지 88 | 89 | System.out.println(a==b) // false 90 | ``` 91 | 92 | 따라서 자바에서는 두 객체(참조 타입)의 동등성을 알기 위해서 `equals`를 호출해야 한다. 93 | 94 | ``` 95 | String a = "hi" // 주소값 : 1번지 96 | String b = "hi" // 주소값 : 2번지 97 | 98 | System.out.println(a.equals(b)) // true 99 | ``` 100 | 101 | Kotlin 102 | 103 | >1. == (값 비교 자바의 equals랑 같음) 104 | >2. === (주소 비교. 자바의 == 과 같음) 105 | >3. equals 106 | ```kotlin 107 | String a = "hi" // 주소값 : 1번지 108 | String b = "hi" // 주소값 : 2번지 109 | 110 | System.out.println(a==b) // true 111 | ``` 112 | 113 | 114 | https://wooooooak.github.io/kotlin/2019/02/24/kotiln_%EB%8F%99%EB%93%B1%EC%84%B1%EC%97%B0%EC%82%B0/ 115 | 116 | --- 117 | 118 | 다시 코루틴으로 돌아가자면, 119 | - 코루틴은 하나의 부모 코루틴만을 가질 수 있음. 120 | - 루트 코루틴은 부모가 없는 최상위임. parent가 null 121 | - 자식 코루틴은 여러개 가능 122 | ![[스크린샷 2024-12-12 오후 1.28.19.png]] 123 | 124 | ## 7-2. 코루틴의 구조화와 작업 제어 125 | 126 | 구조화된 코루틴의 특성 127 | 1. 코루틴으로 취소가 요청되면 자식 코루틴으로 전파된다 128 | 2. 부모 코루틴은 모든 자식 코루틴이 실행 완료돼야 완료할 수 있다. 129 | 130 | --- 131 | 1. 취소의 전파 132 | 자식코루틴한테 취소를 전파함. 133 | 그래서 부모 취소되면 자식도 취소됨 134 | 그러는 이유는? 135 | - 자식 코루틴이 부모 코루린 작업의 일부이기 때문 136 | --- 137 | 2. 부모 코루틴은 모든 자식 코루틴이 실행 완료되야 완료 될 수 있다. 138 | 작은 작업이 완료가 되야 큰 작업을 할 수 있기 때문 139 | => 부모 코루틴이 자식 코루틴에 대해 완료 의존성을 가진다 140 | 141 | 부모 코루틴이 마지막 코드를 실행하고 나서 더이상 실행할 코드가 없음에도 자식 코루틴이 완료되는 시점까지 완료될 수 없다. 142 | 143 | => 부모가 자기꺼 다 실행하고서, 자식 코루틴을 기다리고 있는 상태를 "실행 완료 중"이라고 한다. 144 | 145 | "실행 완료 중"인 부모 Job의 상태값? 146 | - isActive >> true 147 | - isCancelled >> false 148 | - isCompleted >> false 149 | 150 | 정리: 실행 완료 중이랑 실행 중은 완전히 같은 상태여서 구분 없이 사용한다. 151 | 152 | 153 | ## 7-3. CoroutineScope 사용해 코루틴 관리하기 p216-256 154 | 155 | CoroutineScope = CoroutineContext를 가진 인터페이스 156 | 157 | ```kotlin 158 | public interface CoroutineScope { 159 | public val coroutineContext: CoroutineContext 160 | } 161 | ``` 162 | 163 | ```kotlin 164 | class CustomCoroutineScope : CoroutineScope { 165 | override val coroutineContext: CoroutineContext = Job() + 166 | newSingleThreadContext("CustomScopeThread") 167 | } 168 | ``` 169 | 170 | CoroutineContext를 인자로 받아서 CoroutineScope 객체를 생성함 171 | 172 | 173 | CoroutineScope(Dispatchers.IO)를 호출하면 Dispatcher.IO랑 새로운 Job을 CoroutineContext로 가지는 CoroutineScope 객체가 반환되는 것임. = 새 Job~ 174 | 175 | launch를 까보면 176 | CoroutineScope.launch 임 그래서 launch에서 this가 가능한거는 CoroutineScope가 수신 객체 이기 때문이다. 177 | 178 | launch 뿐만 아니라 runBlocking, async 다 CoroutineScope를 람다식의 수신 객체로 제공 => 코루틴의 실행환경이 상속됨 179 | 180 | 181 | this가 생략 가능하므로 그냥 launch~ async~ 쓸 수 있는 것임 182 | 183 | ```kotlin 184 | fun main() = runBlocking { //나머지는 다 같은 scope launch(CoroutineName("Coroutine1")) { 185 | launch(CoroutineName("Coroutine3")) { 186 | println("[${Thread.currentThread().name}] 코루틴 실행") 187 | } 188 | CoroutineScope(Dispatchers.IO).launch(CoroutineName("Coroutine4")) { 189 | println("[${Thread.currentThread().name}] 코루틴 실행") 190 | } 191 | } 192 | launch(CoroutineName("Coroutine2")) { 193 | println("[${Thread.currentThread().name}] 코루틴 실행") 194 | } 195 | } 196 | ``` 197 | 198 | 하나만 다른 scope 사용하게 하기 199 | CoroutineScope를 생성하면 새로운 Job객체가 생성됨. 200 | 새로운 Job에 의해서 새로운 계층 구조를 만들게 됨 -------------------------------------------------------------------------------- /코틀린 코루틴의 정석/README.md: -------------------------------------------------------------------------------- 1 |

2 | 표지 3 |

4 | 5 | - 위 책을 완독하는 것으로 목표합니다. 6 | - 다소 추상적일 수 있는 코루틴을 완벽히 이해하고 의심 없이 사용하는 것을 목표로 합니다. 7 | --------------------------------------------------------------------------------