▲

코딩은 프로그래밍이 아니에요

(socallinuxexpo.org)
48P by GN⁺ 6일전 | ★ favorite | 댓글 5개
  • Leslie Lamport는 LaTeX의 초기 개발자이며 분산 시스템 분야의 선구자. 2013년 튜링상 수상
  • 그가 SCaLE 22x 키노트에서 추상화의 중요성을 강조하며, 대부분의 프로그래머가 코딩과 언어에 몰두하지만, 코딩 전 추상적 사고와 설계가 핵심임을 지적함

발표 요약

  • 여러분은 내가 동시성(Concurrency)에 대해 얘기하는 걸 기대할 수 있으나, 이에 대해 새롭게 말할 것이 없음
  • 그러나 "Concurrent한 프로그램 작성"에 대한 통찰이 일반적인 모든 프로그래밍에도 적용됨
  • 이 발표는 프로그래밍 전반에 관한 이야기임

알고리듬 vs. 프로그램

  • 알고리듬: 언어와 무관한 추상적 아이디어. 프로그램보다 더 추상적이고 상위 수준의 개념
  • 프로그램: 알고리듬을 특정 언어로 구현한 구체적인 형태. 프로그래밍 언어는 알고리듬을 표현하기에 너무 복잡함
  • 알고리듬은 실행되지 않으며, 일반적으로 짧고 간단함
  • 특히 동시성 관련 코드에서는 먼저 정확한 알고리듬을 정의하고 구현해야 함

배열 최대값 예제로 보는 추상화

  • 단순한 문제라도 "무엇을 할 것인가(What)"를 명확히 정의해야 함
  • 예: "정수 배열의 최대값 반환" → "모든 원소 이상인 최소 수 반환"
  • 비어 있는 배열 처리도 사전에 정의 필요 (예: -∞ 사용)
  • 이렇게 명확한 정의를 통해 더 간단하고 견고한 알고리듬(How) 을 도출 가능

프로그램 실행은 상태의 흐름

  • 프로그램 실행은 단순한 명령 순서가 아닌, 상태(state)의 연속
  • 각 상태 전이는 코드의 한 부분 실행을 의미함
  • 이러한 시각은 알고리듬의 올바름을 증명할 때 중요함 (불변식 사용 등)

복잡한 시스템을 위한 도구: TLA+

  • 추상화를 정밀하게 표현하기 위해 정확한 언어가 필요
  • TLA+는 그런 용도로 설계된 도구
  • Amazon Web Services는 TLA+로 심각한 설계 결함을 사전에 발견
  • Rosetta 우주선의 OS인 Virtuoso도 TLA+ 기반으로 설계, 코드가 간결하고 안정적이었음

불완전한 사양에서도 추상화의 역할

  • 예: 프리티 프린터는 정렬 기준이 주관적일 수 있음
  • 그럼에도 불구하고 추상화된 규칙 세트를 정해두는 것이 디버깅과 유지보수에 중요

글쓰기와 사고의 관계

  • 생각을 글로 적는 것이 사고를 명확하게 해줌
  • 추상화는 단순히 머리로만 하는 게 아니라 글로 표현해야 효과적
  • Lamport는 자신의 수학적 훈련이 추상화 능력을 길러줬다고 언급
  • 수학자들이 프로그래머에게 추상화를 가르칠 수 있음

라이브러리와 버그에 대한 시각

  • 발표 2부 "왜 프로그램은 버그를 가져야 하는가"에서 복잡성 문제를 다룸
  • 현대 소프트웨어는 많은 라이브러리에 의존하지만, 이들은 정확한 언어 독립적 설명이 부족
  • 이로 인해 통합 과정에서 예상치 못한 버그가 발생
  • 예: 본인의 TLA+ 강좌 사이트에서 JavaScript 디버깅 경험
  • 상태 기반 시각이 이러한 복잡성을 이해하는 데 유용

질의응답에서 다룬 주제들

  • AI가 추상화에 미칠 영향
  • 오픈소스와 학계의 단절
  • 개발자들이 형식 정의(formal definition)를 소홀히 하는 현실
  • 여전히 가장 중요한 것은 "코딩 전에 생각하기"

결론: 프로그래밍의 본질은 사고

  • Lamport는 단순한 코딩보다 추상적 사고와 형식적 사양을 우선시해야 한다고 주장
  • upfront 노력이 크지만, 결과적으로 더 견고하고 유지보수하기 쉬운 소프트웨어로 이어짐
  • 코딩은 프로그래밍의 일부일 뿐, 진짜 프로그래밍은 정확한 알고리듬과 추상화에서 시작
  • 시스템 복잡성과 동시성이 증가하는 현대에서 추상화는 필수 역량 이며, 사고하고 추상화하는 훈련이 프로그래머에게 필요함
▲
softer 5일전  [-]

저도 이 글에 공감합니다
추상화 된 상태 값들로 문제 정의하는게 문제 발견에 유용하다 보고 있고 다이어그램 등으로 상태시각화나 언리얼 블루프린트나 워크 플로우 같이 시각적 명시적 으로 분명한 상태 관리 툴을 만들려하고 있는데

언어를 먼저 봐야겠네요

답변달기
▲
felizgeek 5일전  [-]

계산이론 전공 수업이 생각나는 글입니다! 프로그래밍 하는분들께 공부해보길 추천드려요.

답변달기
▲
aer0700 6일전  [-]

TLA 가 뭔지 궁금하네요
찾아봐야겠어요

답변달기
▲
GN⁺ 6일전  [-]
Hacker News 의견

  • 데모 씬의 '코더'들은 자신들을 그렇게 부르며 자부심을 느끼고, 이들은 종종 뛰어난 '프로그래머'와 '소프트웨어 엔지니어'이기도 함. 코더, 프로그래머, 소프트웨어 엔지니어 등 어떤 이름을 사용하든, 중요한 것은 컴퓨터가 원하는 대로 작동하게 만드는 것임

  • 다음 해의 키노트는 '바이빙은 코딩이 아니며, 프로그래밍도 아니며...; 가끔은 조금 작동하는 쓰레기의 피라미드'일 것 같음. Dijkstra가 이를 보지 않아 다행임. 그는 80년대에 부모님 거실에서 화가 났었음. '바이브 코딩'을 보면 어떤 반응일지 상상도 할 수 없음

  • Leslie Lamport의 SCaLE 22x 키노트: 생각하고, 추상화하고, 그 다음 코딩하기. Lamport는 코딩 전에 생각과 추상화를 강조하는 프로그래밍 접근 방식의 근본적인 변화를 주장했으며, 이는 모든 비사소한 코드에 적용됨

    • 추상화 우선: 코드를 작성하기 전에 프로그램의 추상적 관점을 정의함. 이 고수준 설계는 논리를 명확히 하고 오류를 조기에 발견함. 특정 언어가 아닌 아이디어에 집중함
    • 알고리즘 != 프로그램: 알고리즘은 추상적 개념이며, 프로그램은 구체적 구현임
    • 상태로서의 실행: 프로그램 실행을 상태의 연속으로 모델링하며, 각 상태의 미래는 현재에만 의존함. 이는 특히 동시성에서의 추론을 단순화함
    • 불변성의 중요성: 모든 실행 상태에 대해 참인 속성인 불변성을 식별함. 이를 이해하는 것이 정확성에 필수적임
    • 명확한 명세의 중요성: 많은 라이브러리 프로그램이 명확한 명세가 부족하여 올바른 사용을 방해함. 특히 동시성에서 기능의 명확하고 언어 독립적인 설명이 필요함
    • 글쓰기는 사고임: 글쓰기는 명확성을 강요하고 부주의한 사고를 드러냄. 사고는 글쓰기를 개선함. 이는 선순환임
    • 추상화 배우기: 추상화는 수학의 핵심 기술이며, 프로그래머는 이 능력을 개발해야 함
    • AI를 통한 추상화? AI 모델이 프로그래밍에서 추상적 사고 과정을 위해 활용될 수 있는지에 대한 질문이 제기됨

  • 프로그래밍은 신중한 설계(추상화) 후 구현(코딩)을 따르는 의도적인 과정이어야 하며, 명확한 명세와 상태 연속 및 불변성을 통한 프로그램 행동 이해에 중점을 둬야 함. 생각하는 것이 항상 더 나음

  • 수학 교수는 개념을 더 정확하고 기계가 읽을 수 있는 형태로 변환하는 모든 행위를 코딩이라고 부름. 프로그래밍 언어로 컴퓨터가 하기를 원하는 것을 쓰는 것뿐만 아니라 데이터를 인코딩하는 것도 포함됨. "인코드"라는 단어가 이를 명확히 함. 이진 트리를 자연수로 변환하는 코딩 방식을 정의하는 과제를 줌. 코딩이라는 단어는 너무 모호하여 많이 사용하지 않음

  • Lamport는 "무엇"과 "어떻게"를 분리해야 한다고 주장함. 그러나 대부분의 문제에서 프로그램의 "무엇"과 "어떻게"가 어느 정도 합쳐지지 않나 궁금함. 예를 들어, 성능 고려사항은 "무엇"의 일부인가, "어떻게"의 일부인가?

  • 흥미로운 요약: 알고리즘은 프로그램이 아니며 프로그래밍 언어로 작성되어서는 안 되며 단순해야 함. 반면 프로그램은 잠재적으로 큰 데이터셋에서 빠르게 실행해야 하므로 복잡해야 함. 특히 여러 CPU에서 실행되는 동시 프로그램의 실행 순서가 다르기 때문에 논의됨

  • 코딩 전에 생각이 필요한 코드, 코드를 읽고 싶지 않은 사람이 사용할 코드로 프로그램을 정의함. 이 강연은 오래전부터 진행되어 왔음. 가장 작은 항목을 찾는 것을 단순화하는 예시가 John Ousterhout의 책에서 "Define Errors Out of Existence"와 정확히 일치함

  • 댓글 섹션이 메시지를 이해하지 못하는 사람들로 주로 채워져 있는 아이러니를 즐기고 있음. Leslie Lamport의 핵심은 추상적 사고 능력을 개발하는 것이 더 나은 프로그램으로 이어진다는 것임. 수학적 및 논리적 의미에서의 추상화는 모든 관련 없는 세부 사항을 제거할 수 있게 해줌. AI가 안내하는 소프트웨어 개발도 마찬가지임

  • 엄격함이 관련된 모든 것에서 예상할 수 있듯이, 많은 사람들이 제목만 읽고 부정적인 반응을 보임. Hacker News의 해커는 문제를 해결할 수 있는 숙련된 프로그래머일 수 있음. 이제는 "You're a Hack"이라는 의미로, 무능하고 저품질 결과를 만드는 사람일 수도 있음

  • 이 강연과 논의는 지나치게 세세함

  • 현재 ACM에 좋은 기사가 있으며, 추상화가 무엇인지에 대해 동의하지 않지만, 그럼에도 불구하고 매우 유용하다는 내용임. 중요한 점이 어디에 있는지 대체로 동의함. 정확히 무엇인지, 왜 중요한지에 대해서는 동의하지 않음. 영감을 많이 받을 수 있으며, 이는 자체적으로 가치가 있음

  • 해킹은 코딩이 아니며, 프로그래밍도 아니며, 소프트웨어 개발도 아니며, 소프트웨어 엔지니어링도 아님. 그러나 결국 많은 사람들이 이 용어들을 거의 교환 가능하게 사용하며, 개인적으로 사용하는 정의의 차이를 강조하는 것은 거의 생산적인 시간 사용이 아님

답변달기