OOPogramming에서 둘중 어느 방법으로 하시나요?

둘 다 합니다.
1. UI를 먼저 작업할때.
어플리케이션의 동작이 이해 안갈때 UI 부분을 간단히 먼저 작업해봅니다(콘솔로 만들거나, 간단한 폼 정도). 전체 돌아가는 UI를 보고 Domain Logic 과 interface 등을 만든뒤, Refactoring 해서 분리해냅니다.

2. Domain 을 먼저 작업할때
평상시 어플리케이션에 대해 이해하는 경우에 이부분을 먼저 작업합니다. Test Driven 으로 개발하시는 분들은 아마 Domain 먼저 접근하시는게 Test를 작성하기 쉽기 때문에 이쪽부터 접근하시려고 하실겁니다. 상대적으로 Refactoring 횟수가 적긴 합니다.

* UI 부분은 어플리케이션에 비교적 변경이 잦은 부분이라 생각합니다. 웹이라면 디자이너랑 협업도 해야 하는 부분이기도 하고요. 그래서 UI 를 먼저 구성한다 해도 '언젠가 이 부분은 바뀐다' 를 전제로 하고 가능한 한 디펜던시를 없애려고 노력합니다. 개발하시는 부분에 따라 다르긴 하겠지만. 개인적으로 UI 를 먼저 작성할 경우에 구현해야 할 부분이 명확해지고 프로그램을 이해하기에 좋다는 의견에는 동의합니다. 하지만, 후에 UI 에 핵심코드에 신경을 써 갈 수 있다는 점에는 반대합니다. (추후 변경이 잦다는 점에서요.)

* 가능한 한 UI에 로직이 붙은 Class를 상속하진 않습니다. 라이브러리 의존적인 코드가 많은 위치일 것이기 때문에 DIP 상으로도 맞지 않죠. 차라리 interface 를 정의하고 표현부분에 대해서는 Delegation 을 하는 입장을 취합니다.

* 어느부분을 먼저하건, 최종적으로 필요한 기능들이 완성되어있으면서 Low Coulping, High Cohesion 한 모듈들을 만들어내면 된다고 봅니다. 최근에 학교 프로젝트가 Minimax 스타일의 오델로 만드는 거였는데, 이 경우는 도스용 콘솔 어플리케이션 만들고, 이를 GUI 버전으로 옮겼습니다. 중간에 AI 부분 로직 자체에 대한 디버깅을 할때엔 콘솔버전으로 하면서 UnitTest 같이 붙이고, 최종 프로덕트는 GUI 버전으로 완료시켰습니다.
최종 프로덕트의 경우 12 x 12 짜리 게임인데, 중간에 테스팅을 하기 위해 8 x 8 모드로 만들었습니다.(AI가 버전업 될때마다 클래스 하나가 늘어납니다. 그리고 이 클래스는 기존에 이미 만들어진 AI 들과 대전을 하고 그 결과 로그를 만들어내야 합니다. 그리고 초기 작업때는 WZebra 등의 AI와 대결해보기 위해 8x8 모드가 필요합니다.) 모듈간 의존성이 낮았기 때문에, 하나의 프로그램에 대해 이러한 부가적인 기능들을 만드는데 별로 시간이 걸리지 않았습니다.

개인적인 방법은..
Logic 이 위주인 Server 같은 프로그램은 로직먼저...
UI 가 중요한 Client Program 은 UI 먼저...
(사실 Logic 도 많지 않져... ) 이렇게 짭니다...

Logic 도 UI 도 중요한 프로그램은 병렬로 짜는것에 한표를 던지고 싶지만... 쉽지는 않겠군요..

프로그래머는 로직에 무게중심을 많이 두지만..
시장은 UI에도 많은 무게가 쏠려있다는것을 염두에 두고 프로그래밍을 하시면 될것 같군요.

개인적인 생각으로는 프로그램의 종류에 따라 'UI를 중심으로' 클래스를 설계할 수는 있어도 'UI 로직에' 비즈니스 로직을 끼워 넣는 개발은 득보다는 실이 많은 것 같습니다.

VB의 대표적 문제점이 '마법의 버튼' 같은 코딩 스타일로 빠지기 쉽다는 점인데, 즉 버튼의 이벤트 핸들러에 400-500 줄씩 코딩이 들어간다던 지 하는 경우 입니다.

그런 부분만 피한다면 작은 규모의 간단한 데스크탑 어플리케이션의 경우 따로 기획이 없는 경우가 많기 때문에 UI를 중심으로 설계해도 큰 문제는 없을 것 같습니다.

그 밖의 경우는 대부분 도메인 모델 -> 비즈니스 계층 -> 프리젠테이션 계층 순으로 올라가는게 편한 경우가 많은 것 같습니다.

주제를 벗어난 얘기인지도 모르지만...
CUI(Commandline User Interface)를 주 환경으로 해서 먼저 만들고,
그담에 GUI든 웹인터페이스든 이 CUI와 스트림으로 input/output을 주고 받는 건 어떨까요?

제가 기억하기론, edonkey의 경우에도 커맨드라인 메인 인터페이스가 있고,
많은 클론들이 여기에 GUI를 붙여서 제작이 되고도 했습니다.
최근 mldonkey를 쓰고 있는데, 이 mldonkey의 경우,
브라우저로 볼 수 있는 웹인터페이스와 더불어 외부 포트를 열어서
텔넷 접속으로 사용할 수 있는 CUI 환경을 제공하기도 합니다.

이런 식으로 제작할 경우, 좀더 융통성 있게 만들 수 있지 않나 하는 생각이 듭니다.
아무래도 통합된 프로세스보다는 반응이 느리긴 하겠지만,
실제 클라이언트 데스크탑 환경에선 별 차이 없을 것이고,
CUI, GUI, 웹을 모두 제공한다는 것은 큰 장점이 될 수도 있을 것 같습니다.
그리고 GUI보다는 커맨드라인 옵션 파싱이 훨씬 쉽기에,
핵심 알고리듬에 좀더 주력할 수 있게 해준다는 것도 장점이 될 수 있겠죠. (원시적인 모듈화가 가능하다는 얘깁니다.)