⚛️ React

<img src="https://image.until.blog/morethanmin/article/1729780816938.gif" data-width="100%" data-align="center" alt="1878"><h2>문제상황</h2>언틸에서 아티클을 작성하다 실수로 창을 닫거나 뒤로가서 내용을 전부 날려먹었다는 피드백을 종종 들었다. (나도 몇번 있었음)물론 노션처럼 실시간으로 데이터가 저장될 수 있다면 더더욱 좋겠지만... 개인이 작성하는 블로그에서는 실시간성이 매우 중요한 요소가 아니기도 하고, 서버 비용도 고려해봤을때 간단하게 이탈을 방지해줄 수 있는 팝업을 띄우는 것이 좋겠다고 생각했다.<h2>BeforeUnload Event</h2>우선 윈도우 창이 닫히는 것을 감지하기 위해서는 wep api인 <a target="_blank" rel="noopener noreferrer nofollow" href="https://developer.mozilla.org/ko/docs/Web/API/Window/beforeunload_event">BeforeUnload Event</a>를 사용하면 된다.문서에 나와있는대로, 작성 페이지에서 대화상자를 열기위해 이벤트 트리거 시점에 <code spellcheck="false">preventDefault()</code>를 호출했다.<pre spellcheck="false"><code class="language-typescript">const handleBeforeUnload = (e: BeforeUnloadEvent) =&gt; {
 e.preventDefault()
} 

// ..... 아티클 작성 페이지 컴포넌트 내부

 useEffect(() =&gt; {
 window.addEventListener('beforeunload', handleBeforeUnload)

 return () =&gt; {
 window.removeEventListener('beforeunload', handleBeforeUnload)
 }
 }, [router])

// .....</code></pre>이렇게 하면 아티클 작성페이지에서 예기치 않게 창을 닫으려고 하는 경우를 막아줄 수 있다.하지만.. 창을 닫는 것 이외에도 client side에서 창을 이동하는 경우에는 해당 이벤트가 트리거 되지 않는다. 이부분을 막기 위해 next router 의 기능을 살펴보면서 route 가 바뀌는것을 방지할 수 있는 방법을 찾아보았다.<h2>방법1. ConfirmLink ❌</h2>첫번째로 시도한 방법은 next에서 제공하는 Link를 감싼 <code spellcheck="false">ConfirmLink</code> 라는 컴포넌트를 만들어 route가 실제로 push되기 전에 모달을 띄워주는 방법이였다.실제로 아래와 같이 구현하였고, 아티클 작성페이지에서 표시되고 있는 헤더에 적용해서 아티클 페이지인 경우 컨펌 모달이 표시되도록 해주었다.<pre spellcheck="false"><code class="language-typescript">import Link from 'next/link'
import { useRouter } from 'next/router'
import { ComponentProps, FC, MouseEvent, useState } from 'react'
import { ConfirmDialog } from 'src/components/ConfirmDialog'

type ConfirmLinkProps = Omit&lt;ComponentProps&lt;typeof Link&gt;, 'onClick'&gt; &amp; {
 title?: string
 description?: string
 showConfirm: boolean
}

const ConfirmLink: FC&lt;ConfirmLinkProps&gt; = ({
 title = '정말 나가시겠어요?',
 description = '저장하지 않은 내용은 모두 사라질 수 있어요. 🥲',
 showConfirm,
 ...linkProps
}) =&gt; {
 const router = useRouter()
 const [isOpen, setIsOpen] = useState(false)

 const handleClick = (e: MouseEvent&lt;HTMLAnchorElement&gt;) =&gt; {
 if (!(e.target instanceof HTMLAnchorElement) || !showConfirm) {
 return
 }

 e.preventDefault()
 setIsOpen(true)
 }

 const handleConfirm = () =&gt; {
 setIsOpen(false)
 router.push(linkProps.href)
 }

 return (
 &lt;&gt;
 &lt;Link onClick={handleClick} {...linkProps} /&gt;
 &lt;ConfirmDialog
 title={title}
 open={isOpen}
 onConfirm={handleConfirm}
 onClose={() =&gt; setIsOpen(false)}
 onCancel={() =&gt; setIsOpen(false)}
 &gt;
 {description}
 &lt;/ConfirmDialog&gt;
 &lt;/&gt;
 )
}

export default ConfirmLink
</code></pre>여기까지는 분명 잘 동작했지만... 이 컴포넌트로는 뒤로가기를 막아줄 수 있는 방법이 없었다.또한 라우트가 생겨날 때마다 해당 컴포넌트를 사용해줘야한다는 컨텍스트를 가지고 있어야하기에 좋은 방법은 아니라고 생각했다.때문에 다른 방법을 찾아보기로 했다.<h2>방법2. next.js 에서 제공하는 router.events 사용하기 ✅</h2><blockquote>pages router 기준으로 작성했습니다.</blockquote>next.js에서는 라우트가 변경되는것을 감지할 수 있도록 이벤트 메서드를 제공하고 있다. (<a target="_blank" rel="noopener noreferrer nofollow" href="https://nextjs.org/docs/pages/api-reference/functions/use-router#routerevents">문서</a>)이 중 routeChangeStart 를 통해 route가 시작되는 시점에 이벤트를 감지하고 에러를 발생시킴으로써 라우팅을 막아주기로 했다.그렇게 작성된 코드는 아래와 같다.<pre spellcheck="false"><code class="language-typescript">const handleBeforeUnload = (e: BeforeUnloadEvent) =&gt; {
 e.preventDefault()
}

const ArticleForm: FC&lt;Props&gt; = ({ defaultValues }) =&gt; {
 const router = useRouter()
 const [blockedUrl, setBlockedUrl] = useState&lt;string | null&gt;(null)

 const syncUrlWithRouter = useCallback(() =&gt; {
 if (router.asPath !== window.location.pathname) {
 window.history.pushState(null, '', router.asPath)
 }
 }, [router.asPath])

 const handleRouteChangeStart = useCallback(
 (url: string) =&gt; {
 if (decodeURIComponent(url).includes(decodeURIComponent(router.asPath))) {
 return
 }

 syncUrlWithRouter()
 setBlockedUrl(url)
 router.events.emit('routeChangeError')
 throw new Error('routeChangeError')
 },
 [router],
 )

 const saveArticle = useSaveArticle((articleUrl) =&gt; {
 router.events.off('routeChangeStart', handleRouteChangeStart)
 router.push(articleUrl)
 })

 useEffect(() =&gt; {
 router.events.on('routeChangeStart', handleRouteChangeStart)
 window.addEventListener('beforeunload', handleBeforeUnload)

 return () =&gt; {
 router.events.off('routeChangeStart', handleRouteChangeStart)
 window.removeEventListener('beforeunload', handleBeforeUnload)
 }
 }, [router])

 return (
 &lt;&gt;
 &lt;FormProvider {...methods}&gt;
 &lt;form css={wrapperStyle} onSubmit={handleSubmit}&gt;
 {/* .... */}
 &lt;/form&gt;
 &lt;/FormProvider&gt;
 &lt;ConfirmDialog
 title="정말 나가시겠어요?"
 open={!!blockedUrl}
 onConfirm={() =&gt; {
 router.events.off('routeChangeStart', handleRouteChangeStart)

 blockedUrl &amp;&amp; router.replace(blockedUrl)
 }}
 onClose={() =&gt; setBlockedUrl(null)}
 onCancel={() =&gt; setBlockedUrl(null)}
 &gt;
 저장하지 않은 내용은 모두 사라질 수 있어요. 🥲
 &lt;/ConfirmDialog&gt;
 &lt;/&gt;
 )
}

export default ArticleForm</code></pre>이제 뒤로가기 버튼의 경우에도 대응해줄 수 있게 되었고, 아티클 작성시점에는 모달이 발생되지 않도록 이벤트를 종료해주었다.에러를 발생시키는 것이기 때문에 dev server에서는 next.js 에러 팝업이 발생하게된다.실제로 이런 방식이 올바른 접근인지에 대해서는 여러 의견이 존재한다. next.js 이슈에서 진행되고 있는 <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/vercel/next.js/discussions/32231">route cancellation에 대한 논의</a>도 한번 구경해보면 좋을 것 같다!

문제상황언틸에서 아티클을 작성하다 실수로 창을 닫거나 뒤로가서 내용을 전부 날려먹었다는 피드백을 종종 들었다. (나도 몇번 있었음)물론 노션처럼 실시간으로 데이터가 저장될 수 있다면 더더욱 좋겠지만... 개인이 작성하는 블로그에서는 실시간성이 매우 중요한 요소가 아니기도 하고, 서버 비용도 고려해봤을때 간단하게 이탈을 방지해줄 수 있는 팝업을 띄우는 것이 

next.js 페이지 바깥으로 못나가게 하기 (router.events)

<img src="https://image.until.blog/steady/article/1727867628378.jpeg" data-width="100%" data-align="center"><h2>알고리즘을 모르면 개발을 못하나?</h2><hr>선배 개발자들의 의견이 다를지 모르겠지만, 내 생각은 NO다.그간 개발을 해오면서 단순히 어떤 변수를 처리해서 전달하고 결과값을 얻어내는 기능을 만들어 내는 데에 어떤 알고리즘을 아냐 모르냐는 큰 영향을 끼치지 않았다.그래서 나는 이 재미없는 알고리즘을 굳이 배워야 하나라는 생각을 머리 한켠에 가지고 있었다.<h2>그럼 알고리즘을 어디에 쓰나?</h2><hr>알고리즘은 효율적인 코딩을 위해 쓴다.똑같은 동작을 하는데 어떤 코드가 더 빨리 수행되고 메모리를 덜 쓴다면 그게 효율적인 코드라고 할 수 있겠다.나는 단순히 어떤 기능을 빨리만 만들어 내는 것보다 어떤 코드를 어떻게 효율적으로 만들거나 수정했는지가 스스로에게 더 보람차고 면접관의 눈에도 더 가치 있는 경험이 된다고 확신한다. (내가 이미 실패 해봤으니까)<h2>복잡도?</h2><hr>알고리즘을 얘기할때 자주 내용인 복잡도는 알고리즘이 수행될때 걸리는 시간이나 메모리의 양을 나타내는 수치이다. 따라서 복잡도가 클수록 비효율적이라고 할수있다.<h3>빅오 표기법</h3>: 복잡도를 설명할때 사용하는 표기법이다.O는 'Order of' 의 약자로 알고리즘의 성능이 입력 크기에 따라 어떻게 변화하는 지 나타낸다.O(입력 크기) 와 같이 표기하며 가장 최악의 경우를 가정한다.<h3>시간 복잡도</h3>: 알고리즘이 수행되는 데 걸리는 시간에 따라 결정된다.<ul><li>주요 복잡도<ul><li>O(1) (상수 시간): 어떤 값을 입력 받던지 실행 시간이 늘 일정한 경우<ul><li>이미 만들어지 변수의 값에 접근하는 경우.</li></ul></li><li>O(log n) (로그 시간): 입력 크기에 따라 실행 시간이 로그 비율로 증가하는 경우<ul><li>이진 검색 알고리즘</li></ul></li><li>O(n) (선형 시간): 입력 크기에 비례하여 실행 시간이 증가하는 경우<ul><li>배열 내의 모든 값을 조회하는 경우</li></ul></li><li>O(n log n): 입력 크기에 따라 로그 비율로 연산을 여러번 하는 경우<ul><li>퀵 정렬, 병합 정렬</li></ul></li><li>O(n²) (이차 시간): 입력 크기에 따라 실행 시간이 제곱으로 증가하는 경우<ul><li>버블 정렬</li></ul></li><li>O(2ⁿ): 입력 값의 모든 경우의 수를 계산하는 경우<ul><li>피보나치 수열을 재귀적으로 계산할 경우</li></ul></li></ul></li></ul><h3>공간 복잡도</h3>: 알고리즘이 수행되는 데 걸리는 메모리의 양에 따라 결정된다.<ul><li>주요 복잡도<ul><li>O(1) (상수 공간): 어떤 값을 입력 받던지 고정된 양의 메모리를 사용하는 경우<ul><li>하나의 변수를 이용할때 데이터를 저장하는 경우</li></ul></li><li>O(n) (선형 공간): 입력 크기에 따라 비례하여 메모리를 사용하는 경우<ul><li>1차원 배열을 이용해 데이터를 저장하는 경우</li></ul></li><li>O(n²) (이차 공간): 입력 크기에 따라 메모리 사용량이 제곱 비례하는 경우<ul><li>2차원 배열이나 그래프로 데이터를 저장하는 경우'</li></ul></li></ul></li></ul><h2>정리하자면</h2><hr><blockquote>코드를 효율적으로 작성하려면 알고리즘을 공부하자.시공간 복잡도가 낮을 수록 효율적인 알고리즘이다.복잡도는 표기법 별로 아래 순서대로 좋고 나쁨을 구분한다. O(1) &lt; O(log n) &lt; O(n) &lt; O(n log n) &lt; O(n²) &lt; O(2ⁿ) &lt; O(n!)다음엔 알고리즘 별 처리 방법과 복잡도 차이를 적어보며 공부하겠다.</blockquote>

알고리즘을 모르면 개발을 못하나?선배 개발자들의 의견이 다를지 모르겠지만, 내 생각은 NO다.그간 개발을 해오면서 단순히 어떤 변수를 처리해서 전달하고 결과값을 얻어내는 기능을 만들어 내는 데에 어떤 알고리즘을 아냐 모르냐는 큰 영향을 끼치지 않았다.그래서 나는 이 재미없는 알고리즘을 굳이 배워야 하나라는 생각을 머리 한켠에 가지고 있었다.그럼 알고리즘을 

[Algorithm] 알고리즘에 대해

이전에 Java에서 불변 데이터 객체를 만들기 위해서는 여러 보일러플레이트들이 많이 필요했다. 그리고 이런 불편을 해소하기 위해 JDK 14부터 <code spellcheck="false">record</code>라는 녀석이 추가되었다.<code spellcheck="false">getter</code>, <code spellcheck="false">equals</code>, <code spellcheck="false">hashcode</code>, <code spellcheck="false">toString</code> 등을 자동으로 만들어주어, 불변 데이터 객체를 쉽게 만들 수 있게 해주는 효자같은 존재다.하지만 이런 record를 사용할 때 조심해야 할 점이 있다.<h1>record에 배열을 쓸 때 조심해야한다</h1><pre spellcheck="false"><code class="language-java">public record Person(
 String[] names,
 int age
) {
}</code></pre>바로 다음과 같이 레코드의 구성요소에 배열(array)이 있을 경우이다.레코드의 구성요소에 배열이 존재할 경우, 레코드가 보일러플레이트들을 자동으로 생성해줌에도 불구하고 직접 equals, hashcode, toString을 재정의해주어야 한다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://rules.sonarsource.com/java/?search=Equals%20method%20should%20be%20overridden%20in%20records%20containing%20array%20fields">https://rules.sonarsource.com/java/?search=Equals%20method%20should%20be%20overridden%20in%20records%20containing%20array%20fields</a>실제로 SonarQube에도 관련된 이슈가 major 단계로 등록되어 있다.그렇다면 이제 왜 이런 이슈가 존재하는지 그 이유를 알아보자.<h1>record에 배열을 쓸 때 조심해야 하는 이유</h1><h2>record의 equals 메소드 작동 방식</h2><a target="_blank" rel="noopener noreferrer nofollow" href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Record.html">https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Record.html</a>오라클의 Record 명세를 살펴보자.<img src="https://image.until.blog/octoping/article/1726301665126.png" alt="until-1346">레코드의 equals 메소드는 해당 레코드의 모든 매개변수 인스턴스가 상대 인스턴스와 동등할 때 true를 반환한다.레코드 클래스의 동등성(Equality)을 비교하는 방법은 다음과 같다.<ul><li>레코드 구성요소 c가 참조 타입 (reference type)일 경우, <code spellcheck="false">Objects.equals(this.c, r.c)</code>의 결과로 판단한다</li><li>레코드 구성요소 c가 원시 타입일 경우, 래퍼 클래스로 바꿔서 <code spellcheck="false">Integer.compare(this.c, r.c)</code>와 같이 compare의 결과로 판단한다.</li></ul><img src="https://image.until.blog/octoping/article/1726301722607.png" alt="until-1347">배열(array)은 참조 타입이므로 <code spellcheck="false">Objects::equals</code>의 결과로 동등성을 판단하게 되고, 배열은 참조가 같을 경우에만 true를 반환하기 때문에 레코드의 equals 연산은 우리가 바라던 대로 흘러가지 않게 된다.그리고 이는 <code spellcheck="false">hashcode</code>, <code spellcheck="false">toString</code>에도 똑같은 논리로 적용되어 원치 않는 결과를 만들어낼 수 있다..<h1>해결법</h1><h2>1. 직접 equals, hashcode, toString을 재정의한다</h2>문제에 대한 직관적인 해답이다. 직접 배열에 대응하도록 이 셋을 재정의해주어야 한다.<pre spellcheck="false"><code class="language-java">public record Person(
 String[] names,
 int age
) {
 @Override
 public boolean equals(Object o) {
 if (this == o) return true;
 if (o == null || getClass() != o.getClass()) return false;
 Person person = (Person) o;
 return age == person.age &amp;&amp; Arrays.equals(names, person.names);
 }

 @Override
 public int hashCode() {
 int result = Objects.hash(age);
 result = 31 * result + Arrays.hashCode(names);
 return result;
 }

 @Override
 public String toString() {
 return "Person{" +
 "names=" + Arrays.toString(names) +
 ", age=" + age +
 '}';
 }
}</code></pre>하지만 이렇게 되면 코드가 굉장히 복잡해진다. 또, 자동으로 생성해주는 함수들을 직접 또 만들어야 하니 사실상 Record를 사용하는 맛이 없다.<h2>2. 배열 대신 List를 사용한다</h2>훨씬 간단하고 영리한 방법이다.<code spellcheck="false">Objects::equals</code>를 제대로 지원하지 않는 배열 대신 List를 사용하면 된다.<pre spellcheck="false"><code class="language-java">public record Person(
 List&lt;String&gt; names,
 int age
) {
}</code></pre><img src="https://image.until.blog/octoping/article/1726302032359.png" alt="until-1348"> List 최고!

이전에 Java에서 불변 데이터 객체를 만들기 위해서는 여러 보일러플레이트들이 많이 필요했다. 그리고 이런 불편을 해소하기 위해 JDK 14부터 record라는 녀석이 추가되었다.getter, equals, hashcode, toString 등을 자동으로 만들어주어, 불변 데이터 객체를 쉽게 만들 수 있게 해주는 효자같은 존재다.하지만 이런 record를 

record에서 배열 사용하지 않기

Cloud Issue

<blockquote>Dawn입니다. 오늘은 업무를 하다 일어난 일을 정리하여 기록하려고 합니다. 부족한 제 글을 읽어주셔서 감사합니다. 😁</blockquote><h2>배경</h2>저희 회사는 멀티 클라우드(GCP, NCP) 기반 서비스를 운영하고 있습니다. 그 중 CDC 파이프라인은 대충 그리자면 아래와 같습니다. 따라서 사내 로그를 <code spellcheck="false">BigQuery</code>로 적재하기 위해서 적절한 <code spellcheck="false">Logging Sink</code>를 생성하는 것이 맞습니다. 그런데..아래와 같은 메일 내용이 전직원에게 전달되게 됩니다.(젠장..)<img src="https://image.until.blog/dawn-py/article/1727248513445.png" alt="until-1543">이 문제가 왜 발생했는지 원인을 파악하고 해결했던 방법에 대해서 작성해보도록 하겠습니다.(의외로 간단했다..)<h2>원인 파악</h2>이 오류의 원인은 <code spellcheck="false">gcloud</code> 로 싱크를 생성할 경우 <code spellcheck="false">BigQuery</code>내의 권한 부여(<code spellcheck="false">Data editor</code>)까지 자동으로 적용하지 않는 것이었습니다. 또한 Logging 서비스 에이전트(Logging Service Agent)와 밀접한 관련이 있는 오류였습니다. 그렇다면 Logging 서비스 에이전트가 뭘까요?<h3>Logging Service Agent</h3>정의하자면 GCP Logging을 포함한 Stack Driver API 내의 서비스를 참조 혹은 직접적으로 사용하게 될 경우 문제가 되지 않게 구글에서 자동으로 생성해주는 서비스 계정입니다.이전에는 Logging 싱크가 생성될 때마다 <code spellcheck="false">p{projectID}-{randomInt}@sa-googleapis.com</code> , 이런 형식으로 서비스 계정에 BigQuery 데이터 편집자 권한을 부여하고 싱크 프로젝트 단위로 생성해주었습니다.하지만 현재는 생성되는 싱크는 모두 <code spellcheck="false">service-{projectID}@sa-googleapis.com</code> , 형식의 공통의 서비스 계정을 참조하고 있고 이 계정을 Logging 서비스 에이전트라고 합니다. 아래는 Logging 싱크 생성 시 발생되는 상황을 시퀀스 다이어그램으로 정리한 그림입니다.<img src="https://image.until.blog/dawn-py/article/1727248529439.png" alt="until-1544">이 때 웹 콘솔과 <code spellcheck="false">gcloud</code>의 생크 생성 과정은 전혀 다른 로직을 타게 됩니다. 따라서 싱크를 생성했을 당시 CLI로 생성했기에 라우팅되는 로그를 실시간으로 적재하기 위해 Logging 서비스 에이전트의 서비스 계정을 찾아 최소 데이터셋에 대한 데이터 편집자 권한을 등록해야 했던 겁니다.<h2>오류 해결</h2><img src="https://image.until.blog/dawn-py/article/1727248585126.png" alt="until-1545"><blockquote>⚠️&nbsp;저희 팀은 GCP 관리자(Admin) 권한을 가지고 있기 때문에 IAM 관리 및 편집이 가능합니다. 만약 권한이 없다면 따로 요청을 해서 처리해야 할 것입니다. 이 점 참고바랍니다.</blockquote>IAM관리 탭에서 우리는 ‘Google 제공 역할 부여 포함’을 체크하게 되면 <code spellcheck="false">Logging 서비스 에이전트</code>에 등록된 서비스 계정을 확인할 수 있었고 해당 계정을 편집하여 BigQuery 데이터 편집자 역할까지 부여하게 되니 <code spellcheck="false">gcloud</code>로 생성 시 BigQuery 내에 테이블이 생성되는 것을 확인할 수 있었습니다.<blockquote>여기까지 부족한 글임에도 읽어주셔서 감사합니다. Dawn이었습니다. 😁</blockquote><hr><h2>참고 자료</h2><ul><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://cloud.google.com/logging/docs/routing/user-managed-service-accounts?hl=ko">사용자 관리형 서비스 계정으로 로그 싱크 구성 &nbsp;|&nbsp; Cloud Logging &nbsp;|&nbsp; Google Cloud</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://stackoverflow.com/questions/58899182/google-cloud-stackdriver-logging-log-export-to-bigquery-access-to-the-datase">Google Cloud Stackdriver Logging - Log Export to BigQuery - Access to the dataset was denied</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://stackoverflow.com/questions/61935273/google-cloud-creating-sink">Google Cloud - creating sink</a></li></ul>

GCP Logging Sink를 활용해 BigQuery에 로그를 적재하는 과정에서 발생한 권한 문제 해결 방안.

[GCP] Logging Sink 생성 시 오류 원인 파악

Apache Kafka

<blockquote>Dawn입니다. 사내에서 활용하고 있는 아파치 카프카에 대해서 더욱 알아가고자 공부를 하고 있습니다. 강의를 들으면서 내용을 제 생각과 섞어 정리한 부분이기 때문에 글 내용이 완전한 정답이라고는 할 수 없습니다. 더욱 나은 데이터 엔지니어가 되고자 노력하겠습니다. 감사합니다.</blockquote><h2>초기의 스타트업</h2><img src="https://image.until.blog/dawn-py/article/1727054642391.png" alt="until-1441">기업이 막 생겨나서 초기 서비스가 시작되었을 때는 대게 이렇게 소스데이터(예를 들어 데이터베이스)가 어떤 서비스 내 타켓 데이터로 흘러가는 형식입니다. 서비스가 막 생겨났기 때문에 시스템 규모가 작아 위와 같은 형식이 문제가 되지는 않습니다. 누군가가 코드를 작성하고 데이터를 받아 추출 후 변환하고 로딩하게 되는겁니다.<h2>기업이 확대</h2><img src="https://image.until.blog/dawn-py/article/1727054652308.png" alt="until-1442">점점 기업이 발전하게 되면 자연스럽게 많은 소스 시스템을 갖게 되는데 이때 동일하게 타깃 시스템도 많아지게 됩니다. 정보를 공유하기 위해서는 소스 시스템이 모든 타깃 시스템에 데이터를 전송해야 하기 때문에 데이터 통합 문제는 위와 같이 복잡한 형태를 이루게 됩니다.위와 같은 아키텍쳐는 예를 들어 4개의 소스 시스템이과 6개의 타깃 시스템이 있다면 서비스를 운영하기 위해서는 24개의 통합을 코드로 작성해서 소스데이터를 추출하고 변환하고 로딩해야 합니다. 여간 번거로운 일이 아니죠.또한 모든 소스데이터가 모두 동일한 통신 프로토콜로 전송받는다는 보장도 없습니다. 이제는 TCP, HTTP, REST, FTP, JDBC 등으로 여러 방식으로 데이터가 전송되기 때문입니다.그리고 이러한 데이터가 모두 같은 형식이라는 것도 보장할 수 없습니다. JSON이 될 수도 있고, CSV, Binary, Parquet 등등 다양한 형식으로 데이터가 구성되기때문입니다.이러한 문제를 주먹구구식으로 해결한다고 했을 때 관리의 문제와 비용의 증가가 가장 큰 문제점이라고 할 수 있습니다.지금은 대기업이 된 링크드인 또한 이와 동일한 문제가 있었습니다. 링크드인이 이러한 문제를 어떻게 풀었는지는 <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.google.com/url?sa=i&amp;url=https%3A%2F%2Fwww.linkedin.com%2Fpulse%2Flinkedin-apache-kafka-muhammad-waqas-dilawar&amp;psig=AOvVaw1OjL81dhH37D0ql7MA0vfO&amp;ust=1726248601132000&amp;source=images&amp;cd=vfe&amp;opi=89978449&amp;ved=0CBcQjhxqFwoTCPj08qb3vYgDFQAAAAAdAAAAABAS">해당 링크</a>를 통해 읽어보면 좋을 것 같습니다.<h2>카프카</h2><img src="https://image.until.blog/dawn-py/article/1727054661037.png" alt="until-1443">잠깐 언급했듯이 링크드인은 이러한 문제를 해결하고 이벤트 스트리밍 데이터를 한 곳에 모아서 관리하는 Kafka라는 시스템을 개발하게 됩니다. 카프카는 데이터 중개 플랫폼으로서 소스데이터가 생산(Producer)해내는 데이터를 스트림 형식으로 변환시키고 타깃 시스템이 데이터를 가져가거나 혹은 전달해주는 역할을 합니다. 중간 관리자 역할로 존재하고 분산되어 있던 데이터의 흐름을 연결해서 관리하기 때문에 링크드인은 더욱 확장성있는 이 시스템을 통해 다양한 서비스를 만들게 됩니다.오늘은 카프카가 무엇인지 왜 필요한지에 대해서 간략하게 설명해 보았습니다. 정리도 하면서 글을 써 내려가니 복잡하고 어렵지만 제 글을 읽으면서 도움이 되셨으면 하는 마음에 마무리 지었던 것 같습니다. 다음에는 더 나은 글로 인사드리겠습니다. 감사합니다.

왜 많은 기업은 카프카를 선택할까

[Kafka] 1. 카프카의 필요성

취미

<h3>HG x Minecraft Base 65 Keyboard - Grass Block 구매후기</h3><a target="_blank" rel="noopener noreferrer nofollow" href="https://higround.co/products/minecraft-x-hg-base-65-keyboard-grass-block">https://higround.co/products/minecraft-x-hg-base-65-keyboard-grass-block</a><hr>나는 몰랐다. 내가 마인크래프트 굿즈를 살줄... 근데 그게 키보드 일줄... 근데 그걸 직구를 할줄...나는 게임을 좋아하는데 마인크래프트랑 포켓몬을 좋아하는 편이다.하이그라운드에서는 둘다 판매를 한다. 키보드를 몇번 사봤다만, 화이트에 심플한 디자인만 사다가 애정하는 캐릭터들이 잔뜩 그려져 있는 키보드를 보니 눈이 돌아가는줄 알았다. 하이그라운드에는 그 외의 덕질하기 좋은 애니키보드도 많다.아주.. 뭔가 잘 아는 사람들인거같다... 음...어찌됐든 저찌됐든 7월 2일에 구매해서 7월 11일에 배송받앗다. 생각보다 빠르게 배송받았다.구매 과정에서 주문취소가 3번이나 되기도 했으며 영어로 메일을 보내기도 했고 그 과정을 좀 공유하려 한다.구매를 고민하는 분들 의사결정에 도움이 되길..<h1></h1><h1>결제금액</h1><img src="https://image.until.blog/dody/article/1720795464943" alt="until-819">패키지 보호? 저건 배송보험 인거같아서 소중히 제품을 받고 싶은 마음에 결제했다.키보드는 145달러 20만원 정도이고, 원래 쓰던 키보드들도 그정도 해서 크게 부담이 되진않았다.배송비는 5만원정도인데, 뭐 해외에서 오는 값 생각하면 비싸지만... 어쩔수 없다 생각...그렇게 25만원 정도로 구매를 했다.<h1>3번의 주문 취소</h1>나는 해외직구는 처음인데 결제정보를 제대로 입력했음에도 불구하고, 계속해서 취소되었다고 메일을 받았다. 주문하자마자 취소를 받았기 때문에.. 내가 잘못된 정보를 작성한건가? 싶어서 메일을 보냈다.<blockquote><h4>Why cancel my payment?</h4>I really want to buy it, but is there something I'm writing wrong? I'm curious what the problem is.</blockquote>딱 이렇게 본론만 적어 6월21일 메일을 보냈고, 아래 답장을 7월 2일에 받았다.한국의 고객센터와 같은 속도를 바라지 않았기 때문에 천천히 기다렸다. 그래도 친절하게 사유를 알려주셨고.. 자동플래그에서 나를 제외해서 결제하기에 문제가 없게 도와주셨다.내가 또 개발자이다 보니, 저러한 의사결정과 대응에 아주 만족하고 감사함을 느끼고 바로 주문을 다시 했고<img src="https://image.until.blog/dody/article/1720795636084" alt="until-820">드디어.. 결제가 성공했다7월 2일에 결제해서 7월 12일 퇴근하고 돌아오니 집앞에 택배가 와있었고, 바로 테스트 중이다.<h1>맥북과 호환</h1>아니 이것에 대해서는 고민조차 하지도 않았었다. 당연히 될줄 알았는데 window, alt, ctrl 키를 마주했을때는 조금 당황했을지도...처음에는 키가 완벽하게 작동하지 않아서 뭔가 잘못됐다 생각했는데,<a target="_blank" rel="noopener noreferrer nofollow" href="https://higround.co/blogs/hypegeek-update/how-to-connect-a-higround-keyboard-to-an-apple-macbook">https://higround.co/blogs/hypegeek-update/how-to-connect-a-higround-keyboard-to-an-apple-macbook</a>하이그라운드의 블로그 글을 참고해서 도움을 받았다.중간 부분에 Key Mapping 부분을 읽어보면 window는 command alt는 option의 역할을 하고 있다고 되어있어서, 두 위치를 바꿔주기만 하면 문제가 없다고 생각했다.system setting &gt; keyboard &gt; keyboard shortcuts 에서 수정이 가능하다.<img src="https://image.until.blog/dody/article/1720796773431" alt="until-821"><img src="https://image.until.blog/dody/article/1720796817271" alt="until-822">modifier keys &gt; select keyboard가 higround인걸 확인하고 option 과 command 키 위치를 바꿔주면 맥 호환은 완벽하게 된다.<h1>그래서 만족하는가?</h1>완전 대만족이다. 내가 구매한건 잔디블록의 키보드인데나는 식물을 좋아해서 식물의 갈색과 녹색을 좋아해서 나에게 이렇게 안성맞춤일수가 없다.<img src="https://image.until.blog/dody/article/1720795444318" alt="until-817">외관도 불투명 녹색? 못참지사실 박스를 오픈하면서도 감동을 받았는데 디테일이 좀 뛰어났음..<img src="https://image.until.blog/dody/article/1720796960599" alt="until-823"><img src="https://image.until.blog/dody/article/1720796970729" alt="until-824">ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ마인크래프트 화면 박스에 그려져 있는거 진짜 졸귀탱... 나도 다이아 검 가지고 싶어잉... &gt;0&lt;<img src="https://image.until.blog/dody/article/1720797000505" alt="until-825">키캡 제거나 하는 거나 usb to c케이블 들어있었다.이런 디테일이 예상치못한 감동을 만든다니까 정말..거기다가 키보드의 조명이 장난 아니다... 하이그라운드의 기술력인거같은데 되게 다양한 스타일의 조명을 제공해주는데, 나는 그냥 불빛만 전체적으로 나오는 키보드만 써봤지.. 이렇게 스타일리쉬한 조명이 나오는건 처음 봤는데 키보드 칠 맛이 난다.정말로 정말로 다양한 조명이 있다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://app.higround.co/">https://app.higround.co/</a>이곳에서는 조명 커스텀이 가능하다던데, find device에 내 기기가 뜨지 않아서 나는 안해봤다. 꼭 저걸 하지 않아도 키보드 단축키로 조명을 스위칭 할수 있기 때문에 앞으로 딱히 필요 없을듯하다.하여튼 오타쿠들 하이드라운드로 다 모여~~~~<h1>단점</h1><h3>1) 65키 괜춘?</h3>딱봐도 키가 65개에다가 콤팩트하기 때문에 손에 익지 않을사람은 안익을거같다. 나는 원래 텐키리스도 잘쓰던 사람이라 거의 바로 적응했다.흠... 오른쪽 쉬프트랑 방향키가 좀 킹받긴 하지만 뭐...할만하다.<h3>2) 백틱 위치 괜춘?</h3>물결이라던가 템플릿 리터럴 코드 쓸 때 좀 당황스럽다.백틱은 보통 esc 아래에 있는데, 이 키보드는 제일오른쪽상단에 위치한다.이게 당황스럽긴한데,왼손으로는 shift를 누르고 오른손으로는 백틱버튼을 누르면 생각보다 안정적이고 편하다... 백틱의 위치는 애초부터 이곳에 있는게 모두의 행복과 가까운게 아닐까 생각이 들 정도...<h1>결론</h1>그 외 단점은 없다.기계식 키보드의 스위치 종류에 빠삭하지는 못해서 자세히 평가를 내리진 못하겠지만,저소음적축만 사용하던 나였는데 그것보다는 경쾌하고 키압이 적은 편이다.히히 너무 만족스러운 소비였고 ~~ (이 물결 치면서도 백틱 위치 헷깔려서 삐끗함)마인크래프트 하러 가야겠다🪴🪴🪴

higround 마인크래프트 키보드를 산 사람이 있다? 

[취미]🌴 higround 마인크래프트 키보드 구매 후기 (맥북 호환)

팬텀 타입(Phantom Type)은 Haskell, Rust와 같은 언어에서 사용하는 기술이다. 팬텀 타입은 타입 매개변수(Generics)의 역할을 하는데, 실제 런타임에는 사용되지 않는 타입을 의미한다. 코드에서 타입 안전성을 강화하기 위해 사용된다......위와 같은 내용의 글들을 많이 읽었다. Typescript 사용자로써, 팬텀 타입에 대해 공부하려고 할 때마다 이게 무슨 뜻인지 이해가 잘 안 갔었는데, 공부하고 정리해본 내용을 이해하기 쉽게 예시와 함께 소개해보려고 한다.<h1>TypeScript는 구조적 타이핑을 하는 언어다</h1>구조적 타이핑이 무엇인지 알지 못하는 타 언어 사용자를 위해 짧은 설명을 하고 넘어가자. 구조적 타이핑은 클래스의 이름 따위가 아니라, '객체의 형태와 구조'를 타입의 중요한 요소로 여기는 방식을 의미한다.<pre spellcheck="false"><code class="language-typescript">class Human {
 name: string;
 age: number;
}

class Animal {
 name: string;
 age: number;
}

const member = {
 name: "Octoping",
 age: 25,
};

// 이 세 가지 객체 or 클래스의 타입은 사실상 전부 같다

function sayName(x: Human) {
 console.log(x.name);
}

// 전부 타입 문제 없이 작동한다
sayName(new Human("Octoping", 25));
sayName(new Animal("Pig", 3));
sayName(member);</code></pre>다음은 자바 같은 언어라면 생각도 못할 일이다. Human 클래스도, Animal 클래스도, member라는 변수도 <code spellcheck="false">string</code> 타입의 name과 <code spellcheck="false">number</code> 타입의 age를 가지므로 전부 같은 타입으로 인지하는 것이다.물론 객체를 클래스를 사용하지 않고도 바로 만들 수 있다는 자바스크립트의 특징 때문에 어쩌면 당연할 수 밖에 없다. 그리고 이 특성으로 인해 Typescript는 큰 생산성을 얻게 되면서 동시에 한 가지 단점을 얻게 되는데.<h2>문제 제기</h2>구조적 타이핑으로 인해 조금 불편을 겪을 수 있는 에피소드를 소개해보고자 한다.<pre spellcheck="false"><code class="language-typescript">type Dollar = number;
type Won = number;

// 십만원을 가진 나
const octopingMoney: Won = 100000;
const friendMoney: Won = 50000;

// 달러를 더하는 함수
function addDollar(a: Dollar, b: Dollar): Dollar {
 return a + b;
}

// 🥵
const result = addDollar(octopingMoney, friendMoney);</code></pre><code spellcheck="false">Dollar</code> 와 <code spellcheck="false">Won</code>은 둘 다 숫자지만, 단위가 다르므로 서로 더하면 안된다. 하지만 구조적 타이핑 덕분에 이런 놀라운 일이 가능해진다.이런 불편함을 어떻게 하면 좋을까?도메인 주도 개발에서 이야기하는 값 객체라는 걸 이용해보면 좋을 것 같다.<h2>값 객체를 다루기 어렵다</h2><pre spellcheck="false"><code class="language-java">class Member {
 private Email email;
 private Password password;
 // ...
}

class Email {
 private String value;

 public Email(String value) {
 if (!value.contains("@")) {
 throw new IllegalArgumentException("이메일 주소가 올바르지 않아요");
 }
 
 this.value = value;
 }
}

class Password {
 private String value;

 public Password(String value) {
 if (value.length() &lt; 8) {
 throw new IllegalArgumentException("비밀번호가 너무 짧아요");
 }

 this.value = value;
 }
}</code></pre>다음은 Java를 이용해서 값 객체 (VO)를 사용한 예제다. <code spellcheck="false">Member</code>에 이메일과 비밀번호를 그냥 String으로 저장하는 대신, 각각을 클래스로 묶어서 자기 자신이 값을 지님과 동시에 유효성 검사를 할 수 있도록 했다. 자신이 자기 자신을 그 자체로 소개할 수 있도록 하는 것. 그것이 도메인 주도 개발에서 이야기하는 값 객체이다.<pre spellcheck="false"><code class="language-typescript">class Member {
 constructor(
 private readonly email: Email,
 private readonly password: Password
 ) {}
}

class Email {
 value: string;

 constructor(value: string) {
 if (!value.includes("@")) {
 throw new Error("이메일 주소가 올바르지 않아요");
 }

 this.value = value;
 }
}

class Password {
 value: string;

 constructor(value: string) {
 if (value.length &lt; 8) {
 throw new Error("비밀번호가 너무 짧아요");
 }

 this.value = value;
 }
}

// 순서가 틀렸지만 당연히 에러가 나지 않는다!
const member = new Member(new Password("email"), new Email("password"));</code></pre>그런데 아뿔싸! 다음과 같은 코드를 Typescript에서 작성한다면 조금의 문제가 생겨버린다. 바로 <code spellcheck="false">Email</code>과 <code spellcheck="false">Password</code>의 시그니처가 똑같다는 것. 멤버 변수 타입 똑같고.. 메소드가 없는 것도 똑같은 것 같다. 당연히 에러가 나지 않겠지?<blockquote>이 문제에 대해서 진지하게 이야기해보면. 일단 첫 번째: 두 객체의 멤버 변수 값을 다르게 하면 된다. 그것이 구조적 타이핑이니까.. 하지만 서로 다른 두 클래스가 각자의 멤버 변수 이름에 강결합되는 프로그래밍을 유도하게 되는 것 같다. 두 번째: value를 private으로 만들면 된다.</blockquote><h2>문제 갈무리</h2>정리해보자. <code spellcheck="false">Dollar</code>와 <code spellcheck="false">Won</code>을 그냥 number로써 동일하게 표현하면 타입스크립트는 이 둘을 완전히 같은 타입으로 인지하여 똑같이 다뤄버리게 된다.이를 위해 값 객체를 사용해보려 하니 이 또한 멤버 변수의 이름을 신경써야 하니 나름의 어려움이 있다.마지막으로, 그냥 타입을 number로 쓸 때에 비해 객체를 생성해야 하니 메모리도 더 잡아먹게 된다. 객체지향이 원래 그런 것이다만은..<img src="https://image.until.blog/octoping/article/1723552083845" alt="until-1228">이런 상황을 어떻게 하면 좋을까?<h1>Phantom Type</h1>서론이 길었다. 팬텀 타입을 이용해보면 이런 문제를 해결해볼만한 실마리를 잡을 수 있을지도 모른다. 팬텀 타입을 내 나름대로 간단히 설명해보면 이렇다.<blockquote>형태는 같지만 실제로는 서로 다른 타입을 구분하기 위해, 실제로는 존재하지 않는 타입을 이용하는 것</blockquote><h2>코드로 살펴보기</h2><pre spellcheck="false"><code class="language-typescript">type Dollar = number &amp; { __unit: "Dollar" };
type Won = number &amp; { __unit: "Won" };

const myDollar = 2 as Dollar;
const myWon = 1000 as Won;</code></pre>달러와 원을 그냥 number가 아니라, <code spellcheck="false">number</code>이면서 <code spellcheck="false">{ __unit: string }</code> 인 녀석으로 정의하는 것이다.물론 이 뒷 부분은 실제 런타임에는 전혀 존재하지 않는 녀석이다. (타입스크립트에서 타입은 컴파일 단계에서 사라지므로 런타임에는 더더욱 존재하지 않게 된다)하지만 타입스크립트에게 억지로 이것이 존재한다고 함으로써 이 둘을 마냥 서로 같은 <code spellcheck="false">number</code>가 아니도록 만드는 것이다.<pre spellcheck="false"><code class="language-typescript">type Dollar = number &amp; { __unit: "Dollar" };
type Won = number &amp; { __unit: "Won" };


function addDollar(a: Dollar, b: Dollar): Dollar {
 return (a + b) as Dollar;
}

function dollarToWon(dollar: Dollar): Won {
 return (dollar * 1300) as Won;
}


const myDollar = 2 as Dollar;
const myWon = 1000 as Won;


const addedDollar = addDollar(myDollar, myDollar);
const convertedWon = dollarToWon(myDollar);

// 에러!
addedDollar(myWon, myWon);

// 에러!
convertedWon(myDollar);</code></pre>그렇다면 이렇게, 사실은 서로 같은 number를 서로 다른 타입처럼 사용할 수 있다.<h2>실생활 예제</h2>그럼 이걸 실생활에 어디다 어떻게 쓰라고? 팬텀 타입에 대해 다부지게 설명해주신 이 글에서 소개해준 예제를 조금 가공해서 빌려와볼까 싶다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://dev.to/busypeoples/notes-on-typescript-phantom-types-kg9">https://dev.to/busypeoples/notes-on-typescript-phantom-types-kg9</a><pre spellcheck="false"><code class="language-typescript">type MemberJoinPayload = {
 name: string;
 age: number;
};

export const onSubmit = (e: FormEvent&lt;HTMLFormElement&gt;) =&gt; {
 const payload: MemberJoinPayload = {
 name: e.currentTarget.name,
 age: e.currentTarget.age,
 };
 
 // validate를 해야 하지만 깜빡했다~~!!!!

 callApi(payload);
};

function validateData(data: MemberJoinPayload) {
 if (data.age &lt; 0) {
 throw new Error("나이가 음수에요");
 }
}

async function callApi(data: MemberJoinPayload) {
 // 대충 api 호출하는 코드
}
</code></pre>회원가입 폼에서 입력 받은 내용을 validate를 거친 후, 성공했다면 회원가입 api 호출 함수를 쏘는 로직을 떠올려보자.여기서 validate를 까먹어서 검증을 안 거치고 api를 호출하도록 코드를 작성하더라도 타입 상으로는 아무~ 문제가 없이 작동하기 때문에 내가 뭘 잘못했는지 생각 못하고 넘어갈 수 있다.여기서 팬텀 타입을 적용해보자.<pre spellcheck="false"><code class="language-typescript">type MemberJoinPayload = {
 name: string;
 age: number;
};

type UnvalidatedData = MemberJoinPayload &amp; { _type: "Unvalidated" };
type ValidatedData = MemberJoinPayload &amp; { _type: "Validated" };


export const onSubmit = (e: FormEvent&lt;HTMLFormElement&gt;) =&gt; {
 const payload = {
 name: e.currentTarget.name,
 age: e.currentTarget.age,
 } as UnvalidatedData;

 const validatedData: ValidatedData = validateData(payload);
 
 callApi(validatedData);
};

function validateData(data: UnvalidatedData): ValidatedData {
 if (data.age &lt; 0) {
 throw new Error("나이가 음수에요");
 }

 return { name: data.name, age: data.age } as ValidatedData;
 // return data as unknown as ValidatedData; 사실 이게 더 깔끔할지도
}

async function callApi(data: ValidatedData) {
 // 대충 api 호출하는 코드
}</code></pre>폼을 입력 받아 실행되는 <code spellcheck="false">onSubmit</code>에서 <code spellcheck="false">UnvalidatedData</code> 타입의 payload를 생성한다. 물론 이 변수로는 <code spellcheck="false">callApi</code> 함수를 실행할 수 없다.따라서 그 후 validate를 실행하면 <code spellcheck="false">ValidatedData</code> 타입의 결과를 받게 되니 이제서야 api를 호출할 수 있게 되는 것이다.실제 객체의 값은 전혀 변하지 않았고, <code spellcheck="false">__type</code>이니 뭐니 하는 것은 그 어디에도 존재하지 않았지만, 있는 타입이라고 타입스크립트에게 공갈을 하여 똑같은 타입의 서브 타입을 두 개를 만들어낸 것이다.<h2>팬텀 타입 추상화하기</h2>이 쯤 봤으면 팬텀 타입을 공용적으로 쓸 수 있게 추상화해볼 수 있겠다는 생각이 들 것이다. <code spellcheck="false">type Data = OriginalType &amp; { __value: string }</code> 대충 이런 형태이니..<pre spellcheck="false"><code class="language-typescript">type PhantomType&lt;Data, Type = never&gt; = Data &amp; { _type: Type };</code></pre>짜잔!그럼 이걸 이용해서 다양한 팬텀 타입을 원하는 대로 만들어보자.<pre spellcheck="false"><code class="language-typescript">type MemberJoinPayload = {
 name: string;
 age: number;
};

type UnvalidatedData = PhantomType&lt;MemberJoinPayload, "Unvalidated"&gt;;
type ValidatedData = PhantomType&lt;MemberJoinPayload, "Validated"&gt;;</code></pre><pre spellcheck="false"><code class="language-typescript">type Dollar = PhantomType&lt;number, "Dollar"&gt;;
type Euro = PhantomType&lt;number, "Euro"&gt;;
type Won = PhantomType&lt;number, "Won"&gt;;</code></pre><h2>ChatGPT가 추천하는 팬텀 타입 유망 직종</h2>다음은 ChatGPT에게 직접 팬텀 타입을 어디에 써보면 좋겠을지 물어보아 나온 결과인데 공유해본다.<ul><li>데이터베이스 ID 타입 구분<ul><li>서로 다른 테이블에서 사용되는 ID 값을 혼동하지 않도록 팬텀 타입을 사용할 수 있습니다</li></ul></li></ul><pre spellcheck="false"><code class="language-typescript">type UserId = PhantomType&lt;number, "User"&gt;;
type OrderId = PhantomType&lt;number, "Order"&gt;;

function getUserById(userId: UserId) {
 // 사용자 조회 로직
}

function getOrderById(orderId: OrderId) {
 // 주문 조회 로직
}

const userId: UserId = 1 as UserId;
const orderId: OrderId = 1 as OrderId;

// 올바른 사용
getUserById(userId);
getOrderById(orderId);

// 잘못된 사용 방지
// getUserById(orderId);</code></pre><ul><li>도메인 모델의 상태 구분<ul><li>상태 변화에 따른 도메인 모델의 상태를 팬텀 타입으로 구분하여, 잘못된 상태에서 발생할 수 있는 동작을 방지할 수 있습니다.</li></ul></li></ul><pre spellcheck="false"><code class="language-typescript">type Draft = { __status: 'Draft' };
type Published = { __status: 'Published' };

type Document&lt;Status&gt; = {
 content: string;
 status: Status;
};

function publish(doc: Document&lt;Draft&gt;): Document&lt;Published&gt; {
 return { ...doc, status: { __status: 'Published' } };
}

const draftDoc: Document&lt;Draft&gt; = {
 content: 'Draft content',
 status: { __status: 'Draft' }
};

// 올바른 상태 전환
const publishedDoc = publish(draftDoc);

// 잘못된 상태 전환 방지
// publish(publishedDoc); // 이미 게시된 문서는 다시 게시할 수 없음</code></pre>개인적으로 이건 비즈니스 로직에 관련된 건데 그냥 진짜 타입으로 관리해야 좋을 것 같다는 생각이다.<ul><li>서로 다른 API 엔드포인트에 안전하게 호출<ul><li>API 요청 시, 서로 다른 API 엔드포인트에 같은 데이터 타입을 사용하더라도, 요청 경로를 팬텀 타입으로 구분하여 잘못된 경로로 요청을 보내는 실수를 방지할 수 있습니다.</li></ul></li></ul><pre spellcheck="false"><code class="language-typescript">type PhantomType&lt;Data, Type = never&gt; = Data &amp; { _type: Type };

type ApiUri = string;
type OrderServerUri = PhantomType&lt;ApiUri, "주문"&gt;;
type UserServerUri = PhantomType&lt;ApiUri, "유저"&gt;;

async function fetchOrderList(uri: OrderServerUri, payload: any) {
 return fetch(uri, payload);
}

fetchOrderList("/api/order" as OrderServerUri, { userId: 1 });
fetchOrderList("/api/order" as UserServerUri, { userId: 1 }); // Error</code></pre>

Phantom Type 기초부터 알아보자

[영상처리프로그래밍]

프론트엔드

2024년, FE 개발자들은 어떤 일들을 할까?

잘보고갑니다! 저는 모든 역할을 하고있네요.. 🥲

CodingTest

<h3>다시푸는 코딩 테스트 준비 일지</h3><ul><li>응시 사이트 : <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.acmicpc.net/">BOJ</a></li><li>문제 : <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.acmicpc.net/problem/9728">9728.Pair Sum</a></li><li>사용언어 : C#</li><li>난이도 : Easy</li><li>풀이시간 : 13m</li><li>유형 : 투 포인터, 해시</li></ul><h2>문제</h2>You are given an integer array of size N and an integer M. This array has (N*(N-1))/2 different pairs. You need to calculate how many of those pairs have the sum equal to M. For example, if the array is {1,2,3,4} and M is 5, then there are exactly 2 pairs {1,4} and {2,3} whose sum is equal to M.&nbsp;<h2>입력</h2>The first line has a positive integer T, T &lt;= 100,000, denoting the number of test cases. This is followed by each test case per line.&nbsp;Each test case consists of two lines. The first line contains 2 integers N and M separated by a single space. N is between 2 and 20,000 inclusive. The second line consists of the N integers separated by a single space, denoting the values of the given array. All the numbers in the array are between 1 and 1,000,000,000 inclusive. They are distinct and sorted in increasing order.<h2>출력</h2>For each test case, the output contains a line in the format Case #x: R, where x is the case number (starting from 1) and R is the number of pairs whose sum is exactly the given M.&nbsp;<h2>예제 입력 1 복사</h2><pre spellcheck="false"><code>5
8 100
19 25 32 48 52 68 75 81
8 100
19 28 31 49 51 61 72 81
8 100
16 22 38 46 58 62 73 81
8 100
13 21 32 48 52 67 78 87
8 100
13 24 34 43 57 61 76 81
</code></pre><h2>예제 출력 1 복사</h2><pre spellcheck="false"><code>Case #1: 4
Case #2: 3
Case #3: 1
Case #4: 2
Case #5: 2
</code></pre><h3>문제 풀이 접근</h3>문제가 영어라 이해를 하기 쉽지않은데, 문제 자체의 조건은 단순하다. <ol><li>Arr Size 를 N으로 주겠다. 그리고 정수하나를 M으로 주겠다. </li><li>배열 내에서 두개의 페어(원소)의 합이 M와 동일한 값을 갖는 수의 갯수를 찾아라. </li><li>그리고 출력처럼 양식 맞춰서 출력하라.</li></ol>크게 투포인터 유형의 전형적인 문제라서 문제 풀이 전략을 간단히 적어본다면,<ol><li>Left = 0. Right = _arr.Length -1 로 양 끝점에 인덱스를 배치한다. </li><li>while ( Left &lt; Right ) 의 조건을 사용하여 Left가 Right 에 도달하면 루프 종료하도록 한다.</li></ol>**인덱스를 연산하는 것 때문에, 보통 정렬된 배열에서 투포인터 알고리즘을 사용한다.<h3>작성 코드 (C#)</h3><pre spellcheck="false"><code class="language-csharp">using System;
using System.Collections;
using System.Collections.Generic;
using System.Xml.Linq;
using static CodingTestProj.Program;
using System.Text;

///*
// * Difficulty : Easy
// * URL : https://www.acmicpc.net/problem/9728
// * Time : 13m
// */

namespace CodingTestProj
{
 internal class Program
 {
 static void Main(string[] args)
 {
 Solution solu = new Solution();
 solu.solve();
 }
 }

 public class Solution
 {
 int _n; // 배열 사이즈
 int _m; // 정수 M

 int _loopCnt;
 int[] _arr;
 Dictionary&lt;int, int&gt; _dic;

 public void solve()
 {
 _dic = new Dictionary&lt;int, int&gt;();
 _loopCnt = int.Parse(Console.ReadLine());

 for (int i = 0; i &lt; _loopCnt; ++i)
 {
 string[] _input = Console.ReadLine().Split(' ');
 _n = int.Parse(_input[0]);
 _m = int.Parse(_input[1]);

 _arr = new int[_n];
 _input = Console.ReadLine().Split(' ');

 for (int j = 0; j &lt; _input.Length; ++j)
 _arr[j] = int.Parse(_input[j]);
 // 데이터 설정

 int _left = 0;
 int _right = _arr.Length - 1;

 while (_left &lt; _right)
 {
 if (_arr[_left] + _arr[_right] == _m)
 {
 if (_dic.ContainsKey(i) == false)
 _dic.Add(i, 0);

 _dic[i]++;
 ++_left;
 }
 else if (_arr[_left] + _arr[_right] &lt; _m)
 {
 ++_left;
 }
 else
 {
 --_right;
 }
 }
 }

 foreach (var pair in _dic)
 {
 int key = pair.Key;
 int value = pair.Value;

 Console.WriteLine($"Case #{key + 1}: {value}");
 }
 }
 }
}</code></pre><h3>코드 결과</h3><img src="https://image.until.blog/sin0105/article/1734366681076.png" data-width="100%" data-align="center" alt="2550">

혼자서 다시푸는 코딩테스트 준비 일지 - 69

코딩테스트 준비 - Pair Sum

오늘 이야기할 단일 책임 원칙(SRP)은 이 SOLID 의 다섯 가지 원칙 중 첫 번째에 해당하며, 이를 잘 이해하고 적용하는 것이 나머지 원칙들을 제대로 구현할 수 있는 토대가 된다고 생각합니다 

until blog seo 점수가 낮음(x -> 낮지 않음)