내 머리속 지우개

이번 포스팅은 아래 글은 참고하여 작성하였습니다.참고: https://addyo.substack.com/p/vibe-coding-is-not-an-excuse-for Vibe Coding is not an excuse for low-quality workA field guide to responsible AI-assisted developmentaddyo.substack.comVibe 코딩, 정말 개발자를 대체할 수 있을까?요즘 개발자 커뮤니티를 돌아다니다 보면 “Vibe 코딩”이라는 단어를 종종 보게 됩니다. AI가 코드를 빠르게 작성해주고, 사람은 그걸 그냥 다듬는 정도만 하면 된다는 이야기죠. 어떤 사람들은 이걸 두고, “이제 개발자의 역할이 크게 줄어들 거다”라고까지 말합니다. 솔직히, 저도 처음..

1. 자동차 제어 소프트웨어, 무엇이 사용자를 만족시키는가?요즘 자동차를 떠올리면 단순히 이동수단이라는 말로는 설명이 부족합니다. 스마트폰처럼 똑똑해진 네비게이션, 운전자 없이 스스로 멈추고 가는 크루즈 기능, 부드럽게 연결되는 전기 모터의 가속감까지. 이 모든 것 뒤에는 복잡하고 정교한 자동차 제어 소프트웨어가 숨어 있습니다. 그렇다면, 이렇게 복잡한 소프트웨어가 사용자에게 ‘좋다’, ‘편하다’는 느낌을 주는 건 어떤 순간일까요? 기본 기능이 잘 작동하는 것만으로는 충분하지 않습니다. 우리가 “이 차 괜찮네!“라고 느끼는 건, 기대한 것보다 더 부드럽게 반응하거나, 생각지도 못했던 편리함을 느꼈을 때입니다. 예를 들어, 가속 페달을 밟았을 때 원하는 만큼 자연스럽게 반응하거나, 주차 보조 기능이 매끄럽..

1. 통풍이 보내는 신호, 그리고 우리가 해야 할 일통풍은 단순한 관절의 통증이 아니라, 신진대사 균형의 붕괴에서 기인한 질병입니다. 퓨린(purine)이라는 물질이 요산으로 분해되면서, 이 요산이 혈액에 과도하게 쌓이면 결정이 되어 관절에 침착되고, 극심한 염증과 통증을 유발합니다. 통풍은 한 번의 고통이 아니라, 만성 질환으로 이행할 가능성이 높은 경고 메시지입니다. 특히 최근의 연구들은 통풍이 심혈관 질환, 신장 질환, 제2형 당뇨병과 깊이 연관되어 있다는 사실을 밝혀내고 있으며, 단지 ‘아픈 관절’로만 바라보는 것은 큰 오산입니다. 따라서 통풍은 약물치료와 함께 반드시 식이조절을 병행한 총체적 관리가 필요합니다. 2. 체질을 알칼리화하기 위한 핵심 노력① 채소와 과일 섭취 비율을 압도적으로 높이기..

2025년 4월 10일 킨텍스에서 개최된 서울 모빌리티 포럼 2025에서 "미래 자동차, AI 그리고 안전을 향한 여정" 이란 제목으로 발표를 할 수 있는 기회가 있었습니다. 오랜만에 자료 준비도 재미가 있었지만, 스스로를 돌아 볼 수 있는 기회였다고도 생각합니다. 이번 포스팅에서는 이날 발표한 자료들을 다시 정리해 보고자 합니다.미래 자동차에서의 "안전"의 재정의: 패러다임 전환 속의 위기와 기회자동차는 더 이상 단순한 ‘기계적 이동 수단’이 아닙니다. 디지털 인터페이스, AI 기반 의사결정 시스템, OTA(Over-The-Air) 기능 개선이 적용된 소프트웨어 정의 자동차(SDV, Software-Defined Vehicle)는 이제 이동수단을 넘어서는 ‘지능형 디지털 공간’으로 진화하고 있습니다...

요구사항(Requirement)은 시스템 개발 및 엔지니어링 과정에서 필수적인 요소로, 제품이나 시스템이 기대하는 기능과 성능을 충족하도록 정의하는 역할을 합니다. 잘 정의된 요구사항은 프로젝트의 성공을 결정하는 핵심 요소이며, 이를 체계적으로 작성하는 것이 중요합니다. 국제 시스템 공학 협회(INCOSE, International Council on Systems Engineering)에서 발행한 “Guide to Writing Requirements”는 요구사항을 명확하고 효과적으로 작성하기 위한 지침을 제공하며, 요구사항이 가져야 할 여러 가지 중요한 특징을 정의하고 있습니다. 그중에서도 “단일성(Singluar)”은 소프트웨어 개발과 시스템 설계에서 요구사항이 갖추어야 할 사항을 모두 정의되어야 ..

1. 설렘으로 시작된 자리에 찾아온 깊은 혼란얼마 전, 회사에서 마련한 경영진 간담회에 참석할 기회가 있었습니다. 중간관리자로서 최고경영진(A), 특히 요즘 회사 내외부에서 혁신의 아이콘처럼 조명받고 있는 A를 가까이에서 뵐 수 있다는 것만으로도 무척 기대되는 자리였습니다. 간담회는 조직의 변화, 기술적 전환, 그리고 미래 전략에 대해 보다 진솔한 이야기를 나눌 수 있으리라는 희망을 안고 시작되었습니다. 초반 분위기는 괜찮았습니다. Software Defined Everything이라는 개념에서 출발해, 사내에서 추진 중인 여러 개발 현황들이 공유되었습니다. 처음엔 “우리가 드디어 디지털 전환의 큰 물결을 타고 있구나” 하는 긍정적인 감정도 느껴졌습니다. 하지만 이야기가 점점 진행되면서 상황은 달라졌습니..

비기능 요구사항 작성은 항상 어렵습니다. 표현은 애매하고, 해석은 다르고, 검증은 어렵습니다.비기능 요구사항을 설명하고자 "안정적이게", "빠르게", "사용자 친화적으로"라는 모호한 표현들이 수반되고,이들이 반복될 수록 개발 현실에서는 더 많은 질문들이 쏟아집니다. "얼마나 빠르게?""얼마나 안정적으로?""사용자 친화적이라는 누구를 기준으로 하나요?" 그래서 비기능 요구사항 작성을 위한 한걸음 더 들어가보면, 결국 비기능 요구사항은 시스템이 무엇을 해야 하는지보다, 어떻게 동작해야 하는지를 규정하는 것인데, 일반적으로 다음과 같은 품질 속성과 관련된 요소들을 포함하게 됩니다. 성능: 응답 시간, 처리량가용성: 가동 시간, 중단 시간보안: 인증, 권한, 암호화사용성: 직관성, 접근성유지보수성: 수정 용이성..

소프트웨어 요구사항에서 비기능 요구사항을 작성할 때 자주 빠지는 함정은 이 비기능 요구사항을 "설계 가이드"나 "바람"처럼 모호하게 적는 것입니다. 하지만 비기능 요구사항도 요구사항이며, 따라서 품질을 보장하기 위한 명확한 작성 기준이 필요할 것입니다. 다행히 INCOSE의 니즈 및 요구사항 명세 특성 (in Guide to Writing Requirements, GWR)은 요구사항이 가져야할 몇가지 기준을 이미 제시하고 있습니다. 이를 이용하여 별도의 비기능 요구사항 특성을 정의하지 않고도, 다음과 같은 물음을 통해 비기능 요구사항의 품질을 확보 할 수 있을것으로 생각합니다.비기능 요구사항이 명확하게 정의되었는가? (C3, Unambiguous): INCOSE 요구사항 작성 가이드(GWR): Unamb..

어느덧 우리는 알게 모르게 수많은 소프트웨어 위에서 삶을 살고 있습니다. 스마트폰을 이용하여 친구들과 소통하고, 인터넷을 검색하고, 물건을 구매하며, 자동차를 운전하며, 병원에서 진료를 받고, 은행 업무를 처리하고 회사에서 여러가지 업무를 처리하는 과정에서 이미 복잡한 소프트웨어 시스템의 통제를 받고 있습니다. 그런데 이들 소프트웨어는 실제로 사람이 볼 수 있는 형상을 가지고 있지는 않습니다. 실제로 스마트폰, 인터넷, 자동차, 병원, 은행, 그리고 회사에서 접하는 모든 소프트웨어는 이를 운영하는 기기(컴퓨터, 스마트폰, 기타 여러 단말기 등)는 눈으로 보고 만질 수 있지만 그 이면에서 동작하는 소프트웨어 그 자체는 눈으로 보거나 만질 수도 없습니다. 단지 운영 기기를 통한 소프트웨어 동작 결과를 우리..