프로젝트 회고 - 나만의 위키 만들기

• 공부 기간 : 2024.01.22. ~ 2024.02.23. (조금씩 기능 추가하고 UI 바꿔가며 진행중)
• Tool : spring , spring boot , mysql , mobaxterm , AWS lightsail , filezilla , Linux ubuntu ... 등
• 동기 : 내가 속한 동아리에 동아리 부원들이 노는 사이트가 있는데, 동아리 전용 나무위키 같은 개념이었다. 그 범위를 더 축소시켜서 나와 내 친구들만 쓰는 나무위키가 있으면 좋겠다는 생각을 했다. 그래서 처음에는 나무위키 클론 코딩을 해보고 싶었는데, 생각보다 정보가 잘 나오지 않아서 1달 안에(개강 전에) 프론트엔드도 없이 혼자서 시도하기는 무리였다. 백엔드 기능만 하는 거라면 어찌저찌 해보겠지만 프론트에 대해 무지했기에... 위키는 조금 접어두고 비슷하게 게시판을 좀 만들어서 배포하고, 대신 복습겸 주석을 최대한 많이 달아야겠다고 생각했다. 그렇게 찾은 것이 바로 위키독스에 있는 '점프 투 스프링부트'였고, 이것을 조금씩 변형해서 만들어봐야겠다는 생각을 했다. UI까지 바꾸고 싶은데, 그것은 잘 안돼서 아쉬웠다. 해당 책을 참고하여 변수설정, UI, 기능 등을 조금씩 변경하고 추가해서 만들어보았다.  https://wikidocs.net/160022

0장 들어가기 전에

 

2/23 첫 배포 후 결과물

 

고난과 깨달음1 - 버전문제 (Mysql 8.0)

mysql 8.0부터는 보안이 강화되었는지.... 이것저것 안되는 게 많았다. 예를 들어 8.0부터는 계정 생성과 권한 부여를 동시에 할 수 없다든가 ...  그래서 약간 애를먹었는데 앞으로는 버전을 몇으로 하는지도 신중하게 생각해보아야겠다... 쉽게 여길 문제는 아닌듯하다. 예전에 spring security 할 때에도 6.0 이상에서는 문법이 달라져서 검색한 것을 적용해도 잘 되지 않아서 어려움을 겪었던 적이 있었다. 앞으로는 버전을 잘 확인하고, 버전에 따른 주의점, 문법 변경점 등을 확인하며 작업해야겠다.

 

고난과 깨달음2 - 접근권한

접근 권한에 대한 문제가 굉장히 많았다 ... 권한을 주지도 못하고 접근도 못하고 이래저래 좀 치였다 ... 들어가지도 못하고, 들어가서도 뭘 만들지를 못하고 ... 예시로 static ip에 맞는 user를 생성할 때, kwang이라는 username을 가진 유저를 생성하고 이걸로 진행하고 있었는데, 이렇게 고정 ip에만 맞는 유저를 생성해서 그런지, workbench에 연결할 때 권한이 없다고 떴다. 그래서 권한을 주려고 했더니 권한을 줄 권한이 없다던데.... 이게 무슨..? 방법은 root를 만들고 root에 권한 부여 후 그걸 쓰라는데 괜히 꼬일까봐 안하고 있다. 그리고 mobaxterm에서 하는 cli 작업도 적응하면 좋을듯해서 그냥 cli에서 sudo mysql로 DB를 접근하고 있는 상황이다.

 

고난과 깨달음3 - 버그 / 버그 아닌 버그

1) 배포 후 깨달은 코드 오류

배포 후 친구들에게 사용하게 해보고 결과를 봤는데 댓글을 달아도 계속 게시글의 사용자명이 댓글에 달리는 것이었다. A가 쓴 게시글에 B가 댓글을 달아도 A가 댓글을 단 것처럼 표시가 되었다. 결과적으로 게시글도 A가 쓰고... 댓글도 A가 쓴 모양새인데 개발단계에서는 미처 알지 못했다. 코드를 확인해보니, 댓글 작성자를 {답변.작성자}로 표시해야하는데 {게시글.작성자}로 잘못 표시한 것이었다. 이게 {게시글.작성자}로 표시를 해도 버그도 아니고 오류도 아니기에 빨간줄도 안쳐져 있었다. 그래서 인지조차 못하고 있었는데, 개발단계에서는 몰랐던 버그(?)가 배포 후 알게 된 것이 신기했다. 테스트를 더 많이 해봐야겠다는 생각과, 이래서 유지보수 단계가 개발단계보다 더 길다고 말하는 건가 싶다.

 

2) 리눅스 대소문자 구분

mobaxterm에서 백그라운드 서버를 손쉽게 켜고 끄기 위한 파일인 start.sh와 stop.sh를 만들었었다. 근데 ./stop.sh 에서 내가 WIKI_PID를 wiki_PID라고 쓴 것 때문에 아무리 ./stop.sh를 해도 실행중인 프로세스가 아니라고 뜨는 것이다. 그래서 알고보니 대소문자가 바뀌어있었고, 혹시나 해서 대문자로 고치기 제대로 작동하더라니.... 리눅스가 대소문자 구분을 이렇게까지 엄격히 하는가 싶어서 찾아봤더니 결론은 대소문자 구분을 했다.. 몰라서 오류를 겪은 것이다 보니 약간 웃기기도 했는데, 리눅스의 모든 "명령어"는 소문자로 되어있고, 대소문자를 구분한다고 하니 나중에는 이런 실수 안하겠지...

 

고난과 깨달음4 - $2a$10$

배포하고 유저 정보를 보고 있는데, 우연히 비밀번호 앞이 다 같은 문자로 시작하는 것을 보았다.

복호화 단계에서 특정 암호 알고리즘을 썼다는 것을 알리기 위함이 아닐까 싶어서 검색해보았다. 알고보니 BCrypt 암호화 방식이라더라.

• $2a : bcrypt 버전 정보 (알고리즘 식별자 역할)
• $10 : 키스트레칭을 돌린 횟수(이 횟수만큼 Hash function을 "다시" 돌려서 또 암호화함)
• 그 뒤 : salt + 인코딩된 암호 (hash값)

이를 통해 만약 암호화된 비밀번호가 노출되었다고 해도 엄청난 반복횟수로 해커들이 쉽게 정보를 해독하지 못하도록  한다. 온라인으로 BCrypt를 사용하는 사이트가 있다고 하니 심심하면 해보자. https://www.devglan.com/online-tools/bcrypt-hash-generator

Different Online Crypto Tools

 

고난과 깨달음5 - 서버 구축

서버 "구축"이란 것이 무엇인지 전혀 몰랐다. 서버는 AWS에 이미 있는 것 아닌가? 아래 쓰는 것이 맞는지 아닌지는 아직도 확실하지 않지만 내가 생각하는 서버 구축은 이런 플로우다. (틀린 내용일 수도 있다 ...!)

aws의 static ip 번호를 가지고 와서 연결을 해줘야 하는데, 이때 서버 내에서도 Mysql을 설치하고 active 해줘야하는 것이다. 서버에 mysql이 없어서 엄청난 오류를 많이 겪었었다. 그리고 유저도 만들어줘야했는데, 모든 접근 권한을 가진 유저를 만들거나, 해당 ip에만 접근할 수 있는 유저를 만들거나 선택이었다. 나는 후자로 유저 하나를 만들어서 서버 내에서 mysql에 접근하고 있다.

그렇게 mysql로 이것저것 해보는데, 파일을 실행시켜도 자꾸 테이블이 없다고 뜨는 것이었다. 근데 JPA를 사용하고 있었기 때문에 테이블을 내가 직접 create ... 하면서 만드는 것은 아닐텐데 ... 라는 생각으로 오류를 찾고 있었다. 이것도 접근 권한의 문제였던 걸로 기억한다. ABC라는 유저가 해당 ip에 접근할 권한이 없다고 뜨거나 아니면 connection refused라고 계속 떠서 정말 힘들었다. 결과적으로 내 예상대로 서버 내에서 직접 create로 테이블을 만들거나 이렇게 해야하는 것은 아니었다. // 여담으로, JPA가 테이블 만들어준다는 것을 알고 절대 테이블 문제는 아닐 것이라는 굳은 믿음으로 다른 해결법을 적용했던 것이 핵심이었다고 본다.

 

고난과 깨달음6 - 배포

배포가 처음이었기에 2월 18일부터 5일간 붙잡고 있었고 ... 그 전에 시도했던 것도 포함하면 거의 7-8일 정도를 배포 문제를 겪었던 것 같다. 앞서 말했던 내용들이랑 좀 겹치기도 하니 짧게 이야기하면...

애당초 이 프로젝트를 한 이유가 배포 프로세스를 경험해보고 싶어서였다. 개발 자체는 금방 끝났는데 무슨 배포하는 단계에서 오류만 엄청 만나고 1주일 넘게 걸렸다. 진짜 웬만하면 포기 안하고 싶은데 중간중간 그냥 포기하고 나중에 다시 해볼까 생각도 들었다. 매일매일 다른 오류를 마주했고 모두 실패했다. 오늘은 서버 구축에서 에러, 해결하면 Mysql 버전문제가 날 기다리고, 이걸 해결하면 Mysql 사용자의 접근권한 문제 등 ... 매일매일 다른 에러를 겪는 것은 진짜 고통이었다.

근데 한편으로는 오류를 해결할수록 DB와 가까워지는(?) 느낌이 들었다. 진짜 물리적으로 DB에 한발자국씩 들어가고 있다고 생각이 들어서 매일 다른 에러를 겪었지만 포기할 수 없었다. 그리고 결국 약 10일간 배포 하나만 붙잡고 있던 결과로 다행히 해결할 수 있었다.

 

마무리

위에서 언급한 것 외에도 HikariPool-1 - Starting... 여기서 움직이지 않는 에러나... 뭐 기타 에러는 참 많았는데 왜 해결됐는지 모르고 성공했기에 따로 언급하지 않았다. 쉬워보이는 프로젝트였는데 생각보다 많은 툴을 경험할 수 있었다. 그리고 대학교에서 "시스템 소프트웨어"라는 과목에서 배운 linux를 어디에 쓰는지 이해도 못했는데 직접 서버관리를 해보니 이렇게 cli 환경에서 관리하기 위해 배워야하는 것을 알게 되었다.

지금 현재도 기능을 추가하고, UI를 수정하며 다시 JAR파일을 만들어서 파일질라로 넘겨서 mobaxterm에서 배포하고 ... 과정을 계속하고 있다. 나만의 위키는 더 발전하고 있고 내 생각대로 바뀌고 관리할 수 있다는 것이 큰 재미라고 생각한다. 뭐든 만들어보라는 선배들의 말이 이래서 나온 것일까. 좋은 경험이었다.

2024.02.24.