소개

• 인원 : 1인
• 담당 : 프로그램 구현 전체
• 개발 환경 : Visual Studio 2015, CUDA 9.0
• 문제
  • Input
    • Data : 비트맵 이미지의 R, G, B 값
    • 화면 입력 : 불러올 이미지 파일 이름, 적용 필터
  • Output
    • 화면 출력 : 필터 적용에 걸린 시간, 저장된 파일 이름
    • 파일 출력 : 필터가 적용된 이미지
• 소스코드 : CUDA를 이용해서 멀티 스레드로 작동하는 Image Filter 프로그램

내용

1. 전부 다 늘릴 때와 각각을 늘릴 때의 차이

두 필터는 RGB에 일정 비율을 곱했다는 공통점이 있습니다. 이 중에 밝기 필터는 단순하게 모든 픽셀의 RGB값을 일정 비율만큼 더하면 되지만, 저희가 만든 필터는 채도를 올리는 방식이라서 붉은 계열 색상이라면 더 붉게 만들고, 푸른 계열 색상이라면 더 푸르게 만들어야 합니다.

2. 적용 방법

RGB 값을 비교하고, 가장 많이 쓰인 색을 높이는 방식으로 필터를 구현했습니다.

3. 병렬화 부분

그리드와 블록은 단순하게 설계하였습니다, 먼저 총 픽셀 수를 구하고, 블록 당 스레드 수를 지정하게 됩니다. 그리고 각 스레드는 한 픽셀 씩 맡아서 RGB값을 처리하게 됩니다. 이렇게 스레드가 한 픽셀을 맡게 되면 동기화 문제는 해결됩니다.

5. 결과 분석 (Intel i7-7700 & GTX 1070 기준)



각 필터 마다 CPU 시간을 GPU 시간으로 나누어서 계산한 차트입니다.
평균적으로 10배 이상의 성능 향상을 보이고, 그레이 필터는 다른 필터보다 더 빠른 23배 정도의 성능향상이 있었습니다.
아무래도 CPU나 GPU 둘 다 높은 성능 이라서 큰 차이가 보이지 않는 것 같습니다.

어려웠던 점

무작정 큰 값만 늘리다보니 문제가 발생했습니다. 이 주변은 하늘이라서 주로 파란색 값이 크지만, 이 부분은 구름과 겹쳐서 파란색보다 녹색이 더 많았습니다. 그래서 이 픽셀만 녹색이 더 증가하는 문제가 생기게 된다는 사실을 알았습니다.

이 문제를 해결하기 위해 허용 범위를 지정하였습니다. RGB 값의 차이가 일정 범위 이내라면 비슷한 값들을 한 번에 증가시켰습니다. 이렇게 증가시켰더니 이전 사진에서 구름 일부가 녹색으로 바뀌던 문제를 해결할 수 있었습니다.

배운 점

이전에 OpenMP만 사용할 때에는 CPU만 사용했기 때문에 스레드가 많아야 겨우 8개 정도였지만, 이번에는 그래픽 카드를 이용했기 때문에 훨씬 많은 수의 스레드를 생성하고 제어하였습니다. 이 프로젝트에서는 사진 파일이 가진 픽셀 수 만큼 스레드를 생성하였는데, 1024 X 1024의 사이즈를 가진 사진이라면 100만개 이상의 스레드를 생성하게 됩니다. 너무 많은 수의 스레드를 생성하다보니 이를 제어하는 것이 처음에는 어려웠지만, 점점 익숙해져서 잘 다룰 수 있게 되었습니다.

소개

• 인원 : 1인
• 담당 : 프로그램 구현 전체
• 개발 환경 : Ubuntu 16.04 LTS, VMware Workstation 14 Player
• 문제
  • 파일 전송 서버는 서버에서 실행중이며 클라이언트가 전달해주는 내용을 파일로 저장하고 보내주는 역할을 한다.
  • 파일 전송 클라이언트는 서버에 전송할 파일을 선택하여 전송하고, 서버에서 선택한 파일을 전송받아 저장하는 기능을 수행한다. (get : 다운로드 명령, put : 업로드 명령)
  • 클라이언트는 접속한 디렉토리에 대해서 파일을 업로드, 다운로드 하도록 함.
  • 서버에 전송한 파일을 저장하는 디렉토리는 서버 프로세스가 실행되는 곳으로 함.
  • 다운로드할 수 있는 파일은 전체 디렉토리를 대상으로 가능함.
    (퍼미션을 고려하여 다운로드 가능한 파일)
  • text 파일, binary 파일 모두 전송이 가능하도록 함.
• 소스코드 : Linux에 C로 FTP Server와 Client 작성하기
• 사용법 : Linux에 C로 FTP Server와 Client 작성하기

내용

컴퓨터의 수가 부족하여 부득이하게 로컬에서 서버와 클라이언트를 함께 실행하였습니다.

이 중에 위에 있는 터미널은 서버, 아래에 있는 터미널은 클라이언트 입니다.
클라이언트는 6가지의 명령을 사용할 수 있습니다.

• get : 서버에서 파일 다운로드
• put : 서버로 파일 업로드
• pwd : 현재 디렉토리 위치
• ls : 현재 디렉토리의 파일 목록
• cd : 디렉토리 이동
• quit : 접속 해제

어려웠던 점

평소에는 터미널에서 고작 문자나 주고받는 소켓프로그래밍을 하였지만, 이번에 파일을 통째로 전송해야해서 처음에 어떻게 구현을 해야할지 막막했습니다. 그래서 다른 사람의 소스코드를 참고해가면서, 파일 사이즈를 먼저 전송하고 그 이후에 파일을 전송하는 방식으로 문제를 해결했습니다.

배운 점

TCP 부분을 응용해서 구현해야하는 프로젝트였습니다. 처음에는 이 문제를 어떻게 해결해야 할지 고민이 많았지만 하나씩 차근차근 해결해나가다 보니 프로그램이 완성되어 있는 것을 볼 수 있었습니다.
기본적인 기능 구현 이외에 사용자 편의성을 높이기 위해서 더욱 직관적인 사용법을 도입하였고, 색을 통한 구분으로 가독성이 뛰어나도록 더욱 깔끔한 출력을 하기 위해서 많은 시간을 투자하였습니다. 이를 통해 사용자는 보다 편리한 사용이 가능하고, 손쉽게 파일을 주고받을 수 있습니다.
이렇게 사용자를 배려한 프로그램을 구현하다보니 평소에 습득하지 못했던 지식을 더욱 알아갈 수 있는 계기가 되었고, 실력향상에 많은 도움이 되었던 것 같습니다.

소개

• 인원 : 1인
• 담당 : 프로그램 구현 전체
• 개발 환경 : Python 2.7
• 문제 : CS188
• 소스코드 : Python을 이용한 팩맨 프로젝트 중 Search와 Multiagent Search 구현

내용

1. Search

위에 보이는 것처럼 미로에서 팩맨이 어떻게 하면 최단거리로 먹이를 찾을 수 있을 지에 대한 것을 구현한 것입니다. 이를 구현하기 위해서 DFS, BFS, UCS, A* 알고리즘을 사용하였고, 각 알고리즘을 서로 비교해보았습니다.

2. Multiagent Search

위에 보이는 것처럼 팩맨은 유령을 피하면서 먹이를 먹는 여러 대상을 고려한 알고리즘을 구현하였습니다. 이를 구현하기 위해서 minimax, Alpha-Beta Pruning, Expectimax 를 사용하였습니다.

어려웠던 점

인공지능을 공부하면서 파이썬을 처음으로 접하게 되었는데, 평소에 사용하던 언어와 다르게 스크립트 기반의 언어라서 어색했습니다. 그래도 이 프로젝트를 진행한 덕분에 파이썬을 더욱 잘 다룰 수 있게 되었습니다.

배운 점

이론적으로만 알고 있던 알고리즘들을 직접 구현해보니 상황에 따라 어떤 알고리즘을 사용해야하는 지 장단점을 직접 볼 수 있어서 도움이 많이 되었습니다. 이전에 알고리즘 과목을 수강했을 때에는 단일 대상으로부터의 검색 알고리즘 만을 배웠었지만, 이번에는 여러 대상이 있을 때에도 사용 가능한 검색 알고리즘을 익히게 되어서 더욱 다양한 환경에도 적용할 수 있게 되었습니다.

소개

• 인원 : 1인
• 담당 : 프로그램 구현 전체
• 개발 환경 : Ubuntu 16.04 LTS, VMware Workstation 14 Player
• 문제
  • 클라이언트 간의 채팅 프로그램을 기반으로 작성한다.
  • 서버는 접속하는 클라이언트가 송신한 메시지를 모두 관리하고 모니터링 한다.
  • 클라이언트가 보내는 문자를 모두 기록하고 있으며, 총 문자 수, 보낸 시간 등의 내역을 보관한다.
  • 이 외에 서버는 총 접속자 수(클라이언트의 총 접속자 수), 각 클라이언트의 접속 시간, 클라이언트의 IP를 관리한다.
  • 클라이언트는 최소 5개 이상 접속이 되도록 작성하시오.
• 소스코드 : Linux에서 Socket으로 채팅구현하기
• 사용법 : Linux에서 Socket으로 채팅구현하기

내용

컴퓨터의 수가 부족하여 부득이하게 로컬에서 다중 클라이언트를 실행하였습니다.

이 중에 가장 오른 쪽 위에 있는 터미널이 서버 역할을 하고 있습니다.
서버에서는 클라이언트가 보내는 메시지를 모두 확인할 수 있습니다.

위 터미널은 서버가 처음 실행되었을 때 나오는 화면이고, 서버는 4가지의 명령어를 사용할 수 있습니다.

• help : 도움말 출력
• num_user : 현재 접속한 유저의 수
• num_chat : 현재까지 오간 대화의 수
• ip_list : 현재 접속한 유저들의 IP

어려웠던 점

이 문제를 해결하면서 어려웠던 점은 기능 구현보다 터미널의 글씨에 색상을 입히는 작업이었습니다. 일반적인 printf로는 잘 작동하지 않았고, write나 fprintf(stderr)을 이용해서 해결하였습니다.

배운 점

이번 프로젝트는 사용자 편의성을 높이는 데에 더욱 집중하였고, 더욱 깔끔한 출력을 하기 위해서 많은 시간을 투자하였습니다. 그러다보니 평소에 습득하지 못했던 지식을 더욱 알아갈 수 있는 계기가 되었고, 실력향상에 많은 도움이 되었습니다.

소개

• 인원 : 1인
• 담당 : 프로그램 구현 전체
• 개발 환경 : Visual Studio 2015, OpenMP 2.0
• 문제
  • Input
    • Data : 0~RANGE 범위, 1,073,741,824개의 floating point number
    • 화면 입력 : 2개의 정수 값 – 예) 4 9
  • Output
    • 화면 출력 : Sorting에 걸린 시간, Search에 걸린 시간
    • 파일 출력 : 정렬한 리스트, 검색한 숫자의 개수와 리스트
• 소스코드 : OpenMP를 이용하여 멀티 스레드로 작동하는 정렬 및 검색 프로그램

내용

1. 일상에서의 접근

문제를 먼저 우리 주변에 있을 수 있는 일로 가져와서 생각해보려고 합니다. 만약 1부터 100까지 숫자가 적힌 카드가 왼쪽처럼 섞여 있을 때, 오름차순으로 정리하려면, 방법은 크게 두 가지 정도 있을 거라고 생각합니다. 하나씩 숫자를 확인하면서 정리된 카드와 비교하고 정리하는 방법과 110, 1120…으로 미리 분류하고 각각 정리하는 방법입니다. 아마도 카드의 개수가 적으면 방법1이 더 빠르겠지만 일정 개수를 넘어간다면 방법2가 더 빠를 것이라고 생각합니다.

2. 실제 문제에 적용

가장 큰 숫자의 크기만큼 배열을 만들어서 이렇게 분류하고, 각 배열을 정렬하는 방법을 생각했습니다. 이 방법을 적용하기 위해서 미리 랜덤 숫자들의 분포를 세서 0번째는 17개, 1번째는 6개….이런 식으로 동적 할당을 해야 합니다. 이렇게 하면 랜덤 수를 저장할 배열 4GB와 숫자를 정리할 배열 4GB로 총 8GB가 필요하고, 메모리 16GB정도의 컴퓨터라면 충분히 실행할 수 있습니다.

3. 병렬화 부분

각 배열을 정렬하는 부분을 병렬로 처리하였습니다. 만약 정렬을 하는 알고리즘을 병렬화 한다면 스레드 사이에 동기화가 필요해서 성능에 좋지 않은 영향을 줄 수 있지만, 이 방법은 각 배열을 정렬하기 때문에 동기화가 전혀 필요하지 않아서 각 스레드가 제 성능을 온전히 발휘할 수 있습니다.

4. 검색 알고리즘
정렬할 때 정수 인덱스를 기준으로 정렬하였고, 각 배열의 크기를 알고 있기 때문에 정수 범위로 검색된 데이터는 단순하게 출력만 하면 됩니다. 따라서 바로 출력만 하면 되기 때문에 시간 복잡도는 O(1)입니다.

5. 결과 분석 (Intel i7-6700K @ 4.00GHz & 16GB RAM 기준)

시리얼 시간을 병렬 시간으로 나누어서 계산한 차트입니다.
스레드가 2개일 때는 약 1.8배, 4개일 때는 2.99배, 8개일 때는 4.09배 정도 성능이 향상되었습니다. 아무래도 물리적인 코어 수는 4개라서 스레드를 8개를 사용하면 효율이 떨어지게 되는 것 같습니다. 그리고 4개를 사용할 때에는 이 프로그램 뿐 만 아니라 다른 백그라운드 프로그램도 프로세서를 사용해야 하기 때문에 2개를 사용했을 때 보다 효율이 떨어질 수밖에 없습니다.

어려웠던 점

처음 구현할 때는 벡터나 리스트를 이용해서 구현하려고 했지만 숫자가 너무 많아서 컴퓨터의 메모리 용량을 초과하는 문제가 발생했습니다. 이에 따라 최적화를 진행하게 되었고, 한 번 파일을 모두 읽은 뒤에 동적할당을 함으로써 이 문제를 해결하였습니다.

배운 점

4학년이 되기 전까지 모든 프로젝트는 싱글코어를 활용한 프로그램들이었지만, 이번에 OpenMP를 배우게 되어 처음으로 멀티코어를 활용한 프로그램을 만들게 되었습니다. 정렬은 정렬할 개수가 많을 수록 오랜 시간이 소요되는 작업인데, 멀티코어를 활용하여 프로그램을 제작하니 빠른 속도로 결과를 얻을 수 있었습니다. 또한, 항상 빠른 정렬 알고리즘을 사용한다고 해서 병렬 처리를 할 때 더 좋은 결과를 얻는 것은 아니라는 사실도 깨달았습니다.

소개

• 인원 : 1인
• 담당 : 프로그램 구현 전체
• 개발 환경 : PHP 5.2.12, MySQL, bootstrap
• 소스코드 : PHP기반 반응형 피아노 동아리 홈페이지 제작

내용

주요기능

어려웠던 점

게시판을 DB와 연동해서 구현하는 것이 가장 어려웠습니다. HTML이나 CSS 같은 프론트엔드 부분을 위주로 다뤄본 탓에 백엔드 부분에는 서툰 면이 있었습니다. 그래서 인터넷을 참고해가면서 페이지 넘김이나 검색 부분을 구현했습니다.

배운 점

실제로 피아노 동아리 활동을 하고 있는데, 이 홈페이지를 만들면서 다른 동아리원들의 의견도 반영하였습니다. 동아리 일정 기록을 위한 달력 제작도 부탁받았지만, 아직 실력이 부족해서 구현할 수 없었습니다. 이처럼 실제 사용자의 의견을 들으면서 홈페이지를 만들어 가다보니 더욱 완성도 높은 홈페이지가 제작되었습니다.

소개

• 인원 : 4인
• 담당 : 팀장 및 프로그램 구현
• 팀원 : 팀원1 - 미로 작성, 팀원2 - 보고서 작성, 팀원3 - PPT작성
• 개발 환경 : Visual Studio 2015
• 문제
  • 미로는 .txt파일로 입력된다.
  • 미로의 모양은 사각형이긴 하지만 크기는 임의의 으로 미리 그 크기를 알 순 없고, 미로 내에 있는 1개의 출구의 위치 또한 미리 알 수 없다. 단, 미로의 입구는 (0, 1)이다
  • 미로에서 출구를 찾는 쥐는 최초에 의 에너지와 0의 마나를 지닌다.
  • 쥐는 미로의 상하좌우만 움직일 수 있고, 사선으로 움직일 수 없다.
  • 쥐는 미로를 한 칸 움직일 때마다 에너지를 1 소모하게 되며, 마나를 1 획득하게 된다.
  • 쥐는 10의 마나를 소모해서 임의의 만큼 미로를 스캔할 수 있고, 30의 마나를 소모해서 벽 한 칸을 뚫을 수 있다. 단, 외벽은 파괴할 수 없다.
• 소스코드 : 특수한 스킬을 가진 쥐로 미로의 출구 찾기

내용

알고리즘 설계

• 탐욕적 알고리즘을 적용한다.
  (현재 위치로부터 가상의 목적지까지 가장 거리가 짧은 방향으로 이동한다.)
• 쥐는 지금까지의 이동경로를 모두 기억하고 있다.
• 쥐가 스캔을 통해 목적지를 찾았을 경우, 목적지 주변 일정한 부분을 스캔으로 탐색합니다.
• 쥐는 막다른 길에 도달했거나 스캔을 통해 목적지를 찾았을 경우, 자신이 기억하고 있는 경로를 통해 목적지로 향하는 최단(최적)경로를 찾아간다.
• 목적지를 스캔을 통해 찾았을 경우, 그 주변으로 스캔 범위를 넓혀간다.
• 현재 쥐의 위치부터 목적지까지의 경로 중, 스캔을 통해 찾아낸 경로나 쥐가 이동을 통해 찾아낸 가장 짧은 경로로 이동한다.
• 마나가 30이상이며 스캔을 통해 출구를 찾았으며, 최적의 경로로 출구를 향해 이동중일 때 벽을 만났는데 마나가 4 이상인 경우, 진행방향으로 스캔을 뿌려보고 벽이 1칸 있으면 그 벽을 뚫고 지나간다.
  

어려웠던 점

일반적인 미로찾기가 아니라 마나와 스킬을 가진 미로찾기여서 어떻게 알고리즘을 구현하는 것이 효율적일지 생각하는 것이 가장 어려웠습니다. 그래서 평균적으로 확률을 높이는 것이 가장 좋은 방법이라고 생각해서 위와 같은 알고리즘으로 구현하게 되었습니다.

배운 점

평소에는 콘솔 기반의 프로그램을 위주로 만들었지만, 이번에는 GUI를 이용해서 프로그램을 만들었습니다. 그렇다보니 그림의 배치나 색 등 여러가지 고려할 부분이 늘어나서 처음에는 생각보다 잘 안되었지만, 이런 부분을 해결해나가는 과정에서 자료 검색 능력이나 문제를 해결하는 센스가 더욱 늘어났습니다.

소개

• 인원 : 1인
• 담당 : 프로그램 구현 전체
• 개발 환경 : Visual Studio 2015
• 문제
  
  • 테이블에 5명의 철학자가 있고, 그 사이에 포크가 1개씩 있다.
  • 자신에게 가장 가까이 있는 두 개의 포크만 사용할 수 있다.
  • 식사를 하기 위해서는 무조건 두 개의 포크가 필요하고, 한 개의 포크로는 식사를 할 수 없다.
  • 이미 다른 사람이 포크를 쥐고 있다면 그 포크를 테이블에 내려놓기 전까지 가져갈 수 없다.
  • 철학자는 식사, 생각, 대기라는 세 가지 상태만 존재한다.
    (대기 = 배고픈 상태이나 포크가 부족해서 기다림)
  • 철학자는 서로 대화할 수 없으며 포크를 들고 내려놓는 행동을 보는 것으로 상태를 확인해야 한다.
  • 위와 같은 조건에서 아무도 굶어죽지 않도록 하는 방법을 생각하자.
• 소스코드 : 식사하는 철학자들-Semaphore를 이용한 모니터와 비대칭 해결안을 적용

내용

비대칭 해결안

• 기본 원리

  • 홀수 번호의 철학자는 먼저 왼쪽 포크를 집고, 다음에 오른쪽 포크를 집는다.
  • 짝수 번호의 철학자는 먼저 오른쪽 포크를 집고, 다음에 왼쪽 포크를 집는다.

• pseudocode

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

  main() { while (TRUE) { /* Hungry Area */ if (P % 2) { // 짝수 번호의 철학자이면 왼쪽 포크부터 wait(Left_Fork); wait(Right_Fork); } else { wait(Right_Fork); wait(Left_Fork); } /* Eat Area */ signal(Left_Fork); signal(Right_Fork); /* Think Area */ } }

• 해결 원리
  이 방법대로 철학자들이 포크를 집는다면 모든 철학자들이 한 포크만을 집는 사태는 벌어지지 않습니다. 양 옆의 철학자가 서로 같은 포크를 집으려하기 때문에 그 포크를 먼저 집는 사람이 다음 에 식사를 하게 됩니다.

• 실행화면
  

어려웠던 점

가장 어려웠던 점은 windows의 환경에 맞게 프로젝트를 설정하는 일이었습니다. 인터넷 검색을 통해서 pthread와 semaphore의 사용법을 검색해보았지만 Linux의 gcc 환경에서 사용하라는 글이 대부분이었습니다. 그래서 열심히 찾아본 결과 semaphore는 windows.h에 포함된 함수로 사용이 가능해서 매크로를 이용해 함수이름을 변환하였습니다. 하지만 pthread는 방법을 찾지 못해서 어떤 사람이 Windows에 사용 가능하도록 만들어둔 pthread.h를 직접 추가하고, 이에 필요한 lib 파일과 dll 파일을 프로젝트 경로에 추가하였습니다.

배운 점

식사하는 철학자들 문제에 대한 여러 가지 해결책을 생각해보았습니다. 모두가 일정한 간격으로 식사하고 생각한다면 타이머를 이용해서 간단하게 해결이 가능하지만, 꼭 그렇지는 않다는 것이 이 문제의 중점이라 생각했습니다. 그래서 가장 보편적인 해결안인 비대칭 해결안을 사용하게 되었고, lock과 unlock을 위해서는 semaphore를 사용하였습니다. 프로그래머가 semaphore를 사용할 때 오류가 발생하지 않도록 주의하며 프로그래밍을 해야 하는 단점이 있지만, 여기서는 추상화된 데이터 형인 모니터를 이용했기 때문에 안전하게 프로그래밍을 할 수 있었습니다. 또한 미리 정의된 함수들을 이용한 덕에 소스코드도 짧게 작성할 수 있었습니다.

소개

• 인원 : 1인
• 담당 : 프로그램 구현 전체
• 개발 환경 : Unity
• 마켓 링크 : 슈팅게임 A

내용

유니티 공부하면서 간단하게 만들어본 슈팅게임입니다.

• 3000점 마다 “현재 스코어/1000”의 체력을 가진 보스 생성
• 6000점 마다 발사 속도가 증가하는 파워업 아이템 생성
• 10000점 마다 목숨을 1만큼 올려주는 하트 아이템 생성
• 12000점 마다 스테이지 1 증가, 적군의 체력이 1만큼 상승
• 60000점이 되면 게임 클리어

어려웠던 점

게임을 하면서 불편했던 점은 많았지만, 그것들을 직접 구현하려고 하다 보니, 기능 하나를 추가하는데 하루가 지나기도 했습니다. 게다가 프로그래밍만 하면 될 것 같았지만, 그림 편집도 필요했고, 음악 제작도 필요해서 직접 공부하느라 힘들었습니다. 가장 어려웠던 것은 적이 총알을 발사할 때 플레이어를 향하도록 하는 것이었는데, 적 유닛 하나하나에 방향을 지정하는 방법을 결국 알아내지 못했습니다. 그래서 어쩔 수 없이 모든 적이 무작위의 각도로 한 방향으로만 총알을 쏘고 있습니다.

배운 점

이렇게 힘든 과정 끝에 게임을 완성하고 나니 저만의 것이 하나 탄생한 것 같았습니다. 정말로 Unity를 이용해 게임을 완성하는데 2주도 안 걸렸고, 주위 친구들도 게임을 직접 플레이하며 즐거워하는 모습을 보니 성취감도 느껴졌습니다. 그 당시에 게임 개발을 위해 노력했던 것은 지금의 실력이 있는 저로 성장한 좋은 계기가 되었습니다.

소개

• 인원 : 1인
• 담당 : 프로그램 구현 전체
• 개발 환경 : JDK 8
• 소스코드 : Java로 만든 채팅 프로그램 - IntraMessenger

내용

부대에서 사용하기 위해 개발했던 것으로 지금은 DB가 없어서 작동하지 않으며, 스크린샷도 존재하지 않습니다.

작동 방식

• 로그인 기능 구현 : ID와 PW를 DB에서 동시에 검색하여 나온 필드가 존재한다면 로그인이 됩니다.
• 실시간 채팅 구현 : 채팅창이 활성화 되어있는 동안에는 스레드를 생성하여 새로 도착한 메시지가 있는지 계속 확인합니다.

단점 및 취약점

• DB를 제외하고 별도의 서버가 존재하지 않아서 DB접속을 위한 ID와 PW가 클라이언트에 노출되어 있음
• 실시간 채팅을 위해서 DB에 로그인하고 쿼리를 보내 계속 확인 작업을 해야하므로 DB에 큰 무리가 있음

어려웠던 점

개발 당시에 Java를 처음 공부했던 시절이라 코드를 비효율적으로 작성해서 유지보수가 어려웠습니다. DB와 Java를 연동해보는 일도 처음이어서 개발하는 컴퓨터로는 프로그램이 작동하는데, 사용자의 컴퓨터로는 Oracle 드라이버가 로딩되지 않아서 프로그램이 작동하지 않는 오류도 있었습니다. 사소한 부분에 오류가 있었고, 부대에서는 정보검색에 한계가 있어서 이 부분을 해결하는 일이 어려웠습니다.

배운 점

일과시간에 항상 이 프로그램을 만들 수는 없기 때문에 저녁에 손으로 코드를 작성하고, 일과시간에는 전날 저녁에 작성한 코드를 입력하는 방식으로 프로그램을 천천히 완성하였습니다. 손으로 코드를 작성하는 일을 많이 하다보니 눈으로 디버깅하는 능력이 좋아져서 컴퓨터로 옮기더라도 오류가 거의 나지 않고 잘 작동하였습니다. 그래서 평소에 소스코드를 눈으로 보더라도 어디가 잘못된 곳인지 찾아내는 능력이 많이 향상되었습니다.