[병렬프로그래밍]에서 멀티스레드를 다루던 도중 레이스 컨디션 상황에 대한 언급이 나왔다. 마침 [냉장GOAT]에서 레이스 컨디션을 메인으로 다루었고, [ParkingMate]에서도 이중 예약 방지를 위해 동일한 문제를 다룬 적이 있어 이번 기회에 자세히 정리하고자 한다.

Race Condition이란?

두 개 이상의 스레드가 같은 자원에 동시에 접근할 때 실행 순서에 따라 결과가 달라지는 현상이다.

각 스레드의 코드는 틀리지 않았다. 다만 실행 순서가 보장되지 않아서 생기는 문제다.

고전적인 예시가 있다.

// 재고가 1개 남은 상황
if (stock > 0) {       // 스레드 A: 통과
                       // 스레드 B: 통과 (동시에!)
    stock--;           // 스레드 A: stock = 0
    stock--;           // 스레드 B: stock = -1 💥
}

두 스레드 모두 stock > 0을 확인하고 통과한다. 결과는 재고 -1. 현실에서는 결제는 됐는데 상품이 없는 상황이다.

어디서 터지나?

레이스 컨디션은 (확인 → 행동) 사이에 틈이 생길 때 발생한다.

냉장GOAT에서는 여러 직원이 동시에 재고를 차감하는 상황이었고, ParkingMate에서는 같은 주차 공간에 두 명이 동시에 예약을 시도하는 상황이었다.

둘 다 본질적으로 공유 자원에 대한 비원자적 연산에 관한 문제이다.

해결 전략 4계층

레이스 컨디션 해결법은 적용 범위에 따라 4가지 계층으로 나눌 수 있다.

1. 애플리케이션 레벨 (JVM 내부)

단일 서버, 스레드 간 경합을 제어한다.

synchronized

public synchronized void decreaseStock(Long id, int quantity) {
    // 한 번에 하나의 스레드만 진입
}

메서드나 블록에 synchronized 키워드를 붙여 한 번에 하나의 스레드만 접근하게 한다.

메서드 단위로 걸면 간단하지만, JVM 하나 안에서만 유효하다. 서버가 2대가 되는 순간 무용지물이다.
Atomic 클래스 (CAS)

AtomicInteger stock = new AtomicInteger(10);
stock.decrementAndGet(); // CPU 명령어 수준의 원자적 연산

AtomicInteger 등은 하드웨어 수준의 Compare-And-Swap 알고리즘을 사용하여 락(Lock) 없이 원자성을 보장한다. 성능이 좋다.

단, 주의할 점이 있다. decrementAndGet() 자체는 원자적이다. 문제는 아래처럼 확인과 행동을 분리할 때다.

if (stock.get() > 0) {        // CAS 1번째
    stock.decrementAndGet();   // CAS 2번째 ← 사이에 다른 스레드가 끼어들 수 있음
}

각 연산은 원자적이지만 CAS와 CAS 사이는 원자적이지 않다. "재고 확인 후 차감 + 주문 생성"처럼 복합 연산의 원자성은 보장하지 못한다.

2. DB 레벨 (RDB)

가장 확실하게 정합성을 보장할 수 있는 계층이다.

낙관적 락 (Optimistic Lock)

충돌이 드물다는 가정 하에 동작한다.

@Version
private Long version;

수정 시점에 내가 읽었던 버전과 현재 버전을 비교한다. 버전이 다르면 OptimisticLockException 발생 → 애플리케이션에서 재시도.

DB 락을 잡지 않아서 가볍다. 단, 충돌이 잦아질수록 재시도가 폭발적으로 늘어나 오히려 DB 부하가 커진다.
비관적 락 (Pessimistic Lock)

충돌이 잦다는 가정 하에 동작한다.

@Lock(LockModeType.PESSIMISTIC_WRITE)
Optional<Stock> findByProductId(Long productId);

SELECT FOR UPDATE로 읽는 순간부터 해당 row를 선점한다. 정합성은 강하게 보장되지만, 락 점유 시간 = DB 커넥션 점유 시간이다. 트래픽이 몰리면 HikariCP 커넥션 풀 고갈로 이어진다.

냉장GOAT에서 @Transactional을 processOrder에서 제거한 이유가 바로 이것이다. 트랜잭션이 길어질수록 커넥션을 오래 붙잡게 되고, 결국 전체가 막히게 된다.

ParkingMate 적용 사례 ParkingMate에서는 같은 문제를 다른 방향으로 풀었다. 락 범위를 줄이는 대신, 트랜잭션 안에 묶여 있던 알림 처리를 Transactional Outbox로 통째로 분리했다. 예약 트랜잭션(T1)은 booking INSERT + outbox_event INSERT만 처리하고 커밋한다. 알림은 별도 스케줄러(T2)가 나중에 처리하도록 분리했다.

실측 결과 평균 응답시간은 37ms → 36ms로 큰 변동이 없었지만, Hikari 커넥션 점유 표준편차가 5.1ms → 2.1ms로 줄었다. 절대값보다 분산 안정성이 핵심이었던 사례이다.

3. 분산 락 레벨 (다중 서버)

서버가 여러 대로 늘어나면 JVM 레벨 락은 의미가 없다. 각 서버의 synchronized는 서로를 모른다.

Redis (Redisson)

RLock lock = redissonClient.getLock("stock:lock:" + productId);
boolean acquired = lock.tryLock(5, 10, TimeUnit.SECONDS);
if (!acquired) throw new IllegalStateException("락 획득 실패");
try {
    // 임계 구역
} finally {
    lock.unlock();
}

Redisson의 RLock은 내부적으로 두 가지를 함께 사용한다.

Lua 스크립트로 "키 확인 → 세팅 → TTL 설정" 세 단계를 원자적으로 묶는다. Redis는 Lua 스크립트를 실행하는 동안 다른 명령을 일절 받지 않기 때문에 중간에 끼어드는 것이 불가능하다.

락을 못 얻은 스레드는 Pub/Sub 채널을 구독하고 대기한다. 락이 해제되면 Redis가 해당 채널에 알림을 보내고, 대기 중이던 스레드가 그때 재시도한다. 계속 폴링하지 않으니 Redis 부하가 낮다.

냉장GOAT에서 직접 적용한 방식이기도 하다.
주의할 점은 Redis 자체가 단일 장애점(SPOF)이 된다는 것. 이를 보완하기 위한 방법으로 Redlock 알고리즘이 있다. Redis 노드를 홀수 개(보통 5개)로 독립적으로 운영하고, 과반수(3개 이상)에서 락 획득에 성공하면 유효한 락으로 인정하는 방식이다. 노드 하나가 죽어도 나머지로 과반수를 충족할 수 있다.

다만 Redlock의 안전성에 대한 논쟁이 있다. Kleppmann은 GC pause 중 TTL이 만료되면 두 클라이언트가 동시에 락을 가질 수 있다고 지적했고, Redis 창시자 antirez는 이는 분산 시스템 전반의 문제이지 Redlock만의 문제가 아니라고 반박했다. 완벽한 분산 락은 없다는 것이 현재까지의 결론이다.

냉장GOAT에서는 Resilience4j 서킷 브레이커로 Redis 장애 시 fallback을 처리했다.

MySQL Named Lock

SELECT GET_LOCK('order:lock:1', 3);
-- 임계 구역
SELECT RELEASE_LOCK('order:lock:1');

별도 인프라 없이 DB만으로 분산 락을 구현할 수 있다. 단, Named Lock은 커넥션 단위로 락을 관리하기 때문에 트랜잭션용 커넥션과 락용 커넥션을 반드시 분리해야 한다. 결국 커넥션 풀을 두 배로 운영해야 하는 복잡도가 생긴다. Redis는 DB 커넥션과 완전히 독립된 시스템이라 이 문제가 없다. 프로덕션에서 Named Lock보다 Redis를 선택하는 이유다.

4. 아키텍처 레벨 (Queue)

락 자체를 없애버리는 방식이다.

요청 → Kafka → 단일 Consumer → 순차 처리

모든 요청을 큐에 쌓고, 소비자 하나가 순서대로 처리하면 동시성 문제가 원천 차단된다. 대규모 트래픽에서 처리량과 정합성을 동시에 잡는 가장 강력한 방법이다.

단, Consumer가 1개면 처리량이 병목이 된다. 실전에서는 파티셔닝 + 파티션당 1 Consumer 구조로 처리량도 확보한다.

정리

레이스 컨디션 해결의 핵심은 "어떤 락을 쓸지"가 아니라 "지금 어떤 상황인지를 먼저 정의하는 것"이다.

충돌 빈도, 서버 수, 트래픽 규모. 이 세 가지에 따라 적절한 답이 달라진다.

2편에서는 낙관적/비관적 락의 트레이드오프를 더 깊게 파고, 냉장GOAT에 실제로 적용한 구조를 함께 다룰 예정이다.

참고 : CAS(https://steady-coding.tistory.com/568#google_vignette)

위에서 언급한 ParkingMate 실측 과정

측정 방법 : BookingConnectionTimingTest.java에서 직접 측정. @SpringBootTest + @ActiveProfiles("mysqltest")로 실제 MySQL(Docker, localhost:3307)에 연결하고, TransactionTemplate으로 트랜잭션을 직접 제어하면서 System.currentTimeMillis()로 커넥션 획득부터 반납까지의 시간을 10회 반복 측정.

Before(알림을 T1에 포함): [32, 37, 51, 37, 38, 34, 38, 36, 35, 39] → 평균 37ms, 표준편차 5.1ms After(Outbox 분리): [36, 40, 34, 38, 38, 38, 34, 37, 36, 33] → 평균 36ms, 표준편차 2.1ms

인프라 이해에 대한 필요성을 느껴 네트워크, 도커, 쿠버네티스, 클라우드 등을 학습하고 대규모 트래픽 실무형 프로젝트를 진행하며 팀워크와 엔지니어적 사고를 배울 수 있었던 CloudWave 수료 후기.

why?

이전 프로젝트(INSK_V3 배포 등)를 겪으며 "서버가 죽으면 내 백엔드 코드는 동작할 수 없다"는 것을 알 수 있었다.

배포하는 과정에서 익숙치 않은 AWS, CI/CD 등을 시도하며 많은 어려움을 겪었지만, 동시에 내가 만든 코드를 클라우드에 띄워 실제 운영을 할 수 있다는 것이 신선한 충격으로 다가왔다.

코더의 역할이 점점 줄어가는 현 추세에 단순 코딩을 넘어서 SDLC를 이해하고 풀 사이클을 통제할 수 있는 능력이 중요하다고 느꼈고, 운영과 유지보수 더 나아가 '인프라를 통제할 줄 아는 백엔드 엔지니어'가 되고 싶었다.

대기업에서 여러 해 진행했던 부트캠프라 체계적인 과정 및 지원이 확실했다. 심지어 교육혜택 중 CJ올리브네트웍스 서류 가점, CJ올리브네트웍스 현직자 특강 및 멘토링 지원이 포함되어 있어 추후 취업 준비에도 큰 도움이 될 것 같았다.

사실 제일 맘에 들었던 건 AWS 기반 프로젝트 진행과 실무형 프로젝트를 통한 취업 포트폴리오 확보였다. 비용 걱정 없이 다양한 AWS 서비스들을 사용해보고 이를 활용해 실무형 프로젝트를 하게 된다면 인프라에 대한 전반적인 이해는 물론이고 기존에 목표했던 백엔드 엔지니어적 역량을 채울 수 있을 것 같았다.

지원 과정

지원 절차는 다음과 같았다. 자세히 언급한 후기들이 많기 때문에 가볍게 넘어가겠다.

• 지원서 접수
• [1차] 테스트
• [2차] 면접

면접을 대비하여 AWS 배포 과정에서 502 에러와 DB 연결 실패, GitHub Actions의 레이스 컨디션 문제를 Nginx 로그 분석과 RDS 보안 그룹 설정, CI/CD 파이프라인 개선으로 해결한 경험을 준비해갔다.

전체적으로 전문적인 역량보다 이 활동에 참여할 열정과 의지를 더 중요하게 봤던 것 같다. 면접에서도 인천 송도에서 이뤄지는 대면 과정인데 집이 먼 경우 어떻게 통학할지를 물어보셨다. (나를 비롯한 여러 수강생들은 근처에서 자취를 하며 수강했다.)

활동

주관 : CJ OliveNetworks 활동명 : 클라우드 웨이브(CLOUD WAVE) 시즌 7 기간 : 25.12.15~26.02.27

활동은 크게 3가지로 나누어졌다.

1. 교과 과정 교육
2. 현직자 특강 및 멘토링
3. 실무 프로젝트 및 발표

1. 교과 과정 교육(기본 80H, 심화 192H)

교과 과정은 약 7주 간의 과정으로 구성됐다.

1주차 : 네트워크 2주차 : 리눅스 3주차 : 도커 4주차 : 쿠버네티스 5주차 : 퍼블릭 클라우드 6주차 : Ansible 7주차 : Terraform

짧은 기간동안 많은 과정들을 이해하고 습득하기 위해 정말 열심히 공부했다. 하루 8시간 동안 진행되는 교육이 쉽진 않았지만 힘든만큼 얻을 것들이 많아보여 철저히 학습했다.

1~2 과목마다 다른 강사님(전문 강사, 타 기업 현직자)분들이 오셔서 강의를 해주셨다. 이론학습과 실습을 통한 밀도 높은 교육에 지식적으로도 도움이 되었지만, 교과목이 아닌 실무 팁, 사고체계 또한 큰 도움이 되었다.

개인적으로는, A가 B보다 더 최신 버전이고 좋은 기술이더라도 무조건 A를 선택하지는 않는다는 것에 놀랐다. 회사에 맞는 기술이 B라면 B를 선택해야 한다. 회사를 다니지 않아 이런 관점은 생각해보지 못했는데 실무에 계신 현직자분들이 강의를 해주셔서 이런 관점도 얻을 수 있어 유익했다. (그 외에도 항상 대체제, Tradeoff를 생각하기 장애가 났을 때, 어떤 일이 벌어지고 어떤 방안이 있을지를 계속 생각해기 등등)

이론적인 부분과 더 생각해보면 좋을 사고들을 분리해서 Notion에 전부 기록했고 예습, 복습에 유용하게 사용했다. 과정이 종료된 이후에도 한 번씩 복습하며 잊지 않으려고 노력했다.

중간중간 쉬는 시간에는 밖으로 나가 클라우드 센터와 주변 건물들을 보며 바람을 쐬곤 했다. 찬 바람에 기분까지 환기되어 다음 수업에 집중할 수 있었다!

또, 송도IDC 센터 견학을 할 기회가 있었다. 실제 대규모 인프라의 물리적 계층과 철저한 보안 시스템을 직접 확인할 수 있어 재밌었다. 특히 서버 랙과 쿨링 설비를 실물로 접할 수 있었던 게 인상 깊다. 하드웨어 가용성과 인프라 관리의 중요성에 CJ OliveNetworks가 얼마만큼 투자하는 지 알 수 있었다.

2. 현직자 특강 및 멘토링

특강은 기대했던 것보다 훨씬 많이 이루어졌다. (거의 20회정도) CJ OliveNetworks 현직자분들부터 외부 클라우드, 개발 현직자분들까지 다양한 분야의 전문가분들이 오셔서 강의를 해주셨다. 현직 업무와 트렌드, 그리고 신입으로서 중요한 자세들을 배울 수 있어 유익했다. 최근 몇 년 사이에 취업하신 강사님도 계셔서 클라우드/백엔드 분야 취업에 관련된 팁들도 받을 수 있어 좋았다.

3. 실무 프로젝트 및 발표

프로젝트는 약 3주간 진행되었다. 한 조에 6명씩 배정되었고, 현직 멘토님 한 분과 매칭이 되어 올리브영과 CGV 중 한 기업의 문제 상황과 관련된 프로젝트를 진행해야 했다.

교육받을 때부터 느낀 것이 있었는데, Cloud Wave에 모인 수강생들의 열의가 대단했다. 대부분의 외부 프로젝트들에선 시간이 안 맞는다거나, 개인적으로 할 일이 있다거나, 갖가지 이유로 연락이 안되는 팀원들이 많았다. 하지만 7주간 하루 8시간 동안 같이 공부하며 버틴 수강생들이 모여서 그런지 설 명절이 중간에 끼어있었음에도 팀 프로젝트에서의 단합이 아주 잘 됐다.

특히 우리 팀은 수 차례 Cloud Wave를 맡으신 강사님과 CJ임원이신 심사위원분들께도 팀워크적으로 큰 칭찬을 받은 팀이었다. (팀워크와 프로젝트에 관한 자세한 내용은 추후 포스팅 예정)

우리 팀은 "올영세일 대응 AWS 인프라 구축"을 주제로 삼았다. 시스템 신뢰성, 보안, AI를 차별점으로 설계하고 15만 동시 접속 환경에서의 부하 테스트를 통해 대규모 트래픽 감당을 검증해냈다.

마치며

10주간의 교육 기간이 정말 쏜살같이 지나갔다.

솔직히 말하면, 첫 주 수업을 마치고 남은 9주간의 일정이 정말 막막했었다. 알고 있다고 생각했던 네트워크도 낯설었고, 처음보는 쿠버네티스와 IaC 도구들은 더 낯설었다. 모니터만 바라보며 10주동안 모든 것을 쏟아내는 경험은 정말 흔치 않은 경험이었다.

그런데 프로젝트를 비롯한 모든 활동이 끝나고 나서 다시 돌아보니, 처음엔 막막했던 개념들과 버그들이 이제는 이해가 되고 말로 설명할 수 있다는 것을 알게 되어 정말 뿌듯했다.

Kafka 브로커가 죽었을 때 데이터가 유실되지 않으려면 어떻게 설계해야 하는지, 15만 명이 동시에 몰렸을 때 서버가 버티려면 Pod이 몇 초 안에 몇 개 떠야 하는지, Aurora 연결이 왜 갑자기 터졌는지를 직접 부딪히며 알게 됐다. 코드만으로는 알 수 없는 인프라 레벨에서 장애를 막는 경험이었다.

같이 밤새 Slack하고, 의도대로 작동하지 않아 에러 로그를 들여다보고 Pod와 Node를 체크하며 모니터링 수치가 잘 나오는지 확인하던 팀원들 덕분에 힘들다는 것도 잘 느끼지 못한채 즐겁게 프로젝트에 열중할 수 있었던 것 같다.
이 과정을 통해 얻고 싶던 목표가 풀 사이클 통제를 위해 운영과 유지보수 그리고 더 나아가 '인프라를 통제할 줄 아는 백엔드 엔지니어'가 되자는 것이었다.

수료를 하고 난 지금, 나는 그 방향으로 한 걸음 왔다는 것을 분명히 느낄 수 있다.

팀워크를 비롯해, 15만 VU를 감당했던 인프라 설계와 그 과정에서 마주친 트러블슈팅들은 다음 포스팅에서 구체적으로 풀어볼 예정이다. 수치도 있고, 실패도 있고, 그걸 고치는 과정도 있다.

긴 글 읽어 주신 분들께 감사하다는 말씀 드리고 싶다.😊 이어지는 글은 아래 첨부하겠다.

프로젝트 개발 중 Claude 계정 3개를 돌려쓰다가, 토큰이 아니라 내 사용 방법에 문제가 있지 않을까 의문을 가지게 되었고, 갖가지 방법들을 시도하여 성공적으로 Claude를 다루게 된 과정에 대한 기록.

Claude Code?

여러 프로젝트를 다루며 LLM을 통해 개발을 하게 되었다. 처음엔 무료 사용량이 어느 정도 제공되고 범용성이 좋은 ChatGPT, 대학생 전용 1년 무료인 Gemini를 통해 개발을 시작했다.

간단한 규모에서는 코드 짜달라고 하면 짜주고, 에러를 붙여넣으면 고쳐주는 ChatGPT, Gemini가 편리했다.

그런데 프로젝트 규모가 조금씩 커지게 되고, 파일이 여러 개로 쪼개지기 시작하며 "파일 전체 복사해서 붙여넣기 → 수정 요청 → 다시 복사해서 내 파일에 덮어쓰기"를 반복하는 과정에서 개발의 비효율성을 느끼기 시작했다.

그러다 코딩에 좋다고 소문이 난 Cursor를 접하게 되었다. 그리고 그 결과는 충격적이었다. 몇 주 동안 질질 끌던 작업들을 체험판 단 3일 만에 끝낼 수 있었다. IDE에 LLM이 통합되어, 파일 복붙 없이 코드베이스 전체를 이해한 채로 작업이 가능하다는 게 얼마나 효율적인지 느낀 뒤로 LLM이 통합된 개발 도구에 더 관심이 생겼다.

정리하자면, Cursor는 IDE에 종속되는 구조였다. VS Code 기반이라 다른 편집기와 함께 쓰기 불편했다. (자바 기반의 프로젝트를 할 때, IntelliJ를 사용했기 때문에 두 앱을 번갈아 사용해야 했다.)

반면, Claude Code는 터미널에서 돌아가니까 편집기를 가리지 않았고, 내가 컨텍스트에 무엇을 넣을지 직접 결정할 수 있었다. _(물론 더 편리한 부분과 차이점이 있었지만 이미 Claude를 글쓰기나 코딩에 이용하며 신뢰를 가진 상태였기 때문에 가볍게 살펴본 뒤 막연하게 Claude Code 또한 좋겠다고 생각하고 넘어갔다.) _

토큰 문제

그렇게 Claude Code를 쓰기 시작했고, 개발 속도는 확실히 올라갔다. 마침 CJ 올리브네트웍스 부트캠프인 CloudWave에서 프로젝트를 시작하게 되어서 개발에 유용하게 사용할 수 있었다.

그런데 문제가 생겼다. 토큰이 내 예상보다 빠르게 닳았다. 처음엔 "프로젝트를 시작하면서 처음부터 제작하기 때문에 단순히 많이 드나보다" 하고 넘겼는데, 한도 초과가 반복되고, 토큰 재사용 시간을 기다리는게 일상이 되었다.

프로젝트 마감이 가까워지면서는, 다른 작업을 하고 있는 팀원의 계정 2개를 빌려 총 3개의 계정으로 토큰을 한계까지 돌려써가면서 작업했다. A 계정 한도 차면 B로, B 차면 C로. 당시엔 그게 최선인줄로 알았다.

토큰이 너무 적다고 불평하던 와중, 문득 이런 생각이 들었다. 토큰이 문제가 아니라, 내 사용 방법이 문제 아닐까?

원인부터 찾았다

프로젝트 마감까지 시간은 촉박했기에, 막연하게 "덜 써야겠다"는 결론은 내릴 수 없었다. 토큰이 왜 이렇게 빨리 닳는지 원인을 먼저 파악해야 했다.

그리고 몇 가지 원인을 찾을 수 있었다.

첫째, 긴 대화가 누적되면 이전 대화 전체가 매 요청마다 컨텍스트로 들어간다. 채팅창을 닫지 않고 계속 이어가면, Claude는 처음부터 지금까지의 모든 대화를 매번 읽고 답한다. 대화가 길어질수록 요청 한 번에 소모되는 토큰이 기하급수적으로 늘어난다.

둘째, CLAUDE.md에 수백 줄짜리 프롬프트를 때려박으면 매 세션마다 전부 로드된다. 정성껏 작성한 지시사항이 오히려 독이 된다. 쓸 때마다 전부 토큰으로 소모되는 구조였다.

셋째, 계획 없이 구현을 요청하면 수정 반복이 발생한다. "이렇게 만들어줘 → 아 이건 아닌데 → 저렇게 바꿔줘 → 다시"를 반복하면 토큰이 2~3배로 낭비된다.

넷째, 필요 없는 파일까지 컨텍스트에 포함된다. 관련 없는 파일을 통째로 넘기면 Claude는 그걸 전부 읽는다.

토큰을 많이 쓴 게 아니라, 비효율적으로 쓰고 있었던 거였다.

Claude Code는 이미 에이전트 프레임워크다

원인을 파악하고 나서 해결책을 찾는 과정에서 중요한 사실을 하나 깨달았다.

많은 사람들이 Claude Code 위에 또 다른 제어 로직을 얹으려 한다. 복잡한 프롬프트 체인을 만들거나, 외부 스크립트로 동작을 제어하거나. 그런데 이건 이중 레이어 구조로 오히려 비효율적이다. Claude Code 자체가 이미 에이전트 프레임워크로 설계되어 있기 때문이다.

네이티브 기능만 제대로 써도 충분하다.

커스텀 레이어를 쌓는 대신, 이 구조를 따르는 것만으로도 강력한 에이전트 운영이 가능하다.

토큰을 아끼는 워크플로우

그리고 핵심적인 관점 전환이 있었다.

"코드를 잘 쓰게 만드는 것이 아니라, 코드를 쓰기 전에 무엇을 써야 하는지를 확실하게 만드는 것"

토큰 낭비의 근본 원인은 잘못된 방향으로 구현한 뒤 수정을 반복하는 것이다. 이 사이클을 끊으면 토큰은 자연히 줄어든다. 그래서 5단계 워크플로우를 정착시켰다.

Step 1 - Research

이 [폴더]를 깊이 읽고 세부 사항 파악 후 research.md에 작성해라

채팅으로 주고받지 않고 파일로 저장한다. 컨텍스트가 오염되지 않는다. "깊이", "세부 사항" 키워드가 없으면 Claude는 고수준 요약으로 끝낸다. 사전 리서치가 잘못된 구현으로 인한 수정 반복 사이클을 차단한다.

Step 2 - Plan

research.md 바탕으로 plan.md에 구현 계획 작성해라. 아직 구현하지 마.

plan.md에는 접근 방식, 코드 스니펫, 파일 경로, 트레이드오프, 체크리스트가 들어간다. Claude Code 내장 플랜 모드 대신 MD 파일을 쓰는 이유는 에디터에서 직접 편집할 수 있기 때문이다. 의사결정을 이 단계에서 완료하면 구현 중 방향 전환이 없다.

Step 3 - Review

plan.md를 에디터에서 열고 직접 주석을 단다.

<!-- PUT이 아니라 PATCH여야 함 -->
<!-- 캐싱 불필요, 제거 -->
<!-- 이 함수 시그니처 변경 불가 -->

피드백 후에는 반드시 이렇게 요청한다.

메모 반영해서 업데이트해라. 아직 구현하지 마.

"아직 구현하지 마"는 필수 문구다. 없으면 Claude는 즉시 구현을 시작한다.

Step 4 - Implement

plan.md대로 전부 구현해라.
완료 시 체크리스트 체크. 매 단계 타입 체크 실행.

이 단계에서 개발자의 역할은 설계자(Architect)에서 감독자(Supervisor)로 바뀐다. 이미 확정된 계획을 실행하는 것뿐이라 토큰 낭비 없는 직선 경로로 끝난다.

Step 5 - Refine

UI 오차가 있으면 말 대신 스크린샷을 넘긴다. 말로 설명하다 생기는 오해를 없애준다. 방향이 완전히 틀어졌다 싶으면 git reset 후 재시작한다. 반복되어 덧칠되는 수정을 반복하는 것보다 토큰도 결과물 퀄리티도 낫다.

스킬 시스템으로 반복을 없앴다

워크플로우를 정착시키고 나서 한 가지가 더 거슬렸다. 반복되는 작업마다 같은 설명을 매번 해야 한다는 것.

그래서 스킬 시스템을 구축했다.

스킬은 특정 상황에서만 로드되는 전문 매뉴얼이다. 평소엔 컨텍스트에 없다가, 관련 요청이 들어올 때만 동적으로 로드된다.

평소          → 메모리에 없음 (토큰 0 소비)
관련 요청 감지 → description 키워드 매칭 → 자동 로드

직접 구축한 구조는 이렇다.

~/.claude/skills/skill-creator/
├── SKILL.md              ← 트리거 + 핵심 요약
└── references/
    └── skill_creator.md  ← 상세 가이드 (필요 시만 로드)

"스킬 만들어줘", "스킬 검토해줘", "스킬이 안 불러와져" 같은 말이 나오면 자동으로 로드된다. 반복 작업 패턴을 스킬로 등록하면 매번 설명할 필요가 없어진다.

최종 셋업

결국 정착한 파일 구조는 이렇다.

~/.claude/
├── rules/
│   └── guidelines.md          ← 매 세션 자동 로드 (2.7KB, 61줄)
└── skills/
    └── skill-creator/
        ├── SKILL.md
        └── references/
            └── skill_creator.md

프로젝트별 작업 파일:
├── research.md                ← 코드베이스 분석 결과
├── plan.md                    ← 구현 계획 + 체크리스트
└── skill_creator.md           ← 스킬 제작 상세 전략

guidelines.md는 매 세션마다 자동으로 로드되어 프롬프트 품질을 실시간으로 진단한다.

결론

위 과정을 거친 뒤, 계정 3개로 돌려써야 겨우 가능했던 작업들을 계정 1개로 감당할 수 있었다. 또, plan.md 파일을 만들고 구현하기 시작하니까 구현 후 수정 반복이 거의 사라졌다. 같은 작업에 드는 대화 턴 수가 눈에 띄게 줄은 것을 체감할 수 있었다.

결과적으로, 3가지로 정리할 수 있었다.

확실한 구조가 토큰을 아끼는 방법이다. 잘못된 구현 후 수정 반복이 토큰의 가장 큰 낭비다. Research → Plan → Review가 이 사이클을 차단한다.

네이티브를 이기려 하지 마라. Claude Code는 이미 프레임워크다. 그 위에 중복 레이어를 쌓는 건 역효과다. 공식 구조를 따를수록 Anthropic 업데이트 혜택을 즉시 받는다.

방법론이 도구보다 오래간다. 모델이 바뀌어도 "계획 → 검증 → 실행"의 구조는 어떤 LLM에도 그대로 적용된다. GPT-5가 나오든 Gemini Ultra가 나오든 상관없다.

이번 과정을 통해 도구를 탓하기 전에 도구를 어떻게 쓰고 있는지를 먼저 봐야 한다는 것을 깨달았다.

좋은 개발자는 코드를 많이 쓰는 사람이 아니라, 잘못된 코드를 쓰지 않도록 사고하는 사람이라고 생각한다. 나는 도구를 소비하는 개발자가 아니라, 문제와 구조를 설계하는 엔지니어가 되기 위해 노력할 것이다.

이 문서는 INSK를 운영 환경에 올리면서 실제로 겪은 문제들을 정리한 기록이다. 해결 방법을 정리하기보다는, 왜 이런 문제가 발생했는지, 그리고 이 문제가 어떤 설계 전제 위에서 발생했는지를 남기는 것이 목적이다.

1. 배포는 성공했지만 서비스는 열리지 않았다 (502 Bad Gateway)

- 상황
  - CI/CD 파이프라인은 정상 종료
  - 브라우저 접근 시 `Nginx 502 Bad Gateway` 응답
  - 서버는 살아 있었지만 API는 응답하지 않았다

- 최초 판단
  - 애플리케이션 포트 매핑 오류
  - Spring Boot 프로세스 비정상 종료 가능성

- 확인 과정
  - Nginx access / error 로그 확인
  - EC2 내 애플리케이션 프로세스 상태 확인
  - Spring Boot 기동 로그 확인

- 실제 원인
  - Spring Boot가 기동 단계에서 DB 연결 실패
  - RDS 보안 그룹 인바운드에 EC2 보안 그룹이 허용되지 않음

- 해결
  - RDS 보안 그룹에 EC2 보안 그룹 ID 추가
  - DB 연결 정상화 후 애플리케이션 기동 확인

- 설계상 문제
  - 애플리케이션 오류로 단정하고 네트워크 계층을 후순위로 판단
  - “코드가 문제일 가능성이 가장 크다”는 개발자 편향이 작동

2. 배치 작업이 조용히 멈춰 있었다 (@Scheduled)

- 상황
  - 서비스는 정상 동작
  - 하지만 특정 날짜 이후 뉴스 데이터가 수집되지 않음
  - 모니터링이나 알림은 없었음

- 최초 판단
  - 외부 뉴스 API 응답 지연
  - 데이터 수집 대상 부족

- 확인 과정
  - 배치 로그 직접 확인
  - 특정 스케줄 작업 이후 로그가 더 이상 남지 않음

- 실제 원인
  - 배치 로직 중 예외 발생
  - 예외가 스케줄 스레드를 종료시켰고 이후 재실행되지 않음

- 해결
  - 예외 처리 보완
  - 실패 로그 추가

- 설계상 문제
  - 배치 작업이 항상 정상 동작한다는 전제
  - 실패를 정상 시나리오로 다루지 않음
  - 재시도, 상태 관리, 알림이 없는 구조

3. 캐시 적용 이후 데이터 정합성 문제 (Redis)

- 상황
  - 기사 점수 수정 이후에도 화면에는 이전 점수가 노출됨
  - 새로고침을 반복해야 값이 갱신됨

- 최초 판단
  - 프론트엔드 캐시 문제
  - API 응답 캐싱 문제

- 확인 과정
  - Redis 키 확인
  - 캐시 TTL 확인
  - API 호출 시 캐시 히트 여부 확인

- 실제 원인
  - 캐시 무효화 기준이 API 요청 단위로만 설계됨
  - 배치 작업에서 변경된 데이터에 대한 캐시 무효화가 누락됨

- 해결
  - TTL 단축
  - 일부 키 수동 삭제

- 설계상 문제
  - TTL을 해결책으로 착각
  - 캐시를 성능 도구로만 인식하고 일관성 리스크를 고려하지 않음

4. LLM 호출 실패로 전체 파이프라인 중단

- 상황
  - 일부 뉴스가 저장되지 않음
  - 특정 날짜 데이터가 통째로 누락

- 최초 판단
  - 뉴스 API 수집 문제
  - 데이터 파싱 오류

- 확인 과정
  - LLM 호출 로그 확인
  - OpenAI API 실패 응답 확인

- 실제 원인
  - 요약 / 분류 / 점수 계산을 하나의 흐름으로 처리
  - LLM 호출 실패 시 이후 로직 전체 중단

- 해결
  - 실패 로그 추가
  - 부분 결과 저장

- 설계상 문제
  - 외부 API를 내부 트랜잭션처럼 다룸
  - 실패를 예외 케이스로만 취급
  - 외부 의존성은 항상 실패할 수 있다는 전제 부재

5. CI/CD 배포 이후 코드가 갱신되지 않은 문제

- 상황
  - GitHub Actions 성공
  - 하지만 실제 서비스는 이전 코드 상태

- 최초 판단
  - 배포 지연
  - 서버 캐시 문제

- 확인 과정
  - Docker 이미지 태그 확인
  - 배포 시점과 이미지 빌드 시점 비교

- 실제 원인
  - Docker 이미지에 latest 태그 사용
  - 이미지 Push / Pull 타이밍 간 레이스 컨디션 발생

- 해결
  - Git Commit Hash 기반 이미지 태그 사용
  - 배포 대상 이미지 명시

- 설계상 문제
  - CI/CD에서 불변성(Immutability) 개념 미적용
  - 배포 결과를 “신뢰”하고 검증하지 않음

6. 개발 관점 트러블슈팅에서 느낀 한계

이 문제들의 공통점은 분명했다.

• 대부분의 문제는 코드 품질 문제가 아니었다

• 설계 시 암묵적으로 깔아둔 전제가 깨진 결과였다

• 실패를 고려하지 않은 구조는, 운영 환경에서 반드시 흔들렸다

이 시점에서 INSK는 “기능이 완성된 서비스”가 아니라 운영을 통해 설계 한계를 드러낸 상태에 가까웠다.

이 트러블슈팅편의 의미

이 문서는 문제 해결 자랑을 위한 기록이 아니다. 오히려 반대로, 내가 어떤 판단을 너무 쉽게 했는지를 드러내는 문서다.

그리고 이 기록들이 쌓이면서 다음 질문으로 자연스럽게 이어졌다.

“이 문제들을 계속 땜질로 해결하는 게 맞는가, 아니면 구조 자체를 다시 봐야 하는가?”

이 질문에 대한 답이 다음 INSK 개발편 3의 출발점이 된다.

INSK를 배포하기로 결정했을 때, 목표는 명확했다. “서비스처럼 보이는 결과물”이 아니라, 운영 환경에서 실제로 돌아가는 구조를 만드는 것이었다.

개발 단계에서는 로컬 환경에서 모든 기능이 정상 동작했다. 하지만 그 상태로는 이 프로젝트가 어디까지 갈 수 있는지 판단할 수 없었다. 그래서 비교적 이른 시점에 배포를 먼저 경험해보기로 했다.

배포 구조 요약

INSK의 배포 구조

- Compute

     AWS EC2 단일 인스턴스

- Database

    AWS RDS (MySQL)

- Cache

    Redis

- Web / Reverse Proxy

    Nginx

- Application

    Spring Boot (API + 배치 작업)

- 배포 방식

    Docker 기반 컨테이너화

    GitHub Actions 기반 CI/CD

배치 작업은 @Scheduled 기반으로 애플리케이션 내부에서 함께 실행되도록 구성했다. API 서버와 배치 서버를 분리하지 않은 구조였다.

이 시점에서는 빠른 배포와 단순한 운영을 우선 기준으로 삼았다.

이 구조를 선택한 이유

당시의 판단 기준은 현실적이었다.

• 하나의 인스턴스로도 충분한 트래픽 규모

• 비용을 통제할 수 있는 구조

• 배포 파이프라인을 직접 구성해보는 경험

• API와 배치 로직을 한 흐름에서 관리

특히 뉴스 수집·요약·분류 파이프라인을 “서비스 외부 작업”이 아니라 서비스 내부 책임으로 두고 싶었다. 그래서 배치 작업 역시 Spring 애플리케이션 안에 포함시켰다.

배포 구조에 깔려 있던 전제들

배포를 마친 뒤에야 이 구조가 여러 전제 위에 서 있다는 걸 인식하게 됐다.

• 서버는 쉽게 죽지 않는다

• 배치 작업은 대부분 정상 종료된다

• LLM API 호출은 거의 실패하지 않는다

• API 요청은 동시에 몰리지 않는다

• Redis는 캐시일 뿐, 없어도 치명적이지 않다

• 배포 중 트래픽은 거의 없다

이 전제들은 문서로 정리한 적도, 검증한 적도 없었다. '그럴 것이다'라는 가정 위에서 구조를 쌓아 올린 것이었다.

배포 이후 처음 마주한 현실

배포 자체는 비교적 수월하게 끝났다. CI/CD 파이프라인도 정상적으로 동작했고, 서비스는 외부에서 접근 가능했다.

하지만 운영 환경에 올린 순간부터, 개발 환경에서는 느끼지 못했던 문제들이 하나씩 드러나기 시작했다.

• 배포는 성공했지만 애플리케이션이 기동되지 않는 경우

• 배치 작업이 조용히 멈춰 있는 상태

• 캐시 적용 이후 데이터 정합성이 어긋나는 문제

• 외부 API 실패가 전체 흐름을 중단시키는 상황

이 문제들은 대부분 코드 한 줄의 버그라기보다, 구조와 전제의 문제에 가까웠다.

배포를 통해 처음 체감한 한계

이 시점에서 분명해진 사실이 하나 있었다.

이 구조는 ‘돌아가는 데에는 충분하지만’, 운영을 전제로 안전하다고 말하기에는 근거가 부족하다.

배포를 통해 알게 된 건 “어떻게 배포했는가”보다 “무엇을 당연하다고 가정하고 배포했는가”였다.

이 구조는 장애를 전제로 설계되지 않았고, 실패를 정상 흐름으로 받아들이지도 않았다.

그리고 이 문제들은 단순한 리팩토링이나 설정 수정으로 해결될 성격이 아니었다.

배포편의 위치

이 글은 배포 성공 사례를 정리하기 위한 기록이 아니다. 개발자 기준으로 세운 판단들이 운영 환경에서 어떻게 흔들리는지를 확인하기 위한 중간 정리다.

다음으로 정리할 트러블슈팅 아카이브는 이 구조에서 실제로 발생한 문제들을 사고 기록 형태로 남기는 문서가 될 것이다.

그 이후에, 이 전제들을 하나씩 부수는 재설계를 시작하겠다.

개발편 1까지의 INSK는 분명히 '돌아가는' 서비스였다. 인증이 있었고, 자동화된 뉴스 수집 파이프라인이 있었고, 배포와 캐시까지 얹혀 있었다. 겉으로 보기엔 부족함이 없어 보였다.

하지만 직접 쓰기 시작하면서, 그리고 다른 사람의 입장에서 다시 바라보면서 한 가지가 계속 걸렸다. 이 서비스는 ‘누구를 위한 서비스인가?’라는 질문에 답하지 못하고 있었다.

기능은 많았지만, 흐름은 없었다. 기술적으로 가능한 것들을 하나씩 붙여 나가다보니, 사용자가 실제로 무엇을 기대하는지는 뒤늦게 생각하고 있었다.

기능 중심 개발의 한계가 드러난 순간

가장 먼저 느낀 문제는 진입 지점이었다. 로그인을 하고 나면 사용자는 무엇을 해야 하는지 바로 알기 어려웠다. 키워드, 기사, 점수, 추천 기능은 있었지만 '왜 이게 나에게 필요한지'가 드러나지 않았다.

그제서야 지금까지의 개발은 “구현할 수 있는 것”을 기준으로 쌓아 올린 구조였고, “사용자가 어떤 순서로 이 서비스를 쓰는지”를 고려하지 않았다는 것을 깨닳았다.

그래서 방향을 바꿨다. 기존 구조 위에 기능을 더 얹는 대신, 사용자 기준으로 전부 다시 잘라보기로 했다.

다시 정의한 기준: 사용자 흐름부터

개발편2에서 가장 먼저 한 일은 기능 추가가 아니었다. “사용자가 처음 접속했을 때부터, 이 서비스를 떠날 때까지 어떤 흐름을 타야 하는가”를 다시 그리는 일이었다.

그 결과 몇 가지 원칙이 생겼다.

• 인증은 단순한 보안 기능이 아니라, 개인화의 출발점이어야 한다

• 키워드는 설정 화면이 아니라, 이 서비스의 필터 엔진이어야 한다

• 뉴스 수집과 분석은 보여주는 기능이 아니라, 뒤에서 조용히 돌아가는 엔진이어야 한다

• 점수와 추천은 설명 없이도 납득 가능한 결과여야 한다

이 기준에 맞지 않는 기능들은 과감하게 밀어냈고, 남길 기능들만 다시 설계했다.

사용자 중심으로 다시 정리된 기능들

이 과정에서 INSK는 v3.0 구조로 정리됐다. 중요한 건 “기능이 늘었다”가 아니라, 각 기능이 맡은 역할이 명확해졌다는 점이다.

사용자는 로그인과 동시에 자신의 부서와 키워드를 기준으로 개인화된 서비스를 이용할 수 있다. 키워드는 단순 입력 값으로 쓰이는 것은 아닌, 이후 모든 기사 필터링과 점수 계산의 기준이 되도록 했다. AI 기반 키워드 추천은 선택사항으로 두되, 승인 과정을 거쳐야만 실제 서비스에 반영되도록 했다. 무분별한 자동화는 오히려 신뢰를 해친다고 판단했기 때문이다.

뉴스 수집과 분석 파이프라인은 여전히 서비스의 핵심이지만, 더 이상 전면에 드러나지 않게 했다. 사용자가 “분석 버튼”을 누르지 않아도, 내부에서는 자동으로 요약·분류·중복 제거·점수 계산이 이루어진다. 이 기능은 보여주기 위한 기능에서, 쓰이기 위한 기능으로 역할이 바뀌었다.

기사 조회 역시 마찬가지다. 목록과 상세 화면에서 사용자는 점수, 요약, 인사이트를 자연스럽게 소비할 뿐, 그 점수가 어떻게 계산됐는지를 알 필요는 없다. 좋아요/싫어요와 간단한 피드백만으로도 추천 결과에 영향을 줄 수 있도록 설계했다.

부서별 Top5 기능은 이 흐름의 결과물이다. 개별 사용자의 키워드를 넘어, 조직 단위로 “지금 이 부서가 봐야 할 뉴스”를 한 번에 보여주기 위한 장치였다. 기능을 추가했다기보다, 서비스의 목적을 한 줄로 요약한 화면에 가깝다.

기능 구현 이후, 남아 있던 불안

여기까지 오고 나서야, INSK는 처음으로 “서비스처럼 보이는 형태”를 갖추게 됐다.

기능 구현을 모두 마친 뒤, 한동안은 이 구조를 그대로 두고 써봤다. 큰 문제 없이 돌아갔고, 원하는 결과도 나왔다.

LLM 호출 비용은 아직 감당 가능한 수준이었고, 트래픽도 크지 않았다. 그래서 지금 구조가 꽤 괜찮다고 생각했다.

이 시점까지는 '여기서 더 손볼 이유가 있을까' 라는 생각이 들어서 완성됐다고 판단했었다.

다만 그 판단이 실제 운영을 전제로 한 결론인지, 아니면 아직 문제가 드러나지 않았을 뿐인 상태인지는 구분하기 어려웠다.

잘 작동하는 구조였지만, 그 판단 기준이 전부 개발자 입장이었기 때문에 고려하지 못한 측면이 있을 것이라고 생각했다.

특히 불안했던 건, 중요한 결정 대부분이 경험이 아니라 가정 위에 서 있다는 점이었다.

요약과 분류는 이 정도 호출 빈도면 충분할 거라 생각했고, 동시 요청 역시 나중에 오면 그때 고민하자며 넘겨왔다. 지금 당장은 아무 일도 일어나지 않았지만, 그게 구조가 안전하다는 증거는 아니었다.

이 상태로 더 기능을 얹는 건 의미 없다고 느꼈다. 다음 단계로 가려면, 무엇을 더 만들 것인지 보다 “지금까지 당연하게 둔 전제 중 무엇이 틀렸는가”를 먼저 확인해야 했다.

그래서 다시 외부의 시선을 요청했다. 기능 설명이 아니라, 구조 전체를 놓고 실제로 이 프로젝트를 굴릴 수 있겠는지를 묻고 싶었다. SK 초청 시 만나뵙고 피드백을 받았던 개발자님께 다시 연락을 드렸다.

그리고 며칠 후 돌아온 피드백은, 내가 안정적이라고 믿고 있던 이 구조가 운영 관점에서는 아직 검증되지 않은 선택들의 집합에 가깝다는 점을 정확히 짚고 있었다.

이제 다음 단계에서는 기능을 추가하지 않고, 이 구조를 가능하게 만든 전제부터 하나씩 부숴보려 한다.

개발편 3에서 이어진다.

INSK_V3 github : https://github.com/gm-15/INSK 시연영상 : https://youtu.be/WlKGbvbxHik

프로토타입을 버리고, 처음으로 ‘서비스’를 만들겠다고 결정한 순간

SK 미래역량 프로그램 mySUNI 써니C 4기 대외활동 후기 써니C 4기 대외활동 이후 프로젝트 고도화한 과정

INSK에 대한 컨셉과 뉴스를 수집하고 요약하고 분류하는 자동화 자체는 이미 다른 형태로 만들어본 상태였다. Make 기반 자동화, 그리고 Streamlit + Python으로 빠르게 결과를 확인하는 프로토타입까지는 충분히 의미가 있었다. 하지만 그 구조는 명확했다. 혼자 돌리는 자동화 실험에 가까웠고, 누군가 실제로 쓰는 서비스를 상정한 설계는 아니었다.

INSK_V2 https://github.com/gm-15/INSK_2 현업 개발자들과의 미팅 이후, 이 한계는 더 이상 외면할 수 없게 됐다. “돌아가는 것”과 “서비스”는 완전히 다른 문제라는 지적이었고, 그 말에 동의할 수밖에 없었다. 그래서 결론을 내렸다. 기존 구조를 고도화하는 대신, 아예 엔터프라이즈 서비스를 흉내 내는 방향으로 다시 만들자고.

기술 스택을 다시 고른 이유

Spring, React, MySQL을 아무 의미 없이 선택한 것은 아니었다. 솔직히 말하면 Spring을 선택한 가장 직접적인 이유는 방학 동안 김영한 강사의 스프링 강의를 기초부터 일반까지 한 번 훑어본 상태였기 때문이다. 개념과 실습을 그저 아는 것에서 끝내고 싶지 않았고, 실제 서비스 구조에서 이 선택이 어떤 부담과 이점을 주는지 직접 겪어보고 싶었다.

다만 단순한 학습 연장으로 보이지 않게 하기 위해 기준을 명확히 잡았다.

• 계층 분리가 강제되는 구조

• 기능이 늘어날수록 수정 지점이 한 사람에게 집중되는 상황을 피하기 위해

• 인증, 트랜잭션, 보안이 기본 전제인 서버

• 사용자 개념 추가에 따라, 감당해야하는 비용 체감을 위해

React 역시 마찬가지였다. 프론트엔드 자체를 깊게 파는 것이 목적은 아니었고, 백엔드 API가 실제 사용자 화면과 연결되는 지점까지만 책임지는 역할로 두었다. 이 프로젝트에서 중심은 명확히 백엔드였다.

개인 프로젝트가 아니라, 팀 프로젝트로 만들기로 한 이유

이 프로젝트는 혼자서도 만들 수 있었지만, 일부러 팀으로 진행했다. 이유는 단순하다. 실제 서비스 개발은 항상 협업 위에서 돌아가기 때문이다.

당시 팀원들은 대부분 실질적인 개발 경험이 거의 없는 상태였다. 그래서 자연스럽게 내가 맡은 역할은 기능 구현자라기보다 아키텍처와 일정의 총괄에 가까웠다. 프론트 / 백엔드 / DB / 배포로 역할을 나누고, 나는 백엔드와 배포를 직접 맡으면서 전체 기술 방향과 진도를 관리했다.

5주 단위로 계획을 쪼갰고, 매주 화상 회의를 통해 진행 상황을 공유했다. 말로 설명하는 방식은 최대한 줄이고, 문서로 기준을 남기는 방식을 택했다. 어떻게 하면 팀이 흔들리지 않을까 고민했다.

5주 계획은 일정이 아니라 사고 방식이었다.

1주차는 기능이 아니라 뼈대를 만드는 데 집중했다. 환경 설정, Git 협업 전략, DB 스키마, 기본 아키텍처를 이 시점에 확정했다. Controller–Service–Repository 구조를 먼저 잡았고, 첫 API는 회원가입이었다. 기능의 난이도보다 중요한 건, 이 구조로 앞으로 모든 기능을 밀어붙일 수 있는지였다.

2주차부터 사용자와 직접 맞닿는 기능을 만들기 시작했다. 인증과 개인화 키워드 CRUD. 이 시점에서 Spring Security, Validation, JWT를 얹으면서 “생각보다 귀찮고 복잡하다”는 걸 체감했다. 동시에, Python으로 빠르게 만들던 시절엔 느끼지 못했던 구조의 무게도 분명히 느껴졌다.

3주차는 프로젝트의 핵심 가치였다. 기존 Python 프로젝트에서 가장 중요했던 자동 뉴스 수집과 AI 분석 파이프라인을 Spring의 @Scheduled 기반 배치 작업으로 옮겼다. 이때부터 INSK는 단순 CRUD 프로젝트가 아니라, 엔진을 가진 서비스처럼 보이기 시작했다.

4주차에는 배포와 운영을 건드렸다. Docker로 애플리케이션을 컨테이너화하고, GitHub Actions 기반 CI/CD를 구성해 AWS에 자동 배포했다. 중요한 API에는 Redis 캐시를 붙였다. JMeter 부하 테스트를 통해 캐시 적용 전(195ms)과 적용 후(70ms)의 평균 응답 속도를 측정하여 "64.1% 성능 향상"이라는 정량적 성과를 얻을 수 있었다. 성능 최적화라는 말을 처음으로 “경험”이라고 부를 수 있는 지점이었다. 이 부분의 고민은 이전에 따로 정리한 글로 대신한다.

5주차는 코드가 아니라 설명을 다듬는 시간이었다. README를 단순한 사용법 문서가 아니라, 기술 선택의 근거를 설명하는 문서로 다시 썼다. 아키텍처 다이어그램을 정리하고, 예상 면접 질문을 뽑으면서 스스로에게 "why?"를 계속 물었다

AWS 배포 구조

우리의 초기 목표는 인프라보다 백엔드 설계와 데이터 흐름에 집중하자는 것이었기에, 직접 EC2 + ASG + ALB를 다 구성하지 않고도 배포, 롤백, 환경변수 관리, 헬스체크를 한 번에 처리하기 위해서 EB를 사용했다.

/articles/{id}/feedbacks /articles /admin/*

이런 REST API들을 확장 가능 구조로 만들어서 HTTPS 종단이나 향후 다중 인스턴스를 대비하고, 헬스체크 기반 트래픽 분산을 챙기기 위한 것이었다.

가장 중요하게 둔 것은 RDS를 분리하는 것이었다. EB 환경 종료가 데이터 삭제로 이어지면 안됐기에 환경 외부 자원인 RDS를 사용해 분리했다. *비용 때문에 환경을 내려도 데이터는 살아있다는게 좋았다. *

결과적으로 이번 배포 구성은 Elastic Beanstalk 기반의 관리형 배포 환경 위에서 Spring Boot 백엔드를 운영하고, 데이터는 RDS로 분리해 환경 종료에도 안전하도록 설계한 것이다.

이후 피드백 기반 기능 확장과 재설계를 고려한 부분도 있었다.

INSK_V2 구현 화면

여기까지의 INSK는 분명히 “돌아가는 서비스”였다.

이미 “돌아가는 것과 서비스는 다르다” 는 지적을 인지한 상태였지만, 엔터프라이즈 서비스를 흉내내는 데 집중한 나머지 익숙하지 않은 기술 스택과 기능 구현 자체가 목적이 되어 있었다.

그 결과, 사용자 흐름과 서비스 관점에서 정말 중요한 질문들은 구현 뒤로 밀려나 있었다.

이걸 깨달았다는 사실 자체가, 다음 단계로 넘어갈 수 있었던 이유였다. 개발편 1은 여기까지다.

다음 편, INSK 개발편2에서는 구조를 전면 개편하면서 사용자 측면에서 어떻게 새로 구성했는지를 다룬다.

Redis vs Memcached

INSK를 만들면서 처음으로 “캐시”를 진지하게 고민하게 됐다. 데이터가 많아지고 기능이 늘어나면서, DB만으로는 점점 부담이 커졌기 때문이다.

그래서 자연스럽게 이런 질문이 생겼다.

"캐시를 쓰자. 그런데 어떤 캐시를 쓰지?"

Memcached? 아니면 Redis? 막연하게 “Redis가 더 유명하니까” 같은 기준이 대신, 우리 프로젝트의 특징과 미래 확장까지 함께 고려해보면서 정리해 보았다.

캐시는 왜 필요한가

웹 서비스 구조를 보면, 캐시는 결국 속도를 위한 계층이다.

요청이 들어올 때 항상 DB까지 내려가면 느려질 수밖에 없다. 자주 조회되지만 매 순간 최신일 필요는 없는 데이터라면, 메모리에 저장해 놓고 빠르게 꺼내 쓰는 것이 훨씬 효율적이다.

그래서 캐시는 보통 이렇게 이용된다.

사용자 요청
캐시에서 먼저 확인
(없으면) DB 조회
결과를 캐시에 저장

이 단순한 구조 하나로 서비스 체감 속도는 크게 달라진다.

!캐시는 동일하거나 자주 반복되는 요청에 대해 DB 대신 빠르게 응답하기 위해 사용된다. 다만, 캐시는 한 번 저장된 값을 일정 시간 그대로 유지하기 때문에, 시점에 따라 값이 달라지는 데이터에는 만료 전략이나 무효화(캐시 삭제) 설계가 필요하다.

Memcached

Memcached는 아주 단순한 캐시 서버다.

메모리 기반 key-value만 저장 영속성 없음 구조가 직관적이고 빠름

즉, 단순 조회 캐시에 정말 적합하다.

예를 들면,

메인 화면에 노출되는 데이터 자주 바뀌지 않는 목록 자주 조회되지만 중요도가 낮은 정보

우리 프로젝트인 INSK는 AI 기반 뉴스 트렌드 센싱을 하는 서비스이다. 뉴스 같은 경우, 속도가 아주 중요하다거나 정확한 최신 데이터가 아니어도 된다면 Memcached만으로도 충분히 운영할 수 있다는 얘기가 많다.

실제로 맞는 말이다.

하지만, 곧바로 “우리 서비스에도 충분하다”라고 보기엔 애매했다.

조금 다른 방향의 도구 Redis

Redis를 공부하고 프로젝트 'INSK'와 '냉장Goat'등에 적용하며 느낀 점은, Redis가 단순 캐시라기보다 “메모리 기반 데이터 저장소”에 가깝다는 것이다.

문자열뿐 아니라 리스트, 집합, 정렬된 집합, 해시, 큐, 카운터 등 여러 구조를 다룰 수 있고, 필요하면 데이터 일부를 디스크에 남길 수도 있다.

그래서 세션 관리, 랭킹, 분산락, 메시지 큐 비슷한 역할까지 맡을 수 있다.

단순히 “빠르다”를 넘어서, 서비스 전체 구조에 자연스럽게 녹일 수 있는 도구였다.

우리 프로젝트에서 실제로 고민했던 지점들

INSK는 단순한 뉴스 열람 서비스가 아니다. 다음과 같은 기능을 갖춘 뉴스 트렌드 센싱 자동화 플랫폼이다.

키워드 기반 자동 뉴스 수집 AI 요약과 인사이트 분석 중복 기사 판정 좋아요/싫어요 피드백 기사 점수 계산 부서별 TOP5 추천 PDF 보고서 생성

이 흐름을 만들다 보니, 캐시가 단순 조회에서 끝나지 않았다.

점수 랭킹이 필요했고, 파이프라인 중복 실행을 막아야 했고, 나중에 세션/토큰 관리까지 고려해야 했다.

여기서 Memcached는 기능적으로 한계가 있었고, Redis는 이미 잘 알려진 패턴이 많았다.

특히 점수와 랭킹이 결정적이었다.

기사 점수는 계속 변한다. 추천 결과도 계속 변한다.

이걸 모두 DB만으로 처리하려고 하면 부하가 크다.

Redis의 정렬된 집합 구조를 사용하면,

점수를 기준으로 정렬 상위 N개 즉시 조회

이런 기능을 자연스럽게 만들 수 있었다.

이 지점에서 “Redis가 필요하겠다”라는 그림이 어느 정도 확정됐다.

Cloud Wave 이후

Redis vs Kafka

캐시를 고민하다 보니, 자연스럽게 “캐시로 감당하면 안 되는 데이터는 어디로 가야 하는가”라는 질문이 생겼다.

CJ올리브네트웍스 부트캠프 Cloud Wave 도커 강의에서 들은 내용이 특히 인상 깊었다.

Redis는 메모리 기반이라 빠르지만, 기본적으로 “사라져도 되는 데이터”에 어울린다. Kafka는 디스크 기반이라 상대적으로 느리지만, 데이터를 다시 읽고 재처리할 수 있다.

결국 기준은 단순하다.

이 데이터가 사라져도 되는가? 아니면 반드시 남아 있어야 하는가?

캐시는 사라져도 큰 문제가 없어야 한다. 하지만 로그, 이벤트 흐름, 결제 내역 같은 것들은 사라지면 안 된다.

'장애 상황'

Elastic Beanstalk 서버가 죽을 수도 있다. 문제는 여기서 끝이 아니다.

서버가 죽으면, 그 순간 무슨 일이 발생했는지 기록조차 남지 않는다.

그래서 실무에서는 애플리케이션 안에 로그를 두지 않고, Kafka 같은 큐 시스템으로 로그를 외부에 모아 둔다.

서버가 죽어도 로그는 남는다. 재처리도 가능하다.

이걸 보며 알게 되었다.

“잘 동작하게 만드는 것”보다 “망가졌을 때 추적 가능하게 만드는 것”이 훨씬 중요할 때가 많다는 것.

Trade-off

빠를수록 좋은 것도 아니고, 안전할수록 좋은 것도 아니다.

비용, 운영 난이도, 유지보수, 확장성.

이 모든 걸 놓고 판단해야 한다.

상사가 1초마다 새 일을 던지면 결국 아무 것도 못하듯, 시스템도 한 곳에 책임을 몰아주면 결국 무너진다.

그래서 역할을 나누고, 필요하면 다른 계층으로 빼는 것이다.

컨테이너, 볼륨, 쿠버네티스까지

실습 중 네트워크 설정을 바꾸려고 컨테이너를 내렸다가 올렸는데 로그가 모두 사라진 경험이 있었다.

그때 볼륨의 중요성을 체감할 수 있었다.

컨테이너는 언제든 삭제될 수 있는 존재다. 데이터는 컨테이너 바깥에 두어야 한다.

쿠버네티스도 같은 맥락이었다.

장애가 나면 자동으로 다시 띄우고, 트래픽이 증가하면 자동으로 늘리고, 배포 과정에서 서비스가 멈추지 않게 제어한다.

이 모든 것이 결국 “살아남도록 설계하는 일”이었다.

프록시를 이용한 인증 분리

DB 비밀번호, API 키 같은 민감 정보는 애플리케이션이 직접 들고 있지 않도록 프록시에서 처리한다.

이렇게 되면,

키 공유 문제, 비밀번호 변경, 타팀 협업 이슈가 훨씬 단순해진다.

https://docs.cloud.google.com/sql/docs/mysql/connect-auth-proxy?hl=ko 구글 Cloud SQL Proxy 문서를 보면서, AWS는 방식이 다르지만 목적은 동일하다는 것도 이해됐다.

인증은 가능한 한 애플리케이션 바깥으로 빼는 게 중요하다.

이번 프로젝트를 통해 느낀 점

처음엔 그냥 “Redis vs Memcached” 정도의 고민이었다.

하지만 점점 커지더니 이렇게 확장되었다.

캐시 → 영속 메시지 큐 → 장애 상황 → 로그 수집 → 인프라 안정성 → 컨테이너와 쿠버네티스 → 프록시 인증 구조

도구 하나 선택하던 문제에서, “시스템 전체를 어떻게 설계할 것인가”로 바뀌었다.

INSK 프로젝트에서 Redis를 쓰면서 배운 건 단순했다.

기술은 기능으로만 선택하면 안 되고, “이 서비스가 앞으로 어떻게 커질지”까지 보고 선택해야 한다는 것.

그리고 장애, 데이터 유실, 확장, 운영이라는 현실적인 문제 앞에서 도구의 의미가 완전히 달라진다는 것.

개발이 단순 기능 구현에서, 엔지니어링으로 넘어가는 지점이었다.

데이터 분석과 머신러닝의 기초를 다졌던 SK AI Dream Camp, 그리고 이를 바탕으로 인공지능의 깊이를 더한 상명대학교 전공심화 심층학습.
두 과정을 통해

“데이터가 어떻게 가치 있는 정보가 되고, 실제 서비스에 적용되는지”

를 단계적으로 이해할 수 있었다. 이 글은 그 여정을 정리한 기록이다.

SK AI Dream Camp

지원동기

구분 : 📋수료 항목 : SK AI Dream Camp (초급) 주관기관 : SK mySUNI 기간 : 25.07.01~08.14

이번 여름, SK AI Dream Camp에 대한 공지가 올라왔다.

파이썬은 교내 프로젝트와 알고리즘 코딩 테스트 등으로 많이 다뤄봤지만, 데이터 분석과 머신러닝은 아직 다룬 경험이 없어서 이 교육이 AI에 입문하는데 큰 도움이 될 것 같았다. 중,고급반은 실제 데이터를 다룰 수 있는 숙련도가 필요해서 아쉽지만 초급으로 시작하게 되었다.

학습과정

지원 후 과목을 살펴보니

데이터 분석 -> 머신러닝 -> AI경연(SK텔레콤 LTE 기지국 장비의 성능 상태 예측) 으로 앞선 과목을 수강해야 다음 과목이 수강 가능한 방식이었다.

수강시작까지 기간이 조금 남아서 pandas, numpy, series, dataframe등에 관해 미리 학습했다.

데이터 분석

pandas numpy 기반으로 series, dataframe을 기본적인 파이썬으로 배우고 실습하는 과정이었다. 사전에 미리 학습했기에 크게 어려운 부분은 없었다.

이런식으로 문제가 주어지고 빈칸에 코드를 작성하고 실행해서 원하는 결과가 나오면 넘어가는 식이었다.

시각화에 대해서도 배웠다. 통계나 그래프를 위해 seaborn을 사용했다. matplotlib으로도 가능하지만

• 쉬운 사용성 (1줄 완성 그래프)
• seaborn 에서만 제공되는 통계 기반 plot
• 아름다운 스타일링
• Pandas의 데이터프레임과 높은 호환성

이런 특징이 있어 seaborn을 사용한다고 했다.

다양한 map이나 plot들에 대해서도 다뤄보았다.

머신러닝

지도/비지도 학습과 같은 학습 방법, 회귀/분류나 군집/차원 축소 같은 문제 유형과 머신러닝 모델들에 관해 배웠다.

특히 인상 깊었던 것은 단순히 모델을 돌리는 것이 아니라, 데이터 준비 → 학습 → 평가 → 제출 까지 이어지는 End-to-End 프로세스를 정립했던 것이었다.

머신러닝 프로세스

1) 결측치 처리 2) 데이터 전처리(모두 숫자형으로) 3) Feature Engineering 4) 주요 특성 선택 및 제거 5) 학습을 위해 데이터 분리(X,Y 분리) 6) 레이블에 따른 모델 선정 7) 모델 학습 8) 모델 평가 9) 예측 데이터 추론 10) 결과 제출

보이는 문제에만 집중하는 그리디한 개발자와 전체 프로세스를 알고 설계하는 개발자는 다를 수 밖에 없겠다는 생각이 들었다.

분류/회귀/군집 개념에 대해서도 명확하게 이해할 수 있었다.

분류 : 정답이 범주일 때 회귀 : 값이 연속일 때 군집 : 정답 없이 비슷한 것끼리 묶기

학습 방법과 문제 유형, 그리고 머신 러닝 모델에 따라 머신러닝 문제 유형이 나뉜다는 것을 알 수 있었다.

또한 비지도 학습의 대표적인 알고리즘인 K-Means를 통해 정답(Label)이 없는 데이터들을 거리 기반으로 군집화(Clustering)하여 숨겨진 패턴을 찾는 방법도 실습해 볼 수 있었다.

학습 후

모든 과정이 마무리되고, 수료증을 발급 받았다.

수료증은 발급받았지만, 가볍게 기본 개념을 배운 느낌이라 그 다음이 없어서 아쉬웠다.

그러나 학교 전공과목에서 그 아쉬움을 달랠 수 있는 과목을 발견했다. 바로 전공 심화 과목인 '심층학습'이다.

심층학습

SK AI Dream Camp가 머신러닝의 '전체 숲'을 보는 과정이었다면, 심층학습은 그 숲속에 있는 '거대한 나무'들의 내부 구조를 파헤치는 시간이었다.

기존 머신러닝(ML)으로는 해결하기 어려웠던 비정형 데이터(이미지, 텍스트, 시계열) 처리를 위해, 심층 신경망(DNN)이 어떻게 발전해 왔는지 단계별로 학습했다.

CNN (합성곱 신경망)

기존 ML에서는 사람이 직접 특징을 설계해야 했다.

CNN은:

Convolution + Pooling 을 통해 스스로 중요한 특징을 학습한다.

Stride / Padding 등을 수식으로 계산하며, LeNet-5, ResNet (Skip Connection으로 기울기 소실 해결) 같은 구조를 이해할 수 있었다.

이를 통해 Feature Engineering이 모델 내부로 들어왔다는 것을 알 수 있었다.

별개로, AlexNet의 핵심 3요소인 GPU, ReLu, Dropout에서 Dropout의 역할이 과적합 방지인 이유가 기억에 남는다. -서브 네트워크를 만들어서 앙상블 효과를 만들기 때문. -뉴런을 확률적으로 끄기 때문에 뉴런 자체의 역할을 강건하게 함.

서브 네트워크 개념을 떠올리지는 못했었는데 교수님의 설명을 듣고 놀랐던 기억이 난다.

시계열 & NLP

SK 캠프 경연 주제였던 '시계열 예측'을 심층학습에서는 훨씬 정교한 모델로 다루었다.

시계열 데이터를 처리하는 RNN은 데이터 길이가 길어지면 앞의 내용을 까먹는(장기 의존성 문제) 치명적인 단점이 있다.

이를 해결하기 위해 망각(Forget), 입력(Input), 출력(Output) 게이트를 도입한 LSTM 구조를 상세히 뜯어보았다.

Transformer는 현재 자연어 처리(NLP)의 표준이 된 모델이다. 순차적으로 처리하는 RNN의 한계를 넘어, Self-Attention($Attention(Q, K, V)$) 메커니즘을 통해 문장 전체의 문맥을 한 번에 병렬로 파악하는 원리를 학습했다.

생성 모델

VAE: 확률 분포 기반 생성

GAN: 생성자와 판별자의 경쟁

단순 분류를 넘어서, 모델이 새로운 데이터를 창조할 수 있다는 점이 인상적이었다.

SK AI Dream Camp와 심층학습 수강 후

Dream Camp를 먼저 듣고 심층학습을 배우니,

*왜 이 기술이 필요한가? * 가 분명해졌다.

🔗 연결 1 — Feature Engineering → 자동화 Dream Camp: 내가 직접 변수 고민 Deep Learning: 필터가 자동으로 특징 학습

🔗 연결 2 — 시계열 이해 Dream Camp: 회귀/통계 위주 접근 Deep Learning: RNN/LSTM/Attention으로 순서와 상태를 보존

🔗 연결 3 — Transfer Learning Pre-trained 모델을 가져와 미세조정 현실적인 데이터 부족 문제 해결

마치며

Dream Camp는 Workflow를, 심층학습은 엔진 내부 구조를 이해하게 해 주었다.

*데이터 파이프라인 이해 모델 구조와 연산 비용 감각 클라우드 환경에서 AI를 다루는 시야 *

ML 프로세스를 직접 구현해 봄으로써, 데이터 수집부터 전처리, 학습, 추론으로 이어지는 MLOps 파이프라인의 구조를 이해하게 되었다.

또한 CNN, Transformer 등 거대 모델의 연산 비용과 구조를 이해함으로써, 향후 클라우드 환경에서 GPU 리소스 할당이나 모델 서빙(Serving) 아키텍처를 설계할 때 더 효율적인 의사결정을 할 수 있을 것이다.

앞으로는 실제 서비스에 AI를 연동하고, 클라우드 환경에서 안정적으로 운영하는 경험을 쌓으며 AI를 이해하는 백엔드 엔지니어로 성장하고자 한다.

후기는 써니C 프로젝트 1(make 및 대외활동 기록) 써니C 프로젝트 2(python과 스트림릿) 써니C 프로젝트 3(엔터프라이즈급 아키텍처 구성 및 개발) 써니C 프로젝트 4(실무자 피드백 기반 추가 개발) 으로 예정되어 있다.

주관 : SK mySUNI 활동명 : 써니C 4기 'AI로 일하는 방식 혁신' 프로젝트 기간: 25.07.21~08.21

지원동기

이번 여름, SK mySUNI에서 주관하는 SK의 대외활동 mySUNI 써니C 4기에 참여하게 되었다.

보자마자 지원하기로 결정했다. 이유는 두 가지였다.

1. 써니C 지원 경험
2. AI

작년 여름, 써니C에 3기에 지원했다가 최종에서 떨어졌었다. 비록 떨어졌지만 최종 단계까지 준비하면서 써니C 활동이 충분히 매력적이라는 것을 느낄 수 있었다. 실무 경험과 프로젝트가 매력적으로 보였기 때문이다.

그런데 이번엔 프로그램이 조금 달라져있었다. 기본적으로 기초 미래역량 교육과 실무 프로젝트는 동일했지만, 이번엔 AI가 주요 키워드로 들어가있었다.

<'직무 X AI프로젝트'를 통한 '일 경험'> <'AI Tool'>

이제 대외활동까지 AI가 머리를 내밀기 시작했다. 백엔드 개발자, 클라우드 엔지니어가 되고 싶은 나에게 AI 사용 경험은 선택이 아닌 필수였기 때문에 이번 프로그램이 더욱 매력적으로 느껴졌다.

이전 지원 경험을 살려 이번 활동에 꼭 참가하고 싶다고 생각했다.

지원과정

3기 때는 합격자에게만 교육이 제공되었지만 4기 때는 지원 -> 교육 -> 합격순으로 진행되었다.

사전학습

사전 학습 과목은 사진과 같았다.

지원서 제출 전까지 과목들을 이수해야 한다. 이수하면 이수증도 발급된다.

SK그룹원들에게 제공되는 강의라 그런지 강의 퀄리티는 전체적으로 높았다. 특히 AI 리터러시 생성형 AI의 이해와 전망: 2025 AI Keywords 과정은 들으면서 박수칠 정도로 유익했다. 김지현 CIO님이 강의를 해주셨는데 LMM, LAM, 온디바이스 AI, AI 에이전트에 대해 알기 쉽게 설명해주셔서 현재의 LLM 기술이 왜 중요한 지, 앞으로 어떤 게 중요한 지 단번에 알 수 있었다. 강의에서 다뤘던 ChatGPT의 플랫폼화가 글을 적는 지금 실제로 상용화됐는데 6개월이 전에 학습한 강의임에도 기억이 나서 기뻤다.

그 외에도 프롬프트 엔지니어링이나 문제해결 과목도 큰 도움이 되었다. 교육 이후 문제해결 방식을 이용해서 LLM 사용법을 나에게 적용하고 심지어는 남에게 알려주기도 했다.

지원서에 사전 학습 과정과 연관된 질문이 나오기 때문에 자신과 맞지 않는 과목이더라도 처음 학습 시 제대로 학습하는 걸 추천한다. 나중에 다른 학생들 얘기 들어보니 대충 들어서 여러 번 다시 듣느라 더 힘들었다고 했다.

지원문항

지원 문항은 다음과 같았다.

지원 동기는 써니C 프로그램에서 자신에게 가장 필요한 부분을 살려서 작성하면 좋다.

이 부분이 사전학습과 관련된 문항이다. 써니C는 '일 경험'을 중요하게 여기는 활동이다. 사는 곳도, 전공도 다른 사람들과 같이 프로젝트를 진행하려면 커뮤니케이션이 정말 중요하다. 일에서는 더 중요하다. 그렇기 때문에 사전학습부터 관련 교육을 제공하고 지원문항까지 작성하게 하는 것 같다. 나는 고등학교 때, 컴퓨터 동아리 폐부 위기를 마주하고 부장을 맡아 극복했던 과정을 작성했다. 대니얼 코일의 '최고의 팀은 무엇이 다른가'를 읽고 소속 신호의 중요성을 깨달아 '존중'을 바탕으로 새로운 부원들을 뽑고, 동아리의 전반적인 체계를 구성해나갔다. 결국 연말 교내 축제에서 수상까지 할 수 있었는데, 이 경험이 문항에서 요구하는 부분을 잘 보여줄 수 있을 것 같아 작성했다.

이번 활동은 AI Tool을 사용하여 프로젝트를 진행하기 때문에 AI에 관한 문항이 있을 거라고 예상했는데 역시 있었다. 나는 AI기반 유휴 주차공간 매칭 서비스 ParkingMate를 구상하고 있었기 때문에 사전학습 과정과 엮어서 이렇게 작성했다.

OT

역시 대감집 대외활동이라 그런지 OT 장소가 엄청났다. OT는 워커힐 WAVEHILL에서 진행됐다. 원래 SK 임직원분들이 워크숍할 때 이용하시는 장소인데 우리를 위해 장소를 마련해주셨다..! 오티가 시작되고 이수 기준, 프로그램 진행 계획, 4기 혜택 등의 소식들을 전해주셨다. 출결 기준은 조금 엄격한 편이었다. 써니C 기간동안 매일 출석해야 되기 때문에 해당 기간에 다른 활동이나 일정과의 병행은 어려운 편이므로 참고 바란다.
프로젝트 진행 단계와 평가 기준도 안내되었는데, 해당 기준들은 프로젝트를 진행하고 발표 준비를 할 때 키 포인트로 삼았다. 팀과 주제가 정해진 뒤로는 간단한 아이스 브레이킹 및 팀 이름, 팀 방향성을 잡는 시간을 가졌다. 사진 속 리스트의 강점 3가지를 골라 자신의 이름과 함께 소개하는 시간을 가졌다. 키워드가 꽤 세세하고 다양해서 팀원들의 성향을 파악하는데 도움이 되었다.

OT가 종료된 후, 4기 키트를 받았다. 우리 기수는 작은 캐리어와 에코백, 텀블러, 컵과 필기도구, 써니C 인형 등을 받았다. 작은 캐리어는 다뤄본 적이 없었는데 색감이 이뻐서 만족스러웠다.

활동

프로젝트는 써니C측에서 Sk그룹의 현업자분들께 업무 중 생긴 불편한 점이나 어려운 부분을 미리 받아 주제로 선정하고 이를 우리가 AI Tool을 통해 해결해나가는 방식이었다.

주제를 제출해주신 멘토님과 한 팀씩 매칭되고 매주 방향성을 잡아가며 프로젝트를 제작하는 과정이다. 매주 멘토링과 AI 코칭이 진행되었다. AI 코치님들은 외부에서 오신 분들이었는데 한 분당 3팀 정도 코칭을 해주신 것 같다.

참고로 설문을 매 시간마다 진행하는데 이때 궁금한 점이나 프로젝트 진행 중 어려운 점을 적으면 바로 다음 시간에 반영을 해주신다. 프로젝트에 집중할 수 있게 빠른 피드백과 친절한 태도로 직원분들이 신경 써주셔서 활동 내내 관리받고있다는 느낌이 들었다.

활동이후

프로젝트에 집중하며 매일 같이 회의, 활동을 하다보니 어느덧 8월이 훌쩍 지나가버렸다. 이번 활동에서는 지난 해커톤의 경험을 바탕으로 팀원들과의 소통과 유대를 신경쓰려고 노력했다. 팀원들의 전공이 컴퓨터쪽이 아니라서 개발 경험은 내가 제일 많은 편이었지만, 코딩 경험이 없더라도 소통이나 팀워크적 면에서 뛰어난 팀원들이 많아서 많은 것을 느끼고 배울 수 있었다. 아무래도 열심히 노력하는 친구들이 대외활동에 참여하다보니 모두가 강점을 하나씩은 가지고 있는 듯 했다.

활동 이후, Sk 현직자님이 추가적인 개발을 원하셨다. 대외활동에서 진행한 활동은 특정 AI Tool을 이용했기 때문에 비용 문제나 비효율적인 면이 존재했다. 그래서 1차적으로 MAKE로 제작한 우리 프로젝트를 Python+Streamlit으로 개발했다.

MAKE로 제작한 프로젝트 시연 영상

SK에 초청 받기도 했다. 기존 대외활동에서 진행한 우리 프로젝트의 구상단계, 문제점 해결 기준 등을 설명드리고 Python+Streamlit으로 개발한 INSK_V2 또한 시연했다. 감사하게도 Sk 개발자 두 분이 참석해주셔서 우리 프로젝트에 대해 많은 피드백과 조언을 주셨다. 엔터프라이즈급 프로젝트로의 발전을 위해 갖춰야 할 것들, 기술 스택들, 학업 조언등을 주셔서 앞으로의 계획을 쉽게 세울 수 있었다.

마치며

많은 대외활동을 참여해보지는 않았지만 써니C 활동은 확실히 알찬 활동이라는 것을 알 수 있었다. 성대한 OT와 엄청난 키트로 처음부터 동기부여를 얻고, 훌륭한 기초 강의를 시작으로 현업자분들의 실무 팁과 AI 팁들을 받으며 프로젝트를 진행하다보면 어느새 성장한 자신을 발견할 수 있을 것이다. 개인적으로는 추후 개발자님과의 미팅으로 써니C가 강조하는 '일 경험'까지 경험할 수 있어서 정말 만족스러웠다.

프로젝트에 관한 기술적인 부분은 이어지는 시리즈에서 포스팅할 계획이다.

기술의 성지, 실리콘밸리 엔지니어들의 생각과 철학

'실리콘밸리?'

해외연수 이전, 나에게 실리콘밸리는 막연히 '거대 IT 기업이 모여있는 IT업계의 성지'였다. 하지만 일주일간의 해외연수가 끝나고 느낀 것은 사뭇 달랐다. 이곳은 단순히 테크 회사들이 모인 곳이 아니라, 세상의 문제를 기술로 해결하려는 사람들의 열정이 모여 폭발하는 용광로였다.

어디서도 듣기 힘든 실리콘밸리 현직 개발자들의 생생한 고민과 철학을 직접 들으며, '좋은 개발자'로 성장하기 위한 구체적인 이정표를 발견할 수 있었다. 이 글은 그 치열했던 일주일간의 배움과 성장에 대한 기록이다.

기업 탐방

1. Onehouse: 스타트업의 속도와 기술적 깊이의 균형

Apache Hudi 기반 데이터 레이크하우스 Onehouse에서 이용균님은 "필요한 것만 빠르게 학습하고 즉시 적용하는 실용성"과 "LeetCode, CS 지식의 탄탄한 기본기"를 동시에 강조하셨다. 이를 통해 속도와 안정성, 두 마리 토끼를 모두 잡아야 하는 현대 백엔드 개발의 현실을 체감할 수 있었다.

2. Databricks: 빅데이터 시대, 본질에 집중하는 학습법

"목표를 세워 부딪히며 만드는 경험"과 "프로그래밍 언어의 근본적인 특징 파악"을 강조하신 이문수 개발자님의 조언은, 기술의 홍수 속에서 길을 잃지 않는 법이 되었다. 기술의 트렌드를 쫓기보다, 그 근본 원리를 이해하는 것이 얼마나 중요한지 깨닫게 되었다.

3. Google: 대규모 시스템의 보이지 않는 디테일, 성능 최적화

Android 유튜브 앱 성능 관리 담당자 이재일님과의 대화는 충격이었다.

"수많은 안드로이드 기기의 성능 편차로 인해 사용자들이 IOS로 이동한다. 사용자가 안드로이드도 쾌적하다고 느끼게 하기 위해 성능을 계속해서 안정시키는 중이다. 현재는 최적화를 할 수 있는 만큼 해서 더 성능을 향상시키려면 플랫폼쪽을 건드려야 해 플랫폼 부서와 마찰도 일어난다."

기기 성능의 편차가 실질적인 사용자 이탈로 이어지는 상황에 대해 듣고, 백엔드 개발자에게 API 응답 속도 1ms를 줄이는 노력이 어떤 의미를 갖는지 생각해볼 수 있었다. 기술의 깊이는 보이지 않는 곳에서 발현된다는 것을 느꼈고, 백엔드의 매력을 실감할 수 있었다. 추후 내가 진행할 프로젝트에서 이런 문제를 다뤄보고 싶다고 생각했다.

4. Microsoft: 창의적 활동이 미치는 영향

심재은님의 안내에 따라 개발자들이 본업 외에도 창의적인 프로젝트를 수행하는 "Garage" 프로그램 현장을 방문할 수 있었다. 최신 장비 및 기술적 지원을 활용하여 단순한 연구 및 개발뿐만 아니라, 팀원들과 함께 보드게임을 즐기거나, 레이저 커팅, 3D 프린팅과 같은 다양한 기술을 시도해 볼 수 있었다.

개발자들이 샤워하다가 업무시간엔 풀리지 않던 문제를 무의식으로 풀곤 한다고 들은 적이 있다. 이곳에서 휴식을 취하며 다양한 활동들을 하다보면, 리프레시 되어 새로운 관점에서 문제를 해결할 수 있겠다는 생각이 들었다. 개발자들이 자율적이고 창의적으로 성장할 수 있도록 도와주는 프로그램 또한 중요하다는 것을 알 수 있었다.

5. Meta: 선 빠른 개발, 후 지속적 개선

메타는 빠른 개발과 지속적인 개선을 중요하게 생각한다는 것을 장예원 개발자님을 통해 알 수 있었다.

• 완벽한 코드보다는 빠른 개발 후 성능을 점진적으로 개선하는 방식 • 개발자가 주도적으로 프로젝트를 제안하고 실행하는 문화 • 본인의 업무량을 스스로 조정하고, 필요한 프로젝트를 맡아 진행

위와 같은 회사 문화를 통해 개발자의 주도적 능력과 MVP의 중요성을 알 수 있었다.

6. Intel: 새로운 돌파구

CPU 내부 NPU 테스트를 담당하시는 강화석 개발자님과의 대화에서 무어의 법칙의 한계와 새로운 돌파구의 필요성을 들었다.

CPU의 성능이 1년에 2배씩 상승한다는 무어의 법칙은 최근 2년 주기로 변경되었고 이조차도 점점 한계를 보이고 있다고 한다. 10나노 이하의 초미세공정에 들어가면서 양자 터널효과가 발생해 물리적 크기만 줄이는 것에는 한계가 온 것이 그 이유다. 따라서 초전도체등의 다른 다양한 방식을 찾아야 한다는 것을 알 수 있었다.

또한 "한 가지 특별한 강점과 다른 분야의 넓은 지식을 가진 T자형 인재"를 선호한다는 조언을 들을 수 있었다. 신입 개발자에게 요구하는 능력이 점점 상향되는 상황에서 뾰족한 강점을 가진 T자형 인재가 되겠다는 생각을 했다.

기술을 넘어선 사람들의 이야기: 개발자 간담회

이번 연수의 하이라이트는 단연 첫날 저녁의 개발자 간담회였다. 다양한 배경의 개발자들이 모여 기술에 대해 이야기하는 모습은 단순한 네트워킹을 넘어, 내가 앞으로 어떤 개발자가 되어야 하는지에 대한 깊은 영감을 주었다.

순수한 열의

AI의 미래에 대해 서로의 의견을 존중하며 토론하고, 학생들의 질문 하나하나에 자신의 경험을 녹여 진심으로 답변해주는 시간을 가졌다. 계속된 토론에서 느낄 수 있었던 것은, 그들이 가지고 있는 '순수한 열의'였다. 다양한 나이대, 다양한 배경에서 다른 일을 하는 개발자들이었지만, 그 순수한 열의만큼은 모두가 같았다. 그 중엔 시각장애를 가진 개발자분도 계셨는데, 나레이션을 통해 코딩을 한다는 것을 듣고 그 열의가 대단하다고 느꼈다.

관계의 중요성

"적을 적게 만들고, 진정성 있는 관계를 유지하라"는 조언은 기술 커뮤니티 안에서 협업과 소통이 얼마나 중요한지 다시 한번 깨닫게 했다.

대학 탐방과 AI 시대의 생존 전략

Stanford University와 San Jose State University를 방문하며 교육의 진정한 가치와 능동적인 학습 태도의 중요성을 깨달았다.

앞선 여러 개발자와의 대화를 통해 "실리콘밸리 시니어 개발자들도 AI 발전 속도에 위기감을 느낀다"는 현실과 마주했었다. 그러나 역설적으로 AI 시대일수록 AI가 해결해주지 못하는 근본적인 문제 해결 능력, 즉 CS 기본기의 중요성이 더욱 부각된다는 것을 알게 되었고, 교육의 중요성과 능동적 학습 태도의 중요성을 체감할 수 있었다.

웨이모 탑승 체험: 미래를 직접 경험하다

레벨 4 자율주행 기술을 직접 체험한 것은 깊은 기술적 성찰을 가져다주었다. 센서 데이터의 실시간 처리, 네트워크 지연 최소화, 안전성 확보라는 복합적 과제들이 어떻게 하나의 서비스로 통합되는지 몸소 체험할 수 있었다. 이 경험은 "기술의 궁극적 목표는 사용자가 기술을 의식하지 않게 만드는 것"이라는 깨달음이 되었다.

마치며

일주일간의 여정 끝에 실리콘밸리에서 발견한 것은 화려한 기술이나 거대한 사옥이 아니었다. 그것은 문제를 해결하려는 치열함, 기술에 대한 순수한 열정, 그리고 더 나은 세상을 만들고자 하는 개발자들의 진정성이었다.

특히 개발자 간담회에서 만난 분들의 열정은 마음속 깊은 곳에 새로운 불씨를 지펴주었다. 그들이 보여준 "기술로 세상을 더 좋게 만들겠다"는 신념을 나 또한 품고 싶다.

이 경험을 자양분 삼아, 끊임없이 배우고, 대담하게 도전하며, 언젠가는 나 또한 후배들에게 영감을 주는 개발자로 성장하고 싶다. 실리콘밸리에서 받은 그 뜨거운 열정을 개발자 여정의 영원한 동력으로 삼아, 기술로 사람들의 삶을 더 풍요롭게 만드는 개발자가 되겠다.

+연수 후 7개월: 영감을 프로젝트로 구체화하기

실리콘밸리에서 돌아온 지 7개월이 지났다. 당시 느꼈던 뜨거운 열정과 영감은 막연한 다짐을 넘어, 구체적인 '문제 해결'을 위한 프로젝트 계획으로 발전했다. 연수에서 얻은 가장 큰 가르침인 '기능 구현을 넘어, 근본적인 기술적 문제를 해결하는 엔지니어'가 되기 위해 다음과 같은 프로젝트들을 준비하고 있다.

1. ParkingMate: 공유 경제의 '신뢰' 문제를 해결하다

P2P 주차 공간 공유 플랫폼 파킹메이트는 공유 경제의 고질적인 '신뢰' 문제를 기술로 해결하는 데 집중한다. Onehouse와 Google에서 강조했던 대규모 트래픽 환경에서의 데이터 정합성의 중요성을 체감했기에, 이 프로젝트에서는 '동시성 제어'를 핵심 기술 목표로 삼았다. 여러 사용자가 특정 주차 공간을 동시에 예약하려 할 때 발생하는 Race Condition을 Locking 메커니즘을 통해 해결하고, '사진 증거 시스템'을 도입하여 기술이 어떻게 사용자의 신뢰를 구축할 수 있는지 증명하고자 한다.

2. 냉장Goat: '단순 유틸리티'를 '실시간 협업 시스템'으로

Google에서 1ms의 성능 개선이 사용자의 이탈을 막는다는 사실에 큰 충격을 받았던 것처럼, 이 프로젝트는 점심 피크타임에 수십 개의 POS 단말기에서 발생하는 동시 주문에도 단 하나의 오차 없이 재고 데이터의 정합성을 보장하는 것을 핵심 기술 목표로 삼는다. '1인분 기준 실시간 재료 차감' 기능은 Redis 분산 락을 이용한 동시성 제어 능력을 증명하는 핵심 과제이다.

나아가, 우리는 단순히 데이터를 기록하는 시스템을 넘어, 'AI 기반 스마트 발주 추천' 기능을 통해 미래 수요를 예측하고 점주에게 최적의 의사결정을 돕는 '능동적인 비즈니스 파트너'를 구축하고자 한다. 이 과정은 Meta에서 배운 "빠른 개발 후 점진적 개선" 철학을 적용하여, 현실적인 '모듈형 모놀리스' 아키텍처 위에서 안정적으로 구현하고 고도화하는 경험의 장이 될 것이다.

3. INSK v3.0: '프로토타입'을 '실제 서비스'로 고도화하다

'AI 뉴스 트렌드 센싱 플랫폼'은 SK 대외활동 써니C 4기에서 진행된 기존 Python 프로토타입을 실제 서비스 수준으로 고도화하는 프로젝트이다. Meta에서 배운 "빠른 개발 후 점진적 개선" 철학을 실제로 적용하는 사례다. 사용자의 피드백을 반영하여 확장성 없는 단일 사용자용 스크립트를, Java/Spring 기반의 안정적인 백엔드와 React 기반의 인터랙티브 프론트엔드 아키텍처로 재설계한다. 이 과정을 통해 대규모 트래픽을 감당하고, 안정적인 CI/CD 파이프라인 위에서 지속적으로 발전하는 서비스를 만드는 경험을 쌓고자 한다.

"기술이 아닌 협업과 문제해결의 경험"

해커톤 개요

주제: 기술기반 캠퍼스/GO 글로벌/융합/Life Long Learning을 주제로 한 AWS 인텔리전스 캠퍼스 해커톤
개발 서비스: Slack/Canva/App-Web 등 Any Service
결과: 최우수상 수상 🏆
개발 기간: 24시간 (2024.08.30~08.31)

프로젝트 소개: '인상룩'

"AI 관상 분석을 통한 무전공 신입생 맞춤 학과 추천 서비스"

서비스 개요

• 타겟: 2025년 무전공으로 입학하는 신입생
• 목적: 관상 분석을 통해 재미있고 직관적인 학과 탐색 경험 제공
• 핵심 기능: 얼굴 이미지 → 관상 분석 → MBTI 변환 → 학과 추천 → 학과 사이트 연결

기술 스택 및 아키텍처

• 얼굴 인식: DLIB 라이브러리 (오픈소스, Python 기반)
• 분석 기준: 황금비율 대비 얼굴 특징 추출
• AI 활용: ChatGPT를 통한 학과별 MBTI 분류 데이터 생성
• 프론트엔드: 사용자 친화적 웹 인터페이스

개발 과정: 24시간의 여정

1단계: 철저한 사전 준비의 중요성

"준비된 자에게 기회는 온다"

첫 해커톤 참가라는 부담감에 사전 준비에 많은 시간을 투자했습니다.

• AWS 사전 교육 수료: 클라우드 기반 개발 환경 이해
• 아이디어 사전 검토: GPT, Gemini, Claude를 활용한 다각적 아이디어 발굴
• 실제 데이터 수집: '학교 맛집 찾기' 아이디어 사전 준비로, 기숙사 공유 배달 카톡방에 접근하여 기숙사 배달 주문 데이터 2년치 확보 (22년 8월~24년)

2단계: 팀 역학과 리더십의 도전

"다양성 속에서 방향성을 찾아가는 과정"

4명의 해커톤 초참가자들로 구성된 팀에서 팀장 역할을 맡게 되었습니다.

예상과 현실의 차이:

• 예상: 효율적이고 목표 지향적인 팀워크
• 현실: 친목과 경험 중심의 편안한 분위기

리더십 학습 포인트:

• 개인의 목표와 팀의 분위기 사이에서 균형점 찾기
• 준비한 아이디어를 팀원들과 공유하며 동기 부여하기
• 갑작스런 주제 변경('관상 파악하기')에 유연하게 대응하기

3단계: 문제 정의와 솔루션 설계

"엉뚱한 아이디어를 현실적인 서비스로 발전시키기"

팀원의 관상에 대한 흥미를 해커톤 주제와 연결시켜 '관상 기반 학과 추천 서비스'로 발전시켰습니다.

아이디어 발전 과정:

관상에 대한 흥미 
→ 관상 분석 프로그램 제작
→ 무전공 신입생 타겟 설정 
→ 재미있는 학과 탐색 경험 제공
→ 실용적인 학과 정보 연결

검증 과정: 중간 점검에서 심사위원들의 긍정적 피드백 확보

기술적 구현과 도전

얼굴 인식 기술 선택

FACE++ vs DLIB 비교 분석

• FACE++: 우수한 성능, 유료 서비스
• DLIB: 충분한 성능, 오픈소스, 무료
• 결정: 해커톤 환경과 예산을 고려해 DLIB 선택

핵심 알고리즘 설계

5단계 처리 파이프라인:

1. 얼굴 인식: DLIB를 통한 68개 특징점 추출
2. 특징 분석: 황금비율 대비 얼굴 특징 수치화
3. 성격 매핑: 얼굴 특징을 성격 지표로 변환
4. MBTI 변환: 성격 지표를 MBTI 유형으로 분류
5. 학과 추천: MBTI 기반 최적 학과 매칭

데이터 설계의 창의성

학과별 MBTI 분류: ChatGPT를 활용하여 각 학과의 특성을 MBTI로 체계화

• 객관적 기준 부재 문제를 창의적으로 해결
• AI의 장점을 적극 활용한 데이터 생성

프로젝트 성과 및 임팩트

🏆 수상 결과: 최우수상

• 심사 기준: 기술성, 창의성, 실용성, 발표력
• 차별점: 타겟 명확화 + 재미있는 접근 + 실용적 연결

비즈니스 임팩트

• 사용자: 무전공 신입생의 학과 선택 고민 해결
• 학교: 효과적인 학과 홍보 도구
• 확장성: 타 대학교 적용 가능한 모델

핵심 학습 포인트

1. 커뮤니케이션의 중요성

"기술보다 사람이 먼저다"

해커톤에서 가장 큰 도전은 기술이 아닌 팀원들과의 소통이었습니다.

• 다양한 성향의 팀원들과 공통 목표 설정하기
• 의견 충돌 시 건설적 방향으로 해결하기
• 각자의 강점을 파악하고 역할 분배하기

실무 적용점: 실제 개발팀에서도 기술적 역량만큼 소통 능력이 중요함을 이해

2. 자체 개발 능력의 필요성 인식

"LLM 의존도를 줄이고 근본적인 개발 실력을 키우자"

해커톤 과정에서 LLM에 과도하게 의존하는 자신을 발견했습니다.

• 문제 인식: 기본적인 알고리즘 구현에서도 AI 도구에 의존
• 해결 방안: 자료구조, 알고리즘 등 CS 기초 과목 집중 이수
• 후속 행동: 소프트웨어에 집중하고자 스마트정보통신공학과 → 소프트웨어학과 전과 결정, 알고리즘 실습 과목 A+ 달성

장기적 목표: AI 도구를 보조 수단으로 활용하되, 핵심 개발 능력은 자체적으로 확보

3. 프로젝트 관리와 시간 분배

"마라톤 같은 해커톤에서 배운 전체적 관점"

24시간이라는 제한된 시간에서 효율적인 작업 분배를 경험했습니다.

• 완벽주의의 함정: 한 단계에 모든 시간을 투자하는 위험성
• 전체적 관점: 기획-개발-발표의 균형잡힌 시간 배분
• 우선순위 설정: 핵심 기능 우선 구현 후 부가 기능 추가

실무 연관성: 실제 업무에서도 데드라인 내 전체 프로세스를 관리하는 능력의 중요성

이후 성장 계획

단기 목표

• CS 기초 역량 강화: 자료구조, 알고리즘 심화 학습
• 웹 개발 실력 향상: Spring Boot, React 등 실무 기술 습득
• 포트폴리오 확장: 해커톤 경험을 바탕으로 한 개인 프로젝트 진행

장기 비전

• AI 서비스 개발자: 기술적 기반 위에서 AI를 활용하는 개발자
• 팀 리더십: 다양한 팀 프로젝트 경험을 통한 리더십 역량 강화
• 문제해결형 개발자: 단순 구현이 아닌 비즈니스 문제를 해결하는 개발자

마치며

첫 해커톤 참가는 단순히 상을 받는 것을 넘어서 개발자로서의 방향성을 명확히 하는 계기가 되었습니다.

기술적 완성도보다는 문제 정의의 정확성과 팀워크의 중요성, 그리고 지속적인 학습의 필요성을 깊이 깨달았습니다.

앞으로도 이런 도전적인 경험들을 통해 성장해나가는 개발자가 되고 싶습니다.

🔗 관련 링크

• [GitHub Repository][시연 영상][발표 자료] https://github.com/gm-15/aws_smu_hackathon