BEZZANG DEV

생성형 시대의 개발자: AI 의존성을 이기고 핵심 역량을 지키는 법

bezzang_kim — Fri, 26 Dec 2025 23:49:55 +0900

*이 글은 Gemini 3.0 pro Deep Research로 작성된 문서입니다.

프롬포트

'안다'의 착각 (Illusion of Competence)은 책이나 블로그를 보고 고개를 끄덕인 것을 '내 것이 되었다'고 착각하는 현상입니다.
위 현상과 더불어 학습을 잘하는 사람들의 특징, 습관들을 조사해주고, 개발자에게 특히 필요한 습관을 조사해주세요.

'안다'의 착각과 엔지니어링 마스터리: 인지과학적 분석 및 개발자 학습 전략 심층 보고서

1. 서론: 인지적 유창성과 능력의 괴리

현대 지식 노동자, 특히 소프트웨어 엔지니어에게 있어 학습은 일회성 이벤트가 아닌 생존을 위한 상시적 프로세스이다. 그러나 학습의 과정에는 치명적인 인지적 함정이 존재한다. 학습자가 텍스트를 읽거나 강의를 들으며 내용을 이해했다고 느끼지만, 실제로는 정보를 기억해 내거나 응용할 수 없는 상태, 즉 '안다'의 착각(Illusion of Competence) 현상이다. 이 보고서는 인지심리학적 관점에서 이 현상의 메커니즘을 분석하고, 학습 효율성이 높은 고성능 학습자(High-Performing Learners)들의 보편적 특징을 규명하며, 나아가 급변하는 기술 환경 속에 놓인 개발자들이 실질적 마스터리를 획득하기 위해 갖춰야 할 구체적이고 전문적인 학습 습관과 전략을 총체적으로 제시한다.

1.1 '안다'의 착각(Illusion of Competence)의 정의와 메커니즘

'안다'의 착각은 메타인지(Metacognition)의 오류에서 기인한다. 메타인지는 자신의 사고 과정에 대해 인지하는 능력으로, 내가 무엇을 알고 무엇을 모르는지를 판단하는 기능을 수행한다. 그러나 인간의 뇌는 정보처리의 효율성을 위해 유창성 휴리스틱(Fluency Heuristic)을 사용한다. 즉, 정보가 뇌에서 빠르고 부드럽게 처리될수록, 뇌는 그 정보를 '잘 알고 있다'고 착각하게 된다.1

예를 들어, 개발자가 기술 블로그나 유튜브 튜토리얼을 볼 때, 강사의 논리적 흐름을 따라가는 것은 인지적으로 큰 저항 없이 이루어진다. 이때 뇌는 외부의 정보(강사의 설명)가 자신의 내부 지식 구조와 결합되었다고 착각한다. 연구에 따르면, 텍스트를 단순히 반복해서 읽는 행위(Passive Reading)는 기억의 강화에는 거의 기여하지 않지만, 학습자의 자신감은 비약적으로 상승시킨다.1 이는 정보의 친숙함(Familiarity)을 지식의 습득(Mastery)으로 오인하는 전형적인 현상이다.

이 현상은 특히 '인출(Retrieval)' 과정의 부재에서 발생한다. 정보를 입력받는 것과 그 정보를 필요할 때 꺼내는 것은 전혀 다른 신경학적 경로를 사용한다. 남에게 설명하지 못한다는 것은 정보가 단기 기억이나 작업 기억(Working Memory) 수준에만 머물러 있고, 장기 기억(Long-term Memory)의 스키마(Schema)로 통합되지 않았음을 의미한다.2 소프트웨어 개발 교육에서 이는 학생들이 튜토리얼을 따라 할 때는 완벽하게 코드를 작성하지만, 빈 에디터 앞에서는 한 줄도 작성하지 못하는 현상으로 빈번하게 나타난다.

1.2 연구의 목적 및 범위

본 보고서는 단순히 학습 이론을 나열하는 것을 넘어, 실제 엔지니어링 필드에서 발생하는 인지적 오류를 수정하고 성과를 극대화할 수 있는 실천적 프레임워크를 제공하는 데 목적이 있다.

인지과학적 분석: 능동적 회상(Active Recall)과 수동적 복습의 차이를 분석한다.
고성능 학습자의 DNA: 성장 마인드셋(Growth Mindset), 딥 워크(Deep Work), 회복탄력성 등 탁월한 학습자들의 공통된 심리적, 행동적 특성을 조사한다.
개발자 특화 전략: 파인만 기법, 하브루타, 러버덕 디버깅, 코딩 카타(Kata), 아키텍처 결정 기록(ADR), 기술 레이더(Tech Radar) 등 개발자의 업무 흐름에 최적화된 학습 도구와 습관을 심층 분석한다.

2. 학습의 인지과학: 착각을 넘어 실체로

학습의 본질은 뇌의 신경 가소성(Neuroplasticity)을 이용하여 물리적인 신경망을 재구성하는 것이다. 이 과정은 필연적으로 인지적 부하(Cognitive Load)를 동반하며, '쉽게' 느껴지는 학습은 뇌가 변화하지 않고 있음을 시사한다.

2.1 수동적 반복 vs. 능동적 회상 (Active Recall)

학습 전략의 유효성을 비교한 다수의 실험 연구는 능동적 회상(Active Recall)이 수동적 반복 읽기보다 월등한 학습 효과를 가짐을 증명한다.1

비교 항목	수동적 학습 (Passive Review)	능동적 회상 (Active Recall)
주요 활동	책 다시 읽기, 강의 다시 듣기, 하이라이트 밑줄 긋기	셀프 테스트, 백지 복습, 남에게 가르치기, 코드 처음부터 다시 짜기
인지적 상태	편안함 (Comfort Zone). 뇌가 정보의 흐름에 편승함.	불편함 (Struggle). 뇌가 기억을 재구성하기 위해 에너지를 소모함.
메타인지 정확도	낮음. 친숙함을 앎으로 착각하여 과잉 확신 발생.	높음. 인출 실패를 즉시 경험하여 지식의 공백을 정확히 인지함.
장기 기억 효과	미미함. 단기 기억에 의존.	강력함. 인출 시도 자체가 기억 흔적(Memory Trace)을 강화함.
개발자 적용 예	튜토리얼 비디오를 2배속으로 시청하며 고개 끄덕이기.	튜토리얼 종료 후, 도움말 없이 기능을 재구현하며 에러와 싸우기.

연구 결과에 따르면, 반복적인 읽기는 학습자에게 "거짓된 친숙함(False sense of familiarity)"을 부여하여, 실제로는 이해하지 못했음에도 불구하고 이해했다고 믿게 만든다.1 반면, 능동적 회상은 학습자가 정보를 외부의 도움 없이 인출해내려고 시도하는 과정에서 신경 연결을 강화한다. Karpicke(2017)의 연구는 이러한 반복적인 인출 과정이 지식을 장기 기억으로 공고화할 뿐만 아니라, 지식의 전이(Transfer of Knowledge)를 촉진하여 학습자가 배운 내용을 새로운 상황에 적용할 수 있게 함을 보여준다.1

2.2 메타인지 환상과 AI 의존성

최근 생성형 AI(Artificial Intelligence)의 등장은 '안다'의 착각을 더욱 심화시키는 요인으로 작용하고 있다. ChatGPT나 Copilot이 생성해 준 코드를 보고 이해했다고 느끼는 현상은 전형적인 메타인지 환상(Metacognitive Illusion)이다.2 개발자는 AI가 제시한 해결책을 보고 "나도 이렇게 짤 수 있었다"고 생각하지만, 실제로는 그 해결책에 도달하기까지의 수많은 논리적 분기점과 트레이드오프를 고려하는 사고 과정을 생략한 것이다.

Ramzy 등의 연구(2025)는 AI 도구에 대한 과도한 의존이 '기술 감퇴(Skill Degradation)'를 초래할 수 있다고 경고한다. 인지적 노력을 AI에 외주화(Offloading)함으로써 기억력, 비판적 사고, 메타인지 인식, 창의성 등 인간의 핵심적인 인지 능력이 저하될 위험이 있다.4 이는 특히 학습 단계에 있는 주니어 개발자에게 치명적일 수 있으며, AI가 생성한 결과물의 오류를 검증할 수 있는 '감식안' 자체를 기르지 못하게 만든다.

2.3 유창성의 덫: 파레토 법칙의 적용

학습 효율성을 높이기 위해서는 파레토 법칙(80/20 법칙)을 적용하여, 전체 성과의 80%를 결정하는 핵심적인 20%의 개념을 깊이 있게 파고드는 전략이 필요하다.3 그러나 '안다'의 착각에 빠진 학습자는 모든 내용을 피상적으로 훑어보는 데 시간을 낭비하거나, 이미 알고 있는 쉬운 내용(유창하게 처리되는 내용)만을 반복하며 시간을 보낸다. 진정한 마스터리는 자신이 모르는 20%의 난해한 영역을 직면하고, 이를 능동적 회상을 통해 정복하는 과정에서 발생한다.

3. 고성능 학습자의 특징과 습관

학습을 잘하는 사람들, 소위 '고성능 학습자(High-Performing Learners)'들은 선천적인 지능보다 후천적인 습관과 태도에서 뚜렷한 차이를 보인다. 이들은 학습을 수동적인 정보 수용이 아닌, 적극적인 인지 재구성 과정으로 인식한다.

3.1 성장 마인드셋 (Growth Mindset)과 회복탄력성

스탠퍼드 대학의 캐롤 드웩(Carol Dweck) 교수가 제창한 성장 마인드셋은 고성능 학습자의 가장 핵심적인 심리 기제이다. 이는 지능이나 재능이 고정된 것이 아니라 노력과 학습을 통해 발전할 수 있다는 믿음이다.5

실패의 재해석: 고정 마인드셋(Fixed Mindset)을 가진 사람은 실패를 자신의 능력 부족을 증명하는 사건으로 받아들여 회피하려 한다. 반면, 성장 마인드셋을 가진 학습자는 실패를 학습을 위한 필수적인 피드백 데이터로 간주한다.6
도전의 수용: 고성능 학습자는 자신의 현재 능력보다 약간 높은 수준의 난이도(Desirable Difficulty)를 선호한다. 이들은 쉬운 성공보다 어려운 도전을 통해 얻는 배움을 가치 있게 여긴다.7
개발자를 위한 시사점: 디버깅 상황에서 이 마인드셋의 차이가 극명하게 드러난다. 성장 마인드셋을 가진 개발자는 버그를 "나의 무능함"이 아닌 "시스템에 대한 이해를 높일 기회"로 해석한다. "나는 이것을 못해"가 아니라 "나는 아직 이것을 해결하는 방법을 모를 뿐이야"라고 반응한다.8

3.2 딥 워크 (Deep Work)와 몰입의 의식

칼 뉴포트(Cal Newport)가 정의한 딥 워크는 인지적 능력을 한계까지 밀어붙이는 완전한 집중 상태에서의 활동을 의미한다.10 고성능 학습자들은 멀티태스킹이 학습의 적임을 인지하고, 환경을 통제하여 딥 워크 상태를 유도한다.

의식(Ritual)의 중요성: Atlassian의 디자인 리드 D. Keith Robinson의 사례는 딥 워크를 위한 구체적인 의식을 보여준다.10

셋업(Set Up): 모든 알림(이메일, 슬랙 등)을 끄고 고립된 공간을 확보한다.
멘탈 부팅(Mental Boot-Up): 뇌를 컴퓨터처럼 부팅한다고 상상하며 짧은 명상과 시각화를 수행한다. 잡념을 비우는 호흡 과정을 포함한다.
청각적 집중(Auditory Focus): 뇌파를 자극하는 특정 음악(앰비언트 노이즈 등)을 헤드폰으로 청취하여 집중 모드로의 진입을 돕는다.
종료 의식(Powering Down): 작업이 끝나면 명확한 종료 의식을 통해 뇌를 휴식 모드로 전환한다.

시간 블록킹: 하루 중 가장 집중력이 높은 시간대(주로 오전)를 '방해받지 않는 시간(Focus Blocks)'으로 설정하고, 이 시간에는 회의나 단순 업무를 배제한다.11

3.3 메타인지적 규제와 피드백 루프

고성능 학습자는 끊임없이 자신의 이해도를 점검한다. 그들은 "내가 무엇을 알고 있는가?"를 넘어 "내가 안다고 생각하는 것이 진짜인가?"를 질문한다.

피드백 추구: 이들은 자신의 결과물에 대해 비판적인 피드백을 적극적으로 요청한다.7 개발자의 경우, 코드 리뷰를 방어적으로 받아들이지 않고 자신의 코드를 개선할 기회로 활용한다.
자기 성찰(Reflection): 하루의 학습이나 업무가 끝난 후, 무엇을 배웠고 무엇이 부족했는지를 기록하고 복기하는 습관을 가진다.11

4. 개발자를 위한 특화 학습 전략: 튜토리얼 지옥 탈출하기

소프트웨어 엔지니어링은 추상적인 논리와 구체적인 구현이 끊임없이 교차하는 복잡한 도메인이다. 따라서 일반적인 학습법을 넘어선 개발자 특화 학습 전략이 필수적이다.

4.1 튜토리얼 지옥(Tutorial Hell)과 탈출 전략

'튜토리얼 지옥'은 초보 개발자가 튜토리얼을 따라 하면서 무언가를 만들 때는 성취감을 느끼지만, 스스로 무언가를 만들려 할 때는 아무것도 할 수 없는 상태를 일컫는다.12 이는 '안다'의 착각이 가장 강력하게 작용하는 구간이다.

탈출을 위한 프로젝트 기반 학습 (PBL) 전략

튜토리얼 지옥을 벗어나기 위해서는 '소비(Consumption)'에서 '생성(Creation)'으로 모드를 전환해야 한다.

즉각적인 미니 프로젝트: 배열(Array)을 배웠다면 즉시 연락처 목록 앱을 만들고, API를 배웠다면 날씨 앱을 만든다. 튜토리얼을 완강할 때까지 기다리지 않는다.12
의도적인 변형: 튜토리얼을 따라 하더라도, 강사가 제시한 기능을 그대로 구현하지 않고 의도적으로 기능을 변경하거나 추가한다. 예를 들어, 강사가 '할 일 목록'을 만든다면, 자신은 '쇼핑 목록'을 만들면서 데이터 구조를 약간 비틀어본다.
디버깅을 통한 학습: 스스로 프로젝트를 진행하며 마주치는 에러야말로 진짜 학습 재료다. 구글링과 스택오버플로우를 통해 문제를 해결하는 과정 자체가 개발자의 핵심 역량인 '문제 해결 능력'을 키운다.13

4.2 파인만 기법 (The Feynman Technique)과 설명 기반 학습

물리학자 리처드 파인만의 학습법은 복잡한 개념을 가장 단순한 언어로 설명하는 것이다. 이는 '설명할 수 없으면 이해한 것이 아니다'라는 명제에 기초한다.14

알고리즘:

개념 선택 (예: '클로저(Closure)'란 무엇인가?)
전공 지식이 없는 12세 아이에게 설명한다고 가정하고 단순한 언어로 설명하거나 글을 쓴다.14
설명하다 막히는 부분(Gap)을 식별한다. 이 부분이 바로 '안다'고 착각했던 지점이다.
자료를 다시 찾아보며 공백을 메우고, 더 쉬운 비유(Analogy)를 사용하여 설명을 다듬는다.14

개발자 적용: 기술 블로그를 작성하거나 팀 내에서 테크 토크(Tech Talk)를 진행하는 것이 가장 효과적이다. 특히 '비유'를 사용하는 것은 추상적인 컴퓨팅 개념(예: API를 식당의 웨이터에 비유)을 구체화하여 뇌의 장기 기억 소자에 단단히 고정시킨다.15

4.3 하브루타(Havruta)와 짝 프로그래밍(Pair Programming)

유대인의 전통 학습법인 하브루타는 두 사람이 짝을 지어 서로 질문하고 토론하며 진리를 탐구하는 방식이다.16 이는 현대 소프트웨어 개발의 짝 프로그래밍(Pair Programming)과 인지적으로 동일한 효과를 낸다.

인지적 외주화와 검증: 파트너에게 자신의 코드를 설명하는 과정에서 사고가 명료해지며, 파트너의 질문은 나의 논리적 허점을 찌르는 '검증 도구'가 된다.17
지식의 사회적 구성: 하브루타는 혼자서는 도달할 수 없는 깊이의 이해를 가능하게 한다. 비고츠키(Vygotsky)의 근접 발달 영역(ZPD) 이론처럼, 동료와의 상호작용은 개인의 인지적 한계를 확장시킨다.18
효과: 연구에 따르면 하브루타/짝 프로그래밍은 비판적 사고력과 창의성을 증진시키며, 코드의 결함을 줄이고 지식 전파를 가속화한다.18

4.4 러버덕 디버깅 (Rubber Duck Debugging)

러버덕 디버깅은 개발자가 막힌 코드나 버그를 책상 위의 고무 오리(또는 무생물)에게 한 줄 한 줄 설명하며 해결책을 찾는 기법이다.20

인지적 원리:

사고의 선형화(Linearization): 생각은 비선형적이고 추상적이지만, 언어는 선형적이고 구체적이다. 코드를 말로 설명하려면 뇌는 복잡한 맥락을 논리적인 순서로 재배열해야 하며, 이 과정에서 논리적 비약이나 오류가 드러난다.21
관점의 전환: 남(오리)에게 설명한다는 설정은 개발자를 자신의 코드에서 한 발짝 떨어져 객관적으로 바라보게 만든다(Psychological Distance).21
능동적 인출: 단순히 눈으로 코드를 읽는 것(수동적)과 달리, 입으로 설명하는 것은 뇌의 언어 중추(브로카 영역 등)를 활성화시켜 인지적 참여도를 높인다.22

5. 엔지니어링 마스터리를 위한 심화 습관

초급 단계를 넘어 시니어, 스태프 엔지니어로 성장하기 위해서는 코드 작성 그 이상의 학습 습관이 요구된다. 기술의 변화 속도를 따라잡으면서도 깊이를 잃지 않는 전략이 필요하다.

5.1 의도적 연습(Deliberate Practice): 코딩 카타(Coding Kata)

무술에서 '카타(품새)'를 반복하듯, 개발자도 특정 프로그래밍 패턴이나 리팩토링 기법을 반복적으로 연습해야 한다.23

정의: 코딩 카타는 해답을 찾는 것이 목적이 아니라, 해답에 이르는 과정을 숙달하는 것이 목적이다. 같은 문제(예: 문자열 계산기)를 매일 아침 20분씩, 다른 제약 조건(if문 쓰지 않기, 마우스 쓰지 않기 등)을 걸고 반복한다.24
효과:
- 근육 기억(Muscle Memory): IDE 단축키와 언어의 문법이 무의식 수준에서 자동화되어, 실제 업무 시에는 비즈니스 로직에만 집중할 수 있게 한다.24
- TDD 체화: 테스트 주도 개발(Test-Driven Development) 사이클(Red-Green-Refactor)을 몸에 익히는 최적의 훈련법이다.25

5.2 코드 읽기의 힘 (Reading Code)

많은 개발자가 코드 작성(Writing)에만 집중하지만, 훌륭한 작가가 되기 위해 다독(Reading)이 필수적이듯, 훌륭한 개발자가 되기 위해서는 타인의 코드를 읽는 습관이 필수적이다.26

무엇을 읽을 것인가?

오픈소스 프로젝트: 검증된 대규모 오픈소스 프로젝트의 코드를 분석하며 아키텍처 패턴과 네이밍 컨벤션을 배운다.28
표준 라이브러리: 자신이 사용하는 언어의 내부 구현(예: Java의 ArrayList 소스)을 뜯어보며, 언어 설계자의 의도와 최적화 기법을 학습한다.29

어떻게 읽을 것인가? 단순히 훑어보는 것이 아니라, 디버거를 연결하여 실행 흐름을 추적하거나, 왜 이 시점에서 특정 디자인 패턴을 사용했는지 질문하며 읽어야 한다. 이는 '안다'의 착각을 깨고, 자신이 갇혀 있던 코딩 스타일의 우물에서 벗어나게 해 준다.30

5.3 아키텍처 결정 기록 (ADR)과 기술 부채의 관리

시니어 레벨로 갈수록 '무엇(What)'을 구현하느냐보다 '왜(Why)' 그렇게 결정했느냐가 중요해진다.

ADR (Architecture Decision Records): 소프트웨어 설계 결정의 맥락과 결과, 대안들을 문서화하는 것이다.31

학습 도구로서의 ADR: 과거의 ADR을 읽는 것은 해당 프로젝트의 역사와 제약 사항(Constraints)을 학습하는 가장 빠른 길이다. 이는 '체스터튼의 울타리(Chesterton's Fence)' 원칙과 연결되는데, 어떤 코드가 왜 존재하는지 알기 전에는 그것을 뜯어고치지 말아야 한다는 지혜를 배울 수 있다.32
작성하며 배우기: ADR을 직접 작성하면 자신의 결정에 대한 근거를 명확히 해야 하므로, 비판적 사고와 트레이드오프 분석 능력이 향상된다.33

5.4 기술 레이더(Tech Radar)와 전략적 무시

기술은 폭발적으로 쏟아지기 때문에 모든 것을 배울 수는 없다. 고성능 개발자는 '무엇을 배우지 않을 것인가'를 결정하는 전략을 가진다.

개인용 기술 레이더: ThoughtWorks의 기술 레이더 개념을 차용하여, 자신만의 기술 포트폴리오를 관리한다.34

Adopt (도입): 지금 당장 깊이 있게 학습하고 프로젝트에 사용할 기술.
Trial (시도): 토이 프로젝트 등을 통해 가능성을 타진해 볼 기술.
Assess (평가): 기술 블로그나 문서를 통해 개념만 파악해 둘 기술.
Hold (보류): 아직 성숙하지 않았거나 자신의 커리어 방향과 맞지 않아 학습을 미룰 기술.

FOMO 극복: 이 전략은 최신 기술을 다 알아야 한다는 강박(FOMO)에서 벗어나, 자신의 리소스를 전략적으로 배분하게 해 준다.35

6. 지식 관리 시스템: 제2의 뇌 (Second Brain) 구축

학습한 내용을 잊어버리지 않고 연결하기 위해 외부 메모리 시스템을 활용해야 한다.

6.1 제텔카스텐 (Zettelkasten)

독일의 사회학자 니클라스 루만(Niklas Luhmann)이 사용한 메모 상자 기법으로, 정보의 '저장'이 아닌 '연결'에 초점을 맞춘다.36

개발자를 위한 워크플로우:

임시 메모(Fleeting Notes): 코딩 중 마주친 에러 해결법, 번뜩이는 아이디어를 빠르게 기록한다.
문헌 메모(Literature Notes): 기술 블로그나 책을 읽고, 그 내용을 자신만의 언어로 요약한다. 복사-붙여넣기는 금물이다. 이는 '안다'의 착각을 방지하는 필터 역할을 한다.37
영구 메모(Permanent Notes): 문헌 메모를 바탕으로 하나의 독립된 아이디어를 정제하여 기록하고, 기존의 다른 메모들과 하이퍼링크로 연결한다. 예: "React의 Hook 개념" 메모를 "함수형 프로그래밍의 순수 함수" 메모와 연결.

효과: 이러한 연결 과정은 창의적인 아키텍처 설계의 원천이 되며, 단순한 지식 창고를 넘어 사고를 확장하는 파트너(Second Brain)가 된다.38

6.2 간격 반복 시스템 (Spaced Repetition System, SRS)

문법, 단축키, 명령어 등 암기가 필요한 지식(Declarative Knowledge)은 망각 곡선을 극복해야 한다.

Anki 활용: 앙키(Anki)와 같은 SRS 도구를 사용하여 카드를 만든다.

앞면: "Git에서 직전 커밋 메시지를 수정하는 명령어는?"
뒷면: git commit --amend

효율성: SRS 알고리즘은 사용자가 잊어버리기 직전의 타이밍에 복습을 유도하여, 최소한의 시간 투자로 장기 기억 전환을 극대화한다.39 개발자는 이를 통해 문법을 검색하는 시간을 줄이고, 문제 해결이라는 고차원적 사고에 집중할 수 있는 '몰입(Flow)' 상태를 유지할 수 있다.40

7. 결론: 마스터리는 목적지가 아닌 습관이다

'안다'의 착각은 인간 뇌의 자연스러운 편향이다. 이를 극복하고 진정한 마스터리로 나아가는 길은 편안한 수동적 학습을 거부하고, 불편하고 고통스러운 능동적 학습을 선택하는 데 있다.

본 보고서의 핵심 요약 및 제언:

인지적 겸손: 자신이 모른다는 사실을 인정하는 것에서 시작하라. 설명할 수 없다면 모르는 것이다.
생성적 학습: 소비자가 되지 말고 생산자가 되어라. 튜토리얼을 보는 대신 프로젝트를 만들고, 블로그를 쓰고, 코드를 가르쳐라.
피드백 루프의 단축: 에러, 버그, 동료의 리뷰를 두려워하지 말고 성장의 자양분으로 삼아라(Growth Mindset).
시스템 구축: 의지력에 의존하지 말고, 딥 워크 의식, 코딩 카타, 제텔카스텐, 기술 레이더와 같은 시스템을 구축하여 학습을 자동화하라.
협업적 진화: 짝 프로그래밍, 코드 리뷰, ADR 작성을 통해 개인의 지식을 팀의 지성으로 확장하라.

소프트웨어 개발자에게 있어 학습 능력은 코딩 능력보다 상위의 메타 스킬이다. 위에서 제시된 습관들을 하나씩 내재화함으로써, 개발자는 기술의 파도에 휩쓸리지 않고 그 파도를 타고 넘는 전문가로 성장할 수 있을 것이다.

References Used:

참고 자료

Retrieval practice enhances learning in real primary ... - Frontiers, 12월 26, 2025에 액세스, https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2025.1632206/full
(PDF) Metacognitive illusion or self-regulated learning? Assessing engineering students' learning strategies against the backdrop of recent advances in cognitive science - ResearchGate, 12월 26, 2025에 액세스, https://www.researchgate.net/publication/344830664_Metacognitive_illusion_or_self-regulated_learning_Assessing_engineering_students'_learning_strategies_against_the_backdrop_of_recent_advances_in_cognitive_science
Beyond Content: Leveraging AI and Metacognitive Strategies for Transformative Learning in Higher Education - The Transnational Journal of Business, 12월 26, 2025에 액세스, https://acbspjournal.org/2025/06/01/beyond-content-leveraging-ai-and-metacognitive-strategies-for-transformative-learning-in-higher-education/
Illusion of Competence and Skill Degradation in Artificial Intelligence Dependency among Users - International Journal of Research and Scientific Innovation (IJRSI), 12월 26, 2025에 액세스, https://rsisinternational.org/journals/ijrsi/articles/illusion-of-competence-and-skill-degradation-in-artificial-intelligence-dependency-among-users/
A High-Performance Mindset - Great Place To Work - Kenya, 12월 26, 2025에 액세스, https://www.greatplacetowork.co.ke/en/resources/blog/a-high-performance-mindset
How to Build a Growth Mindset for Continuous Learning in Coding - AlgoCademy Blog, 12월 26, 2025에 액세스, https://algocademy.com/blog/how-to-build-a-growth-mindset-for-continuous-learning-in-coding/
Unlock Success: Transform Your Habits for Personal and Professional Growth, 12월 26, 2025에 액세스, https://rdltraining.com/personal-development/unlock-success-transform-your-habits-for-personal-and-professional-growth/
A Software Engineer's Guide to Self-Esteem and Growth Mindset - Entelect, 12월 26, 2025에 액세스, https://culture.entelect.co.nz/education/a-software-engineers-guide-to-self-esteem-and-growth-mindset/
DHO is Mostly Confused - Debugging: Psychology, Theory, and Application - 9vx.org, 12월 26, 2025에 액세스, https://9vx.org/post/debugging-psychology-theory-and-application/
Deep Work: Experiments, tips and lessons learned | by D. Keith ..., 12월 26, 2025에 액세스, https://medium.com/designing-atlassian/deep-work-3cd27b5fd0f9
The 7 Habits of High-Earning Low-Stress High-Achievers - ProActive Psychology, 12월 26, 2025에 액세스, https://www.proactivepsychology.com.au/high-earning-low-stress-high-achievers/
How To Get Out of Tutorial Hell in 2025 (Step-by-Step) - Snappify, 12월 26, 2025에 액세스, https://snappify.com/blog/how-to-get-out-of-tutorial-hell
Escaping Tutorial Hell: A Roadmap to Becoming a Productive Software Engineer - Medium, 12월 26, 2025에 액세스, https://medium.com/@jatinbisht2308/escaping-tutorial-hell-a-roadmap-to-becoming-a-productive-software-engineer-25ca4de5c64a
(PDF) Feynman Technique as a Heutagogical Learning Strategy for Independent and Remote Learning - ResearchGate, 12월 26, 2025에 액세스, https://www.researchgate.net/publication/358237141_Feynman_Technique_as_a_Heutagogical_Learning_Strategy_for_Independent_and_Remote_Learning
Feynman Technique as a Heutagogical Learning Strategy for Independent and Remote Learning - Recoletos Multidisciplinary Research Journal, 12월 26, 2025에 액세스, https://rmrj.usjr.edu.ph/rmrj/index.php/RMRJ/article/download/958/243/5090
ED482366 - Havruta Study: History, Benefits, and Enhancements. Notes from ATID., 2003, 12월 26, 2025에 액세스, https://eric.ed.gov/?id=ED482366
Journal of Jewish Education A Theory of Havruta Learning - Brandeis ScholarWorks, 12월 26, 2025에 액세스, https://scholarworks.brandeis.edu/view/pdfCoverPage?instCode=01BRAND_INST&filePid=13463156850001921&download=true
A Meta-Analysis of Cognitive and Affective Outcomes of Havruta Learning - ResearchGate, 12월 26, 2025에 액세스, https://www.researchgate.net/publication/367209477_A_Meta-Analysis_of_Cognitive_and_Affective_Outcomes_of_Havruta_Learning
Pair Programming: Pros and Cons of Collaborative Coding - PremierAgile, 12월 26, 2025에 액세스, https://premieragile.com/pair-programming-pros-cons/
TIL of a form of debugging called rubber duck debugging, where you debug code by explaining it. The name is in reference to the book "The Pragmatic Programmer" where a programmer would debug code by explaining it, word by word, to his rubber duck. : r/todayilearned - Reddit, 12월 26, 2025에 액세스, https://www.reddit.com/r/todayilearned/comments/8o0kko/til_of_a_form_of_debugging_called_rubber_duck/
Rubber Duck Debugging: The Simplest Developer Tool You Are Not Using Enough, 12월 26, 2025에 액세스, https://www.joshfinnie.com/blog/rubber-duck-debugging/
Robot Duck Debugging: Can Attentive Listening Improve Problem Solving? - ResearchGate, 12월 26, 2025에 액세스, https://www.researchgate.net/publication/374552881_Robot_Duck_Debugging_Can_Attentive_Listening_Improve_Problem_Solving
7 Best Coding Kata Sites in 2025 (Ranked by a Daily Practitioner) - AlgoCademy Blog, 12월 26, 2025에 액세스, https://algocademy.com/blog/7-best-coding-kata-sites-in-2025-ranked-by-a-daily-practitioner/
The Discipline of Daily Katas: A Developer's Guide to Building Mastery Through Consistent Practice - Engineering Blog, 12월 26, 2025에 액세스, https://engineering.brighthr.com/blog-post/daily-practice
Using coding katas to improve skills - Grade Builder - Living Courses for life and career, 12월 26, 2025에 액세스, https://gradebuilder.tech/using-coding-katas-to-improve-skills/
What Makes Reading Code More Important Than Writing? - CodeEasy, 12월 26, 2025에 액세스, https://codeeasy.io/blog/what-makes-reading-code-more-important-than-writing
Ask HN: Does reading code actually make you a better developer? - Hacker News, 12월 26, 2025에 액세스, https://news.ycombinator.com/item?id=13992063
How do you read/understand the source code of a big/medium project? - Reddit, 12월 26, 2025에 액세스, https://www.reddit.com/r/learnprogramming/comments/1jiobs6/how_do_you_readunderstand_the_source_code_of_a/
Recommended Reading: The Architecture of Open Source Applications - Embedded Artistry, 12월 26, 2025에 액세스, https://embeddedartistry.com/blog/2017/10/09/recommended-reading-the-architecture-of-open-source-applications/
Why Reading Code Matters (and how to get better at it) - amymhaddad, 12월 26, 2025에 액세스, https://amymhaddad.com/why-reading-code-matters/
Architecture decision record (ADR) examples for software planning, IT leadership, and template documentation - GitHub, 12월 26, 2025에 액세스, https://github.com/joelparkerhenderson/architecture-decision-record
What are Architecture Decision Records (ADR) and what should you consider when making architectural decisions? : r/softwarearchitecture - Reddit, 12월 26, 2025에 액세스, https://www.reddit.com/r/softwarearchitecture/comments/1gz7wco/what_are_architecture_decision_records_adr_and/
Why you should be using architecture decision records to document your project - Red Hat, 12월 26, 2025에 액세스, https://www.redhat.com/en/blog/architecture-decision-records
Build Your Own Technology Radar. By Neal Ford | by Thoughtworks - Medium, 12월 26, 2025에 액세스, https://medium.com/featured-insights/build-your-own-technology-radar-27ef3c2e0bc2
How to create your enterprise technology radar | Thoughtworks United States, 12월 26, 2025에 액세스, https://www.thoughtworks.com/en-us/insights/blog/technology-strategy/how-to-create-your-enterprise-technology-radar
Knowledge Management for Software Engineers - Mayflower Blog, 12월 26, 2025에 액세스, https://blog.mayflower.de/14137-zettelkasten-knowledge-management.html
How to Increase Knowledge Productivity: Combine the Zettelkasten Method and Building a Second Brain, 12월 26, 2025에 액세스, https://zettelkasten.de/posts/building-a-second-brain-and-zettelkasten/
A Developer's Second Brain on Plaintext | by Junji Zhi | Gusto Engineering, 12월 26, 2025에 액세스, https://engineering.gusto.com/a-developers-second-brain-on-plaintext-ac96492eff2e
Spaced Repetition for Efficient Learning - Gwern.net, 12월 26, 2025에 액세스, https://gwern.net/spaced-repetition
How to use spaced repetition with Anki to learn to code faster - Medium, 12월 26, 2025에 액세스, https://medium.com/free-code-camp/use-spaced-repetition-with-anki-to-learn-to-code-faster-7c334d448c3c
How Anki Saved My Engineering Career - freeCodeCamp, 12월 26, 2025에 액세스, https://www.freecodecamp.org/news/how-anki-saved-my-engineering-career-293a90f70a73/

[PS] 백준 9367 관리 난항 Java 풀이 (+ 25%에서 계속 틀린 이유, Java의 정수와 소수의 차이)

bezzang_kim — Sat, 2 Aug 2025 17:22:11 +0900

https://www.acmicpc.net/problem/9367

오랜만에 글을 쓰네요. 정말 어이가 없게 푼 문제가 있는데, 이게 풀이법이 널린 문제가 아니라서 이렇게 공유하고자 글을 작성합니다.

25%에서 계속 틀리길래

Gemini Pro 2.5와 머리를 맞대고 대체 논리적으로 틀린 부분이 없는데 왜 틀렸을까... 찾아봤는데

수리비 계산하는 부분에서 문제가 있었습니다.

double damageCost = (double) (car.price * severity) / 100;

double damageCost = car.price * (severity / 100.0);

위 두 코드의 차이인데요, 위에가 정답이고 아래가 틀린 답이었습니다.

왜냐하면 문제 설명이 영어에서 한국어로 번역되면서 누락된 부분이 있었습니다.

백분율 단위로 해야하기 때문에 100.0을 사용하면 안 됐습니다.

하지만 저 두 코드의 연산 값의 차이는 어떻게 생기게 될까요? 그 이유는 아래에서 설명하겠습니다.

풀이 방법

자동차 정보에 대한 class를 만들고 Map <"차 이름", 자동차 정보 class> 형태로 저장
첩보원의 렌탈 상태를 저장하는 class를 만들고, TreeMap<"첩보원 이름", 렌탈 상태 class> 형태로 저장 (이름을 사전순으로 정렬하기 위함)
'p'의 경우, 이미 렌탈 중인 경우 비일관성
'r'의 경우, 빌린 차가 없는데 반납하면 비일관성
'a'의 경우, 빌린 차가 없는데 사고내면 비일관성
위 경우를 다 따졌는데 아직 렌탈중인 경우 비일관성
결과 출력

코드

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.util.*;

public class Main {

    // 자동차 정보를 저장하는 클래스
    static class Car {
        int price, initialFee, kmFee;
        Car(int p, int q, int k) {
            this.price = p;
            this.initialFee = q;
            this.kmFee = k;
        }
    }

    // 첩보원의 현재 렌탈 상태를 저장하는 클래스
    static class SpyState {
        boolean isRenting = false;
        String carName;
        int totalCost = 0;
        boolean inconsistent = false;

        void rent(String carName, int initialFee) {
            this.isRenting = true;
            this.carName = carName;
            this.totalCost += initialFee;
        }

        void processReturn(int distance, int kmFee) {
            this.isRenting = false;
            this.carName = null;
            this.totalCost += distance * kmFee;
        }

        void processAccident(double damageCost) {
            // 수리비는 올림 처리
            this.totalCost += Math.ceil(damageCost);
        }
    }

    public static void main(String[] args) throws Exception {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int testCases = Integer.parseInt(br.readLine().trim()); // 테스트 케이스 수 읽기

        StringBuilder finalOutput = new StringBuilder();

        for (int t = 0; t < testCases; t++) {
            StringTokenizer st = new StringTokenizer(br.readLine());
            int n = Integer.parseInt(st.nextToken()); // 자동차 종류 수
            int m = Integer.parseInt(st.nextToken()); // 사건 로그 수

            Map<String, Car> carInfos = new HashMap<>();
            for (int i = 0; i < n; i++) {
                st = new StringTokenizer(br.readLine());
                String carName = st.nextToken();
                int p = Integer.parseInt(st.nextToken());
                int q = Integer.parseInt(st.nextToken());
                int k = Integer.parseInt(st.nextToken());
                carInfos.put(carName, new Car(p, q, k));
            }

            // 첩보원 이름(String)을 키로, 첩보원의 상태(SpyState)를 값으로 저장
            Map<String, SpyState> spies = new TreeMap<>();

            for (int i = 0; i < m; i++) {
                st = new StringTokenizer(br.readLine());
                st.nextToken(); // 시간 정보는 이 문제의 논리에서는 사용되지 않음
                String spyName = st.nextToken();
                char eventType = st.nextToken().charAt(0);

                // 첩보원 정보가 없으면 새로 생성
                spies.putIfAbsent(spyName, new SpyState());
                SpyState currentSpy = spies.get(spyName);

                // 이미 비일관성으로 판명된 첩보원은 더 이상 처리하지 않음
                if (currentSpy.inconsistent) {
                    continue;
                }

                switch (eventType) {
                    case 'p': // Pick-up
                        String carName = st.nextToken();
                        // 이미 다른 차를 빌리고 있다면 비일관성
                        if (currentSpy.isRenting) {
                            currentSpy.inconsistent = true;
                        } else {
                            Car car = carInfos.get(carName);
                            currentSpy.rent(carName, car.initialFee);
                        }
                        break;

                    case 'r': // Return
                        int distance = Integer.parseInt(st.nextToken());
                        // 빌린 차가 없는데 반납하면 비일관성
                        if (!currentSpy.isRenting) {
                            currentSpy.inconsistent = true;
                        } else {
                            Car car = carInfos.get(currentSpy.carName);
                            currentSpy.processReturn(distance, car.kmFee);
                        }
                        break;

                    case 'a': // Accident
                        int severity = Integer.parseInt(st.nextToken());
                        // 빌린 차가 없는데 사고를 내면 비일관성
                        if (!currentSpy.isRenting) {
                            currentSpy.inconsistent = true;
                        } else {
                            Car car = carInfos.get(currentSpy.carName);
                            // 수리비 = 원가 * (파손율 / 100)
                            double damageCost = (double) (car.price * severity) / 100;
                            currentSpy.processAccident(damageCost);
                        }
                        break;
                }
            }

            // 모든 이벤트를 처리한 후, 여전히 차를 빌리고 있는 첩보원은 비일관성
            for (SpyState spy : spies.values()) {
                if (spy.isRenting) {
                    spy.inconsistent = true;
                }
            }

            // 결과 출력
            for (Map.Entry<String, SpyState> entry : spies.entrySet()) {
                String spyName = entry.getKey();
                SpyState spyState = entry.getValue();

                finalOutput.append(spyName).append(" ");
                if (spyState.inconsistent) {
                    finalOutput.append("INCONSISTENT\n");
                } else {
                    finalOutput.append(spyState.totalCost).append("\n");
                }
            }
        }
        System.out.print(finalOutput);
    }
}

Java의 정수 연산과 부동 소수점 연산의 차이

정수(int)는 이진수로 직접 표현되며, 연산은 해당 범위 내에서 항상 정확하게 수행됩니다.

반면, 부동 소수점 숫자(double)는 IEEE 754 표준을 따릅니다. 이 표준에 따르면, 부동 소수점 숫자는 부호 비트, 지수, 가수(mantissa)의 세 부분으로 구성됩니다.

double 타입은 1비트의 부호, 11비트의 지수, 52비트의 가수를 사용하여 64비트로 표현됩니다.

이진 시스템에서 숫자를 저장하는 방식 때문에 모든 십진수 값을 정확하게 표현할 수 없으며, 이로 인해 작은 정밀도 오차가 발생할 수 있습니다.

십진수 소수를 이진수로 변환하는 기본 원리는 다음과 같습니다.

소수 부분에 2를 곱합니다.
곱셈 결과의 정수 부분(0 또는 1)을 기록합니다. 이 정수 부분이 이진수 소수점 아래 자리가 됩니다.
결과에서 정수 부분을 제외한 소수 부분에 다시 2를 곱합니다.
이 과정을 소수 부분이 0이 되거나, 필요한 정밀도에 도달할 때까지 반복합니다.
기록한 정수 부분들을 순서대로 나열하면 이진수 소수가 됩니다.

십진수 0.625를 이진수로 변환하는 과정을 단계별로 살펴보겠습니다.

단계 1: 0.625에 2를 곱하기

0.625 x 2 = 1.25

정수 부분: 1 (첫 번째 이진수 소수점 자리)
남은 소수 부분: 0.25

단계 2: 남은 0.25에 2를 곱하기

0.25 x 2 = 0.5

정수 부분: 0 (두 번째 이진수 소수점 자리)
남은 소수 부분: 0.5

단계 3: 남은 0.5에 2를 곱하기

0.5 x 2 = 1.0

정수 부분: 1 (세 번째 이진수 소수점 자리)
남은 소수 부분: 0.0

남은 소수 부분이 0이 되었으므로 변환 과정이 끝납니다.

기록된 정수 부분들을 위에서 아래 순서로 나열하면 1, 0, 1이 됩니다.

0.101(2)로 표현할 수 있겠습니다.

십진수 0.1은 이진수로 정확하게 표현할 수 없는 무한소수가 됩니다. 이 과정을 살펴보겠습니다.

단계 1: 0.1에 2를 곱하기

0.1 x 2 = 0.2

정수 부분: 0
남은 소수 부분: 0.2

단계 2: 남은 0.2에 2를 곱하기

0.2 x 2 = 0.4

정수 부분: 0
남은 소수 부분: 0.4

단계 3: 남은 0.4에 2를 곱하기

0.4 x 2 = 0.8

정수 부분: 0
남은 소수 부분: 0.8

단계 4: 남은 0.8에 2를 곱하기

0.8 x 2 = 1.6

정수 부분: 1
남은 소수 부분: 0.6

단계 5: 남은 0.6에 2를 곱하기

0.6 x 2 = 1.2

정수 부분: 1
남은 소수 부분: 0.2

단계 6: 남은 0.2에 2를 곱하기

0.2 x 2 = 0.4

정수 부분: 0
남은 소수 부분: 0.4

이 단계부터 0.2로 돌아와 2단계부터의 과정이 반복되는 것을 알 수 있습니다. 이처럼 소수 부분이 0이 되지 않고 계속해서 순환되므로, 십진수 0.1은 이진수로 무한소수가 됩니다.

기록된 정수 부분들을 순서대로 나열하면 0.0001100110011...(2)가 됩니다.

컴퓨터는 이 무한히 반복되는 소수를 유한한 비트 수(예: double의 경우 52비트의 가수)에 맞게 잘라내서 저장합니다. 이 과정에서 발생하는 아주 미세한 차이가 정밀도 오차의 원인이 됩니다.

public static void main(String[] args) throws Exception {
    double sum = 0.0;

    for (int i = 0; i < 10; i++) {
        sum += 0.1;
    }

    System.out.println("0.1을 10번 더한 결과: " + sum); // 출력: 0.9999999999999999
}

이 코드의 결과는 IEEE 754 표준을 따르는 double 타입의 한계를 보여줍니다. 위에서 언급했듯이, 십진수 0.1은 이진수로 정확히 표현될 수 없는 무한소수입니다.

Java의 JVM은 IEEE 754 표준의 반올림 규칙(가장 가까운 값으로 반올림)을 따르지만, 이는 근본적인 정밀도 문제를 해결하지는 못합니다. 0.1의 근사값을 10번 더하면, 각 연산 단계에서 미세한 오차가 누적되어 최종적으로 1.0이 아닌 0.9999999999999999라는, 육안으로는 구분하기 어려운 오차가 발생합니다.

이는 Java(및 일반적으로 컴퓨팅)의 설계로, 개발자는 애플리케이션의 요구 사항에 따라 필요한 정밀도를 고려하여 데이터 타입을 신중하게 선택해야 합니다.

다시 문제 상황으로 돌아가서,

double damageCost = (double) (car.price * severity) / 100;

double damageCost = car.price * (severity / 100.0);

두 표현식의 근본적인 차이는 나눗셈 연산이 부동 소수점 연산이 되는 시점에 있습니다.

표현식 1: (double) (car.price * severity) / 100;
- 나눗셈 / 100은 int / int로 수행되어 소수 부분이 잘립니다.
- 이후 (double) 캐스트는 이미 잘린 정수 결과에 적용됩니다.
표현식 2: car.price * (severity / 100.0);
- 나눗셈 / 100.0은 int / double (자동으로 double / double로 승격)로 수행되어 소수 부분이 처음부터 보존됩니다.

따라서 damageCost 값이 계속 연산이 될수록 소수 부분의 유무로 인해 값이 오차가 생기게 된 것이죠.

이후 문제 조건인 만일 소수점 이하의 어떤 비용이 발생한다면 그 비용은 청구서에 올라가기 전 올림하여 합산된다. 를 위해 소수 첫째 자리 올림 Math.ceil() 함수를 수행할 때, 값이 달라지게 된 것 이었습니다.

[Network] 소켓 식별 방식과 레이어 별 데이터 정보 (segment, datagram, packet, frame, payload, multiplexing, demultiplexing)

bezzang_kim — Fri, 6 Dec 2024 19:59:08 +0900

TCP/IP stack의 통신 과정

출처: https://adacomputerscience.org/concepts/internet_tcp_ip

Application 레이어: 데이터의 생성과 헤더 추가

브라우저에서 서버로 요청을 보낼 때, 데이터는 Application 레이어에서 생성됩니다. 이 레이어에서는 HTTP와 같은 어플리케이션 프로토콜을 사용하여 서버에 요청을 전달합니다.

데이터와 메시지: Application 레이어에서 송수신되는 데이터는 Data 또는 Message라고 부릅니다.
페이로드: Application 레이어의 데이터와 어플리케이션 헤더 부분을 합쳐 Payload라고 합니다. 이는 실제 데이터 전송 시 다른 계층에서도 동일하게 사용되는 개념입니다.

Transport 레이어: 데이터의 전달과 식별

데이터는 Application 레이어를 지나 Transport 레이어로 내려갑니다. 이 레이어는 프로세스 간의 통신을 관리하며, 데이터를 목적지 프로세스로 전달하는 역할을 합니다.

프로토콜: Transport 레이어에서는 주로 TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)를 사용합니다.
헤더 추가: Transport 레이어에서는 Transport 헤더가 추가되며, 이 헤더에는 송신자와 수신자의 포트 번호가 포함됩니다.
데이터 단위:
- TCP: 데이터를 세그먼트(Segment)라고 부릅니다.
- UDP: 데이터를 데이터그램(Datagram)이라고 부릅니다.

Internet 레이어: 호스트 간의 라우팅

Transport 레이어에서 처리된 데이터는 Internet 레이어로 전달됩니다. 이 레이어는 호스트 간의 데이터 전송과 라우팅을 담당합니다.

프로토콜: 주로 IP(Internet Protocol)를 사용하며, IPv4와 IPv6가 있습니다.
헤더 추가: Internet 레이어에서는 IP 헤더가 추가되며, 이는 IP 패킷(IP Packet) 또는 IP 데이터그램(IP Datagram)으로 불립니다.
IP 헤더 정보:
- 출발지 IP 주소와 목적지 IP 주소.
- 프로토콜 식별자: IPv4에서는 Protocol 필드에, IPv6에서는 Next Header 필드에 TCP는 6, UDP는 17이 저장됩니다.
페이로드: Transport 레이어와 Application 레이어의 헤더 및 데이터를 포함합니다.

Link 레이어: 물리적 전송과 프레임화

인터넷 레이어에서 처리된 데이터는 링크 레이어로 내려가 물리적 네트워크를 통해 전송됩니다.

데이터 단위: 링크 레이어에서는 데이터를 프레임(Frame)이라고 부릅니다.
헤더와 트레일러 추가: 링크 레이어에서는 헤더와 트레일러가 추가됩니다. 헤더에는 출발지와 목적지의 물리적 주소(MAC 주소 등)가 포함되며, 트레일러는 오류 검출을 위한 정보를 포함합니다.
동작 과정:
- 데이터는 프레임으로 캡슐화되어 네트워크를 통해 전송됩니다.
- 라우터는 프레임을 수신하고, IP 헤더를 확인하여 다음 목적지를 결정한 후 다시 프레임으로 캡슐화하여 전송을 이어갑니다.

라우터에서의 데이터 처리 과정

데이터가 라우터를 통과할 때, 다음과 같은 과정이 이루어집니다:

Link 레이어에서 프레임 수신: 라우터는 Link 레이어에서 프레임(Frame)을 수신합니다.
프레임 해제: 프레임의 헤더와 트레일러를 제거하고, IP 헤더와 페이로드를 추출합니다.
라우팅 테이블 확인: IP 헤더의 목적지 IP 주소를 기반으로 라우팅 테이블을 조회하여 다음 홉(next hop)을 결정합니다.
재캡슐화: 다음 홉으로 전송하기 위해 페이로드를 다시 프레임으로 캡슐화합니다.
다음 홉으로 전송: 결정된 경로를 따라 프레임을 전송합니다.

서버에서의 데이터 수신 과정

서버에 도착한 데이터는 다음과 같은 과정을 거쳐 처리됩니다:

Link 레이어에서 프레임 수신: 서버의 네트워크 인터페이스는 프레임을 수신합니다.
프레임 해제: 링크 레이어는 프레임의 헤더와 트레일러를 제거하고, IP 패킷을 추출합니다.
Internet 레이어 처리: IP 패킷의 헤더를 분석하여 Transport 레이어로 전달할 프로토콜(TCP/UDP)을 식별합니다.
Transport 레이어 처리:
- TCP: 세그먼트를 재조립하고, 연결 상태를 관리합니다.
- UDP: 데이터그램을 그대로 전달합니다.
디멀티플렉싱(Demultiplexing): 트랜스포트 레이어는 데이터의 목적지 포트 번호를 사용하여 적절한 소켓으로 데이터를 전달합니다.
- TCP의 경우:
  - 리스닝 소켓: 새로운 연결 요청(SYN 플래그가 설정된 세그먼트)이 들어오면 리스닝 소켓으로 전달합니다.
  - 기존 연결 소켓: 이미 연결된 세그먼트는 출발지 IP와 포트, 목적지 IP와 포트에 따라 해당 소켓으로 전달됩니다.
- UDP의 경우: 포트 번호를 기반으로 단순히 해당 포트로 전달됩니다.

멀티플렉싱과 디멀티플렉싱

멀티플렉싱(Multiplexing)

멀티플렉싱은 여러 개의 데이터 스트림을 하나의 통신 경로로 결합하는 과정을 말합니다. 예를 들어, 여러 개의 애플리케이션 프로세스가 동시에 네트워크를 통해 데이터를 송신할 때, Transport 레이어는 이 데이터를 하나의 네트워크 연결로 결합하여 전송합니다.

애플리케이션 레벨: 여러 애플리케이션이 데이터를 생성하고, 각각의 데이터는 포트 번호를 통해 식별됩니다.
Transport 레이어: 각 애플리케이션의 데이터를 포트 번호를 기준으로 분리하여 하나의 네트워크 연결로 전송합니다.

디멀티플렉싱(Demultiplexing)

디멀티플렉싱은 하나의 통신 경로로 들어온 데이터를 각 애플리케이션 프로세스로 분리하는 과정을 말합니다. 서버는 수신한 데이터 패킷을 분석하여, 해당 데이터가 어느 애플리케이션 프로세스로 전달되어야 하는지를 결정합니다.

인터넷 레이어: IP 패킷을 수신하고, Transport 레이어로 전달합니다.
트랜스포트 레이어: IP 헤더의 프로토콜 필드를 확인하여 TCP 또는 UDP를 결정하고, 포트 번호를 기반으로 해당 소켓으로 데이터를 전달합니다.

용어 정리 및 주의 사항

주요 용어

Packet: 일반적으로 인터넷을 통해 송수신되는 데이터의 단위로, 인터넷 레이어뿐만 아니라 다른 계층에서도 사용되는 범용적인 용어입니다.
Datagram: 주로 UDP와 관련된 용어로, UDP 데이터그램 또는 IP 데이터그램을 의미합니다. UDP는 연결 지향적이지 않기 때문에 데이터그램이라는 용어가 적합합니다.
Segment: TCP에서 사용하는 데이터 단위로, 연결 지향적이고 신뢰성을 보장하기 위해 세그먼트라는 용어를 사용합니다.
Frame: 링크 레이어에서 사용하는 데이터 단위로, 물리적 네트워크 전송을 위해 캡슐화된 데이터입니다.
Payload: 각 계층에서 실제 전송되는 데이터의 일부로, 상위 계층의 데이터와 헤더를 포함합니다.

용어 사용 시 주의 사항

Packet과 Datagram: 때로는 동일한 의미로 사용되기도 하지만, 정확히 구분할 필요가 있습니다. Packet은 일반적인 용어로, 다양한 계층에서 사용될 수 있으며, Datagram은 주로 UDP 또는 IP와 관련된 데이터 단위를 의미합니다.
Segment와 Datagram의 혼용: 일부 문서나 책에서는 TCP 세그먼트와 UDP 데이터그램을 편의상 모두 Datagram이라고 부르기도 합니다. 그러나 기술적으로는 다르므로 명확한 구분이 필요합니다.

소켓 식별 방식의 중요성

Transport 레이어에서 소켓을 식별하는 방식은 데이터의 정확한 전달을 보장하는 데 필수적입니다. 소켓은 IP 주소와 포트 번호의 조합으로 식별되며, 이를 통해 데이터가 올바른 애플리케이션 프로세스로 전달됩니다.

UDP의 소켓 식별: UDP는 단순히 포트 번호를 사용하여 소켓을 식별합니다. 데이터그램의 목적지 포트 번호를 확인하여 해당 포트로 데이터를 전달합니다.
TCP의 소켓 식별: TCP는 연결 지향적이기 때문에, 단순히 포트 번호뿐만 아니라 연결 상태도 고려해야 합니다. 새로운 연결 요청(SYN 플래그)이 들어오면 리스닝 소켓으로 전달하고, 기존 연결의 경우 출발지 IP와 포트, 목적지 IP와 포트를 기반으로 해당 소켓으로 데이터를 전달합니다.

참조

https://www.youtube.com/watch?v=eveNtda0_yk&t=1019s

[Network] 프로토콜과 OSI 7 layer, 그리고 네트워크의 기능들이 어떻게 구조화 돼서 동작하는지

bezzang_kim — Thu, 5 Dec 2024 21:23:52 +0900

네트워크의 개념과 기능

네트워크는 컴퓨터나 기타 기기들이 리소스를 공유하거나 데이터를 주고 받기 위해 유선 혹은 무선으로 연결된 통신 체계를 뜻합니다.

이 네트워크는 다양한 기능들이 있습니다.

네트워크는 애플리케이션 목적에 맞는 통신 방법을 제공합니다.
신뢰할 수 있는 데이터 전송 방법도 제공합니다.
네트워크 간의 최적의 통신 경로를 결정합니다.
결정된 경로를 바탕으로 목적지로 데이터를 전송합니다.
이 때 여러 노드들을 거치게 될텐데, 이 노드들도 네트워크가 결정합니다.

프로토콜

그런데 이런 네트워크 통신 기능들이 제대로 동작하기 위해서는 참여자들 사이에 약속된 통신 방법이 있어야 합니다. 왜냐하면 상대방과 나 사이에서 이루어지기 때문입니다. 만약 내가 한국어로 말을 하고 상대가 영어로 말한다면, 대화가 되지 않을 것 입니다.

프로토콜이란 네트워크 통신을 하기 위해 통신에 참여하는 주체들이 따라야 하는 형식, 절차, 규약을 말합니다.

OSI model (7 layer)과 TCP/IP stack (4 layer)의 등장

하지만 이 네트워크가 해주는 모든 기능을 단 하나의 프로토콜로는 구현할 수 없습니다. 이는 마치 백엔드 애플리케이션을 한 클래스에 모두 구현하겠다와 같습니다. 이러면 유지보수도 힘들어지고 새 기능 추가도 어려워집니다. 따라서 이를 모듈화해야 합니다.

그럼 어떻게 모듈화 하느냐 하니, 네트워크의 기능들이 뭔가 계층 별로 구분할 수 있을 것 같습니다.

따라서 나온게 OSI Model (7 layer)와 TCP/IP stack (4 layer) 입니다.

OSI 7 Layer

https://github.com/gyoogle/tech-interview-for-developer/blob/master/Computer%20Science/Network/OSI%207%20%EA%B3%84%EC%B8%B5.md#osi-7-%EA%B3%84%EC%B8%B5

각 레이어에 맞게 프로토콜이 세분화돼서 구현됩니다.

각 레이어의 프로토콜은 하위 레이어의 프로토콜이 제공하는 기능을 사용하여 동작합니다.

예를 들어 Network Layer는 Data link Layer가 제공하는 기능을 사용해서 자신의 기능을 구현합니다.

각 레이어 별 담당하는 기능은 이렇습니다.

Application layer: 애플리케이션 목적에 맞는 통신 방법을 제공합니다. HTTP(웹 페이지를 보여줄 때), DNS,SMTP(이메일), FTP(파일 전송)가 있습니다.
Presentation layer: 애플리케이션간의 통신에서 메시지 포맷 관리, 인코딩과 디코딩, 암호화와 복호화, 압축과 압축 풀기가 있습니다.
Session layer: 애플리케이션 간의 통신에서 세션을 관리, RPC(remote procedure call)
Transport layer: 애플리케이션 간의 통신을 담당, 실제로 목적지 애플리케이션으로 어떻게 데이터를 전송할지 구현합니다.
안정적이고 신뢰할 수 있는 데이터 전송 보장 -> TCP
신뢰성은 떨어지나, 필수 기능만 제공 -> UDP
Network Layer:호스트 간의 통신 담당 -> IP 프로토콜, 목적지 호스트로 데이터 전송, 네트워크 간의 최적의 경로 결정
Data Link Layer: 직접 연결된 노드 간의 통신을 담당합니다, MAC 주소 기반 통신 (ARP)
Physical Layer: 물리적 신호, 케이블과 같은 장치를 통해 bits 단위로 데이터를 전송합니다.

OSI 7 Layer의 통신 예제: 유튜브 댓글이 유튜브 서버까지 가기까지

1. 사용자 → 애플리케이션 계층 (Application Layer)

댓글 작성 및 전송: 사용자가 유튜브 웹사이트나 앱에서 댓글을 작성하고 전송 버튼을 누릅니다.
HTTP 요청 생성: 애플리케이션 계층에서 HTTP/HTTPS 프로토콜을 사용하여 댓글 데이터(내용, 작성자 정보 등)를 HTTP POST 요청으로 패키징합니다.
리버스 프록시 처리: 요청은 유튜브의 리버스 프록시 서버(Nginx, HAProxy 등)를 거쳐 들어옵니다. 리버스 프록시는 요청을 적절한 내부 서버로 분배하고, SSL 종료(HTTPS 암호화 해제)를 수행할 수 있습니다.

2. 세션/트랜스포트 계층 (Session/Transport Layer)

세션 설정: TLS/SSL을 통해 클라이언트와 유튜브 서버 간의 보안 세션이 설정됩니다.
TCP 연결 설정: 트랜스포트 계층에서는 TCP 프로토콜을 사용하여 신뢰성 있는 데이터 전송을 보장합니다. 3-way 핸드셰이크(연결 설정)를 통해 출발지와 목적지 포트가 설정됩니다.

3. 네트워크 계층 (Network Layer)

IP 라우팅: 클라이언트의 IP 주소와 유튜브 서버의 IP 주소를 기반으로 패킷이 전달될 최적의 경로가 설정됩니다.
CDN 활용: 유튜브는 전 세계에 분산된 CDN(콘텐츠 전송 네트워크) 노드를 사용합니다. 사용자의 요청은 지리적으로 가까운 CDN 노드로 라우팅되어 대기 시간을 줄이고 부하를 분산시킵니다.
패킷 헤더 추가: 출발지와 목적지의 IP 주소가 데이터 패킷에 추가됩니다.

4. 데이터 링크 계층 (Data Link Layer)

ARP 요청: 네트워크 계층에서 목적지 IP 주소를 기반으로 물리적 주소(MAC 주소)를 알아내기 위해 ARP(Address Resolution Protocol) 요청이 발생합니다.
프레임 생성: 데이터는 프레임으로 변환되고, 출발지와 목적지의 MAC 주소가 프레임 헤더에 추가됩니다.
에러 검출: CRC(Cyclic Redundancy Check)와 같은 에러 검출 정보가 프레임에 포함됩니다.

5. 물리 계층 (Physical Layer)

비트 전송: 데이터 프레임이 전기 신호, 광 신호 또는 무선 신호 등 물리 매체를 통해 전송됩니다.
매체 전송: 유선(이더넷 케이블) 또는 무선(Wi-Fi, LTE 등)을 통해 데이터가 전송됩니다.

6. 라우터 → 목적지 전달

라우팅 처리: 데이터는 여러 라우터를 거치며 목적지 IP를 확인하고 다음 경로로 전송됩니다. 각 라우터는 네트워크, 데이터 링크, 물리 계층을 통해 패킷을 처리합니다.
CDN 노드 처리: CDN 노드에서 요청이 유튜브의 리버스 프록시 서버로 전달됩니다.

7. 서버 → 애플리케이션 복구

리버스 프록시에서 내부 서버로 전달: 리버스 프록시 서버는 요청을 내부 유튜브 애플리케이션 서버로 전달합니다.
각 계층 헤더 제거 및 데이터 복구: 서버는 각 OSI 계층에서 헤더를 제거하고 원래의 HTTP 요청 데이터를 복구합니다.
댓글 처리 및 데이터베이스 저장: 유튜브 애플리케이션 서버는 댓글 데이터를 처리하고, 데이터베이스에 저장합니다.
응답 생성 및 반환: 서버는 댓글이 성공적으로 저장되었음을 알리는 HTTP 응답을 생성하여 클라이언트로 반환합니다. 이 응답 역시 위의 과정을 거쳐 사용자에게 도달합니다.

TCP/IP Stack과 비교

인터넷 구조에 특화된 Layered 아키텍처이며 아래와 같은 구조를 가집니다.

이미지 출처: https://www.guru99.com/images/1/093019_0615_TCPIPModelW1.png

Application layer는 Osi 7 layer에서 application, presentation, session을 포함하고

Network interface (link 계층이라고도 함)은 physical, data link, network layer를 통합한 것으로 볼 수 있습니다.

참조

https://www.youtube.com/watch?v=6l7xP7AnB64&t=155s

[PS] 백준 오아시스 재결합 Java 풀이 (+모노톤 스택에 관하여)

bezzang_kim — Thu, 28 Nov 2024 23:37:29 +0900

https://www.acmicpc.net/problem/3015

모노톤 스택

모노톤 스택은 스택의 요소가 오름차순 또는 내림차순으로 유지되도록 설계된 특수한 스택입니다. 이는 특정 조건을 만족하는 요소를 효율적으로 처리하거나 빠르게 접근해야 할 때 사용됩니다.

오름차순 스택: 스택에 쌓인 값이 항상 작아지지 않도록 유지.
내림차순 스택: 스택에 쌓인 값이 항상 커지지 않도록 유지.

모노톤 스택은 일반적으로 배열이나 리스트의 각 요소와 관련된 "가장 가까운 큰 값" 또는 "가장 가까운 작은 값"을 찾는 문제에 사용됩니다. O(N)의 시간 복잡도로 해결할 수 있어 효율적입니다.

문제 접근

이 문제 또한 모노톤 스택을 사용하여 해결할 수 있습니다.

먼저 서로를 볼 수 있는 조건을 생각해 봅시다.

두 사람이 서로 볼 수 있으려면 두 사람 사이에 둘 중 더 큰 사람보다 키가 큰 사람이 없어야 합니다.
따라서, 각 사람은 자신보다 키가 작은 사람들만 볼 수 있습니다.

여기서 우리는 스택을 현재까지 처리된 사람들의 키를 저장하고, 내림차순으로 정렬할 것입니다.

새로운 사람이 들어오면, 키가 작거나 같은 사람들을 처리하고 스택에서 제거합니다.

예를 들어 2 4 1 2 2 5 1 의 경우 처리 과정은,

첫 번째 사람(2): 스택에 추가 → 스택 상태: [2(1명)]
두 번째 사람(4): 스택 비움, 1명 볼 수 있음 → 스택 상태: [4(1명)]
세 번째 사람(1): 스택에 추가 → 스택 상태: [4(1명), 1(1명)]
네 번째 사람(2): 스택 비움, 1명 볼 수 있음 → 스택 상태: [4(1명), 2(1명)]
다섯 번째 사람(2): 같은 키 누적 → 스택 상태: [4(1명), 2(2명)]
여섯 번째 사람(5): 스택 비움, 3명 볼 수 있음 → 스택 상태: [5(1명)]
일곱 번째 사람(1): 스택에 추가 → 스택 상태: [5(1명), 1(1명)]

따라서 최종 출력은 10입니다.

특히 같은 키의 사람을 누적해야 합니다.

이를 위해 아래 Node 클래스를 정의합니다.

static class Node {
    int height; // 사람의 키
    long count; // 해당 키를 가진 사람의 수

    public Node(int height, long count) {
        this.height = height;
        this.count = count;
    }
}

사람의 키에 따른 count 값을 누적시키는 이유는 누적하지 않으면 같은 키를 가진 사람들 간의 쌍이나 새로운 사람과의 쌍을 제대로 계산하지 못해 정답이 틀리게 됩니다.

스택 처리 코드는 다음과 같습니다.

long count = 1;
// 스택에서 현재 키보다 작거나 같은 키를 처리
while (!stack.isEmpty() && stack.peek().height <= currentHeight) {
    Node node = stack.pop();
    answer += node.count; // 스택의 사람들은 현재 사람과 서로 볼 수 있음
    if (node.height == currentHeight) {
        count += node.count; // 같은 키의 사람 수를 누적
    }
    if (!stack.isEmpty()) answer += 1; // 스택이 비어있지 않으면 가장 큰 키인 사람과 쌍이므로 + 1
    stack.push(new Node(current, count));
}

새 키가 들어오면, 스택의 맨 위에 있는 사람들과 비교:
- 새 키보다 작거나 같은 키들은 새 키와 볼 수 있는 관계를 형성합니다.
- 키가 같다면, 같은 키를 가진 사람들의 개수를 누적 처리합니다.
새 키보다 큰 키가 나오면:
- 새 키는 스택에 추가되며, 다음 비교를 위해 유지됩니다.
스택이 비어 있지 않으면:
- 새 키는 스택 맨 위 사람과도 볼 수 있습니다.

위 로직을 모든 요소들에 대해 수행하면 됩니다.

참고로, 정답 값의 타입은 Long 이어야 합니다.

코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.*;

public class Main {

    static class Node {
        int height;
        long count;
    
        public Node(int height, long count) {
            this.height = height;
            this.count = count;
        }
    }

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int n = Integer.parseInt(br.readLine());

        int[] arr = new int[n];
        for (int i = 0; i < n; i++) {
            arr[i] = Integer.parseInt(br.readLine());
        }

        Stack<Node> stack = new Stack<>();
        long answer = 0;
        for (int current : arr) {
            long count = 1;
            while (!stack.isEmpty() && stack.peek().height <= current) {
                Node prev = stack.pop();
                answer += prev.count;
                if (prev.height == current) count += prev.count;
            }
            if (!stack.isEmpty()) answer += 1;
            stack.push(new Node(current, count));
        }
        System.out.println(answer);

    }
}