<img src="https://image.until.blog/steady/article/1727700265407.png" alt="until-1670"><h2>어디서 나타났니?</h2><hr>여기다 이런걸 써도 되나 모르겠다만 언틸은 생각보다 꽤나 흥미로웠다.뭔가 글을 적는 재미가 있달까? 그냥 좀 간지가 난달까? 이런 사소한 이유도 있긴하지만 내가 느낀 점을 적어보고 싶었다.나는 개발자로서 기술 블로그를 작성하며 내 가치를 늘려보자라고 생각하며 여기저기 기웃거린 전적이 있다. (until에 대한 정보를 얻은 곳도 기웃대던 곳 중 하나인 Velog 다.)하지만 대체로 정착을 못했는데 다 각각의 변명거리가 있었다.그래서 내가 각 플랫폼에 느낀 느낌을 적어보자면<h2>다른 블로그들은?</h2><hr><h3>Tistory</h3>: 개발에 대한 궁금증을 구글에 검색하다보면 가장 많이 보였던 블로그였다.<ul><li>기술을 제외한 다양한 주제의 글들이 많다.</li><li>진입장벽이 있다. (초기 셋팅을 하지 않으면 작성글이 보기에 썩 좋지 않다.)</li><li>기능이 뭐가 많다. (근데 어떻게 쓰는지 몰라 배워야한다.)</li></ul>그래서 이쁘게 글을 쓰고 싶다보니 글을 열심히 적는게 아니라 여러 설정들을 찾아보고 있는 나를 발견했다.<h3>Velog</h3>: 사이트 분위기가 가벼워 간단하게 글을 쓰기 좋은 느낌의 블로그였다.<ul><li>에디터가 묘하게 불편하다. (글을 작성하는 부분과 미리보기 하는 부분이 2분할 되어있다.)</li><li>잔버그가 있었다. (썸네일 이미지가 본문에 자동으로 추가된다던지...)</li></ul>아무래도 글을 작성하는 부분이 불편하다 보니 자주 안적게 되며 눈팅족이 되어버렸다.<h2>언틸은?</h2><hr><ul><li>그냥 맨바닥에 글을 쓰는데 편하고 스스로 만족스럽게 볼만하다.</li><li>개발자 입장에서 흥미로운 아티클들이 많다.</li><li>우선 깃허브에서 영감을 받은 듯한 잔디심기가 은근 재밌다. (얼른 글을 작성해 색칠하고 싶어진다.)</li><li>아직 사람이 많지 않아서 그런지 최신 아티클에 내 글이 뜨는게 재밌다.</li></ul><h3></h3><h5>진짜 사소한 아쉬운점</h5><ul><li>이미지를 편하게 다루면 좋겠다.(한 행에 2~3개 둔다던지)</li><li>이게 지금 팔로우를 한건지 안한건지 모르겠다.<img src="https://image.until.blog/steady/article/1727702641092.png" alt="until-1674"></li></ul><h5>아무튼 이렇게 마음에 쏙 드는 블로그를 만들어 주신 개발자께 감사드리며.</h5><h2>결론은?</h2><hr><img src="https://image.until.blog/steady/article/1727702304083.png" alt="until-1671"><blockquote>언틸아 아프지 말고 오래오래 건강해야한다~</blockquote>

어디서 나타났니?여기다 이런걸 써도 되나 모르겠다만 언틸은 생각보다 꽤나 흥미로웠다.뭔가 글을 적는 재미가 있달까? 그냥 좀 간지가 난달까? 이런 사소한 이유도 있긴하지만 내가 느낀 점을 적어보고 싶었다.나는 개발자로서 기술 블로그를 작성하며 내 가치를 늘려보자라고 생각하며 여기저기 기웃거린 전적이 있다. (until에 대한 정보를 얻은 곳도 기웃대던 곳 

[Until] 내가 Until을 쓰는 이유

<img src="https://image.until.blog/steady/article/1727781344899.jpeg" data-width="100%" data-align="center"><h2>어디에 쓰이나?</h2><hr>서버를 관리하다 보면 각종 로그나 소스 자체, 데이터베이스를 백업하게 될 일이 생기게 된다.그때 단순히 파일들을 복사해서 둔다면 불필요한 서버 자원을 소비하게 되는데, 그걸 방지하기 위해 파일들을 한데 모으고 압축하여 용량을 줄이는 작업이 필요하다.윈도우에는 알집이나 반디집 등 익숙한 압축 전용 도구들이 있는데, 오늘은 리눅스에서 압축을 처리하는 방식에 대해 정리하려고 한다.<h2>압축 하는 법</h2><hr> 나는 기존에 리눅스에서는 일반적으로 <code spellcheck="false">tar</code> 명령어를 통해 압축을 한다고 알고 있었는데 비슷하지만 내용이 조금 달랐다.<code spellcheck="false">tar</code> 명령어는 여러 파일을 하나로 뭉치기(아카이브)만 할때 사용하는 도구였다. 자체적으로 압축을 하지 않고 압축을 해주는 도구인 gzip, bzip2 와 같이 사용하는 방식이였다.<h3>아카이브</h3><pre spellcheck="false"><code class="language-shell">// 아카이브
tar -cvf archive.tar file1 file2 file3

// 아카이브 해제
tar -xvf archive.tar</code></pre><ul><li>file1, file2, file3를 하나로 묶어 archive.tar 라는 아카이브 파일을 만든다.</li><li>단순히 모아두는 것이기 때문에 용량이 줄어들지는 않는다.</li><li>옵션<ul><li>c : 아카이브 생성, x : 아카이브 해제 (둘 중 하나는 반드시 입력해야 함)</li><li>v : 명령어 수행 중 현재 실행 중인 파일이 출력된다. (없어도 실행에 문제는 없음)</li><li>f : 결과물을 파일로 출력(옵션 뒤에 생성될 파일의 이름을 지정해야 함)</li></ul></li></ul><h3>아카이브 + 압축</h3><pre spellcheck="false"><code class="language-shell">// 아카이브 + gzip 압축
tar -zcvf archive.tar.gz file1 file2 file3

// 아카이브 + bzip2 압축
tar -jcvf archive.tar.bz2 file1 file2 file3

// 아카이브 + xz 압축
tar -Jcvf archive.tar.xz file1 file2 file3</code></pre><ul><li>gzip, bzip2, xz 별로 옵션 값이 다르니 주의해야 한다.</li><li>아카이브 하고 압축까지 진행했기때문에 파일의 용량이 줄어든다.</li><li>옵션<ul><li>z : gzip 을 이용함</li><li>j : bzip2 를 이용함</li><li>J : xz 를 이용함</li></ul></li></ul><h4>주의 </h4>압축 파일을 해제할때 사용했던 도구를 사용해 해제를 해야 문제가 발생하지 않는다.<h2>뭐가 더 좋음?</h2><hr>그래서 위에서 나온 압축 도구들은 서로 뭐가 다를까?<h3>gzip</h3><ul><li>다른 압축 도구들에 비해 속도가 매우 빨라 대용량 파일 처리에 용이하다.</li><li>거의 모든 리눅스와 운영체제에서 호환된다.</li><li>압축률은 적당한 편.</li><li>멀티 스레딩을 지원하지 않아 다중 코어를 사용한다고 해서 빨라지지 않는다.</li></ul><h2>bzip2</h2><ul><li>속도는 gzip에 비해 느린편.</li><li>거의 모든 리눅스와 운영체제에서 호환된다.</li><li>gzip 보다 압축률이 더 좋다.</li><li>멀티 스레딩을 지원하지 않아 다중 코어를 사용한다고 해서 빨라지지 않는다.</li></ul><h2>xz</h2><ul><li>속도는 가장 느린편.</li><li>비교적 최신 포맷이기 때문에 호환되지 않을수도 있다.</li><li>최고의 압축률.</li><li>멀티 스레딩을 지원해 다중 코어 이용시 속도가 개선될 수 있다.</li></ul><h2>정리하자면</h2><hr><blockquote>압축률 : gzip &lt; bzip2 &lt; xz속도 : xz &lt; bzip2 &lt; gzip호환성 : xz &lt; bzip2 &lt; gzip</blockquote>빠른 속도와 적당한 압축률을 원한다면 gzip.속도를 포기하고 최고의 압축률을 원한다면 xz.더 나은 압축률과 호환성이 필요하다면 bzip2.

어디에 쓰이나?서버를 관리하다 보면 각종 로그나 소스 자체, 데이터베이스를 백업하게 될 일이 생기게 된다.그때 단순히 파일들을 복사해서 둔다면 불필요한 서버 자원을 소비하게 되는데, 그걸 방지하기 위해 파일들을 한데 모으고 압축하여 용량을 줄이는 작업이 필요하다.윈도우에는 알집이나 반디집 등 익숙한 압축 전용 도구들이 있는데, 오늘은 리눅스에서 압축을 처리

[Linux] 파일 압축에 대해

올해로 거의 4년째 토스 만보기를 사용 중인 사용자입니다<ol><li>혼자 걷기 만보채우면 100원</li><li>미션 걷기- 친구와 같이 하는거</li><li>5천보 10원, 만보 20원, 친구 총합 3만보 30원, 친구 총합 5만보 40원이었나? 그런거..</li><li>혼자 걷기인데, 천보 5천보 만보단위..? 그리고 어디 미션하는데 도착하면 10원</li><li>아이템 도입</li><li>현재.. 애매하게 한 4개 나뉘어져있음.. 선물 주기/ 만보채우면 아마 최대 40원까지 받을듯?</li></ol>뭐 이런 토스의 만보기 여정을 기억하고 있는 사용자임돠토스 항상 친절한 라이팅과 신경 쓴 사용자 경험 덕에 편안하고 재밌게 사용 중이에요ㅎㅎ근데 요즘! 토스 만보기 좀 섭섭하다~화면이 닫히면 광고가 나와요?????아 조금 섭섭합니다...원래 그냥 받기만 하는거였는데 광고까지 보게 만드네?? 이건 쫌?싶은 그런 경험이에요눈치를 챘는지 다시 사라진거 같기도 한데.. 말이죠..원래 주던 거에 (-)를 추가해서 이렇게 느낀 것 같아요.. 차라리 돈을 줄이고 다르게 광고보고 뭘 얻게끔 추가해주시든지요ㅠ 원래 그냥 주던걸 받았을뿐인데 그 댓가로 뭘해라 시키는거 같아서 좀 섭섭....앞으로도 지켜보겠어요 토스...👀<img src="https://image.until.blog/ssunj/article/1719981889772" alt="until-703">

토스 만보기의 UX에 관하여

Workthrough for prev. projectForm Basics : Controlled Input &amp; UnControlled InputReact &amp; FormsReact-Hook-FormZod + ResolverForm Component &amp; UI Componentfourth project : React-Hook-Form Proj

#4. Form handling in React

<img src="https://image.until.blog/steady/article/1727427951503.jpeg" alt="until-1588"><h2>어디에 쓰이나?</h2><hr>서버 개발을 하다보면 트래픽을 생각하지 않을 수가 없게 된다. 이때 단순 텍스트로 이루어진 데이터들은 크게 문제가 되지 않지만 이미지나 동영상이 끼게 되면 아무래도 복잡해진다. 트래픽은 다 서버 비용을 늘리는 주된 범인이니 해결 방법을 찾아야했다.그래서 우선적으로 이미지의 용량을 줄이는 방법을 생각하게 되었다.<h2>이미지 용량 줄이는 법</h2><hr>이미지의 용량을 줄이는 방법은 크게 두 가지가 있는데<h3>1. 해상도 줄이기</h3>높이와 너비 픽셀 수를 조정하여 이미지의 사이즈 자체를 줄여버리는 방법으로 확장자와 상관없이 사용 가능하고 일정 크기까지는 그렇게 불편하게 보이지는 않는다.<h3>2. 압축률 조정하기</h3>이미지 파일들은 확장자 별로 2가지 방식의 압축 방식을 가지고 있다.손실 압축 (ex. JPG)손실 압축을 사용하는 확장자의 경우에는 압축률을 줄일수록 다양한 색상이나 디테일을 포기하는 대신 용량이 확연히 줄어들게 된다. 하지만 압축률에 따른 이미지가 정말 이상해진다.비손실 압축 (ex. PNG)비손실 압축을 사용하는 확장자의 경우에는 압축률에 따른 이미지 손상이 크게 눈에 띄진 않지만, 용량의 변화가 크지 않다.<h2>어떻게 할까?</h2><hr>내가 개발하는 기능의 경우에는 다양한 확장자의 이미지 파일을 다뤄야 하고 용량을 최대한으로 줄여 트래픽을 줄여야 하는 상황이라 해상도를 줄이는 방법을 선택하기로 했다.(사실 JPG 압축률을 한번 줄여보긴 했는데 압축률을 많이 줄여서 그런지 내 기준으로 못 쓸만한 이미지가 되었다.)<h2>개발 과정</h2><hr>개발 하다 보니 1:1 비율로 이미지를 자르는 기능도 필요해 추가하게 되었다.<pre spellcheck="false"><code class="language-java">public class ImageUtil {

 // POST WEB 통신을 통해 전달받는 데이터 포맷이 MultipartFile 이었다.
 public MultipartFile resizeAndCrop(MultipartFile file, float quality) throws IOException {

 // 원본 이미지 읽기
 BufferedImage originalImage = ImageIO.read(file.getInputStream());

 // 해상도 낮추기(0.0 ~ 1.0 까지의 실수를 받아 얼마나 줄일지를 결정했다.)
 BufferedImage resizeImage = resizeImage(originalImage, quality);

 // 이미지를 1:1 비율로 변환
 BufferedImage croppedImage = cropImage(resizeImage);

 // 이미지를 스트림에 저장
 // ImageIO.write 부분을 변경해 파일을 직접 저장할 수도 있다.
 ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
 ImageIO.write(croppedImage, "jpg", byteArrayOutputStream); // format: "jpg", "png" 등

 // ByteArrayInputStream을 사용하여 MultipartFile로 변환
 ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(byteArrayOutputStream.toByteArray());
 MultipartFile resultFile = new MockMultipartFile(
 file.getName(), // 원본 파일 이름
 file.getOriginalFilename(), // 원본 파일 이름 그대로 사용
 "image/jpeg", // MIME 타입 설정
 byteArrayInputStream // 입력 스트림으로 변환
 );

 // 결과 파일을 반환
 return resultFile;
 }

 // 해상도를 낮추는 메서드
 private BufferedImage resizeImage(BufferedImage originalImage, float quality) {

 // 너비와 높이를 quality 값에 맞는 비율로 조정해 임시 이미지 파일 생성
 int targetWidth = (int)(originalImage.getWidth() * quality);
 int targetHeight = (int)(originalImage.getHeight() * quality);
 BufferedImage resizedImage = new BufferedImage(targetWidth, targetHeight, originalImage.getType());

 // 사이즈에 맞춰 이미지를 실제로 그려낸다.
 Graphics2D g2d = resizedImage.createGraphics();
 g2d.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BILINEAR);
 g2d.drawImage(originalImage, 0, 0, targetWidth, targetHeight, null);
 g2d.dispose();

 return resizedImage;
 }

 // 중앙을 기준으로 1:1 비율로 크롭하는 메서드
 private BufferedImage cropImage(BufferedImage image) {
 int width = image.getWidth();
 int height = image.getHeight();

 // 가로와 세로 중 짧은 쪽으로 1:1 비율 만들기
 int newSize = Math.min(width, height);

 // 중심 좌표 계산
 int x = (width - newSize) / 2;
 int y = (height - newSize) / 2;

 // 중앙을 기준으로 크롭
 return image.getSubimage(x, y, newSize, newSize);
 }
}</code></pre><h2>돌아보며</h2><hr><blockquote>단순한 기능이라 생각했지만 나름 시간을 많이 잡아먹었다.결과적으로 사용은 하진 않았지만, 압축률을 조정해 보며 직접 테스트해 본 건 좋은 경험이었던 것 같다. 이 기억이 남아있다면 다음에는 시간을 절약할 수 있길 바라본다.추가로 곧 동영상도 다루게 될 것 같은데 시간이 된다면 동영상을 다루는 것도 작성해 보도록 하겠다.</blockquote>

어디에 쓰이나?서버 개발을 하다보면 트래픽을 생각하지 않을 수가 없게 된다. 이때 단순 텍스트로 이루어진 데이터들은 크게 문제가 되지 않지만 이미지나 동영상이 끼게 되면 아무래도 복잡해진다. 트래픽은 다 서버 비용을 늘리는 주된 범인이니 해결 방법을 찾아야했다.그래서 우선적으로 이미지의 용량을 줄이는 방법을 생각하게 되었다.이미지 용량 줄이는 법이미지의 용