- 질문 게시판입니다.
| Date | 15/06/07 15:52:08 |
| Name | ArcanumToss |
| Subject | 버그없는 프로그래밍이 가능할까요? |
|
만일 인공지능에게 프로그래밍을 학습시켜서 논리적 오류가 없는 프로그래밍을 하는 것이 가능해진다면 어떨까 하는 생각을 하다가 갑자기 궁금해지는 게 있네요. 프로그래밍을 하다 보면 항상 버그는 그림자처럼 따라다닙니다. 그런데 가만 생각해 보니 버그가 꼭 실수를 했기 때문에 발생하는 문제일까 하는 생각이 들더군요. 프로그래밍 기법 자체에 뭔가 빈틈이 있을 수도 있고 컴파일러 자체에 문제가 있을 수도 있지 않을까 하는 생각인데 제가 전공자가 아니다 보니 판단할 수가 없어 질문을 올려봅니다. 프로그래밍을 할 때 프로그래머가 논리적 오류가 없이 프로그래밍을 한다고 가정할 때 운영체제급 프로젝트를 진행하면서 버그가 없는 결과물이 나올 수 있나요? 뭐... 워즈니악이 OS를 만들 때 버그 하나도 없이 쭉쭉 써내려갔다는 말을 듣고 경악하긴 했지만... 0
이 게시판에 등록된 ArcanumToss님의 최근 게시물
|
|
함수형 언어도 타입 빡세게 해서 짜면 버그 앵간하면 안납니다. 실제로 버그나면 x되는 증권이나 은행쪽에서는 함수형 언어 쓴다고 하더군요(물론 미국 이야기). 문제는 함수형으로 짜면 퍼포먼스가 존내 안나와서 문제입니다. 이건 컴퓨터 구조적인 문제인데 재귀적으로 프로그램을 짜면 레지스터 점프가 필연적으로 존재하고 흔히 쓰는 cpu는 레지스터 점프가 쥐약입니다. 퍼포먼스가 상당히 많이 떨어져요. 찾기 어려운 버그들이 나는 과정이 보통 약한 타입 때문에 나는 경우가 대부분입니다. C도 타입이 없는 언어이고 요즘 유행하는 파이썬도 동적 타입... 더 보기
함수형 언어도 타입 빡세게 해서 짜면 버그 앵간하면 안납니다. 실제로 버그나면 x되는 증권이나 은행쪽에서는 함수형 언어 쓴다고 하더군요(물론 미국 이야기). 문제는 함수형으로 짜면 퍼포먼스가 존내 안나와서 문제입니다. 이건 컴퓨터 구조적인 문제인데 재귀적으로 프로그램을 짜면 레지스터 점프가 필연적으로 존재하고 흔히 쓰는 cpu는 레지스터 점프가 쥐약입니다. 퍼포먼스가 상당히 많이 떨어져요. 찾기 어려운 버그들이 나는 과정이 보통 약한 타입 때문에 나는 경우가 대부분입니다. C도 타입이 없는 언어이고 요즘 유행하는 파이썬도 동적 타입언어죠. 타입이 약할 경우 찾기 어려운 런타임 버그가 생길 확률이 높아집니다. 반면에 함수형 언어는 강한 타입 언어라서 타입 안맞으면 컴파일 단계에서 에러가 나니까 일단 컴파일만 어떻게든 해내면 버그가 있을 확률이 엄청 줄어들죠. 버그가 있다고 해도 프로그래머의 멍청함으로 빚어진 찾기가 쉬운 버그입니다.
PL분야에서 프로그램 검증학이라고 프로그래머가 의도한 대로 프로그램이 돌아가는지 검증하는 분야가 있긴한데 여기도 진전이 더뎌서.. 뭐 미래에 완성되면 버그없는 프로그램을 만들 수 있겠죠?
그리고 컴파일러는 죄가 없습니다. 프로그래머가 문제죠.
PL분야에서 프로그램 검증학이라고 프로그래머가 의도한 대로 프로그램이 돌아가는지 검증하는 분야가 있긴한데 여기도 진전이 더뎌서.. 뭐 미래에 완성되면 버그없는 프로그램을 만들 수 있겠죠?
그리고 컴파일러는 죄가 없습니다. 프로그래머가 문제죠.
http://en.wikipedia.org/wiki/Compilation_error#Internal_Compiler_Errors
위키페디아에도 항목이 있습니다.
https://github... 더 보기
위키페디아에도 항목이 있습니다.
https://github... 더 보기
http://en.wikipedia.org/wiki/Compilation_error#Internal_Compiler_Errors
위키페디아에도 항목이 있습니다.
https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-ICE
이 링크는 최근 1.0 버전이 나온 Rust 프로그래밍 언어의 내부 컴파일러 오류 이슈들을 다루고 있습니다. 보통 재현할 수 있는 minimal case를 찾아서 함께 올라와 있는데, 이것만 봐도 의외의 버그가 제법 된다는 것을 알 수 있습니다. 아직 활발하게 새 코드가 추가되는 젊은 언어이기 때문에 다른 언어보다 많은 것이라고 볼 수는 있습니다만, GCC라던지 OCaml 컴파일러 등도 이슈 트래커를 찾아보면 틀림없이 ICE 관련 이슈가 계속 등장하고 있을 겁니다.
금시초문이신 것은 첫째로는 관심이 없으시기 때문일 것이고, 둘째로는 자주 쓰는 형태의 코드에서는 이런 버그가 잘 발생하지 않기 때문이겠죠. C/C++같은 오랫동안 쓴 언어들은 어느 정도 안정화가 되어 있기도 하겠고요. 그러나 컴파일러도 소프트웨어이고 verification 과정을 거쳐가며 만든 것이 아니기 때문에 이런 버그는 생각보다 많습니다.
위키페디아에도 항목이 있습니다.
https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-ICE
이 링크는 최근 1.0 버전이 나온 Rust 프로그래밍 언어의 내부 컴파일러 오류 이슈들을 다루고 있습니다. 보통 재현할 수 있는 minimal case를 찾아서 함께 올라와 있는데, 이것만 봐도 의외의 버그가 제법 된다는 것을 알 수 있습니다. 아직 활발하게 새 코드가 추가되는 젊은 언어이기 때문에 다른 언어보다 많은 것이라고 볼 수는 있습니다만, GCC라던지 OCaml 컴파일러 등도 이슈 트래커를 찾아보면 틀림없이 ICE 관련 이슈가 계속 등장하고 있을 겁니다.
금시초문이신 것은 첫째로는 관심이 없으시기 때문일 것이고, 둘째로는 자주 쓰는 형태의 코드에서는 이런 버그가 잘 발생하지 않기 때문이겠죠. C/C++같은 오랫동안 쓴 언어들은 어느 정도 안정화가 되어 있기도 하겠고요. 그러나 컴파일러도 소프트웨어이고 verification 과정을 거쳐가며 만든 것이 아니기 때문에 이런 버그는 생각보다 많습니다.
간단하게 생각하자면 컴파일러도 결국 사람이 만든 프로그램인데 버그가 없을리가요.. ㅠㅠ
Finding and understanding bugs in C compilers(http://dl.acm.org/citation.cfm?id=1993532)라는 논문에 실린 내용들 중 하나를 인용하자면
int foo (void) ~{
signed char x = 1;
unsigned char y = 255;
return x > y;
}
라는 함수가 우분투 8.04.1 x86버전의 GCC에서 최적화 옵션을 걸었을 때 0이 아니라 1이 리턴되게 프로그램을 컴파일하는 버그가 있었다고 합니다.
Finding and understanding bugs in C compilers(http://dl.acm.org/citation.cfm?id=1993532)라는 논문에 실린 내용들 중 하나를 인용하자면
int foo (void) ~{
signed char x = 1;
unsigned char y = 255;
return x > y;
}
라는 함수가 우분투 8.04.1 x86버전의 GCC에서 최적화 옵션을 걸었을 때 0이 아니라 1이 리턴되게 프로그램을 컴파일하는 버그가 있었다고 합니다.
하드웨어나 소프트웨어에 논리 버그가 전혀 없어도 오동작은 일어납니다. 방사선 등의 물리적 원인에 의해 메모리나 레지스터의 값이 바뀔 수 있거든요(...)
다만 이상적인 하드웨어와 버그 없는 컴파일러를 가정하고, 소프트웨어의 특정한 기능 부분이 정해진 specification에 항상 맞게 동작한다는 formal proof는 가능합니다. 그러나 이것이 버그가 없는 소프트웨어를 항상 만들 수 있는가? 로 질문이 변하면 복잡합니다. 기본적으로 소프트웨어 버그는 시간과의 트레이드 오프라고 보면 됩니다. 무한대의 시간이 있으면 버그 없는 소프트웨어를 만들 수 있겠지만 시간도 비용이기에 그렇게 하지 않는 것이죠.
다만 이상적인 하드웨어와 버그 없는 컴파일러를 가정하고, 소프트웨어의 특정한 기능 부분이 정해진 specification에 항상 맞게 동작한다는 formal proof는 가능합니다. 그러나 이것이 버그가 없는 소프트웨어를 항상 만들 수 있는가? 로 질문이 변하면 복잡합니다. 기본적으로 소프트웨어 버그는 시간과의 트레이드 오프라고 보면 됩니다. 무한대의 시간이 있으면 버그 없는 소프트웨어를 만들 수 있겠지만 시간도 비용이기에 그렇게 하지 않는 것이죠.
| 목록 |
|
