목차
제가 진행한 세미나의 발표 스크립트를 글로 작성한 내용 입니다.
세미나 소개문
우리는 개발할 때 클린 아키텍쳐, 결합도 제거, 리팩토링, 관심사의 분리와 같은 원칙에 진심입니다.
하지만 스파게티 같은 업무 상황은 그냥 스트레스 받으면서 끌려다니고 있진 않나요?
저는 코드에서 사용하는 좋은 설계 원칙들이 업무에도 적용될 수 있다고 생각합니다.
이번 세미나에서는 업무 의사결정, 협업, 일정 관리, 커뮤니케이션과 같은 업무에서 이 원칙들을 어떻게 활용할 수 있는지, 제 사례와 함께 생각을 공유드리겠습니다.
※ 주의점
- 회사, 부서마다 상황이 다를 수 있습니다.
- 전 운영 경험은 거의 없습니다.
- 이 세미나는 논문이나 원론이 아니라, 제 사고방식과 생각을 공유하는 세미나 입니다.
들어가며
참 좋은 답변이죠. 하지만 회사를 자주 옮겨다녀야할 수 있습니다. 그럼 어떤식으로 답변해야할지 한번 생각해보죠.
개발자는 기술 전문가 입니다. 개발자가 받을 스트레스는 저런 것들이 있죠.
기술 때문에 받는 스트레스는 성장으로 이어집니다.
하지만 기술 외적인 ‘업무 노이즈’ 때문에 소모되는 스트레스와 감정 소모는 불필요합니다.
전 개발 원칙은 철학이라 생각합니다.
SRP, 결합도, 캡슐화, DDD… 이 원칙들은 코드에만 적용할 수 있는게 아닙니다.
업무에도 적용할 수 있습니다.
좋은 스트레스와 나쁜 스트레스를 좀 더 명확히 하기 위해, 우선 개발자의 오너쉽부터 생각해보겠습니다.
반면 스파게티와 같은 업무는 외부 노이즈에 해당합니다. 직접적 노이즈도 있을테고, 스스로 만든 파생 노이즈도 있겠죠.
단, 스파게티와 같은 업무 말고 스파게티 같은 코드는 저희의 책임이 맞습니다.
이번 세미나에서는 업무 의사결정, 협업, 일정 관리, 커뮤니케이션과 같은 업무에서 개발 원칙들을 어떻게 활용하여 외부 노이즈를 줄일 수 있는지, 제 사례와 함께 생각을 공유드리겠습니다.
CASE1. 일정 결합도 최소화 하기
사내 플랫폼 서비스에서 사용될 수 있도록 Micro Service 형태로 API를 만들어두었습니다.
이미 사내 플랫폼 서비스에서는 해당 API를 사용중입니다.
영업 쪽을 통해 타 업체에서도 해당 API를 사용하려고 하는 상황입니다.
그런데 해당 타 업체에서 요구사항을 제시한 경우 입니다.
이걸 대충 “내부 협의 후 말씀드릴께요”, “확인 후 연락드리겠습니다.”, “가능해보이긴 한데 좀 알아봐야겠네요.” 이런식으로 답변할 경우, 무조건 상대방은 “언제까지 가능한가요?”, “언제쯤 회신 주실 수 있을까요?”, “저희 일정은 그 기능이 될 때 맞춰야 해서요” 등 일정 결합 스파게티가 시작됩니다. (시간 결합도)
그때마다 하던 일을 멈추고(Context Switching) 다시 고민해야 하는 비용이 발생하게 됩니다.
또한 타 업체에서는 이 기능이 만들어지는 시점을 기반으로, 본인 서비스의 오픈 일정 잡을 수 있습니다.
따라서 제가 원한건, “이 기능은 현재 지원이 불확실하다. 이 기능을 기준으로 오픈 일정을 잡지말아라.” 라고 말하는 것 입니다.
또한, 이후 부가적인 외부 노이즈(”언제까지 가능한지 연락주실껀가요?”)가 생기지 않도록 하는 것도 목표였습니다.
실제로 답변한 내용은 이랬습니다.
제가 원하는것을 이루기 위해 적용한 개발 원칙들을 얘기해보겠습니다. 우선 이건 비단 이 경우 뿐 아니라 대부분의 경우 통용됩니다. 기본적으로, 굳이 내부 정보를 외부에 자세히 알릴 이유가 없습니다.
현재 이 프로젝트는 "메인 프로젝트가 아니다"와 같은 내부 리소스의 자세한 상황, 프로젝트 우선순위, R&D 난이도 이런 건 타 업체에게 필요한 정보가 아닙니다.
외부에는 그저 “현재 확약 불가 / 일정 전제로 삼지 말라” 라는 확정된 인터페이스만 제공하면 됩니다.
외부는 ‘결과’만 알면 됩니다. 내부 구현(사정)은 숨겨도 됩니다.
기술적으로 가능해 보여도, 불확실성이 있는 요구사항은 조기 리턴이 나을 수 있습니다.
이 과정을 미루면 “그럼 언제까지 검토해주실꺼에요?”, “그럼 우선 PoC까지만 해주실 수 있나요?” 이런 가지들이 생겨날 수 있습니다. 불확실한 기능 요청은 초기에 명확하게 처리해야 뒤에 나올 브랜치 전체가 날아갑니다.
상대방이 원하는건 소수점 기능 완료를 전제로 서비스 도입 일정을 묶는 것일테죠.
제가 원하는건 도입 일정과 소수점 기능 개발 추가 요구사항을 분리하는 것 입니다.
이 케이스에서는 제가 원하는쪽으로 흘러가도록 하여 일정 결합도 자체를 만들지 않을 수 있었습니다.
가능한지 여부가 문제가 아닙니다. 기술적으로 불가능하다고 판단되었다면 이보다 더 강하게 답변했을겁니다.
기술적으로 가능하더라도 불확실한 약속은 서로의 일정 전체를 블로킹 시킵니다.
이 경우 명확한 답변이 비동기 처리의 기본 전략이라 생각합니다.
일정에 여유가 있다면 해줄수도 있겠지만, 현재 내부 사정이 그렇지 않은 경우 입니다.
여기서 두루뭉술한 답변은 곧바로 무한 polling을 부릅니다. 개발과 똑같습니다
CASE2.불가능한 요구는 명확히 거절하기
기존에 저희 부서에서 만든 플랫폼 서비스가 있습니다. 현재는 다른 부서에서 운영중이죠.
해당 서비스에 필요한 기능들이 있었습니다. 사내의 정식 요청은 아니었으나, 재밌어 보여서 주말에 취미로 만들었는데 생각보다 쓸만해보여서 사내에 알리고 정식 프로젝트로 해당 플랫폼 서비스에 적용해둔 상황입니다.
AI관련 N개의 기능이 있고, 스프링AI + 파이썬 마이크로 서비스 + LLM 으로 구성된 여러 기능의 API 모음 같은 토이 프로젝트입니다. 영업 쪽에서 외부 업체에서도 써도 되냐고 문의가 들어왔습니다. 별 생각없이 “API 문서 있으니, 정산 ID만 발급되면 쓸 순 있어요” 라고 했습니다. 근데 알고보니 기존 사내에 제가 새로 만든 N개의 기능 중 하나에 대한 ML 기반 특화 솔루션이 있었는데, 타 업체 입장에선 높은 비용과 버전문제로 현재 해당 솔루션의 사용이 번거로운 상황 이었습니다.
즉, 영업 쪽에서는 해당 ML의 대체품으로써 외부 업체에 얘기한거죠. 이에 따라 외부 업체에서는 속도 관련 이슈를 제시했습니다.
우선 레거시 솔루션에 대해 알아봤습니다. 수만 장의 이미지로 학습한 전용 ML 모델 기반 온프레미스 솔루션 서비스였습니다.
제가 만든 건 주말 개인 토이프로젝트이고, N개의 기능을 API로 제공중입니다. 레거시와 비슷한 기능은 그 중 하나의 API일 뿐이고, 기존 레거시와 달리 해당 기능은 이미지 100~200장 가량정도로 테스트하면서 만든 것입니다.
애초에 제가 타겟으로 잡은 서비스는 속도가 그렇게 중요하지 않았으므로, 타겟으로 잡은 플랫폼 서비스에서도 채택되어 사용중인 상황이었죠. 또한 ML이 아니라 LLM 기반이므로, 애초에 응답 시간의 90%가 LLM의 응답시간이라 시간을 크게 줄일 수 없는 상황이었습니다.
더 빠른 경량화 LLM 모델 사용 시 응답 시간은 빨라지지만, 정확도가 30~40% 가량 떨어지는 트레이드오프 존재했죠.
즉, 레거시보다 싼 가격에 레거시의 1초 이내 응답은 불가능한 상황입니다.
이용기관에서는 유지관리도 쉽고(온프라미스 vs API), 비용도 싸서 제가 신규로 만든걸 쓰려고 했지만,
제가 원하는 건 기술적으로 불가능함을 명확히 전달하고, 추가 요구를 끊는 것이겠죠.
실제 답변 내용은 이와 같았습니다.
추가로, 말할 때 마다 "~인 것 같습니다."로 답변하는 분들도 가끔 보입니다. 엄청 자신감 없어보입니다.
본인의 영역에 해당하는 부분에 대해서는 확정적인 어휘를 쓰시는게 좋습니다.
제 경우에도 나머지는 확정적인 어휘이고, 레거시에 대한 부분만 "~로 보입니다" 형태로 쓰인걸 보실 수 있습니다.
이번에도 개발 원칙과 비교해 생각해보죠.
소프트웨어 공학의 대원칙. 모든 것을 만족하는 마법 같은 솔루션은 없습니다.
범용성 vs 특수화 : 레거시는 특수화 되어 빨랐고, 제껀 범용화 되어 느립니다. 대신 비용이 싸죠.
고객은 둘 다 원했지만, 저는 이게 구조적 트레이드오프임을 명확히 하여,
속도 저하가 버그가 아닌 설계된 특성임을 인지시키려 했습니다.
캡슐화는 여전히 중요합니다. 내부적으로는 ‘주말에 만든 토이프로젝트’,’ 적은 학습 데이터’라는 초라한 디테일이 있습니다.
결론적으로는 여러 기능을 제공하는 사내 공용 API와 같은 형태가 되었고, 레거시와 동일한 기능에 대해서도 거의
동일하거나 그 이상의 정확도가 나오면서도 가격은 더 싸게 가능한 결과가 나왔습니다.
다만 이 과정에서 속도까지 챙길 순 없었습니다.
내부 관계자라면 이러한 세부사항을 말해도 상관 없습니다. 하지만 외부에 이를 노출하는건 다른 얘기입니다.
“제가 주말에 따로 만든거라서요”, “아 기존껀 수만장으로 학습한거고, 전 100~200장가지고 만든거에요.” 라고 했다면 신뢰를 잃겠죠. 그래서 ‘공통 모듈 설계’와 ‘구조적 특성’이라는 고수준의 인터페이스로 캡슐화하여 소통했습니다.
멱등성은 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 말합니다.
답변 후 여러 곳에서 연락이 왔지만(재시도), 제 대답은 변하지 않았고 상대방 모두 납득했습니다.
왜냐면 단순히 일하기 싫은 핑계가 아니라, 기술적 팩트에 기반했기 때문입니다.
물론 상대방에 따라 대화의 추상화 수준은 바뀔 수 있습니다.
개발자끼리거나 내부 개발자 끼리라면, Transactinal Consistency 보장이 불가합니다. 이래도 되겠죠.
근데 상대방이 비개발직군이라면, 주문은 됐는데 결제는 안 되는 클레임이 발생할 수 있어요. 이런식으로 얘기해야겠죠.
이 시스템이 유지해야 하는 아키텍처적 철학이 있습니다. 이 불변을 깨지 않고는 1초이내의 속도 SLA는 불가능한 상황이죠.
이 케이스는 기능 추가 여부의 문제가 아니라, 요구 자체가 시스템 구조와 충돌한 케이스 입니다.
기술적으로 불가능한 요구는 ‘조심스럽게 돌려 말하는 것’이 아니라, 기술적 기준을 명확히 제시하며 거절해야 합니다.
안 되는 건 안 된다고 말하는 것이 기술 전문가의 윤리라 생각합니다. 기술적 판단이 섰다면, “노력해보겠습니다.”가 아니라,
기술적 경계를 지키며 불가능한 요구를 걸러내는 것이 좋습니다. 그렇지 않으면 실패할 수 밖에 없는 프로젝트에 모두를 끌어들이는 무책임한 행동을 하게 되는겁니다.
요구를 얼마나 많이 들어주느냐가 중요한게 아니라, 시스템이 어느 선까지 책임질 수 있는지 정확히 이해하고 고객에게 그 경계를 명확하게 안내해줘야 합니다.
단점을 숨기려다 변명하지 말고, 당당하게 트레이드오프라고 설명하시면 됩니다. 엔지니어링에서 공짜는 없습니다.
감정이나 상황에 따라 답이 바뀌면 상대는 다양한 방향으로 공격해옵니다. 논리가 팩트에 기반하면, 방어는 멱등성을 가집니다.
이 케이스의 핵심은 요구가 틀려서가 아니라, 대상 시스템이 그 요구를 충족시키는 구조가 아니었다는 점 입니다.
CASE3. 요구를 수용하더라도 코어는 지켜라
CASE1, CASE2는 모두 요청을 거부한 상황입니다. 하지만 언제나 YES, 언제나 NO는 답이 아닙니다.이번엔 요구를 수용한 케이스를 한번 살펴보겠습니다.
사내 플랫폼 서비스를 타겟으로 한 Micro Service 형태로 API를 만들어둔 상황입니다.
이미 사내 플랫폼 서비스에서는 해당 API를 사용중입니다.
타 업체에서도 해당 API를 사용하려고 하는 상황입니다. 해당 업체는 기존 비슷한 기능의 다른 서비스를 사용중이었습니다.
해당 서비스의 API 스펙에 맞춰, 본인 업체의 N개의 서비스를 만들어둔 상황이고, 이에 따라 위와 같은 요구사항이 들어왔습니다.
기존 타겟은 사내의 플랫폼 서비스이지만, 기능 특성상 앞으로도 외부 업체에서 계속 사용을 요청할 수 있다고 판단했습니다.
즉, 이번 한 번이 아니라 이후에도 유사한 형태의 데이터 형식 변경 요구가 반복될 수 있다고 판단되었습니다.
그렇더라도 메인 비즈니스 로직(코어 도메인 모델)을 건드리고 싶지 않은거죠.
실제 메일 내용은 이러했습니다.
즉, 수용한 경우입니다.
이번엔 소프트스킬과는 약간 다르게, 수용하더라도 메인 로직을 건드리지 않는 경우에 대한 약간은 개발적인 얘기입니다.
개방 폐쇄 원칙의 경우 설명만 보면 헷갈리실 수 있으나, 결국 기존 코드를 수정하지 않고 기능 추가가 가능하냐는 원칙입니다.위 코드가 일반적으로 아무생각 없이 업체별로 기능을 추가 할 때 사용할 수 있는 방식입니다.이 경우 서비스던 도메인이던 업체 추가시마다 기존 메인이 되는 로직이 변경될 수 밖에 없습니다.
아래쪽의 경우, 저 코드는 이후 변경되지 않습니다.
즉, 코어 로직은 수정에 닫혀 있습니다.
새로운 고객사가 들어오고 데이터 형식 변경 요구가 있을 경우, 해당 서비스의 운영팀에서는 해당 고객사 어댑터 클래스만 추가로 만들면 됩니다. 참고로 저런식으로 생성자 주입 받을 시, 해당 인터페이스를 구현한 컨테이너 내 모든 빈이 저기에 박히게 됩니다. 그리고 객체지향적으로, 역으로 adapter에게 너가 지원 가능하냐고 물어보고, 지원 한다고 하면 그냥 그대로 위임하면 끝이죠.
고객 특화 처리는 어댑터에서 처리하고, 도메인 핵심은 외부 규격에 절대 끌려가지 않는거죠..
개발자의 오너쉽은 무조건적인 YES, 무조건적인 NO에서 오지 않습니다.
필요한 요구사항이라면 그걸 받아들일 수도 있습니다. 하지만, 코어는 함부로 열면 안됩니다.
즉, 고객 특화 처리는 인터페이스로 처리하되 도메인 핵심은 외부 규격에 맞추면 안됩니다.
만약, 코어의 데이터를 가공하여 어댑터를 만들 수 없는 상황이었다면 전 이 요구사항에 대해 거절하거나 다시 생각해봤을 겁니다.
개발자의 오너쉽은 모든 요구에 대한 YES/NO의 문제가 아니라 ‘기술적 판단 기준을 중심으로, 어디까지 코어로 받아들이고, 어디까지 외부로 밀어낼지 판단하는 능력’ 입니다.
CASE4. 역할, 책임, 협력
존경하는 개발자인 조영호님의 객체지향의 사실과 오해, 오브젝트 책에서 자주 쓰인 말 입니다. '역할, 책임, 협력'. 객체지향의 근본이기도 한 이 단어들을 전 매우 좋아합니다.
주니어인 친한 동생의 신세한탄을 듣고, 제가 조언한 내용 입니다.
상황은 한마디로, 3개의 업체가 협력을 해야하는데 그 중 하나의 업체가 트롤링해서 친구에게 해달라고 때쓰는 상황입니다.
해당 업체의 메일을 보여드릴순 없으니 정리하면 다음과 같습니다.
1. 서로 인터페이스 정해져 있고 협력해야 하는상황에서, 갑자기 신세한탄을 엄청나게 구체적으로 함 (캡슐화 실패). 친구네 회사에서 알 필요도 없는 구구절절한 "우리 할게 생각보다 많다"는 내용을 엄청 구체적으로 말합니다.
-> 요구사항 분석 및 초기 설계를 완전히 실패한거죠. 심지어 캡슐화도 안된 메일입니다. 이러면 엄청 구차해보입니다. 알게뭐야 변명하려고 장황하게 적는건가? 느낌이 들 수 밖에 없죠.
2. "X사 일정을 맞추기 위하여 죄송하지만 A사에 협조 부탁드립니다." -> 너네가 해줘.
3. "저희 보다 ~~에 경험이 많으신 A사에서 함꼐 개발을 해주시면 일정에 문제가 없이 가능합니다." -> 안 하면 전부 일정 터져 ^^
만약 제가 저 메일을 받았으면 전 저 업체랑 절대 일 안한다고 했을것 같네요. 사실 친구한테 질문 받은거지만 제가 열받더라고요.
여기서 친구는 주니어급이고, 최근 팀이 변경되어 저런 경우를 잘 몰랐던 것 같습니다.
혼자 멘탈 터지기 전이더라고요.
사실 이런건 어려운 문제가 아닙니다.
어차피 친구가 받아도 기존 정해진 일정을 못지키는거고, 안받아도 업체간의 관계를 개발자 그것도 주니어가 신경쓸 필요가 없죠.
그냥 상급자로 올려서, 요청을 받더라도 리스크 파악 후 정식 일정 받아서 처리해야 하고, 거절하더라도 영업 쪽에서 처리할 일입니다.
그래서 전 저렇게 조언을 해줬습니다.
즉, 혼자 경우의 수 생각하면서 스트레스 받지 말고, 본인 책임 범위 밖이 아니라면 그냥 그걸 처리할 수 있는 역할로 위임하고 끝내라는 얘깁니다.
객체지향에서 객체는 모든 책임을 혼자 지지 않습니다.
역할은 분리되어 있고, 협력은 메시지로 이루어지죠.
지금 상황은 이미 협력 구조가 깨진 상황입니다.
Z사가 자기 책임을 캡슐화도 없이 A사로 넘겼고,
A사 내부에서도 개발자에게 “역할 밖의 책임”을 얹으려 한거죠.
결과적으로 A사 친구는 SRP가 깨진 객체처럼 과부화가 온 상황이고요.
개발자가 판단하면 안 되는 문제는 즉시 상위 객체로 위임하고 early return 해야 합니다.
이는 책임 회피가 아니라 정상적인 협력 구조입니다.
회사마다, 부서마다 다를 순 있겠지만 이건 기본적인 구조 입니다.
개발자는, 그것도 주니어는 일정/계약/범위 조정 도메인에 대한 책임을 가지고 있지 않습니다.
이걸 가지고 스스로 만들어낸 파생 노이즈로 혼자 고민하며 스트레스 받을 필요가 없어요.
만약 상급자가 처리 안해주면요?
더 위로 올리세요. 그래도 처리가 안되면 다소 공격적으로 보일 수 있으나 이런 방법도 있습니다.
그냥 윗선에다가 날짜 박아서 "몇일까지 결정 안해주실 경우, A안으로 진행하겠습니다." 이렇게요.만약 그걸 받고 이후 왜 A안으로 결정했냐고 책임을 씌우려 할 경우, 상급자라도 싸대기 날리셔도 됩니다.그 경우까지 가면 애초에 해당 회사의 역할,책임,협력이 깨진겁니다. 정상적인 회사라 생각되진 않네요.
친구의 컨텍스트
- 최초 요구사항 기반으로 개발
- 약속된 일정 내 구현
- 테스트 데이터 준비 대기 및 기능 완성
- 즉. “개발 수행”이라는 도메인을 책임지는 컨텍스트
상위 결정권자의 컨텍스트
- 계약 범위 재협상
- 일정 조정
- 대외 커뮤니케이션
- 시스템 흐름 조정(양방향/중계 구조 변경 여부 및 그에 따른 리스크 판단)
- 즉, “협상 & 의사결정”이 책임인 별도의 컨텍스트
이 둘은 A사 내의 분리된 도메인입니다. 참고로 헥사고날이 도메인 외의 것을 외부로 처리하는 거라면,
이 경우는 도메인 내에서의 경계에 대한 얘기입니다.
친구가 스트레스 받은 이유는, 자기 바운디드 컨텍스트 밖의 문제를, 자신의 컨텍스트 안에서 해결하려 했거나, 본인 컨텍스트인줄 알았기 때문입니다.
즉, 도메인 A의 규칙을 도메인 B가 억지로 해결하려고 해서 모델이 깨지는 상황입니다.
올바른 협력 모델은 이렇겠죠.
친구 → 상위 결정권자 : 이런 요청이 들어왔고, A안/B안이 있습니다. 이에 따른 리스크는 다음과 같습니다.
상위 결정권자 → 친구 : B안으로 가. 일정은 내가 조율할게
이 케이스는 기술 문제가 아니라, 회사간 협력 구조가 무너진 케이스 입니다.
여기서 개발자는 역할 경계를 명확히 하고 책임을 상위로 위임하는 능력이 필요합니다. 능력이라기보다, 사실 당연한 겁니다.
SRP가 깨지면 객체가 망가지듯, 사람도 괜히 SRP 생각 안하고 혼자 감당하려 하면 깨지면서 번아웃이 납니다.
마치며
회사마다, 부서마다 다를 수 있겠으나 개발자가 겪는 요구사항의 대부분은 기술 자체보다
상황, 역할, 관계, 협력, 트레이드오프 같은 정답 없는 문제들에서 출발하곤 합니다.
기술 스트레스는 성장을 만듭니다.
하지만 외부 노이즈(”계약 어렵게 딴거라 이건 무조건 해줘야돼”)와 내가 만든 파생 노이즈(”하 거절해야 되는데 어떻게 거절할지도 모르겠고.. 받아도 일정 밀리고 나 야근해야되는데 ㅠ”)는 낭비일 뿐입니다.
이번 세미나에서 다룬 네 가지 케이스는 서로 다른 상황처럼 보이지만, 사실 하나의 메시지를 말합니다.
“개발자는 언제나 Yes나 No만 말하는 사람이 아닙니다. 핵심은 어떤 기준으로 판단하고, 무엇을 지키며, 어떻게 협력하느냐 입니다.”
이런 의미에서 개발 원칙들은 개발자의 업무에 적용하기 좋은 철학적 틀이 되어준다고 생각합니다.
기술적으로 가능해보이긴 하나 확실치 않고 현재 일정도 애매하다면, 가볍게 안된다고 해야할 수 도 있습니다.
기술적으로 불가능한 경우 단호하게 안된다고 해야할 수도 있죠.
고객의 니즈가 코어를 건드리지 않는다면, 유연하게 된다고 할수도 있습니다.
제일 중요한건 역할 밖의 책임이 넘어오면, 그냥 해당 역할로 위임하고 빠르게 리턴 때리세요. 스트레스 받지 마시고.
제가 CASE2에서 여러 재시도를 받고도 멱등성을 유지할 수 있었던 건, 구조적 한계를 기술적으로 정확히 이해하고 있었기 때문입니다.
개발자로서, 결국 중요한건 개발자로써의 오너쉽이겠죠.
기술적 실력이 없으면 논리는 결국 공허한 말장난이 될 수도 있습니다.
은탄환은 없습니다.
우리는 트레이드오프를 보고, 판단 기준을 세우고, 조금씩 더 나은 결정을 해나가면 됩니다.
또한 여러분의 실력(납 탄환)을 더 무겁고 단단하게 만드시는데에도 힘쓰셔야 합니다.
마지막으로,
스파게티 코드는 리팩터링하면서, 스파게티 업무는 그냥 당하고 계시진 않았으면 좋겠습니다.
감사합니다.
'Development > 기타 개발관련' 카테고리의 다른 글
| [2025-09-29 업데이트(윈11)] 개발자 윈도우 세팅 (WSL, IntelliJ, vscode, git, docker 등) (5) | 2025.09.29 |
|---|---|
| 선택도가 높은게 좋을까? DB 인덱스 설계 시 '선택도'가 헷갈리는 이유 (5) | 2025.07.07 |
| 내가 사내 기술 공유를 어렵게 만든게 아닐까? (1) | 2025.07.02 |
| 한글 초성검색 날로먹으려다 실패한 후기 (2) | 2025.05.08 |
| 개발자가 질문하는 방법 (회사, 상사, 커뮤니티, 개발관련 질문 등) (25) | 2024.02.25 |
댓글