대웅제약은 최근 소송과 관련해서 다시 이슈가 된 이후, 약 8% 가량 떨어지면서 최근 바이오주식들이 하락세를 보이는 와중에 18만원대로 떨어졌다. 덕분에 기존에 진입을 못했던 투자자들에게는 진입 기회가 온 것이다.
물론, 코오롱생명과학처럼 이슈가 문제가 되어, -70% 손실을 볼 수도 있겠으나, 최근 대웅제약의 나보타는 미국에서 판매가 좋을 뿐만 아니라, 유럽까지 판매처를 확산하고 있다. 관련 기사는 아래에 링크를 확인하시면 된다.
기사1) 대웅제약은 ITC의 미국 국제무역위원회(International Trade Commission, ITC)가 결정한 균주에 대한 증거수집 절차를 통해 메디톡스 균주를 비교 분석하여 나보타 균주의 적법성을 증명할 예정이라고 14일 밝혔다. 미국 소송은 한국 소송과 달리 증거수집 절차를 통해 양 측이 소송에 필요한 자료를 서로에게 요구, 전달받도록 돼 있다.
증거수집 절차 기간 동안에는 양 측이 필요한 자료들을 추가적으로 요청할 수 있으며 대웅제약도 포자 형성 여부 감정과 유전체 염기서열분석 등을 진행하기 위해 메디톡스의 균주를 제공받도록 요청했다. ITC 재판부는 증거수집 절차에 따라 양사에 균주 제출을 요구할 것이므로 메디톡스 역시 대웅제약이 지정한 전문가에게 균주를 제출하게 된다. 대웅제약은 양사의 균주를 정밀 비교 분석하여 그 결과를 ITC에 제출할 예정이다. 현재 증거수집 절차에 따라 양사는 서로에게 균주를 제출하는 시기와 방법에 대해 조율 중이다.
대웅제약이 소송에 실패시 승자가 되는 메디톡스의 주식에는 큰 변화가 없음.
대웅제약에 따르면 메디톡스는 현재까지 언론보도를 통해 자사의 전체 염기서열을 공개하겠다고 하면서 이를 통해 양사의 균주를 비교하자고 적극적으로 주장해 왔다.
그러나 아직까지 전체 염기서열을 직접 공개하지 않고 있으며, 자사의 균주가 어떠한 경우에도 포자를 형성하지 않는다고 국내소송 등에서 일관되게 발표해 왔다. 대웅제약은 미국소송 뿐만 아니라 국내 소송에서 양사 균주의 포자 형성 여부를 비교함으로써 메디톡스 주장의 허구성을 입증할 것으로 기대하고 있다고 밝혔다.
기사2)2019.04.26 대웅제약(179,000원▲ 5,000 2.87%)이 자체 개발한 보툴리눔 톡신 제제 "나보타"의 유럽시장 진출을 위한 마지막 허가관문을 넘어섰다. 유럽 내 의약품 사용을 심사하는 전문가들의 권고로 사실상 현지 허가 발표 절차만 남기게 된 것이다.
대웅제약은 26일(현지시각) 유럽의약품청(EMA) 산하 약물사용자문위원회(CHMP)에서 나보타(유럽제품명 누시바)의 미간주름 개선 효과에 대한 유럽 사용허가 권고 의견을 획득했다고 밝혔다.
추가)대웅제약이 올해 1분기 매출액은 2381억원, 영업이익은 102억원을 기록했다. 이는 지난해 같은 기간에 비해 매출은 10.3%, 영업이익은 27.2% 증가한 실적이다.
온라인 서비스는 멀티프로세스로 인해, 개별 거래의 속도가 느릴지라도 사용자가 느낄 만큼 속도가 느린 경우는 없다. 물론 조회시 where 조건들이 index에 등록되어 있지 않다면, 처음에는 속도가 느린 것을 느끼지 못할지라도 ... 자료가 쌓이면 속도가 느린 것을 느낄 것이다.
그럼 실행 쿼리의 실행시간 기준으로 TOP 10을 조회하여, 해당 where 조건에 항목들에 대해 인덱스를 생성해주면 된다.
인덱스 생성시에 모든 조건을 인덱스로 만들어서는 안된다. 데이터 1건인데, 인덱스가 10개면 실제 11개의 처리가 발생하므로, 속도저하가 발생하고 인덱스 실행 계획이 원하지 예상하지 못하는 방식으로 나와 문제가 될 수 있다.
인덱스는 무조건 5개 이하이다.
왠만하여 공통 인덱스는 모든 업무를 커버할 수 있도록 선정하고, 조회는 인덱스만 잘 설정되어 있다면 문제 없다.
만약, 배치업무를 수행하는데 느리다면, 다음 사항을 체크해 보자.
1. 조회시 인덱스를 이용하는지? 2. Array 작업을 수행하는지? 3. 중간중간 commit 을 수행할 수 있는지? 4. Counter 체크 5. 통계 정보 생성 6. 불필요한 과거 정보 삭제 7. 업무 프로세스 변경
1. 조회시 인덱스를 이용하는지? 또는 TABLE FULL SCAN 을 하는지? 만들었다고 생각하지 말고, 체크해보자. 그리고 인덱스는 순차적으로 차례대로 찾기 때문에 항목이 5개인 인덱스는 중간에 3번 항목이 없다면, 결국 1번과 2번 항목만 인덱스를 읽고 나머지는 range_scan을 하기 때문에 데이터량에 따라 항목 조절을 해야 한다.
2. Array 작업을 수행하는지? 대량의 작업은 기본적으로 다량 Fetch, 일괄 Insert(또는 Update)를 수행해야 속도가 빠르다. execute() * 10000 보다는 batch_Execute() * 5 가 몇십배 빠르다.
3. 중간중간 commit 을 수행할 수 있는지? 업무에 따라, 중간에 commit을 할수 있다면, 몇천건 또는 몇만건 단위로 commit을 수행한다면 재작업시 작업량을 줄일 수 있다. 검토 후 중간에 commit을 삽입하자.
4. Counter 체크 : 오라클의 sequence를 사용하지 않고, select max(seq) from tableA; 사용한다면, 당장 변경하라. * 혹시 개발자 중에서 SELECT TASEQ.nextval from BigTable where rownum =1; 로 개발했다면, 당장 변경하라. SELECT TASEQ.nextval from dual; 로 실제 수행속도는 테이블의 사이즈에따라 몇백배까지 차이 난다.
5. 통계 정보 생성 : 통계정보가 최신화 되지 않아 plan이 느릴 수 있으므로, Analyze 해보자.
6. 불필요한 과거 정보 삭제 :데이터의 사이즈에 따라, 성능이 저하될 수 도 있으므로 과거 정보 삭제나 parition 나누자.
7. 업무 프로세스 변경 : DB에서 index 타고, 기본적인 속도개선까지 했다면 프로세스 변경을 고려해 보자. 여기까지 한 후, 하드웨어 증설을 고려하자.
# 추가 설명. sql 구성요소들은 아래와 같은 순서로 실행 된다
1) FROM, WHERE 절을 처리 2) ROWNUM 조건 적용 3) SELECT COLUMN LIST 절을 적용 4) GROUP BY 절을 적용 5) HAVING 절을 적용 6) ORDER BY 절을 적용
그러므로, 4번의 예시처럼 의미없이 대량의 테이블에서 rownum <=1 을 하면, 대량의 자료를 fetch 한후 nextval을 가져오는 불필요한 작업이 발생하므로, dual을 적절히 사용하자.
추가 tip. SMS 제품에서는 Oracle에서 제공하 v$sql, DBA_HIST_SQLSTAT, DBA_HIST_SQLTEXT, DBA_HIST_SNAPSHOT 등의 테이블을 이용하여, TOP N Query(상위 N개의 쿼리)를 제공한다. 이것을 바탕으로 지연 서비스의 쿼리 실행계획 및 실행 단위의 소요시간까지 제공해준다. SMS제품이 제공해 주는 것외에 본인이 DBA 또는 고급 개발자로써, 서비스 품질을 위한다면, 아래의 내용을 참고하여 개선 대상을 찾아 고민해보자.
다만, 아래의 것은 여러분이 문제를 찾기 위한 Query일 뿐, 해결방법은 각양각색이므로 획일적으로 답할 순 없다.
반복하는 쿼리 중에서 총 수행시간이 긴 쿼리 찾기. (짧은 업무일지라도, 단일 프로세스로 처리되면 문제가 된다. 예를 들어, 30msec * 100만번이면, 300,00초= 6,000분 = 100시간이 된다.)
SELECT * FROM ( SELECT S.SQL_ID, ROUND(SUM(CPU_TIME_DELTA)/100000) CPUTIME, SUM(EXECUTIONS_DELTA) TOTAL_EXECUTED, DBMS_LOB.SUBSTR(SQL_TEXT,2000,1) SQLTEXT FROM DBA_HIST_SQLSTAT H, DBA_HIST_SQLTEXT S, DBA_HIST_SNAPSHOT T WHERE S.SQL_ID = H.SQL_ID AND H.SNAP_ID = T.SNAP_ID AND T.BEGIN_INTERVAL_TIME BETWEEN TO_DATE('20190513 09:00:00','YYYYMMDD HH24:MI:SS') AND TO_DATE('20190514 15:00:00','YYYYMMDD HH24:MI:SS') GROUP BY S.SQL_ID, DBMS_LOB.SUBSTR(SQL_TEXT,2000,1) ORDER BY 3 DESC ) WHERE rownum < 21 and CPUTIME > 1000 ;
ORACLE서버에서 수행시간이 긴 쿼리 찾기 쿼리 SELECT ROWNUM NO, PARSING_SCHEMA_NAME, to_char(ELAPSED_TIME/(1000000 * decode(executions,null,1,0,1,executions)),999999.9999 ) 평균실행시간, executions 실행횟수, SQL_TEXT 쿼리 , SQL_FULLTEXT FROM V$SQL WHERE LAST_ACTIVE_TIME > SYSDATE-(1/24*2) -- AND LAST_ACTIVE_TIME BETWEEN to_Date('20111226163000','YYYYMMDDHH24MISS') AND to_Date('20111226170000','YYYYMMDDHH24MISS') -- AND ELAPSED_TIME >= 1 * 1000000 * decode(executions,null,1,0,1,executions) and PARSING_SCHEMA_NAME = 'ZIPCODE' ORDER BY 평균실행시간 DESC, 실행횟수 DESC;
SELECT TO_CHAR (SID) sid, serial# serialNumber, SUBSTR (TO_CHAR (last_call_et), 1, 6) executeSeconds, userName, machine, b.sql_text sqlText FROM v$session a, v$sqltext b WHERE username NOT IN ('SYSTEM', 'SYS') AND a.TYPE != 'BACKGROUND' AND a.status = 'ACTIVE' AND a.sql_address = b.address(+) AND a.sql_hash_value = b.hash_value(+) ORDER BY a.last_call_et DESC, a.SID, a.serial#, b.address, b.hash_value, b.piece
현재 실행되고 있는 쿼리 와 실행 시간
SELECT TO_CHAR (SID) sid, serial# serialNumber, SUBSTR (TO_CHAR (last_call_et), 1, 6) executeSeconds, userName, machine, b.sql_text sqlText FROM v$session a, v$sqltext b WHERE username NOT IN ('SYSTEM', 'SYS') AND a.TYPE != 'BACKGROUND' AND a.status = 'ACTIVE' AND a.sql_address = b.address(+) AND a.sql_hash_value = b.hash_value(+) ORDER BY a.last_call_et DESC, a.SID, a.serial#, b.address, b.hash_value, b.piece
1. 스마트폰은 기본적으로 일정 시간동안 아무런 반응이 없으면 자동으로 화면이 꺼지게 됩니다.
원할 경우 실행되는 동안 화면을 안꺼지 게 할수 있습니다. getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON); 을 추가하게 되면 실행되는 동안 화면이 꺼지지 않습니다.
2. Dialog 타이틀바 없애기.
3. EditText에 이벤트 주기
EditText 이벤트는 addTextChangedListener() 를 사용하면 보다 쉽게 다룰수가 있었다.(setOnClickListener() 보다 좋음.)
et.addTextChangedListener(new TextWatcher(){
public void afterTextChanged(Editable arg0) {
// TODO Auto-generated method stub
}
public void beforeTextChanged(CharSequence s, int start, int count,
int after) {
// TODO Auto-generated method stub
}
public void onTextChanged(CharSequence s, int start, int before,
int count) {
// TODO Auto-generated method stub
}
});
Service는 background에서 처리를 계속할 수 있는 클래스이다. Service는 기본적으로 activity를 가지지 않는다.
서비스를 구현하기 위한 3가지 절차 -- Service 클래스를 확장한 새로운 클래스 정의 -- Manifest file에 Service 선언 추가 -- App에서 Service 실행
1. 서비스를 실행하는 클래스 - 타이머를 이용한 반복 처리.
public class MyService extends Service implements Runnable {
// 시작 ID
private int mStartId;
// 서비스에 대한 스레드에 연결된 Handler. 타이머 이용한 반복 처리시 사용.
private Handler mHandler;
// 서비스 동작여부 flag
private boolean mRunning;
// 타이머 설정 (2초)
private static final int TIMER_PERIOD = 2 * 1000;
private static final int COUNT = 10;
private int mCounter;
// 서비스를 생성할 때 호출
public void onCreate() {
Log.e("MyService", "Service Created.");
super.onCreate();
mHandler = new Handler();
mRunning = false;
}
// 서비스 시작할 때 호출. background에서의 처리가 시작됨.
// startId : 서비스 시작요구 id. stopSelf에서 종료할 때 사용.
//onStart는 여러번 호출될 수 있기 때문에 식별자로 사용.
public void onStart(Intent intent, int startId) {
Log.e("MyService", "Service startId = " + startId);
super.onStart(intent, startId);
mStartId = startId;
mCounter = COUNT;
// 동작중이 아니면 run 메소드를 일정 시간 후에 시작
if (!mRunning) {
// this : 서비스 처리의 본체인 run 메소드. Runnable 인터페이스를 구현 필요.
// postDelayed : 일정시간마다 메소드 호출
mHandler.postDelayed(this, TIMER_PERIOD);
mRunning = true;
}
}
// 서비스의 종료시 호출
public void onDestroy() {
// onDestroy가 호출되어 서비스가 종료되어도
// postDelayed는 바로 정지되지 않고 다음 번 run 메소드를 호출.
mRunning = false;
super.onDestroy();
}
// 서비스 처리
public void run() {
if (!mRunning) {
// 서비스 종료 요청이 들어온 경우 그냥 종료
Log.e("MyService", "run after destory");
return;
} else if (--mCounter <= 0) {
// 지정한 횟수 실행하면 스스로 종료
Log.e("MyService", "stop Service id = "+mStartId);
stopSelf(mStartId);
} else {
// 다음 작업을 다시 요구
Log.e("MyService", "mCounter : " + mCounter);
mHandler.postDelayed(this, TIMER_PERIOD);
}
}
// 원격 메소드 호출을 위해 사용
// 메서드 호출을 제공하지 않으면 null을 반환
public IBinder onBind(Intent intent) {
return null;
}
}
2. 서비스 실행, 종료를 사용자가 요청하는 클래스
// 서비스 시작과 종료를 요구하는 Activity
public class MyServiceActivity extends Activity {
ComponentName mService; // 시작 서비스의 이름
TextView mTextView; // 서비스 상태 표시
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
mTextView = (TextView)findViewById(R.id.text_view);
Button start = (Button)findViewById(R.id.start_button);
start.setOnClickListener(new View.OnClickListener(){
public void onClick(View v) {
startHelloService();
}});
Button stop = (Button)findViewById(R.id.stop_button);
stop.setOnClickListener(new View.OnClickListener(){
public void onClick(View v) {
stopHelloService();
}});
}
// 서비스 시작 요청
private void startHelloService() {
mService = startService(new Intent(this, MyService.class));
mTextView.append(mService.toShortString()+" started.\n");
}
// 실행한 서비스 중지 요청
private void stopHelloService() {
if (mService == null) {
mTextView.append("No requested service.\n");
return;
}
Intent i = new Intent();
i.setComponent(mService);
if (stopService(i))
mTextView.append(mService.toShortString()+" is stopped.\n");
else
mTextView.append(mService.toShortString()+" is alrady stopped.\n");
}
}
3. 사용자가 서비스 실행, 종료하는 화면 구성
<!-- 시작 --> <Button android:id="@+id/start_button" android:text="Start" android:layout_width="fill_parent" android:layout_height="wrap_content"/>
<!-- 종료 --> <Button android:id="@+id/stop_button" android:text="Stop" android:layout_width="fill_parent" android:layout_height="wrap_content"/>
6. 컴포넌트의 생명주기 컴포넌트의 생명주기는 컴포넌트를 인스턴스화 할 때 시작해서, 인스턴스가 사라질 때 종료됩니다. 액티비티의 경우 그 사이에 활성화, 비활성화가 될 수 있기 때문에 사용자에게 보이거나 , 또는 보이지 않을 수도 있습니다.
1. 액티비티 생명주기
액티비티는 필수적으로 세 가지의 상태를 가지고 있습니다.
▣ 활성화(activity) 또는 실행 (running) 상태
액티비티가 포그라운드 화면으로 사용자에게 보이는 상태입니다 ( 즉, 현재 태스크에서 스택의 최상위에 위치하는 것). 이 상태는 사용자 액션을 받을 수 있게 됩니다.
▣ 멈춤(paused) 상태
사용자 액션을 받진 못하지만 여전히 보여지고 있는 상태입니다. 즉 다른 액티비티가 그 위에 위치하지만 해당 액티비티가 화면을 전부 채우지 않거나 투명해서 멈춤 상태의 액티비티를 볼 수 있는 상태입니다. 이 상태의 액티비티는 살아있습니다 ( 모든 상태정보와 멤버를 유지 중 ) 하지만 , 메모리 부족시엔 시스템에 의해 강제종료 될 수 있습니다.
▣ 정지 (stopped) 상태
완전히 다른 액티비티에 의해 가려진 상태입니다.더 이상 사용자에게 보이진 않지만 여전히 살아서(정보와 멤버유지) 있는 상태이죠. 여전히 보여지진 않기 때문에 메모리 부족시엔 강제종료 될 수 있습니다.
액티비티가 멈춤 또는 정지 상태라면, 시스템은 finish() 메소드를 호출하거나 프로세스를 강제종료 시킴으로서 메모리에서 제거할 수 있습니다. 종료된 액티비티가 다시 실행된다면, 다시 시작되어야 하고 이전 상태로 복구되어야 할 것입니다.
액티비티 상태변화
액티비티의 상태가 변하면 아래의 메소드가 호출됨으로써 변화가 통보되는데요. 이 메소들은 모두 프로텍티드(protected) 메소드입니다.
여기의 7가지 메소드들은 오버라이드 할 수 있습니다. 단,모든 액티비티는 최초 인스턴스 초기화를 위해 onCreate() 메소드는 무조건 구현해야 합니다.
또한, 액티비티 종료직전.... 마지막 기회가 될 수도 있는 시점에선 적절한 데이터 저장을 위해 onPause() 메소드도 구현해주면 좋겠네요.
액티비티 생명주기 메소드를 구현할 땐 항상 슈퍼클래스 버전을 호출하여야 합니다. protected void onPause() {
super.onPause() ;
}
네스티드 루프(nested loop)
액티비티 생명주기 메소드를 구현하여 볼 수 있는 것은 아래와 같습니다.
▣ 액티비티 인타이어 라이프타임 ( entire lifetime )
onCreate() 와 onDestroy() 메소드 사이에서 발생합니다. 액티비티는 onCreate() 메소드에서 모든 초기 설정을 하고 onDestroy()에서 모든 리소스를 해제하죠.
▣ 액티비티 비지블 라이프타임 ( visible lifetime )
onStart() 메소드에서 onStop() 메소드 사이에서 발생합니다. onStart() 메소드에서는 사용자 인터페이스의 변화 모니터를 위해 브로드캐스트 리시버를 등록할 수 있고 사용자가 보고있는 화면이 없을때엔 onStop() 메소드에서 제거할 수 있습니다. onStart() 와 onStop()은 액티비티가 사용자에게 보여지고 숨겨지는 상태이므로 여러번 호출 될 수 있습니다.
▣ 액티비티 포그라운드 라이프타임 ( foreground lifetime )
onResume() 메소드와 onPause() 메소드 사이에서 발생합니다. 이 기간동안 액티비티는 화면에서 다른 모든 액티비티보다 앞에 놓이며 사용자에게 보여집니다. onPause()는 기계가 꺼지거나 새로운 액티비티가 시작될 때 호출되고, onResume() 은 액티비티가 다시 복귀되거나 새로운 인텐트가 도착했을때 호출됩니다. 따라서 이 두개의 메소드 내용은 빠르고 가벼울 수록 좋겠네요.
생명주기 메소드가 하는 일
▣ onCreate()
액티비티가 최초 생성시에 호출됩니다. 초기화 설정을 하는 곳이지요. 보관된 상태의 액티비티가 있다면, 그 상태를 저장중인 Bundle 객체를 받습니다. onStart() 메소드가 이어집니다. 강제종료가 불가능 합니다.
▣ onRestart()
액티비티가 정지 후 다시 시작되기 바로 직전에 호출됩니다. onStart() 메소드가 이어집니다. 강제종료가 불가능 합니다.
▣ onStart()
액티비티가 사용자에게 보여지기 직전에 호출됩니다. 액티비티가 보여지게되면 onResume() 메소드가, 안보이게 되면 onStop() 메소드가 이어집니다. 강제종료가 불가능 합니다.
시스템이 다른 액티비티를 시작하려 할 때 호출됩니다. 일반적으로 데이터 저장을 하기에 좋은 곳입니다. 하지만 소스코드의 속도가 빨라야합니다. 왜냐하면이 메소드가 끝나기 전까진 다음 액티비티가 실행되지 않기 때문인데요, 액티비티가 되돌아오면 onResume(), 보이지않게되면 onStop() 이 이어집니다. 강제종료가 가능 합니다.
▣ onStop()
액티비티가 사용자에게 보이지 않을때 호출 됩니다. 액티비티가 제거되거나 다른 액티비티가 실행되어 해당 액티비티를 덮어버렸을 때, 호출되죠. 액티비티가 되돌아오면 onRestart(), 액티비티가 사라지면 onDestroy() 가 이어집니다. 강제종료가 가능 합니다.
▣ onDestroy()
액티비티 삭제 직전에 호출됩니다. 액티비티가 받는 마지막 호출 메소드가 되죠. 시스템이 메모리 확보를 위해 액티비티 인스턴스를 없애버려고 하거나 , finish() 메소드가 호출되면 호출되는 메소드입니다.
isFinishing() 메소드로 두 가지를 분기할 수 있습니다.
onStart() 메소드가 이어집니다. 강제종료가 불가능 합니다.
☞ 여기에서 onPause() 는 프로세스가 강제종료 되기 전에 호출되는 것입니다. 즉,프로세스가 강제종료 될 때 onPause() 는 무조건 호출되는 유일한 곳이 됩니다. (onStop(), onDestroy() 는 호출되지 않을 수 있어요), 따라서데이터 저장 등의 작업은 종료되기 직전에 호출되는 onPause() 에 구현해야 되겠네요.
액티비티 상태 저장하기
시스템이 액티비티를 강제종료 했을때, 사용자는 이전의 액티비티로 돌아가고 싶을 수 있습니다. 이럴 경우 액티비티가 강제종료 되기 전에 상태를 저장할 수 있는onSaveInstanceState()메소드를 구현하면 저장이 가능해 집니다.
즉, 액티비티가 파괴되기전에 호출되는 메소드 인데요. ( onPause() 호출 이전에 호출됩니다. ) 이 메소드는 이름/값 쌍으로 이루어진 번들 객체(Bundle) 를 인수로 가집니다. 액티비티가 다시 시작되면 번들은 onSaveInstanceState() 와 onStart() 이후에 호출되는onRestoreInstanceState()에게 전달됩니다.
☞ onSaveInstanceState() , onRestoreInstanceState() 메소드는 생명주기 메소드는 아닙니다. 따라서 항상 호출되지는 않으며 특정 상황 ( 액티비티 강제종료전에 onSaveInstance() 호출처럼 ) 에서만 호출됩니다. 단, 사용자 액션에 의해 종료될 때는 ( 사용자가 직접종료 ) 호출되지 않습니다. - 사용자가 되돌아가지 않을 생각으로 종료한 것으로 판단한 것이겠죠...
onSaveInstanceState() 는 액티비티의 일시적인 상태 저장을 위한 것이므로 , 데이터 등을 안전하게 저장하려면 onPause() 메소드에서 처리해야 합니다.
액티비티 생명주기 메소드의 순서
하나의 액티비티가 다른 액티비티를 시작할 때 하나는 멈추고 정지되며, 다른 하나는 시작되는 구조를 가집니다. 생명주기 메소드의 순서는 두 개의 액티비티가 동일 프로세스 안에 있을 때에 정의됩니다.
1. 현재 액티비티("A") 의 onPause() 가 호출됩니다. 2. 다음 시작되는 액티비티("B") 의 onCreate() -> onStart() -> onResume() 이 차례대로 호출됩니다 3. "B" 액티비티가 더 이상 사용되지 않으면 그것의 onStop() 이 호출됩니다.
링크 들어가셔서 PC 환경에 맞는 프로그램 다운 받으시고 '다음 다음' 을 쭉 클릭하시면 끝입니다.
쉬운 이해를 위해 아래 3가지 예제 업무를 통해 설명을 드릴게요 :)
업무 1. 텍스트 파일에서 다음 문구를 찾아서 모두 바꾸세요
(변경 전) > (변경 후)
(1) 다른나라 > 우리나라
(2) Windows > Windows Computer
방법 1. 바꾸기 기능을 활용합니다.
(1) Ctrl + R 를 눌러서 창 띄움 (2) 찾을 내용 / 바꿀 내용 입력 (3) 모두 바꾸기 버튼 클릭
방법 2. 줄편집을 활용한다. (단축키 ALT + C )
* + TIP. 줄편집은 영문/숫자/특수문자는 가능하지만, 한글은 깨지므로, 'XXXX'로 표시한 후, 모두 변경으로 원하는 한글로 변경하면 된다.
* + TIP. 개발자의 경우, 중복되는 표현을 작성하고, 특정 영역만 다른 코딩을 할 경우 엄청난 효율을 발휘한다.
업무 2. 특정 문구(단어)가 포함된 내용만 뽑아내기.
방법 1. 찾기 (CTRL + F) 를 수행한 후, '문자열을 표시하는 줄 나열(G)' 를 체크 한후, 찾기를 하면...해당 문구가 있는 줄만 별도로 표시해 보여준다. 이것을 클립보드로 저장한 후 새글에 저장하면 원하는 문구가 표현된 내용만 쉽게 찾을 수 있다.
업무 3. 정렬하기(중복 제거 가능)
방법 1. 파일 < 정렬 > 파일 정렬(또는 고급 정렬)
최초 고급 정렬로 기준을 잡으면, 이후에는 파일 정렬로 기존 설정값대로 정렬가능하다. 중복 지우기 기능도 있어서 중복 제거도 가능하므로, 엑셀보다 더 편리한 부분도 있다. 해당 메뉴의 위치는 실제 울트라버전에 따라 상이할 수는 있으나 기능이 모든 버전들이 갖추고 있다.
업무 3. 파일 비교하기
방법 1. 메뉴의 파일 > 파일비교 를 클릭하면 비교할 파일을 선택하고, 확인을 누르면... 순차적으로 동일한 내용은 흰색으로 표시하지만, 다른 내용은 붉은색으로 표시해준다.(빈칸, 띄어쓰기)가 달라도 다른 내용으로 표시한다. 내용이 너무 많은 경우 =, =/ 을 클릭하면 다른 것만 표시할 수도 있다.
유원상 유유제약 대표이사가 캐나다에서 개막한 ARVO컨퍼런스 현장에서 안구건조증 치료 신약 소개
유유제약이 항염증 기전의 새로운 안구건조증 신약후보물질을 첫 공개했다. 유유제약은 28일(현지시간) 캐나다 밴쿠버에서 개막한 국제 안과학회 ARVO(The Association for Research in Vision and Ophthalmology)에서 안구건조증 치료 펩타이드 신약(프로젝트명: YDE)의 연구 결과를 발표했다. YDE는 유유제약이 국내 임상 2상 승인을 받은 YY-101과는 별도로 개발중인 프로젝트다.
이번에 발표된 연구는 안구건조증 유발 마우스 모델을 이용해 YDE와 기존 치료제 성분인 사이클로스포린A, 디쿠아포솔, 히알루론산, 리피테그라스트와의 치료 효과를 비교하기 위해 진행됐다. 그 결과 YDE가 우수한 항염증(Anti-inflammation) 기전에 따라 각막 상피세포 치유 효과 뿐 아니라 눈물 분비량 개선을 확인했다.
ARVO가 공개한 발표자료에 따르면 안구건조는 각막 상피 병변 및 염증이 발생하는 질환으로 복잡한 다중 인자적 병리학적 특성을 가진다. 유유제약은 통제된 환경에서 스코폴라민(scopolamine)에 의해 유발된 안구건조 설치류 모델의 연골세포 유래 세포외기질(chondrocyte derived extracellular matrix)에서 YDE-010, YDE-011, YDE-043 세가지 합성 펩타이드의 효과를 확인하는 실험을 진행했다.
연구진은 6~9주령의 암컷 C57BL6 마우스의 꼬리에 스코폴라민 패치를 적용하고 10일동안 건성 안구를 유발하기 위해 습도가 25% 이하인 통제된 환경실에서 사육했다. 스코폴라민 패치의 경우 격일 단위로 교체 적용됐다.
스트레스가 유발된 후, 10마리로 구성된 각각의 그룹에게 10일동안 3가지 펩타이드 중 하나 또는 대조군(vehicle), 리피테그라스트(lifitegrast; Xiidra), 사이클로스포린 A(cyclosporine A; Restasis), 디쿠아포솔나트륨(diquafosol sodium; Diquas), 히알루론산 나트륨(sodium hyaloronate; Vismed) 등을 하루 4~5회 양쪽 안구에 5µl씩 적용했다.
이들은 스트레스 유발 10일째와 치료 후 3,5,7,10일 이후의 눈물의 양(volume)과 각막 염색 점수(corneal staining score)의 변화를 평가했다.
10일간의 건조 스트레스가 주어진 모든 동물에게서 안구의 건조 징후가 관찰됐다. 스트레스가 해제된 이후 모든 그룹이 시간이 지남에 따라 눈물 생산이 향상됐다.
YDE-010, YDE-001, YDE-043가 각각 국소 투여된 마우스는 각막 염색에서 대조군 대비 유의미한 개선이 확인됐다. 대조군과 비교해 TDE-011 펩타이드의 경우 치료 3일, 5일 후 CFS(Cornea Fluorescein staining; 각막염색검사)에서 각막의 상처가 각각 30%, 47% 감소하는 등 관련성 있는 개선이 관찰됐다.
효과를 비교하기 위해 적용된 싸이클로스포린 A와 디쿠아포솔 나트륨, 히알루론산 나트륨 및 리피테그라스트 적용군은 각막 염색 결과에서 유의미한 개선이 없었다. 유유제약 측은 이러한 전임상 결과를 토대로 안구건조 설치류 동물모델에서 YDE-010, YDE-011, YDE-043이 기존의 처방약제들과 비교해 더 뛰어난 각막 상태 개선를 보였다고 발표했다.
백태곤 유유제약 연구소장은 "ARVO 사무국에 이번 연구결과에 대한 초록을 제출했으며, 사무국으로부터 발표자로 선정돼 연구결과를 처음으로 선보이게 됐다"면서 "이번 연구결과를 바탕으로 국제저널 발표 및 글로벌 임상을 준비 할 예정"이라고 말했다.
[현재 개발중인 프로젝트] 유유제약은 3월 12일 자사가 개발 중인 안구건조증 치료 펩타이드 신약 후보물질 YY-101에 대한 임상 2상 진입을 식품의약품안전처로부터 승인을 받았다고 3월 13일 밝혔다.
이번 임상시험은 국내 안구건조증 환자 30명을 대상으로 YY-101 점안액의 내약성, 안전성 및 유효성을 평가하기 위해 진행됐다.
유유제약의 YY-101은 한국산업기술평가관리원이 주관하는 바이오의료기기산업 핵심기술개발사업의 유망바이오IP사업화촉진사업으로 선정돼 지원을 받고 있다. 안과질환 T2B(Technology to Business) 기반구축센터인 부산 백병원과 비임상시험을 진행했으며, 임상 1상은 정재용 분당서울대병원 임상약리학과 교수가 맡았다.
백태곤 유유제약 연구소장은 "YY-101의 주성분인 콜라겐 타입 펩타이드는 연골 세포 유래 세포 외기질에서 분리된 물질로서 안전성이 확인됐다"며 "이번 임상2상 승인을 통해 개발 속도에 박차를 가할 예정"이라고 말했다.
실제 스마트폰의 영향으로 안구건조증 발생빈도가 높아져서 시장도 좋지만, 현재 개발중인 프로젝트외에도 더욱더 개발에 노력하고 있는 건실한 바이오 업체로 고려됨
미국 식품의약국(FDA)이 코오롱티슈진에 인보사의 미국 3상 중단과 주요성분 변경 사유 등을 포함한 관련 자료 제출을 요구했다.
코오롱생명과학은 3일 "코오롱티슈진이 FDA로부터 인보사 임상 중단에 관한 공문을 접수했다”고 밝혔다. 코오롱티슈진은 지난 3월 30일 인보사의 형질전환세포 변경 사실을 FDA에 통보하고 미국 내 인보사 3상 임상시험 환자 모집을 잠정 보류한 바 있다.
FDA는 이번 공문에서 인보사의 미국 3상 중단을 통보했다.
FDA는 이어 임상 중단 해제를 위한 요구사항으로 △임상 시험용 의약품의 구성 성분에 대한 특성 분석△구성 성분 변화 발생 경위△향후 조치사항 등을 포함하는 보고서 제출을 명시했다.
FDA는 임상중단 해제 사유로 특정하지는 않은 △종양원성 여부 판단에 사용한 방법론△종양관련 임상데이터△임상참여 환자들에 대한 투여정보△장기추적 계획△미국 임상기관 및 환자 통지문 제출을 요구했다.
인보사의 형질전환세포가 연골유래세포에서 태아신장유래세포로 바뀌게 된 경위부터 태아신장유래세포를 사용한데 따른 종양원성 발생 우려, 환자 안전보장 계획 등까지 광범위한 자료제출을 요구한 것이다.
코오롱생명과학은 "미국 FDA가 요청한 자료를 제출하고 필요시 대면 미팅 등을 신청해 미국 FDA와 추가적으로 협의 할 예정"이라고 밝혔다. 다만 그 시기는 이달 내 인보사와 관련 추가자료 제출하라는 국내 식품의약품안전처의 요청을 이행한 이후가 될 것이라는 설명이다. 이에 따라 FDA와의 협의와 임상재개 여부 결정까지는 시간이 걸릴 전망이다.
한편 코오롱생명과학은 2016년 인보사 기술수출계약 취소와 함께 계약금 250억원 반환을 요구하며 국제상업회의소(International Chamber of Commerce) 중재 절차를 진행중인 일본 미츠비시타나베제약이 계약취소사유로 형질전환세포의 유래와 관련된 내용을 추가했다고 밝혔다.
2017년 기사를 확인해보면, 미쓰비시 타나베는 가장 큰 계약 해지 이유로 "코오롱생명과학은 계약 당시 인보사의 개발사이자 자회사인 티슈진이 미국 3상을 위한 임상시료 생산처의 변경을 고려하고 있다는 점을 설명하지 않았다"는 점을 들었다. 또 코오롱생명과학이 미국 식품의약처(FDA)로부터 임상 3상 시료에 대한 사용 승인을 받은 후 임상을 개시해야 한다는 내용의 설명문을 미쓰비시 측에 제대로 전달하지 않은 것도 문제가 됐다.
당시 표면적으로는 기술과 무관한 임상절차나 생산처 변경에 대한 이슈였으나, 최근 그 당시 해지사유로 기술적인 부분역시 있는 것으로 확인되었다.
'인보사' 파문을 일으킨 코오롱생명과학[102940]의 미국 자회사 코오롱티슈진[950160]이 이미 2년 전에 의약품 성분이 뒤바뀐 사실을 알았다는 정황이 나왔다.
최근에야 인보사 성분이 바뀐 사실을 알았다는 코오롱생명과학의 주장과는 전면 배치되는 내용이다. 이런 상황에서도 코오롱생명과학은 "몰랐다"는 입장을 고수하고 있다.
코오롱티슈진은 지난 3일 저녁 공시에서 "(인보사의) 위탁생산 업체(론자)가 자체 내부 기준으로 2017년 3월 1액과 2액에 대해 생산 가능 여부를 점검하는 과정에서 STR(유전학적 계통검사) 위탁 검사를 해 2액이 사람 단일세포주(293유래세포)이며 생산에 문제가 없음을 확인하고 생산한 사실이 있다는 사실을 코오롱생명과학에 통지했다"고 했다.
인보사는 사람 연골세포(HC)가 담긴 1액과 연골세포 성장인자(TGF-β1)를 도입한 형질전환세포(TC)가 담긴 2액으로 구성된 골관절염 유전자치료제 주사액이다. 최근 2액의 형질전환세포가 허가 당시 제출한 자료에 기재된 연골세포가 아닌 293유래세포로 드러났다.
공시에 따르면 코오롱티슈진은 인보사의 2액이 293유래세포라는 사실을 이미 2017년 3월에 알고 있었다는 얘기가 된다. 당시 STR 검사는 인보사의 임상 시약을 위탁 생산하던 론자가 진행했다. 특히 이 시기는 인보사가 국내에서 식품의약품안전처의 허가를 받은 2017년 7월보다 약 4개월 앞선 때다.
즉, 코오롱티슈진이 인보사의 성분이 2004년 특성 검사에서 밝혀진 연골세포가 아닌 293유래세포인 걸 알고 있으면서도 허가 당국인 식약처에 알리지 않은 셈이 된다.
코오롱생명과학은 코오롱티슈진이 이런 사실을 알고 있었다는 것조차 "몰랐다"는 입장을 유지하고 있다.
관련 업계에서는 코오롱생명과학의 주장이 사실이라면 자회사와의 내부 커뮤니케이션에 심각한 문제가 있는 셈이고, 알고 있었는데도 은폐했다면 '대국민 사기극'에 준하는 일이라고 지적하고 있다.
코오롱티슈진과 코오롱생명과학이 론자의 STR 검사 결과를 이제야 알린 것도 자의가 아니라는 점에서 석연치 않다.
이 사실을 공개한 건 지난해부터 진행 중인 일본 제약사 '미쓰비시다나베'와의 소송 때문이었다. 코오롱생명과학은 2016년 미쓰비시다나베와 총 5000억원 규모의 인보사 기술 수출 계약을 맺었다가 2017년 12월 파기됐다.
미쓰비디사다베는 계약 의무 불이행을 이유로 들었고, 지난해 4월 코오롱생명과학을 상대로 계약금 250억원을 돌려달라는 소송을 냈다.
미쓰비시다나베가 론자의 STR 검사에서 2액이 293유래세포였다는 사실이 드러났다는 내용을 계약 취소 사유에 추가하면서 외부에도 알려진 것이다.
이런 상황에서도 코오롱생명과학은 합리적인 해명을 내놓지 못하고 있다.
코오롱생명과학 관계자는 "2017년 론자가 STR 검사를 코오롱티슈진에 전달한 건 맞지만 당시 담당자들이 '생산이 가능하다'는 내용에만 집중해 내부 보고를 처리한 것으로 알고 있다"며 "코오롱생명과학에서는 해당 사실을 이제야 파악하게 돼 구체적인 경위를 파악 중"이라고 말했다.
코오롱생명과학은 실제 위의 기사를 부정하고 있다. 코오롱생명과학은 2019년 2월말 미국 BioReliance 社의 STR 분석 중 일부 데이터에서 293 유래세포의 가능성을 유선으로 전달 받았다고 했다. 그리고 당시 시점은 시험 과정 및 데이터에 대한 검증 절차가 완료되지 않은 단계였기 때문에, 해당 데이터가 신뢰성 있는 정보인지에 대한 고려가 필요했다고 한다.
임상결과가 의도한바 대로 나왔고, 부작용이 없었다면 성분이 다른 것이 큰 문제가 될까? 실제 비아그라 역시 탈모 방지를 위해 치료약을 개발하는 과정에서 나온 희대의 역작이었다.
결국 5월~6월중에 한국식약청에서 요구한 자료를 제출하고, 미국 FDA의 요구에 대응하면서 진실은 드러날 것이다.
