Microservice Architecture (MSA)

• 하나의 어플리케이션을 여러개의 작은 서비스 유닛으로 구성

Pros

• 각각의 독립적 서비스로 개발과 배포가 빠름
• 서비스 장애의 경우 전체 시스템에 영향을 주지않음
• 서비스마다 다른 기술스택을 가질 수 있음

Cons

• 각 서비스간 통신 비용 증가
• 개별 서비스간의 내부 통신 복잡성
• 통합 테스트 및 배포의 어려움

Monolithic Architecture

• 하나의 어플리케이션에 모든 구성요소가 통합되어 하나처럼 움직임

Pros

• 소규모 프로젝트에 적합
• 개발 / 빌드 / 배포 / 테스트가 용이

Cons

• 프로젝트 규모가 커질수록 빌드 배포 시간이 길어짐
• 작은 수정에도 프로젝트 재배포 필요
• 일부의 오류가 시스템 전체에 영향
• 한 종류 기술스택에 국한

MSA on Robotics

• 모듈화되어 여러 컴포넌트가 하나의 시스템으로 동작하는 로보틱스 특성상 MSA가 적합
• 로보틱스의 각 기능을 개별 서비스로 분리하면, 필요한 부분만 독립적 확장 가능
  • ex) SLAM 서비스가 높은 연산량을 요구할 경우 SLAM 컴포넌트만 스케일링하여 성능 최적화
• 서비스별로 최적의 기술스택 사용 가능
  • ex) SLAM(C++) / perception(Python) / data logging(Go)
• 하나의 서비스가 실패해도 전체 시스템이 중단되지 않도록 설계(Fault Tolerance)
  • ex) perception 서비스가 다운되도, navigation 기능은 유지
• 분산 환경 및 클라우드 연계
  • 일부 서비스는 로컬에서 실행하고, 일부는 클라우드에서 활용(navigaion - local / data analysis - cloud)
• 개발 생산성 향상 및 협업 용이
  • 컴포넌트 단위로 나누어 병렬 개발
  • CI/CD를 적용하여 빠르게 배포 및 테스트

MSA on Robotics 예시

Monolithic Architecture on Robotics의 문제점

• 다양한 센서, 액추에이터, 제어 알고리즘을 포함하므로 코드가 거대해지고 관리가 어려움
• 하나의 모듈을 변경할 경우 전체 시스템을 재배포해야 함
• 새로운 기능 추가 시 기존 코드와의 종속성이 증가

ROS와 연계

• ROS2는 기존 ROS1보다 마이크로서비스 구조에 적합
  • DDS (Data Distribution Service) 사용하여 비동기 통신 지원
  • 노드 기반 설계를 통해 독립적인 서비스로 구성 가능
  • 컨테이너화하여 Kubernetes 기반 로봇 시스템 구축 가능

마이크로서비스 도입 시 고려할 점

서비스 간 통신 방식 결정

• gRPC → 고속 바이너리 통신, 경량 로봇 시스템에 적합
• REST API → HTTP 기반, 클라우드 연동 용이
• MQTT → IoT 및 저지연 데이터 스트리밍에 적합
• ROS2 DDS → 실시간 로봇 시스템에 최적

오케스트레이션 관리

• Kubernetes 사용 시 로봇의 Edge 컴퓨팅 환경과의 적합성 검토 필요
• Docker Compose를 이용하여 경량화된 마이크로서비스 구성 가능

데이터 처리 및 저장소 설계

• 센서 데이터와 로깅 데이터를 적절히 분리하여 관리해야 함
• 실시간 데이터는 Redis, 장기 저장 데이터는 PostgreSQL/MongoDB 사용 고려

MSA 기반 로보틱스 시스템

1. 물리 계층 - 리소스의 효율적 관리 및 확장성 제공

• 서버, 스토리지, 네트워크 등의 자원을 관리
• 퍼블릭 클라우드 (IaaS) 기반이거나 프라이빗 클라우드로 구축 가능
• OpenStack을 이용해 리소스를 가상화하고 동적 할당 수행
• Docker 컨테이너를 통해 리소스 격리 및 배포
• Kubernetes(k8s) 를 사용하여 자동화된 운영 및 유지보수 관리

2. 통신 인터페이스 계층 - 로봇과 클라우드 간의 데이터 통신을 담당

• Ubuntu 운영체제 및 개발 도구를 사전 설치
• ROS (Robot Operating System) 통합 → 로봇과 클라우드 간의 원격 통신 지원
• ROS의 토픽(topic) 기반 통신 방식을 활용하여 모듈 간 결합도 감소
• 로봇과 클라우드 플랫폼의 ROS 버전이 일치하면 ROS_MASTER를 통해 원격 연결 가능

3. 마이크로 애플리케이션 계층 - 경량 RESTful 프로토콜 기반의 마이크로서비스 관리

• 주요 컴포넌트
  • Zuul: API 게이트웨이 → 동적 라우팅, 모니터링, 부하 분산 수행
  • Consul: 마이크로서비스 등록 및 발견 기능 제공
  • Ribbon: 클라이언트 측 부하 분산 → AWS 환경에서 중간 계층 서비스 관리
  • Message Bus: 마이크로서비스 간 메시지 통신 담당
  • Config Center: GitHub 등의 저장소에서 설정 파일을 관리하여 배포 및 유지보수 간소화

4. 비즈니스 계층 - 로봇이 필요로 하는 다양한 소프트웨어 및 데이터 처리 서비스 제공

• 자율주행 관련 서비스: 자율 주차, 자동 추종, 차선 유지 등
• 기본 클라우드 서비스: 오프라인 연산, 데이터 저장, 지도 생성 등
• 클라우드에서 센서 데이터를 수집 → 이종 데이터 융합, 머신러닝, 분석 수행
• 분석된 데이터는 다른 로봇과 공유되어 더욱 효율적인 자율주행 지원

로보틱스 시스템의 CI/CD

CI/CD Components

• Kubernetes (K8s)
  • 컨테이너화된 애플리케이션을 자동 배포, 확장, 관리하는 도구
  • 클러스터링 및 리소스 분배를 최적화하여 서비스의 가용성 유지
• Jenkins
  • CI/CD 프로세스를 자동화하는 웹 기반 플랫폼
  • 코드 작성 → 빌드 → 테스트 → 배포 과정을 자동화
  • GitHub, GitLab 등의 코드 저장소와 연동하여 최신 코드 자동 배포
• Harbor
  • Docker 이미지를 관리하는 프라이빗 저장소
  • 보안 강화를 위한 RBAC(Role-Based Access Control), LDAP 연동
  • 네트워크 최적화 및 확장성 제공
• Pipeline
  • Jenkins의 공식 플러그인으로, CI/CD 프로세스를 단계별로 정의하고 자동 실행
  • 수동 배포 없이 사용자 정의 자동화 프로세스 구축 가능

CI/CD Process

1. 개발자가 코드 작성 → GitLab에 푸시
2. Jenkins가 GitLab에서 코드 가져오기
3. Jenkins가 코드 컴파일 및 빌드 진행
4. 빌드된 Docker 이미지를 Harbor 저장소에 업로드
5. Docker가 Harbor에서 이미지를 가져와 프로덕션 환경에 배포
6. Kubernetes(K8s)가 컨테이너 오케스트레이션 수행
   • Pod(가장 작은 단위의 컨테이너 그룹) 생성
   • Pod가 자동으로 코드 빌드, 이미지 푸시 수행
   • 작업 완료 후 Pod는 자동 삭제 및 리소스 해제
7. 로봇 애플리케이션 개발자는 Harbor에서 이미지를 가져와 원하는 환경에 배포 가능

※ https://doi.org/10.1155/2021/6656912

로그 레벨

1. FATAL (치명적 오류)

애플리케이션이 더 이상 실행될 수 없는 심각한 오류

• 시스템이 즉시 종료될 정도로 중요한 문제
• 반드시 즉각적인 조치가 필요

예시

• 중요한 설정 정보가 누락됨
• 데이터베이스 연결이 끊어져 필수 기능 수행 불가
• 디스크 공간 부족으로 시스템 중단
• 해킹 시도 감지

2. ERROR (오류)

특정 기능이 작동하지 않지만, 전체 시스템은 계속 실행 가능

• 긴급 대응 필요하지만, 시스템 전체가 멈추는 것은 아님
• 일부 기능이 비정상적이거나 실패했을 때 기록됨

예시

• API 요청이 실패하여 서비스에 영향
• 네트워크 연결 실패 (자동 복구가 안 되는 경우)
• JSON 데이터를 읽는 중 오류 발생

3. WARN (경고)

예상치 못한 상황이지만, 시스템이 정상적으로 동작함

• 즉각적인 오류는 아니지만, 조치가 필요할 가능성이 높음
• 시스템이 정상적으로 동작하더라도 미래에 문제로 발전할 수 있음

예시

• CPU, 메모리 사용량이 위험 수준 근접
• 로그인 실패 횟수가 비정상적으로 많음 (보안 위험)
• 오래된 설정값 사용 중

4. INFO (정보)

시스템의 정상적인 동작을 기록하는 로그

• 문제 해결보다는 시스템의 중요한 상태 변화 기록
• 일반적으로 프로덕션 환경에서 기본적으로 활성화됨

예시

• 서비스 시작 및 종료 기록
• 작업이 정상적으로 완료됨 (예: 파일 업로드 성공)
• 주기적인 상태 점검 결과

5. DEBUG (디버그)

개발자가 문제 해결을 위해 사용하는 상세한 로그

• 개발 및 테스트 환경에서만 사용
• 많은 양의 데이터를 기록하기 때문에 운영 환경에서는 비활성화하는 것이 일반적

예시

• 데이터베이스 쿼리 내용 확인
• API 요청 및 응답 정보
• 설정값 및 실행 시간 기록

6. TRACE (추적)

코드 실행 경로를 상세하게 추적하는 로그

• 디버깅보다 더 세밀한 로그로 코드가 어떻게 실행되는지 확인
• 보통 성능 분석이나 복잡한 문제 해결 시 사용
• 운영 환경에서는 사용하지 않음 (너무 많은 데이터 생성)

예시

• 함수가 호출될 때 입력값 및 반환값 기록
• 반복문 내에서 처리되는 데이터 추적
• 알고리즘의 동작 과정 확인

정리

운영 환경(production): INFO, WARN, ERROR, FATAL
개발 환경(development): DEBUG, TRACE 포함 모든 로그

#include <chrono>
#include <functional>
#include <memory>

#include "geometry_msgs/msg/twist.hpp"
#include "rclcpp/rclcpp.hpp"
#include "sensor_msgs/msg/laser_scan.hpp"

using namespace std::chrono_literals;
using std::placeholders:: _1;

class Sample{
    public:
        Sample(): ranges_size(0){};
        void LaserScanCallback(const sensor_msgs::msg::LaserScan::SharedPtr _msg){
            this->ranges_size = _msg->ranges.size();
            std::cout << this->ranges_size << std::endl;
        }
    private:
        unsigned int ranges_size;
};
class MovingRobot: public rclcpp::Node{
    public:
        MovingRobot(): Node("moving_robot"){
            sample_ptr_ = std::make_shared<Sample>();

            laserscan_subscription_ = this->create_subscription<sensor_msgs::msg::LaserScan>(
                "/scan", rclcpp::QoS(rclcpp::SystemDefaultsQoS()),
                std::bind(&Sample::LaserScanCallback, sample_ptr_.get(), _1));
        }
    private:
        rclcpp::Subscription<sensor_msgs::msg::LaserScan>::SharedPtr laserscan_subscription_;

        std::shared_ptr<Sample> sample_ptr_;
};

int main(int argc, char* argv[]){
    rclcpp::init(argc, argv);
    rclcpp::spin(std::make_shared<MovingRobot>());
    rclcpp::shutdown();

    return 0;
}

핵심은 subscription callback 등록할때 bind 함수에서 this 포인터 대신 클래스의 포인터를 등록

workspace dependency visualization

colcon graph --dot > graph.dot  
dot -Tpng graph.dot -o graph.png  

download package(online)

pip3 download --platform linux_aarch64 pyelftools

• 설치된 pyelftools 설치 압축파일을 설치목적지로 복사

install package(offline)

pip3 install --no-index --find-links pyelftools-xxxxxxxxxxxxxxxx.whl pyelftools

offline pip upgrade

pip3 download pip # online
python pip-xxxxxxxx.whl/pip install --no-index pip-xxxxxxxxxx.whl # offline

fix gazebo client coordinates

vi ~/.gazebe/gui.ini

[geometry]
x=0
y=0
width=1754
height=1043

set camera projection

vi warehouse.world

<?xml version="1.0" ?>
<sdf version="1.4">
  <world name="default">
    <include>
      <pose>4 1 30 0 0 0</pose>
      <uri>model://sun</uri>
    </include>
    <model name="warehouse">
      <include>
        <pose>0 0 0 0 0 0</pose>
        <uri>model://warehouse</uri>
      </include>
    </model>
    <gui fullscreen='0'>
      <camera name='user_camera'>
          <pose frame=''>0 0 0 0 1.57 0</pose>
          <!--projection_type orthographic or perspective-->
          <projection_type>orthographic</projection_type>
      </camera>
    </gui>
  </world>
</sdf>

1. Apache 2.0 License
- ASF(Apache Software Foundation)에서 만든 라이센스
- 아파치에서 만드는 소프트웨어는 모두 적용
- Apache 2.0 License 고지 해야함
- Apache 2.0 License 소스코드를 수정하였을때는 수정 내용도 고지
- Derivative Works의 소스코드 공개의무 없음
- Apache라는 상표명에 대한 침해가 되어서는 안됨

2. MIT License
- MIT에서 만든 라이센스
- Copyright, License 정보만 표기하면됨
- 매우 개방적인 라이센스
- 상업적인 배포가 가능
- 무상으로 제한없이 사용이 가능
- 문제 발생시 카피라이터가 책임지지 않고 사용자에게 모든 책임이 있음

3. GNU General Public License
- FSF(Free Software Foundation)에서 만든 라이센스
- 상업적인 배포가 가능(유료배포 가능)
- 소스코드 공개의무(내부 : closed, 외부 : open)
- 상대적으로 보수적인 라이센스

4. GNU Less General Public License
- 상대적으로 보수적인 GPL 때문에 라이브러리에 여유를 둔 라이센스
- 전반적으로 GPL과 동일하지만, 동적 정적 라이브러리에 GPL 라이센스가 적용된 경우에는 소스코드를 공개하지 않아도 됨
- LGPL 라이브러리를 사용하고있다는것만 명시 의무있음
- 그러나 LGPL 라이브러리를 수정하는경우에는 소스코드를 공개해야함

5. BSD-3 License
- Berkeley Software Distribution License
- 소스코드 공개의무가 없음
- 라이센스 정보만 명시
- 때문에 상용 소프트웨어에서 가장 많이 사용됨
- 그러나 BSD 라이센스의 소프트웨어에서 문제가 발생해도 카리라이터에게는 아무런 책임이 없음(non-endorsement clause)

6. BSD-2 License
- BSD-3 License에서 non-endorsement clause 삭제

[Adaptive AUTOSAR]

80년대 자동차 산업에서 처음 ECU가 등장하였고, 프로그램 크기와 complexity의 관점에서 ECU 내부의 소프트웨어는 간단하계 설계되었다.
현재는 자율주행의 완성도가 점점 높아지고 있으며, telematics, 인포테인먼트, IoT 장비 등등 많은것들이 차량 내부에 설치되고있다.
그러나 소프트웨어들이 많아질수록 다양한 OEM에서 다양한 규격의 소프트웨어들이 제작되었고, 제각각인 소프트웨어에 대한 표준이 필요했는데 그게 바로 AUTOSAR이다.
2002년 AUTOSAR가 처음 소개되었고, 차량 소프트웨어 개발의 관점에서의 기준 제시였다.
그러나 AUTOSAR 위에서 개발된 소프트웨어는 소프트웨어 lifecycle 내에 소프트웨어 업데이트가 이루어지지 않는다는 전제가 깔려있고, 최근에 개발되는 소프트웨어들은 빈번한 업데이트가 필요하기 때문에 Classic AUTOSAR는 맞지않다.
이는 Classic AUTOSAR가 구식이라는 이야기는 아니고, 자율주행과 같은 미래시대의 needs를 충족시키기 위한 다른 기준의 필요성 정도이다.
어쨋든 이러한 needs를 충족시키기 위해 나온 새로운 기준이 Adaptive AUTOSAR이다.

[Adaptive AUTOSAR의 필요성]

Advanced Driver Assistance System

ADAS는 자율주행의 핵심기술로 라이다, 레이더, 고성능 카메라와 같은 센서들을 기반로 동작한다.
사실상 다이나믹 통신, 유연하고 안전한 플랫폼, 빠른 데이터 전송과 프로세싱등을 제공하는 Adaptive AUTOSAR를 요구한것은 자율주행이라고 할 수 있겠다.
자율주행은 신호등, 다른 차량과 통신을 하고, 센서와 카메라를 통해 얻은 차량 외부 환경에 관련된 데이터를 가지고 핸들을 조향하고 속도를 줄이는등 차량을 조작한다.
라이다, 레이더와 같은 센서를 통해 얻은 데이터는 실시간으로 ECU에 전송되어 빠르게 처리되어야한다.
빠른 차량내부 통신을 위해서 기존의 통신 프로토콜인 CAN, LIN, Flexray 등은 충분한 속도를 내지 못하고 이더넷, SOME/IP와 같은 프로토콜이 도입되어야한다.

Vehicle Architecture

센서와 직접 연결된 기존의 ECU와 다르게, 새로운 Domain Controller Architecture는 자율주행에서 새로운 트렌드가 되고있다.
분리된 컨트롤러대신 이 컨트롤러는 Body Control, 인포테인먼트, 파워트레인 등 각각의 도메인들에 할당된다.
전기차의 경우 충전소와 차량간의 통신은 유일하고 안전해야 한다.
Classic AUTOSAR는 이러한 요구조건에 맞게 설계되지 않았다.

Firmware-Over-The-Air Update(FOTA)

OTA란 새로운 소프트웨어, 업데이트 등을 무선 네트워크를 통해 배포하는것인데 FOTA는 펌웨어를 무선으로 다운받아 업데이트 한다는 것이다.
Classic AUTOSAR는 FOTA를 제공한다.
그러나 ECU 내부 각각의 어플리케이션을 업데이트할 수는 없고, 이는 Classic AUTOSAR에서 FOTA에 대한 의존성을 약화시켰다.
flexible한 Adaptive AUTOSAR는 새로운 주안점을 가지고 소프트웨어를 업데이트하고 확장시켰다.

[Classic AUTOSAR와 Adaptive AUTOSAR의 아키텍쳐]

[두 AUTOSAR는 공존 가능한가?]

위에서도 언급했듯이 Adaptive AUTOSAR는 Classic AUTOSAR의 대체가 아니고 자동차 생태계에서 상호공존을 의미한다.
두 플랫폼 모두 각기다른 문제에 대한 솔루션이며, 이것들의 공존은 높은 가치를 창출한다.

위 사진은 두 플랫폼이 차량 내에서 공존하는 overview이다.
CAN, LIN등의 차량 내부 프로토콜을 사용하던 Classic AUTOSAR와 달리, Adaptive AUTOSAR가 가져온 가장 큰 변화는 이더넷 프로토콜이다.

그렇다면 Adaptive와 Classic ECU는 어떻게 통신할까?
첫번째 시나리오는 gateway ECU이다.
Classic ECU는 게이트웨이로써의 역할을 하고, BUS 시스템에서 Adaptive ECU가 읽을수 있는 서비스로 신호를 패킹한다.
다만 포맷에대한 변화는 필요하다.
Classic ECU는 단지 신호기반이고, 신호를 서비스로 패킹할 수 없다는 또 다른 시나리오가 있다.
여기서 Classic ECU는 신호를 UDP 프레임으로 변환하고, 이를 이더넷으로 전송한다.
Adaptive ECU는 UDP 프레임을 서비스로 변환하기위해 'signal to service'라는 맵핑 feature를 갖추고있다.

[AUTOSAR의 미래]

Classic과 Adaptive AUTOSAR는 상호 보완하고 공존이 가능하다.
Classic AUTOSAR는 소프트웨어가 깊게 embedded된 functional ECU에 특화된 플랫폼이고, 자율주행을 실현시켜주는 미래지향적인 플랫폼이 Adaptive AUTOSAR이다.
그리고 자동차 산업에서 두 플랫폼은 모두 필요하다.
언젠가 Adaptive AUTOSAR가 ECU 소프트웨어 개발에 있어서 단독 플랫폼이 될지도 모르지만 아직 그렇게 생각하기에는 이르다.

www.embitel.com/embedded-blog/adaptive-autosar-vs-classic-autosars

블로그는 정말 공부 저장용으로만 쓰고 있는데 심심해서 써본다.
후기는 처음 써보는 거라 어떻게 쓰는 건지 잘 모르겠고 그냥 서류부터 수료까지 시간순으로 기억나는 대로 써보겠다.

소마가 무엇이냐. 그냥 IT 대외활동인데 다른 대외활동에 비해 지원이 짱짱하다.
(매달 000만원 장학금, IT기기 000만원, 플젝비용 000만원, 학습비 000만원)
참고로 개발 쪽은 한이음, 멋쟁이사자처럼, 42서울 
보안 쪽은 케이쉴드, 비오비 같은 것도 있다. 
자격은 학력전공나이 무관이나 수입이 있는 사람 즉 직장인은 불가하다.

지원 절차는 서류 - 인적성 - 코딩테스트 - 면접 순이다.

[서류]
전역직후 공부 계획도 제대로 안 잡혀있었고 시간도 많아서 신경 써서 썼던 것 같다.
서류접수 기간에 사무국에서 설명회도 개최하는데 나는 안가서 어떤지 모르겠다.

[인적성]

인적성 검사는 AI를 통해 진행되는데 AI면접 처음이라 집에서 신기해하면서 대답했다.

내용이 기억이 잘 안나고 나 혼자 로봇한테 대답한 거 보고 뭔가 최첨단인데 자괴감 들었다.

[코딩테스트]
나는 ps문제를 백준에서 조금 풀어보긴 했지만 시간 안에 푸는 연습은 한 번도 안 해봐서 애좀 먹었다.

15문제 중 5~6개 정도 맞았던 거 같고 시간은 90분 줬다.

4문제 푼 사람은 떨어진 사람도 있고 붙은 사람도 있고 3문제 풀고 붙은 사람은 못 봤다. 나도 운 좋게 붙은 것 같다.
내 생각에는 15문제 다 풀라고 낸 건 절대 아닌데 ps 괴물들은 거의 다 맞추는 거 같더라.
(실제 10기 연수생들과 만남을 가진 후 5명의 괴물이 있다는 걸 알게 댐
IT 공부하면서 항상 우물 속에 있다고 느꼈는데 역시나 세상에 천재는 많드라)

ps. 강남 소재 컴퓨터학원에서 봤는데 사람이 정말 많이 왔더라. 알고 보니 역대 최고 경쟁률(8.1:1)이었다고 한다.

하지만 42서울이라는 새 대외활동이 생겼기 때문에 11기부터 다시 좀 줄어들 거라고 생각한다. 지원해보세요.

 
[면접]

취준 하면서 면접 다닐 때도 많이 안 떨었는데 이때는 왜 이렇게 떨었는지 모르겠다.

면접은 다대다 면접이다. 면접관이 6분 정도 면접자는 7명 정도 들어왔던 것 같다.

지원동기 같은 기본적인 질문들은 공통으로 한 번씩 하고,

면접자 별로 본인이 서류에 썼던 공부 했던 분야 위주로 개인 질문이 들어온다.

나 같은 경우 보안에 대한 내용을 좀 썼어서 PKI, 프로가드, 암호화와 인코딩 차이를 물어봤던 것 같다.

교통비도 준다.

[연수생 멘토 팀 매칭(가장 중요)]

3주 정도의 시간이었던 거 같다.

자유 멘토링을 통해서 팀을 구성하고 담당 멘토님을 정해야 한다.

먼저 사무국에서 그룹웨어에 본인 자기소개를 올리라고 한다.

그러면 10기 연수생, 멘토님들이 모두 자기소개를 올린다.

대충 어느분야에 관심이 있고 공부해왔는지 알 수 있다.

이때 적극적으로 연수생들 간에 네트워킹이 이루어져야 한다.

그리고 멘토님들이 자율주제로 자유 멘토링을 개설하시는데 매일 있으니 가능한 시간별로 참석하면 좋다.

본인들 소개하고 대화하며 이 사람이 어떤 생각을 가지고 있는지 알 수 있고 6개월간 함께 프로젝트할 팀원을 정하는데 큰 도움이 된다.

3명으로 팀을 구성했으면 이제 멘토님들께 연락해서 담당 멘토님이 되어주실 수 있냐고 여쭤봐야 한다.

팀당 멘토님은 4명이 붙어주신다.

이 기간에 멘토 특강도 같이한다. 여러 주제로 특강을 해주시고 그분들의 10년 20년 업계 노하우를 알려주시기도 하니 많이 참석하면 좋다.

[1차 워크샵]

리조트로 1박 2일 갔었던 거 같은데 그냥 자기소개하고 특강 몇 개 하고 레크리에이션 하고 돌아온다.

이때는 아직 팀 구성이 대부분 안되어있을 때라 자유시간에 연수생들끼리 많은 대화를 하고 팀을 구성하게 된다.

사실 일정이 매우 빡빡해서 자유시간이 많이 없다.

그래서 팀 구성을 하기 위해 잠도 포기하고 사람들을 만나고 다니는 연수생들도 있다.

[발대식]

뭐 뻔하다. 선서하고 영상 좀 보고 높으신 분들 훈화 말씀 듣고 밥 먹고 사진 찍고 끝이다.

[프로젝트 기획 심의]

팀을 구성하고 이제 어떠한 주제로 프로젝트를 진행할지를 정해야 한다.

매우 많은 고민을 했고 어려웠던 시기이다.

일단 외부에서 실제 사업하시는 분들을 심사위원으로 초빙해오기 때문에

프로젝트 주제가 단지 기술적인, 공부 목적의 자신의 실력을 발전시킬 수 있을만한 프로젝트가 아니고

사업성이 있는 프로젝트  즉 '결과물을 통해 돈을 벌 수 있는가'가 중요하다.

물론 기술적인 부분도 중요하지만 사업적인 부분을 더 본다는 것이다.

이때 멘토님들도 사업적인 부분을 강조하신다.

프로젝트 주제, 개요, 향후 일정, 기술적 요소, 기대효과 등 프로젝트 제안서 비슷하게 문서를 작성하고

심사위원분들 앞에서 발표를 한다.

첫 번째 심의에서 떨어지면 두 번째 세 번째 심의도 있다고 한다.

다행의 우리 팀은 1차 심의에서 통과돼서 바로 개발에 들어갈 수 있었다.

ps. 지정 프로젝트가 따로 있는데 3개의 팀은 멘토님들이 정한 프로젝트를 진행할 수 있다.

[2차 워크샵]

심의 끝나고 바로 2차 워크샵을 가는데 이때는 프로젝트 주제까지 모두 정해진 시기라 다들 편안한 마음으로 간다.

1차 워크샵하고 다를 건 별로 없고 50팀의 프로젝트 소개 간단하고 기억에 남는 게 없다.

선배 기수들이 몇 명 왔는데 그냥 Q & A 시간 가졌던 거 같다.

[중간평가]

8월 말쯤에 중간평가를 진행하는데 약 2달간 진행했던 프로젝트 내용을 발표한다.

우리 팀은 프로젝트 전체에서 1/3 정도 목표치를 달성해 발표했다.

[탑싯]

평가요소에 TOPCIT 점수가 들어가기 때문에 사무국에서 시험 접수를 해주고 공짜로 시험을 볼 수 있다.

10월 중순쯤에 시험을 보는데 우리 팀은 처음 팀이 구성될 때 열심히 하되 인증에 대해서 부담감을 갖지는 말자는 주의였기 때문에 프로젝트 막바지에 너무 힘들어서 나는 그냥 안 갔다. 사실 전날 밤까지 멘토링 하다가 다음날 못 일어나서 못 갔다.

어쨌든 공짜로 시험 볼 수 있기 때문에 보는 걸 추천한다.

[최종평가]

11월 말쯤에 최종평가를 진행한다.

중간평가 이후로 결원이 생겨서 부득이하게 2명에서 진행했다.

인증에 대한 부담은 없었기 때문에 멘탈이 흔들리지는 않았고 유종의 미를 거두자는 마인드로 진행했다.

웹 개발자가 없었기 때문에 마지막 1달은 처음 배우는 언어를 통해 개발을 진행해야 했고 웹 디자이너에게 외주를 맡겨가며 진행했다.

어쨌든 안 되는 건 없었고 우리 팀 프로젝트 주제가 흔치 않은 주제였기 때문에 평가 때 심사위원분들께서 고생했다고 격려를 많이 해주셨다.

[수료식]

역시 뻔하다. 선서하고 훈화 말씀 듣고 밥 먹고 사진 찍고 수료증 받고...

다만 6개월 전과 달라진 점은 모두 친해진 것

[해외연수]

팀 구성되면서 팀원들끼리 인증에 부담 갖지 말자는 마인드였기 때문에 우리 팀은 당연히 인증자가 없었지만

인증자로 선정돼 무료로 미국을 가는 연수생들에게는 축하를 보낸다. 

물론 우리 팀도 열심히 했다. 다만 인증자들은 더 열심히 했다.

센터에 그냥 상주하며 살았고 항상 있었던 사람들이다.

나도 마지막 한 달 동안 웹 개발하면서 막힐 때마다 물어보러 센터에 가면 항상 있던 사람들이었다.

받을만한 사람들이 받았던 것 같다.

내가 지원할 시기에 후기를 찾아봤을 때는 찾아도 안 나와서 매우 궁금했었는데 다음 지원자들을 위해 써줘야겠다.
휴학에 대해서 궁금할 텐데 결론적으로 우리 팀은 안 했다. 하지만 팀원들끼리 상의하에 휴학을 해도 되고 안 해도 된다.
이건 팀 구성 전에 팀원들이 소마에 어떤 마음으로 임하는지 서로 확인해야 하고 피해를 주지 않아야 하기 때문에 많은 고민을 요한다.
하면 얻어가는 건 더 많겠지만 본인의 성향 그리고 상황에 따라 해도 되고 안 해도 된다고 생각한다. 

ps. 개인적으로 휴학 추천함(남성은 재수를 안 했거나 군대가 면제라면 한 학기 휴학할만한 가치가 있다고 생각하고 여성은 4년 동안 휴학을 했거나 할 계획이 없었다면 한 학기 휴학하는 거 추천)


[경험에서 우러나온 팁] 
- 팀 꾸리기 전 최대한 많은 사람들과 많은 이야기를 해봐라.
- 팀 꾸리기 전 가능하면 소마에 임하는 태도를 확인하면 좋겠다.
- IT는 확실히 좁고 가면 분명 아는 사람 만날 것이다.

- 사무국분들은 매우 친절하고 잘 활용해라.

- 행사 때마다 유용한 굿즈를 많이 준다. 다만 전부 소마 로고가 각인되어있다.
- 9월쯤에 팀 전체가 침체기였는데 살면서 이런 거 해보는 기회 흔치 않은데 시간 날리지 말자.

- 당시에는 힘들지 몰라도 돌아보면 후회이다. 힘들어도 참고 그냥 해라.

- 소마에 시간을 많이 쓸수록 멘토님들께 배울 건 더 많아질 것이고 당연히 배우는 건 많아질 것이다.

- 소마는 90프로 자율적으로 진행된다. 본인이 노력하면 노력할수록 얻는 건 정비례한다.

- 안 하면 얻는 것도 없다.

- 새로운 것을 하는데 두려워하면 안 된다.

공교롭게도 조만간 사무국에서 11기 선발 공지를 올릴 텐데...
나도 그랬고 일부 수료생들도 내가 왜 붙었지 라는 생각을 해본 사람 많다.

나만 빼고 다들 가만 보면 붙을만해서 붙었는데 정작 본인은 왜 붙은 건지 의아해한다.
나는 안될 거라 생각하지 말고 무조건 지원해보길 바란다. 

국내 IT 대외활동에서 높은 수준의 지원과 학부생이 쉽게 경험하기 힘든 경험을 하게 될 것이다.