매일 성장하기

우리는 하루에도 수많은 결정을 내립니다. 그리고 그 모든 결정의 이면에는 도파민(Dopamine)이 작용하고 있습니다. 도파민은 단순한 ‘행복 호르몬’이 아닙니다. 오히려 우리를 움직이게 하는 동기 부여의 핵심 물질입니다. 하지만 많은 사람들이 도파민을 잘못된 방식으로 사용하면서 즉각적인 보상에 길들여지고, 결국 성장과 성공으로 가는 길에서 멀어지고 맙니다. 이 글에서는, 세계적인 뇌과학자 애나 렘키(Anna Lembke) 교수와 유명 팟캐스트 "Diary of a CEO"에서 논의된 도파민 활용법을 바탕으로 도파민을 내 편으로 만드는 실천 가능한 방법을 소개합니다. 도파민이 우리를 망치는 이유도파민은 우리를 움직이게 만드는 원동력이지만, 잘못된 방식으로 활용될 때 즉각적인 보상만을 추구하는 함정에 빠지..

1. FSD란 무엇인가?Feature-Sliced Design(FSD)은 프로젝트를 기능 중심으로 구조화하여 유지보수성과 확장성을 높이는 방법론입니다. 기존 계층 기반 아키텍처(MVVM, 클린 아키텍처)와 달리 기능 단위로 모듈을 나누고, 관련된 코드(UI, 비즈니스 로직, 데이터 등)를 한 곳에 배치하는 방식을 따릅니다. 이를 통해 코드의 응집도를 높이고, 기능 단위의 독립성을 유지할 수 있습니다. FSD는 여러 계층으로 구성되며, 각 계층이 서로 긴밀히 연결됩니다. 각 계층이 어떻게 상호작용하는지를 이해하는 것이 중요합니다. 이제 FSD의 핵심 계층을 살펴보고, 하나의 기능을 중심으로 이 계층들이 어떻게 유기적으로 연결되는지 예제를 통해 설명하겠습니다. 2. FSD의 핵심 계층1) App Layer ..

소프트웨어 개발에서 구조화의 중요성개발을 하다 보면 코드가 점점 커지고 복잡해지면서 유지보수가 어려워지는 순간이 옵니다. 작은 프로젝트라면 괜찮겠지만, 기능이 추가되고 팀원이 늘어나면서 코드의 일관성과 재사용성을 유지하는 것이 점점 힘들어집니다. 전통적으로 MVC, MVVM, Clean Architecture 같은 다양한 패턴을 사용해 왔습니다. 하지만 이러한 패턴에도 모호한 부분이 존재하고, 기능이 많아질수록 구조를 유지하는 것이 어려워집니다. 여기서 등장하는 것이 바로 Feature-Sliced Design (FSD)입니다.  FSD는 기능 중심으로 코드를 정리하는 방법론으로, 코드의 위치를 명확히 정의하고, 유지보수성과 확장성을 극대화하는 데 초점을 맞춥니다. 이제, 기존 아키텍처와 비교하며 FSD..

우리 모두 알고 있죠. 운동이 건강에 좋고, 공부가 미래를 밝게 해주며, 테스트 코드가 개발 품질을 높인다는 사실을요. 그런데 문제는 ‘알고 있음’이 아니라, ‘하기 싫음’입니다. 운동할 생각만 해도 피곤하고, 공부는 재미없고, 테스트 코드 작성은 귀찮기 그지없죠. 그런데 말입니다, 하기 싫은 일을 꾸역꾸역 하면 뇌에서 엄청난 변화가 일어난다는 연구 결과가 있어요.의지력의 본진, 전대상 피질뇌에는 ‘전방 중대상 피질 (Anterior Midcingulate Cortex, aMCC)’이라는 영역이 있습니다. 이름이 너무 어려우니 그냥 ‘의지력 발전소’라고 해볼까요? 이 영역은 우리가 하기 싫은 일을 집요하게 수행할 때 활성화되는데, 단순히 많은 일을 한다고 커지는 게 아니라, 진짜 하기 싫은 일을 할 때 ..

클린 코드(clean code)는 로버트 C. 마틴(Robert C. Martin)의 저서에서 제안된 개념으로, 이해하기 쉽고, 변경하기 용이하며, 예측 가능해야 한다는 특징을 갖습니다. 클린 코드를 달성하는 방법 중 하나는 OOP 원칙을 따르는 것입니다. OOP는 현실 세계의 개념을 모델링하는 방식으로, 객체와 클래스를 활용해 소프트웨어 시스템을 구성합니다. 하지만 단순히 객체를 사용하는 것만으로는 클린 코드가 보장되지 않습니다. 잘못된 객체 모델링은 오히려 복잡성을 증가시키고, 유지보수를 어렵게 만들 수 있습니다. 이러한 문제를 해결하기 위해 등장한 것이 바로 MAPPER 원칙입니다.MAPPER 원칙이란?현실 세계를 반영하는 소프트웨어 설계 원칙에서 설명한 내용을 MAPPER라는 원칙으로 설명하는 책..

소프트웨어 개발에서 가장 중요한 목표 중 하나는 예측 가능성과 유지보수성을 확보하는 것입니다. 이를 위해 가장 중요한 원칙은 각 도메인 개념이 소프트웨어 엔터티와 1:1로 대응되어야 한다는 것입니다. 이 원칙은 객체지향 프로그래밍(OOP), 도메인 주도 설계(DDD), 그리고 클린 코드 접근법에서도 동일하게 적용됩니다.1. 현실 세계를 반영하는 1:1 매핑 원칙소프트웨어는 현실을 그대로 반영해야 합니다. 현실 세계에 존재하는 개념이 소프트웨어에서도 하나의 모델로 존재해야 하며, 여러 개의 객체나 시스템에 분산되어서는 안 됩니다. 예를 들어:현실에서 자동차(Car)가 존재한다면, 소프트웨어에서도 Car 클래스가 있어야 합니다.직원(Employee)이 있고, 그 직원이 월급과 직책을 가진다면, 이 속성들은 ..

노력과 보상의 역설대부분의 사람들은 목표를 달성하는 과정에서 보상을 기대합니다. 금전적 보상, 사회적 인정, 혹은 개인적인 성취감이 그 예시입니다. 하지만 신경과학 연구에 따르면 이런 보상 중심적인 사고방식이 오히려 지속적인 동기 부여를 방해할 수 있습니다. 노력 자체에서 기쁨을 찾는 것이야말로 진정한 동기 부여의 핵심입니다.스탠퍼드 대학의 실험스탠퍼드 대학에서 유치원생들을 대상으로 한 실험에서 연구자들은 그림 그리기를 좋아하는 아이들에게 보상을 주기 시작했습니다. 처음에는 아이들이 기쁜 마음으로 그림을 그렸지만, 보상이 중단된 후에는 이전보다 그림을 덜 그리게 되었습니다. 외적 보상이 사라지자 내적 동기도 약해지는 '과잉 정당화 효과(overjustification effect)'가 나타난 것입니다.보..

저는 발표를 시작할 때 분위기를 부드럽게 만들기 위해 농담을 던지곤 했습니다. "이 발표가 끝나면 다들 졸지 않고 끝까지 들었으면 좋겠습니다!" 같은 말을 했었죠. 그런데 "How to Speak" 유튜브 영상을 보고 중요한 사실을 깨달았습니다. 발표를 들으면 무엇을 얻을 수 있는지를 먼저 알려주는 것이 청중의 집중력을 높이는 데 훨씬 효과적이라는 것입니다. 이 방식을 적용해 보니, 청중이 발표에 더 집중하고 발표 내용에 대한 반응이 더욱 활발해졌습니다. 그래서 저는 발표 초반에 가볍게 웃을 수 있는 요소는 유지하되, "이 발표를 들으면 이런 것들을 배울 수 있습니다!" 라는 메시지를 명확하게 전달하는 방식으로 개선했습니다. 많은 도움이 되었던 내용을 정리하는 차원에서 기록으로 남깁니다. 이 글을 읽어보..

소프트웨어 유지보수와 테스트 자동화를 어렵게 만드는 주요 요인 중 하나는 의존성(Dependency)입니다. 레거시 코드에서는 특히 static 메서드가 이러한 문제를 심화시키는 경우가 많습니다. static 메서드는 특정한 상태를 가지지 않고 클래스 레벨에서 호출되기 때문에, 객체를 주입하여 대체하기 어렵습니다. 이러한 문제를 해결하는 방법 중 하나가 Introduce Instance Delegator 기법입니다. 이 기법은 기존 static 메서드를 인스턴스 메서드로 감싸서 객체를 통해 호출할 수 있도록 만드는 방식입니다. 이를 활용하면 기존 코드를 크게 변경하지 않으면서도 의존성을 줄이고, 테스트 가능성을 높일 수 있습니다. Introduce Instance Delegator 기법 적용Introdu..

소프트웨어 유지보수와 테스트 자동화를 어렵게 만드는 주요 요인 중 하나는 의존성(Dependency)입니다. Working Effectively with Legacy Code에서 소개된 "인터페이스 추출(Extract Interface)" 기법은 이러한 의존성을 줄이고, 테스트 가능성을 높이는 데 중요한 역할을 합니다. 이번 글에서는 인터페이스 추출 기법의 개념과 이를 활용하여 코드의 테스트 가능성을 높이는 방법을 살펴보겠습니다.1. 인터페이스 추출이란?인터페이스 추출(Extract Interface)은 기존 클래스에서 특정한 역할을 수행하는 메서드들을 추출하여 새로운 인터페이스를 정의하는 기법입니다. 이를 통해 기존 코드의 직접적인 의존성을 줄이고, 테스트를 위한 대체 구현(Fake, Mock 등)을 ..