내 머리속 지우개

SW Qualification - 안해도 당장은 굴러간다!

오늘 조금 특별한 만남이 있었습니다. 시간은 짧았지만, 흔치 않은 주제로 이야기를 나누다 보니 개인적으로 정말 재밌고 유쾌한 시간이었습니다. 그런데 대화가 진행될수록, 마음 한켠에 묘한 안타까움이 퍼졌습니다. 아마도 오늘의 주제가 Code Library Qualification이었기 때문일지도 모르겠습니다.국내에서는 이 주제에 대한 정리된 사례가 아직 드물고, 심지어 OEM도 필요성은 인식하면서도 실제 개발과 양산의 전면에 세우지 못하는 경우가 많다는 이야기가 나왔습니다. 특히 자동차 소프트웨어 분야에서 라이브러리의 잘못된 사용은 안전과 신뢰성과 맞닿아 있는데도, 현실의 우선순위 속에서는 자주 “나중에 하자” 또는 "업체가 해야 할 일이야"로 밀리는 장면이 겹쳐 보였습니다.사실 실제 개발 현장에서는 라이..

프로젝트를 시작할 때, 보통 업무 분장(R&R, Role and Responsibility)을 결정합니다. 각 업무별로 책임자(R)를 지정하고, 도와주는 사람(S)도 결정합니다. 그런데, 이 과정에서 많은 사람들이 각 역할에 대해 오해를 하고 있는 걸 쉽게 볼 수 있습니다.“S는 지원이니까 필요하면 좀 도와주면 되죠?”“R이 다 해버리면 더 빨라요.”“R을 둘이서 수행하면 더 확실하지 않나요?”얼핏 들으면 모두 합리적으로 보입니다. 하지만 이런 이야기는 팀의 작업 속도를 잠깐 끌어올릴 수는 있을지 모르지만, 종국에는 품질을 흔들고 일정과 신뢰를 무너뜨리는 위험한 착각입니다. 먼저, “S는 지원이니까 대충 도우면 된다”는 생각부터 고쳐야 합니다. S는 단순 심부름이 아니라 작은 책임자입니다. 인터페이스 ..

테스트 엔지니어라고 하면 흔히 요구사항에 따라 올바르게 개발되었는지를 검증(Verification)하고, 결과적으로 고객을 만족시킬 수 있는지를 확인(Validation)하는 업무를 수행하는 엔지니어를 의미합니다. 실제 현장에서 테스트 엔지니어들과 함께 일하다 보면, 자주 듣는 말이 있습니다.“테스트 기법에 대해 더 많은 지식을 쌓아야 한다.""테스트 케이스를 더 늘려야 한다.""테스트 커버리지를 더 올려야 한다.”이 접근은 분명 올바른 방향을 제시하고 있습니다. 그러나 테스트 케이스도 늘었고, 자동화 배치도 자주 돌리고, 커버리지 숫자도 올라갔습니다. 그런데 비슷한 유형의 이슈가 필드에서 다시 터집니다. 일정이 반복될수록, 같은 테스트 케이스를 활용하여 지속적으로 테스팅을 수행하고 있음에도 불구하고, ..

주변에서 소프트웨어 개발 효율성과 관련하여 이런 이야기를 많이 듣습니다. "제품 간 공통된 기능은 하나로 묶어서 공용화 하겠습니다."“재사용 가능한 공통 모듈을 정의하여, 하나의 플랫폼으로 통합하겠습니다.”아주 좋은 말이지요. 그리고 처음에는 좋은 의도였을 것입니다.하지만 어느 순간부터 다음과 같은 현상이 나타나기 시작합니다:하나의 공통모듈에 제품 A, B, C, D, E, F의 기능이 다 들어가기 시작합니다.모든 제품 요구를 한 모듈에 ‘옵션’이나 ‘조건 분기’로 추가하다 보니, 그로 인해 소프트웨어 구조는 미로처럼 복잡해집니다.소스 파일 하나가 수천 줄을 넘어가고, ‘어느 조건일 때 이 코드가 실행되는지’는 아무도 확신할 수 없습니다.한 줄의 수정이나 옵션 설정이나 조건 분기 설정 오류로, 수십 개 ..

지난 포스팅에서 하드웨어 플랫폼 개념을 차용한 소프트웨어 플랫폼화에 대한 생각을 정리하며 여기에는 분명 본질적 한계가 있다는 점을 알아 보았습니다. 하드웨어는 공차, 수명, 물리적 규격을 기준으로 공통화를 설계하지만, 소프트웨어는 가변성(Variability), 비가시성(Invisibility)이 존재하는 조금은 특별한 세계입니다. 그래서 소프트웨어 플랫폼의 핵심은 "공통 부품"을 이용한 플랫폼화가 아니라, "가변성"을 이용한 "Configuration"이어야 합니다. 소프트웨어 공용화(플랫폼화)... 잘못된 길로 가는 우리...주변에서 소프트웨어 개발 효율성과 관련하여 이런 이야기를 많이 듣습니다. "제품 간 공통된 기능은 하나로 묶어서 공용화 하겠습니다."“재사용 가능한 공통 모듈을 정의하여, 하나..

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

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

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

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

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