들어가며처음 이 프로젝트의 출발점은 개인용 오픈클로우를 만들어보자는 생각이었습니다. 반복해서 처리하는 일을 대신 정리해주고, 필요한 정보를 찾아오며, 개발 작업의 흐름을 잡아주고,문서와 코드까지 함께 다뤄주는 개인 비서에 가까운 시스템을 상상했습니다. 처음부터 거창한 구조를 생각했던 것은 아닙니다. 매번 반복하는 일을 조금 줄이고,흩어진 작업을 한곳으로 모으며, 필요할 때 바로 꺼내 쓸 수 있는 자동화 도구를 만들고 싶었습니다. 오픈클로우처럼 Claude를 내 작업 환경에 연결해보고 싶다는 생각은 Claude Code를 직접 사용하면서더 구체적인 문제의식으로 이어졌습니다. Claude Code는 생각보다 많은 일을 해냈습니다. 코드를 읽고, 구조를 파악하고,수정 방향을 제안하며, 실제 구현까지 이어가는 ..

JavaScript는 프론트엔드를 공부할 때 결국 한 번은 반드시 마주하게 되는 언어입니다. 하지만 지금의 저는 이 언어를 깊이 있게 파고들기보다는, 필요한 만큼 이해하고 다음 단계로 넘어가는 쪽에 더 무게를 두고 있습니다.애초에 JavaScript는 제 메인 언어가 아니기도 하고, 현재 목표 역시 프론트엔드 자체를 주력으로 삼는 것이 아니라 기본적인 화면 구조와 동작 방식을 이해하는 데 있기 때문입니다.그래서 이번 학습에서는 문법 하나하나를 깊게 붙잡고 오래 머무르기보다는, 아주 기초적인 개념과 핵심 문법을 먼저 가볍게 익히는 방향으로 접근하려고 했습니다.지금 필요한 것은 JavaScript를 완전히 정복하는 것이 아니라, 코드를 읽었을 때 흐름이 보이고, 간단한 구현을 따라가면서도 막히지 않을 정도의..

Front Sandbox는 클라이언트와의 원활한 협업을 위해 프론트엔드 기본 역량을 학습하고 정리하는 레포지토리입니다. 주력 분야는 Spring Backend이지만, 실제 개발에서는 프론트엔드에 대한 이해 역시 협업의 완성도를높이는 중요한 요소라고 생각합니다.이 레포는 프론트엔드를 깊이 있게 다루기 위한 공간이라기보다는, 화면 구조와 기본적인 동작 방식을이해하고 클라이언트와 더 정확하게 소통할 수 있는 기반을 다지기 위한 보조 학습 공간입니다.현재는 개인 사이트를 직접 구현할 수 있는 수준과 프론트엔드의 전반적인 흐름을 이해하는 수준까지를목표로 하며, 실무 협업에 필요한 감각과 기초를 가볍지만 꾸준히 쌓아가고자 합니다.

최근에 시간을 다루는 글을 두 편에 걸쳐 정리하면서, 절대 시각과 지역 시각을 구분해 바라보는 기준이왜 중요한지도 함께 정리할 수 있었습니다. 다만 개념을 이해했다고 해서 바로 설계 기준이 정해지는 것은 아니었습니다.실제 프로젝트에서는 결국 하나의 기준을 선택해야 했고, 그 과정에서 자연스럽게 이런 질문에 도달하게되었습니다. 실제 프로젝트에서는 시간을 어떤 기준으로 저장하고 관리해야 할까? 특히 서비스가 하나의 지역만을 기준으로 동작하지 않거나, 해외에서도 접속할 가능성까지 고려한다면시간은 더 이상 단순히 “지금 몇 시인가”의 문제로만 볼 수 없었습니다. 사용자에게 보여주는 시간은 지역에 따라 달라질 수 있지만, 서버 내부에 저장되는 시간은 어느 환경에서든 같은 기준으로 해석될 수 있어야 했기 때문입니다..

Spring 중심으로 개발해 오면서 익숙한 방식에 많이 의지해왔고,비교적 단순하고 가벼운 방식으로 백엔드를 구성하는 Go가 실제 서비스 구현에서 어떤 감각을 주는지 궁금했습니다.그래서 이번에는 문법만 익히는 데서 끝내지 않고, 이커머스 서비스를 직접 구현하면서 Go를 학습해보려고 합니다. Spring을 사용해 개발을 하다 보면 구조와 역할이 비교적 명확하게 나뉘어 있어서,일정 수준의 일관성을 유지하면서,개발하기 좋다는 장점이 있습니다. 저 역시 지금까지는 그런 흐름 안에서 백엔드 기능을 만들고, 문제를 해결하고, 서비스를 운영하는 경험을 쌓아왔습니다. 그런데 한편으로는 다른 언어와 런타임이 같은 문제를어떤 방식으로 풀어내는지도 계속 궁금했습니다. 특히 Go는 작은 언어와 표준 라이브러리를 바탕으로 백엔드..

회사를 다니며 개발하다 보면, 기능을 충분히 고민한 뒤 구현하기보다 정해진 기간 안에 빠르게 결과를내야 하는 경우가 훨씬 많습니다. 때로는 복잡한 기능이 일주일 안에 만들어야 할 만큼일정이 매우 짧게 주어지기도 합니다. 이런 환경에서는 우선 동작하는 결과를 만들어내는 것이 가장 중요해지고, 더 좋은 설계가 없는지,다른 방식으로 풀면 어떤 차이가 있는지, 여러 기술을 비교하고 검토해볼시간은 자연스럽게 뒤로 미뤄질 수 밖에 없는 것 같습니다. 저 역시 그런 흐름 속에서 개발을 해왔습니다.짧은 일정 안에 기능을 구현하고 이슈를 해결하는 경험도 중요하지만, 한편으로는늘 비슷한 방식과 익숙한 선택 안에서만 문제를 풀고 있는 것은 아닐까 하는 생각이 들었습니다. 분명 더 나은 방법이 있을 수도 있고, 더 정확한 ..