인트로
해커톤 대회가 있다는 사실은 입대하기 전부터 알고있었다. 하지만 내가 할 수 있을까. 훈련소에서 179번 훈련병을 만나지 않았다면 그저 겁을 먹은 채 끝났을 대회.
대회는 내가 훈련소 때 관물함에서 React.js 책을 꺼냈을 때 부터 시작됐다. 옆자리 강은솔 훈련병이 심심해보여 내가 가지고 있는 책을 주려 했는데 전공책이라 어떡하지 라고 고민하던 도중, " 어? 컴공이세요? " 라는 그의 말. 38일의 훈련소 기간 동안 우리는 함께 대회에 대한 꿈을 키워 나아갔다.
참가신청
군 해커톤 대회는 총 4단계의 신청 과정이 존재한다.
- 온라인 교육
- 이론 평가
- 코딩 테스트
- 개발 계획서
온라인 교육 & 이론 평가
일단 주제를 정하지는 않았지만 블록체인을 메인 스택으로 가져갈 생각이였기 때문에 클라우드 과정을 선택했다.
처음 교육 주제를 접한 내 심정은 이..이게뭐야 라는 느낌이였다. 도커, 클라우드 네이티브 등등 개념적으로만 알고있던 내용들을 세부하게 들어가는 수업들이라 이걸로 시험보면 어떻게 보지.. 했지만 열심히 공부한 결과(ㅋㅋ) 95점인가 맞았던 것으로 기억한다. 21년 해커톤 후기를 보니 웹은 만점이 대부분이지만 클라우드는 80점대가 대부분인 걸 봐서 점수를 보고 스스로 뿌듯해했던 기억이 있다 ㅎㅎ
코딩 테스트
코딩 테스트가 제일 문제였다. 살면서 한 번도 코딩 테스트 연습을 해 본 적이 없었기 때문에 되게 막막했던 기억이 있다.
함께 해커톤 준비를 했던 은솔이와 은솔이의 친구분과 같이 스터디를 하며 실제 신청기간 전부터 계속 공부했다. 큐/스택 문제부터 bfs/dfs까지 "나는" 거의 문제 유형과 풀이 과정을 외우다시피 공부했다. 그래도 첫 시험이라 떨린건가 공부한 방식이 효율이 좋지 못했던 건가는 모르겠지만 그래도 212점을 기록하며 33등을 했다. 무슨 문제가 나왔는지는 비밀이다.
개발 계획서
우리 해커톤의 방향을 결정하는 단계이다. 처음 은솔이와 전화로 토론을 했을 때에는 블록체인의 분산 데이터 저장과 임의 수정 불가능성이란 기술적 특징을 포인트를 잡았다.
기술의 본질을 바라보니 먼저 떠오른 것은 클라우드 스토리지 서비스였다. 네트워크 운용병 특기를 받고 군복무를 한 나는 소위 전산병의 일을 했다. 통신계의 행정병이라고 볼 수 있는데 문서작업을 할 일이 많았었다. 일은 계속 쌓이고 관리해야 하는 문서는 많아지고 비밀 문서는 비밀 문서대로 따로 처리해야 하는 불편함이 있었다. 따라서 이를 Pain Point 로 잡아서 문제 해결을 해보자고 했다.
Pain Point는 우리 해커톤의 전체적 기반이 되는 단어이다.
군 부대 내에서 불편했던 점을 우리의 기술력으로 해결했다 라는 기승전결로 이루어진 이 단어가 우리가
Keep Your Endeavor를 기획하게 할 수 있는 원동력이 됐다.
하지만 이는 곧 특별함의 부재. 다시말해 주최측의 관심을 끌 수 있을만한 주제인지 의심됐다. 구글클라우드, 아이클라우드, 원클라우드 등 기존에 존재하는 기술을 군부대로 가져온다라는 점이 전혀 매력적이지 않았던 것. 또한 이 기술의 활용도 클라우드의 기능은 이미 군부대 내부에서 여러 갈래로 모듈화 돼 사용되고 있었다.
아래는 부소대장님과 주제에 대해서 이야기를 나눈 내용이다. 다시금 부소대장님께 감사말씀 드리고싶다.
부소대장님과의 대화
문제점
간부들이 카톡을 하면서 실제로 대외비의 수준의 비문도 주고받지 않는다고 합니다.
또한 파일도 전혀 주고받고 있지 않구요. 그 증거로 군 관련 자료들은 거의 대부분 국방망에서 다루는데 국방망에서 인터넷망인 핸드폰으로 자료를 옮겨오는 것이 물리적으로 불가능하다는 지적이였습니다.
질문사항
Q1. (보안이 지켜진다는 가정하에) 채팅 앱으로 업무 파일을 주고받을 수 있다면?
A. 의미없다. 애초에 주고 받을 파일은 망이 분리돼 존재하기 때문에 활용 가치가 낮다.
Q2. 비문을 핸드폰으로 주고 받을 수 있다면 편리한가?
A. 핸드폰에서 국방망으로 채널이 생성돼 옮길 수 있고, 그에 따른 보안절차가 마련된다면 편리하겠지만 그 과정이 복잡할 것이고 그 과정이 생략된다면 의미가 없다.
Q3. 파일을 국방망으로 연결할 수 있는 채널이 생긴다면 어떠한가?
A. 편리할 것 같지만 보안성에 대해서는 계속 걱정이 된다. 비문은 개인 PC에 저장돼 있으면 안되기 때문이다.
Q4. 군 내에 클라우드 서버를 구축해 파일을 올리고 내릴 수 있다면 업무에 도움이 되는가?
A. 이미 메모보고로 위와 같은 기능을 사용하고 있고, 파일 버전 관리의 문제는 사용자의 미숙함이 문제이지 체계의 문제가 아니다. 추가로 영환이한테 내 의견을 좀 덧붙여 주자면 핸드폰으로 비문을 주고 받는것 보다 데스크탑에서 1:1 로 연결된, 혹은 N:M으로 연결된 채널이 임시적으로 생성돼 비문을 주고 받는 것이 더 메리트가 클 것같다. 또한 비문의 경우 개인PC에는 저장하는 것이 안되지만 너 말대로 공통된 공간에서 보안성을 유지한 채 관리된다면 그건 문제가 없을 것 같다. ( 말씀 이후 1:1 채널은 이미 엣000-R로 기능이 수행되고 있다고 말씀. )
정리
핸드폰 ( 인터넷 망 )으로 보안유출이라 문제삼을 정도의 내용들이 오고가지는 않는다. 분대결산, 유동병력 등의 예시를 들어보았지만 이는 대외비 수준도 아니고 그냥 평문에 지나지 않는다 하셨음. 유동병력의 경우 최소 지휘관 이상의 중령급 인사의 휴가내역부터가 대외비로 취급된다고 함.
핸드폰으로 파일을 주고받지도 않는다. 애초에 파일을 핸드폰으로 옮길 수 없고 인터넷망으로 오가는 파일들은 애초에 비문이 아니기 때문에 문제되지 않는다.
새로운 의견??
App에서는 파일을 따로 주고받지 않기 때문에 App에서 존재하는 파일은 연결된 DB 서버에 근거한다.
따라서 App과 DB서버 간의 채널이 필요하며 DB서버는 국방망에서도 접근 가능한 환경이여야 한다.
따라서 Front 서버를 Native-App과 Web 두 트랙으로 나누어서 활용도를 높힐 필요가 보인다.
저장소는 Web에 근거해 파일을 주고 받는다. App 자체에서는 파일의 내용만 볼 수 있고 기타 저장소에 저장할 수 없다. App은 Web DB에 접근할 수 있는 인증, 보안의 기능을 충족시킬 수 있는 열쇠의 역할을 한다.
또한 비문의 경우 Web에서 송수신자들의 N*M 채널을 설정해 주고 받으며 채널은 단일성으로 만든다. ( 저장되는 클라우드 공간은 허가자에 대해 Opening 상태지만 클라우드 공간에 접속하는 과정과 수정하기 위한 작업을 위해 다운로드 받는 행위에 대해서는 stateless 를 유지한다. )
그렇다면 이 앱은 무슨 pain point를 해결할 수 있는가?
1. 기능의 확장
USB, CD 등의 물리적 저장장치에 대한 유출, 보안사고를 걱정할 필요가 없다. ( 보안성이 증명된 인증된 채널에서 파일을 이동하기 때문. )
2. 비문 작업의 유연성 제시
기존 : 비문은 국방망에서 저장하고 가지고 있으면 음성비밀이 되므로 인증된 USB로 네트워크 망을 제거한 채 작성하고 보관해야 함. H/W 유출, 사용자의 미숙함 등을 이유로 문제 발생 가능성이 농후함.
개선 : 비문을 인증된 보안 클라우드 저장소에 저장해 App으로 인증된 사용자가 log를 남기고 나서 절차를 통해 ‘열람’ 후 ‘수신인 설정 후 발송’ 등의 행위를 할 수 있음. 이 모습은 약간 짱구는 못말려에서 나오는 가운데 공간에 다리가 한 번 놓이고 건너가면 다리가 끊김. 그리고 돌아갈 때 다시 인증을 해서 다리가 생겨서 돌아갈 수 있는, 그런 stateless를 생각 중..
3. 암호화 채팅이 가지는 pain point 가 있겟쮸?
결론
Cloud의 주 기능을 버전관리가 아닌 비문의 보안성 전송 및 열람, 보관에 초점을 달리 잡자. ( 기존에는 망을 전장망과 국방망으로 나누는 수고가 필요했음 )
Web Cloud에 파일들을 저장하는 것이다. App에선 열람과 수신인 설정후 발송만 가능함. ( 터미널 역할만 가능)
즉, 블록체인 인증기능을 기반으로 하는 암호화 채팅 App이 Entry Point가 되는 암호화 DB Cloud로 방향을 잡아보자,,?
그러나 결국 우리는 암호화 채팅이든 ( 부소대장님과 대화를 통해 나온 생각 + 은솔이의 아이디어 ) 클라우드 서비스든 군 장병 전체 ( 병사 + 간부 ) 가 만족할 수 있으면서 사회적 효과성을 보여줄 수 있지 않다고 판단했다.
그래서 나는 똥글을 썼다. 진짜 똥글이다.
너무 무게잡지 않고, 틀 없이 아이디어가 떠오를 때마다 글을 썼다. 기준은 정말 간단하다.
군 장병인 내가 군생활을 하며 불편했던 점이나 기술력으로 극복 가능한 문제점을
해결할 수 있는 Pain Point를 찾는 것
맘 편히 쓰니 참 여러가지 아이디어가 나왔다.
- 병 자기능력 평가표 전자문서화
- 경작서와 총기수불대장의 연동과 전자문서화
- 출타인원 자동 결산 시스템 ( by block chain )
- 블록체인 기술을 이용한 클라우드 서비스
이에 나는 당시 진급시험에 굉장히 신경을 쓰고 있었고 특급을 여러 개 맞으며 상병 진급을 한 터였다. 그런데 후임은 진급시험을 단 하나도 보지않고 그저 숨만 쉬고 진급을 하는게 아닌가. 이에 너무나 억울한 나는 중간 관리자가 개입할 수 없는 진급 시스템을 만들고 싶었다. 그래서 탄생한 것이 KeepYourEndeavor - 너의 노력을 지켜라 이다.
아래는 아이디어가 나온 과정이다. 정말 의식의 흐름을 주체할 수 없었다.
생각의 방향을 최대한 기존 틀을 벗어나지 않는 선에서 해보자.
암호화 채팅 서비스
암호화는 블록체인 기술과 다르다.
블록체인은 p2p환경에서 다수의 node가 동등한 관리자 입장에서 자료의 변조, 위조를 막으며
고유성을 인증받는 기술이다 - 협의, 합의 등등...
암호화는 그냥 암호화 알고리즘 몇 개 돌려서 꽁꽁 싸맨채로 db에 저장하고 불러올때 복호화하면 됨.
블록체인 기술이 기반이 될 오브젝트 :
신분증, 문서인증서, 채팅방 개설/삭제 로그?, 명함..?, 출입증… 등등
기존 문제점의 쟁점 :
보안이 필요한 내용들이 평문저장되고있다.
신분이 확인되지 않은 사람이 접근할 수 있다.
평문 저장의 경우 → DB 저장시 암호화
파일/문서의 경우 → 문서등록대장을 체인에 올려놓고 대장 → 채팅방 → 문서 순으로 링크되게 업로드 한 뒤에 파일/문서를 가져올 때 신분증을 확인해서 다운받을 수 있도록 함. ( 채팅방 내부에서는 파일, 문서 공유 불가.)
→ 2020년 3월 기준 정보 유출의 케이스에서 보면 정보가 유수되는 끝 점은 군 관계자가 아닌 사업자들이였다.
문서등록대장에 붙이고 땔 수 있는 플렛폼이 되는 채팅방 역시 함부로 개설되고 삭제되면 안되므로 로그를 관리해야 함.
신분증이 생겨서 다른 부대에 들어가거나 NFC칩이 담긴 공무원증을 반드시 지참할 필요가 없이 핸드폰 하나로 해결되기 때문에 편리 ( 부가 기능 )
생각을 완전 논외로 해보자면??
수정이 불가하다는 블록체인 기술을 생각해보자.
데이터의 변화가 방향성이 없다.
시간도 방향성이없다
삼단논법에 의해서 블록체인 기술은 시간이다.
시계를 만들자.
수정이 불가하다.
무언가 인증할 수 있는 최적의 도구이다.
전산장비 불출현황, 통신장비 불출현황, 군수품 불출현황 등?
아니야 의미없어. 어차피 가라치잖아.
살어리 살어리랏다
군대에 살어리랏다
일백번 고쳐죽어
거지꼴을 못면한다.?
병사들의 군자기능력평가표를 온체인시켜서 행정병이 가라를 못치게 막는거야.
난 상병달라고 입에 거품물면서 3키로 뜀걸음 12분나왔는데 후임련은 그냥 가라로 올려서 상병됨
병진급인증마크를 다는거지. → 너 당첨
서버를 담당하는 내가 할 수있는 걸 생각해보자
routing, session, token passing, socket 통신, db구축-관리, data가공..은필요없고 , 블록체인 서버로 request ( 클라이언트가 되어보기 - “ 블록체인님,, 국이 좀 짜네요? “ )
경계작전명령서랑 작전판단서를 블록체인에 실어버리는건?
둘 다 수정되선 안되는 중요한 문서임과 동시에 대외비니까.
이미 엣ooo 2차로 쓰고 있긴 하니까 의미없긴하겠네.
인증받는다는 쪽에서는 NFT도 생각해보자.
단 N개만 발행되는 토큰에 어떠한 데이터를 넣어서 토큰의 소유주가 데이터의 소유주가 되는
다시말해, 네트워크안에서 소유권이 인정되는 것이다.
원본을 인증받음과 소유권을 인정받아야 하는 자료에 사용해햐 하는데
군부대내부에 그런 게 있었나?
비문의 생산자 정도?
비문의 원본은 NFT로, 사본은 해당 내용의 복사로? 좀 이상한데
비밀관리기록부 같은느낌?
개발 시작
처음에 내 API 서버를 테스트하기 위해서 헉 프론트 서버 하나 더 돌려야하나? 했는데 마침 블록체인 책을 보면서 공부하던 도중 postman을 만났다. 약간 다 이런식이다. 어 이거 어떡하지? 어 이거 쓰면되네. 어 이게 왜 안되지? 어 이거 쓰면 되네 이런식. 이번 해커톤을 하면서 굉장히 다양한 SaaS를 만났고 정말 감사한 마음을 가지며 사용했다.
이번 프로젝트에서 내가 담당한 부분은 DB 설계, API 서버 개발, IoT 개발, 문서화 이다.
DB 설계
DB를 설계하면서 가장 중요하게 생각한 점들은 객체와 트렌젝션 두 분류로 테이블을 나누고 해당 테이블을 정규화 하는 부분들이다. 사실 유지보수가 필요한 프로젝트는 아니여서 대충해도 되지만 그렇게 되면 발전이 없다 생각해 최대한 내가 아는 DB 설계 지식을 활용했다.
API 서버
KeepYourEndeavor 프로젝트는 분산형 데이터베이스인 블록체인에 점수를 온체인 시켜 제 3자가 자격을 임의 수정할 수 없게 하는데 의의가 있다. 그에 따라 사용자의 실질적인 정보는 KY2 체인에 온체인 되고 API 서버의 DB에는 사용자의 권한에 대한 부분과 시험 종류, 공지 등의 Authentication과 Notification의 내용만을 담고있다. 권한 인증을 위해 Token을 활용했고 ( Redis DB 활용 ) 시험 종류나 점수 기준등 NoSQL 정보를 처리하기 위해 Firebase DB를 활용했다.
서버 개발을 진행하면서 지금 되돌아 생각해보니 아쉬웠던 점은 하나의 라우터에 여러 매소드를 달아놓고, 접근 제한 status code를 날려주도록 설계하는게 맞다는 생각을 뒤늦게 했던 점이다. 프론트 개발자와 군 특성상 매일 토의를 거칠 수 없기에 서버 측에서 필요하다 싶으면 열어놓고 프론트에서 필요없다 싶으면 그런갑다 하고 놔두었었는데 후에 Delete 메소드를 가진 라우터에서 해당 DB의 의존성을 파악하지 못한 채 삭제를 했던 적이 있는데 해당 이슈를 처리하기 위해 모든 블록체인 노드들을 날려버리고 했던 아픈 기억이 있다... ㅜ
IoT 개발
정말 IoT는 살면서 처음 해본 분야이다. 처음 은솔이가 기기는 가져오고 코드 예시를 보여주었기에 망정이지 처음부터 해보라 했으면 막막했을 것 같다. 언어는 C를 사용한다. 그래서 일단 코드를 긁어오고 아 이게 이부분인가보다 하고 진행했다.
처음 겁을 먹었던 것과 달리 제일 재밌었던거 같다. 회로를 연결하고 저항을 붙이고 스위치를 작동시키는 과정에서 내가 생각한대로 기기들이 작동할 때 너무나 행복하고 재밌었다. 나중에 어떤 프로젝트를 하더라도 IoT 해본 적 있다고 자신있게 대답할 수 있을만큼 재미있고 즐거웠던 분야였다.
문서화
지금 블로그에 글을 쓰는 것 또한 문서화의 일부겠다. 정말 싫었다 ㅋㅋㅋ 신나게 개발할 때는 몰랐지만 내가 개발한 내용을 다른 사람들에게 보여주고 설득시키는 과정은 생각보다 힘들었다. 프로젝트 전반을 보여주지만 양이 방대해선 안되고 아주 그냥 알잘딱깔쎈을 했어야 하는 부분이라 IoT개발보다 오래걸린듯하다. Git Book과 Notion 그리고 Github를 활용했고 지금도 다시 보면 계속 고치고 싶은 마음이 들만큼 시간에 쫓기듯 진행한 파트이지만 그래도 하얗게 불태웠으니 만족한다.
육군참모총장상 수상
헬스장에서 운동하던 도중 은솔이한테 전화가 와서 상을 탔다는 말을 들었을 땐 정말 도파민이 폭발하는 듯 행복했다.
그동안 노력한 결과를 얻은거 같아 너무 기쁘고 뿌듯했다 ㅎㅎ. 정말 많은 걸 배웠다. 기술적으로도 커뮤니케이션으로도.
다양한 서드파티 서비스를 활용할 수 있고 맨 땅에서부터 개발해서 배포까지 하는 모든 과정을 몸으로 습득한 좋은 기회였다. 내 의견을 다른 사람들과 어떻게 공유하고 발전시켜나가는지에 대한 경험도 했고 나 자신에 대한 자신감도 생겼다.
남들은 일년 반을 군대에서 버리지만 나는 버려지는 시간속에서 나 자신에게 당당할 수 있는 결과를 낸 것 같아 일년 반이라는 시간을 잘 활용한 것 같다.
훈련소 시절부터 병장까지 함께 고민하고 꿈꾼 좋은 친구도 얻고 다신 없을 경험을 하게 된 군생활이였다!!
https://github.com/osamhack2022/CLOUD_APP_IOT_KeepYourEndeavor_Moment
'일상 > 군복무' 카테고리의 다른 글
| 군대에서 팀플하기 (5) | 2022.01.24 |
|---|---|
| 군 복무를 시작하며 (2) | 2021.09.04 |