어플리케이션 흐름의 구조와 분석.

우리들은 수많은 서비스와 정보들의 홍수 속에서 살아가고 있다.

난 소비자로서 좋은 서비스에 대한 선택과 고민을 해왔고, 또 만들고 싶은 프로그램에 대한 고민을 해왔다.

그리고 이제 그 해답에 대한 갈피를 조금이나마 잡은 듯하다.

이상적인 제품에 대한 계획(?)같은 해석에 관한 것은 추후 내가 만들어보고 싶어서 빠졌지만,

이 글을 통하여 각종 어플리케이션들이 차지하는 위치와 구조에 대하여 설명하고자 한다.

1. 구조(Structure)와 사상하는 프로그램.

다양한 서비스와 어플리케이션들을 사용해보고 해당 어플리케이션의 본질에 대하여 한 문장씩 정리해보았다.

그 후 카테고리 별로 정리를 하였다.

1.1 입력(Input).

정보를 저장전에 사용됨.

입력: 정보를 저장하기 위해 받아들임.

(내부)

• 내부 컨텐츠: 공유(SNS)등 내부 계정들을 통한 정보, Create에서 생성되는 정보 등.
  

(외부)

• 외부 컨텐츠: Mail이나 타사 서비스들.
  
• 카메라: 이미지 입력.
• IME: 글자 입력 .
  

1.2 저장(Store).

정보를 활용하기 위해 저장.

메모: 현재의 정보를 미래로 전달.

(시간)

• 시계: 시간을 보여줌, 시간에 따른 알람, 스톱워치, 타이머.
• 달력: 달력과 그에 따른 일정을 보여줌.
• 일정: 일정을 시간 또는 내용으로 표시.^[각주:1]
  

(정보)

• 서지관리: 메타데이터를 이용한 레퍼런스(출처) 관리.
  
• Read it Later: 북마크와 클리핑.
• 노트: 간단한 서식의 글, 그림, 표등을 표현.
  
• 드로잉: 펜이나 붓같은 느낌이 나는 도구로 그림을 그림.
• 스티키 노트: 위젯 형태로 보여줌.
  
• 기타: 사진, 영상, 음성등의 데이터로 남기는 모든 행위.
  

클라우드: 정보를 다른 곳에서 쓸 수 있게 처리.

(저장)

• 주소록: 주소 저장 및 관리.
  
• 드라이브: 파일 저장 및 관리.
• VCS: 버전 관리.
• 백업: 정보들을 백업.

1.3 창조(Create).

저장된 정보를 이용하여 새로운 정보를 만들어냄.

마인드맵: 정보를 연결하고 관계를 지음.

(리스트): 순서대로 정렬함. 정보에 변형이 없다는 것이 특징.

• 마크 업: 정보를 써내려 가며 강조함.
• 워드프로세서: 문서 작성(종이나 인쇄를 목적)
• 프레젠테이션: 발표용 문서 작성(디지털 목적)
• 웹브라우저: 웹문서 보기.
  

(합성 or 연산): 정보를 합침. 상쇄 및 보간간섭, 가산 및 감산혼합과 같이 일반적인 정보를 합칠 수도 있고, 크기 조절이나 주파수 변조처럼 추상적인 성질을 합칠 수 있다.

• 계산기: 수를 계산.
• 스프레드 시트: 정보를 쉽게 정리.
  
• 수치해석: 해의 근삿값을 구해줌.
• Computer Algebra System(CAS): 전통적인 대수학을 푸는 것처럼 값을 구함.
• DB: 정보 체계화 및 관리.
• 통계: 수량적인 비교로 분석.
• 비트맵: 픽셀을 기준으로 다루기.
• 편집: 사진이나 그래픽에 그래픽 처리를 위한 것.
  
• 보정: 화이트밸런스, 노출값등 카메라에서 지원하는 요소들을 수정.
• 페인팅: 브러시를 사용해 그림.
  
• 벡터: 색상과 위치 속성등을 이용함.
• 일러스트: 2D 그래픽 도구.
  
• CAD: 정밀한 설계를 위한 것.
• 기타 3D 프로그램: 폴리곤, 넙스, 서브디비전 등.
• DAW: 오디오의 레코딩, 편집등.
• 기타 이미지, 음성, 영상처리.
  

컨텐츠: 각종 결과물.

책, 영화, UCC, 사진 등으로 불리는 것들.

1.4 전달(Trans).

디지털 세계 내외부로 전달함.

내부

(공유)

• 메신저: 정보를 단위매체(텍스트, 사진 등)로 다른 사람이나 그룹에게 전달하고 받음.
• 블로그: 정보를 자신 또는 불특정 다수의 사람들에게 보여줌.
• SNS: 정보를 가깝거나 비슷한 그룹의 사람들과 주고 받음.
  
• 커뮤니티: 정보를 불특정 다수의 사람들에게 주고 받음.
• 카페: 대형 포털에서 제공하는 커뮤니티 서비스.
  
• 위키: 정보를 다수의 사람들이 수정 가능하고 공유.

-> 권한의 문제.

외부

(출력)

• 알림: 신호를 전달.
  
• 뷰어 or 플레이어: 디스플레이로.
• 프린터: 종이로 ..etc
  

원래 형태는

와 같았는데 입력에 해당하는 기능들이 많아 편의를 위해, 분산을 위하여 분리하였음.

1.5 자동화(Automation).

위의 과정을 자동적으로 순환시켜줌.

• 매크로: 몇가지 정해진 절차를 실행.
• RPA: 체계적으로 프로그래밍한 매크로.
  
• AI: 자동으로 매크로(또는 함수등)를 만들기 위한 것.[Meta Macro]
  

그 후 핵심적인 기능들에 대한 관계도를 처음과 같이 만들었다.

2. 구조 분석.

이 파트에서는 어플리케이션 흐름에 대하여 집중적으로 설명한다.

2.1 전반적인 구조.

우선 정보가 돌아가는 전반적인 구조에 대해 생각해보자.

디지털을 다루는 가장 원초적인 언어인 어셈블리를^{[각주:2][각주:3]} 생각해보면 정보는 입ㆍ출력(Import ㆍ Export), 메모리 접근(Memory Access), 데이터 처리(Data Processing), 분기(Branch) 정도로 나뉠 수 있다.

어플리케이션도 디지털 정보를 다루기 위한 SW이고, 사람 인지능력의 한계 때문에 각자 '특화'된 영역이 존재하게 된다.

따라서 전체 구조를 보면 마치 프렉탈처럼 대응되도록 분야가 나뉘어지게 된다.

때문에 이 구조에서 벗어나기가 어렵다고 생각한다.

• 입출력=>Trans
  EXPORT된 정보를 IMPORT하는 것처럼 정보를 입력받고(Input), 디지털 세계 내외부로 전달(Trans)
  
• 메모리접근=> Store
  STR, LDR처럼 저장^[각주:4]한다.
  
• 데이터 처리=> Create
  ADD, MOV처럼 연산하거나 옮기는 등의 작업을 하여 새로운 정보를 만들어낸다.
  
• 분기=> Automation
  MACRO, IF처럼 어떤 작업 도와주거나 특정조건시 행동을 하도록 해줌.
  

또는 MVC 모델처럼 Model=>Store, View=>Trans, Controller=>Create로 치환할 수도 있다.

실제로 카테고리 정리 후 마지막으로 추상화단계를 거칠때 두개 다에서 조금씩 영감을 받았다.

사실 촘스키 언어 계층을 이용해 튜링머신과 관련해서 쓰고 싶었으나 좀 귀찮아서..

만약 학사 논문을 작성하게 되면 수직계열화 또는 어플리케이션과 오토마타 관련해서 써볼까 생각중이긴 한디..

2.2 심층적인 구조.

각 모듈별로 조금 더 자세히 살펴보도록 합시다.

역시 관리의 편의성을 위해

Input을 분리하였다.

2.2.1 Input.

내부에서 생성된 정보를 받아들이는 In, 외부의 정보를 받아들이는 Out으로 나뉘어져 있다.

내부라는 것은 하나의 계(System) 안에서 내부를 뜻하는 것으로, 계정 또는 서비스를 기준으로 삼을 수 있다.

위에서도 썼듯이 각각에서 대표적인 프로그램은

In: 뉴스피드나 새글 목록 같은 구독 프로그램

out: 카메라, IME(입력기), 외부 서비스(사용중인 계정이 구글이라면 MS 계정은 외부 서비스가 된다.)

2.2.2 Store.

아마 가장 고민이 많았던 파트가 아닐까 싶다.

말이 Time과 Space로 나뉘어져 있지 저 둘은 위에서 보면 알 수 있듯 메모와 클라우드의 속성을 그대로 옮겨놓은 것이다.

클라우드가 메모보다 상위의 개념에 속하지 않냐고 물을 수 있는데, 아니다.(단호)

메모는 정보를 미래로 전달하는 것이 목적이고, 아날로그 데이터는 물론 단순한 텍스트 파일, 이미지, 영상 등 형태를 가리지 않고 미래로 정보가 전달된다는 조건만 맞으면 된다.

반면 클라우드는 네트워크에 연결된 다른 장치를 이용해 저장하는 것으로 정보를 전달하려는 순간 이미 시간에 종속적이며(광속에 가깝다 하더라도 약간의 시간이 필요), 또 다른 컴퓨터라는 공간이 필요하다.

물리학적으로 메모는 시간에만 종속적이만 클라우드는 시공간에 종속적이므로 메모는 클라우드보다 추상화된 개념일 수 밖에 없다는 뜻이다. 하이데거 존재와 시간 같은 것을 보아도 마찬가지다. 존재와 실존은 시간 속에 있다.

설사 미래에 양자 얽힘과 같은 것을 이용해 시간의 제약을 깬다고 하더라도 공간은 가역적이지만 시간은 비가역적인 성질 때문에 상위에 속한 개념일 수밖에 없다.

메모와 클라우드의 개념은 시공간이란 가장 높은 추상화가 이루어져 있는 단계이므로 어떤 서비스에서든 사용이 되고 가장 핵심이 되는 중요한 서비스라 생각한다.

여기에서 또 드는 의문은 각종 SW나 정보들은 오프라인 환경에서도 사용할 수 있는데 어떻게 Space가 클라우드냐는 생각이 들 수 있다.

이에 대한 간단한 대답은 인간의 뇌를 컴퓨터로 취급하고 사람이 컴퓨터와 상호작용을 한다면 오프라인 상태의 컴퓨터와 네트워크로 연결이 된 상태로 볼 수 있다.

'인터넷 망 네트워크'가 아니라  '데이터 관점의 네트워크'라는 것이다.

클라우드 계열에 속하는 프로그램중 아주 재미있는 것이 있다.

Git이나 SVN 같은 VCS(Version Control System)이다.

시간의 특성을 제대로 보여주는 것 중의 하나인데, 시간이 흐른다는 것은 무엇일까?

바로 상태가 변했다는 것, 상호작용이 이루어졌다는 것 자체이다.

위키 서비스를 운영 중인데 10명의 사람이 편집한다고 해보자.

1년이 지났어도 여전히 10명의 사람만이 편집한다고 해서 시간이 흐르지 않은 걸까?

위키내부의 문서가 바뀌고, 각종 토론 내역 같은게 있으니 계(System)의 상태는 과거와 다르다.

반면, 10년동안 모두가 아무 활동이 없었다고 하다면 계의 상태는 과거와 같다고 할 수 있다.^[각주:5]

VCS는 상호작용 내역을 저장해 과거 버전과 오고가고 하여 시간의 비가역성을 일부 극복해낸 프로그램이다.

어쨌든 클라우드 서비스는 사람이 특별히 인지하지 않아야 이상적인 서비스지만 메모는 사람이 인지하도록 만들어야 한다는 것도 그렇고.. 메모와 클라우드는 서로 상호의존적인 관계이다.

그래서 오피스 솔루션이 없던 드롭박스, 박스와 같은 클라우드 플랫폼도 메모 사업에 뛰어드는 경우가 많다.

Dropbox 블로그와 Box 커뮤니티에서 가져왔다.

2.2.3 Create.

자료를 연결하여 새로운 가치를 창출하는 포지션이다.

자료의 연결은 크게 두가지 형태로 나뉘어지는데

원자료의 값이 출력시 그대로 반영되는 리스트^[각주:6]

예.

• 리스트 인자1
• 리스트 인자2
  

와 출력시 달라지는 함수형태

예.

$$function(함수 인자1, 함수 인자2)$$

이다.

그리고 저 둘을 포함하는 추상적인 연결의 형태.

인자1 - 인자2^[각주:7]

가 나올 수 있다.

이 세개의 구조로 특화된 프로그램이 마인드맵(추상적 연결), 마크업 언어(리스트), 계산기(함수)다.

2.2.4 Trans

말 그대로 전달을 하는데 특화가 된 모듈이다.

대표적인 것이 바로 메신저류 서비스인데 메모가 되어 있던 내용들을 전달하는데 의미를 가진다.

재미있는 것은 메모와 권한(유저끼리)의 차이일 뿐이지, 그다지 차이는 없다.

- 컨텐츠 구조.

우선 컨텐츠 구조^[각주:8]를 보자.

	최상위	구분	묶음	단위
메모	프로젝트	보드(섹션)	노트(페이지) 그룹	노트(페이지)
메신저	대화방	채널	연관 또는 답 메세지	메세지
블로그	카테고리	매거진	챕터	포스트
SNS	뉴스피드	계정, 그룹, 페이지등의 뉴스피드	연관 포스트, 리블로그	포스트
카페	게시판	카테고리	답글	글
커뮤니티	게시판	카테고리	답글	글
위키	위키	분류	틀, 관련문서	문서
설명	작업을 위한 묶음.	폴더와 같이 내용이 없는 것으로 구분.	링크나 하위문서등 문서를 기준으로 묶인 그룹.	사용자가 보는 문서.

보다시피 세부적인 것이 다를뿐 규격은 거의 호환이 된다.

이를 가장 잘 활용하는 서비스가 페이스북.

• SNS -> 담벼락(타임라인)
• 메신저 -> 페이스북 메신저
• 블로그 -> 페이지
• 카페 -> 그룹

SNS(마이크로 블로그)가 아니라 커뮤니티 중심인 서비스로는 Discourse가 좋은 예.

• 블로그 -> 구글 Blogger나 워드프레스와 통합 기능
  
• 커뮤니티 -> Discourse 자체의 목적
• 위키 -> 위키 포스트 기능
  

- 서비스 권한.

이제 서비스 권한이다.

다음은 권한차이를 보기위한 두가지 지표다.

사용자 분류(위에 있을 수록 폐쇄적).^[각주:9]

사용자 구분	기호	부가설명
자신(Self)	S	계정 소유자
친한 친구(Best Friend)	B	특별한 등급의 친구
친구(Friend)	F	친구 신청 후 허락
지인(Acquaintance)	A	맞팔
구독(Subscriber, Reader)	R	팔로우
멤버(Member)	M	가입한 사용자
모두(Unpecified, User)	U	모든 사용자

보통 서비스들에서 서비스의 복잡도를 줄이기 위해 지인과 친구를 구별하지 않아 살짝 헷갈릴수 있지만 실제 인간관계를 생각해보면 쉽다.

나와 친척은 서로 얼굴을 알고 있는 사이고 어느정도 호감(팔로우)은 있지만, 친구 사이라 보기는 어렵다.

게시물 권한.

	설명
글 쓰기	자신의 글을 쓰거나 고칠수 있는 권한
글 읽기	자신의 글을 읽을 수 있는 권한
게시판 쓰기	게시판에 글을 유저가 쓰거나 고칠 수 있는 권한
게시판 읽기	게시판의 글을 유저가 읽을 수 있는 권한
사용자 노출도	자신의 계정이 노출 되는 환경

게시판은 서비스의 성격에 따라 온전히 혼자서 사용하는 곳이 아니다는 점이 가장 큰 차이.

통상적인 서비스 권한.(역시 절대적이지는 않음)

	글 쓰기	글 읽기	게시판 쓰기	게시판 읽기	사용자 노출도
메모	S	S	S	S	S
메신저	S	M	R	M	R
블로그	S	U	S	U	U
SNS	S	M	M	R	M
카페	S	M	M	M	M
커뮤니티	S	U	M	U	U
위키	U	U	U	U	U

메모는 따로 공유를 하지 않는 한 혼자서 사용하는 서비스다.

이와 반대되는 서비스는 위키로 모두다 공유하며 사용하는 서비스다.

블로그는 메모 글이 열려있는 형태다.

글과 게시판은 혼자서 채우지만 글과 게시판, 사용자 정보는 찾아오는 사람들이 모두 볼 수 있다.

커뮤니티는 게시판을 불특정 다수의 멤버들과 함께 채울 수 있다는 점이 블로그와 다르다.

카페도 커뮤니티 서비스지만 포털 서비스가 가두리 양식을 하려고 만들어졌고 카페정책 자체가 검색이 힘든 폐쇄적인 경우가 많아 글 읽기, 게시판과 유저 노출도 모두 멤버로 바뀐다.

서비스 형태가 특이해서 SNS와 메신저는 파악하는데 조금 걸렸는데..

SNS는 마이크로블로그라 불리는 형태로 운영이 되지만, 폐쇄적이라 멤버가 되어야 컨텐츠들을 자유롭게 볼 수 있다. 게시판이 통합되어 뉴스피드나 인박스되는 형태로 운영이 되기 때문에 불특정 다수의 멤버글을 읽는게 아니라 타게팅이된(ex. 구독) 글들을 보는 형태다.

메신저는 전달받는 메시지나 초대된 대화방의 메시지를 멤버면 읽을 수 있지만 상대방에게 전할 때는 최소한 구독이 된 상태여야 하므로 R이다.

2.2.5 Automation.

말그대로 자동화를 수행한다.

• 매크로: 안드로이드의 Tasker, IOS의 Workflow, Web에서 IFTTT
  
• 정교한 매크로: RPA(UI Path, Automation Anywhere)
  
• 메타 매크로: AI, Chat Bot

너무 명확해서 따로 쓸말은 없는듯.

아직 인공지능쪽 개념을 많이 모르기도 하고.

2.3 흐름.

매우 간략하게나마 어플리케이션의 흐름을 적어본다면

- 책 쓰기.

• 주제 설정 및 소통(Trans)
  그룹웨어, 메신저등을 통함.
• 자료 수집 및 저장(Store, Automation)
  각종 설정-> 노트
  사진 -> 자동 백업 및 분류
  사이트 -> 클리핑(Read It Later)
  논문 -> 서지관리 프로그램
• 책 저작(Create, Automation)
  일러스트나 포토샵을 통해 이미지 만들기
  Indesign같은 프로그램을 사용하여 저작
  퇴고 및 오탈자 수정자동 서식
  
• 홍보(Trans, Automation)
  커뮤니티, SNS, Store등에 올리기.
  

- 프로그래밍.

• 주제 설정 및 회의(Trans)
  그룹웨어, 메신저등을 통함.
• 자료 수집 및 저장(Store)
  사이트 -> 클리핑(Read It Later)
  코드 스니펫 -> Github Gist
  각종 리소스 -> 클라우드 공유
• 만들기(Create, Automation)
  리소스 제작.
  프로그래밍.
  자동 포맷, 빌드 테스트 등
• 홍보(Trans, Automation)
  커뮤니티, SNS, Store등에 올리기.
  

이렇듯 정보의 유통을 수직계열화 시키는 게 IT플랫폼 사업의 핵심이고, 모두가 지향하고 있는 지점이다.

다루는 방법이 비슷비슷한점이 많다보니 나중엔 깔끔히 통일된 플랫폼이 등장하지 않을까 싶다.

---

솔직히 이걸론 제품 설계할만큼 충분한 자료는 아니지만 플랫폼의 전반적인 구조 이해에는 도움이 되었기를 바란다.

1. GTD 포함. [본문으로]
2. 아래 예제에서 사용할 것은 ARM 어셈블리.
   참고하세요. [본문으로]
3. 어셈블리는 기계어를 치환한 것이므로 동일하게 취급하였음. [본문으로]
4. 레지스터나 메모리가 아니라 스토리지에 저장하는게 가장 큰 차이 [본문으로]
5. 흔히 말하는 양자역학에서 말하는 '관찰'이라는 것도 물체와 광자와의 '상호작용'이 필요한 것이기 때문에 시간이 흘러서 상태가 바뀐다고 말할 수 있다. [본문으로]
6. 프로그래밍에선 자료구조 정도로 생각해도 무방. [본문으로]
7. '-'는 단지 서로 연관성이 있다는 것을 나타내는 표현일 뿐이다. [본문으로]
8. 서비스에 따라 일부 기능은 제한 될 수도 있음. [본문으로]
9. * 친한 친구는 싸이월드 일촌 같은 개념.
   ** 서비스에 따라 합치기도 함. [본문으로]