본문 바로가기

전체 글

좋은 요구사항의 기준을 바꾸자: 독자 중심의 요구공학 최근 회사에서 진단 요구사항과 진단 매뉴얼 개발 프로세스를 정립하는 작업을 진행하면서, 한 가지 잊고 있었던, 매우 당연한 사실을 다시 생각하게 되었습니다. 지금까지의 고민들은 요구사항을 얼마나 상세하게 작성했는지, 그리고 상세하게 작성하기 위해 무엇을/어떻게 해야 하느냐가 고민의 포인트였는데, 이번 계기를 통해 요구사항을 상세하게 쓰는 것 자체가 곧바로 품질을 의미하지는 않는다는 점을 다시 한번 느끼게 되었다는 것입니다. 초기에는 부족했던 진단 요구사항을 보완한다는 목표가 분명했고, 그래서 진단 조건을 더 상세히 적고, 신호 수준까지 상세한 설명을 덧붙이며, 진단 알고리즘과 임계값, 저장 데이터까지 가능한 많은 정보를 문서에 담을 수 있도록 노력했습니다. 그결과, 작성자 입장에서는 “이 정도면 충분하.. 더보기
AI 기반 소프트웨어 개발의 역설: AI는 개발을 어떻게 바꾸고 있는가? AI를 쓰면 일은 확실히 편해집니다. 실제로 회사 업무에서 많은 도움을 받고 있고, 그 도움의 범위를 점차 늘려가고자 노력중이기도 합니다. 그래서 저는 그 편함이 주는 효용을 부정하고 싶지 않습니다. 특히 낯선 API를 만났을 때, 문서 탐색 시간을 줄이고, 일단 돌아가는 형태를 빠르게 얻을 수 있습니다. 그런데 오늘 Anthropic 연구진(Judy Hanwen Shen, Alex Tamkin)의 실험 요약을 접하고 나서는, 그 편함이 항상 좋은 방향으로만 작동하지는 않을 수 있겠다는 생각이 들었습니다. 오류는 줄었는데 이해도(실력)는 떨어졌다 How AI assistance impacts the formation of coding skillsAnthropic is an AI safety and re.. 더보기
요구사항 Granularity란 무엇인가? 왜 지금 granularity를 다시 말해야 하는가 현장에서 제가 자주 듣는 말은 “요구사항이 너무 추상적이다”라는 말 입니다. 실제로 문서를 펼쳐 보면 “지원해야 한다”, “가능해야 한다”, “보장해야 한다” 같은 문장들이 가득합니다. 이런 요구사항들은 개발팀 입장에서 볼 때, 무엇을 하라는 의미인지 알수가 없지요. 그리고 테스트팀 입장에서는 이 요구사항들을 가지고 테스트케이스를 만들어 낼 수가 없습니다. 그리고 소프트웨어 통합이 이루어질 수록 이 추상성은 여기저기 수많은 문제들을 야기하게 됩니다. 이 즈음에 결국 자연스러운 결론에 도달하지요. “그럼 더 구체적으로 쓰자.” 그런데 문제는 여기서부터입니다. 요구사항을 구체적으로 쓰기 시작하면, 많은 경우 문제가 해결되기는 커녕 형태만 바뀐 채 더 복잡해.. 더보기
좋은 소프트웨어 공학 연구논문을 "설계" 하는 방법 한해를 마무리할 겸, 예전 자료를 정리하던 중 CMU의 Mary Shaw 교수님께서 특강을 해 주셨던 자료를 발견하였습니다. 제목은 "Writing Good Software Engineering Research Papers"인데요. 한동안 잊고 지냈던 Mary Shaw 교수님의 말씀들이 다시금 생각났습니다. "연구는 아이디어가 아니라 주장과 근거의 구조로 서야 한다", "논문을 독자를 설득하는 공학적 산출물", "논문 작성은 시스템 설계와 같다"라고 하셨던 말씀들을 자료를 보며 다시 한번 떠 올릴 수 있었던 즐거운 시간이었던거 같습니다. 저는 연구 실적이 우수한 연구자는 아니지만, 이번 자료를 보면서 다시 한번 좋은 논문을 써 보고 싶다는 욕구가 생기네요!1. 기본 원칙: 연구는 시스템 설계와 같다연구를.. 더보기
모델기반 개발에서는 요구사항이 필요없다? 지금 개발 중인 모델이 가장 정확한 요구사항이에요.최근 다른 팀과 협업을 진행하는 프로젝트가 있습니다. 협업 진행을 위해 자연스럽게 상대팀으로부터 요구사항을 전달받게 되었는데, 살짝 당황스러운 상황이 연출되었어요. 그 요구사항이라는 것이 전통적인 형태의 요구사항 문서가 아니라, 현재 개발 중인 Simulink 모델인 것이었습니다. 그 담당자는 너무도 자연스럽게, 마치 더 이상의 설명이 필요 없다는 듯 "이게 요구사항이에요"라고 말하는 것이었습니다. 물론 모델 기반 개발(Model-Based Development, MBD)이 무엇인지, 그리고 그 특징이 무엇인지는 잘 알고 있습니다. 모델은 동작(로직)을 표현하고 있고, 시뮬레이션도 가능하며, 코드 생성도 가능합니다. 즉 모델은 살아 있는 산출물입니다. .. 더보기
자동차 기능안전 온톨로지 (5): 디버깅(Debugging) 지금까지 자동차 기능안전 온톨로지를 정의하기 위해 클래스를 정의하고, 계층구조를 설정하였으며, 각 클래스에 적용될 수 있는 관계(Object Property)들을 정의하였습니다. 또한 이들이 논리적으로 배치되었는지를 확인하기 위해 Reasoner를 수행하기 위해 Reasoner에 대해서도 살펴 보았는데요. 막상 Reasoner를 돌려보면 의도했던, 의도하지 않았던.. 오류나 경고가 무더기로 쏟아집니다. 뿐만 아니라 맞다고 생각하고 배치한 클래스들이 Reasoner에 의해 추론된 결과가 전혀 예상하지 못했던 결과들이 나오기도 합니다. 한마디로 나는 기능안전 구조를 잘 알고 있어서 잘 배치했다고 생각했지만, 논리 기반의 Reasoner는 냉정하게도 "네 것은 틀렸어!" 라고 말하는 셈이죠. 하지만 조금 관.. 더보기
지속가능성(Sustainability): "잘 쓰는 것"을 넘어 "계속 쓰이게 하는것"으로... 최근 경영진 보고를 준비하면서 팀원/파트원들과 함께 꽤 긴 시간을 브레인 스토밍 했는데요, 그건 단순히 보고서 한 장을 채우기 위한 시간이라기 보다, 다양한 아이디어를 끌어내고, 흩어진 개념을 한 덩어리로 정리하고, 현재 수준을 냉정하게 파악하여, 실행 가능한 개선대책을 마련하는 데 많은 에너지를 쏟았습니다. 그 결과 우리가 지금 무엇을 하고 있는지, 그리고 무엇을 해야 하는지의 핵심이 의외로 또렷하게 정리되었습니다. 무언가를 잘 만들고, 잘 정리해서, 잘 이행하는 것, (자세한 내용을 언급하긴 좀 그렇지만), 이 세 가지가 결국 이번 보고의 핵심적 액션 아이템으로 자연스럽게 수렴되었습니다. 그런데 마음속 한켠에는 이런 질문이 떠 올랐습니다. “우리는 정말 ‘잘 만들고, 잘 정리하고, 잘 이행’하면 충분.. 더보기
자동차 기능안전 온톨로지 (4): 추론기(Reasoner) 활용 자동차 기능안전 온톨로지를 구축의 출발은 클래스를 정의하고, 하위 클래스를 만들고, 개념을 연결하는 것만으로도 온톨로지를 만들 수 있을 것이라고 생각하기 쉽습니다. 예를 들어 Hazard, Malfunction, SafetyGoal, FSR, TSR, VehicleSystem, Hardware와 같은 개념을 추가하고, Object Property를 만들어 Domain과 Range를 지정하는 과정은 겉으로 보기에는 매우 직관적이며, 경험에 의존적으로 작성할 수 있습니다. 결국 “나는 지금 온톨로지를 잘 만들고 있다”라는 착각에 빠지기 매우 쉽지요. 그러나 과연 지금까지 구성한 구조가 논리적으로 올바를까요? Hazard와 Malfunction을 연결했는데, 이 두 개념의 Domain과 Range가 섞여 충.. 더보기

티스토리툴바