글을 작성한 이유 2024년이 되면서 취준 생활을 청산하게 됐다. 그래서 취준 생활 청산 기념으로 어떻게 취준 생활을 했는지 회고하기 위해 글을 작성해보려 한다. 내가 어떻게 개발 공부를 했는지, 취준은 어떻게 했는지 한번 정리해보려고 한다. 진로 선택 재학하던 과는 산업공학과로 2학년 때 C 프로그래밍을 한번 배운다. 그때 당시에는 컴퓨터와 거리가 멀었던 나는 “이거 공부 왜 해야 해?”라며 바로 C 학점을 받았다. 프로그래밍 수업이 있었기에 학과에서는 컴퓨터실을 운영하였고, 이 컴퓨터실을 관리하는 서버실이라는 곳이 존재했다. 서버실에서는 선배들이 더블 모니터를 사용하여 알고리즘 및 개발 공부를 하고 있었다. 그 모습을 보고 멋있다라는 생각이 들었던 나는 컴퓨터 공부를 한번 해볼까 라는 생각이 들었다...

토스 SLASH 23 중 ‘실시간 시세 데이터 안전하고 빠르게 처리하기’ 발표를 보고 정리한 내용입니다. 발표에서 사용되는 키워드를 중심으로 학습을 진행했습니다. 또한, 제 생각을 적어놓은 것들이 많아 틀린 부분에 대해서 말씀해 주시면 감사하겠습니다. 시세 플랫폼이 하는 일 시세 플랫폼은 거래소 데이터를 제일 먼저 수신하고 가공한 뒤, 내부 서비스들에게 제공한다. 거래소에 있는 데이터 전문을 디코딩하고 전달하며, 주식차트처럼 과거 데이터를 누적하거나 여러 정보를 합성하여 제공하기도 한다. 내부 서비스들은 이 가공된 데이터 중 각자 필요한 정보를 실시간 혹은 API를 통해 얻게 되고, 최종적으로 토스 앱에도 보이는 것이다. 시세 플랫폼의 최우선 목표는 낮은 지연시간과 빠른 장애복구이다. 시세 플랫폼 파트 ..

레벨 3, 4 회고를 작성하기에는 너무 늦은 감이 있다. 하지만 이 기록을 하지 않는다면 너무 아쉬운 기억일 것 같아서, 기억을 끄집어내어 작성해 본다. 주제 바꾸기 우리는 처음에 ‘얼마면 살래’라는 팀으로 가격 추정을 알려주는 프로젝트를 진행하게 됐다. 하지만 여러 가지 이유로 인해 얼마면 살래를 하지 못하고 다른 주제로 옮겨야 했다. 그 과정이 정말 다사다난했고, 팀 분위기도 좋지 않았다. 회의를 하면 주제를 꺼내고, 그 주제가 타당한지 오랜 시간 회의를 통해 나를 포함한 팀원들은 모두 지쳐만 갔던 상태였다. 그 과정에서 주제를 정하며 2차 데모데이를 진행하게 됐다. 의기소침 2차 데모데이에서 우리 팀원들은 의기소침해 있었다. 다른 팀들은 처음부터 정한 주제를 가지고, 기획을 어느 정도 정해두고, ..

토스 SLASH 23 중 ‘토스는 Gateway 이렇게 씁니다’ 발표를 보고 정리한 내용입니다. 토스에서는 gateway를 어떻게 사용하고 있고, 발표에서 사용되는 키워드를 중심으로 학습을 진행했습니다. 또한, 제 생각을 적어놓은 것들이 많아 틀린 부분에 대해서 말씀해 주시면 감사하겠습니다. Gateway란? 라우팅 및 프로토콜 변환을 담당하며 마이크로 서비스의 중개자 역할을 하는 서버로써 보안, 모니터링 등을 위한 단일 제어 지점으로 사용된다. 서버가 적을 때는 Client에서 서비스를 직접 호출하고, 인증이나 유저 정보 호출과 같은 공통 로직을 각 서비스에서 처리해도 큰 부담이 되지 않을 수 있다. 하지만 서버가 많아지면 위 방법처럼 수행하기 어렵다. 왜냐하면 공통 로직에 변경이 생기면 모든 서버에 ..

글을 쓰게 된 이유 커디에서는 현재 댓글 알림, 행사 알림이 하나의 테이블에서 관리되고 있습니다. 각 알림은 type으로 구분하고 있습니다. Event 객체도 하나의 클래스로 관리하고 타입으로 이벤트 종류를 구분하고 있습니다. public class UpdateNotificationEvent { private static final String UPDATE_NOTIFICATION_COMMENT_TYPE = "comment"; private static final String UPDATE_NOTIFICATION_EVENT_TYPE = "event"; private final Long receiverId; private final Long redirectId; private final String updat..

글을 쓰게 된 이유 레벨 3을 마무리하고 나니 커디에 약 300개의 테스트가 있었습니다. application layer에서는 @SpringBootTest를 통한 통합 테스트 presentation layer에서는 @WebMvcTest 슬라이스 테스트 JpaRepository에서는 @DataJpaTest 슬라이스 테스트를 진행했습니다. 이때 문제가 있었습니다. rest docs가 잘 만들어지는 테스트 하려면 모든 테스트를 실행해야 하고, service에서 기능을 하나 만들고, 해당 기능뿐만 아니라 전체 테스트를 실행할 때 rest docs 테스트까지 실행해야 합니다. 왜냐하면 service에서는 해당 테스트가 다른 테스트에 영향을 주는지 확인해야 하기 때문입니다. 테스트 자체가 내가 작성한 기능의 동작여..

글을 쓰게 된 이유 이 글은 (1) 편과 이어집니다. (1) 편은 예제를 통해서 적용해 보았고, (2) 편은 이제 실제 커디 프로젝트에 적용해보려고 합니다. 이 글은 이제 팀원들을 이해시키기 위해서 작성해보려고 합니다. 그래서 (1) 편과 중복된 얘기가 있을 수 있습니다! 감안하고 봐주시면 감사하겠습니다. 기준 테스트 @Test @DisplayName("publish(Comment) : 댓글 이벤트가 성공적으로 발행되면 UpdateNotification이 성공적으로 저장될 수 있다.") void test_publish_comment() throws Exception { //given final Event event = eventRepository.save(EventFixture.인프콘_2023()); f..

아래 코드는 GitHub 에서 보실 수 있습니다. 글을 쓰게 된 이유 우아한테크코스(이하 우테코)에서 진행한 프로젝트 ‘커디’에서 알림 서비스를 개발했습니다. 해당 서비스를 개발하다보니 아래와 같은 궁금점들이 생겼습니다. 서드파티인 파이어베이스를 통해 알림을 보내게 되면 기존 로직에 비해 오래 걸릴 텐데, 동기적으로 수행한다면 사용자가 알림이 전송될 때까지 기다려야 하는 걸까? 만약에 애플리케이션 로직(알림 저장)은 성공했지만 파이어베이스 서버가 잘못되면 알림 전송이 실패될 텐데, 즉, 같은 트랜잭션 내에 묶여있으면 실패로 될 텐데 이게 맞는 걸까? 사용자 입장에서는 정확하게 알림을 저장했지만, 파이어베이스 서버가 잘못되어 알림이 사라지는 경우가 맞는 걸까? 등과 같은 다양한 생각이 들었습니다. 그래서 ..

글을 쓰게 된 이유 이번 글은 커디 팀뿐만 아니라 우아한테크코스(이하 우테코) 크루들에게 모두 도움이 되지 않는 글일까 생각합니다. 레벨 3 프로젝트를 진행하면서 기존에 JPA를 사용했던 분들, 처음 사용해 보신 분들이 있으실 겁니다. 기존에 사용했던 분들은 N+1을 알고 있지만 기능 만들기에 급해서 일단 구현 먼저 하셨을 것이고, 처음 사용해 보신 분들은 N+1 들어는 봤는데 이걸 어떻게 찾는 거지?라는 분들이 계실 거예요. 레벨 3가 끝나고 N+1을 해결해야 하는데 만든 기능들이 너무 많아서 API 호출하고 나서 로그에 찍힌 쿼리들을 하나하나 읽기 힘들더라고요,, 그래서 이 부분을 어떻게 해결할 수 있을까 생각해 보니 AOP(프록시)를 통해서 해당 API에서 쿼리의 개수를 측정할 수 있는 N+1 de..

이전 글과 이어지는 글입니다! 로그 레벨마다 따로 패널(모니터)을 보여주는 게 어떨까? 현재 레벨마다 로그들이 다른 디렉터리에 저장되어있으므로 레벨마다 다른 모니터(패널)로 보여주는 게 어떨까라는 생각이 들었습니다. 추후에 JSON 형식으로 로그를 남긴 후에 이 로그들을 ES로 전달하는 방법을 생각하고 있어서, 기존 로그들은 유지한 채로 인덱싱 하기로 결정했습니다. 이전 로그들을 legacy-log, 나중에 JSON 형식의 로그들은 new-log(예시)라는 인덱스에 저장하기로 했습니다. 그래서 아래와 같이 filebeat.yml 을 수정해 보았습니다. 42,17 모두 filebeat.inputs: - type: log enabled: true paths: - /var/app/current/logs/inf..

글을 쓰게 된 이유 https://c-king.tistory.com/entry/monitoring-local에서-filebeat-elasticsearch-grafana를-통해-모니터링-구축해보기 위 글과 이어지는 글입니다. Prolog 모니터링 시스템을 구축하기 위해 먼저 로컬에서 해보았습니다. 이 글을 썼을 때가 7월 6일이어서 방학 이전부터 학습해 왔기 때문에 아마 그전부터 계속해서 학습해 왔습니다. 브라운이 이전 기수 분께 말씀해 주셔서 운이 좋게 모니터링을 구축하면서 질문할 수 있었습니다. 그때 첫 슬랙이 5/30 이어서 그때부터 천천히 해보았던 것 같아요. 레벨 3 프로젝트를 병행하다 보니 저녁 시간에 틈틈이 작업하는 거라 시간이 많이 걸렸던 것 같네요,, 그리고 제 실력 이슈도 있습니다. 지금..

글을 쓰게 된 이유 우아한테크코스(우테코) 커디 팀에서 배포자동화를 구성하면서 고민이 하나 생겼습니다. GitHub Actions를 사용하면서 runner 가 설치되어 있는 서버에 jar 파일을 전달하기 위해 artifact를 사용했습니다. 하지만 artifact를 사용하게 되면 해당 레포에 접근 권한이 있는 사람들, 더 나아가 organization에 포함되어 있으면 organization 사람들 모두 jar 파일을 다운로드할 수 있게 됩니다. 이게 위험한 이유는 jar 파일을 unzip 하여 내부 파일을 볼 수 있기 때문입니다. 결국 해결해야하는 점은 artifact를 사용하지 않고 jar 파일을 서버에 옮겨야 하고, 서버마다 필요한 설정 파일(yml 및 key)들을 감춰야 합니다. 현재는 yml 파..