컴퓨터공학 300 주제 시리즈의 300번째 글이다. 전체 지도는 여기.

한 줄 요약

개발자의 성장은 지식을 쌓는 일, 그 지식을 실제 문제에 써 보는 일, 그리고 결과에 책임지는 일의 반복이다. 300개 주제는 지도일 뿐이고, 길은 직접 걸어야 생긴다.

왜 필요한가

이 시리즈는 수학적 기초에서 시작해 자료구조, 운영체제, 네트워크, 데이터베이스, 보안, AI 를 지나 사람과 사회에서 끝났다. 순서에는 이유가 있다. 기술은 결국 사람이 쓰고, 사람에게 영향을 준다.

그런데 300개 글을 다 읽었다고 개발자가 되지는 않는다. 읽은 것은 금방 잊힌다. 기술은 빨리 바뀐다. 이 시리즈에 나온 도구 중 일부는 몇 년 뒤 다른 것으로 대체될 것이다. 그래서 마지막 글은 특정 기술이 아니라, 계속 배우고 일하는 방법에 대한 이야기다.

핵심 개념

변하는 것과 변하지 않는 것

잘 변하지 않는 것 빨리 변하는 것
자료구조와 알고리즘의 복잡도 프레임워크와 라이브러리
운영체제의 프로세스·메모리·파일 개념 클라우드 서비스 이름과 가격
네트워크 계층과 프로토콜의 원리 배포 도구와 설정 문법
트랜잭션과 일관성 유행하는 아키텍처 용어
보안의 기본 원칙 특정 취약점과 패치
사람의 인지 특성 UI 트렌드

왼쪽을 탄탄히 하면 오른쪽을 배우는 속도가 빨라진다. 새 데이터베이스가 나와도 “이건 어떤 일관성 모델이지? 인덱스는 어떤 자료구조지?”라고 물을 수 있기 때문이다. ACM·IEEE-CS·AAAI 가 함께 만든 컴퓨터과학 교육과정 CS2023 과 소프트웨어 공학 지식 체계 SWEBOK 이 시대가 바뀌어도 기초 영역을 유지하는 이유다. 이 시리즈의 파트 구성도 CS2023 의 지식 영역을 참고했다.

T자형 역량

넓게 아는 가로축과 깊게 아는 세로축이다.

  넓이: 네트워크  DB  보안  OS  프런트엔드  ML  운영 ...
  ──────────────────────────────────────────────
                      │
                      │  깊이: 한두 분야는
                      │  "왜 그렇게 동작하는지"를
                      │  소스와 명세 수준까지
                      │

넓이는 문제를 올바른 곳으로 보내는 능력이다. “이건 DB 락 문제 같다”, “이건 DNS 캐시 문제 같다”라고 짐작할 수 있어야 한다. 깊이는 그 문제를 끝까지 푸는 능력이다. 처음에는 깊이 하나를 만들고, 그다음 넓히는 순서가 대체로 효과적이다.

의도적 연습

Ericsson 외(1993)는 전문가의 수행 능력이 단순한 경험 시간보다 “의도적 연습(deliberate practice)”과 관련이 있다고 주장했다. 의도적 연습의 특징은 이렇다.

  • 현재 실력보다 약간 어려운, 구체적인 목표
  • 즉각적인 피드백
  • 약점을 겨냥한 반복

개발에 옮기면 이렇다.

그냥 경험 의도적 연습
같은 종류의 CRUD 를 계속 만든다 매번 하나씩 낯선 것을 넣는다(캐시, 큐, 다른 DB)
코드 리뷰를 형식적으로 받는다 리뷰 댓글에서 반복되는 지적을 모아 고친다
장애가 나면 고치고 잊는다 회고를 쓰고, 같은 범주의 문제를 다시 공부한다
튜토리얼을 따라 친다 튜토리얼을 덮고 처음부터 다시 만든다

기억에 남기는 법: 간격 반복과 인출

읽기만 하면 아는 것 같은 착각이 생긴다. 학습 연구는 두 가지 방법이 기억에 효과적이라고 보고한다.

  • 간격 반복(spaced repetition): 한 번에 몰아서 보는 것보다 간격을 두고 여러 번 보는 것이 오래 남는다(Cepeda 외, 2006 의 메타분석).
  • 인출 연습(retrieval practice): 다시 읽는 것보다 떠올려 보는 것(문제 풀기, 설명하기)이 효과적이다.

이 시리즈의 모든 글 끝에 확인 문제가 있는 이유다. 답을 보기 전에 먼저 떠올려 보는 것이 공부다.

만들고, 공개하고, 설명하기

  • 만들기: 작은 것이라도 끝까지 만든다. 배포하고, 모니터링하고, 고장 나면 고친다. 홈랩 k3s 클러스터 같은 개인 환경은 실패해도 되는 연습장이다. 운영체제·네트워크·보안 글에서 본 개념이 실제로 어떻게 드러나는지 손으로 확인할 수 있다.
  • 공개하기: 코드와 글을 공개하면 피드백이 생긴다. 오픈소스 기여는 다른 사람의 코드를 읽고, 리뷰를 받고, 협업 규칙을 익히는 좋은 방법이다. 작은 문서 수정부터 시작해도 된다.
  • 설명하기: 블로그 글, 사내 발표, 동료에게 설명하기. 설명하다 막히는 곳이 내가 모르는 곳이다.

전문가의 책임

ACM 과 IEEE-CS 가 함께 만든 소프트웨어 공학 윤리 강령은 여덟 원칙을 둔다. 공공(PUBLIC), 고객과 고용주, 제품, 판단, 관리, 직업, 동료, 자기 자신(SELF). 첫 원칙은 소프트웨어 엔지니어가 공공의 이익에 맞게 행동해야 한다는 것이고, 마지막 원칙은 평생 학습에 참여해야 한다는 것이다.

이 시리즈 마지막 파트에서 본 것들이 이 원칙의 구체적 모습이다. 개인정보를 지키는 스키마, 편향을 측정하는 평가, 누구나 쓸 수 있는 인터페이스, 비난 없는 회고, 에너지를 아끼는 설계. 전문가가 된다는 것은 기술을 잘 아는 것과 함께, 그 기술이 사람에게 미치는 영향을 책임지는 것이다.

확인한 것만 말한다

마지막으로 실무에서 가장 쓸모 있는 습관 하나. “됐다”고 말하기 전에 확인한다. 배포했다면 실제 URL 에 요청해 보고, 고쳤다면 재현 절차로 다시 시험하고, 수치를 인용한다면 출처를 확인한다. 확인하지 못했으면 그렇다고 말한다. 이 습관 하나가 신뢰를 만든다. 신뢰는 기술보다 오래간다.

직접 해 보기

간격 반복을 위한 라이트너 상자 스케줄러를 만든다. 이 시리즈의 주제를 카드로 두고, 맞히면 다음 상자(긴 간격)로, 틀리면 첫 상자로 보낸다.

from datetime import date, timedelta

# 라이트너 상자: 맞히면 다음 상자(간격이 길어짐), 틀리면 1번 상자로
INTERVALS = {1: 1, 2: 3, 3: 7, 4: 14, 5: 30}   # 상자별 복습 간격(일)

cards = {
    "#046 해시 테이블": {"box": 1, "due": date(2026, 10, 12)},
    "#110 페이징": {"box": 1, "due": date(2026, 10, 12)},
    "#284 렌더링 파이프라인": {"box": 1, "due": date(2026, 10, 12)},
}

def review(name, today, correct):
    c = cards[name]
    c["box"] = min(c["box"] + 1, 5) if correct else 1
    c["due"] = today + timedelta(days=INTERVALS[c["box"]])

# 2주 동안의 복습 기록: 렌더링 파이프라인은 한 번 틀렸다
log = [
    (date(2026, 10, 12), "#046 해시 테이블", True),
    (date(2026, 10, 12), "#110 페이징", True),
    (date(2026, 10, 12), "#284 렌더링 파이프라인", True),
    (date(2026, 10, 15), "#046 해시 테이블", True),
    (date(2026, 10, 15), "#110 페이징", True),
    (date(2026, 10, 15), "#284 렌더링 파이프라인", False),
    (date(2026, 10, 16), "#284 렌더링 파이프라인", True),
    (date(2026, 10, 22), "#046 해시 테이블", True),
]
for day, name, ok in log:
    review(name, day, ok)

for name, c in sorted(cards.items(), key=lambda kv: kv[1]["due"]):
    print(f"{name:22s} 상자 {c['box']}  다음 복습 {c['due']}")

실행 결과다.

#284 렌더링 파이프라인         상자 2  다음 복습 2026-10-19
#110 페이징               상자 3  다음 복습 2026-10-22
#046 해시 테이블            상자 4  다음 복습 2026-11-05

잘 아는 주제는 점점 드물게, 헷갈리는 주제는 자주 돌아온다. 한 번 틀린 렌더링 파이프라인은 1번 상자로 돌아갔다가 다시 올라가는 중이다. 복습 시간은 약한 곳에 자동으로 몰린다. 의도적 연습의 “약점을 겨냥한 반복”을 코드로 만든 셈이다.

간격 값은 예시다. 중요한 것은 정확한 숫자보다 “떠올려 보고, 틀린 것을 다시 보는” 구조다. 각 글의 확인 문제를 카드로 쓰면 바로 시작할 수 있다.

현업에서는

  • 주니어 시기의 가장 큰 자산은 질문할 수 있다는 것이다. 질문 전에 스스로 조사한 것을 정리해 가면 질문이 좋아지고 답도 좋아진다.
  • 시니어로 가는 길은 혼자 잘하는 것에서 팀이 잘하게 만드는 것으로 넘어가는 과정이다. 리뷰, 문서, 멘토링, 장애 회고, 설계 결정 기록이 그 수단이다.
  • 기술 선택은 유행이 아니라 문제와 팀에 맞춰 한다. “이 기술로 무엇이 쉬워지고 무엇이 어려워지는가”를 적어 보는 습관이 판단력을 기른다.
  • 몸과 마음도 인프라다. 지속 가능한 속도로 일해야 오래 성장한다. 새벽 알림에 매일 깨는 구조라면 알림 기준과 당번 체계를 고치는 것도 엔지니어링이다.
  • 이 시리즈의 지도를 다시 펴고, 확인 문제에 답하지 못한 주제부터 하나씩 직접 만들어 보라.

확인 문제

  1. 빨리 변하는 기술을 따라가려면 오히려 잘 변하지 않는 기초가 중요한 이유는?
  2. “그냥 경험”과 “의도적 연습”의 차이를 개발 상황의 예로 설명하라.
  3. 글을 다시 읽는 것보다 확인 문제를 푸는 것이 학습에 유리한 이유는?
  4. ACM/IEEE-CS 소프트웨어 공학 윤리 강령의 첫 원칙과 마지막 원칙은 무엇인가?
  5. “배포 완료”라고 보고하기 전에 확인해야 할 것은?

풀이

  1. 새 기술도 기초 개념(자료구조, 일관성, 프로토콜) 위에 서 있어서, 기초를 알면 새 기술을 기존 지식에 연결해 빠르게 이해할 수 있다.
  2. 그냥 경험은 익숙한 일을 반복하는 것이고, 의도적 연습은 약간 어려운 목표를 정하고 피드백을 받아 약점을 겨냥해 반복하는 것이다. 예: 같은 CRUD 반복 대 매번 새 요소(캐시, 큐)를 넣고 리뷰를 받아 고치기.
  3. 인출 연습이 기억을 강화하고, 모르는 부분을 드러내 준다. 다시 읽기는 익숙함을 이해로 착각하게 만든다.
  4. 첫 원칙은 공공(PUBLIC), 공공의 이익에 맞게 행동한다. 마지막은 자기 자신(SELF), 평생 학습에 참여한다.
  5. 실제 서비스 URL 이나 헬스체크가 기대한 응답을 주는지, 새 버전이 실제로 돌고 있는지 측정으로 확인한다. 확인하지 못했다면 그 사실을 함께 보고한다.

더 읽을거리 (References)