dev.daisy

데이터베이스 트랜잭션을 깊이 있게 들여다보면서 가장 인상 깊었던 점은, 자칫 복잡하게 얽히기 쉬운 동시성과 장애 복구 로직을 Undo Log와 WAL Log라는 로그 중심의 아키텍처로 깔끔하게 풀어냈다는 사실이었습니다.이전에는 비즈니스 애플리케이션 레벨에서 인프라 다운이나 동시 요청 충돌 같은 예외 상황을 어떻게 방어해야 할지 막막할 때가 많았는데요. 데이터베이스의 하위 레이어에서 ACID 속성을 받쳐주고 있다는 걸 이해하고 나니, 전체 시스템을 설계할 때 더 예측 가능하게 구현할 수 있다는 생각이 들었습니다.물론 모든 정합성 문제를 무조건 최고 등급의 격리 수준으로 해결하는 게 정답은 아닐 것이라고 생각합니다. 데이터의 중요도와 서비스 트래픽 상황을 균형 있게 고려하면서, 성능과 정합성 사이의 트레이드..

React Hook Form을 사용해 직접 구현해보면서 가장 인상 깊었던 부분은, 폼을 구성하는 컴포넌트들이 더 이상 서로의 내부를 알 필요가 없어진다는 점이었습니다. 이전에는 Input 하나를 수정할 때도 상위 폼의 로직이나 상태 구조를 함께 고려해야 했지만, 컨텍스트 기반 구조에서는 각 컴포넌트가 자신의 역할에만 집중할 수 있었습니다. 또한 유효성 검사 로직을 Zod 스키마로 한 곳에 모으면서, “이 폼이 어떤 데이터를 받고 어떤 규칙을 가지는지”를 코드 한 파일에서 명확하게 파악할 수 있게 되었습니다.이 패턴이 모든 폼에 정답은 아닐 수 있지만, 입력 필드가 많고 요구사항 변경이 잦은 폼이라면 충분히 적용해볼 만한 구조라고 느꼈습니다. 단순히 React Hook Form을 사용하는 것을 넘어 의존성..

JavaScript에서 얕은 복사와 깊은 복사를 이해하는 핵심은 결국 참조와 메모리 주소라는 근본적인 개념에 달려있다는 것을 깨달았습니다. 단순히 문법을 외우는 것이 아니라, 객체와 배열이 메모리에 어떻게 저장되는지를 먼저 이해해야만 얕은 복사 시 발생하는 부수 효과의 원인을 명확히 파악할 수 있었습니다. 무엇보다 다루는 객체의 크기와 구조를 고려하여 성능과 안정성 사이에서 현명하게 선택해야 한다는 것을 알게 되었습니다.JavaScript에서 객체와 배열 같은 참조 타입(Reference Type)의 데이터를 다룰 때, 단순히 = 연산자를 사용하거나 복사 기능을 사용할 때 우리가 예상하는 것과 다른 동작을 보일 때가 있습니다. 이 모든 것은 데이터가 저장되는 메모리 주소인 참조(Reference) 때문에..

Frontend Fundamentals에서도 말하듯, 가독성 · 예측 가능성 · 응집도 · 결합도는 네 가지 모두를 완벽하게 충족시키기 어렵습니다. 예를 들어서 응집도를 높이기 위해 추상화를 하면 가독성이 떨어질 수 있고, 결합도를 낮추기 위해 중복을 허용하면 응집도가 떨어질 수 있습니다. 따라서 프론트엔드 개발자는 현재 코드가 어떤 상황에 놓여 있는지 판단하고, 장기적으로 “가장 변경하기 쉬운 구조는 무엇인가?” 를 기준으로 가치들을 조정해야 합니다.정리해보면, 컴포넌트 분리를 고민할 때 흔히 SRP를 떠올리지만, 절대적인 규칙이 아니라 변경하기 쉬운 코드를 만들기 위한 한 가지 도구일 뿐입니다. 프론트엔드 개발에서 더 중요한 것은 원칙 자체가 아니라 원칙을 언제 어떻게 적용할지 결정하는 판단이라는 것..

구름톤 제주는 3박 4일간 제주에서 진행되며 개발자, 디자이너, 기획자가 모여 제주의 문제를 해결하는 해커톤이다. 구름톤 유니브를 처음 접한 대학생 때부터 알고 있었는데, 리프레시가 필요한 상황에 마침 카카오테크 부트캠프 가산점이 있다고 해서 지원하게 되었다. 프론트엔드 지원서 질문으로는 아래와 같이 있었는데, 대부분 300-500자라서 많은 내용을 담기 어려워 핵심적인 내용만 담았다. 작성하는데 약 30-40분 정도 사용했다.사용 가능한 프레임워크/라이브러리(React, Vue 등)를 나열하고, 그중 가장 자신 있는 기술을 하나 골라 이유를 설명해주세요.최근 6개월 내에 가장 많은 시간을 들여 해결했던 기술적 문제를 작성해주세요.현재 관심 있는 프론트엔드 기술이나 개념을 작성해주세요.선호하거나 관심 있..

ENUM 키워드 매핑 실패 문제를 겪고 enum value가 중복될 수 있는 구조라서 prefix를 붙여야겠다는 생각까지는 했지만 이것만으로 문제를 해결할 수 없었습니다. 카테고리별 포맷을 camelCase에서 SNAKE_CASE로 통일해야 했고, 매핑 객체의 key 규칙이 명확하게 정의되지 않은 상태에서는 구조와 포맷이 어긋날 때마다 오류가 반복적으로 발생했습니다. 또한 포맷 불일치로 매핑이 실패할 경우 내부 영문 키가 그대로 노출되는 fallback은 사용자 경험 측면에서도 안좋은 문제라고 생각이 들었습니다.이번 문제를 해결하며 다시 한 번 느낀 점은 “사용자에게 보이는 한 줄의 텍스트도 그 이면에는 데이터 구조, enum 설계, 포맷 규칙 등 전체 시스템이 유기적으로 연결되어 있어야 한다”는 사실입..

ENUM에서 value가 같으면 동일한 의미일 것이라는 가정으로 키워드 매핑 오류가 발생했습니다. 렌더링 단계에서는 value만 보고 매칭하기 때문에 구분이 불가능했고, 이 때문에 UI에 잘못된 정보가 표시되는 UX 문제가 발생했습니다. 이를 해결하기 위해 카테고리 + key 조합을 고유 식별자로 사용하는 방식을 enum 구조에 적용해 문제를 해결했습니다.이번 리팩터링으로 단순히 오류를 해결하는 것을 넘어서, Personality와 PreferredPeople처럼 동일한 key 구조를 가진 다른 enum들에도 확장 가능하도록 전체적인 구조를 정리하는 계기가 되었습니다. 작은 텍스트 하나가 사용자에게는 직접적인 정보이기 때문에 키워드가 어떤 의미를 갖고 어떤 맥락인지 확실히 구분해주는 것이 얼마나 중요한지..

CJS와 ESM은 단순히 문법만 다른 것이 아니라, 로딩 방식, 최적화 가능성, 트리 쉐이킹 여부, 의존성 관리 방식까지 전반적으로 구조가 크게 다르다는 점을 공부하면서 새롭게 느꼈습니다. 특히 ESM은 정적 분석이 가능하기 때문에 번들링 과정에서 더 효율적인 최적화가 이루어진다는 점이 인상적이었습니다. 실제로 프로젝트를 진행하면서 모듈 시스템이 어떻게 코드의 구조를 좌우하는지 체감했고, 전역 스코프가 오염되던 시절과 비교하면 개발 환경이 얼마나 안정적으로 변했는지도 이해할 수 있었습니다.또한 모듈을 어떻게 나누고 어떤 방식으로 가져올지를 설계하는 것이 단순한 파일 분리가 아니라, 전체 애플리케이션의 유지보수성과 확장성에 직결된다는 것을 경험했습니다. 작은 예시 코드에서도 export 방식 하나 바꾸는 ..

JavaScript 함수에 관련된 개념을 공부하면서 익숙하게 사용하던 함수들이 서로 구체적인 차이와 목적을 가지고 있다는 점을 다시 확인할 수 있었습니다. 특히 개발하면서 자주 사용하는 JavaScript에서 함수가 일급 객체로 취급된다는 사실이 고차 함수, 콜백, 함수 조합 같은 패턴을 가능하게 한다는 구조적 특징이라는 점이 가장 인상깊었습니다. 코드 작성 방식이 프로그램 전체의 안정성과 복잡도에 어떻게 기여하는지 다시 생각해 볼 수 있는 시간이었습니다.1) 함수(Function)정의함수는 특정 입력을 받아 내부 로직을 통해 결과를 계산한 뒤 반환하는 실행 단위입니다. 프로그램의 연산을 독립된 블록으로 구성해 재사용할 수 있는 구조를 제공하며, 동일한 로직을 여러 곳에서 호출할 수 있도록 단일 책임 단..

네이버 컨퍼런스에 참여해보았는데, 다른 컨퍼런스와 비교해 보고 즐길 거리가 많아 재밌었습니다! 특히 단순 홍보용 부스 뿐만 아니라 채용 상담회나 실제 현업 개발자분들과 네트워킹을 할 수 있는 공간이 있는 구조로 운영된 점이 인상깊었습니다.평소에 쉽게 접할 수 없었던 네이버 내부 서비스의 구조나 개발 철학을 가까이서 듣고 볼 수 있었고, 스스로 동기부여가 많이 되는 시간이였습니다. 단순히 구경하는 컨퍼런스가 아니라 참여하면서 배우고 고민할 수 있는 경험이였다는 점에서 의미 있는 시간이였습니다 :) 지난주 우아콘에 이어 DAN25에 참여하려 코엑스를 방문했습니다! 부스나 이벤트 개수가 타 컨퍼런스에 비해서 4-5배 많았고, 굿즈도 거의 사진의 2배는 받아 가방 무겁게 집에 갈 수 있었습니다. 규모도 크고 ..