(OLD) 소프트웨어 개발을 위한 지식 기반 시스템 Knowledge Base System for Software Development

주의) (OLD)로 표기된 글은 현재 제 생각과 크게 다르거나 중대한 오류가 있지만
아카이브용으로 유지하는 글입니다

프로그래밍이란 무엇인가(무엇이어야 하는가)

프로그래밍은 현실의 문제를 해결하기 위해
문제를 모델링하고, 그에 대한 해답을 소프트웨어로 제시하는 과정이다.

프로그래밍은 모르는 것을 알아가는 과정이다(이어야 한다).
인간은 본능적으로 프로그래밍을 할 수 있게 태어나지 않았다.
무슨 일을 해도 모르는 부분이 반드시 있다.
그것을 메꾸기 위해 문서도 보고, 프로토타입도 만들고, 스파이크도 하고.

지금의 상황

문제: 현실과 합치하지 않는 인식을 토대로 이루어지는 개발
이 바로 소프트웨어 프로젝트 실패의 가장 큰 원인이다.

• 알아야하는 것을 충분히 알지 못한 채로 해답(프로그램)을 내놓거나
• 해결해야 하는 진정한 문제가 뭔지 모르는 상태에서 해답을 내놓거나
• 된다고 믿었던 것이 사실 그렇지 않거나
• 시간에 쫓겨서 잘 알지 못하지만 잘 되리라 믿고 일을 진행하기 때문.

문제: 복잡하고 혼돈스러운 소프트웨어 개발 과정
뭔가 알기 위해 했던 일이 그대로 해답이 되거나, (프로토타입이 제품이 되는 경우)
중요하지 않은 일(이른 최적화, ..)을 하다가 정말 중요한 것을 하지 못하는 등.
이는 지금 무슨 일을 하고 있는지 (해야 하는지) 모르고 개발하기 때문이다.

제안하는 해답

해답: 지식 기반을 이용한 소프트웨어 개발
알게 된 것들과 새로운 사실, 물음과 그에 대한 해답을
머리속 뿐만 아니라 어딘가에 명시적으로 기록해 두어야 한다.

그것을 관리하기 위해 지식 기반이 필요하다.

프로그래밍을 위한 지식 기반 Knowledge Base for Programming

지식은 작은 문장들로 이루어진다.
소프트웨어 설계를 위한 지식 기반은 문장들의 모임으로 표현될 수 있다.

문장은 다음처럼 나눌 수 있다.

• 사실 fact: 현실과 합치할 가능성이 매우 높은 문장. 물론 틀릴 수도 있음.
• 물음 question❓: 참/거짓, 선택, 혹은 문장(들)으로 "답"을 내야 하는 문장
• 제안/해답 proposition/answer🙋: 주장. 사실이 될 수도 있는 문장.
• 조건 constraint❗: 제안/해답이 만족해야하는 문장. ("사실"의 특수한 종류)

조건은 흔히들 "요구사항"이라고 부르는 것이다.
물음은 우리가 알고 있는 "아직 모르는 것들"이다.
문제의 핵심적(답하면 문제가 해결되는) "물음"은 **"미지"**라고도 한다.

명시적인 지식 기반을 이용하는 소프트웨어 개발

소프트웨어는 제안/해답을 구현한 것이다. (모든 제안/해답이 소프트웨어인 것은 아니다.)

소프트웨어 개발은

• 다양한 행동(탐구 - 문서, 스오플 읽기 / 탐험 - 스파이크, 프로토타입)으로
• 물음에 대한 답(제안/해답 -> 사실)을 만들어 나가다가,
• 결국 **가장 핵심적인 물음(미지)**에 답을 내는 행위이다.

소프트웨어 개발을 위한 지식 기반을 명시적으로 표현하면

• 복잡하고 혼돈스러운 개발 과정이 좀 더 이해하기 쉬워질 것이다.
• 무엇을 해야할지(TODO) 더 빨리 알 수 있게 될 것이다.
• 모르는 것을 명시하고 해결해 나가서, 잠재적 위험을 줄일 수 있다.
  • 운에 맡기는 프로그래밍이 줄어들 것이다.

소프트웨어 지식 기반이 만족해야 하는 조건

작은 "문장"들을 관리할 수 있어야 한다.

문장은 여러가지 형태로 표현될 수 있어야 한다.

• 문자열 - 말 그대로 문장의 형태
• 그림, 혹은 그림의 일부
• 테이블, 혹은 테이블의 일부
• 요약하는 이름

문장은 특정 attribute를 추가할 수 있어야 한다.

• kind: 사실, 물음, 제안/해답, 조건
• 관계나 표현(문자열, 그림, 테이블..)들도 모두 attribute로 표현 가능하다.

문장들은 서로 관계를 맺을 수 있어야 한다

• 물음 -> 답 -> 사실
• 물음 -> 답 -> 참/거짓
• 사실 -> 새버전 -> 사실
• 물음 => 알아야할것들 => 사실(들)

문장은 버전이 관리되고 모두 기록되며 이후 변화를 확인할 수 있어야 한다(datomic)

문장의 reference가 쉬워야 한다.
정보가 중복되어서는 안 된다. 문장을 찾기 쉽고 참조를 만들기 쉬워야 한다.

"문장"의 "표현"을 쉽고 효과적으로 관리할 수 있어야 한다.

문자열, 그림, 테이블, ref를 관리해야 함.
문서 표현은 중간에 그림이 들어갈 수 있어야 함.

기타

자료는 아직 정리되지 않은, 소화되지 않은 원본 자료나 출처를 뜻한다.
자료를 보고 듣고 정리하여 지식 기반에 사실을 더해나간다.
자료는 문장은 아니지만, 현실적인 이유에서 지식 기반에 포함시킨다.

고객의 의견이나, 기능 요구(feature request)는 "자료"가 된다.
개발자는 고객의 요구를 다 들어주는 게 아니라, 고객의 문제를 해결해주어야 한다.

소프트웨어 지식 기반 - 구현 예상

이모지를 쓰거나, 특정한 표시를 통해 문장에 달린 어트리뷰트를 명시할 수 있다.
문장 표현 정책을 전역적/부분적으로 정의할 수 있다.

문서 표현

문장을 여러개 모아서 만들 수 있다.
전형적인 설계 문서의 예시로는 "문제" 문서 표현이 있다.

문제의 이름을 문서의 이름으로 적고,
문제와 관련된 문장(사실, 조건)을 모아 넣는다.
사실, 조건들을 적당한 카테고리로 나눠 담을 수도 있다.

문제를 해결하기 위해 제안하는 해답도 적는다.
해답으로 테이블을 쓸 경우 조건들이 자동으로 행의 첫 요소로 붙는다.

제목: 문제의 이름

미지:❓문제의 핵심적인 물음

사실 카테고리

• 사실1
  • ❗사실1과 연관된 조건 1
  • ❓사실1과 연관된 문제 1
• 사실2
  • 사실 2.1
  • 사실 2.2
• 사실3ref
• 사실4ref

조건 카테고리

• ❗조건 2
• ❗조건 3

해답(문장)
🙋해답 1: 은 문제에 대한 해답 제시
🙋해답 2: 는 문제에 대한 해답 제시

해답(테이블)

미지	🙋해답 1	🙋 해답 2
❗조건 1	테이블의	사실은
❗조건 2	일종의	❓물음이
❗조건 3	될수도	있다

"문제 문서"는 다양한 연관 관계를 표현한다...
또한 자동적으로 생성되는 물음들이 있다(테이블에 넣을 사실들)

TODO 문서 표현

지식 기반에 존재하는 ❓물음은 그 자체로 TODO가 될 수 있다.
혹은 ❓물음을 해결하기 위한 활동(탐구/탐험)을 연결시켜 TODO로 제시할 수 있다.

물음들을 (가능하면 컨텍스트까지) 가져와서 모아두면
그것들은 바로 해결해야 하는 TODO 리스트가 된다.

TODO는 리스트로 표현할 수도 있고, 테이블로 표현할 수도 있다.

물읍에 대한 답과, 그 근거(사실)를 연결할 수 있다.

TODO(자동 생성)

물음	활동 1	활동 2	...
❓물음 1	📖탐구 1	🏃탐험 1.1
❓물음 2	📖탐구 2 -> 사실1, 사실2,..	🏃탐험 2.1
❓물음 3	🏃탐험 3.1	🏃탐험 3.2

테이블에서 물음의 중요성("미지"라면 크다)이나 연관된 속성에 따라 sort 가능

테이블을 이용한 해답 trade off

표현하는 연관관계: 문제 <-> 조건, 문제 <-> 해답, [조건+해답] <-> 사실

테이블 사용은 스프레드 시트 정도로 편하면 좋겠다.
테이블은 sort가 가능해야 한다.

해답: 더 작은 문제로 분해하기

• 문제1
  • 문제1.1
    • 문제 1.1.1
    • 문제 1.1.2
  • 문제1.2
    • 문제 1.2.1
    • 문제 1.2.2

문제는 더 작은 문제로 분해될 수 있다.
이런 문제의 분해 자체가 (특히 설계 문제의) 해답이다.

표현은 접을 수 있어야 한다.
트리 다이어그램으로도 표현할 수 있다.

표현 관계: 문제1 <- 문제/소문제 -> 문제 1.1 <- 문제/소문제 -> 문제1.1.2

그림

그림은 자유롭게 그릴 수도 있지만,
그림 전체나 일부를 문장과 연관시킬 수도 있다.
문서 중간에 삽입할 수 있어야 한다.

ref 관리

어떤 사실이 삭제되거나 변경될 경우,
그것을 ref하는 모든 곳에서 삭제/변경된다.

이 과정은 사용자와 인터렉티브하게 진행될 수 있다.
그래서 삭제/변경이 지식 기반에 미치는 영향을 확인할 수 있다.
또한 그렇기에 문장이 어디에 저장되는지는 중요하지 않게 된다.

또한 한번 기억된 문장은 삭제/변경으로도 지식 기반에서 제거되지 않는다.
그냥 "과거의 것"이라 표시되며, 이후에도 확인할 수 있다.
이는 시간과 인식에 따라 사실(참이라 생각하는 것)이 달라질 수 있기 때문이다.
_{datomic 계열의 db로 구현하자...}

이 문서가 제안하는 해답을 어떻게 평가하는가?

뭔가 논문처럼 생긴 글인데...
사실 당장은 명시적인 실험이나 평가가 불가능하다.
지식 기반 툴을 실제로 만들고 사용해볼 수 밖에 없다.

일단 RoamResearch를 이용해서 어느 정도는 따라해 볼 생각이다.
Obsidian은 다 좋은데 글의 일부를 레퍼런스 하는 block ref 기능이 넘 구려서
알아볼 생각이다.

근데 결국 내가 이거 만들지 싶다.

그리고 논문을 쓴다면..
다양한 주장에 대해 빠짐없이 근거나 레퍼런스를 들어야겠지.
그건 개발에 도움이 될 거 같다.

논문을 진짜로 쓴다면, 아마 귀찮아서 안 하겠지만..
백서와 같은 보고서 정도는 쓸 수 있겠다.

참고
해먹 주도 개발
그래프 기반 툴?
개발 방법론: 프로그래밍은 모르는 것을 알아가는 과정이다
설계 문서를 어떻게 써야 하나
소프트웨어 설계와 구현

이 글의 근거라 할 만한 건
내 글이랑 해먹 주도 개발이랑 개인적인 경험 밖에 없음 엌ㅋㅋ
어디 가서 발표하면 싸대기 맞기 딱 좋은 논문이라 할 수도 없는
그러니 블로그에 쓰지 ㅋㅋ루삥뽕

주의: 이 글은 아무런 의미 없는 헛소리입니다 그냥 저장용입니다.
이 글에 대한 비판과 23년 현재 설계에 대한 제 생각은 [여기]서 확인해 주세요