ioh's Development

티스토리 자동 목차(TOC) 만들기: 클릭 이동 안 됨 현상 완벽 해결!

블로그 포스팅이 길어질수록 독자들은 원하는 정보를 찾기 힘들어합니다. 이때 꼭 필요한 게 바로 목차라고 생각합니다.!구글 SEO(검색 최적화)에도 도움이 된다는 사실, 알고 계셨나요?하지만 인터넷에 나온 코드를 그대로 따라 해도 "클래스명이 달라서 안 보이거나", "클래식하면 해당 위치로 이동하지 않는" 문제로 고생하시는 분들이 많습니다. 오늘은 어떤 스킨에서도 완벽하게 작동하는 자동 목차 설치법을 정리하겠습니다. 1. 왜 자동 목차를 써야 할까?사용자 편의성: 독자가 원하는 부분으로 바로 점프할 수 있습니다.SEO 점수 상승: 구글 로봇이 글의 구조를 파악하기 쉬워져 검색 노출에 유리합니다.체류 시간 증가: 깔끔한 정돈은 블로그의 전문성을 높여줍니다.2. 1분 만에 끝내는 자동 목차 설치법Step 1:..

소프트웨어 아키텍처 스터디 회고 - 완독보다 오래 남은 것은 ‘의사결정의 방식’이었다

소프트웨어 아키텍처 스터디가 2월 12일을 마지막으로 마무리됐다.회사 업무가 바빠지면서 몇 번은 참석하지 못했지만, 이번 스터디는 결과적으로 혼자 읽는 독서와는 다른 종류의 완주였다. 단순히 책을 끝까지 읽었다는 성취보다, 읽는 과정에서 아키텍처를 바라보는 시야와 의사결정 습관이 더 분명해졌다.스터디를 하면서 가장 자주 떠올랐던 문장은 이것이다.아키텍처는 정답을 맞히는 일이 아니라, 무엇을 포기할지 합의하는 일이다.혼자 읽을 때는 “개념을 이해했는가”에 초점이 갔다면, 함께 읽을 때는 자연스럽게 “이 개념이 실무 의사결정에서 어떤 역할을 하는가”로 질문이 이동했다. 이 이동이 이번 스터디의 가장 큰 가치였다.1) 약속이 만든 실행력, 실행이 만든 학습출석률이 완벽하진 않았지만, 스터디가 약속이라는 사실은..

WIL - 2주차 유비쿼터스 언어를 먼저 고정하니 설계가 따라왔다

이번 주에 새로 배운 것이번 주 과제는 이커머스 도메인(상품, 브랜드, 좋아요, 주문 등)을 대상으로 설계 산출물만으로 PR을 제출하는 것이었다. 요구사항 정리부터 시퀀스 다이어그램, 클래스 다이어그램, ERD까지. 코드 없이 설계를 완성한다는 게 처음엔 막막했다.그래서 나는 시작점부터 명확히 잡았다.유비쿼터스 언어(Glossary)를 가장 먼저 정의하고, 그 언어 위에서 설계를 진행한다.이 선택은 “문서 작성 순서”가 아니라 “설계의 품질을 결정하는 규약”을 먼저 고정하는 일이었다.실무에서 설계가 흔들리는 순간을 떠올려보면, 대부분은 기술이 아니라 단어의 혼용에서 시작한다.“상품”과 “아이템”을 같은 의미로 쓰거나“주문”과 “결제”를 동일시하거나“장바구니”와 “주문서” 경계를 흐리거나이런 상태로 ERD..

TL;DR이번 이커머스 설계 과제에서 AI를 "도메인별 전문가"로 세워놓고 브레인스토밍하며 요구사항을 명확히 했다. 대화에서 나온 결정을 문서(결정 로그)로 고정했다. AI 시대에 문서화는 단순한 이해 도구가 아니라, “왜 이 결정을 했는지”를 남겨 팀이 다시 흔들리지 않게 하는 운영 자산이 된다.1. AI에게 "당신의 의견이 궁금합니다"라고 물었다이번 과제의 도메인은 이커머스였다. 상품, 브랜드, 주문, 재고, 쿠폰, 결제. 각각이 하나의 전문 영역이고, 나 혼자 모든 도메인을 깊이 있게 설계하기엔 한계가 있었다. 각 도메인은 결국 서로 얽히고, 작은 정책 차이가 데이터 모델과 트랜잭션 경계를 흔든다. 혼자 모든 도메인을 깊이 있게 설계하려 하면, 금방 “그럴듯한 정답”에 기대게 된다.그래서 AI를..

법령 프로젝트에서 전제 조건이 깨진 경험이, 이커머스 설계에서 내 판단을 어떻게 바꿨는지에 대한 이야기 TL;DR회사에서 법령 번역 서비스를 만들며, 기획과 함께 꼼꼼하게 정의한 전제 조건이 한 번에 무너지는 걸 경험했다. "외국 법령은 수정 불가"라는 핵심 제약이 깨지면서 데이터 정합성이 무너졌고, 운영 데이터가 쌓인 상황에서 DB를 쉽게 바꾸지 못해 애플리케이션 레벨에서 분기 처리를 억지로 끼워 맞추느라 코드가 복잡해졌다. 그 결과 코드가 빠르게 복잡해졌고, 그 경험이 이번 이커머스 설계 과제에서 "요구사항을 꼼꼼하게 보고, 전제가 바뀌어도 테이블이 흔들리지 않는 최소한의 여유"를 우선으로 두게 되었다.1. 기획과 분명히 합의했는데, 그게 깨졌다회사에서 세무법인을 위한 법령 서비스를 맡았던 적이 있다..

WIL - 1주차 (TDD & Hello Agent)이번 주에 새로 배운 것TDD는 “테스트 먼저”가 아니라, 설계를 이끌어내는 도구였다과제를 시작할 때 “기능 구현에 앞서 테스트 코드를 먼저 작성하라”는 요구를 받았다. 처음에는 단순히 “테스트를 먼저 쓰고 통과시키면 되겠지”라고 생각했다. 그런데 막상 시작하니, 어디서부터 어떤 순서로 무엇을 테스트해야 하는지부터 불명확했다.처음에는 요구사항을 기준으로 기능 단위로 구현하려 했다. 하지만 곧 흐름이 무너졌다. PasswordValidator부터 시작해 검증 로직 → Entity → Service → Controller 순서로 접근하려니, 기능이 이곳저곳에 흩어졌다. 결과적으로 “지금 내가 무엇을 검증하고 있는가?”를 잃어버린 상태가 됐다.방향을 다시 잡..

TL;DRAI와 협업하면서 개발자의 역할이 "코드를 작성하는 사람"에서 "의도를 정의하고 판단하는 사람"으로 바뀌고 있음을 체감했다. 단, 테스트 코드만큼은 직접 작성해야 진짜 내 것이 된다.왜 이 글을 쓰게 되었는가?1주차 과제를 Claude Code와 함께 진행했다. 처음에는 "AI가 코드를 다 짜주겠지"라는 막연한 기대가 있었다. 하지만 실제로 협업해보니, AI를 잘 쓰려면 내가 더 명확해야 했다.무엇을 만들지, 어떤 구조로 할지, 어디까지 허용할지 — 이런 판단들을 내가 하지 않으면 AI는 엉뚱한 방향으로 달려갔다.이 글에서는 AI와 TDD를 함께하며 느낀 점들을 정리해본다.CLAUDE.md - AI에게 규칙을 알려주는 것부터 시작Claude Code를 사용할 때 가장 먼저 한 일은 CLAUDE...

테스트는 통과했는데 버그였다 - 트랜잭션 경계에서 배운 것 TL;DRMock 테스트의 한계를 마주한 순간 - JPA Detached Entity 디버깅 경험단위 테스트(Mock)에서는 절대 발견할 수 없는 버그가 있다. 비밀번호 변경 기능이 "성공"했는데 DB에 반영되지 않는 버그를 통합 테스트를 작성하면서 발견했고, 원인은 JPA의 Detached Entity 상태였다.왜 이 글을 쓰게 되었는가?1주차 과제로 회원가입, 내 정보 조회, 비밀번호 변경 API를 TDD로 구현하고 있었다.단위 테스트는 모두 통과했다. E2E 테스트도 작성해뒀다. 그런데 Facade 통합 테스트를 작성하는 과정에서 이상한 현상을 발견했다.비밀번호 변경 API 호출 → 성공 응답새 비밀번호로 로그인 → 실패이전 비밀번호로 로그..

오케스트레이션 주도 서비스 지향 아키텍처 (SOA) 완벽 가이드들어가며: 아키텍처 스타일의 흥망성쇠아키텍처 스타일은 예술 사조와 비슷한 측면이 있다. 그것이 발전하던 시대의 아키텍트에게는 의미가 있지만, 이후 시대에는 유관성(relevance)이 사라진다. 오케스트레이션 주도 서비스 지향 아키텍처(Orchestration-Driven Service-Oriented Architecture)가 바로 그런 경향을 보여주는 대표적 사례다.이 아키텍처는 논리적으로는 타당해 보이는 조직의 아이디어가 어떻게 개발 프로세스의 가장 중요한 부분을 저해할 수 있는지 보여주는 훌륭한 본보기다. 특히, 소프트웨어 아키텍처의 제1법칙인 "소프트웨어 아키텍처의 모든 것은 트레이드오프"라는 점을 무시할 때 생기는 위험을 잘 보여준..

1. 공간 기반 아키텍처란?공간 기반 아키텍처(Space-Based Architecture)는 높은 확장성, 탄력성, 동시성(concurrency)과 관련한 문제를 해결하기 위해 특별히 설계된 아키텍처 스타일입니다.1.1 이름의 유래: 튜플 공간 (Tuple Space)튜플 공간은 여러 병렬 프로세서가 공유 메모리를 통해 통신하게 함으로써 병렬 처리의 이점을 취하는 기법입니다.1.2 핵심 아이디어보통의 시스템에서 중앙 데이터베이스는 시스템의 동기적 제약조건입니다. 공간 기반 시스템은 중앙 데이터베이스를 두는 대신 메모리 안에서 데이터 그리드를 복제함으로써 높은 확장성과 탄력성, 성능을 달성합니다.1.3 주요 특징애플리케이션 데이터는 메모리에 유지: 모든 활성 처리 단위 사이에서 복제비동기 데이터베이스 갱..

목차이벤트 주도 아키텍처란?요청 기반 모델 vs 이벤트 기반 모델토폴로지 개요이벤트 vs 메시지파생 이벤트와 확장 능력비동기 역량브로드캐스팅과 이벤트 페이로드오류 처리데이터 손실 방지요청-응답 처리중재자 토폴로지데이터 토폴로지아키텍처 특성 평가예시와 용례1. 이벤트 주도 아키텍처란?이벤트 주도 아키텍처(Event-Driven Architecture, EDA)는 인기 있는 분산 비동기 아키텍처 스타일로, 고확장성·고성능 애플리케이션을 만드는 데 흔히 사용됩니다.1.1 핵심 특징적응성이 매우 높음: 소규모 애플리케이션부터 대규모 복합 애플리케이션까지 다양한 규모에 적용 가능분리된 컴포넌트: 결합이 느슨한(decoupled) 이벤트 처리 컴포넌트들로 구성비동기 처리: 컴포넌트들이 비동기적으로 이벤트를 발생하고..