페레로

[AWS] CloudFront로 React 정적배포하기 - 7. Route53 A/CNAME 레코드 추가

rocher71 — Thu, 6 Nov 2025 17:41:49 +0900

AWS CloudFront로 React 프로젝트를 배포하는 과정을 기록해보려고 한다.

글은 2025년 11월 기준 aws 콘솔이다.

이전 글 확인하기

[AWS] CloudFront로 React 정적배포하기 - 1. 가비아 도메인 구매하기

[AWS] CloudFront로 React 정적배포하기 - 2. Route 53 설정하기

[AWS] CloudFront로 React 정적배포하기 - 3. AWS Certificate Manager ACM인증서 발급

[AWS] CloudFront로 React 정적배포하기 - 4. S3 버킷 생성 및 설정

[AWS] CloudFront React 정적배포하기 - 5. Cloudfront 배포

[AWS] CloudFront로 React 정적배포하기 - 6. ACM 인증서 검증 및 Cloudfront 연결

이제 거의 다 왔다!

이거만 하면 사이트에 접속 가능!!

1. Route 53 콘솔에서 생성한 도메인에 들어간 뒤, 'Create record' 버튼을 클릭한다.

2. 화면을 보고 아래 값들을 입력해주고 'Create records' 버튼을 클릭해준다.

1: Record name 은 비워두기!!!!! 루트 도메인 자체를 의미함.

2: Record type은 A

3: Alias 설정 켜기

4: Alias to CloudFront distribution

5: 4번을 선택하면 자동으로 만들어둔 cloudfront 도메인이 뜬다. 선택만 해주면된다

3. Create record를 한번 더 해준다.

1: 'www' 를 입력한다

2: Record type은 CNAME

3: Alias 설정 끄기!

4: Value에는 www 뒤에오는 도메인(2번 과정에서 생성한부분) 입력.

여기까지 하면 www.memeduck.site , memeduck.site, 둘 다 아래와같이 cloudfront 도메인 들어갔을 때 떴던 access denied 화면이 뜬다! 연결이 된것이다!

지금까지 설정하며 사용한 개념들에 대해서 알아보자.

GPT로 정리해봤다.

1️⃣ 도메인과 DNS의 기본 개념

인터넷에서 도메인은 사람이 보기 쉬운 주소이고,
DNS는 그 도메인을 실제 서버(IP)로 연결시켜주는 전화번호부 같은 시스템

예를 들어:

memeduck.site → 52.78.xxx.xxx (CloudFront 서버 IP)

이 “memeduck.site → 어디로 연결할지”를 기록하는 게 바로 DNS 레코드(record)야.

2️⃣ A 레코드 (Address Record)

역할:
도메인 이름을 IPv4 주소(숫자로 된 서버 주소)로 연결하는 기본 레코드야.
예시:
memeduck.site → 192.0.2.235
하지만 AWS CloudFront나 S3 같은 경우엔 IP가 고정되어 있지 않음
그래서 직접 IP를 쓰지 않고 “Alias” 기능을 사용해 CloudFront 배포를 연결 해줌

정리

항목 설명

대상	실제 IP나 AWS 리소스(CloudFront, S3 등)
용도	루트 도메인(예: memeduck.site) 연결
주의	CloudFront는 고정 IP가 없으므로 “Alias” 필수!

3️⃣ CNAME 레코드 (Canonical Name Record)

역할:
다른 도메인에 대한 별명(Alias) 을 만드는 것
즉, “이 주소로 가면 다른 주소랑 똑같이 취급해줘~” 하는 개념.
예시:이제 사용자가 www.memeduck.site로 접속해도
실제로는 memeduck.site로 리다이렉트되도록 해줌
www.memeduck.site → memeduck.site

정리

항목 설명

대상	다른 도메인 이름
용도	서브도메인 연결용 (www, api, cdn 등)
IP는 없음	CloudFront나 다른 주소를 참조

4️⃣ 루트 도메인 (Root Domain)

의미:
www 같은 접두어(subdomain)가 없는 도메인.
즉, 가장 기본적인 도메인 주소야.
예시:
- 루트 도메인: memeduck.site
- 서브 도메인: www.memeduck.site, api.memeduck.site, cdn.memeduck.site
일반적으로 사용자는 www보다 루트 도메인(memeduck.site)으로 접근하니까
CloudFront 배포도 여기에 연결해주는 게 기본이야.

5️⃣ Alias (AWS 전용 기능)

정의:
AWS Route53에서 제공하는 특수한 A 레코드 확장 기능.
IP를 직접 입력하지 않아도, CloudFront / S3 / ELB 같은 AWS 리소스로 직접 연결 가능.
예시:
memeduck.site (A 레코드 + Alias ON) → d2grajanenhj0.cloudfront.net (CloudFront 배포)
장점:
- CloudFront IP가 바뀌어도 자동 반영됨 (안정적)
- HTTPS 연결 시에도 작동
- 추가비용 없음

정리

항목 설명

기능	A레코드의 확장판 (AWS 리소스로 직접 연결)
대상	CloudFront, S3, ELB 등
장점	IP 관리 불필요, SSL 지원, 자동 업데이트

정리표

개념 역할 예시 비고

A 레코드	도메인을 IP 주소로 연결	memeduck.site → 52.x.x.x	기본 주소 연결
CNAME 레코드	다른 도메인으로 별칭 지정	www.memeduck.site → memeduck.site	서브도메인용
루트 도메인	최상위 도메인	memeduck.site	가장 기본 주소
Alias	CloudFront 등 AWS 리소스에 직접 연결	memeduck.site → CloudFront 배포	AWS 전용 확장 기능

비유하자면:

A 레코드 = “이 집 주소는 123번지야!”
CNAME = “이 별칭(www)은 123번지 집을 가리켜!”
루트 도메인 = “동네 중심 주소 (기본 집 이름)”
Alias = “IP 대신 CloudFront 같은 AWS 건물로 바로 연결해주는 자동 네비게이션!”

여기에 세부 설정만 하면 s3에 올렸던 프론트 코드까지 뜨게 된다.

4. AWS S3 콘솔로 들어와서 생성해둔 버켓의 'Permissions' 탭에 'Edit' 버튼을 클릭해준다.

5. 최상위에 있는 'Block all public access' 버튼을 클릭해서 설정을 해제해준다.

단, 퍼블릭 전체 공개는 보안상 안 좋으니까,

곧바로 CloudFront OAC(Origin Access Control)로 접근 제한을 걸어줄것이다.

6. 다시 S3 콘솔의 bucket을 선택하고, Permissions 탭 하단에 있는 Bucket policy 'Edit' 버튼을 클릭한다.

7. Policy 부분에 아래의 json을 그대로 붙여넣고 하단의 Save changes 버튼을 클릭한다.

단, 버켓이름과 cloudfront 배포 id 부분은 수정해야한다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::S3버켓명/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::계정ID:distribution/CLOUDFRONT배포ID"
        }
      }
    }
  ]
}

계정 ID, Cloudfront 배포 ID는 아래 사진처럼 cloudfront 콘솔에서 확인할수 있다.

8. S3 콘솔에서 Properties 탭 최하단에 있는 Static website hosting 우측의 'edit' 버튼을 클릭한다.

9. Enable, Host a static website를 클릭하고 index.html 을 입력해준다.

하단에 redirection 설정이 있는데 그부분은 비워둬도 된다.

10. Cloudfront 콘솔의 Error pages탭에 'Create custom error response' 버튼을 클릭한다.

/login, /mypage, /signup과 같은 경로에서 새로고침 시
CloudFront가 S3에 해당 경로(artist/3)를 직접 찾으려 하다가 “AccessDenied” 발생하는 문제 해결.
CloudFront가 403 또는 404 발생 시 index.html로 돌려보내도록 설정.

위 두가지를 위해서 설정하는 것이다.

11. 403 에러에 대해서 다음 값들을 입력한다.

1: 403 Forbidden

2: 0

3: Yes

4: /index.html

5: 200 OK

404 도 똑같이 만들어준다.

12. 혹시, Cloudfront 콘솔에서 아래 사진처럼 Default root object가 설정되어있지 않다면, edit를 눌러서 'index.html' 로 수정해준다.

여기까지 해주면 원래 크롬에서 접속이 가능해야하는데 나는 계속 Access Denied가 떴다ㅠ 확인해보니 S3에 파일을 잘못올려서 그랬는데,

아래 사진처럼 버켓의 루트에 index.html이 있도록 올려줘야한다.

처음에 업로드 할 때 upload folder로 dist폴더 자체를 넣어버려서 안됐던거였다!

짠 크롬에서 접속하면 www.duckon.site duckon.site 다 잘 뜬다!!!

이제 api 연결을 하려면 몇가지 더 설정을 해야하는데... 그건 다음 글로 써보겠다.

[AWS] CloudFront로 React 정적배포하기 - 6. ACM 인증서 검증 및 Cloudfront 연결

rocher71 — Thu, 6 Nov 2025 16:06:36 +0900

AWS CloudFront로 React 프로젝트를 배포하는 과정을 기록해보려고 한다.

글은 2025년 11월 기준 aws 콘솔이다.

이전 글 확인하기

[AWS] CloudFront로 React 정적배포하기 - 1. 가비아 도메인 구매하기

[AWS] CloudFront로 React 정적배포하기 - 2. Route 53 설정하기

[AWS] CloudFront로 React 정적배포하기 - 3. AWS Certificate Manager ACM인증서 발급

[AWS] CloudFront로 React 정적배포하기 - 4. S3 버킷 생성 및 설정

[AWS] CloudFront React 정적배포하기 - 5. Cloudfront 배포

1. Route53 콘솔에서 'Create record' 버튼을 클릭한다.

2. AWS Certificate Manager 콘솔에서 CNAME name, CNAME value 두 쌍이 있을 것이다.

이 쌍을 두번 route 53에 입력해줄 것이다.

3. 아래와 같아 Route53 create record 창에서 값을 넣어준다.

1: ACM의 첫번째 CNAME name 값. 이때 그대로 복사해오면 뒤에 도메인이 붙어있을 수 있다. 중복되지 않게 제거해주도록 하자.

2: CNAME 선택

3: Alias 사용 끄기

4: CNAME value

똑같이 ACM의 두번째 CNAME name, value 값을 새로운 route53 레코드를 추가해서 넣어주면 된다.

두번째 레코드에서는 CNAME name 부분에 www까지만 오도록 설정해주었다. (뒤에 .memeduck.site 는 자동으로 붙으니까!)

이렇게 설정을 해주고 조금 기다리면 AWS Certificate Manager 에서 Pending이었던 status가

아래처럼 바뀐다. 다 바뀌는데 시간이 좀 걸려서 기다려야한다!

나는 memeduck.site 는 바로 됐는데, www.memeduck.site 는 success 될때 까지 15분정도 걸린것 같다.

그래서 아래단계를 미리 진행했다.

4. CloudFront 콘솔에서 사이트를 위해 만든 distribution을 클릭하고, 중앙에 있는 Add domain 버튼을 클릭한다.

5. Domains to serve 부분에 www가 붙은 도메인과 붙지 않은 루트 도메인 두개를 넣어준다.

6. 위 3번 단계의 status가 다 success가 됐다면, 이렇게 자동으로 생성한 acm 이 뜬다.

정상적으로 뜬다면 우측 하단의 next 버튼을 클릭한다.

7. 다음 페이지에선 설정할건 없고 확인하는 창이다.

우하단의 Add domains 버튼을 클릭한다.

다음 단계는 마지막으로!

Route53에서 A alias 레코드를 설정할 것이다. 다음단계까지만 하면 배포 끝!

[AWS] CloudFront React 정적배포하기 - 5. Cloudfront 배포

rocher71 — Thu, 6 Nov 2025 15:21:42 +0900

AWS CloudFront로 React 프로젝트를 배포하는 과정을 기록해보려고 한다.

글은 2025년 11월 기준 aws 콘솔이다.

이전 글 확인하기

[AWS] CloudFront로 React 정적배포하기 - 1. 가비아 도메인 구매하기

[AWS] CloudFront로 React 정적배포하기 - 2. Route 53 설정하기

[AWS] CloudFront로 React 정적배포하기 - 3. AWS Certificate Manager ACM인증서 발급

[AWS] CloudFront로 React 정적배포하기 - 4. S3 버킷 생성 및 설정

1. AWS console에서 cloudfront 에 접속한다.

cloudfront는 region이 global로 뜨는게 맞다!

우측에 Create distribution 버튼을 클릭해준다.

2. 아래의 정보들을 입력하고 하단의 Next 버튼을 클릭해준다. 회색은 선택값!

1: cloudfront distribution 이름

2: 부가 설명 (선택)

3: React는 Single website or app 기본 설정 그대로 두면 된다.

4: 이 칸은 비워둬야한다! 우리는 route 53 Hosted zone이 있기때문에, 비워둬야함!

5: 태그는 선택사항.

3. Origin 설정해주는 화면. Amazon S3 > Browse S3 버튼을 클릭해준다.

그러면 아래와같이 이전에 생성했던 S3 버켓이 보인다.

해당 버킷을 클릭하고 우하단의 Choose 버튼을 클릭한다.

4. 이제 다른 설정들은 그대로 두면 되는데,

여기서 'Allow private S3 bucket access to CloudFront' 부분은 꼭 체크가 돼있는걸 확인하자.

이걸 체크하면 CloudFront가 자동으로 OAC(Origin Access Control) 을 생성해서
S3 버킷을 “CloudFront만 읽을 수 있게” 만들어주고, 내부적으로

새 OAC가 자동 생성됨
S3 버킷 정책에 필요한 JSON을 자동 제안 (다음 단계에서 복사/붙여넣기 가능)

이런 설정이 된다!

5. security 설정이다.

Enable security protections를 선택하면 월에 약 $14 정도가 부과된다고 한다.

Enable security protections	SQL injection, XSS, 봇, IP 차단 등 일반적인 웹 공격 방어. AWS가 관리하는 룰셋을 자동 적용.	유료 (대략 $14/1000만 요청당/월)
Do not enable security protections	단순 정적 사이트일 경우 방화벽 생략. CloudFront만 사용.	무료

MemeDuck 프론트는 정적 사이트(SPA) 로, 서버 API나 로그인 요청을 직접 받지 않음.
공격 표면이 거의 없기 때문에, CloudFront + HTTPS만으로 충분히 안전.
WAF는 나중에 백엔드 API (예: ALB, API Gateway) 앞단에서 쓰는 게 효과적

나는 위와같은 이유로 Do not enable security protections 를 선택했다.

6. Distribution 생성하기

지금까지 입력한 설정들을 확인해주는 화면이다.

모두 맞게 되어있으면 Create distribution 버튼 클릭!

7. 생성 후 조금 기다리면, logging 탭에서 Distribution status가 enabled로 바뀐다.

General에 있는 d123abcde.cloudfront.net 같은 도메인이 생기고, 여길 들어가보면

이런식으로 Access Denied가 뜬다.

아직 설정을 다 안해줬으니까 이렇게 뜨는게 맞다. 그럼 마저 설정하러 가보자!

다음 단계로 넘어가기 전에, dns 전파가 완료됐는지 확인해야한다.

로컬 cli 아무데에나 아래 코드를 쳐서 가비아에 등록한 route53 네임서버가 뜨는지 확인해보자.

nslookup -type=ns memeduck.site 8.8.8.8

nslookup -type=ns memeduck.site

다음 단계에서 acm 인증서를 검증하고, cloudfront와 연결할것이다.

[AWS] CloudFront로 React 정적배포하기 - 4. S3 버킷 생성 및 설정

rocher71 — Thu, 6 Nov 2025 13:14:51 +0900

AWS CloudFront로 React 프로젝트를 배포하는 과정을 기록해보려고 한다.

글은 2025년 11월 기준 aws 콘솔이다.

이전 글 확인하기

https://bba-jin.tistory.com/78

[AWS] CloudFront로 React 정적배포하기 - 1. 가비아 도메인 구매하기

AWS CloudFront로 React 프로젝트를 배포하는 과정을 기록해보려고 한다.글은 2025년 11월 기준 aws 콘솔이다. 1. 가비아에서 도메인 구매하기1. 가비아에서 구매할 도메인을 검색해본다. 마음에 드는 도

bba-jin.tistory.com

https://bba-jin.tistory.com/79

[AWS] CloudFront로 React 정적배포하기 - 2. Route 53 설정하기

AWS CloudFront로 React 프로젝트를 배포하는 과정을 기록해보려고 한다.글은 2025년 11월 기준 aws 콘솔이다. 이전 글인 가비아 도메인 구매하는 방법은 아래 글에 자세히 적어두었다. https://bba-jin.tistory

bba-jin.tistory.com

https://bba-jin.tistory.com/80

[AWS] CloudFront로 React 정적배포하기 - 3. AWS Certificate Manager ACM인증서 발급

AWS CloudFront로 React 프로젝트를 배포하는 과정을 기록해보려고 한다.글은 2025년 11월 기준 aws 콘솔이다. 이전 글 확인하기 https://bba-jin.tistory.com/78 [AWS] CloudFront로 React 정적배포하기 - 1. 가비아 도메

bba-jin.tistory.com

1. AWS Console 에서 S3 서비스로 이동한다.

이때, ACM 인증서 만들 때 바꿨던 Region을 꼭 Seoul로 바꿔주자!

CloudFront는 전역 서비스지만
버킷은 실제 파일 저장 위치가 한국 리전인 게 더 효율적임.
다른 리전에 만들어도 동작은 하지만 지연과 관리가 번거로워짐.

'General purpose buckets', 'Directory buckets'가 있는데 전자를 선택해준다.

Directory buckets는 새로나온 S3 Express One Zone인데 CloudFront연결이 안되고 아직은 실험적이라고 합니다.

즉, Directory bucket은 CloudFront에서 인식도 안 됨,
정적 파일 배포 목적이면 무조건 General purpose bucket 써야 함!

2. Bucket name에 원하는 이름 입력하기.

여기 말고 아래 부분은 모두 기본 셋팅으로 두면 된다.

나는 Bucket Versioning 부분만 Enable로 바꿔줬다.

그러면 아래와같이 버켓이 생성된걸 확인할 수 있다.

해당 버킷을 클릭해서 들어가자.

CICD 설정을 하기 전에, 우선 사이트 배포를 확인하기 위해 현재 있는 프론트엔드 파일을 업로드할것이다.

3. 업로드 버튼 클릭

4. 프론트엔드 프로젝트에서 npm run build 를 통해 dist 폴더를 만들어준다.

프로젝트 디렉토리에서 npm run build를 하면 아래와 같이 dist 폴더가 생성된 것을 확인할 수있다.

5. 버킷 콘솔에서 Add folder 버튼을 눌러 위에서 만들어진 dist를 선택하고 하단의 upload 버튼을 클릭한다.

6. S3 버킷에 dist 폴더 파일들이 잘 올라간 것을 확인할 수 있다.

[AWS] CloudFront로 React 정적배포하기 - 3. AWS Certificate Manager ACM인증서 발급

rocher71 — Thu, 6 Nov 2025 13:09:06 +0900

AWS CloudFront로 React 프로젝트를 배포하는 과정을 기록해보려고 한다.

글은 2025년 11월 기준 aws 콘솔이다.

이전 글 확인하기

https://bba-jin.tistory.com/78

[AWS] CloudFront로 React 정적배포하기 - 1. 가비아 도메인 구매하기

bba-jin.tistory.com

https://bba-jin.tistory.com/79

[AWS] CloudFront로 React 정적배포하기 - 2. Route 53 설정하기

bba-jin.tistory.com

1. AWS Console에서 'Certificate Manager'를 검색해 들어간다.

이때 CloudFront용 인증서는 무!조!건! Region이 United States - N.Virginia 여야만 한다!!!

지역을 설정하고 우측에 있는 'Request'버튼을 클릭한다.

2. 다음 페이지에는 기본적으로 선택 되어있는 'Request a public certificate'를 그대로 두고 Next 버튼을 누른다.

3. 아래 정보들을 입력한다.

1: 도메인 주소 (저는 루트 도메인인 memeduck.site 와 www.memeduck.site 를 모두 입력해주었습니다.)

2, 3, 4 : 기본 설정 그대로

이후 Request 버튼 클릭

그러면 아래와같이 인증서가 발급된다.

[AWS] CloudFront로 React 정적배포하기 - 2. Route 53 설정하기

rocher71 — Thu, 6 Nov 2025 13:06:02 +0900

AWS CloudFront로 React 프로젝트를 배포하는 과정을 기록해보려고 한다.

글은 2025년 11월 기준 aws 콘솔이다.

이전 글인 가비아 도메인 구매하는 방법은 아래 글에 자세히 적어두었다.

https://bba-jin.tistory.com/78

[AWS] CloudFront로 React 정적배포하기 - 1. 가비아 도메인 구매하기

bba-jin.tistory.com

1. AWS Console의 Route53으로 접속한다.

이때! Region은 Global로 뜨는게 맞다. (특정 지역을 선택하는게 아님!)

2. Hosted Zone 생성하기

좌측 메뉴의 'Hosted zones' > 'Create hosted zone' 버튼을 클릭한다.

3. 아래 정보들을 입 후 하단에 'Create hosted zone' 버튼을 클릭한다. 빨간색은 필수!

Domain name(필수!) : 가비아에서 산 도메인

Description : 부가 설명

Type : Public hosted zone 버튼 클릭 (필수!)

Tags : 태그 설정(인데 안해도 전혀 문제되지 않는다)

+ 여기서 설정한게 하루가 지나도 적용이 안되길래 골머리를 썩었는데

다시 사진을 확인해보니 내가 'memeduck.site'가 아니라 'memduck.site'로 입력을 해둔걸 발견했다ㅠㅜ

혹시 이 글을 보고 설정하고 계신분들은 domain name에 오타가 나지 않도록 조심하시길!

4. 생성 후 '.org', '.com', '.co.uk', '.net'으로 끝나는 4개의 NS레코드가 나온다.

이 네개를 복사해서 가비아에 넣으면 된다.

5. 'My 가비아' https://my.gabia.com/dashboard#/ 링크 접속 후 '서비스 관리', '서비스 관리' 탭을 클릭한다

6. 구매한 도메인 우측에 '관리' 버튼 클릭

7. 네임서버 우측에 있는 '설정' 버튼 클릭

8. 1-4차 입력칸에 4에서 생성된 네임서버들을 입력한다.

순서는 무관!

9. 소유자 인증을 하고 확인버튼을 누르면 아래와 같이 변경된 걸 확인할 수 있다.

설정을 잘 하면 아래 코드를 그냥 아무 로컬 cli에 입력했을 때 처음엔 아래 사진 처럼 나오던게, 2~30분정도 지나면 두번째 사진처럼 route 53에 뜨는 ns 레코드가 나온다.

 nslookup -type=ns 사이트도메인 8.8.8.8

30분정도 후, 네임서버 등록이 완료됐을 때 :

등록 후 전파되는데 시간이 걸리기 때문에, 다음단계를 진행하고 추후에 이 부분을 확인하는걸 추천한다.

✅ 1	Route53 Hosted Zone memeduck.site 새로 생성
✅ 2	가비아 네임서버 4개 AWS로 교체 완료
3	전파 대기 (최대 24시간, 보통 1~3시간)
4	ACM 자동 검증 후 “Issued”
5	CloudFront 배포 + Route53 레코드 연결

[AWS] CloudFront로 React 정적배포하기 - 1. 가비아 도메인 구매하기

rocher71 — Thu, 6 Nov 2025 13:02:57 +0900

AWS CloudFront로 React 프로젝트를 배포하는 과정을 기록해보려고 한다.

글은 2025년 11월 기준 aws 콘솔이다.

1. 가비아에서 도메인 구매하기

1. 가비아에서 구매할 도메인을 검색해본다.

마음에 드는 도메일을 선택하고 우측에 '신청하기' 버튼을 누른다.

나는 1년에 2,750원짜리 이벤트 도메인으로 골랐다.

2. 네임서버 설정 > '가비아 네임서버 사용'

사실 여기서 타사 네임서버 사용을 선택해야 route 53을 사용할 수 있는데,

몇번을 해봐도 타사 네임서버 사용하면 뭔가 내부적으로 오류가 나서 다음 단계로 진입이 안됐다.

그냥 가비아 네임서버 사용 버튼을 선택하면 된다. 어차피 나중에 바꿀 수 있음!

3. 도메인 구매

결제하면 카톡이 오고, DNS 관리로 들어가면 구매한 도메인이 뜬다.

4. 도메인 들어가서 확인해보기

아무것도 안뜨는게 맞다!!

당연히 아무런 설정도 안해줬으니까!!!

이제 설정 하러 가보자

2024년 개발 회고

rocher71 — Sun, 5 Jan 2025 05:42:07 +0900

조오금 뒷북이지만, 2024년 회고를 해보려고 한다.

1. 2024.02.23 라인 본사 방문

친한 동아리 선배가 라인에서 백엔드 개발자로 일하고 계신데, 좋은 기회로 초대해주셨다.

오피스 뷰가 정말 좋았고.... 무엇보다 선배 취직하신지 1년이 넘었는데 회사에 세번째인가? 와본다고 하셨던게 기억에 남는다ㅋㅋㅋㄱ

재택이 정말 잘 되어있다고 말씀해주셨다.

2. 2024.05~ KB IT's Your Life 합격

미국 인턴 후 귀국해서 한 학기는 휴학을 할 예정이었는데, 혼자서 공부를 열심히 하는 타입은 아닌지라.... 부트캠프를 선택했다.

합격자 OT날 다과도 예쁘게 준비되어있었고, 명찰과 웰컴키트도 받았다.

그치만 한 달정도 다녀보다가 퇴소했다.

일단 거리가 너무 멀었다.... 인천에서, 그것도 인하대후문에서 교육 장소인 건대까지 통학이... 2시간 20분 정도 잡았어야했다.

거기에 전공자 반이었고 백엔드 교육이 주를 이룬다고 홍보하는 걸 봐서 입과했는데,

계속 HTML CSS JS 수업만 반복되었고... 3개월 뒤에 백엔드 수업이 시작되는 과정이었는데

이걸 위해 눈 감고도 할 수 있는 프론트 부분을 3개월간 4-5시간을 통학하며 들을 자신이 없었다.

결국 퇴소를 했다.

3. 2024.08-2024.11 Mono 개발 참여

정말 댕쩌는... 데스크탑 메일 어플리케이션이다.

프론트엔드 개발자로 참여했고, 다른 개발자분들에 비해 실력이 부족했지만 열심히 하려고 노력했다.

나는 주로 에디터 부분을 맡았는데, 모노 개발을 하면서 깃헙 리포에 별2.8만개나 되는 tiptap 에디터에 contribute할 수 있었다.

https://github.com/ueberdosis/tiptap

GitHub - ueberdosis/tiptap: The headless rich text editor framework for web artisans.

The headless rich text editor framework for web artisans. - ueberdosis/tiptap

github.com

당연히 내 레포에 바로 고정해둠...허허

그치만 모노 역시 병원 이슈로 그만두게 되었다....

재미도 있었고 끝까지 같이 하고 싶었는데.. 건강이...흑흑

데탑 메일 관리 어플 관심있으시면 요기 들어가보셔요

https://monomail.co/

Mono Mail - Join waitlist

Next-generation email app. Minimal and focused. Work seamlessly.

monomail.co

4. 2024.10 삼성전자 서류합격

겨우 서류합격이긴 했고 당연히 코테에서 광탈을 했지만..!!!!

그래도 제대로 취준 준비도 안 된 상태에서, 전자 DS부문에서 서합 했다는 것 자체가 너무 기뻤다.

코테는 진짜 난이도 극악이었다....

그래도 기출 이것저것 풀어보고 갔는데 너무 어려웠음...

게다가 당연히 안될 줄 알고 넣어본거라서, 제대로 사전조사를 안하고 보러 갔다가

2번 문제를 풀었다 ㅋㅋ ide에선 잘 돌아가는데 도대체 왜 시간 초과가 나는거지!!!!

라는 생각을 하며 채점서버 문제겠거니 했는데^^ 부끄러우니까 이하 생략하겠습니다...

그래도 이번 상반기 다시 도전해본다....

5. 수많은 서탈

코테 준비가 정말 안됐음에도 일단 눈 감고 서류부터 넣어봤다.

결과는 광~~탈~!!

1, 2학년땐 컴공은 서류에선 거의 붙여주고 코테에서 많이 컷한다고 들었었는데... 그거 맞는건가요ㅠㅜ

물론 내가 자소서도 거의 제대로 안쓴게 많았지만, 위 사진보다 훨씬 많이 서탈을 했다. (기분 나빠서 초반엔 서탈한거 행을 삭제해버림ㅋㅋ)

그래도 신한카드, 삼전, 카카오모빌리티, 하나은행 정도는 서류 합격이었다. 몇개 더 있었던것 같은데

이때 쯤 부터 병원을 다니기 시작해서... 제대로 기록도 안하고 넘어간게 많았다.

아무튼 하반기 공채 10월쯤 부턴 거의 지원도 안했다.

그냥 내년에 싸피 하길 기도함ㅋㅋ

6. 2024.12.17 캡스톤 종합설계 우수상 수상

한 학기동안 개발한 프로젝트로 우수상을 받았다..!!

사실 개발은 일주일? 만에 몰아서 했는데 ㅋㅋㄱ 다른 팀원들이 잘 해줘서 받을 수 있었다.

종설 발표에 버츠비가 부스를 운영해서(?? 왜 왔는지 아직도 모름) 립밤이랑 귀여운 벌 인형도 받았다.

가장 기억에 남는 것은 요 판넬 만들기...

왜냐면 월요일 자정까지 제출이었는데 이걸 일요일 저녁 7시쯤에 다같이 회의를 위해 모인 날 깨달았음....

ㅋㅋㅋㅋㄱ 그래서 갑자기 학교에서 밤 새서 UI갈아 엎은 뒤 만든 판넬..

20학번 가장 친한 동생네 팀이랑 우연히 같은 테이블에 배정됐는데, 우리 두 팀이 나란히 대상, 우수상을 받았다 ㅎㅅㅎ

동생네 팀은 진짜 피피티도 짱이고 발표 보면서 모두가 "대상은 쟤네다!!!" 했는데 우리팀은 거의 유일하게 발표에서 시연 영상도 없었고..

열심히는 했지만 다들 기대 안하고 있었다가 '장려상 정도는 받을 수도...?' 라는 생각 후에 받은 우수상이라서 너무 기뻤다 ㅎㅎ

6. 2024.12.23 싸피 서울캠퍼스 전공자반 최종 합격!

모든 공채 광탈 후 희망은 싸피뿐이었고....

PT면접이 처음이기도 했기에 살면서 처음으로 면접스터디까지 하며 준비를 했었다.

결국 PT면접은 그럭저럭 본 것 같은데, 아무튼 최종 합격 할 수 있었다.

감사합니다 싸피ㅠ

아마 올 해는 싸피 하면서 열심히 코테 준비하고, 본격적으로 취준하는 시간이 될 것 같다.

7. 개발 외적인 부분

올해 막 열심히 개발을 한 건 아니라 그 외 부분이 더 많은데...

우선 10키로 감량에 성공했고, 대만 부산 여수 전남 제주도 강릉 홍콩 여행을 다녀왔다 ㅎ

취준을 위해 조금 남아있던 금발 머리도 다 검정색으로 덮었고, 취직 사진도 찍어봤다.

7월? 쯤부터 병원에 다니기 시작했는데, 경과는 좋은 것 같다..!

총정리 해보면 연초에는 그냥 다시 한국 생활 적응을 했고, 하반기부터 공채에 넣다가, 연말에 종설 우수상, 싸피 합격이 가장 기억에 남는다.

그래도 마지막에 상을 받으니 보람찬 한 해였다는 생각이 드는 것 같다 ㅎ

앞으로 싸피 다니면서... 열심히 살아야지!!

[React/Typescript] Button onClick, useRef로 파일 업로드 하기 (input type='file', label 사용x)

rocher71 — Thu, 27 Jun 2024 22:15:54 +0900

React로 파일 업로드 하는 법을 검색해보면

input 태그와 label태그를 활용해서 하는 코드가 많이 나온다.

나는 이미 코드에 커스텀해둔 버튼이 있어서,

해당 태그를 label로 감싸거나 해당 태그 안쪽에 label을 넣든 뭘해도 작동하지 않았다.

그래서 onChange로 input태그 ref에 접근하여 파일 업로드 하는 방식으로 구현을 했다.

이때 react로만 개발하면 useRef에 타입지정을 다로 하지 않아도 잘 실행이 되나,

나는 프로젝트에서 typescript를 쓰고있기 때문에 타입을 지정해주지 않으면 타입 에러가 났고,

아래 코드로 해결했다.

코드

import { useRef } from "react";

//구현해둔 Button ui를 누르면 input type=file이 클릭돼서(.click())/파일선택창 열림

const Card = () => {
  const selectedFiles = useRef<HTMLInputElement>(null); 
  // TS에선 HTMLInputElement라고 타입 지정을 해주지 않으면 에러남

  return (
  <>
  	{/* 버튼 ui */}
    <Button
          variant={'ghost'}
          sizeVariant={'sm'}
          typeVariant={'icon'}
          tooltip={`Add Attachment`}
          onClick={() => selectFile.current?.click()} //input에 접근하기 위한 useRef
        >
      <Paperclip className="w-4 h-4" />
    </Button>
    {/* 파일 업로드 input 태그 */}
    <input 
        ref={selectedFiles}  //ref 연결
        type={'file'} 
        className="hidden" // display:none
        multiple={true}  //파일 여러개 선택 가능하도록
     />
   </>
  );
};

export default Card;

화면 :

김영한 스프링 입문 6. 스프링 DB 접근 기술 - 스프링 통합 테스트

rocher71 — Thu, 6 Jun 2024 21:16:09 +0900

인프런 김영한 스프링 입문

섹션 6. 스프링 DB 접근 기술

- 스프링 통합 테스트

Test도 실제 DB까지 연결하여 동작하는 통합 테스트를 할 예정.

이전에 했던 테스트들은 스프링과 관련이 없고, 순수 자바 코드만을 가지고 했었음.

현재는 순수 자바 코드만으로는 테스트를 할 수 없음 -> DB 커넥션 정보도 스프링 부트가 가지고 있기 때문에.

-> 테스트를 Spring 과 엮어서 해볼 것임.

현재 'MemberServiceTest'는 Java JVM안에서 끝남.

1. 'MemberServiceTest' 파일을 복사하여 같은 위치에 'MemberServiceIntegrationTest'라는 파일명으로 붙여넣기.

2. MemoryMemberRepository를 memberRepository로 수정하고, memberService와 memberRepository 앞에 @Autowired annotation추가

@Autowired MemberService memberService;
@Autowired MemberRepository memberRepository;

이전에는 직접 MemoryMemberRepository, MemberService 객체를 생성해서 넣었음, 이제는 Spring Container에게 해당 객체들을 받아옴.

+ 기존 코드들은 생성자 injection이 좋으나, test 코드는 간단하게 field injection으로 받아도 됨.

이렇게 하면 구현체는 'SpringConfig' 한 곳에서 올라온다.

3. 기존 코드의 '@BeforeEach', '@AfterEach' 및 사용하지 않는 코드 모두 삭제

-> @AfterEach가 필요 없는 이유는 맨 위에 추가한 @Transactional 때문, 추후 설명 예정

현재 코드 상태 :

package hello.hellospring.service;

import hello.hellospring.domain.Member;
import hello.hellospring.repository.MemberRepository;
import hello.hellospring.repository.MemoryMemberRepository;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.transaction.annotation.Transactional;

import static org.assertj.core.api.Assertions.assertThat;
import static org.junit.jupiter.api.Assertions.assertThrows;

@SpringBootTest
@Transactional
class MemberServiceIntegrationTest {

    @Autowired MemberService memberService;
    @Autowired MemberRepository memberRepository;


    @Test
    void 회원가입() {
        //given
        Member member = new Member();
        member.setName("spring");

        //when
        Long saveId = memberService.join(member);

        //then
        Member findMember = memberService.findOne(saveId).get();
        assertThat(member.getName()).isEqualTo(findMember.getName());
    }

    @Test
    public void 중복_회원_예외(){
        //given
        Member member1 = new Member();
        member1.setName("mem");

        Member member2 = new Member();
        member2.setName("mem");

        //when
        memberService.join(member1);
        IllegalStateException e = assertThrows(IllegalStateException.class, () -> memberService.join(member2));

        assertThat(e.getMessage()).isEqualTo("이미 존재하는 회원입니다");
    }

}

4. 여기서 '회원가입'에 대한 테스트를 실행 > 다음과 같은 에러 발생.

'java.lang.IllegalStateException: 이미 존재하는 회원입니다'.

-> 왜냐하면 DB에 'spring'이라는 이름의 회원 존재, test 파일에서 'spring'이라는 이름으로 회원가입 했기 때문.

-> DB의 데이터를 완전 지워줘야함.

5. h2 웹콘솔에 아래 코드 입력 -> 모든 행 지우기

delete from member

이후 조회해보면 아래 사진과 같이 모든 데이터가 삭제되어있어야 함.

실제 DB에 값이 추가되기 때문에 이 상태로 test 돌려야함.

(보통은 test용 DB가 별개로 존재함.)

6. 다시 회원가입 메소드 test 실행

아까와는 다르게 위 사진과 같이 test인데 spring이 뜸.

7. @Transactional annotation을 주석처리하고 다시 회원가입() test를 돌려보자.

처음 실행할 땐 잘 돌아가고, DB에도 'spring'이 잘 올라와 있다.

8. 그러나 다시 한번 또 돌리면 에러가 뜬다.

Test는 반복해서 실행할 수 있어야한다.

이때 Spring이 좋은(기가막힌) 기능을 제공한다.

DB는 기본적으로 'Transaction'이라는 개념이 있음.

그래서 디비에 데이터를 insert query 한 다음에 commit이라는 것을 해줘야 디비에 반영이 됨.

혹은 auto commit 이라는게 존재해서, 보통 auto commit이냐 아니냐의 차이이고, 기본적으로는 transaction이라는 개념이 있어서 다 insert 쿼리를 한 뒤에 commit을 하기 전까지는 DB에 반영이 되지 않음.

auto commit은 커밋이 자동으로 되는 것.

그런데 테스트가 끝난 뒤 롤백을 하면 디비에서 데이터가 모두 없어짐, 반영이 안됨.

이렇게 검증을 할 수 있는 방법이 바로 '@Transactional'이라는 annotation.

이걸 test case에 달면, 테스트를 실행할 때 transaction을 먼저 실행한 뒤, db에 insert query로 데이터를 넣은 다음에

테스트가 끝나면 롤백을 해줌.

그래서 디비에 넣었던 데이터가 깔끔하게 반영이 안되고 다 지워짐.

9. 우선 지금 디비에 있는 데이터를 지워준다

delete from member;

10. 7에서 주석처리한 @Transactional 어노테이션을 다시 주석처리하지 않고 회원가입 테스트를 실행한다.

그러면 몇번을 실행해도 테스트가 실행된 뒤에 디비를 봐도 깔끔!

테스트를 시작하기 전에 transaction을 걸고,

db에 쿼리를 다 날린다. (그래서 findOne, join 등등 다 됨)

그 후 테스트가 끝날 때 롤백 해버림(반영을 아예 하지 않음)

-> DB의 실제 데이터에 반영이 되어있지 않음

-> 다음 테스트를 반복해서 실행할 수 있다!

기존처럼 지우는 코드를 넣지 않아도 됨.

11. 18번 라인 왼쪽을 클릭해 전체 test파일 실행

중복 회원 예외 및 회원가입 모두 정상적으로 실행!

정리

- @SpringBootTest : 스프링 컨테이너와 테스트를 함께 실행함.

- @Transactional : 테스트 케이스에 이 애노테이션이 있으면, 테스트 시작 전에 트랜잭션을 시작하고, 테스트 완료 후에 항상 롤백한다. 이렇게 하면 DB에 데이터가 남지 않으므로 다음 테스트에 영향을 주지 않는다. (테스트케이스에 붙었을 때만 이런식으로 작동한다)

단위 테스트 : 순수하게 자바 코드로 하면서 최소한의 단위로 하는 테스트

통합 테스트 : 디비, 스프링컨테이너까지 연동한 테스트

이때 순수한 단위 테스트가 훨씬 좋은 테스트일 확률이 높음.

그러므로 순수한 단위, 단위로 쪼개서 테스트를 잘 할 수 있도록 하고, 스프링 컨테이너 없이 테스트할 수 있도록 훈련해야함.

꼭 그런건 아니지만, 그럴 확률이 높다.

어쩔수 없이 컨테이너까지 올려야하는 상황이라면, 테스트 설계가 잘못 됐을 확률이 높음.

통합 테스트도 필요하긴 하나, 단위 테스트를 잘 만드는 것이 좋음!!!

다음 시간에는 스프링의 JDBC 템플릿으로 바꿔서 돌려볼 것임!