dev_eun

[Spring Boot 배포 with AWS ECS] ④ 가비아 도메인을 컨테이너로 연결 및 HTTPS 적용

_eun — Tue, 30 Jan 2024 14:50:43 +0900

Spring Boot 배포 with AWS ECS 시리즈

1. Dockerfile 작성, Docker 이미지 빌드, ECR 업로드

2. AWS 로드 밸런서(Load Balancer) 및 대상 그룹(Target Group) 설정

3. ECS 태스크 정의, 클러스터, 서비스, 태스크 설정

4. (현재글) 가비아 도메인을 컨테이너로 연결 및 HTTPS 적용

5. Github Action을 통해 CD 구축하기

안녕하세요.

AWS의 ECS 서비스를 처음 써보면서 삽질을 오래 해서 지친 사람입니다

저같은 사람들이 한 명쯤 있을까 하여 시리즈를 작성하게 되었습니다. 혹시 잘못된 부분이나 추가하면 좋을 내용 등 피드백이 있다면 코멘트 주시면 감사합니다.

이전 포스트에서 컨테이너를 배포하고 정상적으로 접속이 되는 것까지 확인했습니다.

이 컨테이너에 도메인을 붙여보려고 합니다.

저는 가비아에서 도메인을 구매했어요.

네임서버를 AWS Route53 NS 값로 설정

AWS Route53에 접속합니다. 호스팅 영역을 생성해주세요.

구매한 도메인 이름을 입력해주세요.

그리고 가비아에 접속해서 네임서버를 설정해줍니다.

Route53에 등록한 호스팅 영역의 "NS(Name Server)" 값 4개를 가비아에 적어줍니다. 값의 맨 끝에 있는 온점(".") 은 제거하고 입력해주세요.

AWS Route53 NS 값을

가비아 네임서버 설정

SSL 인증서 발급

https를 적용하려면 ssl 인증서가 필요하겠죠. AWS Certificate Manager(ACM)에 접속하여 인증서를 요청합니다.

퍼블릭 인증서로 요청하시고, 도메인 이름을 작성해줍니다.

서브도메인을 사용하실 예정이라면 *.domain.com 처럼 정규화된 이름도 추가해주세요.

인증서의 상세 정보에 들어가서, 도메인의 Route53에서 레코드 생성을 해줍니다.

이후 다시 Route53에 가보면, CNAME이 추가되어 있는 것을 확인해주세요. 조금 기다리면 인증서 상태가 성공으로 변경됩니다.

로드 밸러서 리스너 편집

이전에는 로드 밸런서의 리스너 규칙을 HTTP:80으로 설정해주었었죠.

이제 https로 변경해봅시다.

서비스와 연결되어 있는 로드밸런서의 상세 페이지로 가서 편집을 눌러주세요.

리스너 구성에서 HTTP를 HTTPS로 바꿔줍니다.

보안 리스너 설정 섹션에서 아까 발급 받은 인증서를 선택해주세요.

Route53의 레코드에 로드밸런스 DNS 추가

저는 구매한 도메인의 서브 도메인과 서비스를 연결할 거예요.

다시 Route53에 접속해서, 레코드를 생성해줍니다. 저는 제공해주는 기능인 마법사를 사용할게요.

단순 라우팅 선택합니다.

레코드 유형을 "A"로 설정해주세요. 여기에 이전에 만들었던 로드밸런서를 연결해줄 겁니다.

라우팅 대상을 하라는대로 [ALB - 서울 - 로드밸런서]로 잘 선택해주시면 돼요.

레코드 생성해줍니다.

모든 설정이 끝났다면 이제 https로 접속이 가능합니다.

[Spring Boot 배포 with AWS ECS] ③ ECS 태스크 정의, 클러스터, 서비스, 태스크 설정

_eun — Tue, 30 Jan 2024 14:49:11 +0900

Spring Boot 배포 with AWS ECS 시리즈

1. Dockerfile 작성, Docker 이미지 빌드, ECR 업로드

2. AWS 로드 밸런서(Load Balancer) 및 대상 그룹(Target Group) 설정

3. (현재글) ECS 태스크 정의, 클러스터, 서비스, 태스크 설정

4. 가비아 도메인을 컨테이너로 연결 및 HTTPS 적용

5. Github Action을 통해 CD 구축하기

안녕하세요.

AWS의 ECS 서비스를 처음 써보면서 삽질을 오래 해서 지친 사람입니다

앞 포스트에서 ECS 구성을 위한 준비를 마쳤습니다.

이제 드디어 컨테이너를 띄워볼 차례입니다.

Task Execution Role 설정

태스크 정의를 하기 전에, 이 태스크가 실행할 수 있도록 역할 권한을 부여해주어야 합니다.

AWS 콘솔에서 IAM 서비스의 "역할"로 접속합니다. 역할 생성을 눌러주세요.

사용 사례에서 Elastic Container Service를 선택하시고 사용 사례로 Elastic Container Service Task 선택하세요.

다음으로 가셔서 권한으로 AmazonECSTaskExecutionRolePolicy 를 선택해주시면 됩니다.

이름을 지정하시고 생성하시면, 바로 확인하실 수 있어요.

Task Definition

그 다음 Task Definition을 생성해줍니다.

태스크 정의는 애플리케이션을 구성하는 매개변수와 하나 이상의 컨테이너를 설명하는 JSON 형식의 텍스트 파일 입니다.
컨테이너 이미지, 리소스, 포트 등 태스트 실행을 위한 정보를 설정할 수 있어요. 태스크 정의가 되어야 이걸 참조해서 태스크 또는 서비스를 실행할 수 있습니다.

AWS 콘솔에서 ECS 서비스에 접속합니다. 왼쪽 메뉴에서 "태스크 정의"에 접속합니다.

태스크 정의 패밀리 이름을 입력해주세요.

인프라 요구 사항에서 Fargete 혹은 EC2 인스턴스 중 사용할 유형을 선택합니다. 저는 Fargete를 사용할 예정입니다.

그리고 태스크 실행 역할에서 "새 역할 생성"을 선택해주세요.

여기서 태스크 역할을 아까 생성해던 taskExecutionRole을 지정해주시면 됩니다.

컨테이너 섹션에서 정보를 입력합니다.

이름 : 본인이 알아볼 수 있는 이름

이미지 URI : ECR에 업로드했던 이미지의 세부 정보에서 확인할 수 있어요.

컨테이너 포트 : 서버 실행 시 설정해준 포트를 설정합니다. 저는 8080이에요.

Cluster 생성

AWS 콘솔에서 ECS 서비스에 접속합니다.

"클러스터 생성" 버튼을 통해 클러스터를 생성해줍니다.

클러스터 이름을 설정하고, 인프라에서 자신이 원하는 자원을 선택해주세요.

저는 Fargate를 선택하였습니다.

생성한 클러스터가 활성상태가 되면, 서비스를 생성해줍니다.

환경은 그대로 두시고, 배포 구성에서 패밀리와 서비스 이름을 설정해줍니다.

패밀리는 앞서 정의했던 태스크 정의 패밀리를 선택해줍니다.

네트워킹 섹션에서 VPC가 적절하게 선택되었는지 확인하시고, 보안 그룹을 설정해줍니다.

새 보안 그룹 생성을 선택하시고 이름과 설명을 작성해주세요.

인바운드 규칙에 사용자 지정 TCP, 포트를 8080(서버 실행 시 세팅한 값), 소스를 이전에 만들었던 보안 그룹을 선택해줍니다.

로드 밸런싱 섹션에서 ALB 유형을 선택합니다.

기존 로드 밸런서 사용 선택 후, 앞서 생성했던 로드 밸런서를 선택해줍니다.

리스너와 대상 그룹도 이전에 생성했던 것을 선택해줍니다.

이렇게 서비스를 생성할게요. 서비스가 생성되면 태스크가 자동으로 배포됩니다.

서비스 세부 상태에서 태스크의 상태를 확인할 수 있어요.

서비스가 안정 상태가 되었다면, 실제 접속해서 테스트할 수 있어요.

만들었던 로드밸런서의 DNS 이름으로 접속해보면, 정상적으로 동작하는 것을 확인할 수 있습니다.

[Spring Boot 배포 with AWS ECS] ② AWS 로드 밸런서(Load Balancer) 및 대상 그룹(Target Group) 설정

_eun — Tue, 30 Jan 2024 14:48:36 +0900

Spring Boot 배포 with AWS ECS 시리즈

1. Dockerfile 작성, Docker 이미지 빌드, ECR 업로드

2. (현재글) AWS 로드 밸런서(Load Balancer) 및 대상 그룹(Target Group) 설정

3. ECS 태스크 정의, 클러스터, 서비스, 태스크 설정

4. 가비아 도메인을 컨테이너로 연결 및 HTTPS 적용

5. Github Action을 통해 CD 구축하기

안녕하세요.

AWS의 ECS 서비스를 처음 써보면서 삽질을 오래 해서 지친 사람입니다

이 포스트는 아래 요소들이 필요합니다.

1. ECR에 업로드된 이미지 존재

이전 포스트에서 Docker 이미지를 생성하고 Repository에 push해주었습니다.

이 포스트에서는 본격적인 ECS 구성에 앞서,

VPC와 로드 밸런서(Load Balancer), 대상 그룹(Taret Group), 보안 그룹(Security Group)을 설정할 겁니다.

각 요소들이 필요한 이유를 먼저 간략하게 설명해보자면,

VPC는 Virtual Private Cloud로, AWS 의 인스턴스들이 논리적으로 격리된 공간입니다. 이 공간 안에서 컨테이너가 실행되어야 해요. 그리고 이 공간은 인터넷 게이트웨이를 보유하고 있습니다. 그래야 외부에서 접근할 수 있으니까요.

이 외부에서 접근하는 요청들을 처리하는 곳이 로드 밸런서입니다. 저희는 서버를 실행할 것이니까 Application Load Balancer(ALB)를 생성할 거예요. ALB는 HTTP 혹은 HTTPS 트래픽을 해당 VPC에 속한 여러 대상에 배포합니다.

로드 밸런서에는 여러 리스너를 설정합니다. 이 리스너들은 저희가 설정한 값에 일치하는 요청이 들어오면 수신하여 정해진 규칙에 따라 대상 그룹으로 라우팅해줍니다.

대상 그룹은 로드 밸러선의 리스너가 수신한 요청을 받는 대상이에요. 이 시리즈에서는 ECS를 통해 배포한 태스크입니다. 컨테이너라고 생각하시면 돼요.

마지막으로 보안 그룹은 들어오는 요청과 나가는 요청에 대해 제한할 수 있는, 보안을 위해 세팅하는 값들이에요. 어떠한 제한도 없이 모든 곳에서 요청을 받으면 해킹에 더 취약해질 것입니다. 이런 취약점을 보완하기 위해 설정하는 거예요. 어떤 ip 주소에서 어떠한 형태의 요청을 받을 건지 혹은 나가는 요청을 허락할 건지 구성합니다.

이제 진짜 설정해봅시다.

설정할 때는 항상 AWS 콘솔에서 "서울"로 지역이 세팅되어 있는지 확인해주세요.

VPC 설정

AWS 콘솔에서 VPC 서비스에 접속해주세요. 계정을 생성하면 기본 VPC가 존재할 것입니다. 저는 이 VPC를 사용할 예정입니다.

혹시 디폴트 VPC가 없으시다면, VPC 생성 버튼을 통해 생성해줍니다.

Security Group(보안 그룹) 설정

AWS 콘솔에서 EC2 서비스에 접속해주세요. 왼쪽 메뉴에 보안 그룹에 접속해주세요.

"보안 그룹 생성" 버튼을 클릭합니다.

지금 생성하는 보안 그룹은 다음에 생성할 로드 밸런서에 대한 보안 그룹입니다. 즉, 서버 API를 사용하는 클라이언트에 관련한 보안 그룹입니다.

보안 그룹 이름과 설명은 본인이 알아 볼 수 있도록 작성해주세요. 보안 그룹을 적용할 VPC를 선택해주세요.

인바운드 규칙을 설정해줍니다. 인바운드 규칙은 들어오는 요청에 대한 제약이에요. 저는 서버를 배포할 거고, HTTP 혹은 HTTPS로 접근하게 될 겁니다. 이에 따라서 설정해줄게요.

아웃바운드 규칙은 인바운드와 반대로 나가는 요청에 대한 제약입니다. 이건 기본 설정 그대로 두고 생성할게요.

Target Group(대상 그룹) 설정

AWS 콘솔에서 EC2 서비스에 접속해주세요. 왼쪽 메뉴에 대상 그룹에 접속해주세요.

"대상 그룹 생성" 버튼을 클릭합니다.

대상 유형으로 IP 주소를 선택하고, 대상 그룹 이름은 본인이 알아볼 수 있도록 설정해줍니다.

프로토콜과 포트는 각각 HTTP, 80으로 설정해줄게요. VPC는 앞서 생성했던 것 혹은 디폴트로 설정해주세요.

상태 검사 섹션에서는 서버가 정상적으로 동작한다는 것을 알 수 있는 값을 설정할 수 있습니다.

저는 전에 배포 후 태스크가 지속적으로 [실행 - 실행 - 실행 - 실패 - 종료 - 새로운 태스크 실행 - ...] 을 반복했었어요. 그 이유는 이 상태 검사에서 실패했기 때문이었습니다. 이유는 스프링 부트에서 아무런 구현도 하지 않고 초기 상태 그대로 배포해서 접속 시 404로 응답되었기 때문이에요. 저처럼 아무 구현없이 바로 배포하실 경우, 고급 상태 검사 설정의 성공 코드를 404로 변경해주시면 됩니다.

이런 경우가 아니라면 서버가 정상 상태 라는 것을 확인할 수 있는 path와 성공 코드로 설정해주세요. root path에 GET api가 있다면 그대로 두셔도 됩니다.

다음으로 넘어가면 대상 그룹 선택하는 페이지가 나옵니다.

아직 설정할 게 없으니 그대로 두고, 바로 "대상 그룹 생성" 해주시면 됩니다.

Load Balancer(로드 밸런서) 설정

AWS 콘솔에서 EC2 서비스에 접속해주세요. 왼쪽 메뉴에 로드 밸러서에 접속해주세요.

"로드 밸런서 생성" 버튼을 클릭합니다.

Application Load Balancer를 생성합니다.

로드 밸런서 이름을 작성합니다.

"네트워크 매핑"에서 VPC를 세팅해줍니다. 매핑에서는 서브넷을 선택해줍니다. 저는 가용 영역으로 모든 서브넷을 선택해주었어요.

"보안 그룹"에서 앞서 생성했던 보안 그룹을 설정해줍니다.

"리스너 및 라우팅"에서 리스너를 세팅해줍니다. 프로토콜과 포트를 각 HTTP, 80으로 맞춰주세요.

그리고 앞서 생성했던 대상 그룹을 선택합니다.

이렇게 되면 설정한 값에 맞는 요청이 들어오면 이 리스너가 해당 요청을 선택한 대상 그룹으로 라우팅해줍니다.

사진에는 없지만, 이전에 제가 생성했던 그룹인 "ecs-test-target"으로 선택해주었습니다.

HTTPS 선택하셨다면, 인증서를 추가로 선택해주어야 합니다.

하단의 "로드 밸런서 생성 버튼"을 통해 마쳐주세요.

로드 밸런서의 상태가 프로비저닝에서 활성 상태로 변경되면 완료입니다!

대상 그룹에서 연결된 로드 밸런서를 확인할 수 있어요.

이제 ECS 배포를 위해 미리 설정해야 하는 단계는 모두 끝났습니다!

[Spring Boot 배포 with AWS ECS] ① Dockerfile 작성, Docker 이미지 빌드, ECR 업로드

_eun — Tue, 30 Jan 2024 14:46:27 +0900

Spring Boot 배포 with AWS ECS 시리즈

1. (현재글) Dockerfile 작성, Docker 이미지 빌드, ECR 업로드

2. AWS 로드 밸런서(Load Balancer) 및 대상 그룹(Target Group) 설정

3. ECS 태스크 정의, 클러스터, 서비스, 태스크 설정

4. 가비아 도메인을 컨테이너로 연결 및 HTTPS 적용

5. Github Action을 통해 CD 구축하기

안녕하세요.

AWS의 ECS 서비스를 처음 써보면서 삽질을 오래 해서 지친 사람입니다

먼저 아래 요소들을 전제로 Docker 이미지 빌드 및 업로드 해보겠습니다.

1. 빌드가 가능한 상태의 Spring 애플리케이션 프로젝트가 존재

2. 자신의 컴퓨터에 Docker 설치 완료

3. AWS 계정 존재

참고로 저의 Docker 버전은 24.0.6 입니다.(2023.12.05.)

Dockerfile 작성

Dockerfile은 Docker Container를 어떻게 만들어야 하는지 작성해놓은 설명서같은 것입니다.

docker build 명령어를 입력하면, docker는 명령어의 루트 디렉토리에 있는 Dockerfile를 참고해서 이미지를 빌드합니다.

Dockerfile은 INSTRUCTION(지시어)와 arguments(인자)로 구성된 문장으로 구성되어 있습니다.

INSTRUCTION arguments

지시어는 대소문자를 구분하지 않지만, 대문자로 작성하는 것이 관례입니다.

Docker는 이 Dockerfile에 존재하는 지시어들을 작성된 순서대로 실행합니다.

저는 아래와 같이 작성하였습니다.

FROM eclipse-temurin:17-jdk-alpine
ARG JAR_FILE=/build/libs/*-SNAPSHOT.jar
COPY ${JAR_FILE} ecs-test.jar
ENTRYPOINT ["java","-jar","/ecs-test.jar"]

- FROM <이미지>:<태그>

FROM 지시어는 새로운 빌드 단계를 초기화하고, 뒤에 있을 지시어를 위해서 Base Image(Dockerfile에 지정된 부모 이미지가 없는 이미지)를 세팅합니다.

제가 작성한 인자는 eclipse-temurin의 17-jdk-alpine 태그를 가진 이미지입니다. Docker Hub에서 퍼블릭 이미지를 확인할 수 있습니다. (참고)

이 값은 각자 프로젝트의 JDK 버전에 맞춰서 세팅해주셔야 합니다.

- ARG <name>=<value>

ARG는 docker build 명령어를 통해서 사용자가 전달할 수 있는 변수를 정의합니다. 이 변수는 빌드타임에 사용할 수 있고, --build-arg <name>=<value>를 전달하지 않을 경우 디폴트 값으로 쓰입니다.

- COPY <src>=<dest>

파일로부터 새로운 파일이나 디렉토리를 복사해서, 컨테이너 내부 파일 시스템에서 path에 복사한 것들을 추가하는 지시어입니다.

이미 빌드되어 있는 파일의 경로인 ${JAR_FILE}을 컨테이너 내부에 ecs-test.jar로 복사합니다. 이름을 자유롭게 변경해주세요.

가 "/"로 끝날 경우 디렉토리로 인식되는 점을 주의해주세요.

- ENTRYPOINT ["java","-jar","/note-quest-api.jar"]

실행파일로 실행할 컨테이너를 구성할 수 있는 지시어입니다.

빌드된 jar 파일을 실제로 실행할 때 사용하는 명령어들을 리스트 형태로 ENTRYPOINT 지시어의 인수로 작성합니다.

docker run 커맨드를 사용하면 ENTRYPOINT로 작성했던 명령어를 실행하여 컨테이너를 구성합니다.

Docker Image 빌드

아래 명령어를 입력하여 이미지를 빌드해주세요.

$ docker build --platform linux/amd64 -t ecs-test .

그리고 아래 명령어를 사용하면 ecs-test 이름의 이미지가 생성된 것을 확인할 수 있습니다.

$ docker images

ECR에 이미지 업로드

이제 ECR에 이미지를 업로드 해봅시다.

ECR의 공식 명칭은 Elastic Container Registry로, AWS에서 제공하는 Docker Hub 같은 컨테이너 리포지토리입니다.

Public Registry 사용할 경우에는 무료이고, Private Registry를 사용할 경우 데이터 송신 크기에 따라 요금이 부과됩니다.

특별히 설정할 것은 없으니 어떠한 레지스트리든 하나 생성해주세요. 저는 private repository를 사용할 예정입니다.

생성 후 해당 레포지토리로 들어가보면 "푸시 명령 보기"이 있습니다.

여기서 이미지를 푸시할 수 있는 명령어를 확인할 수 있습니다.

이 명령어들을 실행하려면 먼저 AWS CLI가 설치되어 있고, 자격증명이 완료되어야 합니다. 관련해서 아래 글을 참조해주세요.

AWS CLI 자격증명하기

AWS CLI를 사용하기 위해선 최초 한 번 자격 증명을 해주어야 합니다. AWS CLI 설치 먼저, AWS CLI는 공식 홈페이지에서 다운 받아 설치할 수 있습니다. https://aws.amazon.com/ko/cli/ Command Line Interface - AWS CLI

ttalkisyrup.tistory.com

첫 번째 명령어는 본인의 자격증명을 통해 AWS 리포지토리에 로그인 하는 명령어입니다. 그대로 복사하셔서 터미널에서 실행해주세요.

두 번째 명령어는 아까 빌드 했으니 생략합니다.

세 번째는 태그를 붙이는 명령어입니다. 아래와 같이 구성되어 있으니, 각자 앞에서 설정한 이름대로 실행해주세요.

$ docker tag <이미지이름>:latest <ECR레포지토리>/<이미지이름>:latest

저는 ecs-test로 이미지 이름을 세팅하였으니 아래와 같은 명령어로 실행합니다.

$ docker tag ecs-test:latest <ECR레포지토리>/<이미지이름>:latest

마지막으로 네 번째 명령어를 실행합니다. 세 번째 명령어에서 가장 마지막 인자를 그대로 push해주시면 됩니다.

성공적으로 완료가 되었다면, ECR에서 업로드된 이미지를 확인하실 수 있습니다.

AWS CLI 자격증명하기

_eun — Tue, 30 Jan 2024 14:44:35 +0900

AWS CLI를 사용하기 위해선 최초 한 번 자격 증명을 해주어야 합니다.

AWS CLI 설치

먼저, AWS CLI는 공식 홈페이지에서 다운 받아 설치할 수 있습니다.

https://aws.amazon.com/ko/cli/

Command Line Interface - AWS CLI - AWS

aws-shell은 명령줄 셸 프로그램으로서, AWS 명령줄 인터페이스를 사용하는 새로운 사용자와 고급 사용자 모두에게 도움이 되는 편의 기능 및 생산성 기능을 제공합니다. 주요 기능은 다음과 같습

aws.amazon.com

각자 OS에 받게 설치해주세요.

Access Key 발급

그 후 AWS Management Console에 접속하여 액세스 키를 발급받습니다.

보안을 위해 root 계정이 아닌 IAM 계정을 생성하여 발급받는 것을 추천드립니다.

콘솔에서 상단 계정을 클릭 -> 보안 자격 증명 페이지로 접속합니다.

"액세스 키" 섹션에서 "액세스 키 만들기"를 통해 키를 생성해주세요.

생성 후 CSV 파일을 다운로드 하거나, 보안이 되는 곳에 access key와 secret key를 모두 복사하여 저장해주세요.

secret key는 지금만 접근 가능하고, 이후로는 볼 수 없습니다. 그리고 굉장히 중요한 값들이므로 유출되지 않도록 안전한 곳에 보관해주세요.

- Access Key Id : 자격증명 주체를 가리키는 ID

- Secret Key : 자격증명 주체가 본인임을 인증하는 Key

AWS CLI에서 자격 증명

cli를 사용할 곳의 터미널에 접속하여 아래 명령어를 입력합니다.

$ aws configure
AWS Access Key ID [None]: <Access Key Id>
AWS Secret Access Key [None]: <Secret Access Key>
Default region name [None]: 
Default output format [None]:

Access Key Id와 Secret Access Key를 요구하는 대로 입력합니다.

Default region과 Default ouput 은 입력하지 않으셔도 됩니다.

이 작업이 완료되면, 아래 명령어를 통해 저장된 파일의 값을 확인할 수 있습니다.

$ cat ~/.aws/credentials
[default]
aws_access_key_id = <Access Key Id>
aws_secret_access_key = <Secret Access Key>

이후 아래 명령어를 통해서 자격 증명이 정상적으로 활성화되었는지 확인할 수 있습니다.

$ aws sts get-caller-identity
{
    "UserId": "------",
    "Account": "------",
    "Arn": "arn:aws:iam::------:root"
}

AWS 관리 콘솔에서 나의 계정 ID와 같은 값을 가지는지 확인합니다.

SKT 2023 Prompter Day Seoul 후기

_eun — Tue, 26 Sep 2023 22:06:05 +0900

SKT에서 주관하는 Prompter day 해커톤에 참가했다.
서류 - 예선 - 본선으로 구성되었고, 상금이 어마어마한 해커톤이었다.
OpenAI와 함께 하는 해커톤이라 그런지 규모가 꽤 컸다. 그리고 꼭 openAI의 서비스들을 이용한 서비스를 개발해야 한다는 점이 특이점이었다.
이제 막 LLM을 사용해야 했던 인턴십을 끝낸 상태라 꽤나 익숙하게 프로젝트를 진행할 수 있을 것 같아, 서류 마감 일주일 전에 부랴부랴 대학 선배들을 모아서 팀을 구성했다.

심사 프로세스

1. 서류

프로젝트 제안서와 MVP 링크, 3분 소개 영상을 제출해야 했다.
학교에서 함께 일할 땐 아무것도 모르는 학부생이었는데, 이제 다들 직장인이다보니 뭐든 알아서 척척 해서 놀라웠다.
아이디어 회의 좀 하고, 우리 자율주행로봇 만들던 팀이었던 거 감안해서 하드웨어가 가미된 아이디어로 확정되었다.
다들 바빠서 만날 시간이 부족해서 하루 일과 끝나고 밤 10시부터 만나 다음날 새벽 6시까지 작업하고 순댓국 먹고 헤어졌다.
서류 준비를 하루 컷으로... 했지만 왜인지? 서류를 합격했고, 예선을 보게 되었다.

2. 예선

예선에서는 발표와 Q&A 시간을 모두 합쳐 10분 이내로 완료해야 했다.
발표 시간을 굉장히 타이트하게 잡았고, Q&A로 다 풀어낸다는 전략으로 준비했다.

근데 이 날 다른 사이드 프로젝트의 일정이 있어서 중간에 왔다 갔다 하느라 정신이 좀 없었다. 스터디룸을 빌려서 발표를 해야 했는데, 내가 스크립트를 다 완료하지 못한채로 발표 15분 전까지 수정을 하였다. 하하...
게다가 긴장했는지 배가 슬슬 아파서 예민한 상태이기도 했고.

하지만 기우였는지 다행히도 심사위원분들이 재밌게 봐주셨고, 우리 팀의 에너지가 잘 전달된 것 같았다.
사실 이 예선도 거의 하루컷 했기에... 상위 40팀에 뽑힌 것만해도 정말 많이 왔다고 생각하고 있었다.
그런데 본선에도 합격한 것이... 이왜진?

3. 본선

예선 합격 메일이 온 것이 월요일이고, 본선이 토요일부터 시작이라 준비 시간은 많지 않았다. 팀원들이 직장인이라 시간이 많이 없었고, 더군다나 하드웨어 만들고 테스트해야 하는데 내가 할 수 없어서 미리 개발을 진행하는 것 자체가 힘들었다.
그래도 각자 자리에서 할 수 있는 것들을 준비하며 주말을 기다렸다.

본선은 주말에 무박 2일로 강남에서 진행되었다. 기업에서 운영하는 대규모 해커톤은 처음이었는데, 확실히 학생 레벨에서 준비하는 것과 완전히 달랐다.
skt 답게 네트워크 장비를 빵빵하게 준비해주셨고, 예외 상황에 대비를 정말 많이 준비한 것처럼 보였다.
프로세스와 정책들이 잘 정비되어 있고, 멘토 분들도 신경을 많이 써주셔서 정말 좋은 경험이었다. 행사 진행에 있어서도 많이 배우게 되었다.

토요일에는 개발을 계속 진행하면 되었는데, 중간중간 연사님들의 발표 세션이 있었다.
세션들이 모두 흥미로웠는데, 메모를 안해놓아서 다 휘발돼버렸다 ㅠㅠ
그 전날 밤을 새고 온 터이기도 하고, 하드웨어 세팅에 개발에 어쩌고 저쩌고 정신이 나가버릴 것 같았다. 그래서 그런지 세션 때도 집중 잘 못하고 실시간으로 '오 좋은 말이다' 이렇게 생각만 하고 적지 않았었는데, 왜 그랬니..

일요일에는 오전에 모든 팀 발표하고 시상식하고 해커톤이 종료되었다.
오전에 팀 발표를 듣는데, 정말 대단하다는 말밖에 나오지 않았다.
사실 우리 팀은 본선에 오기 전까지 대학생 수준의 해커톤을 예상하고 있었고 즐기자는 마인드로 크게 힘을 주지 않고 있던 터라, 본선에서 많은 것을 준비하기에는 무리가 있었다.
하지만 다른 팀들은 달랐다. 정말 진심으로 해커톤에 임하고 있다는 게 느껴졌고, 정말정말정말 준비를 많이 했다는 걸 깨달았다.
사실 발표와 완성도를 보면 본선 기간 내에 만들 수 있는 퀄리티가 절대 아니긴 하다. 이미 많이 개발이 된 상태로 본선까지 왔고, 본선에서는 아마 멘토 분들에게 피드백 받은 부분들을 수정하거나 QA를 하면서 이슈 대응하거나 했겠지.
하지만 그럼에도 정말 감동을 많이 받았다.

나는 해커톤 서류 접수 바로 직전에 LLM을 이용한 서비스를 기획/개발 하는 인턴십을 마쳤다. 그래서 인턴십에서 AI를 활용한 아이디어를 팀원들과 정말 많이 논의해보고, 다른 팀들의 아이디어를 듣기도 많이 들었다. 그 중 수많은 아이디어들이 이미 존재하는 아이디어, 식상한 아이디어 라고 치부되었고 빛을 보지 못했었다. 그런데 정말 신기하게도 이 해커톤 본선에서 인턴 때 논의 했던 아이디어가 20팀 중 절반이 될 정도로 정말 많았다.
그걸 보면서 '해커톤은 어차피 아이디어 싸움'이라고 생각했던 게 좀 부끄러워졌다. 아이디어가 식상하더라도(사실 신박한 아이디어라는 건 없다는 것을 알고 있다), 어떻게 구현하냐에 따라서 프로덕트가 정말 많이 달라질 수 있다는 것을 알았다. 이 부분에서 기획자와 디자이너의 역할이 크다는 것을 다시금 깨닫게 되었다. 모든 분야의 사람이 기획력이라는 것을 어느정도 갖추어야 한다고 생각은 하지만 그건 조력일 뿐, 확실히 전문가가 만든 프로덕트는 대단했다.

그래서 우리 팀은 수상하지 못했지만 아쉬운 점이 없었다. 다른 팀들에 비해 완성도나 노력 면에서 너무나도 부족한 걸 알고 있었다.
오히려 수상하지 못한 다른 팀들이 아쉬울 것 같았다. 그 정도로 다들 너무 노력을 많이 했고, 좋은 제품을 만들었다.

내년에 다시 이 해커톤이 열린다면, 그 땐 정말 최선을 다 해서 나도 같이 경쟁해보고 싶다.

느낀 것들

좋았던 점

1. 주최 측의 적극적인 지원이 너무 감사했다

우리 팀이 하드웨어를 만들어야 해서 작업 공간이 필요했다.
납땜을 해야 하는데 밀폐된 공간에서 하면 안되니까 외부에 공간을 마련해주시도 했고, 3D 프린터 때문에 자리가 추가적으로 필요했는데 구석에 따로 또 마련해주셨다.
참여자분들이 불편하지 않고 최대한 개발에만 집중할 수 있도록 신경써주시는데 내가 다 감동했다. 보통은 이럴 때마다 안된다거나 그냥 여기서 하세요~ 하고 알아서 가서 다 세팅해야 하는 상황이 대부분이었는데, 이렇게 배려해주시니 정말 감사할 따름이었다.
게다가 유일한 하드웨어 팀이다 보니, 관심을 많이 가져주셔서 신기했다(그 관심에 부응한 결과는 내지 못했지만 )
그래도 멘토 분들이 응원도 많이 해주시고, 힘나는 말들 많이 해주셔서 끝까지 갈 수 있지 않았을까.

열심히 납질 중

제작을 위해 따로 마련해주신 공간

2. 뛰어난 사람들이 한 곳에 모여 있어서 나오는 그 에너지

사람들의 열정과 성과에 감동했다.
최근 몇 개월간 개발에 대한 회의감에 휩싸여 있었다. 내가 개발로 뭘 할 수 없을 거라는 생각에 자신감은 물론 열정과 의욕 모두 상실한 상태였다. 그래서 이 해커톤도 정말 편한 사람들과 즐겁게 그냥 놀고 싶어서 참여를 했었다.
이런 상태로 훌륭한 사람들을 만나니 굉장한 충격을 받았다. 20팀이 모두 발표를 5분씩 진행했고, 중간중간 딜레이도 있다고 생각하면 총 2시간 동안 발표만 듣고 있었어야 했는데, 전혀 지루하지 않을 정도였다. 벌써 끝났나? 싶을 정도로 성과가 대단했고 존경스러웠다.

여튼 이런 사람들 사이에 있으니 내가 자극을 받았다. 이번엔 나도 최선을 다 했기 때문에 결과가 어찌됐든 긍정적인 영향을 받지 않았나 싶다. 이렇게 부족한 시간에도 다들 열심히하고, 또 그렇게 하면 좋은 성과를 낼 수 있구나 라는 생각이 들었다.
이런 분위기와 열정에 나도 앞으로 나아갈 수 있는 힘을 다시 얻은 것 같다.

3. 필요한 것을 어떻게 딱 알고 제공해주신 굿즈들

굿즈로 슬리퍼, 후드티, 에코백, 스티거 가 제공되었다. 슬리퍼를 주는 해커톤은 처음이었다.
슬리퍼가 진짜 필요한데 사기도 애매하고 챙기기도 애매한 그런 건데, 딱 제공해주시니 센스가
후드티도 요긴하게 잘 썼고, 스티커는 예쁘게 잘 활용할 예정이다 :D

4. 오랜만에 해커톤 나가서 그냥 신남

오래만에 대학 사람들 만나서, 그 때 그랬던 것처럼 다시 함께 프로젝트를 하니까 그냥 너무 즐거웠다. 요즘 이 사람들이랑 만나서 술마시고 노는 것밖에 하지 않아서 몰랐는데, 정말 대단한 사람들이구나 새삼 다시 느꼈다.
학부생 때도 대단하다고 생각했는데 직장인 되니까 더 멋있어졌다.
내가 정말 현명하다고 생각하고 존경하는 몇 안되는 사람 중 2명과 함께 해서 더더욱 좋았던 시간.
그래서 정말 이 해커톤 그냥 나 혼자 너무 신나서 우리 팀 스티커도 만들고 제품 스티커도 만들어서 갔다.
대학교 해커톤 느낌 생각하고 만들어 간 거였는데 막상 가보니 분위기가 너무 진지해서 잘 활용하지는 못했지만, 우리 팀 분위기 살리는 데는 한 몫했을 지도 ㅋㅋ큐ㅠㅠ
폴라로이드 가져가서 사진도 찍고 그냥 잘 즐겼다는 것 하나로도 만족한다

아쉬웠던 점

1. 다른 팀들과 의 교류가 부족했다

끝나고 나니 더 아쉬운 점이다. 이렇게 훌륭한 사람들이 한 곳에 모일 기회가 많이 없으니, 대화를 조금이라도 할 수 있었으면 더 좋았을 것 같다.
사실 한 공간에 있으니까 그냥 가서 말 걸면 되긴 한데, 다들 예민한 상태이고 한국인 특성상 명문없이 가서 말 거는게 좀 힘든 분위기였다.
이런 오프라인 행사에서는 꼭 교류할 수 있는 세션이 있었으면 좋겠다. 인맥도 쌓을 수 있고 인사이트도 얻을 수 있어서 서로 윈윈인데, 너무 아쉽다.
그 사람들... 친해지고 싶다.... 어떻게 구현했는지, 뭐 하는 사람들인지 한 팀씩 다 가서 커피챗하고 싶다.....

2. 이틀 동안 만의 해커톤은 아니었던 것 같다

다른 팀들의 발표를 보면 구현 정도랑 완성도가 말도 안된다. 아무리 MVP가 있었다고 해도, 저걸 이틀 안에 하는 건 거의 불가능에 가깝다고 생각한다. 그래서 좀 더 아쉬움이 있었는데, 우리 팀이 좀 더 잘 준비할 걸 이라는 점과 출발점과 도착점이 모두 다 동일했으면 더 재밌지 않았을까 싶은 생각이다.
해커톤을 2박 3일로 잡고, 첫 날 주제를 공개하고 다 같이 출발하면 그 부족한 시간 내에서 어떤 재밌는 일이 있을지 궁금하기도 하다.

3. 제대로된 AI 프로덕트를 만들지 못했다

이건 개인적으로 아쉬운 부분이다.
웹 개발자가 나 혼자 이다보니 시간이 많이 부족했다. 본선 전까지는 무조건 가능하다고 생각했었는데, 역시 무리더라.. 그게 온전히 집중할 수 있고, 정신 상태가 멀쩡하면 가능했을 수도 있지만, 오픈된 장소이고 기획이 계속해서 바뀔 수 있는 상황을 고려하지 못했다.
게다가 이번에 하는 김에 배우고 싶었던 Java+Spring을 사용해보려고 했으나, 처음 해보는 것이다 보니 리서칭하는데에 너무 많은 시간이 소요가 되었다. 이러다가는 본선에 가서 이슈 대응을 아예 하지 못할 것 같아서 nest.js로 변경하였다. 처음부터 js 사용했으면 시간이 좀 더 많았을 텐데 너무 아쉬웠다. 이거 하느라고 덕분에 본선 전날 밤을 새서 본선 내내 제정신 아니었다. 근데 밤 안샜으면 아예 완성 못했을지도...
그리고 직전에 프롬프터 데이와 목적이 동일한 인턴십을 진행했었는데, 그 때 LLM 관련 아이디어 회의도 많이 하고, 기획을 엎어도 보고, openAI api도 꽤 써보고, 프롬프트 엔지니어링 기법에 대해서도 리서칭을 많이 한 상태였다. 그래서 적용해보고 싶은 것들이 많았는데, 웹 개발이 완료되지 않으니.. 완성도를 높이는데 시간을 할애하지 못해서 제품의 한계가 명확했다. 내가 서비스 개발을 먼저 다 끝내놓고 프롬프트 퀄리티를 올리는 쪽에 더 신경을 썼으면 좋았을 텐데.. 팀 전체적으로 LLM에 대한 이해도가 떨어지다 보니 이 부분을 놓친게 가장 아쉽다.

그래도 다른 팀들의 프로덕트를 보면서 인사이트를 많이 얻었다. 직접 AGI를 활용한 서비스를 만들어 보고도 싶고, 시도하고 있는 회사에서 일해보고도 싶다.

이렇게 길다면 길고 짧다면 짧았던 해커톤이 마무리되었다.
개발에 대한 회의감이 든 이후로 블로그 포스팅도 멈추게 되었는데, 이걸 깰만큼 기억하고 싶고 값진 경험이었다.
대기업이 괜히 대기업이 아닌지 자본 냄새가 많이 나는... 해커톤이었지만, 그렇기 때문에 훌륭한 사람들이 많이 모였고, 좋은 퀄리티의 프로덕트가 많이 개발되었고, 참가자 분들도 훨씬 질좋은 경험을 하지 않았나 싶다.

내년에도 혹시 이런 해커톤이 열린다면, 그 때는 정말 전력을 다 해서 무조건 참여하고 싶다.

혼자 무박 3일하고 너무 힘들었던 이후 이야기

원래 토요일에 아이유 팬콘서트 가기로 했는데, 본선에 진출한 덕분에 그 표는 친구에게 양보하고 일요일 표를 구했다.

해커톤 마무리 되고 나오는데 진짜 헤롱거려서 미치는 줄 알았다. 해커톤 중간중간 좀 자긴 했지만, 그것만으로 3일을 버티기는 택도 없었다. 콘서트장 근처 카페에 가서 좀 자야지 생각했지만, 다른 사람들 역시 일찍 와서 기다리느라 자리가 하나도 없었다.

결국 티켓 수령하고 공원 길가 벤치 한가운데서 가방 끌어안고 잤다. 덥고 창피하고 그런거 다 필요없고 너무 힘들었다. 그토록 고대하던 팬콘서트였지만? 다 포기하고 그냥 집에 가서 자고 싶은 마음 뿐이었다.

하지만 언제 또 아이유를 보겠냐는 생각에... 꾹 참고 콘서트가서 소리 내내 지르다가 집에 와서 기절했다.

17시간 자고 일어났는데 정상적으로 몸이 돌아오지 않아서 저녁 먹고 또 바로 기절했다.

앞으로는... 미리미리 준비 철저하게 해서 수명 앞당겨 쓰는 일 없도록 하자.

결론은 해커톤 끝나고 아이유 팬콘서트 갔다는 이야기.

개발자 노션 이력서&포트폴리오 만들기

_eun — Thu, 23 Dec 2021 04:07:02 +0900

이번에 노션 포트폴리오를 v2.0으로 업데이트했습니다!

그리고 이전에 썼던 예비개발자 노션 포트폴리오 만들기 글이 그냥 아무생각 없이 작성한 건데 조회수가 꽤 높더라구요.

예비개발자 노션 포트폴리오 만들기

미루고 미뤄두었던 포트폴리오 초안을 드디어 완성했다. 여러 개발자 포트폴리오를 서칭하고 참고했지만 가장 도움을 많이 받았던 건 tngusmiso님의 노션 포트폴리오이다. [Notion] 노션으로 모바일

programmer-eun.tistory.com

이걸 보면서 많은 사람들이 같은 고민을 하고 있구나 라는 생각이 들었습니다.

그래서 이번에 업데이트한 내용도 함께 공유하려고 합니다.

먼저, 저의 v2.0 이력서와 포트폴리오입니다.

정말 부끄럽지만 도움이 되시는 분이 있길 바라면서 공유합니다☺️

이은성 | 꾸준히 성장하는 개발자

‍♀️ Front-End Developer

eunseong.notion.site

이은성 | portfolio

✨ RESUME

eunseong.notion.site

일단 가장 큰 변화는 제 포지션을 확실히 정한 것입니다.

이전 포폴에서 보면 제가 어떤 일을 하는지 명확하게 기재되어 있지 않았어요.

언뜻 보기에는 프론트엔드 개발자같았지만, 안드로이드 개발자 같기도 했었죠.

방황의 시간을 거치고 드디어 프론트엔드로 정착을 했기 때문에, 이런 애매한 부분을 없애기 위해 Introduce 부분에 Frontend Develeper라고 명시하게 되었습니다.

두 번째는, Stacks 입니다.

이전에는 C++, Java, JS 가 함께 있었어요. 이 셋의 공통점이라고 하면 잘 모르겠습니다 ㅎㅎ

저는 JS 개발자이기 때문에 js 위주로 작성하였어요. 그리고 다룰 수 있는 협업 툴도 함께 작성하였습니다.

정말 잘 하는 거 아니면 적지 않는게 맞다고 하셔서 과감하게 다 뺐습니다. 그리고 이렇게 하는 게 자신을 더 잘 나타내 줄 수 있어서 맞는 것 같습니다.

세 번째는 Project와 Experience 부분입니다.

저 UI가 예쁘긴 한데, 해당 내용을 확인하려면 한 뎁스를 더 들어가야 해서 조금 불편하다는 생각이 들었습니다.

그래서 한 눈에 간략히 볼 수 있도록 수정하였어요.

그리고 Github 링크를 넣고, 프로젝트 상세 내용은 포트폴리오로 링크하였습니다.

이력서에 있는 상세 내용은 아직 마음에 들지 않는데, 뭘 적을지 생각을 해내지 못해서 개략적인 내용만 작성하였습니다.

보통은 수치적인 내용으로 적으라고들 하시는데, 수치적으로 나타낼 수 있는 게 뭐가 있을까요..?

이번에 이력서를 대거 수정하면서 가장 신경썼던 부분은, 제가 정말 열심히 했지만 제 직무와 관련이 없는 것들을 거르는 것이었습니다.

그래서 저에게 큰 부분을 차지하고 있었던 NOA 활동을 거의 제외하게 되었습니다.

안드로이드 개발을 맡아서 했었기 때문에, 제 이력서에 있어봤자 쓸모가 없어요.

수상 경력도 삭제하였어요. 대부분 안드로이드 개발로 수상하게 된거였기 때문이죠

정말 마음이 아프지만... 제 소중한 프로젝트를 떠나보내게 되었습니다...

그런데 이력서 다이어트를 하면서 저의 직무에 조금 더 초점을 맞출 수 있게 되었어요.

이렇게 하다보면 지금 내가 뭐가 부족한지, 그래서 앞으로 뭘 해야 하는지 보이더라구요.

부족한 글 보러와주셔서 감사하고,

이 글을 보신 모든 분들 승승장구 하시길 바라요

[Crew Space] 프로젝트 구조 설계

_eun — Thu, 23 Dec 2021 03:33:19 +0900

Directory Structure

처음에 저는 React와 React Native를 유사한 기술이라 생각하고 덤볐었는데, 반성하고 있습니다

애초에 구동되는 환경이 다른데, 어떻게 유사하다고 생각할 수 있었을까요? 하하

그냥 문법만 유사한 거지 완전히 다른 생태계였습니다.

그래서 디렉토리 구조도 다시 한 번 고민해보게 되었습니다.

많은 리서칭 후에 나온 결과는 아래와 같습니다.

디렉토리 구조

react app과 크게 차이가 나는 것같지는 않긴한데..

가장 다른 점은 screens와 navigation입니다.

page 대신 screen, router대신 navigation으로 세팅하였습니다.

Navigation Structure

React Native에서는 router역할을 하는 것이 navigation입니다.

RN에서는 web의 site-map처럼 navigation 설계도 진행하더군요.

마침 저도 뷰가 너무 많아서 어디서부터 처리해야 할 지 모르겠는 참이어서 한 번 설계를 해보았습니다.

네비게이션 구조

Authentication과 Content 로 두 개를 먼저 구분하였습니다. 이 둘은 겹치지 않기 때문에 SwitchNavigation으로 구성하였습니다.

Content는 StackNavigation으로 사용자가 들어갈 모든 스크린이 있습니다.

그 안에 Main은 BottomTabNavigation으로 하단에 탭이 있는 스크린입니다.

BottomTabNavigation 위로 스크린이 덮어지는 경우도 있기 때문에, nested 하게 구성하였습니다.

~~이거 때문에 발생한 문제가 몇 가지 있는데 그건 나중에..ㅠㅠ~~

별 거 아닌 것 같지만, 이거 설계하느라고 머리 뽀개지는 줄 알았습니다ㅠㅠ

web처럼 path가 따로 있는 것도 아니고, 모든 스크린이 연결되다 보니 어떻게 설계를 해야 할 지 처음에는 막막했어요.

플로우 차트를 보면서 겨우겨우 설계해 냈습니다.

그래도 한 번 하고 나니 내가 이 프로젝트를 제어하고 있구나 라는 느낌도 들고, 확실히 서비스에 대한 이해도가 올라간 것 같았어요.

아마 기능이 더 추가가 되면 뷰도 추가가 될 테고, 그럼 더 복잡해질텐데 추가할 때마다 더 나은 방법이 없을까 생각해봐야겠습니다

[Crew Space] 모바일 앱, 뭘로 개발할까?

_eun — Thu, 23 Dec 2021 03:06:34 +0900

크루 스페이스 서비스 플랫폼은 "모바일"입니다.

모바일 앱을 만드는 방법은 크게 총 3가지입니다.

Native
WebView로 감싸기
Hybrid

저는 javascript 개발자이기 때문에 1번은 선택지에 있지 않았습니다.
새로 배울 마음도 없지만 배운다고 해도 러닝 커브가 너무 높고, 크루 스페이스 특성상 무조건 android&ios 모두 한 번에 출시해야 했기 때문에 저 혼자로는 역부족이기 때문이죠!

2번과 3번 중 어느 것을 고를 지는 꽤 오래 고민했습니다.

제가 고민하던 포인트는 아래 2가지 였습니다.

네이티브의 제스처
가장 비중을 뒀던 부분입니다. 웹뷰로 감쌀 경우 네이티브에 맞는 제스처 동작이나 액션을 구현하기가 까다롭다는 것입니다. 예를 들면 아이폰의 경우 화면이 전환될 때 오른쪽에서 왼쪽으로 새로운 화면이 나오고, 뒤로갈 때는 사용자가 왼쪽에서 오른쪽으로 화면을 끄는 제스처를 하게 되는데 웹으로 구현하기는 까다롭기도 하고 시간도 없습니다.
모바일 앱인데 모바일스럽지 못하고 조금 뚝딱거리는 느낌이 나는 걸 개인적으로 정말 좋아하지 않습니다..
네이티브 기능 사용
네이티브의 기능을 많이 사용하는 경우는 웹뷰로 구현하기에는 까다로움

크루 스페이스는 네이티브 기능을 거의 사용하지 않아서 2번은 제외였습니다. 하지만 1번이 너무... 너무... 개인적으로 너무 싫어서 결국 3번을 선택하게 되었습니다.

그럼 또 고민이 되는 게 있는데, expo vs RN 입니다.

이전 프로젝트에서 지도 sdk를 사용해야 할 때가 있었는데, expo에서 제공하지 않았고 써드파티를 사용해야 했기 때문에 이 점이 상당히 불편했었어요.. 그래서 사전 조사를 많이 하다가 벨로퍼트 님의 이 글을 보고 마음을 다잡았습니다.

네이티브 앱 → 리액트 네이티브 앱 전환 그리고 1년 후

라프텔에서 네이티브 앱으로 구현되어 있던 환경을 리액트 네이티브 앱으로 전환 한 지 1년이 되었습니다. 그동안의 배움에 대해 공유합니다.

velog.io

과제 제출은 Expo도 포함해서 냈지만... RN으로 도전하기로 했습니다!

해커톤이 끝나고

그냥 웹뷰로 할 걸 후회가 되었습니다

가장 큰 이유는 제가 웹 개발을 더 좋아한다는 점입니다. 원래도 알고 있었지만 더 확실히 알게 되어버렸죠!

모바일은 집이 정말 좋은데 붙박이여서 제가 마음대로 꾸밀 수 없는 느낌이고,

웹은 집은 좀 허름하지만 가구를 제 마음대로 바꾸거나 배치할 수 있는 느낌이었습니다.

그리고 두 번째 이유는 역시나 배포가 너무 오래 걸린다는 점입니다.

크루 스페이스가 런칭을 하게 된다면, 초기에는 수정 사항도 굉장히 많이 생기고 빠르게 테스트하는 것도 필요할텐데 배포에 너무 많은 에너지를 쏟기가 힘들 것 같았습니다ㅠㅠ

그래서 다른 서비스들의 레퍼런스를 많이 찾아봤는데, 전체적으로 웹뷰를 사용하는 게 아니라 필요한 부분만 한 스크린당 한 웹뷰로 사용을 하더군요!

그래서 저도 부분적으로 웹뷰를 사용하기로 결정하였습니다.

작은 부분부터 웹뷰로 전환을 시작하려고 합니다!

[Next.js] 시작하기③ Routing

_eun — Thu, 23 Dec 2021 02:32:34 +0900

Dynamic Routes

/posts/:id 경로의 post를 라우팅하고 싶을 경우

pages/posts/[id].ts 파일을 생성
getStaticPaths()가 id 값들의 리스트를 반환
리스트 원소의 타입은 object이다. 그리고 이 객체는 반드시 params안에 key가 id인 객체를 가지고 있어야 한다.
```
 return fileNames.map(fileName => {
   return {
     params: {
       id: fileName.replace(/\.md$/, '')
     }
   }
 })
```
filename([id].js)의 id와 같은 key여야 한다.
getStaticProps()가 id에 필요한 데이터들을 fetch

`getStaticPaths()`

Fallback

fallback: false일 경우 404 페이지를 생성한다.
true일 경우는 getStaticProps()의 행동이 달라진다.

getSTaticPaths()로 반환된 경로가 빌드 타임에 HTML로 빌드된다.
빌드 타임에 생성되지 않는 경로는 404 페이지를 생성하지 않는다.
대신, Next.js는 이러한 경로에 대한 첫 번째 요청에서 페이지의 fallback을 제공한다.
백그라운드에서 Next.js는 요청된 경로를 정적으로 생성한다.

모든 Routes 잡기

... 를 사용하면 된다.

pages/posts/[...id].js 일 경우

/posts/a
/posts/a/b
/posts/a/b/c

모두 가능하다.

이렇게 하려면 getStaticPaths()에서 key id에 꼭 이렇게 줘야 한다.

return [
  {
    params: {
      // list로
      id: ['a', 'b', 'c']
    }
  }
  //...
]

Router

Next.js에서 라우터에 접근하려면 useRouter hook을 사용할 수 있다.

404 Page

pages/404.js 를 생성하여 커스텀 404 페이지를 만들 수 있다.

API Routes

API Routes 생성하기

pages/api 디렉토리에 이런 형식을 가지고 있으면 lambda 처럼 serverless function을 배포할 수 있다.

// req = HTTP incoming message, res = HTTP server response
export default function handler(req, res) {
  res.status(200).json({ text: 'Hello' })
}