Chapter 1| 풀스택 미니 프로젝트
Dev_Interview
Dev_Interview란
개발자 면접 질문에 대한 답변을 서로 공유하고 이를 토대로 기술면접을 성공적으로 준비할 수 있게 해주는 서비스
Dev_Interview 구현 목록
- 회원가입
- 이름
- 아이디
- 이메일 형식인지 확인
- 비밀번호
- 특수문자, 영어, 숫자 중 2개 이상
- 비밀번호 확인
- 비밀번호란과 동일한지 확인
- 로그인
- 아이디
- 공란이 아닌지 확인
- 이메일 형식인지 확인
- 비밀번호
- 공란이 아닌지 확인
- 아이디
- 메인페이지
- 질문
- 이전/다음 버튼으로 이전/다른 질문을 볼 수 있음.
- 답변 작성 및 등록
- 등록이 되어야만 다른 사람 답변 조회 가능
- 답변 수정
- 좋아요/좋아요 취소
- 답변 리스트 정렬
- 좋아요순 (Default)
- 최신순
- 질문
- 마이페이지
- 내 정보 수정
- 비밀번호 다시 한 번 확인 후 맞는 경우 수정 페이지로
- 아이디는 변경 불가
- 내 답변 모아보기
- 카드 형태로 질문 및 답변 출력
- 내 정보 수정
Dev_Interview 와이어 프레임
Dev_Interview API
프로젝트 후기
프로젝트 설계 단계에서는 4일이면 충분한 시간이라 생각하였으나 중간에 팀원이 1명 줄어들면서 파트 분배를 다시 해야하는 문제가 발생하였다. 그래서 필수 기능을 기준으로 우선순위에서 밀려난 기능들은 구현을 미루어두기로 결정하였다. 그럼에도 불구하고 Python, flask, javascript 등 경험해보지 못한 언어와 프레임워크를 사용하면서 예상하지 못했던 오류들을 만나게 되는 경우와 혼자서만 사용하던 git을 협업에 사용하려다보니 사용법이 익숙하지 않아 3~4시간 가량을 git에 써버리는 등의 문제들로 시간이 많이 부족하였다. 처음엔 자신있게 가장 복잡한 메인 페이지를 맡았는데 나중엔 기능을 다 구현하지 못할까봐 걱정이 되기도 하였다. 하지만 마지막날 밤을 새면서 맡은 역할을 모두 수행할 수 있었다.
JWT(JSON Web Token)
JWT란
당사자 간에 JSON 오브젝트로 정보를 안전하게 전송하는, 간편하고 URL에 안전한 방법을 정의하는 개방형 표준
JWT 구조
Header
{
"typ": "JWT",
"alg": "HS256"
}- typ: 토큰의 타입
- alg: 서명 생성에 사용된 해시 알고리즘
Payload
{
"sub": "1", //registered claim
"iss": "psy", //registered claim
"exp": "1480849147", //registered claim
"https://velog.io/@soyp": "true", //public claim
"username": "yoong" //private claim
}Registered claims : 미리 정의된 클레임
- sub(Subject): 토큰 제목
- iss(Issuer): 토큰 발급자
- aud(Audience): 토큰 대상자
- exp(Expiration Time): 토큰 만료 시간
- nbf(Not Before): 토큰 활성 날짜
- iat(Issued At): 토큰 발급 시간
- jti(JWT Id): 토큰 식별자
Public claims : 공개용 정보 전달을 위해 사용하는 사용자가 정의할 수 있는 클레임
- 충돌이 방지된 이름을 가져야 하기 때문에 클레임 이름을 URI 형식으로 지음
Private claims : 당사자들 간에 정보를 공유하기 위해 만들어진 사용자 지정 클레임
- 양 측간에 협의하에 사용되며 외부에 공개되어도 상관없지만 해당 유저를 특정할 수 있는 정보를 담음
Signature
[Signature 부분을 만드는 슈도코드 구조]
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
your-256-bit-secret
)- header의 인코딩 값, payload의 인코딩 값을 합친 후 주어진 비밀키로 해쉬하여 생성
JWT 장점
- Header와 Payload로 Signature을 생성하기 때문에 데이터의 위변조를 막을 수 있음
- 토큰 자체가 인증된 정보이므로 별도의 인증 저장소가 필요하지 않음
- 클라이언트 상태를 서버가 저장해두지 않아도 됨
- 토큰에 대한 기본 정보와 전달할 정보 및 서명 등 모든 정보를 자체적으로 지니고 있음
- 확장성이 우수함
- 토큰 기반으로 다른 로그인 시스템에 접금 및 권한 공유가 가능함
- 모바일 어플리케이션 환경에서도 잘 동작함
JWT 단점
- 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해짐
- Payload 자체는 암호화되지 않기 때문에 중요한 정보는 담을 수 없음
API(Application Programming Interface)
API란
프로그램들이 서로 상호작용하는 것을 도와주는 매개체
API 역할
- 서버와 데이터베이스에 대한 출입구 역할
- 허용된 사람들에게만 접근성을 부여함
- 애플리케이션과 기기가 원활하게 통신할 수 있도록 함
- 모든 접속을 표준화함
- 기계/운영체제 등과 상관없이 누구나 동일한 액세스를 얻을 수 있음
API 종류
SOAP API
- 단순 객체 접근 프로토콜을 사용
- XML를 사용하여 메시지 교환
- 유연성이 떨어지며 과거에 많이 사용됨
RPC API
- 원격 프로시저 호출이라 함
- 클라이언트가 서버에서 함수나 프로시저를 완료하면 서버가 출력을 클라이언트로 다시 전송
Websocket API
- JSON 객체를 사용하여 데이터를 전달하는 웹 API
- 클라이언트 앱과 서버 간의 양방향 통신을 지원
- 서버가 연결된 클아이언트에 콜백 메시지를 전송할 수 있어 REST API보다 효율적
REST(Representational State Transfer) API
- HTTP를 사용하여 데이터 교환
- 서버가 클라이언트 입력을 사용하여 내부 함수를 시작하고 출력 데이터를 다시 클라이언트에 반환
- 오늘날 웹에서 가장 많이 사용되고 유연한 API
01주차 회고
배운 점
낯가림이 심해서 처음엔 소통에 어려움이 있었는데 프로젝트를 진행하면서 소통의 필요성을 배울 수 있었고 팀원들에게 많은 도움을 받으면서 앞으로 나도 다른 분들에게 그런 팀원이 되고 싶다는 생각이 들었다.
느낀 점
많이 부족하다는 것을 알고 있었지만 더욱 뼈저리게 느끼게 된 계기가 된 것 같다. 전공자에 프로젝트 경험이 있음에도 불구하고 다른 분들에 비해 전혀 나은 점이 없다는 것이 너무 부끄럽기도 하였다.
또 앞으로 자주 사용하게 될 git 사용법을 공부해야겠다는 생각이 들었다.
아쉬운 점
시간이 부족하면서 코드를 너무 지저분하게 작성한 것이 아닌가 하는 생각이 들어서 너무 아쉬웠다. 또한 기능 구현에만 신경을 쓰다보니 다른 조들에 비해 결과물 디자인이 아쉽게 느껴진 것 같다.
