개발 블로그 개발 블로그

7월 19일 - 20일동안 무박 2일로 넷제로 해커톤을 진행했다. 해커톤에는 2가지의 문제가 주어졌는데, 우리 팀은 문제 B : 저전력/고효율을 위한 스마트홈 어플리케이션 개발을 선택했다. 사실 주제를 정할 때 스마트홈 어플리케이션이 너무 잘 되어있어서 고민이 많았는데, 그럼에도 불구하고 사람들이 스마트홈을 많이 사용하지 않는다는 생각이 들었기에 단점을 찾아 보완하는 방식으로 진행했다. 우리팀의 주제는 슬랙 채팅 봇을 이용해서 집 안의 전기기기들을 제어할 수 있는 스마트홈 개발을 주제로 했다.  여기서 많은 사람들이 의아해 하는 부분이 있을텐데, 기존의 스마트홈이 많은데 왜 굳이 스마트홈 개발을 추가로 진행하냐는 것이라고 생각된다.   PPT 발표 자료에 있는 사진들로 설명을 해보자면, 기존의 스마트홈 ..

이번 프로젝트에서 ai 기능을 활용해서 사용자에게 회의 관련 자동화 업무 서비스를 제공한다. 사용한 ai는 총 3개이다.  3가지의 ai 모델회의 내용 요약(Text summarization)텍스트 감정 분석(Text Sentiment Analysis)영상 감정 분석(Face Expression Recognition) 백엔드 개발자로서 백엔드 관련 개발을 진행했지만, ai 모델도 3개나 적용하기에 각자 1개씩 맡아서 주도적으로 진행했다. ai 개발자인 팀원의 도움을 받아서 1번의 회의 내용 요약 ai를 집중적으로 개발했다.그렇다고 다른 ai에 대해서 모르는 것도 아니고, 주도적으로 요약 ai 모델링을 한 것이기에 3가지 모델에 대해서 정리해보려고 한다. AutoMeet은 3가지 ai 모델을 그대로 사용한..

이번 프로젝트에서 회의 요약 보고서에 댓글을 작성할 수 있는 요구사항이 있다. 처음에는 Meet collection와 Comment collection를 분리한 뒤에 comment를 저장할 때 meetId를 컬럼에 저장하는 방식으로 사용했었다. -> 생각해보니 NoSQL을 사용하며 RDBMS처럼 사용하고 있는 것이었다. mongo db의 장점은 유연한 스키마인데, mongo db의 장점을 잘 활용하지 못하고 이전에 해왔던 익숙한 방식 그대로 사용했던 것이다.  Mongo DB의 데이터 저장 방식1. reference 관계2. embedded 관계  1. reference 관계- RDBMS처럼, 위에서 내가 했다고 언급했던 것처럼 하는 것이다. 문서 간의 관계 ID를 통해 참조하는 방식이다.장점 : 데이터..

이번에 진행한 프로젝트에서는 ai 개발자가 개발한 ai 로직을 수행하기 위해 화상 회의을 구현해야 했다. 화상회의는 webRTC라는 기술이 화상채팅을 지원한다고 한다. webRTC는 Real-Time-Communications의 약자로 웹에서 별도의 소프트웨어 없이 음성, 영상 등의 데이터를 브라우저끼리 주고 받는 기술이라고 한다. webRTC의 Kurento 기반의 중개 서버를 애플리케이션에 쉽게 추가할 수 있는 플랫폼을 Openvidu라고 부르며, Openvidu를 사용하면 화상 채팅 서버를 쉽게 구현할 수 있다.  위의 사진에서 Application server를 내가 구현한다. Application client는 프론트엔드 개발자가 개발할 것이며, OpenVidu deployment는 OpenVi..

지금까지 프로젝트를 할 때에는 db로 RDBMS인 mysql을 사용했다. (추가로 redis로 jwt token 받는 정도??) 그 이유는 가장 보편적이고 간편하며 널리 사용되기 때문이다. 이번 프로젝트에서 회의를 진행하고 끝날 때 회의 데이터를 저장해야하는 요구사항이 생겼다. 제목, 회의 요약 내용 등을 비롯해서 데이터를 저장하는데 RDBMS에 저장하는 것보다 Nosql에 저장하는 게 좋을 것 같다는 생각이 들었지만, 확신은 없었다. 하지만 ERD를 설계하던 도중, 회의 참여자 수가 고정되지 않는다는 문제점이 생겼다. 회의에 2명이 참가할수도, 4명이 참가할 수도 있는데 회의 table에 참여 인원을 고정시킨 member1 ~ member4 중에서 필요없는 컬럼을 null로 설정하는 것은 효율적이지 않..

2024-1 정보통신종합설계에서 화상채팅 관련 프로젝트를 진행하기 때문에 실시간 채팅을 구현해야 했다. 스프링에서는 웹 소켓이라는 프로토콜과 STOMP(Simple Text Oriented Messaging Protocol)을 이용해서 실시간 양방향 통신이 이루어진다. 웹 소켓 외에도 HTTP의 폴링과 SSE 방식이 있지만 가장 보편적이며 좋은 것이 웹 소켓이라고 한다. WebSocketConfigurer @Configuration @EnableWebSocketMessageBroker public class WebSocketConfigurer implements WebSocketMessageBrokerConfigurer { @Override public void configureMessageBroker(..

리스트를 조회할 때 fetch join을 사용했다 하더라도 시간이 많이 소요된다. 저번 포스팅에서 데이터를 임의로 30만개를 생성했다고 했는데, 30만개를 실제로 한 번에 get할 일은 거의 없다. 때문에 페이징을 진행하여 원하는 갯수만큼의 데이터를 가져오게 되는데 페이징을 할 때 계속 시간이 오래 걸리는 문제가 생겼다. @Override public Page findAllSuggestion(Category category, Boolean likeCount, Pageable pageable) { JPAQuery query = queryFactory .selectFrom(suggestion) .leftJoin(suggestion.user, user).fetchJoin() // fetch join 제거 .l..

기능 개발을 할 때에는 쿼리에 대해 고려하지 않고 일단 개발을 진행했다. 개발을 완료하고 테스트를 하는 과정에서 쿼리를 호출할 때 N+1 문제가 발생하는 것을 확인했다. SuggestionController @GetMapping("/list") public ResponseEntity suggestionList( @AuthenticationPrincipal PrincipalDetails principal, @RequestParam(name = "category", required = false, value = "category") String category, @RequestParam(name = "likeCount", required = false) Boolean likeCount) { List allS..