개발자 시니

TLS가 안 맞아서 통신이 안 됐다 – 결국 JDK 올렸습니다

리신 — Fri, 25 Apr 2025 00:00:48 +0900

☁️ 새로 연동하는 협력사와 통신이 안 됐다

우리 회사는 커머스 플랫폼이라
협력사와의 API 연동 작업이 일상이다.

이건 내가 직접 처리한 건 아니고
우리팀에서 실제로 겪었던 실무 이슈다.

그날도 새로 들어온 협력사와
이미지 API 연동 작업을 진행하고 있었는데…

“이미지 API 요청 자체가 실패합니다.”

다른 협력사들은 아무 문제 없이 잘 되는데
유독 이 새 협력사만 통신이 안 됐다.

우리는 당연히 로그부터 확인했고
파고 또 파고… 그러다 딱 하나가 의심됐다.

“이거 TLS 버전 문제 아니야?”

우리는 JDK 1.7 , TLS는 1.0/1.1만 지원

우리 시스템은 아주 건강한(?) 레거시다.
현재까지도 Java 1.7을 쓰고 있었고
그 말은 곧 지원 가능한 TLS 버전은 1.0 또는 1.1이라는 뜻.

그런데 해당 협력사는
AWS 이미지 서버를 사용 중이었다.

협력사에서 온 답변은 단 하나였다

“저희는 AWS를 사용하고 있어서
하위 TLS 버전은 지원이 어렵습니다.”

끝.
딱히 기술적 이유나 대안은 없었다.

그래서 AWS 엔지니어 친구한테 물어봤다

내가 너무 답답해서
친한 AWS 엔지니어 친구에게 직접 물어봤다.

“야, 진짜 AWS는 TLS 1.1도 안 되냐?”

그 친구의 말:

“맞아. AWS는 TLS 1.0 / 1.1은 EOS(지원 종료) 때렸어.
지금은 TLS 1.2 이상만 기본적으로 허용돼.”

그런데 여기서 중요한 말이 하나 더 나왔다:

“근데 그거 완전 차단은 아냐.
일부 서비스는 설정에 따라 1.0 / 1.1도 쓸 수는 있어.”

“그러니까 반은 진짜고, 반은 귀찮아서 안 해주는 걸 수도 있어.
TLS 낮췄다가 보안 사고 나면 누가 책임질 거야?
나라도 그냥 안 내려줬을 듯.”

즉,
기술적으로 가능하더라도
정책상, 혹은 책임 회피성으로
“지원 못 합니다”라고 단답하는 경우도 있다는 것.

결국, 우리 팀이 바꿨다

협력사 쪽에선 TLS 버전 하향이 어렵다는 입장이었고
우리 시스템은 Java 1.7이었기 때문에 TLS 1.2를 지원하지 않았다.

그래서 결국 우리 팀에서 JDK를 1.8로 업그레이드하기로 결정했다.

물론 단순히 버전만 바꾸는 게 아니다.

테스트 환경까지 싹 점검
라이브러리 버전 호환 확인
운영 반영 및 배포 프로세스 조정

쉽지 않았지만, 해야만 했다.

보안도 중요하고, 협력사와 통신되는 게 더 중요했으니까.

✅ 정리하며

이번 일을 겪은 우리 팀은
“통신이 안 될 땐 TLS부터 의심하자”는 교훈을 확실히 얻었다.

특히 레거시 환경을 운영 중이라면
TLS 버전과 JDK 버전을 항상 인지하고 있어야 한다.

실무 핵심 요약

Java 1.7 → TLS 1.2 지원 불가
AWS → TLS 1.2 이상만 기본 허용
협력사 → “내려줄 수 없음” (응. 안 해줌)
해결책 → JDK 1.8 업그레이드로 TLS 1.2 대응

그리고 이건 단순한 기술 이슈가 아니었다.
우리 시스템 구조에 대한 인식을 바꾼 계기이기도 했다.

캐시는 빠르다! 근데 터지면 진짜 다 같이 죽는다!

리신 — Thu, 24 Apr 2025 00:00:59 +0900

☠️ 캐시 서버가 터졌다

그날 진짜... 아무 생각 없이 평소처럼 일하고 있었는데
갑자기 “사이트 접속이 안 된다”는 연락이 여기저기서 쏟아졌다.

싸늘하다.
팀장급들과 윗분들 다 모여서 한 화면만 보고 있다.

그 화면 = 접속 불가된 우리 서비스.

커머스 회사에서…
사이트 접속이 안 됐다.

그게 가능하냐고?

가능했다.

원인?

캐시 서버 터짐.
진짜로. 그 한 놈 때문에 전체가 무너졌다.

터진 이유는? 솔직히 아직도 잘 모른다

지금 생각해보면…

원인은 이 중 하나거나 전부였을지도 모른다..

메모리 초과 (OOM)
→ 캐시 TTL 안 걸려 있던 거 다 모여서 메모리 꽉 찼을 가능성 있음

동시에 대량 캐시 MISS
→ 한 타이밍에 요청 몰려서 캐시 못 받고 DB로 몰렸을 수도 있음

❌ 캐시 삭제 실수?
→ 배치든, 코드든, 누가 잘못해서 TTL 싹 날렸을 수도 있음

그냥 캐시 구조가 엉망이라?
→ 캐시 키 관리도 없고, 갱신 로직도 없고…
그냥 다들 막 썼다. 진짜로.

사실 로그도 제대로 안 남았고, 추적도 힘들었다.
근데 분위기로는 다들 알았다.

“이건… 캐시를 너무 아무렇게나 썼던 거다.”

오만 개발자들이
가이드도 없이, 기준도 없이, 상황도 모르고
그냥 "느리다" → "캐시 써요~" 해서 붙였고..

결국 그렇게 누적된 것들이
한날한시에… 팡.

그런데 왜 그렇게 썼냐고?

우리 회사는 커머스 회사다.
고객이 원하는 건 지금, 바로, 눈앞에서 처리되는 서비스.

근데 현실은?

현업은 이렇게 온다:

“기능 만들어줘잉~ 화면 만들어줘잉~”
그리고 1분 뒤엔 결재 올라가 있다.
오픈일자까지 다 정해져 있음.
개발자한테 말도 안 하고.

그럼 개발은 어떻게 되냐?

그냥 막 한다.

시니어, 주니어 가릴 것 없이
일단 만들고 → 바로 붙이고 → 테스트는 내일
그리고 오늘 오픈

그러다 어느 날
현업이 이렇게 말한다:

“상품 사진 느려요! 빨리 뜨게 해주세요!”
"상품이 안 뜨잖아요!!"

그리고 개발자는 고민한다:

“그럼… 캐시 써야겠네요…”

그리고 그냥 막… 막… 쓴다.

그 결과는?

터진다.

‍ 그 이후 우리 팀장은 이렇게 말했다

“캐시 쓸 거면 나한테 먼저 말하고 써.
그냥 붙이지 마.
또 그날처럼 되는 수 있어.”

✅ 캐시는 빠르다, 하지만 위험하다

캐시 장점	캐시 단점
빠르다 (메모리 기반)	휘발성, 데이터 유실 가능
DB 부하 줄임	캐시 MISS 몰리면 오리혀 DB 터짐
실시간 UX 개선	TLT/갱신 잘못 잡으면 장애 발생
응답속도 향상	모니터링 없으면 터질 때까지 모름

마무리

캐시는 칼이다.
잘 쓰면 빠르고 멋지다.

근데 잘못 쓰면…
진짜 다 같이 죽는다.

그리고 그날 이후

모두가 마음속으로 인정했다.

“캐시를 너무 난발해서 쓴 게 문제였다.”

터진 서버는…
알고 보니 엄청 오래된 캐시 서버였다.

물리 장비는 낡았고
증설도 안 됐고
모니터링도 없었다

결국 우리는 중요한 캐시들은
하나씩 Redis로 옮기는 작업을 시작했다.

그리고 그 이후로
우리의 캐시에 대한 태도는 완전히 달라졌다.

“빠르니까 쓴다”
→
“책임질 수 있을 때만 쓴다”

[Oracle] 오라클 시퀀스 초기화 3가지 방법

리신 — Wed, 23 Apr 2025 00:00:42 +0900

실무에서 시퀀스 초기화가 필요했던 순간

개발하다 보면 종종
테스트 데이터를 모두 삭제하고
시퀀스도 다시 1부터 시작하고 싶을 때가 있다.

나도 INSERT 테스트 몇 번 하고 DELETE로 비웠는데
시퀀스는 계속 101, 102... 이렇게 올라가 있어서

“이거 다시 1부터 못 돌리나?”
싶어서 한참 찾아봤던 기억이 있다.

그래서 정리했다.

Oracle에서 시퀀스를 초기화하는 3가지 방법
가장 많이 쓰는 기준으로!

❗ 그리고 참고로
운영에서 시퀀스 초기화하면… 크으으으은일 납니다

운영 시퀀스 건드릴 수도 없겠지만 혹시나 하는 마음에 ㅎ
(진짜 PK 충돌나서 난리부르스 서비스 에러에러에러 voc voc voc... ++;)

이건 어디까지나 개발 서버 기준에서만 사용하세요!

1. 기존 시퀀스 삭제 후 새로 생성 (가장 깔끔함)

가장 확실한 방법은 DROP 후 CREATE 하는 것.

DROP SEQUENCE MY_SEQ;

CREATE SEQUENCE MY_SEQ
START WITH 1
INCREMENT BY 1
NOCACHE;

START WITH로 초기값 설정 가능
기존 시퀀스와 동일한 옵션으로 재생성하는 게 핵심

✅ 단점: 기존 시퀀스를 참조하던 트리거나 외부 객체가 있을 경우
의존성 문제로 에러 날 수 있음

❗ 더더더 주의!!

이건 내가 개발하려고 새로 만든 시퀀스다!
= 내가 소유권 100%일 때만 쓰세요.

아래와 같은 시퀀스는 절대 함부로 삭제 금지:

남들도 같이 쓰는 공용 시퀀스
운영 중 실시간으로 참조 중인 시퀀스

그런 거 건드리면… 호호호호혼. 남.

2. ALTER로 NEXTVAL 조정 (간단하지만 제한적)

-- 현재 시퀀스 값보다 낮게 설정하고 싶으면
-- INCREMENT 값을 일시적으로 조정한 후 한번 호출
ALTER SEQUENCE MY_SEQ INCREMENT BY -99;
SELECT MY_SEQ.NEXTVAL FROM DUAL; -- (예: 현재 100 → 1로 맞추기)
ALTER SEQUENCE MY_SEQ INCREMENT BY 1;

현재 값 기준으로 상대 조정
정확히 몇까지 올라갔는지 알고 있어야 가능함

3. RESTART 옵션 사용 (Oracle 12c 이상)

ALTER SEQUENCE MY_SEQ RESTART START WITH 1;

오라클 12c 이상부터 가능
가장 간단하게 “다시 1부터 시작”

❗ 단점: 구버전에서는 동작하지 않음

실제로 나는 이렇게 했음

처음엔 몰랐어서...
그냥 SELECT MY_SEQ.NEXTVAL FROM DUAL;
계속 호출하면서 시퀀스를 올렸었다

나란놈은 개발자 맞냐..? ‍

"뭔가 아닌데…" 싶었지만
그때는 다른 방법을 몰랐어서 계속 눌렀음. 진짜로.

결국 검색 끝에
DROP 후 CREATE로 초기화하는 방식을 알게 됐고
그 방법으로 깔끔하게 리셋했다.

물론 나는 테스트 환경이라 괜찮았지만
실제 운영 환경이었다면 트리거나 의존성 문제로 사고 남

운영 환경이라면?

그냥 하지 말고 무조건 DBA한테 먼저 의논하세요!!!

⚠️ 신규 개발로 만든 시퀀스가 아닌데도 손댄다?
→ 개발에서도 조심해야 함
→ 잘못 건드리면 진짜 욕.먹.음.

그래서 꼭 말하고 싶다:

DROP 방식은 정말 내가 신규로 개발하기 위해 만든 시퀀스일 때만.
그리고 의존성 확인은 무조건 먼저 해야 함!

SVN 커밋이 안 될 때 점검할 3가지

리신 — Tue, 22 Apr 2025 00:00:43 +0900

SVN 커밋이 안 될 때 실제로 겪은 상황

SVN으로 소스 관리를 하다 보면
어느 날 갑자기 커밋이 안 되는 프로젝트가 생기곤 한다... 개빡침..

나도 똑같은 이클립스 환경 같은 SVN 리포지토리에서
A 프로젝트는 정상 커밋이 되는데, B 프로젝트는 아무 반응 없이 실패하는 상황을 겪었다.

"설정이 다른 것도 아닌데, 왜 이 프로젝트만 안 되지?"

결국 확인해보니, 원인은 파일 잠금(Lock) 상태와 숨겨진 설정 차이에 있었다.

1. 파일이 lock 상태인지 확인해보기

SVN은 파일을 lock(잠금) 상태로 지정할 수 있음
누군가가 해당 파일을 Lock 해두었거나, 내가 Lock 후 Release 안 했을 경우
→ 커밋 시도해도 아무 반응 없이 멈춤

✅ 해결 방법:

TortoiseSVN 기준: 해당 파일 우클릭 → "Release lock" 또는 "Get Lock"으로 상태 확인/변경
이클립스 기준: Team → Show Properties로 lock 정보 확인 가능

2. SVN 상태 갱신 (Clean up)

때때로 작업 중 SVN 메타정보가 꼬여서 커밋이 실패하는 경우도 많음
이럴 땐 Clean up 기능으로 상태를 정리해줘야 함

✅ 해결 방법:

TortoiseSVN → 프로젝트 폴더 우클릭 → "SVN Clean up"
"Break locks", "Include externals" 등 체크박스 전부 체크 후 실행

3. .svn/wc.db 내부 잠금 수동 삭제 (SQLite 활용)

모든 방법을 다 써도 안 되는 경우엔
SVN 내부의 .svn/wc.db 파일을 직접 열어
잠금 정보를 SQLite로 삭제하는 방법이 있음

이 파일은 SVN 워킹 카피의 내부 상태를 저장하는 SQLite DB인데
잠금 정보가 LOCK 테이블에 남아 있으면 커밋이 막힐 수 있음

✅ 해결 방법:

1. .svn/wc.db 파일을 SQLite DB Browser 또는 SQLite CLI로 연다.

2. 현재 잠금 상태 확인

SELECT * FROM LOCK;

3. 모든 잠금 삭제

DELETE FROM LOCK;

4. 저장 후 종료 → 다시 커밋 시도

Clean up이 안 통하던 상황에서 이 방법으로 커밋 문제를 해결한 적이 있음

✅ 마무리 요약

SVN 커밋이 안 될 땐 당황하지 말고
1️⃣ 파일 잠금 상태
2️⃣ Clean up 여부
3️⃣ .svn 내부 상태

이 3가지를 순서대로 점검해보면 대부분 해결된다.

특히 .svn/wc.db에 남아 있는 LOCK 정보는
커밋이 조용히 먹통 되는 원인 중 가장 찝찝한 놈이다.

[트러블슈팅] DB 세션이란? 롱 아이들 세션이 쌓이면 생기는 진짜 문제

리신 — Mon, 21 Apr 2025 00:00:29 +0900

원래는 인터페이스로 통신해 해당 기능을 실행하던 구조였는데
직접 시스템 자체에서 해당 기능을 처리하라는 요청이 들어왔다.

급하게 대응하기 위해 DB LINK를 신청해서 다른 DB에 INSERT하는 방식으로 로직을 변경했고
단순한 작업이라 금방 끝냈다고 생각했다.

그런데 바로 다음날 DBA팀에서 연락이 왔다.

“해당 DB에 세션이 갑자기 급증했는데, 혹시 무슨 작업하셨어요?”

확인해보니, DB LINK를 통해 연결된 세션이 자동으로 닫히지 않아
INACTIVE 상태로 계속 남아 있었던 것...

이 일을 계기로, DB 세션과 롱 아이들 세션 이슈의 심각성을 처음 알게 되었고
정리 차원에서 이 글을 작성하게 되었다.

DB 세션이란?

DB 세션은 클라이언트(자바 애플리케이션 등)가
DB에 접속할 때 생성되는 하나의 연결 통로임

해당 세션을 통해 SQL 쿼리를 날리고 결과를 받아오며
작업이 끝나면 close() 등을 통해 명시적으로 종료해줘야 함

롱 아이들 세션(Long Idle Session)이란?

세션이 열려 있지만 아무 작업도 하지 않고 오랫동안 남아있는 상태를 말함.

보통 INACTIVE, IDLE 상태라고 표현되며
이 세션들도 여전히 DB 자원을 점유하고 있기 때문에 문제가 됨

DB LINK를 썼을 때 왜 이런 문제가 생겼을까?

DB LINK는 하나의 DB에서 다른 DB로 직접 접근할 수 있는 기능임

INSERT 쿼리 한 줄만 날리면 끝나는 것 같지만
실제로는 다음과 같은 이유로 세션이 정리되지 않고 쌓일 수 있음

쿼리 실행 후 커밋/롤백을 명시적으로 하지 않음
자바 코드에서 DB LINK로 연결된 커넥션을 직접 종료할 수 없음
외부 DB에서 rollback을 기다리는 상태일 수 있음
기능이 반복적으로 호출되면서 세션이 계속 누적됨

어떻게 해결할 수 있을까?

방법	설명
트랜잭션 명확히 처리	COMMIT 또는 ROLLBACK을 명시적으로 해줄 것
DB LINK 사용 최소화	읽기 전용 쿼리는 괜찮지만 쓰기(INSERT/UPDATE)는 피할 것
JNDI 방식으로 전환	자바 애플리케이션에서 직접 DB커넥션을 관리할 수 있어 세션 회수가 쉬움
커넥션 풀 설정 튜닝	removeAbandoned=true, removeAbandonedTimeout 설정 등을 통해 미사용 커넥션 회수 가능

✅ 내가 실제로 해결한 방법

필자는 DB LINK 방식에서 발생한 세션 누적 문제를 해결하기 위해
DB 연결 방식을 JNDI로 전환했다.

이렇게 하면 애플리케이션 레벨에서 커넥션을 직접 제어할 수 있고
세션이 자동으로 관리되어 누수가 발생하지 않는다.

다만, 직접 해당 DB에 INSERT를 수행해야 했고
해당 DB는 사양이 낮은 편이어서 TPS(Transactions Per Second)를 너무 높이지 않도록 주의가 필요했다.

그래서 JNDI 설정 시
커넥션 풀의 maxActive 값도 의도적으로 낮게 조정해
DB에 무리가 가지 않도록 설정했다.

JNDI 설명 참고

https://dev-cini.tistory.com/90

결론

세션은 눈에 보이지 않지만
쌓이면 시스템에 큰 문제를 유발할 수 있는 중요한 자원임

DB LINK는 설정이 간단하다는 장점이 있지만
트랜잭션 관리와 세션 종료가 불확실해 세션 누적 문제가 자주 발생함

가능하다면
JNDI 기반 커넥션 풀 방식으로 DB를 연결하고
트랜잭션을 명확하게 종료하는 습관을 들이는 것이 좋음

[JAVA] JNDI란 무엇인가? 그리고 언제 사용하는가?

리신 — Sun, 20 Apr 2025 00:00:07 +0900

Java 애플리케이션이 어떻게 DB와 연결되는지를 JNDI를 통해 흐름 순서대로 정리한 구조도

JNDI란?

JNDI(Java Naming and Directory Interface) 는
Java 기반 웹 애플리케이션에서 DB 연결 정보(DataSource) 를 외부 설정으로 분리하고
필요할 때 코드에서 lookup 방식으로 꺼내 쓰는 기술임

쉽게 말하면
“DB 접속 정보를 미리 서버(Tomcat 등)에 등록해두고 앱에서는 그냥 이름만 불러서 사용하는 방식”임

전체 흐름 한눈에 보기 (위 다이어그램 설명)

TOMCAT 설정 → JNDI에 DataSource 등록됨
        ↓
Java Application이 JNDI에서 lookup()
        ↓
DataSource에서 Connection 꺼냄
        ↓
DB에 쿼리 날림

✅ 흐름 설명 (실제 동작 순서)

Tomcat에서 server.xml이나 context.xml에 JNDI DataSource 설정을 해둠
WAS가 실행되면 설정된 JNDI 리소스가 등록됨 (예: jdbc/myDB)
Java 코드에서 lookup("java:comp/env/jdbc/myDB") 호출 → 등록된 JNDI 리소스를 가져옴
가져온 DataSource 객체에서 getConnection() 호출 → DB에 커넥션 연결
연결된 커넥션을 통해 DB 작업 수행

왜 필요한가?

보안: DB ID/PW를 코드에 직접 적지 않음
환경 분리: 개발/운영서버 환경마다 설정 다르게 가져갈 수 있음
커넥션 풀 관리: DB 커넥션을 효율적으로 재사용 → 성능 향상
트랜잭션 제어: DB 세션을 명확히 제어 가능 → 불필요한 세션 낭비 방지

구성 예시

✅ server.xml (Tomcat)

<Resource
 name="jdbc/myDB"
 auth="Container"
 type="javax.sql.DataSource"
 factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
 driverClassName="oracle.jdbc.OracleDriver"
 url="jdbc:oracle:thin:@192.168.111.14:1555/EZBILL"
 username="myuser"
 password="mypassword"
 maxActive="10"
 maxIdle="5"
 maxWait="5000"
 removeAbandoned="true"
 removeAbandonedTimeout="60"
 logAbandoned="true"
 validationQuery="select 1 from dual"/>

✅ context.xml

<Context>
  <ResourceLink name="jdbc/myDB" global="jdbc/myDB" type="javax.sql.DataSource"/>
</Context>

✅ Java 코드에서 사용

Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/myDB");
Connection conn = ds.getConnection();

커넥션 풀 설정 요소

설정명	설명
maxActive	동시에 사용할 수 있는 최대 연결 수
maxIdle	대기 상태로 유지되는 최대 연결 수
removeAbandoned	일정 시간 동안 사용되지 않으면 커넥션 회수 여부
validationQuery	커넥션이 유효한지 검사할 쿼리

커넥션 풀을 잘 설정하면
불필요한 세션 낭비 없이 성능도 높이고 세션 폭주도 막을 수 있음

언제 사용해야 할까?

JNDI는 “Java 애플리케이션이 DB에 연결할 때” 사용함
단순히 데이터를 넣고 뽑는 게 아니라 WAS 환경에서 안정적으로 커넥션을 관리하려는 목적이 큼

✅ 사용해야 하는 상황

Java 애플리케이션에서 DB에 연결해야 할 때
- JDBC를 직접 쓰기보다 톰캣/WAS에 미리 등록해두고 꺼내 쓰는 구조가 필요할 때
운영환경과 개발환경 설정을 분리하고 싶을 때
- 코드에 DB URL/ID/PW를 직접 넣는 게 아니라 환경 설정 파일에서만 관리하고 싶을 때
DB 커넥션 풀을 도입하고 싶을 때
- 세션을 효율적으로 재사용하고 TPS(초당 트랜잭션 수) 가 많은 시스템에서 성능을 높이고 싶을 때
세션 누수 DB 접속 제한 같은 문제를 방지하고 싶을 때
- DB_LINK처럼 세션이 계속 유지되는 방식 대신 명확하게 열고 닫히는 구조가 필요한 경우

❌ 꼭 JNDI를 안 써도 되는 경우

아주 작은 테스트용 프로젝트
- DB 접속도 1~2회 트랜잭션도 적음
로컬에서만 쓰는 간단한 툴성 애플리케이션
- 환경 분리나 커넥션 관리가 중요하지 않음

한 줄 요약

JNDI는 Java와 DB를 안정적으로 연결하고,
DB 커넥션을 효율적으로 관리할 수 있게 해주는 설정 방식이다.

[Oracle] 오라클 디비링크(DB LINK)란?

리신 — Sat, 19 Apr 2025 18:02:32 +0900

오라클에서 외부 DB와 연결할 때 사용하는 DB LINK는
간편하지만 세션 부하 등 주의가 필요한 기능이다.

DB LINK란?

DB_LINK(Database Link)는 오라클 DB에서 다른 원격 DB의 객체(테이블, 뷰 등)를
로컬 DB에서 직접 접근할 수 있도록 만들어주는 기능이다.

운영 중 서로 다른 DB 인스턴스를 연결해야 할 상황이 생깁니다.
예를 들어 A 시스템에서 B 시스템의 테이블에 접근하거나 데이터를 쓰고 싶을 때

가장 간편한 방법 중 하나가 바로 DB LINK입니다.

사용 예시

✅ SELECT 예시

SELECT * FROM customer@ERP_LINK;

✅ INSERT 예시

INSERT INTO log_table@LOG_DB_LINK (id, message) VALUES (1, '처리 완료');

✅ DB_LINK 생성 예시

CREATE DATABASE LINK LOG_DB_LINK
CONNECT TO log_user IDENTIFIED BY log_password
USING 'LOG_TNS_ENTRY';

DB LINK의 장점

항목	설명
간편한 연동	외부 DB에 복잡한 설정 없이 SQL만으로 접근 가능
트랜잭션 공유 가능	로컬 트랜잭션과 외부 트랜잭션을 하나로 묶을 수 있음
데이터 조회,사입 가능	SELECT뿐 아니라 INSERT/UPDATE등도 가능

DB LINK의 단점

항목	설명
트랜잭션 처리 복잡	외부 DB까지 트랜잭션이 퍼지면서 오류 시 Rollback 문제가 생길 수 있음
성능 이슈	외부 DB 응답 속도에 따라 전체 SQL이 느려질 수 있음
세션 누수	사용 후 세션이 INACTIVE 상태로 남는 롱 아이들 세션이 발생할 수 있음
장애 시 리스크	외부 DB 연결 문제로 우리 시스템까지 영향을 받을 수 있음

DB LINK는 언제 왜 써야 할까?

위에서 보면 단점이 너무 큰 것 같은데 도데체 왜 쓰는걸까?

→ DB LINK는 아래와 같은 상황에서 간단하고 강력한 선택지가 된다

빠르게 다른 DB와 연동해야 할 때
- 예: 내부 시스템이 2개 DB로 나뉘어 있는데 데이터를 조인하거나 비교해야 할 경우
- JNDI 설정까지 시간이 없거나 단기간 데이터 조회만 필요할 때

운영 중인 타 시스템 DB에 직접 접근해야 할 때
- 다른 팀에서 운영하는 DB를 우리 쿼리에서 직접 조회해야 하는 경우
- REST API 또는 별도 연계 없이 빠르게 활용 가능

트랜잭션 공유가 필요한 경우
- 우리 DB와 외부 DB 모두 한 트랜잭션 내에서 처리되어야 할 때
- 예: insert(우리DB) → insert@link(외부DB) → commit 같이 일괄 처리

언제 쓰면 안 되는가?

반대로 아래 상황이라면 JNDI, API, 메시징 방식이 더 적합함

TPS(초당 처리량)가 높은 시스템이라면
- DB LINK는 세션 관리가 어려워지고 병목이 발생할 가능성이 높음

외부 DB의 장애가 곧 우리 시스템에도 영향을 줄 수 있는 구조라면
- DB LINK는 그 장애를 그대로 전파시킬 수 있기 때문에 위험

장기적으로 유지보수나 이중화를 고려해야 하는 시스템이라면
- DB LINK는 연결 구조가 불투명하고 관리 포인트가 늘어나기 때문에 신중히 검토

결론

DB_LINK는 편리함과 유연함을 제공하지만 그만큼 리스크도 존재함

따라서 아래처럼 “간단한 연동”, “일시적인 조회”, “트랜잭션 동기 처리가 꼭 필요한 경우”에만 사용하는 것이 이상적임

✔️ 작고 단순한 연동에는 효율적
❌ 복잡하거나 고부하 시스템엔 신중히 검토할 것

[ JAVA ] 네트워킹 (Networking)

리신 — Tue, 25 Apr 2023 23:55:52 +0900

네트워킹

네트워킹이란 두 대 이상의 컴퓨터를 케이블로 연결하여 네트워크를 구성하는 것을 말한다.

네트워킹의 개념은 컴퓨터들을 서로 연결하여 데이터를 손쉽게 주고받거나 또는 자원프린터와 같은 주변기기를 함께 공유하고자 하는 노력에서 시작되었다.

자바에서 제공하는 java.net패키지를 사용해 네트워크 어플리케이션의 데이터 통신 부분을 쉽게 작성할 수 있으며,

간단한 네트워크 어플리케이션은 단 몇 줄의 자바코드 만으로도 작성이 가능하다.

클라이언트/서버

클라이언트/서버는 컴퓨터간의 관계를 역할로 구분하는 개념이다.

서버 : 서비스를 제공하는 컴퓨터
클라이언트 : 서비스를 사용하는 컴퓨터

서비스는 서버가 클라이언트로부터 요청받은 작업을 처리하여 그 결과를 제공하는 것을 뜻한다.

서버가 제공하는 서비스의 종류에 따라 파일서버, 메일서버, 어플리케이션 서버 등이 있다.

예를 들어, 파일서버는 클라이언트가 요청한 파일을 제공하는 서비스를 수행한다.

서버에 접속하는 클라이언트의 수에 따라 하나의 서버가 여러 가지 서비스를 제공하기도 하고

하나의 서비스를 여러 대의 서버로 제공하기도한다.

서버가 서비스를제공하기위해서는서버프로그램이있어야하고클라이언트가서비스를 제공받기ㅔ 위해서는 서버프로그램과 연결할 수 있는 클라이언트 프로그램이 있어야 한다.

예를들면, 웹서버에 접속하여 정보를 얻기 위해서는 웹브라우저가 있어야 하고, FTP서버에 접속해서 파일을 전송받기

위해서는 알FTP와 같은 FTP클라이언트 프로그램이 필요하다.

네트워크를 구성할 때 전용서버를 두는 것을 서버기반모델(server-based model)이라 하고 별도의 전용서버없이 각 클라이언트가 서버열할을 동시에 수행하는 것을 P2P모텔(peer-to-peer)이라 한다.

서버기반모델(server-based model)	P2P모텔(peer-to-peer)
- 안정적인 서비스의 제공이 가능하다. - 공유 데이터의 관리와 보안이 용이하다 - 서버구축비용과 관리비용이 든다.	- 서버구축 및 운용비용을 절감할 수 있다. - 자원의 활용을 극대화 할 수 있다. - 자원의 관리가 어렵다. - 보안이 취약하다.

IP 주소 (IP address)

IP주소는 컴퓨터(호스트, host)를 구별하는데 상뇽되는 고유한 값으로 인터넷에 연결된 모든 컴퓨터는 IP주소를 갖는다.

IP주소는 네트워크 주소와 호스트 주소로 나눌 수 있는데, 32bit(4byte)의 IP주소 중에서 네트워크주소와 호스트주소가 각각 몇 bit를 차지하는 지는 네트워크를 어떻게 구성하였는지에 따라 달라진다.

그리고 서로 다른 두 호스트의 IP주소의 네트워크 주소가 같다는 것은 두 호스트가 같은 네트워크에 포한되어 있다는 것을 의미한다.

InetAddress

자바에서는 IP주소를 다루기 위한 클래스로 InetAddress를 제공한다.

아래 링크에서 메소드들을 확인 할 수 있다.

https://docs.oracle.com/javase/7/docs/api/java/net/InetAddress.html

InetAddress (Java Platform SE 7 )

Gets the fully qualified domain name for this IP address. Best effort method, meaning we may not be able to return the FQDN depending on the underlying system configuration. If there is a security manager, this method first calls its checkConnect method wi

docs.oracle.com

URL

인터넷에 존재하는 여러 서버들이 제공하는 자원에 접근할 수 있는 주소를 표현하기 위한 것이다.

'프로토콜://호스트명:포트번호/경로명/파일명?쿼리스트링#참조' 의 형태로 이루어져 있다.

http://www.codechobo.com:80/sample/hello.html?referer=codechobo#index1

프로토콜 자원에 접근하기 위해 서버와 통신하는데 사용되는 통신규약 (http)
호스트명 자원을 제공하는 서버의 이름 (www.javachobo.com)
포트번호 통신에 사용되는 서버의 포트번호 (80)
경로명 접근하려는 자원이 저장된 서버상의 위치 (/sample)
파일명 접근하려는 자원의 이름 (hello.html)
쿼리(query) URL에서'?' 이후의 부분 (referer=javachobo)
참조(anchor) URL에서 '#' 이후의 부분 (index1)

URLConnection

어플리케이션과 URL간의 통신연결을 나타내는 클래스의 최상위 클래스, 추상클래스이다.

URLConnection을 상속받아 구현한 클래스로는 HttpURLConnection과 JarURLConnection이 있으며,

URL의 프로토콜이 http프로토콜이라면 openConnection()은 Http URLConnection을 반환한다.

참고자료 : 자바의 정석

[ JAVA ] 직렬화란

리신 — Tue, 25 Apr 2023 23:19:07 +0900

객체를 저장하거나 메모리, 데이터베이스 혹은 파일로 옮기려면 어떻게 해야할까?

이럴 때 필요한 것이 직렬화다.

직렬화란?

직렬화란 객체를 데이터 스트림으로 만드는 것을 뜻한다.

즉 객체에 저장된 데이터를 스트림에 쓰기위해 연속적인 데이터로 변환하는 작업을 말한다.

솔직히 이렇게 말하면 어려운것 같다..

쉽게 말하면, 직렬화란 현재 데이터의 상태를 영속적으로 저장하거나

다른 환경으로 전달(네트워크 통신 등)하기 위해 어떠한 정해진 포맷으로 변환하는 과정을 말한다.

그리고 이 변환된 데이터를 다시 원래 데이터로 변환 가능하며, 이러한 과정을 역직렬화라고 한다.

그리고 자바에서는 직렬화란?

자바 시스템 내부에서 사용되는 객체 또는 데이터를 외부의 자바 시스템에서도 사용할 수 있도록 바이트(byte) 형태로 데이터 변환하는 기술과 바이트로 변환된 데이터를 다시 객체로 변환하는 기술(역직렬화)을 아울러서 말한다.

시스템 적으로는 JVM(Java Virtual Machine)의 메모리에 상주(heap 또는 stack) 되어 있는 객체 데이터를 바이트 형태로 변환하는 기술과 직렬화된 바이트 형태의 데이터를 객체로 변환해서 JVM으로 상주시키는 형태를 말한다.

ObjectInputStream, ObjectOutputStream

직렬화에는 ObjectOutputStream을 사용하고, 역직렬화에는 ObjectInputStream을 사용한다.

각각은 OutputStream과 InputStream을 직접 상속받지만 기반스트림을 필요로 하는 보조 스트림이므로 객체 생성시 입출력할 스트림을 지정해주어야 한다.

예시)

만약 파일에 객체를 저장(직렬화)하고 싶다면 아래와 같이 하면된다.

FileOutputStream fos = new FileOutputStream("objectfile.ser");
ObjectOutStream out = new ObjectOutStream(fos);

out.writeObject(new UserInfo());

위 코드는 objectfile.ser 이라는 파일에 UserInfo 객체를 직렬화 하여 저장한다.

출력할 스트림(FileOutpu tStream)을 생성해서 이를 기반스트림으로 하는 ObjectOutputStream을 생성한다.

ObjectOutStream의 writeObject(Object obj)를 사용해서 객체를 출력하면,

객체가 파일에 직렬화되어 저장된다.

역직렬화 방법도 간단하다.

직렬화할 때와는 달리 입력스트림을 사용하고 writeObject(Object obj)대신 readObject()를 사용하여 저장된 데이터를

읽기만 하면 객체로 역직렬화 된다.

직렬화 가능한 클래스 만들기 - Serializable, transient

직렬화하고자하는 클래스가 java.io.Serializable인터페이스를 구현하도록 하면 직렬화가 가능한 클래스를 만들 수 있다.

조상이 Serializable인터페이스를 구현하였다면 자손 클래스도 직렬화가 가능하다.

public class UserInfo implements Serializable{
    Object obj = new Object(); // 직렬화 불가능
    Object obj = new String("abc"); // 직렬화 가능
}

Object 객체는 직렬화할 수 없지만, 실제로 저장된 객체가 직렬화가 가능하다면 직렬화를 수행할 수 있다.

transient

직렬화하고자 하는 객체의 클래스에 직렬화가 안 되는 객체에 대한 참조를 포함하고 있다면,

제어자 transient를 붙여서 직렬화 대상에서 제외할 수 있다.

public class UserInfo implements Serializable {
  String name;
  transient String password;  // 직렬화 대상에서 제외
  int age;
  transient Object obj = new Object();  // 직렬화 대상에서 제외

직렬화가능한 클래스의 버전관리

직렬화된 객체를 역직렬화할 때는 직렬화 했을 때와 같은 클래스를 사용해야한다.

그러나 클래스의 이름이 같더라도 내용이 변경된 경우에는 역직렬화에 실패하기 때문에 버전을 일치시켜야 한다.

객체를 직렬활 할 때 serialVersionUID라는 클래스 버전을 자동생성해서 직렬화 내용에 포함한 뒤,

역직렬화 할 때 클래스의 버전을 비교할 수 있게 한다.

그러나 static변수나 상수 또는 transient가 붙은 인스턴스변수가 추가되는 경우에는 직렬화에 영향을 미치지 않기 때문에

클래스의 버전을 다르게 인식하도록 할 필요는 없다.

참고자료 : 자바의 정석, 우아한형제들 기술블로그

https://techblog.woowahan.com/2550/

자바 직렬화, 그것이 알고싶다. 훑어보기편 | 우아한형제들 기술블로그

{{item.name}} 자바의 직렬화 기술에 대한 대한 이야기입니다. 간단한 질문과 답변 형태로 자바 직렬화에 대한 간단한 설명과 직접 프로젝트를 진행하면서 겪은 경험에 대해 이야기해보려 합니다.

techblog.woowahan.com

[ JAVA ] 입출력

리신 — Wed, 5 Apr 2023 00:57:58 +0900

입출력이란?

I/O란 INPUT과 OUTPUT의 약자로 입력과 출력, 간단히 줄여서 입출력이라고 한다.

입출력은 컴퓨터 내부 또는 외부의 장치와 프로그램간의 데이터를 주고받는 것을 말한다.

1. 스트림 (Stream)

한마디로 정의 하면 스트림이란 데이터를 운반하는데 사용되는 연결통로이다.

스트림의 특징

스트림은 단방향통신만

가능하다.

따라서 입력과 출력을 동시에 처리 할 수 없다.

입력과 출력을 동시에 수행하려면❕❓

입력을 위한 입력스트림과 출력을 위한 출력스트림, 2개의 스트림이 필요하다.

그리고 스트림은 먼저 보낸 데이터를 먼저 받게 되어 있으며 중간에 건너뜀 없이 연속적으로 데이터를 주고받는다.

큐와 같은 FIFO(First In First Out)구조로 되어 있다고 생각하면 이해가 쉽다.

2. 바이크기반 스트림 - InputStream, OutputStream

스트림은 바이트단위로 데이터를 전송하며 입출력 대상에 따라 아래의 표와 같이 입출력스트림이 있다.

입력스트림	출력스트림	입출력 대상의 종류
FileInputStream	FileOutputStream	파일
ByteArrayInputStream	ByteArrayOutputStream	메모리(byte배열)
PipedInputStream	PipedOutputStream	프로세스(프로세스간의 통신)
AudioInputStream	AudioOutputStream	오디오장치

자바에서는 java.io패키지를 통해서 많은 종류의 입출력관련 클래스들을 제공하고 있으며,

입출력의 대상이 달라져도 동일한 방법으로 입출력이 가능하기 때문에 프로그래밍을 하기에 편리하다.

InputStream	OutputStream
abstract int read( )	abstract void write(int b)
int read(byte[] b)	void write(byte[] b)
int read(byte[] b, int off, int len)	void write(byte[] b, int off, int len)

위 표에 나온 메서드의 사용법만 잘 알고 있어도 데이터를 읽고 쓰는 것은 입출력 대상의 종류에 관계없이 간단한 일이라고 한다.

InputStream의 read()와 OutputStream의 write(int b)는 입출력의 대상에 따라 읽고 쓰는 방법이 다를 것이기 때문에

각 상황에 알맞게 구현하라는 의미에서 추상메서드로 정의되어있다.

3. 보조 스트림

보조 스트림은 말그대로 스트림을 보조하는 역할을 한다.

보조 스트림은 실제로 데이터를 주고받는 스트림이 아니기 때문에 데이터를 입출력 할 수 있는 기능은 없지만,

스트림의 기능을 향상시키거나 새로운 기능을 추가 할 수 있게 해준다.

예) test.txt라는 파일을 읽기 위해 FileInputStream을 사용할 때, 입력 성능을 향상시키기 위해 버퍼를 사용하는

보조스트림인 BuffereadInputStream을 사용한다.

입력	출력	설명
FilterInputStream	FilterOutputStream	필터를 이용한 입출력 처리
BufferedInputStream	BufferedOutputStream	버퍼를 이용한 입출력 성능향상
DataInputStream	DataOutputStream	int, float와 같은 기본형 단위로 데이터를 처리
SequenceInputStream	없음	두 개의 스트림을 하나로 연결
LineNumberInputStream	없음	읽어 온 데이터의 라인 번호를 카운트
ObjectInputStream	ObjectOutputStream	데이터를 객체단위로 읽고 쓰는데 사용
없음	PrintStream	버퍼를 이용하여 추가적인 print관련 기능
PushbackInputStream	없음	버퍼를 이용해서 읽어 온 데이터를 다시 되돌리는 기능

4. 문자기반 스트림 - Reader, Writer

Java에서는 한 문자를 의미하는 char형이 1byte가 아니라 2bute이기 때문에 바이트기반의 스트림으로 2byte인 문자를 처리하는 데는 어려움이 있다.

이 점을 보완하기 위해서 문자기반의 스트림이 제공된다.

문자데이터를 입출력할 때는 바이트기반 스트림 대신 문자기반 스트림을 사용해야한다.

바이트기반 스트림	문자기반 스트림
FileInputStream FileOutputStream	FileReader FileWriter
ByteArrayInputStream ByteArrayOutputStream	CharArrayReader CharArrayWriter
PipedInputStream PipedOutputStream	PipedReader PipedWriter
StringBufferedInputStream StringBufferedOutputStream	StringReader StringWriter

문자기반 스트림의 이름은 바이트기반 스트림의 이름에서 뒤에 부분만 바꿔주면 된다.

InputStream → Reader
OutputStream → Writer

5. 바이트기반 스트림

InputStream 메서드

메서드 명	설 명
int available()	스트림으로부터 읽어 올 수 있는 데이터의 크기를 반환한다.
void close()	스트림을 닫음으로써 사용하고 있던 자원을 반환한다.
void mark(int readlimit)	현재 위치를 표시해 놓는다. 후에 reset()에 의해서 표시해 놓은 위치로 다시 돌아갈 수 있다. readlimit: 되돌아갈 수 있는 byte의 수
boolean markSupported()	mark()와 reset()을 지원하는 지를 알려 준다. 이 메서드로 먼저 확인을 해야한다.
abstract int read()	1 byte를 읽어온다. 더 이상 읽을 데이터가 없다면 -1을 반환한다.
int read(byte[] b)	배열 b의 크기만큼 읽어서 배열을 채우고 읽어 온 데이터의 수를 반환한다.
int read(byte[] b, int off, int len)	최대 len 개의 byte를 읽어서 배열 b의 위치off부터 저장한다.
void reset()	스트림에서 위치를 마지막으로 mark()이 호출되었던 위치로 되돌린다.
long skip(long n)	스트림에서 주어진 길이n만큼 건너뛴다.

OutputStream 메서드

메서드 명	설 명
void close()	입력소스를 닫음으로써 사용하고 있던 자원을 반환한다.
void flush()	스트림의 버퍼에 있는 모든 내용을 출력소스에 쓴다.
abstract void write(int b)	주어진 값을 출력소스에 쓴다.
void write(byte[] b)	주어진 배열 b에 저장된 모든 내용을 출력소스에 쓴다.
void write(byte[] b, int off, int len)	주어진 배열 b에 저장된 내용 중에서 off번째 부터 len개 만큼만을 읽어서 출력소스에 쓴다.

스트림의 종류에 따라서 mark()와 reset()을 사용하여 이미 읽은 데이터를 되돌려서 다시 읽을 수 있다.
이 기능을 지원하는 스트림인지 확인하는 markSupported()를 통해서 알 수 있다.

flush()는 버퍼가 있는 출력스트림의 경우에만 의미가 있으며, OutputSteream에 정의된 flush()는 아무런 일도 하지 않는다.
프로그램이 종료될 때, 사용하고 닫지 않은 스트림을 JVM이 자동적으로 닫아 주기는 하지만,

스트림을 사용해서 모든 작업을 마치고 난 후에는 close()를 호출해서 반드시 닫아 주어야 한다.

그러나 ByteArrayInputStream과 같이 메모리를 사용하는 스트림과
System.in, System.out과 같은 표준 입출력 스트림은 닫아 주지 않아도 된다.

6. ByteArrayInputStream과 ByteArrayOutputStream

두 스트림은 메모리, 즉 바이트배열에 데이터를 입출력 하는데 사용되는 스트림이다.

주로 다른 곳에 입출력하기전에 데이터를 임시로 바이트배열에 담아서 변환 등의 작업을 하는데 사용된다.

예제를 보면 아래의 코드는 ByteArrayInputStream ByteArrayOutputStream을 이용해서 바이트배열 inSrc의 데이터를 outSrc로 복사하는 예제이다.

public class Main {
    public static void main(String[] args) {
        byte[] inSrc = {0,1,2,3,4,5,6,7,8,9};
        byte[] outSrc = null;

        ByteArrayInputStream input = null;
        ByteArrayOutputStream output = null;

        input = new ByteArrayInputStream(inSrc);
        output = new ByteArrayOutputStream();

        int data = 0;
        // read()를 호출한 반환값을 변수 data에 저장한 후 data에 저장된 값이 -1인지 비교
        while((data = input.read()) != -1) {
            output.write(data); 
        }

        outSrc = output.toByteArray(); // 스트림의 내용을 byte배열로 반환한다.

        System.out.println("Input Source: " + Arrays.toString(inSrc));
        System.out.println("output Source: " + Arrays.toString(outSrc));
    }
}

/*
  출력결과
  Input Source: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
  output Source: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
*/

바이트배열은 사용하는 자원이 메모리 밖에 없으므로 가비지컬렉터에 의해 자동적으로 자원을 반환하므로 close()를 이용해서 스트림을 닫지 않아도 된다.

그리고 위 코드는 read()와 write( int b)만 사용하기 때문에 한번에 1 byte만 읽고 쓰므로 작업효율이 떨어진다.

그러면 효율적이게 작업을 하기 위해서는 어떻게 해야할까?

아래의 예제를 보면 int read(byte[] b, int off, int len)와 void write(byte[] b, int off, int len)을 이용해서 입출력하는 방법을 보여주는 예이다.

이전 예제와는 달리 byte배열을 이용해서 한 번에 배열의 크기만큼 읽고 쓸 수 있다.

만약 스트림의 크기를 정확히 모를 때는 일정한 크기의 바이트를 계속해서 받아서 써야한다.

public class Main {
    public static void main(String[] args) {
        byte[] inSrc = {0,1,2,3,4,5,6,7,8,9};
        byte[] outSrc = null;

        byte[] temp = new byte[10];

        ByteArrayInputStream input = null;
        ByteArrayOutputStream output = null;

        input = new ByteArrayInputStream(inSrc);
        output = new ByteArrayOutputStream();

        input.read(temp, 0, temp.length);       // 읽어 온 데이터를 temp에 담는다.
        output.write(temp, 5, 5);           // temp[5]부터 5개의 데이터를 write한다.

        outSrc = output.toByteArray();

        System.out.println("Input Source: " + Arrays.toString(inSrc));
        System.out.println("temp Source: " + Arrays.toString(temp));
        System.out.println("output Source: " + Arrays.toString(outSrc));

    }
}
/*
출력결과
Input Source: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
temp Source: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
output Source: [5, 6, 7, 8, 9]


*/

7. FileInputStream과 FileOutputStream

FileInputStream/FileOutputStream은 파일에 입출력을 하기 위한 스트림이다.

생성자	설명
FileInputStream(String filePath)	filepath로 지정한 파일에 대한 입력 스트림을 생성한다.
FileInputStream(File fileObj)	fileObj로 지정한 파일에 대한 입력 스트림을 생성한다.
FileInputStream(FileDescriptor fdObj)	fdObj 로 기존의 접속을 나타내는 파일 시스템의 입력 스트림을 생성한다.
FileOutputStream(String filepath)	filepath로 지정한 파일에 대한 OutputStream을 생성한다.
FileOutputStream(String filepath)	지정한 파일로 OutputStream을 생성한다. append 인자로 출력할 때 append 모드를 설정한다.
FileOutputStream(File fileObj)	fileObj로 지정된 파일에 대한 OutputStream을 생성한다.
FileOutputStream(File fileObj, boolean append)	fileObj로 지정된 파일에 대한 OutputStream을 생성한다. append 인자로 출력할 때 append 모드를 설정한다.
FileOutputStream(FileDescriptor fdObj)	fdObj 로 기존의 접속을 나타내는 파일 시스템의 OutputStream을 생성한다.

* 단순히 텍스트파일을 다루는 경우에는 문자기반의 스트림인 FileReader/FileWriter를 사용하는 것이 더 좋다.

*참고 : JAVA의 정석