"이렇게나 간편하고 편하게 디자인을 코드로 구현할 수 있는 방법이 있다고?"

ai 사용에 대해 아직 좀 회의적이지만 이 기술은 너무나 인상적이어서 사용해보고 싶었다.

세미나가 종료된 후 바로 claude code에 figma mcp server를 연결해봤다.

claude cli를 활용하니 연결은 간단하게 됐다.

claude code와 figma mcp server 연결 방법

먼저 claude code에 figma mcp server를 등록해야 한다.

claude code에 figma mcp server 등록

터미널을 열고 다음 명령어를 입력하면 전체 프로젝트에서 사용할 수 있는 figma mcp server 등록이 된다. (claude cli가 깔려 있어야 한다.)

claude mcp add --scope user --transport http figma https://mcp.figma.com/mcp

만약 현재 프로젝트에서만 figma mcp를 사용하고 싶다면 다음과 같이 입력하면 된다.

claude mcp add --transport http figma https://mcp.figma.com/mcp

이렇게 명령어를 작성하면 등록이 됐다는 메세지가 나올 것이다.

figma mcp server 인증

그 다음 figma mcp server 인증을 해야 한다. 인증은 claude code 통해 진행할 수 있다.

claude cli를 실행하고 /mcp 를 입력하면 현재 연결된 mcp 서버를 볼 수 있다.

필자는 이미 인증을 해서 connected라고 나오는데 인증을 안 했다면 아마 unauthenticated라고 나올 것이다. 그러면 figma 정보를 조회하고 인증을 진행하면 된다.

인증은 브라우저를 통해서 진행되기 때문에 간편했다.

동의 및 액세스 허용을 누르면 인증이 완료된다.

figma mcp로 figma 디자인을 코드로 구현하기

먼저 디자인을 구현하고 싶은 브라우저 figma 페이지에 접속해서 URL을 복사한다. 그리고 claude code에 그 디자인을 본인이 원하는 라이브러리 코드로 구현해달라고 말하면 된다.

위 사진은 figma에 간단하게 만들어봤던 경제 서비스 와이어프레임이다.

figma mcp server 테스트를 위해 이 figma 디자인을 활용했다.

claude code에게 "내가 보여준 figma 페이지의 디자인을 옮겨와서 next.js로 구현해줘 {figma 주소}" 라고 명령을 했더니 알아서 디자인을 가져오고 Next.js 코드로 구현해줬다.

현재 figma 무료 플랜이라 총 7개의 페이지인데 4개 밖에 가져오지 못했다.

하지만 claude code는 똑똑해서 나머지 3개 페이지는 메타데이터를 가져와 코드로 구현해준다고 했다.

그 결과 완전히 똑같진 않더라도 어느정도 비슷한 UI를 구현해냈다.

와우. 디자인만 괜찮은 게 아니라 사용자와의 상호작용도 잘 구현해냈다.

그저 페이지 UI만 따라 구현한게 아니라 페이지 간의 연결성을 고려하고 상호작용 요소를 배치한 것이다.

간단하게 figma mcp server를 사용해봤는데 결과가 만족스러워서 claude code MAX 플랜을 구매하고 싶다는 충동이 마구 생겨났다. (현재 가장 싼 Pro 플랜을 사용 중이다😭)

ai를 잘만 사용하면 생산성을 말도 안 되게 높일 수 있을 것 같다는 걸 직접 체험한 순간이었다. 기술의 발전이 정말 무섭도록 빠른 것 같다.

궁금했다. 왜 searchParams를 문자열로 변환해 다시 URLSearchParams()에 넣는지.

그냥 searchParams를 바로 사용하면 안 되나 싶었다.

하지만 URLSearchParams를 생성한 이유는 따로 있었다.

바로 Next.js의 useSearchParams 반환값은 read-only인 URLSearchParams 이기 때문이다.

Next.js의 useSearchParams()

useSearchParams()에 관한 Next.js 공식 문서: https://nextjs.org/docs/app/api-reference/functions/use-search-params

사진에서 보이는 것처럼 useSearchParams의 반환값은 read-only 버전의 URLSearchParams라고 한다.

실제로 console.log에 useSearchParams 반환값과 URLSearchParams로 생성한 값을 순서대로 찍으면 다음과 같이 표시된다.

결국 searchParams의 값을 변경해서 사용하려면 다른 방법을 찾아야한다는 뜻이다.

URLSearchParams 생성자

값을 변경해서 사용하는 방법 중 하나는 URLSearchParams 생성자에 기존 searchParams를 전달해 사용하는 것이다.

URLSearchParams의 생성자를 활용하는 방법은 MDN 공식문서에 다음과 같이 나와있다.

https://developer.mozilla.org/ko/docs/Web/API/URLSearchParams/URLSearchParams

이 중 두 번째 방법인 문자열 리터럴을 전달하는 방법을 통해 기존 Next.js의 read-only인 searchParams 값을 변경 가능한 값으로 변환하여 사용할 수 있다.

코드를 다시 살펴보자.

const searchParams = useSearchParams()
console.log(searchParams.toString()) // 'foo=1&bar=2'
const params = new URLSearchParams(searchParams.toString())

searchParams의 toString() 메서드는 search parameter 값을 ?를 제외한 문자열 형태로 반환한다.

이 값을 URLSearchParams의 초깃값으로 전달해주면 같은 URLSearchParams지만 값이 변경 가능한 객체가 생성된다.

다음은 useSearchParams()에 관한 Next.js 공식 문서 활용 예제이다.

이를 통해 공식 문서에서도 searchParams를 변경하는 방법으로 URLSearchParams 객체를 재생성하는 방법을 사용하고 있는 걸 알 수 있다.

declare module은 타입스크립트 문법으로, 특정 module에 선언된 타입을 추가하거나 수정해서 사용하기 위해 사용한다.

다음은 금요일에 작성했던 코드의 일부다.

declare module 'next-auth' {
  interface Session {
    user: {
      id: string
    } & DefaultSession['user']
  }
}

next-auth의 Session 타입을 커스텀 해야하는 일이 있었다.

기존 Session 타입의 user 속성에 id 속성을 추가해야 했던 것이다.

이를 위해 기존에 선언된 Session 타입을 중복해서 선언함으로써 원래 갖고 있던 속성들을 그대로 가져왔고, user 속성에 id 속성을 추가했다. (interface 타입의 선언 병합 개념)

자세히 보면 user 속성에 DefaultSession['user']를 확장 선언했는데, 그 이유는 user 속성을 커스텀할 경우 기존 user 속성이 전부 날아가기 때문이다.

이로써 원래 갖고 있던 속성을 그대로 가져오면서 id값을 추가할 수 있었다.

결과적으로 Session 타입은 user에 id 속성이 추가되어 다음과 같이 코드에 적용된다.

interface Session {
  user?: {
    id: string
    name?: string | null
    email?: string | null
    image?: string | null
  }
  expires: ISODateString
}

declare module을 사용해야 하는 이유

문득 '꼭 declare module을 써야할까? 커스텀 타입을 만들어 사용하면 안 될까?'라는 궁금증이 생겼다.

이에 대해 gemini에게 물어보니 declare module을 쓰는 게 더 좋다는 답변을 얻었다.

커스텀 타입을 만들어서 사용할 때

커스텀 타입을 만든다고 하면 이렇게 만들 수 있을 것이다.

interface MySession extends Session {
  user: {
    id: string
  } & DefaultSession['user']
}

만약 커스텀 타입을 만들어 사용할 경우, useSession() 훅이 반환한 값에서 user의 id 값에 접근하려고 하면 에러가 발생한다.

const { data: session, status } = useSession()
session?.user.id // 에러 발생
const mySession = session as MySession
mySession?.user.id // 정상 작동

이럴 때 타입 캐스팅을 활용해서 MySession 으로 타입을 바꿔줘야 하는데, 만약 session을 사용하는 컴포넌트가 늘어나면 불필요한 타입 캐스팅 코드가 반복된다.

이런 반복을 없애기 위해 declare module을 사용한다.

declare module의 장점

declare module을 사용하면 next-auth 모듈 내의 타입을 수정하기 때문에 typescript 컴파일러가 이를 인식하고, id값에 접근해도 오류를 내지 않는다.

반복되는 코드를 줄여주고 코드 자동완성 기능까지 제공하는 편리한 기능이다.

이 문제를 해결하기 위해 gemini에게 해답을 물어보니 애니메이션 최적화가 필요하다고 답하며

리플로우 현상과 GPU 연산을 이해해야 한다고 말했다.

리플로우(reflow)

리플로우란 화면 레이아웃을 재조정하는 과정을 말한다.

애니메이션이나 레이아웃 조정이 필요할 때, 브라우저는 화면 요소의 크기와 위치를 다시 계산하여 렌더링하는 리플로우를 거친다.

이 과정에서 재조정이 필요한 요소 말고도 DOM 트리의 상위 요소들을 함께 다시 계산해버린다.

리플로우는 CPU 연산을 사용하기 때문에 복잡한 js 연산이 필요한 페이지일 경우 애니메이션이나 레이아웃 조정이 버벅이는 현상이 발생한다.

대표적으로 width, height, left, top, padding 속성을 바꿀 때 이 현상이 일어난다.

나는 기존 코드에서 padding 속성을 바꾸는 애니메이션을 구현했고, 그 결과 화면이 버벅이며 렌더링 속도가 느려졌다.

이에 대한 해답으로 gemini는 padding를 바꾸는 대신 scale을 조정하는 방법을 알려줬다.

GPU 연산

출처: Mong dev blog

scale 속성 변경은 GPU를 사용하는 연산이기 때문에 기존 CPU 자원을 사용하지 않고 병렬적으로 처리가 가능해 렌더링 속도가 향상되는 이점이 있다고 한다.

(GPU를 사용해서 속도가 향상되는 건 노드 레이어 분리와 연관이 있는데 이 내용은 더 공부해서 시간이 되면 정리해보려고 한다.)

이렇게 padding 대신 scale을 변경함으로써 리플로우 현상을 없애고 GPU 연산을 통해 애니메이션 최적화를 할 수 있었다.

물론 사진 자료에서 볼 수 있듯이 GPU 연산도 남용하면 성능 저하를 일으킬 수 있으니 필요에 따라 사용하는 것이 좋겠다.

CPU 연산과 GPU 연산을 생각하며 애니메이션을 최적화한다면 멋진 애니메이션을 효율적으로 구현할 수 있을 것이다.

기초적인 레이아웃을 잡는 건 어렵지 않았지만, 컴포넌트를 hover했을 때 배경색이 생기는 애니메이션을 구현하는 데 애를 먹었다.

이 과정에서 chakra ui의 새로운 group이라는 클래스를 알게되었다.

group 클래스와 _groupHover 속성

나는 이번에 썸네일 컴포넌트를 hover하면 컴포넌트 배경에 있는 투명한 박스의 배경색과 패딩을 변경하려고 했다.

배경 박스는 z-index가 전면 요소들보다 낮기 때문에 마우스를 아무리 올려봐도 배경 박스엔 hover가 적용되지 않았다.

대상 요소에 직접 마우스를 올려야 hover가 활성화되는 것 같다.

그래서 gemini에게 물어보니 group이라는 class를 알려주었다.

이 클래스를 부모 요소에 추가하면 부모 요소가 hover됐을 때, _groupHover속성이 활성화되어 직접 hover되지 않은 자식 요소에 hover 효과를 부여할 수 있다고 한다.

적용 코드 예시

작성한 코드의 일부다.

맨 위, 부모 Flex 요소에 className='group'을 설정했다. 자식 Box 요소엔 _groupHover 로 패딩과 bg를 조절하는 코드가 있다. 이렇게 설정하면 결과적으로 Flex의 자식 요소 전체 중 일부를 hover 했을 때 _groupHover가 활성화되어 padding과 bg가 변한다.

이 내용은 chakra ui mcp 서버를 통해 가져온 정보라 공식 문서에서 자세한 내용을 직접 확인하고 싶었다. 하지만 chakra ui 공식문서를 찾아봐도 class에 대한 정보는 찾을 수 없었다.

이에 관해 gemini는 chakra ui가 내부적으로 panda css 엔진을 채택해서 사용하기 때문에 class를 통한 스타일링을 지원한다라고 알려줬다. 일단 그냥 쓰다가 더 공부가 필요하면 그때 찾아보려고 한다.

추가로, _groupHover 외에도 다양한 속성이 있어서 나중에 활용해보면 좋을 것 같다.

addEventListener('resize', () => {})로 이벤트를 등록해야하는 줄 알았는데 gemini에게 물어보니 또다른 방법이 존재했다.

바로 ResizeObserver라는 객체다.

이 객체는 화면 요소의 사이즈 변화를 감지했을 때 콜벡함수를 자동으로 실행해준다.

리액트 내장 객체인 줄 알았는데, 그게 아니라 import 없이도 사용할 수 있었다.

ResizeObserver사용 방법

사용 방법은 간단하다.

1. 사이즈 변화 요소의 ref를 생성한다.
2. ResizeObserver 인스턴스를 생성하고 콜벡함수를 전달한다.
3. ResizeObserver 인스턴스의 observe() 메서드에 변화 요소 ref.current를 전달한다.
4. 인스턴스의 disconnect()를 실행하여 감지를 해제한다.

실제 코드로 사용법을 확인하면 이해하기 쉽다.

  useEffect(() => {

    // resize 이벤트 발생시 실행할 콜백 함수
    const callbackFunc = () => {}

    // ResizeObserver 인스턴스 생성 & 콜백 함수 등록
    const observer = new ResizeObserver(() => {
      callbackFunc()
    })

    // observer 감지 시작
    observer.observe(scrollAreaRef.current)

    // observer 감지 해제
    return () => observer.disconnect()
  }, [])

다른 페이지로 넘어갔을 때 감지를 멈추기 위해 useEffect()안에서 ResizeObserver를 생성하고 클린업 함수에서 감지 해제 함수를 실행했다.

이렇게 하면 메모리 누수를 막을 수 있다.

적용 예시

Chakra UI로 유튜브 클론 코딩 중, 필터 버튼 리스트를 구현할 때 ResizeObserver를 적용했다.

위 gif에서 스크롤 박스 크기가 일정 크기 이상 줄어들면 화살표 버튼이 표시된다. 물론 크기가 커지면 그 반대로도 작동한다.

이는 스크롤 박스의 크기가 스크롤 width 보다 작아질 경우 버튼을 표시하는 함수를 ResizeObserver에 등록한 것이다.

이렇게 화면 요소의 사이즈 변화를 감지하고 특정 함수를 실행할 때 ResizeObserver를 활용할 수 있다.

기존엔 이미지를 받고 나서 buffer에 담긴 정보를 toString('base64')로 인코딩하여 db에 저장했었다.

  @Post()
  @UseInterceptors(FileInterceptor('book-image'))
  async createBookReview(
    @UploadedFile() bookImage: Express.Multer.File,
    @Body() bookDto: BookReviewDto,
  ) {
    bookDto.bookImage = bookImage.buffer.toString('base64')
    await this.bookReviewService.createBookReview(bookDto);
  }

이렇게 구현하니 프론트에서 이미지를 불러오고 렌더링 하기까지 5초가 걸렸다.

왜 이렇게 오래 걸린걸까?

gemini한테 물어보니, base64 인코딩은 이미지 저장 용량을 30%까지 늘리기 때문에 데이터베이스 저장이나 이미지 불러오는 시간 측면에서 단점이 많다고 한다.

gemini가 내놓은 해답은 이렇다.

이미지는 S3에 저장하고 저장된 이미지 url만 db에 저장하세요.

S3는 한 번도 세팅해보지 않아서 gemini의 도움을 많이 받았다

먼저 AWS S3 버킷을 만들어야 한다.

AWS S3 버킷 만들기

버킷 생성

AWS에 접속한 후 S3에 들어간다.

주황색 버킷 만들기를 누르고 초기 세팅을 진행한다.

1. 일반 구성: Global namespace 그대로 둔다.
2. 버킷 이름: 마음대로 지정한다.(그렇다고 막 짓진 말고 서비스와 관련해서 짓자)
3. ACL 비활성화됨을 유지한다.
4. 모든 퍼블릭 액세스 차단 선택을 풀어주고 하단 경고창에 체크표시를 한다.(이 설정을 해야 외부에서도 파일 접근이 가능하다)
5. 버킷 버전 관리, 기본 암호화도 기본 설정을 유지한다.

이렇게 세팅을 마치고 버킷 만들기를 누르면 버킷이 생성된다.

버킷 정책 설정

버킷 생성이 완료됐으면 정책을 설정해야 한다.

1. 생성된 버킷을 클릭하고 상단 권한 탭에 들어와 버킷 정책을 편집하면 된다.
2. 정책에 빈 json 내용이 있으면 거기에 작성하면 되고 없다면 우측에 새 문 추가를 누른다.

3. {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::{본인 버킷 명}/*"
        }
    ]
   }

   { } 자리에 본인 버킷 명을 그대로 작성해주면 된다.(물론 {,}는 뺀다)

이후 변경 사항 저장을 누른다.

이렇게 버킷 설정은 완료됐다.

IAM 생성하기

사용자 생성

만들어놓은 버킷에 접근 권한이 있는 사용자를 생성한다.

여기서 가졌던 의문

루트 계정으로 다 접근할 수 있게 해야하는 거 아닌가? 왜 굳이 사용자를 또 나눠서 관리하지?

gemini의 대답

1. 최소 권한 원칙: 루트 계정이 털리면 모든 서비스에 피해가 간다. 필요에 맞게 최소한의 권한으로 사용자를 설정해서 사용하는 게 안전하다.
2. 책임 소재 파악: 루트 계정만 사용할 경우 로그 관리가 어렵다. 여러 부서가 한 계정을 사용할 경우 실수로 DB를 날려도 어떤 부서가 잘못한 건지 알 수 없다.

개인적으로 aws를 사용하는 분들에겐 첫 번째 이유가 가장 중요할 것 같다.

어쨋든, IAM 사용자 탭에 들어와서 사용자 생성을 누른다.

1. 사용자 이름을 설정한다.
2. 권한 옵션에서 직접 정책 연결을 선택한다.
3. 하단 권한 정책 검색창에 s3full을 입력하면 아래에 AmazonS3FullAccess 옵션이 나오는데 왼쪽 체크박스를 클릭하고 다음 버튼을 누른다.
4. 바로 다음 페이지에서 사용자 생성 버튼을 누른다.

액세스 키 발급

사용자를 만들었으니 이 권한을 사용할 수 있는 액세스 키를 발급받아야 한다.

여기에 나오는 키는 생성된 직후만 조회할 수 있기 때문에 안전한 개인 파일에 보관하는 게 중요하다.

1. 생성된 사용자를 클릭하고 하단 액세스 키 탭의 액세스 키 만들기 버튼을 누른다.
2. AWS 외부에서 실행되는 애플리케이션 옵션을 클릭하고 다음을 누른다.
3. 태그는 생략하고 액세스 키 만들기를 누른다.
4. 이후에 하단에 나온 액세스 키와 비밀 액세스 키를 꼭 저장해둔다.

이렇게 S3 버킷과 IAM 사용자 생성이 완료됐다.

이제 버킷명, IAM 사용자 액세스 키와 비밀 액세스 키를 본인 서비스 .env파일에 저장하고 S3를 사용하면 된다.

끝. 생각보다 쉬웠다.

gemini 말대로 설정했을 때 잘 된 경우가 많이 없었는데, 최근에 좀 똑똑해졌나보다

오늘 처음으로 안티그래비티라는 에디터를 설치해서 사용해봤다. 이 에디터는 기존 vscode, cursor와 어떤 점이 다른 지가 궁금했다.

좋았던 점

1. 처음 사용해보고 좋았던 건 agent manager 창이 따로 있다는 점이다.

chatgpt와 gemini 와 비슷한 UI를 갖고 있어 사용법을 익히는 건 어렵지 않았다. 웹 브라우저에서 LLM을 사용하는 것과 크게 다르지 않다. 그래서 편했다.

2. 사용가능한 모델 종류와 사용량

gemini 3.1 pro부터 gpt까지 여러 모델을 사용할 수 있다. 평소에 코딩할 때 클로드 코드를 이용하는데, 여기서도 클로드 코드 모델(sonnet, opus)을 사용할 수 있어서 좋았다.

사용량 부분에서도 이점이 있었다.

gemini pro(High)는 plan 모드로 2~3번 사용했을 때 전체 사용량의 20%가 줄었고 gemini pro(Low)도 plan 모드로 5번 정도 사용했는데 20% 줄었다. gemini flash 모델로는 가벼운 질문을 10번 넘게 했던 거 같은데 사용량은 20% 줄어있었다.

안티그래비티가 최근에 나온 에디터라서 그런지 무료 플랜인데도 사용량을 많이 주는 것 같다.

더구나 모델별로 사용량을 제한하기 때문에 한 모델의 사용량을 전부 써도 나머지 모델을 쓰면 돼서 가벼운 코딩에는 결제하지 않아도 될 정도로 사용량이 넉넉하다.

3. mcp 서버 연결

테스트를 위해 노션 mcp 서버를 연결을 시도해봤다.

mcp store에서 검색 후 install 버튼을 누른 다음 API 키만 입력하니 연결이 됐다. mcp 연결이라하면 과정이 되게 복잡할 것 같았는데, 익스텐션 설치해서 사용하는 것처럼 편하게 설정할 수 있어서 좋았다.

불편했던 점

폴더에서 사진을 끌어다 에디터 폴더에 붙여넣기 하려고 했는데 paste to agent라고 나오면서 잘 되지 않았다. 구글링을 해봐도 그냥 cmd+c, cdm+v 하라는 말만 나왔다.

서비스가 배포된 지 얼마 되지 않아서 그런가. 오류가 좀 남아있는 듯하다.

결론

vscode UI와 크게 다른 점이 없고, 세팅도 똑같이 사용할 수 있어 코딩할 때 이질감이 들지 않았다. cursor를 선택하지 않은 이유가 vscode와 이질감이 들어서인데, 안티그래비티는 그러지 않았다.

또한, vscode를 쓸 땐, AI를 잘 안 썼는데, 안티그래비티에선 이상하게 자주 사용하게됐다. AI agent를 사용하기 편하게 만들어놔서 그런 것 같다.

앞으로도 계속해서 안티그래비티를 사용해보려고 한다. 지금 클로드 코드를 결제해서 사용 중인데, 괜찮다면 나중에 안티그래비티 유료 플랜으로 넘어갈 생각이다.

프로젝트 생성 및 설정하기

프로젝트 생성

PyCharm을 실행하면 기본 화면이 나오는데 여기서 New Project 버튼을 누른다.

프로젝트 세부 설정

그 다음으로는 프로젝트 세부 설정을 해야한다.

1. 프로젝트명 수정 Location을 보면 기본적인 프로젝트 명은 PythonProject로 설정되어 있을 것이다. 이것을 본인이 원하는 프로젝트 명으로 바꿔주면 된다
2. 본인이 원하는 Python 버전 선택(3버전 이상으로)

모두 완료하면 다음 화면처럼 보인다.

설정 완료 후 우측 하단 Create 버튼을 누르면 PyCharm이 프로젝트를 생성해준다.

장고 모듈 설치

장고를 개발하려면 장고 모듈이 필요하다. 터미널을 열고 아래의 명령어를 입력하여 장고 모듈을 설치해보자.

pip install django

버전을 따로 명시해주지 않으면 최신 버전으로 설치된다. 버전을 설정하는 방법은 다음과 같다.

pip install django==5.2.1

장고 프로젝트 기본 구조 생성

터미널을 열어 다음과 같이 명령어를 입력하자.

django-admin startproject 프로젝트명 .

현재 위치에 장고 프로젝트를 생성하라는 명령어다. (프로젝트명은 python 모듈로 사용되기 때문에 ' '(공백), -(하이픈)을 피하고 숫자로 시작하지 않는 이름을 사용해야 한다.)

이렇게 입력하면 다음과 같이 manage.py 파일과 프로젝트 폴더가 생성된다.

manage.py는 말 그대로 프로젝트를 관리하는 데 사용되는 파일이다. 프로젝트 관련 설정(setting.py)을 자동으로 인식한다는 특징이 있다.

장고 실행하기

이제 장고 서버를 실행해보자.

터미널에 다음과 같이 명령어를 입력하자.

python manage.py runserver

이는 장고 서버를 시작하라는 명령어다. 실행이 성공적으로 완료되면 터미널 창에 다음과 같이 표시가 된다.

이제 브라우저를 열고 주소창에 127.0.0.1:8000(혹은 localhost:8000)을 입력하면 장고 웹사이트를 볼 수가 있다.

+ PyCharm에서 Django 편의 기능 활용하기

파이참에선 장고 개발을 위한 여러 편의 기능을 제공해준다. 해당 기능을 사용하려면 따로 설정이 필요하다.

Enable Django support 설정

1. PyCharm -> Settings -> Languages & Framework -> Django
2. Enable Django support를 체크
3. django project root에 현재 프로젝트 최상위 폴더 지정
4. Settings는 settings.py 파일을 지정

(폴더나 파일을 지정할 때 각 입력칸 맨 오른쪽 끝에 있는 폴더 모양을 클릭하면 편하게 할 수 있다.)

서버 실행 및 디버깅 설정

1. 화면 우측 상단 Current File을 누르고 Edit Configurations를 클릭
2. Add new run configuration을 누르고 Django Server를 찾아 클릭
3. Name은 본인 프로젝트 명으로 입력하고 Working directory는 프로젝트 최상위 폴더로 지정

이렇게 하면 우측 상단 시작 버튼▶️만 누르면 장고 서버를 시작할 수 있다. 장고 서버 중지 및 디버깅도 가능하다.

파이참을 사용하면 개발이 편해진다. 장고를 개발할 땐 꼭 파이참을 사용하자.

Django는 파이썬 기반 프레임워크이기 때문에 파이썬 설치가 필수다.

현재로서는 3.12 버전이 bugfix가 완료된 안정된 버전이기 때문에 다운로드 시점 기준 3.12 버전 중 최신 stable release 버전을 다운로드 받으면 된다. (나는 3.12.10 버전을 다운로드 받았다.)

파이썬 다운로드 링크: https://www.python.org/downloads/macos/

(사진 출처: https://devguide.python.org/versions/)

가상 환경 세팅하기

파이썬에서는 가상환경을 세팅해주는 라이브러리가 있다. (사실 파이참을 사용하면 알아서 가상환경을 설정해주지만 직접 적용하는 법을 배워놔도 나쁠 건 없다.)

가상환경이란?

개발하다보면 여러 프로젝트를 진행할 때가 있다. 만약 A와 B라는 프로젝트가 있다고 하자. 이 프로젝트는 C라는 라이브러리를 공통으로 사용한다. 이 때 A프로젝트에서는 2.xx버전을 사용하고 B프로젝트에서는 3.xx버전을 사용한다고 하면 라이브러리 버전을 프로젝트별로 관리할 필요성이 생긴다. 이때 사용하는 것이 가상환경이다.

가상환경을 사용하면 A프로젝트용 가상환경을 생성하여 2.xx버전을 다운받아 사용할 수 있고 마찬가지로 B프로젝트용 가상환경을 설정하여 3.xx버전을 다운받고 사용할 수 있는 것이다.

간단히 말해 라이브러리 버전 관리 시스템이다.

가상환경 생성 방법

파이썬에서는 venv라는 라이브러리로 가상환경을 세팅할 수 있다. (Virtual ENVironment의 줄인말)

터미널을 열어 프로그래밍 작업 폴더에 들어가 venvs 폴더를 만들고 그곳으로 들어가보자.

cd 작업폴더명
mkdir venv
cd venv

그 후 다음 명령어를 실행해보자.

python3 -m venv 가상환경이름

(나는 가상환경을 venv1으로 설정하였다.)

이렇게 작성하면 내가 입력한 가상환경이름으로 가상환경 폴더 하나가 생성된다.

가상환경 활성화하기

생성한 가상환경 폴더로 들어간 다음 bin 폴더로 들어가자.

cd venv1/bin

그 후 다음 명령어를 실행해보자.

source activate

(source는 해당 실행파일을 실행하라는 명령어다.)

이렇게 하면 터미널에 다음과 같이 가상환경이 활성화되었다는 표시가 생긴다.

(가상환경 활성화 표시는 터미널 환경마다 다를 수 있다. 나는 따로 oh my zch로 터미널 테마를 커스텀했기 때문에 위와 같이 보인다.)

가상환경 비활성화하기

활성화한 가상환경을 비활성화 하는 법은 간단하다. 터미널 창에 다음과 같이 명령어를 실행해보자.

deactivate

비활성화하면 활성화 되었다는 표시가 사라진다

PyCharm IDE 설치하기

본격적으로 장고를 개발하기에 앞서 코딩 프로그램을 하나 설치해보자.

PyCharm은 JetBrains사에서 만든 파이썬 전용 통합개발환경 프로그램이다. 코드 편집, 코드 자동 완성, 데이터베이스 조회, 프로젝트 버전 관리 등 개발자가 편하게 개발할 수 있는 환경을 제공해준다. (대학생이라면 학생 인증을 하고 무료로 Pro 버전을 사용할 수 있다. 기본 버전은 Community 버전이며 둘 중 어느 것으로 해도 상관없다.)

PyCharm IDE 공식 다운로드 링크 for Mac

다운로드가 완료되면 실행해보자. 아래 사진과 같이 새로운 프로젝트를 생성하거나 기존 프로젝트를 볼 수 있는 화면이 나온다.

다음 포스팅에선 장고 프로젝트를 생성하고 실행해보는 시간을 가져보겠다.

글에서 나오는 SecurityConfig 클래스는 filterChain 메서드를 작성하는 Spring Security의 환경 설정 클래스이다.

클래스명은 사람마다 다를 수 있다는 점을 알아주기 바란다.

사용 버전 정보

• Spring Boot: 3.4.1
• Spring Security: 6.4.2
• Java: 17

인증받지 않은 유저 처리

인증 받지 않은 유저를 처리할 수 있게 해주는 인터페이스가 존재한다.

바로 AuthenticationEntryPoint라는 인터페이스다.

이 인터페이스를 구현하는 클래스를 만들어 Spring Security에 등록하면 인증 받지 않은 유저에 대한 예외 처리가 가능해진다. ex) 응답 날리기, 리디렉션 하기 등

코드를 보며 예시를 살펴보자.

AuthenticationEntryPoint 구현 클래스 작성

@Component
public class CustomAuthenticationEntryPoint implements AuthenticationEntryPoint {
    @Override
    public void commence(HttpServletRequest request, HttpServletResponse response, AuthenticationException authException) throws IOException, ServletException {
        response.setContentType("application/json");
        response.setCharacterEncoding("UTF-8");
        response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
        response.getWriter().write("{\"error\": \"Unauthorized\", \"message\": \"로그인이 필요합니다.\"}");
    }
}

@Component 어노테이션을 사용하여 빈으로 등록했다. 이는 SecurityConfig 클래스에서 주입 받아 사용하려는 목적을 가진다.

AuthenticationEntryPoint 인터페이스를 구현하려면 commence라는 메서드를 오버라이딩 해야된다.

나는 response에 Content-Type, Encoding, status 설정을 하고 메세지를 작성해주었다.

이렇게 메서드 내용을 작성한 후 SecurityConfig 클래스에 등록해주면 된다.

등록하는 과정은 인가 관련 클래스를 작성 후 보여주겠다.

인가받지 않은 유저 처리

인가받지 않은 유저를 처리할 수 있게 해주는 인터페이스가 존재한다.

바로 AccessDeniedHandler 인터페이스다.

이 인터페이스도 마찬가지로 구현하는 클래스를 작성 후 SecurityConfig 클래스에 등록해주면 인가 받지 않은 유저에 대한 예외처리를 할 수 있게 된다.

AccessDeniedHandler 구현 클래스 작성

@Component
public class CustomAccessDeniedHandler implements AccessDeniedHandler {
    @Override
    public void handle(HttpServletRequest request, HttpServletResponse response, AccessDeniedException accessDeniedException) throws IOException, ServletException {
        response.setContentType("application/json");
        response.setCharacterEncoding("UTF-8");
        response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
        response.getWriter().write("{\"error\": \"Unauthorized\", \"message\": \"권한이 없습니다.\"}");
    }
}

이 클래스도 @Component 어노테이션을 사용해 빈으로 등록했다.

AccessDeniedHandler 인터페이스에는 구현해야할 handle 메서드가 존재한다.

해당 메서드 안에 인가 받지 않은 유저에 대한 처리를 작성하면 된다.

아까와 마찬가지로 response 에 여러 옵션을 설정해줬다.

이렇게 인증과 인가 관련 예외 처리 클래스 작성이 완료됐다.

SecurityConfig 클래스에 등록

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {

    private final CustomAuthenticationEntryPoint customAuthenticationEntryPoint;
    private final CustomAccessDeniedHandler customAccessDeniedHandler;

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

        // ~~생략~~

        http
                .exceptionHandling((exceptions) -> exceptions
                        .authenticationEntryPoint(customAuthenticationEntryPoint)
                        .accessDeniedHandler(customAccessDeniedHandler)
                );

        // ~~생략~~

        return http.build();
    }
}

SecurityConfig 클래스의 filterChain 메서드 안에 등록하면 된다.

HttpSecurity 객체가 갖는 exceptionHandling 메서드 안에 람다식을 작성하고 구현하는 인터페이스 명과 일치하는 메서드에 알맞은 객체를 전달해준다.

이렇게 하면 인증되지 않은 사용자가 접근하려할 때 혹은 인가받지 않은 사용자가 특정 자원에 접근하려할 때의 예외 처리가 가능해진다.

사용 이유

Oauth2 로그인을 구현하는 도중, 해당 클래스를 작성하기 전에는 인증 받지 않은 사용자가 접근했을 때 의도치 않게 로그인 페이지로 리다이렉션되는 어려움을 겪었다.

리다이렉션을 방지하고 메세지와 오류 상태코드를 반환하고자 사용하였다.

스프링 시큐리티의 편리함과 기능의 다양성을 느낄 수 있었던 좋은 경험이었다.

참고 자료

• chb2005님의 블로그글 해당 자료가 2년 전 자료라 현재 deprecated된 게 존재해서 코드를 살짝 수정하였다. SecurityConfig 클래스에 등록 방법: 메서드 체이닝 -> 람다식 사용

= Cross-Site Request Forgery

웹 애플리케이션 취약점 중 하나로 사용자가 자신의 의지와 무관하게 공격자가 의도한 행동을 해서 특정 웹 페이지를 보안에 취약하게 한다거나 수정, 삭제 등의 작업을 하게 만드는 공격 방법

공격 과정

1. 공격자가 CSRF 스크립트가 담긴 게시글을 작성한다.
2. 다른 사용자가 해당 게시글에 접근한다.
3. CSRF 스크립트가 사용자의 권한으로 실행된다

예시

공격자가 해당 사이트의 url 패턴을 분석하여 계정 정보를 바꾸는 url을 알아낸다.

그 후 자신이 원하는대로 계정을 바꾸는 링크를 게시글이나 메일에 올려서 사용자가 접속하도록 한다.

http://example.com/user/update?user=abcd&password=1234

이 링크를 누른 사용자의 아이디는 공격자가 미리 지정해놓은 대로 바뀌게 되고, 이를 통해 해킹이 가능하게된다.

예방 방법

서버에 http 요청을 보낼 때 특정 토큰을 함께 보내도록 강제해서 사용자가 의도한 요청만 실행되도록 한다.

서버에서 사용자에게 웹페이지를 전달할 때 토큰을 전달하고, 사용자가 그 페이지에서 http 요청을 보내면 전달받은 토큰을 함께 받아 토큰 값을 검증하는 방식이다.

<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Join Page</title>
</head>
<body>
join page
<br>
<form action="/joinProc" method="post" name="joinForm">
    <input id="username" type="text" name="username" placeholder="id"/>
    <input id="password" type="text" name="password" placeholder="password"/>
    <input type="hidden" name="_csrf" value="{{_csrf.token}}"> <!-- 요청할 때 토큰을 함께 보낸다. -->
    <input type="submit" value="join"/>
</form>

</body>
</html>

회원가입 페이지의 html 코드이다.

서버는 해당 페이지를 사용자에게 보낼 때 토큰값을 끼워넣어 함께 보내고, 사용자가 http 요청을 하면 다시 토큰을 받아 이전에 보냈던 토큰과 일치하는 지 확인한다.

이를 통해 사용자는 항상 자신이 의도한 요청만 할 수 있게 된다.

Spring Security에서의 csrf 대응 방법

스프링 시큐리티는 기본적으로 csrf 토큰을 전달해서 공격을 방어한다.

그래서 처음 스프링 시큐리티를 배울 때 이 옵션을 disable하라고 한다. 왜냐하면 추가적으로 해야할 일이 생기기 때문이다.

http
        .csrf((auth) -> auth.disable());

(config 클래스에서 해당 코드를 작성하면 csrf 옵션이 비활성화된다.)

모든 폼 타입의 요청에서 csrf 토큰 코드를 작성하지 않으면 요청이 받아들여지지 않는다.

따라서 초보자는 처음 배울 때 해당 옵션을 비활성화 하고 나중에 숙련이 되면 코드를 추가하는 식으로 csrf 설정을 하게된다.

Spring Boot : 3.3.5 버전 Java : 17 버전

📕 스프링 시큐리티란?

인증&인가를 편하게 구현할 수 있도록 스프링에서 제공해주는 보안 관련 프레임워크입니다.

📗 인증과 인가(Authentication& Authorization)

인증과 인가라는 단어를 자주 들어보셨을테지만 헷갈리는 개념이라 짚고 넘어가겠습니다.

인증(Authentication) : 사용자가 누구인지 검증하는 과정 인가(Authorization) : 사용자의 역할에 따라 권한을 부여하는 과정

서버를 회사라고 비유해보겠습니다.

회사 출입 카드를 사용하여 회사에 들어가는 과정 = 인증 직급에 따라 출입가능한 사무실이 다르게 배치되는 것 = 인가

이렇게 생각하면 이해하기 쉬울 겁니다.

스프링 시큐리티 인증 과정

전체적인 인증 과정을 살펴보겠습니다.

스프링 시큐리티의 인증 내부 구조입니다. 간단한 흐름은 다음과 같습니다.

1. 사용자가 로그인 요청을 보냈을 때 인증 필터가 요청을 받습니다.
2. 인증 매니저에게 요청과 관련된 유저 정보를 가져오도록 합니다.
3. UserDetailsService에서 유저 정보를 찾아 인증 매니저에게 전달합니다.
4. 요청 정보와 찾아낸 유저 정보를 비교하여 일치한다면 인증 객체를 생성하고 SecurityContext에 저장합니다. (= 세션 저장)

📕 작성할 코드

내부구조를 보면 엄청 복잡해보이지만 사실 구현할게 그리 많지 않습니다.

📗 추가할 의존성(dependency)

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-security'
}

spring-boot-starter-security 의존성 하나만 의존성 정보에 추가해주시면 됩니다.

📗 Security Config 파일

가장 중요한 설정 파일입니다. 이 파일에 여러가지 보안 관련된 설정을 할 수 있습니다.

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

        // 인가(Authorization) 설정 코드
        http
                .authorizeHttpRequests((auth) -> auth
                        .requestMatchers("/", "/login","/loginProc","/join","joinProc", "loginFail").permitAll()
                        .requestMatchers(PathRequest.toStaticResources().atCommonLocations()).permitAll() // static 자원에 대한 접근 모두 허용
                        .requestMatchers("/api/admin/**","/admin/**").hasRole("ADMIN")
                        .requestMatchers("/logout").hasAnyRole("ADMIN", "USER")
                        .anyRequest().authenticated()
                );

        // 특정 url에 csrf 검증 비활성화
        http
                .csrf((auth) -> auth
                        .ignoringRequestMatchers("/api/**")
                );

        // 로그인 관련 설정
        http
                .formLogin((auth) -> auth
                        .loginPage("/login")
                        .loginProcessingUrl("/loginProc")
                        .failureForwardUrl("/loginFail")
                        .defaultSuccessUrl("/articles", true)
                        .permitAll()
                );

        // 로그아웃 관련 설정
        http
                .logout((auth) -> auth
                        .logoutUrl("/logout")
                        .logoutSuccessUrl("/")
                );

        // 중복 로그인 처리
        http
                .sessionManagement((auth) -> auth
                        .maximumSessions(1)
                        .maxSessionsPreventsLogin(true)
                );

        // 세션 고정 공격을 방어하기 위한 방법 - 공격자의 세션 id로 로그인 해도 새로운 세션 id가 발급되어
        // 공격자의 세션 id는 여전히 익명 사용자 세션이 됨
        http
                .sessionManagement((auth) -> auth
                        .sessionFixation().changeSessionId());

        return http.build();
    }

    @Bean
    public BCryptPasswordEncoder bCryptPasswordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

뭔가 많아보이지만 하나씩 살펴보면 간단합니다.

어노테이션 설정

먼저 @Configuration과 @EnableWebSecurity를 클래스 상단에 추가해주세요. 스프링 시큐리티 설정을 위한 어노테이션입니다.

인가(Authorization) 설정

http
        .authorizeHttpRequests((auth) -> auth
                .requestMatchers("/", "/login","/loginProc","/join","joinProc", "loginFail").permitAll()
                .requestMatchers(PathRequest.toStaticResources().atCommonLocations()).permitAll() // static 자원에 대한 접근 모두 허용
                .requestMatchers("/api/admin/**","/admin/**").hasRole("ADMIN")
                .requestMatchers("/logout").hasAnyRole("ADMIN", "USER")
                .anyRequest().authenticated()
        );

인가 관련 코드를 작성하는 곳입니다.

requestMatchers에 특정 url을 입력하면 해당 url에 대한 접근 권한을 설정할 수 있습니다.

자세히 보시면 requestMatchers 뒤에 permitAll(), hasRole(), hasAnyRole()이 붙어있는 것을 볼 수 있습니다.

• permitAll(): 인증받지 않은 유저(로그인 하지 않은 유저)에게도 접근을 허용
• hasRole(): 특정 권한을 갖고 있는 유저에게만 접근을 허용
• hasAnyRole(): 인수에 전달한 여러 권한 중 하나라도 가진 유저에게 접근을 허용

예를 들어

.requestMatchers("/api/admin/**","/admin/**").hasRole("ADMIN")

이 코드는 /api/admin/**,/admin/** url 관련 요청은 ADMIN 권한을 가진 유저만 접근이 가능하다는 것을 의미합니다.

.anyRequest().authenticated()

마지막에 작성된 이 코드는 위에 설정한 url 이외에 다른 모든 url에 대한 요청은 인증된 유저에게 접근을 허용한다는 뜻입니다.

csrf 설정

// 특정 url에 csrf 검증 비활성화
http
        .csrf((auth) -> auth
                .ignoringRequestMatchers("/api/**")
        );

이는 /api/** url에 전송되는 요청은 csrf 검증을 하지 않는다는 것을 의미합니다.

  http
          .csrf(AbstractHttpConfigurer::disable);

위와 같이 코드를 작성하여 csrf 검증을 아예 적용하지 않게 할 수 있습니다. 이는 주로 csrf 검증이 필요없는 REST API server를 만들 때 사용합니다. 혹은 csrf 설정이 복잡한 초보자 분들이 이를 비활성화 할 때 사용합니다.

로그인, 로그아웃 설정

// 로그인 관련 설정
http
        .formLogin((auth) -> auth
                .loginPage("/login") // 로그인 페이지
                .loginProcessingUrl("/loginProc") // 로그인 요청을 받는 url
                .failureForwardUrl("/loginFail") // 로그인이 실패했을 때 이동하는 url
                .defaultSuccessUrl("/articles", true) // 성공했을 때 이동하는 url
                .permitAll()
        );

// 로그아웃 관련 설정
http
        .logout((auth) -> auth
                .logoutUrl("/logout") // 로그아웃 요청을 받는 url
                .logoutSuccessUrl("/") // 로그아웃이 성공했을 때 이동하는 url
        );

로그인과 로그아웃을 어떤 url을 통해 진행할건지 설정합니다. 또한 해당 과정이 실패하거나 성공했을 때 어떤 url로 이동할지도 설정합니다.

제가 작성한 것 외에 다른 여러 옵션도 많으니 직접 찾아보시면 다양한 설정을 하실 수 있을 것입니다.

다중 로그인 설정

// 중복 로그인 처리
http
        .sessionManagement((auth) -> auth
                .maximumSessions(1) // 최대 다중 로그인 허용자 설정
                .maxSessionsPreventsLogin(true)); // 최대 허용자를 넘어선 로그인에 대해 금지하는 설정

다중 로그인은 말 그대로 최대 몇 명까지 로그인을 허용할지를 결정하는 설정입니다.

세션 고정 공격 설정

// 세션 고정 공격을 방어하기 위한 방법 - 공격자의 세션 id로 로그인 해도 새로운 세션 id가 발급되어
// 공격자의 세션 id는 여전히 익명 사용자 세션이 됨
http
        .sessionManagement((auth) -> auth
                .sessionFixation().changeSessionId());

세션 고정 공격을 막는 설정입니다. 세션 고정 공격에 대한 내용을 여기서 설명하지는 않겠습니다. 따로 검색해보시면 자세히 알 수 있습니다.

간단하게 말하면 공격자가 사용자 브라우저에 자신의 세션을 심어두고 사용자가 로그인을 하면 자신도 사용자의 인증 권한을 얻게되는 공격 방법입니다.

이를 방어하기 위해 로그인을 했을 때 자신이 갖고있던 세션 아이디를 변경시켜주는 설정입니다.

BCryptPasswordEncoder (비밀번호 암호화 객체)

스프링 시큐리티에서는 기본적으로 BCrypt 암호화 객체를 제공합니다. 이를 통해 비밀번호를 암호화할 수 있습니다.

사용자의 비밀번호를 그대로 db에 저장하기보단 암호화를 하고 저장하는 게 보안상 좋습니다.

다음과 같이 회원가입 과정에서 사용합니다.

private final BCryptPasswordEncoder bCryptPasswordEncoder;

User user = User.builder()
                .username(joinDTO.getUsername())
                .password(bCryptPasswordEncoder.encode(joinDTO.getPassword()))
                .role("ROLE_USER")
                .build();

userRepository.save(user);

📗 유저 엔티티

스프링 시큐리티가 유저 정보를 가져오기 위해 유저 엔티티에 추가설정을 해야합니다.

아마 기존에 유저 엔티티를 만들어 놓으셨을텐데 거기에 추가로 UserDetails 인터페이스를 구현해주시면 됩니다.

UserDetails 인터페이스를 구현함으로써 스프링 시큐리티가 유저 정보를 가져올 수 있도록 합니다.

@Getter
@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class User implements UserDetails {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(unique = true)
    private String username;

    private String password;

    private String role; //admin이나 user 역할 부여용 컬럼

    @OneToMany(mappedBy = "user")
    private List<Article> articleList;

    @Builder
    public User(String username, String password, String role) {
        this.username = username;
        this.password = password;
        this.role = role;
    }

    // 여기서부터 UserDetails 인터페이스 구현 메서드
    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return List.of(new SimpleGrantedAuthority(role));
    }

    @Override
    public String getUsername() {
        return username;
    }

    @Override
    public String getPassword(){
        return password;
    }

    @Override
    public boolean isAccountNonExpired() {
        return true;
    }

    @Override
    public boolean isAccountNonLocked() {
        return true;
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }

    @Override
    public boolean isEnabled() {
        return true;
    }
}

구현해야하는 메서드는 7개입니다.(@Override가 붙은 메서드만 보세요)

하나씩 살펴보겠습니다.

getAuthorities 메서드

@Override
public Collection<? extends GrantedAuthority> getAuthorities() {
    return List.of(new SimpleGrantedAuthority(role));
}

Config 파일에 대해 살펴볼 때 권한에 대해 언급했습니다. "ADMIN", "USER"가 있었는데, getAuthrities 함수를 통해 스프링 시큐리티는 유저의 권한 정보를 얻습니다.

유저 정보를 반환하도록 코드를 작성합니다.

getUsername, getPassword 메서드

@Override
public String getUsername() {
    return username;
}

@Override
public String getPassword(){
    return password;
}

유저의 아이디와 비밀번호를 반환하도록 작성합니다. 사용자 인증을 하기위한 유저 정보를 가져올 때 사용됩니다.

그외 4가지 메서드

@Override
public boolean isAccountNonExpired() { // 계정이 만료되었는지 반환
    return true;
}

@Override
public boolean isAccountNonLocked() { // 계정이 잠금되었는지 반환
    return true;
}

@Override
public boolean isCredentialsNonExpired() { // 계정 비밀번호가 만료되었는지 반환
    return true;
}

@Override
public boolean isEnabled() { // 계정이 활성화되어있는지 반환
    return true;
}

만약 여러분이 계정에 대한 만료 기간이나 비밀번호 만료 기간을 설정해두셨다면 해당 기간을 검증하여 결과를 반환하는 로직을 작성하시면 됩니다.

하지만 그렇지 않고 일반적인 로그인 과정을 구현하고 싶으시다면 true를 반환하도록 합니다.

role에 관하여

회원가입을 할 때 유저의 role을 설정해야할 겁니다.

이때 그냥 "ADMIN", "USER"로 하는 게 아니라 "ROLE_ADMIN", "ROLE_USER"로 설정해서 저장해야합니다.

그렇지 않으면 오류가 나올 것입니다. 꼭 지켜주세요.

📗 CustomUserDetailsService

스프링 시큐리티에서는 로그인 요청이 오면 해당 아이디의 유저를 찾아서 비밀번호를 비교하고 검증한다고 했습니다.

이때 유저를 가져오는 일을 담당하는 서비스가 필요합니다.

UserDetailsService 인터페이스를 구현하는 클래스를 만들고 메서드 한 개만 간단하게 구현해주시면 됩니다.

@Service
@RequiredArgsConstructor
public class CustomUserDetailsService implements UserDetailsService {

    private final UserRepository userRepository;

    @Override
    public UserDetails loadUserByUsername(String username) {
        return userRepository.findByUsername(username)
                .orElseThrow(()-> new IllegalArgumentException(username));
    }
}

findByUsername 메서드

말 그대로 username을 바탕으로 유저 정보를 찾는 함수입니다. UserRepository에서 username을 통해 유저를 반환하는 함수를 작성하시면 됩니다.

Optional<User> findByUsername(String username);

저는 UserRepository에 위의 코드를 추가하였습니다.

📗 로그인 시도해보기

이를 통해 스프링 시큐리티 세션 로그인 구현이 완료되었습니다.

직접 로그인 페이지를 만들어 form login 방식으로 username과password를 담아 POST 요청을 보낸다면 로그인이 완료될 것입니다.

• html 예시

  <form id=loginForm action="/loginProc" method="post" name="loginForm">
  <label for="username">아이디</label>
  <input id="username" type="text" name="username" placeholder="id"/>
  <label for="password">비밀번호</label>
  <input id="password" type="password" name="password" placeholder="password"/>
  </form>

📕 참고 자료

• 유튜브 개발자유미 채널 : 스프링 시큐리티에 대해 이해하기 쉽게 설명해주십니다. 재생목록에서 spring security를 찾아 보시면 도움이 되실 겁니다.

스프링 계층(layer)

스프링에는 계층이 존재한다.

Client가 전송한 요청을 Controller, Service, Repository 순으로 처리하고 다시 역순으로 데이터를 반환하며 응답을 전송한다. 이렇게 여러개의 계층을 나눈 까닭은 MVC 패턴에 맞춰 개발하기 위함이다.

이를 통해 협업의 편리, 유지보수 용이, 코드간 의존성 낮춤, 코드 중복 제거 등 여러 장점이 생긴다.

간단하게 Controller와 Service에 대해 알아보자.

Controller란

Controller는 클라이언트의 요청에 맞게 함수를 실행해주고, 응답을 전송해주는 역할을 한다. 데이터베이스에 직접 접근하지 않고, 실행한 함수의 리턴 결과로 오는 데이터만 가지고 응답을 전송한다.

Service란

Service는 말 그대로 서비스의 메인 로직을 수행하는 역할을 한다. Controller가 Service의 함수를 실행하면 Service는 Repository를 통해 데이터베이스에 접근하여 필요한 정보를 가져오고 가공해서 Controller에게 다시 전달한다.

구분을 제대로 해야하는 이유?

제대로 구분하지 않는다면 처음에 말했던 MVC 패턴을 따랐을 때 생기는 장점을 모두 잃게 된다.

Controller는 Controller의 역할에 맞게 코드를 작성하고 Service는 Service의 역할에 맞게 코드를 작성해야 하는 것이다.

계층에 맞게 코드를 작성하여 효율적으로 코딩하는 게 중요

내가 이전에 작성했던 코드를 보며 뭐가 잘못됐는지 확인해보자.

내가 작성했던 잘못된 코드

@PostMapping("/user/signUp")
public ResponseEntity<MessageDTO> signUp(@Valid @RequestBody UserSignUpRequestDTO request, BindingResult bindingResult) {
    MessageDTO messageDTO = new MessageDTO();

    if (bindingResult.hasErrors()) { // 입력받은 request body 값에 정상적인 값들이 들어있는지 확인
        List<FieldError> list = bindingResult.getFieldErrors();
        for (FieldError error : list) {
            messageDTO.setMessage(error.getDefaultMessage());
            return new ResponseEntity<>(messageDTO, HttpStatus.BAD_REQUEST);
        }
    }

    boolean isDuplicated = userService.checkEmailDuplication(request.getEmail()); // 아이디 중복 체크

    if (isDuplicated) {
        messageDTO.setMessage("중복된 아이디입니다.");
        return new ResponseEntity<>(messageDTO, HttpStatus.BAD_REQUEST);
    }

    try {
        userService.signUp(request); // 중복되지 않았으면 계정 생성
        messageDTO.setMessage("회원가입 성공");
        return new ResponseEntity<>(messageDTO, HttpStatus.CREATED);
    }catch(IllegalArgumentException e){
        messageDTO.setMessage("학교 정보가 잘못되었습니다.");
        return new ResponseEntity<>(messageDTO, HttpStatus.BAD_REQUEST);
    }
}

유저 회원가입 요청을 처리하는 Controller 함수이다.

잘못된 점은 크게 두 가지로 보인다.

1. Service에서 boolean 값을 받아옴
2. Controller에서 Exception 처리

첫 번째, 계층 간 데이터는 DTO를 통해 전달되어야 한다. 그렇지 않고 바로 데이터를 전달한다면 계층 간 의존성이 높아지기 때문에 유지보수가 힘들어진다.

두 번째, Controller에서는 Controller 계층의 역할에 맞게 코드를 작성해야 한다. Controller는 Client의 요청에 맞는 함수를 매핑하고 응답을 반환하는 계층이다. 여기서 오류처리를 해버린다면 코드 복잡도가 증가하고 반복되는 코드의 양이 늘어나 유지보수가 어려워진다.

오류처리는 Service 계층에서 진행하고 ExceptionHandler를 사용해서 응답처리를 하자.

다음은 최근에 작성한 올바른 코드이다.

최근에 작성한 코드

@PostMapping("/api/articles")
public ResponseEntity<AddArticleResponse> saveArticle(@RequestBody AddArticleRequest addArticleRequest) {
    AddArticleResponse addArticleResponse = boardService.saveArticle(addArticleRequest);
    return new ResponseEntity<>(addArticleResponse, HttpStatus.CREATED);
}

@GetMapping("/api/articles")
public ResponseEntity<GetAllArticlesResponse> findAllArticles(){
    GetAllArticlesResponse getAllArticlesResponse = boardService.findAllArticles();
    return new ResponseEntity<>(getAllArticlesResponse, HttpStatus.OK);
}

@GetMapping("/api/articles/{id}")
public ResponseEntity<GetArticleResponse> findArticleById(@PathVariable("id") Integer id){
    GetArticleResponse articleDTO = boardService.findArticleById(id);
    return new ResponseEntity<>(articleDTO, HttpStatus.OK);
}

게시글과 관련된 요청을 처리하는 Controller다. 이전 코드와는 비교가 안 될 정도로 코드가 깔끔하다.

Service 계층의 함수를 실행하여 결과를 DTO로 받아오고 다른 서비스 로직없이 응답을 반환했기 때문에 코드가 간결해진 것이다.

이렇게 코드를 작성하면 Client 요청이 왔을 때 어떤 Service 함수가 실행되고, 어떤 값이 응답에 담겨 전달되는 지 알아보기 쉽다. 또한, Controller와 Service가 제대로 분리되어 유지보수가 쉬워진다.

앞으로 코드를 작성할 땐 Controller와 Service 구분을 제대로 해서 코드를 작성하자!

출처

• 계층 사진 자료 http://randikatech.blogspot.com/2019/09/get-your-hands-dirty-with-micro-services.html

Vercel이란?

자동으로 웹 어플리케이션을 빌드하고 배포해주는 서비스를 제공한다. front-end 개발자들을 위한 사이트로 자동으로 빌드, 배포는 물론 https를 적용해서 보안성까지 제공해주는 친절한 사이트다. 👍👍👍

Github와 연동하면 commit을 감지하여 자동으로 웹사이트를 업데이트하고, pull request가 요청되면 preview page를 보여주기도 하는 등 github와의 연동성이 굉장히 좋다.

배포 방법

Vercel 로그인(Github 연동)

https://vercel.com/signup vercel의 회원가입 페이지에 들어가서 hobby를 클릭하고 간단한 인적사항을 입력 후 github로 로그인을 진행한다.

Import Github Repository

맨 처음엔 Github application을 install 해야할 것이다. 화면에 바로 보이는 install을 눌러서 Github application을 해준다.

그 후 내 Github repository를 검색 및 선택해준 후 import 해온다.

그 다음 project 기본 설정을 해주면 배포 준비는 완료된다.

이렇게 하면 끝! 어때요 정말 쉽~죠? 😄

배포된 사이트 방문해서 확인해보기

화면 속 Visit을 누르면 배포된 사이트 확인이 가능하다.

짜잔~

느낀점

배포라는 것을 어렵게만 생각했던 지금까지의 생각이 완전히 바뀌는 경험이었다. 기술이 발전함에 따라 이렇게 많은 이점이 생긴다는 것이 놀라웠고, 왜 개발자가 평생 배워야하는 직업인지를 깨닫게 되었다. 앞으로 배포하는 과정을 지인이나 후배들에게 가르쳐줄 때 Vercel을 활용해보라고 추천해 줘야겠다!😆

참고자료

• Next.js 공식 튜토리얼 페이지 https://nextjs.org/learn/dashboard-app/setting-up-your-database

개발 과정

Node.js용 papago API 사용 예제

네이버가 아주 친절하게 사용 예제를 정리해놨다. request라는 모듈로 API요청을 한 것 같은데, 뭔지는 알고 지나가야할 것 같다는 생각에 구글링을 해봤다.

이런.. 2020년부터 deprecated 되었다고 한다. '더 이상 사용되지 않는, 사라지게 될'이라는 뜻이다.

눈 앞이 깜깜해졌다. 그렇다면 나는 이 코드를 수정해서 API 요청을 해야했다. 마음을 가다듬고 API 요청하는 방법부터 차근차근 공부해보기로 했다.

express에서 API 요청 보내기

맨 처음엔 express에서 API 요청 보내는 방법이 따로 있는 줄 알았다. 항상 프론트엔드단에서 axios로 API 요청을 보내다가 서버에서 API 요청을 보내려니 기분이 묘했다.

express에서 API 요청보내는 법을 구글링해보니 온통 express'로' API 요청 보내는 글만 나와서 당황스러웠다.

'그래도 js 기반이니까 fetch로 하면 되겠지'라는 생각에 fetch API를 사용해보기로 했다. (익숙한 axios를 사용해서 편하게 요청해도 됐지만 fetch라는 기본적인 함수를 공부하고 싶어서 fetch를 사용했다.)

fetch 함수 사용법을 구글링하니 잘 정리된 글들이 많았다. 덕분에 어렵지 않게 fetch를 사용할 수 있었다.

fetch 함수는 axios 라이브러리와 다르게 body에 들어가는 data를 JSON 문자열로 바꿔줘야 한다는 귀찮음이 있다(JSON.stringify 활용).

일단 간단하게 fetch 함수 활용법은 알게 됐고, 이제 request 모듈 사용을 가정한 네이버 사용 예제를 fetch 함수에 맞게 바꿔야 하는 과정이 남았다.

fetch함수를 활용한 papago API 요청

이 단계에서 살짝 뇌정지가 왔다. 헤더를 어떻게 설정해야하는지, x-www-form-urlencoded는 무엇인지 등 너무 복잡해 보였기 때문이다.

일단 먼저 Content-Type: application/x-www-form-urlencoded 라는게 뭘 뜻하는지 알아봤다.

Content-Type: application/x-www-form-urlencoded 란?

간단하게 설명하자면 request 요청 속 body 데이터의 자료형이다.

클라이언트와 서버가 데이터를 주고 받을 땐 그냥 주고받지 않는다. 문자열 데이터로 바꿔서 주고 받는다.

클라이언트는 정해진 규칙에 따라 데이터를 문자열로 바꿔서 전달하고, 서버는 바뀐 자료형을 인식하고 그에 맞게 해석해서 데이터를 사용한다.

이때 request 요청의 header라는 부분에 '우리가 ~ 형식으로 데이터 변환했으니까 알고있으세요'라는 메세지를 남기는데 그게 바로 Content-Type이다. Content-Type엔 application/json도 있고 multipart/form-data 등 여러가지가 있다. (요즘 많이 쓰이는 건 application/json 타입이다.)

Content-Type: application/x-www-form-urlencoded

는 x-www-form-urlencoded라는 형식으로 데이터를 변환했다는 것을 서버에게 알려준다.

x-www-form-urlencoded는 key=value 형식으로 데이터를 보내야하기 때문에 객체형 데이터를 key=value 형식으로 변환해주는 qs 라이브러리를 install해서 사용하였다. (query string의 줄인말)

qs의 사용법은 간단하다. JSON.stringify처럼 qs.stringify에 객체형 자료를 인수로 전달하면 된다.

{ source: "ko", target: "en", text: query}

"source=ko&target=en&text=만나서 반갑습니다. 앞으로 잘 부탁드립니다."

이런 식으로 객체형 자료가 문자열로 바뀐다.

npm qs 문서 링크

fetch 함수 작성

let query = "만나서 반갑습니다. 앞으로 잘 부탁드립니다.";
app.get('/translate', function (req, res) {
  const api_url = 'https://openapi.naver.com/v1/papago/n2mt';
  const data = qs.stringify({ source: "ko", target: "en", text: query },{ encode: false })
  console.log(data);
  const opt = {
    method: "POST",
    headers: {
      'Content-Type' : 'application/x-www-form-urlencoded; charset=UTF-8',
      'X-Naver-Client-Id': client_id,
      'X-Naver-Client-Secret': client_secret
    },
    body: encodeURI(data)
  }
  fetch(api_url, opt)
    .then((res) => {
      console.log(res.body);
    })
    .catch((err) => {
      console.error(err)
    })
});

application/x-www-form-urlencoded라서 encode 해줘야 되는줄 알고 encodeURI()를 통해 data를 encode했다. (나중에 확인해보니 encode를 안 해도 응답이 잘 왔다. fetch 함수가 알아서 encoding을 해주는 것 같다.)

일단은 이렇게 fetch함수를 작성해봤다. papago로 번역된 결과를 콘솔창에서 확인해보자.

ReadableStream 데이터 읽기

번역된 결과를 확인하려고 res.body를 출력해봤는데 콘솔창에

ReadableStream { locked: false, state: 'readable', supportsBYOB: false }

이런 결과가 나왔다...

분명 응답의 body를 console.log로 출력했는데, ReadableStream이라는 이상한 데이터가 출력된 것이다.

구글링한 결과 json()함수를 사용해서 ReadableStream을 파싱하면 데이터를 제대로 확인할 수 있다는것을 알게됐다.

fetch(api_url, opt)
    .then(async (res) => {
      console.log(await res.json());
    })
    .catch((err) => {
      console.error(err)
    })

json()함수는 response를 리턴하는 비동기 함수이다. 따라서 async await으로 비동기처리를 하지 않으면 Response가 출력되는 일이 발생한다. 항상 주의하자.

stack overflow - readablestream object 링크

짜잔~ 번역결과를 정상적으로 확인할 수 있게 되었다.

Content-Type: application/json으로 해도 정상 작동

Content-Type을 application/json 바꿔도 잘 작동하는 지 궁금해서 확인해봤다. 데이터 형식을 json으로 변환하고 요청을 보냈더니 잘 작동하는 걸 확인할 수 있었다.

let query = "만나서 반갑습니다. 앞으로 잘 부탁드립니다.";
app.get('/translate', function (req, res) {
  const api_url = 'https://openapi.naver.com/v1/papago/n2mt';
  const data = JSON.stringify({ source: "ko", target: "en", text: query})
  console.log(data);
  const opt = {
    method: "POST",
    headers: {
      'Content-Type' : 'application/json; charset=UTF-8',
      'X-Naver-Client-Id': client_id,
      'X-Naver-Client-Secret': client_secret
    },
    body: data
  }
  fetch(api_url, opt)
    .then(async (res) => {
      console.log(await res.json());
    })
    .catch((err) => {
      console.error(err)
    })
});

데이터 형식이 요청을 보낼 때 크게 중요한 것 같지는 않다. header에 잘 명시해놓으면 서버가 알아서 변환을 하는 것 같다.

최종코드

Content-Type: x-www-form-urlencoded 일때

express, qs 모듈 install은 필수이고 dotenv 모듈은 선택사항이다.

client_id와 client_secret를 직접 입력하려면 상관없는데, 나는 보안성을 위해 .env파일에 저장한 뒤 dotenv모듈을 사용해서 가져왔다.

const express = require('express');
const app = express();
const qs = require('qs');
require("dotenv").config();

app.listen(8080, () => {
  console.log('8080 포트에서 서버 실행중');
})

const client_id = process.env.PAPAGO_CLIENT_ID;
const client_secret = process.env.PAPAGO_CLIENT_SECRET
let query = "만나서 반갑습니다. 앞으로 잘 부탁드립니다.";
app.get('/translate', function (req, res) {
  const api_url = 'https://openapi.naver.com/v1/papago/n2mt';
  const data = JSON.stringify({ source: "ko", target: "en", text: query})
  console.log(data);
  const opt = {
    method: "POST",
    headers: {
      'Content-Type' : 'application/json; charset=UTF-8',
      'X-Naver-Client-Id': client_id,
      'X-Naver-Client-Secret': client_secret
    },
    body: data
  }
  fetch(api_url, opt)
    .then(async (res) => {
      console.log(await res.json());
    })
    .catch((err) => {
      console.error(err)
    })
});

Content-Type: application/json 일 때

const express = require('express');
const app = express();
require("dotenv").config();
app.listen(8080, () => {
  console.log('8080 포트에서 서버 실행중');
})

const client_id = process.env.PAPAGO_CLIENT_ID;
const client_secret = process.env.PAPAGO_CLIENT_SECRET
let query = "만나서 반갑습니다. 앞으로 잘 부탁드립니다.";
app.get('/translate', function (req, res) {
  const api_url = 'https://openapi.naver.com/v1/papago/n2mt';
  const data = JSON.stringify({ source: "ko", target: "en", text: query})
  console.log(data);
  const opt = {
    method: "POST",
    headers: {
      'Content-Type' : 'application/json; charset=UTF-8',
      'X-Naver-Client-Id': client_id,
      'X-Naver-Client-Secret': client_secret
    },
    body: data
  }
  fetch(api_url, opt)
    .then(async (res) => {
      console.log(await res.json());
    })
    .catch((err) => {
      console.error(err)
    })
});

express에서 papago API를 활용하려는 분들에게 도움이 됐으면 좋겠다.

참고자료

• 네이버 파파고 api 문서 https://developers.naver.com/docs/papago/README.md

• fetch 함수 사용법 https://www.daleseo.com/js-window-fetch/

• x-www-form-urlencoded 타입 https://wildeveloperetrain.tistory.com/304

vite를 통해 react앱을 만들고 로컬 환경에서 express로 서버를 구축하던 중 오류가 발생했다.

바로 __dirname이 정의되지 않았다는 것이다.

    app.use(express.static(path.join(__dirname, '/dist')))

이 코드에서 문제가 발생했는데, dist라는 디렉터리를 express에 등록하는 코드이다.

vite로 build를 할 경우 루트 디렉터리 내에 dist라는 디렉터리가 생기고, 그 안에는 index.html, 이미지 파일과 같은 정적인(static) 파일이 저장된다. 이 디렉터리를 express가 전송해주기 위해선 먼저 등록하는 과정이 필요한데, 나는 그 과정에서 오류가 발생한 것이다.

원인

구글링 하던 중 원인과 해결방법을 찾을 수 있었다.

ES module을 사용하면 __dirname을 '그냥' 사용할 수 없다는 것이다.

"target": "ES2020",
"useDefineForClassFields": true,
"lib": ["ES2020", "DOM", "DOM.Iterable"],
"module": "ESNext",
"skipLibCheck": true,

tsconfig.json파일의 내용 중 compilerOptions 일부분을 가져온 것이다. 코드를 보면 ESNext라는 module을 사용하고 있다는 것을 알 수 있다.

해결방법

코드 2줄을 server.js파일 상단에 추가했다.

import path from 'path';
import { fileURLToPath } from 'url';

파일이나 디렉터리 경로를 다루는 path모듈과 일반적인 파일 url을 Node.js 파일 path로 바꿔주는 fileURLToPath 함수를 가져온다.

fileURLToPath 함수란?

다음은 fileURLToPath 함수에 관한 공식문서이다.

url을 입력받으면 (완전히 플랫폼 문제가 해결된) 특정한 Node.js 파일 경로를 리턴해준다고 한다.

그 다음 하단에 코드 2줄을 추가한다.

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

1. server.js의 파일url을 가져와서 fileURLToPath로 경로 변환해서 __filename에 저장하고
2. 변환된 경로의 디렉터리 경로를 __dirname에 저장한다.

이렇게 코드를 작성하면 오류가 해결되는데, 도대체 어떤 과정을 거쳐 해결되는지 궁금해서 더 알아봤다.

import.meta.url은 어떤 값일까?

server.js의 경로를 저장하고 있는건 맞는데, 앞에 file:///가 붙어있다. 아마 이를 제거하기 위해 fileURLToPath함수를 사용하는 것 같다.

그럼 __filename, __dirname에는 어떤 값이 저장될까?

console.log로 __filename과 __dirname을 출력해보면 다음과 같은 결과를 얻는다.

• __filename에 저장된 값 C:\Users\user\Desktop\Programing\nodejs-study\my-blog-app\server.js

• __dirname에 저장된 값 C:\Users\user\Desktop\Programing\nodejs-study\my-blog-app

결론적으로 fileURLToPath(import.meta.url)을 통해 서버 파일의 경로, 즉 server.js의 경로를 가져온 후, path.dirname(__filename)을 통해 그 파일이 포함된 디렉토리를 찾아서 경로를 반환하는 것을 알 수 있다.

이를 통해 정상적으로 __dirname을 사용할 수 있게 됐다.

참고자료

• __dirname 오류 원인과 해결방법 https://flaviocopes.com/fix-dirname-not-defined-es-module-scope/

• fileUrlToPath함수 관련 Node.js 공식 문서 https://nodejs.org/api/url.html#urlfileurltopathurl

아쉬웠던 점

1. 적극적으로 질문을 하지 못한 것

내가 참여했던 부트캠프는 하나부터 열까지 친절하게 알려주는 부트캠프가 아니었다. 모르는 건 직접 찾아보고, 물어보고, 적용해보며 실전으로 배우는 과정이었다. 나는 원래 혼자서 고민하고 공부하는 걸 좋아해서 질문을 거의 안 했다. 질문 개수를 세자면 열 손가락으로 셀 수 있을 정도? 사람들이 내가 모르는 것에 대해 얘기할 때도 잘 물어보지 않고 구글에 검색해서 그 뜻을 알아냈다. 나는 그런 과정이 즐거웠고, 검색하면 다 나와서 물어볼 필요성을 못 느꼈다.

그런데 부트캠프가 끝나고 돌아보니 질문을 잘 하는 것도 개발자로서의 중요한 능력 중 하나인데 내가 그 능력을 키울 좋은 기회를 날렸다는 생각이 들었다. 6주라는 짧은 기간동안 프로젝트를 완성해야 했기에 1분 1초가 아까운 상황에서 나 혼자 즐겁다는 이유로 에러에 대해 3시간 이상 주구장창 고민했으면 안 됐다. 부트캠프에 참여하신 멘토님이 이런 말씀을 하셨다. '모르는 게 있을 때 너무 많이 고민하지 말고 질문을 해라' 이런 식으로 말이다. 질문을 잘 하는 법까지 친절히 알려주셨는데, 그걸 활용해보지 못한게 아쉽다. 앞으로는 의식적으로 질문을 하도록 노력해야겠다.

2. 팀원 간의 커뮤니케이션

내가 속한 팀은 뭔가 커뮤니케이션이 잘 안 되는 느낌이 들었다. 음 그냥 서로 얘기를 잘 안 했던 것 같다. 한 예로, 나는 프론트엔드를 맡았었는데, 백엔드 쪽에서 api 변경사항이 생겼는데도 변경사항을 전달받지 못한 경우가 있었다. 에러 로그가 떠서 나 혼자 console.log를 찍어보며 response data가 바뀌었다는 걸 파악하고 백엔드 분들에게 물어보자 그제야 변경사항이 있었는데 말 못해서 미안하다라는 말을 들을 수 있었다. 커뮤니케이션의 부재가 팀 전체의 효율성을 낮추는 결과를 낳았다.

그리고 팀의 프로젝트 방향성을 정할 때마다 적극적으로 의견을 냈어야 했는데, '나는 잘 모르니까, 실력이 부족하니까'와 같은 생각 때문에 다른 분들이 내는 의견에 그냥 동참했던 경우가 종종 있었다. '내 의견을 좀 더 용기있게 말했으면 어땠을까'라는 아쉬움이 남는다.

내가 만약 팀을 이끄는 리더가 된다면 이런 상황이 발생하지 않도록 자유로운 커뮤니케이션 분위기를 만들 것이다. 자신의 의견을 마음껏 표현할 수 있게 내가 먼저 의견을 적극적으로 낼 것이고, 의견을 잘 내지 않는 팀원에게는 직접 의견을 물어봐서 프로젝트 참여를 이끌어 낼 것이다. 또한, 커뮤니케이션 미스가 생기지 않도록 메뉴얼을 만들어 팀의 효율성을 높일 것이다. 예를 들어, '변경사항이 생길 때는 먼저 보고 하고 문서화 제대로 반영하기', '깃허브 풀리퀘스트 날릴 때 수정사항 상세히 작성하고, 코드리뷰 코멘트 작성해주기'와 같이 말이다.

배운 점

1. 공부 습관

매일 아침 10시부터 새벽 3~4시까지 하루종일 코딩을 하는 걸 3주 정도 했을 때쯤, 뇌의 변화가 느껴졌다. 이게 이상하게 들릴지도 모르지만 뭔가 두뇌회전이 빨라졌고, 새로운 내용을 배울 때 더 빨리 이해가 되는 느낌이 들었다. 이전까지는 이런 기분을 느껴본 적이 없었는데, 정말 신기한 경험이었다. 그 당시 '몰입'이라는 책을 읽었는데, 책에서 말하는 몰입상태에 들어간 듯했다. 종일 코딩 생각만 하고 코딩만 했으니 몰입 상태에 들어갈 수밖에 없었나보다.

아쉽게도 그 느낌은 3주차 이후로는 느낄 수 없었다. 처음의 열정이 3주차 이후까지 이어지지 못했기 때문이다. 처음엔 새로 배울 것도 많고 배운 것을 프로젝트에 적용하는 재미가 있어서 열정적으로 코딩을 했는데, 주차가 지나갈수록 새로운 걸 적용하기보다는 오류를 수정하는 작업이 많아졌기 때문이다.

결론적으로, 3주차때 느꼈던 기분을 가진채로 쭉 공부를 이어 나간다면 나 자신이 확실하게 변할 것 같다는 생각이 들었다. 이번 부트캠프를 통해 얼마나 공부해야 변화를 만들어 낼 수 있는지 알게됐다. 앞으로 꾸준히 부트캠프 때의 공부습관을 버리지 않고 이어나갈 생각이다.

2. 공부 방향

프로젝트의 기획부터 개발, 배포까지의 전 과정을 거쳤기 때문에, 내가 뭘 모르는 지 알게됐고, 나 혼자서도 서비스를 개발해서 배포까지 할 수 있겠다는 자신감이 생겼다.

일단 지금 당장 내가 해야할 공부는 백엔드 공부다. 백엔드 프레임워크와 데이터베이스를 공부하고 그 이후엔 docker 띄우기, AWS 서버 개설, CI/CD 적용 등의 devops 과정까지 공부해볼 생각이다.

만약 부트캠프를 하지 않았다면 이런 배포까지의 전 과정을 알 수 없었을 것이고, 개발과정의 큰 그림을 보지 못한 채로 어영부영 시간만 날렸을 것이다. 하지만 부트캠프 덕분에 공부 계획을 세밀하게 작성할 수 있게 되었다.

3. 공부 방법

이 부트캠프는 학생들이 기존의 이론중심의 개발에서 벗어나 잘 모르더라도 일단 어떻게든 프로그램을 만들어보면서 배우는 공부방법을 알려준다. 이게 정말 효과적인게, 일단 재밌다. 잘 모르더라도 코드에 적용했을 때 프로그램이 동작하는 걸 보니까 흥미가 생기고, 내가 이 내용을 적용했을 땐 프로그램이 이렇게 동작하는 구나를 눈으로 확인할 수 있어서 좋았다.

앞으로 새로운 개발 지식을 공부할 때, 두꺼운 책을 처음부터 끝까지 보고 나서 개발을 시작하는 게 아니라, 일단 개발을 시작하고 모르는 게 나오면 구글링을 하거나 유튜브, 책 등의 자료를 참고하는 방식으로 공부해야 겠다고 느꼈다.

앞으로의 다짐

부트캠프에 참여하며 내가 얼마나 실력이 부족한지 알게되었다. 계속해서 새로운 걸 배우고 어려운 일에 도전하는 마인드를 가져야겠다.

개발을 하며 겪었던 일들을 기록하고 성장하기 위해 velog 계정을 만들어 첫 글을 써봤는데, 글쓰는 건 역시 어렵다. 계속 써봐야 감을 잡을 것 같다.