OAuth 2.0

• OAuth 2.0을 사용한다면 대부분의 로그인, 개인정보 관리 책임을 서드파티 애플리케이션 (Google, Facebook, Kakao 등)에게 위임할 수 있다. (단, 사용자가 기존에 서드파티 서비스에 회원가입이 되어있어야 함) 뿐만아니라 각 서드파티가 가지고 있는 사용자의 리소스를 조회 등을 내 애플리케이션에서 수행할 수 있다.

• Resource Owner : 리소스의 권한을 가진 사용자. 사용자 혹은 유저(User)라고도 한다. ex) 나몰닭 유저
• Client : 리소스 서버에 접근을 요청하는 어플리케이션 혹은 웹 사이트. 즉, 서비스를 제공자이며 Third Party Application 라고도 한다. ex) 나몰닭이 여기에 해당
• Authorization Server : 액세스 토큰(Access Token)을 클라이언트에게 발급해주는 서버. 인가의 주체. ex) 카카오톡, 구글, 네이버 등
• Resource Server : Authorization Server가 발급한 액세스 토큰(Access Token)을 확인하고 리소스를 제공. API 서버. ex) 이름, 나이 등 아이디 관련 정보(리소스)를 제공하는 서버. 카카오톡, 구글, 페이스북, Github 등

· Authorization Code Grant Type

•   클라이언트가 사용자 대신 특정 리소스에 접근을 요청할 때 사용된다. 클라이언트는 Access Token을 발급 받기 전, 인가코드(Authorization Code)를 사용자에 의해 받게 되고, 그 인가코드(Authorization Code)를 가지고 인가 서버(Authorization Server)에 요청을 보내면 리소스에 대한 Access Token을 발급 받을 수 있다.

Redis Refresh Token 

• JWT는 발급한 후 삭제가 불가능하기 때문에, 접근에 관여하는 토큰에 유효시간을 부여하는 식으로 탈취 문제에 대해 대응을 하여야 한다.
• 이처럼 토큰 유효기간을 짧게하면 토큰 남용을 방지하는 것이 해결책이 될 수 있지만, 유효기간이 짧은 Token의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편하다는 단점이 있다. 그렇다고 무턱대고 유효기간을 늘리자면, 토큰을 탈취당했을 때 보안에 더 취약해지게 된다.
• 이때 “그러면 유효기간을 짧게 하면서  좋은 방법이 있지는 않을까?”라는 질문의 답이 바로 Refresh Token이다. 이름이 다르지만 형태 자체는 Refresh Token은 Access Token과 똑같은 JWT다.
• 단지 Access Token은 접근에 관여하는 토큰이고, Refresh Token은 재발급에 관여하는 토큰 이므로 행하는 역할이 다르다고 보면 된다.

Redis 사용 이유

1) In Memory DB의 장점인 빠른 액세스 속도로 사용자 로그인시 (리프레시 토큰 발급시) 병목이 되지 않는다.

2) Refresh Token은 발급된 후 일정 시간 이후 만료되어야 한다. Refresh Token을 RDB인 MySQL에 저장하면, 스케줄러 등을 사용하여 주기적으로 만료된 토큰을 만료 처리하거나 제거해야한다. 하지만, 레디스는 기본적으로 데이터의 유효기간(time to live)을 지정할 수 있어서 보다 쉽게 구현이 가능하다.

AWS S3 이미지 업로드

• putObject 메소드를 이용하여 지정된 버켓에 파일이름과 이미지파일을 저장해주고
• return값으로 이미지 url을 String 타입으로 반환하다.
• S3에 저장될 파일이름을 fileName 에 담아준다.
• 다음, 이미지 파일과 파일 이름을 아래 putS3 메소드를 이용하여 S3에 업로드해준다.
• 다음 아아래에 있는 removeNewFile 메소드를 이용해 로컬에 저장된 이미지파일을 삭제한다.
• 1개 이상의 이미지가 담겨있는 multipartFileList를 for문을 돌려 이미지가 있을 시 convert 메소드를 통해 파일을 전환시켜 준다.
• 그리고, new ImagFile 안에서 아래의 upload 메소드를 사용해 이미지 파일과, 폴더명, 유저 정보, 룸 정보를 담아준다. 
• 다음 imageFileRepository에 저장한다.

Enum

• Enum이란 enumerated type의 줄임말로 열거형이라고 불리며 서로 연관된 상수들의 집합을 의미한다.
• 흔히 상수를 정의할 때 final static string 과 같은 방식으로 상수를 정의한다. 하지만 이렇게 상수를 정의해서 코딩하는 경우 다양한 문제가 발생하는데, 이러한 문제점들을 보완하기 위해 자바 1.5버전부터 새롭게 추가된 것이 바로 "Enum" 이다.
• 코드가 단순해지며, 가독성이 좋다.
• 인스턴스 생성과 상속을 방지하여 상수값의 타입안정성이 보장된다.
• enum class를 사용해 새로운 상수들의 타입을 정의함으로 정의한 타입이외의 타입을 가진 데이터값을 컴파일시 체크한다.
• Enum을 사용하는데 있어 가장 큰 허들은 "변경이 어렵다"란 점
• 코드를 추가하거나 변경해야 하는 일이 빈번하다면, 매번 Enum 코드를 변경하고 배포하는것보다 관리자 페이지에서 관리자가 직접 변경하는 것이 훨씬 편리할 수 있다.
• 위와 같은 경우 테이블로 관리함으로써 얻는 장점이 정적언어를 활용함으로써 얻는 장점을 버릴정도로 더 큰지 고민해봐야 한다.

비관적 락

• 자원 요청에 따른 동시성문제가 발생할것이라고 예상하고 락을 걸어버리는 방법론
• 트랜잭션의 충돌이 발생한다고 가정 = 사용자들이 같은 데이터를 동시에 수정 할 것이라고 가정
• 하나의 트랜잭션이 자원에 접근시 락을 걸고, 다른 트랜잭션이 접근하지 못하게 하는 방식 = 한사용자가 데이터를 읽는 시점에 Lock을 걸고 조회 또는 갱신 처리가 완료될 때 까지 유지

장점

• 충돌이 자주 발생하는 환경에 대해서는 롤백의 횟수를 줄일 수 있으므로 성능에서 유리
• 데이터 무결성을 보장하는 수준이 매우 높다.

단점

• 데이터 자체에 락을 걸어버리므로 동시성이 떨어져 성능 손해를 많이 보게 된다. 특히 읽기가 많이 이루어지는 데이터베이스의 경우에는 손해가 더 두드러짐.
• 첫번째 사용자가 트랜잭션을 완료하기 전까지 다른 사용자들이 데이터를 수정할수 없기때문에 제어를 잘못하면 동시성을 저해 받게 된다.
• 서로 자원이 필요한 경우에, 락이 걸려있으므로 데드락이 일어날 가능성이 있다.

낙관적 락 

• 자원에 락을 걸어서 선점하지말고, 동시성 문제가 발생하면 그때 가서 처리 하자는 방법론 
• 낙관적 동시성 제어는 사용자들이 동시에 데이터를 수정하지 않을 것이라고 가정한다. = 트랜잭션의 충돌이 발생하지 않을것이라고 기대
• 일단 충돌이 나는것을 막지 않고, 충돌이 난것을 감지하면 그때 처리

장점

• 충돌이 안난다는 가정하에, 동시 요청에 대해서 처리 성능이 좋다.

단점

• 잦은 충돌이 일어나는경우 롤백처리에 대한 비용이 많이 들어 오히려 성능에서 손해를 볼 수 있다.
• 롤백 처리를 구현하는게 복잡할 수 있다.

• 비관적락 은 데이터의 무결성이 중요하고, 충돌이 많이 발생하여 잦은 롤백으로 인한 효율성 문제가 발생하는것이 예상되는 시나리오에서좋다.
• 비관적 동시성 제어는 동시성이 저하 되지만 데이터를 일일이 검사하지 않아도 된다. 만약 데이터 정합성이 중요한 업무(금융) 라면 비관적 동시성 제어로 동시성이 저하 되더라도 for update 문으로 예외처리를 하여 오히여 동시성을 높이면서 좋은 데이터 정합성을 가질 수 있다.
• 낙관적락 은 실제로 데이터 충돌이 자주 일어나지 않을것이라고 예상되는 시나리오에서 좋다.
• 낙관적 동시성 제어는 크게 경합이 벌어지지 않는 업무 ( 쇼핑몰) 등에서 사용하고, Lock이 짧아져 동시성을 높이는것이 좋다.
  하지만 상품 조회시점과 결제 시점에 가격이 다를 수 있으므로 반드시 데이터 수정시 일관성 검사를 거쳐야만 한다.

Spring Security

• 인증(Authentication) : 해당 사용자가 본인인지 확인하는 절차
• 인가(Authorization) : 인증된 사용자가 요청한 자원에 접근 가능한지 결정하는 절차
• 접근 주체(Principal) : 보호받는 Resource에 접근하는 대상
• 비밀번호(Credential) : Resource에 접근하는 대상의 비밀번호
• 권한 : 인증된 주체가 어플리케이션의 동작을 수행할 수 있도록 허락되어 있는지 결정
  • 인증 과정을 통해 주체가 증명된 이후 권한을 부여할 수 있다.
  • 권한 부여에 두 가지 영역이 존재하는데 웹 요청 권한과 메서드 호출 및 도메아ㅣㄴ 인스턴스에 대한 접근 권한 부여가 있다.

Spring Security는 기본적으로 인증 절차를 거친 후 인가 절차를 진행하게 되며, 인가 과정에서 해당 리소스에 대한 접근 권한이 있는지를 확인한다. 이러한 인증과 인가를 위해 Principal을 아이디로, Credential을 비밀번호로 사용하는 인증 방식을 사용한다.
spring security 에서는 기본적으로 세션 - 쿠키 방식을 사용하고 있다.

일반적인 Form Login 절차

1. 요청 수신

• 사용자가 form을 통해 로그인 정보가 담긴 Request를 보낸다.

1. 토큰 생성

• AuthenticationFilter가 요청을 받아서 UsernamePasswordAuthenticationToken토큰(인증용 객체)을 생성
• UsernamePasswordAuthenticationToken은 해당 요청을 처리할 수 있는 Provider을 찾는데 사용

1. AuthenticationFilter로 부터 인증용 객체를 전달 받는다.

• Authentication Manager에게 처리 위임
• Authentication Manager는 List형태로 Provider들을 갖고 있다.

1. Token을 처리할 수 있는 Authentication Provider 선택

• 실제 인증을 할 AuthenticationProvider에게 인증용 객체를 다시 전달한다.

1. 인증 절차

• 인증 절차가 시작되면 AuthenticationProvider 인터페이스가 실행되고 DB에 있는 사용자의 정보와 화면에서 입력한 로그인 정보를 비교

1. UserDetailsService의 loadUserByUsername메소드 수행

• AuthenticationProvider 인터페이스에서는 authenticate() 메소드를 오버라이딩 하게 되는데 이 메소드의 파라미터인 인증용 객체로 화면에서 입력한 로그인 정보를 가져올 수 있다.

1. AuthenticationProvider 인터페이스에서 DB에 있는 사용자의 정보를 가져오려면, UserDetailsService 인터페이스를 사용한다.
2. UserDetailsService 인터페이스는 화면에서 입력한 사용자의 username으로 loadUserByUsername() 메소드를 호출하여 DB에 있는 사용자의 정보를 UserDetails 형으로 가져온다. 만약 사용자가 존재하지 않으면 예외를 던진다. 이렇게 DB에서 가져온 이용자의 정보와 화면에서 입력한 로그인 정보를 비교하게 되고, 일치하면 Authentication 참조를 리턴하고, 일치 하지 않으면 예외를 던진다.
3. 인증이 완료되면 사용자 정보를 가진 Authentication 객체를 SecurityContextHolder에 담은 이후 AuthenticationSuccessHandle를 실행한다.(실패시 AuthenticationFailureHandler를 실행한다.)

JWT

• JWT(JSON Web Token)란 인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미한다.
• JWT(Json Web Token)란 Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token이다. JWT는 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달한다. 
• JWT는 Header, Payload, Signature의 3 부분으로 이루어지며, Json 형태인 각 부분은 Base64Url로 인코딩 되어 표현된다. 또한 각각의 부분을 이어 주기 위해 . 구분자를 사용하여 구분한다. 추가로 Base64Url는 암호화된 문자열이 아니고, 같은 문자열에 대해 항상 같은 인코딩 문자열을 반환한다.

단점 

• Self-contained: 토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있다. 
• 토큰 길이: 토큰의 페이로드(Payload)에 3종류의 클레임을 저장하기 때문에, 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있다. 
• Payload 인코딩: 페이로드(Payload) 자체는 암호화 된 것이 아니라, BASE64Url로 인코딩 된 것이다. 중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로, JWE로 암호화하거나 Payload에 중요 데이터를 넣지 않아야 한다. 
• Stateless: JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능하다. 즉, 토큰을 임의로 삭제하는 것이 불가능하므로 토큰 만료 시간을 꼭 넣어주어야 한다. 
• Store Token: 토큰은 클라이언트 측에서 관리해야 하기 때문에, 토큰을 저장해야 한다.

[서버 기반 vs 토큰 기반]

서버(세션) 기반 인증 시스템
서버의 세션을 사용해 사용자 인증을 하는 방법으로 서버측(서버 램 or 데이터베이스)에서 사용자의 인증정보를 관리하는 것을 의미한다.
그러다 보니, 클라이언트로부터 요청을 받으면 클라이언트의 상태를 계속에서 유지해놓고 사용한다.
(Stateful) 이는 사용자가 증가함에 따라 성능의 문제를 일으킬 수 있으며 확장성이 어렵다는 단점을 지닌다.

토큰 기반 인증 시스템
이러한 단점을 극복하기 위해서 "토큰 기반 인증 시스템"이 나타났다.
인증받은 사용자에게 토큰을 발급하고, 로그인이 필요한 작업일 경우 헤더에 토큰을 함께 보내 인증받은 사용자인지 확인한다.
이는 서버 기반 인증 시스템과 달리 상태를 유지하지 않으므로 Stateless 한 특징을 가지고 있다.

RESTful 한 API 란?

RESTful API(=REST API)란, REST한 방식으로 클라이언트와 서버간 상호 데이터 교환을 하는 API이며, 서로간에 stateless한 특징을 가지는 API입니다. -> HTTP를 잘사용하기위해, URI와 HTTP메소드를 사용해서, URL로 어떤 자원에 접근할 것인지, 메소드로 어떤 행위를 할것인지 표현하여 설계된 API를 말합니다.

또한 API가 RESTful로 간주되기 위해서는 몇가지 조건이 있는데 그 중 가장 중요한 건,

• 클라이언트-서버 커뮤니케이션: 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음
• Stateless(무상태)입니다.

클라이언트와 서버간 종속적이지 않다는 말입니다.

즉, 서버는 클라이언트의 정보를 저장-유지하고 있지않아, 같은 사람이보낸 정보도, 같은사람이 보냈는지 정보를 유지하고있지 않다는 말입니다.

이말은 즉, 클라이언트가 요청시 마다, 자기 정보를 보내야하고, 서버는 받은 정보로 클라이언트의 정보를 확인합니다.

따라서,  

• 멀티플랫폼 지원이 용이하고,
• Stateless한 RESTful API는 Client의 요청(호출)을 어느 Server라도 동일하게 처리할 수 있고
• 즉, 어떤 Server라도 Client들의 요청에 응답할 수 있다는 것은, 서버 환경이 분산되었든 아니든, Client쪽에서는 Server쪽에 신경 쓸 필요 없이 API 호출만 하면 원하는 결과를 받을 수 있다는 점에서 RESTful API가 활용되는 것입니다.

오늘 아침 [KB국민은행 IT's Your Life 3기] SW역량평가 시험이 있었다.

10시 30분 부터 시작인데, 9시 55분까지 메일로 받은 줌 링크로 접속하여 오리엔테이션을 진행하고, 줌을 킨 상태로 시험을 보는 형식이었다.

총 문제는 40문제, 1시간 안에 풀어야 했다. 

몇몇 부트 캠프나 개발 교육 프로그램들은 사전 시험이 있다고 들어봤지만, 직접 참여해본 건 처음이다. 

이번이 3기라 그런지 별로 시험에 대한 후기가 없어서 대략 알고리즘 문제겠지? 라고 추측 했는데, 결론은 아니었다.

내용을 포스팅 해도 되는지 확실히 몰라서 대략 설명하자면, 공기업 NCS 문제가 반 그리고 알고리즘 사고를 해야하는 문제가 반 정도 된 것 같다. 공학용 계산기 혹은 일반 계산기 사용이 가능했다. 도구가 있어도 쓸 줄 알아야 .... ㅎ 엄청 찍고 나옴 ^^ ㅎ .....................

이런 시험 잘푸시는 분들 너무 신기하다. 좋은 경험이었다. 

( + 추가 )

분명히 시험 망했다고 생각했는데 오늘 서류 전형 합격 문자를 받았다.

알고리즘 사고 문제가 주관식이었고 마지막 두 문제는 풀지도 않고 찍어서 기대를 안 했는데, 아무래도 예전에 잠깐 취준한다고 공부 했던 NCS문제를 잘 찍은 것(?) 같다. 일단 서류 전형 통과해서 역량 테스트를 본 사람은 대략 300명이 넘었던 것 같은데, 면접 전형은 몇 명을 붙여 준 건지 잘 모르겠다. 총 75명이 선발 되는 걸로 아는데, 시험에 통과한 것 만으로도 기분이 좋음 : ) 

오늘 봤던 PM직무 면접에 기술 면접이 포함되어 있었다. 사실 기술 면접이 있을 줄 모르고 준비를 하나도 안하고 본지라 쉬운 문제만 주셨음에도 불구하고 제대로 답변을 하지 못했다. 하 창피하다 정말 ^-ㅠ. 어쨌든 PM으로 지원을 계속 할거라면 당분간 기술 면접 준비도 꾸준히 해야할 것 같다. 정말 열심히 했나? 라고 되돌아 보게 되는 하루였다. 솔직히 더 하면 할 수 있었을 것 같은데, 너무 안일하게 공부를 했던 것 같기도 하고, 오늘은 자기 반성이 필요하다.

1. API란 무엇인지 간단하게 설명해주세요.

• Application Programming Interface : Inter는 ~ 간에, ~ 사이에, face는 '면' , 면과 면 사이에 무언가를 프로그래밍 적으로 작동하게 해주는 것. 이라고 이해하면 쉬울 듯.
• 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환가능 하도록 하는 것

2. Restful한 API란 무엇인가요?

REST(Representational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미

즉 REST란 

1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
2. HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.

3. Arguments와 Parameter의 차이점에 대해 설명해 주세요.

• 컨트롤러 단에 집어넣는 전달인자는 Argument, Parameter는 매개 변수.
• Parameter는 함수 혹은 메서드 정의에서 나열되는 변수 명입니다. 반면 Argument는 함수 혹은 메서드를 호출할 때, 전달 혹은 입력되는 실제 값입니다. Parameter의 실체는 변수이고 Argument의 실체는 값입니다.

4. var, let, const의 차이점에 대해 설명해 주세요.

• var는 애크마스크립트 때 많이 사용했지만 자바스크립트 버전이 업그레이드 되면서 많이 사용하지 않게 되었다.
• let은 선언 중복이 되지 않지만, 재할당은 가능함
• const는 선언도 재할당도 모두 안된다.

5. 객체지향에 대해 설명해 주세요.

• 객체 지향 프로그래밍 (Object-Oriented Programming, OOP)은 프로그래밍에서 필요한 데이터를 추상화 시켜 상태와 행위를 가진 객체로 만들고, 객체들간의 상호작용을 통해 로직을 구성하는 프로그래밍 방법이다.
• 객체는 또한 레고 조각과도 비슷하게 여러군데에서 재사용 할 수 있는데 이는 부품화 와 재사용성 이라는 객체 지향 프로그래밍의 특징을 보여주기도 한다.
• 객체 지향 프로그래밍은 크게 추상화 , 캡슐화 , 상속 , 다형성 의 네가지 특징을 가진다.

https://jongminfire.dev/%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D%EC%9D%B4%EB%9E%80

https://jeong-pro.tistory.com/95

6. 인생에 어려웠던 순간을 어떤 방식으로 해결했는지?

7. 보통 부트 캠프 수료생들은 복붙만 할 줄 아는데, 스스로 코딩연습을 얼마나 했는지? 

8. 부트 캠프 프로젝트를 하면서 어떤 역할(포지션)을 맡으셨는지? 

9. 모르면 모른다고 하는게 부끄러운 건 아니지만, 알아야 하는 건 알아야 한다. (뼈맞았어요 ^^)

• 몰라도 괜찮을 땐 몰라도 해도 좋지만, 내가 지금 역량이 안되서 못하는 상황인데 다 할 수 있다는 사람도 원치 않고, 개발을 못한다고 쉽게 포기하는 사람도 원치 않는다. 벌써부터 개발이 안맞아서 PM직무를 선택하는 건 섯부른 판단인 것 같다. 프로젝트를 하면서 맡을 수 있는 업무 중에 맡은 업무가 PM이었을 것 같다. 더 개발공부를 하면 좋을 것 같다.
• 개발만큼 중요한게 목적을 잃어 버리는 것. 매니저급들이 잡아주는 역할이 필요하다. 그 역량은 아마 PM을 하면서 키웠을 것 같은데, 개발 역량 같은 경우는 베트남 지사같은 경우 체계가 없고 바로바로 뚝딱 만들어야 하는 현실이기 때문에, 개발을 꾸준히 공부했으면 좋겠다. 

10. 회사에 바라는 점이나 해보고 싶은 업무가 있는지?

첫 술에 배부를 수 없다. 반성하고 여행으로 리프레시 하고 다시 열심히 해보자 ! 

3달 안에 무조건 취업 뽀개는 방법 

취업, 왜 이렇게 어려운 걸까 ?

• 본인을 잘 모르고, 주어진 환경을 잘 모르기 때문 
• 나의 강점을 잘 모르기 때문이다.
• 당신은 신입 개발자로서 어떤 사람인가요?에 대한 질문을 던져보자.
• 매력어필을 잘 하는 것이 중요하다. 
• 의지가 있는 한, 타석에 오를 수 있다. 홈런왕은 삼진왕. = 실수하고 개선하는 과정이 필요하다.
• 최대한 많이 지원하고 부딪혀보면서 배워야 한다. 
• 빨리 준비해서 빨리 한대 더 맞는게 중요해. 실패에서 더 잘 배우기
• 면접을 보면서 피드백을 여쭤보자, 보안할 점 더 공부해야할 점.
• 계속해서 기술적인 챌린지를 유지해야한다 = 기술 블로그, 알고리즘, cs공부
• 처음 시작할 때와 비교하면 많이 성장해있음을 볼 수 있을 것이다.
• 3달 뒤에 또 성장할 모습을 상상하면서 구직을 하자.

무조건 뽀갠다! 필승 원칙 5가지

• 많이 쓴다. = 가장 중요하다
• 피드백을 받는다.
• 변명 말고 고친다.
• 효율화 한다.
• 같이 한다.

FQA

• 조금은 아쉽지만, 그래도 내게 기회를 준 회사. 가야 할까? - 무조건 가라.
• 면접 준비는 어떻게 하면 좋을까요? 
• 프로그래밍 면접 = 알고리즘 문제많이 풀어보기
• 기술 면접 (cs) = 팀으로 준비하는게 효과적, 팀원끼리 질문하기
• 이력서 바탕 예상 질문 서로 물어보면서 실제 면접처럼 연습해보기
• 노션 형식이 깔끔 ( 이력서 )
• 이력서 포맷 - 너무 길면 이상함. 첫 페이지 상단을 가장 많이 봄. 따라서 첫 페이지 상단 부분에 자신을 드러내는 것을 잘 기입하는게 중요. 내가 생각하는 나를 드러내는 방법을 잘 고민해서 레이아웃을 짜기
• 부트 캠프 비전공자 연봉 제안 상한선 : 4000만원 정도 ? 

매력적인 신입 개발자 ? 

• 사람들마다 다르겠지만, 성장가능성을 본다.
• 0부터 99일까지의 성장 곡선을 잘 보여주면 좋다.
• 내가 이력서에 적은 내용을 막힘없이 깊이있게 아는 사람. 내가 했던 것들에 대해 깊이 알고 있는 사람.
• 다른 일을 해봤던 사람. 일하는 방식을 아는 사람.

다음은 지난주에 있었던 토스뱅크 프론트엔드 개발자 박지혜 멘토님,  네이버 시크플랫폼 개발자 김건희 튜터님의 이력서 특강 내용을 정리한 부분이다  !

1. 포맷을 맞춰서 보기 쉽게 한 장으로 ( 항해 이력서 포맷 참고/ 한눈에 보기 쉽게 / 스토리텔링 있도록 )
2. 깃허브를 이용하자! 깃허브 프로필 잘 꾸미기
3. 어떤 기술로 어떤 개선사항이 있었는지 적어주기 ( 이력서 프로젝트 아래에 ) 
4. 유저수 만족도 구체적으로 어떤 피드백이고 어떻게 개선했는지 적용하면 더 매력적일 듯. 
5. 노드 : AWS 사용해서 로드밸런싱 한 경험 어필 등 서버 개발자의 역량을 좀 더 어필하기.
6. 사용기술 왜 그 기술을 선택했는지, 그 질문을 잘 준비해야 함 ( 면접 )
7. 경험은 최대한 자세하게 적기. 무엇을 했는지 알 수 있도록.
8. 항해에서 제공하는 포맷이 아닌경우, 예를 들어 노션으로 만든 경우 다른 디자인이고 디자인에 개성이 표현되어 있으면 한번 더 눌러보게 된다. 본인을 잘 표현 할 수 있도록 가독성있게 작성하기 ! 
9. 개발자의 발작 버튼 ! 키워드 ! - 서버의 경우 Pessimistic Lock - 데드락 어떻게 해결했나요? 라는 질문 들어올 것. 어떻게 해결했는지 등등 개념 공부를 빠삭하게 하고 적어야 한다. 
10. 발작버튼을 잘 눌렀을 때 답변을 잘 하면 취업이 훨씬 수월할 것이다.
11. 아키텍쳐 넣기 - 기술스택 
12. 본인이 어떤 노력을 했고 어떤걸 배웠는지 잘 녹여내도록 하기. ( 스토리텔링 !!)
13. 읽기 편한 이력서를 작성할 것 ! ( 노션을 잘 활용해도 좋아 )

위와 같이 배운점과 개선점을 잘 풀어내는게 중요해.

1인분의 정의가 무엇인가요? 회사에서 생각하는 1인분의 구체적인 기준이요

( 박지혜 개발자님 답변 )

비유로 설명하기 애매할 수도 있지만, 요리를 한다고 생각해보면, 가끔 레시피(구글링)을 찾아볼 수는 있겠지만, 재료손질부터 간을 맞추는 것까지 혼자 할 수 있고, 요리하다가 돌발상황(개발자로서 생각한다면 서비스 장애나 이슈 트러블 슈팅을 위한 디버깅 같은 것들)을 만나도 대응할 수 있다면, 1인분을 하는 거라고 생각합니다. 기능을 코드로 구현하는 것은 보통 신입이든 경력직이든 누구든 할 수 있는 영역이라고 생각하는데요. 보안을 신경쓴 코드라든지, 대용량 트래픽을 신경쓰기 위해 인프라를 어떻게 구성하는게 좋겠다든지, 배포전략을 어떻게 세워야한다든지, 장애가 발생해서 바로 대응해줘야한다든지, 디버깅을 해야해서 로그를 찾아야하는 상황 등등 여러 상황을 아직 경험하지 못하셨기 때문에 서비스 하나를 온전히 한 사람에게 못 맡기는 경우들이 더러 있어요. 몇 가지 안되는 경우만 예시를 들긴 했지만, 이런 걸 현재 다 하실 수 있다면 1인분을 충분히 하실 수 있는 개발자라고 생각합니다!!