정진영의 포트폴리오

네이버, 감정형 AI 비서 ‘NAVER Mate’ 공개 임박…국내 검색 생태계 지각 변동 예고

Mon, 20 Oct 2025 00:00:00 +0000

국내 최대 포털 네이버가 연내 새롭게 선보일 것으로 알려진 감정형 AI 비서 NAVER Mate가 업계의 주목을 받고 있다. 단순 답변형 챗봇을 넘어 사용자의 기분·맥락·패턴을 분석해 능동적으로 제안까지 수행하는 퍼스널 AI 에이전트로, IT 업계에서는 “국내 검색 시장 패러다임을 바꿀 서비스가 될 것”이라는 평가가 나오고 있다.

1. NAVER Mate, 어떤 서비스인가

NAVER Mate는 사용자의 생활 전반에 걸쳐 AI가 능동적으로 정보를 수집·분석하고 행동을 제안하는 하이브리드형 AI 어시스턴트다.
네이버의 캘린더, 메일, 뉴스, 지도, 쇼핑 등과 API 수준에서 연동되며, 사용자는 음성·텍스트 기반 대화만으로 다양한 업무를 처리할 수 있다.

주요 기능

일정 자동 정리 및 리마인드
뉴스/자료 요약 및 근거 출처 제공
사용자 감정 상태 분석 및 대화 톤 조절
관심사 기반 콘텐츠 추천
실시간 자연어 기반 검색·요약

2. 기존 AI 비서와의 차별점

업계가 주목한 지점은 단순 요약형 AI가 아닌 검증 가능한 AI라는 점이다.

비교 항목	기존 챗봇	NAVER Mate
데이터 출처	불분명한 경우 다수	출처 링크 명시
역할	질의응답 중심	요약 + 팩트 검증 + 제안
UX	단순 대화형	탭 전환 없는 하이브리드 UI

AI가 내용을 요약하면, 바로 옆에 근거 출처 링크가 함께 제시되는 방식으로, 사용자가 팩트를 검증하며 신뢰도 높은 정보를 소비할 수 있도록 설계되었다.

3. 전문가 코멘트

AI 업계 관계자는 다음과 같이 전망했다.

“이제 사용자는 링크를 수집하는 것이 아니라 정보를 검증하는 단계로 넘어가고 있다.
NAVER Mate는 ‘검색-요약-팩트체크’라는 3단계를 한 화면에서 해결하는 첫 시도라는 점에서 상징성이 크다.”

하지만 우려도 존재한다. AI가 감정·루틴까지 학습하는 만큼 프라이버시, 데이터 관리, 감정 의존성 문제가 뒤따를 수 있다는 지적이다.

4. 향후 전망

네이버는 조만간 비공개 베타를 진행하고, 사용자 피드백을 바탕으로 정식 버전을 연내 출시할 것으로 예상된다.
업계에서는 이 서비스가 본격적으로 공개될 경우 카카오, 구글, 퍼플렉시티 등과의 차세대 검색 경쟁이 본격화될 것으로 보고 있다.

5. 결론

NAVER Mate는 “대화로 이해하고, 링크로 검증하는” AI 시대를 선언하는 상징적 서비스가 될 전망이다.
AI가 단순히 빠른 답을 주는 존재에서, 책임 있는 정보 파트너로 진화할 수 있을지 관심이 집중된다.

※ 본 기사는 허구의 시나리오를 기반으로 작성된 콘텐츠로, 실제 기업 계획과 무관합니다.

Machine Learning

Mon, 13 Oct 2025 00:00:00 +0000

머신러닝 학습 일지: 데이터로 컴퓨터를 가르치다

3학년 2학기가 되면서 기계학습이라는 교과목을 접하게 되었습니다. 매주 월, 수 16시에 공과대학 7호관 523호실에서 송현제 교수님의 수업을 듣고 있습니다. 위의 첨부되어 있는 링크에서 송현제 교수님 사이트에서 정보를 확인 하실 수 있습니다!

‘머신러닝’이라는 단어, 처음에는 왠지 어렵고 복잡하게만 느껴졌습니다. 하지만 막상 배워보니, 생각보다 우리 삶과 가까운, 흥미로운 기술이라는 것을 알게 되었습니다. 제가 배운 머신러닝의 기초적인 개념들을 쉬운 말로 한번 정리해 보았습니다.

🧐 머신러닝, 그게 뭔데? 제가 이해한 머신러닝은 아주 간단한 아이디어에서 시작합니다. 컴퓨터에게 ‘이건 사과야’, ‘이건 오렌지야’라고 하나하나 모든 규칙을 알려주는 대신, 수많은 데이터를 보여주고 컴퓨터가 스스로 패턴이나 규칙을 배우게 하는 기술입니다.

마치 어린아이가 강아지 사진 수백 장을 보고 ‘아, 귀가 쫑긋하고 털이 북슬한 동물이 강아지구나!’ 하고 스스로 깨닫는 것과 비슷하죠.

📚 내가 배운 학습 방법 두 가지 머신러닝에는 여러 종류가 있지만, 저는 가장 대표적인 두 가지 방법에 대해 배웠습니다.

정답을 알려주며 가르치기: 지도 학습 (Supervised Learning) 지도 학습은 말 그대로 ‘정답(Label)‘이 있는 데이터로 컴퓨터를 학습시키는 방법입니다. ‘문제’와 ‘정답’을 한 세트로 묶어서 계속 보여주는 거죠.

스팸 메일 필터가 대표적인 예입니다. ‘이건 스팸 메일이야(정답)’, ‘이건 중요한 메일이야(정답)‘라고 표시된 수많은 이메일(문제)을 학습시키면, 나중에는 새로운 메일이 왔을 때 스스로 스팸인지 아닌지 구분하게 됩니다.

주택 가격 예측도 마찬가지입니다. ‘A 지역의 30평 아파트는 5억이야(정답)’ 같은 수많은 집값 데이터(문제)를 학습하면, 새로운 아파트 정보를 주었을 때 가격을 예측할 수 있게 됩니다.

정답 없이 스스로 배우게 하기: 비지도 학습 (Unsupervised Learning) 비지도 학습은 정답이 없는, 날것의 데이터를 던져주고 “이 안에서 뭔가 의미 있는 그룹이나 구조를 찾아봐!” 하고 시키는 것과 같습니다. 컴퓨터는 데이터의 특징을 분석해서 비슷한 것들끼리 스스로 묶어줍니다.

고객 관리에 유용하게 쓰일 수 있습니다. 고객들의 구매 패턴 데이터를 주고 그룹으로 묶어보게 하면, ‘알뜰 구매 그룹’, ‘신제품 선호 그룹’처럼 숨겨진 고객 그룹을 찾아낼 수 있습니다.

뉴스 기사 클러스터링도 좋은 예입니다. 수많은 뉴스 기사를 던져주면, 인공지능이 스스로 ‘정치’, ‘경제’, ‘스포츠’ 등 비슷한 주제의 기사들끼리 묶어줍니다.

✨ 마치며 직접 개념을 배우고 나니, 머신러닝이 막연한 기술이 아니라 문제를 해결하기 위한 아주 논리적인 도구라는 생각이 들었습니다. 물론 아직은 정말 기초적인 부분만 알고 있지만, 데이터 속에서 의미를 찾아내는 과정이 정말 매력적이라고 느꼈습니다. 앞으로 더 깊이 공부해 보고, 간단한 프로젝트도 직접 해보고 싶다는 목표가 생겼습니다.

JAVA

Sun, 12 Oct 2025 00:00:00 +0000

자바의 문법과 기능을 단순히 알기만 하는 것이 아니라, 그 기능이 왜 필요하고 어떻게 실무에 적용할 수 있는지에 대해 깊이 있게 탐구하기 위해 공부를 시작하였다.

지금까지 공부한 내용은 다음과 같다.

Object 클래스

Object 클래스는 모든 클래스의 최상위 부모이다. Object 클래스가 필요한 이유와 Object 클래스가 제공하는 기능과 equals()를 통해 자바의 동일성과 동등성 개념도 함께 공부하였다.

불변 객체

한번 생성하면 그 이후로 변하지 않는 객체를 불변 객체라 합니다. String, 래퍼, 날짜와 시간을 포함해서 자바가 제공하는 많은 객체들은 불변 객체로 제공된다. 불변 객체가 왜 필요한지, 그리고 어떻게 불변 객체를 만드는지 공부하였다.

String 클래스

String 클래스는 자바에서 문자열을 다룰 때 사용되는 클래스이다. String 객체의 기본 기능 뿐만 아니라, StringBuilder와 String의 기능과 성능 차이, 또한 자바가 String 클래스를 어떻게 최적화하는지 공부하였다.

래퍼, Class 클래스

자바 기본형의 한계를 알아보고 그 한계를 극복하기 위한 래퍼 클래스를 공부하였다. 추가로 클래스의 정보를 나타내는 Class 클래스, 시스템의 정보를 제공하는 System 클래스, 자주 사용하는 Math, Random 같은 클래스도 함께 공부하였다.

열거형 - ENUM

열거형은 높은 타입 안전성을 제공하는 훌륭한 기능이다. 단순히 열거형의 문법을 배우는 것이 아니라 본질적으로 열거형이 왜 필요한지 공부하였다. 그리고 열거형이 없던 시절 직접 구현했던 타입 안전 열거형 패턴도 구현해보았다.

중첩 클래스, 내부 클래스

클래스 내부에 클래스를 두는 것을 중첩 클래스 또는 내부 클래스라 한다.

예외 처리

자바에서 예외 처리 문법은 단순하지만 예외 처리가 왜 필요한지 공부하였다.

Spring MVC

Sun, 12 Oct 2025 00:00:00 +0000

서블릿에서 스프링 MVC까지: Java 웹 개발의 흐름을 배우다

이번에는 Java 백엔드 개발의 핵심 기술이라 할 수 있는 웹 애플리케이션의 발전 과정을 되짚어보는 시간을 가졌습니다.

왜 웹 애플리케이션인가? 현대의 애플리케이션은 대부분 웹 환경에서 동작합니다. 우리가 매일 사용하는 수많은 서비스가 바로 웹 애플리케이션이죠. Java 백엔드 개발자는 이러한 웹 애플리케이션의 서버 측 로직을 개발하는 중요한 역할을 담당하며, 이때 가장 강력한 도구로 사용되는 것이 바로 스프링 프레임워크, 특히 스프링 MVC입니다.

이번 학습을 통해 복잡한 웹 애플리케이션을 쉽고 빠르게 개발할 수 있도록 도와주는 스프링 MVC를 깊이 이해하기 위해, 그 뿌리가 되는 기술부터 차근차근 공부했습니다.

Java 웹 기술의 시작, 서블릿(Servlet) 모든 것은 서블릿에서 시작되었습니다. 서블릿은 클라이언트의 요청을 받고, 비즈니스 로직을 처리한 후, 동적인 HTML 응답을 생성하는 순수 Java 코드입니다. 하지만 서블릿 코드 안에 HTML 코드를 문자열(out.println("…")) 형태로 작성해야 했기 때문에, 화면을 수정하기가 매우 번거롭고 가독성이 떨어지는 단점이 있었습니다.
화면을 분리하다, JSP(JavaServer Pages) 이러한 서블릿의 단점을 보완하기 위해 등장한 것이 JSP입니다. JSP는 HTML 문서 안에 Java 코드를 삽입하는 방식으로, 디자이너와 개발자의 협업을 더 쉽게 만들었습니다. 덕분에 화면(View)을 표현하는 작업이 훨씬 수월해졌습니다.

하지만 JSP만으로는 부족했습니다. 비즈니스 로직과 화면을 보여주는 코드가 하나의 파일에 뒤섞여, 프로젝트 규모가 커질수록 유지보수가 어려워지는 ‘스파게티 코드’ 문제가 발생하기 시작했습니다.

역할 분담의 시작, MVC 패턴 이 문제를 해결하기 위해 MVC(Model-View-Controller) 패턴이라는 설계 사상이 등장했습니다.

Model: 데이터와 비즈니스 로직을 담당합니다.

View: 사용자에게 보여지는 화면(UI)을 담당합니다. (JSP)

Controller: 사용자의 요청을 받아 Model과 View를 연결해주는 중간 다리 역할을 합니다. (Servlet)

이렇게 각자의 역할을 명확히 분리함으로써, 코드는 훨씬 더 체계적이고 재사용하기 쉬워졌습니다.

스프링 MVC의 탄생과 실무 활용 MVC 패턴을 직접 구현하는 것은 여전히 반복적이고 번거로운 작업이 많았습니다. 개발자들은 이러한 MVC 패턴을 더 쉽고 편리하게 사용할 수 있도록 도와주는 MVC 프레임워크를 만들기 시작했고, 그중 가장 성공적이고 압도적인 인기를 얻게 된 것이 바로 스프링 MVC입니다.

스프링 MVC는 MVC 패턴 구현에 필요한 복잡한 처리 과정을 대신해주어, 개발자가 오직 비즈니스 로직에만 집중할 수 있는 환경을 제공합니다. 이번 학습을 통해 스프링 MVC의 탄생 배경부터 실무에서 주로 사용하는 최신 기술까지 익히며, 왜 수많은 기업이 스프링을 선택하는지 몸소 깨달을 수 있었습니다.

앞으로 이 기술들을 활용하여 직접 프로젝트를 진행하며 겪는 경험들도 꾸준히 공유해 나가겠습니다. 감사합니다!

위의 첨부된 링크에서 제가 지금까지 공부한 코드들을 확인 해볼 수 있습니다!

애플, ‘iOS AI’ 전격 발표… “앱 중심에서 에이전트 중심으로” 패러다임 대전환

Fri, 10 Oct 2025 00:00:00 +0000

애플이 차세대 운영체제 iOS AI를 공개하며, 스마트폰의 UX 패러다임을 앱(App)에서 에이전트(Agent) 중심으로 전환하겠다고 선언했다. 애플은 “사용자가 앱을 실행하지 않아도 AI가 자동으로 실행하고 정리하는 시대를 열 것”이라고 발표했으며, 이에 따라 글로벌 IT 업계에 거대한 변화가 예상된다.

1. iOS AI, 무엇이 달라지나

이번 업데이트의 핵심은 에이전트형 OS다. 사용자가 명령하거나 앱을 직접 열지 않아도, AI가 선제적으로 업무를 처리하는 방식이다.

주요 기능

자연어 하나로 멀티 작업 자동 실행
앱 사용 패턴 기반 ‘선(先)추천형’ UI
AI가 메시지·이메일을 자동 요약 및 분류
상황 기반 액션 실행(시간·위치·사용자 상태 반영)

애플은 이를 ‘No-App Surface Era(앱 없는 표면의 시대)’라고 정의했다.

2. UX 변화: ‘실행’에서 ‘위임’으로

기존 스마트폰 UX는 “앱 실행 → 작업 수행” 구조였다.
애플은 이를 아래와 같이 바꾼다.

기존 UX	iOS AI UX
내가 앱을 켬	AI가 필요한 앱을 먼저 염
내가 정보를 찾음	AI가 정보를 요약·정리해 제시
내가 할 일을 계획	AI가 먼저 제안 & 실행

애플은 “사용자는 의지를 표현만 하면 되고, 실행은 OS가 책임지는 환경을 만들겠다”고 강조했다.

3. 우려와 논쟁

전문가들은 기회와 위험을 동시에 지적한다.

“시스템 레벨의 AI 자동화는 생산성을 폭발적으로 올리지만,
개인정보와 알고리즘 편향에 대한 전례 없는 감시와 규제가 필요하다.”

특히 AI가 OS 핵심에 들어가면, 사용자가 ‘왜 이런 추천을 봤는지’ 알 권리가 더 중요해질 것으로 보인다.

4. 향후 전망

iOS AI는 내년 3월 베타, 6월 정식 배포가 예상된다.
업계에서는 이번 발표가 사실상 구글·삼성과의 ‘AI OS 전면전’의 시작이라고 해석하고 있다.

5. 결론

애플은 스마트폰의 다음 시대는 앱이 아니라 에이전트가 주도한다는 메시지를 던졌다.
이제 경쟁의 무대는 앱 스토어가 아니라 생성형 OS의 주도권이 될 전망이다.

※ 본 기사는 창작된 가상의 시나리오이며 실제 기업 발표와 무관합니다.

삼성, ‘Galaxy Glass’ 내년 출시설… 스마트폰 이후 차세대 플랫폼 노리나

Wed, 01 Oct 2025 00:00:00 +0000

삼성이 내년 상반기, AR 기반 웨어러블 기기 **Galaxy Glass(가칭)**를 공개할 것이라는 소식이 전해지며, 글로벌 IT 업계의 관심이 집중되고 있다. 애플의 Vision Pro와 메타의 Quest 라인업이 경쟁 중인 가운데, 스마트폰 제조 강자 삼성까지 AR 풀스택 시장에 본격 뛰어든다면 판도가 크게 바뀔 수 있다는 전망이 나온다.

1. 스마트폰 다음 플랫폼으로 ‘안경형 AR’

업계 관계자들에 따르면 Galaxy Glass는 안경 형태의 초경량 AR 디바이스로, 스마트폰 없이도 핵심 기능을 단독 수행할 수 있도록 설계된 것이 특징이다.

예상 기능

AR 기반 내비게이션 & 실시간 번역
AI 비서(삼성 Gauss) 연동
눈동자/제스처 기반 UI
클라우드 스트리밍 기반 앱 실행
스마트폰+웨어러블 연동 생태계 확장

삼성은 이를 스마트폰 이후의 주력 인터페이스로 설정하고, 플랫폼 전환을 노린다는 평가다.

2. 시장 경쟁 구도

기업	전략 방향	약점
애플	고성능+프리미엄 생태계	진입장벽·고가
메타	대중형 MR 시장 확대	수익성 문제
삼성(예상)	경량·실사용성 중심 AR	콘텐츠 확보 과제

애플이 기술 완성도, 메타가 접근성을 앞세운다면, 삼성은 실사용성과 경량화를 무기로 다른 길을 갈 것이라는 분석이 많다.

3. 전문가 의견

한 AR 연구자는 다음과 같이 말했다.

“삼성은 디스플레이·칩·디바이스 라인업을 모두 가진 몇 안 되는 회사다.
만약 진짜 출시한다면, AR 시장의 균형을 바꿀 변수가 될 수 있다.”

다만 콘텐츠, 앱 생태계, 규제, 개인정보 보호는 여전히 해결해야 할 숙제로 꼽힌다.

4. 전망

Galaxy Glass가 실제로 출시된다면, 스마트폰 이후 차세대 플랫폼 경쟁이 본격적인 3강 구도로 재편될 가능성이 높다.
2026년은 AR 대중화의 원년이 될지 주목된다.

※ 본 기사는 허구의 시나리오로 작성된 가상 콘텐츠이며, 실제 기업 계획과 무관합니다.

팩맨

Sat, 01 Mar 2025 00:00:00 +0000

이 프로젝트는 인공지능 수업의 일환으로 진행한 UC Berkeley Pacman AI 프로젝트입니다. 이 과제의 핵심 목표는 **그래프 탐색(Graph Search)**의 기본이 되는 여러 알고리즘을 직접 구현하고, 이를 팩맨 게임 환경에 적용하여 실제 문제를 해결하는 것이었습니다.

search.py 파일에 범용 탐색 알고리즘들을 구현하고, searchAgents.py 파일에 팩맨의 특정 문제(Problem)들을 정의하고 해결하는 방식으로 진행했습니다.

1. 핵심 탐색 알고리즘 구현 (search.py)

먼저, 어떤 문제에도 적용할 수 있는 4가지 핵심 탐색 알고리즘을 구현했습니다.

DFS (깊이 우선 탐색): Stack(스택) 자료구조를 사용하여 가능한 한 깊은 노드를 먼저 탐색하는 알고리즘입니다. 방문한 노드를 기록(explored)하여 무한 루프를 방지하는 그래프 탐색 방식으로 구현했습니다.
BFS (너비 우선 탐색): Queue(큐) 자료구조를 사용하여 현재 노드에서 가장 가까운(얕은) 노드들을 먼저 탐색합니다. 이 방식은 경로의 비용이 모두 같을 때 최단 경로를 보장합니다.
UCS (균일 비용 탐색): PriorityQueue(우선순위 큐)를 사용합니다. 각 경로의 ‘누적 비용(cost)‘을 우선순위로 하여, 항상 비용이 가장 적게 든 경로를 먼저 탐색합니다. 이를 통해 최단 비용의 경로를 보장합니다.
A* (A-star) 탐색: UCS와 마찬가지로 PriorityQueue를 사용하지만, 우선순위를 ‘현재까지의 누적 비용($g(n)$)‘과 ‘목표까지의 추정 비용(휴리스틱, $h(n)$)‘의 합 ($f(n) = g(n) + h(n)$)으로 설정합니다. 정보에 기반한(informed) 탐색으로, UCS보다 훨씬 효율적으로 최적의 해를 찾아냅니다.

2. 팩맨 문제 정의 및 해결 (searchAgents.py)

단순히 알고리즘을 구현하는 것을 넘어, 팩맨이 직면한 복잡한 문제들을 ‘탐색 문제’로 모델링하고 해결했습니다.

📍 4개의 코너 방문 문제 (CornersProblem)팩맨이 맵의 네 귀퉁이에 있는 모든 점을 방문하는 경로를 찾는 문제입니다.

상태(State) 정의: 이 문제를 풀기 위해 상태 공간을 단순한 (x, y) 좌표가 아닌, (현재 위치, (방문한 코너 튜플))로 정의했습니다. 예를 들어, ((5, 5), (True, False, False, True))와 같이 현재 위치와 4개 코너의 방문 여부를 함께 기록했습니다.
목표(Goal) 정의: state[1]에 해당하는 튜플의 모든 값이 True가 되는 순간을 목표 상태로 설정했습니다. 후계자(Successor) 함수: 팩맨이 이동할 때마다, 새로 도착한 위치가 4개의 코너 중 하나인지 확인하고, 만약 코너라면 튜플의 해당 값을 True로 갱신한 새로운 상태를 생성하도록 구현했습니다.

💡 코너 문제 휴리스틱 (cornersHeuristic)

위의 코너 문제를 A* 탐색으로 풀기 위한 휴리스틱 함수를 직접 설계했습니다.

설계: 휴리스틱은 항상 실제 비용보다 낮거나 같아야 합니다(Admissible).
로직: ‘현재 위치’에서 ‘아직 방문하지 않은 모든 코너’까지의 맨해튼 거리(Manhattan Distance)를 각각 계산한 뒤, 그중 가장 큰(max) 값을 반환하도록 했습니다.
이유: 팩맨은 적어도 남아있는 코너 중 가장 먼 곳까지는 가야 모든 코너를 방문할 수 있으므로, 이 값은 항상 실제 남은 비용의 하한선이 되어 A*의 허용 가능한(admissible) 휴리스틱 조건을 만족합니다.

🍔 모든 음식 찾기 휴리스틱 (foodHeuristic)

맵에 흩어져 있는 모든 음식을 먹는 경로를 찾는 FoodSearchProblem을 위한 휴리스틱입니다.

로직: 코너 휴리스틱과 유사하게, ‘현재 위치’에서 ‘아직 먹지 않은 모든 음식’까지의 실제 미로 거리(mazeDistance)를 계산하고, 그중 가장 큰(max) 값을 반환했습니다.
mazeDistance 활용: 맨해튼 거리와 달리, mazeDistance는 BFS를 기반으로 벽을 모두 고려한 실제 최단 거리를 반환해 주어 더 정확한 추정치를 제공합니다.

🎯 가장 가까운 음식 찾기 (ClosestDotSearchAgent)

모든 음식을 한 번에 찾는 것은 매우 복잡(NP-hard)하므로, ‘가장 가까운 음식을 찾아 먹는’ 과정을 반복하는 탐욕(Greedy) 알고리즘을 구현했습니다.

findPathToClosestDot 구현: AnyFoodSearchProblem(어떤 음식이든 하나만 먹으면 성공)이라는 하위 문제를 정의했습니다.
UCS 활용: 이 문제에 UCS를 적용하여, 현재 위치에서 가장 비용(거리)이 적게 드는 음식의 위치와 경로를 찾아 반환하도록 했습니다. (비용이 1로 동일하므로 BFS도 동일한 결과를 보장합니다.)

전화번호부 애플리케이션

Fri, 20 Dec 2024 00:00:00 +0000

2024년 2학기 모바일프로그래밍 수업에서 만든 간단한 모바일 앱입니다.

이 프로젝트는 안드로이드의 기본 기능과 데이터베이스를 활용한 전화번호부 관리 앱입니다.

먼저, phoneDB라는 이름의 데이터베이스와 phoneTBL 테이블을 설계했습니다. 이 테이블은 **이름(문자형 20)**과 **전화번호(문자형 20)**를 저장하며, 이름은 중복될 수 없도록 UNIQUE 제약 조건을 설정했습니다. ‘홍길동’과 제 연락처를 초기 데이터 2개로 포함시켰습니다.

제가 구현한 주요 기능은 다음과 같습니다.

메인 화면 (데이터 조회): 앱 실행 시, 데이터베이스에 저장된 모든 사용자의 이름을 리스트(ListView)로 불러와 보여줍니다. 하단에는 ‘추가’ 버튼과 옵션 메뉴를 배치했습니다.

연락처 추가 (Create): ‘추가’ 버튼을 누르면, 별도의 Activity가 열려 이름과 전화번호를 입력받습니다. 입력 완료 후, 이 정보를 메인 Activity로 전달하여 데이터베이스에 저장하고 리스트를 즉시 갱신하도록 구현했습니다.

데이터베이스 초기화 (Delete All): 옵션 메뉴에서 ‘초기화’를 선택하면, 대화상자를 띄워 사용자에게 정말 초기화할 것인지 확인을 받습니다. ‘확인’을 누르면 데이터베이스의 모든 내용을 삭제하고 리스트도 새로고침합니다.

데이터 백업 (Export): 옵션 메뉴의 ‘백업’ 기능을 통해, 데이터베이스에 저장된 모든 이름과 전화번호를 SD카드(_sdcard) 경로에 제학번.txt 파일로 저장하는 기능을 구현했습니다.

전화 앱 연동 (Intent): 리스트의 특정 항목을 클릭하면, 해당 항목의 전화번호를 가져와 안드로이드의 기본 전화 앱으로 즉시 연결(Intent)되도록 했습니다.

수정 및 삭제 (Update/Delete): 리스트 항목을 길게 누르면(Long Click), 선택한 항목을 수정하거나 삭제할 수 있는 별도의 Activity로 이동합니다. 각 작업 시 대화상자를 통해 사용자 확인을 받도록 했으며, 완료 시 메인 Activity의 데이터베이스와 리스트에 변경 사항이 실시간으로 반영되도록 구현했습니다.

리눅스 TCP 채팅 프로그램

Wed, 26 Jun 2024 00:00:00 +0000

리눅스 시스템 프로그래밍 수업에서 배운 내용을 바탕으로 간단한 멀티-클라이언트 TCP 채팅 프로그램을 프로젝트로 구현해 보았습니다.

C언어의 소켓(Socket) 통신과 멀티스레드(pthread) 개념을 직접 적용해 볼 수 있었던 의미 있는 경험이라, 프로젝트의 구조와 핵심 동작 원리, 그리고 배운 점들을 정리해 보려고 합니다.

1. 프로젝트 개요

이 프로그램은 1개의 서버와 다수의 클라이언트가 TCP/IP 프로토콜을 기반으로 실시간 채팅을 주고받을 수 있는 간단한 콘솔(터미널) 기반 채팅방입니다.

주요 기술: C언어, TCP/IP 소켓 프로그래밍, pthread (멀티스레딩)

핵심 기능:

서버: 다수의 클라이언트 접속을 동시에 관리합니다.
브로드캐스팅: 한 클라이언트가 보낸 메시지를, 보낸 사람을 제외한 모든 접속자에게 전송합니다.
멀티 채팅: 여러 사용자가 동시에 메시지를 보내고 받을 수 있습니다.

2. 핵심 아키텍처: 어떻게 동시에?

채팅 프로그램의 핵심은 ‘어떻게 여러 명의 요청을 동시에 처리하는가’입니다. accept(), recv(), fgets() 같은 함수들은 기본적으로 ‘블로킹(Blocking)’ 방식으로 동작합니다. 즉, 자기 차례가 올 때까지 프로그램 전체를 멈추고 기다립니다.

이 문제를 해결하기 위해 멀티스레딩을 사용했습니다.

⚙️ 서버: 클라이언트마다 전담 스레드 (Thread-per-Client) 서버는 동시에 여러 클라이언트의 접속 요청과 메시지 수신을 처리해야 합니다.

메인 스레드는 accept() 함수로 클라이언트의 새로운 접속을 기다립니다.
새로운 클라이언트가 접속하면, pthread_create()를 호출해 그 클라이언트만을 전담하는 스레드(client_chat)를 하나 생성합니다.
이 전담 스레드는 recv() 함수를 통해 해당 클라이언트로부터 메시지가 올 때까지 대기합니다.
메인 스레드는 다시 accept()로 돌아가 다음 접속자를 기다립니다.

즉, ‘접속 처리’ 스레드와 ‘클라이언트별 메시지 수신’ 스레드들이 각자 독립적으로 동시에 실행됩니다.

메시지를 받으면 send_msg 함수가 모든 클라이언트 리스트(clientList)를 순회하며 메시지를 전파(브로드캐스팅)합니다.

💻 클라이언트: ‘보내는 스레드’와 ‘받는 스레드’의 분리 클라이언트 역시 큰 숙제가 있습니다. 바로 내가 메시지를 입력하는 중에도 다른 사람의 메시지를 실시간으로 받아야 한다는 것입니다.

만약 스레드가 하나라면, fgets()로 내 입력을 기다리는 동안 recv()가 실행될 수 없어 다른 사람의 메시지를 받지 못합니다.

이 문제를 해결하기 위해 클라이언트 프로그램을 2개의 스레드로 분리했습니다.

메인 스레드 (main 함수): 사용자의 키보드 입력(fgets)을 받아 서버로 전송(send)하는 ‘보내는’ 역할만 전담합니다.
수신 스레드 (receive 함수): pthread_create()로 생성되며, 오직 서버로부터 메시지를 받는(recv) ‘받는’ 역할만 전담합니다.

이렇게 두 스레드가 각자의 역할을 나눠 갖기 때문에, 내가 메시지를 한창 입력하고 있는 중에도 receive 스레드는 서버가 보낸 다른 사람의 메시지를 화면에 실시간으로 출력해줄 수 있습니다.

위에 첨부된 링크로 코드를 확인하실 수 있습니다!

소속

Tue, 24 Oct 2023 00:00:00 +0000