A short Primer to Java Memory Pool Sizing and Garbage Collectors
TAG GC

RIA와 Memory-Managed Programming

엔터프라이즈 자바 2007. 8. 4. 16:48 posted by 엔트웍스
자바 프로그래머는 메모리 할당과 해제에 신경쓸 필요가 없다. 자바는 메모리를 VM이 관리해주는 Memory-Managed Programming 언어이기 때문이다. 그저 new 키워드로 객체를 생성하고 쓰다가 잊어버리면 그만이다. C에서처럼 delete를 잊어버려 메모리 누수가 발생하는 문제도 없다. delete 키워드 따위는 애초에 존재하지도 않으며, C처럼 메모리 주소를 알아 낼 수 있는 방법도 없다. 겉보기에는 메모리라는 개념은 자바에 애초에 존재하지도 않으며, 메모리라는 저수준의 개념을 가지고 더 이상 머리를 싸맬 필요가 없다.

그러나 자바는 메모리 개념을 감추기만 했을 뿐 없애지는 못했다. 그리고 우리에게 가비지 컬렉터라는 신종 부라퀴를 풀어 놓았다. 참조가 해제된 객체가 가지고 있는 메모리를 해제하기 위한 가비지 컬렉터는, J2EE 환경에서 GC로 인한 성능저하 문제를 안겨준다.

게다가 메모리 누수 가능성이 0이 되지는 않았다. GC가 아무리 완벽하게 구현되었더라도 메모리 누수 가능성은 낮아질 뿐 0은 아니다. 간단히 어떤 클래스의 static 변수에 HashMap을 만들어 두면, 거기다 객체를 넣어두는 순간 이 객체는 영생을 얻고 메모리는 누수된다. 간단한 예지만 복잡하게 만들면 끝도 없이 복잡하게 만들 수도 있다. 자바는 메모리 누수에 대해 신경을 안쓰게 만들어 놓고 나중에 뒷통수를 때리는 언어일 수 있다.

결국 자바에서 메모리 관련한 문제가 해결된 것은 아무것도 없다. 나아진 것이라면 문제점들이 좀 더 정리되고 좀 더 컴포넌트화 되었다는 것이 달라졌을 뿐.

프로젝트에서 RIA(Rich Internet Application)를 적용하다 보니 문제는 돌고 도는 것이라는 진리를 다시금 깨닫는다. RIA도 메모리 문제에서 자유로울 수 없다.

기존의 DHTML 기반의 UI를 가진 시스템은, 클라이언트는 어느 정도 메모리 문제에서 자유롭다. 사용자는 하나의 페이지에서 길어야 분 단위로 머무를 뿐이다. 페이지가 갱신되고 나면  클라이언트 메모리는 다시 리셋된다. 따라서 하드코어하게 AJAX라도 사용하지 않는 한, 자바스크립트로 인한 누수된 메모리는 사용자가 인식하기 전에 새로운 페이지에서 사라져 버린다. 신경쓸 이유가 없으니 기억하거나 배울 필요도 없었다.

이제 RIA가 등장했다. RIA를 지원하는 환경은 모두 Memory-Managed Programming 언어를 제공한다. 그것이 어떤 언어이든지. 애시당초 웹 개발 언어가 Memory-Managed가 아니라면 보안문제가 발생할 것이다. 웹으로 다운로드 받은 프로그램이 내 OS의 메모리의 포인터를 얻어가는 걸 허용할 사람이 있을까?

그런데 대부분의 RIA 애플리케이션은 브라우저 입장에서는 하나의 웹페이지일 뿐이다. Rich한 애플리케이션은 러닝타임 또한 길 것이다. 러닝 타임이 길 수록 메모리 누수는 문제를 일으킬 가능성이 높아진다.

웹기반 시스템의 클라이언트 메모리 누수 문제? 심각하게 고민할 필요가 있나?

이것이 심각한 이유는, 대부분의 RIA 프로그램 들은 그 특성상 자체적으로도 하나하나의 객체가 상대적으로 메모리를 많이 차지하기 때문에, 메모리 누수는 매우 치명적일 가능성이 높다. RIA 애플리케이션은 각종 아이콘이나 이미지를 하나의 애플리케이션 메모리에서 처리함을 기억하라.

게다가 대부분의 RIA 프로그래머는 커리어의 특성상 이러한 메모리 누수의 개념 자체가 희박하거나, 기존 웹페이지 방식의 개발에 익숙한 나머지 그만 잊어버렸다는 것이다. 따라서 메모리 누수를 일으키는 프로그램을 작성할 가능성이 매우 높다. 팝업 윈도우 하나 띄우는데 1메가의 메모리가 필요하고, 이 팝업 윈도우를 닫아도 메모리가 해제되지 않는다면 그것은 재앙이나 다름없다.

게다가 대부분의 RIA 플랫폼은 GC를 통해 메모리를 해제하게 된다. 그런데 각 RIA 플랫폼의 GC 알고리즘은 아직 성숙되지도 않았고, 제대로 된 프로파일링 도구도 제공되지 않기 때문에 GC가 수행되었는지 알기 조차 힘들다. 또 GC는 대부분 수동 제어가 불가능하다.

메모리 누수 문제는 치명적인데 메모리 관리의 근간이 허술하니, 결국 인력으로 돌파할 수 밖에 없다. 경험 많은 엔지니어가 프로젝트 초기에 메모리 문제에 관해 명시하고 해결방법을 모색하고 가이드라인을 제공하고 프레임워크화하지 않는다면, 아마 대부분의 프로젝트는 막판에, 최악의 경우에는 프로젝트 완료 후에 진정한 고생길이 열릴 것이다.

Flex? Silverlight? JavaFX?
DHTML 기반에서는 꿈도 꾸지 못하던 멋진 사용자 인터페이스. 마치 데스크탑 애플리케이션같은 User Experience를 제공하는 매력적인 웹기반 시스템.
그러나 세상에 공짜는 없는 법이다.
모든 문제는 해결되지 않고 다른 곳에서 나타날 뿐이다.
RIA는 웹과 Rich Client의 빛을 함께 지녔지만, 중첩된 그림자는 더 진하다.

  1. Commented by 얼음공주 at 2007.08.21 15:23

    블로그 구경잘 하였습니다. 블로그에 필요한 동영상, boom4u.net 도 구경 오세요~~

  2. Commented by 민재 at 2007.12.05 17:53

    Memory-Managed가 아니라면 보안문제가 발생
    RIA는 메모리 관리가 되므로 보안 문제가 발생하지 않는다는 말이죠?

    이 부분은 여전히 헷갈리는 부분입니다. 개념적으로 잘 안 서요..

    • Commented by Favicon of http://crosscutter.info BlogIcon entworks at 2007.12.06 18:27

      아니 갑자기 이 글이 왜 최신으로 갱신되었죠.. -_-
      Memory-managed 프로그래밍 환경이 사용자측 리소스 보안 문제를 예방하는 충분조건은 아니고, 중요한 필요조건 정도가 아닐까요? 파일이나 키보드같은 자원에 액세스하는 걸 프로그래밍 언어가 막는건 아니니까요.

  3. Commented by 민재 at 2007.12.05 17:53

    "RIA는 웹과 Rich Client의 빛을 함께 지녔지만, 중첩된 그림자는 더 진하다." 이 말 멋지군요.. 음.

같기도

엔터프라이즈 자바 2007. 8. 3. 12:22 posted by 엔트웍스
- 자바는 메모리 누수가 있는 것도 아니고 없는 것도 아니다.
- 자바는 C보다 빠른 것도 아니고 느린 것도 아니다.
- EJB는 비즈니스 로직에만 집중하게 하기도 하면서 기술적 이슈에 더 깊은 이해를 필요로 한다.
- RIA는 웹과 리치 클라이언트의 장점을 모두 가진다. 한편 웹과 리치 클라이언트의 단점도 모두 가진다.
- Memory-managed Programming은 메모리 할당과 해제에서 해방시켰지만 Garbage Collection이라는 숙제를 던졌다.
- 오픈 스탠다드는 모두의 허기는 채워주지만 각자의 입맛은 만족시키지 못한다.


.... 세상에 공짜는 없다.

  1. Commented by Favicon of http://uggi.tistory.com BlogIcon 어기 at 2007.08.09 14:30

    와우~~

아래는 현재 프로젝트에서 발생한 문제점을 해결하기 위해 검색하여 찾은 정보를 정리한 것이다.

[GC의 수행 조건]

1. 고정 크기 메모리 블록의 chunk 단위로 OS의 메모리를 할당/해제
2. chunk의 집합이 Flash의 Memory Pool(JVM의 Heap과 같은 개념)이 됨
3. 객체 생성시마다 Pool에서 메모리를 할당 받음
4. 할당시 Pool이 바닥나면 GC 수행
5. GC는 4번 이벤트 시점에만 수행됨(!)

[GC 수행 규칙]
1. Java와 동일하에 Reference Count로 GC 대상을  분류함
2. 한 번의 GC 수행이 모든 GC 대상을 collect 하는 것은 아님(!)
3. GC 후 chunk를 정리하여 사용율 0인 chunk는 OS로 반환함

[Memory Leak 문제]
1. GC 자체의 Memory Leak 버그는 입증된 바 없음
2. EventListener의 reference 규칙을 이해하지 못하면 leak 위험성 상존

[Memory Leak의 해결]
1. EventListener에 의한 leak 해결방법은 정확한 이해와 함께 weak reference를 적극/정확히 사용하는 것
2. Flex 자체 제공 컴포넌트 일부에서도 leak를 유발한다고 함.

[요약]
1. GC 자체는 버그가 없다고 볼 수 있으나 애매한 작동 방식은 각종 FUD의 원인이 됨.
2. Memory Leak를 일으킬 수 있는 케이스에 대해 반드시 숙지하고 개발해야 함

Limitations of the Java Virtual Machine

엔터프라이즈 자바 2007. 7. 27. 09:41 posted by 엔트웍스
역시 OOOO....
(OOOO는 무엇일까요? 힌트: 네 글자 이름의 프레임워크입니다.)

자바의 한계를 또 하나 깨닫게 했다.
(정확히 이야기자면, 현실에서도 발생할 수 있는 것임을 깨닫게 했다.)
자바 개발 시에는 메소드 크기가 64K가 넘지 않도록 주의해야 한다.
다음 링크에서 볼 수 있다.
Limitations of the Java Virtual Machine

JSP 개발시에 이 제약조건에 주의하라는 경고 - 하나의 JSP 페이지는 전체가 하나의 메소드 내 구현 코드로 변환되어 컴파일 된다 - 를 책에서는 본 적이 있으나,
말 그대로 책 속의 이야기였다. 64K가 넘는 메소드는 경험해 본 적이 없다.

그런데 OOOO은 이것이 책 속의 이야기가 아님을 알게 해줬다.

보다 심각한 사실은,
컴파일이 안되는 소스가 JSP가 아니라 제품의 코드생성기에 의해 생성된 자바 코드라는 것이다.

OOOO의 코드 생성기를 고치던가,
DTO 구조를 분해하던가 해야 한다.

이번 일로 새롭게 알게 된 한 가지 교훈이다.

컴파일된 자바 메소드의 바이트코드는 64K를 넘어가면 컴파일시 오류 발생. 따라서 혹시라도 소스 생성기를 만들 때는 메소드의 크기에도 신경쓰자(손으로 코딩할 때는 하고 싶어도 하기 힘들다).


개인적 감상.
- 역시 OOOO과는 친해지기 어렵다.

TAG 64k, OOOO, 제한
  1. Commented by Favicon of http://younghoe.info BlogIcon 영회 at 2007.07.30 12:28

    답을 알 듯... 혹시.. 그거?

  2. Commented by Favicon of http://www.ologist.co.kr BlogIcon ologist at 2007.08.08 00:05

    정말 놀라운 사실이네요. 그런 제약사항이 있었다니~
    근데, 코드생성이 넘 과도하네요..^^

  3. Commented by Favicon of http://wookay.egloos.com BlogIcon ㄴㅇㄱ at 2007.12.05 23:59

    후후. 메소드가 얼마나 크길래 ^^

  4. Commented by Favicon of http://daeheekim.tistory.com BlogIcon kazami at 2008.05.16 12:56

    저도 몇년전에 프로젝트하면서 옆의 팀원이 겪은 상황이었는데,
    기존 PL/SQL의 로직을 떼서 java에 전환시키는데 분기되는 경우의수가 많아서.. 쪼개고 쪼개서 나눈적이 있었습니다.

Flex 적용 프로젝트의 이슈

엔터프라이즈 자바 2007. 7. 24. 10:02 posted by 엔트웍스
[성능]

A. Application이 전체적으로 무거움
    -> Flex Runtime 개선 필요
    -> 결론은 UI 디자인 시 이미지와 효과 등을 배제하고 최대한 단순하게
   -> 방법론적 해결은... 초기에 디자인 방향을 몇가지 설정하고 이에 대한 BMT 실시. 각 방향에 따른 사용자 PC 사양 컨펌

B. Flex Builder가 무거움
    -> Java 기반의 개발환경의 근본적인 문제점
    -> 개발자 PC 사양을 높일 수 밖에(P4급 CPU & 2G Memory)

[한글문제]

A. 한글 입력시 반응이 다소 느림
   -> Flex Runtime의 개선이 없는 한 해결 불가

B. 한글 폰트에 따라 컴포넌트 내의 수직 align 문제 발생
   -> Flex Runtime의 개선이 없는 한 근본적 해결 불가
  -> 임시 해결책은 문제가 없는 폰트와 사이즈로 통일 시키는 것

[Flex Architecture]

A. 개발시 컴파일 오버헤드
    -> Flex의 근본 아키텍처임
    -> 로컬 개발/테스트 환경 및 서버 빌드/배포 도구/프로세스를 초반에 확립해야 함

B. Rich Internet Application
    -> Rich 하다는 것은 Thin Internet Application(ex. JSP)에 비해 Presentation & Application 코드량과 복잡도 증가를 의미함
    -> 아키텍처링시 Flex Application 설계를 기존에 비해 더 고민할 것
    -> Flex 전문가를 초기에 프로젝트에 참여시켜 프레임워크 개발 & 컴포넌트화에 노력

[기타]

A. 서버 주소가 하드코딩된 URL
    -> 개발서버/QA서버/Production서버 간 이관에 따른 형상관리가 어려워짐
    -> Flex 만의 문제는 아니지만 Flex 만 놓고 보자면...
   -> 초기에 Flex App내에 사용될 URL의 종류를 분류하고 각각에 대해 App 내에서 하드코딩을 피하는 메커니즘 및 정책 강구

B. Flex Application의 컴포넌트화
    -> SWF 용량과 응집도를 고려한 컴포넌트 식별 프로세스를 반드시 거쳐야 함


TAG flex, 이슈
  1. Commented by Favicon of http://thetree.tistory.com BlogIcon pisteuo at 2007.07.25 13:33

    직접 경험해 보지 않고도 상황을 그릴 수가 있게 잘 정리해 놓으신 것 같습니다.
    아주 유용한 정보 감사합니다. 행복하세요~ ^^

  2. Commented by Favicon of http://cbiscuit.info BlogIcon cbiscuit at 2007.07.26 16:36

    아래와 같은 형식으로 정리하면 더 좋은 글이 될 수 있을 것 같네요. ^^

    1 문제점
    - 제품측면
    - 사용측면
    - 타제품연계측면

    2 예상원인
    - 플렉스 아키텍처
    - 개발환경 및 프로세스

    3 해결방안
    - 기술지원 강화
    - 프로세스 개선
    - 미해결

서비스 연동 방식의 특성 분류

엔터프라이즈 자바 2007. 7. 17. 16:17 posted by 엔트웍스
[Plain Java Call]
VM : Local
Class Loader : Shared
Class Dependency(Interface) : Yes
Class Dependency(Parameter) : Yes
Parameter Style : Object
Parameter Pass By : Reference
Sync : Sync
Note : 기본 자바 호출 타입

[RMI Call]
VM : Remote
Class Loader : Separate
Class Dependency(Interface) : Yes
Class Dependency(Parameter) : Yes
Parameter Style : Object
Parameter Pass By : Value
Sync : Sync
Note : 기본 원격 호출. Caller측 ClassLoader에 Callee의 원격 인터페이스 & 파라미터 클래스를 반드시 로딩시켜야 한다

[Local Session/Entity Bean Call]
VM : Local
Class Loader : Shared
Class Dependency(Interface) : Yes
Class Dependency(Parameter) : Yes
Parameter Style : Object
Parameter Pass By : Reference
Sync : Sync
Note : Local의 의미는 VM-local이 아니라, ClassLoader-local 이라고 봐야 한다. 같은 WAS(VM) Instance 내에서의 호출이라 할지라도, Callee 측 EJB Interface 정보가 Caller측의 ClassLoader에 로딩되지 않으면 호출시 NoClassDefFoundError가 발생한다. 실제로 같은 EAR 내에 packaging 하지 않는한 Local EJB Call은 정상적으로는 불가능하다.

[Remote Session/Entity Bean Call]
VM : Basically Remote
Class Loader : Basically Separate
Class Dependency(Interface) : Yes
Class Dependency(Parameter) : Yes
Parameter Style : Object
Parameter Pass By : Basically Value
Sync : Sync
Note : Remote EJB라 할지라도 대부분의 WAS에서는 Local Call로 최적화 시킬 수 있다. 다만, parameter semantics는 Call-by-value를 따라야만 한다.

[Message-driven Bean Call]
VM : Remote/Local
Class Loader : Basically Separate
Class Dependency(Interface) : Yes
Class Dependency(Parameter) : Yes
Parameter Style : Object
Parameter Pass By : Basically Value
Sync : Sync
Note : 기본적으로 Class Dependency가 없다. 다만 ObjectMessage를 사용하는 경우에는 Dependency가 발생한다.

TAG SOA, 연동
  1. Commented by Favicon of http://younghoe.info BlogIcon 영회 at 2007.07.23 14:54

    오~~ 오랜만에 보는 글입니다.

  2. Commented by 경욱 at 2007.07.24 11:12

    지훈~ 살아 있었네 ^^

소스생성기술에 의존하지 마라

엔터프라이즈 자바 2007. 3. 29. 20:32 posted by 엔트웍스
요즘 세상에 소스생성기술은 새삼스러운 것이 아니다.
Rose나 Together 같은 모델링 도구의 forward engineering 기술은 물론이며,
Eclipse만 해도 상위 클래스의 생성자 정보를 토대로 생성자를 생성해 주기도 하고, property에 대한 getter/setter를 만들어 주기도 한다.
또 프로그래밍을 잘 하는 사람(혹은 귀차니즘이 심한 사람)은 한 두가지 쯤 사제 소스(혹은 SQL) 생성 툴을 가지고 있을 것이다.
프로그래머 입장에서 소스생성은 귀찮고 반복적인 작업을 꽤나 줄여주고, 경우에 따라서는 생산성을 높이는데 공을 세울 수도 있다.

그러나 프로젝트 관점에서는 소스생성은 아주 잘 써봐야 수% 비용밖에 절감할 수 없다는 것이 내 생각이다. 오히려 소스생성기술을 잘못 적용하면 절감은 커녕 비용이 증가할 위험이 더 크다.

우선 프로그래머가 프로젝트 전체에서 소스생성기가 생성해 주는 소스를 타이핑하는데 걸리는 시간은 아주 많아야 1%(본문에서 등장하는 수치는 모두 주관적이고 직관에 의한 수치이다)도 안되는 경우가 대부분일 것이다. 물론 %는 업무가 단순하고 소스 생성기가 좋을 수록 높기는 할 것이다.
나머지는 업무를 분석하고 이해하고 어떻게 프로그래밍할 지 고민하고 실행하고 오류 원인을 찾고 코드를 고치는 시간이다.
과연 이렇게 얻어지는 시간이 소스생성기의 구매/개발/학습/사용부담에 드는 비용을 상쇄할 수 있을까?

문제는 잘못 적용하면 소스 생성 기술이 오히려 독이 되는 경우가 있다는 것이다.

생성되는 소스가 오히려 잘못된 설계를, 잘못된 동작을 유도한다면?

또 아키텍처 혹은 정책이 변경되었는데 이 부분이 소스생성기술에 의존하고 있었다면, 기존에 생성되었던(게다가 십중팔구 추가/수정이 발생된) 소스 들은 어떻게 하는가?
어떻게 하긴... 모조리 찾아 내서 고치는 수밖에 없다.

더 심각한 경우는, 소스생성기가 아예 생성된 소스의 수정은 원천봉쇄하는 경우이다.
그런 경우를 못 본 사람이 더 많겠지만 최근 그러한 소스생성기의 존재를 확인할 수 있었다.
이 경우는 완전히 소스 생성기에 의존할 수 밖에 없으므로, 소스생성기 작성자(혹은 업체)는 100% 프로젝트 병목이 될 수 밖에 없다. 그리고 첨언하면 이 소스생성기는 상당히 안좋은  설계의 클래스와 엄청난 중복 코드를 생산하며, 보도 듣도 못한 제약사항 들이 곳곳에 숨어 있어서 하다보면 하나둘씩 머리를 쳐 든다.
(옛날에도 이러한 도구가 있었으나 곧 망했다고 한다. 그리고 현재에는 다른 도구가 이와 유사한 모습으로 작동하고 있다.)

소스생성기술은 잘만 선택(혹은 개발)하면 나름대로 괜찮은, 특히 프로그래머의 귀차니즘을 날려버려서 의욕을 북돋는 기술이 될 수 있다.
그러나 조금만 부주의하게 선택(주로 벤더의 부추김에 의해)한다면 아마 프로젝트는 생산성은 커녕, 그나마 얻는 수%의 생산성보다 훨씬 많은 비용을 지불하며 숨어 있던 위험과 제약사항에 빠져 허우적 댈 것이다.

프로젝트에서 다음의 원칙을 지킨다면 아마 이러한 위험은 피할 수 있을 것이다.
  • 소스생성기능을 강력히 자랑하는 도구는 피하라.
  • 소스생성기능이 없으면 개발자체가 불가능한 도구는 절대 잊으면 안된다. 깜빡하면 나중에 또 소개자료를 읽는 엄청난 손실이 생긴다.
  • 소스생성기술을 가지고 엄청나게 생산성을 높이려는 생각은 버려라. 잘만 적용한다면 수십%도 얻을 수 있겠지만, 일반적으로 5%만 얻어도 엄청난 생산성이라고 믿는 편이 낫다.


  1. Commented by Favicon of http://cbiscuit.info BlogIcon cbiscuit at 2007.03.31 01:00

    혹시... HOORO HOOREM 아니야?

    일부 지각있는 개발자들이 보고는 치를 떤다는.. 그..

바나나우유는 하얗다

엔터프라이즈 자바 2007. 2. 23. 18:55 posted by 엔트웍스
먼저 매일유업, 하얀 바나나우유에 박수를!! 을 보세요.
재미로만 봐도 동영상이 정말 재밌군요.

그리고, 포스팅에도 나온 질문.

바나나 우유는 왜 노란색일까?
바나나 껍데기로 만드건가?

IT 분야에 종사하는 우리에게도 시사하는 바가 큽니다.

조금만 생각해봐도 답이 뻔히 나오는 지극한 상식을 상식이라 말하지 못하고,
남들이 베스트 프랙티스, 관행 등으로 포장한 지극히 상식적인 일을,
좋은 거라니까...
대세가 그렇다니까...
옛날부터 그랬다니까...
마치 상식인 것처럼 하고 계시지는 않는지요?

M유업의 기막힌 상술이기는 합니다만,
상식에 대해 다시 한 번 생각해 볼 수 있는 기회로 삼을 수 있을 것 같습니다.

  1. Commented by Favicon of http://seal.tistory.com BlogIcon 물개선생 at 2007.02.26 09:01

    로드존슨이 쓴 J2EE without EJB에서 비판적 사고가 무엇인지에 대해 깨달을 수 있었지만, 그렇게 얻은 깨달음을 실천하기란 정말 쉽지 않았습니다. 가끔은 그저 좋은거라니까.. 대세가 그러니까, 옛날부터 그랬으니까.. 하고 살았던 때가 더 좋았지 않나. 하는 생각도 듭니다.

    • Commented by Favicon of http://cbiscuit.info BlogIcon cBiscuit at 2007.02.26 12:27

      알면 알 수록 머리 아파지고 힘들어지는 삶이라..

    • Commented by Favicon of http://crosscutter.info BlogIcon EntWorks at 2007.02.26 19:16

      앞으로도 쉽지는 않겠죠. 수많은 비상식적인 상식과 FUD, 그리고 myth를 물리치려면... 열정과 논리의 학익진을 펼치는 길 외에는 없을 것 같습니다.
      갑자기 매트릭스에서 깨어난 네오 생각이 나네요 ㅎㅎ

  2. Commented by Favicon of http://crosscutter.info BlogIcon EntWorks at 2007.02.26 22:11

    그나저나 저녁을 굶는 바람에 빵 하나하고 "바나나는 하얗다"를 직접 먹어보았습니다.
    원재료를 살펴보니 무색소도 맞고 바나나농축과즙이 들어가는 있습니다만, "바나나향 합성착향료"도 같이 들어가 있네요.
    마케팅 비디오는 좋았지만 실제는 기대가 조금 깨지는 군요.
    하기야 이 정도 맛을 내려면 저런 인공향을 넣지 않고서는 안되는 것도 일종의 "상식"이긴 하겠군요.

  3. Commented by Favicon of http://blog.naver.com/rryusoo BlogIcon 제니 at 2007.10.09 17:51

    바나나..

    껍질을 막 깠을때는 하얀색
    으깨 놓으면 노란색
    으깨 놓은채로 그냥 두면 까만색..

    원래 하얗다는건 껍질을 깠을때?
    그렇게 보면 사과도, 배도, 복숭아도, @@@
    모두 하얀색이란 말이지..

Deployment Time

엔터프라이즈 자바 2007. 2. 21. 03:07 posted by 엔트웍스
30초 : Deployment Request를 검토하는 데 걸리는 시간
01분 : Deployment Plan을 작성하는 데 걸리는 시간
05분 : Application Server가 기동되어 완전히 실행모드 상태로 진입하는데 걸리는 시간
22분 : Deployment 중 애플리케이션 컴파일(appc)에 걸리는 시간
45분 : 전체 Deployment가 종료하는데 걸리는 시간
60분 : 코드 한 줄 수정하여 Application Server에 Deployment가 완료되는데 걸리는 시간

  1. Commented by Favicon of http://cbiscuit.info BlogIcon cBiscuit at 2007.02.21 16:45

    너무 오래 걸린다... 10분 안으로 땅겨!

  2. Commented by Favicon of http://cbiscuit.info BlogIcon cBiscuit at 2007.02.23 16:45

    그런데 이렇게 써 놓고 보니까 50년전 천공카드에 구멍뚫어서 OP한테 신청해놓고 실행결과 한정없이 기다리던 그때 그 시절 같다야... ㅎㅎ 한줄 고치고 1시간을 기다려야 하다니..