짧은머리 개발자

오늘은 블록체인에 등록된 거래에 대하여 어떻게 검증이 이루어지는지 얘기하려 한다.

그러려면, 우선 블록이 어떻게 이루어지는지 알아야 한다. [1. 블록체인이란?]에서 언급한 바와 같이 블록은 Transactions, timestamp, nonce, ..., previous_blocks_hash_id를 사용하여 블록의 hash ID가 결정된다.

지금 검증하고자 하는 것은 블록의 실질적인 내용이고, 등록하고자 한 데이터의 한 형상인 Transactions이다.

Transaction

Transaction은 거래라는 의미를 갖고 있다. 비트코인으로 예를 들면, "A가 B에게 10만큼의 비트코인을 전송했다."를 Transaction이라 생각하면 된다.

이후에 아무 B는 비트코인을 사용하거나 전송하지 않았으면, B는 적어도 10만큼의 비트코인을 갖고 있어야 한다.

따라서 B는 자신이 비트코인 10만큼을 소유하고 있다는 것을 남들에게 알리려면, 적어도 해당 Transaction이 유효하다는 것을 검증해야 한다.

Merkle Tree

이제 블록에 등록되는 내용 중 새로운 친구인 Merkle Tree에 대해 설명하고자 한다.

Merkle Tree는 Hash Tree라고도 불린다. 따라서 어떤 해시 된 데이터들을 node로써 갖고 있는 Tree다.

우선, 위에서 든 예로 "A가 B에게 10만큼의 비트코인을 전송했다." 라는 데이터가 있다고 하자. 하지만, 실제로 우리는 Transaction을 봤을 때, A와 B를 지목하거나 대상을 구체화 할 수 없다. 그 이유는 데이터가 해시 되어서 블록에 저장되어 있기 때문이다.

즉, 거래 내역에 대한 데이터가 해시 되어 Transaction으로 존재하게 된다. 대충 Merkle Tree에 어떤 정보들이 존재하는지 짐작이 가지 않는가?

Merkle Tree는 Binary Tree로 생각하면 구현하기 쉽다. 그 이유는 다음 글을 참고하길 바란다.

Transaction을 두 개씩 짝지어 하나의 해시 값을 만들고, Bottom Up 방식으로 node를 만들어 나가다보면, 언젠가 트리가 완성될 것이다. 이 때, 트리의 root 값이 나오게 되는데, 이 값이 중요하다.

검증!

이제 검증이 어떻게 이루어지는지 설명할 차례다.

이쯤되면 우리는 각각의 character(마땅히 단어가 생각나지 않는다.) 혹은 character의 집합을 hash 했을 때 고유한 값이 나오는 것을 알고 있다.

즉, 거래의 내용이 변하면 hash값도 변하게 되고, 이를 이용해 Merkle Tree를 만들었을 때 다른 Root값이 나올것이다.

따라서 내가 검증하고자 하는 어떤 데이터가 블록체인에 정상적으로 등록되어 있다면, Merkle Tree를 다시 만들었을 때, Root Node의 값은 블록을 생성할 때 나왔던 값과 같을 것이고, 이로써 내가 갖고있는 데이터가 유효함이 검증된다.

*Merkle Tree에 쓰인 다른 Transaction은 다른 네트워크 참여자에게 요청하여 얻을 수 있다.

정리하면

내가 검증하고자 하는 데이터를 해시하여 Transaction을 만들고, 해당 Transaction을 바탕으로 블록의 Merkle Tree를 재구성하여 Tree의 Root 노드가 같은 값을 갖고 있다면, 데이터는 유효하다. 다른 값이 나오면, 해당 데이터는 유효하지 않은 것이다.

사실 여기까지의 내용으로 간단한 중앙화 블록체인(Centralized Blockchain Network)을 구현할 수 있다.

블록체인은 탈중앙화로 알고있는 사람들이 많기 때문에, 다음 글에서는 중앙화 / 탈중앙화 그리고 공개 / 비공개 블록체인 네트워크에 대해 글을 써야겠다.

오늘은 작업증명에 대해 알아보려 한다. 블록체인에서 작업증명은 빼놓을 수 없는 중요한 내용이다.

앞 글의 제일 하단에 보면, 블록체인의 해킹이 왜 어려운지 합의 파트에서 설명하겠다고 작성하였고, 이 문장을 보면 블록체인에서 어떤 합의를 해야 하기 때문에 해킹이 어렵다고 으레 짐작할 수 있다.

비트코인에서 합의 알고리즘은 작업증명(Proof of Work)를 채택하고 있다. 

합의

그렇다면 합의는 무엇일까?

합의는 간단하게, 블록체인에 등록될 어떤 거래 내역(Transactions)들에 대하여 정상적(valid)이라고 많은 사람들이 동의하는 것이다.

비트코인에서는 작업증명을 통해 Nonce를 찾고, 해당 값이 Maximum Value보다 낮으면 합의하게 되고, 이 Nonce를 찾은사람에게 비트코인을 보상으로 제공한다. 이 때, 해당 Nonce와 블록 내용으로 누가 되었건 hash를 했을 때, 같은 값이 나오고 해당 난이도 시점에서 valid한 값을 찾기 때문에, 모두가 동의할 수 밖에 없는것이다.

실제 합의 알고리즘은 작업증명, 지분증명, 위임지분증명, ... 등 많은 종류가 있고, 해당 내용은 나중에 중요한것만 다루도록 하겠다.

해킹이 어려운 이유?

블록체인이 해킹이 어려운 이유는 보통 다음과 같다.

1. 이미 생성된 블록들의 내용을 변조하는 것은 불가능하다.
2. 전체 블록체인의 참여자의 50%가 해당 블록에 대해 동의해야 한다.

1번은 앞 글에서 설명한 것 처럼, N번째 블록은 해시 ID를 생성할 때, (N-1)번째 블록의 해시 ID를 사용하기 때문에, 이미 생성된 블록의 내용을 변조하는 것은 해당 M번째(변조된 N) 블록의 해시 ID가 변하게 된다. 이는 기존 (N+1)번째 해시와 (M+1)번째 해시가 달라지게 되고 결국 사슬이 끊어지는것을 의미하며, 해당 블록들은 무의미한 블록이 된다.

2번은, 기본적으로 블록체인은 Peer to Peer 네트워크로 이루어져 있다. 참여자들이 노드 정보(Block정보)를 갖고 있게 되고, 따라서 블록의 내용을 다른 참여자와 비교 하였을 때, 절반 이상 같은 내용을 가지고 있어야만 해당 노드가 유효하게 된다. 앞 1번의 이유로 인해, 이미 생성된 블록을 해킹하는건 불가능하고, 즉 새로 생성될 블록에 내가 변조 내용을 넣어야 한다. 그러나 블록체인 네트워크는 "나"만을 가리켜 블록에 대한 합의를 해달라고 요청하지 않고, 네트워크의 모든 참여자에게 합의를 요청한다. 이는 결국 해당 블록에 대한 합의는 작업증명을 기준으로 모두 같은 값을 줄 것이고, 중간에 변조내용을 심은 사람만 다른 값을 줄 것이다. 이 때 블록체인은 어떤것이 유효한지 선택하여야 하고, 결국 많은 사람들이 동의한 내용을 채택할 것이다.

이를 다시 말하면, 내가 전체 블록체인 네트워크의 51%에 대한 힘을 가지고 있어야만 블록체인에 해킹된 내용을 심을수 있다는 것과도 같다. 이제 왜 블록체인 해킹이 어려운지 이해가지 않는가?

정리하면

블록체인 네트워크는 합의를 통해 새로운 블록을 생성하고, 해킹을 시도한다면 변조된 내용을 동의할 만큼 센 힘을 가지고 있어야 한다. 

다음 글에서는 내가 갖고있는 거래 내역이 어떻게 블록체인에서 검증되는지, 어떻게 유효성이 유지되는지 설명하는 글을 올리겠다.

내 생각에 블록체인은 비트코인에 의해 확-뜨고 인공지능에 의해 확-진 기술인 것 같다.

사실 블록체인 자체는 그렇게 어려운 개념이 아니다.

나는 블록체인을 쉽게 얘기할 때, '일종의 데이터 저장 시스템' 혹은 '일종의 데이터베이스와 같은 것'이라고 얘기한다.

그렇다면 블록체인은 데이터 저장 시스템인데 왜 사람들이 어렵다 말하고, 비트코인이 유명해진걸까? 본 글에서는 사토시 나카모토의 비트코인을 기반으로 블록체인을 설명하려고 한다.

비트코인

우선 비트코인이 무엇인지 알아볼 필요가 있다. 사실 지금 가상화폐로 인해 비트코인이 무엇인지 모르는 사람은 없겠지만, 우리는 블록체인으로서 비트코인이 어떻게 동작하는지 알 필요가 있다.

Bitcoin: A Peer-to-Peer Electronic Cash System, Satoshi Nakamoto, 2008.

놀랍게도 비트코인은 2008년에 논문이 공개되었고, 2009년에 발행이 시작된 가상화폐다. 2009년부터 비트코인을 구매하기 시작했다면, 지금 엄청난 부자가 되었겠지?

블록체인 기술이 주목받기 시작한 이유는 하드웨어의 발전을 빼놓고 얘기할 수 없다. 왜 하드웨어가 중요한지, 도대체 블록체인이 뭔지 이제 시작해보도록 하자.

블록체인, 말 그대로 블록을 연결한 구조

블록-체인. 즉 블록을 사슬처럼 연결하였다는 뜻이다. 사슬을 이루는 각각의 블록은 거래 내역(지금부터 데이터라 칭하겠다.)을 가지고 있고, 이러한 블록들이 연결되어 있다. 단순히 연결되어 있다면, 사슬이라는 이름보다는 블록-리스트 라는 이름이 되었을 것이다.

따라서 '사슬'처럼 쉽게 끊어낼 수 없는 어떠한 알고리즘이 사용되어야 하고, 비트코인에서는 Hash(암호화)를 이용하였다. 단순히 현재의 블록이 갖고 있는 내용만으로 Hash를 하였다면, 마찬가지로 단순한 '리스트'였을 것이다. 이를 해결하기 위해 각각의 N번째 블록은 자신의 ID를 만들기 위해 그 앞번째, (N-1)번째의 블록 정보를 이용하여야 한다.

만약 여기까지 이해했다면, 다음과 같은 의문이 생길수 있다. "그러면 블록의 정보들만 모두 구할 수 있으면 똑같은 블록을 만들 수 있는거 아니야? 내가 알기로 블록체인은 변조가 어려운 걸로 알고 있는데"

맞는 말이다. 블록의 내용만으로 똑같은 블록을 구성할 수 있고, 블록체인을 이룰 수 있다면, 비트코인의 가격이 폭등하지도 않았고, 그래픽카드 대란이 일지도 않았을 것이다.

즉 블록의 ID를 만들기 위해서는 추가적인 기술이 필요하고, 흔히 난이도라고 부르는 것이 그것이다.

*Hash : 임의의 길이의 데이터를 고정된 길이의 데이터로 매핑하는 함수, 나무위키, 비트코인에서는 SHA-256을 이용하였다. 

난이도

난이도가 꽤 어려운 내용이기 때문에, 여기서는 단순하게 난이도가 어떤것인지 설명만 하도록 하겠다.

난이도라는 이름 그대로, 쉽게 말하면 블록을 생성할 때의 난이도다. 난이도가 쉽다면 블록을 누구나 만들 수 있을것이고, 난이도가 어렵다면 블록을 아무나 쉽게 만들지 못할 것이다.

비트코인은 SHA-256을 이용하여 데이터를 해시하였으며, SHA 함수는 값마다 서로 다른 해쉬값을 뱉어내는데, 예로 다음과 같다.

iphone: 241c1e30ed886aa4a8f4248024be2ca1a221fe9773b52e2dca7891ff5771f399
iPhone: 38fdf519314e3151d7e7f6ef456f327b78ddb84bc457bdb0d49bce0b1fc3c959
IPhone: fde283a6fa88982b40441fe8d9d1ba8659ddb4c4cd75bf717a9371822370bcf4

조금만 값이 바뀌어도, 전혀 다른 결과가 나오는 것을 볼 수 있다. 이에 착안하여, 비트코인에서는 Nonce라고 불리는 값을 내가 만들고자 하는 블록의 데이터에 추가한다. 위의 그림 <ID Hash>를 보면, Transactions + Timestamp + Nonce + ... + Prev_ID라 이해하면 된다.

위의 해시 결과를 보면 알겠지만, 대소문자만 바뀌어도 값이 변하기 때문에, Nonce는 막 수학적으로 계산하거나, 어려운 값을 넣을 필요 없이 단순히 숫자 0부터 조건을 만족할 때 까지 1씩 증가시키면 된다. 

비트코인에서는 그 조건으로, 해시된 결과의 앞 n개의 글자가 0이면 된다. 최초에는 000000... 으로, 0이 6개 나오면 됐지만, 하드웨어가 발전함에 따라 해시속도는 급격하게 빨라졌고, 따라서 지금은 가변적인 난이도를 갖게 되기 때문에 n개의 글자수가 0이면 되는 것이다.

000000을 만드는것도 쉬운거아니야? 라고 생각할 수 있는데, i5-9600KF 기준으로 000000을 찾는데 평균 2분 30초 정도 걸리며, i9 10900으로는 1분 30초가 소요된다.

이러한 난이도(Nonce)를 찾는 행위를 작업증명이라고 한다.

정리하면

블록체인은 앞 블록의 Hash값과 현재 만들고자 하는 블록의 정보(Transactions, Timestamp, ...)를 함께 Hash하여 원하는 조건이 되는 ID를 가지는 블록들로 이루어진 데이터 사슬이라고 보면 된다.

"그러면 해킹은 왜 어려운거야?" 라는 질문이 생길수도 있는데, 이는 아직까지 설명하기엔 쉽지 않다. 하지만, 사람들이 흔히 말하는 내용처럼, "비트코인 네트워크의 절반 이상이 해킹된 내용을 갖고 있어야해."가 그 정답이다. 이는 나중에 합의파트에서 설명하도록 하겠다.

이번에 누나가 S21으로 휴대폰을 바꾸면서 워치 쿠폰이 생겼다.

그냥 지나가는 말에 워치 "엄청 저렴하다~! ㅎㅎ.." 했더니 누나가 사줬다 (...)

개인적으로 갤럭시 스마트 워치를 통해 기아 자동차의 UVO앱을 정말 사용하고 싶었는데, 이제 나도 가능해졌다!!!

모나미 S펜, 버즈 프로 모두 보라색 계열인데, 이번에 들여온 액티브 2도 보라색으로 구매함으로써 나도 갤럭시 깔맞춤을 하게 됐다. (내 플립은 검정색이지만..ㅠㅠ..)

삼성 마일리지몰에서 구매를 했는데, 매번 느끼는거지만 삼성 물류 배송은 좀 많이 개선되어야 한다. 2021년에 물품 구매 후 배송까지 어떻게 1주일이 넘는 시간이 걸리는가.. (3월 25일 구매해서 4월 3일에 수령했다.) 제품을 받아서 파는 곳이면 그럴 수 있지만, 삼성 내부적으로 판매하는건데도 이렇게 오래 걸리는지 아직도 이해가 안간다.

상자를 개봉하면, 위 뚜껑 안에 보이는 SAMSUNG이라 써 있는 곳은 삼성의 제품이 항상 그러했든 사용설명서가 들어있다. 시계의 모양을 유지해주고 있는 둥근 기둥(?) 같은 것을 들면, 충전기가 나온다.

갤럭시 액티브2 충전기의 단점이라면, 스탠드가 아니고 눕혀서 액티브 2를 충전 시켜야 한다. 그래서 나는 미리 충전기 거치대를 구매했고, 위 사진처럼 거치하여 충전하고 있다. 거치해서 충전하는게 공간도 덜 차지해서 꽤 괜찮은듯.

사실 나는 제품을 착용하기 전까지, 40mm면 좀 많이 작지 않을까..? 하는 걱정이 있었는데, 시원시원하다. 내가 차고다니던 시계는 이것보다 큰데, 불편함이 없다. (원래 아날로그 시계는 액티브2의 베젤까지 모두 시계영역이었으니, 꽤 답답할거라 생각했는데도.)

갤럭시 생태계 구축은 이제.. 노트북만..남았다..!!

총평 (★★★◐☆)

3.5 개를 준 이유는, 우선 아직 장착해서 실생활을 안해봤기 때문에 배터리 러닝타임이 얼마나 되는지 몰라서 한칸 비워뒀다. 반개를 깎은 이유는 시계의 반응이 좀 느리다.

예전에 갤럭시 기어 S3를 썼을 때는, 느리다는 느낌이 없었는데, 액티브2는 반응이 느리다.

베젤 터치 반응도 그렇고, 버벅거림이 눈에 보인다.

디자인은 완전 만족!

나중에 실생활 1주일 해보고, 본 게시글에 배터리 관련하여 내용을 추가 하겠다.

2021.06.12 추가!

배터리는 하루에 40%씩 소모되고, 따라서 이틀 쓰고 충전해주고 있다! 꽤 괜찮은듯?

이번에 모나미 S펜 할인하길래 하나 장만했다. (배송비 포함 25000원!)

예전부터 갖고싶었는데, S펜이 없다는 단점 때문에 망설이다 구매했다. (버즈, 워치 모두 보라색이라 S펜도 꼭 있어야 할것 같았다...)

박스를 열자마자 첫 인상은 내가 생각했던 영롱한 색깔이 아니었다는 느낌이 컸다.

버즈 프로의 그것 처럼 꽤 밝은 보라색일 줄 알았는데, 버즈 프로의 겉부분??의 유광 색상과 매우 흡사하다.

그리고 유튜브에서 봤을 때, 정품 북커버의 S펜 수납 공간에 수납해서 다니면 되겠다고 하시는 분들이 많았는데, 이는 실제 써봐야 할 것 같다.

펜을 사용할때는 저곳에 실제로 수납할 공간이 겨우 없을것 같았는데, 일단 펜이 자력이 없어서 저기에 착 하고 붙지를 못한다. 따라서 다른 펜 처럼 쓸때는 책상위에 올려두거나, 내가 계속 잡고있어야 한다.

들고다닐때는 기본 S펜을 함께 들고다니지 않는다면, 저곳에 넣어 다닐 수 있겠지만, 나는 S펜의 버튼이 아직 훨씬 편하기 때문에, 잘 모르겠다. 아마 모나미 S펜은 필통에 넣어다니지 않을까..

외관은 일단 이러하고, 실제로 모나미 펜을 써 봤을때, 필기감은 매우 괜찮았다.

무게가 있어서 그런지 필기하기에는 모나미 S펜이 1.3배 정도 더 좋았다. S펜은 터치펜으로 쓰는 느낌이고, 모나미 S펜은 진짜 펜으로 쓰는 느낌..?

총점 ★★★★☆

3줄 요약

1. 필기감은 1.5배 정도 더 좋다.

2. 수납이 불편하다. (필통을 들고다녀야하나..?)

3. S펜의 버튼이 그립다.. 지우개기능..ㅠㅠ..

MkWeb의 Controller는 json으로 정의되는데, 그 생김새는 다음과 같다.

{
	"Controller": {
		"name":"",
		"last_uri":"",
		"device":{
			"desktop":{
				"default":{
					"path":"/views/root",
					"file":"main.jsp",
					"uri":""
				},
				"en":{
					"path":"/views/root/eng",
					"file":"main.jsp",
					"uri":""
				}
			},
		 	"android":{
				"default":{
					"path":"/views/root/android",
					"file":"main.jsp",
					"uri":"/and"
				},
				"en":{
					"path":"/views/root/android/eng",
					"file":"main.jsp",
					"uri":"/and"
				}
			}
		},
		"debug":"error",
		"api":"no",
		"services":[
			{
				"page_static":"true",
				"type":{
					"kind":"sql",
					"id":"selectName"
				},
				"method":"get",
				"obj":"list",
				"parameter_name":"",
				"value":{
					"1":""
				}
			}
			{
				"page_static":"false",
				"type":{
					"kind":"sql",
					"id":"selectUserByClass"
				},
				"method":"post",
				"obj":"list",
				"parameter_name":"byclass",
				"value":{
					"1":"user_class"
				}
			}
		]
	}
}

위 json파일을 보고 어지러운가? 아니면 어느정도 이해할만 한가? 아래 표 먼저 보게되면 어지러울 수 있기 때문에, 생김새 먼저 보여준 점 이해 부탁한다.

내가 이 글을 쓰면서 느낀건데,, 나는 MkWEb의 사용법을 여기에 올리려 한게 아니라 개발일지를 적으려 했다..

흠.. 어떻게 블로그 글을 써야할까?

MKWeb은 정말 내가 json파일만 수정하면 웹서버가 동작하는, 그런 기능이 필요했다. 처음에는 모든 웹 개발자가 접근하는 HTML, 마크업 언어와 비슷한 XML로 MkWeb의 모든 설정을 하였다.

하지만 이는 기능이 늘어감에 따라 복잡해지는 XML과 그로 인한 떨어지는 가독성 때문에 JSON 으로 대체하였다.

다행인점은, 컨트롤러와 서비스를 읽어오는것과 그 기능이 하게 하는것은 쉽게 프로그래밍이 가능하다는 것이다.

내가 이때까지 FTP 서비스나, 세션 등 많은 컨트롤러를 개발하면서 느낀 점은 다음과 같았다.

1. 이렇게 많은 서비스를 만든다 해서, 프론트 개발자가 모두 사용할까?
2. 내가 지정한 규칙에 맞춰(hard) 사용한다면, 프론트 개발자가 어려움을 느끼지 않을까?

그래서 나는 정말 기본적인 Logger, SQL, RESTful API, JWT와 같은 기능만 구현하여 사용자에게 제공하고, 나머지 추가 컨트롤러나 서비스(FTP와 같은)는 개발하여 MkWeb에 적재시키도록 할 예정이다.

사실 프론트 개발자는 React나 vue를 많이 사용하는데, 요즘 fresh한 느낌과는 거리가 먼 jsp를 굳이 사용할까? 하는 느낌도 있었기 때문에, 최대한 가볍게, 그러나 편리하게 쓸 수 있는 방향으로 살짝 방향을 전환하였다. (RESTful API만을 이용해서 React의 데이터 서버로 사용한다든지 등.. 근데, node가 아닌 tomcat을 따로 설치해야 한다는게 좀.. 이걸 굳이 프론트 개발자가 하려나..?)

MkWeb은 Minwhoan-Kihyeon's Webserver framework의 약자이다. 이름에서 볼 수 있듯이 최초 시작은 나와 내 친구인 hyeonic 둘이서 개발을 시작하였다.

MkWeb은 앞장에서 언급한 바 있지만, 프론트 개발자가 더 쉽고 간편하게, 내가 알지 못하는 서버에 대한 고민 없이 웹 서비스를 할 수 있게 도와주는 프레임 워크이다.

사실 https://mkweb.dev-whoan.xyz 이 페이지에 들어가면 MkWeb에 대한 설명이 조금이나마 더 문서에 맞는 어투를 사용하여 작성하였으나, 처음 공식문서를 작성하다보니 그 어색함이 있고, 표현하기에도 애매한 바가 있고, 편하게 그 내용을 정리하고 싶어서 여기에도 글을 쓴다.

MkWeb은 MVC 패턴에 맞춰 디자인된 웹서버 프레임워크이다. 그렇다고 해서 Spring Project는 아니다. Tomcat과 같은 WAS에서 동작하는 JSP 기반 웹 서버이다. (JSP라 쓰고 HTML/Javascript 라 읽는다. ㅋㅋ)그럼에도 불구하고 MVC에 맞춰 디자인한 이유는 다음과 같다.

1. 프론트 개발자가 웹서버를 쉽게 정의할 수 있어야 한다.
2. 프론트 개발자가 웹서버를 쉽게 유지/보수 할 수 있어야 한다.
3. 설계만 잘 한다면, 그에 맞게 웹서버가 동작할 수 있어야 한다.

지금이야 기본 기능이 구현된 후에서야 쓰는 글이지만, 위 3가지를 바꿔 말하면,

1. 프론트 개발자가 사용하고자 하는 View를 정의하고 (JSP), 미리 짜여진 Controller의 설계에 맞춰 기능을 잘 만든다면 웹서버가 동작하여야 한다.

2. 유지보수를 쉽게 하기 위해 프론트 개발자는 일절 Server-side Programming 지식이 없어도 되야 하므로, 프론트 개발자가 잘 사용하는 json/xml 방식을 통해 유지/보수 할 수 있어야 한다.

와 같다. 어느정도 그림이 그려 지는가?

따라서 우리 MkWeb는 MVC를 다음과 같이 정의했다.

Model: 서버의 자원 (DB, File Server 등)

View: Client가 볼 웹 페이지

Controller: 모델과 뷰 사이의 관계

Service: 컨트롤러 내에 존재하여 실제 동작하는 워커

정리해보면, MkWeb은 프론트 개발자가 json으로 정의된 컨트롤러들을 잘 정의하고, 사용하고자 하는 Service를 잘 등록해주면 웹서버가 돌아간다!

지금 지원하는 Service(Controller)는 다음과 같다.

1. RDBMS
2. RESTful API
3. MkLogger
4. FTP

개발 연혁(?)
2020.05: dev.whoan과 hyeonic의 웹서버 공부를 목적으로 MkWeb 개발 시작

2020.08: RESTful API 기능을 추가하고자 하였으나, 우리 둘의 지식 부족으로 인해 MkWeb 개발 중단

2020.09: 학기 시작과 hyeonic의 4학년 준비로 인해 MkWeb의 공동개발 중단, dev.whoan의 독자개발 진행

2021.01: koh의 관심으로 koh의 합류.

2021.03: 학기가 시작됨에 따라 MkWeb 개발 중단.

MkWeb이라는 웹서버 프레임워크를 만들기 시작했다.

누군가의 부탁이나, 어떤 대회에 참가하기 위해서가 아니라 '이러한 방법으로도 만들 수 있구나!' 하는 경험과 백엔드를 공부하기 위함이 그 목적이다.

따라서 MkWeb은 웹서버 프레임워크이며, MkWeb을 사용함으로써 편리하게 웹을 개발하자는게 그 취지이다.

특별한 점이 있다면, SSR(Server-Side Rendering) 방식이지만 어떻게 해야 프론트 개발자가 더 쉽고 간편하게, 내가 알지 못하는 서버에 대한 고민 없이 웹 서비스를 할 수 있을까 하는 방향에서 접근하기 시작했다.

위에서 언급한 '이러한 방법으로도 만들 수 있구나!'에 대한 경험은 SkyLove의 전창렬 이사님의 SkyFramework를 보고 경험했고, 나도 웹서버를 독자적으로 만들어보고 구조를 이해하고자 함이다.

처음에는 'MkWeb을 모든 대학생이 한번쯤 써보면 어떨까?' 하는 큰 꿈이 있었으나, 추가하고자 하는 기능이 많아짐에 따라 이제는 그냥 '누군가는 써봤으면' 하는 그러한 꿈도 있다.