문서화 프로젝트2: 환경설정

서론
1. 전체지도(슬라이드3장)
2. Git인 이유
본론
1. Git 환경설정
2. IIS환경설정
3. Vscode

전체구조

여러형식 중 HTML가 적당하다고 판단. 어떻게 표/그림/그래프/수식을 다룰 것인지 포스팅했다. 포스팅1을 요약하자면 아래와 같다.

슬라이드1

▷ 편집기는 메모장으로도 충분하지만 좀 더 효율적인 작성을 위해서 툴을 사용할 수 있다. notepad++이란 프로그램은 Ultraedit이나 source insight와 같이 여러파일을 동시에 다루기에 훌륭하고, 여러번 돈을 지불하지 않아도 꾸준히 업데이트 해주는 장점이 있다. 작업하다가 컴퓨터를 꺼도 파일을 유지해 준다. 또한 태그마다 색과 크기, 모양을 다양하게 지정되어 있으니 생산성에도 도움이 된다.
vscode는 MS에서 무료로 배포하고 있는데, c, java, python은 물론 html까지 다양하게 지원이 된다. (환경설정이 까다로운 편이다.)

▷ 표, 그래프/그림, 수식에 대해서는 지난 포스팅에서 다루었다.

▷ 서버에는 크게 3가지 버젼이 있다.

파일서버(FTP) : 파일 업/다운로드에 특화. 접속권한에 따라서 폴더/파일별로 관리가 가능하고, 폴더를 공개
웹서버(Web) : html을 해석해서 맞춤형으로 보여주기 위한 서버
DB서버(DBMS) : 검색을 주 목적으로 함. 정보가 요청(쿼리, Query)에 따라 해석해서 반환 됨. 쿼리 해석기 필요

우리가 주로 사용하는 클라우드란 FTP인데, Google Drive, 네이버 드라이버, MS OneDrive를 사용해 본 결과 내 PC와 동기화가 가장 잘 이루어지는 것은 OneDrive가 아닌가 싶다. 주로 사용하는 자료는 내PC와 클라우드에 동시에 저장이 되고(ⓥ), 자주 사용하진 않는 데이터는 클라우드에만 보관을 한다(☁️). 그리고 편집된 파일은 설정한 시간마다 자동으로 업로드/다운로드 된다(🔃).

슬라이드2

블로그는 웹 서버이고, DB서버는 완벽하게 제공하는 서버는 아직 없다고 본다.

웹 서버도 2000년대 초반 붐이 일어났을 때부터 써왔지만, 자유도가 높으면 어렵고, 쉬우면 한계가 있다. Wix.com에서 2022현재 16,000원부터 광고하고 있다. 사용해 본 바 결론부터 말하면 싸이월드나 네이버 블로그 수준이라면 몰라도 편집을 하겠다고 마음먹는 순간부터 난이도는 상당히 높은 편이다. 비용(노동)은 줄이고 생산성을 확보한다. 이 대전제를 확보하기 위한 결론이 웹 서버는 블로그를 활용하자인 것이다. 네이버 블로그는 제약이 너무 많다. 싸이월드나 페이스북이나 다름이 없다. 티스토리는 된다. 아래는 직접 만든 계산기 프로그램이고 자바스크립트로 만들어졌다. 물론 소스코드도 공개해 놓았다. (물론 Git도 된다. 대신 에디터가 없다.)
https://github.com/iseohyun/html/tree/main/examples/Calc1

그러면 문서화를 티스토리에서 모두 진행하면 되는 것 아닌가? 티스토리의 최대 단점이라면, 진행 중 저장이 어렵다는데 있다. 대부분의 작업은 한 번에 이루어지지 않는다. 이 문서도 마찬가지다. 참고로 나는 이 문서를 몇 번이나 다시 만들고 있다. 몇 번은 날려먹어서 같은 작업을 반복하고 있다. 내 PC처럼 작업하다가 다른 일을 하더라도 그대로 멈춰 있어야 한다. 클라우드를 연동시키려는 이유가 여기에 있다.

Git

과거에 직접 서버를 운영하던 시절에 내 컴퓨터를 365일 내내 켜놨던 사람들은 알 것이다. 매우 귀찮다는 것을. 지금은 토렌토며 불법 영화와 야구 동영상을 저장해야할 이유도 없어졌다. 훨씬 더 고품질의 최신의 영상을 적은 비용이면 손쉽게 구할 수 있다. 실제로 개인 이력서와 포트폴리오 파일은 1TB안에서 얼마든지 운용가능하다. 보안 때문에 클라우드를 못 쓴다는 말도 옛말이다. 따지고 보면 은행계좌도 다 믿고 사용하는 것이다. 채팅은? 카톡은? 기업운영을 난장판으로 할 것이라고 판단하지 않는다면 어느정도 믿고 갈 필요가 있다는 것이다.

내 컴퓨터와 클라우드의 동기화는 OneDrive로 해결했다. WebServer는 티스트로리로 한다. 둘을 어떻게 연동할 것인가는 git으로 해결할 것이다. 사실 Git의 아이디어는 어떻게 안정적으로 저장할 것인가에서 왔다. 그 아이디어는 매우 심플하다. 우리가 대학생때 레포트를 쓰던 시절을 생각해보자. 당시에 우리는 '저장을 생활화하자'라는 것이 있었다. 그런데, 저장도 실수할 수 있다. 예를 들어보자. 템플릿을 베껴오고 싶어서 원래 파일을 카피했다고 생각했는데, 데이터를 날리고 저장하고보니 카피파일이 아니었다. 그래서 저장 할 때, 자동으로 버전을 바꿔가면서 저장해주면 참 좋겠다라고 생각한게 바로 Git이다.
그 다음 드는 의문이 당연히 용량문제이다. 1차적으로 저장할 때 압축저장을 한다. 이것만으로도 편리하다. 만약 1TB 파일에 바뀐내용이 꼴랑 10byte인데, 저장할 때마다 1TB가 늘어난다고 생각하니 끔찍하다. 그러면 바뀐 파일만 따로 저장을 하면 되잖아? ~~Git은 이것을 무료로 해준다.(그래서 GitHub인가?)~~ 그럼 뭐가 바뀌었는지 기록해놓아야 할 것 아닌가? 그것이 Log다. 이제 우리는 명령만 하면 된다. 이 파일을 저장목록에 넣어줘. 변경 내용을 반영해줘. 기록을 보여줘.

Git은 개발자들의 전유물이었다. 물론 MS에 인수되면서 좀 더 대중으로 다가가지 않았나 싶다. 계정만 만들면 무료로 FTP서버를 사용할 수 있고, 최근에 web서버를 연동했기 때문에 이를 끌어올 생각이다. 문제는 오너쉽인증인데, 개인인증서를 박아놓아야 편하게 사용할 수 있다. Git이 개발자 생태계에서 시작했기 때문에, 당시의 고급인증체계를 그대로 유지하고 있다고 봐야한다.

Git의 인증구조는 공인인증서의 구조와 동일하다. 단지 인증서 발행을 은행이 하지만, 사실 이는 매우 위험한 발상이다. 인증의 수학적 모델은 페르마 소정리에 있다. 암호 전공을 하지 않는 이상 이해할 필요는 없다. 단지 왜 해야하는지 정도는 이해시키고 싶다.
우리는 숫자가 순서대로 있다고 생각하지만(1 다음은 2, 다음은 3...) 암호학에서는 이를 잘 뒤섞어 주어야 한다. 마치 톱니바퀴처럼 총 10칸의 톱니라면 3계단을 갔다가 나머지 7계단을 가면 정답이 나온다. 이는 CRC라던가 대부분의 현대적 암호 메커니즘이 동일하다. 얼마나 쉽게 순서를 섞는가가 알고리즘의 승패를 좌우한다. 총 몇 칸인지, 몇 개의 계단을 올랐는지에 대한 내용은 숨기고, 최종으로 몇 개의 계단을 올라가야 하는지는 공개한다. 이해가 조금 빠른 사람이라면 "2명이 인증할 것이 아니라 3명, 4명, 여러명의 동시인증도 가능하겠는 걸?"이라고 생각 할 것이다. ~~이미 내가 석사논문으로 썼기 때문에 당신들은 늦었다.~~ 결론적으로 만들어지는 키 중에서 아무거나 하나를 전달해도 된다. 7을 전달하든, 3을 전달하든 말이다. 동작은 한다. 보안이 무너져서 그렇지... 실제로 업계에서 일할 때, 비밀키를 넘겨서 사용하는 사람을 본 적이 있다.

회사라면 사설 SSH서버를 유지하겠지만, 앞서 언급했듯이 엄청 귀찮다. 일요일 밤 10시에 서버 전원 내려가서 회사로 출근하고 싶지 않다면 git서버를 쓰자. 안정적이고 공짜다. 누군가 훔쳐간다면, 축배를 들겠다. 그 만큼 가치가 있다는 것이니까.

개발자 베이스였기 때문에 공개키 시스템을 사용할 것이고, 공개키를 전달할 것이다. 그럼 어떻게 할까? 드디어 본론이다.

Git 환경 설정

컴퓨터 학습의 단점이라면 자주 바뀐다는 것이다. 우리는 'ㅐ'와 'ㅔ'가 동일하다는 것을 이미 알고 있지만 수백년동안 그대로 써오고 있지 않는가? (심지어 공부하고 모르면 무식하다고 놀린다. 사실 혼용헤서 써도 소통애 전혀 지장이 없다. 게발자들이라면 10년도 안되서 전부 'ㅐ'로 통일헤 버렸을 것이다.) 서버설정도 구글서칭이면 엄청나게 나오는데도 일부러 포스팅에 넣는 이유다. 2022년 버전이다.

1. https://git-scm.com/downloads 에서 깃 터미널을 다운로드 받을 수 있다. 다운도르 후엔 윈도우 기본 터미널에서도 git을 사용할 수 있다. 어쨌든 난 git bash의 알록달록이 좋더라.

2. https://github.com/ 에 방문해서 가입해서 개인 저장공간을 만들자. Create repository를 한다.

처음 공간을 만들고 나서 아래와 같은 안내가 보인다.

최초의 git 컨셉이, "내 컴퓨터에 저장 공간을 만들고, git server에 백업을 한다"였다. (현대에 와서 의미는 완전히 달라졌지만서도...) 그래서 내 컴퓨터에 저장공간을 만들어야 한다. 이 공간이 프로젝트의 메인 폴더라는 것을 선언해 줘야 한다. 초기화라고 하는데, 앞서 언급했듯이 로그를 자동으로 생성하기 위해서 .git이라는 숨겨진 폴더를 생성하고 그 안에 압축파일이며 로그등 지저분(?)한 것들을 보관할 폴더를 생성하는 작업을 수행한다.

echo "# Test" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin git@github.com:iseohyun/Test.git
git push -u origin main

한 줄, 한 줄 분석해보자.

echo "# Test" >> README.md
git add README.md

사실 git init만 해도 된다. 그래도 뭔가 업로드 해야할 껀덕지가 있어야 하니까 README.md파일을 만드는 것이고, github정책상 README.md는 메인화면에 안내로 출력되니까 작성하는 것이다. md는 Markup Language(이전 포스팅에서 html외 후보로 놓았던) hyper-text의 후보군이다. 딱히 MS에서 민다기보다 키보드로 쓱쓱 만들기 좋으라고 만든 뉴 타입의 포멧이라 차입하는 개발자 군이 있다. 편하긴 한데, 일반인들 보기엔 알록달록 하지도 않고 뿌슝빠슝 하는 것도 없으니 심심하기는 하다. README.md를 열면 "# Test"가 입력되어 있을 것이다. 결국 초보자를 위한 더미일 뿐.

git commit -m "first commit"

첫 번째 수정 반영을 한다.

git branch -M main

저장 모드를 변경할 수 있다. git프로젝트가 커지면서, 여기저기서 수정을 하다보면 버전이 꼬이는 현상이 발생했다. 따라서 각자가 따로 개발을 하고 병합을 한번에 하는 방향으로 진행할 수 밖에 없었다. 아무래도 자주 사용하는 명령이 아니다보니 헷갈리기도 하고, 브랜치가 다르면 서로 영향이 전혀 없다보니 모델관리로도 사용할 수 없다. A모델에서 버튼에 새로운 기능이 업데이트 되었는데, B, D, E, F모델도 동일하게 반영된다고 치자(C모델은 빠짐). 그럼 브렌치별로 따로 수정하다보면 실수가 나올 수 밖에 없다. 내가 서버에서 끌어다 쓰고 있는데, 업로드 하려면 버전충돌 일어나는 경우가 종종 발생한다. 그 동안 내 동료가 업데이트 했기 때문이다. 머지(통합)기능이 있다. 혼자 사용하는 경우라면, 기본으로 main 또는 master로 관리되므로 우선은 신경쓰지 않아도 된다.

git remote add origin git@github.com:iseohyun/Test.git
git push -u origin main

업로드 할 서버를 여러군데 지정 할 수 있다. (상상하는 건 다 된다고 보면 될지도...)
git@github.com:iseohyun/Test.git이 최종 목적지이고, git push가 업로드 명령어다. 환경 세팅만 끝나면 다음부터 git push만 쓰면 된다. git remote명령어는 git@github.com:iseohyun/Test.git의 별명을 origin으로 하겠다는 뜻이다.

메인 저장공간을 내 컴퓨터가 아니고 github로 할 것이기 때문에 공간만 생성하고, 복사해서 가져올 것이다. 서버이름이 git@github.com:iseohyun/Test.git 이므로 다 필요없고, git clone git@github.com:iseohyun/Test.git를 하면 된다.

물론 지금 하면 안된다. 왜냐면 키 교환을 안했기 때문에...

3. 키 생성

c:/user/.ssh 폴더에서 수행한다. shell에서 실행한다.(git bash도 상관없다.) 우선 키 생성을 해야한다. ssh-keygen명령을 입력하면, 파일명을 입력해달라고 한다. 나는 iseohyun을 입력했기 때문에 iseohyun과 iseohyun.pub 두 파일이 생성되었다. 이제 pub(public '공개된'의 약자)를 github에 알려줄 차례이다.

PS C:\Users\iseoh\.ssh> ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (C:\Users\iseoh/.ssh/id_rsa): iseohyun
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in iseohyun
Your public key has been saved in iseohyun.pub
The key fingerprint is:
SHA256:LhutlVawvKoWmw5sSIrqiEqgapLQK7+WWLjTucz6Mkg iseoh@SeohyunBook
The key's randomart image is:
+---[RSA 3072]----+
|                 |
|                 |
|        .        |
|       . o       |
|.+      S .      |
|OEo .  o +       |
|OB++ +o B        |
|^=*.+  O         |
|%@B=o.+          |
+----[SHA256]-----+
PS C:\Users\iseoh\.ssh>

폴더를 열어보면 두개의 파일이 보인다. iseohyun, iseohyun.pub이다. 둘 다 메모장으로 보인다. base64방식으로 인코딩되서 그런데 몰라도 상관은 없다. 나중에 iseohyun.pub을 복사할 것이다.

4. 키 공유

github.com에서 psrsonal account >>Access>>SSH and GPG keys>>SSH keys에 붙여넣기 할 텐데, 붙여넣을 데이터는 방금만든 iseohyun_pub의 내용을 메모장으로 읽어서 붙여넣으면 된다. (포스팅을 위해 다시 만듬 ㅠㅠ)

5. 데이터 가져오기

git clone git@github.com:iseohyun/html.git를 입력해보자.

만약 아래와 같이 나온다면 디렉토리가 잘못된 것이다.

iseoh@SeohyunBook MINGW64 ~/OneDrive/Document
$ git clone git@github.com:iseohyun/html.git
Cloning into 'html'...
no such identity: /c/Users/iseoh/.ssh/iseoBook: No such file or direy
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

c:/User/iseoh는 "사용자 폴더"이고, ".ssh"폴더가 인증서 관리하는 기본 폴더이다. 들어가보면, config 파일과 know_hosts파일이 보일텐데, 둘다 텍스트 파일이라 메모장으로 열면 열린다. 리눅스놈들이 확장자를 사용하지 않기 때문에, 윈도우로 자동화 할 방법이 없다.

먼저 config파일이 잘 못 되었을 수 있다. 아래는 config 예시파일이다.

Host github.com
	User iseohyun
	Hostname github.com
	PreferredAuthentications publickey
	IdentityFile ~/.ssh/iseoBook/iseohyun

각 항목을 자신에게 맞게 수정하자. 위 에러는 마지막 IdentityFile항목이 잘못되었음을 경고하고 있다. 폴더가 아니고 파일을 가르켜야 한다.

known_host는 기계가 작성하는 항목으로, 최초 접속시 접속내용을 기억하겠다고 하면 자동으로 기록해준다. 처음 물어봤을 때, yes라고 대답하면 끝난다.

$ git push
The authenticity of host 'github.com (20.200.245.247)' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com' (ED25519) to the list of known hosts.
Everything up-to-date

정상적으로 동작한다면, done을 보게 된다.

$ git clone git@github.com:iseohyun/html.git
Cloning into 'html'...
remote: Enumerating objects: 64, done.
remote: Counting objects: 100% (64/64), done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 64 (delta 17), reused 55 (delta 8), pack-reused 0
Receiving objects: 100% (64/64), 489.87 KiB | 631.00 KiB/s, done.
Resolving deltas: 100% (17/17), done.

IIS서버 설치

Web에 올릴 준비가 되었으니 올리기 전에 테스트 해 볼 서버가 있으면 더 좋겠다는 생각을 한다. 조금 아는 사람들은 "그냥 파일을 열어보면 되지 뭐하러 내가 나한테 접속을 하는 삽질을 한단 말인가?"라고 할 수도 있다. 99% 맞는 말이다. 그렇지만 브라우저는 웹서버 해석기의 모든 기능을 하지 않는다. 게다가 git서버는 Web반응하는데 몇 분이나 걸린다. 고작 몇 분? 사실 몇 초만 걸려도 일하기 싫어진다. 5분 동안 담배 한대 피우고 오지, 커피 한 잔 마시고 오지 이러다보면 하루가 간다. 결코 경험에서 우러나와서 하는 소리가 아니다.

apache가 이 분야의 원조다. 무룐데 강력크하다. 얘네가 안된다고 하면 불가능한거다. APM쓴다고 옛날부터 삽질 많이 했다. 근데 그냥 뭔가 더 깔고, 어플이 돌아가는 걸 자꾸 나한테 보고하니까, 좀 더 심플한 것을 찾다가 IIS를 5분만에 설치해버렸다. IIS는 윈도우의 부가 기능이다. 난 윈도 살 때, 같이 산 기억은 없는데 동봉되어 있더라는...

자세한 설명은 생략한다. (☞ https://jsitclub.tistory.com/56)

※ Windows11을 사용중이라, UI가 조금 달라서 첨언하자면, 설정판>>앱 >> 선택적 기능 >> 관련설정 >> 기타 Windows기능>> Windows 기능 켜기/끄기 창에서 >> 인터넷 정보 서비스 >> 확인

이게 다다. 정말로... 이제 127.0.0.1로 접속하면 바로 화면이 나온다. 문제는 폴더가 마음에 안든다. 테스트 폴더(C:\inetpub\www)에서 작성하고 다시 클라우드 서버로 옮기는 것은 매우 잘못되었다. IIS관리자를 열면 아래와 같이 나온다.

설정하기

Default Web Site를 클릭하면 왼쪽에 작업탭이 열린다. 기본설정을 열고 아래와 같이 바꿔준다.

위 화면처럼 경로를 내 마음대로 바꾸어준다. 아마 실행해보면...

아마도 HTTP 오류 401.3 - Unauthorized 에러가 발생할 것이다. 접근 권한이 없는 것으로 나오는데, 작업관리자에서는 IIS의 소유권이 SYSTEM에 있는 것으로 나온다. 아쉽게도 SYSTEM만 권한을 주면, 한 번 열리다가 다시 권한이 없다고 나온다. 야메 냄새가 나기는 하지만 어쩔 수 없이 Everyone의 읽기 권한을 부여해주니 잘 동작한다. SYSTEM에는 모든 권한을 Everyone에는 읽기권한을 부여했다(오른쪽). TrustedInstaller라는 개체가 보여지지 않아서 설정할 수는 없지만 아래 목록처럼 설정할 수도 있다. 내가 은행권에서 일하고 있지 않으니 당신들의 예금은 안전하다. 아마도... 권한 주는 방법은 해당폴더에서 "우클릭>>속성>>보안>>편집>>추가"를 통해 진행하면 된다.