미디어를 보다보면
꽃보다남자
너의이름은 도
운명의 실로 이어져있다고도 많이 표현한다.
아주 맘을 태우는 주제다.
나와 너의 관계가 생기고, 이를 통해 순수한 어떤 것이 생성된다.
매력적이 아닐 수 없다.
사실 기계공학으로는 공부한 게 너무 적어서 돌려막기의 형태다
시스템의 구조는
덩어리에서 어떠한 조건, 규칙을 통해
묶음을 만들고
이를 통해 소속감을 주거나, 혹은 어떠한 곳에 이용을 하거나를 한다.
이번 주제에서 말하고 싶은것은 이 행위가 교집합의 형태가 된다는것이다.
내가 한곳에만 속하지 않을 것이고, 중첩이 될 것이고, 충돌이 발생할 수도 있다.
API를 먼저 이야기 해보고
심화하여 앞서말한 교집합의 주제가 왜 나왔는지 언급해본다.
처음 개발공부를 시작했을 때 맥락을 파악하는데 어려움을 많이 겪었다.
뭐만하면 API라고 이야기를 하는데
알겠으면서도, 정확한 구분을 하지 않고 있는 것 같기도 하고,
(사실, 버전 관리와 API에서 지금의 블로그, 유튜브 생태에 혐오감을 느꼈긴 하다.)
틀린 말은 아니긴 하나, 이 글들에서 내가 어떠한 자세, 방향을 가져야하나에 대한 의문의 답을 쉽게 찾을 수 없었다.
사실 내가 찾는 게 맞지, 남한테 이를 해달라 하는 것도 웃기긴하다.
그래도 나와 같은, 처음의 사람들에게 이러한 환경은 생각보다 가혹할 수 있다고도 생각했다.
안일한 봉사, 도움 정신인가.. ㅋㅋ
뭐, 암튼! 사설은 정말 여기까지만 하고
나는 글에서 사진을 많이 사용하지 않는다.
사진이 개똥이기도 하고, 사진으로 이해가 잘 되지 않더라 다
정말 도움이 되었던 사진은 손에 꼽는다
뭐 여기서도, 내가 그 당시에 공부 정도에 따라 이를 받아들이는 정도가 달랐을 테지만,
사진보단 글이오, 글보단 말이다.
커뮤니케이션이 되기 때문이다
REST API 는 이론이다.
너가 나한테서 뭘 얻으려 한다면 나는 그 장소를 너한테 지정해 주겠다. 이고 그 장소는 URL로 한정하겠다. 가 끝이다.
다시말해 육하원칙(언제, 어디서, 누가, 무엇을, 어떻게, 왜) 에서 어디서에 대한 답을 좀더 구체화를 하겠다는 소리다.
기초 공부에서 수학적 사고는 2차원도 필요없다
1차원에서 왠만한건 다 처리가 된다고 본다.
초등학교, 중학교 때 배웠던
점 선 면 에서, 거기서도
점 선 까지만 보자.
오늘은 선에서만 언급을 할 것이고, 이 글을 읽고 흥미가 있다면
더 다운그레이드해 점에 대해 고찰의 시간을 가져보면 좋을 것이다.
기본적으로 선을 그릴 때 두 점을 찍고, 이를 이어 선을 만든다.
이 그림을 절대 잊어버리지 말자.
드로잉, 스케치의 과정을 거칠 때 이를 떠올려 기초를 잡고
지금 그린 선에서 어떠한 것을 이어나갈 수 있을까
잘 떠오르지 않을 때 육하원칙으로 시작해보자
-
언제(WHEN) :
-
어디서(WHERE) :
REST API 가 될 것이다.
이 부분에서 말이 길어 질 것 같다 -
누가(WHO) :
나의 위치는 고정이 될 것이다.
여기서 시각을 반전하여
데이터의 흐름을 살필 수도 있을 것이다.
내가 데이터를 가게 할 수 있을 것이고,
내가 데이터를 오게 할 수도 있을 것이다,
이러한 행위의 주체가 (내가 혹은 너가 될수도 있다)
이러한 형태를 깊게 생각해 보면 좋다
- 무엇(WHAT)
데이터 관점에서는 4번 까지면 충분하다고 본다.
- 어떻게(HOW) : 어떻게에서는
어떻게는 중요하지만
사실 HOW에서 아니, HOW랄 것도 없다.
시간을 너무 과하게 투자하는 사람들이 많다
얻는 건 없고 멍때리는 수준이다.
그럼 절대 안된다. 악수를 두게 된다.
지금 내 수준이 이걸 할 때인가는 계속 생각해보아야 한다고 생각한다
(정답은 아니지만, 초중고 수학 건너 뛰고 바로 대학 수학 절대 못들어 간다고 생각한다)
이 글은 초중 수준이다. 대학 수준에서 본다면 맞지 않는 부분이 있을 수 있다
- 왜(WHY)
왜가 육하원칙에서 가장 마지막에 배치된 데는 이유가 있다고 본다.
이게 핵심이거든. 서비스를 하는 입장에서
근데 어렵다
왜에 대한 적절한 답을 찾기 위에선
앞선 4-5가지 경우에 대한 대비가 잘 되어 있어야 한다.
이를 다시 종단으로 말해보자.
후에 육하원칙을 살려보자
클라이언트가 서버에 어떠한 데이터를 요청한다고 하자.
-
그 행위는 어떻게 되는가?
: 버튼을 누른다, 주소를 입력한다, 명령어를 입력한다. -
그 행위가 시행이 되었을 때
그 장소는 없어도 가능한 것인가?
장소는 꼭 필요하다고 생각한다.
그렇다면 장소는 /url로 한정이 되는가? 아니면 또 다른 장소가 있는 것인가
여기서 궁금증이 생겼다.
블록체인을 공부하고 있는데
클라이언트-서버의 구조에서 나아가 P2P 구조를 공부하게 되었고,
블록체인 특성상 PEER들은 동일한 조건, 동일한 상황을 가지게 된다.
디스코드의 호스트도 같은 관계지
블록체인에서
채굴의 경우는
백그라운드에서 구동이 되어도 충분하다고 생각한다.
이를 굳이 수면위로 올려 웹에서 효과 등의 처리를 나타내어야 할까?
블록을 이어붙여나가는 행위는 백에서 해버리고,
클라이언트의 요청에, 혹은 내가 서비스할 목적에 따라 특정 것만 띄워주면 된다
이게 API다.
- 데이터를 얼마나 이쁘게 다듬어 올려주냐
어플리케이션을 만들어본다고 하자
이제 블록, 그리고 거래(트랜잭션들)은 백에 저장이 된다.
쳐나가는데,
-
어떠한 거래 내역을 검색해보고 싶다.
이 때 어떤 처리 과정을 거칠까 생각해보자 -
웹(클라이언트)에서 어떠한 조건, 값을 넣고 요청을 한다.
-
요청은 비동기 처리가 될 것이다. 다른 것도 해야하니까
비동기는 언제하냐? : 다른 것도 해야할 때
아무튼 요청이 백에 들어왔다.
(여기서 쓰레드랑 이 구조가 나오는구나 파악을 해야겠네)
이 검색에서 나만의 거래를 검색할 것인가
아니면 타인의 검색도 할 것인가를 봐야 하는데
트랜잭션(거래)들이 어떠한 처리가 되어있는지는 난 몰라
이거 단방향은 아닐거고 그러면 파악은 될거야 대신, 내거래만 확인이 되겠지
여기서, 새로 생성된 암호화 키들이 서비스하는 나한테는 저장이 되게 되어있나?
시각화에서는
나의 거래소(서비스하는 곳에서) 오고가는 거래들에 대한 시각화가 나오면 좋겠네
보안이 필요없는 데이터를 시각화하는거지
총 자산, 거래량 대신
조건이 개인의 거래량이 아닌, 일정 시간, 일정 장소 등에서의 거래겠지
이는 쿼리 SQL로까지 연결이 될 수 있다.
그리고, 내가 거래만 할 수도 있잖아.
이때
승인자 쪽이랑 거래자 쪽을 어떻게 나눌까 에 대한 고민도 해보자
나는 블럭을
- 나의 거래라고 한정을 하였으니,
처음에는 승인자와 거래자를 구분 짓지 않아서 아니다 두 경우다 생각해보자 어떻게 구현할지
승인자/거래자 가 나뉘어 있다고 한다면
내 트랜잭션도 어디에 있는지 모르겠지
내가 가지고 있는건 키니까
트랜잭션들에서 쿼리로다가 키를 입력해 찾는 경우인데
이 경우에는 그냥 SQL인거 같은데?
오케이 끝
승인자=거래자였다고 한다면 블록생성에 있어서도 위와는 조금 다른 경우 였을거야
내 블록에 내 거래만 담기는 경우겠지
이경우 사고를 블록체인으로만 한정짓지 말고 또 다른데 이용할 곳은 없냐 까지 발전을 시켜야해
내블록에 왜 내 거래만 담기는 경우라고 생각을 했냐면
블럭찾기를 할거란 말이지 내가, 그리고 남이
그렇게 서로 돌리다가 찾았어.
찾았다면, 그때 브로드캐스트를 해서 남들에게 검증을 돌리고(이때 검증과, 블록찾기는 같이 진행되는 거겠지) 이를 비동기/동기라고 말하는게 맞나? 이건 아직 잘 모르겠음 암튼!
그래서 맞다면, 그때까지의 거래들은 다 블록으로 들어가겠지(이때로 어떠한 처리가 있을 거야,
여기에는 거래가 다들어가는지 아니면 제한이 있는지, 들어가는 순은 거래량 큰 순이라고 알고 있는데)
멤풀에 대한 내용은 우선 보류다. 좀있다 책을 좀 볼거야
블록을 찾는 구조가 비동기 처리가 맞냐에 대한 질문을 해야겠네!!
백에 들어올 것이고,
이제는 P2P 구조에 대해 생각을 정리해보자
클라이언트-서버 관계와 대비해서
p2p는 모두가 동등한 위치를 가진다 이소리지
아까 얘기했던 선의 4가지 경우에서 더 볼 수 있다고
그러네, 동등한 입장이니까 선의 경우를 여기서부터 출발하는게 맞네
그리고, 앞뒤 뒤앞 둘다 할 수 있는거 생각해보고
데이터는 다 똑같은 걸 가지고 있어,
그러면 데이터 보는건 뭐 나한테서 바로 하면 되니까 상관이 없는데
데이터 뭐에 시간이 걸린다 했잖아
그건 무슨 경우지
데이터 동기화에 시간이 걸린다는 말인가?
80기가가 된다는데, 어떻게 다 가지고 있을 수 있는거지?
블록참여할 때 요구 조건이 있나?
그리고, 동기화에 용량이 부족할 수 있잖아
그러면 뭘 이용해야 하는거지??
블록생성할 때
그렇다면 클라-서버에서 데이터가 서버에 있으니까
이건 종단 관계를 파악해야 하는데
블록체인에선 이 경우를 굳이 판단할 필요가 없는건가?
일단 데이터는 나한테 다 있으니까
그럼 블록처리에서 이 관계를 봐야하는데,
브로드캐스트, 그리고 내가 블록을 찾았을 때 서버에 하는 처리를 한번 봐보자
내가 블록을 찾으면, 브로드 캐스트를 하나? 모두에게 알리는데
브로드캐스트가 js에서 보면
foreach로 돌리잖아
이 브로드 캐스트 부분 일단 봐보자
open api일때 클라이언트에게
데이터 이형식으로 맞추라 강제하잖아
이건 내가 코드 작성할 때도 마찬가지로 적용되는거야
그거에 맞게 코드를 짜내려 갈테니까
노파심에 말한다
API에서
REST API 그리고 GRAPHQL 이 나왔는데
이 둘에 큰 차이가 있는 것이 아니다
그렇게 해석하면 안된다
데이터 관계 를 보아야하고
GRAPHQL은 쿼리언어다. 차라리 SQL를 더 깊이 보아야한다는 소리다
(겉멋 부리지 말고 차근차근 깊게 봐라)
rest던 graphql이던 어쨌든 뭘 한다하면
어디서 할지가 있어야된다는 소리다
육하원칙을 어기면 안된다
계속 하니까 서당같은데 이게 맞다고
그렇다면 PEER를 통들은 PEERS와 서비스하는 나는 다시 클라이언트-서버 관계를 가지게 되고,
이렇듯 보든 관점에, 시야에, 범위에 따라 말할 수 있는 것들이 달라진다.
과하게 정리하자면 이러한 관계성들을 정립해 놓은 것이 디자인 패턴인 것이다.
이는 원론이다.
때문에 지금 말한 API 뿐 아니라
라우트, 컴포넌트 등에서 모두 적용이 가능하다.
상황을 잘 분석하고,
이용하는 것이다.
더미(Dummy)일 뿐이다.
프레임워크를 쓰고, 가지는데
왜 나와있는 구조, 패턴은 개무시를 하는건지 모르겠다.
연결은 어디서나 물체 두개 있으면 형성되기때문에 끊임없고 그래서 한번에 이해하기 더 어렵다
삶의 지혜를 가르치는 좋은 시스템인데
이를 인지하게 하는 교육은 부족하다랄까
어찌됐던 긴 글이 끝났다. 글이 길면 그래서 뭘 말하려는지 요지 찾기가 어렵다
이 또한 도움을 주겠다
내가 말했던 rest, graphql, json 자동화, 크롤링, open api 던
기저에 있는 공통점 중 하나가 있다.
데이터 다듬기, 선언하기!
이 예제에 대한 링크를 첨부하고 글을 마친다
(링크)
