이번 주에 운전면허 4일컷을 내야해서 아침 9시에 가서 오후 3~4시에 집에 도착해서 컴퓨터를 만질 시간이 별로 없을 예정이다.
전부터 백엔드의 전체적인 동작 구조와 원리를 이해하기 위해서 유튜브에서 백엔드 맛보기 영상 클론코딩을 해보고 있다.
사실 클론코딩이기도 하고 코드도 일일이 하기엔 너무 많고 내용도 많아서 다 적기에는 좀 그렇고 이번 글에서는 영상을 멈추고 나름 혼자 짜고 나서 봉착했던 난관과 이를 해결할 때 했던 내용들, 그리고 앞으로 내가 해나가야 할 것들에 대해서 적어볼 것이다.
Difficulty
1. button 태그를 이용 시 주의할 점
사실 이것은 클론 코딩을 안 하고 내 방식대로 하다가 실수를 하게 되었는데 이 때 알게 된 내용이다.
먼저 버튼 태그 자체가 클릭이 되면 새로고침을 하게 되는데, 이 때 기본적으로 Post 요청을 보낸다고 한다.
일단 강의에서는 버튼이 눌리면 새로고침이 되기에 console.log로 찍은 내용을 볼 수 없어서 임시로 p태그로 바꾸고 해당 p태그에 아이디를 부여해서 이벤트리스너로 처리해주셨다.
#register.ejs
<p id="registerBtn">Create</p>#register.js
registerBtn = document.querySelector("#registerBtn");
registerBtn.addEventListener("click",register);하지만 나는 "아이 그래도 버튼은 버튼으로 하고 싶고 데이터는 alert로 찍어봐야지"라는 생각에
#register.ejs
<button>Create</button>#register.js
registerBtn = document.querySelector("button");
registerBtn.addEventListener("click",register);어차피 회원가입 페이지에 버튼은 하나밖에 없었기에 쿼리셀렉터로 태그를 가져와도 되겠다는 생각에 이런 식으로 해놓았었다.
그리고 회원가입 코드는 이전 강의에서 짜놓으셨던 로그인 내용들을 복사해오셔서 회원가입으로 바꾼건데 잠시 그 내용을 가져와보면 이와 같다.
#login.ejs
<button id="loginbtn">login</button>#login.js
loginBtn = document.querySelector("#loginbtn");
loginBtn.addEventListener("click",login);눈치가 빠르신 분들은 벌써 뭐가 잘못 된 것인지 알아차리셨을 것이다.
현 코드 상황으로는 로그인은 정상작동, 회원가입은 제대로 작동하지 않는 것이다.
그래서 이제부터 정상작동되는 로그인과 작동하지 않는 회원가입을 비교하며 오류를 알아볼 것이다.
일단 무슨 문제가 있었는지부터 적어보면
먼저 회원가입에서는 버튼을 눌러도 아무 반응이 안 오길래 보니 fetch에서 오류가 났었고 해당 오류를 alert로 찍어보니 이런 오류가 났었다.
해당 오류를 구글에 검색해보니 서버에서 response로써 html을 보내서 태그의 시작인 <가 json이 아니라 뱉는 오류라고 한다.
참고로 정상 작동이 되는 로그인창에서 로그인 버튼을 눌렀을 때 서버에서 보내는 응답을 alert로 찍으면 이와 같다.
그래서 회원가입이 보내는 것이 html이 맞는지 더 확실히 하기위해 로그인과 같은 방식으로 응답을 찍어보니 이런 식으로 나오는 것을 보니 html을 보낸 것이 확실해지는 순간이었다.
결론적인 문제는 이것이다.
둘 다 같은 Post 요청을 보내는 데 하나(로그인)는 우리가 원하던 형식의 json을 보내고 하나(회원가입)는 해당 페이지의 통 HTML을 보내는가
이제와서 실토하자면 친구와 같이 머리를 맞대보았지만 확실한 답은 없었고 그냥 이래서 이런 것 같다는 뇌피셜만 나왔지만 그래도 말해보자면 저 둘의 차이는 id를 통한 선택인가 태그를 통한 선택인가의 차이밖에 없었다.
이제 본격적으로 분석하기 전에 알아둬야 할 점은 form 태그안에 있는 버튼은 위에서도 말했듯이 submit(~=Post)를 하게되는데 위의 Html의 공통점은 "어디"로 Post할지가 없었다는 것이다.
그래서 친구와의 "뇌피셜"을 말해보면 먼저 "id" 선택자를 통해 이벤트리스너를 해준 로그인은 버튼을 누르게 되면 바로 이벤트리스너에 있는 Post가 먼저 실행이 되어 우리가 원하는 json형식의 응답을 받을 수 있었지만 "태그" 선택자로만 선택했던 회원가입은 form안의 버튼을 눌렀을 때 기본적으로 실행되는 Post(즉 목적지가 없는 Post)가 실행되어 html이 넘어왔다는 느낌이다.
말이 어려워서 정리하면 각 코드에 있는 이벤트리스너의 post와 버튼태그 자체에 있는 목적없는 post의 충돌이라는 것인데 id선택자로 하면 우선 순위가 디폴트보다 높아져서 로그인만 실행되었을 것 같다는 말이다.
정상 로그인(id 선택자) : submit의 기본 목적없는 Post < 리스너의 Post -> 코딩한대로 응답
비정상 회원가입(태그 선택자) : submit의 기본 목적없는 Post > 리스너의 Post -> 요청이 이상한데로 감
그래서 결론적으로
회원가입의 html에도 아이디 선택자로 하면 되지 않냐고하니 친구가 그래도 되기는 한데그냥 요즘은 form안에 버튼을 안쓰는 추세라고, 굳이 쓸거면 form태그 바깥에 쓰라고 한다.
2. async/await , Promise 비동기처리
사실 이건 난관이라기보다는 문제를 초기에 잡아내서 앞으로의 다짐에 가깝다.
1학기에 웹프로그래밍이라는 과목을 수강했고 교수님께서 뭔지는 알려주셨지만 내가 애당초 수업을 잘 안듣기도 했었고 웹이라는 기술에 비해 한 학기라는 시간은 턱없이 부족했기에 교수님께서도 정말 대충 짚고 넘어가셔서 솔직히 몰랐고 이번 강의를 통해 알게 되었다.
처음에 수업을 들을 때 node.js의 장점중에 하나가 비동기 처리를 통한 효율향상이라고 하셨다.
하지만 시작을 같이 한다는 장점도 있지만 어떤 작업은 어느 다른 한 작업의 결과물을 필요로 하는 것도 있기에 동기식으로 짜야하는 상황도 필연적이다. 그래서 등장한 것이 promise인데
강의에서는 일단 코드를 다 짜고 "아~ 여기는 동기로 해야하죠~"라고하시면서 그제서야 동기처리를 해주셨는데 문득 '코드를 다 짜고 실행했는데 막상 동기처리가 필요한 부분이 있었으면 그 부분이 어딘지 어떻게 알지?'라는 생각이 들었다.
※ 참고로 위에 생각한 것 처럼 동기처리를 해주어야 하는 곳에서 안해주면 이런 식으로 undefined가 alert된다
그래서 실컷 코드 짜놓고 실행해보니 저렇게 undefined가 뜨면 어떡하나 싶어서 위와 같은 생각을 한 것인데 백엔드를 한 친구에게 물어보니 그래서 데이터를 넘길 일이 있으면 그때마다 console.log로 프로미스 객체를 뱉는지 확인을 해야한다고 한다.
그래서 위에 내용에 비해 많이 싱겁지만 사소하더라도 애초에 코딩 끝나고 부랴부랴 찾는게 아니라 처음부터 코딩할 때 동기처리를 확실히 하기위해 노력을 할 것이다.
To Do
1. 여러가지 DB 연동
사실 이때까지 써 본것이 MySql같은 관계형 데이터베이스밖에 없다.
이외에 몽고같은 비관계형도 써보면서 관계형을 쓸 때와의 장단점을 통해 어떤 기능에는 무슨 DB를 쓸지 체득을 해야할 것 같다.
+++
그리고 아무리 이제는 거의 방어가 되는 Sql Injection을 하기 위해서라도 이는 꼭 필요한 공부라고 본다.
2. axios / redis ................
우리 연구실에 계시는 분들이 지금 웹 프로젝트를 하고 계시는데 마침 백엔드 네 분이 모두 랩실에 계시는 분들이라 회의를 하시곤 한다. 난 이 부분이 좋은게 협업을 하시는 모습도 직접 볼 수 있기도 하고 생판 처음 들어보는 단어나 기술 스택이 나오면 이것도 공부해야 할 내용이라는 것을 깨닫기도 한다.
이 때 나온 것이 ajax, axios, redis 등등이 있는데 대충 찾아보니 강의에서 하시는 것 보다는 조금은 최신 기술인 것 같아 이쪽으로 조금 더 공부해볼 것이다.
3. 보안패치
어차피 나는 화이트해커가 될 것이고 직업으로써는 시큐어 코딩이나 모의해킹 + 솔루션 제시를 해야할 것 같기에 취약점을 분석하는 동시에 이를 막는 방법과 예방방법도 알아야 할 것이다. 그래서 애당초 코딩할 때 선제적으로 조치할 수 있는 보안패치도 해 봐야한다.
