2025-09-13

1일 1아티클

데보션

인지 부하

정의

  • 개발자가 특정 작업을 완료하기 위해 생각해야 하는 양의 척도
  • 일반적으로 사람은 작업 기억에 약 4개의 정보 덩어리(chunk) 담기 가능

종류

  • 내재적 부하 : 작업 자체의 고유한 어려움, 소프트웨어 개발의 핵심
  • 외재적 부하 : 정보 제시 방식에 의해 생성, 작업과는 직접 관련 X, 크게 줄일 수 있는 부분
    • ex. 똑똑한 개발자의 기벽, etc.

인지 부하를 줄이는 방법

  1. 복잡한 조건문

    
   if val > someConstant // 🧠+
   && (condition2 || condition3) // 🧠+++, 이전 조건이 참이어야 하고, c2나 c3 중 하나가 참이어야 함
   && (condition4 && !condition5) { // 🤯, 이 시점에서 우리는 혼란에 빠짐    ...}
    • 의미 있는 이름을 가진 중간 변수 도입
    
   isValid = val > someConstant
   isAllowed = condition2 || condition3
   isSecure = condition4 && !condition5
   // 🧠, 이제 조건을 기억할 필요 없이 설명적인 변수만 보면 됨
   if isValid && isAllowed && isSecure {
      ...
   }
  2. 중첩 if문
    • 조기 반환(early return) 방식
  3. 수많은 상속
    • 합성을 선호할 것
  4. 다량의 작은 메소드, 클래스, 모듈
    • 깊은 모듈 : 간단한 인터페이스, 복잡한 기능
    • 얕은 모듈 : 제공하는 작은 기능에 비해 복잡한 인터페이스
    • ex. UNIX I/O의 인터페이스는 단 5개의 기본 호출만 존재 (open, read, write, lseek, close)

      인간은 선형적 사고가 자연스러움

  5. 다량의 얕은 마이크로서비스
    • 얕은-깊은 모듈 원칙 → MSA에도 적용 가능
    • 업계는 매크로서비스(Macroservices) (깊은 서비스) 지향
    • 일반적으로 유연성 및 유지보수에 필요한 인지적 노력 측면에서, 격리된 모듈을 갖춘 잘 만들어진 모놀리스 > 여러 개의 MSA
  6. 기능이 풍부한 언어
    • 선택지의 수를 제한하여 인지 부하를 줄일 것
    • 언어 기능들의 직교(orthogonal)는 괜찮음
  7. 비즈니스 로직과 HTTP 상태 코드
    • 자기 서술적 문자열 선호할 것
    • ex. 백엔드의 상태 반환 시 401, 403, 418 이렇게만 반환하면 프론트엔드나 QA 엔지니어는 인지 부하 발생
  8. 프레임워크와의 강한 결합
    • 프레임워크가 아키텍처에 맞지 않는 새 요구사항에 직면 시, 상당한 제약 발생
    • 프레임워크는 핵심 로직의 밖에 두고 라이브러리처럼 사용할 것
  9. 계층형 아키텍처
    • 아키텍처라는 명목으로 하는 추상화 계층 추가는 높은 인지 부하로 이어짐
    • 정당하고 실용적인 확장 필요 시에만 추가
  10. 익숙한 프로젝트의 인지 부하
    • 친숙함과 단순함은 다르다!
    • 프로젝트에 새로운 사람을 온보딩하여, 그들이 겪는 혼란의 양 측정해 보기 (페어 프로그래밍)
    • 인지 부하를 낮게 유지 → 다른 사람들이 쉽게 코드베이스에 기여 가능

오늘 배운 것

내일 할 일

  1. 포트폴리오 내용 복기

참고자료

results matching ""

    No results matching ""