(OLD)설계 표현과 설계 활동에 대한 연구: 쓰라는 논문은 안 쓰고!

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

나는 작년 여름부터 올바른 설계 표현을 찾으려고 노력했다.
그와 동시에 가장 효과적인 설계 활동이 무엇인지도 계속해서 찾았다.

구글 Docs + 폭포수 모델 or 오버띵킹

설계를 표현하기 위해 다양한 매체를 사용해 보았다.

처음에는 구글 닥스 파일 여럿과 [구글 드라이브를 바탕으로 한 위키]​(https://www.youneedawiki.com) 가 설계 표현이었다. 이걸로 했던 거(과거 블로그)

이걸 좀 썼지만... 지금 생각해보면 정말 쓰레기였다.
일단 구글 드라이브가 너무 느려서 못 써먹을 정도였다.

설계 활동으론 뭘 했을까?
이거 할 때 전형적인 "오버띵킹" "폭포수 모델"을 했었다.

한창 리치 히키의 "해먹 주도 개발"을 보던 때인데
나는 해먹 주도 개발을 한다고 생각했지만 실제로는 오버 띵킹을 하고 있었다.

오버띵킹은 문제를 잘 모르거나 문제를 해결하는데 충분한 지식이 없는데 망상만 하고 있는 경우에 발생한다.
머리 속에 담긴 지식이라는 것이 눈에 보이는 것이 아니기 때문에,
설계를 하는 당사자는 자기가 제대로 하고 있는지 오버띵킹을 하고 있는지 깨닫기 어렵다.

내가 경험한 오버띵킹 증상은 다음과 같다.
어떤 기술에 대한 맹목적 믿음 - 이걸 쓰면 (다) 잘 될 것이다
해답이 문제를 해결하는지 확인하지 않음
떠오른 해답만을 생각하고 다른 해결책을 찾거나 생각하지 않음

• 해답을 너무 자세하게 표현함 (폭포수 모델)
• 생각한 아키텍처(해답)를 바탕으로 유스케이스를 쪼개 보는 일
  (필요한 일이지만 해답이 명확해지고 문제의 조건을 만족하는지 확인할 때 해야 한다.)

RDB를 쓰고 처참하게 실패

이 때 가장 기억에 남는 일은
DB 스키마를 구조만 생각하고 실제 SQL을 써보지 않은 것이었다.
정말 별 거 아닌 코드인데, 테이블 4개를 join해야만 했었고,
SQL을 잘 못쓰는 나는 그걸 하려다가 포기하고 만다.
전에는 그냥 하면 되던 일이 상상도 못할 정도로 어려워졌기 때문이다.

나는 SQL에 대한 지식도 적고, 경험도 적었다.
RDB 설계도 부족했다. 그런데도 내가 생각한 해답이 문제를 해결하리라 생각했다.
전형적인 오버띵킹이었고, 나는 파멸했다.

ㅅㅂ 그래도 한달만에 그만 둬서 다행이다 진짜
진짜 끔찍한 실패였다. 별 것도 아닌 프로그램이 거의 손도 못 댈 정도로 개발하기 어려워진 적은 처음이었다.

대가리가 제대로 깨져버린 나는 그 이후에 그렇게 엄청난 실패의 원인이 대체 무엇이었는지 열심히 외양간을 고치기 시작했다

• szmc_data: 다섯번을 바닥부터 다시 짠 프로젝트
• 혼자서 하는 이미지 위주 머신 러닝 프로젝트의 데이터를 관리할 때 RDB가 필요한가?
• (OLD)생각이 없는 프로그래밍: 5번을 새로 짠 머신 러닝 데이터 관리 시스템

지금 생각해보면 그냥 RDB가 내가 해결하려는 문제에 어울리지 않았던 것 같다.
아님 스키마를 잘못 짰거나.

RDB가 안 어울리는 분야가 있다고? 반문하는 사람도 있을 것이다. 니콜라스 센세가 하는 말이 보통은 맞다. 이거 까는 거 아님 ㅇ
성능 문제도 아니고 로깅 하는 문제도 아니고 데이터 모델링 하는 거다. 근데 안 맞았다. RDB 쓰다 좆됬다고 ㅅㅂ

모든 것이 테이블인 건 아니고, 테이블이 안 맞는 분야는 분명히 있다. 모든 것을 C로 짤 수 있지만 21세기에 웹을 C로 짜는 정신 나간 놈은 없는 거랑 비슷하다.
재수 없게도 내가 그 바닥의 문제를 풀고 있었다.
그런데도 나는 ​데이터베이스(= RDB)​를 쓰면 데이터 모델링 문제가 해결될 것이라고 굳게 믿고 있었다.

그 이후로는 모든 것을 의심하게 되었다. 이렇게 해도 괜찮을까? 그래도 될까?
왜 XXX를 썼는데도 코드가 쓰레기 같을까?

아무튼 첫번째 설계 표현 / 활동은 참담한 실패 그 자체였다.

Notion, Obsidian, Roam Research

두 번째 설계 표현으로는 노션을 쓰기 시작했다.
https://blog.naver.com/rhdnfka94/222132792071

노션의 문제점은 문서간 링크가 거지 같다는 점이다.
그 외에도 토글로 접고 펴는 게 커질수록 줫나 느려졌다.

설계 활동은 그냥 문서 열심히 작성 하는 거였다.
draw.io로 그림 열심히 그리고...

이 때 만든 설계의 결과 작성한 건 딱 모듈 DSL 하나다.
이 때 설계가 지금도 어느 정도 남아 있다만 지금은 또 다르게 고쳐졌다.
노션으로 쓰다보니 결국 문서를 하나만 쓰게 됬는데, 그게 영 안 좋다고 생각했다.
​문서 여럿을 보는 것이 여러 측면에서 문제를 생각하게 하는 것 아닐까?
​하고 생각을 했다.
그러다가 옵시디언과 롬 리서치를 알게 되었고,
제텔카스텐이란 방법론을 알게 되었다.

결국 노션 거지 같아서 옵시디언으로 갈아타게 된다.
https://blog.naver.com/rhdnfka94/222199401538

위 블로그 글을 보면 알겠지만
이 때는 다양한 설계 문서의 표현과 그래프로 연결된 생각이 설계 표현의 중요한 요소라 생각했다.
https://blog.naver.com/rhdnfka94/222199619945

옵시디언으로도 문서를 꽤나 많이 만들었는데... 위에 저게 다 문서다.
이거 만들면서 뭔가 짰던 코드는 ​딱히 없는 거 같다
이거 하면서 얻은 건 대략적인 디플로이 다이어그램 정도?

근데 해보니까.. 해답이 문제를 정말로 해결하는지 확인하는 데 필요한 건 그래프로 연결된 문서가 아니었다.
그 보다는 "문장" ref가 더 중요했다.
문제를 해결하는 해답이 갖춰야 하는 다양한 조건을 문장 여럿으로 표현하고,
해답이 그걸 만족하는지 하나 하나 확인하는 작업이 필요했다.
해답이 여럿이라면 테이블을 쓰는 것도 좋다.

근데 옵시디언은 둘 다 부족했다. 테이블은 마크 다운 테이블이라서 쓰기 줫나 번거로웠고
문장 ref는 이딴 식이었다.

저렇게 블록을 ref하면 앞 뒤로 공간을 펑펑 띄워둬서 개빡친다. 세세한 ref가 불가능하다.

결론 내리자면 옵시디언은 제텔카스텐 용으로는 훌륭하지만 설계 문서 표현으로는 별로였다.
지금도 단순 메모 용도로는 구글 닥스 대신 잘 쓰고 있다.

설계 활동은 별 거 없다. 그냥 열심히 문서를 썼다. 그리고 해답이 문제의 조건을 잘 만족하는지 확인하려 했다
그러다 빡쳐서 갖다 버림 ㅇㅇ

그래서 나는 결국 한달에 만 오천원 내는 롬 리서치를 문서 표현으로 선택하게 된다.
이것도 한 한달 쯤 썼더라. 확실히 문장 단위 ref와 위지윅 테이블(여전히 구리지만)도 꽤 괜찮았다.

문장 ref가 작게 문장으로 들어간 모습이다.

설계 활동으로, 밤마다 자기 전에 모니터에 문서들 여럿을 띄워놓고 이리저리 보다가 잠들곤 했다.
그러면 자면서 생각을 할거라 생각했다.
근데 이래 봤자 큰 의미가 없다는 생각이 점점 들기 시작했다.

이 때도 문서를 정말 많이 만들었는데, 지금 생각해보면 의미 있는 문서도 있지만 별 의미 없는 문서도 더러 있었던 것 같다.

그리고 문장이 이곳 저곳에서 ref되고 embed 되는데 어디서 왔는지, 무엇을 의미하는지 알기 힘들었다.
지들 말로는 문장을 어디에 저장하든 ref할 수 있으므로 걍 아무 곳이나 저장해도 되고
중복을 제거하기 매우 쉽다고 광고는 하는데 응 아니였다. 중복 존나 심하고 계속 어디 넣을지 생각해야 했음
그래프는 이번에도 아무짝에도 쓸모가 없었다.

사실 문장 ref 보다 ​문제와 관련된 것(미지, 사실, 조건, 해답)들을 한 곳에 모으는 것​이 더 중요했다고 생각한다.

이 설계 방식으로 그림을 많이 그렸다. 몇가지는 도움이 되었고 지금도 도움이 되고 있다. (그림 자체는 draw.io로 그렸다. 설계 중에 그렸다는 거다)
https://blog.naver.com/rhdnfka94/222224393428

그리고 작은 모듈 하나를 설계했고, 성공적으로 코딩했다.

그러나 나는 아무래도 뭔가 머리속에서 정리된다거나 정답으로 나아간다는 느낌이 들지 않았다.

몰입

그러다가 황농문 교수의 "몰입" 책을 읽게 된다.
http://www.yes24.com/Product/Goods/2783642

어떤 문제를 해결하기 위해 그 문제만을 생각하고 또 생각하고 그냥 그것만을 위해 삻을 사는 것이 바로 "몰입"이다.
수많은 천재들이, 거의 모든 천재 과학자(뉴턴, 아인슈타인, 파인만)들이 몰입을 했다고 하며
그렇게 몰입하는 방법과 자신이 체험한 몰입 경험과 그걸 통해 해결한 문제와 논문 등을 소개한다.
그리고 그것이 인생을 달라지게 했다고 한다.

저자는 "몰입" 경험이야 말로 인생을 행복하게 해주는 진정한 방법이라고 한다.
이렇게 보면 무슨 사이비 자기개발서 같지만 실제로 과학적인 토대가 있는 이야기다.

사실 나는 몰입에 대해서 약간은 알고 있었다.
그리고 내가 과제를 하면서 직접 일주일 정도 몰입 상태를 경험한 적도 있었다. (그 다음 손이 아파서 병원에 다녀야 했지만...)
https://blog.naver.com/rhdnfka94/222029970212
https://blog.naver.com/rhdnfka94/222021998539

굉장히 재미 있는 경험이었기도 했다.

이걸 경험해본 사람은 알겠지만, 문제를 풀기 위해 그야말로 무아지경으로 빠져들게 된다.

이걸 하던 때에는 생각하고 생각하고 코딩만 계속했다. 다른 취미니 웹서핑이니 그딴 것도 없었다.
데드라인이 급하기도 했고 그냥 코딩이(PBT를 썼었다) 재미있기도 했다.

황교수의 책은 "코딩"과 같은 활동이 아닌 "생각"을 통해서 몰임 상태에 다다르자고 한다.
이건 해보고 있는데 좀 많이 어려운 듯..

약간 삼천포로 빠졌지만, 리치 히키의 해먹 주도 개발도 비슷한 이야기를 했다.
사실 지금 생각해 보면 ​리치 히키는 설계 표현 따위 보다 생각을 하는 것을 더욱 강조하고 있었다.
https://blog.naver.com/rhdnfka94/222131927156

비로소 깨달은 점은 ​설계 표현보다 설계 활동이 더 중요하다​는 점이었다.
그동안 너무 설계 표현에 집착했던 것 아닐까? 하는 생각이 들었다.

그리고 더욱 중요한 것은 ​오로지 문제만을 생각하기 위해 다양한 입력을 없애야 한다는 점이다.
몰입에서도 나오는 이야기다.
문제에만 집중하기 위해 게임, 영화, 애니메이션, 만화, 소설, 웹서핑, 커뮤니티, 인간관계, 모든 것을 (최소한 잠깐이라도) 끊어야 한단다.

그래서 이제 어떻게 하고 있냐고?
입력을 끊으려면 어떻게 해야 하는지 생각했다.
그리고 곧 ​컴퓨터를 보지 않아야 한다​는 결론을 내렸다.

하지만 설계 문서는 작성해야 했다. 모든 것을 기억할 수는 없으니까.
결국 설계 문서를 인쇄하자​는 생각을 했다. 그리고 문서를 들고 그것만 계속 보고 생각하는 것이다.
그런데 롬은 꽤 괜찮은 툴이었지만, 인쇄 기능이 없었다.

그래서 나는 다시 구글 닥스를 이용하기로 했다. 단, 문서는 딱 하나만 써서 인쇄하기 편하게 했다.

이렇게 문서 하나에 여러 페이지로 설계문서를 작성하면 문서 하나만 인쇄하면 모든 내용을 인쇄할 수 있어 편하다.
문서를 가로로 눞히고, 각 페이지 하나의 내용에 관련된 내용을 쓰기로 했다.
쓸데 없이 모든 걸 다 적지 않고, 지금 생각하는 문제와 꼭 연관된 것만 적었다.
페이지마다 문제의 제목과 id를 붙이고 문장에도 필요하면 id를 붙였다.
그리고 인용한 문장에 밑줄을 긋고 id를 붙이는 식으로 ref를 아날로그로 표현했다.

표현보다 중요한 것은 설계 활동이다.
이제 설계 문서는 설계의 핵심이 아니라, 그냥 하드디스크 수준의 보조 기억 장치일 뿐이다.
문제의 해답을 내기 위한 생각을 할 때, 이제는 모니터 앞이 아니라 책상 앞에 앉기 시작했다.

^{이건 사실 컨셉샷이다 ㅋ}

지금 생각하려는 주제에 필요한 문서들을 책상위에 올려두고 (HDD)
손에 가장 가까운 곳에는 텅 빈 A4를 올려둔다.(RAM)
그리고 편한 의자에 눕듯이 앉아서 눈을 감고 띵킹을 한다.
그러다 좋은 생각이 나거나 남겨야 되겠다 싶으면 종이에 기록을 한다.

그림이든 표든 문장이든 자유롭게 표현한다.
샤프를 이용한 손그림의 압도적인 자유도가 매우 중요하다.​

앉는게 힘들어 지면 누워서 한다. 눈 감고 생각하다가(자면 안되니까 안 피곤할 때만 했다) 필요하면 종이에 기록한다.
RAM에 충분히 내용이 모였으면 적당히 정리한다.
한 숨 자거나 하룻밤이 지난 뒤에 RAM을 다시 꺼내서 내용을 보고
HDD에 영구히 남겨야겠다 싶으면 컴퓨터를 켜고 구글닥스에 내용을 기록한다.

만일 설계 문서가 잘못 되었다면 가차없이 버린다. 이런 식으로.

그 결과 얼마 되지 않은 시간(7일)만에 설계에서 많은 진척이 있었다

• 유스케이스를 구현할 구체적인 방법을 알아내었다
• 시스템의 큰 그림을 좀 더 구체적으로 그릴 수 있게 되었다.
• 기존에 복잡하던 모듈의 설계를 더 작게 리팩토링할 수 있었다.
• 기존에 불명확하던 모듈을 명확히 할 수 있었다. https://blog.naver.com/rhdnfka94/222272002408

솔직히 말하자면 입력을 완전히 끊은 것은 아니다.

만화를 조금 봤고 깃헙 갤러리도 틈틈이 봤다.
그래도 낮에는 늘 폰을 꺼 두었고, 밤에 돌아 와서 한 두시간 정도만 봤다.
웹서핑으로 시간을 보내거나 커뮤니티에 죽치고 있지는 않았다.

또한 출퇴근 길과 화장실 갈 때 폰 대신에 수첩과 펜을 들었다.

^{돌아다니면서 적은거라 졸라 더럽다}

이런 식으로 계속 이것만 생각하려고 노력했다.

아무튼 아날로그 방법과 입력 줄이기로 꽤나 효과를 보았다.
어쩌면 표현이니 인쇄니 다른 거 다 필요 없고 입력을 많이 없애고 계속 생각하려고 노력한 것 때문일지도 모르겠다.

이제 일주일이지만, 벌써 효과가 나오고 있다.
모든 것이 끝나고 나서도 한번 이야기를 해보겠다.

지금 설계 표현 / 설계 활동의 문제점은 다음과 같다.

• 구글닥스는 역시 불편하다. 문장 ref는 역시 좋은 기능이다. 그걸 제일 잘 해주는 roam은 인쇄가 안 된다...
• 필기에 의존하는 경향이 있다. 하나의 생각을 오래 하지 못하고 자꾸 다른 생각을 하게 된다. 명상 비슷한 연습을 해야할지도.

결론

여기까지가 내가 탐구하고 실험해본 설계 표현 & 설계 활동이었다.
결론을 내 보자.

설계 표현

• ​설계 표현은 반드시 인쇄해서 볼 수 있어야 한다.
• 모든 것을 설계 문서에 적지 마라. 먼저 자유롭게 생각을 종이에 기록한 뒤, 영구적으로 필요한 것만 남겨라.

설계 활동

• 문제와 관련 없는 불필요한 입력을 최대한 줄여라
• 모니터가 없는 책상에서 설계하라. 설계 문서를 출력해서 봐라.
• 오직 문제만을 생각하라. 계속해서 문제만 생각하고 또 생각하라.

지금도 설계 표현과 설계 활동을 어떻게 해야하는지 계속해서 연구하고 실험해보고 개선하고 있다.
이번에 시도한 방법이 좀 breakthrouth 같아서 글로 공유해 보았다.
다음에도 기회가 있으면 그 때는 어떻게 변했는지 알려주겠다. 내가 죽기 전까지는 계속 발전시킬 거다...

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