PPAK

개요 지난 프로젝트를 진행하면서 테스트 코드를 작성하는 방법에 대해서 스스로 만족할 만큼 학습하지 못했다. 일종의 변명이지만 아직 테스팅하는 것에 익숙하지 않아 주어진 기간 내에 요구사항을 구현하면서도 체계적인 테스트 코드 작성을 병행하기에 시간적 여유가 부족했다고 생각한다. 개발을 하면서도 수시로 테스트 코드 작성에 대한 필요성을 느꼈다. 특히 테스팅에 대해서 아예 무지할 때는 구현된 기능의 사소한 변경사항(요청값의 변화, 로직 일부 수정 등등) 이 있을 때마다 애플리케이션을 실행하고 Swagger 나 Postman 을 통해서 요청을 전송하고 결과를 확인하는 과정은 굉장히 불편했다. 왜 그 과정이 불편한가에 대해 생각해봤다 애플리케이션 실행을 위한 모든 설정을 셋팅해야한다 서버가 외부 API(MySql..

두달 전부터 학부 학생회 중 하나인 개발부(구 시스템 도서 위원회) 에 속해 학부생들이 교내에서 겪는 문제를 찾고 해결하는 일에 참여하고 있다. 원래는 교내 실습실을 관리하는 업무를 주로 했지만, 방향을 조금 바꿔서 뜻이 맞는 학우들과 함께 부서를 발전시켜나가기로 했다. 해당 부서에서 내가 첫 번째로 한 일은 학부생들이 겪고 있는 문제를 조사하는 것이였다. 그러던 중 사실 고질적인 문제로 볼 수 있는 공지사항 열람의 불편함은 올해에도 어김없이 문제점으로 제기된다는 것을 확인했다. 문제 상황은 다음과 같다. 다른 학과의 상황은 잘 모르지만 컴퓨터학부 공지사항에는 학생들에게 도움이 되는 공지사항(공모전, 특강, 마일리지 관련) 꾸준히 올라오고 있다. 특정 장학금이나 특강에 관한 공지사항은 선착순 마감이 존재..

기존에 진행하던 프로젝트에서 Redis 를 사용해 캐싱과 이벤트를 공유하는 로직을 추가했다. 캐싱의 경우, 우선 시스템 내에서 자주 조회 되면서 시스템 내에 존재하는 데이터 간 연관 관계가 복잡하지 않은 (혹은 수정 가능성이 낮은) 데이터를 중심으로 수행했다. 따라서 인증 정보와 좋아요 기능을 위한 캐싱을 수행하기로 했고 아래 두 가지의 요구사항에 따라서 로직을 구성했다. 1. 인증 정보의 교환에서 세션 정보를 서버에 저장하지 않고 JWT 를 통해 인증/인가 진행. 잦은 Access Token 발급을 방지하기 위해 Refresh-Access 토큰 쌍을 일정 시간 동안 캐싱할 때 Redis 를 사용했다. 덕분에 여러 대의 서버에서 동일한 Redis 의 캐싱 정보를 사용할 수 있었고, 시스템 자원의 낭비를 ..

프로젝트 자료 GitHub Youtube 포스팅할 주제들은 산더미인데 프로젝트를 진행하며 전공 학습을 병행하느라 정돈된 글을 작성할 시간이 많이 부족한 것 같아서 아쉽습니다. 그래도 프로젝트 리뷰는 하루라도 빨리 써야 느낀 생각을 잘 남길 수 있을 것 같아서 조금 무리해서 작성합니다. 교내에서 학부 행사 겸 대회를 주최했습니다. 전공에 크게 관심이 없던 학생들도 교내 행사를 통해서 흥미를 붙이는 모습을 보아서 그런지 저는 정말 긍정적인 영향을 주는 행사라고 생각합니다. 주제는 주어진 대구 시 문제를 소프트웨어를 통해서 해결할 수 있는 방법을 모색하는 것입니다. 단 주제가 대회 마감 5일 전에 공개됩니다. 다시 말해 5일 간 기획부터 시연 제품 개발까지 완료해야하는 일종의 해커톤이라고 볼 수 있습니다. 멤..

아직 대회와 프로젝트 개발이 끝난 것은 아니지만 MVP 레벨의 기능 개발도 어느 정도 마무리가 된 것 같아서 최근 약 두 달간 어떻게 개발을 진행해 왔는지 살펴보고 쉬어가며 소감도 한번 작성해보고자 합니다 !! 프로젝트 시작 전 복학 후 두 학기를 정말 학교 생활에 집중했던 것 같습니다. 열심히 하고자 다짐한 것도 있지만 예상보다 CS 공부나 코딩이 조금 더 저에게 잘 맞았고 덕분에 두 학기 모두 좋은 성적으로 마무리할 수 있었던 것 같습니다. 무슨 자신감이었는지는 모르지만 3학년 1학기에는 회사 이곳저곳에 포트폴리오를 작성하여 내보기도 하고 코딩 테스트를 응시하기도 했습니다. 크게 기대는 안했지만 역시나 모두 광탈을 했고 그 과정에서 제가 무엇이 부족한지에 대해 성찰을 했던 것 같습니다. 어떤 개발자가..

프로젝트를 기획하면서 가장 무모(?) 하게 도전한 챌린지 중에 하나가 WebSocket 사용이였던 것 같습니다. 사실 WebSocket 이라는 것도 찾아보고 안 것이지 기획 단계에서는 그저 "비동기적으로 서버 측에서 브라우저로 메세지를 날리는 것" 정도로 이야기하고 넘어갔던 것이 기억납니다. 그 때 당시에는 브라우저와 파이프라인을 만드는 써드파티 라이브러리가 있지 않을까? 혹은 아무 방도가 없어라도 서버로 비동기적으로 호출을 날려놓고 이벤트가 발생하면 응답해주는 방식으로 구현하면 되지 않을까? 라며 어떻게든 해답이 있을거라 판단하였습니다. MVP 가장 마지막 개발 기능으로 추가해 놓은 "서버에서 역으로 메세징 하기" 는 자료조사 끝에 WebSocket 이라는 통신 프로토콜을 이용해 구현이 가능하다는 것..

프로젝트에서 본격적으로 Redis 를 사용하기 위해서는 로컬에서 실행중인 Spring Container 와 Redis Container 간의 연결이 필요했습니다. 일반적으로 OS 위에서 실행하는 JVM 과 Redis 는 host network 를 사용하여 손쉽게 연결할 수 있지만 Docker 는 컨테이너 간 네트워크 역시 격리시켜놓았기 때문에 같은 네트워크를 사용하고자 한다면 컨테이너를 잇는 네트워크 브릿지를 생성하고 이어주어야 합니다. $ docker network ls 위 명령어를 통해 docker 에서 기본적으로 생성해놓은 네트워크를 확인해보면 host 와 bridge 가 존재하는 것을 확인할 수 있습니다. $ docker network inspect bridge 별도의 연결 네트워크를 명시하지않은..

본 포스팅에서는 최근에 진행중인 프로젝트의 서버 설계, 구현 과정을 살펴보려고 합니다. 우선 api 서버를 구축하기 위해서 1. 인증/인가 2. JWT 사용(Authorization Header) 3. CORS 허용 등의 요구사항이 있었고 이를 적용하고 있는 방식을 설명하고자 합니다. 위 사진은 일반적인 Spring 서버의 요청 처리 구조를 나타내는 그림입니다. 저는 현재 기본 Spring Boot Application 에 1. Filter(Spring Security) 를 통해 인증/인가 2. Interceptor 를 통해 인가된 요청 헤더값 추출 3. Controller 에서 JWT 생성 및 발급을 수행하고 있습니다. Client 의 요청이 Filter -> Interceptor -> Controll..

의미있는 단위로 브랜치를 생성, 관리하고, 가독성이 좋은 형태의 브랜치의 구조를 만들기 위해서 브랜치 관리 전략 중 Git-flow 에 대해서 알아보고, 프로젝트에 적용할 수 있는 방식을 고민해보았다. Git-flow 에서 제시하는 branch 생성 방식은 아래와 같다. master : 실제 배포 버전이 있는 브랜치, 실 서비스에 사용되는 제품을 의미한다. hotfix : 배포 버전에서 발생하는 버그 중 긴급하게 수정이 이루어지는 브랜치 develop : 버전 업그레이드를 위해 기능 추가, 수정 사항이 반영되는 등의 개발이 이루어지는 브랜치 feature : 개발 단계 별 추가, 수정되는 기능 개발이 이루어지는 브랜치 release : 다음 배포 버전에 포함될 기능 개발이 끝난 후 QA 가 이루어지는 브..