abonglog

          • 소프트웨어 개발방법론

            • 로우파이 와이어프레임과 하이파이 와이어프레임
          • 자료구조 및 알고리즘

            • 다익스트라 알고리즘
            • 플로이드-워셜 알고리즘
            • 외판원 순회 문제(TSP) 를 완전 탐색 , DP로 풀어보자
            • 순열,조합과 그래프의 관계에 대해 알아보자
            • 백준 10986 - 나머지합 (모듈러 연산 , 누적합, 중복조합)
          • 함수형 자바스크립트

            • 모나드와 함께하는 함수형 프로그래밍 - Maybe 모나드
            • 복잡한 상태관리, 함수형으로 생각하며 리팩토링하기
            • 이터레이터와 이터러블, 제네레이터, 비동기 이터러블
            • 멀티패러다임 프로그래밍 서적 리뷰
            • 제네레이터를 이용해 자바스크립트의 큐 자료구조 10줄로 구현하기
            • 함수형 자바스크립트 모나드 알아보기
            • 함수형 자바스크립트의 펑터와 적용형 펑터
            • 커링 (currying) 에 대해 알아보자
            • 함수형 프로그래밍의 정의와 기초지식 및 가볍게 살펴보는 활용 예제
            • 함수형 자바스크립트 프로그래밍 학습 커리큘럼
          • 컴퓨터 공학 지식

            • 고급 프롬프트 엔지니어링을 위한 개념 정리
            • 개방형 와이파이에서도 폼 데이터는 안전할까 ?
          • 독서 노트

            • 솔로프리너의 시대 서평 리뷰
          • 인생 회고록

            • AI 에이전트를 이용해 블로그의 UI를 리디자인하며 느낀 회고 (바이브코딩, 양의 순환고리, 회고의 중요성)
          • 웹 브라우저 지식

            • 경험에 의거한 FSD (Feature Sliced Design) 구조 완전 공략
            • zustand는 어떻게 마법같이 동작할까?
            • 이번에 합성 컴포넌트를 이용하여 디자인 시스템을 만들어봤던 경험
            • 함수형 컴포넌트의 useEffect에 대한 사견, 부수효과 관점에서 다시 보기
            • 브라우저의 캐시 사용법 및 NextJS 에서 캐시를 사용하는 방법
            • NextJS 는 어떻게 이미지 최적화를 구현하는가 ?
          • introduction to algorithms

            • 이진 검색 트리 (이진 탐색 트리)
          • mostly-adequate-guide

            • Chapter 13: Monoids bring it all together [번역]
            • Chapter 12: Traversing the Stone [번역]
            • Chapter 11: Transform Again, Naturally [번역]
            • Chapter 10: Applicative Functors [번역]
            • Chapter 09: Monadic Onions [번역]
            • Chapter 08: Tupperware [번역]
            • Chapter 07: Hindley-Milner and Me [번역]
            • Chapter 06: Example Application [번역]
            • Chapter 05: Coding by Composing [번역]
            • Chapter 04: Currying [번역]
            • Chapter 03: Pure Happiness with Pure Functions [번역]
            • Chapter 02: First Class Functions [번역]
            • Chapter 01: What Ever Are We Doing? [번역]
          • Zero to One

            • 2번의 프로젝트 관리 실패로 배운 1인 개발의 씁쓸한 회고록
            • Zero to one 시리즈를 시작하며
          abonglog logoabonglog
          AI 에이전트를 이용해 블로그의 UI를 리디자인하며 느낀 회고 (바이브코딩, 양의 순환고리, 회고의 중요성) 의 썸네일

          AI 에이전트를 이용해 블로그의 UI를 리디자인하며 느낀 회고 (바이브코딩, 양의 순환고리, 회고의 중요성)

          인생 회고록
          프로필 이미지
          yonghyeun1/10/2026, 11:26:55 PM

          1. Fact (사실: 무슨 일이 있었나?)

          1.1 블로그 UI 개편 결과물

          UI 개편 전 메인 페이지UI 개편 전 메인 페이지

          UI 개편 전 글 페이지UI 개편 전 글 페이지

          주말 하루 날 잡고 현재 사용중이던 블로그의 전체적인 UI를 개편하기로 했다. 과거에 블로그를 만들 때 디자인과 관련된 내용은 하나도 생각하지 않은 채로 단순히 손에 잡히는데로 컴포넌트를 만들고 좋아하는 색상들을 하나씩 대입해가며 만들어갔었다. 그러다보니 디자인의 통일성도 떨어질뿐더러 심미적으로도 완성도가 낮은 모습이였다고 생각한다.

          UI 개편 후 메인 페이지UI 개편 후 메인 페이지

          UI 개편 후 글 페이지UI 개편 후 글 페이지

          글을 밀도있게 전달하기 위해서 일반적으로 쓰이는 너비인 680~720px 사이의 레이아웃 안에서 정보를 전달하기로 하고 타이포그래피같은 경우도 최대한 눈이 편안하도록 쓸데없는 효과를 넣지 않는 식으로 변경했다.

          1.2 리디자인 기간 때 목표했던 것은 AI 워크플로우를 이용한 작업 시간 단축

          이번 리디자인 때 목표했던것은 AI 에이전트를 이용해서 최대한 빠르게 원하는 결과물을 만들어내는 것이였다.

          컴퓨터에 앉아서 타이머를 2시간으로 설정하고 이 시간 안에 모든 작업을 끝내겠다라고 마음을 먹고 AI를 이용해 다음과 같이 작업했다.

          1. Deep Research 기능을 이용해 기술블로그에 필요한 UI/UX 정보 조사 (소요 시간 : 3분)
          2. 조사된 정보 내용을 토대로 영역 별 기술 명세서 생성 (소요 시간 : 5분)
          3. 기술 명세서 읽어보며 에이전트를 이용해 보강 (소요 시간 : 10분)
          4. 기술 명세서 별 작업 단위 명세서 설정, 작업 단위는 기술 명세서를 SOT로 바라보고 상세한 작업 내역, 체크리스트등 생성 (소요 시간 : 5분)
          5. 에이전트 호출 전 작업 단위 명세서를 읽어보며 보강 (소요 시간 : 10분)

          기술 명세서와 명세서 별 작업 단위 문서 설정기술 명세서와 명세서 별 작업 단위 문서 설정

          1. 모든 명세서가 문제가 되지 않았다고 판단되면 에이전트를 호출하여 구현 (소요 시간 30분)
          2. 구현된 코드 사항 바라보며 작업 단위 명세서에 정의된 체크리스트 퀄리티 체크 (소요 시간 5분)

          틈틈히 쉬는 시간을 제외하고 전체 작업 시간이 1시간20분도 안되는 기간동안 3000개의 코드 라인을 생성하고 500개의 코드라인을 제거 했다.

          단순히 UI관련된 것들만 퍼블리싱한게 아니라 디자인 시스템을 구축하고 이전에 매끄럽지 않던 비즈니스 로직들과 버그들을 수정했다. (사실 비즈니스 로직과 버그는 이번에 건들면 안됐지만)

          2. Feeling (감정: 어떤 기분이었나?)

          2.1 아웃풋 볼륨을 적은 노력만으로도 늘릴 수 있게 되었다는 충격

          양의 순환고리로 성장양의 순환고리로 성장

          작업 기간 동안 내가 직접 투자한 시간은 25분 밖에 되지 않았다. AI가 직접 구현했던 부분을 내가 직접 구현하기로 마음먹었다면 며칠은 잡고 있었어야 했을 것이다.

          시간을 줄였다는 부분 뿐 아니라 에너지 소모량에서도 큰 차이가 있다. 구현이란 행위 자체에서 벗어나니 뇌가 지치지 않았기에 2시간여동안의 작업 이후 읽고 싶었던 책을 읽기도 하고, 알고리즘 문제를 풀기도 하고 다른 프로젝트에 집중하기도 하는 등 또 다른 아웃풋 볼륨을 높힐 수 있었다.

          이렇게 해서 늘어나는 아웃풋 볼륨들은 또 성장분이 되어 다음엔 퀄리티가 더 좋은 아웃풋과 볼륨을 미친듯이 쏟아 낼 것이라 생각이 든다.

          2.2 말로는 AI 워크플로우였지만 사실 에이전트 친구 하나와 나의 딸깍 동업쇼

          아직 나는 AI를 제대로 활용하지 못한다. 이미 세상에는 다양한 에이전트 도구들이 있으나 찾아보기 귀찮은 나머지 나는 여전히 gemini , copilot 이 두 가지 도구만 이용해서 쓰고 있다.

          AI 워크플로우로 문서 생성 및 구현, 체크를 했다고 하지만 워크플로우라고 하기엔 내가 중간에 관여하는 부분들이 많았고 여전히 그 과정에서 내 에너지가 소모 되는 부분이 존재했다.

          가장 에너지가 많이 소모되었던 부분은 문서들과 구현 사항의 컨텍스트를 유지하는 것과 구현 사항에 대한 퀄리티 체크 부분이였다. 아웃풋 볼륨은 무지하게 늘어나는데 나의 능력은 제한이 있기 때문이였다.

          그래서 사실상 나중에는 버그가 나지 않을 정도로만 QC를 하고 코드 퀄리티나 문서 유지 또한 AI 에이전트에게 다시 맡기곤 했다.

          3. Finding (배운 점/교훈: 무엇을 깨달았나?)

          3.1 개발자에게 아웃풋 볼륨이 우선순위 1순위는 아닌 거 같다.

          이젠 더 이상 아웃풋 볼륨이 우선순위 1순위는 아닌 거 같다. 코드를 만들어내는 능력은 압도적으로 AI 에이전트가 뛰어나기 때문에 많은 사람들이 공감하지 않을까 싶다. 이제 중요한 건 어떤 아웃풋을 만들어낼 것이고, 그 아웃풋 볼륨들을 어떻게 관리 할 것인지 가 중요하다.

          실력이 좋고 나쁘고를 떠나서 생성 가능한 아웃풋 볼륨들은 대동소이 할 것이고 결국엔 품질이 전부일 거라 생각이 들었다. 혹은 폭발적인 아웃풋 볼륨으로 다양한 것들을 빠르게 도전해보거나 말이다.

          3.2 양의 순환고리 , 좋은 인풋이 필요하다.

          결국 좋은 아웃풋을 만들고 관리하기 위해선 좋은 인풋이 필요하다. 그러기 위해선 아웃풋보다 인풋이 많은 사람이 되어야 한다.

          최근 런닝을 다시 시작하면서 팟캐스트를 듣고 있는데 영화 평론가 이동진의 팟캐스트를 들었다.그 팟캐스트에선 자신의 생각을 말하는 작가들을 대상으로, 불변할 만한 이론을 계속 이야기하는 작가들의 경우엔 아웃풋이 인풋보다 많을 수 있겠지만 변경되는 것에 대해선 무조건 아웃풋보다 인풋이 많아야 한다고 이야기 한다. 동일하게 생각한다. 결국 좋은 아웃풋은 좋은 인풋을 가진 사람에게서 나온다. 그럴 수록 더더욱 인풋을 쌓아가야겠다.

          4. Future (향후 계획: 앞으로 무엇을 할 것인가?)

          향후 계획은 우선 좋은 인풋을 쌓기 위해 노력하려 한다. 특히 기술 서적 뿐 아니라 인문 서적도 가까이 하려 한다.

          또 정말 AI 워크플로우를 이용해서 폭발적인 볼륨을 내고 있는 사람들을 찾아 그들의 방법을 많이 배워야 할 것이다.

          그리고 프로덕트 외 실생활 속에서도 AI 워크플로우를 가까이 하여 인풋을 채워주는 아웃풋을 만들어보려 한다. 양의 순환고리처럼 말이다.

          지금 읽고자 하는 책은 우선 애자일관련 된 책 (함께 자라기 외 2권), 1인 개발자를 위한 책정도이다. AI 워크플로우 관련되어서는 영상을 찾아봐야지

          5. Feedback (피드백: 전체적인 총평)

          폭발적 아웃풋 볼륨은 양의 순환고리처럼 나를 더 성장 시켜줄 것이라 믿는다.

          아 참, 양의 순환고리처럼 성장하려면 중간에 무조건적으로 회고 시간이 필요하다.

          • 1. Fact (사실: 무슨 일이 있었나?)
            • 1.1 블로그 UI 개편 결과물
            • 1.2 리디자인 기간 때 목표했던 것은 AI 워크플로우를 이용한 작업 시간 단축
          • 2. Feeling (감정: 어떤 기분이었나?)
            • 2.1 아웃풋 볼륨을 적은 노력만으로도 늘릴 수 있게 되었다는 충격
            • 2.2 말로는 AI 워크플로우였지만 사실 에이전트 친구 하나와 나의 딸깍 동업쇼
          • 3. Finding (배운 점/교훈: 무엇을 깨달았나?)
            • 3.1 개발자에게 아웃풋 볼륨이 우선순위 1순위는 아닌 거 같다.
            • 3.2 양의 순환고리 , 좋은 인풋이 필요하다.
          • 4. Future (향후 계획: 앞으로 무엇을 할 것인가?)
          • 5. Feedback (피드백: 전체적인 총평)

          abonglog

          공부한 내용을 기록하고 함께 성장하고 싶어 만든 두 번째 블로그입니다.
          주로 웹개발과 관련된 내용을 포스팅합니다.

          Githubttddcc119@naver.com

          © 2026 abonglog All rights reserved.