작년에 개발한 Drag and Drop으로 파일 첨부하기 기능을 구현하면서 생겼던 문제와 해결방법에 대해서 거의 1년이 다 되어가는 시점에서 다시 정리해서 올려본다. 사실 사내 발표를 위해 준비했던 자료를 글로 다시 풀어 작성하는 정도인데 지금 생각 해 보니 아쉬운 점이 많았던 결과와 과정이었던 것 같다. 그래도 그만큼 성장한 거라고 생각하기.
<hr>
채용 솔루션에 메시지 기능을 추가하면서 PO님께서 조심스럽게 요청사항을 추가하셨다. 드래그 앤 드랍으로 파일을 첨부할 수 있도록 해달라는 것인데 채팅 화면에 파일을 가져와서 떨구면 바로 파일이 첨부되는 기능이었다. 그 때 이미 SDK를 이용해서 메시지 보내기와 파일 보내기 기능이 모두 구현되어 있었고 재미있을 것 같아서 흔쾌히 수락했고 작업은 금방 끝날 것 같다고 말했다. 전에 MDN에서 본 <code>Drag and Drop API</code>를 사용하면 금방 구현할 수 있을거라고 생각했었기 때문이다.
지금까지 그 어떤 태스크 진행하면서도 생각대로 된 적이 없었음에도 왜 그런 안일한 생각을 했던걸까… 아무튼 당연히 생각대로 되지 않은 부분들이 너무 많았고 해결 과정을 공유해볼까 한다.
<h3>Drag and Drop API</h3>
말 그대로 브라우저 내에서 요소들을 Drag and Drop 할때의 동작을 제어해줄 수 있는 API이다. Draggable한 (image, anchor 등) 요소들이 Drag될 때 발생하는 이벤트들을 조작할 수 있으며 운영체제의 Drag and Drop API와도 연동이 되어서 외부로 파일을 끌어오는 기능에도 사용할 수 있다.
<h3>구현</h3>
기능 스펙은 매우 간단했다. 외부에서 파일을 드래그해서 채팅창 영역으로 끌고오면 첨부가 될 것을 알리는 오버레이로 띄우고 그 상태에서 드랍을 하게되면 파일을 전송해준다.
<img src="/images/dnd_example.gif" alt="">
처음에는 아래 코드 수준으로 간단하게 구현할 수 있을거라고 기대했다.
<pre><code class="language-tsx">const [enteredDrag, setEnteredDrag] = useState(false);

return (
 &lt;ChatContainer
 onDragEnter={() =&gt; {
 setEnteredDrag(true);
 }}
 onDragLeave={() =&gt; {
 setEnteredDrag(false);
 }}
 onDrop={() =&gt; {
 // ...
 }}
 &gt;
 {enteredDrag &amp;&amp; &lt;AttachmentOverlay /&gt;}
 &lt;Chat /&gt;
 &lt;/ChatContainer&gt;
);
</code></pre>
그러나 생각한대로 overlay가 노출되지 않았다. 이유는 두가지가 있었는데 첫번째로는 overlay가 화면을 가리면서 dragLeave와 dragEnter이벤트가 무한 반복으로 발생하는 것이었다. overlay컴포넌트가 마운트 되면서 기존에 dragOver되어 있던 element에서 dragLeave가 발생하면서 enteredDrag가 <code>false</code>로 처리되고 다시 overlay아래쪽에 있던 element에서 dragEnter가 발생한다. 그러면서 enteredDrag는 다시 <code>true</code>가 되면서 이벤트가 무한반복하게 된다.
두번째로는 drag이벤트가 모두 버블링으로 이벤트가 전파되기 때문에 <code>ChatContainer</code>안에서 발생하는 모든 이벤트에 대해서 이벤트 핸들러가 동작하게 되어 기대하는 동작이 이뤄지지 않는 것이었다.
아무튼 특정 경계에서만 dragEnter와 dragLeave 이벤트 핸들러가 동작할 수 있도록 해야했다. 처음 시도했던 방법은 이벤트가 발생한 <code>target</code>과 <code>currentTarget</code>이 일치할 때만 이벤트가 발생하도록 했는데, 경계에 겹치는 요소가 있으면 거기서 문제가 발생했다. 경계에 겹치는 요소에서 dragEnter가 발생하면 <code>target</code>과 <code>currentTarget</code>이 다르기 때문에 의도대로 동작하지 않았다.
<h4>경계 정하기</h4>
특정 경계를 넘어서 들어오는 dragEnter 이벤트에서만 동작하도록 하기 위해선 어떻게 해야할까? 결론적으로 <code>relatedTarget</code>을 통해서 분기를 나눌 수 있었다. <code>relatedTarget</code>은 MouseEvent객체의 속성 중 하나인데 커서가 들어오거나 나갈 때의 대상이 되는 요소를 담고 있다. (참고: <a href="https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/relatedTarget">MDN - relatedTarget</a>) 즉 dragEnter의 <code>relatedTarget</code>이 <code>ChatContainer</code>에 포함(contain)되지 않는다면 <code>ChatContainer</code>를 기준으로 밖에서 진입한 dragEnter 이벤트라는 것을 알 수 있다. dragLeave이벤트도 동일하게 조건을 넣어줄 수 있다.
아래 이미지처럼 event의 <code>relatedTarget</code>이 경계로 지정한 요소에 contain 되고 있다면 경계에서 발생한 이벤트가 아니기 때문에 무시해버리면 된다.
<img src="/images/2023-05-21-14-00-15.png" alt="relatedTarget에 맞춰서 이벤트 동작의 여부를 결정하는 다이어그램">
위 방법으로 다음과 같이 코드를 작성해서 처리할 수 있었다.
<pre><code class="language-tsx">const [enteredDrag, setEnteredDrag] = useState(false);

const setEnterDragWithBoundary = (
 e: React.DragEvent&lt;HTMLDivElement&gt;,
 value: boolean
) =&gt; {
 if (
 relatedTarget instanceof HTMLElement &amp;&amp;
 // Container에 포함된다면 return
 (e.currentTarget.contains(relatedTarget) )
 ) {
 return;
 }

 setEnterDrag(value);
 };

return (
&lt;ChatContainer
 onDragEnter={() =&gt; {
 setEnterDragWithBoundary(true);
 }}
 onDragLeave={() =&gt; {
 setEnterDragWithBoundary(false);
 }}
 onDrop={() =&gt; {
 // ...
 }}
&gt;
 {enteredDrag &amp;&amp; &lt;AttachmentOverlay /&gt;}
 &lt;Chat /&gt;
&lt;/ChatContainer&gt;
</code></pre>
이렇게 처리해서 drag이벤트가 Container의 밖에서 안으로 들어올때나 안에서 밖으로 나갈 때만 동작하도록 할 수 있었다.
그러나 이렇게해서 끝이 났다면, 블로그 포스팅까지는 하지 않았을 것이다… 새로운 시련이 생겼는데 바로 사파리에서 문제가 발생했다.
<h3>사파리(Safari) 이슈</h3>
사파리에서는 drag이벤트에서 <code>relatedTarget</code>이 모두 <code>null</code>로 평가되는 치명적인 이슈가 있었다. 찾아보니 굉장히 오래된 <a href="https://bugs.webkit.org/show_bug.cgi?id=66547">버그</a>였고, 2011년에 보고 된 이후로 지금까지도 방치되고 있는 듯 하다. IE가 떠나고 나니 이제 사파리가 그 자리를 대신 하는듯한 느낌…^^ 그렇다고 해서 사파리를 배제할 수는 없었다… 다시 생각해 봐도 <code>relatedTarget</code>을 사용하지 않고 구현할 수 있는 방법은 떠오르질 않았고, 결국에는 ref를 사용해서 <code>relatedTarget</code>을 직접 구현하는 방식으로 진행했다.
<h4><code>relatedTarget</code>을 직접 구현</h4>
<code>relatedTarget</code>을 직접 구현하기 위해서는 dragEnter, dragLeave일 때 참조하는 <code>relatedTarget</code>이 각자 다른 방식으로 구현되어야 했다. 먼저 dragEnter일 때는 간단하게 구현이 가능했다. 아래처럼 마지막으로 dragLeave가 발생할 때 <code>target</code>을 <code>relatedTarget</code>에 할당해주면 된다. 그럼 그 다음 바로 발생하는 dragEnter이벤트의 <code>relatedTarget</code>이 마지막으로 dragLeave가 일어난 element를 참조한다.
dragEnter의 relatedTarget이 결정되고 참조되는 과정을 이미지로 표현하면 아래와 같다.
<img src="/images/2023-05-21-16-38-45.png" alt="A에서 B로 드래그 이벤트가 이동하면서 ref를 사용하여 만든 임의의 relatedTargetRef을 결정하고 참조하는 방법을 보여주는 다이어그램, A에서 DragLeave이벤트가 발생하면 relatedTargetRef에 이벤트의 target을 할당하고 B에서 DragEnter이벤트가 발생하면 relatedTargetRef을 참조하여 relatedTarget을 찾는다.">
비교적 간단하게 dragEnter 이벤트의 <code>relatedTarget</code>을 결정할 수 있었다.
그러나 dragLeave이벤트의 <code>relatedTarget</code>을 결정하는 방법은 바로 떠오르지 않았다. dragEnter가 발생하는 요소를 참조해야 하는데 dragLeave이벤트가 발생하는 시점에서 외부 맥락에서는 어떤 요소로 이동할지를 알 수 없었기 때문이다. 즉 내가 갈 곳을 내가 나가는 시점에서 바로 알 수 있는 방법이 없다.
<img src="/images/2023-05-21-16-51-07.png" alt="">
이 문제를 해결하기 위해서 꽤나 많은 고민을 했는데, 결국에는 방법을 찾을 수 있었다. 바로 <code>document.elementFromPoint</code>메서드를 사용하는 것이다. 아마 바로 이해되는 사람도 있을테고 그걸로 어떻게? 할 수도 있는데, 아주 원초적이고 단순한 방법으로 다음으로 이동할 요소를 가져올 수 있었다.
<code>elementFromPoint</code>메서드는 특정 위치에 존재하는 요소를 가져오는 메서드이다. 그리고 dragLeave가 발생한 시점의 마우스 좌표에 있는 요소는 dragLeave가 발생한 이후 dragEnter가 발생하는 요소와 동일할 것이다. 그렇다면 dragLeave가 발생하는 시점의 마우스 좌표를 가져와 <code>elementFromPoint</code>로 요소를 가져오면, 해당 요소가 dragLeave의 <code>relatedTarget</code>으로 사용될 수 있다는 것이다.
그리하여 아래와 같이 dragLeave와 dragEnter의 <code>relatedTarget</code>을 명령형으로 결정해 줄 수 있게되었다.
<img src="/images/2023-05-21-17-09-13.png" alt="">
<pre><code class="language-tsx">const [enterDrag, setEnterDrag] = useState(false);
const relatedTargetRef = useRef&lt;HTMLElement | null&gt;(null);

const setEnterDragWithBoundary = (
 e: React.DragEvent&lt;HTMLDivElement&gt;,
 value: boolean
) =&gt; {
 const relatedTarget =
 // e.relatedTarget이 없다면, enter일 때는 relatedTargetRef를, leave일 때는 elementFromPoint을 통해서 relatedTarget을 가져옴
 e.relatedTarget ||
 (value
 ? relatedTargetRef.current
 : window.document.elementFromPoint(e.clientX, e.clientY));

 if (
 relatedTarget instanceof HTMLElement &amp;&amp;
 e.currentTarget.contains(relatedTarget)
 ) {
 return;
 }

 relatedTargetRef.current = null;
 setEnterDrag(value);
};

return (
 &lt;ChatContainer
 onDragEnter={e =&gt; {
 setEnterDragWithBoundary(e, true);
 }}
 onDragLeave={e =&gt; {
 // dragLeave를 할 때 dragEnter할 때 참조할 relatedTargetRef를 결정
 if (e.target instanceof HTMLElement) {
 relatedTargetRef.current = e.target;
 }
 setEnterDragWithBoundary(e, false);
 }}
 onDrop={() =&gt; {
 // ...
 }}
 &gt;
 {enteredDrag &amp;&amp; &lt;AttachmentOverlay /&gt;}
 &lt;Chat /&gt;
 &lt;/ChatContainer&gt;
);
</code></pre>
기본적으로는 <code>relatedTarget</code>을 참조하고 만약 <code>relatedTarget</code>이 <code>null</code>이라면, dragEnter의 상황에서는 직접 정의한 <code>relatedTargetRef</code>를 참조하도록 하고 dragLeave의 상황에서는 <code>elementFromPoint</code>으로 가져온 요소를 참조하도록 하여 구현하게 되었다.
물론 이후에도 몇가지 예외처리가 필요했지만, 이렇게 일단락하여 기능을 구현하여 배포할 수 있었고 그러면서 발생했던 가장 골치아팠던 문제들을 해결했던 과정을 정리해봤다.
<hr>
<h3>회고</h3>
당시에는 이 문제를 해결했음에 성취감이 굉장했다. 불가능할 것 같은 상황을 내가 알고있는 지식을 활용해서 하나씩 해결해 내는 과정에서 느끼는 카타르시스는 '이 맛에 개발자 한다’는 느낌을 낭낭하게 받을 수 있게 해줬다. 주니어는 그렇다. 뭔가 복잡한 문제를 역량을 통해 해결하는 것을 통해서 성장한다고 느낀다. 그런 관점에서는 좋았지만 이제 와서 생각해 보면 나는 이런 해결 방법이 좋지 못했다 라고 회고한다. 개발역량을 증명하는 것과 좋은 코드를 쓰는 것은 비슷하면서도 다른 부분이 많은 것 같다. 내가 알고있는 다양한 API들과 메서드들을 잘 사용해서 어려운 문제를 해결해내는 것은 개발자로서 가져야 하는 소양임은 분명하지만 그게 좋은 방법인지에 대한 고민도 함께 해야하는 것이다. 일단 위 코드는 실제로 다양한 예외처리와 함께 구현되었을 때 한 눈에 이해하기가 많이 어렵다. 만약 누군가 이 코드를 수정해야 하고 나에게 설명을 요구한다면 나는 꽤나 민망한 상황을 마주하게 될 것 같다는 생각이다.
어떤 동료분이 '차력쇼’라는 표현을 자조적으로 사용했었다. 그러니까 이렇게 어떤 문제를 해결하기 위해서 A to Z로 명령형인 코드를 짜는 과정을 위트있게 표현한 것인데 나는 이런 문제해결 방식이 말 그대로 차력쇼가 아니었을까 생각한다. 만약 그 어떤 라이브러리나 마크업 구조를 변경하지 않고라는 전제가 있는 상태로 파일 첨부 기능을 구현해야 하는 상황이었다면 최선을 다했다고 생각하겠지만, 유지보수 가능한 프로덕션 레벨의 서비스의 코드를 작성해야 하는 상황에서 이렇게 한 땀 한 땀 구현한 건 그냥 주니어의 객기가 아니었을까… 싶은 아쉬움이 남는다. 하지만, 지금와서 이런 회고를 할 수 있다는 게 어느정도는 성장을 통해 가질 수 있는 시야라고 생각하기도 하기 때문에 내가 잘 가고있구나 라는 생각도 든다.
다음에는 ‘이렇게 차력쇼를 할 수 있겠군… 하지만 좀 더 좋은 방법을 찾아볼까?’ 라는 식으로 문제를 세련되게 해결해보고 싶다.

Drag and Drop을 활용한 파일첨부 기능 개발기

개발자로 일을 시작한지 1년 정도가 지났다. 그동안 드라마앤컴퍼니의 컨텐츠 크루와 커리어 크루에 있으면서 정말 다른 성격의 두 가지 제품을 함께 만들며 느낀 점과 앞으로 성장하고 싶은 방향 들을 적어내려가 보려고 한다.
작년의 나와 비교했을 때 뭐가 달라졌을까? 주니어 개발자들이 모두 갖고있는 걱정과 강박이 성장이 아닐까 싶다. 일년 전 보다 더 나은 코드를 짤 수 있고 일년 전 보다 더 나은 설계를 할 수 있게 되기를 바라는 것이 아직도 성장해야 하는 입장에서 당연하게 바라는 것이겠지만, 내가 좋은 개발자가 되기 위해 그냥 계속 정진하면 따라오는 게 성장이라는 점 또한 말하지 않아도 지당하다. 그러면 내가 생각하는 좋은 개발자가 무엇인지에 대한 정의가 먼저 되어야 내가 바라는 성장이 따라올 것 이다.
<h2>좋은 개발자?</h2>
그래서 내가 생각하는 좋은 개발자는 무엇일까 생각해봤다. 1년 정도 개발자로 일을 하면서 느낀 게 있다면, 스스로 개발자라고 정의하기 전에 제품을 만드는 사람이라고 정의하고 싶다는 것이다. 제품은 반드시 사용되어야 가치가 있을테고 때문에 사용자가 가장 중요하다. 그리고 좋은 제품을 만들 때 필요한 다양한 리소스 중에서 나는 사용자의 피부에 닿는 인터렉션을 담당하는 부분을 만드는 개발자이다. 그런 제품을 만들기 위해서는 UX에 대한 이해와 사용자가 불편을 느끼는 지점들을 잘 파악해야 하고, 그런 문제들을 개발이라는 도구를 통해서 풀어나갈 수 있어야 한다.
<h3>내가 되고싶은 좋은 개발자</h3>
그런 관점에서 좋은 제품을 만드려는 의지는 결국 좋은 개발자가 되는 방향과 연결된다. 당연하게도 사용자는 빠르게 화면을 보고 지체없이 원하는대로 빠르게 작동하기를 원한다. 그러기 위해서는 사용자에게 우리의 제품이 전달되는 유일한 통로인 네트워크에 대해서 잘 이해하고 있어야 하며 코드가 어떤 환경에서도 빠르고 문제없이 동작 할 수 있도록 성능과 안정성을 생각하며 작성해야 한다. 그리고 필요한 기능을 제공하기 위한 API들을 잘 이해하고 있어야 한다. 또한 사용자가 원하는 것이 무엇인지 빠르게 확인하고 피드백을 반영하기 위해서는 생산성 또한 아주 중요하다. 그러기 위해서는 변화에 유연한 설계와 기능과 의존성의 분리 등 신경써야 하는 것이 정말 많아진다. 결국에는 좋은 제품을 만드는 개발자가 되기 위해서 필연적으로 개발적인 역량이 필요한 것이다.
좋은 개발자가 되기 위해 좋은 개발자가 되는 건 어려운 것 같다. 영어를 잘 하기 위해 영어공부를 하는 것이 동기부여가 잘 되지 않는 것 처럼. 올 해는 막연히 ‘좋은 개발자가 되고싶다.’ 라고 생각하기 보다는, 사용자에게 훌륭한 경험을 주는 제품을 만들 수 있는 좋은 개발자가 되어보려는 방향을 명확히 할 수 있었던 한 해가 된것 같다.
<h3>아쉬운 점</h3>
아쉬운 점도 확실한데, 제품을 만드는 사람으로써의 개발자, 내가 되고싶은 좋은 개발자에 대한 정립은 잘 해낸 것 같지만, 정작 기술적인 성장에 있어서는 많이 더뎠던 것 같다. 부트캠프에서 주 5일 하루 12시간씩 공부할 때와 비견하면 안되겠지만, 그럼에도 아쉬운 건 어쩔 수 없는 것 같다. 매번 좋은 아티클들을 읽어보려고 북마크 해두고 있지만 시간내어 읽는 것이 쉽지가 않다. 네트워크나 인프라에 대한 지식도 좀 더 깊이있게 배워야 하는데 아직까지 회사에서 실제로 하는 업무에 엮이지 않은 영역에 대한 공부를 적극적으로 하지 못하고 있는 것 같아서 아쉽다. 이 부분에 대한 해소도 올해 다양한 방법으로 시도해 볼 생각이다.
<h2>앞으로</h2>
아무튼 2022년은 내가 처음 개발자로써 제품에 기여해보고 좋은 개발가 되기위해 가야할 방향을 정하는 소스를 입력받는 한 해가 되었다면 2023년은 좀 더 능동적인 학습을 통해서 그 소스들을 갖고 추진력을 만들기 시작하는 해가 되었으면 한다. 개발자 커리어가 늦었다면 늦었다고 할 수 있지만 그럴수록 조급하지 않고 그 전에 내가 쌓은 인사이트와 경험들을 어떻게 더 녹여서 시너지를 낼 수 있을지 고민하면서 성장하고 싶다.
<h3>독서</h3>
처음에 기능개발을 하면서 코드를 짤 때 의존성을 적당히 분리하고, 적당히 변경할 수 있도록하여 당장 돌아가는 코드만 짜도 뿌듯했었는데, 점점 협업하는 사람들이 많아지고 내가 짠 코드가 다양한 곳에 영향을 줄 수 있게 된다는 것을 느끼면서 코드에 대한 책임감이 늘어갔다. 그에 따라서 코드의 맥락적인 구조나 설계, 디자인패턴, 방법론등에 대한 고민을 많이 하게 되었는데 그런 부분들을 책을 통해 해소할 수 있지 않을까 싶다. 지금까지 개발에 대한 방법론이나 철학에 대한 책이 얼마나 도움이 될까 싶은 의문이 있었어서 굳이 시간투자를 하지 않았는데, (사실 저런 생각을 할 때는 책을 읽었어도 별 도움이 되지 않았을 것 같다.)이제는 내가 고민하는 분명한 지점이 있고 해소하고 싶은 것들이 있으니 한 권씩 읽고 느낀 점들을 블로그에 올려볼 생각이다.
<h3>사이드 프로젝트</h3>
이건 진짜… 사실 2022년에도 계속해서 진행하던 사이드 프로젝트가 있었는데 솔직히 의욕부족으로 인해 제대로 진행하지 못했었다. 백엔드 개발까지 함께 하려니까 힘이 부치기도 했고… 작년에 못했던 걸 올 해라고 갑자기 할 수 있지는 않을 것 같지만, 일단 기능을 더 축소하더라도 배포정도는 해봐야하지 않을까?! 사실 초반에 너무 힘을 주고 시작한 게 이렇게 의욕상실까지 오지 않았을까 싶다. 그래서 가능하면 최소기능으로 배포 한 다음 천천히 기능을 붙여보는 방법으로 방향을 전환해볼까 생각중이다. 디자인도 내가 해보겠다고 피그마 파일 만들고 했었는데, 정말… 열정을 불태우는데에 모든 연료를 써버린 것 같다. 2023년 리필된 열정을 이번에는 효율적으로 사용해보자.
<h3>코어크루</h3>
그리고 1월 16일 부터는 컨텐츠크루, 커리어크루를 지나 코어크루에서 일하게 될 것 같다. 근 일년동안 회사가 투자유치 이후 빠르게 성장해야하는 과정에 있다보니 조직구조의 변화가 많이 있었다. 덕분에(?) 다양한 도메인의 제품을 모두 경험할 수 있었고, 그 베이스를 토대로 코어크루에서 리멤버 제품 전체에 적절하게 기여할 수 있지 않을까 기대된다. 사실 나는 제품을 함께 만들어 나가는 것에 큰 만족을 느낀다고 생각했었기 때문에 커리어에 남아있을까 했었는데, 그렇다고 내가 제품 없이 다른 방향성으로 기여하는 방식으로 일해 본 적도 없으니까. 이번에 해보고 판단해볼 생각이다. 그리고 확실히 제품에 대한 바인딩이 없는 작업들이 많을테니까 지금까지와는 다른 방향으로 기술적 고민들이 있지 않을까 기대하는 부분도 있다. 그리고 인프라…! 진짜 인프라쪽도 많이 공부해보고 싶다. 아쉬운 점이라면 지금까지 컨텐츠크루와 커리어크루를 계속 함께 일했던 PO님과의 생이별이 있었다… 일을 함에 있어서도 서로 이해도가 있고 인간적으로도 편한 부분이 있었어서 참 좋은 파트너다 라고 생각했지만 이번 조직개편때는 함께하지 못하게 되었다. 결국 다양한 사람들과 빠르게 적응하는 것도 역량이니까… 서로 홀로서기 해보자고 하며 응원하며 보내줬다(?)
하나의 회사를 다니면서 이렇게 다양한 경험을 쌓아갈 수 있는 건 진짜 행운이라고 생각한다. 일년 동안 세 번 도메인을 바꿔가면서 일한다? 경험에 목마른 주니어 개발자에겐 최고의 환경 아닐까? 물론 한 도메인에 전문성을 갖는 것도 좋지만 아직은 다양한 방향에 대해서 고민해볼 수 있는 시점에서는 더 많은 인풋을 가져올 수 있는 환경이 좋다고 생각한다. 아무튼 올해는 코어크루에서 폭풍성장 해보자! 파이팅!

Drag and Drop을 활용한 파일첨부 기능 개발기

2022년 회고