추상화는 인간의 인지 능력에 한계가 있어서 자연히 발생합니다. 프로그래밍에서의 추상화뿐만아니라 일상 생활 전반에서 인간은 추상화된 환경에서 살아갑니다.

코드를 읽어내려가다보면 갑자기 구현체가 드러나지 않는 인터페이스가 등장할때가 있습니다.

코드를 들여다보려는 관성에 제동이 걸리고, 갑자기 뭔가 막혔다는 느낌이 듭니다. 브레이크 포인트를 걸고 디버깅을 돌려서 구현체를 찾기도 하죠.

코드를 들여다보는 도중에 갑자기 인터페이스가 등장하면 바로 그 지점이 "지금 전개되는" 코드의 맥락과 동떨어진 지점입니다. 거기서 더 깊이 들어가면 인지 부하가 높아져 코드의 맥락을 이해하는데 방해가 될 수 있는, 이세계로 빠지는 길입니다.

문자열 다룰때 s.substring(2, 8)과같은 메소드를 쓰면서 내부 동작까지 다 이해하려고 애쓰지 않아도 되듯이 현재 전개되는 코드 맥락과 직접적인 관계가 없는 기능들은 적절한 추상화로 격리시켜야 합니다.

메소드나 함수를 따로 정의하는 것도 그 본질은 추상화입니다. 반복되는 동작을 호출해서 쓰자는 기능적인 목적도 있지만 인지적으로는 지금 구현하려는 문제 맥락과 직접적인 연관이 없기때문에 함수로 따로 빼내서 인지 부하를 낮추려는겁니다.

"아침에 알람이 안울려서 급하게 택시를 탔는데 신호가 너무 막히길래 도중에 내려서 지하철을 타고 왔다"라고 늦은 이유를 설명할때도 프로그래밍과 똑같이 수많은 추상화가 존재합니다.

알람이 울리는 기계적 메커니즘, 택시가 움직이는 원리, 교통 신호 조절의 과정, 티머니 카드의 금액이 차감되는 원리 등등 수많은 사건들이 얽혀있으나 적절한 용어들로(알람, 택시승차, 결제, 교통 신호) 추상화시켜서 대화의 맥락을 간결하게 유지합니다. 이런 것들이 프로그래밍에서는 함수나 클래스 인터페이스, 패키지 등에 해당합니다.

인간이 이해할 수 있는 범위는 정해져있고, 대개는 범위가 넓지 않습니다. 그래서 추상화는 인간의 습성이 된듯하고 프로그래밍도 예외는 아닙니다.

그래서 결론은 "적응해야함"

댓글을 읽으면서 생각 흐름 정리가 잘됐습니다.!!

생각의 흐름을 애기하자면

추상화에 대한 필요성이 조직에서도 나타나는거 같습니다.

예를들면 대통령이 굳이 행정, 경호, 법 전문가들 보다 많이 알  필요 없이 이 사람들이 무슨 일을 하고 내가 그 사람들한테 무엇을 기대하는지만 명확하게 안다면 그걸로 충분한거져

yeori님이 달아주신 인지능력과 매우 연관된 애기 입니다!! 어차피 한 사람이 다 통달하는건 무리이니까용

하지만 추상화의 고질적인 문제점도 결국은 껴안고 가게 됩니다..

우리은행 600억 횡령 사태도 결국 추상화로 조직관리를 하다보니 조직 내부에 디테일 까지 파악못하여

발생한 일이라고 생각되서 항상 단점을 염두해두고 프로그래밍 해야할 거 같습니다..