ch-yang

Whatever 프로젝트 회고 - 7 주차

ch-yang — Mon, 25 Sep 2023 20:44:28 +0900

이번주는 좋은 것과 나쁜 것이 무엇이 있었나요?

지난 7주간 안해봤던 작업들을 많이 해봐서 좋았습니다. 이번에 AWS 서버도 많이 만져봤고, OAuth2 로그인 기능도 처음해보고, 프론트와 백엔드 페이지가 나뉘어 있는 환경에서 작업을 하면서 많이 배웠습니다. 프로젝트 시작 전 다른 파트를 맡는 팀원과 기능 정의와 와이어 프레임을 구성해본 것도 좋았어서, 다른 프로젝트를 진행 할 때도 도움이 될 것 같습니다.

이번주 진행했던 개발 내용은 무엇이었나요?

피드 삭제
피드 문자열 및 필터 검색

가장 고민을 했던 부분은 무엇이었나요?

기록 안해두면 잊어버릴 것 같은 내용들이 많이 있어서 어떻게 기록을 남기면 좋을 지 고민 중입니다. 요즘 옵시디언이 많이 보여서 사용해보고 싶습니다.

아쉬운 부분을 개선하기 위해서 필요한 것은 무엇인가요?

어려웠던 부분과 아쉬웠던 부분은 기록으로 남기고, 관련해서 더 공부하려고 합니다.

다음주는 어떻게 보낼 예정인가요?

수정 기능이 남았는데 완료하고, readme를 작성하려고 합니다.
리팩토링과 테스트 추가를 앞으로 진행 할 것 같습니다.

Whatever 프로젝트 회고 - 6 주차

ch-yang — Mon, 18 Sep 2023 19:27:50 +0900

이번주는 좋은 것과 나쁜 것이 무엇이 있었나요?

저번 주 위클리 이후 슥슥 해결되었습니다. 문제가 많았던 세션 쿠키 문제는 서브 도메인을 맞추는 방법으로 해결이 되었습니다. 다음부터 서로 다른 도메인간의 쿠키 유지는 안되는 것으로 생각하겠습니다.

MockMvc 테스트에서 모든 경로에 403 인증 에러 나는 문제도 해결 했습니다.

피드나 댓글 삭제, 수정 그리고 필터 및 검색 API가 구현되지 않았습니다.

이번주 진행했던 개발 내용은 무엇이었나요?

피드 및 댓글 작성, 조회 기능
서브 도메인을 사용해서 프론트/백 도메인 통합
이미지 업로드
사용자 닉네임 랜덤 생성

가장 고민을 했던 부분은 무엇이었나요?

Swagger 없이 Post만으로 테스트하는 것이 좀 비효율적인 것 같습니다. Spring REST Docs와 Swagger를 둘 다 적용하는 경우도 있던데 다음에 참고해봐야겠습니다.

피드 쪽 패키지에 너무 많은 클래스가 생기고 있어 분할해야 할 필요성을 느끼고 있습니다. 패키지 간 순환 의존을 하지 않도록 하려다 보니 더 쪼개지 못하는 것 같습니다.

Feed 패키지와 FeedLike는 패키지를 분리하도록 계획을 잡았는데, 피드 목록과 상세 내용을 반환하는 기능에서 피드 정보와 좋아요 정보를 같이 반환하려하니 *서비스 레이어에서는 Feed → FeedLike 방향으로 의존이 생기고, *도메인 레이어에서는 FeedLike → Feed 방향으로 의존하다보니 같은 패키지로 묶이게 되었습니다.

아쉬운 부분을 개선하기 위해서 필요한 것은 무엇인가요?

해봤다고 생각한 기능에서도 고민할 것이 많았습니다. 아키텍처와 같은 부분은 계속해서 공부해야겠습니다.

다음주는 어떻게 보낼 예정인가요?

남은 기능을 구현하겠습니다.

Whatever 프로젝트 회고 - 5 주차

ch-yang — Mon, 11 Sep 2023 19:21:27 +0900

이번주는 좋은 것과 나쁜 것이 무엇이 있었나요?

로그인 후 세션 쿠키가 사라지는 것을 해결할 수 없었습니다. 서로 다른 도메인에서 OAuth2 + 세션 로그인 구현 관련해서 인터넷에서 찾아볼 수 있었던 내용들은 다 적용해봐도 쿠키가 사라졌습니다. 일찍 안되는 것으로 판단했어야 했는데 늦었습니다. 서브 도메인을 맞추는 방법으로 진행해야 할 것 같습니다.

SecurityConfig에서 petmitAll()로 열어둔 경로가 MockMvc 테스트에서 403에러가 발생했었습니다. MockMvc 테스트에서는 SecurityConfig 빈이 적용 안되는 것을 알았습니다.

이번주 진행했던 개발 내용은 무엇이었나요?

OAuth2 로그인 기능을 구현했으나 정상 동작하지는 않았습니다.
피드와 댓글 작성 기능을 구현했지만 피드의 이미지 업로드에서 문제가 생겼습니다.
피드 조회 기능은 완성했으나 데이터를 넣지 못했습니다.
https 서버 구축

가장 고민을 했던 부분은 무엇이었나요?

Controller에서 이미지 파일을 받아 S3로 업로드하는 API를 테스트하고 Spring REST Docs로 문서 제작하는 것이 어려웠습니다. Controller 부터 잘못 작성한 것 같아서 수정하려고 합니다.

구현하는 것마다 문제가 생기고 시간이 촉박하니 Spring REST Docs를 없애고 Swagger를 다시 적용할까 고민했었습니다. Swagger에 OAuth2 적용할 시간도 많이 걸릴 것 같아서 그냥 진행했습니다.

아쉬운 부분을 개선하기 위해서 필요한 것은 무엇인가요?

로그인 기능과 피드 작성 기능에서 문제가 생겨서 다른 기능들이 제대로 진행되지 않았습니다.

다음주는 어떻게 보낼 예정인가요?

동작에 문제가 있는 기능 먼저 정상 작동하도록 해야겠습니다.

Whatever 프로젝트 회고 - 4 주차

ch-yang — Mon, 4 Sep 2023 17:14:11 +0900

이번주는 좋은 것과 나쁜 것이 무엇이 있었나요?

이전에 Swagger를 사용했을 때는 API 문서와 엔드포인트 테스트 UI는 기본적으로 제공했었는데, Spring REST Docs는 각 API 엔드포인트마다 테스트 코드와 API 문서 포맷 파일을 작성해줘야 하는 번거로움이 있었습니다.

Spring REST Docs 적용하면서 문제가 많았었는데 지금은 안정적으로 사용할 수 있습니다. 적용하고 나니 Swagger보다는 API 문서 제공 용으로는 더 깔끔하고 좋은 것 같습니다.

이번주 진행했던 개발 내용은 무엇이었나요?

"찾아주세요", "댕글냥글" 피드 및 목록 조회 기능을 구현했습니다.
Spring REST Docs로 API 문서를 생성했습니다.
GitHub Actions로 CI/CD를 구축했습니다.

가장 고민을 했던 부분은 무엇이었나요?

API 문서 작성 방법과 문서 포맷은 어떻게 해야할 지 고민이 있었는데, 컬리 GitHub 페이지에서 레퍼런스를 찾아 도움이 많이 되었습니다.

아직도 Controller Mapping URL 정하는 것이 어렵습니다. 어느정도 URL이 쌓이면 조언을 구하고 싶습니다.

아쉬운 부분을 개선하기 위해서 필요한 것은 무엇인가요?

조회 기능이 마무리 되었어야 했는데 다 못 끝낸 것이 아쉽습니다. 이제부터는 이전에 구현해봤던 내용들이여서 금방 구현 할 수 있을 것 같습니다.

다음주는 어떻게 보낼 예정인가요?

조회 기능 마무리
로그인 구현
로그인 후 가능한 조회, 글 작성, 수정 내용 구현

Whatever 프로젝트 회고 - 3 주차

ch-yang — Mon, 28 Aug 2023 16:11:08 +0900

이번주는 좋은 것과 나쁜 것이 무엇이 있었나요?

와이어 프레임 작성이 끝났다고 생각했었는데 더 자세하게 설계가 되어야 한다는 것을 알았습니다. 시작할 때 구현해보자 했던 기능들이 많았다는 게 이해되고 있습니다.

이번주 진행했던 개발 내용은 무엇이었나요?

와이어 프레임에서 세부 내용들을 더 정리했습니다.
Repository를 공개로 전환했습니다.
ERD 설계를 완료 했습니다.
로그인 없이 가능한 조회 기능부터 개발을 진행 중입니다.

가장 고민을 했던 부분은 무엇이었나요?

"찾아주세요" 피드와 "댕글냥글" 피드 관련 Entity 설계에서 고민이 있었습니다. "찾아주세요" 피드에는 "동물 종류", "품종" 등 과 같은 추가적인 필드가 필요하고, 피드의 "제목"이나 "내용" 같이 공통적인 부분은 "댕글냥글" 피드와 기능을 같이 쓰고자 했습니다. 그러면서도 나중에 필요한 피드 카테고리가 추가될 때 확장하기 어렵지 않도록 하고 싶었습니다.

고민했던 구조는 3가지였습니다.

첫번째는 "Feed" Entity 하나만 두고 필요한 필드들을 모두 넣어 관리하는 하는 것이였습니다. 구현하기는 이 방법이 쉽기는 할 것 같은데, 확장에도 문제가 있고 피드가 주 컨텐츠인 프로젝트인데 구조를 조금 더 신경쓰고 싶었습니다.

두번째는 공통적인 필드는 "Feed" Entity에 두고, 필드에 추상 클래스인 "FeedDetail" 필드를 두어 공통적이지 않은 필드는 "FeedDetail"을 상속해서 구현하는 구조였습니다. 이렇게 되면 "Feed"이 방법으로 진행을 하려다보니, JSON으로 변환을 한다던가, 이 필드가 어떤 카테고리의 필드인지 확인하는 것 등 괜히 복잡해진다는 느낌이 들었습니다.

세번째는 공통적인 필드는 추상 클래스인 "Feed"에 두고, 이 피드를 상속해서 공통적이지 않은 필드를 각 "CommunityFeed"와 "LostPetFeed"가 갖도록하는 구조였습니다. 나중에 카테고리가 늘면 "Feed"를 상속하는 Entity 클래스를 추가하면 될 것이고, 코드 정리도 이 방법이 간편할 것 같았습니다. 이게 가장 기본적인 구조인 것 같은데, 가장 나중에 생각이 났습니다. 현재 도메인 중심으로 패키지를 구분을 하고 있는데, 지금은 "Feed" 패키지에 같이 있는 "CommunityFeed"와 "LostPetFeed"의 패키지를 나누는 것은 조금 더 생각해 봐야겠습니다.

아쉬운 부분을 개선하기 위해서 필요한 것은 무엇인가요?

이전에도 블로그와 같은 구조의 프로젝트를 개인적으로 진행한 적이 있었는데, 그 때는 카테고리와 포스트만 나누어도 되는 구조였습니다. 카테고리가 늘면 카테고리에 하나 추가하면 되었었는데, 이번에는 카테고리가 다르면 피드(포스트)의 구성 자체도 다른 경우라서 고민이 많았고 진행 중 회귀하는 경우도 있었습니다. 이 부분은 경험이 부족했던 것 같습니다.

다음주는 어떻게 보낼 예정인가요?

로그인 없이 가능한 조회 기능 구현
로그인 구현 (여기까지가 목표)
로그인 후 가능한 조회, 글 작성, 수정 내용 구현

인텔리제이 remote : Repository not found 에러 해결

ch-yang — Wed, 23 Aug 2023 21:24:41 +0900

내 경우에는 인텔이제이의 Git 기능을 사용해서 GitHub의 Organization의 Repository에 push를 하는 과정에서 "remote : Repository not found" 에러가 발생했다.

CLI에서 git push를 할 때는 원격 저장소에 push가 문제 없이 잘 되는데, 인텔리제이를 통해서 push 할 때만 이 현상이 발생하니 인텔리제이가 뭔가 잘못하고 있는 것 같았다.

인텔리제이가 push 할 때 만들고 있는 명령어는 다음과 같았다.

git -c credential.helper= -c core.quotepath=false -c log.showSignature=false push --progress --porcelain origin refs/heads/master:master

이 명령을 CLI에서 직접 수행해보니 GitHub 로그인을 요구했다. 찾아보니 저 "credential.helper="에 value가 할당되지 않는 것이 문제였다. 저 할당도 해주지 않은 옵션을 어떻게 빼기만 하면 될 것 같았다.

검색해보니 나와 같은 케이스는 아니지만, 이거다 싶은 해결 방법을 발견했다.

참고: Intellij에서 git push가 안되는 경우 (tistory.com)

아래의 그림 처럼 "Use credential helper"만 체크해주면 된다.

이 설정 후 다시 push를 해보니 정상적으로 push가 되었다. 생성되는 git 명령어에서도 "credential.helper="가 빠진 것을 확인 할 수 있었다.

git -c core.quotepath=false -c log.showSignature=false push --progress --porcelain origin refs/heads/master:master

찾다보니 토큰으로 로그인해서 해결도 하던데, 더 쉬운 이 방법을 사용하는 것이 편하겠다.

끝!

[Spring] OAuth2 로그인 구현하기 2 - 로그인 과정 디버깅

ch-yang — Tue, 22 Aug 2023 15:42:44 +0900

aboutSpringSecurity/oauth 에서 테스트 프로젝트와 같이 볼 수 있습니다.

용어

Roles

공식 문서 section-1.1에서는 아래 4개의 역할을 정의한다.

Resource Owner
- 리소스 소유자는 사용자로, 자신의 계정 데이터에 대한 접근 권한을 부여할 수 있는 개체입니다.
Resource Server
- 리소스 서버는 리소스 소유자의 데이터를 호스팅하는 서버로, 보호된 리소스에 대한 접근을 처리합니다.
Authorization Server
- 인증 서버는 사용자의 신원을 확인하고, 클라이언트에게 토큰을 발급하는 역할을 합니다.
- 이 토큰은 클라이언트가 리소스 서버에 접근할 수 있는 권한을 부여합니다.
- 아래 설명 중 나오는 Provider와 같습니다. (google, kakao, naver 등)
Client
- 클라이언트는 리소스 소유자의 데이터에 접근을 요청하는 애플리케이션입니다.
- 웹 서비스, 모바일 앱 등이 될 수 있습니다.

OAuth2 로그인 과정

Authorization Code Grant 방식

여러 Grant 방식이 있지만, 여기서는 안전하고 흔히 사용하는 방식인 Authorization Code Grant만 설명합니다.

Authorization Code Grant는 크게 3가지 단계로 진행 된다.

나중에 이 단계를 따라 Spring OAuth2 디버깅을 진행합니다.

Authorization Endpoint에 code 요청
- Client는 User를 설정 정보와 함께 Authorization Endpoint로 리디렉션한다.
- Provider는 로그인 페이지로 리디렉션하여 사용자의 신원을 인증하고 권한을 요청한다.
- 사용자가 로그인하고 권한을 승인하면, Provider는 URL에 인증 코드를 포함하여 Client로 리디렉션한다.
Token Endpoint에 Token 요청
- Client는 받은 인증 코드와 Client ID/Secret 등을 포함하여 Token Endpoint에 Token을 요청한다.
- access_token, refresh_token 등을 발급 받고, OIDC 프로토콜을 사용한다면 id_token도 발급 받는다.
UserInfo Endpoint에 UserInfo 요청
- Client는 Access Token으로 UserInfo Endpoint에 사용자 정보를 요청한다.
- id_token(JWT 포맷)을 발급 받았다면, 이 Endpoint에 접근할 필요없이 id_token에서 정보를 꺼낸다.
인증 객체 생성
- UserInfo로부터 인증 객체를 생성한다.

sequenceDiagram
    participant User as "User"
    participant Client as "Client"
    participant AuthorizationServer as "Authorization Server"
    participant ResourceServer as "Resource Server"

    User->>Client: 1. Open App
    Client->>AuthorizationServer: 2. Redirect to Auth Server for Login
    AuthorizationServer->>User: 3. Provide Login Page
    User->>AuthorizationServer: 4. Enter Credentials and Login
    AuthorizationServer->>Client: 5. Redirect with Authorization Code
    Client->>AuthorizationServer: 6. Request Access Token (with Code)
    AuthorizationServer->>Client: 7. Return Access Token
    Client->>ResourceServer: 8. Access Resource with Token
    ResourceServer-->>Client: 9. Return Resource

설정

Well-known 엔드포인트

출처: Google OpenID Coonect 문서

OpenID Connect 프로토콜은 사용자를 인증하고 토큰, 사용자 정보, 공개 키를 포함한 리소스를 요청하기 위해 여러 엔드포인트를 사용해야 합니다.

구현을 간소화하고 유연성을 높이기 위해 OpenID Connect는 승인, 토큰, 취소, 사용자 정보, 공개 키 엔드포인트의 URI를 포함하여 OpenID Connect 제공업체의 구성에 대한 세부정보를 제공하는 잘 알려진 위치에서 발견된 JSON 문서인 '검색 문서'를 사용할 수 있도록 허용합니다.

Well-known 엔드포인트를 활용하면, 애플리케이션 설정을 간소화 할 수 있습니다.

Kakao의 Well-known JSON

{
  "issuer": "https://kauth.kakao.com",
  "authorization_endpoint": "https://kauth.kakao.com/oauth/authorize",
  "token_endpoint": "https://kauth.kakao.com/oauth/token",
  "userinfo_endpoint": "https://kapi.kakao.com/v1/oidc/userinfo",
  "jwks_uri": "https://kauth.kakao.com/.well-known/jwks.json",
  "token_endpoint_auth_methods_supported": ["client_secret_post"],
  "subject_types_supported": ["public"],
  "id_token_signing_alg_values_supported": ["RS256"],
  "request_uri_parameter_supported": false,
  "response_types_supported": ["code"],
  "response_modes_supported": ["query"],
  "grant_types_supported": ["authorization_code", "refresh_token"],
  "code_challenge_methods_supported": ["S256"],
  "claims_supported": [
    "iss",
    "aud",
    "sub",
    "auth_time",
    "exp",
    "iat",
    "nonce",
    "nickname",
    "picture",
    "email"
  ]
}

간소화 된 application.yml 설정

spring:
  security:
    oauth2:
      client:
        registration:
          kakao:
#            client-id: application-dev.yml
#            client-secret: application-dev.yml
            redirect-uri: http://localhost:8080/login/oauth2/code/kakao
            authorization-grant-type: authorization_code
            scope: openid,profile_nickname,profile_image,account_email
        provider:
          kakao:
            # "issuer-uri"만 있으면 모든 Endpoint를 알아서 가져온다.
            # https://kauth.kakao.com/.well-known/openid-configuration
            issuer-uri: https://kauth.kakao.com

[Well-known 엔드포인트 포맷 및 예시]

well-known 엔드포인트 포맷이 정해져 있으므로 issuer-uri만 설정하면 다음 경로에서 메타 데이터를 수집합니다.

포맷 : "https://{issuer-uri}/.well-known/openid-configuration"
Kakao : https://kauth.kakao.com/.well-known/openid-configuration
Google : https://accounts.google.com/.well-known/openid-configuration
naver : 네이버는 OIDC를 지원하지 하지 않아, 엔드포인트가 없음

Spring OAuth2 로그인 과정 디버깅

1단계: Authorization Endpoint에 code 요청

이 로그인 버튼은 "http://localhost:8080/oauth2/authorization/kakao" 경로로 링크되어 있고, Code 요청 URI를 자동으로 생성하여 리디렉션합니다.

[OAuth2AuthorizationRequestRedirectFilter]

이 클래스에서 Code를 요청하는 URI를 생성하여 Authorization Endpoint로 리디렉션하는 과정을 볼 수 있다.

OAuth2AuthorizationRequestRedirectFilter#sendRedirectForAuthorization 에 디버깅 포인트 설정

redirectUri가 "/login/oauth2/code/kakao"로 설정되어 있다. Provider는 이 경로로 발급한 code를 전달한다.

# 생성된 URI
https://kauth.kakao.com/oauth/authorize?response_type=code&client_id=bae9aa27df816d042ef63a7e710aba74&scope=openid%20profile_nickname%20profile_image%20account_email&state=CmJpTmvZ_wrAkYSC9AMXHpeB-gJ9FZ2gtkhu41rrcGs%3D&redirect_uri=http://localhost:8080/login/oauth2/code/kakao&nonce=wlBvOV6TpnEldBtNsTJl_Qh5QKyKPzlBclussGPk5pk

2단계: Token Endpoint에 Token 요청

[OAuth2LoginAuthenticationFilter]

OAuth2LoginAuthenticationFilter#attemptAuthentication에 디버깅 포인트

사용자가 로그인하고 권한을 승인한 후, Provider가 발급한 code를 확인
이 메서드에서 code를 token으로 바로 교환한다.
Token 교환을 확인하려면 authenticate() 메서드만 찾아 따라 들어가면 된다.

AuthenticationManager
  -> OidcAuthorizationCodeAuthenticationProvider 
    -> DefaultAuthorizationCodeTokenResponseClient

[DefaultAuthorizationCodeTokenResponseClient]

여기서 Code를 Token으로 교환하는 Request와 Response를 확인할 수 있다.
request와 Response의 body를 확인

3단계: UserInfo Endpoint에 UserInfo 요청

OpenID Connect 프로토콜을 사용하기 때문에 UserInfo Endpoint에 요청하지 않고, ID Token에서 User 정보를 꺼냅니다.

[OidcAuthorizationCodeAuthenticationProvider]

위에서 토큰 교환을 진행한 OidcAuthorizationCodeAuthenticationProvider 클래스의 authenticate 메서드를 따라
OidcAuthorizationCodeAuthenticationProvider#createOidcToken에 디버깅 포인트를 찍으면
JWT로부터 OidcIdToken을 생성하는 과정을 확인 할 수 있습니다.

4단계: 인증 객체 생성

위에서 생성한 OidcIdToken을 기반으로 OAuth2User(OidcUser)를 만들어 Authentication의 principal 속성에 저장한다.

Reference

정수원 - 스프링 시큐리티 OAuth2

Whatever 프로젝트 회고 - 2 주차

ch-yang — Mon, 21 Aug 2023 17:58:06 +0900

이번주는 좋은 것과 나쁜 것이 무엇이 있었나요?

와이어 프레임을 같이 작성하며 팀원들과 대화를 나눈 것이 좋았습니다. 기능 뿐만 아니라 어떤 API가 나와야 할 지 정리가 되었습니다.
카카오 로그인 기능을 구현해봤습니다. 스프링 OAuth2 라이브러리가 잘 되어 있어 로그인 관련해서 직접 작성할 코드는 많이 없었지만, OAuth2 인증 플로우를 디버깅하며 이해하는 과정이 좋았습니다. 이 과정이 웹 서버, 웹 애플리케이션 서버가 나뉘어진 환경에서도 유효한지는 잘 모르겠습니다.

이번주 진행했던 개발 내용은 무엇이었나요?

댕냥이 홈커밍(PetComing)의 레포지토리를 생성했습니다.
프로젝트에 필요한 Dependencies를 정했고, 프로젝트를 생성했습니다.
ERD를 설계 중입니다. 필요한 Entity는 정했고 각 Entity에 들어갈 필드를 추가하고 있습니다.

가장 고민을 했던 부분은 무엇이었나요?

다른 테이블들은 이전에 했던 프로젝트에 비슷한 테이블이 있었지만, Post에 붙을 Tag 관련해서는 ERD를 어떻게 설계해야 할 지 고민을 했습니다. PostInfo 테이블의 필드에 하나의 String으로 태그를 갖고 가는 것이 처음 설계였는데, 태그 검색을 하기 쉽게 TagItem 테이블과 PostTag 테이블을 추가했습니다.

API 문서 구성은 "Swagger"와 "Spring Rest Docs" 중에 어떤 라이브러리를 사용할지 고민했습니다. 테스트 코드가 강제되고, 운영 코드에도 침투하지 않는 "Spring Rest Docs" 쓰기로 했습니다. 무엇보다 이전에 "Swagger"를 써본 적이 있어서 안 써본 "Spring Rest Docs"를 써보고 싶었습니다.

아쉬운 부분을 개선하기 위해서 필요한 것은 무엇인가요?

ERD 설계하면서 이게 맞는지 자신이 없어서 레퍼런스를 많이 찾아봤습니다. 다음에는 찾는 시간을 줄일 수 있도록 각 상황에 맞는 레퍼런스를 모아서 정리하고, ERD 설계 방법을 좀 더 공부해야 할 것 같습니다.

다음주는 어떻게 보낼 예정인가요?

ERD 설계 완성: 오늘 내일 중으로 되지 않을까 싶습니다.
API 구현 시작: 어떤 기능을 먼저 개발할 지 순서를 정하고 시작할 예정입니다.

[Spring] OAuth2 로그인 구현하기 1 - 카카오 애플리케이션 등록

ch-yang — Wed, 16 Aug 2023 11:54:20 +0900

Kakao 애플리케이션 추가하기

https://developers.kakao.com/console/app

사업자명 적으래서 당황했는데 찾아보니 다들 막 적고 시작하더라

Web 플랫폼 등록

로컬테스트만 하려는데 사이트 도메인부터 준비해야하나 했지만 그냥 localhost 주소 작성해도 된다.

Web 플랫폼을 등록하고 나면 아래 Redirect URI도 설정하는 링크가 생긴다.

상태를 활성화하고, 카카오는 OpenID Connect도 지원하니 이것도 활성화 했다.

Redirect URI는 default Redirect URI를 적었다.

동의 항목 설정

닉네임, 프로필 사진, email을 설정했다.

Client Secret 발급

보안 > Client Secret

"Implicit Grant" 방식도 지원을 하는지 Client Secret이 필수가 아니였다. "Authorization Code Grant" 방식을 사용하기 위해서 Client Secret도 발급하고 활성화했다.

끝!

Whatever 프로젝트 회고 - 1 주차

ch-yang — Mon, 14 Aug 2023 17:26:13 +0900

2023월 8월 7일 ~ 8월 13일

첫번 째 Weekly 회의

모든 팀의 역할 구성이 같지는 않은 것 같은데, 우리 팀은 FE(Frontend) 1명, PD(Product Design) 1명, BE(Backend) 1명 총 3인으로 구성되었고, 나는 여기에 BE로 참여하게 되었다.

첫 모임에서는 짧은 자기 소개를 통해 서로를 알게 되었고, 멘토 분들이 앞으로 6 주간 프로젝트를 어떻게 진행해야 하는지 설명해주셨다. 그리고 팀원들과 친해지기 위한 아이스브레이킹 시간도 있었다. 노래 제목과 가수 맞추기 게임이 기억이 나는데, 대부분 아는 노래임에도 제목과 가수가 기억이 안나 많이 맞추지 못했지만 재밌었다.

회의가 종료된 후, 팀원들과 짧게 아이디어 회의와 잡담 시간을 보내고, 주제 선정을 마무리 하기 위한 다음 미팅 시간을 정한 뒤에 마무리 했다.

팀 미팅

금요일 저녁 주제 선정을 마무리 하기 위해 다시 모였다. 여러 후보 중 "유기 동물 공고 안내 사이트"를 주제로 선정했고 입양 후기 포스팅과 지역 별 알림 등의 추가 기능을 더해 프로젝트를 진행하기로 했다.

유저 플로우도 작성 했는데 FigJam이라는 협업 툴을 처음 써봤다. 유빈님(FE), 수진님(PD)은 많이 써보셨는지 뚝딱 뚝딱 잘하셨다.

회고

이전까지 진행했던 프로젝트들에서는 기능만 결정하고 바로 막개발을 했었는데, 이번 “Whatever 프로젝트 코스”에서는 현직 멘토 분들의 가이드를 받아, 실무적인 개발 과정과 다른 파트의 팀원과의 협업 방식을 경험할 수 있을 것 같아 기대가 된다.