TDD 를 SI 에서 잘 도입을 하지 못하는 이유는 뭘까요?

Question

요즘 TDD 에 꽂혀서 TDD 를 배우고 있습니다.개인적으로 SI 환경에서 TDD 도입이 어려운 이유를 두 가지로 분석해 보았습니다.엄격한 납품 기한: 품질보다 우선시되는 '기능 완결성' 중심의 개발 문화.잦은 비즈니스 로직 변경: 설계 단계에서 확정되지 않은 로직의 유동성.최범균 님의 저서에서는 '테스트 코드를 작성하며 모호한 요구사항을 정립한다'고 설명합니다.하지만 실제 SI 프로세스에서는 기획자나 PM이 비즈니스 로직을 선제적으로 검토한 뒤 개발자에게 전달합니다. 그럼에도 불구하고 현업에서 로직이 수시로 변경되는 근본적인 원인이 무엇인지 궁금합니다.이러한 현상이 주로 클라이언트의 요구사항 변경(변심)에 기인하는 것인지, 아니면 기획/PM 단계에서의 소통 오류나 도메인 이해 부족으로 인해 잘못된 정의가 전달되기 때문인지 실무 선배님들의 견해를 듣고 싶습니다.그리고 이러한 잦은 비즈니스 로직의 변경을 방지하기 위해 개발자가 취할수 있는 스탠슨는 어떠한 자세일까요..?ps - AI 로 바이브 코딩을 짜서 기능을 개발했다는 얘기는 자주 보여도 테스트 코드를 만들고 이를 도입했다는 얘기는 아직 못봤네요..

돌아온크리미드림 · Answer

si애들이 공부를 안해서 그럼

MuDaeng · Answer

모르는것을 부끄러워하지않고 오히려 아는사람이 잘못된거라 생각하는것

bvknd544 · Answer

Si에서 안쓰는 이유는 크게는 2가지 일거같애요테스트 코드 공부하기도,짜기도 싫다(해본적이없어서)Si환경 자체가 테스트코드가 그렇게 의미가없음 작성자 님이 정확하게 올려주셨는데 기간과 자주바뀌는 요구사항 이거때매 할이유가 없어지죠

도니코니 · Answer

아무리 고객 요구사항에 맞춰서 설계를 잘 한다한들 요구사항 틀어지면 나가리

nippori · Answer

si 의 문제라기 보단.. 전에 일한곳이 기술에 관심 많은 개발팀 5명 정도의 스타트업이었는데 문제가 같더라고요. 1. 스케줄(부족한 인원으로 빨리 만들면 좋음)2. 기획, 디자인 등 자주 바뀜면접볼땐 TDD 얘기 나누면서 들어갔는데 결국 안 지켜집니다. 저 두 문제가 없을 정도면 어느정도 서비스가 안정된 회사여야만 가능할것 같습니다

월급은나의빛 · Answer

객관적으로 우월한 방법론은 시간이 걸리더라도 결국 대세가 됩니다.미국의 빅테크에서도 TDD가 쉽사리 자리잡지 못하는 것을 보면 절대적으로 우수한 방법론은 아니라고 생각합니다.자주 변하지 않는 핵심 모듈 개발팀에서는 쓸 수 있지만, UI 와 쿼리 중심의 개발에서는 가치가 크지 않다고 봅니다.tc 먼저 만들기의 효용은 의심스럽지만, regression test 를 수행하는 깃헙 ci/cd 는 확실히 대세인 것 같네요.

쓸모있는 개발 · Answer

납품기한기 정해졌는데 계속 요구사항은 바뀌고… 일정은 무리하고 될까요?

haydeni · Answer

다양한 사유들이 있겠지만 그중 하나라고 생각하는건 50명, 100명의 기여자(개발자)가 있는 애플리케이션/서비스가 아닌경우 TDD 가 오히려 병목이 될 수 있어서 그렇다고 생각합니다. 소수의 인원이 모두 도메인을 이해하고 개발 할 수 있고, 테스트 코드를 짜지 않아도 문제가 안생기고 한다면 굳이 적용 할 생각을 안할거라고 생각합니다.반대로 오픈소스중 자동화된 CI/CD 구성되어있는 것들 중에 유닛테스트/e2e 테스트 없는것 보기가 힘듭니다. 정말 다양한 기여자가 있고, 또 내가 만든 코드가 정말 배포되어도 안전하구나, 괜찮구나 라는 최소한의 방어장치가 되어주니까요. TDD가 항상 정답은 아니지만 대규모의 퀄리티있는 소프트웨어를 만드려면 테스트코드(유닛테스트,e2e 등등.. 다 포함해서)는 안 쓸래야 안 쓸수가 없겠죠?

엡실론 · Answer

TDD와 테스트 코드 작성은 구별합시다.TDD 는 간단하게 말하면 테스트 코드를 먼저 쓰고, 개발을 한다는 것입니다. 그런데 대부분의 사람은 일단 물건을 만들고, 그걸 테스트 하는 것에 익숙해서 TDD에 적응하기 쉽지 않습니다. 게다가 테스트 코드를 쓰고 개발을 하든지, 개발을 하고 테스트 코드를 만들든지, 다른 사람 입장에서는 별 차이가 없습니다. 따라서 이걸 굳이 강제할 이유가 없습니다.테스트 코드 작성을 왜 하지 않는가는 여러가지 이유가 있겠지만, 가장 큰 건 위에서 그걸 요구하지 않기 때문이고, 그 이유는 글쓴분이 말씀하신 것과 비슷합니다. SI에서는 품질보다는 일단 기한내에 납품하는게 가장 중요한 일이기 때문입니다. 신생 스타트업도 상황은 비슷하고요. 반대로 대형 서비스 회사는 품질이 회사의 이익에 주는 영향이 크니 테스트 코드에도 많은 투자를 하고, 고과 평가에서도 어느 정도 반영을 하는 거죠. 테스트 코드를 쓰든 안쓰든 내 연봉이나 승진이나 전혀 영향이 없다면 굳이 할 사람이 얼마나 될까요.단순히 비지니스 로직 변경이 잦으니 테스트 코드를 쓰지 않는 다는 건 조금 잘못된 것 같습니다. 오히려 변경이 잦으면, 이 변경이 혹시 다른 예상치 못한 영향이 있지 않은지 테스트 코드를 열심히 쓰는게 품질을 생각한다면 올바른 일이죠.

badRacoon · Answer

테스트코드는 있으면 당연히 좋죠다만 테스터블한 객체, 코드를 작성하는 사람이 극도로 적을 것 같구요

오리구이 · Answer

TDD는 시간이 많고 널널하면 도입하겟지만 납기준수일이 있는데 TDD 일정까지 집어 넣으면 개발단계만 2배되게는데요.

basscraft · Answer

첫째, 요구사항 자체가 바뀜, 때로는 근본적인 엔티티 설계 부터가 바뀌어야 하는 경우도 수시로 발생둘째, 그럼에도 불구하고 갑님들은 구현된 결과물을 먼저 보고 싶어함셋째, 케이스를 완벽하게 한다고 해서 버그나 성능에 문제가 없는 어플리케이션이 나오는 것과는 괴리가 있음특히나 SI는 개발자가 수시로 바뀌기 때문에 위에 말한 세가지가 지대한 영향을 미친다고 봐야 합니다.

TDD 를 SI 에서 잘 도입을 하지 못하는 이유는 뭘까요?

12개의 답변

#si 목록