백엔드 개발자 면접준비 4탄

강신찬·2022년 12월 13일
207

✔ 인증 / 보안

1번 - 인증과 인가의 차이에 대해 설명해 주세요.

  • 인증(Authentication)
    • 신원을 검증하는 행위
    • 인증프로세스(비밀번호, 일회용 핀, 인증 앱, 생체인식 등)을 구성하여 1가지 이상이 성공적으로 확인되어야만 시스템에 엑세스가 가능.
  • 인가(Authorization)
    • 사용자에게 특정 리소스나 기능에 엑세스할 수 있는 권한을 부여하는 프로세스
    • 엑세서 제어 혹은 클라이언트 권한

참고자료 https://www.okta.com/kr/identity-101/authentication-vs-authorization/

2번 - 세션에 대해서 모르는 사람한테 설명하듯 간단하게 설명해 주세요.

  • 네이버의 세션에 대한 정의
    • 망 환경에서 사용자 간 또는 컴퓨터 간의 대화를 위한 논리적 연결.
    • 프로세스들 사이에서 통신을 하기 위해 메시지 교환을 통해 서로를 인식한 이후부터 통신을 마칠 때까지의 기간.
  • 세션이란
    • 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술
    • 일정시간: 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점으로부터 웹 브라우저를 종료함으로써 연결을 끝내는 시점
  • 방문자가 웹서버에 접속해 있는 상태를 하나의 단위로 보고 세션이라고 칭함

3번 - 세션과 쿠키 그리고 토큰 인증 방식에 대해 설명해 주세요.

  • 쿠키
    • 쿠키의 경우는 방문자의 정보를 방문자 컴퓨터의 메모리에 저장
    • ex) ID나 비밀번호를 저장하거나 방문한 사이트를 저장하는데에 사용
  • 세션
    • 방문자의 요청에 따른 정보를 방문자 메모리에 저장하는 것이 아닌 웹 서버가 세션 아이디 파일을 만들어 서비스가 돌아가고 있는 서버에 저장
  • 쿠키와 달리 세션은 사용자들의 로그인 정보에 대한 보안을 한층 업그레이드 할 수 있어 웹사이트에 방문하여 계속 접속을 유지할 때 이전의 접속 정보를 이용할 수 있는 방법

참고자료 https://88240.tistory.com/190

  • 토큰인증방식
    • 토큰을 왜쓰죠?
      • 보안성! 더 이상 쿠키 전달 안해! 보안이 조금 낫다.
      • 하지만 토큰을 탈취당한다면...눈물.. -> 유효기간 설정
      • 유효기간이 끝나면 새로운 Access토큰을 받는다.
      • 세션에 단점 극복!!(서버 여러대 일 경우) -> 무상태&확장성
    • Access Token과 Refresh Token
      • Access Token(JWT) 인증 방식은 탈취당하면 너무 위험하다. 그래서 유효기간을 주지만... 유효기간이 길면 보안이 취약하고 짧으면 불편하고 크..
      • 그래서 나온것이 Refresh Token!
      • Access Token과 동시에 발급되지만 유효기간을 길게 주고 안전한 곳(Local Storage같은..?)에 저장한다. API 요청 시 Access Token이 만료되었다면 바로 Refresh Token을 서버로 보냄으로써 Access Token을 다시 받을 수 있다.
      • 잠깐! Refresh Token 털리면 끝 아님??
      • API 요청 시마다 HTTP통신으로 노출되는 Access Token과 달리 Refresh Token은 Access Token이 만료 되었을 경우에만 보내기 때문에 빈도수의 차이로 탈취될 위험이 훠어어얼씬 적다.

4번 - 세션과 토큰 인증 방식 중 각각의 장단점을 말씀해 주세요.

  • 차이점1. 사이즈
  • 차이점2. 안전성
    • 세션
      • 세션은 서버측에서 저장/관리하기 때문에 상대적으로 온전한 상태를 유지하기에 유리
      • 하지만 공격의 위험은 있어 유효기간, HttpOnly,Secure 옵션 등을 주어 쿠키에 저장
    • 토큰
      • 웹 브라우저측에 저장되기 때문에 공격노출 가능성 높음.
      • 민감한 정보는 토큰에 넣으면 안됨.
      • 유효기간을 짧게 해서 공격 노출 최대 방어
      • 짧은 유효기간 너무 귀찮. 고로 로그인시 refresh token 추가 발급.
  • 차이점3. 확장성
    • 세션 <<<< 토큰
    • 세션은 서버에 저장 되기 때문에 다중 접속자 발생 시 과부하 -> scale out? -> 세션 어디 들어가 있어 -> 혼돈

      출처 https://fierycoding.tistory.com/69

    • 세션용 서버를 두거나 sticky session, session clustering같은 방안이 나오기도 했지만 비용 발생 등이 문제

5번 - HTTP와 HTTPS 각각에 대해 설명하고둘의 차이점을 말씀해 주세요.

  • HTTP(Hyper Text Transfer Protocol)
    • 서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜
    • HTTP는 인터넷에서 하이퍼텍스트를 교환하기 위한 통신 규약으로 80번 포트를 사용하고 있음.
    • HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP위에 작동한다. HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성된다.

      https://mangkyu.tistory.com/98

    • 단점
      • HTTP는 암호화되지 않은 평문 데이터 전송 프로토콜로 비밀번호나 주민등록번호같은 민감정보를 제3자가 조회가능하다. 그래서 등장 -> HTTPS (S에 주목하도록 하자)
  • HTTPS(Hyper Text Transfer Protocol Secure)
    • HTTP에 데이터 암호화가 추가된 프로토콜
    • 443번 포트를 사용
    • 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 암호화
    • 대칭키 암호화와 비대칭키 암호화를 사용하여 동작
    • 대칭키 암호화
      • 클라이언트와 서버가 동일한 키를 사용해 암호화/복호화 진행
      • 키가 노출되면 매우 위험하지만 연산 속도가 빠름
    • 비대칭키 암호화
      - 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용
      - 키가 노출되어도 비교적 안전하지만 연산 속도가 느림
      - 비대칭키 암호화는 공개키/개인키 암호화 방식을 이용해 데이터를 암호화(공개키와 개인키는 서로를 위한 1쌍의 키)
      - 공개키: 모두에게 공개가능한 키
      - 개인키: 나만 가지고 알고 있어야 하는 키
      - 공개키 암호화
      - 공개키로 암호화를 하면 개인키로만 복화화 가능 -> 개인키는 나만 가지고 있으므로 나만봐
      - 개인키로 암호화하면 공개키로만 복호화 가능 -> 공개키는 모두에게 공개되어 있으므로 내가 인증한 정보임을 알려 신뢰성 보장

      출처 https://mangkyu.tistory.com/98

6번 - HTTPS의 동작 방식을 설명해 주세요.

  • HTTPS는 대칭키 암호화와 비댕칭키 암호화를 모두 사용하여 빠른 연산 속도와 안전성을 모두 가지고 있음.

  • HTTPS 연결과정(Hand-Shaking)에서는 먼저 서버와 클라이언트 간에 세션키를 교환한다. 여기서 세션키는 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키이며, 데이터 간의 교환에는 빠른 연산속도가 필요하므로 세션키는 대칭키로 만들어진다.

  • 이 세션키를 클라이언트와 서버가 대칭키로 교환한다.

  • 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 대칭키가 사용되는 것이고 이후에 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용되는 것이다.

    출처 https://mangkyu.tistory.com/98

  • 실제 HTTPS 연결과정이 성립되는 흐름

    1. 클라이언트(브라우저)가 서버로 최초 연결 시도를 함.
    2. 서버는 공개키(엄밀히는 인증서)를 브라우저에게 넘김.
    3. 브라우저는 인증서의 유효성을 검사하고 세션키를 발급함.
    4. 브라우저는 세션키를 보관하며 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송함.
    5. 서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻음.
    6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화/복호화를 진행함.

      출처 https://mangkyu.tistory.com/98

7번 - OAuth 2.0의 워크플로우에 대해서 설명해 주세요.

8번 - Spring Security의 인증(Authentication) 처리 흐름에 대해 설명해 주세요.

사용자가 로그인 정보와 함께 인증 요청을 합니다. 이 요청을 AuthenticationFilter가 요청을 가로채고, 가로챈 정보를 통해 UsernaemPasswordAuthenticationToken의 인증용 객체를 생성합니다. Authuenticion Manager의 구현체인 ProviderManger에게 생성한 UssernamePasswordToken 객체를 전달합니다. AuthenticationManger는 등록된 AuthenticationProvider를 조회하여 인증을 요구합니다. Provider는 UserDetials를 넘겨받고 사용자 정보를 비교합니다. 인증이 완료되면 권한등의 사용자 정보를 담은 Authentication 객체가 반환 됩니다. Authentication 객체를 SecurityContext에 저장합니다.

인증 절차는 실제로 이러한 흐름을 진행된다고한다.

  1. 사용자가 로그인 정보와 함께 인증 요청을 한다.(Http Request)
  2. AuthenticationFilter가 요청을 가로채고, 가로챈 정보를 통해UsernamePasswordAuthenticationToken의 인증용 객체를 생성한다.
  3. AuthenticationManager의 구현체인 ProviderManager에게 생성한UsernamePasswordToken 객체를 전달한다.
  4. AuthenticationManager는 등록된 AuthenticationProvider(들)을 조회하여 인증을 요구한다.
  5. 실제 DB에서 사용자 인증정보를 가져오는 UserDetailsService에 사용자 정보를 넘겨준다.
  6. 넘겨받은 사용자 정보를 통해 DB에서 찾은 사용자 정보인 UserDetails 객체를 만든다.
  7. AuthenticationProvider(들)은 UserDetails를 넘겨받고 사용자 정보를 비교한다.
  8. 인증이 완료되면 권한 등의 사용자 정보를 담은 Authentication 객체를 반환한다.
  9. 다시 최초의 AuthenticationFilter에 Authentication 객체가 반환된다.
  10. Authenticaton 객체를 SecurityContext에 저장한다.
  • SecurityContextHolder는 세션 영역에 있는 SecurityContext에 Authentication 객체를 저장. 세션에 정보를 저장한다는 것은 전통적인 세션-쿠키 기반의 인증 방식을 사용한다는 것을 의미

인증 처리

이제 본격적으로 인증이 어떠한 과정으로진행되는지 처리 순서에 대한 흐름을 알아보자.

출처 https://mycatlikeschuru.github.io/

9번 - Spring Security의 인가(권한 부여, Authorization) 처리 흐름에 대해 설명해 주세요.

Spring Security에서 권한 부여를 위해 authiztion필터 클래스를 이용해 처리합니다. 권한 부여필터는 먼저 Securtiy Context Holder로 부터 Authenitcation을 획득합니다. 획득한 인증과 HTttp 서블렛 리퀘스트를 매니저에게 전달합니다. 매니저는 구너한 부여 처리를 총괄하는 매니저 역할을 하는 인터페이스이고, 리퀘스트 매쳐 딜리게이팅 어써리제이션 메니저는 AuthriztionManger를 구현하는 구현체 중에 하나이빈다. RequestMatherDeligatingAuthizaionManger는 리퀘스트 메쳐 평가식을 기반으로 해당 평가시에 매치되는 메니저에서 권한 부여 처리를 위임하는 역할을 하며, 내부에서 매치되는 구현클래스가 있다면 해당 매니저를 구현 클래스가 사용자의 권한을 체크합니다. 적절하면 다음 요청 프로세슬를 이어가고, 아니라면 AcesssDeninedExpetion이 던져 ㄷExcetption Translateiton Filter가 입세션 처리를 합니다.

권한부여 처리흐름

AuthorizationFilter

출처 https://mycatlikeschuru.github.io/

Spring Security에서는 권한 부여를 위해AuthorizationFilter 클래스를 이용해 처리를 한다.

  • Spring Security Filter Chain에서 URL을 통해 사용자의 액세스를 제한하는 권한 부여 Filter는 바로 AuthorizationFilter입니다.
  • AuthorizationFilter 는 먼저 SecurityContextHolder로 부터 Authentication을 획득합니다.
  • SecurityContextHolder로 부터 획득한Authentication과 HttpServletRequest를 AuthorizationManager 에게 전달합니다.
  • AuthorizationManager 는 권한 부여 처리를 총괄하는 매니저 역할을 하는 인터페이스이고, RequestMatcherDelegatingAuthorizationManagerAuthorizationManager 를 구현하는 구현체 중 하나입니다. RequestMatcherDelegatingAuthorizationManager 는 RequestMatcher 평가식을 기반으로 해당 평가식에 매치되는 AuthorizationManager 에게 권한 부여 처리를 위임하는 역할을 합니다. ⭐ RequestMatcherDelegatingAuthorizationManager 가 직접 권한 부여 처리를 하는 것이 아니라 RequestMatcher를 통해 매치되는 AuthorizationManager 구현 클래스에게 위임만 합니다.
  • RequestMatcherDelegatingAuthorizationManager 내부에서 매치되는 AuthorizationManager 구현 클래스가 있다면 해당 AuthorizationManager 구현 클래스가 사용자의 권한을 체크합니다
  • 적절한 권한이라면 (4)와 같이 다음 요청 프로세스를 계속 이어갑니다.
  • 만약 적절한 권한이 아니라면 (5)와 같이 AccessDeniedException이 throw되고 ExceptionTranslationFilterAccessDeniedException을 처리하게 됩니다.

10번 - Filter가 무엇인지 설명하고 Filter Chain의 동작에 대해 설명해 주세요.

서블릿 필터는 자바에서 제공하는 API이며, javax.servlet 패키지에 인터페이스 형태로 정의되 있습니다. 필터 인터페이스를 구현한 서블릿 필터는 웹 요청을 가로채어 전처리를 할 수 있으며, 또한 엔드포인트에서 요청처리가 끝난 후 전달되는 응답을 클라이언트에게 전달하기 전에 후처리를 할 수 잇습니다. 서블릿 필터는 하나 이상의 필터들을 연결해 필터 체인을 구성할 수 있습니다. 각각의 필터들이 doFilter()라는 메서드를 구현해야하며, doFilter()매서드 호출을 통해 필터 체인을 형성하게 됩니다.

Spring Security Filter

출처 https://urclass.codestates.com/content/3cbfcde0-c4a0-4a24-a45c-2b6b2c837531?playlist=2337

  • 다양한 필터체인 통해 커스터마이징 가능
  • SecurityContextPersistentFilter : SecurityContextRepository에서 SecurityContext를 가져와서 SecurityContextHolder에 주입하거나 반대로 저장하는 역할
  • LogoutFilter : logout 요청 감시, 인증 주체 로그아웃
  • UsernamePasswordAuthenticationFilter : login 요청 감시, 인증 과정 진행
  • DefaultLoginPageGenerationFilter : 사용자가 별도의 로그인 페이지 구현하지 않으면, 스프링에서 기본적으로 설정한 로그인 페이지로 넘어감
  • BasicAuthenticationFilter : HTTP 요청의 인증 헤더를 처리하여 결과를 SecurityContextHolder에 저장

✔ Cloud

13번 - CI/CD가 무엇이라고 생각하시나요? CI와 CD의 차이점이 무엇인지 설명해 주세요.

1차

요? CI와 CD의 차이점이 무엇인지 설명해 주세요.
CI/CD는 애플리케이션 개발 단계를 자동화 하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법입니다. CI는 개발바를 위한 자동화 프로세스인 지속적 통합 continuous integartion의 약자입니다. 지속적인 통합이 제대로 구현되면 애플리케이션코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합됩니다. CD는 지속적인 서비스 제공및 지속적인 배포를 의미하며 이 두 요어는 상호 교환하여 사용됩니다. 두 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이뤄지는지 설명하기 위해 별도로 사용되기도합니다. (차이점???)

CI/CD란?

  • CI (Continuous Integration) 다수의 개발자가 작성·수정한 소스코드를 지속적으로 통합·테스트하는 것을 의미한다.
  • CD (Continuous Delivery/Deployment)란 개발, 통합, 배포, 릴리즈, 테스트를 자동화하여 지속적으로 배포하는 것을 의미한다.

전통적인 방식으로는 코드수정하고 배포하는데 까지 많은 시간이 소요되었다. 특히 QA테스팅에서 많은 버그가 발생되었다.

https://blog.oursky.com/wp-content/uploads/2019/08/image-1160x553.png

출처 https://blog.oursky.com/2019/08/19/how-to-build-cicd-pipeline/

CI/CD를 통해 지속적으로 통합·테스트·배포를 하고 이 흐름을 자동화하여 효율적으로 일을 처리할 수 있게 되었다.

https://blog.oursky.com/wp-content/uploads/2019/08/image-1-1160x571.png

출처 https://blog.oursky.com/2019/08/19/how-to-build-cicd-pipeline/

CI/CD 예시

  1. [Delfood] CI/CD 서버 구축과 첫 배포CI/CD의 이해하기 쉽도록 잘 정리된 적용사례이다. 개인적으로 만든 프로젝트를 배포한 경험에 관한 글을 볼 수 있다.

https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FAfO7u%2FbtqE1wewJny%2F2BBNTXLqwuEfgFMgPF6PHk%2Fimg.png

https://deveric.tistory.com/106

  1. 라인개발자가 작성한 CI/CD적용 글 : 데이터 기반으로 지속적인 CI/CD 개선 환경 만들기

CI와 CD(및 또 다른 CD)의 차이점

CI/CD는 약어로, 몇 가지의 다른 의미를 가지고 있습니다. CI/CD의 "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미합니다. 지속적인 통합이 제대로 구현되면 애플리케이션 코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합됩니다. 따라서 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌하는 문제를 이 방법으로 해결할 수 있습니다.

CI/CD의 "CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환하여 사용됩니다. 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 합니다.

지속적인 제공이란 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리(예: GitHub 또는 컨테이너 레지스트리)에 자동으로 업로드되는 것을 뜻하며, 운영팀은 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포할 수 있습니다. 이는 개발팀과 비즈니스팀 간의 가시성과 커뮤니케이션 부족 문제를 해결해 줍니다. 그러므로 지속적인 서비스 제공은 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 합니다.

지속적인 배포(또 다른 의미의 "CD": Continuous Deployment)란 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미합니다. 이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결합니다. 지속적인 배포는 파이프라인의 다음 단계를 자동화함으로써 지속적인 서비스 제공의 장점을 활용합니다.

https://www.redhat.com/cms/managed-files/styles/wysiwyg_full_width/s3/ci-cd-flow-desktop.png?itok=2EX0MpQZ

CI/CD는 지속적 통합 및 지속적 제공의 구축 사례만을 지칭할 때도 있고, 지속적 통합, 지속적 제공, 지속적 배포라는 3가지 구축 사례 모두를 의미하는 것일 수도 있습니다. 좀 더 복잡하게 설명하면 "지속적인 서비스 제공"은 때로 지속적인 배포의 과정까지 포함하는 방식으로 사용되기도 합니다.

결과적으로 CI/CD는 파이프라인으로 표현되는 실제 프로세스를 의미하고, 애플리케이션 개발에 지속적인 자동화 및 지속적인 모니터링을 추가하는 것을 의미합니다.

이 용어는 사례별로 CI/CD 파이프라인에 구현된 자동화 수준 정도에 따라 그 의미가 달라집니다. 대부분의 기업에서는 CI를 먼저 추가한 다음 클라우드 네이티브 애플리케이션의 일부로서 배포 및 개발 자동화를 구현해 나갑니다.

Red Hat 전문가가 고객이 조직 차원에서 더 효율적으로 기존 애플리케이션을 현대화하고 새로운 애플리케이션을 구축하는 데 필요한 사례와 툴을 개발하고 문화를 조성하도록 지원합니다.

지속적 배포

CI/CD 파이프라인의 마지막 단계는 지속적 배포입니다. 프로덕션 준비가 완료된 빌드를 코드 리포지토리에 자동으로 릴리스하는 지속적 제공의 확장된 형태인 지속적 배포는 애플리케이션을 프로덕션으로 릴리스하는 작업을 자동화합니다. 프로덕션 이전의 파이프라인 단계에는 수동 작업 과정이 없으므로, 지속적 배포가 제대로 이루어지려면 테스트 자동화가 제대로 설계되어 있어야 합니다.

실제 사례에서 지속적 배포란 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 클라우드 애플리케이션을 자동으로 실행할 수 있는 것을 의미합니다(자동화된 테스트를 통과한 것으로 간주). 이를 통해 사용자 피드백을 지속적으로 수신하고 통합하는 일이 훨씬 수월해집니다. 이러한 모든 CI/CD 적용 사례는 애플리케이션 배포의 위험성을 줄여주므로 애플리케이션 변경 사항을 한 번에 모두 릴리스하지 않고 작은 조각으로 세분화하여 더욱 손쉽게 릴리스할 수 있습니다. 그러나 자동화된 테스트는 CI/CD 파이프라인의 여러 테스트 및 릴리스 단계를 수행할 수 있어야 하기 때문에 많은 선행 투자가 필요합니다.

14번 - 본인이 구현해 본 CI/CD 배포 자동화 과정을 설명해 주세요.

우선 첫번째 단계로 codepipeline을 이용해서 각 단계를 연결하는 파이프 라인을 구축합니다.
Source 단계에서 소스 코드가 저장된 github 리포지토를 연결하여 수정후 push하면 빌드 단계로 넘어가게 됩니다. code build 서비스를 이용해서 빌드 후 ec2인스턴스로 빌드된 파일 이 전달되고 이 결과 문이 객체 스토리지 S3버킷에 저장되면 deploy단계로 codeDeploy 서비스를 이용하여 EC2 인스턴스에 변경 사항을 실시간으로 반영하게 됩니다.

Source 단계

  • 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우,이를 감지하고 다음 단계로 전달하는 작업 수행

2. Build 단계

  • Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공
  • Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업 수행

3. Deploy 단계

  • Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업 수행

출처 https://keumbi.github.io/

profile
꾸준히 공부하는 풀스텍 개발자

15개의 댓글

comment-user-thumbnail
2022년 12월 19일

벨로그 트렌드에 떠서 구경하러 왔슴미다 ~~
주어졌던 질문들 중 대부분의 것들을 정리해 놓으셨군요 !
멋지십니다 👍

1개의 답글
comment-user-thumbnail
2022년 12월 20일

이제부터 블로그의 왕은 신찬님입니다.

1개의 답글
comment-user-thumbnail
2022년 12월 20일

역시 트민남!! ㅎㅎㅎㅎ
블로거님이라고 불러드릴게요!!

1개의 답글
comment-user-thumbnail
2022년 12월 20일

아. 4빠..

1개의 답글
comment-user-thumbnail
2022년 12월 20일

신찬님 댓글 달려고 회원가입 했습니다. - 근본 2조 -

1개의 답글
comment-user-thumbnail
2022년 12월 23일
답글 달기
comment-user-thumbnail
2024년 6월 17일

저도 직장인인데 백엔드 취준 병행중이거든요..! 좋은 취준 팁 얻고 갑니다! 다른 사람들은 어떻게 공부하는지 궁금할 때 가끔 블로그 찾아보고 있는데 도움이 많이 됩니다~! 혹시 저처럼 직장 병행하느라 시간 부족하신 분들은 저랑 같이 공부해보시면 어떨까요..ㅎㅎ 저도 많이 부족하긴 하지만, 현직자분들이 직접 저녁까지 1:1로 코칭해주시거든요..!
고민 중이신 분들 있다면 한 번 들어와서 보셔요..!https://zrr.kr/G5Hr

1개의 답글
comment-user-thumbnail
2024년 7월 11일

좋은 글이네요 감사합니다!

1개의 답글