<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>kimchi-person.log</title>
        <link>https://velog.io/</link>
        <description></description>
        <lastBuildDate>Sun, 12 Feb 2023 08:30:51 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://github.com/jpmonette/feed</generator>
        <image>
            <title>kimchi-person.log</title>
            <url>https://velog.velcdn.com/images/kimchi-person/profile/805dab8e-f995-44d6-9cbb-164cebcc6883/social_profile.png</url>
            <link>https://velog.io/</link>
        </image>
        <copyright>Copyright (C) 2019. kimchi-person.log. All rights reserved.</copyright>
        <atom:link href="https://v2.velog.io/rss/kimchi-person" rel="self" type="application/rss+xml"/>
        <item>
            <title><![CDATA[[TIL #7] 항해99 2023.02.12]]></title>
            <link>https://velog.io/@kimchi-person/TIL-7-%ED%95%AD%ED%95%B499-2023.02.12</link>
            <guid>https://velog.io/@kimchi-person/TIL-7-%ED%95%AD%ED%95%B499-2023.02.12</guid>
            <pubDate>Sun, 12 Feb 2023 08:30:51 GMT</pubDate>
            <description><![CDATA[<p>Spring Data JPA와 같은 ORM 구현체에 대한 자료를 보거나 다루게 되다 보면
더티체킹이라는 단어를 종종 듣게 됩니다.</p>
<p>Dirty : 변경을 감지
Checking : 검사</p>
<p>이라는 뜻으로 조합하여 본다면 변경을 감지한다고 생각하고 접근하면 될것 같습니다.</p>
<h1 id="🤔-더티-체킹dirty-checking-">🤔 더티 체킹(Dirty Checking) ?</h1>
<p>Spring Data JPA와 같은 ORM 구현체를 다루다 보면 자주 등장하는 용어입니다.</p>
<p>JPA(Java Persistence API) 를 사용하면서 더티체킹과 트랜잭션의 관계에 대해서 알고 있지 않으면, 비즈니스 로직에서 다루는 엔티티 데이터가 꼬이는 경우가 발생하게 됩니다.</p>
<p>데이터가 꼬이는 경우를 방지하려면,
더티체킹(Dirty Cheking)이 어떤 상황에 사용이 되고 있는지 이해할 필요가 있어 준비하였습니다.</p>
<h2 id="더티-체킹이-발생하는-상황">더티 체킹이 발생하는 상황</h2>
<ul>
<li>JPA는 엔티티 매니저가 엔티티를 저장/조회/수정/삭제를 합니다.
: 그런데 엔티티 매니저가 지원하는 메서드를 찾아보면
저장(persist) / 조회(find) / 수정(update) / 삭제(delete) 로 해당하는 메서드는 찾아볼 수 없습니다.</li>
</ul>
<p>대신에 수정에 해당하는 더티체킹을 지원합니다.</p>
<p>더티 체킹은 Transaction 안에서 엔티티의 변경이 일어나면, 변경 내용을 자동으로 데이터베이스에 반영하는것이 JPA의 특징입니다.</p>
<ul>
<li>데이터베이스에 커밋 되는 데이터를 저장하는 시점은 아래의 3가지 케이스입니다.</li>
</ul>
<ol>
<li>Transaction commit 시점 
2) EntityManager flush 시점 
3) JPQL 사용 시점</li>
</ol>
<ul>
<li>또한, 영속성 컨텍스트(Persistence Context) 안에 있는 엔티티를 대상으로
더티체킹이 일어납니다.</li>
</ul>
<hr>
<blockquote>
<p>더티 채킹이 발생할때 충족되어야 하는 조건은 아래 두가지 조건이 있습니다</p>
</blockquote>
<ol>
<li>영속 상태(Managed) 안에 있는 엔티티인 경우</li>
<li>Transaction 안에서 엔티티를 커밋 하는 경우</li>
</ol>
<p>그리고 Transaction은 두 가지 방식으로 사용할 수 있습니다</p>
<ol>
<li>Service Layer 에서 @Transactional 어노테이션을 사용하는 경우</li>
<li>EntityTransaction을 이용해서 트랜잭션의 범위를 지정하고 사용하는 경우</li>
</ol>
]]></description>
        </item>
        <item>
            <title><![CDATA[[TIL #6] 항해99 2023.02.11]]></title>
            <link>https://velog.io/@kimchi-person/TIL-6-%ED%95%AD%ED%95%B499-2023.02.11-g8xpeio1</link>
            <guid>https://velog.io/@kimchi-person/TIL-6-%ED%95%AD%ED%95%B499-2023.02.11-g8xpeio1</guid>
            <pubDate>Sun, 12 Feb 2023 08:00:06 GMT</pubDate>
            <description><![CDATA[<p>어제 적었던 TIL 주제에서 JPA를 다뤘는데
JPA(Java Persistence API)의 풀네임에서 Persistence는 영속성을 의미합니다.
즉, 영속성을 알고 넘어가지 않으면 JPA를 완벽하게 이해하지 못할것 같아서</p>
<p>오늘은 &quot;영속성&quot;에 대하여 끄적여 보려고 합니다.</p>
<hr>
<h1 id="🤔-영속성-">🤔 영속성 ?</h1>
<p>사전적 의미를 찾아보면</p>
<p><strong>영속성이란, 영원히 계속되는 성질이나 능력 이라고 합니다.</strong></p>
<p>사전적 의미를 응용하여 접근한다면, 데이터를 생성한 프로그램이 종료되어도 사라지지 않는 데이터의 특성이라고 생각하면 될것 같습니다.</p>
<p>영속성을 갖지 않으면 데이터는 메모리에서만 존재하게 되고 프로그램이 종료되면 해당 데이터는 모두 사라지게 됩니다.</p>
<p>그래서 우리는 데이터를 파일이나 <strong>DB에 영구 저장함으로써 데이터에 영속성을 부여합니다.</strong></p>
<hr>
<h2 id="📌-jpa에서의-영속성">📌 JPA에서의 영속성</h2>
<p>JPA의 핵심 내용은 엔티티가 영속성 컨텍스트에 포함되어 있냐 아니냐로 갈립니다.</p>
<p>JPA의 엔티티 매니저가 활성화된 상태로 트랜잭션(@Transactional) 안에서 DB에서 데이터를 가져오면 이 데이터는 영속성 컨텍스트가 유지된 상태입니다. </p>
<p>이 상태에서 해당 데이터 값을 변경하면 트랜잭션이 끝나는 시적에 해당 테이블에 변경 내용을 반영하게 된다. 따라서 우리는 엔티티 객체의 필드 값만 변경해주면 별도로 update()쿼리를 날릴 필요가 없게 됩니다.! 이 개념을 더티 체킹이라고 합니다.</p>
<p>더티체킹에 대해서는 다음 TIL에 작성해보도록 하겠습니다.</p>
<hr>
<h2 id="📌-영속성-컨텍스트란-">📌 영속성 컨텍스트란 ?</h2>
<p>위에서도 말했다시피 영속성 컨텍스트(Persistence Context)는 &quot;엔티티를 영구 저장하는 환경&quot; 이라는 뜻으로 사용됩니다.</p>
<ul>
<li><p>엔티티 매니저로 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트에
엔티티를 보관하고 관리합니다.</p>
</li>
<li><p>엔티티 매니저를 생성할 때 하나가 만들어집니다.</p>
</li>
<li><p>트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 DB에 반영합니다
== flush()</p>
</li>
<li><p>영속 상태의 엔티티는 모두 영속성 컨텍스트의 내부 캐시(1차 캐시) 에 저장합니다.</p>
</li>
<li><p>애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스와 같은 역할을 합니다.</p>
</li>
<li><p>조회한 엔티티만 영속성 컨텍스트가 관리하게 됩니다.</p>
</li>
</ul>
<h3 id="🟢-영속성-컨텍스트의-장점">🟢 영속성 컨텍스트의 장점</h3>
<ul>
<li>1차 캐시로써의 저장</li>
<li>동일성 보장</li>
<li>트랜잭션을 지원하는 쓰기 지연</li>
<li>변경(커밋) 감지</li>
<li>지연로딩</li>
</ul>
<p><img src="https://velog.velcdn.com/images/kimchi-person/post/dfd8cd7d-6bf6-4fae-805b-7aee5c6c0fd7/image.png" alt=""></p>
<p>■ 비영속
: 영속성 컨텍스트와 전혀 관계가 없는 상태 (순수한 객체 상태)</p>
<p>■ 영속
: 엔티티 매니저를 통해 엔티티를 영속성 컨텍스트에 저장 (영속성 컨텍스트에 의해 관리)</p>
<p>■ 준영속
: 영속성 컨텍스트에 저장되엇다가 분리 및 해제된 상태</p>
<blockquote>
<p>📌 엔티티를 준영속 상태로 전환하는 방법</p>
</blockquote>
<p>em.detach(entity) : 특정 엔티티만 준영속 상태로 전환, 영속성 컨텍스트로부터 분리</p>
<ul>
<li><p>1차 캐시, 쓰기 지연 SQL 저장소 정보 제거    </p>
</li>
<li><p>영속 상태였다가 더는 영속성 컨텍스트가관리하지 않는 상태</p>
</li>
<li><p>쓰기 지연 SQL 저장소의 Insert SQL 도 제거되어 DB에 저장되지 않음</p>
</li>
</ul>
<p>em.clear() : 영속성 컨텍스트를 완전히 초기화</p>
<ul>
<li><p>영속성 컨텍스트를 초기화해서 해당 영속성 컨텍스트의 모든 엔티티를 준영속 상태로 만듦</p>
</li>
<li><p>영속성 컨텍스트를 제거하고 새로 만든 것과 같음</p>
</li>
</ul>
<p>em.close() : 영속성 컨텍스트를 종료</p>
<ul>
<li>해당 영속성 컨텍스트가 관리하던 영속 상태의 엔티티가 모두 준영속 상태로</li>
</ul>
<hr>
<blockquote>
<p> 📌 엔티티를 영속 상태로 전환하는 방법</p>
</blockquote>
<p>em.merge(entity), 병합 : 준영속 상태의 엔티티를 다시 영속 상태로 변경, 새로운 영속 상태의 엔티티를 반환</p>
<ul>
<li><p>파라미터로 넘어온 엔티티의 식별자 값으로 영속성 컨텍스트를 조회하고 찾는 엔티티가 없으면,</p>
<p>데이터베이스에서 조회. </p>
</li>
<li><p>만약 데이터베이스에서도 발견하지 못하면 새로운 엔티티를 생성해서 병합</p>
</li>
<li><p>병합은 준영속, 비영속을 신경쓰지 않고, 식별자 값으로 엔티티를 조회할 수 있으면</p>
<p>불러서 병합하고 조회할 수 없으면 새로 생성해서 병합,</p>
</li>
<li><p>병합은 save or update 기능 수행</p>
</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[[TIL #5] 항해99 2023.02.10]]></title>
            <link>https://velog.io/@kimchi-person/TIL-5-%ED%95%AD%ED%95%B499-2023.02.10</link>
            <guid>https://velog.io/@kimchi-person/TIL-5-%ED%95%AD%ED%95%B499-2023.02.10</guid>
            <pubDate>Fri, 10 Feb 2023 12:43:16 GMT</pubDate>
            <description><![CDATA[<p>오늘은 <strong>JPA(Java Persistence API)</strong>가 무엇인지 알아보려고합니다.</p>
<p>JPA는 자바 진영의 <strong>ORM 기술의 표준</strong>이라고 할 수 있습니다.</p>
<p>기본적으로 스프링을 입문하게 되서 배우기 위함과 사용에 대한 이유를 꼽자면!</p>
<ul>
<li><p>대표적으로 JPA가 제공하는 API를 사용하면 객체를 DB에 저장하고 관리할 때,
개발자가 직접 반복적이며 복잡한 SQL을 작성하지 않아도 됩니다.</p>
</li>
<li><p>JPA가 개발자 대신 그에 맞는 적절한 SQL을 작성해서 DB에 전달하고, 객체를 자동으로 Mapping 해줍니다.</p>
</li>
<li><p>JPA는 내부적으로 JDBC API를 사용하는데, 개발자가 직접 JDBC API를 활용하면 패러다임 불일치, SQL 의존성 등등 효율성이 떨어집니다.</p>
</li>
</ul>
<blockquote>
<p>🙏결론은 JPA를 활용한다면 개발자에게 SQL로 인한 생산성 저하를 줄여줄 수 있다는말이다.</p>
</blockquote>
<hr>
<h2 id="🤔-근데-orm은-뭔데">🤔 근데 ORM은 뭔데?</h2>
<p>Object Relational Mapping, 줄여서 ORM 이라고 합니다.</p>
<p>단어뜻처럼 <strong>객체</strong> 와 <strong>관계형 데이터베이스(테이블)</strong>의 데이터를 자동으로 매핑(연결) 해주는 것을 말합니다.</p>
<ol>
<li><p>객체 지향 프로그래밍은 클래스를 사용하고, 관계형 데이터베이스는 테이블을 사용합니다.</p>
</li>
<li><p>객체 모델과 관계형 모델 간에 불일치가 존재합니다.</p>
</li>
<li><p>ORM을 통해 객체 간의 관계를 바탕으로 SQL을 자동으로 생성하여 이에 대한 불일치를 해결해줍니다.</p>
</li>
</ol>
<h3 id="🟢-orm의-장점">🟢 ORM의 장점</h3>
<ul>
<li>객체 지향적은 코드로 인해 더 직관적이고 비즈니스 로직에 더 집중할 수 있게 도와줍니다.</li>
<li>ORM을 사용하면 SQL Query가 아닌 직관적인 코드(메서드)로 데이터를 조작할 수 있어 개발자가 코드에 흐름을 파악하거나, 그로인해 반비례적으로 올라가는 능률이 증가합니다.</li>
<li>선언문, 할당, 종료 같은 부수적인 코드가 없거나 급격히 줄어듭니다.</li>
<li>SQL의 절차적이고 순차적인 접근이 아닌 객체 지향적인 접근으로 인해 생산성이 증갑합니다.</li>
</ul>
<blockquote>
<p>☝️ 코드가 간결하며 직관적이다 == 재사용 및 유지보수의 편리성 증가!
✌️객체간의 관계를 바탕으로 SQL문을 자동으로 생성 == DBMS에 대한 중속성 저하!</p>
</blockquote>
<h3 id="🔴-orm의-단점">🔴 ORM의 단점</h3>
<ul>
<li>완벽한 ORM으로만 서비스를 구현하기가 어렵습니다.</li>
<li>사용하기는 매우 편하지만 설계는 매우 신중하고 철저하게 해야합니다.</li>
<li>프로젝트의 규모가 커지거나, 복잡해질 경우 난이도 또한 비례하여 증가합니다.</li>
<li>잘못 구현 or 무분별한 사용이 있을경우 프로그램 내부적으로 속도 저하 및 심각할 경우 일관성이 무너지는 문제점이 발생할 수 있습니다.</li>
</ul>
<hr>
<h2 id="🤔-jpa-란">🤔 JPA 란?</h2>
<p>JPA(Java Persistence API)는 자바 진영의 ORM 기술 표준입니다.</p>
<p>JPA를 사용하려면 JPA를 구현한 ORM 프레임워크를 선택해야하는데, 가장 대중적인건 하이버네이트입니다.</p>
<p>■ JPA의 역할</p>
<ul>
<li>Entity 분석</li>
<li>INSERT SQL 생성</li>
<li>JDBC API 사용</li>
<li>패러다임 불일치 해결</li>
</ul>
<h3 id="🟢-jpa의-장점">🟢 JPA의 장점</h3>
<ul>
<li><p>특정 데이터 베이스에 중속되지 않습니다.
만약, 다른 데이터 베이스 오라클(Oracle)을 사용하여 개발하다가 오픈소스인 MariaDB로 변경한다면 데이터 베이스마다 쿼리문이 다르기 때문에 전체를 수정해야 합니다.
하지만 JAP는 추상화한 데이터 접근계층을 제공합니다.
그로인해 설정 파일에 어떤 데이터베이스를 사용할지만 다시 정의 해준다면 얼마든지 데이터베이스의 형식을 전환할 수 있습니다.</p>
</li>
<li><p>객체지향적(OOP) 프로그래밍
JPA를 사용하면 데이터베이스 설꼐 중심의 패러다임에서 객체지향적으로 설계가 가능하다. 이를 통해 좀 더 직관적이고 비즈니스 로직에 집중할 수 있도록 도와줍니다.</p>
</li>
<li><p>생산성 향상
데이터베이스 테이블에 새로운 컬럼이 추가되었을 경우, 해당 테이블의 컬럼을 사용하는 DTO 클래스의 필드도 모두 변경해야 한다. JPA에서는 테이블과 매핑된 클래스에 필드만 추가한다면 쉽게 관리가 가능하다. 또한 SQL문을 직접 작성하지 않고 객체를 사용하여 동작하기 때문에 유지보수 측면에서 좋고 재사용성도 증가한다.</p>
</li>
</ul>
<h3 id="🔴-jpa의-단점">🔴 JPA의 단점</h3>
<ul>
<li><p>복잡한 쿼리 처리
통계 처리 같은 복잡한 쿼리를 사용할 경우는 SQL문을 사용하는게 나을 수도 있습니다.
JPA에서는 Native SQL을 통해 기존의 SQL문을 사용할 수 있지만 그러면 특정 데이터베이스에 중속된다는 단점이 생깁니다.
이를 보완하기 위해서는 SQL과 유사한 기술인 JPQL을 지원하기도 합니다.</p>
</li>
<li><p>성능 저하 위험
객체 간의 매핑 설계를 잘못했을 때 성능 저하가 발생할 수 있으며, 자동으로 생성되는쿼리가 많고 제 각기 의존성을 띄기에 개발자가 의도하지 않는 쿼리로 인해 성능이 저하되기도 합니다.</p>
</li>
<li><p>숙련의 시간
JPA를 적재적소에, 제대로 사용하려면 알아야 할 것이 많아서 학습하고 숙련하는데 오래 걸립니다.</p>
</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[[TIL #4] 항해99 2023.02.09]]></title>
            <link>https://velog.io/@kimchi-person/TIL-4-%ED%95%AD%ED%95%B499-2023.02.09</link>
            <guid>https://velog.io/@kimchi-person/TIL-4-%ED%95%AD%ED%95%B499-2023.02.09</guid>
            <pubDate>Thu, 09 Feb 2023 15:08:35 GMT</pubDate>
            <description><![CDATA[<p>오늘은 스프링 입문주차가 끝난날이다.
CRUD를 기초적으로 구현하는 시험도 봤고 퀴즈(?)도 보고 오늘부로 입문주차가 끝나고
내일부터 숙련주차에 들어가는데 으으...</p>
<p>그래도 나름대로 핵심 키워드나 구현의 흐름은 이해하고 지나가는것 같아 마음은 가벼운것 같다.</p>
<p>다른건 아니고 조금 뜬금없기는 한데 오늘 튜터님께서 들어와서 퀴즈 리뷰를 해주시고
질문시간에 &quot;아 요새는 MSA 개발 기법이 유행해요 알아서 손해볼거 없어요&quot; 라는 말이 나와서 궁금해서 찾아보고 정리해보려고 한다.</p>
<hr>

<h1 id="■-msa-">■ MSA ?</h1>
<p><img src="https://velog.velcdn.com/images/kimchi-person/post/9d910059-0fc4-45d0-927f-f94325d118eb/image.png" alt=""></p>
<p>MSA는  MicroService Architecture의 줄임말로, 소프트웨어 개발 기법 중 하나    라고 합니다.
MSA는 작고, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스들로 구성된 프    레임워크입니다.</p>
<p>경령화되고 독립적인 여러 개의 서비스를 조합하여 프로그램을 구현하는 방식이고,
서비스마다 자체 데이터베이스를 탑재하고 동작하기 때문에 개발부터 빌드, 배포까지
효율적으로 수행할 수 있습니다.</p>
<hr>

<h3 id="■-msa-등장배경-or-이유">■ MSA 등장배경 or 이유</h3>
<p>애플리케이션 개발 초기에는 전체 소스 코드를 하나의 배포 유닛 (war 또는 ear)으로 내장시키는 &#39;Monolithic&#39; 방식을 사용하였습니다.</p>
<p>하지만 기존 애플리케이션의 사소한 변경사항이 있더라도 자체적인 QA(Quality Assurance) 주기에 따라 업데이트를 하거나 일부 서비스 업데이트로 오류가 발생한 경우 전체 시스템을 중단하고 오류를 해결하는 등의 다운타임이 발생하는 일이 빈번하였습니다.</p>
<blockquote>
<p>이러한 문제점을 해결하기 위해 애플리케이션의 핵심 서비스를 분할하는 MicroService Architecture라는 방식이 생겨났으며 각 서비스들을 독립적으로 구축하고 배포할 수 있게 되었습니다.</p>
</blockquote>
<h2 id="🧐-그럼-monolithic은-뭐야">🧐 그럼 Monolithic은 뭐야</h2>
<p>Monolithic은 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태이며,
모듈별로 개발을 하고 개발이 완료된 하나의 결과물로 패키징 하여 배포되는 형태를 의미합니다.</p>
<p>상세하게 다루지는 않고 근본적인 장점과 단점만 몇가지 소개 해보려고 합니다.</p>
<p>▶ 장점</p>
<ul>
<li>개발 초기에는 단순한 아키텍처 구조와 개발에 용이했습니다.</li>
</ul>
<p>▶ 단점</p>
<ul>
<li>서비스 규모가 커짐에 따라 전체 시스템 구조 파악 및 유지보수가 어려워짐</li>
<li>부분 장애가 전체 서비스의 장애로 확대될 수 있음</li>
<li>배포 시간이 오래 걸림</li>
<li>한 Framework와 언어에 종속적</li>
<li>부분적인 Scale-out(여러 서버로 나누어서 일을 처리 방식)이 어려움</li>
</ul>
<p><del>단점이 너무 명확해서 단점만 알고 있어도 될듯하다...!</del></p>
<hr>


<h1 id="🤘본론인-msa의-장점--단점">🤘본론인 MSA의 장점 &amp; 단점</h1>
<h3 id="🟢-msa-장점">🟢 MSA 장점</h3>
<ul>
<li>분산형 개발을 통해 개발 주기가 단축되기 때문에 빠르고 유연한 배포가 가능(출시 기간 단축)</li>
<li>서비스가 독립적이기 때문에 다른 서비스에게 영향을 주지 않음 (뛰어난 복구 능력)</li>
<li>서비스별 기술 도입 및 확장이 자유로움 (높은 확장성)</li>
<li>모놀리식 방식에 비해 애플리케이션이 모듈화 되고 규모가 작기 때문에 우려사항이 줄어든다. (손쉬운 배포)</li>
<li>다중 언어 지원(Polyglot) API를 사용 (향상된 개방성)</li>
<li>하나의 애플리케이션을 여러 부분으로 분할했기 때문에 각 서비스 업데이트 및 개선 용이 (편리한 액세스)</li>
</ul>
<h3 id="🔴-msa-단점">🔴 MSA 단점</h3>
<ul>
<li>각 서비스들은 API를 통해 통신하므로 네트워크 통신에 의한 오버헤드 발생</li>
<li>서비스별로 로그가 생성되므로 중앙 로그 모니터링이 존재하지 않는다.</li>
<li>하나의 프로젝트에 수많은 서비스들이 존재하므로 모든 서비스 모니터링 오버헤드 증가</li>
<li>하나의 서비스에서 다른 서비스를 호출하므로 장애 발생 시 경로 및 장애 추적이 힘듦</li>
<li>서비스가 분산되어 있기 때문에 모놀리식에 비해 상대적으로 많이 복잡</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[[TIL #3] 항해99 2023.02.04 ]]></title>
            <link>https://velog.io/@kimchi-person/TIL-3-%ED%95%AD%ED%95%B499-2023.02.04</link>
            <guid>https://velog.io/@kimchi-person/TIL-3-%ED%95%AD%ED%95%B499-2023.02.04</guid>
            <pubDate>Sat, 04 Feb 2023 17:51:41 GMT</pubDate>
            <description><![CDATA[<p>오늘 3번째 TIL을 끄적여 써보려한다.</p>
<p>아직은 코드에 티끌만큼도 모른다고 생각하지만 여러 강의 자료들을 보고,
예제를 풀어보면서 공통적으로 느끼는게 있다.</p>
<p>강의를 하기 위해서는 서로 다른 강사분들이, 자신만의 색깔과 전하고자 하는 메세지를 담아 만든 자신만의 예제와 자료가 있을텐데 푸는 입장에서는 엄청 쉽다고 생각이 들거나 별거 아니라고 생각하고 지나가곤한다.</p>
<p>하지만 막상 나 자신은 그 사소한 클래스 이름, 변수 이름 조차 떠오르지 않아 유용하거나 대표적인 예시를 가져와서 사용을 해왔다.</p>
<p>이렇게 작은 설계와 구상이 어렵다는걸 요새 정말 많이 느끼고 있다...!</p>
<p>코드는 되도록이면 간결하고, 가독성이 뛰어나며 그로인해 유지보수력이 올라가는 형태가 모범적인 형태라고 배웠고.
현재 배우는 입장에서 첫 단추를 그렇게 끼워가며 하려 노력하지만 생각보다 잘안되는게 현실이다....</p>
<p>그래서 오늘은 백엔드에 꽃인 API에서 가장 널리 사용되고 있는 패턴중 하나인 레이어드 <code>아키텍처 패턴(layered architecture)</code> 에 대해서 써보려고 한다.</p>
<hr>

<h1 id="레이어드-아키텍처-">레이어드 아키텍처 ?</h1>
<p>백엔드 API를 구상 및 설계 할때 가장 널리 착안되어 쓰이고 있는 패턴이라고 알면 될것같다.</p>
<p>레이어드 아키텍처의 기본 개념이자 패턴은 API를 구현할때 역할에 따라 독립된 모듈로 나누워서 코드를 구현하는것을 말한다.</p>
<hr>

<p>각 시스템과 환경에 따라 다를 수 있겠지만, 일반적으로 다음과 같이 3개의 대표적인 레이어가 존재한다.</p>
<p><img src="https://velog.velcdn.com/images/kimchi-person/post/c869d521-8c37-4103-8c78-c050bb160843/image.gif" alt=""></p>
<blockquote>
<p>■ Presentation layer(User Interface) : 
해당 시스템을 이용하는 사용자 혹은 클라이언트 시스템과 가장 직접적으로 연결되는 부분이다.</p>
</blockquote>
<ul>
<li><p>CU, HTTP 요청, HTML 처리 등을 담당한다.``</p>
</li>
<li><p>HTTP 요청 처리 및 HTML 렌더링에 대해 알고 있는 웹 계층</p>
</li>
<li><p>흔히 말하는 MVC(Model / View / Controller) 도 이 계층에 속한다.</p>
</li>
</ul>
<blockquote>
<p>■ Business layer(Business Logic) :
실제 시스템이 구현해야하는 로직을 이 레이어에서 구현하게 된다.</p>
</blockquote>
<ul>
<li><p>서비스 / 시스템의 핵심 로직</p>
</li>
<li><p>유효성 검사 및 계산을 포함하는 Business 논리 계층</p>
</li>
<li><p>애플리케이션이 수행해야 하는 도메인과 관련된 작업들을 담당한다.</p>
</li>
<li><p>입력/ 저장된 데이터를 기반으로 계산</p>
</li>
<li><p>Presentation 계층에서 받은 데이터의 유효성 (Validation) 검사</p>
</li>
<li><p>어떤 Data Access 를 선택할지 결정</p>
</li>
</ul>
<blockquote>
<p>■ Persistence layer(Data Access) :
데이터 베이스와 관련된 로직을 구현하는 부분이다.</p>
</blockquote>
<ul>
<li><p>DAO 계층</p>
</li>
<li><p>Database / Message Queue / 외부 API와의 통신 등 처리</p>
<ul>
<li>데이터베이스 또는 원격 서비스에서 영구 데이터를 관리하는 방법을 분류하는 데이터 접근 계층</li>
</ul>
</li>
</ul>
<hr>]]></description>
        </item>
        <item>
            <title><![CDATA[[TIL #2] 항해99 2023.02.03]]></title>
            <link>https://velog.io/@kimchi-person/TIL-2-%ED%95%AD%ED%95%B499-2023.02.03-eegr70j9</link>
            <guid>https://velog.io/@kimchi-person/TIL-2-%ED%95%AD%ED%95%B499-2023.02.03-eegr70j9</guid>
            <pubDate>Fri, 03 Feb 2023 17:37:21 GMT</pubDate>
            <description><![CDATA[<p>오랜만에 돌아온것 같은데...
설 연휴때 제주도 결항이 있어서 7일동안 진행하였던 알고리즘 주차에서 4일 빼먹었다...
핑계가 될 수 있지만 나름대로 언어학습 주차때 나가지 못했던 진도 + 28개 정도의
알고리즘을 풀어야 해서 정말 정신이 없었다...</p>
<p>그래서 일단 오늘 돌아왔다 다시 써볼거다 화이팅!
<del>파이썬 짱</del></p>
<hr>
오늘부터 주특기 입문 주차가 시작되었다.
첫 주특기 관련 세션도 진행되었는데, 그로인해 들었던 내용들의 상세 내용과 보완을 해보려한다.
<hr>

<h1 id="http-">HTTP ?</h1>
<p>● HTTP는 하이퍼 텍스트 전송 프로토콜(HyperText Transfer protocol) 이다.
● 월드 와이트 웹(WWW)에 내재된 프로토콜이다.
● HTTP는 무상태 프로토콜이며, 이는 서버가 두 요청 간에 어더한 상태나 데이터를 유지하지 않음을 의미한다. (상태를 유지하기 위한 노력으로 Cookie와 Session을 사용한다.)
● HTTP는 인터넷에서 데이터를 주고 받을 수 있는 프로토콜이다.
<img src="https://velog.velcdn.com/images/kimchi-person/post/bf546f6f-5595-48c8-a746-8dd71568cba8/image.webp" alt=""></p>
<hr>
<p>👉  프로토콜(Protocol)이란?</p>
<p>● 프로토콜은 규칙(약속) 이란 의미라고 한다.
● 컴퓨터 네트워크(관계망) 에서 데이터를 주고 받을때, 이러한 규칙에 맞춰 개발함으로써 서로 정보를 교환할 수 있게 된것이다.</p>
<hr>
<p>👉 HTTP의 동작 방식</p>
<pre><code>📌클라이언트📌 :
서버에게 요청을 보내는 리소스 사용자 Ex) 웹 브라우저, 모바일 애플리케이션, IOT 등

📌서버📌 :
클라이언트에게 요청에 대한 응답을 제공하는 리소스 관리자</code></pre><p>클라이언트(웹 브라우저, 모바일 등)가 브라우저를 통해서 어떠한 서비스를 URI를 통해 서버에 요청(Request)하면 서버에서는 해당 요청에 대한 결과를 응답(Response)하는 형태로 동작한다.</p>
<hr>
<p>👉 HTTP Method ?</p>
<p>클라이언트와 서버 사이에 이루어지는 요청(Request)과 응답(Response) 데이터를 전송하는 방식을 말합니다.</p>
<p>쉽게 정리하면 서버에 주어진 리소스에 수행하길 원하는 행동, 서버가 수행해야 할 동작을 지정하는</p>
<p>요청을 보내는 방법입니다.</p>
<hr>
<p>■ GET -리소스 조회(Read)</p>
<ul>
<li><p>데이터를 쿼리스트링으로 주고 받습니다.</p>
</li>
<li><p>GET/api/post/title=항해99&amp;username=강민규</p>
</li>
</ul>
<p>■ POST -리소스 생성(Create)</p>
<ul>
<li><p>요청 데이터를 바디(body)에 담아 서버에 전달합니다.
 URL에 데이터가 노출되지 않기 때문에 데이터를 노출하면 안되는 경우(ex. 회원가입)에</p>
<p> 사용합니다.</p>
</li>
<li><p>주로 새로운 데이터를 등록할 때 사용합니다.</p>
</li>
</ul>
<p>■ PUT - 리소스 수정(update)</p>
<ul>
<li><p>기존에 데이터가 있으면 대체하고, 없으면 새로 생성합니다.</p>
</li>
<li><p>데이터를 대체해야하기 때문에 요청 경로를 구체적으로 지정해주어야 합니다.</p>
</li>
</ul>
<hr>
<aside>
💡 POST와 PUT의 차이

<pre><code>▶ POST : /api/post : 게시물 신규 등록

▶ PUT : /api/post/27</code></pre></aside>

<hr>
<p>■ PATCH - 리소스 수정(update)</p>
<ul>
<li><p>데이터의 일부분을변경하고자 할 때 사용합니다.</p>
</li>
<li><p>모든 서버에서 PATCH를 지원하지 않습니다.</p>
</li>
</ul>
<p>■ DELETE - 리소스 삭제(delete)</p>
<ul>
<li>데이터를 삭제합니다.</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[[TIL #1] 항해99 2023.01.21]]></title>
            <link>https://velog.io/@kimchi-person/TIL-%ED%95%AD%ED%95%B499-2023.01.21</link>
            <guid>https://velog.io/@kimchi-person/TIL-%ED%95%AD%ED%95%B499-2023.01.21</guid>
            <pubDate>Fri, 20 Jan 2023 16:26:07 GMT</pubDate>
            <description><![CDATA[<p>조금 늦은감이 없지 않지만 초반부터 습관을 잡아놓지 않으면 시작할 엄두가 나지 않을까 걱정되어 오늘부터 &quot;TIL&quot; 을 써보려한다.</p>
<p>현재는 주특기의 기반을 이루는 언어를 속성으로 배우기 위한
언어 주차 3일째이다. 자바 겁나어렵다.</p>
<hr>

<p>우선 오늘 수업의 주제는 &quot;객체지향 part.1&quot; 이다.</p>
<p>자바의 대표적인 특징이라고 한다면 &quot;객체지향적&quot; 언어라고 들었다.</p>
<blockquote>
<p>객체지향이란,
하나의 기능을 객체로 만들고, 이러한 객체들을 결합해서 하나의 프로그램을 만든다.</p>
</blockquote>
<p>일단은 이 말을 계속 리마인드 하며 공부했던 하루인것 같다.
더 깊게 파보려고 했는데 뭐... 그럴 시간도 없긴했지만</p>
<p>이론적인건 이정도만 알고 지나가고 나중에 더 파보기로!</p>
<hr>

<h1 id="선언-위치에-따른-변수-종류">#선언 위치에 따른 변수 종류#</h1>
<p>정말로 짜증났던 부분이다...
자바에서는 변수의 타입에 따라 크기가 부여되고, 그에 맞춰 형변환도 진행해주어야 한다. <del><strong><em>(Python 사랑해)</em></strong></del></p>
<p>그런데 거기다 변수라는걸 어느 위치에 놓았을때도 그 성격과 구조적인 면에서도 달라지고 Error도 나고 내가 원하는 값을 구하지도 못해 정말 머리아팠다.</p>
<p>우선적으로,
<img src="https://velog.velcdn.com/images/kimchi-person/post/6dbda2c0-5399-43f6-b95c-c239cf96fc62/image.jfif" alt=""></p>
<p>▶▶클래스 영역(선언위치) : 클래스 변수</p>
<ol>
<li>클래스가 메모리에 올라갈 떄 생성된다.</li>
<li>객체 생성을 하지 않아도 생성되고 언제든지 사용이 가능하다.</li>
<li>접근 방법 : 클래명.클래스변수명</li>
</ol>
<blockquote>
<p>Tip(암기를 위한 키워드) : </p>
</blockquote>
<ul>
<li>인스턴스 변수에 static을 붙여주면됨,</li>
<li>공통적인, 공유하는 으로 생각하면 될듯,</li>
<li>실행된 후 고정적이기에 메모리에 딱 한번 올라감 == 1. 특징</li>
<li>모든 인스턴스가 공통된 값을 공유하게 해줌</li>
</ul>
<p>▶▶클래스 영역(선언위치) : 인스턴스 변수</p>
<ol>
<li>객체가 생성될 때 인스턴스 변수가 생성된다.</li>
<li>접근방법: 참조변수명.인스턴스변수명</li>
</ol>
<blockquote>
<p>Tip(암기를 위한 키워드) :</p>
</blockquote>
<ul>
<li>인스턴스가 생성될 때 생성된다.</li>
<li>그러니 먼저 인스턴스를 생성 후 값을 저장하거나 읽어올 수 있음</li>
<li>변수 별로 다른 값을 가질 수 있으므로, 각각의 인스턴스 마다 고유의 값을 가져야할때는 
인스턴스 변수로 선언.</li>
</ul>
<p>▶▶매서드 영역(선언위치) : 지역 변수</p>
<ol>
<li>메서드가 호출 되서 실행될 떄 생성된다.</li>
<li>메서드가 종료되면 자동으로 제거된다.</li>
</ol>
<blockquote>
<p>Tip(암기를 위한 키워드) :</p>
</blockquote>
<ul>
<li>메서드 안에서 선언되며, 그 안에서만 사용할 수 있다.</li>
<li>해당 메서드 실행시 메모리를 할당 받으며, 실행이 종료되면 메서드가 소멸되어 사용할 수 없다.</li>
</ul>
<hr>

]]></description>
        </item>
    </channel>
</rss>