내 머리속 지우개

소프트웨어 공학이라는 말을 들으면 대개는 소프트웨어를 개발하는데 도움을 주는 학문 또는 체계적이고 과학적인 소프트웨어 개발 방법론을 떠올립니다. 예측 가능한 일정, 안정적인 품질, 반복 가능한 결과. 하지만 실제 개발 현장에서는 이 이상적인 개념들이 종종 현실의 벽에 부딪힙니다. 특히 프로젝트가 복잡해지고, 요구사항이 자주 변하며, 일정은 항상 촉박한 상황에서는 “소프트웨어 공학을 적용한다는 것” 자체가 부담으로 다가오기도 합니다. 그리고 최근 몇 년 사이에는 AI 기술이 급속도로 발전하면서, 복잡한 분석이나 예측 업무까지 자동화가 가능해졌지만, 그조차도 현실에 곧바로 녹아들기에는 여전히 많은 간극이 존재합니다. 이번 포스팅에서는 어떤 이론이나 도구, 또는 기술 기술이 ‘좋다’ 혹은 ‘나쁘다’라는 판단보..

지난 포스팅에서는 소프트웨어 변경을 바라보는 눈을 기계적으로 ‘어디가 바뀌었는가’에만 두지 말고, 이를 구조화된 기술적 기준으로 분석해야 한다는 점을 살펴보았습니다. 예를 들어, 아키텍처가 바뀌었는지, 알고리즘이 달라졌는지, 혹은 파라미터만 살짝 조정되었는지를 구체적으로 구분하는 것만으로도 변경관리의 품질이 높아졌다는 피드백을 많이 받았습니다. 2025.07.07 - [Software Engineering] - 어떤 소프트웨어 변경이 관리되어야 하는가? - 기술적 기준 어떤 소프트웨어 변경이 관리되어야 하는가? - 기술적 기준소프트웨어 개발은 끊임없는 "변화의 연속"입니다. 기능이 추가되고, 로직이 개선되며, 운영 환경이 진화합니다. 이렇게 수시로 발생하는 변경을 무작정 수용하거나, 반대로 지나치게 통제..

소프트웨어 개발은 끊임없는 "변화의 연속"입니다. 기능이 추가되고, 로직이 개선되며, 운영 환경이 진화합니다. 이렇게 수시로 발생하는 변경을 무작정 수용하거나, 반대로 지나치게 통제하는것 모두 소프트웨어의 품질과 신뢰성, 나아가 조직의 지속 가능성에 부정적인 영향을 줄 수 있습니다. 따라서 어떤 변경을 어떻게 반영하고, 어떻게 관리할 것인가? 라는 질문에 명확한 기준을 세울 필요가 있습니다. 특히 안전이 중요한 자동차, 의료기기, 항공 소프트웨어에서는 이 기준이 단순한 운영 원칙이 아니라 품질 보증과 생명 안전을 위한 설계 규범이 됩니다. 또한, 소프트웨어 변경 기준은 단순히 "어떤 변경은 크고, 어떤 변경은 작다” 또는 "어떤 변경은 중요하고, 어떤 변경은 중요하지 않다"는 식으로 정의할 수 없습니다...

변화하는 세계 속, 새로운 인공지능의 필요아침에 눈을 뜨자마자 우리는 여러 감각으로 세상을 인식합니다. 창문 너머로 들려오는 자동차 소리, 새 소리, 손끝에 닿는 이불의 감촉, 창밖으로 비치는 햇빛의 밝기. 이처럼 인간은 하나의 감각이 아닌 다양한 감각의 조합을 통해 세상을 종합적으로 이해합니다. 마찬가지로, AI가 사람과 자연스럽게 상호작용하려면 글이나 말뿐 아니라 이미지, 소리, 심지어 동작까지 함께 이해해야 합니다. 바로 이것이 멀티모달 AI가 주목받는 이유입니다. 멀티모달 AI는 "텍스트, 이미지, 오디오, 비디오와 같은 다양한 데이터 형태를 동시에 처리하고 통합적으로 이해할 수 있는 AI"입니다. 기존의 텍스트 기반 AI가 한 가지 형태의 정보만을 다룰 수 있었다면, 멀티모달 AI는 “사람처럼 ..

2025.07.07 - [Software Engineering] - 어떤 소프트웨어 변경이 관리되어야 하는가? - 기술적 기준 어떤 소프트웨어 변경이 관리되어야 하는가? - 기술적 기준소프트웨어 개발은 끊임없는 "변화의 연속"입니다. 기능이 추가되고, 로직이 개선되며, 운영 환경이 진화합니다. 이렇게 수시로 발생하는 변경을 무작정 수용하거나, 반대로 지나치게 통제하는habana4.tistory.com 1. 변화는 작지만, 책임은 크다우리는 종종, 무언가 ‘작다’는 이유만으로 그것의 중요성을 과소평가하곤 합니다. 소프트웨어 개발 현장에서도 마찬가지입니다. 변수 하나의 이름을 바꾸는 일, 로그 메시지를 조금 다듬는 일, 함수 안쪽의 코드 몇 줄을 정리하는 일은 언뜻 보기에는 하찮아 보입니다. 개발자는 이를 ..

적은 인원으로 운영되는 소프트웨어 개발 조직에서는 개발자들이 매일 전쟁과도 같은 일정 속에서 코드를 작성하고, 버그를 잡고, 기능을 배포하며 하루하루를 보냅니다. 이런 현실 속에서 “이 기능에 대한 문서도 작성해 주세요”라든지 “게이트 점검을 위해 설계서를 제출하세요” 같은 요청이 들어오면, 개발자들은 본능적으로 거부감을 느끼게 됩니다. “우리는 애자일인데, 애자일은 문서화보다는 작동하는 소프트웨어를 중시하는 거 아닌가요?”“도대체 언제 문서화까지 합니까, 코딩도 벅찹니다.”“게이트 문서화는 형식적인 절차일 뿐, 실질적인 개발에는 도움되지 않아요.” 이러한 반응은 단순히 문서화를 싫어해서라기보다는, 그 문서화가 진짜 ‘가치 있는 활동’인지에 대한 의문 때문일 것입니다. 이번 포스팅에서는 이러한 현장의 목..

2025년 6월 22일, 미국 텍사스주 오스틴에서 테슬라가 자율주행 기반의 ‘로보택시(Robotaxi)’ 서비스를 시작했다는 소식은 전 세계 자동차 산업은 물론, 도시 모빌리티의 미래에 강한 충격을 주었습니다. 기존에도 자율주행 시범사업은 많았지만, 대중적 상징성과 시장 파괴력을 동시에 가진 기업인 테슬라가 상용 서비스를 시작했다는 점에서, 자율주행 기술이 본격적인 시장 진입 단계로 접어들었다는 평가가 가능해졌습니다. 이와 동시에, 우리는 이 기술이 과연 충분히 안전한가라는 오래된 질문을 다시 던지지 않을 수 없습니다. 자율주행 기술의 상업적 성공을 좌우하는 ‘열쇠’는 아마도 사용자 경험, 서비스 속도, 운영 효율, 그리고 비용 경쟁력일 수 있습니다. 그러나 이 모든 요소를 가능하게 만드는 기반 중의 기..

우리가 매일 사용하는 기술 시스템 속에는 수많은 ‘프로세스’가 작동하고 있습니다. 또한 이러한 시스템들이 우리의 생명과 재산을 위협하지 않도록 ‘안전’이 설계되어 있습니다. 하지만 이 모든 것들은 대부분 눈에 보이지 않습니다. 그리고 이 ‘보이지 않음’—즉, 비가시성(Invisibility)은 곧 신뢰의 부재와 문제 발생 시 무력함으로 이어집니다. 기술이 고도화될수록, 시스템은 복잡해지고, 그 안에서 작동하는 절차와 보호장치는 점점 더 추상적이고 불투명해집니다. 이는 특히 자동차, 철도, 항공, 제조 산업 등 사람의 생명과 직결되는 영역에서 매우 중요한 이슈가 됩니다. 이번 포스팅에서는 ‘프로세스’와 ‘안전’이 왜 비가시적인 존재가 되었는지, 그로 인해 발생하는 문제는 무엇인지, 그리고 어떻게 하면 다시..

1. 왜 지금, 전기차를 고민해야 하는가?2025년 현재, 국내 전기차(EV) 시장은 기술적 완성도와 인프라의 발전으로 빠르게 대중화되고 있습니다. 충전소의 확산, 차량 성능의 향상, 제조사의 다양한 모델 출시, 그리고 정부 및 지자체의 보조금 정책은 전기차에 대한 심리적, 경제적 진입 장벽을 낮춰주고 있습니다. 하지만, 전기차는 단순히 연료 방식이 바뀐 ‘자동차’가 아니라, 새로운 사용문화와 기술이 결합된 복합 소비재입니다. 이로 인해 구매자는 내연기관차보다 훨씬 더 많은 고려 사항을 분석해야 합니다. 2. 전기차 구매 시 고려해야 할 핵심 요소2.1. 주행거리 (1회 충전 기준)가장 먼저 확인해야 할 것은 완충 시 최대 주행거리입니다. 최근 국내에 출시된 차량의 경우 300km~600km 사이로 다..

Feature와 Function의 정의1.1 Function국제표준 ISO/IEC/IEEE 24765:2017는 Function을 다음과 같이 정의합니다:“A function is a defined objective or characteristic action of a system or component, typically described in terms of inputs, behavior, and outputs.” 이는 시스템이나 컴포넌트가 특정 입력에 대해 수행해야 하는 동작, 혹은 제공해야 할 계산, 처리, 제어 동작을 말합니다. 즉, function은 시스템 동작의 기본 단위이며, 구현 가능하고 검증 가능한 작업 단위입니다. 또한, ISO/IEC/IEEE 29148:2018 (Systems an..