Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

세계 최고의 초파리 연구 엔진은 델파이를 사용해 구축되었다


Recommended Posts

이안 바커 (Ian Barker)"World’s Best Fruit Fly Research Engine Is Built With Delphi" 을 번역했습니다. (원문 작성: 2023년 2월, 최종 번역: 2024년 1월)

초파리는 매우 작다. 그러나 생명의 비밀을 밝히고자 하는 연구자들에게 매우 인기 있는 생물 중 하나다. 오늘 소개할 기업용 애플리케이션 개발 사례는 델파이 개발자 David Schwartz가 왜 델파이를 로우 코드 애플리케이션 플랫폼으로 최고의 선택이라고 생각 하는지 그 이유에 대한 것이다. 또한, 그가 델파이 프로그래밍 기술을 어떻게 확장해서 강력한 웹 앱을 만들었는지, 그리고 "초파리 연구계의 구글"이라고 불리는 앱을 어떻게 만들었는지를 설명한다.

목차


소프트웨어 개발 경력은?

나는 1979년 6월 애리조나 주립대학교에서 수학/컴퓨터 과학 학사 학위를 받았고, 거의 모든 경력을 소프트웨어 개발자로 일해왔다. 1980년대 중반에, 'OOP(Object-Oriented Programming, 객체 지향 프로그래밍)'라는 새로운 프로그래밍이 등장했다. OOP는 'C'에 기반한 새로운 언어인 C++가 지원했다.  나는 호기심이 생겨서 공부를 시작했고, 어느새 OOP와 C++ 모두 능숙하게 다룰 수 있게 되었다. 실제로, 나는 미국 내 여러 곳에서 가르치기도 했다.

1990년대에는 직접 컨설팅 회사를 운영했다. 나는 주로 무언가를 위한 소프트웨어를 만드는 아이디어를 가진 사람들과 함께 일했다. 그들은 그 아이디어를 머릿속에서 꺼내 '현실'에서 실현하고자 나를 고용했다. 정말 즐거웠다. 내 경력의 대부분은 자동차, TV, 전자레인지를 작동시키는 컴퓨터와 같은 '임베디드 시스템'이었다.

그 시기에, 마이크로소프트는 '윈도우'라는 훌륭한 'GUI(graphical user interface, 그래픽 사용자 인터페이스)' 플랫폼을 도입했다. 그런데, 이것을 프로그래밍하는 것은 너무 복잡하고 까다로웠다. 나는 많은 동료들이 파산하는 것을 보았다. 내가 본 바에 따르면 마이크로소프트 도구에 너무 많은 시간과 돈을 투자해야 했는데, 수익은 매우 작았기 때문이었다. 그 방식은 아마도 대기업에서는 잘 되지만 개인사업자에게는 그렇지 않았던 것 같다. 그래서 나는 윈도우 프로그래밍을 전염병이라 여기고 멀리했다.

델파이가 탑재된 RAD 스튜디오를 선택하여 애플리케이션 개발하게 된 계기는 무엇인가?

spacer.png나는 1995년 2월 캘리포니아 몬테레이에서 열린 소프트웨어 개발자 컨퍼런스라는 행사에 참석했다. 그 주에, 발렌타인데이인 2월 14일, 볼랜드 인터내셔널(Borland International)사는 윈도우용 소프트웨어 앱을 작성하는 새로운 방법을 소개했다. 그 제품이 델파이(Delphi)였다. 나는 그날 관람자들 사이에 있었는데 완전히 감탄했다. 네 가지가 내 눈에 띄었다:

  1. "윈도우 이벤트 루프"라고 불리는 것을 델파이는 어떻게 완전히 숨겼을까. 그것 하나만으로도 윈도우용 코드를 작성하는데 있어 최악의 부분은 해결된 것이었다. 윈도우 이벤트 루프는 개발자들에게는 악몽과 같았고, 보편적으로 경멸의 대상이었다. 델파이가 이 문제를 마법처럼 완전히 해결한 것이다. 대단했다!
  2. 너무나 간단하고 쉽게 델파이의 GUI-기반 폼 디자이너로 그래픽 폼을 만들어 냈다. 실행되는 그래픽 폼은 델파이의 폼 디자이너 안에서 보이는 것과 그 모습이 거의 똑같았다. 이를 'WYSIWYG(What You See Is What You Get, 보이는 그대로 표시)' 디자인 방식이라고 했었다. 이와 비슷한 도구들이 있긴 했다. 하지만, 윈도우용이 아니었다. 게다가 그 어느 것도 가격이 만만치 않았다. 예산이 많은 대기업이 아니라면 말이다.
  3. 이러한 WYSIWYG의 마법을 가능하게 한 것은 '컴포넌트'의 모음이었다. 컴포넌트 팔레트에서 '컴포넌트'를 선택하여 폼 위에 끌어다 놓으면 되었다. 그리고 나서, 새 “Property Inspector”를 사용해 설정을 조정하면 되었다. 유용한 (그리고 단순한) 윈도우 프로그램을 구축할 때라면 코드를 한 줄도 직접 쓰지 않고도 가능하다는 것이 말 그대로 사실이었다.
  4. 아마 가장 놀라웠던 점을 꼽자면, 이 '컴포넌트' 자체를 작성하는 것조차 델파이 자체 안에서 할 수 있다는 것이었다. 컴포넌트를 만들기 위해서 완전히 다른 언어와 환경에서 개발하지 않아도 되었다. 당시 VB나 기타 이와 비슷한 플랫폼들은 그렇게 해야만 했었다. 하지만, 델파이는 스스로 확장할 수 있었다. 

무엇보다 가장 좋았던 것은, 무료 사본을 모든 참석자에게 제공했기 때문에 집에서 가지고 놀아볼 수 있었다는 점이다. 이 이벤트로 인해, 내 경력의 방향이 바뀌었다고 해도 과언이 아니다. 몇 년도 안되어, 내 작업의 거의 모두가 델파이 프로그래밍을 통해 이루어졌기 때문이다. 그 이후, 델파이는 내 이력의 핵심이 되었다.

위에 언급한 기능들은 1995년 당시에는 매우 놀라운 것들이었다. 하지만, 그 후부터 모든 프로그래밍 플랫폼에서는 거의 당연한 것으로 여겨지게 되었다. 아마도 마이크로소프트사에게도 매우 충격적이었던 것 같다. 왜냐하면 마이크로소프트는 터보 파스칼의 저자이자 델파이의 수석 아키텍트Anders Hejlsberg를 영입하여, 자신들의 후속 작업 모두를 이끌도록 했기 때문이다.  Anders Hejlsberg는 새 언어('C#')와 개발 플랫폼('비주얼 스튜디오')을 설계하는데 도움을 주었다. 오늘날, 델파이와 비주얼 스튜디오는 여전히 매우 비슷한 IDE이다. 한 쪽을 능숙하게 사용한다면, 다른 한 쪽도 문제없이 사용할 수 있다.

최근에는 어떤 것들을 개발하고 있는가?

그 이후로 나는 다양한 델파이 기반 프로젝트에 참여해 왔다. 나는 델파이를 사용해 작성된 대규모 엔터프라이즈 애플리케이션을 유지 관리하는 작업을 주로 해오고 있다. 심지어 2023년 현재에도, 수많은 레거시 애플리케이션이 있다. 그리고, 이것들은 수많은 기업들에게 여전히 수십억 달러까지는 아닐 수 있지만 수백만 달러의 이익을 만들어 주고 있다. "왜 그런가?"라고 물어볼 수도 있겠다.

내 생각에는, 두가지 이유가 있다: (1) 대부분 견고한 애플리케이션이다. 그리고 유지 관리가 거의 필요하지 않다. (2) 교체하려면 너무 많은 비용이 든다는 말 말고는 달리 설명할 수 없다. 나는 델파이를 기반으로 한 엄청나게 큰 앱들을 유지 관리하는 일을 돕는 일을 했는데, 원래 있던 개발자들은 그 후속 제품을 다른 플랫폼으로 구축하는 업무를 맡았다.  누가 구축하든 간에, 나는 개인적으로 그런 프로젝트들 중에서 완료된 것을 단 하나도 본 적이 없다. 그것들은 모두 예산과 일정을 훌쩍 넘겼다. 내가 있는 동안을 그랬다. 떠나고 나서 나는 그 프로젝트들에 대한 소식을 듣지 못했다.

난 종종 의아스러울 때가 있다. 왜 델파이는 회사의 경영진들에게 존중을 받지 못하는가 하고 말이다. 그들이 이끄는 사업에서 수백만에서 수억 달러의 수익이 델파이-기반 애플리케이션이 운영하는 사업에서 나오는데도 말이다. 게다가 그들은 델파이를 전혀 다른 언어와 플랫폼으로 대체하려고 하는데 그러면 현재 존재하는 (완전하게 디버깅되어 있고, 안정적인) 델파이 코드로부터 얻을 수 있는 이점이 전혀 없는데도 말이다. 내가 마지막으로 일했던 두세 곳에서는, 버그 수정에 필요한 경우 외에는 코드에 손을 대지는 것조차 경영진들이 원하지 않았었다.

왜 다른 개발 솔루션이 아니라 델파이가 탑재된 RAD 스튜디오를 계속 선택하고 있는가?

'오늘날' 개발할 '다음' 프로젝트를 하기에 델파이가 얼마나 훌륭한 플랫폼인지를 밝혀주는 이야기를 해보겠다. 왜 다른 것이 아니라 델파이를 고려하는 것이 마땅한가?라는 질문에 대해 내가 생각하는 델파이가 더 뛰어난 점은 모두 5가지 영역이다.

델파이가 탑재된 RAD 스튜디오를 추천하는 첫 번째 이유

첫째, 델파이는 파스칼 언어를 기반으로 한다. 파스칼은 원래 프로그래밍 학생을 위한 교육용 언어로 개발되었다. 그래서 간단하고 논리적이며 읽고 쓰기 쉽다. 가장 중요한 것은 배우기 쉽다는 점이다. 델파이는 OOP(object oriented programming)를 수용하도록 확장된 것이고, 이를 오브젝트 파스칼이라고 부른다. 이 언어의 의미론은 C++의 의미론과 거의 완전히 겹친다. 가장 눈에 띄는 예외라면, 오브젝트 파스칼은 다중 상속을 지원하지 않는다.

C++와 델파이의 작지만 중요한 또 하나의 차이점을 들자면, 델파이의 모든 "오브젝트"(예: 클래스 인스턴스)는 암시적으로 참조에 의해(by reference) 전달된다. 그러므로, 포인터 유형을 사용(또는 타입을 깨는 명시적 형변환을 사용)할 필요가 거의 없다.

그 당시로 가보면, 모두가 가장 애증하는 언어는 'C' 였다. 그리고 나서는 'C++'이었다. 왜 그럴까? 아마  사람들은 "너무 간결하다"는 이유를 들지 모르겠다. 90년대에는 그랬을 수 있다. 하지만, 지금은 그다지 그렇지 않다. 오랫동안 나는 C++를 사용하지 않고 있다. 하지만, 최근에 C++20의 코드를 훑어보면서 슬펐다. 많은 것들이 덕지덕지 추가된 것 같다는 생각이 들었다. 그렇다. 최신 C++과 비교하면 델파이의 오브젝트 파스칼이 훨씬 덜 장황하고, 더 단순하다. 비록 둘 중 어느 것도 '간결하다'고 할 수는 없지만 말이다. J

델파이가 탑재된 RAD 스튜디오를 추천하는 두 번째 이유

둘째, 사람들이 알지 못하는 사실 중 하나는 델파이의 오브젝트 파스칼은 결코 도퇴되지 않았다는 사실이다. 많은 사람들이 믿고 있는 것과 실제로 다르다. 델파이는 절차적 프로그래밍과 함수형 프로그래밍 모두를 지원한다. 실제로 델파이의 오브젝트는 이 두 가지 사용 사례 모두에서 일등급 오브젝트로 간주된다. 일등급 오브젝트(first-class object)는 다음이 가능하다:

  • 표현식에 나타난다
  • 변수에 할당(assigned)된다
  • 인자(argument)로 사용된다
  • 함수 호출의 결과로 리턴 된다

델파이로 함수형 프로그래밍 표현식을 작성하는 구문은 약간 장황하다. 그렇지만 일등급 오브젝트를 지원하는 다른 함수형 프로그래밍 언어에서 할 수 있는 모든 것을 델파이로 할 수 있다. 또한, 제네릭을 지원하고, 훌륭한 제네릭 라이브러리들도 있다.

델파이가 탑재된 RAD 스튜디오를 추천하는 세 번째 이유

셋째, 볼랜드 그리고 그 이후 엠바카데로가 수년 동안 고수해 온 원칙 중 하나는 새로운 델파이 버전은 이전 버전 언어와 호환성을 유지해야 한다는 암묵적인 요구사항이다. 첫 버전으로 만든 오래된 델파이 앱을 컴파일해서 실행하는 것이 가능하다.

이런 노력이 오랜 기간 지속되는 동안 생긴 두 가지 약점이 있다. 오래된 프로젝트를 업그레이드하는 경우 전형적으로 겪게 되는 가장 큰 방해물은 유니코드 문자열로 전환하기이다. 유니코드 문자열은 델파이 2009에서 생겼다. 또 다른 하나는 내부 변경에 따른 것이다. 런타임 타입 식별 지원을 강화하고, 더 유연한 컴포넌트를 가능하게 하고 제네릭을 지원하느라 변경된 것들과 관련이 있다; 또한 일부 인기 있는 컴포넌트 라이브러리들을 업그레이드 하는 것이 어렵거나 비용이 너무 많이 들기도 했다.

델파이가 탑재된 RAD 스튜디오를 추천하는 네 번째 이유

넷째, 대부분의 개발자가 잘 모르는 점이다. 델파이는 오늘날 시장에 출시된 거의 모든 런타임 플랫폼용으로 네이티브 애플리케이션을 만들 수 있다. 예를 들면:

  • 윈도우(32비트, 64비트)
  • 맥OS(32비트, 64비트)
  • iOS
  • 안드로이드
  • 리눅스
  • 심지어 대부분의 브라우저에서 실행되는 웹 앱도 포함한다.

즉, 하나의 언어와 하나의 개발 플랫폼을 사용해서 모든 개발 요구사항을 충족할 수 있다는 의미이다. 오늘날! 서로 다른 개발 기술과 툴셋으로 작업하는 여러 명의 개발자로 구성된 팀을 최대 6 팀을 고용하는 것이 아니라 델파이 팀 하나만 있으면 된다: 델파이.

써드 파티 컴포넌트를 사용하는가?

이런 멀티플랫폼 지원은 (델파이 XE2 이후) 지금까지 거의 10년동안 델파이 안에서 꾸준히 진화해 왔다. 하지만, 써드 파티 공급업체인 TMS 소프트웨어는 웹 코어라는 일종의 확장 기능에 많은 공을 들여 왔다. 웹 코어(WEB Core)라는 제품이다. 이것을 사용하면, 델파이 IDE 안에서 애플리케이션을 작성하고, 컴파일 해서 최신 웹 브라우저에서 바로 실행할 수 있다. 심지어 디버깅까지 할 수 있다. 실제로 보면 정말 놀랍다! 윈도우 앱을 작성하는 것과 똑같은 방식으로 델파이로 코드를 작성하면 된다. 그러면, 그 코드는 자바스크립트로 변환 컴파일되고 간단한 HTML 파일 안에 포함 되는 방식으로 패키징 된다. TMS사가 그 변환 컴파일러를 조금 더 강화했기 때문에, 이제는 웹 앱이 가지고 있는 비동기(asynchronous) 특징을 델파이 코드로 쉽게 다룰 수 있다. 정말 천재적인 아이디어다.

나는 TMS 웹 코어를 시작하기 위해, 상당히 단순하지만 사소하지는 않은 앱을 만들어 보았는데 한 시간이 채 걸리지 않았다. 몇 달 후에, 다시 한 시간을 더 들여서 몇 가지 기능을 추가했다. 여기에서 볼 수 있다: https://bestkeywordmixer.com 

spacer.png

또한 TMS는 단일 컴포넌트 라이브러리이고 완전한 크로스-플랫폼인 FNC 컴포넌트 라이브러리라는 제품을 계속 발전시켜 오고 있다. 그 결과, 개발자는 똑같은 컴포넌트를 사용하지만, 그 컴포넌트들은 델파이가 지원하는 모든 플랫폼의 폼(form)에서 그 모습이 똑같거나 매우 비슷하다. 심지어 웹 코어에서도 그렇다.  지금까지는, 각 플랫폼마다 다른 컴포넌트 라이브러리를 사용해야 했다.

델파이 앱들의 예시를 보여줄 수 있는가?

아래 그림은 최근 작업한 델파이 앱의 스냅샷이다. TTS (Text-to-Speech, 텍스트를 음성으로 변환하는) 요청을 처리하는 API를 제공하는 써드-파티 사이트에 접근한다. 가장 먼저 하는 일은 REST 요청을 하여 음성 목록을 받아와 담는(load) 것이다. 여기에서는 영어 음성을 모두 얻어서 리스트 하나 안에 넣었다. 더블클릭하면, 짧은 문장과 사용하고자 하는 음성을 함께 호스트 서버로 보낸다. 그리고, MP3 파일을 받아 와서 오디오 플레이어에 로드한다. 그러면 이제 소리로 들을 수 있게 된다. 아이디어는 마음에 드는 목소리를 고르는 것이다. 오디오 플레이어 컴포넌트와 오른쪽에 있는 트랙 바는 모두 FNC 컴포넌트 라이브러리에서 제공하는 것들이다. 실제로, 이 오디오 플레이어 컴포넌트는 내부에서 자바스크립트로 구현되어 있다. 윈32 앱임에도 불구하고 말이다. 이 코드를 웹 코어 앱으로 변환해면, 정확히 똑같이 동작한다.

spacer.png

델파이가 탑재된 RAD 스튜디오를 추천하는 다섯 번째 이유는 개발 속도이다

다섯째, 내가 생각하는 가장 중요한 장점이다. 현재 구입할 수 있는 것들 중에 델파이는 가장 빠르고 쉬운 플랫폼이다. 프로토타이핑과 코드 개발 양쪽 모두에서 그렇다.

먼저 말하고 싶은 것은, 델파이로 앱을 구축하는 것 외에도, 나는 델파이를 이용해 개략적인 디자인과 간단한 프로토 타입을 만드는 경우가 자주 있다는 점이다. 물론 PcC(proof-of-concept, 개념 증명) 그리고 기능 프로토타입을 제작을 할 때도 이용한다. 이런 경우에는 결국에 가서는 예상보다 훨씬 더 많은 기능을 갖추게 된다. 솔직히 말해, 나는 꽤 정교한 와이어프레임 모델링 툴들 몇 개 봤다. 가격은 거의 델파이와 비슷한 수준이었다. 그런데, 그것들은 모두 기능이 없는 모델만을 만드는 것들이다. 그런데도, 사람들은 델파이의 가격에 불만이다. 한 상자 안에 여러 도구들이 들어 있다고 생각하면 어떨까?

앱 개발과 관련하여, 델파이가 나의 생산성을 어떻게 향상시켰는지에 대해 말하려면, 할 이야기들이 여러 가지이다. 하지만 대부분은 그 회사들과 맺은 기밀 유지 계약으로 인해 말할 수 없다. 하지만, 지금 말 할  FLYBASE의 탄생에 관한 이야기는 내가 가장 좋아하는 것이고 내가 말 할 수 있는 것이다.

초파리 배아 연구에 대한 글로벌 데이터베이스를 구축하는데 델파이가 큰 역할을 했다는 사실을 알고 있는가?

나는 2000년부터 2004년까지 ASU의 바이오 디자인 연구소에서 근무했다. 그때 나는 그곳의 유전학 및 유전체학 교수였던 Sudhir Kumar[3]박사가 개발한 MEGA[4]라는 애플리케이션을 지원하는 일을 했다. 나는 Kumar 박사의 연구실에서 유전학 및 비교 유전체학 박사 학위 과정을 밟고 있던 대학원생들과 함께 일했다. 그는 델파이를 사용해 MEGA를 만들었고, 나는 이를 지원하고 확장하는 일을 도왔다.

(사실, 나는 이 분야에 대해 전혀 몰랐기 때문에 "왜 저를 고용하셨나요?"라고 물었다. 박사가 대답하기를, "제 경험상 프로그래머에게 유전학을 가르치는 것이 생물학자에게 프로그래밍을 잘하는 방법을 가르치는 것보다 훨씬 쉽기 때문입니다."라고 했다. 나는 그곳에서 근무하면서 확실히 유전학 및 유전체학에 대해 많은 것을 배웠지만, 퇴사 후에는 곧바로 대부분을 잊어버렸다.)

2002년 가을, Kumar 박사는 "다소 복잡한 작업"을 단순화하는 데 도움이 될 몇 가지 도구를 만들어 달라고 요청했다. 그리고 이 도구를 사용하게 될 인턴들을 몇 주 안에 고용할 것이라고 말했다. 박사는 전체적인 과정에 대한 틀을 요약해 주었다.

그의 아이디어는 데이터베이스 하나를 구축해서, 그 안에 전 세계 유전학 및 유전체학 연구자들이 공통적으로 사용하는 일부 데이터를 저장하는 것이었다. 그는 이를 Drosophila Image Acquisition Utility(초파리 이미지 수집 유틸리티, 아래 이미지 참조)라고 불렀고, 목표는 연구자들이 초파리에 대한 유전적 연구 세부 정보를 최대한 한곳에 수집할 수 있도록 하는 것이었다. (수십 년 동안 생물학자와 유전학 연구자들은, 여러 세대에 걸친 진화적 유전 경향을 연구하는데 초파리를 사용해 왔다. 초파리는 태어나고, 살아가고, 번식하고, 죽기는데 약 48시간이 걸린다. 따라서 여러 세대를 연구하는데 몇 주면 충분하다.)

초파리 이미지 캡처 유틸리티에 대해 자세히 알려줄 수 있는가?

실제 애플리케이션에 대해서는 기억이 잘 나지 않기 때문에 자세히 설명하지 못한다. 대신, 나에게 주어졌던 일반적인 요구 사항들을 이야기해 보겠다. 독자들 대부분은 다양하게 이와 비슷한 옵션들을 떠올릴 수 있을 것이다. 먼저, 이 프로젝트는 여러 단계에 걸쳐 Kumar 박사가 직접 발로 뛰면서 노력해서, 전체 프로젝트를 구축하기 위한 자금을 확보했다는 점을 알고 읽으면 도움이 될 것이다. 그 노력은 성공했을 뿐만 아니라, 그 결실은 오늘날까지 여전히 남아서 전 세계 연구자들이 자주 활용하고 있다.

나는 초기 단계에 참여했는데, 그 단계는 델파이를 사용하여 완수했다. 그때 나는 델파이를 사용했을 때 내가 얼마나 놀랄만큼 생산적인지 깨달았다. 그리고 내가 만든 초기 앱 역시 Kumar 박사의 예상보다 훨씬 더 생산적이었다.

Kumar 박사의 비전은  거대한 데이터 베이스를 구축하는 것이었다. 그래서 전 세계 연구자들이 초파리 배아에 대한 연구와 관련된 모든 세부 정보의 유형을 분류하고 상호 참조하는 데 사용할 수 있도록 하는 것이었다. 그는 시간을 가능한 멀리 앞 뒤로 오갈 수 있고 또 그만큼 실용적이기를 바랬다. 연구자가 이 데이터베이스에 접근하지 못한다면, 그는 자신의 연구와 관련된 세부 정보를 찾기 위해 엄청난 시간과 노력이 필요할 것이다. 그리고 종합적인 결과를 얻을 수도 없을 것이다. 구글™은 이런 종류의 작업에 도움이 되지 않았다. 이 데이터베이스가 '초파리 연구를 위한 구글™'이 되었다. 😃

spacer.png

이 엔터프라이즈 앱을 제작하는 데 사용한 디자인 절차는 무엇인가?

이 작업을 시작하기 위해 Kumar 박사는 지난 10년간 발표된 초파리 관련 논문 10,000편의 목록을 뽑아냈다. 그 논문들에는 배아 이미지와 해당 이미지 및 관련 연구에서 발견된 다양한 식별 특성이 들어 있었다. (일반적으로 이런 이미지들은 다양한 디테일을 표현하기 위해 다양한 빛의 파장으로 착색하고 조명한다.)

아래 수작업 절차(일명 '요구 사항 스펙')는 박사가 내게 자동화를 요청했던 것이다:

  • 출판된 논문(보통은 PDF파일)의 URL을 받아서 인터넷에서 액세스한다
  • 논문의 URL, 서지(bibliographic) 정보, 그리고 그 안에 있는 배아 이미지 수를 기록한다
  • 논문의 각 배아 이미지에 대해 다음을 수행한다
    • 이미지만 골라서 스크린샷을 찍는다(SnagIt과 같은 도구 사용)
    • 해당 이미지를 '원본' 이미지로 저장한다
    • 해당 이미지를 식별할 수 있는 모든 정보를 저장한다. 그래서, 온라인에서 그 이미지를 본 사람도 논문을 불러와 어떤 그림인지 정확히 알 수 있도록 한다
    • 이미지 크기를 고정된 크기 테두리(예: 600×400픽셀)에 맞게 조정한다
    • 이미지를 외부 프로그램을 통해 실행한다. 그래서, 필요에 따라 이미지를 회전하고 뒤집어서 정해진 방향에 맞춘다
    • 특정 방식으로 이미지를 자른다
    • 이미지 보정 작업을 한다
    • 보정한 이미지를 '처리된' 이미지라고 저장한다
    • 이미지를 외부 프로그램을 통해 실행한다. 그리고 특정한 그래픽 세부 정보(예: 특징)를 추출하고 그 특징들을 기록한다
    • 논문 내용을 스캔하여 기타 중요한 세부 사항을 찾아서 기록한다
    • 이 모든 세부 정보를 데이터베이스의 레코드에 저장한다.

수작업으로 처리할 때는, 각 단계마다 다른 프로그램을 사용하여 수행해야 했다. Kumar 박사는 나에게 (위와 같은) 작업의 개요를 건네주고, 모든 과정을 한 번씩 안내했다. 그리고는, "이 작업들을 자동화할 수 있는 방법을 델파이에서 찾아보세요. 기간은 2주 입니다."라고 했다.

어려웠을 것 같은데, 어땠는가?

개인적으로, 나는 이런 도전을 좋아하기 때문에 필요한 모든 작업을 자동화할 수 있는 앱을 개발하기 위해 미친듯이 노력했다. 나는  '마법사' 구조 즉, 한 화면에서 다음 화면으로 단계별로 이동하는 구조로 앱을 만들었다. 그리고 각 화면당 하나의 단계를 수행하도록 했다.  그 프로그램 밖으로 나갈 필요가 없었다. 또한,  한 논문에 대해 한두 단계까지만 수행하고, 다음 논문으로 이동할 수도 있게 했다. 이전에 완료하지 못한 논문으로 다시 돌아오면 마법사 안에서, 다음에 수행해야 할 단계에 위치하도록 했다. 표식을 붙일 수도 있는 기능도 넣었다. 예를 들어, 예를 들어 '3단계 처리가 필요한 논문만 제공할 것' 등이다. 덕분에 작업자는 동일한 작업을 반복적으로 수행할 수 있었다. 컨텍스트를 계속 전환하지 않아도 되었다. 이 기능들은 모든 상황에서 매우 잘 작동했다.

시작하기 위해, 우리는 먼저 10,000개의 전체 논문 목록과 해당 URL을 데이터베이스에 등록했다. 버튼을 클릭하여 시작하면, 데이터베이스의 목록 안에 있는 그 논문을 가져오도록 했다. 그래서 작업을 바로 시작할 수 있도록 했다. 주어진 논문은 한번에 오직 한 사람만 작업 할 수 있었다.

시작할 때, 이 프로그램은 논문을 어도비 아크로뱃(Adobe Acrobat) 안에서 열어 주었다. 그래서 사용자는 논문을 쭉 훑어 볼 수 있다. 그 다음, 마우스를 사용해 원하는 이미지를 선택하고 버튼을 클릭하면 해당 이미지를 캡처할 수 있다. 그러면, 다른 화면으로 옮겨가서 해당 이미지와 관련된 다른 세부 정보들을 확보하는 것을 완료할 수 있도록 했다.

예를 들어, 그 다음 마법사 페이지에서는 그 이미지를 정상화 하고, 뒤집고 회전하고, 자른 다음 보정한다. 작업한 모든 내용은 필요한 경우 다시 덮어쓸 수 있다. 그런 다음에는, 그 연구와 관련된 특징들을 그 논문 안에서 찾아낸다. 그래서 다른 연구자가 검색하고 저장하고 싶어할 수 있는 것들을 저장한다. 그 다음에는 그 논문으로 다시 돌아가서 그 논문에 있는 다른 이미지를 작업할 수 있다. 언제든지, 목록에 있는 다른 논문으로 이동할 수 있다.
사용했었던 외부 프로그램들 몇 가지는, 내가 그 소스 코드를 구할 수 있었기 때문에 내 앱 안에 직접(또는 DLL로) 통합할 수 있었다. 다른 작업은 간단하게 하위 작업으로 실행했다. DOS Command 셸을 작동시켜 실행했다.

어떤 데이터베이스 기술을 RAD 스튜디오에서 사용했는가?

spacer.png각 이미지에 대한 모든 데이터는 MySQL 데이터베이스 안에 저장했으며, 논문은 부모 레코드, 각 이미지는 자식 레코드로 저장했다. 최종 결과는 다음과 같았다. 연구자들은 이미지, 연구자, 날짜 등의 특성을 명시하여 전체 글로벌 작업 카탈로그를 검색할 수 있었다. 해당되는 모든 논문 내용이 나오고, 그 안에서 검색된 해당 세부 사항들은 강조 표시되었다. 사용자들은 이 기능이 매우 유용하다는 것을 금방 알게되었다.

Kumar 박사는 어떤 요소들을 기반으로 추정했는지 내게 알려준 적이 없다. 하지만 박사는 6명의 인턴을 고용해 6주 정도의 기간동안 업무 시간의 절반을 이 일에 할당할 계획이었고, 그 기간 안에 10,000개의 논문을 모두 분류하는 것이 가능하기를 기대하고 이 자동화 프로젝트를 나에게 맡겼던 것으로 생각된다. 박사는 내가 인턴들의 작업을 얼마나 단순하게 만들었는지에 대해서는 거의 알지 못했다!

프로젝트는 성공했는가?

간단히 말하자면, 그들은 내가 만든 델파이 앱을 사용해 단 2주 만에 10,000개의 논문을 모두 분류하는 작업을 완료했다. 그들이 작업을 착수하고 세번째 월요일이 되었을 때, 나는 작업실에 있었다. 모두들 점심 식사를 마치고 돌아와서는 다들 연구실에서 서성거리고 있었다. 그 때 Kumar 박사가 연구실에 들어와서는 "왜 일하지 않고 있느냐?"고 물었다. "왜 그러는 거예요! 일들 합시다"라고 박사가 말했다. 그런데 모두들 그대로 서 있었다. 그 중 한 사람이 "Kumar 박사님, 작업이 끝났어요." 라고 말했다. 인턴들 모두 고개를 끄덕였다. 박사가 "10,000개의 논문 모두를?"이라고 묻자. 모두들 고개를 끄덕였다. 박사는 "어디 보자..." 하면서 사무실의 컴퓨터 앞에 앉아 데이터베이스 쿼리를 실행했다. 정말 그 작업은 완료되어 있었다.

내 생각에 그 인턴들은 모두 기쁘지 않았을 것이다. 고용된 6주 중 2주치 부분만 급여를 받게 될 것이기 때문이다. 또한 내가 Kumar 박사에게 문제를 안겨주었다고 생각한다. 글쎄다. 내가 추측하기에 자금 지원 기관은 연구 자금이 얼마나 필요한지 산정할 때 너무 크게 산정하는 것을 좋아하지 않는다. 내가 그들을 위해 해 줄 수 있는 것은 더 이상 없었다. 맙소사.

핵심은,  Kumar 박사조차 그렇게 많은 작업을 이렇게 빨리 완료하게 해주는 프로그램을 예상하지 못했다는 점이다. 그것도 연구비 제안서를 작성하는 것을 도울 일회성 도구에 불과한 프로그램이 말이다.  2주간의 작업으로 내가 무엇을 해낼 수 있는지에 대해 나 스스로도 놀랐다. 이 '성공'은 부분적으로는 내 아키텍처 기술과 프로그래밍 기술 덕분이겠지만, 가장 크게 도움이 된 것은 델파이였다. 매우 사용하기 쉽고 생산성이 높았기 때문이다.

그렇다면, 델파이가 탑재된 RAD 스튜디오를 사용하여 앱을 구축하는 것이 매우 생산적이라고 판명된 것인가?

spacer.png델파이의 이러한 '높은 생산성' 측면은 다른 상황에서도 문제를 일으킨 경우가 있었다는 점을 언급해야겠다. 내가 고객들을 위해 프로포타입을 만들었을 때, 보기에도 그렇고 작동도 너무나 '진짜’같아서 그 고객들은 내가 이미 '거의 끝냈다’고 생각하는 경우들이 있었다. 고객들이 본 것은 헐리우드의 영화 세트장과도 같은 것이다. 겉모습은 되어 있지만, 그 뒤에는 또는 그 안에는 실제로 아무것도 없었다. 내가 만약 고객들을 속이려고 했다면 성공했을 거란 생각이 든다. 하지만 이런 내막을 잘 모르는 상대방에게 개발 시간이 더 필요하다고 협상하면 문제가 된다. 왜냐하면 내가 거짓말을 하고 있다고 생각하기 때문이다. 나는 프로토타입을 훨씬 덜 "진짜'처럼 보이게 만들어야 한다는 점을 배웠다. 심지어 나쁜 결과가 가끔 나오게끔 ('가짜 버그'를) 만들어야 한다. 그래야 더 많은 작업이 필요하다는 것을 명확히 알 수 있기 때문이다.

그 이후로 달라진 것이 있는가?

아마도 사람들은 "글쎄요. 그건 20년 전에 훨씬 더 오래된 버전의 델파이를 사용하던 때였잖아요!"라고 말할 수도 있다. 그렇다. 지금은 그때보다 시간이 30~50% 더 적게 소요될 것이다. 최신 버전의 델파이를 사용하면 말이다. 그 이유 중 일부는 오늘날의 컴퓨터가 훨씬 빠르기 때문이다. 또 다른 이유는 델파이용 컴포넌트들과 라이브러리들이 매우 많기 때문이다. 이것들은 수많은 로직을 간단히 폼 위에 뭔가를 올려놓고 나서 사용할 프로퍼티들 몇 가지만 설정하면 되도록 해준다.

또한, 나는 지금 심지어 앱을 개발해서 웹 상에서 실행할 수 있다. 따라서 누구든 세계 어디에서든 즉시 접근할 수 있다. 이것은 TMS 웹 코어 기술 덕분이다.

내가 말할 수 있는 것은 그 데이터를 등록한 데이터베이스가 있었기 때문에 Kumar 박사의 연구 동료들이 사용할 수 있었고, 그들이 그 데이터베이스가 매우 유용하다는 점을 알게 되었다는 사실이다. 내 생각에 이 버전이 발전하여 FlyBase [5]라고 불리는 것이 되었다.  Kumar 박사는 이 결과를 바탕으로 NIH(National Institutes of Health (미국) 국립 보건원)에 훨씬 더 큰 규모의 연구비 지원 제안서를 제출할 수 있었다. 그래서 FlyExpress [6]라는 훨씬 더 큰 규모의 데이터베이스가 나오게 되었다. FlyExpress는 MySQL 대신 오라클 DB를 사용했다. 내가 만든 FlyBase 앱은 공공연하게 더 널리 연구자들에게 배포되었고, 시간이 가면서, 훨씬 더 많은 기존 연구 논문들이 쌓여갔다. 오늘날, 이 두 앱 모두 전 세계 유전체학 연구 커뮤니티에서 매우 효과적으로 기여하고 있으며 여전히 건재하다.

내가 작업한 MEGA [4] 앱은 여전히 사용되고 있으며, 전 세계 유전학 및 유전체학 연구자들로부터 가장 널리 언급되는 도구이다. (아직도 델파이로 작성되어 있는지는 모르겠다. 하지만 이것은 지금 윈도우, 맥OS, 리눅스를 지원하고 있고, 일부 웹 컴포넌트들도 포함되어 있다는 것을 알 수 있다.)

Kumar 박사[3]는 현재 펜실베니아 주 필라델피아에 있는 템플 대학교(Temple University)에서 자신의 연구실을 책임지고 있으며, 그곳에서 비교 유전체학 분야의 연구를 계속 가르치고 이끌어 나가고 있다.

그리고 나는 이제 반쯤 은퇴해서, 내 자체 웹을 작업하고 있다...델파이, 웹 코어, 기타 TMS 기술 등을 사용해서 뭔가를 만들고 있다. 그리고 이 웹 앱이 조만간 세계적으로 성공하기를 기대하고 있다. ☺️

참고자료

  1. Anders Hejlsberg (델파이를 최초로 설계한 사람): https://en.wikipedia.org/wiki/Anders_Hejlsberg 
  2. Best Keyword Mixer (WEB Core 앱 예시, 델파이로 한 시간도 안 걸려서 구축했다): https://bestkeywordmixer.com 
  3. Dr. Sudhir Kumar: https://kumarlab.net/home 
  4. MEGA: https://www.megasoftware.net/ 
  5. FlyBase: http://flybase.org/ 
  6. FlyExpress: http://www.flyexpress.net/ 
  7. TMS Software: https://www.tmssoftware.com/site/default.asp?s=home 
  8. TMS WEB Core: https://www.tmssoftware.com/site/tmswebcoreintro.asp 
  9. TMS FNC Components Library: https://www.tmssoftware.com/site/fnc-products.asp 

이 글은 기업용 대형 애플리케이션에 대한 기고 경연 대회(Enterprise Article challenge)에 제출된 것이다. 만약 여러분도 델파이, C++빌더 또는 RAD 스튜디오를 사용하여 만든 훌륭한 엔터프라이즈 제품과 프로젝트에 대해 이야기하고 싶은 성공 사례가 있다면 연락을 주기 바란다.

한국 개발자는 데브기어의 델파이 사례 기고 행사에 참여하세요!

이 댓글 링크
다른 사이트에 공유하기

  • 어드민 changed the title to 세계 최고의 초파리 연구 엔진은 델파이를 사용해 구축되었다
  • 4주 후...

이 토의에 참여하세요

지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.

Guest
이 토픽(기고/질문)에 답하기

×   서식있는 텍스트로 붙여넣기.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   이전에 작성한 콘텐츠가 복원되었습니다..   편집창 비우기

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.