PAVDUP's DO Something

장단점

기존 옵시디언의 장점이라고 생각하였던 내용이 마크다운 등이 표준을 가지지 않는 등의 문제점으로 인해, 잘 맞아떨어지지 않는다는 것을 알게 되었음.

이에 따라 옵시디언의 장단점을 새롭게 정리.

Obsidian 장점 :

1. Graph View (문서 사이의 연결과 흐름을 파악할 수 있는 것은 가히 가장 좋음.)
2. 읽기 쉬움 (표준화된 기록 방법을 사용하므로 - 제한되어 있으므로. 형식이 정해져 있음.)
3. 해당 형식의 지원 자체는 계속 이어질 것 (결국, 마크다운이라는 간단한 텍스트 파일 형식을 사용하므로)

Obsidian 단점 :

1. 컬러드 텍스트가 불가능 (설령 사용한다해도, CSS 스니펫을 사용하여야 하는데, 치고 넣는 과정 등이 굉장히 번거로움.)
2. 마크다운 방식 자체가 표준이 존재하지 않음. -> 출판 등, 글로써 결과물을 낼 때 번거로움. (해당 텍스트를 해당 화면에 맞게 한번 더 다듬는 공정을 거쳐야 함.)
3. 쓸 때 제한적 (읽기 쉽고, 쓰기 쉽게 만들기 위해서 오히려 기능이 부재함으로써 발생하는 문제. 컬러드 텍스트를 비롯, 많은 것을 표현하기가 까다롭다.)

(사실상 옵시디언의 단점이라기보다도 마크다운 그 자체가 가지는 단점이라고 볼 수 있을 듯 하다.)

개선

1. Colored Text

이에 따라 다른 툴 - Scrivener 을 물색하거나, 옵시디언이 가지는 문제를 개선하고자 하였다.
컬러드 텍스트 등이 적용되지 않아 글이 직관적으로 표시되지 않는 문제는 템플릿과 Style Setting을 이용한 직관성 강화를 통해 해결하였다.

• 예시 :
  • 이탤릭이에용 이걸로 강조를 표시할 수가 있겠죠?
  • 볼드표시에용. 이걸로 강조를 표시할 수가 있겠죠?
  • 굵게 기울여볼게요?
  • > 를 이용한 인용도 있긴 하지만, 이건 단락이 끝나야 끝난다. (\를 통해 특수 기호를 실제 타이핑에서도 활용할 수 있다.)
  • 이걸로 밑줄이 표시될까요? // 이건 html 문법인 것 같네요!
  • ===> Escape를 원하지 않는 문자열은 이렇게 표시할 수 있어용==
  • *==이런 하이라이트도 이 템플릿에서는 지원합니당!
  • **==색이 다 다르네용!

(Blue Topaz 테마와, Style Setting을 이용하여 다른 색깔로 나타나도록 정리하였다.)
(부분적인 글자 혹은 문장에 style을 적용하는 것 또한 가능하다.)

2. 마크다운의 표준

마크다운의 표준에 차이가 있는 것은 사실이다. 하지만, 이건 Tistroy 등에서 사용할 때가 보통 대다수이고, Github 에서 사용하는 마크다운 문법과 Obsidian 에서 사용하는 마크다운 문법의 경우엔 크게 차이가 존재하지 않는 것으로 보인다.

또한 이건 서식이 없는 문자 (마크다운) 으로서 정리되어 있는 것이기 때문에 문제가 발생하는 것이므로, 이를 해결할 수 있는 방법도 여러 방법이 존재한다.
Viewer Mode에서 복사 붙여넣기를 이용하면 Obsidian 의 서식을 가진채로 복사되며, Obsidian의 pandac plug-in을 활용하면, 바로 word 로 뽑아낼 수 있다.

3. 쓸 때 제한적

표현이 까다로운 문제는 대표적으로 개행이 있다. 쓸 때 아무리 개행을 많이 하더라도, 실제로 볼 때 해당 개행이 반영되지 않는다는 것인데, 이는 마크다운의 자체적인 문법이다.
현재 글에서 작성하는 것처럼 Header 를 효과적으로 이용하는 것이 개행에 큰 영향을 미칠 것으로 보인다.

pandac의 경우, plugin 활용방법을 아직 제대로 학습치 못했으므로 이를 학습할 필요가 있다.

메모 :

제텔카스텐을 종이로 직접 노트로 적는 것과, 디지털 노트화 (Obsidian 등의 툴을 이용하여 이렇게 전산화 및 타자로.) 하는 것. 두 가지가 차이가 있다는 주장이 존재한다.
주장의 결론은 다음과 같다.

• 종이 노트로 하는 것이 우리의 생각을 정리하는데 더 큰 도움을 준다.
• 지식을 소화할 수 있는 시간이 충분해야 한다.
• 종이 노트를 이용한 제텔카스텐 기록 방식은 이를 강제한다.

결론 : 종이로 작성하는 것이 기록의 방식에서 좋다. 왜? 소화와 생각의 정리에 있어서 더 좋기 때문에.

하지만, 이에 대한 개인적 의견을 내놓은 다른 의견도 존재하였다. 이에 주목해보자.

• 디지털 등의 편리한 도구를 사용하느냐 보다는 메모나 기억이 -> 지식을 활용하는 맥락을 (환경)을 반영하고 있는지 -> 가 중요하다.
• 제텔카스텐은 우리의 인지과정을 보조하는 도구이며, 이에 따라 다양한 목적으로서 활용될 수 있다.
• 정해진 분량이 존재한다 하자. 이에 맞게 학습할 내용을 변형 및 요약하려 할 때, 우리는 해당 내용을 자연스럽게 학습하게 된다. => 단, 해당 요약은 오히려 비용이 더 많이 드는 경우가 많고, 내용을 요약 및 정리하는데 인지와 노력을 기울이다 오히려 내용을 제대로 이해하지 못할 수 있다.
• 이 사람이 말하고 있는 바는 체화된 인지에서 분화된 개념인 분산된 인지에 기반을 두고 있다. 인간과 상호작용하는 환경 또한 '사고 (생각)'나 인지의 일부분이라는 이론.
• 이러한 분산은 보통 "다른 사람", "외부 환경 (메모나 기록 등)", "시간 (알람)"으로서 나누어 진다.

결론 : 우리의 사고(생각)는 머릿속에 존재하는 것 뿐만이 아닌, 다른 곳에 분산된 정보들 또한 포함한다. 즉, 머릿속에 들어있을 필요가 없다. 제텔카스텐(메모)은 우리의 또 다른 사고(정보)이기 때문이다. 이에 따라, 해당 메모가 그 내부에 해당하는 정보와, 그를 사용할 수 있는 맥락과 환경에 관한 정보까지도 함께 포함되어 있는지가 중요하다.

-> 이에 대한 나의 생각 :
종이 노트, 태블릿 등의 전자노트를 작성할 때 오는 이점도 분명 존재한다고 생각한다. 글이나 해당 내용을 보고 계속 생각하여 기록하고 나만의 언어로 풀어쓰므로, 자신의 언어로 바꾸는 과정이 더 잘 일어난다. (즉, 해당 내용이 머리에 좀 더 잘 박힌다.)

또한, 무언가를 그려내고, 도식을 짜내려 가기가, 손으로 기록할 때 훨씬 쉽기 때문에, 여기서 오는 강점 또한 분명 존재할 것이다. 이렇게 제한된 양식의 글로써 작성하는 것보다 자유로우니까.

제텔카스텐이 분산된 사고라고 하였을 때, 이 이점은 상관없어 지는가? => 내 생각은, 아니다.
머릿속에 더 깊은 이해를 가지고 있어야 해당 기술을 더 잘 활용할 수 있을 것이다. 또한 자유로운 작성과 도식화는, 이해의 과정에 있어서 큰 강점을 가진다.

**-> 흠,,, 그럼 Obsidian을 통해 제텔카스텐을 구현하는 것에 대해 재고해봐야 하나? (오프라인 기록이 가지는 효용이 더 크므로?) 이를 사용했을 때 얻을 수 있는 이점이 어떤 게 있을까?

• 좀 더 빠른 기록
• 제한된 양식으로 인해 '읽'고 '쓰'기가 쉬움.
  (일반적인 책들의 형태가 이로써 기억되어 있음을 생각하면 + 잘 활용하였을 때, 내가 노트에 필기해둔 것보다 읽기는 더 쉬울 것임. / 또한 쓰는 관점에서, 다양한 기능들을 활용하는 것보다, 제한된 양식에 따라 해당 내용을 분류하여 기록하는방법의 효용성을 알고 있고, 실제로 내가 내용을 분류할 때도 제한된 양식으로 체계화시키지 않던가.)
• 표준화된 기록양식을 사용하므로, 다른 사람들도 '읽기'가 쉬울 것.
  이는 글로써 출판하는 등의 결과물을 내었을 때 다른 사람이 더 읽기 쉬움을 의미하기도 함.

오프라인으로 기록하였을 때 가지는 효용은 위쪽에 적어둔,

• 나만의 언어로 작성하는 과정과, 내용과 정보를 되새기고, 소화하는 과정이 더 잘 일어남.
• 자유로운 작성으로 인한, 쉬운 도식화 - 내용의 연결 - 필기 등.

떠올리지 못한 장단이 많겠지만.
지금 직관적으로 바로 떠오르는 것들은 이와 같다.
장단을 파악하여, 효과적으로 활용할 수 있도록 하자.

하나를 중심에 두고 (정보 자체를 하나의 뇌처럼 여길 때, 활용하기 쉬운 하나의 공간에 기록하는 게 더 효율적일 것) 다른 많은 것들도, 필요에 따라 용이하게 활용해나가는 것이 권장되지 않을까 한다.
(제텔카스텐에 다시 이용할 수 있을 만큼의 양질의 정보를 기록하고, 노트는 사고의 흐름 일련의 과정, Fleet Note 를 작성해나가는 용도로 사용한다던가.
혹은 도식화와 흩어진 사고를 작성해두는 용도로 사용한다던가.)

출처 (References) :

• https://gall.dcinside.com/mgallery/board/view/?id=reading&no=403616

연결 문서 (Linked Documents) :

• [[종이 필기 제텔카스텐 앱]]

https://gall.dcinside.com/mgallery/board/view/?id=singlebungle1472&no=629525&exception_mode=recommend&page=1

해당 사이트에 재밌게 풀어진 내용에 더해 자료조사 하여 추가적으로 정리하였습니다.

아쉽게도, 따로 질문 혹은 주제가 따로 나오지 않았다! 또한, 나 스스로도 하는 일이 바빠 계속 병합 및 퀄리티 상승 등을 진행하였다!

학부연구생으로서 진행하는 VR 콘텐츠 제작은 현재, 각 단계를 병합하는 마지막 단계인데, 이 때 생각보다 예기치 못한 오류가 많이 생겨났다. 해당하는 오류들은 다음과 같다.

1. 기존에 구현했던 Fade in - out 이 되지 않음.

2. Sister 등, 바깥에 표시되던 UI 들이 표시되지 않던 문제.

3. robot을 움직이는 범위 제한이 예기치 못한 상태로 움직이는 문제.

4. waitforsignal 등이 제대로 동작하지 않는 문제.

이때, robot을 움직이는 범위제한이 제대로 동작하지 않는 것은. 해당 Boundary가 이동하여도, track 되는 크기 자체는 world 좌표에 기반을 두고 있기 때문이었다. 이를 해결하기 위하여, robot의 움직임 로직 자체를 다시 제작하였다.

=> robot이 중심에 있고. robot이 움직일 방향을 결정하는 trackball이 controller의 입력을 따라 결정된다. trackball로 robot은 lerp 하게, 순차적으로 보간되어 움직이며, 만약 track boundary를 빠져 나간 경우, robot은 해당 trackball을 추적하지 않는다.

=> 해당 코드의 logic을 구현한 후, 해당 기능을 구현한 controller presence class가 component로서 두 개 존재하기 때문에, 이를 고려해 주어야 하는 등, 예기치 못한 상황이 발생하였으나, 결과적으로는 잘 구현하였다.

이후, neg point changed 가 동작하지 않는 문제의 경우, if else~ 로 구현된 구조를 잘못 파악하고 있었던 굉장히 단순한 문제였다. 이의 경우 해결하였다.

이후, 제일 시급한 문제들을 여럿 해결하고 나니, 부자연스러운 여러 문제들이 여전히 존재하였기 때문에 (Camera의 시야가 처음 달랐다가 나중에 갑자기 바뀐다던가. Camera의 시야가 중심에 맞지 않는다던가. User가 답안을 선택하는 육각형의 UI 위치가 제대로 보이지 않는다던가.) 계속해서 퀄리티를 업그레이드하고, 해결해나갈 예정이다.