이룰 수 있다 (2003)

 (multicians.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Honeywell Cambridge의 Multics 파일 시스템 개편 과정에서 André Bensoussan은 핵심 하위 시스템인 VTOC manager를 맡아 설계부터 테스트까지 진행함
  • 이 모듈은 파일 설명 정보를 디스크와 메모리 사이에서 옮기고 버퍼 풀과 디스크 공간까지 관리해야 해, 사실상 작은 가상 메모리 관리자에 가까웠음
  • André는 터미널 앞에서 바로 코딩하지 않고 연필로 다이어그램과 코드를 다듬으며, 상태 정보를 담으면서도 대칭적인 설계를 만들려 했음
  • 최종 원고를 입력한 뒤 첫 컴파일에서 나온 문제는 오타 3개뿐이었고, 시스템에 바인딩한 실행도 첫 시도에 성공함
  • 이후 발견된 버그는 Tom Van Vleck가 오류 처리 절차의 호출 순서를 잘못 알려준 데서 생긴 하나뿐이어서, 프로그램 자체의 완성도가 매우 높았음

Multics VTOC manager 작업

  • André Bensoussan은 Tom Van Vleck와 함께 Honeywell Cambridge에서 Multics 운영체제 작업을 함
  • 파일 시스템의 대규모 변경에는 VTOC manager라는 하위 시스템이 필요했음
    • 파일 설명 정보를 디스크와 메모리 사이에서 이동
    • 공유 메모리 버퍼 풀 관리
    • 파일 정보용 디스크 공간 관리
  • 이런 역할 때문에 VTOC manager는 작은 가상 메모리 관리자처럼 동작해야 했음
  • André는 이 모듈의 설계, 구현, 테스트를 맡음

연필로 완성한 프로그램

  • André는 먼저 책상에 앉아 많은 다이어그램을 그림
    • 상태 정보를 모두 담는 동시에 보기 좋고 대칭적인 형태를 원했음
    • 일정 때문에 코드 작성이 늦어지는 점을 주변에서 걱정할 정도였음
  • 코딩도 터미널이 아니라 연필로 진행함
    • 타이핑 도움을 거절함
    • 일부를 다시 쓰고, 옮겨 적고, 지우고, 고쳐 쓰며 최종 원고를 만듦
  • 최종 연필 원고를 터미널에 모두 입력한 뒤 첫 컴파일은 실패했지만, 오타 3개를 고친 다음 컴파일에 성공함
  • 시스템에 바인딩해 실행하자 첫 시도에 동작했고, 이후 VTOC manager는 계속 완벽하게 동작함
  • 발견된 유일한 버그는 André가 물어본 오류 처리 절차의 호출 순서를 Tom Van Vleck가 확인하지 않고 추측해 알려준 데서 생김
    • 그 오류 경로를 처음 밟았을 때 크래시가 발생함
    • 그 외에는 프로그램에 문제가 없었음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 그가 그렇게 할 수 있었던 주된 이유는 요구사항이 매우 명확하게 정의되어 있었기 때문이라고 봄
    오늘날 소프트웨어가 버그 많고 느린 큰 이유는 실제로 무엇을 만들고 있는지 아무도 모르거나, 알아도 “애자일” 때문에 계속 바뀌기 때문임
    개발자에게 명확한 API와 잘 정의된 기준을 주면, 대부분은 아주 잘 동작하는 코드를 작성함

    • 듣기 싫은 현실은 그가 가능했던 이유가 본인이 도메인 전문가였기 때문이라는 점임
      요구사항은 목록과 티켓을 칸반 보드에 늘어놓는 일이 아니라, 만들 대상의 도메인을 실제로 배우는 일임
      이해하지 못한 영역도 만들 수는 있지만 결과물은 쓰레기가 되기 쉽고, 그 쓰레기 작성 과정을 도메인 과제와 가능한 해법을 배우는 초안 작성으로 받아들인다면 괜찮음
      품질에는 지름길이 없음
      이해관계자라면 애플리케이션을 만드는 사람에게 접근할 수 있어야 하고, 그들이 도메인을 이해하는지 확인해야 함. 계속 괴롭히지 않고도 가능함
      유행어를 늘어놓는 허풍쟁이는 조심해야 함
      디자이너와 프로그래머라면 이해관계자와 도메인 전문가가 적극적이고 몰입해 있는지 확인해야 함. 그렇지 않으면 요구사항과 이해를 끌어내는 일이 이를 뽑는 것처럼 어려워짐
      어떤 이해관계자는 문제를 풀고 싶어 하지조차 않을 수 있고, 완전히 다른 방향을 원했거나 정치적 이유로 삐쳐 있을 수도 있음. 게으르거나 무관심한 이해관계자만큼 프로젝트를 가라앉히는 것도 없음
    • 완전히 동의함. 문제는 대개 프로젝트 계획이 형편없게 이루어진다는 데 있음
      이해관계자는 자신이 원하는 것을 모르면서도, 무작위처럼 추가 기능이나 대대적 변경을 요구함
      이 도구로 하면 안 될 일까지 억지로 하느라 수많은 예외 처리가 필요해짐
      디자이너는 필요한 기능, 기존 시스템 동작, 이해관계자의 요구와 충돌하는 설계를 만들 때가 많고, 시스템 각 부분을 개발하는 팀들은 제대로 소통하지 못한 채 사일로 안에서 만듦
      잘못 설계된 “애자일” 프로세스는 의심스러운 점수 산정에 따라 모든 것을 특정 기간 안에 밀어 넣으려 함
      결국 이런 문제들이 시스템을 의도대로 동작하지 않게 하거나 버그 덩어리로 만듦
      요구사항이 명확하고 바뀌지 않으며, 프로젝트 구성원들이 잘 소통하고 프로세스를 완전히 통제할 수 있는 환경을 만들면 잘 풀림. 원문 사례도 그렇게 보임
    • 거기에 더해 수천 개의 특수 사례가 붙고, 코드로 구현하는 의미가 거의 없는데도 반드시 해야 하는 경우가 많음
      대기업에서 주로 일하는데, 들어오는 일의 90~99%는 평균적인 경우에 해당함
      그런데 3년에 한 번, 그것도 월식과 일식이 동시에 일어나고 숲에서 마녀들이 주문을 외울 때쯤 발생하는 유니콘 같은 특수 사례가 무수히 있음
      이런 사례를 수작업으로 처리하지 않고 코드에 구현해야 하니 버그가 생기고, 검토하고 유지보수할 코드가 훨씬 늘어남
      유지보수 얘기는 시작도 하지 말자. 아픈 부분임
    • “애자일” 때문에 요구사항이 바뀐다고 생각한다면 뭐라 해야 할지 모르겠음
      요구사항은 항상 바뀜. 그건 자연의 힘 같은 것이고, 모두가 처음부터 무엇을 만들지 알고 완전히 명세된 API를 받아 동굴에 들어가 구현만 하면 되는 세계는 없음
      현실은 절대 그렇게 돌아가지 않고, 그런 조건이 필요하다면 소프트웨어 엔지니어링은 맞는 직업이 아님
    • 평범하고 지루한 데스크톱 소프트웨어를 만들고 있는데, 버그는 전부은 아니어도 대부분 사용자가 “멍청한” 일, 즉 전혀 예상하지 못한 행동을 하는 예외 사례에서 나옴
      사용자가 없다면 내 소프트웨어는 완벽할 텐데 ;)

  • 소련에서 망명한 사람과 일한 적이 있음. 그는 소련 프로그래머들이 뛰어났던 이유가 컴퓨터 접근이 매우 제한적이었기 때문이라고 했음
    연필과 종이로 프로그래밍해야 한다면, 첫 실행에 동작하도록 만들고 싶어짐
    우연히도 우리는 Honeywell에서 일하고 있었음

    • 다른 해석도 가능함. 종이로 작업하고 컴퓨터 접근이 제한된 환경을 견딜 만큼 몰입한 사람들만 이후에도 계속 일했을 수 있음
      그러면 이건 좋은 교육 방식이었을까, 아니면 덜 동기부여된 사람을 걸러내는 좋은 필터였을까?
    • 이건 증언할 수 있음. 대학 강사가 프로그래밍 과제를 내고 해결 방법을 설명하던 중, 종이에 해법을 개요로 적기 시작했음
      학교에서는 수업 중 컴퓨터를 쓸 수 없어서, 종이에 프로그래밍하고 심지어 디버깅하는 데 익숙했음
      집에 도착해서 입력하고 실행해 봤고, 예전에 읽은 Multics 일화를 재현할 수 있을지 궁금했음
      첫 컴파일은 실패했지만 변수 이름 하나를 고친 뒤 완벽하게 동작함
    • 카드와 출력물이 입출력 시스템이던 컴퓨터로 배웠음
      몇 년 동안은 편집→컴파일→출력 루프에서 터미널보다 리스팅 출력이 훨씬 나았던 기억이 있음. 코드를 효율적으로 보고 이동하고 수정하기가 어려웠기 때문임
      더 나은 시각적 편집기, 더 큰 터미널, 더 빠른 컴파일과 실행이 나오면서 결국 개선됨
      비유하자면 초기 화기와 비슷함. 젖은 화약, 불안정한 부싯돌식 점화, 총신에 모든 것을 밀어 넣어야 하는 방식 때문에 장궁에서 넘어가는 과도기가 비효율적이었던 것과 같음
    • 고등학교에서 COBOL을 배울 때 대부분 펜과 종이로 했음. 학교 실습실에 학생마다 쓸 PC가 충분하지 않아서 컴퓨터 한 대를 3~4명이 같이 써야 했음
    • 그렇다면 그는 연필과 종이에 접근할 수 있었던 특권층 중 하나였겠군

  • 이 글의 이전 HN 스레드에 André와 함께 일했던 jrd259 계정의 좋은 댓글이 있음: https://news.ycombinator.com/item?id=18415231
    넓은 책상과 알림 없는 개인 작업 공간이 얼마나 중요한지와 관련된 내용임

  • 내 삶에서 종이에 프로그래밍했던 두 번이 떠오름
    첫 번째는 10~12살쯤이었음. 컴퓨터도 스마트폰도 없던 조부모님 댁에 갔는데, 검은색과 빨간색을 스위치로 바꿔 찍을 수 있는 기계식 타자기가 있었음
    당시 주된 취미가 Turbo Pascal이라, 나중에 집에 돌아가 PC에 입력해 실행할 Pascal 프로그램을 타자기로 작성했음
    조부모님 댁에 일주일 있었기 때문에 충분히 생각하고, 손으로 디버깅하고, 잘못된 부분을 다시 타이핑할 시간이 있었음
    두 번째는 내가 만든 난해한 프로그래밍 언어 Ziim(https://esolangs.org/wiki/Ziim)과 그 페이지의 이진 덧셈 함수에 관한 일임
    그 함수는 거대하고 복잡했고 버그가 있었음. 인터프리터에서 실행해 봤기 때문에 버그가 있다는 건 알았지만 어디가 문제인지, 어떻게 고칠지 몰랐음
    마침 약 6시간짜리 장거리 버스를 탈 일이 생겼고, 디버깅하기에 완벽한 기회였음
    Ziim 덧셈 함수를 연필로 모눈종이에 옮긴 뒤 버스에서 한 단계씩 손으로 실행했음. 버그를 찾아 고칠 수 있었고, 함수 배치를 전부 다시 해야 했음
    쉬운 방식으로 하는 능력을 일부러 제한하면 때로는 잘 숙고된 코드로 이어질 수 있다는 교훈 같음
    그래도 평소에 이렇게 하지는 않음. 대충 스니펫을 쓰고 반복하거나, 디버거로 한 줄씩 실행하는 식도 바로 함. 다시 생각해 봐야 할지도 모르겠음

    • 보통은 대부분의 생각을 머릿속에서 하기 때문에, 가끔 종이와 펜으로 깊게 생각할 때는 중요한 것만 적고 나머지는 머릿속에 유지하는 규율과 신중함이 생김
      하지만 모든 일을 종이로 하면 결국 컴퓨터에 직접 하는 것과 크게 다르지 않게 됨. 전부 다 적게 되고, 그 추상화와 신중함을 잃게 됨

  • 내가 시작했을 때는 “대형 컴퓨터” 시대의 끝물이었음
    옛날에 “프로그래머”는 대개 데이터 입력 사무원에 가까웠고, 종종 여성이었음
    소프트웨어를 작성하는 사람들은 담배 연기로 가득 찬 사무실에서 종이에 프로그램을 쓰고 있었음
    컴퓨팅 시간은 비싸고 귀했음. 실행 중 버그가 나면, 다시 데이터 입력 시간을 잡고 또 CPU 실행 시간을 잡기 전까지는 고칠 기회가 없었음
    그래서 두 번 재고 한 번 자르는 접근을 장려했음
    당시 대부분의 소프트웨어는 오늘날 당연시되는 것에 비하면 꽤 소박해서 그렇게 하기가 더 쉬웠음. 또한 소프트웨어의 입출력은 극도로 제한적이었고, UI라는 말조차 없었으며, 주변장치 연결은 큰일이었음
    요즘은 소프트웨어를 쓸 때 자주 “벽에 던져 보고 뭐가 붙는지 보는” 식으로 함. 반쯤 된 코드를 쓰고 IDE에서 디버깅하는 편이 더 쉬움
    내 소프트웨어 개발은 반복적인 편이고, 여기서 쓴 적이 있음: https://littlegreenviper.com/miscellany/evolutionary-design-...

    • 바로 그 점임. 코드를 쓰기 전에 소프트웨어에 대해 많이 생각해야 했던 옛 시절을 아쉬워하지만, 사실 오늘날 같은 프로그래머라면 반복 개발로 같은 프로그램을 절반쯤의 시간에 만들었을 수 있음
      대학 과제에서 간단한 운영체제 커널을 작성해야 했던 기억이 있음
      C도 잘 몰랐고 커널이 무엇을 하는지도 이론 이상은 몰랐지만, 작업 관리를 위해 C 코드 몇백 줄을 써야 했음
      이 프로그램이 동작하지 않으면 병렬 코드라 디버깅할 방법이 거의 없고, 버그는 알 수 없는 경쟁 상태로 나타날 거라고 생각했음
      시스템 전체를 추론했고, 며칠 동안 작고 독립적인 함수들을 아주 많이 생각하며 작성했음
      그런 다음 컴파일하고 실행했더니, 당연한 “세미콜론 누락” 컴파일 오류를 고친 뒤 첫 실행에 동작함

  • 인상적인 성취가 올라올 때마다 댓글들이 대체로 흠을 잡음. 그만했으면 함

    • 현대 개발자들은 좌절해 있음. 이제 더 이상 중요하거나 의미 있는 일을 하지 않음
      새로운 운영체제를 위한 가상 메모리 관리자를 설계하는 사람이 아니라, 아이들과 노인에게 광고를 보여 주려고 SQL 쿼리를 HTML로 바꾸는 기계 속 톱니바퀴일 뿐임
      냉소적이고 씁쓸해질 수밖에 없음
    • 누군가 반론을 올릴 때마다 사람들이 거기에 흠을 잡음. 그만하자고?
      사실 그러지 말아야 함. 토론은 바로 그런 것이어야 함
      어느 정도는 맞지만, 긍정적으로 방향을 돌리는 더 나은 질문은 이거임. 오늘날 회사 환경에서 비슷한 성취가 가능한 상태에 어떻게 도달할 수 있을까?
    • 이런 태도는 이해하지만, 내가 이 글을 올린 지 5시간 뒤에 들어왔을 때 상위 댓글은 모두 꽤 긍정적이었고 흠잡는 분위기가 아니었음
      이런 반응을 볼 때마다 대체로 그렇다. 사용자 조정이라는 체가 더 나은 댓글을 위로 올리는 데 조금 시간이 걸릴 뿐임
    • 하지만 이해 못 하는군. 나는 한때 chart.js 3을 chart.js 4로 교체해야 했고, 문서가 모든 변경 사항을 다루지 않았음
      이 사람이 내가 겪은 도전을 마주했다면 그대로 주저앉았을 것임

  • 당시 소프트웨어는 훨씬 작았음
    요즘은 장난감 프로그램보다 조금만 커져도 대부분 프로젝트가 메가바이트 단위이고, 단일 파일로 “적어 내려가기”는 불가능함

    • 코드를 직접 확인해 보길 바람: https://multicians.org/vtoc_man.html
      이건 오늘날 대부분이 작업하는 것보다 더 크고 복잡함. 오늘날 많은 일은 CRUD/REST 같은 것들을 붙이는 과장된 접착 코드에 가까움
      전체 프로젝트의 코드 줄 수보다는 작을 수 있지만, 사람들이 다루는 단위보다는 큼. 게다가 이것도 전체 운영체제 코드의 일부임
      이건 “파일 설명 정보를 관리하는 관리자” 전체임. 파일 정보를 디스크와 메모리 사이에 운반하고, 공유 메모리 버퍼 풀을 관리하며, 그 정보를 위한 디스크 공간도 관리해야 했음
      현재 대부분의 프로그래머에게 같은 요구사항과 의미론을 가진 것을 자신이 고른 언어로 오늘 작성해 보라고 해보면 어떨까
      대부분은 그것을 상상하는 단계에서부터 길을 잃을 것임. 하물며 종이에 쓰고 입력해서 동작하게 하는 것은 더더욱 어려움
    • 반대로 참고할 예제가 거의 없었음. 그들의 운영체제 입문 수업에는 가상 메모리 강의가 없었음. 이 사람들은 운영체제 설계를 개척했음
    • 미안하지만 우리가 대부분 작업하는 업무용 소프트웨어가 파일 시스템의 주요 구성요소를 처음부터 작성하는 것보다 더 인상적이지는 않음
    • 지난 한 달 동안 전자공학 노트에 쓴 자연어 메모가 벌써 0.25메가바이트, 약 37,000단어의 Markdown이라는 걸 알고 놀랐음
      그중 작은 일부는 전자부품 URL이지만, 거의 90%는 그냥 영어 텍스트임. 또 10%는 다른 사람의 글, 웹페이지, 제조사 애플리케이션 노트, 책 등에서 인용한 것임
      단일 파일이고, 아마 올해 남은 기간은 물론 계속 단일 파일로 남을 것임. 같은 속도로 이어지면 12메가바이트가 됨. 불가능한 일은 전혀 아님
      관심 있다면 git clone http://canonical.org/~kragen/sw/leatherdrink.git 하면 됨
      현재는 avr 도구체인을 커밋해 둬서 거의 200메가바이트이고, 사진·동영상·회로도 같은 것도 있음
      프로그래밍 언어라면 월별 증가 바이트 수는 더 적겠지만, 아마 다섯 배 정도 차이일 수 있음

  • André Bensoussan이 작성한 코드는 여기 있음: https://multicians.org/vtoc_man.html

    • “어떻게 했을까?”에 대한 답은 분명함. 현대 기준으로는 그다지 복잡한 작업이 아니었기 때문임
    • PL/1을 많이 본 적은 없는데, 제어 흐름을 제외하면 문법이 놀랄 만큼 깔끔해 보임

  • 업무를 시작하려고 책상에 앉아 꺼려지던 일을 끝내려는 순간, 당연하게도 마음이 새서 reddit이나 HN에서 뉴스를 확인하고 싶어졌음
    HN을 열었더니 첫 제목이 이거였음
    “할 수 있다”
    동기부여가 됐음
    추신: 물론 글도 읽었음 :)

  • “André는 연필 말고 아무 도구 없이 어떻게 이걸 했을까?”
    14살에 고등학교에 갔을 때, 프로그래밍 수업에서 대부분의 코드를 종이에 썼음
    가난한 나라의 가난한 아이였고, 집에 PC가 없었을 뿐 아니라 학교 컴퓨터실의 몇 안 되는 “컴퓨터”도 당시 쓰던 프로그래밍 언어인 Turbo Pascal을 실행하지 못하는 ZX Spectrum 복제품들이었음

답변달기