SU8Y

• [Research] 보이지 않는 파산을 막는 AI 네이티브 시대의 엔지니어링 리더십 코딩 속도는 10배 빨라졌는데, 우리 팀은 왜 더 바빠졌을까?비즈니스의 진정한 속도를 결정하는 것은 코드 생성 속도가 아니라, '코드의 복잡성을 통제하는 소프트웨어 공학적 널리지(Knowledge)'이다.최근 AI 코딩 어시스턴트(Claude, Cursor 등)의 도입으로 우리는 '초자동화(Hyper-automation)' 시대에 진입했다. 개발자의 타이핑 시간은 확실히 획기적으로 줄어들었다.하지만 안심하기엔 이르다. 적절한 '아키텍처 거버넌스(Architecture Governance)'나 품질 통제망 없이 AI가 코드를 양산하도록 방치한다면, 역설적으로 신규 피처(Feature) 배포 주기는 점차 정체되거나 과거보다 더 느려질 위험이 크다.그 이유는 명확하다. 통제되지 않은 코드 생성 속도는 곧 '기.. 2026.07.11
• 기타를 치면서 코딩하기(딸깍 딸깍). 바이브 코딩을 늦게시작했다. 시작한지 7일차.처음은 조금 허덕였지만, 벌써 익숙해졌다. (기타를 들며)나의 구조적 철학이 들어간 잘 만들어진 프로젝트를 기반으로 Claude에게 여러 패턴을 만들게 하고 (딸깍 x 2)내가 가장 익숙했던 방식을 기반으로 Claude가 자기자신 일하는 방식을 정리하게 하고 (딸깍 x 4)내 고민을 Claude 에게 적고 (딸깍 x 8)좋은 결과가 나오길 기다리면서 기타를 친다. (딸깍 x 16)별거 없지만 댓글 남겨주면 나의 노하우를 전수하겠다. Q: 이렇게 빠르게 노하우를 쌓을수 있었던 이유는 ? A: Architecture ! 2026.05.22
• PS 포스팅은 비공개 되었습니다. 블로그의 방향성을 생각하던중 ps포스팅은 현재 작성하고 있는 포스팅의 내용과 어울리지 않아서 비공개하기로 결정했습니다. 2026.04.24
• 전문대학 3년제 졸업생의 학점은행제 학사학위 취득 회고 나는 운이 좋다전문대 융합소프트웨어학과 3년대(졸업) 운이 좋게 학업중 취업을 하여 경력을 쌓기 시작했다.나는 전문대 3년제 컴공 졸업으로 IT업계에서 일을한지 2년이 되어가는 해에 학위에 대해서 다시 생각을 해보게 되었다.학부생 시절 학교 생활을 열심한 결과 운이 좋게도 교수님들의 추천으로 2개의 기업을 면접을 보고 2곳을 합격하였다. 둘 중 어디를 갈지 고민하던 중 한기업이 LINC 3.0(3단계 산학엽협력 선도전문대학 육성사업)를 연계하고있는 기업이어서 해당 기업을 선택하고, 학교생활과 회사 생활을 병행하며 경력을 쌓을수 있었다.나는 이렇게 경력 시작을 운이좋게 하다보니, 제대로된 취업준비를 하지 않았고, 자격증이나 학력 그 외 많은 활동에 대해서 필요성을 많이 느끼지 못했었다. 그럼에도 회사에.. 2026.02.09
• ‘잘하고 있는데 왜 힘들까?’에서 시작된 개발 프로세스 개선 1년 그동안 이런 질문들을 반복해왔다.왜 특정 단계에서 일이 자주 막힐까?이슈 기반 관리나 CI/CD에 대한 거부감은 왜 생길까?문제는 도구일까, 프로세스일까, 아니면 학습의 문제일까?“지금 우리 조직은 잘하고 있는 걸까?”장애가 잦거나 실패를 반복하는 이유부터 시작된 질문은 아니었다. 오히려 각자 최선을 다하고 있었고, 일정은 빠듯했지만 결국 결과를 만들어내고 있었다. 문제는 그 과정에서 일어났다. 같은 유형의 이슈가 반복되고, 프로젝트가 끝난 뒤에도 왜 힘들었는지 정확히 설명하기 어려웠다.회고1. 몇 차례의 프로젝트를 돌아보며 공통적으로 발견한 패턴이 있었다. 일정이 밀리거나 품질 이슈가 발생했을 때, 원인은 특정 개인의 역량이나 기술적 난이도가 아니었다.- 요구사항 변경이 언제, 왜 발생했는지 추적되지 .. 2026.01.27
• [Spring] 모노레포 환경에서 MessageSource를 모듈별로 독립시키는 방법(feat. BeanPostProcessor) 최근 로또 프로젝트를 모노레포(Monorepo) 구조로 전환하면서 흥미로운 기술적 난관에 부딪혔습니다.현재 프로젝트는 모듈별 관심사 분리를 위해 Common 모듈의 AbstractCommonException과 ErrorCode를 확장하여 각 모듈(User, Lotto, Resilience 등)이 독자적인 에러 처리를 담당하고 있습니다. 이때 ErrorCode를 구현한 Enum은 MessageSource를 통해 국제화(i18n)된 에러 메시지를 반환하게 됩니다.public interface ErrorCode { String code(); HttpStatus status(); String messageKey();}public abstract class AbstractErrorCodeException exte.. 2026.01.14
• [1일 1커밋 2년 회고] 관성의 위기감 2025년 12월 31일, 올해의 마지막 커밋을 푸시하고 깃허브 프로필을 새로고침했습니다. 2년 치의 초록색 타일들이 빈틈없이 빽빽하게 채워져 있더군요.작년 이맘때, 1년 차 회고를 쓰며 "귀찮음을 어려움으로 착각하지 않으면 꾸준함은 어렵지 않다"라고 적었던 기억이 납니다. 그 다짐 덕분인지 지난 1년도 큰 위기 없이 잔디를 채울 수 있었습니다. 하지만 2년이라는 시간을 꽉 채운 지금, 제 마음속에는 뿌듯함과 동시에 묘한 위기감이 공존하고 있습니다.2026년을 맞이하며, 그 '위기감'에 대해 솔직하게 적어보려 합니다.동경에서 시작해 관성이 되기까지처음 1일 1커밋을 시작했을 때는 단순했습니다. 챌린지를 진행하는 멋진 개발자분들을 보며 "나도 흉내라도 내면 저 사람들과 조금이라도 가까워지지 않을까?" 하는.. 2026.01.01
• [DevFest Incheon 2025 후기] 불안을 이기는 '긴 호흡', 그리고 AI의 눈과 귀가 된 WebRTC 안상혁 연사님의 초대로 이번 주말에 DevFest Incheon 2025을 다녀왔습니다.제가 들었던 세션은 총 6개를 꽉 채워 들어 1시부터 7시까지의 너무나도 유익하고 짧게만 느껴졌던 Dev Fest를 마무리 했습니다.임현욱 연사님의 "검정고시에서 구글까지: 불안을 이기는 '긴 호흡'의 힘"차지현, 이상아, 이수형 연사님의 "개발자의 다음 챕터: 기술을 넘어 '나'를 성장시키는 방법"김종현 연사님의 "개발만 하게 해줄게, 뒷 일은 우리한테 맡겨"이재규 연사님의 "WebRTC in AI Era"초대해주신 안상혁 연사님의 "오픈소스 기여 Quick Start, 그런데 Kafka와 Spring Kafka를 곁들인."그리고 "CQRS는 반드시 비동기로 구현되어야 할까?"를 들으려고 했으나 임현욱 연사님의 첫 .. 2025.12.07
• [포스팅 리뷰] Simple code scales better than "scalable" code. You're Not Building Netflix: Stop Coding Like You AreYou know what's hilarious? Fresh bootcamp grads write code that's too simple. Six months later, after...dev.to과도한 추상화이 글에서 다루는 내용은 과도한 추상화에 대한 이야기다.나는 개발을 하기시작한지 3년이 넘어가며 Clean Architecture, DDD, TDD, Hexagonal, Port & Adaptor, XP 책, 수많은 기술블로그 아티클, 강의와 다양한 패턴에 대해서 설명하는 글들을 많이 읽고나서는 하나의 정답처럼 여겨지는 코드들의 부산물들이 내 머릿속에 있었다. 그것은 마치 "인터페이스가 없는 클래스는 죄악.. 2025.11.23
• [독서] 웹 개발자를 위한 대규모 서비스를 지탱하는 기술 여자친구와 교보문고에서 독서를 하며 건강한 데이트를 하고있다가 제목이 궁금증을 생기게 하여 펼쳐본 책이었습니다.간단하게 읽어보려 했지만, 정신없이 구매까지 이어지며 완독까지 해버렸네요.이직을 준비하면서 많은 채용공고에서 주니어 개발자들에게 원하는 기술적 능력치중 하나인 '대규모 트래픽 경험'많은 기술블로그를 보기도 하면서 이럴땐 이렇게 하구나를 느꼈지만 항상 느낀 감정은 이건 'How-to(사용 방법)'에서 끝나는 아쉬움이 있었습니다.단순히 기능을 구현하는 '애플리케이션 개발자'에서, 전체 구조를 이해하는 '엔지니어'로 시야를 넓혀준 책입니다.들어가며, 책의 초반부는 대규모 데이터와 트래픽을 처리하기 위한 가장 기초적이면서도 중요한 전략을 다룹니다.스케일 업(Scale-up) vs 스케일 아웃(Scale.. 2025.10.18
• [Spring Data] JPA를 왜 쓰는가에 대한 오해 JPA에 대해서 친구가 이런 질문을 던졌다.어차피 복잡한 쿼리는 Native Query를 쓰게 된다Join도 연관관계가 없으면 결국 Native Query다그렇다면 JDBC나 MyBatis가 더 낫지 않나?영속화는 리소스 낭비가 아닌가 ?이 질문들은 결국 다음 지점으로 수렴한다.영속성 컨텍스트를 굳이 써야 할 이유가 있을까?이 질문은 굉장히 합리적으로 보인다. 동시에, JPA를 바라보는 관점이 살짝 어긋나 있다는 신호이기도 하다.논의의 출발점: 패러다임의 불일치이 논쟁은 결국 패러다임의 불일치에서 시작된다.데이터베이스의 목표데이터를 안전하게 저장한다정합성과 무결성을 유지한다집합 기반 연산에 최적화되어 있다객체지향 언어의 목표데이터를 추상화한다상태와 행위를 캡슐화한다변경에 강한 구조를 만든다이 둘은 애초에.. 2025.10.05
• [OpenSource] 아파치 Gravitino 릴리즈(v0.9.1, v1.0.0) 기여 최근 데이터 카탈로그 솔루션인 Apache Gravitino (Incubating) 프로젝트의 v0.9.1과 v1.0.0 릴리즈에 컨트리뷰터로 참여하게 되었습니다.생각치도 못하게 릴리즈 노트의 제 닉네임과 이름이 적혀있어서 1차로 놀랐고 코드 기여가 실제 사용자들이 변경을 체감할수있는 편의을 위한 기여가 되었다는 것이 감회가 새로웠습니다.Apache Gravitino v1.0.0 Release NoteApache Gravitino v0.9.1 Release Note내가 얻은 것방대한 양의 코드베이스 -> 전체 아키텍처를 간단한 다이어그램으로 도식화를 하는 연습테스트 코드 작성현실적인 코드 리뷰(테스트 코드)와 같은 원칙 2025.10.01
• [Spring Security]: 시큐리티 필터 예외 바꿔치기 문제 안녕하세요! 오늘은 Spring Security 환경에서 JWT 인증 필터를 통해서 인증을 실패했을때 발행했던 Exception이 Override되는 이슈를 해결했던 경험을 정리합니다. 분명히 토큰 파싱 중 발생한 ExpiredJwtException이나 MalformedJwtException에 대한 에러 처리를 했는데, 정작 클라이언트가 받는 것은 내가 의도한 메시지가 아닌 InsufficientAuthenticationException의 기본 메시지인 "Full authentication is required to access this resource" 이었습니다. 이 현상의 원인을 AnonymousAuthenticationFilter부터 ExceptionTranslationFilter까지 이어지는 .. 2025.09.07
• Tell, Don't Ask 객체지향 프로그래밍(OOP)을 배우다 보면 수많은 원칙과 패턴들을 접하게 됩니다. SOLID, 디자인 패턴, 클린 코드 등등… 때로는 그 복잡함에 압도되기도 하죠. 하지만 그중에서도 이해하기 쉽고, 적용했을 때 코드 품질에 변화를 가져다주는 황금률이 하나 있습니다. 바로 "Tell, Don't Ask (묻지 말고 시켜라)"입니다.이 원칙은 프로그래밍의 가장 기본적인 활동 중 하나인 "객체 간의 상호작용"에 대한 강력한 지침을 제공합니다. 이름만 들어도 벌써 뭔가 직관적이지 않나요? 굳이 물어보지 말고, 그냥 하던 대로 시키라는 겁니다.왜 "묻지 말고 시키라"는 걸까?자, 예를 들어봅시다. 저는 한 팀의 리더이고, 팀원에게 특정 작업을 지시해야 합니다.나쁜 예 (Ask):"팀원 A 씨, 지금 이 파일의 상.. 2025.07.23
• [OpenSource] WET vs DRY(feat 오픈소스기여) 오픈소스 기여를 통해 배운 유닛 테스트: WET vs DRY최근 Apache 오픈소스 프로젝트에 기여하면서 유닛 테스트 작성에 대한 흥미로운 고민에 빠졌습니다. PR(Pull Request)을 보내는 과정에서 기존 테스트 코드와의 중복 문제에 부딪혔고, 이 과정에서 WET(Write Everything Twice)과 DRY(Don't Repeat Yourself) 원칙에 대한 인사이트를 경험했습니다.시작은 코드 중복에 대한 고민제가 맡았던 이슈에 대한 유닛 테스트를 작성하던 중, 기존의 update model 테스트들과 상당한 코드 중복이 발생한다는 것을 발견했습니다. 처음에는 테스트 문자열을 바꾸는 임시방편으로 문제를 해결했지만, '과연 이것이 이 코드베이스에서 더 나은, 관용적인 방법일까?'라는 의문.. 2025.07.13