Convention

팀 프로젝트를 진행할 때마다 팀원들이 각자 생각하는 API 설계 규칙이 달라서, 매번 새로운 회의를 하고 규칙을 작성하는 것이 번거롭고 시간 낭비가 되었습니다.이런 답답한 상황에서 팀원 모두를 설득할 수 있을 만큼 완벽한 RESTful API 설계 규칙을 만들기 위해 많은 노력을 기울였습니다!!!덕분에 팀원들을 설득하여 프로젝트를 빠르게 진행할 수 있었습니다. 원래 노션에 작성해두었던 이 문서를 다른 사람들에게도 도움이 될까 하여 블로그에 올려보게 되었습니다 :)<h2>1. 자원(리소스) 기반 URI</h2><ul><li>일관된 URI 구조: 모든 자원은 고유한 URI를 가짐. 자원은 간결하고 명확하게 식별되어야 합니다.</li></ul><h3>URL 설계 규칙</h3><ul><li>마지막에 / 포함하지 않기:<ul><li>예: <code spellcheck="false">http://api.test.com/users</code></li></ul></li><li>_(underbar) 대신 -(dash) 사용:<ul><li>예: <code spellcheck="false">http://api.test.com/users/post-comments</code></li></ul></li><li>소문자 사용:<ul><li>예: <code spellcheck="false">http://api.test.com/users/post-comments</code></li></ul></li><li>URL에 행위(method) 포함하지 않기:<ul><li>예: DELETE <code spellcheck="false">http://api.test.com/users/1/posts/1</code></li></ul></li><li>컨트롤 자원을 의미하는 URL에는 동사 허용:<ul><li>예: <code spellcheck="false">http://api.test.com/posts/duplicate</code></li></ul></li></ul><hr><h2>Restful API 설계 모범 사례</h2><img src="https://image.until.blog/thingk0/article/1718791191412" data-width="100%" data-align="center" alt="until-599"><img src="https://image.until.blog/thingk0/article/1718791228436" data-width="100%" data-align="center" alt="until-600"><img src="https://image.until.blog/thingk0/article/1718791344586" data-width="100%" data-align="center" alt="until-601"><img src="https://image.until.blog/thingk0/article/1718791581052" data-width="100%" data-align="center" alt="until-602"><img src="https://image.until.blog/thingk0/article/1718791600715" data-width="100%" data-align="center" alt="until-603"><img src="https://image.until.blog/thingk0/article/1718791633327" data-width="100%" data-align="center" alt="until-604"><img src="https://image.until.blog/thingk0/article/1718791656507" data-width="100%" data-align="center" alt="until-605"><img src="https://image.until.blog/thingk0/article/1718791687549" data-width="100%" data-align="center" alt="until-606"><h3>추가적인 PathVariable 및 QueryString 사용 예시</h3><img src="https://image.until.blog/thingk0/article/1718791707307" data-width="100%" data-align="center" alt="until-607"><h3>PathVariable과 QueryString</h3><hr><h3>PathVariable</h3><ul><li>정의: <code spellcheck="false">PathVariable</code>은 URL의 경로에 포함되는 변수를 의미합니다. 일반적으로 리소스의 식별자나 주요 속성을 나타내는 데 사용됩니다.</li><li>적합한 상황:<ul><li>특정 리소스 식별: 특정 리소스에 직접 접근할 때 사용합니다. 예를 들어, <code spellcheck="false">/users/{id}</code>에서 <code spellcheck="false">{id}</code>는 특정 사용자의 고유 식별자</li></ul></li></ul>입니다.<ul><li>리소스 계층 표현: 부모-자식 관계나 계층적 구조를 표현할 때 유용합니다. 예: <code spellcheck="false">/users/{id}/posts</code>는 특정 사용자의 모든 포스트를 나타냅니다.</li><li>장점:<ul><li>URL 경로의 일부로서 직관적이고 명확하게 특정 리소스를 지목합니다.</li><li>계층적이고 구조적인 URL을 만들 수 있어 API의 가독성이 향상됩니다.</li></ul></li></ul><h3>QueryString</h3><ul><li>정의: <code spellcheck="false">QueryString</code>은 URL의 <code spellcheck="false">?</code> 뒤에 오는 키-값 쌍의 집합입니다. 주로 옵션, 필터링, 정렬 또는 검색 조건 등을 지정하는 데 사용됩니다.</li><li>적합한 상황:<ul><li>데이터 필터링: 특정 기준에 따라 데이터를 필터링할 때 사용합니다. 예: <code spellcheck="false">/products?category=books&amp;price_below=20</code></li><li>정보 정렬: 데이터를 특정 순서로 정렬해야 할 때 사용합니다. 예: <code spellcheck="false">/posts?sort_by=date&amp;order=asc</code></li><li>검색 조건 적용: 키워드나 다양한 파라미터로 데이터를 검색할 때 유용합니다. 예: <code spellcheck="false">/users?name=John</code></li></ul></li><li>장점:<ul><li>URL 경로가 아닌 파라미터를 통해 유연한 데이터 조작과 검색을 할 수 있습니다.</li><li>다양한 파라미터 조합을 통해 복잡한 쿼리와 데이터 요청을 간편하게 처리할 수 있습니다.</li></ul></li></ul><hr><h2>2. HTTP 동사 활용</h2>HTTP 프로토콜은 다양한 동사(메서드)를 제공합니다. RESTful API 설계에서는 이러한 동사를 적절하게 활용하여 API의 의도를 명확하게 전달해야 합니다.<ul><li><code spellcheck="false">GET</code>: 리소스의 정보를 조회하기 위해 사용합니다.</li><li><code spellcheck="false">POST</code>: 리소스를 생성하기 위해 사용합니다.</li><li><code spellcheck="false">PUT</code>: 리소스의 정보를 업데이트하기 위해 사용합니다.</li><li><code spellcheck="false">DELETE</code>: 리소스를 삭제하기 위해 사용합니다.</li><li><code spellcheck="false">PATCH</code>: 리소스의 일부분을 업데이트하기 위해 사용합니다.</li></ul><hr><h2>3. 적절한 상태 코드 반환</h2>HTTP 상태 코드는 API의 응답에 포함되어 클라이언트에게 작업 결과를 알려줍니다. RESTful API 설계에서는 적절한 상태 코드를 반환하여 클라이언트가 요청에 대해 올바르게 대응할 수 있도록 해야 합니다. 일반적으로 사용되는 몇 가지 상태 코드는 다음과 같습니다:<ul><li>200 OK: 성공적인 GET, PUT, PATCH 요청.</li><li>201 Created: 성공적인 POST 요청.</li><li>204 No Content: 성공적인 DELETE 요청.</li><li>400 Bad Request: 잘못된 요청 형식.</li><li>401 Unauthorized: 인증되지 않은 접근.</li><li>403 Forbidden: 권한 없는 접근.</li><li>404 Not Found: 요청한 리소스가 없음.</li><li>500 Internal Server Error: 서버 내부 오류.</li></ul><hr><h2>4. 적절한 데이터 포맷</h2>모든 요청과 응답은 JSON 형태로 주고받습니다.<ul><li>예시 요청/응답 데이터 포맷:<ul><li>요청: <code spellcheck="false">{ "title": "The Great Gatsby" }</code></li><li>응답: <code spellcheck="false">{ "id": 3, "title": "The Great Gatsby" }</code></li></ul></li></ul><hr><h2>5. 적절한 인증과 권한 부여</h2>인증 방식은 API 키, OAuth, JWT 등을 활용합니다.<ul><li>모든 API 요청은 적절한 인증 토큰과 함께 전송되어야 합니다.</li></ul><hr><h3>참고문헌</h3><ul><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://velog.io/@tiger/API-RESTful-API">https://velog.io/@tiger/API-RESTful-API</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://library.gabia.com/contents/8339/">https://library.gabia.com/contents/8339/</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://medium.com/tech-pentasecurity/restful-api-%EB%84%A4%EC%9D%B4%EB%B0%8D-7c81bdb9da63">https://medium.com/tech-pentasecurity/restful-api-네이밍-7c81bdb9da63</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://velog.io/@gun_123/RESTful-API-%EC%84%A4%EA%B3%84-%EC%9B%90%EC%B9%99%EA%B3%BC-%EC%98%88%EC%8B%9C">https://velog.io/@gun_123/RESTful-API-설계-원칙과-예시</a></li></ul>

원래 혼자서만 몰래 보려고 만든 문서였지만, 다른 사람들에게도 도움이 되고자 그동안 제가 나름대로 정리해서 만든 RESTful API 설계 규칙입니다!!

내가 쓰려고 만든 RestfulAPI 설계 규칙 !

요즘 같이 신입들이 설 자리가 굉장히 없는 각박한 시기에, 얼마 전 운이 좋게 신입으로 게임 회사에 면접을 보게 되었습니다 🤣🤣🤣그런데 면접 중 다음과 같은 질문을 받을 수 있었는데, ‘포트폴리오를 확인해 보면 스프링 부트를 주로 사용해 왔는데, 스프링 부트는 보통 내장되어 있는 웹 서버로 Tomcat을 사용하는데도 불구하고 Nginx를 사용한 이유가 있을까요?’이러한 질문을 주셨는데 당시 많이 긴장되어 있는 상황이기도 하였고, 당장 생각나는 것은"저희가 프로젝트 환경상, EC2 한 대에서 프론트엔드와 백엔드를 함께 배포해야 하는 상황이었습니다. 따라서 하나의 도메인으로 모든 요청과 응답이 이루어지는데, 요청이 들어올 때 리버스 프록시 기능을 사용하기 위해 Nginx가 필요하기도 하였고, 보안적인 측면에서도 HTTPS를 사용해야 하기 때문에 Nginx를 사용했습니다."지금은 글로 작성하니까 나름 그럴싸하게 작성했지만, 실제로 대답할 때는 조금 어색하게 표현한 것 같아 후회가 듭니다.😅면접을 볼 때에는 당장 생각나는 것이 이것밖에 없었지만, 뒤늦게 면접관님의 의도를 떠올릴 수 있었습니다. 아마도 Nginx를 사용한 이유, 즉 웹 서버(WS)와 웹 애플리케이션 서버(WAS)의 차이점을 분명하게 이해하고 사용한 것인지를 물어보려고 하셨던 게 아닐까 하는 생각이 들었습니다.그래서 이제는 비슷한 질문을 받더라도 더 이상 실수하지 않게 다시 한 번 학습하고 리마인드를 해보려고 합니다.<hr>웹 서버(Web Server)는 웹 클라이언트(예: 웹 브라우저)로부터 HTTP 요청을 받아 정적 콘텐츠(HTML, CSS, JavaScript, 이미지 등)를 제공하는 소프트웨어입니다.<h2>웹 서버의 주요 역할</h2><h3>주요 기능</h3><ol><li>정적 콘텐츠 제공:<ul><li>HTML, CSS, JavaScript 파일 및 이미지 등과 같은 정적 파일을 클라이언트에 제공합니다. Q. 프론트엔드, 백엔드가 구분되어 사용되는 것이 보통입니다. HTML, CSS, JS 파일은 웹 서버에서 언제 어떤 상황에서 클라이언트에게 제공되는가 ? <ul><li>상황: 사용자가 웹 브라우저를 통해 특정 웹 페이지를 요청하는 경우<ul><li>사용자가 브라우저에서 <code spellcheck="false">http://example.com</code>을 입력하면, 브라우저는 해당 URL에 대한 HTTP 요청을 웹 서버로 보냅니다.</li><li>웹 서버(ex. Nginx)는 요청된 URL을 기반으로 적절한 파일을 찾아 클라이언트에 반환합니다. 여기서 정적 파일 제공이 이루어집니다.</li><li>예를 들어, Nginx와 같은 웹 서버가 <code spellcheck="false">/usr/share/nginx/html</code> 디렉토리에 웹페이지 파일을 저장하고 있다면, 다음과 같은 과정이 진행됩니다:<ul><li>사용자가 <code spellcheck="false">http://example.com/index.html</code>을 요청합니다.</li><li>웹 서버는 요청된 파일 경로를 확인하고, <code spellcheck="false">/var/www/html/index.html</code> 파일을 찾아 응답으로 반환합니다.</li></ul></li><li>HTML 파일 반환: 웹 서버는 <code spellcheck="false">index.html</code> 파일을 클라이언트(브라우저)에 반환합니다. 브라우저는 HTML 파일을 파싱하여 페이지의 기본 구조를 렌더링합니다.</li><li>CSS와 JavaScript 파일 요청: HTML 파일이 로드되면서, 페이지 내에 포함된 CSS 및 JavaScript 파일에 대한 추가 요청이 발생합니다. 예를 들어, HTML 파일에 다음과 같은 링크가 포함되어 있을 수 있습니다:<pre spellcheck="false"><code class="language-html">&lt;link rel="stylesheet" href="styles.css"&gt;
&lt;script src="app.js"&gt;&lt;/script&gt;</code></pre><ul><li>브라우저는 <code spellcheck="false">styles.css</code>와 <code spellcheck="false">app.js</code> 파일을 추가로 요청합니다.</li><li>웹 서버는 동일한 방식으로 이 파일들을 찾아 클라이언트에 반환합니다. </li></ul></li></ul></li><li>구체적인 예시사용자가 <code spellcheck="false">http://example.com</code>에 접속하면 다음과 같은 요청과 응답 흐름이 발생합니다:<ol><li>브라우저 요청: <code spellcheck="false">GET /index.html</code></li><li>웹 서버 응답: <code spellcheck="false">/var/www/html/index.html</code> 파일 반환</li><li>브라우저 요청: <code spellcheck="false">GET /styles.css</code></li><li>웹 서버 응답: <code spellcheck="false">/var/www/html/styles.css</code> 파일 반환</li><li>브라우저 요청: <code spellcheck="false">GET /app.js</code></li><li>웹 서버 응답: <code spellcheck="false">/var/www/html/app.js</code> 파일 반환 </li></ol></li></ul>이 과정을 통해 사용자는 웹 페이지를 볼 수 있게 되며, CSS로 스타일링된 페이지와 JavaScript로 동작하는 기능을 사용할 수 있게 됩니다. </li></ul></li><li>HTTP 요청 처리 및 응답:<ul><li>클라이언트의 HTTP 요청을 처리하고, 적절한 응답을 생성하여 반환합니다. </li></ul></li><li>URL 매핑 및 라우팅:<ul><li>요청 URL을 기반으로 적절한 파일이나 서비스로 요청을 라우팅합니다. 이는 리버스 프록시의 역할로, 클라이언트의 요청을 받아 적합한 백엔드 서버로 전달하고 결과를 다시 클라이언트에게 반환합니다. </li></ul></li><li>로드 밸런싱:<ul><li>여러 서버 간에 트래픽을 분산시켜 고가용성을 유지하고 성능을 향상시킵니다. </li></ul></li><li>보안 기능:<ul><li>SSL/TLS를 통한 데이터 암호화, IP 필터링, 사용자 인증 등 다양한 보안 기능을 제공합니다.</li></ul></li></ol><h3>웹 서버의 예시</h3><ul><li>Apache HTTP Server:<ul><li>오픈 소스 웹 서버로, 다양한 플랫폼에서 사용되며, 매우 널리 사용됩니다.</li></ul></li><li>Nginx:<ul><li>고성능 웹 서버로, 특히 높은 동시 연결 수를 처리할 수 있어 정적 파일 제공 및 리버스 프록시로 자주 사용됩니다.</li></ul></li></ul><hr>웹 애플리케이션 서버(Web Application Server, WAS)는 웹 서버와는 달리, 동적 콘텐츠를 생성하고 웹 애플리케이션의 비즈니스 로직을 처리하는 소프트웨어입니다. WAS는 클라이언트의 요청을 받아들여 데이터베이스와 상호 작용하고, 그 결과를 동적 웹 페이지 형태로 클라이언트에 반환합니다.<h2>웹 애플리케이션 서버의 주요 역할</h2><ol><li>비즈니스 로직 처리:<ul><li>클라이언트 요청을 처리하는 비즈니스 로직을 실행합니다. 예를 들어, 사용자의 로그인, 상품 검색, 주문 처리 등의 작업을 수행합니다. → 서블릿 기반 </li></ul></li><li>동적 콘텐츠 생성:<ul><li>JSP, 서블릿, EJB 등과 같은 기술을 사용하여 동적인 웹 페이지를 생성합니다. 클라이언트의 요청에 따라 실시간으로 콘텐츠를 생성하여 응답합니다. </li></ul></li><li>데이터베이스 연동:<ul><li>데이터베이스와 상호 작용하여 데이터를 조회, 삽입, 업데이트, 삭제하는 작업을 수행합니다. 이를 통해 클라이언트가 요청한 데이터를 처리하고 반환합니다. </li></ul></li><li>세션 관리:<ul><li>사용자 세션을 관리하여 사용자 상태를 유지하고, 인증 및 권한 부여를 처리합니다. 이를 통해 사용자의 로그인 상태를 유지하거나, 사용자별로 다른 콘텐츠를 제공할 수 있습니다. </li></ul></li><li>트랜잭션 관리:<ul><li>데이터베이스 트랜잭션을 관리하여 데이터의 일관성과 무결성을 보장합니다. 여러 작업이 하나의 트랜잭션으로 묶여 일관성 있게 처리되도록 합니다. </li></ul></li></ol><h3>웹 애플리케이션 서버의 예시</h3><ul><li>Apache Tomcat:<ul><li>오픈 소스 서블릿 컨테이너로, 서블릿과 JSP 기반의 웹 애플리케이션을 실행합니다.</li></ul></li></ul><hr><h2>정리</h2><img src="https://image.until.blog/thingk0/article/1716860951310" alt="until-318"><h3>이유 1: 정적 콘텐츠 제공</h3><ul><li>Nginx는 정적 콘텐츠(예: 이미지, CSS, JavaScript 파일 등)를 매우 효율적으로 제공할 수 있습니다. 이를 통해 스프링 부트 애플리케이션이 정적 리소스를 제공하는 부담을 줄이고, 동적 콘텐츠 제공에 집중할 수 있게 합니다.<blockquote>하지만, 보통 프론트엔드와 API 서버 조합으로 많이 사용하기 때문에, 사실상 정적 콘텐츠 제공에는 큰 메리트를 느끼기 어려웠습니다. 그러나 프론트엔드가 SPA일 경우에는 매우 유용하다고 생각합니다.</blockquote></li></ul><h3>이유 2: 리버스 프록시</h3><ul><li>리버스 프록시로서 Nginx는 클라이언트 요청을 스프링 부트 애플리케이션으로 전달합니다. 이를 통해 애플리케이션 서버를 보호하고, 로드 밸런싱 및 SSL 종료(SSL termination) 등의 기능을 제공합니다.<blockquote>실제로 제가 Nginx를 사용하는 가장 주된 이유는, 보통 프로젝트를 진행할 때 서버 인스턴스를 하나만 사용할 수 있는 상황이 많아서, 어쩔 수 없이 서버 안에서 프론트엔드, 인프라, 백엔드를 모두 배포해야 했기 때문입니다.이러한 이유로 Nginx의 리버스 프록시 기능은 매우 유용하고 필요했습니다. 그래서 다행히도 면접에서 가장 먼저 떠올린 리버스 프록시를 답변할 수 있었습니다 !!</blockquote></li></ul><h3>이유 3: 로드 밸런싱</h3><ul><li>로드 밸런싱을 통해 여러 대의 스프링부트 인스턴스에 트래픽을 분산시킬 수 있습니다. 이를 통해 고가용성과 성능을 향상시킬 수 있습니다.<blockquote>면접 중 로드 밸런싱 관련 질문을 받았고, 당연히 Nginx를 통해 로드 밸런싱이 가능하다는 것은 알고 있었습니다.하지만 더 좋은 답변을 위해서는 추후에 블루-그린 배포를 적용하거나 스케일 아웃을 염두에 두었을 때, 로드 밸런싱 기능이 필요하기 때문에 Nginx가 필요하다는 답변을 떠올리지 못했다는 것이 뒤늦은 후회로 남네요..🥲</blockquote></li></ul><h3>이유 4: SSL/TLS 처리</h3><ul><li>SSL/TLS 처리를 Nginx가 담당함으로써 스프링부트 애플리케이션은 암호화된 트래픽을 직접 처리하지 않아도 되므로, 성능과 보안 측면에서 유리합니다.</li></ul><h3>이유 5: 보안</h3><ul><li>보안 설정 및 접근 제어를 Nginx 레벨에서 관리함으로써 애플리케이션의 보안성을 향상시킬 수 있습니다. IP 제한, DDoS 방어, WAF(Web Application Firewall) 등을 설정할 수 있습니다.</li></ul><h3>이유 6: 고성능</h3><ul><li>고성능의 Nginx는 적은 리소스로 많은 요청을 처리할 수 있어, 특히 많은 동시 접속이 발생하는 상황에서 유리합니다.<blockquote>“ Nginx는 비동기 이벤트 기반으로 설계되어, 적은 리소스로도 많은 수의 동시 연결을 효율적으로 처리할 수 있고 다중 워커 프로세스를 통해 병렬로 작업을 수행하여 성능을 극대화하며 메모리를 효율적으로 사용하여 더 많은 요청을 처리할 수 있습니다. "라고도 대답할 수 있다면 아마 만점짜리 답변이겠죠..?</blockquote></li></ul><hr>즉, 저는 리버스 프록시와 보안 부분에서는 어느 정도 정답에 가까운 대답을 했다고 생각해요 ! 하지만 기억을 되돌려보면, 로드 밸런싱 부분에 대해서도 잠깐 질문을 받았는데, 급히 다른 질문으로 넘어갔던 것이 아쉽고... Nginx를 통해 로드 밸런싱, 성능, 그리고 정적 콘텐츠 제공에 대해서도 답변을 할 수 있었다면 더 좋았을 것 같아요.다음에 비슷한 질문을 받는다면, 기존 답변에 보완해서 더욱 멋진 답변을 해보도록 하겠습니다. 😃

최근 게임 회사 면접에서 스프링 부트와 Nginx 사용 이유에 대한 질문을 받았습니다. 이번 포스팅에서는 웹 서버와 웹 애플리케이션 서버의 차이를 명확히 이해하고, Nginx 사용 이유를 깊이 있게 다뤄봅니다.

WAS가 있음에도 불구하고, 웹서버인 Nginx 를 사용하는 이유 - 개발자 면접 리마인드

Frontend

<img src="https://image.until.blog/ninefloor/article/1729926668847.jpeg" data-width="100%" data-align="center" alt="1895"><h1><code spellcheck="false">path alias</code>?</h1><img src="https://image.until.blog/ninefloor/article/1729926632812.png" data-width="75%" data-align="center" alt="1894">상대 경로를 이용하면 프로젝트가 커질수록 <code spellcheck="false">../../src</code> 처럼 복잡하여 구조파악이 어렵고 불편하다. 이를 해결하고 개발 경험을 증진시키는 해결 방법으로 대표되는 것이 path alias이다.path alias는 경로에 별칭을 붙인다는 뜻으로, 상대경로로 인해 복잡해지는 import를 간략하게 만드는 방법이다. 보통 모듈 번들러에서 해당 기능을 지원하며, 번들러마다 적용하는 방법이 약간씩 다르지만 맥락은 대부분 비슷하다. TS를 사용하는 경우 추가로 <code spellcheck="false">tsconfig.json</code>에도 작성해주어야 한다.path alias를 적용하면 해당 컴포넌트가 어디에 속해있는지 쉽게 파악할 수 있고 import 역시 편해진다.<blockquote> CRA의 경우 webpack을 사용하는데, webpack config를 따로 정의할 수 없기 때문에 eject하거나 craco와 같은 오버라이딩 라이브러리를 이용해 설정해야 한다.</blockquote><h1>Path Alias with Vite</h1>번들러 중 하나인 Vite에서도 마찬가지로 지원하는데, <code spellcheck="false">vite.config.js</code> 파일에 아래와 같이 작성하면 된다.<pre spellcheck="false"><code class="language-typescript">import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import path from 'path';

// &lt;https://vitejs.dev/config/&gt;
export default defineConfig({
 plugins: [react()],
 resolve: {
	// find: 해당 경로의 이름. 실제로 import문에 적용된다.
	// replacement: 경로 지정. 이때, path.resolve를 이용한다.
 alias: [
 { find: '@', replacement: path.resolve(__dirname, 'src') },
 {
 find: '@components',
 replacement: path.resolve(__dirname, 'src/components'),
 },
 {
 find: '@assets',
 replacement: path.resolve(__dirname, 'src/assets'),
 },
 {
 find: '@page',
 replacement: path.resolve(__dirname, 'src/page'),
 },
 {
 find: '@util',
 replacement: path.resolve(__dirname, 'src/util'),
 },
 {
 find: '@recoil',
 replacement: path.resolve(__dirname, 'src/recoil'),
 },
 ],
 },
});
</code></pre><h3>VScode 자동완성 설정 (w/ JavaScript)</h3>단, 해당 설정을 하고 나면 VSCode는 이를 인지하지 못해 자동완성이 안된다. 이 때는 <code spellcheck="false">jsconfig.json</code>에 아래와 같이 path alias를 정의해주면 정상적으로 자동완성이 동작한다. (TS의 경우 <code spellcheck="false">tsconfig.json</code>)<pre spellcheck="false"><code class="language-jsx">{
 "compilerOptions": {
 "baseUrl": ".",
 "paths": {
 "@/*": ["./src/*"]
 }
 }
}
</code></pre>

쩜쩜슬래시 지옥을 벗어나보자

Path Alias with Vite (+ 자동완성 설정)

백엔드와 관련된 자료들을 올립니다.

🖥 백엔드

잘봤습니다!! 서버 구성이 이쁘네요
혹시 API Gateway 를 사용하지 않은 이유가 궁금합니다! 메시지큐.. 때문인가요?

아주 흥미로운 글이네요 :) 최고!

감사합니다! DB에 로직 빼는게 참 힘들죠.. 저도 api 하나 만들 때마다 레포지토리에 함수 하나씩 생기는 것 같아 가슴이 참 아픈데.. 열심히 고민하고 노력해봅시다

잘봤습니다! DB단에 최대한 로직을 뺴려고 노력하는데 애매한 부분들이 참 많은거같아요

설계할때부터 잘못되었나? 이런 생각도 많이 들더라구요

오.. SpEL에 대해서 알고는 있었지만 잘 몰라서 활용을 잘 못했었거든요 ㅠ 디폴트 값도 조금 야매로 처리를 했었는데 SpEL이 생각보다 좋은 녀석이었군요.. 바로 활용해봐야겠네요!! 잘 읽었습니다 :)

- 뚱땅뚱땅 평화로운(?) 푸시알림 기능 개발 시간 -예약 발송 기능이 필요해 방법을 알아보고 있었다.어찌저찌 구글링을 통해 NestJS Task Scheduling - Dynamic timeouts에 대해 알게 되었다 !스케줄러는 이미 사용해본 경험이 있었는데(매일 @@시 ##분 마다 동작 등), 동적으로 필요에 따라 생성했다 없앴다 할 수도 있었다니 ! (문서를 끝까지 읽어본 적이 없는 사람)사용 방법은 어렵지 않아서 내가 원하는 타이밍에 푸시알림을 발송할 수 있게 되었다. 너무너무 단순하다! <a target="_blank" rel="noopener noreferrer nofollow" href="https://docs.nestjs.com/techniques/task-scheduling#dynamic-timeouts">진짜로</a>즉시 발송과 예약 발송 모두 잘 작동하는 것을 확인하고 필요한 곳 마다(6~7군데 정도) 알림 발송 코드를 때려 박았는데, 막상 이렇게 해놓고 나니 나중에 수정이 필요하거나 또 푸시알림이 필요한 곳이 생기면 같은 작업을 반복해야한다고 생각하니 좀 간지가 안나는 것 같아서 정리를 좀 하기로 했다.일단 내가 원하는 것이 무엇인가 정리<ul class="tight" data-tight="true"><li>"특정 상황"에 유저에게 푸시알림을 보내야함 (FCM 사용)</li><li>즉시발송/예약발송</li><li>현재는 6~7가지 상황이 있지만 점점 늘어날 수 있음</li><li>특별한 경우를 제외하고 어드민 페이지에서 푸시알림을 관리하고 싶음<ul class="tight" data-tight="true"><li>발송상황, 발송타이밍, 메시지 내용 관리 / 발송 내역 관리 등</li></ul></li><li>위 내용은 단일 대상에게 자동으로 보내는 알림. 다수에게 보내는 수동 알림은 따로 처리</li></ul>필요한 api 마다 푸시알림을 쏘는 코드를 심는 것 보다는 한 지점(?)에서 처리하고 싶었는데 그러기 위해선 어떤 요청이 들어왔는지 구분하고 푸시알림이 필요한 요청 및 상황인지 판단, 알맞은 대상 및 내용 구성을 할 수 있어야 했다.어떤 요청인지("특정 상황")는 요청 end point로 구분할 수 있다.발송 대상은 요청에 jwt 토큰도 있고 앱에서 오는 요청이 아닌 경우(서비스 특성 상 서버가 임베디드와도 통신 중) 식별 가능한 데이터가 함께 담겨 있어 어렵지 않았다.내용 역시 왔다갔다하는 데이터들로 충분히 구성할 수 있다.즉시발송/예약발송은 0초 뒤 발송, n초 뒤 발송 으로 설정이 가능하다.이런 점들을 바탕으로 DB를 꾸려보았다. 푸시알림을 보내길 원하는 상황과 내용을 미리 등록해둘 수 있도록.<pre spellcheck="false"><code class="language-typescript">{
 알림발송상황: "유저가 ~~한 상황";
 endPoint: "/request/endpoint";
 n밀리초뒤발송: 300000;
 푸시알림제목: "이것은";
 푸시알림내용: "name씨에게 보내는 푸시알림";
 내용에들어가는변수이름: ["name"];
 클릭시이동url: "어디어디";
}</code></pre>문제는 한 곳에서 처리하려면 과연 그 한 곳은 어디로 해야 좋을까 였다. 미들웨어, 인터셉터 등 뭔가 이것저것 알긴 아는데 정확한 작동 방식이나 그런 것을 아직 완전히 깨우치지 못한 상태라 GPT씨에게 상담 요청을 했다.위 상황들을 죽 설명하고 어쩌면 좋을지 물어보니 그(?)(그녀?) 역시 미들웨어나 인터셉터에 심을 것을 추천해주었는데, 간단한 테스트와 모든 데이터를 처리한 뒤 응답을 보내기 직전에 푸시알림을 쏘고 싶다는 추가 질문으로 인터셉터를 활용하는 것으로 확정을 지었다.이렇게 내가 원하던 대로 '한 곳' 까지 정해졌다.- 뚱땅뚱땅 코딩 타임 -그렇게 뚱땅뚱땅 코드를 작성해놓고 테스트를 하다보니 문제점들이 발견되었다.<ul class="tight" data-tight="true"><li>n시간 뒤 어떤 사람에게 발송하도록 예약해둔 메시지를 만약 그 사람이 특정 조건을 만족한 경우 예약을 취소해야 함</li><li>예약을 해둔 메시지들이 만약 서버가 재시작되면 스케줄러가 초기화되면서 사라짐</li></ul>여러 고민과 GPT씨와의 상담 끝에 두 가지 문제점 모두 스케줄러와 DB를 함께 활용해 해결할 수 있다는 결론을 내렸다.첫번째 문제는 고유한 예약 번호와 함께 푸시알림 내역을 저장해뒀다가 원하는 상황에 예약을 취소할 수 있도록 했다. 예약을 취소하게 되는 상황은 당장에는 한가지 상황 뿐이라 중앙처리 말고 해당 api에서 하도록 했다.나중에 조금 더 발전시킬 필요가 있을 것 같다.두번째 문제는 발송 상태[발송완료/발송예약/발송취소]를 함께 저장해뒀다가 <a target="_blank" rel="noopener noreferrer nofollow" href="https://docs.nestjs.com/fundamentals/lifecycle-events">OnApplicationBootstrap</a>을 사용해 서버가 재시작될 때 발송예약 상태인 메시지들을 다시 스케줄러에 집어넣어주도록 했다.어차피 발송 내역을 저장하기로 해서 DB도 이미 구성해뒀기 때문에 몇 개의 필드만 더 추가하면서 사건을 해결할 수 있었다.대략적인 형태<pre spellcheck="false"><code class="language-typescript">import { Injectable, OnApplicationBootstrap } from '@nestjs/common';
import { firebaseAdmin } from 'src/config/firebase.config';
import { SchedulerRegistry } from '@nestjs/schedule';
@Injectable()
export class PushMessageService implements OnApplicationBootstrap {
	constructor(private readonly schedulerRegistry: SchedulerRegistry) {}
async onApplicationBootstrap() {
	// 발송예약 상태인 메시지들을 다시 스케줄러에 등록
}

async fcmSendMessage(message, sendAfterMilliSeconds, timeoutName, history) {
	const timeout = setTimeout(async () =&amp;gt; {
		await firebaseAdmin
			.messaging()
			.sendEachForMulticast(message)
			.then((res) =&amp;gt; {
				console.log('success: ', res);
		})
		.catch((err) =&amp;gt; {
			console.log('error: ', err);
		}); 
 	// history(발송내역)를 사용해 에약발송인 경우 발송예약 &amp;amp;gt; 발송완료로 업데이트
 	// ~ code ~
	
 	// 발송한 뒤에 스케줄러에서 삭제
		this.schedulerRegistry.deleteTimeout(timeoutName);
		}, sendAfterMilliSeconds);
	this.schedulerRegistry.addTimeout(timeoutName, timeout);
}

async sendAutoPushMessage(endPoint) {
	// 인터셉터에서 호출해 사용
	// 푸시알림 보낼지 말지 판단 후 내용 구성해 발송 예약
}}</code></pre>이런식으로 구현을 해놓았지만 솔직히 지금도 마음에 썩 들지는 않아서 계속 고민 중이다. 조금 더 깔끔하게 할 수 있을 것 같은데 막 아이디어가 떠오르지는 않아서 다른거 할 거 하면서 계속 지켜보는 중이다..

푸시알림 날리기

Spring

스프링을 처음 학습하는 초보자 분들이 흔히 하는 실수가 있습니다..! 바로 서비스 레이어에서 <code spellcheck="false">@Service</code> 애노테이션과 함께 <code spellcheck="false">@Transactional</code>을 습관적으로 세트로 붙이는 것입니다. 그러면 이것이 잘못된 걸까요? 아닙니다. 당연하게도 서비스 레이어에서는 <code spellcheck="false">@Transactional</code>을 붙여주는 것이 좋습니다.<img src="https://image.until.blog/thingk0/article/1727797045468.jpeg" data-width="75%" data-align="center">대부분의 개발자들은 서비스 클래스에서 DAO 혹은 리포지토리를 사용하여 CRUD와 관련한 로직을 많이 처리합니다. 리포지토리를 통해 실제 DB와 상호 작용하기 때문에 데이터베이스 작업 중 일관성, 안전성, 무결성을 보장해야 하며, 에러 발생 시 자 동 롤백이 필요합니다.만약 <code spellcheck="false">@Transactional</code>이 없다면 여러 문제점이 발생할 수 있으므로 작성해주는 것이 좋습니다.또한 메서드 단위로 일일이 붙여주시는 분들도 계시지만, 클래스 단위에 붙여주면 해당 클래스 내부의 모든 메서드에서 자동으로 트랜잭션 처리를 해주어 편리합니다.<h3>그런데 왜 <code spellcheck="false">@Transactional</code> 어노테이션만 사용했는데 트랜잭션 처리가 자동으로 이루어질까요?</h3><hr>스프링을 JPA와 함께 처음 학습하신 분들은 잘 모를 수 있지만, 사실 JPA는 내부적으로 JDBC를 사용합니다. 순수 JDBC를 사용할 때는 드라이버 클래스를 로드하고, 커넥션을 직접 생성해서 트랜잭션을 시작하고, 커밋하고 하는 등 모든 작업을 개발자가 직접 해주어야 합니다. 하지만 기술이 추상화되고 발전하면서 이를 자동화해주게 되었습니다.예를 들어, 순수 JDBC를 사용하면 아래와 같습니다.<pre spellcheck="false"><code class="language-java">public class MemberRepository {

 private static final String URL = "DATABASE_HOST";
 private static final String USER = "USERNAME";
 private static final String PASSWORD = "PASSWORD";

 public void saveMember(String memberId, String memberName) {

 Connection connection = null;
 PreparedStatement preparedStatement = null;

 try {
 // 1. 드라이버 로드
 Class.forName("com.mysql.cj.jdbc.Driver");
 // 2. 커넥션 생성
 connection = DriverManager.getConnection(URL, USER, PASSWORD);
 // 3. 트랜잭션 시작 (AutoCommit을 false로 설정)
 connection.setAutoCommit(false);

 // 4. SQL 작성 및 준비
 String sql = "INSERT INTO members (member_id, member_name) VALUES (?, ?)";
 preparedStatement = connection.prepareStatement(sql);

 // 5. 파라미터 바인딩
 preparedStatement.setString(1, memberId);
 preparedStatement.setString(2, memberName);

 // 6. SQL 실행
 preparedStatement.executeUpdate();

 // 7. 커밋 (트랜잭션 종료)
 connection.commit();
 System.out.println("회원 저장 성공: " + memberId + ", " + memberName);

 } catch (Exception e) {
 try {
 if (connection != null) {
 // 예외 발생 시 롤백
 connection.rollback();
 System.out.println("롤백 수행: " + e.getMessage());
 }

 } catch (SQLException rollbackEx) {
 System.err.println("롤백 실패: " + rollbackEx.getMessage());
 }

 e.printStackTrace();

 } finally {
 // 8. 리소스 정리 (Connection, PreparedStatement 닫기)
 try {
 if (preparedStatement != null) {
 preparedStatement.close();
 }

 if (connection != null) {
 connection.close();
 }

 } catch (SQLException closeEx) {
 System.err.println("자원 해제 실패: " + closeEx.getMessage());
 }
 }
 }
}</code></pre>위 코드는 다음과 같은 순서로 진행됩니다.1. 드라이버 로드<ul><li>JDBC 드라이버를 로드하여 MySQL과 같은 DBMS와 연결할 수 있도록 합니다.<ul><li><code spellcheck="false">Class.forName("com.mysql.cj.jdbc.Driver")</code>를 통해 JDBC 드라이버 클래스를 명시적으로 로드합니다.</li></ul></li></ul>2. 커넥션 생성<ul><li><code spellcheck="false">DriverManager.getConnection()</code>을 사용하여 데이터베이스와의 연결(`Connection`)을 만듭니다.<ul><li>이때 DB URL, 사용자 이름, 비밀번호를 사용합니다.</li></ul></li></ul>3. 트랜잭션 시작<ul><li><code spellcheck="false">connection.setAutoCommit(false)</code>를 사용하여 트랜잭션을 수동으로 제어합니다.<ul><li>기본적으로 JDBC는 AutoCommit 모드이기 때문에, 이 설정을 끄면 트랜잭션을 개발자가 직접 커밋하거나 롤백할 수 있습니다.</li></ul></li></ul>4. SQL 작성 및 실행<ul><li><code spellcheck="false">PreparedStatement</code>를 사용하여 SQL 쿼리를 준비합니다.<ul><li>쿼리에 바인딩할 파라미터(`memberId`, `memberName`)를 설정하고 <code spellcheck="false">executeUpdate()</code>로 쿼리를 실행합니다.</li></ul></li></ul>5. 커밋 및 롤백<ul><li>작업이 정상적으로 완료되면 <code spellcheck="false">connection.commit()</code>을 호출하여 트랜잭션을 커밋합니다.</li><li>오류가 발생하면 <code spellcheck="false">catch</code> 블록에서 <code spellcheck="false">connection.rollback()</code>을 호출하여 롤백합니다.</li></ul>6. 리소스 정리<ul><li>JDBC를 사용할 때는 <code spellcheck="false">Connection</code>과 <code spellcheck="false">PreparedStatement</code>를 반드시 <code spellcheck="false">close()</code>로 닫아줘야 합니다.<ul><li><code spellcheck="false">finally</code> 블록에서 예외와 상관없이 자원을 정리합니다.</li></ul></li></ul><h3>회원 저장 한 번 하는데 너무 복잡합니다 !</h3><hr><img src="https://image.until.blog/thingk0/article/1727797173729.jpeg" data-width="75%" data-align="center">순수 JDBC를 사용하면 아래와 같은 단점들을 쉽게 눈치챌 수 있습니다.- 반복되는 코드: 커넥션을 생성하고, 쿼리를 실행하며, 예외 처리 및 리소스를 정리하는 코드가 반복적으로 등장합니다. 이는 코드의 중복을 야기하고 유지보수가 어렵습니다.- 직접적인 트랜잭션 관리: 트랜잭션을 수동으로 관리해야 하므로, 실수로 <code spellcheck="false">commit()</code>을 호출하지 않거나 <code spellcheck="false">rollback()</code>을 누락할 위험이 있습니다.- 리소스 관리: 커넥션과 같은 자원을 명시적으로 닫아야 하므로, 실수로 리소스를 닫지 않으면 메모리 누수나 DB 커넥션 풀 고갈 같은 문제가 발생할 수 있습니다.개발자들은 불필요한 반복과 중복을 싫어합니다. 중요한 것은 주요 비즈니스 로직이지, 드라이버를 로드하고 커넥션을 얻고, 직접 트랜잭션을 열고 닫고 예외 처리까지 하는 복잡하고 반복적인 작업이 아닙니다. 그래서 하나씩 불필요한 부분을 제거해보겠습니다 🔥<h2>1. <code spellcheck="false">try-with-resources</code>로 리소스 정리</h2><hr>자바 7부터는 <code spellcheck="false">try-with-resources</code> 구문을 제공하여 <code spellcheck="false">AutoCloseable</code> 인터페이스를 구현한 자원들을 자동으로 닫아줍니다.<pre spellcheck="false"><code class="language-java">import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.SQLException;

public class MemberRepository {

 private static final String URL = "DATABASE_HOST";
 private static final String USER = "USERNAME";
 private static final String PASSWORD = "PASSWORD";

 public void saveMember(String memberId, String memberName) {
 // 1. 드라이버 로드
 try {
 Class.forName("com.mysql.cj.jdbc.Driver");
 } catch (ClassNotFoundException e) {
 throw new IllegalStateException("JDBC 드라이버 로드 실패", e);
 }

 // 2. try-with-resources 구문을 사용해 Connection과 PreparedStatement를 자동으로 닫음
 try (
 Connection connection = DriverManager.getConnection(URL, USER, PASSWORD);
 PreparedStatement preparedStatement = connection.prepareStatement(
 "INSERT INTO members (member_id, member_name) VALUES (?, ?)")
 ) {
 // 3. 트랜잭션 시작 (AutoCommit을 false로 설정)
 connection.setAutoCommit(false);

 // 4. 파라미터 바인딩
 preparedStatement.setString(1, memberId);
 preparedStatement.setString(2, memberName);

 // 5. SQL 실행
 preparedStatement.executeUpdate();

 // 6. 커밋 (트랜잭션 종료)
 connection.commit();

 System.out.println("회원 저장 성공: " + memberId + ", " + memberName);
 } catch (SQLException e) {
 // 예외 처리 및 오류 메시지 출력
 e.printStackTrace();
 System.err.println("회원 저장 실패: " + e.getMessage());
 }
 }
}</code></pre><ul><li><code spellcheck="false">Connection</code>과 <code spellcheck="false">PreparedStatement</code>는 이제 <code spellcheck="false">try</code> 블록 안에서 선언되었으며, 자동으로 자원 해제가 이루어집니다.</li></ul>-&gt; 더 이상 <code spellcheck="false">finally</code> 블록에서 수동으로 <code spellcheck="false">close()</code>를 호출할 필요가 없습니다.<h2>2. 드라이버 로드 자동화</h2><hr>JDBC 4.0 이상부터는 드라이버를 명시적으로 로드하지 않아도 됩니다.<pre spellcheck="false"><code class="language-java">import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.SQLException;

public class MemberRepository {

 private static final String URL = "DATABASE_HOST";
 private static final String USER = "USERNAME";
 private static final String PASSWORD = "PASSWORD";

 public void saveMember(String memberId, String memberName) {
 // try-with-resources 구문을 사용해 Connection과 PreparedStatement를 자동으로 닫음
 try (
 Connection connection = DriverManager.getConnection(URL, USER, PASSWORD);
 PreparedStatement preparedStatement = connection.prepareStatement(
 "INSERT INTO members (member_id, member_name) VALUES (?, ?)")
 ) {
 // 트랜잭션 시작 (AutoCommit을 false로 설정)
 connection.setAutoCommit(false);

 // 파라미터 바인딩
 preparedStatement.setString(1, memberId);
 preparedStatement.setString(2, memberName);

 // SQL 실행
 preparedStatement.executeUpdate();

 // 커밋 (트랜잭션 종료)
 connection.commit();

 System.out.println("회원 저장 성공: " + memberId + ", " + memberName);
 } catch (SQLException e) {
 // 예외 처리 및 오류 메시지 출력
 e.printStackTrace();
 System.err.println("회원 저장 실패: " + e.getMessage());
 }
 }
}</code></pre><ul><li>드라이버 로드 부분 삭제: <code spellcheck="false">Class.forName("com.mysql.cj.jdbc.Driver")</code> 코드를 제거했습니다.</li></ul><h2>3. 트랜잭션 관리 자동화</h2><hr>이제 트랜잭션 시작과 종료 부분만 제외하면 딱입니다. 바로 여기에서 스프링의 <code spellcheck="false">@Transactional</code>이 등장합니다.<img src="https://image.until.blog/thingk0/article/1727797214371.jpeg" data-width="75%" data-align="center"><h3><code spellcheck="false">@Transactional </code>은 어떻게 트랜잭션을 자동으로 관리할까?</h3>스프링의 <code spellcheck="false">@Transactional</code> 애노테이션은 AOP(Aspect-Oriented Programming)와 프록시 패턴을 기반으로 동작합니다. 이를 통해 개발자는 트랜잭션 관리에 대한 코드를 직접 작성하지 않아도 됩니다.<blockquote>AOP(관점 지향 프로그래밍): 핵심 비즈니스 로직과 부가적인 관심사를 분리하여 모듈화하는 프로그래밍 패러다임입니다. 예를 들어, 로깅, 보안, 트랜잭션 관리 등의 공통 기능을 비즈니스 로직과 분리할 수 있습니다.</blockquote><blockquote>프록시 패턴: 어떤 객체에 대한 접근을 제어하기 위해 그 객체의 대리자나 대리인을 제공하는 디자인 패턴입니다.</blockquote><h3><code spellcheck="false">@Transactional</code>의 동작 과정</h3>1. 프록시 생성<ul><li>스프링은 <code spellcheck="false">@Transactional</code> 애노테이션이 붙은 클래스나 메서드를 감지합니다. 이를 위해 스프링은 해당 클래스의 프록시 객체를 생성합니다.</li></ul>2. 메서드 호출 가로채기<ul><li>클라이언트가 <code spellcheck="false">@Transactional</code>이 적용된 메서드를 호출할 때, 실제 객체 대신 프록시 객체가 메서드 호출을 가로챕니다.</li></ul>3. 트랜잭션 시작<ul><li>프록시는 트랜잭션 매니저를 통해 트랜잭션을 시작합니다. 이때 데이터베이스 연결의 <code spellcheck="false">AutoCommit</code>을 <code spellcheck="false">false</code>로 설정하여 수동으로 트랜잭션을 제어합니다.</li></ul>4. 비즈니스 로직 실행<ul><li>트랜잭션이 시작된 상태에서 실제 비즈니스 로직이 실행됩니다.</li></ul>5. 트랜잭션 커밋 또는 롤백<ul><li>비즈니스 로직이 정상적으로 완료되면 프록시는 트랜잭션을 커밋합니다.</li><li>예외가 발생하면 프록시는 트랜잭션을 롤백합니다.</li></ul>6. 리소스 정리<ul><li>트랜잭션이 완료되면, 스프링은 사용된 자원들을 자동으로 정리합니다.</li></ul><h3>기존 코드에서 <code spellcheck="false">@Transactional</code> 적용하기</h3>이제 기존의 코드를 스프링의 <code spellcheck="false">@Transactional</code>을 사용하여 더욱 간단하게 바꿔보겠습니다.<pre spellcheck="false"><code class="language-java">import org.springframework.stereotype.Repository;
import org.springframework.transaction.annotation.Transactional;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.SQLException;

@Repository
public class MemberRepository {

 private static final String URL = "DATABASE_HOST";
 private static final String USER = "USERNAME";
 private static final String PASSWORD = "PASSWORD";

 @Transactional
 public void saveMember(String memberId, String memberName) {
 try (
 Connection connection = DriverManager.getConnection(URL, USER, PASSWORD);
 PreparedStatement preparedStatement = connection.prepareStatement(
 "INSERT INTO members (member_id, member_name) VALUES (?, ?)")
 ) {
 // 파라미터 바인딩
 preparedStatement.setString(1, memberId);
 preparedStatement.setString(2, memberName);

 // SQL 실행
 preparedStatement.executeUpdate();
 System.out.println("회원 저장 성공: " + memberId + ", " + memberName);

 } catch (SQLException e) {
 ...
 }
 }
}</code></pre>1. 트랜잭션 관리 코드 제거<ul><li>기존 코드에서 수동으로 처리하던 <code spellcheck="false">connection.setAutoCommit(false)</code>와 <code spellcheck="false">connection.commit()</code> 부분이 제거되었습니다.<ul><li>스프링이 자동으로 트랜잭션을 관리해주기 때문에, 개발자는 이런 저수준 트랜잭션 관리를 신경 쓸 필요가 없습니다.</li></ul></li></ul>2. `@Transactional` 사용<ul><li><code spellcheck="false">@Transactional</code> 애노테이션을 추가하여 메서드 전체를 트랜잭션 관리 대상으로 지정했습니다.<ul><li>스프링은 이 애노테이션을 보고 해당 메서드를 호출할 때 트랜잭션을 시작하고, 종료 시점에 자동으로 커밋하거나 롤백합니다.</li></ul></li></ul>3. 프록시를 통한 자동화<ul><li>프록시 객체가 <code spellcheck="false">saveMember()</code> 메서드를 감싸고 있으며, 클라이언트가 이 메서드를 호출하면 스프링 프록시가 트랜잭션을 시작하고, 예외 발생 시 자동으로 롤백합니다.</li></ul><hr><h2>결론</h2>이번 포스트를 작성하면서 저도 JDBC, 트랜잭션, AOP에 대해 다시 한 번 복습할 수 있었습니다. 물론, 모든 것을 세세하게 외워야 한다는 의미는 아닙니다. 이 부분들은 이미 충분히 자동화된 검증된 기술이기 때문에, 중요한 것은 트랜잭션의 중요성과 원리를 이해하고, 우리가 이를 사용할 때 어떤 원리로 동작하는지 감각적으로 파악하는 것입니다 :)특히, AOP를 통해 핵심 로직과 공통 관심사를 분리하는 방식은 개발 생산성을 크게 높여줍니다. 오늘의 핵심은, 트랜잭션 관리가 AOP 기반으로 이루어지며, 이를 통해 우리는 비즈니스 로직에만 집중할 수 있는 환경을 제공받고 있다는 것입니다. <s>(감사드립니다)</s>저는 개인적으로 AOP를 주로 로직의 시간 측정에 활용하고 있지만, 이 외에도 무궁무진한 가능성이 있는 기술입니다. 부족하지만 제 포스트를 읽어주셔서 정말 감사드리며, 앞으로도 AOP와 관련된 더 깊이 있는 내용을 다룰 예정이니, 많은 기대 부탁드립니다! 😆✨<img src="https://image.until.blog/thingk0/article/1727797410419.gif" data-width="50%" data-align="center">

스프링의 @Transactional을 통해 트랜잭션 관리가 자동화되는 과정을 설명하며, AOP와 프록시 패턴을 활용한 효율적인 트랜잭션 처리의 중요성을 다룹니다.

왜 '@Transactional'은 AOP인가?

📱 Webview

<h1>Problem</h1>웹뷰를 작업하던 도중 video를 배경으로 사용하는 케이스가 존재해 구현하던 도중... mobile safari에서 poster -&gt; video로 전환되면서 아래와 같이 깜빡거리는 현상이 발생했다.<img src="https://image.until.blog/morethanmin/article/1723285031061" data-width="50%" data-align="center" alt="until-1220">관련해서 이슈를 찾아보았으나 관련된 내용이 많지 않았고, 임시 대응책을 고민해보았다.<h1>background-image 추가하기</h1>아래와 같이 video의 background-image로 poster를 추가해 임시로 대응해줄 수 있었다.<pre spellcheck="false"><code class="language-xml"> &lt;video
 src={video}
 poster={poster}
 style={{ width: 260, height: 200 }}
 autoPlay
 loop
 playsInline
 muted
 css={css`
 // mobile safari에서 poster -&gt; video로 전환 시 깜빡임이 발생해 추가
 overflow: hidden;
 background-image: url(${poster});
 background-position: center;
 background-size: cover;
 `}
 /&gt;</code></pre>placeholder -&gt; video로 전환될 때의 영역을 background image가 채워줌으로서 깜빡임 현상을 임시로 해결해 줄 수 있었다.아래는 결과물이다.<img src="https://image.until.blog/morethanmin/article/1723285046176" data-width="50%" data-align="center" alt="until-1221">

Problem웹뷰를 작업하던 도중 video를 배경으로 사용하는 케이스가 존재해 구현하던 도중... mobile safari에서 poster -&gt; video로 전환되면서 아래와 같이 깜빡거리는 현상이 발생했다.관련해서 이슈를 찾아보았으나 관련된 내용이 많지 않았고, 임시 대응책을 고민해보았다.background-image 추가하기아래와 같이 video

mobile safari에서 video poster가 깜빡이는 이슈

23233

프론트엔드

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

⚛️ React

언틸 서비스 초기에는 회원가입시 프로필 이미지를 oauth에서 제공하는 url을 그대로 저장해 사용했었다. (지금은 따로 s3에 저장하고 있습니다. 🥲)때문에 해당 주소가 유효하지 않게 되면 아래와 같이 엑박이 발생했다.<img src="https://image.until.blog/morethanmin/article/1726644394473.png" alt="until-1368">이런 문제를 해결하기 위해서는 img 태그의 onError를 적절히 사용해주면 된다.상황에 따라 아예 <code spellcheck="false">display:none</code> 을 걸어주거나, 대체 이미지를 보여줄 수도 있다. 언틸에서는 기본 아바타를 보여주는 방식으로 대응했다. 아래는 예시이다.<pre spellcheck="false"><code class="language-typescript">const Avatar = forwardRef&lt;HTMLDivElement, Props&gt;(
 (
 { type = 'user', size, src, loading = false, ...props },
 ref,
 ) =&gt; {
 const [isError, setIsError] = useState(false)

 if (loading)
 return (
 &lt;Skeleton /&gt;
 )

 if (!src || isError) {
 return (
 &lt;div
 ref={ref}
 css={[wrapperStyle, sizeStyle]}
 className={className}
 onClick={onClick}
 {...props}
 &gt;
 &lt;CgUserlane /&gt;
 &lt;/div&gt;
 )
 }

 return (
 &lt;div
 ref={ref}
 css={[wrapperStyle, sizeStyle]}
 {...props}
 &gt;
 &lt;Image src={src} fill alt="avatar" onError={() =&gt; setIsError(true)} /&gt;
 &lt;/div&gt;
 )
 },
)

export default Avatar</code></pre>

언틸 서비스 초기에는 회원가입시 프로필 이미지를 oauth에서 제공하는 url을 그대로 저장해 사용했었다. (지금은 따로 s3에 저장하고 있습니다. 🥲)때문에 해당 주소가 유효하지 않게 되면 아래와 같이 엑박이 발생했다.이런 문제를 해결하기 위해서는 img 태그의 onError를 적절히 사용해주면 된다.상황에 따라 아예 display:none 을 걸어주거

img 태그 에러 대응하기 (이미지를 불러올 수 없을 때)

[자료구조와실습]

<img src="https://image.until.blog/morethanmin/article/1726239900445.gif" data-width="100%" data-align="center" alt="until-1342">언틸의 피드에서는 유저들이 작성한 아티클을 모달의 형태로 볼 수 있는데요.이런 모달 형태는 유저들의 글을 빠르게 전환하며 볼 수 있다는 장점을 가지고 있어요.하지만 React State로 관리되기 때문에 몇가지 단점이 존재했어요. 예를 들어 새로고침시에 보고 있던 게시글이 사라지거나, 브라우저의 history stack을 쌓지 않기 때문에 뒤로가기(history.back)로 닫을 수 없었어요.이런 경험은 데스크탑에서는 그렇다 쳐도 모달이 풀페이지로 나타나는 모바일에서는 뒤로가기를 했을 때 아예 페이지가 닫혀버리는 등 유저 경험이 좋지 않았어요.때문에 Route로 동작하는 Modal로 변경하기로 했어요. 어떤 방식으로 구현했는지 간단하게 공유해볼게요.<h2>ArticleCard</h2>우선 ArticleCard는 기존에는 onClick handler를 통해 isOpen state를 변경해주고 있었는데요. 이것을 next/Link 컴포넌트로 변경해주었어요.<pre spellcheck="false"><code class="language-typescript">import { LinkProps } from 'next/link'
import { useRouter } from 'next/router'
import * as _ArticleCard from 'src/components/ArticleCard'
import { ArticleItem } from 'src/types/article'

type Props = {
 data: ArticleItem
}

export const ArticleCard = ({ data }: Props) =&gt; {
 const router = useRouter()

 const href: LinkProps['href'] = {
 query: {
 ...router.query,
 'article-id': data.articleId,
 },
 }

 const as = `@${data.blog.username}/${data.urlSlug}`

 return (
 &lt;_ArticleCard.Root data={data}&gt;
 &lt;_ArticleCard.Thumbnail shallow href={href} as={as} /&gt;
 &lt;_ArticleCard.AuthorInfo showGroup /&gt;
 &lt;_ArticleCard.ArticleInfo shallow href={href} as={as} /&gt;
 &lt;/_ArticleCard.Root&gt;
 )
}</code></pre><code spellcheck="false">Article.Thumbnail</code> 과 <code spellcheck="false">Article.ArticleInfo</code>가 Link의 props을 대신 받아오고 있습니다.이제 아티클 카드를 클릭하면 next/router는 href에 의해서 <code spellcheck="false">until.blog?article-id=219</code> 로 이동하게 되요.또한 as prop을 통해 article-hash-id를 브라우저 검색창에 노출하지 않고 실제 게시글 상세 route인 것처럼 변경해주었어요.<h2>ArticleDetailDialog</h2>이제 서치파라미터에 등록된 article-id를 읽어와서 모달을 띄워주면 돼요.<pre spellcheck="false"><code class="language-typescript">import { useRouter } from 'next/router'
import { Dialog, useCurrentSize } from 'ui'
import Content from './Content'
import { boxStyle } from './styles'

const ArticleDetailDialog = () =&gt; {
 const router = useRouter()
 const currentSize = useCurrentSize()

 const articleId =
 typeof router.query['article-id'] === 'string' &amp;&amp;
 router.query['article-id'] !== ''
 ? Number(router.query['article-id'])
 : null

 const handleClose = () =&gt; {
 const query = { ...router.query }
 delete query['article-id']

 router.push(
 {
 query,
 },
 undefined,
 { shallow: true, scroll: false },
 )
 }

 return (
 &lt;Dialog
 open={!!articleId}
 onClose={handleClose}
 align="top"
 alignOffset={currentSize === 'desktop' ? 60 : 40}
 css={{
 maxWidth: '920px',
 width: '100%',
 }}
 &gt;
 &lt;div css={boxStyle}&gt;
 &lt;Content articleId={articleId} onClose={handleClose} /&gt;
 &lt;/div&gt;
 &lt;/Dialog&gt;
 )
}

export default ArticleDetailDialog</code></pre>이를 통해 유저는 새로고침을 하더라도 게시글 상세페이지를 유지할 수 있고, 뒤로가기를 통해서도 모달을 닫을 수 있게 되었습니다. 👍

언틸의 피드에서는 유저들이 작성한 아티클을 모달의 형태로 볼 수 있는데요.이런 모달 형태는 유저들의 글을 빠르게 전환하며 볼 수 있다는 장점을 가지고 있어요.하지만 React State로 관리되기 때문에 몇가지 단점이 존재했어요. 예를 들어 새로고침시에 보고 있던 게시글이 사라지거나, 브라우저의 history stack을 쌓지 않기 때문에 뒤로가기(hist