Search

최신순으로 보기

최신순
Search
전체 포스팅

Ruby on Rails 가이드로 시작하기

공식 문서가 제공하는 가이드를 이용해 Ruby on Rails를 시작해보자.

1. 설치

1-1. Ruby 설치

Rails에는 Ruby 버전 3.2.0 이상이 필요하다. 아래 공식 문서에 바탕해 설치했다. homebrew를 사용 중이라서 brew install ruby 명령어 한 줄로 간단하게 설치 가능했다. stable version인 3.3.6으로 설치했다.
Ruby on Rails 가이드로 시작하기
2024/12/17
ETC

입출력

•
출력하기: print 3 → 3
•
개행과 함께 출력하기: puts 3 → 3\n
•
포맷해서 출력하기

배열

•
선언하기: ticket = [14,37,18]
•
정렬하기: ticket.sort!
•
인덱스 기반 접근하기: ticket[0]
Ruby 언어 문법 정리
2024/11/19
ETC

시작하며

총대마켓 팀은 READ/WIRTE DB를 분리하며 Replication을 적용했다. Replication은 Amazon RDS 가 제공하는 기본 복제 기능을 사용해 구성했다. 관련한 AWS Docs 를 보면 복제 지연(Replication Lag)이 언급된다. 소스 인스턴스와 다른 AWS 리전에 읽기 전용 복제본을 생성할 때는 지연 시간이 증가할 수 있단 점을 감안해야 한다고 명시되어 있다.
총대마켓 팀은 소스 인스턴스와 다른 리전에 복제본을 생성했기에 지연 시간 증가를 분명 고려해야 한다. AWS Docs엔 지역 데이터 센터 간 네트워크 채널이 긴 경우 지연 시간이 발생한다고 나와있는데, 이 부분은 사용자인 내가 제어할 순 없기에 복제 지연을 어떻게 시뮬레이션해볼 수 있을지 고민했다. 복제 지연을 시뮬레이션 해보기 위해 MySQL에서 제공하는 복제를 직접 사용해 복제 환경을 구성하고, 의도적으로 1초의 지연 시간을 설정해보기로 했다.

Replication 이란?

Amazon RDS 읽기 전용 복제본

Replication Lag 시뮬레이션 및 해결 (I/O Thread)(MySQL 8.0)
2024/10/20
WEB/INFRA
HIGHLIGHT

문제 분석

배포자동화 과정 중 OAS 파일을 제대로 업로드하려면 build를 두 번 해야만 하는 문제가 존재했습니다. 왜 build를 두 번 이상 할 때만 OAS 파일이 제대로 업로드 되는지 원인을 알기 위해 배포 서버의 JAR 파일을 열어 보았습니다. build를 한 번만 했을 땐 JAR 파일에 OAS 파일이 누락되는 걸 확인할 수 있었습니다.
이는 OAS 파일을 만드는 task가 bootJar task에 의존하고 있어 발생한 문제였습니다. processResources task에서 static 경로에 있는 파일을 읽어두고, bootJar task는 해당 파일들만 인식합니다. OAS 파일은 processRecourses task가 실행된 이후 생성됐기 때문에 JAR 파일에 누락되었습니다.

해결 과정 1

이를 해결하기 위해 먼저 단순하게 task의 순서를 조정해봤습니다. OAS 파일 관련한 task를 processResources task 보다 먼저 실행하면 해결되지 않을까 싶었는데, task들끼리 순환 참조하는 문제가 발생했습니다. 원래는 processResources -> test -> createOAS -> bootJar 순서로 의존했는데, processResources -> test -> createOAS -> processResources 의 순환 의존 관계가 형성되어 문제가 되었습니다.
JAR 파일에 OAS 파일이 누락되는 문제 어떻게 해결할까?
2024/09/20
JAVA/KOTLIN
지난 글에서 클린 아키텍처에 대한 오해를 풀어보았다. 이번 글에선 클린 아키텍처를 실제로 어떻게 적용할 수 있을지 구체적인 활용 방안을 공유하려 한다.

Uncle Bob 이 말하고자 하는 바

Uncle Bob의 클린 아키텍처에는 우리가 흔히 중요하다고 여기는 SRP, OCP, DIP 같은 설계 원칙들이 기저에 깔려 있다. 특히, 그는 그의 저서들에서 단일 책임 원칙(SRP)의 의미를 강조하며, 이 원칙이 단순히 “하나의 일만 해야 한다”는 것과는 다르다고 말한다. SRP는 “하나의 모듈이 변경되는 이유는 단 하나여야 한다” 또는 “하나의 모듈은 하나의 액터에 대해서만 책임을 져야 한다”라는 뜻이라고 강조한다.
그렇다면 그가 말하는 “하나의 모듈이 변경되는 이유가 하나뿐”이어야 한다는 것은 어떻게 가능할까? 바로 의존성 규칙이 이를 가능하게 한다. 이 규칙은 클린 아키텍처가 동작하는 데 가장 중요한 규칙 중 하나로, "소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다"는 것이다. 이렇게 하면 외부의 세부 구현이나 기술적 변경이 안쪽의 중요한 비즈니스 로직에 영향을 미치지 않으며, 안쪽 모듈의 변경 이유는 오직 해당 모듈 내의 비즈니스 규칙이나 정책 변화에 국한될 수 있다.
클린 아키텍처에서 코드 품질 향상의 근거 찾기 (with 레거시 리팩토링)
2024/09/19
DESIGN
HIGHLIGHT
내 생각이자 이 글에서 말하고 싶은 바를 한 줄로 요약하자면, “클린 아키텍처는 따라야 할 스타일이 아니라, 지향해야 할 규칙이다”라는 점이다. 관련해 하고 싶은 말이 많았어서 글이 조금 길긴 한데, 핵심만 보고 싶은 이들은 중간에 ‘덕질을 하다 답답해진 포인트’부터 읽어도 무방하다.
요즘 내 최대 관심사는 클린 아키텍처다. 오늘만해도 집에 와서 읽은 클린 아키텍처 관련한 책이 너무 설레는 배움을 줘버린 바람에 다른 해야 할일이 눈에 보이지 않게 방해했다. 클린 아키텍처를 모두가 알았으면 좋겠는 이 마음을, 글로 정리해서라도 가라앉혀 보려 한다.

클린 아키텍처를 덕질하게 된 계기

클린 아키텍처에 대한 내 관심(을 넘어선 사랑)은 레벨 3가 끝나고 찾아온 방학부터 본격적으로 시작됐다. 그 전까진 사실 클린 아키텍처에 대해선 모두가 알고 있을 유명한 원 그림 정도만 알고 있었다. 그렇다면 어쩌다 클린 아키텍처에 대한 애정 어린 탐구가 시작된걸까.

데이터베이스 주도 개발 편하고 좋은 거 아닌가요?

클린 아키텍처에 대한 오해와 헥사고날 아키텍처에 대한 무한한 신뢰가 답답해서 쓰는 글
2024/09/05
DESIGN
HIGHLIGHT

개발 철학에 대한 고민

크루들 봤을 때 보이는 학파들이 아래와 같다 생각했다.
(지극히 개인적인 의견임. 그 외에 수많은 학파 있을 수 있음. 당장 떠오르는 것만 정리해봄)
나는 기능 유지보수 학파에 가장 가까운 것 같다. 그렇다보니 기능 구현에 집중하고, DB 의존 개발에 별 생각 없다. 엄밀하겐 지양해야 한단 쪽에 매우 동의하지만 가장 먼저 나서서 불편해하진 않았다.
또, 당장 성능에 큰 문제 없으면 성능 개선에도 별 관심 없다. 예를 들어 2초 가량 걸리는 테스트가 개선 했을 때 0.x초 가량을 개선할 수 있다면 큰 관심 없다. 시간이 흘러 테스트가 10초 가량이 걸리게 되어 개발에 병목이 발생한다면 그제야 관심을 가진다.
내가 잘하는 거 하기 (with 개발 철학에 대한 고민)
2024/08/29
DIARY_MIND

문제 상황

우테코에서 인덱스와 트랜잭션에 대해 학습하며, 몇 십 만 건의 데이터를 더미 데이터로서 저장해둘 필요가 있었다. 이때, 토미(코치)가 아래와 같은 말씀을 해주셨다.
pk 포함한 insert 쿼리이니 하나의 파일 전체를 하나의 커넥션에서 실행하는 것보다, 여러 개의 파일로 나눠서 여러 커넥션을 이용해 쿼리를 병렬로 실행하면 좀 더 빠르겠죠? 이렇게 데이터가 많을 때는 텍스트 에디터를 사용하는 것보다, 리눅스 커맨드를 이용해 파일의 특정 라인을 잘라내는 것이 훨씬 빠르고 쉬울 수 있습니다.
토미가 제공해주신 파일은 아래와 같은 형태였다.
쉘 스크립트로 insert 쿼리 병렬 실행하기
2024/08/28
DIARY_DEVELOP

Fair Scheduling

그라운드룰: 공평하게 말하기

“회의 내 deadlock과 starvation을 방지하고, fair scheduling을 추구한다”. 내가 속한 총대마켓 팀의 그라운드 룰이다. 무슨 뜻일까? 쉽게 말해 회의 속 자원인 ‘말’을 모두가 공평하게 한다는 뜻이다.
‘피로 쓰이는 안전 수칙’이란 말이 팀 그라운드룰에도 적용된다. 협업을 더 잘하기 위해 총대마켓 팀이 몸소 고군분투하며 만들어 나간 그라운드룰 제1법칙을 소개한다.
1 . 말(자원)은 모두가 공평하게

문제 정의: 말을 못 하는 사람 존재

협업 잘하는 법: Fair Scheduling
2024/08/20
REFLECTION

editorconfig-gradle-plugin 에 대해 알아보자

•
정의) .editorconfig 파일에 정의된 형식 규칙을 준수하는지 여부를 확인하고, 위반 사항을 수정하기 위한 Gradle 플러그인
•
기본 사용)
•
추가 설정)
•
동작 과정)

자바 파일에 대해 .editorconfig 규칙 설정하기

build.gradle에 코드 포매팅 적용 (with editorconfig)
2024/07/29
DIARY_DEVELOP

논리적 오답과 비논리적 정답

감정의 회오리에 숨겨진 자아 정체성

이 이야기는 행복과 슬픔의 감정 가운데 자아 정체성을 찾아간 이야기다. 우리는 살면서 수많은 감정을 느낀다. 감정은 고민을 수반하기도 하고, 우리를 이리저리 요동하기도 한다. 감정의 회오리에 휘말렸을 때 비로소 보이는 것이 있는데, 바로 자기 자신이다. 자신을 반추하여 '나를 나답게 하는 것'(이하 자아 정체성)이 무엇인지 찾아낸다면, 앞으로 다가올 수많은 감정의 회오리 속에서 보다 매끄럽게 헤쳐 나와 평온함을 유지할 수 있다.
자아 정체성은 한 개일 수도 있고, 여러 개일 수도 있다. 평생 똑같을 수도 있고, 해가 지날 때마다 바뀔 수도 있다. 어떤 이는 평생 자아 정체성을 찾지 못할 수도 있다. 확실한 사실은 인간은 최소한 한 개의 정체성을 가진단 점과, 그 정체성을 알면 앞으로의 인생을 슬기롭게 헤쳐 나가는 데 도움이 된단 점이다.

행복

'나는 무엇을 할 때 행복을 느끼는 사람인가'를 정의해보면 정체성을 찾아가는 데에 도움이 된다. 인간은 자기 연민을 지니고 살기에 아무래도 슬픈 감정보단 행복한 감정에서 자신을 찾기 더 쉽다. 이때 가짜 행복을 주의해야 한다. 아래 도라의 이야기를 들어보며 가짜 행복은 무엇이고 진짜 행복은 무엇인지 알아보자.
도라는 집에서 홀로 게임을 하며 '와, 이게 행복이지!'라고 생각했다. 만족할 만큼 게임을 한 도라는 게임을 껐다. 게임을 하던 중과 달리 게임을 끈 후엔 퀭한 눈과 약간의 두통만 남긴 채 아무 생각도, 감정도 들지 않았다.도라는 우아한테크코스에서 페어와 함께 불꽃 튀는 토론을 하고 나서, 집으로 돌아가며 보람과 행복을 느꼈다. 무엇이든 해낼 수 있으리란 자신감이 쏟아져 나옴을 느끼며 '왜 이렇게 행복하지?'라고 생각했다.
누군가는 게임이 끝나고 나서도 잊을 수 없는 고양감과 자신감을 느낄 수도 있지만, 도라는 그러하지 않았다. 게임이 주는 행복은 도라의 정체성에서 우러나온 행복이 아니기 때문이다. 도라에게 1번은 가짜 행복이다.
소통 잘하는 법: 논리적 오답과 비논리적 정답
2024/06/20
REFLECTION
외부 API를 연동하기 위해 RestClinet를 사용하던 중 아래와 같은 코드를 마주했다. 여기서 builder()가 이 글의 주제다. 결론부터 말하자면 builder 패턴은 때론 anti pattern 이 될 수 있다. 특히 POJO에선 anti pattern 으로 사용하게 될 확률이 높다. 이에 대해 Spring Framework Docs에서도 사용하고 있는데 좋은거 아니야? 라고 반문할 수 있다.

When Builder is anti-pattern

builder 패턴이 왜 문제가 될 수 있는지를 살펴보면 해당 질문에 대한 해답을 어느 정도 얻어갈 수 있다.
아래 아티클의 내용 중 핵심을 뽑아보자면 아래와 같다.
POJO에서 builder 패턴의 효용성
2024/06/02
DIARY_DEVELOP
애플리케이션 로직과 도메인 로직이 각각 무엇인지에 대해 이해하고, 둘을 구분해 코드를 개선한 사례를 글로 풀어보겠습니다.

애플리케이션 로직? 도메인(비즈니스) 로직?

각각을 아래와 같이 짧게 정의해볼 수 있습니다. 여기서 도메인 로직의 정의는 조금 추상적으로 느껴집니다.
•
애플리케이션 로직: 도메인 로직이 의사결정을 할 수 있도록 입력을 제공하거나, 그 결과를 외부 서비스, DB, UI 등에 업데이트하는 역할을 맡음
•
도메인(비즈니스) 로직: 현실 세상의 문제에 대한 의사결정을 함

애플리케이션 로직만 있고 도메인 로직은 없는 시스템 vs 애플리케이션 로직만 있고 도메인 로직은 없는 시스템

애플리케이션 로직과 도메인(비즈니스) 로직을 구분해 얻는 장점
2024/05/14
DIARY_DEVELOP
우테코 내 핫한 였던 DELETE 메서드에 대한 논란들을 내 생각과 함께 정리해보겠다.

1. DELETE는 멱등성을 보장하는가? 보장해주어야 하는가?

(1) DELETE는 멱등성을 보장하는가?

아래와 같은 상황에서 DELETE /reservations/1 은 멱등성을 보장한다고 말할 수 있을까?
우테코 슬랙 채널에 올라온 재밌는 이야기를 가져와봤다. 대다수의 크루들이 멱등성을 보장한다고 답했다. 이때, 한 가지 재밌는 의견을 내준 크루가 있었다.
DELETE의 멱등성 보장 & DELETE의 id 검증 필요성(200, 400 status code)
2024/05/10
WEB/INFRA

좋은 API란?

API는 application programming "interface"의 약자로, 응용 프로그램에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.
이번 미션에선 HTTP API, JAVA API 정도를 사용했다. HTTP API를 이용해 웹브라우저(응용프로그램)와 저희 서버 간에 데이터를 주고받을 수 있었다. JAVA API를 이용해서 저희의 자바애플리케이션을 쉽게 구현할 수 있었다.
API도 결국엔 인터페이스이기에 API가 왜 만들어졌고 왜 쓰는지를 고민해보는건 인터페이스를 만들고 쓰는 이유를 고민해보는것과 비슷한 맥락으로 바라볼 수 있다고 생각한다. 우리는 인터페이스를 만듦으로써 구현과 사용을 분리하고 기능을 추상화하여 사용을 쉽게 만들 수 있었다. 마찬가지로 우리는 API를 만들고 사용함으로써 서로 다른 프로그램 간 추상화된 기능을 쉽게 사용하게 만들 수 있다.
결국 레벨 1에서 배웠던 좋은 코드를 짜는 법이 좋은 API를 만드는 법에도 적용된다. 의도가 분명하고 적절한 역할과 책임을 가지는 객체들에서 객체 대신 API를 대입해보면 된다.

REST API란?

중첩 리소스에 대한 REST API 디자인 (with. 좋은 API란)
2024/05/04
DIARY_DEVELOP
Repository를 인터페이스화 하여 얻는 장점은 뭘까? 특히나, db가 바뀔 일 없는 상황에선 더더욱 의문이 들 수 있다. 이에 대해 내 나름대로의 근거를 찾아간 과정을 공유해보겠다.

Repository의 구현체를 Dao로 명명

우선 내 코드의 구조를 설명하자면 domain 패키지에 Repository 인터페이스가 들어가있고, Repository의 구현체는 dao 란 이름을 가진 채로 dao 패키지에 들어가있다. 이게 무슨 뚱딴지 같은 소리야? 싶은 이들은 코드로 좀 더 내 코드의 상황을 살펴보자. 이해를 돕기 위한 부분만 남기고 간략화한 코드다. 전체 코드를 보고 싶다면 아래 링크로 들어가서 볼 수 있다.
domain 패키지엔 아래 클래스들이 들어있다. 참고로, domain 패키지에 repository 인터페이스를 넣어준 이유는 repository를 도메인 객체의 컬렉션을 관리하는 개념으로 보았기 때문이다.
Repository의 구현체를 숨겼을 때 얻을 수 있는 장점
2024/04/27
DESIGN

고민한 상황

Controller > Service > Repository 구조의 스프링 프로젝트에서 Service가 다른 Service에 의존할지, 다른 Repository에 의존할지 고민이 되는 순간이 생겼다. 코드로 보자면 아래와 같은 상황이었다.
Reservation이 ReservationTime과 연관관계를 맺고 있어 Reservation을 저장하려면 ReservationTime에 대한 조회 쿼리를 함께 날려야 했다. 이때 ReservationService 에서 ReservationTimeRepository의 findById() 함수를 이용할지, ReservationTimeService의 findById() 함수를 이용할지 고민이 되었다. 둘중 뭘 사용해도 결과는 쿼리 실행 결과는 똑같은 상황이었다. 고려할 점은 객체 간 의존성이었다.

Service에서 다른 Service 의존

ReservationService가 ReservationTimeDao를 아는 건 Controller -> Serivce -> Dao 순에서 하위 계층을 참조하고 있기에 순환참조의 위험이 없다. 그러나 중복 코드가 생길 수 있다. 지금 상황에선 ReservationTimeService 에 아래의 함수가 존재했다면, 두 Service 객체 사이에 중복 코드가 존재한다.
Service에서 다른 Service 의존 vs Repository 의존
2024/04/26
DIARY_DEVELOP
Web, Service, Dao 레이어를 분리해둔 코드에 대해, 현재 database를 사용하지 않는데 레이어 분리가 꼭 필요했을지에 대해 질문 받았다.

Dao 레이어 분리

정확하겐 아래와 같이 레이어를 분리해뒀다.
•
Web : request/responseDTO로 웹과 상호작용
•
Service : request/responseDTO를 domain으로 매핑해 웹과 데이터저장공간 사이를 연결
•
Dao : domain으로 데이터저장공간과 상호작용
오버엔지니어링과 Dao 레이어 분리
2024/04/18
DIARY_DEVELOP
아래 코드에 대해 Dao인데 Repository 어노테이션을 사용한 이유에 대해 질문 받았다.
일단 왜 위의 코드가 Dao인지부터 궁금할 수 있는데, 추후 save, delete, find 동작이 List 콜렉션에 대해 동작하는 게 아니라 database에 대해 동작하게 리팩토링할 계획이라 Dao라고 이름 붙여뒀다.

Repository 어노테이션의 역할

스프링 빈으로 등록하고 싶어서 별 고민없이 사용했었는데, @Repository 어노테이션의 역할을 살펴보니 현재 코드에선 불필요하단 점을 깨달아 @Component 어노테이션으로 변경해주었다. 현재 코드에선 database와 관련한 예외를 변환할 일이 없기 때문이다. 스프링 빈으로 등록시키는 건 @Component 어노테이션으로 충분하다.
Dao 클래스에 Repository 어노테이션을 붙여도 될까
2024/04/17
DIARY_DEVELOP
기본적인 웹 요청을 처리할 수 있는 프로그램을 페어와 만들며, DTO 사용과 관련한 컨벤션에 대해 논의했다. 크게 1) API마다 서로 다른 DTO를 사용할지, 하나의 DTO를 사용할지와 2) DTO의 네이밍 컨벤션에 대해 논의했다.

Web 계층의 DTO

Spring Boot 프레임워크를 사용해 웹 요청을 받고 응답하도록 했다. 이때, Spring Boot에서 제공하는 @Controller, @RequetsMapping 어노테이션을 사용해 요청을 처리하는 Web 계층이 만들어졌다. 완성된 Web 계층의 코드는 아래와 같다.
Web 계층의 DTO와 네이밍 컨벤션
2024/04/16
WEB/INFRA
우테코 미션을 하다보면, 추상클래스를 쓸 때도 있고 인터페이스를 쓸 때도 있다. 둘의 차이를 내 생각과 함께 면밀히 정리해보겠다. 용어 정의에 바탕한 이론을 다루는 글임을 미리 밝힌다. 학창 시절 교수님께 배웠던 C++의 추상클래스와 비교하며 원론적인 정의를 내려보겠다.

1. Dynamic Method Dispatch (vs. Dynamic Binding)

먼저, Dynamic Method Dispatch 라는 개념을 통해 추상 이란 용어에 대해 이해해보자. 긴 용어로 들으면 뭐지 싶을 수 있는데, 해석해보면 어렵지 않다. “동적으로 호출할 메서드를 결정한다”라는 뜻이다. 반댓말론 Static Method Dispatch 가 있다. 이는 “정적으로 호출할 메서드를 결정한다”라는 뜻이다.
정적이라 함은 컴파일 시점에 컴파일러가 특정 메서드를 호출할 것을 명확히 알고 있는 경우를 의미하고, 동적이라 함은 컴파일러는 어떤 메서드를 호출해야 하는 지 모르고 런타임 시점에 호출할 메서드를 결정하는 경우를 의미한다.
그렇다면 어떻게 해야 동적으로 메서드 호출을 결정할 수 있을까? 바로, 인터페이스나 추상 클래스에 정의된 추상 메서드를 사용하면 된다. 같은 클래스를 상속하고 있는 여러 클래스 중 어느 서브 클래스를 사용할 것인가를 런타임 시점까지 미룸으로서, 클래스 재사용성을 높이는 것이다.
Abstract class vs Interface (virtual function vs abstract method)
2024/03/25
JAVA/KOTLIN
3월 18일, 벌써 우테코에서 한 달이 지났습니다. 한 달 간 자동차 경주 게임, 사다리 게임, 블랙잭 게임 총 세 가지 미션을 진행했습니다. 미션을 진행하며 생각한 내용들을 정리해보겠습니다.
+
4월 13일, 레벨 1의 마지막 미션인 체스 게임까지 완료한 시점에서 해당 글을 이어 작성해보겠습니다. 레벨 1 기간 동안 생긴 저의 개발 철학과 기준들을 작성하려 합니다.

1. 자동차 경주 게임

(1) SOLID 의존 관계 역전 원칙

문제가 된 코드는 아래와 같았습니다다.
레벨 1 기간동안 생긴 나의 개발 철학과 기준 (Java, OOP)
2024/03/18
JAVA/KOTLIN

Inheritance(상속)

•
정의) 기존에 정의되어 있는 클래스의 필드와 메서드를 물려받아 새로운 클래스를 생성하는 기법
•
장점)
•
단점)

Composition(조합)

•
정의) 전체를 표현하는 클래스가 부분을 표현하는 객체를 포함해서 부분 객체의 코드를 재사용하는 방법
•
구현) 조합하고 싶은 클래스의 인스턴스를 새로운 클래스의 private 필드로 참조하고, 인스턴스의 메서드를 호출하는 방식으로 구현
Inheritance vs Composition
2024/03/11
DIARY_DEVELOP
Load more