Programmer's Progress

이제야 깃허브를 배우면서 소스코드를 관리하기 시작했다. 사실, 블로그에 개발과 관련된 공부를 한 내용을 바탕으로 프로젝트를 진행하면서 조금씩 내용을 정리하고 포스팅하면 그래도 도움이 될 것이기에 굳이 깃허브를 쓸 필요가 없다고 생각했다. 그러나 블로그에 올리는 것만으로 되겠지 싶었던 것은 혼자만의 착각이었다. 내가 깃허브를 배우고 활용해야겠다고 생각했던 것은 DBMS를 Oracle에서 MariaDB에 맞게 변경하면서 문제가 발생했고, 기존에 백업했던 소스코드로 다시 작업을 시작해야겠다고 생각했지만 어째 내가 생각했던 것보다 훨씬 더 전에 백업을 했었는지, DBMS연동이나 SQL Mapping과는 상관없는 많은 부분들에 영향이 있었다. 가령 도서대출 웹서비스라는 말이 어울리게끔, 도서 대출 신청과 대출 현..

게시글 수정 구현 방법과 관련된 내용을 소개하기 전에 앞서 게시글 수정을 구현하는 것이 얼마나 복잡하고, 어려운 것인지를 설명해야 할 것 같다. 먼저 게시글을 수정하기에 앞서, 수정해야 할 게시글의 제목, 내용, 이미지 등등을 백엔드 서버에 요청해야 할 것이다. 이때 JQuery의 AJAX기능을 활용해 비동기식으로 요청한다. 게시글의 제목이나 내용 자체는 DB에 저장된 내용을 SQL Mapping방식인 MyBatis프레임워크를 이용해 얻어오기만 하면 되므로 간단하다. 그런데 이미지는 이미지 자체를 DB에 저장한 것이 아니라, 서버 컴퓨터의 D:드라이브에 저장되어있고 DB에는 해당 게시글의 번호, 원본 이미지 이름, 난수 이름만을 저장하고 있다. 아래의 릴레이션 스키마를 확인해보자. 하나의 게시글은 여러 ..

게시글 삭제 구현 과정을 설명하기 전에 짚고 넘어가야 할 것이 있다. 먼저 기존의 코드 중에서 새로운 게시글, 메시지 번호를 얻는 방법을 변경하였음을 밝힌다. 기존 방식은 이렇다. SELECT NVL(MAX(article_id),0)+1 FROM free_board와 같이 현재 존재하는 게시글들 중에서 가장 게시글 번호가 큰 게시글의 번호 + 1을 새로운 게시글에 할당한다. 이 방식에는 큰 문제가 있었다. 1. 현재 게시글 목록에 번호가 1, 2, 3인 게시글들이 있고 각각 서로 다른 탭에서 참조하고 있다고 가정하자. 2. 첫 번째 탭에서 3번 게시글을 삭제하고, 다시 새로 게시글을 작성한다. 3. 두 번째 탭에서 기존 3번 게시글을 삭제하려고 하면, 이미 삭제된 게시글이 아닌, 2번 과정에서 작성한 새..

글을 수정하는 동작은 다음 포스팅에서 다룰 예정이다. 이유를 간단하게 밝히자면, 게시글 자체의 제목, 내용을 DB에서 새로운 내용으로 UPDATE 하는 것 자체는 정말 쉬운 일이지만, 해당 게시글에 첨부된 이미지 파일들의 경우 이것이 기존에 존재하는 이미지 파일인지 아닌지, 기존 이미지 파일을 완전히 삭제하려는 것인지 단순히 수정하려는 것인지 판단하는 것이 상당히 복잡한 과정을 거쳐 이루어지기 때문이다. 만약 게시글당 첨부할 수 있는 이미지 파일이 최대 1개로 고정되어있다면 단순히 글을 수정할 때 업로드하는 이미지 파일의 이름과 서버에 저장된 이미지 파일의 이름이 같은지 다른지 판단해서 처리하면 쉽지만 첨부한 파일이 여러 개인 경우에는 그렇게 할 수가 없기에 방법을 고안하느라 구현 시간도 오래 걸렸다. ..

앞서 구현한 메시지의 경우는 그 동작이 무척이나 간단했다. 그저 textarea 태그에 작성한 메시지 내용이나, input 태그에 입력한 제목을 그저 송신, 수신함 릴레이션에 데이터를 insert 했을 뿐이었다. 그런데 이번에 구현하는 게시판의 경우는 좀 얘기가 다르다. 단순히 게시글 내용만 DB에 저장하는 것이 아니다. 이미지 파일 또한 서버에 저장해야 할 것이다. 자유게시판, 문의게시판, 정보 게시판의 스키마 다이어그램 하나의 게시글은 여러 개의 파일을 첨부하여 작성할 수 있지만 하나의 파일은 하나의 게시글에만 첨부될 수 있으므로 1:N의 관계를 갖는다. 따라서 ER 모델링을 R모델링으로 변환할 때 1 관계에 속하는 게시글의 기본키인 ARTICLE_ID를 포함하여 임시 파일 이름을 기본키로 삼도록 스..

앞서 언급했듯이, 비밀번호는 절대로 복호화 가능한 형태로 암호화해서는 안 된다. RSA든, AES든, DES든 어떠한 암호화 알고리즘을 사용하더라도 복호화가 가능하다면 이 비밀번호가 담긴 레코드를 탈취당했을 때 큰 문제가 발생할 것이다. 따라서 복호화가 불가능한, 단방향 해싱 알고리즘인 SHA512와 랜덤 한 값 SALT를 갖고 비밀번호를 암호화하였다. 그러나 복호화가 불가능하기 때문에 비밀번호 찾기를 구현하는 데 있어서 큰 문제가 있었다. 복호화가 불가능하기에, 기존의 비밀번호가 무엇인지 도저히 알 수가 없다는 것이다. 단순하게 JS의 alert( )를 이용해 기존 비밀번호를 출력하기에는 큰 문제가 있었다. 기존 비밀번호가 무엇인지 알지 못할 뿐만 아니라, 알고 있다고 하더라도 이 비밀번호를 DB에서 ..

메시지 읽기 기능을 구현하는 과정을 설명하기 전에 먼저 웹서비스의 전반적인 구조를 변경했음을 밝힌다. 기존에는 스프링 프레임워크, 마이 바티스 프레임워크 등, 프레임워크의 도움을 받지 않고 라이브러리 추가부터 의존관계 구성, MVC 패턴으로 설계 등등 많은 것들을 직접 구현했었다. 하지만 스프링 프레임워크를 사용하지 않고는 DAO, Service, Controller 등의 클래스 객체들이 각각의 객체들의 정보를 담아두도록 일일이 생성자 및 setter( ) 메서드를 설정하기란 번거로운 일이었고 또한 마이바티스 프레임워크 없이 DAO클래스에서 질의를 수행할 때에는 일일이 SQL문을 작성해주어야 했기에 상당히 가독성도 떨어지고, SQL문을 작성하는 것도 어려웠다. 특히 DBMS에서 단일 SQL문에 대해서는 ..

본격적으로 백엔드 개발을 공부하기 시작하면서 상당히 많은 SQL문을 작성했었다. 가령 회원의 목록을 질의하는 것부터, 회원 추가, 삭제, 수정, 계층형 게시판, 답글 등등 심지어는 3중 SELECT문을 활용하기도 했었다. 그 외에도 여러 SQL문을 한 번에 수행해야 할 때도 있었다. 가령, 게시판에 새로운 글을 추가할 때에는 반드시 현존하는 게시글중에서 가장 큰 번호를 가진 게시글의 번호보다+1된 값을 새 게시글의 번호로 사용해야 할 때가 있었다. 그런데 만약 우연하게도 동시에 두 사용자가 게시글 작성을 했다면 어떻게 될까? 물론 단일 SQL 질의에 대해서는 DBMS가 동시성제어를 통해 마치 OS에서 프로세스 간의 공유 자원을 동기화하기 위해 세마포어나 락을 사용하듯, DBMS도 마찬가지로 ACID의 원..