BadRequestError: Error code: 400 - {'error': {'message': 'you must provide a model parameter', 'type': 'invalid_request_error', 'param': null, 'code': null}}

처음엔 외부 API 서버 측 일시적인 문제겠거니... 하고 우선 모니터링에 더 집중했다. (건드린 사람이 없었고 코드에서도 이상이 없어보였으니까!!!) 그런데 잠깐... OpenAI status도 특이사항 없었고 여러 가지 상황을 가정해보았는데 모두 말이 안 되었다. 400이면 클라이언트(=나) 잘못인데... 다시 분석해보았다.

1. 언제 you must provide a model parameter가 뜨는가?

1. body에 model 값을 보내주지 않았을 때

메시지 그대로다. 정말로 model을 null로 보내주거나 아예 보내주지 않으면 해당 메시지가 뜨게 된다. OpenAI에서 지원하지 않는 모델명을 설정하여 보내줄 경우 다른 메시지가 뜬다.

2. header에 Content-Type을 application/json으로 설정하지 않았을 때

header에 Content-Type을 아예 누락시키거나 application/json으로 정확히 설정하지 않으면 해당 메시지가 뜨게 된다 (오타도 조심하자).

리서치 및 실험 결과 위 두 가지 케이스를 발견하였는데 더 있을 수도...

2. RestTemplate 객체 생성 및 초기화 부분 확인

여기! 를 검색하면 원인 코드를 좀 더 빠르게 확인할 수 있을 것이다.

model을 명시적으로 보내주지 않는 케이스가 아니라면 Content-Type을 header에 설정하는 부분을 살펴볼 필요가 있다. (Spring Boot 기준 보통 RestTemplate을 bean으로 관리하거나 서비스 생성자 레벨에서 초기화하여 사용할테니 그 부분을 유심히 살펴보면 될 것 같다.) 본인은 아래와 같이 RestTemplate를 초기화하여 사용했었다.

HttpHeaders headers = new HttpHeaders();
       headers.setContentType(MediaType.APPLICATION_JSON);
       headers.setBearerAuth(API_KEY);

this.restTemplate = restTemplateBuilder
       .rootUri("https://api.openai.com")
       .interceptors((request, body, execution) -> {
               request.getHeaders().addAll(headers);
               return execution.execute(request, body);
       })

                ...

       .build();

대충 봤을 때는 이상 없어보이는데 결론부터 이야기하자면 Content-Type application/json이 두 번 설정된다. 그 이유가 궁금하여 내부 코드를 살짝 열어보았다.

RestTemplateBuilder.java

public RestTemplate build() {
    return configure(new RestTemplate());
}

RestTemplateBuilder를 통해 RestTemplate()을 만들게 되는 경우 RestTemplate() 기본 생성자를 호출한다.

RestTemplate.java

public RestTemplate() {
        ...
        if (jackson2Present) {
            this.messageConverters.add(new MappingJackson2HttpMessageConverter());
        }
        ...
    }

RestTemplate 생성자의 일부다. jackson2Present가 true인 조건은 ObjectMapper 클래스의 존재 여부인데 본인 프로젝트에서는 사용하고 있었기 때문에 messageConverters에 MappingJackson2HttpMessageConverter가 추가된다.

MappingJackson2HttpMessageConverter.java

/**
 * Construct a new {@link MappingJackson2HttpMessageConverter} with a custom {@link ObjectMapper}.
* You can use {@link Jackson2ObjectMapperBuilder} to build it easily.
* @see Jackson2ObjectMapperBuilder#json()
*/
public MappingJackson2HttpMessageConverter(ObjectMapper objectMapper) {
    super(objectMapper, MediaType.APPLICATION_JSON, new MediaType("application", "*+json"));
}

protected AbstractJackson2HttpMessageConverter(ObjectMapper objectMapper, MediaType... supportedMediaTypes) {
    this(objectMapper);
    setSupportedMediaTypes(Arrays.asList(supportedMediaTypes));
}

MappingJackson2HttpMessageConverter 생성자를 따라가보면 supportedMediaTypes에 application/json, application.*+json이 추가되는 걸 볼 수 있다. 이제 이 값들이 어떻게 사용되는지 알아보자.

RestTemplate.java

@Override
@SuppressWarnings("unchecked")
public void doWithRequest(ClientHttpRequest httpRequest) throws IOException {
    super.doWithRequest(httpRequest);
    Object requestBody = this.requestEntity.getBody();
    if (requestBody == null) {
        HttpHeaders httpHeaders = httpRequest.getHeaders();
        HttpHeaders requestHeaders = this.requestEntity.getHeaders();
        if (!requestHeaders.isEmpty()) {
            requestHeaders.forEach((key, values) -> httpHeaders.put(key, new ArrayList<>(values)));
        }
        if (httpHeaders.getContentLength() < 0) {
            httpHeaders.setContentLength(0L);
        }
    }
    else {
        Class<?> requestBodyClass = requestBody.getClass();
        Type requestBodyType = (this.requestEntity instanceof RequestEntity ?
                ((RequestEntity<?>)this.requestEntity).getType() : requestBodyClass);
        HttpHeaders httpHeaders = httpRequest.getHeaders();
        HttpHeaders requestHeaders = this.requestEntity.getHeaders();
        MediaType requestContentType = requestHeaders.getContentType();
        for (HttpMessageConverter<?> messageConverter : getMessageConverters()) {
            if (messageConverter instanceof GenericHttpMessageConverter) {
                GenericHttpMessageConverter<Object> genericConverter =
                        (GenericHttpMessageConverter<Object>) messageConverter;
                if (genericConverter.canWrite(requestBodyType, requestBodyClass, requestContentType)) {
                    if (!requestHeaders.isEmpty()) {
                        requestHeaders.forEach((key, values) -> httpHeaders.put(key, new ArrayList<>(values)));
                    }
                    logBody(requestBody, requestContentType, genericConverter);
                    genericConverter.write(requestBody, requestBodyType, requestContentType, httpRequest);
                    return;
                }
            }
            else if (messageConverter.canWrite(requestBodyClass, requestContentType)) {
                if (!requestHeaders.isEmpty()) {
                    requestHeaders.forEach((key, values) -> httpHeaders.put(key, new ArrayList<>(values)));
                }
                logBody(requestBody, requestContentType, messageConverter);
                ((HttpMessageConverter<Object>) messageConverter).write(
                        requestBody, requestContentType, httpRequest); // 여기!
                return;
            }
        }
        String message = "No HttpMessageConverter for " + requestBodyClass.getName();
        if (requestContentType != null) {
            message += " and content type \"" + requestContentType + "\"";
        }
        throw new RestClientException(message);
    }
}

REST API 요청을 하게 되면 결국 위 메소드를 호출하게 되는데 여기서 messageConverter의 write 메소드에 집중해보자.

AbstractHttpMessageConverter.java

@Override
public final void write(final T t, @Nullable MediaType contentType, HttpOutputMessage outputMessage)
        throws IOException, HttpMessageNotWritableException {

    final HttpHeaders headers = outputMessage.getHeaders();
    addDefaultHeaders(headers, t, contentType); // 여기!

    if (outputMessage instanceof StreamingHttpOutputMessage) {
        StreamingHttpOutputMessage streamingOutputMessage = (StreamingHttpOutputMessage) outputMessage;
        streamingOutputMessage.setBody(outputStream -> writeInternal(t, new HttpOutputMessage() {
            @Override
            public OutputStream getBody() {
                return outputStream;
            }
            @Override
            public HttpHeaders getHeaders() {
                return headers;
            }
        }));
    }
    else {
        writeInternal(t, outputMessage);
        outputMessage.getBody().flush();
    }
}

/**
 * Add default headers to the output message.
 * <p>This implementation delegates to {@link #getDefaultContentType(Object)} if a
 * content type was not provided, set if necessary the default character set, calls
 * {@link #getContentLength}, and sets the corresponding headers.
 * @since 4.2
 */
protected void addDefaultHeaders(HttpHeaders headers, T t, @Nullable MediaType contentType) throws IOException {
    if (headers.getContentType() == null) {
        MediaType contentTypeToUse = contentType;
        if (contentType == null || !contentType.isConcrete()) {
            contentTypeToUse = getDefaultContentType(t); // 여기!
        }
        else if (MediaType.APPLICATION_OCTET_STREAM.equals(contentType)) {
            MediaType mediaType = getDefaultContentType(t);
            contentTypeToUse = (mediaType != null ? mediaType : contentTypeToUse);
        }
        if (contentTypeToUse != null) {
            if (contentTypeToUse.getCharset() == null) {
                Charset defaultCharset = getDefaultCharset();
                if (defaultCharset != null) {
                    contentTypeToUse = new MediaType(contentTypeToUse, defaultCharset);
                }
            }
            headers.setContentType(contentTypeToUse); // 여기!
        }
    }
    if (headers.getContentLength() < 0 && !headers.containsKey(HttpHeaders.TRANSFER_ENCODING)) {
        Long contentLength = getContentLength(t, headers.getContentType());
        if (contentLength != null) {
            headers.setContentLength(contentLength);
        }
    }
}

getDefaultContentType() 를 통해 contentType을 가져와서 헤더에 Content-Type을 설정해준다.

HttpHeaders.java

/**
 * Set the {@linkplain MediaType media type} of the body,
 * as specified by the {@code Content-Type} header.
 */
public void setContentType(@Nullable MediaType mediaType) {
    if (mediaType != null) {
        Assert.isTrue(!mediaType.isWildcardType(), "Content-Type cannot contain wildcard type '*'");
        Assert.isTrue(!mediaType.isWildcardSubtype(), "Content-Type cannot contain wildcard subtype '*'");
        set(CONTENT_TYPE, mediaType.toString());
    }
    else {
        remove(CONTENT_TYPE);
    }
}

@Override
public void set(String headerName, @Nullable String headerValue) {
    this.headers.set(headerName, headerValue);
}

final MultiValueMap<String, String> headers; // 여기!

그리고 headers는 MultiValueMap이었다. 따라서 중복 값이 들어갈 수 있었던 것이다. 실제로 postman에서도 Content-Type을 중복으로 요청하였더니 진짜 동일한 메시지가 뜨는 것을 확인할 수 있었다!!!

3. 정리를 마치며

오랫동안 정상 동작했던 코드라도 너무 믿지 말고 외부 Call이 끼어있다면 다시 한 번 확인해보자. 400 에러면 본인 잘못일 확률이 매우 높다... 오류 찾기 전까지는 매우 답답했지만 원인을 알아내고 RestTemplate 내부 코드를 열어보는 과정은 재미있었다 🙂

주제는 크게 AI를 활용한 프로젝트 및 프론트엔드에 TDD를 적용한 사례 소개였으며 백엔드 개발자인 본인에게도 도움이 될 만한 주제라고 생각했는데 이유는 다음과 같다.

• 회사에서 AI를 활용한 프로젝트를 진행한 적이 있었는데 구조, 성능, 예외처리 등 고민할 사항이 많았다.
• 프로덕트 팀에 속하게 되면서 예전보다는 직군이 다른 엔지니어 분들과 소통할 기회가 많아졌고 자연스레 개발 이야기를 나누는 일이 많아졌는데 전부 이해하지는 못하더라도 이야기를 듣는 게 재밌다.
• 프론트에서는 어떻게 테스트를 진행하는지 궁금했다.

1. 내용

이번 세미나는 지난 if(kakaoAI)2024 컨퍼런스에서 진행되었던 기술 세션들을 압축한 형태로 보여주었다고 하여 내용은 영상으로 첨부하였다. (그리고 복습하고 싶어서...ㅎㅎ)

(1) AI Agent 기반 스마트 AI 마이 노트 (링크)

사용자가 어떤 질문을 해야하는지 자체를 고민해야 한다는 건 쉬운 서비스는 아니라는 말씀이 인상 깊었다. (가령 chat GPT가 처음 출시되었을 때 뭘 어떻게 질문해야지 등을 고민하는 것) 기능 조직에만 속해있을 때는 단순히 들어오는 요청만 수동적으로 처리했었는데 프로덕트 조직에 속하게 된 이상 기능을 만들기 전에 왜 필요한지에 대해 한 번 더 생각하는 것이 필요하겠다는 점을 다시 한 번 느꼈다. (기술적으로 불가능하기 때문에 다 해드릴 수는 없겠지만...)

(2) TDD로 앞서가는 프론트엔드: 디자인, API 없이도 개발을 시작하는 방법 (링크)

다른 세션은 기술적으로 신기하다 (또는 어렵다) 라고 생각했더라면 이번 세션은 재밌게 들으면서 반성을 많이 했던 것 같다. 클라이언트 역할로 Back To Back API 연동을 해본 경험에 이어서 프론트엔드 개발자의 고충을 간접적으로나마 경험할 수 있었다. 결론적으로 API 문서 초안 작성 시 검토를 신중하게 해야겠다고 다짐하였다.

또한 프론트엔드라고는 사이드 프로젝트만 끄적거려본 사람으로써 테스트가 어떻게 이루어지는지 궁금했는데 그 궁금증이 조금은 해소된 것 같다. 특히 API Layer와 View Layer 사이에 ViewModel Layer를 둠으로써 api 스펙이 바뀌어도 viewModel의 구조 변환 없이 데이터 매핑 부분만 바꾸는 방향을 제시하면서 예제를 보여주셨는데 이 부분이 가장 재밌으면서도 고민이 많아졌던 것 같다. (외부 API 호출할 때 백엔드 입장으로는 view 대신 service로 본다면 비슷한 것 같기도...?)

(3) 업무 효율화를 위한 카카오 사내봇 개발기 (링크)

프로젝트 진행 중 간혹 다른 팀의 도메인을 알아야 하는 순간이 종종 오는데 그 때마다 담당자를 찾아뵙기도 죄송스럽고 부재 시 난감했던 적도 있었는데 이런 기능이 있다면 일의 효율성이 높아질 것으로 보여 쉽지 않겠지만 개인적으로 사내에도 도입하고 싶었던 프로젝트였다.

2. 질의응답

올해 외부 API를 통해 생성형 AI를 사용할 일이 있었으며 신규 프로젝트 리서치 시 AI를 사용해야 할 일이 있었다. 그런데 배경지식 없이 사용하기에는 실무에 도입해도 되는지에 대한 확신이 없었고 깊게 공부하자니 다른 백엔드 기술들도 공부할 게 많기 때문에 막막해서 아래와 같은 질문을 하게 되었다.

프로젝트에서 직간접적으로 AI를 활용하는 케이스가 늘어나고 있는데 백엔드 개발자로서 적어도 어디까지 대비하면 좋을지에 대한 조언을 해주시면 감사하겠습니다.

많은 멋진 질문 사이에서 감사하게도 본인 질문에 대해 답변해주셨다. 그것도 연차별로 나누어서... 🥹

신입 LLM으로 인해 개발에 대한 진입장벽이 낮아졌으며 데이터 엔지니어링, k8s, docker, AI 등 쌓아야 할 기술이 늘어나 취업이 어려워진 건 사실이다. 경력 모델 형성 방법 등 딥하게 들어갈 필요까지는 없지만 ML 파이프라인, 필요한 컴포넌트 등 큰 흐름 위주로 파악할 필요는 있다.

직장과 거리가 가깝지 않아 퇴근 후 바로 찾아가느라 그날 하루는 정신 없었지만 그래도 참여하기를 매우 잘한 것 같다. 이 글을 마치면서 다시 한 번 참여할 기회를 주셔서 감사하다는 말씀 드리고 싶다.

p.s. 죠르디는 귀엽다.

명령어 라인 개발자 도구는 설치된 상태에서 vscode에서 python 코드 작성 후 실행하는데 오류가 떴다.

[Running] python -u "(...).py"
xcode-select: Failed to locate 'python', requesting installation of command line developer tools.

[Done] exited with code=72 in 0.025 seconds

해결 방법

현재 xcode 확인

xcode-select -p

/Library/Developer/CommandLineTools

심볼릭 링크

sudo ln -s /Library/Developer/CommandLineTools/usr/bin/python3 /Library/Developer/CommandLineTools/usr/bin/python

확인해보니 python binary가 없었고 python3 심볼릭 링크를 통해 해결하였다. 혹시 나중에 똑같은 문제에 직면했을 때 슬쩍 떠올리도록 정리해보았다.

참고 링크 https://forums.developer.apple.com/forums/thread/704099

특정 메소드를 트랜잭션 내에서 수행하도록 하고싶을 때 @Transactional 메소드를 선언하여 사용할 수 있다. 아래와 같이 말이다.

@Transactional
public void test() {
    // 구현
}

By default, a transaction will be rolled back on {@link RuntimeException} and {@link Error} but not on checked exceptions (business exceptions).

기본적으로 스프링 프레임워크에서는 CheckedException일 경우 지금까지의 내용은 커밋하고 UnCheckedException일 경우 모두 롤백한다. 스프링은 EJB 규칙을 따르기 때문이다.

실제 코드

내부가 궁금해서 열고 들어가봤더니 예외가 발생된 이후 롤백하는 메소드가 존재한다. txInfo.transactionAttribute.rollbackOn(ex) 에 주목하자. 해당 메소드에서 UnCheckedException이나 Error가 발생하면 던지는 것을 볼 수 있다.

/**
 * TransactionAspectSupport.java
 */
private Mono<Void> completeTransactionAfterThrowing(@Nullable ReactiveTransactionInfo txInfo, Throwable ex) {
    if (txInfo != null && txInfo.getReactiveTransaction() != null) {
        if (logger.isTraceEnabled()) {
            logger.trace("Completing transaction for [" + txInfo.getJoinpointIdentification() +
                    "] after exception: " + ex);
        }
        if (txInfo.transactionAttribute != null && txInfo.transactionAttribute.rollbackOn(ex)) {
            return txInfo.getTransactionManager().rollback(txInfo.getReactiveTransaction()).onErrorMap(ex2 -> {
                        logger.error("Application exception overridden by rollback exception", ex);
                        if (ex2 instanceof TransactionSystemException systemException) {
                            systemException.initApplicationException(ex);
                        }
                        else {
                            ex2.addSuppressed(ex);
                        }
                        return ex2;
                    }
            );
        }
        else {
            // We don't roll back on this exception.
            // Will still roll back if TransactionStatus.isRollbackOnly() is true.
            return txInfo.getTransactionManager().commit(txInfo.getReactiveTransaction()).onErrorMap(ex2 -> {
                        logger.error("Application exception overridden by commit exception", ex);
                        if (ex2 instanceof TransactionSystemException systemException) {
                            systemException.initApplicationException(ex);
                        }
                        else {
                            ex2.addSuppressed(ex);
                        }
                        return ex2;
                    }
            );
        }
    }
    return Mono.empty();
}

/**
 * DefaultTransactionAttribute
 */
@Override
public boolean rollbackOn(Throwable ex) {
    return (ex instanceof RuntimeException || ex instanceof Error);
}

checked exception 발생 시 롤백하고 싶다면?

Transactional 메소드는 rollbackFor 속성을 제공한다. (자매품 rollbackForClassName())

public @interface Transactional {
    /**
     * Defines zero (0) or more exception {@linkplain Class types}, which must be
     * subclasses of {@link Throwable}, indicating which exception types must cause
     * a transaction rollback.
     * <p>By default, a transaction will be rolled back on {@link RuntimeException}
     * and {@link Error} but not on checked exceptions (business exceptions). See
     * {@link org.springframework.transaction.interceptor.DefaultTransactionAttribute#rollbackOn(Throwable)}
     * for a detailed explanation.
     * <p>This is the preferred way to construct a rollback rule (in contrast to
     * {@link #rollbackForClassName}), matching the exception type and its subclasses
     * in a type-safe manner. See the {@linkplain Transactional class-level javadocs}
     * for further details on rollback rule semantics.
     * @see #rollbackForClassName
     * @see org.springframework.transaction.interceptor.RollbackRuleAttribute#RollbackRuleAttribute(Class)
     * @see org.springframework.transaction.interceptor.DefaultTransactionAttribute#rollbackOn(Throwable)
     */
    Class<? extends Throwable>[] rollbackFor() default {};
}

실제 코드

RuleBasedTransactionAttribute의 rollbackOn()으로 동작하게 된다. 안에 보이는 rollbackRules에 해당하는 값들이 위 어노테이션에서 설정한 값들이다. 만약 발생한 exception이 rollbackRules에 해당하지 않는다면 상위 rollbackOn()을 호출하게 되는데 이는 위에서 봤던 DefaultTransactionAttribute가 되어 UnCheckedException 혹은 Error일 경우 롤백하도록 한다.

    /**
     * Winning rule is the shallowest rule (that is, the closest in the
     * inheritance hierarchy to the exception). If no rule applies (-1),
     * return false.
     * @see TransactionAttribute#rollbackOn(java.lang.Throwable)
     */
    @Override
    public boolean rollbackOn(Throwable ex) {
        RollbackRuleAttribute winner = null;
        int deepest = Integer.MAX_VALUE;

        if (this.rollbackRules != null) {
            for (RollbackRuleAttribute rule : this.rollbackRules) {
                int depth = rule.getDepth(ex);
                if (depth >= 0 && depth < deepest) {
                    deepest = depth;
                    winner = rule;
                }
            }
        }

        // User superclass behavior (rollback on unchecked) if no rule matches.
        if (winner == null) {
            return super.rollbackOn(ex);
        }

        return !(winner instanceof NoRollbackRuleAttribute);
    }

Spring Boot를 이용해 개발을 하면서 ObjectMapper를 직간접적으로 사용하고 있었다. 기본 ObjectMapper를 사용했을 때 자주 잊어버리는 항목인 것 같아 이번 기회에 정리해보았다.

class TestObject {
    private Long id;
    private String name;
}

1. 역직렬화 (String -> Object)

Object에 해당하는 클래스에 @NoArgsConstructor가 필요하고 @Getter 또는 @Setter가 필요하다.

spring boot에서 request json 문자열을 DTO 객체로 변환하는 과정이다.

예시

예시 코드

ObjectMapper mapper = new ObjectMapper();
final String value = "{\"name\":\"test\",\"id\":1}";

TestObject resObject = mapper.readValue(value, TestObject.class);

1) TestObject에 @Getter 또는 @Setter를 붙이지 않은 경우

Exception in thread "main" com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "name" (class com.test.teamlog.global.security.TestObject), not marked as ignorable (0 known properties: ])
 at [Source: (String)"{"name":"test","id":1}"; line: 1, column: 10] (through reference chain: com.test.teamlog.global.security.TestObject["name"])

필드가 없다면서 UnrecognizedPropertyException이 발생한다.

2) TestObject에 @NoArgsConstructor를 붙이지 않은 경우

Exception in thread "main" com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of `com.test.teamlog.global.security.TestObject` (no Creators, like default constructor, exist): cannot deserialize from Object value (no delegate- or property-based Creator)

no Creators, like default constructor 라면서 기본 생성자를 만들어달라고 에러를 뱉는다.

추가 내용

인턴 시절 실무에서 뭣모르고 했다가 종종 버그가 발생했던 사례가 떠올라 적어보기로 했다. 당시 특정 필드의 값을 request로부터 받는 시점에 변환하고 싶었던 모양이었는지 request dto에 해당하는 클래스의 필드에 대한 setter를 재정의했다. (왜 그랬지...) 아래와 같이 말이다.

@Getter
class TestObject {
    private Long id;
    private String name;

    public void setName(String name) {
        this.name = "Hello, my name is " + name;
    }
}

2. 직렬화 (Object -> String)

spring boot에서 DTO 객체 -> response로 변환하는 과정이다.

1) @Getter가 없는 경우

Exception in thread "main" com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer found for class com.test.teamlog.global.security.TestObject and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS)

기본적으로 public인 필드에 접근하게 된다. 즉, 필드를 public으로 열어주거나 getter 메소드를 열어주어 접근 가능하도록 해야한다.

"진아, Rest API가 뭐야?" "어... 저도 정확하게 정의하기는 어렵지만... (어쩌구 저쩌구)"

그러게... Restful API가 뭘까? 1년 넘게 많은 API를 접했지만 정작 'Rest API'가 무엇인지 고민해보는 시간은 갖지 못했던 것 같다. 그래서 이번 기회에 고민해보기로 했다.

1. 보통 개발자가 아는 Rest API의 정의

REST란 Representational State Transfer의 약자로 분산 하이퍼미디어 시스템을 위한 아키텍쳐 스타일이다. 즉, 자원의 이름으로 구분하여 해당 자원의 상태를 주고받는 것이다.

a. Rest API란?

REST(Representational State Transfer) API는 요청을 보내는 API 주소만으로도 대략 어떤 요청인지 파악이 가능하도록 설계한 API다.

1)REST의 구성

• 자원(Resource) - HTTP URI
• 행위(Verb) - HTTP Method
• 표현(Representations) - HTTP Message PayLoad

b. 사실 Rest API가 아니여도 기능 개발에는 문제가 없다.

사실 Restful하게 설계하지 않아도 기능이 동작하도록 구현하는 데에는 아무 문제가 없다. 아래 Spring Boot를 이용해 작성한 코드를 보자.

@RestController
@RequestMapping("/api/accounts")
@RequiredArgsConstructor
public class AccountApiController {
    @GetMapping("/duckling/{idx}")
    public int delete(@PathVariable Long idx) {
        // 회원 탈퇴하는 로직
        return 1;
    }
}

탈퇴할 계정의 idx를 알고, 비즈니스 로직에만 이상이 없다면 이 API는 정상적으로 동작할 것이다.

c. 그럼에도 불구하고 Rest API가 필요한 이유

하지만...

GET /api/accounts/duckling/{idx}

이렇게 API를 제시했을 때 해당 API를 사용할 다른 개발자가, 혹은 추후 유지보수 할 다른 동료 개발자가 과연 어떤 API인지 알 수 있을까? 일단 엉망진창으로 예시를 든 본인도 모르겠다.

위에서 언급한 REST 구성을 잘 이용해 API를 개선해보자.

AS-IS GET /api/accounts/duckling/{idx}
TO-BE DELETE /api/accounts/{idx}

훨씬 나아졌다. API만 보고도 특정 idx에 해당하는 계정을 탈퇴할 떄 사용한다는 것을 짐작할 수 있다.

2. 좀 더 깊게 알아보자

a. REST 제약조건

• client-server
• stateless
• cache
• uniform interface
• layered system
• code-on-demand (optional)

위 조건들은 uniform interface 빼고 웬만한 HTTP API에서도 모두 지켜질 수 있다. 그렇다면 uniform interface가 무엇인지 알아보자.

b. uniform interface

uniform interface 정의를 찾아보면 아래와 같이 나온다.

URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다.

하지만 본인은 저 한 줄로는 이해하기 어려웠다. 따라서 uniform interface를 만족시키는 조건에 대입해서 생각해보려고 한다.

1) uniform interface를 만족시키는 조건

a) identifiaction of resources

• resource가 URI로 식별되면 된다.
• URI로 지정한 리소스에 대한 조작

• ex) '회원'이라는 리소스에 접근하기 위한 API를 설계할 때 localhost:8080/api/accounts 처럼 설계할 수 있다.

b) manipulation of resources through representations

• representations 전송을 통해 resources를 조작해야 한다.
• 여기서 representations이란 GET, POST, PUT, DELETE 등의 HTTP 메소드를 뜻한다.
• 통일되고 한정적인 인터페이스로 수행
  • 보편적으로 등록(POST), 수정(PUT, PATCH), 삭제(DELETE), 조회(GET) 와 같이 사용한다.
  • ex) 회원 탈퇴 API 생성 시 GET localhost:8080/api/accounts/delete 처럼 명시할 수도 있겠지만 약속한 대로 DELETE localhost:8080/api/accounts 처럼 나타내면 더 깔끔하고 명확해진다.

c) self-descriptive messages

• 메시지가 스스로 설명해야 한다.
• (지켜지기 어렵다)

  d) HATEOAS

• application의 상태는 하이프링크를 이용해서 전이되어야 한다.
• (지켜지기 어렵다)

사실 identifiaction of resources와 manipulation of resources through representations는 흔히 알고있는 REST API의 특징이다. 하지만 REST API에서 uniform interface가 지켜지지 않는다고 하는 이유는 self-descriptive messages와 HATEOAS 때문이다.

2) self-descriptive messages 만족하기

self-descriptive는 메시지가 스스로 설명되어야 한다 즉, 메시지의 모든 요소는 메시지만 보고 그 뜻을 알아야 한다는 것이다.

HTTP/1.1 200 OK
Content-Type: application/json
{"idx":1,"name":"윤진"}

사람이 봤을 떄는 json 타입으로 idx는 1이고 이름은 '윤진'이구나 하고 알겠지만, 기계는 이를 알지 못한다. 따라서 RESTful하지 않는 설계라고 할 수 있다. 그렇다면 어떻게 해야 만족할 수 있을까?

a) Media type 정의 (IANA)

HTTP/1.1 200 OK
Content-Type: (사용자 정의 media type)
{"idx":1,"name":"윤진"}

1. 미디어 타입을 정의 후 각 속성의 의미가 담긴 미디어 타입 문서를 작성한다. (위 예제에서는 idx, name이 의미하는 것을 적는다.)
2. IANA에 미디어 타입을 등록한다. 위에서 작성한 문서를 미디어 타입 명세로 등록한다.
3. IAMA에 등록된 명세를 찾을 수 있으므로 메시지의 의미를 해석할 수 있게 된다.

b) link header에 명세를 확인할 수 있는 링크 첨부

HTTP/1.1 200 OK
Content-Type: application/json
Link: <https://...>;  rel="profile"
{"idx":1,"name":"윤진"}

1. json을 구성하는 요소들이 무엇을 의미하는지를 나타내는 문서를 작성한다.
2. link 헤더에 명세를 확인할 수 있는 링크를 넣어 응답에 넘긴다.

단점: 클라이언트가 Link 헤더와 profile을 이해해야 하며 미디어 타입이 아닌 Link 헤더를 통해 판단하기 때문에 content negotiation할 수 없다.

3) HATEOAS 만족하기

HATEOAS는 Hypermedia As The Engine Of Application State의 약자로 애플리케이션은 Hyperlink를 이용해서 전이가 되어야 한다는 뜻이다. html처럼 말이다.
예를 들어 아래의 html에서는 a 태그를 통해 다음 상태가 결정된 것을 확인할 수 있다. 따라서 HTML은 HATEOAS를 만족한다.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>
    <h1>사용자별 소속 팀</h1>
    <a href="localhost:8080/accounts/1/teams">유저1의 소속 팀</a>
</body>
</html>

하지만 response가 아래와 같은 json 형식이라면?

HTTP/1.1 200 OK
Content-Type: application/json
{"idx":1,"name":"윤진"}

응답을 받는 시점에 response만 담기게 되고 다음 상태를 알 수 없다. 따라서 RESTful하지 못하다. 어떻게 해야 HATEOAS를 만족할 수 있을까?

단순 JSON이 아닌, HAL JSON을 이용한다.

HAL Hypertext Application Language의 약자로 JSON, XML 코드 내의 외부 리소스에 대한 링크를 추가하기 위한 특별한 데이터 타입이다.

HTTP/1.1 200 OK
Content-Type: application/hal+json
{
  "data": { // HAL JSON의 리소스 필드
    "id": 1000,
    "name": "게시글 1",
    "content": "HAL JSON을 이용한 예시 JSON"
  },
  "_links": { // HAL JSON의 링크 필드
    "self": {
      "href": "http://localhost:8080/api/article/1000" // 현재 api 주소
    },
    ...
  }
}

• data: 요청에 대한 응답 데이터
• _links: 접근 가능한 추가 API

이렇게 하면 클라이언트에서 API를 호출하는 부분을 하드코딩할 필요가 없어지며 접근 가능한 추가 API가 바뀌어도 해당 API를 호출하는 쪽은 변경할 필요 또한 없어진다.

3. 느낀 점

공부하는 과정에서 uniform interface의 한 줄 정의만 봤을 때는 내가 아는 REST API랑 같은 것 같은데 왜 만족하지 못한다는 거지...? 부터 시작해서 생각이 많았다. 나름대로 정리는 해봤지만 솔직하게 말하자면 REST API에 대해 아직 완전히 이해하지는 못했다고 생각한다.

하지만 분명한 건 개발하면서 지금까지 REST API라고 알고 설계했던 것들은 전혀 RESTful하지 못했던 것 같다. 이번에 RestAPI에 대해 알아보면서 만족시킬 수 있는 방법 중 하나인 self-descriptive message를 만족하는 방법 중 하나인 link header에 명세 링크 첨부 가 가장 인상깊었던 것 같다. 프론트엔드 개발자 입장에서도 그럴 것이고 기능 개발하는 본인도 한 번씩 문서가 어딨었더라...? 하는 경우가 종종 있었는데 이를 적용한다면 그럴 일도 없고 RestAPI를 만족하는 데 한 발짝 나아갈 수 있을 것 같다.

HATEOAS는 오 그러겠네...! 싶다가도 그러면 프론트엔드 개발자 입장에서는 _links에 있는 API가 만약에 get이 아니라면 body에 들어갈 데이터 명세는 어떻게 알지? 명세를 알더라도 위에서 언급한 하드코딩할 필요가 없어진다는 장점이 여기에서도 똑같이 작용하는가? 정도의 궁금증은 남아있는데 이건 본인이 아직 지식이 부족해서 그런 것 같다.

+ 서점에서 지나가다 발견한 RESTful WEB API 웹 API를 위한 모범 전략 가이드 도 기회가 된다면 나중에 한 번 읽어보고 싶다.

** References**
Restful API가 리소스를 나타내는 방법 REST API란? 그런 REST API로 괜찮은가

1-1. S3 퍼블릭 액세스 차단 비활성화

1-2. 버킷 정책 Action에 s3:PutObject 넣기

{
    "Version": "2012-10-17",
    "Id": "ExamplePolicy01",
    "Statement": [
        {
            ...
            "Action": [
                "s3:PutObject",
            ],
            ...
        }
    ]
}

버킷 정책 설정 참고

1-3. 코드 내 설정

build.gradle

implementation group: 'io.awspring.cloud', name: 'spring-cloud-starter-aws', version: '2.4.2'

AmazonS3 bean 생성 및 주입

@PostConstruct
public void setS3Client() {
    AWSCredentials credentials = new BasicAWSCredentials(this.accessKey, this.secretKey);

    final AWSStaticCredentialsProvider credentialsProvider = new AWSStaticCredentialsProvider(credentials);
    s3Client = AmazonS3ClientBuilder.standard()
            .withRegion(this.region)
            .disableChunkedEncoding()
            .withCredentials(credentialsProvider)
            .build();
}

• bean으로 등록한 후 해당 빈을 주입받아 사용하는 것이 바람직하겠지만, 본인은 테스트를 위해 일단 @PostConstruct를 사용하여 해당 객체를 만들어주었다
• 위에서 사용한 accessKey, secretKey, region은 yaml에서 관리하도록 하였다.

파일 업로드 메소드

public void upload(MultipartFile file) {
    ObjectMetadata objectMetadata = new ObjectMetadata();
    objectMetadata.setContentType(file.getContentType());
    objectMetadata.setContentLength(file.getSize());

    String key = "item/" + file.getOriginalFilename();

    try (InputStream inputStream = file.getInputStream()) {
        final PutObjectRequest putObjectRequest = new PutObjectRequest(
                bucket,
                key,
                inputStream,
                objectMetadata);
        putObjectRequest.withCannedAcl(CannedAccessControlList.PublicRead);

        s3Client.putObject(putObjectRequest);
    } catch (IOException e) {
        e.printStackTrace();
    }
}

• bucket : 파일이 저장될 S3 버킷의 이름
• key : S3에 저장될 경로 포함 파일 이름
• CannedAccessControlList.PublicRead : 외부에 공개할 이미지로 public read 권한 추가

2. 403 에러 해결

이대로 실행 시켰는데 403???

그대로 따라했는데 403 에러를 계속 보게 되었다. S3 퍼블릭 액세스 차단도 모두 비활성하고 본인 IAM Access Key와 Secret Key도 전부 맞는데...?

여기서 Access Key와 Secret Key는 root 계정이 아니라 S3와 연결된 IAM의 것이라고 한다.

2-1. S3 접근을 위한 IAM 생성하기

1. 사용자 추가 버튼 클릭

2. 사용자 이름을 적어주고 AWS 자격 증명 유형을 액세스 키-프로그래밍 방식 액세스로 선택

3. 기존 정책 직접 연결 클릭 후 AmazonS3FullAccess 선택

4. 다음 버튼을 계속 누른 후 액세스 키와 비밀 액세스 키를 확인한다.

• 단, 이 페이지에서 반드시 키를 복사해놓고 마쳐야 한다.

참고 https://programming-workspace.tistory.com/61 https://artiiicy.tistory.com/16

1. List

1) List.of()

List<String> animalList = List.of("Dog", "Cat", "Duck");

• 비어있는 리스트를 만들기 위해서는 List.of() 를 사용하면 된다.
• animalList.add("???") 처럼 뭔가를 넣으면 UnsupportedOperationException이 터진다.
  

2. Set

1) Set.of()

Set<String> animalSet = Set.of("Dog", "Cat", "Duck");

• of()에 중복 인자가 들어갈 경우 IllegalArgumentException이 발생한다.

3. Map

1) Map.of()

Map<Integer, String> animalMap = Map.of(1, "Dog", 2, "Cat", 3, "Duck");

2) Map.ofEntries()

Map<Integer, String> animalMap = Map.ofEntries(entry(1,"Dog"), entry(2,"Cat"), entry(3,"Duck"));

• 둘 다 animalMap.add(4, "???") 처럼 뭔가를 넣으면 UnsupportedOperationException이 터진다.

2. 불변 컬렉션 구성

왜 UnsupportedOperationException이 터지는지 알아보자.

1. List.of(), Set.of(), Map.of()

1) 불변 List, Set, Map

ImmutableCollections.java

class ImmutableCollections {

    ...

    @jdk.internal.ValueBased
    static abstract class AbstractImmutableCollection<E> extends AbstractCollection<E> {
        // all mutating methods throw UnsupportedOperationException
        @Override public boolean add(E e) { throw uoe(); }
        @Override public boolean addAll(Collection<? extends E> c) { throw uoe(); }
        @Override public void    clear() { throw uoe(); }
        @Override public boolean remove(Object o) { throw uoe(); }
        @Override public boolean removeAll(Collection<?> c) { throw uoe(); }
        @Override public boolean removeIf(Predicate<? super E> filter) { throw uoe(); }
        @Override public boolean retainAll(Collection<?> c) { throw uoe(); }
    }

    ...

    @jdk.internal.ValueBased
    static abstract class AbstractImmutableList<E> extends AbstractImmutableCollection<E>
            implements List<E>, RandomAccess {

    }

    ...

    @jdk.internal.ValueBased
    static abstract class AbstractImmutableSet<E> extends AbstractImmutableCollection<E>
            implements Set<E> {

    }

    @jdk.internal.ValueBased
    abstract static class AbstractImmutableMap<K,V> extends AbstractMap<K,V> implements Serializable {

    }
}

• ImmutableCollections 클래스 내 AbstractImmutableList와 AbstractImmutableSet은 위의 AbstractImmutableCollection을 상속받고 있다.
• 상위 클래스인 AbstractImmutableCollection은 불변 컬렉션에 대해 변형시키는 메소드를 호출할 시 UnsupportedOperationException을 던지고 있다.
• AbstractImmutableMap은 AbstractMap을 상속받고 있는데 기본적으로 AbstractMap에서 put() 과 같은 연산을 하면 UnsupportedOperationException을 던진다.

2) static of()로 객체 생성 후 add(), put() 했을 때 UnsupportedOperationException 발생하는 이유

• List, Set, Map은 공통적으로 of()를 통해 객체를 생성할 수 있다.
• 해당 불변 컬렉션 어떻게 구성되어 있는지 대표적으로 Set을 통해 알아볼 예정이다. (나머지도 거의 유사하게 구성되어 있다.)

ImmutableCollections.java

class ImmutableCollections {
    @jdk.internal.ValueBased
    static final class Set12<E> extends AbstractImmutableSet<E>
            implements Serializable {
}

Set.java

public interface Set<E> extends Collection<E> {
    @SuppressWarnings("unchecked")
    static <E> Set<E> of() {
        return (Set<E>) ImmutableCollections.EMPTY_SET;
    }

    static <E> Set<E> of(E e1) {
        return new ImmutableCollections.Set12<>(e1);
    }
}

• of() 메소드에서 Set12 객체를 생성하고 있다.
• Set12는 위의 AbstractImmutableSet을 상속받고 있고 이는 불변객체가 생성됨을 의미한다.

참고 Java9의 불변 컬렉션 생성

• SCN 확인 과정을 거치며 쿼리가 시작된 시점을 기준으로 일관성 있는 상태로 블록을 액세스하는 것
• SQL 트레이스 Call 통계의 query 항목, AutoTrace에서의 consistent gets

2. Current 모드 읽기

• SQL문이 시작된 시점이 아니라 데이터를 찾아간 바로 그 시점의 최종 값을 읽으려고 블록을 액세스하는 것
• SQL 트레이스 Call 통계의 current 항목, AutoTrace에서의 db block gets

3. 실습

1) 테이블 생성

create table 계좌1
nologging
as
select 7788 계좌번호, 'JIN' 계좌명, 1000 잔고 from dual;

create table 계좌2
nologging
as
select 7788 계좌번호, 'JIN' 계좌명, 1000 잔고, 2000 총잔고 from dual;

alter table 계좌1 add constraint 계좌1_PK primary key (계좌번호);
alter table 계좌2 add constraint 계좌2_PK primary key (계좌번호);

계좌1

계좌2

1) 실습 1

세션 1

update 계좌1 set 잔고 = 잔고 + 100 where 계좌번호 = 7788; -- 1100
update 계좌2 set 잔고 = 잔고 + 200 where 계좌번호 = 7788; -- 1200

• 두 쿼리를 실행하고 commit하지 않는다. 이 상태에서 다른 세션에서 다른 update문을 날린다.

세션 2

update 계좌2
set 총잔고 = 계좌2.잔고 + (select 잔고 from 계좌1 where 계좌번호 = 계좌2.계좌번호)
where 계좌번호 = 7788;

• 계좌번호가 7788인 row에 lock이 걸린 상태에서 세션 1에서 커밋하면 세션 2의 update문도 수행된다.

결과

• 위 순서대로 실행시킨 결과 총잔고는 2200이 나온다.
• 계좌2.잔고 = 1200

• Current모드로 읽게 되어 세션1에서 commit한 이후의 값을 읽은 것이다.

• 계좌1의 잔고 = 1000

• select문은 Consistent 모드로 읽게 되어 세션1에서 commit하기 전의 값인 1000을 읽는 것이다.

2) 세션2에서 다른 쿼리를 수행한다면?

update 계좌2
set 총잔고 = (select 잔고 + 계좌2.잔고 from 계좌1 where 계좌번호 = 계좌2.계좌번호)
where 계좌번호 = 7788;

• 위 쿼리와의 차이점은 계좌2.잔고를 select문 안으로 넣었다.

결과

• 위 순서대로 실행시킨 결과 총잔고는 2300이 나온다.
• 계좌1.잔고(1100)와 계좌2.잔고(1200) 모두 current 모드로 읽었기 때문에 일관성 있게 갱신되었다.
• current 모드로 읽힐 계좌2의 잔고가 서브쿼리로 들어가게 되면서 스칼라 서브쿼리 또한 current 모드로 동작하게 된다. (원래 스칼라 서브쿼리는 consistent 모드로 읽는다.)

정리

• 오라클은 update문 수행 시 대상 레코드를 읽을 때는 Consistent 모드로 읽고 실제 값을 변경할 때는 Current 모드로 읽는다.
• select문은 Consistent 모드로 읽고, insert, update, delete, merge는 Current 모드로 읽고 쓴다.
• 다만, 갱신할 대상 레코드를 식별하는 작업은 Consistent 모드로 이루어진다.

brew install --cask docker

2. MSSQL Docker Container 생성

도커 이미지 가져오기

docker pull mcr.microsoft.com/azure-sql-edge

컨테이너 실행

docker run -e "ACCEPT_EULA=1" -e "MSSQL_SA_PASSWORD=Rajhans123@" -e "MSSQL_PID=Developer" -e "MSSQL_USER=SA" -p 1433:1433 -d --name=mssql mcr.microsoft.com/azure-sql-edge

3. DataGrip을 이용해 MSSQL에 접속

패러렐즈를 이용해 Window11에 SQL Server 2019 설치를 시도했으나 0xe0000235 와 같은 오류코드와 함께 실패했다. (찾아보니 확실하지는 않지만 버전 문제라고 하는 것 같다.)
참고 자료 : https://macguided.ngontinh24.com/articles/can-i-install-sql-server-on-mac-m1

정의

• 조건에 해당하는 ROW의 컬럼을 비교하여 체크한다.
• 서브 쿼리의 결괏값을 메인 쿼리에 대입하여 조건 비교 후 결과를 출력한다.

예제

SELECT a.empno
     , a.ename
     , a.deptno
  FROM emp a
 WHERE a.job = 'MANAGER'
   AND a.empno IN (SELECT aa.empno
                 FROM dept_history aa)

2. EXISTS

정의

• 조건에 해당하는 ROW의 존재 유무 체크 후 더이상 수행하지 않으며 SELECT절을 평가하지 않으므로 일반적으로 IN에 비해 성능이 좋다.
• 메인 쿼리의 결괏값을 서브 쿼리에 대입하여 조건 비교 후 결과를 출력한다.

예제

SELECT a.empno
     , a.ename
     , a.deptno
  FROM emp a
 WHERE a.job = 'MANAGER'
   AND EXISTS (SELECT 1
                 FROM dept_history aa
                WHERE aa.empno = a.empno)

EXISTS를 사용하면서 저지른 실수

원래 목적

select *
from 월별계좌상태 B
where 상태구분코드 <> '01'
  and 기준연월 = :base_dt
  and exists(select 'X'
             from 계좌원장 A
             where A.계좌번호 = B.계좌번호
               and A.계좌일련번호 = B.계좌일련번호
               AND A.개설일자 like :std_ym || '%');

실수

select *
from 월별계좌상태
where 상태구분코드 <> '01'
  and 기준연월 = :base_dt
  and exists(select 'X'
             from 계좌원장 A
             where A.계좌번호 = 계좌번호
               and A.계좌일련번호 = 계좌일련번호
               AND A.개설일자 like :std_ym || '%');

여기서 서브쿼리에 alias를 달지 않은 컬럼은 서브쿼리 내 테이블의 컬럼으로 인식하는 것 같다. 서브쿼리를 사용할 때는 alias를 달아주는 것이 안전할 것 같다.

3. SQL 튜닝 관점에서 IN과 EXISTS의 차이점

[인덱스 구성] 월말계좌상태_PK : 계좌번호 + 계좌일련번호 + 기준연월 월말계좌상태_X1 : 기준연월 + 상태구분코드

[SQL]

select *
from 월별계좌상태
where 상태구분코드 <> '01'
  and 기준연월 = :base_dt
  and 계좌번호 || 계좌일련번호 in (select 계좌번호 || 계좌일련번호 from 계좌원장 where 개설일자 like :std_ym || '%');

해당 SQL을 월말계좌상태_PK 인덱스로 Range Scan 가능하도록 재작성하는 문제였다.

정답

select *
from 월별계좌상태
where 상태구분코드 <> '01'
  and 기준연월 = :base_dt
  and (계좌번호, 계좌일련번호) in (select A.계좌번호, A.계좌일련번호
                         from 계좌원장 A
                         where A.개설일자 like :std_ym || '%');

오답

select *
from 월별계좌상태 B
where 상태구분코드 <> '01'
  and 기준연월 = :base_dt
  and exists(select 'X'
             from 계좌원장 A
             where A.계좌번호 = B.계좌번호
               and A.계좌일련번호 = B.계좌일련번호
               AND A.개설일자 like :std_ym || '%');

• 위의 IN과 EXISTS를 실행시켰을 때 결과는 동일하게 나온다. 하지만 EXISTS는 실행계획이 원하는대로 나오지 않는 것을 알 수 있었다.

Mac M1에서 Oracle Database 사용하기 https://velog.io/@jduckling_1024/Mac-M1%EC%97%90%EC%84%9C-Oracle-DB-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0

하지만 Parallels Windows 환경에서 Datagrip을 사용하기 개인적으로 약간 불편했다. 그래서 Mac에 Datagrip을 설치하고 Windows 환경에 설치한 Oracle에 접속해서 사용하기로 했다.

1. Parallels가 사용하는 사설 IP 주소 확인하기

Windows 환경에서 사용하는 사설 IP 주소는 cmd에서 ipconfig 명령어를 통해 확인할 수 있다.

여기서 IPv4 주소를 사용하면 된다.

2. 접속 시도 (1) - 실패

Datagrip의 좌측 상단에 + 버튼을 누르면 새 Data Source를 생성할 수 있다.

그럼 이런 창이 뜨는데,

Host에 위에서 확인한 IPv4 주소를 넣어주면 될 것 같았다.

하지만 이런 오류와 함께 접속 실패하였다.

3. 해결 방법

1. 새 인바운드 규칙 추가

(1) 제어판에서 좌측 고급 설정 클릭

(2) 인바운드 규칙 설정

인바운드 규칙에서 우측 새 규칙을 클릭해준다.

포트를 선택하고 다음으로 넘어간다.

연결 허용 누르고 다음으로 넘어간다.

도메인, 개인, 공용 모두 선택해준 후 다음으로 넘어간다.

이름과 설명 추가 후 마친다.

(3) listener.ora 파일 수정

이제 Listener 파일을 수정해야 한다. listener.ora 파일은 Oracle 설치 위치\WINDOWS.X64_193000_db_home\network\admin 에 있다.

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

여기서 HOST = localhost를 볼 수 있는데 localhost 대신 호스트명을 넣어주면 된다. 호스트명은 cmd에서 hostname이라고 치면 알 수 있다.

4. 접속 시도 (2) - 성공

이 과정을 마치면 성공적으로 접속한 것을 확인할 수 있다.

여기에서 Parallel Desktop을 설치한다.

2. Oracle 설치

1. Oracle 홈페이지에서 다운로드

여기에서 Oracle을 설치한다. Parallels에서 사용할 운영체제는 Windows이므로 Microsoft Windows x64 (64-bit) zip 파일을 다운로드해준다.

설치하면 이런 압축파일이 생기는데 압축을 풀어준다.

압축을 풀어주고 적당한 곳에 넣어준다. 본인은 보기 편하게 바탕화면의 oracle 폴더를 만들고 그 안에 넣어주었다.

주의할 점

단, 여기서 주의할 점이 있다. 내 PC의 바탕화면은 본인 MAC이랑 같이 쓰는 바탕화면이다. 즉, MAC에서 바탕화면에 뭔가를 추가하면 여기에도 동기화되어 같이 추가된다. 위와 동일하게 파일이 저장되어 있음을 MAC에서 확인할 수 있다.
위에서 말한 적당한 곳이 Windows 상의 경로여야 한다. 그 이유는 아래에서 알 수 있다.

2. Oracle 설치하기

폴더를 열면 아래와 같이 구성되어 있는 것을 확인할 수 있는데 여기서 setup 응용 프로그램을 실행시켜준다.

이렇게 설치 프로그램이 실행되는데 별다른 설정이 필요없다면 계속하여 다음을 눌러준다.

계속해서 진행하고 5번째 단계에 도달하면 데이터베이스 설정 창이 아래와 같이 나오게 된다.

참고 이미 설치를 해버려서 다시 이 페이지를 띄우려니 뜨지 않았다. (해당 블로그를 보고 설치하였으며 이미지 출처 또한 이 블로그에 있습니다.)

여기서 주의할 점! Oracle Base를 실제 MAC 상에 존재하는 경로로 잡으면 오류가 발생한다. 따라서 Window 상의 경로로 잡아야 다음 단계로 넘어갈 수 있다.

계속하여 다음으로 넘어가면 설치를 시작하게 된다. (약 1시간 걸린다고 한다. 본인은 새벽에 해서 맥북 켜놓고 잤다)

3. 설치 확인

cmd에 들어가 sqlplus를 입력한다.

성공!

4. (번외) Datagrip에서 oracle 사용하기

개인적으로 CLI보다는 더 편리한 툴을 사용하고 싶다. 여기에서 Datagrip을 설치해준다.

설치 후 Datagrip을 열어준다.

좌측 + -> Data Source -> Oracle을 클릭해준다. (본인은 이미 세팅을 완료한 상태이기 때문에 맨 위에 Oracle이 뜬다.)

처음에 SID가 XE로 되어있는데 이를 orcl로 변경해줘야 connection이 성공한다. 처음에는 driver가 설치되지 않았을텐데, driver도 설치해준다.

성공!

3. M1에서 Oracle을 사용할 수 있는 다른 방법

• Oracle Cloud 회원가입 후 사용
• UTM
• lima
• Rosetta

몇 시간동안 삽질한 결과 크게 이런 결과를 얻을 수 있었는데 다 실패했다... 위 방법들을 시도하면서 놓치고 있는 것이 있을 수도, 더 좋은 방법이 있을 수도 있을 것 같다.

클래스 명이나 패키지 명이 네이밍 컨벤션에 맞지 않아 변경해야 할 경우가 있다. 해당 이슈를 수행한 후 다음 이슈를 처리하러 feature -> develop 브랜치로 이동하고자 할 때 아래와 같은 에러를 접하게 된다.

error: The following untracked working tree files would be overwritten by checkout:

해결 방법

원래 master에 아래와 같은 class가 있었다고 가정해보자.

package com.example.test.testpackage;

public class testclass {

}

컨벤션을 지키지 않은 파일 및 패키지 명을 변경하는 이슈를 받고 master로부터 새 브랜치(new-branch)를 파서...

package com.example.test.testpackage;

public class TestClass {

}

이렇게 수정하고 push하고 PR까지 올렸다.

merge 승인받을 때까지 다른 이슈를 처리해야지! 하고 이제 다시 master로 switch해볼 것이다. git switch master

그럼 이런 오류를 볼 수 있다. new-branch(현재 브랜치)에는 TestClass.java가 있지만 master 브랜치에는 testclass.java가 있기 때문에 브랜치 이동이 불가능한 상황이다.

참고 1

이것저것 하면서 local의 master를 삭제했기 때문에 원격의 master를 추적하는 로컬 master 브랜치를 생성하면서 switch하기 위해 위의 캡쳐본에서는 checkout을 사용한 것이다. 로컬 기준 특정 파일명이 현재 브랜치와 이동할 브랜치 간 다르면 똑같은 에러를 볼 수 있을 것이다.

이럴 때는 HEAD의 위치를 조정하여 이동할 브랜치와 현재 브랜치의 파일명 대소문자를 맞춰줘야 한다.

현재 new-branch의 HEAD는 '컨벤션 지킨 클래스명' 에 있다. (new-branch와 origin/new-branch가 보이는데 로컬 기준으로 봐야하기 때문에 new-branch의 위치를 봐주면 된다.)

이제 HEAD의 위치를 master로 변경하여 현 브랜치와 이동할 브랜치를 맞춰줄 것이다.

git fetch --all
git reset --hard origin/master

브랜치 이동이 제대로 된 것을 확인할 수 있다.

참고 2

reset --hard의 대상은 원격 브랜치든 로컬 브랜치든 상관 없다. 이동하고 싶은 브랜치 기준으로 HEAD를 맞추는 데에 중점을 두면 될 것 같다.

참고 3

혹시 대소문자 변경 이슈를 처음 하는거라면... git config core.ignorecase false 이 설정 한 번 해야 변경된 이름이 반영되는 것 같다. git이 파일 혹은 폴더 이름을 🐶 무시할 때

TM Lock은 DML 테이블 Lock으로 테이블을 보호하는 Lock이다.

emp 테이블

select * from emp;

이제부터 이 트랜잭션을 트랜잭션A라고 부를 것이다.

update emp
set sal = 1024
where empno = 1;

그러면 이렇게 정상적으로 업데이트 된다. 아직 commit은 하지 않은 상태다.

이때, 다른 곳(새 cmd창)에서 empno가 1인 emp의 sal을 4021로 업데이트하고자 한다. 이 트랜잭션은 트랜잭션B라고 할 것이다.

update emp
set sal = 1024
where empno = 1;

이 쿼리를 날리면 날라가지 않고 그대로 멈춰있다. 트랜잭션A에서 이 행에 대해 Lock을 걸고 아직 commit을 하지 않았기 때문이다.

또 다른 cmd창을 열어 empno가 1인 emp의 sal을 0으로 업데이트 해볼 것이다. 이 트랜잭션은 트랜잭션C라고 할 것이다.

update emp 
set sal = 0 
where empno = 1;

이 쿼리 같은 이유로 역시 날라가지 않은 상태로 멈춰있게 된다.

모니터링 방법

현재 어떤 상황인지 확인할 때는 아래와 같은 쿼리를 날려주면 된다.

 SELECT DISTINCT T1.SESSION_ID
     , T2.SERIAL#
     , T4.OBJECT_NAME
     , T2.MACHINE
     , T2.TERMINAL
     , T2.PROGRAM
     , T3.ADDRESS
     , T3.PIECE
     , T3.SQL_TEXT
  FROM V$LOCKED_OBJECT T1
     , V$SESSION T2
     , V$SQLTEXT T3
     , DBA_OBJECTS T4
 WHERE 1=1
   AND T1.SESSION_ID = T2.SID
   AND T1.OBJECT_ID = T4.OBJECT_ID
   AND T2.SQL_ADDRESS = T3.ADDRESS
 ORDER BY T3.ADDRESS, T3.PIECE;

결과는 다음과 같다. 맨 아래 두 줄의 SQL_TEXT를 보면 트랜잭션A에 의해 Lock이 발생하여 수행되지 않은 UPDATE 쿼리를 확인할 수 있다.

COMMIT

지금과 같은 상황은 트랜잭션A가 commit하지 않았기 때문에 발생하는 현상이다. 이제 트랜잭션A에서 commit을 날려볼 예정이다.

트랜잭션 A에서 commit을 날렸을 때,

트랜잭션B

트랜잭션C

트랜잭션B에서 UPDATE 쿼리가 날라가게 된다. 트랜잭션C는 그대로다. 트랜잭션B가 먼저 수행되었기 때문에 위와 같은 결과가 나타난 것이다.

1. cmd 실행
2. sqlplus 입력
3. Enter user name : sys as sysdba, Password: (아무것도 치지 않고 바로 Enter)
4. alter user system identified by 새 비밀번호 ex) alter user system identified by 1234;
5. conn system/새 비밀번호 ex) conn system/1234

Oracle System 계정 잠겼을 때

몇 번 틀린 비밀번호를 입력하여 로그인을 시도한다면 계정이 잠기게 된다.

1. select username, account_status, lock_date from dba_users; 지금은 본인이 SYSTEM 계정 LOCK을 풀었기 때문에 SYSTEM의 ACCOUNT_STATUS가 OPEN으로 되어있지만 잠겨있을 때는 LOCKED로 표시된다.

2. alter user system account unlock;

테스트케이스의 정의는 다음과 같다.

테스트케이스

• 본인이 작성한 코드가 예상한 대로 잘 동작하는지 예상되는 값을 부여하여 어플리케이션 빌드 시 동작을 검증하는 것
• 타겟 코드에 대한 기대 행동을 제공하는 시나리오

TDD (Test Driven Development)

TDD는 테스트 주도 개발의 줄임말로 우선 테스트케이스를 작성한 뒤 해당 기능에 대한 코드를 작성하는 방법이다. 테스트를 먼저 작성하다 보니 기능을 만들기 전에 본인이 만들어야 하는 기능들에 대해 좀 더 명확하게 그릴 수 있다는 장점이 있다.

BDD (Behavior Driven Development)

BDD는 행동 주도 개발의 줄임말로 비즈니스 요구사항에 집중하여 테스트케이스를 작성하는 방법이다.

도대체 이게 무슨 말이지? TDD랑 똑같은거 아닌가?

TDD랑 그렇게 다르지는 않다. BDD 역시 TDD로부터 파생되어 나온 것이다.

BDD가 나오게 된 배경

• TDD 방식으로 테스트 케이스를 작성하면서 어떤 케이스가 있을지를 생각하면서 작성해야 한다.
• 흐음 어떤 경우가 있을까??? 아 더 생각나는 케이스가 없는데 누군가가 말해줬으면 좋겠다...
• 테스트케이스를 상상해서 만드는 것보다 이미 작성된 요구사항이 테스트 케이스가 된다면 부담이 줄어들 것이다.
• 그렇다면 무작정 테스트 케이스를 코드로 작성하기 보다는 글로 작성해보자!

이렇게 나온 것이 BDD다!

주로 사용하는 BDD 구조

BDD는 테스트 케이스를 작성하는 대신, 동작 작성으로 시작하는 방법으로 TDD의 확장이다. 테스트 케이스를 작성하기에 앞서 문장으로 풀어 써볼 것인데, 아래와 같은 형식을 지킬 것이다.

주어진 환경에서 어떠한 행위를 했을 때 이런 결과가 나올 것이다.

이 문장을 세 부분으로 나눌 수 있겠다.

Given - 주어진 환경에서 When - 어떠한 행위를 했을 때 Then - 이런 결과가 나올 것이다.

이제 한 예시에 적용해볼 것이다.

예시

MyMath라는 클래스를 만들어 Math.pow(double a, double b)와 동일한 결과를 반환하는 함수 pow(double a, double b)를 구현해본다고 가정해볼 것이다.

public class MyMath {
  public static double pow(int a, int b) {
    double result = 1;
    for (int i = 0; i < b; i++) {
      result *= a;
    }
    return result;
  }
}

a=10, b=3이 준비된 상태에서 MyMath.pow(double a, double b)를 호출하였을 때 Math.pow(10, 3)과 결과가 동일한 1000이 나올 것이다.

이제 요구사항(?)도 작성해봤으니 이를 테스트 코드로 옮기기만 하면 끝이다!

public class TestControllerTest {

  @Test
  void test() {
    // given
    int a = 10;
    int b = 3;

    // when
    double result = MyMath.pow(a, b);

    // then
    assertEquals(result, Math.pow(a, b));
  }
}

본인의 생각

지금까지 Junit5를 이용하여 테스트 코드는 작성해 보았지만 사실 명확하게 TDD였다 혹은 BDD였다고 말하기가 어려울 것 같다고 생각했다. 테스트 코드를 작성하고 기능을 구현한 것이 아니라, 이미 구현된 기능에 대한(혹은 기능을 구현하고 나서) 테스트 코드를 작성하곤 하였다.

사실 머리로는 받아들이겠지만 TDD든 BDD든 정석으로 적용하기에는 어려움이 있을 것이라고 생각한다. 테스트 코드 작성하는 데 테스트 케이스를 생각하는 것부터 시작해서 작성하는데 꽤 오래 걸리는 것 같다. (본인이 초보라서 그럴 수도 있겠지만...) 하지만 테스트 코드 작성 자체는 중요한 역할을 한다는 점 자체는 받아들일 수 있을 것 같다. 예전에 로직 변경하면서 리팩토링하다가 작성해뒀던 테스트 코드 다 터뜨려먹고 일부 기능이 제대로 작동하지 않는 것을 확인하여 급하게 수정한 경험이 있었기 때문이다.

기능 구현 전에 테스트 코드를 작성하든 구현 이후에 작성하든 테스트 코드는 작성하는 습관을 들이자는 것이 결론이다.

Reference TDD, BDD란? [Spring Boot] JUnit5 BDDMockito로 알아보는 TDD와 BDD 의 차이 및 BDD 실습

+ 이해한 내용을 바탕으로 작성한 글이니 추가적인 의견 및 정보 있으시다면 댓글로 공유 좀 부탁드립니다!

이러한 경우 조금 더 코드를 간결하게 작성하는 방법이 있지 않을까 고민해보고 찾아보는 중 Junit5에서 제공하는 @ParameterizedTest 라는 것을 알게 되었다.

@ParameterizedTest

@ParameterizedTest는 하나의 테스트를 여러 번 돌려야 할 때 사용한다.

@ParameterizedTest 적용 방법

• 메소드 위에 @ParameterizedTest를 명시한다.
• 메소드의 파라미터로 순서대로 넘겨줄 배열을 @ValueSource를 이용해 명시해준다. (short, byte, int, long, float, double, char, String, Class 명시 가능)
• 넘겨줄 값들의 타입을 메소드의 파라미터로 적어준다.

예시

import org.junit.jupiter.api.extension.ExtendWith;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.ValueSource;
import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
public class TestControllerTest {

  @ParameterizedTest
  @ValueSource(strings = {"test1", "test2", "test3"})
  void test(String value) {
    System.out.println(value);
  }
}

이 테스트 코드의 실행 결과는 다음과 같다.

하지만, 이 방법은 파라미터를 하나만 전달할 때만 가능하며 두 개 이상의 파라미터는 전달할 수 없다.

@MethodSource

@MethodSource를 이용하면 두 개 이상의 파라미터 또한 전달받을 수 있도록 할 수 있다.

예시

import java.util.stream.Stream;
import org.junit.jupiter.api.extension.ExtendWith;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.Arguments;
import org.junit.jupiter.params.provider.MethodSource;
import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
public class TestControllerTest {

  // test method
  @ParameterizedTest
  @MethodSource("provideKeyAndValue")
  void test(Integer key, String value) {
    System.out.println(key + " " + value);
  }

  //source method
  private static Stream<Arguments> provideKeyAndValue() {
    return Stream.of(
        Arguments.of(1, "value1"),
        Arguments.of(2, "value2"),
        Arguments.of(3, "value3")
    );
  }
}

단, 이를 사용하기 위해서는 source method가 static이어야 한다.

하지만, 성격이 같은 테스트케이스끼리 묶을 경우 종종 inner class를 사용하는 경우가 있고, inner class에서는 static method를 선언하지 못한다.

import java.util.stream.Stream;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.extension.ExtendWith;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.Arguments;
import org.junit.jupiter.params.provider.MethodSource;
import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
public class TestControllerTest {

  @Nested
  public class NestedTestControllerTest {

    @ParameterizedTest
    @MethodSource("provideKeyAndValue")
    public void test(Integer key, String value) {
      System.out.println(key + " " + value);
    }

    // 에러 발생!
    private static Stream<Arguments> provideKeyAndValue() {
      return Stream.of(
          Arguments.of(1, "value1"),
          Arguments.of(2, "value2"),
          Arguments.of(3, "value3")
      );
    }
  }
}

이렇게 불가능하다는 뜻이다... 이럴 때는 @TestInstance를 사용하면 되는데, 이제부터 @TestInstance에 대해 알아볼 예정이다.

@TestInstance

@TestInstance는 테스트 인스턴스의 라이프 사이클을 설정할 때 사용한다.

• Lifecycle.PER_METHOD (Default) : 테스트 함수 당 인스턴스가 생성된다.
• Lifecycle.PER_CLASS : 테스트 클래스 당 인스턴스가 생성된다.

import java.util.stream.Stream;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.TestInstance;
import org.junit.jupiter.api.TestInstance.Lifecycle;
import org.junit.jupiter.api.extension.ExtendWith;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.Arguments;
import org.junit.jupiter.params.provider.MethodSource;
import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
public class TestControllerTest {

  @Nested
  @TestInstance(Lifecycle.PER_CLASS)
  public class NestedTestControllerTest {

    @ParameterizedTest
    @MethodSource("provideKeyAndValue")
    public void test(Integer key, String value) {
      System.out.println(key + " " + value);
    }

    private Stream<Arguments> provideKeyAndValue() {
      return Stream.of(
          Arguments.of(1, "value1"),
          Arguments.of(2, "value2"),
          Arguments.of(3, "value3")
      );
    }
  }
}

이렇게 @TestInstance를 Lifecycle.PER_CLASS로 설정해주면 동일한 test instance에서 모든 test method를 실행할 수 있게 되며 provideKeyAndValue()를 static으로 두지 않고도 @MethodSource를 사용할 수 있게 된다.

사실 위와 같이 Unit Test를 작성해도 괜찮을지는 모르겠지만, 한 번도 접해보지 못한 어노테이션을 사용하였고 알게 되었다는 것에 의의를 둘 수 있었다.

BDDMockito의 willThrow를 사용하던 도중, 파라미터로 다음과 같이 작성할 수 있음을 알 수 있었다.

given(testService.func(any())).willThrow(SomeException.class);

이처럼 willThrow의 파라미터로 class를 넣을 수도 있고,

given(testService.func(any())).willThrow(new SomeException("message"));

이렇게 예외 관련 객체를 생성하여 파라미터로 넣을 수도 있다.

willThrow() 함수 안으로 들어가보니... ...와 같이 이렇게 함수가 오버로딩 되어있음을 확인할 수 있었다.

그렇다면 둘의 차이점은 무엇일까? 직접 돌려봤을 때 stack trace 정보를 나타낼 수 있는지의 여부에서 차이가 발생함을 알 수 있었다.

1. willThrow(Class< ? extends Throwable throwableType)

If you require stack trace information, use thenThrow(Throwable...) instead. stack trace 정보를 알고 싶다면, thenThrow(Throwable...)을 사용하세요.

해당 메소드로는 발생한 예외에 대한 stack trace를 알 수 없다.

2. willThrow(Throwable... thorwables)

you can specify throwables to be thrown for consecutive calls. in that case the last throwable determines the behavior of further consecutive calls. 연속 호출에 대해 throw될 throwable을 지정할 수 있습니다. 이 경우 마지막 throwable은 추가 연속 호출의 동작을 결정합니다.

무슨 말일까... 잠시 고민했었는데 본인은 이렇게 이해했다.

연속 호출에 대해 throw될 throwable을 지정할 수 있습니다.

이런 사용자 지정 예외가 있다고 가정해볼 것이다.

class CustomException extends RuntimeException {
    public RuntimeException(String message) {
        super(message);
    }
}

그리고 실제로 로직을 수행하다가 최종적으로 던져지는 Exception은 CustomException이다.

이 경우 마지막 throwable은 추가 연속 호출의 동작을 결정합니다.

마지막 throwable은 CustomException 최상위 class는 Throwable이다.

public class Throwable implements Serializable {
...
    public Throwable(String message) {
        fillInStackTrace();
        detailMessage = message;
    }
...
}

생성자에서 fillInStackTrace()가 호출될 것이고...

public class Throwable implements Serializable {
...
    public synchronized Throwable fillInStackTrace() {
        if (stackTrace != null ||
            backtrace != null /* Out of protocol state */ ) {
            fillInStackTrace(0);
            stackTrace = UNASSIGNED_STACK;
        }
        return this;
    }
...
}

fileInStackTrace()는 fillnStackTrace()를 호출할 것이다.

public class Throwable implements Serializable {
...
    private native Throwable fillInStackTrace(int dummy);
...
}

이렇게 예외를 던진 이후에 순차적으로 함수를 호출한다.

본인의 생각이 틀릴 수도 있다. 하지만 결론적으로 테스트 도중 stack trace를 보고싶다면 이 willThrow를 사용하면 된다는 사실을 알 수 있었다.

Reference

BDD의 willThrow 2가지 비교하기 본인의 궁금증을 해결해준 블로그다. 여기서는 thenThrow에 대해서 정리한 듯 하지만 같은 경우, 같은 내용이다.

I. git reset

git reset은 좀 전의 commit 내역에 남기지 않고 좀 전의 commit을 취소하고 싶을 때 사용한다.

현재 commit 이력은 다음과 같다. 모두 a.txt를 가지고 있으며 각 commit의 a.txt 내용은 아래와 같다. a : -1 b : 1 c : 0
각각의 옵션을 붙여 b로 돌아갔을 때 무슨 일이 발생할지 알아볼 것이다.

참고로, repository, staging area, working directory가 무엇인지는 여기에서 따로 기재하지 않을 예정이다.

git reset에는 세 가지 옵션이 있다. --hard, --mixed, --soft가 있는데 각각을 붙였을 때 어떤 일이 일어나는지 살펴보자.

1. git reset --hard

git reset --hard를 사용하면 repository, staging area, working directory 모두 b의 상태로 돌아가게 된다.

git reset 6872413 --hard

• 일단 확실히 repository는 b의 상태로 돌아갔을 것이다.
• cat a.txt로 확인했을 때, -1을 출력하는 것을 볼 수 있고 working directory는 b의 상태로 돌아갔음을 알 수 있다. (c의 상태였다면 0을 출력했을 것이다.)
• git status로 확인했을 때, nothing to commit, working tree clean이라는 문구를 볼 수 있다. 즉, staging area 또한 b의 상태로 돌아갔음을 알 수 있다.

2. git reset --mixed

git reset 6872413 --mixed

• 일단 확실히 repository는 b의 상태로 돌아갔을 것이다.
• cat a.txt로 확인했을 때, 그대로 0을 출력하는 것으로 보아 working directory 또한 c의 상태에 머물러있음을 알 수 있다.
• git status로 확인했을 때, a.txt가 modified가 되었으며 빨간색이므로 staging area는 b의 상태로 돌아갔음을 알 수 있다.

참고로 reset시 어떤 옵션도 주지 않게 되면 --mixed가 default다.

3. git reset --soft

git reset 6872413 --soft

• 일단 확실히 repository는 b의 상태로 돌아갔을 것이다.
• cat a.txt로 확인했을 때, 그대로 0을 출력하는 것으로 보아 working directory 또한 c의 상태에 머물러있음을 알 수 있다.
• git status로 확인했을 때, a.txt가 modified가 되었으며 초록색이므로 staging area는 c의 상태에 머물러있음을 알 수 있다.

4. 정리 표

II. git revert

git revert는 결과적으로 봤을 때 이전 상태로 되돌리는 것을 의미하는 것은 맞지만, 되돌린 내역까지 기록으로 남게 된다.

git revert 4aadc32 이렇게 새로운 commit이 남게 되고, 결과적으로 봤을 때, c의 상태를 revert 하였으니 a.txt 파일에는 -1이 남게 된다.

학과에서 프로젝트를 할 때는 변경사항을 되돌릴 때 무조건 revert 것 같다(사실 아무것도 모르고 git desktop을 사용했기에... 뭔지도 모르고 일단 쓴게 저거다...). 실무에서는 git을 끼고 살아야 하니 열심히 따라가는 중이다!