2편 : 단순히 ‘작동’하는 것을 넘어 – 진짜 좋은 소프트웨어란?

1편에서는 소프트웨어 공학을 공부해야하는 이유에 대해 이야기 하였습니다.

2편에서는 그렇다면 우리가 목표로 해야하는 좋은 소프트웨어 개발의 기준이 무엇인지 이야기 해보려고 합니다.

지난 편이 궁금하신 분들은 글 아래 링크를 통해 1편을 봐주세요:)

 

 

이 글을 읽고 계신 여러분은 아마 개발 직군에 종사하고 계시거나,
적어도 IT 업계에서 소프트웨어를 만드는 일에 관여하고 계실 거라 생각합니다.

그런 여러분께 조심스레, 그러나 진지하게 한 가지 질문을 던져보고 싶습니다.

 

여러분은 지금 만들고 있는 소프트웨어가 ‘좋다’고, 자신 있게 말할 수 있으신가요?

 

 

이 질문은 제가 현업에서 종종 꺼내는 말입니다.

처음 들으면 단순한 질문처럼 보일 수 있지만,

막상 대답하려고 하면 생각보다 쉽지 않다는 걸 느끼게 됩니다.

 

왜일까요?

‘좋다’는 기준 자체가 사람마다 다르기 때문입니다.

 

• 어떤 개발자는 “버그 없이 잘 돌아가면 좋은 소프트웨어죠.”
• 기획자는 “사용자가 불편함 없이 목적을 달성할 수 있어야 하죠.”
• 디자이너는 “일관된 UI/UX가 빠질 수 없다”고 하고,
• PM은 “릴리스 이후에도 안정적으로 운영 가능한 구조라면 좋은 소프트웨어”라고 말합니다.

 

직무에 따라, 그리고 경험에 따라 ‘좋음’의 기준은 서로 다릅니다.

그리고 이 다양한 정의는 실무 안에서 끊임없이 충돌하고, 조율되어야 할 중요한 포인트가 되죠.

 

그렇다면, 이 수많은 관점을 아우를 수 있는
‘좋은 소프트웨어’의 공통된 기준은 존재할 수 있을까요?

 

 

 

 

소프트웨어 공학이 말하는 '좋은 소프트웨어'

---

소프트웨어 공학은 바로 이 질문에 대한 해답을 찾기 위해 태어났습니다. 개발 과정의 복잡성과 리스크를 줄이고, 좋은 소프트웨어를 더 체계적으로 만들기 위한 방법론이죠.

 

그렇다면 소프트웨어 공학에서는 어떤 기준으로 '좋다'를 정의할까요?

 

대표적으로, 다음과 같은 품질 요소들을 통해 좋은 소프트웨어의 기준을 제시합니다:

1. 소프트웨어 신뢰도(reliability) - 오류 없이 안정적으로 동작하는가?
2. 소프트웨어 정확성(correctness) - 고객의 요구사항을 정확하게 만족하는가?
3. 소프트웨어의 성능(performance) - 주어진 자원으로 얼마나 빠르고 효율적으로 동작하는가?
4. 소프트웨어의 사용성(usability) - 사용자가 얼마나 쉽게 이해하고 사용할 수 있는가?
5. 소프트웨어의 상호운영성(interoperability) - 다른 시스템과 잘 연결되고 작동하는가?
6. 소프트웨어의 유지보수성(maintainability) - 향후 수정과 개선이 얼마나 쉬운가?
7. 소프트웨어의 이식성(portability) - 다양한 환경에서 쉽게 이전되어 동작할 수 있는가?
8. 소프트웨어의 검사성(verifiability) - 제대로 만들어졌음을 확인 할 수 있는가?
9. 소프트웨어의 추적성(traceability) - 요구사항부터 구현까지의 흐름을 추적할 수 있는가?

 

이 리스트를 보면 드는 생각은 하나죠.

 

“좋은 소프트웨어 만드는 거… 생각보다 훨씬 어렵네.”

 

 

결국 좋은 소프트웨어란, 외부 품질(사용자 관점의 만족도)과 내부 품질(개발자와 시스템 관점의 완성도)를 모두 만족시키는 결과물이라 할 수 있습니다.

 

하지만 실무에서는 이 기준들을 전부 만족시키는 게 쉽지 않습니다.
오히려 서로 충돌하거나, 현실적인 제약 속에서 절충을 강요받는 경우가 대부분이죠.

 

그래서 지금부터는,
제가 실제 프로젝트에서 겪었던 사례들을 통해
이 기준들이 어떻게 현실과 충돌하고, 어떤 배움을 남겼는지 이야기해보려 합니다

 

 

 

 

1. 신뢰도와 정확성 : 돌아간다고 다 된 건 아니다

---

신뢰도는 소프트웨어가 오류 없이 안정적으로 동작하는지,
정확성은 소프트웨어가 요구한 대로 정확히 작동하는지를 평가하는 기준입니다.

 

한 프로젝트에서 거의 마무리 단계에 기획자로 투입된 적이 있습니다.
처음엔 "테스트만 잘 끝내면 되겠지" 싶었지만, 전체 흐름을 파악하다 보니 이상한 점이 보였어요.

기존 설계를 살펴보니, 고객이 요청했던 핵심 요구사항들이 빠져 있었던 겁니다.

 

그런데 이미 기능은 구현되어 있었죠. ‘비슷하지만, 확실히 어긋난 느낌’이 강하게 들었습니다.

 

이야기를 나눠보니 개발자들이 이렇게 말했습니다:

 

“설계가 부족해서 저희가 상상해서 만들었습니다.”
“버그는 없는데요? 잘 돌아가는데 왜 문제죠?”

 

 

 

그런 상황을 여러 번 겪다 보니 확실히 느끼게 됐습니다.
정상적으로 동작한다고 해서, 그것이 곧 정확한 건 아니라는 걸요.

사용자는 “정상 동작”보다 먼저, “요구한 대로 동작”하길 기대합니다.

 

그래서 지금은 기획자로서
요구사항의 명확성과 설계의 추적 가능성에 훨씬 더 신경 쓰게 되었습니다.
설계의 빈틈은 결국, 소프트웨어의 신뢰도에 균열을 만드는 지점이 될 수 있으니까요.

 

 

 

 

2. 성능, 사용성, 그리고 유지보수성: 이 세 가지를 동시에 만족시킬 수 있을까?

---

성능은 얼마나 빠르고 효율적으로 동작하느냐,
사용성은 얼마나 쉽고 직관적으로 사용할 수 있느냐,
유지보수성은 얼마나 쉽게 고치고 개선할 수 있느냐를 말합니다.

 

문제는… 이 세 가지가 항상 서로 친구는 아니라는 거죠.

 

예전에 사용자 경험(UX)을 중심으로 설계를 짠 프로젝트가 있었어요.
사용자가 편하게 흐를 수 있도록 조건 분기와 자동화 로직을 많이 넣었습니다.

 

그런데 개발 단계에서 다음과 같은 상황이 벌어졌습니다:

• 성능은 눈에 띄게 느려지고,
• 코드 구조는 복잡해졌으며,
• 유지보수는 한숨 나올 수준이 되었습니다.

 

그때 개발자 분이 한 말이 아직도 기억나요.

“이거 나중에 수정할 일 없게 해주세요. 저도 다시 보기 싫어요…”

 

 

이 일을 겪은 뒤로,
저는 기획안을 짤 때마다 스스로에게 질문하게 됐습니다.

 

“이 UX 개선이 성능에 어떤 영향을 줄까?”
“유지보수를 고려한 절충점은 없을까?”

 

 

 

좋은 소프트웨어란,
세 마리 토끼를 완벽하게 잡는 것이 아니라,
현실적인 균형을 어떻게 잡느냐의 문제라는 걸 점점 더 실감하게 됐습니다.

 

 

 

 

3. 상호운용성과 이식성: 이게 왜 여기선 안 되죠?

---

상호운용성은 다른 시스템이나 플랫폼과 잘 연동되는가,
이식성은 환경이 달라도 잘 작동하는가를 평가합니다.

 

웹 기반 사내 시스템을 리뉴얼하던 프로젝트에서, 모든 기능을 최신화했고 테스트도 문제없이 통과했습니다.

 

하지만 실제 배포 후, IE11에서 화면이 다 깨진다는 연락이 왔습니다.

고객사 보안 정책상 크롬 설치가 금지되어 있었고, 모든 직원이 IE를 쓰고 있었던 거죠.

 

이후로도 모바일에서는 잘 되던 기능이, 아이폰 사파리에서만 오작동하는 일도 있었습니다.

 

이 일을 겪고 나서부터는
기획서에 항상 다음을 명시합니다:

• 지원 브라우저 및 버전
• 연동 대상 시스템
• 운영 환경의 제약 조건

상호운용성과 이식성은, 사후 대응이 아니라 기획 초기부터 고려해야 하는 요소라는 걸 뼈저리게 배운 순간이었습니다.

 

 

 

 

4. 검사성과 추적성: 결국은 ‘어떻게 증명할 건데?’

---

검사성은 만들어진 소프트웨어를 테스트로 검증할 수 있는가,
추적성은 요구사항이 어디서부터 어떻게 구현까지 이어졌는지를 흐름으로 설명할 수 있는가를 말합니다.

 

이론적으로는 당연히 해야 할 일 같지만,
실무에서는 놀라울 정도로 자주 무시됩니다.

 

요구사항은 회의록에만 남고,
기획서는 단편적이고,
테스트 케이스는 QA가 알아서 만든다?

 

그러다 QA 때 누락이 발견되면 항상 이런 대화가 나옵니다:

 

“기획서에 없었어요.”
“회의에서 얘기했잖아요.”
“이건 누가 놓친 거죠?”

 

 

 

그래서 저는 다음과 같은 방식으로 요구사항 흐름 전체를 추적 관리하고 있습니다:

1. 요구사항 – 최초 정리 시 고유 ID 부여
2. 기능 명세서 – 어떤 요구사항에서 파생된 기능인지 명시
3. 화면 설계서 – 각 화면이 어떤 기능을 구현하는지 연결
4. 테스트 케이스 – 어떤 화면/기능/요구사항을 검증하는지 맵핑

 

이렇게 하면,
“왜 테스트하죠?”, “이 기능 왜 있죠?” 같은 질문에 명확하고 추적 가능한 논리로 설명할 수 있습니다.

 

하지만 이걸 실제로 실천하는 팀은 생각보다 드뭅니다.

 

• 시간이 없어서
• 리소스가 부족해서
• 그냥 귀찮아서
• “우리 팀은 머릿속으로 다 알아요”라는 착각 때문에

 

하지만 프로젝트가 꼬이기 시작하면,
추적성 없는 시스템은 속수무책으로 무너집니다.

추적성은 문서 관리가 아니라, 리스크 관리입니다.

 

기획자와 PM이 끝까지 책임지기 위해 만들어야 할 가장 기본적인 구조이기도 하죠.

 

 

 

 

마무리하며: 좋은 소프트웨어는 결국 좋은 협업에서 나온다

---

이 모든 기준들을 돌아보면,
좋은 소프트웨어란 단순히 "잘 돌아가는 프로그램"이 아닙니다.

그 안에는 수많은 조율과 선택, 기획과 설계, 협업과 소통이 담겨 있습니다.

 

요구사항을 정확히 해석하고,
사용자의 관점과 개발자의 관점을 조율하며,
현실적인 제약 속에서도 ‘더 나은 선택’을 끊임없이 고민하는 것.

 

그 과정이 바로 좋은 소프트웨어를 만들어가는 여정이라고 생각합니다.

 

 

그래서 이제, 글을 시작할 때 드렸던 그 질문을 다시 한 번 던져봅니다.

 

 

 

여러분은 지금 만들고 있는 소프트웨어가 ‘좋다’고, 자신 있게 말할 수 있으신가요?

 

 

 

 

 

 

 

 

이전글도 한 번 봐주세요:)

2025.03.16 - [프로젝트 관리] - 1편 : 소프트웨어 공학을 공부해야 하는 이유

소프트웨어 공학을 공부해야 하는 이유