페르소나 패턴

당신은 FAANG 회사의 선임 엔지니어 입니다. 
보안과 성능에 집중해서 다음 코드를 검토하세요.

레시피 패턴

목표와 필요한 것을 알고있을 때 결과물을 도출할 때 유용

난 일반적으로 이런 방식으로 많이 질문하는 듯

Java 를 사용해서 ~~한 기능을 하는 함수 코드 짜줘
마지막으로 불필요한 단계를 검토해줘.

리플렉션 패턴

답변에 대한 이유를 추가적으로 설명하게 함. 공부할 때 유용

질문 전 : 
답변하기 전 답변의 근거와 가정을 설명하세요. 
선택사항을 설명하고 잠재적은 제한 사항이나 엣지케이스를 설명해줘

뒤집힌 상호작용 패턴

GPT 가 답변을 위한 질문을 우리한테 함. (GPT 가 대화를 주도)

목표를 위한 과정을 모를 때 유용함

AWS 에 웹서버를 배포하기 위한 질문을 나한테 해줘.
필요조건이 모두 충족되면 배포 스크립트도 짜줘.

운 좋게 칼취업을 했다.

하지만 합격 발표 전에도 입사에 대해 많은 고민을 했다. . . .

"SI는 개발자의 무덤이다."

라는 말이 많았다.

자사 서비스를 운영하는 기업에 가고 싶었다.

하지만 나는 비전공자이고,

진로를 개발자로 결정한 것도 늦은 시기였고, (학부생 3학년 2학기때)

이렇다 할 프로젝트도 없어서 자사 서비스를 운영하는 기업은 서류에서 주구장창 탈락만 했다.

앞으로 내 인생이 어떻게 될 지 모르겠지만 일단은 KT ds에서 열심히 근무를 할 것이다.

주어진 일에 최선을 다하고,

주어진 상황에서 자기개발을 꾸준히 할 것이다. . . . . 기회가 된다면 종종 기업에 대한 이야기를 풀어보겠다..!

취준생들 모두 화이팅!

이 글은 스프링부트의 RestTemplate 라이브러리를 사용하여 다른 서버와 통신을 하는 개발 과정을 기록했습니다. 부제 : API 호출하기.

개요

현재 개발 중인 서비스는 아래와 같다.

1. 웹서버(Springboot)와 API서버(Flask)가 있다.
2. API 서버는 Yolov5로 이미지 객체 분석을 하는 기능이 있다.
3. 요구사항은 웹서버에서 받은 클라이언트의 음식 사진에서 음식을 검출하여 칼로리를 얻는 것이다.

해당 요구사항을 위해 웹서버에서 클라이언트로부터 사진을 받으면 이를 API 서버에 요청해 객체 분석 결과를 응답받는 기능이 필요하다.

RestTemplate?

서버 간 통신을 위해 이것저것 찾아보던 중 RestTemplate 라이브러리를 발견

RestTemplate은 HTTP 통신 + RESTful API를 지켜준다.

해당 모듈을 사용하기 위해서는 HTTP 메세지를 잘 이해해야 한다.

반드시 필요한 요청 메세지 정보는 다음과 같다.

Start Line

• method : 어떤 메소드로 데이터를 조작할 것인가 (Manipulation of resources through representation)
• URI : 어떤 자원을 요청할 것인가 (Identification of resources)

Header

• Host : 어디 서버로 요청할 것인가.
• content-type : 요청할 데이터의 타입은 어떤 것인가(self-descriptive message)

Body

• Body : 무슨 데이터와 함께 요청할 것인가.

이제 해당 메세지를 RestTemplate를 통해 서버에 요청을 하면 된다.

구현

먼저 RestTemplate 객체를 생성한다.

RestTemplate restTemplate = new RestTemplate();

RestTemplate의 postForEntity 메소드를 통해 post 요청을 해 줄 것이다.

postForEntity(String url, Object request, Class<T> responseType, Map<String,?> uriVariables)
주어진 객체를 URI 템플릿에 POST하여 새 리소스를 만들고 응답을 로 반환합니다 HttpEntity.

요청을 위해 필요한 파라미터는

1. URI
2. 요청 메세지인 request
3. 응답 타입(어떤 형식으로 응답 받을 것인지) responstType

(uriVariables는 템플릿을 확장하는 변수..라는데 아직 이 내용에 대해서는 잘 모르겠다.)

1) URI, startline

먼저 URI, 어디 서버로 어떤 자원을 요청할 지 정의한다. 나는 로컬 서버에서 동작하는 Flask API서버에 요청을 할 것이므로 다음과 같이 정의했다.

String url = "http://localhost:5000/calorie/binary";

Host : localhost:5000 URI : /calorie/binary

이런 형식을 띌 것이다.

이렇게 요청 메세지의 Startline 설정이 된다.

2) request message, header & body

다음으로 요청 메세지 request를 정의한다.

메세지는 Header, Body를 포함하는 HTTP Entity 객체로 만들어주면 된다.

문서를 보니 파라미터로 Body와 Header를 받는다.

HttpEntity<?> requestMessage = new HttpEntity<>(body, httpHeaders);

Header

먼저 헤더를 만들어보자

HttpHeaders로 헤더 객체를 생성한다.

HttpHeaders httpHeaders = new HttpHeaders();

그리고 setContentType 메소드로 content-type을 설정해준다.

httpHeaders.setContentType(MediaType.APPLICATION_JSON);

나는 JSON 데이터로 요청할 것이므로 APPLICATION_JSON으로 설정했다. (대부분 API 통신 시 데이터는 JSON 형식으로 주고받는다.)

Body 다음으로 Body를 만든다.

Body를 위한 객체는 JSON형식으로 요청하기 위해서 MultiValueMap을 통해 생성해줬다. (JSON이 key-value 형식이므로)

MultiValueMap<String, String> body = new LinkedMultiValueMap<>();

해당 객체를 Body에 담아서 요청하면 서버는 content-type을 보고 JSON으로 이해할 것이다.

Body에 데이터를 추가한다.

body.add("filename", fileName);
body.add("image", imageFileString);

요구사항은 이미지 파일을 전송하면 되는데, JSON형식으로 보내기 위해 이미지파일을 base64로 인코딩하여 담아줬다.

이렇게 Body까지 모두 설정해주었다.

Request Message 최종적으로 메세지 형식을 보면 다음과 같겠다.

Request Message
-------------------------------
POST /calorie/binary HTTP/1.1

Host: localhost:5000
Connection: keep-alive
Content-Type: application/json
Content-Length: 200

{
    "filename": 파일이름,
    "image": 이진화된_문자열
}
-------------------------------

요청하기

생성한 메세지(HttpEntity)로 API 서버에 요청을 해보자.

HttpEntity<String> response = restTemplate.postForEntity(url, requestMessage, String.class);

• 응답 또한 마찬가지로 HttpEntity로 받아오면 된다. (HTTP 통신이므로)
• url로 requestMessage를 요청하고 반환은 문자열 형식으로 받겠다.

해당 라인이 실행되면 RestTemplate에서 HttpMessageConverter를 통해 requestMessage 객체를 HTTP 메세지로 변환하여 요청을 할 것이다.

서버 응답은 response에 담기고 응답 데이터는 Body에 담겨 올 것이다.

참고로 API서버의 응답은 다음과 같다.

{
    "name": ["apple", "banana", ...],
    "calorie: [120, 100, ...]
}

• 객체 분석 후 음식이름과 칼로리를 응답한다.

Body에 담긴 응답 데이터는 getBody() 메소드로 받아올 수 있다.

ObjectMapper objectMapper = new ObjectMapper();
objectMapper.configure(DeserializationFeature.ACCEPT_EMPTY_STRING_AS_NULL_OBJECT, true);

FlaskResponseDto dto = objectMapper.readValue(response.getBody(), FlaskResponseDto.class);

JSON형식의 String타입으로 응답을 받아왔다.

이를 ObjectMapper의 파싱을 통해 응답 객체에 저장해주었다.

전체적인 코드

API 호출(요청) 객체

@Component
public class ClientUtil {

    @Value("${flask.url}")
    private final String url;

    private String getBase64String(MultipartFile multipartFile) throws Exception {
        byte[] bytes = multipartFile.getBytes();
        return Base64.getEncoder().encodeToString(bytes);
    }

    public FlaskResponseDto requestToFlask(String fileName, MultipartFile file) throws Exception {
        RestTemplate restTemplate = new RestTemplate();

        // Header set
        HttpHeaders httpHeaders = new HttpHeaders();
        httpHeaders.setContentType(MediaType.APPLICATION_JSON);

        // Body set
        MultiValueMap<String, String> body = new LinkedMultiValueMap<>();
        String imageFileString = getBase64String(file);
        body.add("filename", fileName);
        body.add("image", imageFileString);

        // Message
        HttpEntity<?> requestMessage = new HttpEntity<>(body, httpHeaders);

        // Request
        HttpEntity<String> response = restTemplate.postForEntity(url, requestMessage, String.class);

        // Response 파싱
        ObjectMapper objectMapper = new ObjectMapper();
        objectMapper.configure(DeserializationFeature.ACCEPT_EMPTY_STRING_AS_NULL_OBJECT, true);
        FlaskResponseDto dto = objectMapper.readValue(response.getBody(), FlaskResponseDto.class);

        return dto;
    }

}

응답 객체 FlaskResponseDto.class

@AllArgsConstructor
@NoArgsConstructor
@Getter
@Data
public class FlaskResponseDto {

    private List<String> name;
    private List<Integer> calorie;

    @Override
    public String toString(){
        StringBuilder result = new StringBuilder();
        for(String i : this.name){
            result.append(", ").append(i);
        }
        return result.toString();
    }

}

이 글은 KT ds 응용 SW개발 직군 면접 후기입니다.

코딩테스트 일정이 끝나면 합격자 발표 후 자세한 면접 일정은 추후에 공지해준다. (참고로 코테는 겁내 쉬웠음)

12월 2일에 면접 일정이 공지되었는데...

. . . 면접 첫 날 당첨~~

그래서 12월 6일 월요일에 면접을 보러 갔다. (면접 일정은 12월 6일부터 2주간 진행)

KT ds 면접은 정장 필수! 첫 면접이라 정장도 없고 무료 대여는 면접 5일전부터인가 예약이 가능했다. 부랴부랴 아는 분께 정장을 빌리고 친구한테 구두도 빌렸다.

면접 시간은 9시 50분부터 잡혀있는 것 같았고 다행히 내 시간대는 15시 50분 타임이었다. (아마 마지막 타임이었지 싶다.)

당일에 대구에서 서울로 올라갔다.

면접 당일

면접장소는 동대문 노보텔이었다. 서울역 내려서 지하철 4정거장 가서 동대문역사문화역인가..에서 내린 뒤에 도보로 한 5분?정도 걸렸다.

13시 30분쯤에 도착해서 로비로 입장하니 KT ds 면접 판넬을 세워놓고 관계자분이 안내해주셨다. (너무 일찍 가서 당황하심) 코로나 관련 설문지 작성 후 이름표와 라텍스 장갑을 받았다.

그러고 밖에 나가서 점심 간단하게 먹고 다시 건물로 들어와서 20층 로비에서 대기하면서 마지막 정리를 했다.

면접 시작 30분 전까지 1층 로비에 모여야해서 15시 15분쯤에 다시 1층 로비로 내려갔다.

면접 대기

한 타임에 6명 면접을 봤고 내 타임에 한 명이 없었다.

인원 출석이 완료되면 다시 다른 층으로 이동.

여기서 다시 3명씩 두 팀으로 나뉘어 대기실에서 대기한다. (대기실은 호텔방을 비워 의자를 세 개 놔둠)

그러고 시간이 되면 각자 다른 호텔방 문 앞에 대기하고 제출한 PT 종이를 받는다.

작년부턴가 코로나때문에 대면인듯 비대면인 방식으로 면접을 진행했다.

직무면접

각자 호텔방 하나 씩 잡고 들어가서 방 안에 있는 노트북과 티비 화면으로 면접관님들과 대면한다. (호텔이라 조명 분위기가 좋았음)

면접은 1대다로 진행했다.

들어가서 마스크 벗고 인사를 한 뒤 면접관님들이 1분 자기소개를 시킨다. 자기소개가 끝나면 바로 "PT 5분 시작하세요." 라고 하신다. 입장 전 받은 종이를 보면서 앉아서 말로만 PT를 진행했다. 너무 PT종이만 보면 좀 그러니까 한 파트가 끝나면 힐끔 보고 다시 진행했다.

나는 PT 주제 유형에서 2번 유형을 선택했다. 개발직이라 그런지 3번 유형은 주제 리스트에 없었던 것 같다. 기술에 대한 정의와 해당 기술 도입 시 장단점, 기술에 대한 조직 변화 등등..을 설명하는 주제였다.

PT가 끝나면 바로 질문을 시작하신다. 체감 상 PT질문 : 자소서 질문 = 5 : 5 정도.. 예상 외로 PT에서 많은 질문을 주셨다.

PT질문의 느낌은 선택한 주제에 대해 기술적으로 잘 알고 있는지에 대해 검증하는 느낌이었고 질문 자체가 기술에 대한 이해가 없으면 대답하기 힘든 질문이었다.

자소서에는 웹 서비스 개발과 IoT관련 프로젝트를 기입했는데 IoT관련 프로젝트에 더 관심이 있으신 것 같았고 질문들이 전반적으로 사실검증 느낌의 질문이었다.

기술적인 질문은 크게 어려움 없었다. (내가 별거 안 한 것도 있다.)

면접이 끝나면 다시 대기실로 들어가 대기한다.

임원면접

다시 임원면접을 하러 다른 방에 들어가서 면접을 진행한다.

임원면접은 화상으로 다대다로 진행하고 같이 대기했던 3명끼리 진행한다. (각자 방에서 화상채팅에 모여서 같이 진행함.)

임원분들의 목소리 톤이나 행동이 되게 편하게 느껴졌다.

약간 오구오구 하는 톤으로 질문주셨다.ㅋㅋ

기억에 남아있는 질문

직무면접

PT내용은 기술적으로만 물어보니 잘 준비해가야한다!

1. 프로젝트 설명
2. 프로젝트에서 역할
3. 프로젝트에 쓰인 기술에 대한 장점
   • 나는 RESTAPI를 적어놨는데 REST API가 무엇이고 이를 통해 얻는 장점을 질문으로 받았다.
4. 리더로서 활동한 점을 강조해서 적었는데 이 때 리더로서 한 행동에 대해 팀원들의 불만이 없었는가?
5. 통신 프로토콜 아는 것
6. 마지막으로 입사 후 어떤 일을 하고 싶은지

임원면접

1. 해외여행 경험 중 어려웠던 점
   • 어려웠던 점을 말하고 이 때 느낀점과 배운점을 말했는데
   • 여가시간을 잘 보내는지에 대한 질문이었다고 함..
2. 최근 가장 도전적이었던 경험
3. 연말정산 끝난 후 고객의 프로젝트 발주 시 팀장이 하기 싫어할 때 어떻게 대처할 것인가.

질문 되게 많았는데 기억이 다 안 나고 인상깊었던 질문들만 적었다.

나는 직무 면접에서 질문 하나에 대답 못 했고 임원 면접에서도 제대로 된 답변을 하나 못 했다.

면접 종료

면접이 끝나면 면접비와 함께 커피쿠폰을 준다.

1층 로비 카페에서 바꿔먹고 가면 된다!

커피 기다리면서 다른 면접자분들이랑 이야기했는데 PT면접에서 좀 털렸다고 한다. (PT 내용도 열심히 준비해야 할 듯 하다.)

면접비는 7만원 받음.

후기

첫 면접이라 떨렸는데 다른 서비스 IT기업들의 면접 후기를 들어본 바로는 면접 난이도는 꽤 쉬운 편에 속하는 것 같다.

그리고 압박 면접의 느낌은 들지 않았다.

끝.

해당 시리즈는 취준생이 포트폴리오를 위해 블로그 운영에 도움 될 만한 내용을 간추려 작성했습니다.

글 작성의 난이도는 집 -> 편 -> 저 -> 술 이다.

또한 조회수가 높은 글도 집, 편에 속한다. (개발 꿀팁, 명령어 모음. 누르고 싶다!)

하지만 개발자의 수준을 볼 수 있는 글은 저, 술의 글이다.

기업에서 블로그를 본다.. 할 때도 개발 경험을 다룬 저, 술 성격을 띈 글을 보면서 개발자를 판단할 것이다.

따라서 포트폴리오를 위한 블로그를 작성 중이라면 개발기 작성에도 도전해보자!

블로그를 하는 이유

블로그를 작성하면 개발자 스스로 공부하게 만든다.

글을 써서 올릴려면 해당 내용, 지식에 대한 체계화를 하는 과정이 필요하다.

이 과정에서 개발자는 모르는 것을 찾아내서 알아내고 아는 것을 재확인한다.

자연스럽게 기술을 더 빨리 익히게 되고 문제를 해결하는 노하우를 기른다.

이런 이유 때문에 다양한 매체에서 개발자가 될려면 블로그 꼭 해라.. 라고 말하는 것 같다.

본 포스팅은 도서 개발자의 글쓰기의 7장 내용을 참고하여 내 생각도 기록함.

기술 블로그의 4종류. 저, 술, 편, 집

편 : 순서를 요약하여 쓰자

편은 산만하고 복잡한 자료를 편집해 질서를 부여한 것.

시간 순서로 하나씩 나열 후 내용 작성 -> 단계로 묶어서 요약

처음부터 목차를 나눠서 쓸려고 하면 복잡해진다. (내가 항상 이래왔음)

일단 아묻따 내용먼저 다 쓰고나서 정리하면 더 쉽다.

꼭 내용을 다 쓴 다음에 목차(단계)로 나눠서 요약하자!

글쓰기에 능숙한 개발자거나 이미 전체 내용에 대해 통달했다면먼저 목차를 써도 된다.

하지만 글쓰기에 능숙치 않으면 구조를 생각하지 말고 본인이 한 일을 쭉 나열하고 그 내용부터 쓰자.

집 : 글쓰기가 두렵다면 자료를 모아 핵심을 엮어서 쓰자

집은 여러 사람의 견해나 흩어진 자료를 한데 모아 정리하는 것.

내용을 많이 쓰는 게 아니라 핵심만 간결하게 정리한 것.

글이 길지 않고 내용이 각각 나열되어 있음.

꼭 여러 사람의 견해나 책, 자료를 모아야 하는 것이 아니라 본인의 경험에서 터득한 것들을 요약해 핵심만 정리해도 된다.

본 포스팅은 도서 개발자의 글쓰기의 7장 내용을 참고하여 내 생각도 기록함.

기술 블로그의 종류는 다양하다

• 직접 개발한 과정
• 튜토리얼
• 개발 가이드
• 에러나 버그를 해결하는 방법
• 세미나 후기
• 책 리뷰
• 스스로 깨달은 교훈
• 각종 레퍼런스
• 개발 상식...

등등 너무나 많은 종류가 있다.

본 책에서는 이를 4가지 종류별로 구분해 목차를 잡아 구조화하는 방법을 설명한다.

기술 블로그의 4종류. 저, 술, 편, 집

저 : 개발기는 목차를 잘 잡아서 본문부터 쓰자

어떤 일지를 작성하면 시간의 흐름대로 1 다음 2, 2 다음 3... 이런 식으로 1차원적인 글쓰기를 하면 쉽다.

하지만 개발기를 작성할 때 가장 어려운 문제가 있다.

개발이 순차적으로 잘 된다면야 개발 순서대로 일지를 써 나가면 되지만 개발은 중간중간 버그도 생기고 이를 해결하기 위해 다른 절차도 거쳐야 한다.

결국 개발기는 2차원적인 이야기로 풀이된다.

이를 위해서는 개발을 완료한 뒤 성공한, 완벽한 개발 순서에 대해 1차적으로 작성한다.

이에 대한 것은 아키텍쳐나 알고리즘, 모델, 플로우 등이다.

이후에 문제 해결에 대한 절차는 다음에 문제 해결이나 팁으로 정리해 덧붙인다.

책에서는 네이버 기술 블로그가 가장 체계적으로 잘 쓰여있다고 한다.

목차 정리

1. 머리말
    가. 서비스 설명
    나. 개발의 필요성

2. 본문
    가. 아키텍처나 알고리즘
    나. 개발 모델(최종 루트)
    다. 개발 과정에서 발견한 문제와 해결 방법(경험 루트)
    라. 남은 작업

3. 맺음말
    가. 소감이나 회고

본문 -> 맺음말 -> 머리말 순서대로 써 보자.

술 : 원전을 비교하고 실험해 풀이해서 쓰자

술이란 어떤 것을 분석해 의미를 풀이하고 해석한 것이다.

• 새로운 기술을 자세하게 또는 비유해 설명한 것
• 비슷한 용어를 비교해 풀이한 것
• 에러 해결 방법

등등이 개발에서 술에 포함된다.

본래 내용 정리 -> 자신의 생각이나 분석, 비교, 해설 덧붙이기

기술 블로그는 어떤 경우에도 모두 통용되는 완벽한 답을 낼 수 없다.

자기 방식대로 풀이하자. (그렇다고 틀리게 적으면 안 됨.)

옳고 그림의 문제가 아니라 특정 상황에서 이렇게 하는 것이 낫다는 정도로만 쓴다고 생각하면 부담이 덜할 것이다.

본 포스팅은 도서 개발자의 글쓰기의 7장 내용을 참고하여 내 생각도 기록함.

개발자의 글쓰기는 독자, 주제가 불분명하다.

기존의 글쓰기와는 조금 다르게 주장할 것도 크게 없다.

그래서 개발자가 글을 쓸 때의 방향성은 세 가지가 있다.

1. 소재 우선 글쓰기
2. 자기 수준 글쓰기
3. 재미있는 글쓰기

1. 주제 의식을 버리고 소재 의식으로 쓰기

특정 대상이나 상황에 대한 자기만의 관점이나 생각이나 해결 방안 쓰기

어떤 주제에 대해 글을 풀기보다는 어떤 상황에서 내가 한 경험을 쓰는 것이다.

주제에 대해 목 메여있으면 정답을 추구하기 마련이고 글을 쓸 때 생각할 것이 더 많아져 글쓰기가 어느새부터 지루해지고 싫어진다..

2. 독자 수준이 아니라 자기 수준으로 쓰기

나도 항상 고민했던 부분이다. 블로그를 시작한 지 얼마 안 됐고 이전에는 깃허브에 공부한 내용을 정리하고 있었는데 어디까지 설명을 해야 할 지 고민이 많았다.

(왜냐면 다른 블로그들을 보면서 이해 안 되던 때가 있었고 그 때마다 다른 블로그를 찾는 수고를 했기 때문이다. 내 글을 보는 사람들은 이러한 수고를 안 했으면 하는 바람에 이런 고민을 했었다.)

하지만 책에서는 블로그에 글을 남기고 공부했던 것을 기록하는 것은 나와 실력이 비슷한 독자를 위한 것이라고 언급한다.

내가 아는 내용도 설명해주기 위해 쓸데없는 설명을 덧붙이면 원래 내가 쓰려했떤 주제에 집중이 흐트러질 수 있기 때문이다.

글에서 모르는 내용은 독자가 스스로 공부할 수 있게 해 놓는 것이 현명한 방법이다. (링크 걸기 등)

3. 재미있게 글을 쓰자

글 쓸 때 기교를 부려 재미있게 글을 만들자.

이러면 읽는 사람도 재밌고 쓰는 사람도 재밌어질 것이다.

너무 내용 설명에만 중점을 두지 말고 적당한 비유와 경험이야기 등등을 포함하면서? 글을 써보기.

토스 개발자 이응준님의 그런 REST API로 괜찮은가를 보고 정리하였습니다. 시간 가는 줄 모르고 봤네요.

용어 정리부터 하고 가자.

1. REST는 1998년 Roy. T. Fielding (로이 필딩)이라는 사람이 만들고 발표했다.

   REST : Representational State Transfer의 약자

2. REST는 분산 하이퍼 미디어 시스템(웹)을 위한 아키텍처 스타일이다.

   아키텍처 스타일이란 제약 조건들의 집합이다.

3. REST API는 REST 아키텍처 스타일을 따른 API이다.

한 줄 요약

로이 필딩이라는 사람이 만든 REST라는 제약 조건에 따라 구현한 API 아키텍처가 REST API이다.

자 그러면 REST API를 설계하려면 로이 필딩씨가 만든 제약 조건이 뭔지 알아야 그에 맞춰서 설계를 할 수가 있다.

REST는 어떤 제약 조건을 걸었나?

로이 필딩씨가 발표한 REST의 아키텍처 스타일

총 여섯 가지의 제약 조건을 내세웠다.

(로이 필딩 : 님들 이거 다 안 맞추면 REST API 아님 ㅅㄱ)

1. client-server
2. stateless
3. cache
4. uniform interface
5. layered system
6. code-on-demand (optional)

우선 1, 2, 3, 5번 조건을 보면 HTTP를 공부했다면 다 알법한 단어이다.

즉 HTTP만 잘 따라도 자연스럽게 만족한다!

또한 6번 조건은 서버에서 코드를 클라이언트에게 보내서 실행할 수 있어야 한다는 조건인데 이는 Java Script를 의미한다. 사용은 선택이므로 따로 다루지는 않겠다.

자 그럼 문제는 4번 조건이다.

이 조건이 대부분의 REST API에서 잘 지키기 힘든 조건이다.

이를 자세히 뜯어보자!

Uniform interface

이 uniform interface라는 제약 조건은 구체적으로 아래의 조건들로 이루어져 있다.

1. Identification of resources
2. manipulation of resources through representation
3. self-descriptive message
4. hypermedia as the engine of application state (HATEOAS)

이제 하나하나 알아보자!

1. Identification of resources

영어로 되있는데 천천히 보면 구글링 하다 블로그 같은 데서 본 것들일 것이다.

REST API에 대해 구글링을 하면 무조~~건 봤을 조건이다.

자원은 URI로 식별되어야 한다.

ㅋㅋ

여기서 자원은 html등과 같은 파일을 칭한다.

식별을 중점으로 생각해보면 서버에서 자원을 저장해놓는 방식을 key-value 맵으로 보자

key값이 uri가 되고 value가 html, css, js, image file..등과 같은 파일이다.

각각의 자원은 uri로 구분(식별)된다.

해당 URI로 클라이언트가 요청을 하면 Spring의 컨트롤러가 적절히 해당 파일을 리턴해주는 것을 생각해보면 된다.

@Controller
public Class ExampleController {

    @GetMapping(value = "/hello")
    public String sayHello() {
        return "hello"
    }

} 

• /hello URI로 요청이 오면 spring에서 hello.html 파일을 찾아 리턴(응답)해준다.

즉 서버에서 메세지에 Resourse를 담아 응답한다.

여기서 요청 메세지에서 요청하는 자원을 URI 형식으로 하자! 는 조건이다.

보통 개발을 하면 해당 조건은 잘 지켜지는 편이다.

2. Manipulation of resources through representation

이것도 영어로 보면 어려운데 설명하면 본 적이 있을 것이다.

일단 해석은 표현을 통한 자원 조작으로 해석할 수 있는데 이를 쉽게 말하면.

Method를 이용하여 자원을 조작하라.

이다.

자원 조작?? 조작도 뭔지 감이 잘 안 온다.

그냥 쉽게 말해 데이터(자원)를 버리던지 수정하던지 가져오던지 등등 갖고 놀고 하는 거다.

정리하면 메소드(GET, POST, PUT, DELETE..)를 이용해서 자원 조작(수정, 삭제 등)을 하라는 조건이다.

이것도 역시 HTTP Request Message의 start-line을 보면 잘 지켜지고 있다.

3. self-descriptive message

여기서부터 잘 지켜지지 않는 문제다.

이에 대한 해석은 이렇다.

메세지는 스스로를 설명해야 한다.

메세지에 담긴 내용으로만 이 메세지가 무슨 일을 하는지, 뭘 의미하는 지, 어떤 동작을 요구하는지 등등을 다 알 수 있어야 한다.

감이 잘 안 오는 우리를 위해 예시를 들어주신다.

해당 메시지를 살펴보면 자원을 받아오는 행위(GET)인지는 알겠다.

근데 어디로 요청을 하는지에 대한 정보가 없다.

그래서 이는 self-descriptive하지 못 한 메세지이다.

위 메세지에 목적지를 추가해주어 클라이언트가 어떤 자원을 요청한지를 명시해줬다.

더 이상 모르는 정보 없이 메세지만으로 의도를 확실히 알 수 있다.

그래서 self-descriptive한 메세지가 되었다.

또 다른 예시를 보자

해당 메세지를 클라이언트가 응답으로 받고 해석을 할려는데 어떤 문법으로 작성된 지도 모르겠다.

그래서 Content-type을 추가해주어 Body가 어떤 문법으로 이루어진지 알려주었고 클라이언트가 적절히 파싱해서 데이터를 얻을 수 있다.

하지만 이렇게는 부족하다.

왜냐면 데이터에 대해 op가 무엇인지, path가 뭘 의미하는지 아직 모른다.

따라서 다음과 같이 명세를 추가해준다.

json-patch+json이라는 명세를 추가해주어 클라이언트가 해당 명세를 보고 해석할 수 있게 된다.

명세에는 op, path가 무엇을 의미하는 지 적혀있을 것이다.

이렇게 해야 비로소 메세지만으로 완전한 해석을 할 수 있게 됐으며 self-descriptive message를 만족한다.

4. hypermedia as the engine of application state (HATEOAS)

hypermedia as the engine of application state 를 줄여서 HATEOAS(헤이티오스)로 부른다.

해석해보면

애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.

이다.

? 무슨 소리인지 잘 모르겠다.

우선 애플리케이션의 상태 전이에 대해 감을 잡아보자

애플리케이션은 사이트 링크에 따라 사용자에게 다른 화면을 표시한다.

각각의 화면들이 현재 애플리케이션의 상태!

페이지에 달려있는 여러가지 링크를 누르면 다른 페이지로 전환된다.

이것이 애플리케이션의 상태가 바뀐 것이다.

또한 상태가 바뀌기 위해서는 링크, 즉 Hyperlink를 이용했다.

이를 조합해보면

애플리케이션의 상태(현재 페이지)는 Hyperlink(링크)를 이용해 전이되어야(바뀌어야) 한다.

고 내 나름대로 해석했다.

예시를 보자~

HTML을 담은 메세지는 당연 만족한다.

a태그는 하이퍼링크이므로 이를 통해 상태가 전이된다!

JSON 데이터로도 HATEOAS를 만족할 수 있다.

헤더 정보에 Link를 통해 명시해줄 수 있다.

이 방식은 클라이언트가 명세를 통해 Link가 무엇인지 그리고 rel이 의미하는 바가 무엇인지를 알아야 한다.

자 uniform interface의 복잡한 조건들을 다 해석해봤다.

근데 왜 필요한지는 아직 잘 모르겠다..

Uniform Interface가 필요한 이유

독립적 진화를 위해서..

• 서버와 클라이언트가 각각 독립적으로 진화한다.
• 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
• REST를 만들게 된 계기 : "How do I improve HTTP without breaking the Web."

서버와 클라이언트 각각 따로 업그레이드 되기를 바라면서 해당 규칙을 만들었다.

웹에서 보면

• 웹 페이지를 변경했다고 웹 브라우저를 업데이트할 필요는 없다.

• 웹 브라우저를 업데이트 했다고 웹 페이지를 변경할 필요도 없다.

• HTTP 명세가 변경되어도 웹은 잘 동작한다.

• HTML 명세가 변경되어도 웹은 잘 동작한다.

위의 것들이 되는 이유는 Uniform interface 조건을 맞춰서 가능하다.

메세지에 포함된 내용만으로 모든 정보를 알 수 있으므로 한 쪽이 업그레이드되도 대처가 가능하다.

명세도 옛날 버전을 버리는 게 아니라 보존하며 하위 호환성을 유지하면서 발전해왔기 때문이다.

1. PT면접을 보는 이유?

지원자가 향후 입사 후 어떻게 문제를 해결해 가는지를 종합적으로 평가.

• 문제 해결을 위한 지원자의 사고 흐름을 판단.
• 소통을 잘 할 수 있는 지.
• 지원한 기업과 산업군에 대한 관심도.

1. 문제 인식 : 주어진 문제에서 요구하는 핵심을 이해하고 있는가?
2. 분석력/자원 관리 : 다양한 정보를 수집/가공하는 등의 자원활용을 통해 논리적으로 문제를 해결하는가?
3. 설득/의사소통 : 주장 외에 타당함 이유와 근거를 제시하고 간결, 명확하게 발표하는가?
4. 관련 지식 : 지원한 직무/기업/산업에 대한 이해를 하고 있는가?

2. 구성 요소

가장 잘 나오는 유형

1. 지원 직무 관련 이슈에 대한 문제 해결형
   • 기업의 최근 기술 이슈 정리 필요
2. 내용, 주제 설명형
3. 시사 관련

고려 사항

• 문제 범위
• 문제 선택
• 준비 시간
• 관련 자료
• 자료 검색
• 자료 검색
• 발표용 자료
• 답안 작성
• 발표 시간
• 질의 응답
• 개인 / 팀
• 판서 이용

3. 유형 별 공략

1) 문제해결형 PT

발표 순서

인사 -> 주제 강조 및 발표 내용 요약 -> 2 전략(간단하게) -> 1 고려요인 -> 2 전략(구체적으로) -> 3-1, 4-1 -> 3-2, 4-2 -> 2 전략(간단하게) -> 마무리 전체 요약 -> 마지막 인사 (경청해주셔서 감사합니다.)

1. 고려 요인(정답 이유) 
    1-1. 문제 인식 (문제 도출)
    1-2. 문제 분석 (원인 파악)
    1-3. 해결 전제 (고려 요소) : 고객, 기업현황, 소비자원, 경쟁사 상황, 시장 트렌드, 정부 정책, 여러 이슈 등등..

2. 전략(정답) 
    - 구체적 활동 1
    - 구체적 활동 2
    - 기대 효과

3. RISK 
    - 예상되는 어려움 1
    - 예상되는 어려움 2

4. 극복방안
    - 방안 1
    - 방안 2

발표자료 구성

• 한 페이지의 발표 자료를 요한다면 이런식으로 구성하자

2) 내용설명형 PT

발표 순서 인사 -> 주제강조 및 발표내용 요약 -> 2 정답(간단하게) -> 1 고려요인 -> 정답(구체적으로) -> 3-1, 4-1 -> 3-2, 4-2 -> 정답(간단하게) -> 마무리 전체 요약 -> 마무리 인사

1. 내용(주제) 확인 강조
    - 관련 전공/학과목
       - 관련 도서
    - 전문가 피드백

2. 주제에 대한 개념
    - 개념 1
    - 개념 2
    - 적용범위

3. RISK
    - 예상되는 어려움
    - 적용 시 주의사항

4. 극복방안
    - 방안 1
    - 방안 2
       - 방안 3

발표자료 구성

• 21/12/02(일) : PT면접 주제문 답안 작성
• 프로그래머스에서 1시간동안 진행
• 제출한 답안으로 12월 중 면접 당일에 PT발표 후 질의응답 진행

인터넷 서칭이 가능하고 발표자료는 파워포인트를 사용하여 만들면 된다.

PT 분량은 총 두 페이지를 제작해야하며 첫 페이지는 주제만 적으면 되서 실질적인 분량은 한 페이지다.

PT 주제 정리

대기업 PT 면접 기출 모음 60선

2. KT ds 면접 예상 질문

KT ds 면접 후기 기반 면접 질문 정리

기업별/직무별 면접 질문 500선

사전과제 관련 질문

1. 코딩테스트 문제 중 주어진 TC 이외 다른 TC도 넣어서 테스트해봤는지?
2. 코딩테스트 왜 이렇게 많이 틀렸는지?

경험 관련 질문

1. 경험했던 프로젝트 관련 질문

   • 프로젝트 내용
   • 이 과정에서 배운 것
   • 어려웠던 점과 극복 방법
   • 팀 내 위치와 역할
   • 프로젝트 산출물이 있는지
   • 프로젝트 개발 과정

2. 실제 개발해본 내용에 대한 설명

3. 인턴경험에 대해 간단히 어떤 것을 하였는지 설명해 달라

4. 조별면접 씨는 왜 조장을 했나? 왜 ~를 도와줬나?

5. 만약 혼자서 프로젝트 계획부터 짜서 시작할 수 있는 지?

직무, 기술 관련 질문

1. SI/SM 이 무엇이라 생각하는가?

   • SI : System Integration, 기업이 필요로 하는 시스템에 관한 기획, 개발, 운영 등 서비스를 제공하는 일입니다.
   • SM : System Management, 기업이 운영중인 시스템을 더 개발하고, 운영, 배포하는 등의 서비스를 제공하는 일입니다.

2. Git의 어떤 전략을 써서 버전관리를 하였는가?

   • 제대로 된 협업 경험이 없어 특정 전략을 사용해 본 경험은 없으나 Github-flow 전략으로 혼자 브랜치를 만들어 따라가 본 적이 있습니다.

3. Spring Framework 설명

   • 자바 플랫폼 기반 오픈 소스 프레임워크.
   • 특징 : IoC, DI, AOP, 확장성 좋음(라이브러리 지원), 영속성을 위한 다양한 인터페이스 제공

4. CI/CD 설명

5. Process / Thread 차이

6. 정렬 알고리즘

7. DB 장애가 발생했을 때 무엇을 살펴볼 것이며 어떤 부분을 누구와 같이 해결할 것인가?

8. 가장 자신있는 기술은?

9. 써본 툴이 있는가

10. 자사 vs 타사 클라우드 비교 설명

그 외

1. 본인의 역량으로 우리 회사에 어떤 도움이 될 수 있다고 생각하는가?
2. 본인의 성격 장단점
3. 본인의 협상의 기술
4. KT ds 입사 후 목표
5. 자소서에 적은 원하는 직무를 하지 못하게 될 수도 있는데 어떻게 할 것인가?
6. KT ds의 주요 사업 아는 것

단순 명령어만 열거하여 개발환경 구성을 빠르게 하는 목적으로 작성하였습니다.

1. Docker 설치

   Docker Download

2. MySQL Image 받아오기

    $ docker pull mysql

3. 이미지로 컨테이너 실행하기

    $ docker run --name [Container Name] -e MYSQL_ROOT_PASSWORD=[password] -p 3306:3306 -d [Image Name]

4. 컨테이너에 bash로 접속

    $ docker exec -it [Container Name] bash

5. 컨테이너에서 MySQL 실행하기

    $ mysql -u root -p

6. MySQL 사용자 생성 및 권한 주기

    > CREATE user '[username]'@'%' identified by '[password]';
    > GRANT ALL PRIVILEGES ON *.* TO '[username]'@'%';

7. DB 생성 및 확인

       > CREATE DATABASE [db name] CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;
    > use [db name];

8. 프로젝트와 연결하기

   src/main/resources/application.yml

    spring:
        datasource:
            driver-class-name: com.mysql.cj.jdbc.Driver
            url: jdbc:mysql://localhost:3306/[db name]?serverTimezone=Asia/Seoul
            username: [username]
            password: [password]